Skip to main content
andrewc94999058
Participating Frequently
June 22, 2011

P: Jpg exposes bugs in QImage and ZoomBrowser

  • June 22, 2011
  • 141 replies
  • 1145 views

Since a recent upgrade to CS5 (I guess 12.0.4 and certainly the current version) JPG files I've saved take about 1000x times longer to open in Canon ZoomBrowser 6.7.2.33 (the latest version). When I say 1000x I mean 1000x. Recent jpg are taking over 30s to open a single image! I raised this with Canon sending then old and new jpg (created using an older version of CS5 and the latest) from the same CR2 file. They said:

Extracting the EXIF data from both the good and bad images we found that the JPEGInterchangeFormatLength (JpegIFByteCount) value is bigger in the bad files.
JPEGInterchangeFormatLength shows the number of bytes of JPEG compressed thumbnail data.

We believe that this higher number is causing the problem as the ZoomBrowser EX application is trying to use the EXIF data to generate the thumbnail images, and to display the files. We were able to reproduce the issue in our test environment.

We would recommend you to contact the Adobe support in order to find out if there were any related updates released in the last few weeks that possibly was installed on your computer manually or automatically.

Please can you investigate what changed recently in CS5. And how I rescue my recent jpg images that I've needed to create for my clients. If you need the images that I sent Canon for your investigation then please let me know.

141 replies

Inspiring
September 13, 2011
FYI - we got sample files, there was nothing wrong with them. This appears to be a bug in Canon's ZoomBrowser code, but we haven't been able to talk to Canon's developers to narrow it down.
Inspiring
September 13, 2011
OK, I did get the files from Brett back in June and just forgot about them.

Yeah, what you're looking at is definitely a bug in ZoomBrowser's code.
We've tried to talk to Canon independently, and haven't gotten anywhere.
So it's in Canon's court - if they want help identifying the bug in ZoomBrowser, they need to contact Adobe. We've done all we can.
Inspiring
September 13, 2011
See Mike's comments below. I think we've found the root cause: bugs in the way QImage parses JPEG files.
Inspiring
September 13, 2011
What Canon told you translates to: the files have a different size. That's all it means. It doesn't tell us anything about why they take so long to read the files.
And it really sounds like that came from someone, um, not technically savvy. The issue really needs to go to Canon's developers so they can debug their code and find out why one file takes longer.

I'll check with Brett (and check the SPAM trap to see if I missed his email).
Participating Frequently
September 13, 2011
So please ask me the questions you need the answers to. Do you need a detailed procedure with settings on my workflow? I am willing to tell you every step I do, I just need to know what you need know. As far as unproven, what do you need us to send you to show you the results we are getting? I can send you prints, files, screen shots, just let us know what you want to see and where to send it.
And, lastly, can you please tell me if there is anyway to "un update" and let us see if we get any better results. It may be coincidence, if that would make my workflow go smoothly again, I can live with that and turn off Adobe updates.
andrewc94999058
Participating Frequently
September 13, 2011
Brett told me on 29-Jun that he'd passed the files over to the engineering team.

OK let's start again. here's what Canon told me:
Extracting the EXIF data from both the good and bad images we found that the JPEGInterchangeFormatLength (JpegIFByteCount) value is bigger in the bad files.
JPEGInterchangeFormatLength shows the number of bytes of JPEG compressed thumbnail data.

We believe that this higher number is causing the problem as the ZoomBrowser EX application is trying to use the EXIF data to generate the thumbnail images, and to display the files. We were able to reproduce the issue in our test environment.
Inspiring
September 13, 2011
The profiles are not leftovers, and are correct for the thumbnails (which according to EXIF standard, are converted to sRGB). There is no garbage, and no corruption -- just the inclusion of the profiles. Parsing the JPEG tag tree does avoid the thumbnails, unless you're extracting only the thumbnails. Those are correctly embedded profiles in the thumbnails, completely parsable within the thumbnails. Um, no, embedded JPEG thumbnails are valid JPEG streams within the main JPEG file. That's how the EXIF standard works, plus another thumbnail/preview is embedded in a private tag for Adobe data. Again, there is no garbage, and no need to "skip around". The file parses just fine.

I hope you are mistaken about the way QImage reads JPEG tags - professional software should never be that sloppy, and should be parsing the file structure correctly. That sort of bug could lead to lots of mistakes in file parsing, especially when working with EXIF standard JPEG and TIFF images.

So, the bottom line appears to be that Photoshop has a minor bug that sometimes includes profiles in thumbnails. And QImage has some major bugs in the way it attempts to read JPEG images and picks up the thumbnail profiles by mistake.
Inspiring
September 13, 2011
The original issue was about Canon's ZoomBrowser software being slow to read files. Brett requested samples, which I don't recall ever seeing (but maybe he forwarded them to Canon without sending them to me).

Also, that still sounds like a bug in Canon's software which Canon would need to debug. I can't do much for Canon's software because I don't have the source code for their software. Even a minor change in metadata (ie: changing the date) could cause a problem if they have a bug in their code (and yes, dates have caused crashes in other software before).
Inspiring
September 13, 2011
Where is "the color wrong every time"? Is it QImage that displays the files incorrectly? Photoshop appears to read the "bad" file and displays it correctly with the AdobeRGB profile in the file (ignoring the extras in the thumbnails like it should). Photoshop prints the good and "bad" files identically. (yes, I just did that)

Shouting won't help the fact that you are leaving out important details and ignoring the findings from the evidence provided.

Yes, you have problems. But that does not mean that you understand the problems, or are assigning the blame correctly. Again, there is apparently a minor bug in Photoshop that causes profiles to be included with the thumbnails sometimes (possibly randomly). Again, that should be completely harmless because the profiles in the thumbnails have no relation to the full resolution document.

Yes, insulting the senior developer who is taking his own time to investigate the problem and help you is really going to help your case. Oh, and I am the developer most knowledgable about file formats, standards, parsing, profiles, and all the related bits.

So far, we can't reproduce your results. Maybe there is a random bug, but we haven't found the triggering factor yet. Now that we know that something is writing profiles in the thumbnails, we'll investigate that code more closely.

But the claims of corrupted files, wrong color, and incorrect printing are still completely unproven. And it still sounds like you are leaving out important details.

You aren't getting any condescension -- but I'm having a hard time determining the facts of the case because you're making a variety of wild claims but providing scant evidence to back up those claims.
Participating Frequently
September 13, 2011
Chris, I would LOVE to have the answers to the above three questions. Ask another aunt or uncle in the "Photoshop Family". Not trying to return the condesending attitude, but could your method of trying to discover the problem be erred? Can you give us a detailed procedure we should try to see if we can get the same results you are getting? What is your definition of a bug in the program?