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

[Igor V. Melichev]

Ralph,

> 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.

Hmm, that's not what I mean.
In general, a strongly "equivalent" isn't possible.
For example, if you take a real gold ring,
and make its image in RGB, 
you of course will get some approximation,
but for a precise rendering you'll need a gold ink.

To my knowledge ICC profiles specify something
in RGB or in CMYK but they don't help
if the printer wants to represent gold as a mix of
silver ink and yellow ink.

> I agree 2 is better, but this isn't possible with the current 
> stream-based accessors.

Not exactly. We can decode the image and send as an RGBA stream
(or CMYKA, or the like), then the stream goes to a T-like pipe,
which selects RGB (or CMYK) and A into separate streams.
The T pipe looks as a writing filter. 
I've did such thing - search for "compression_chooser"
in gs/src.

-----------------------------------

BTW, here is another related problem.

Normally the PDF interpreter knows 
whether a page uses a transparency 
from the page dictionary before starting the page rendering.
If so, it installs the pdf14 compositor
(sorry the name "pdf14" may be misleading - it's Raph's invention).
We do not want to install pdf14 without a strong need because
it is expensive in both time and space. 

Nevertheless if a page contains a transparent JPX image,
we can't know about it from the page dict.
So we'll need to install it later - after the rendering is started, 
and it's a kind of unusual. Possibly it will need some improvement here.

Igor.


----- Original Message ----- 
From: "Ralph Giles" <ralph.giles at artifex.com>
To: "Igor V. Melichev" <igor.melichev at artifex.com>
Cc: <gs-devel at ghostscript.com>; <alex.cherepanov at Artifex.com>
Sent: Friday, November 30, 2007 11:50 PM
Subject: Re: [gs-devel] Getting a JPX stream's colorspace


> 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.
> 
> -r
> 
> _______________________________________________
> gs-devel mailing list
> gs-devel at ghostscript.com
> http://www.ghostscript.com/mailman/listinfo/gs-devel