[gs-devel] Getting a JPX stream's colorspace
ralph.giles at artifex.com
Thu Nov 29 13:01:25 PST 2007
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
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
> 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.
More information about the gs-devel