pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[pdf-devel] JPX filter implementation


From: LRN
Subject: [pdf-devel] JPX filter implementation
Date: Fri, 02 Jan 2009 03:20:29 +0300
User-agent: Thunderbird 2.0.0.19 (Windows/20081209)

I've noticed that JPX filter implementing task is till unassigned, so
i've looked around the code and 32000-1 to see what it takes to complete it.
Correct me if i'm wrong.
In PDF we have something like this (from 32000-1, slightly altered):

21  0  obj % Resource dictionary for page
<<   /ProcSet  [  /PDF  /ImageB  ]
  /XObject  <<  /Im1  22 0 R  >>
>>
endobj
 
22  0  obj % Image XObject
<<   /Type  /XObject
  /Subtype  /Image
  /Width  256
  /Height  256
  /ColorSpace  /DeviceGray
  /BitsPerComponent  8
  /Length  83183
  /Filter  [  /ASCII85Decode  /JPXDecode ]
>>
 
stream
<JPX image encoded in ASCII85 here>
endstream
endobj

According to 32000-1, the image is really JPX, with all metadata and
stuff (you can decode it with ASCII85Decode, then put it into a file and
such file will be readable by any JPEG-2000 image viewer). It is mostly
JPX baseline with few exceptions.
32000-1 also says that most of the parameters (from Image XObject) that
are used to display the image should be taken directly from JPX, with
few exceptions. These exceptions are:
Width and Height (we have to get both JPX w&h and XObject w&h and check
that they are the same; 32000-1 promises that, but it's always better to
recheck)
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.
It also has to get two parameters from GnuPDF itself or from the client:
Resolution reduction - allows JPXDecode to decode the image at reduced
(1/2, 1/4, 1/8 etc) resolution which is faster.
Quality layers - allows JPXDecode to decode only specified number of
quality layers rather than all of them (again - it's faster, but
produces lower quality output).

So far i've found no upstream parameter passing code in GnuPDF. And
GnuPDF is mostly unaware of such things as "color space" and is
incapable of any image rendering whatsoever. Maybe you've put the JPX
task on the task list too early? :)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]