P: Jpg exposes bugs in QImage and ZoomBrowser

I see you've spent extra time replying to each individual thread trying to shift blame to Qimage and away from the bug that we both know exists in CS5. Without the CS5 bug, I would never have found the Qimage bug so yes we both have bugs. Have you fixed yours yet? I've fixed and released mine.

Bottom line: there is a CS5 bug in 12.0.4 and there *was* a bug in Qimage Ultimate v2012.103. To outline the bugs we've found in this thread (as I will not be back here because it serves no further purpose for either side at this point):

CS5 bug: Exact same file and program settings can cause a bug depending on what was converted prior. The bug is that under the right (inconsistent) conditions, CS5 12.0.4 will embed sRGB profiles into all embedded thumbnails. When it works properly (again depending on what was converted prior, even in a separate session), the thumbnails don't have the inapplicable (extra) profiles.

Qimage bug (fixed): A bug in the algorithm used to extract the embedded profile was inappropriately following the parse tree and parsing both the original image and the thumbnail images when looking for an embedded profile. The bug has never surfaced because the condition simply has never been encountered in order for it to surface: there really should only be one profile embedded in any file (including the thumbnails within). Until CS5 12.0.4, no program has ever tried to embed color spaces into embedded thumbnails as they should be sRGB by definition. With the extraneous data, the bug surfaced. The bug is fixed in Qimage Ultimate v2012.104.

BTW, I never posted the wrong file. If you follow the directions in the original ZIP file which were detailed and WILL reproduce the CS5 bug (call it a minor bug if you want, doesn't matter any more), this whole thing could have been solved 9 days ago. Instead, you're looking in the JPEG I included in the ZIP which the instructions clearly say is only there because that is a JPEG that (when present), causes CS5 to inappropriately start embedding color spaces in thumbnails. The instructions very clearly say to use that JPEG as test conditions and *examine the output files from CS5*. Had you done that, this would have been so much easier. Instead, you were so convinced there couldn't possibly be a problem in CS5 that you completely ignored the readme file in my original ZIP. I know you ignored it: or you wouldn't have been examining the sRGB profile embedded in the (superfluous) JPEG that was included. And that would have prevented you from posting the comments like all you've seen are "anecdotes and confused descriptions": a post I see you've now deleted.

Anyway, over and out. No more gained from posting here.

Which surfaced due to the CS5 bug that inconsistently produces a header that has inapplicable profiles attached to multiple thumbnails in the header.

Qimage had a bug, yes, but it only surfaces when the CS5 bug produces JPEG's with inapplicable profiles attached to multiple thumbnails in the header.

Already fixed and released. How are you doing on the CS5 bug?

Follow up - the JPEG file is not "just fine". Sometimes CS5 produces JPEG's with the correct header and sometimes it produces a header that has inapplicable profiles attached to multiple thumbnails in the header. While the aberrant files *will* parse, embedded profiles are not applicable to thumbnails and the inconsistent saving behavior needs to be fixed so that the same file converted with exactly the same settings will produce the same output: not different output depending on a "leftover" state based on what was converted previously. The Qimage bug, which only surfaced due to the Adobe bug, has already been fixed. Please focus on consistent file saving with the next CS5 release.

Looks like you were talking about the QImage bug. Check with Mike to see when he'll have a version out that correctly parses JPEG files with color profiles.

The extra tags are harmless to any correctly written JPEG parser. This entire issue has been about a major bug in QImage that just happened to be triggered by a very minor inconsistency in Photoshop. Inaccurate and incomplete descriptions of the problem didn't help. Someone who jumped to incorrect conclusions about the cause didn't help. Not providing the examples requested didn't help. Repeatedly insulting the people trying to help you didn't help. Etc.

I couldn't find anything at the file offsets because you posted the wrong ZIP archive and had me looking in the wrong JPEG file. You only posted the "bad" file 23 hours ago, and I responded about 2 hours later with the diagnosis. Before that you only gave us source files that failed to reproduce the problem.

Failing to parse JPEG images correctly isn't exactly a minor issue. That's like claiming to read a language because you recognize 4 or 5 words, most of the time.

Next time, consider asking for help debugging your software instead of making inaccurate claims about other companies and dragging out what should have been a 5 minute debugging session.

Chris,

You're welcome! Took 10 days but you do finally see that there is a bug in CS5. We started at "deny, deny", went to "that's impossible", and we've now ended up with "oh yes, there ARE three profiles in the file, but two of them are attached to thumbnails". You and I both know that those two extra APP2 profile tags don't belong in there attached to thumbnail(s) or not, which is why no previous version of PhotoShop (or any other software) has ever done that, nor should 12.0.4. That's probably why you never thought of looking there even when I pointed out the exact file offsets: because they don't belong there.

And no, it's not a minor bug. If you want to define sloppy, the fact that CS5 12.0.4 cannot consistently save the same file the same way twice, randomly inserting extraneous data into the header is a MAJOR bug. I'm sure people who regularly use file cataloging/archiving/backup software are pleased that CS5 will create completely different files on two different runs even though the image, settings, and software version are the same. Kinda makes it hard to tell if your latest conversion is really any different from the previous! Professional software can at least save the same file the same way twice.

And yes, now that you've finally looked in the file where I've been pointing for the last 10 days and you realized CS5 was embedding color spaces into thumbnails (sometimes), you found the CS5 bug and pointed out a minor issue in Qimage as a result of that info. Headers are not parsed correctly if they have undefined data chunks not defined in the EXIF specs (embedded color spaces should not be in thumbnails: thumbnails are sRGB as you pointed out above). Easily fixable and that's a lot less of a problem because I've been doing this for 13 years and Qimage does not misread an embedded profile unless it encounters a malformed header: that combo did set off a bug which I need to fix. So thank you for pointing that out. See, help can go both ways so in the future I hope we can do this without the condescending words and the Adobe pedestal.

Turns out QImage was the problem -- bugs in the QImage JPEG parsing caused it to read the wrong color profile.

Follow up - Mike's guess was wrong. The JPEG file is just fine, but QImage's parsing code is broken and it picked up the wrong profile.