http://crbug.com/115287
If a JPEG has no JFIF marker, the Adode Marker must be used to determine the image color space for decoding by consulting the transform flag values of the Adobe Marker: 2 - The image is encoded as YCCK (implicitly converted from CMYK on encoding). 1 - The image is encoded as YCbCr (implicitly converted from RGB on encoding). 0 - Unknown. 3-channel images are assumed to be RGB, 4-channel images are assumed to be CMYK. The attached image has no JFIF marker, but has an Adobe marker transform 0, meaning an RGB image since it has 3 color channels. Such images fail to decode in libjpeg-turbo if swizzle decoding is active.
Created attachment 128675 [details] apron.jpg Image meta details: % jpegtopnm --comments --verbose --dumpexif apron.jpg > test.ppm Start of Image Adobe APP14 marker: version 100, flags 0x0000 0x0000, transform 0 <-- Adode Marker, transform 0 Define Quantization Table 0 precision 0 Start Of Frame 0xc0: width=225, height=156, components=3 <-- 3 color components Component 82: 1hx1v q=0 Component 71: 1hx1v q=0 Component 66: 1hx1v q=0 Define Huffman Table 0x00 Define Huffman Table 0x10 Start Of Scan: 3 components Component 82: dc=0 ac=0 Component 71: dc=0 ac=0 Component 66: dc=0 ac=0 Ss=0, Se=63, Ah=0, Al=0 jpegtopnm: input color space is 2 (JCS_RGB) <-- RGB color space, since 3 color components ...
Created attachment 128689 [details] Patch
Comment on attachment 128689 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=128689&action=review > Source/WebCore/platform/image-decoders/jpeg/JPEGImageDecoder.cpp:249 > + // FIXME: swizzler incorrectly handles Adobe transform=0 images swizzler => The swizzler (Comments should use complete sentences.)
Roger that. Flaky connection mode here. Will cq+ and fix in followup.
Comment on attachment 128689 [details] Patch Clearing flags on attachment: 128689 Committed r108870: <http://trac.webkit.org/changeset/108870>
All reviewed patches have been landed. Closing bug.
I can't tell whether this is working around an issue in libjpeg-turbo or in the layers above it. If this is something that needs to be fixed in libjpeg-turbo, let me know.
Committed r108884: <http://trac.webkit.org/changeset/108884>
Committed r108887: <http://trac.webkit.org/changeset/108887>
(In reply to comment #8) > I can't tell whether this is working around an issue in libjpeg-turbo or in the layers above it. If this is something that needs to be fixed in libjpeg-turbo, let me know. Yes it's a work-around of sorts, for the reasons noted in http://code.google.com/p/chromium/issues/detail?id=115287#c15. Seems there's no JSC_RGB -> JSC_EXT_BGRA etc converter. I believe hbono-san is preparing a libjpeg-turbo patch to remedy that ...
Greetings, Thanks for your comments. I have filed an upstream bug (*1) and uploaded my quick fix (*2). (*1) https://sourceforge.net/tracker/?func=detail&aid=3494910&group_id=303195&atid=1278158 (*2) http://sourceforge.net/tracker/?func=detail&aid=3494911&group_id=303195&atid=1278160 Regards, Hironori Bono (In reply to comment #11) > Yes it's a work-around of sorts, for the reasons noted in http://code.google.com/p/chromium/issues/detail?id=115287#c15. Seems there's no JSC_RGB -> JSC_EXT_BGRA etc converter. I believe hbono-san is preparing a libjpeg-turbo patch to remedy that ...
Reopening to attach new patch.
Created attachment 129193 [details] Patch
Comment on attachment 129193 [details] Patch Clearing flags on attachment: 129193 Committed r109086: <http://trac.webkit.org/changeset/109086>
Fixed upstream
r808 LGTM. Will it be part of the 1.2.0 libjpeg-turbo release?
1.2.0 has been out for some time. It will be part of 1.2.1.