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

[Ralph Giles]

On Thu, Nov 29, 2007 at 10:57:54PM +0300, Igor V. Melichev wrote:

> 1. What types of color spaces may be returned from .jpxgetcolorspace ?
> Here is what the graphics library handles :
> "DeviceGray", "DeviceRGB", "DeviceCMYK", "DevicePixel", "DeviceN",
> "ICCBased", "CIEBasedDEFG", "CIEBasedDEF", "CIEBasedABC", "CIEBasedA",
> "Separation", "Indexed"
> (I dropped 'Pattern" because likely it's not a case for JPX).

Right, "Pattern" is disallowed for JPX image streams.

I was thinking support for DeviceGray, DeviceRGB, DeviceCMYK and Indexed 
would be a good place to start. The standard colorspaces are actually 
sRGB-based, the the PDF spec mentions falling back to device space if 
you can't do better. Only indexed requires returning something besides 
an enum. We already have such an enum for passing the colorspace the 
other direction.

The JPX format also supports CIE XYZ, CIE Lab, Y'CrCb and arbitrary 
component collections described by a (limited complexity) ICC profile.
Except for ICC-calibrated RBG or CMYK, I've not seen these in the wild. 
As I read the spec, PDF doesn't support Separation/DeviceN-like images 
in JPX, although the underlying format is perfectly capable of it.

> 2. What information about a specific color space to be retrieved with
> .jpxgetcolorspace ?
> For example, if it returns a CIEBased space, does it need to return
> all parameters of CIEBased space ? (Maybe you need to
> discuss with Alex for obtaining a right answer).

I don't know. Obviously for full end-to-end color conversion we want to 
return a specific calibrated state: parameters for Lab, sRGB and friends 
instead of just DeviceRGB, and general ICC profiles when they are 
specificed.

> BTW, As I understand, the PDF interpreter code needs a color space
> before running an image, but then it applies a JPX filter
> to decode the image data. Can JPX library perform
> a conversion to another color space as for ProcessColors?

The jasper library has internal colorspace conversion code, so we could 
in fact ask it to always return RGB in such cases. The Luratech decoder 
does not. The colorspace key from the image dictionary (if any) is 
already passed to the decoder, since this must override the internal 
colorspace description, so we need only do internal conversion for 
files that don't specify the colorspace at the PDF level.

This would let us render the files we've seen, and there is some 
future-proofing with Jasper, but it will not be optimal for CMYK 
images. And in general we want a better solution for end-to-end color 
conversion, which it doesn't help with. I suggest we add to the current 
work-around in this direction, but we still need to have a discussion 
on how to properly report the colorspace.

 -r