[gs-devel] Getting a JPX stream's colorspace

Ralph Giles ralph.giles at artifex.com
Fri Nov 30 12:50:41 PST 2007

On Fri, Nov 30, 2007 at 10:53:25AM +0300, Igor V. Melichev wrote:

> There is no transparent images at all.
> Our graphics library is oriented to PDF transparency model,

Ok, thanks for confirming.

> which associate a mask with a group.
> A group is any combination of graphic objects.
> A mask is also a group.
> So we first render the mask to a buffer,
> then render the group "through" the mask.
> Is an image includes alpha, we'll need to do
> one of 2 things : (1) run the image 2 times
> (and the image stream must be reusable),
> or (2) install 2 raster buffers (for the image and for the alpha),
> and render to them "in parallel".

I agree 2 is better, but this isn't possible with the current 
stream-based accessors. Not small inded. JPX images are internally 
planar, so installing 2 raster buffers in the image reader is
very easy. Formats that embed PNG directly like XPS and SVG will
need to copy the data out of RGBA pixels, just as Tor's
code already does, and the distinction is not so critical.

Another thing that is needed in both cases is a way to return the 
parameters associated with a parameterized colorspace. This is a
third buffer method (2) should support.

> I mean that the color space is specified with some
> parameters besides its name. For example
> an RGB space may be defined with an ICC profile,
> which supplies the parameters.

I see, thanks.

> I do not think that we can use any specific space
> as a default for output colors :

I intended to suggest that the "RGB is sRGB" assumption
might have some validity for our graphics library when
we implement accurate color conversion. It is not a
general solution for all the reasons you outline 
(especially not treating all images are sRGB!) but it
may be a useful improvement for cases there there is
otherwise no calibration at all on an RGB or Gray source.

> Also I'm not sure whether an ICC profile
> can work for spot colors. Can it ?
> I mean we'll need to support DeviceN
> as the output color model.

My understanding is that an ICC profile can define an
equivalent representation of a spot color in a generic
colorspace for preview display and proofs. Of course
the channel should be kept distinct for actual rendering
on a device that supports that particular spot colorant.

> After thinking more on this,
> I see it can be done simpler.
> The PDF interpreter could set
> /ColorSpace = /.FromJPX to the image dictionary,
> so we don't need a new type of iref.
> ".FromJPX" is our special name.
> But we still will need to patch the PDF interpreter
> with it.

Alex? I'd like to hear your opinion on details like this.


More information about the gs-devel mailing list