* [9fans] Proposed: Image Conversion Server @ 2006-10-26 13:08 Randall Bohn 2006-10-26 15:01 ` Skip Tavakkolian 2006-10-26 16:38 ` matt 0 siblings, 2 replies; 8+ messages in thread From: Randall Bohn @ 2006-10-26 13:08 UTC (permalink / raw) To: 9fans I want to make a new server that converts JPEG files to Plan9 image files. Then you can just connect the server to a directory and you get image files out... convert-jpegs -s /srv/xjpeg -src /usr/glenda/jpegs mount -c /srv/xjpeg /n/images ls /usr/glenda/jpegs pawn.jpg bishop.jpg knight.jpg rook.jpg ls /n/images pawn.jpg.image bishop.jpg.image knight.jpg.image rook.jpg.image If you want on-the-fly conversion you can use these images direct from /n/images. If you want to batch convert them just dst=/usr/glenda/images { mkdir $dst cp /n/images $dst } Is server-load .. mount the best way to do this? This would be a first step towards an image processing system that could apply a chain of filters to the source images. Thanks, rsbohn ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 13:08 [9fans] Proposed: Image Conversion Server Randall Bohn @ 2006-10-26 15:01 ` Skip Tavakkolian 2006-10-26 16:38 ` matt 1 sibling, 0 replies; 8+ messages in thread From: Skip Tavakkolian @ 2006-10-26 15:01 UTC (permalink / raw) To: 9fans > Is server-load .. mount the best way to do this? This would be a first > step towards an image processing system that could apply a chain of > filters to the source images. the BUG section of pipefile(1) agrees that an fs is the right way. i wonder if there's a general conversion fs; maybe by giving it the filter for the conversion (e.g. "jpg -c"). for an operating model, wouldn't something like lnfs(1) work better? convert-jpegs /usr/glenda/jpegs ls /usr/glenda/jpegs pawn.jpg cat /usr/glenda/jpegs/pawn.jpg.9 then in convert-jpgs if found pawn.jpg.9 return contents if not look for pawn.jpg if found generate pawn.jpg.9 from pawn.jpg.9 and return contents if not error not found ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 13:08 [9fans] Proposed: Image Conversion Server Randall Bohn 2006-10-26 15:01 ` Skip Tavakkolian @ 2006-10-26 16:38 ` matt 2006-10-26 17:34 ` erik quanstrom 1 sibling, 1 reply; 8+ messages in thread From: matt @ 2006-10-26 16:38 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs Once you've converted the jpegs to plan9 bitmaps, what's the point of having them hanging around in memory ? For image editing etc. the plan9 bitmap is not the best structure (imho) You'll need the images separated into colour channels, RGBA for instance, if you want to do anything interesting with them. I started such a beast that mounted images as RGB/HSB with alpha and got it to do a few tricks, it has a couple of bugs so I never released it. I think I talked about it on the list but it might have been in IRC Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 16:38 ` matt @ 2006-10-26 17:34 ` erik quanstrom 2006-10-26 18:02 ` maht 0 siblings, 1 reply; 8+ messages in thread From: erik quanstrom @ 2006-10-26 17:34 UTC (permalink / raw) To: 9fans the images are seperated by channel. man image(6) and draw(3). a 24-bit image is 1 byte each r, g, b premultiplied by the alpha channel which is in the fourth byte. - erik On Thu Oct 26 12:44:26 EDT 2006, mattmobile@proweb.co.uk wrote: > Once you've converted the jpegs to plan9 bitmaps, what's the point of > having them hanging around in memory ? > > > For image editing etc. the plan9 bitmap is not the best structure (imho) > You'll need the images separated into colour channels, RGBA for > instance, if you want to do anything interesting with them. > > I started such a beast that mounted images as RGB/HSB with alpha and got > it to do a few tricks, it has a couple of bugs so I never released it. > > I think I talked about it on the list but it might have been in IRC > > Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 17:34 ` erik quanstrom @ 2006-10-26 18:02 ` maht 2006-10-26 23:39 ` erik quanstrom 0 siblings, 1 reply; 8+ messages in thread From: maht @ 2006-10-26 18:02 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > the images are seperated by channel. man image(6) and draw(3). > a 24-bit image is 1 byte each r, g, b premultiplied by the alpha channel > which is in the fourth byte. > but they are not contiguous in memory, and that is the "usual" way to split an RGB for when you want to manipulate them surely you'd want to undo the premultiply of the alpha What are you going to do when you want to move the RGB into HSB or CMYK space ? The best approach, in my opinion (and it's only that), is to spearate them into channels and then you can have a set of operations that works on combining channels and doesn't care about what that channel is representing. A bitmap of 8 bit values represents R,G,B,A,H,S,B,C,M,Y and K and any others you come across. Having them interleaved as RGBA, RGBA, RGBA will give you a headache sooner or later. Split them up, get them away from a particular image format be it plan9 bitmap, tga or whatever and then you can choose to write out / read in whatever formats you like. Just my experience of working in broadcast video processing, YMMV. Matt ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 18:02 ` maht @ 2006-10-26 23:39 ` erik quanstrom 2006-10-27 8:46 ` Steve Simon 0 siblings, 1 reply; 8+ messages in thread From: erik quanstrom @ 2006-10-26 23:39 UTC (permalink / raw) To: 9fans On Thu Oct 26 17:08:39 EDT 2006, mattmobile@proweb.co.uk wrote: > > > the images are seperated by channel. man image(6) and draw(3). > > a 24-bit image is 1 byte each r, g, b premultiplied by the alpha channel > > which is in the fourth byte. > > > > but they are not contiguous in memory, and that is the "usual" way to > split an RGB for when you want to manipulate them it's trivial to upconvert to 32-bit images. and then if you take every fourth byte, you have easy access to the channels. i don't see the difficulty. > > surely you'd want to undo the premultiply of the alpha http://alvyray.com/Awards/AwardsAcademy96.htm unfortunately i'm unable to currently locate the original paper referenced at the bottom of that page. > What are you going to do when you want to move the RGB into HSB or CMYK > space ? maybe there's something i'm missing, but what is the benefit to using different colorspaces? if you're using a normal computer display or printer, and you're not doing artbook printing, rgb seems to be the most straightforward representation. the screen, after all, is RGB. > Having them interleaved as RGBA, RGBA, RGBA will give you a headache > sooner or later. i fail to see this difficulty. - erik ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-26 23:39 ` erik quanstrom @ 2006-10-27 8:46 ` Steve Simon 2006-10-27 9:03 ` Bruce Ellis 0 siblings, 1 reply; 8+ messages in thread From: Steve Simon @ 2006-10-27 8:46 UTC (permalink / raw) To: 9fans >> surely you'd want to undo the premultiply of the alpha Yes I believe you do, the alpha blends the image with others it is to be composited with, for image processing you want to undo this and then redo it after processing - say you want to threshold the image to into just two levels of grey, now your blending is undone unless you first remove the blending, do the threshold and then replace it. > http://alvyray.com/Awards/AwardsAcademy96.htm > unfortunately i'm unable to currently locate the original paper referenced at the bottom > of that page. There is a link to it at the bottom of this page ☺ http://plan9.bell-labs.com/wiki/plan9/Papers/index.html > maybe there's something i'm missing, but what is the benefit to using different colorspaces? In theroy you can do any manipulation in any colourspace but if you want to say, correct spatial luma variations in an image and adjust its saturation then having it in CMYK is much more efficent than RGB, you do get the overhead of conversion of course, and if you don't keep enough bits in the middle then you get colourspace quantisation. Swings vs. roundabouts as ever. -Steve ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] Proposed: Image Conversion Server 2006-10-27 8:46 ` Steve Simon @ 2006-10-27 9:03 ` Bruce Ellis 0 siblings, 0 replies; 8+ messages in thread From: Bruce Ellis @ 2006-10-27 9:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs e.g both Score! and More! were entirely composited in LCbCr space - because it was a much richer option. people who think RGBA is it never did any video production. sometimes people view things on other than dumb CRTs. a lot actually. brucee On 10/27/06, Steve Simon <steve@quintile.net> wrote: > >> surely you'd want to undo the premultiply of the alpha > > Yes I believe you do, the alpha blends the image with others it is > to be composited with, for image processing you want to undo this and > then redo it after processing - say you want to threshold the image to > into just two levels of grey, now your blending is undone unless you first > remove the blending, do the threshold and then replace it. > > > http://alvyray.com/Awards/AwardsAcademy96.htm > > unfortunately i'm unable to currently locate the original paper referenced at the bottom > > of that page. > > There is a link to it at the bottom of this page ☺ > http://plan9.bell-labs.com/wiki/plan9/Papers/index.html > > > maybe there's something i'm missing, but what is the benefit to using different colorspaces? > > In theroy you can do any manipulation in any colourspace but if you want to > say, correct spatial luma variations in an image and adjust its saturation > then having it in CMYK is much more efficent than RGB, you do get the overhead of > conversion of course, and if you don't keep enough bits in the middle then you > get colourspace quantisation. > > Swings vs. roundabouts as ever. > > -Steve > ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-10-27 9:03 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-10-26 13:08 [9fans] Proposed: Image Conversion Server Randall Bohn 2006-10-26 15:01 ` Skip Tavakkolian 2006-10-26 16:38 ` matt 2006-10-26 17:34 ` erik quanstrom 2006-10-26 18:02 ` maht 2006-10-26 23:39 ` erik quanstrom 2006-10-27 8:46 ` Steve Simon 2006-10-27 9:03 ` Bruce Ellis
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).