It is well known that Adobe Photoshop for unknown reasons inverts the channel values in a CMYK JPG file, such that 0 is black rather white. The author of org.apache.fop.image.JpegImage knew this and wrote support for it. However, the condition used to determine if the JPG was generated by Photoshop is incorrect. JpegImage checks if the Adobe APPE marker is present in the file. If it is, it assumes that Photoshop created the file. Actually, many other applications use the Adobe APPE marker standard when creating JPG files but do *not* invert the CMYK channel values. As a result, these JPG files are being displayed with inverted colors.
Created attachment 7175 [details] Fixes the described bug
Attachment 7175 [details] is my solution to the bug. It examines a region of the header FFE1 which appears to consistently identify JPGs generated by Adobe Photoshop with the text string "Adobe Photoshop" beginning 124 bytes past the index of "FFE1". I have tested this patch with five unique CMYK JPGs generated by Adobe Photoshop 7. While a better solution would be to check if the CMYK channel values are indeed inverted, I know of no way to perform such a test. The following URL, part of the IJG JPEG library, seems to confirm that there is no such test: http://courses.cs.deu.edu.tr/cse566/libjpeg.htm
Created attachment 7192 [details] CMYK JPEG generated by Adobe Photoshop
Created attachment 7193 [details] CMYK JPEG generated by the "ImageWrite" image I/O plug-in for JAI
After testing before and after, I have applied the patch to the maintenance branch. Thanks very much. Please note that this class has been modified in what look to my eye like substantial ways in the trunk. The image logic or something related to layout of images appears to be broken in the trunk ATM, as placing either test file into normal.fo throws FOP into an infinite loop. So, we may need to revisit this in the trunk code at some future time. I'm sorry for that inconvenience.
Thanks for applying the patch! Let me know when you're ready to revisit this for the trunk code; I'll be happy to write a new patch. Or better yet, I'll just do it when the first milestone trunk version is released.
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed