Re: [pdf-devel] JPX filter implementation

[Ralph Giles]

On Thu, Jan 1, 2009 at 4:20 PM, LRN <address@hidden> wrote:

> ColorSpace (optional), which controls the meaning of each color
> component. 32000-1 promises that number of color components will always
> match the ColorSpace. Anyway, there are a lot of things there about
> ColorSpace, so GnuPDF must be pretty good at colorspaceing and channel
> combining (since JPX filter produces a number of uninterleaved channels;
> plus, the image may be a mask for something else).
> Everything else comes from JPX, so JPXDecode must have a way to pass
> parameters upstream.

Note that the passing goes both ways. If the image dictionary has a
ColorSpace key, it overrides whatever is in the JPX stream. Normally
the rule that the number of components match lets one just ignore the
internal colour space as long as the decoder returns the data without
applying colour correction. However it's not clear how this should be
interpreted in the case of Indexed colour spaces. I've seen a wild
file that assumes the palette in the PDF-level Indexed space must be
applied *instead* of the palette in the JPX stream. So in addition to
the JPX stream decoder passing the internal colour space to the PDF
interpreter, the PDF interpreter also has to be able to communicate
the external colourspace (or at least what kind of raw data it wants)
to the decoder.

As for channel combining, the data source for images is defined to be
a sequence of chunked pixels. So in Ghostscript we do the channel
interleave in the decode filter. Of course you might want to do
something more sophisticated in gnupdf.

In general the JPXDecode filter breaks the stream abstraction quite thoroughly.

FWIW,
 -r