9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [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).