The customer reports and I've verified that the attached PDF file has spurious vertical lines when converted by Ghostscripted gs8.63 and head (r9230). These lines do not appear when the file is opened with Acrobat 9.0 or Apple Preview. The command line I'm using for testing: bin/gs -sDEVICE=tiff24nc -o test.tif ./lakeville_upa_plan_set_21.pdf Converting the file with the luratech decoders does not change the output.
Created attachment 4604 [details] lakeville_upa_plan_set_21_g.pdf
This file has /JPXDecode image with /BitsPerComponent 4 . Ghostscript interprets high bytes of the data stream as a black pixel causing wrong black stripes and the wrong line length. With /BitsPerComponent 8 the scan line length becomes correct but the values received from the filter are too small and look black. So /JPXDecode need to scale this kind of data up.
Assigning to Ralph since this is apparently a JPXDecode issue.
Alex's analysis is correct. Jasper is correctly decoding the image, but the interface code in sjpx.c incorrectly assumes the component with stored with 8 or more bits of precision, when the image has just four, in both the scaling and the stride calculation.
Created attachment 5120 [details] jpxd-4bit.diff Attaching a minimal patch which fixes the bug, with no expected side effects. This was committed at r9801 and will be part of the next release.
Closing the bug since the customer issue is resolved and there are no related regressions. I've opened 690545 for tracking some related improvements for non-8-bit images.
With Luratech decoder the lines are still there and debug MSVC build complains about heap damage.
The Luratech problem has been fixed by the rev. 691816. See bug 691816.