P: Jpg exposes bugs in QImage and ZoomBrowser

My main concern is why was this minor issue introduced? What other things are lurking around?

Yes, Adobe is working on a fix to the minor issue that triggered the bugs in the other software. But it is not a big priority for Adobe because it is a very minor issue, and the other software really had bugs in it.

Accepted that other software may be at fault as well but are Adobe working on a fix to their software?

A minor issue in the JPEG files written by Photoshop exposed a bug in Canon's Zoombrowser and QImage. QImage has fixed their bug, and Canon is working on theirs.

Hi,

I have found this same problem with PSE 10 simply with a JPG.

My test was to take the same JPG image and open it with PSE 9 and PSE 10 (not at the same time of course). I then did a Save as without making any changes and with using the same defaults (slight name change).

The PSE 10 causes a delay and the PSE 9 doesn't.

I can understand that there may well be a problem with ZoomBrowser (as other browsers work OK) but why the change in format between PSE9 & PSE 10?

Brian

No idea, most the above is beyond my ken but thanks for that work around Bill

OK - so to work around this issue in Elements 10 I am not saving the thunbnail data via unchecking the box in preferences.
"Thumbnail Saves thumbnail data for the file. This option is available when the Ask When Saving option for Image Previews is set in the Preferences dialog box."
Does anyone know if this will cause me issues using the photo in the future?
Thanks,
Bill

Yes, the extra profile does violate the strict specification. But it doesn't break any correctly written parsers.

There was no "nesting" issue -- simply bugs in the code in QImage and Canon's zoombrowser where they failed to parse the JPEG stream correctly. The bugs existed in those products independent of Adobe's minor bug, and could have been exposed by files from other manufacturers. Given the nature of the bug in QImage (scanning for tags that look like a profile instead of parsing the file structure to find the profile for the image), it could easily have been triggered even by 100% spec. compliant files (and may have been without people noticing the pattern causing it).

And, again, any change Photoshop makes to files will end up breaking some poorly written code, somewhere. If applications are not parsing the file format correctly, then they will get tripped up even by completely valid changes to the files. And there are so many different file parsers out there, that a few are almost guaranteed to break with any given change.

I'll make this my last post since I really came here to find out when the problem in CS5 would be fixed and I guess you sorta answered that: "in the next major release"... whenever that will be.

I also realize that you will continue to claim that CS5 created JPEG files are "perfectly fine", so I'll just leave you with the actual specs. Not only are they not "perfectly fine" but they are in direct violation of the standards. I understand that Adobe likes to add their own "extensions" to a standard sometimes but this doesn't even fall into that category. Since the files are non-compliant, rather than "perfectly fine", we have to call them one of two things: (1) corrupted or (2) not a JPEG file (some other undefined format).

From the JPEG/JFIF specification, JFIF Extension: Thumbnail Coded Using JPEG, I quote: "no “JFIF” or “JFXX” marker segments shall be present".

From the EXIF specification, section 4.5.5 Basic Structure of Thumbnail Data, I quote: "No APPn marker, COM marker, nor restart marker is recorded in the JPEG stream."

So no matter which way you decide to embed your thumbnail(s) (JFIF or EXIF), embedding of an ICC profile in those thumbnail(s) is specifically forbidden. It's not that it's just an "extra" or not accounted for by the format: that would be fine if the file structure was adhered to. This is a case of clear violation of the standards as they (JFIF/EXIF) are both very specific that such markers "shall not" be present in the thumbnail JPEG stream. Such markers are to be tied only to the main JPEG stream to avoid "nesting" issues like the ones experienced by Canon's software and Qimage. Sure, they could handle the ERROR better. Qimage does (did 4 months ago), Canon says they will, but that does not change the fact that this is first and foremost an Adobe problem for creating non-compliant JPEG files. This problem would not exist if the Adobe software created JPEG files that comply with standards.

"poorly written" applies to code that claims to read JPEG but does not parse the JPEG structure correctly, or is thrown into bad states by perfectly valid JPEG files.
Again, there is no real problem in Photoshop - the files are still valid. The minor issue in Photoshop will be fixed, but it is so minor that it should not be included in a dot release.
And I work with the standards folks quite a bit - their judgement was "it's not optimal, but not a problem."