Created attachment 10231 [details] Example PDF file that does not render correctly Trying to render certain PDF files containing JPEG2000 encoded images results in a rangecheck error message on the command line and an empty result image. I used the precompiled Ghostscript 9.10 x86 Windows executables with the following command line: "C:\Program Files (x86)\gs\gs9.10\bin\gswin32c" -I"C:\Program Files (x86)\gs\gs9.10" -dNOPAUSE -r300 -dBATCH -sOutputFile=test.tif -sDEVICE=tiffgray Testdokument.pdf Rendering the PDF file works correctly with Ghostscript 8, for example GS 8.71 that I was using previously. With GS 9.10 I only get an empty (white) image with the correct size. Attached is an example file that shows this behaviour.
The JPEG2000 images contained in the PDF file are invalid, they declare themselves to have a colour depth of 128 Bits Per Component. The valid range for JPEG2000 is 1 to 38 and for PDF 1 to 16. In fact the images appear to use 8 bits per component. Since the produce seems to be JasPer I guess its no great surprise that the images are invalid. While this is technically illegal Acrobat, as usual, ignores the error and seems to use 8 BPC. I have a test underway which does the same for Ghostscript and will commit it if no problems arise. Note that if such problems do arise in future this hack may be removed as the images *are* illegal.
'Fixed' in commit 6fe7ace41f8afaba72f0f1da7747c062382346fc
Thanks a lot for the quick response. However, after having taken a look at the JP2 file format specification myself I'm actually not sure if the embedded JPEG2000 files are really invalid. At the location of the bits per component value in the file there's a byte with the value 255 which is interpreted as 128 bits per component according to your comment, but is really a special code indicating that the actual bit depth is specified per component in a separate "Bits per component box" which is present in the file with values of 8, 8 and 8. So while your fix will work for this file, it is most likely not correct in all cases where the bit depth is specified per component (and potentially using a different value per component).
(In reply to comment #3) > component value in the file there's a byte with the value 255 which is > interpreted as 128 bits per component according to your comment, but is > really a special code indicating that the actual bit depth is specified per > component in a separate "Bits per component box" which is present in the > file with values of 8, 8 and 8. I couldn't find that in the ISO spec (which is no surprise, its an awful spec). Can you point me to it please ? A page reference in the spec would be ideal, or failing that the box name. > So while your fix will work for this file, it is most likely not correct in > all cases where the bit depth is specified per component (and potentially > using a different value per component). That's why I was looking for an alternate specification.....
What I have in front of me is a document titled ISO/IEC 15444-1 second edition 2004-09-15 (Information technology - JPEG 2000 image coding system: Core coding system) Annex I: JP2 file format syntax The relevant sections are I.5.3 (JP2 Header box), I.5.3.1 (Image Header box) and I.5.3.2 (Bits per Component box). The box types are 'jp2h', 'ihdr' and 'bpcc', respectively. The BPC byte where the 128 came from (byte value 255) is in the image header box and signals the existance of a bits per component box where the actual BPC values are stored. I hope this helps.
(In reply to comment #5) > The relevant sections are I.5.3 (JP2 Header box), I.5.3.1 (Image Header box) > and I.5.3.2 (Bits per Component box). The box types are 'jp2h', 'ihdr' and > 'bpcc', respectively. Yes I managed to find that, I have some code in test which reads the bpcc values. This is still poor practice, if the bpcc values are the same they are supposed to be listed in the ihdr, the presence of the bpcc (and a value of 255 for BPC) is (IMO) an indication that the colour components have differing depths, which is something we (and I think PDF in general) can't cope with. > The BPC byte where the 128 came from (byte value 255) is in the image header > box and signals the existance of a bits per component box where the actual > BPC values are stored. True, but it also says: "If the bit depth is the same for all components, then this parameter specifies that bit depth....If the components vary in bit depth, then the value of this field shall be 255 and the JP2 Header box shall also contain a Bits Per Component box" Which to me says that you shouldn't have a bpcc box if the depth of all components is the same. Well I think my current code will handle this acceptably anyway, and will raise a warning if the BPC is not the same for all channels
Yes, I also think that the bpcc box should not have been created in this case, but on the other hand, evaluating the bpcc box and taking the bit depth from there if it exists shouldn't hurt anyone either. But since I guess that 8 bits really should be by far the most common bit depth, your code will probably be good enough most of the time. I guess the author of the software that created the JP2 file was somewhat lazy and decided to always create the bpcc box, just in case...
This commit be574c5550733da6b2ffa43fbc2099ae01608797 reads the bpcc box if present and ignores the BPC in the ihdr. It uses the first BPC, and raises a warning if they are not all equal.
Excellent. Thank you very much!