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

Igor V. Melichev igor.melichev at artifex.com
Thu Nov 29 23:53:25 PST 2007


Ralph,

> There's also the issue of transparency. The PDF spec currently leaves
> this fairly unspecified, but I expect we'll see it at this point. I
> understand the graphics library has support for images with a separate
> transparency mask, but not direct RGBA-style image data?

There is no transparent images at all.
Our graphics library is oriented to PDF transparency model,
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 think the right way is (2),
but it will need a work, which doesn't look small.

>> I don't know what you mean by "parameterized RGB".

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.

> Because sRGB was designed to more-or-less match computer
> displays (and now some computer displays are designed to more-or-less
> match sRGB) this is a good default

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

1. Printers and displays are different by definition.
Converting CMYK to RGB and back to CMYK isn't possible
without loosing a color information.

2. A Printer may use multiple spot colors, and
converting a DeviceN color to any "standard"
color space won't work if the image uses the same
DeviceN space.

3. If the output device supplies its ICC profile,
and the source image supplies the same or similar ICC profile,
an intermediate conversion to a "standard"
color space isn't optimal and causes color distortions.

4. Some customers want their own color conversion callbacks.

> For advanced use, one can specify an
> explicit ICC profile.

Except for (4) above.

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.

>> Besides all this, I suspect we'll get another problem
>> with the PDF interpreter code. As you know, it is coded in Postscript,
>> and expects a Postscript representation of a color space.
>> Will need to shunt it with passing the color space data
>> around Postscript (because a converting the C structure to Postscript
>> looks too cumbersome). Possibly we'll need structure object
>> to handle gs_color_space_s by iref, and to extend the PDF interpreter 
>> with
>> it.

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.

Igor.

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


> On Fri, Nov 30, 2007 at 01:11:26AM +0300, Igor V. Melichev wrote:
>
>> Well, now we have 3 spaces with no parameters (DeviceGray, DeviceRGB,
>> DeviceCMYK),
>> and 2 with parameters : CIEBasedABC and ICCBased.
>
> Indexed also has parameters.
>
>> I think we must not assume that the PDF spec won't be improved with it.
>> So lets keep in mind that Separation and DeviceN may be possible
>> in future.
>
> There's also the issue of transparency. The PDF spec currently leaves
> this fairly unspecified, but I expect we'll see it at this point. I
> understand the graphics library has support for images with a separate
> transparency mask, but not direct RGBA-style image data?
>
>> If it is restricted with a specific RGB, it can't be used generally.
>> It could be used if it converts to as parameterized RGB,
>> such as an ICC profile. Please explain more if you want me to think
>> in this direction.
>
> I don't know what you mean by "parameterized RGB". I think the spec
> defines sRGB as a default so that "simple" image streams are in fact
> calibrated, and not in some unspecified device space as in formats like
> baseline JPEG. Because sRGB was designed to more-or-less match computer
> displays (and now some computer displays are designed to more-or-less
> match sRGB) this is a good default. For advanced use, one can specify an
> explicit ICC profile.
>
>> Besides all this, I suspect we'll get another problem
>> with the PDF interpreter code. As you know, it is coded in Postscript,
>> and expects a Postscript representation of a color space.
>> Will need to shunt it with passing the color space data
>> around Postscript (because a converting the C structure to Postscript
>> looks too cumbersome). Possibly we'll need structure object
>> to handle gs_color_space_s by iref, and to extend the PDF interpreter 
>> with
>> it.
>
> This Alex's domain, of course, but I was expecting to have to translate
> whatever is returned into Postscript structures. If we do this, it
> should be something we can reuse in porting the PDF interpreter to C.
>
> -r 



More information about the gs-devel mailing list