Participating Frequently

P: Jpg exposes bugs in QImage and ZoomBrowser

Forum|Forum|14 years ago
June 22, 2011
141 replies
1146 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.

Show previous replies

F

FeedbackCommunityMember

Inspiring

There aren't any assumptions being made. Only observations. When I send you the three files, you'll be able to reproduce the problem. Put the two NEF's in a folder and run the image processor to convert to quality 12 JPEG's and the two converted JPEG's are fine. Put one sRGB JPEG into the folder with the two NEF's and now the NEF that is converted after the JPEG goes sour: two sRGB profiles embedded plus one Adobe RGB. That's the same NEF having a completely different result from the image processor: correctly when the JPEG isn't present in the same folder and incorrectly when the JPEG is present. Only way I can fathom that happening is a bug in CS5. Don't see how user error could cause the same NEF to convert two different ways with the exact same conversion setting, only depending on whether or not there is a JPEG converted before it or not.

F

FeedbackCommunityMember

Inspiring

The person with the XVI32 dump just showed different images with different profiles - almost certainly user error.

If one file has multiple profiles in it, then I need to get the files to examine.

You're making a lot of bad assumptions about what is going on (and what's even possible to occur).

F

FeedbackCommunityMember

Inspiring

I'm going to prepare a ZIP for you and send it to you. I'm waiting for permission to send you the photos since they are not mine. Here's what I found. If I put two NEF's in a folder and use image processor, it works fine. If there is an sRGB JPEG in between such that image processor processes one NEF, then the sRGB JPEG, then the next NEF, the last NEF is corrupted with the three embedded profiles. That's why I say I believe it's a variable initialization issue since it looks like the sRGB is being carried over from the JPEG being processed between the two NEF's. If you image process 1775.NEF, 1960.NEF, and then 1999.JPG (the sRGB JPEG), all is fine because the sRGB JPEG is last. As soon as you rename the JPEG to 1780.JPG so that the image processor processes the JPEG as the second image in the batch, the last NEF (1960) gets corrupted. Anyway, I'll send you the ZIP tomorrow. That should be all you need to replicate the problem because it happens every time.

F

FeedbackCommunityMember

Inspiring

Impossible, yet there it is. On multiple installations, different machines. This is actually one of my customers/users. I wasn't able to replicate her problem at first but I discovered it was because I was running an old 12.0 x64 CS5. As soon as I upgraded to 12.0.4 x64, the problem appeared exactly as she was getting it. She says she's contacted you (before I did here) and she's also sent you an XVI32 dump that proves the problem, so since the images are not mine, I'd prefer that she send them to you. I'll let her know and will ask her to contact you. I was able to replicate the problem easily once she sent me a couple NEF's and gave me her settings in image processor. Thanks for the help.

F

FeedbackCommunityMember

Inspiring

Unless you have a bad disk or a problem with the OS - that's pretty much impossible. And, again, the JPEG code didn't change in the dot releases. If you can send me some files (ccox at adobe dot com), I'll take a look and see if there's any pattern.

F

FeedbackCommunityMember

Inspiring

Because I can open the file in a hex editor and see all three. Three ICC_PROFILE tags and three different locations in the same file. Problem did not occur in 12.0 x64. Only 12.0.4 x64. It doesn't seem to be consistent either. Some files have the problem and some don't. It's almost like some variable/block isn't getting reset and it's retaining tags from previous files it may have processed. But that's just a guess. NEF's I was trying were from a Nikon D700 and there were a couple "stray" non-raw (jpg) images in the same folder when I turned image processor loose on the folder.

F

FeedbackCommunityMember

Inspiring

Why do you believe that there are 3 ICC profiles in the JPEG file?

F

FeedbackCommunityMember

Inspiring

There are definitely issues with file saving in 12.0.4. If you use the image processor to process raw photos into JPEG's, many times the saved JPEG's contain three embedded ICC profiles: sRGB is embedded twice and Adobe RGB is embedded once. Definitely needs to be fixed.

F

FeedbackCommunityMember

Inspiring

No changes, the JPEG and thumbnail code hasn't changed in the dot releases.

If Canon has specific issues, they need to contact us directly with details.