Created attachment 12985 [details] PDF file When converting the attached PDF file to TIFF parts of the image are inverted. I tried converting to BMP, PNG and got the same result. Adobe and Foxit render this PDF fine.
Created attachment 12986 [details] BMP file
I am temporarily removing the customer ID since the yahoo.com email address does not allow us to identify the customer company. We understand the desire to not use a company email address for privacy. Please email support @ artifex.com and let us know the company name so we can insure that the customer ID is correct and we will add it and make sure it is tracked as a customer bug, and receives the proper priority. That being said, I viewed this with Ghostscript, just on the screen (Windows 'display' device) and see the portions that are inverted as in the BMP. I extracted the JPEG data and view it with other image viewers. Photoshop shows this as Acrobat does ("correct") as does ImageMagick (version 6.8.7-6) that I happen to have installed and the Windows Media Player, but XnView, mupdf, and of course, Ghostscript all have the inverted parts (white on black). This appears to be caused by the JPEG library we are using (mupdf uses the same software for JPEG images). It could be that XnView is as well.
Updated with customer number (thanks for the confirmation) and set customer level priority.
Created attachment 12988 [details] image_object_7.jpg Extracted JPEG data from the file that some viewers get right, but mupdf, gs, and XnView trip up on.
(In reply to Mike from comment #0) > I tried converting to BMP, PNG and got the same result. Adobe and Foxit > render this PDF fine. Actually, no. Both Adobe and Chrome (which is based on Foxit) render this file incorrectly too - just differently incorrect. In the areas where gs displays inverted colors, they have green corruption on the right hand edge of the image. I have yet to find any viewer that renders it completely correctly.
After some investigation, I have identified the problem. Macroblock 20743 is the one that first goes wrong. It has a coded DC coefficient of 0x3f7, with a quantiser value of 6. This results in a DC value of 6090 being fed into the idct. Tests show that the idct overflows with any value larger than 4096 (or lower than -4096). A simple fix is therefore to clamp the DC value in the idct. I have emailed the maintainers of jpeglib to get their opinion on such a fix.
The JPEGlib maintainers have acknowledged my bug report, but not said anything more, despite me prodding them. I have therefore implemented my own fix. The work was done in 2 commits for gs: commit dc62c90930512f4b571f68c9110022b234cbd411 Author: Robin Watts <robin.watts@artifex.com> Date: Wed Nov 2 16:19:02 2016 +0000 Bug 697186: Tweak to previous JPEG fix. Only clamp the DC coefficient. This shouldn't make a difference in any real world cases, but is more correct. commit 8dcec8cc076a0cf8350ca7a6ec1d3136812e2a24 Author: Robin Watts <robin.watts@artifex.com> Date: Tue Nov 1 18:40:04 2016 +0000 Bug 697186: Workaround JPEG lib bug. Commit fix for overflow. Awaiting response from IJG. You can build a new ghostscript from git now and get the fix, or wait until March when the next release will be out.