Photoshop: jpg exposes bugs in QImage and ZoomBrowser

  • 7
  • Problem
  • Updated 4 years ago
  • (Edited)
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.
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
  • frustrated

Posted 5 years ago

  • 7
Photo of Jeffrey Tranberry

Jeffrey Tranberry, Chief Customer Advocate

  • 11169 Posts
  • 890 Reply Likes
What OS are you on?
Photo of Brett N

Brett N, Official Rep

  • 2208 Posts
  • 98 Reply Likes
Providing the same files would be an enormous help!
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
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.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
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.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
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.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
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.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
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.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
You're contradicting yourself. The JPEG images parse correctly, and doesn't affect applications that read JPEG correctly. Only QImage has problems because it failed to parse JPEG images correctly.

Yes, we will work on the very minor Photoshop issue.
But the problem discussed here is a more major QImage issue of failing to read JPEG images correctly.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
I don't want to belabor this and I promise this will be my last post, but you really do need to get more familiar with the JPEG spec because the Qimage parsing issue is ancillary to the header corruption caused by the intermittent CS5 bug. The Qimage bug will never surface unless the file header is corrupted and this CS5 bug results in undeniable corruption of the header. A file corruption bug is worse than an "error handling" bug in my opinion.

And yes, those files *are* corrupted. You have a thumbnail embedded in the JPEG stream itself and as such, the spec calls for that embedded thumbnail to be free of JFIF segments. Simply put, embedding a profile in a thumbnail image IS NOT ALLOWED by the spec yet the CS5 bug is causing the APP2 JFIF segment to appear there: where it shouldn't. I suspect that might be why BreezeBrowser and other software are having issues with the files. Yes, with the right error handling, they can work around it, and maybe it can even be argued that they SHOULD work around it because embedded profiles in thumbnail images are not allowed. But they really shouldn't be there in the first place so I suspect it is possible that other software engineers have not accounted for that non-spec condition either.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
You are belaboring it, and continuing your attempt to shift blame onto Photoshop for the bugs in your software (or just your misunderstanding of file format standards and how to parse file formats correctly).
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
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.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
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.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
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).
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
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.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
OK. No response from my customer yet on getting permission for her photos (too late I guess) so I tried two of my own photos. They had the same problem: untouched raws from a Canon 5D. Doesn't look like it depends on the camera model so I just sent a ZIP file to you via yousendit. It contains all you should need (files and instructions) to recreate the problem where CS5 creates JPEG files with three embedded profiles on the conversion. Please let me know if I can be of further assistance.
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
Mike,
I agree it is very variable - some pictures are fine and some are not and I cannot see a pattern. But it does occur on my 7D and G11

If you have a "bad image" and are able to look at the hex you might want to try this:

open the file and then invert the image twice, I just use Ctrl I, so you get what looks like the same image back, then save it.

You will now find this is a "good image", this is what I've been using as a workaround. But if you can look at the hex you may be able to see what got fixed in the image.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Andrew, I think by doing that invert-invert, you are just forcing it to re-form the file header, overwriting the corrupted one. I think Chris will be able to reproduce/fix it now. Still looks to me like something getting cross-linked during the conversion: some "stale" piece of the header from a previously converted JPEG gets left over in the raw photo when that gets converted afterward.
Photo of Rebecca Hardgrave

Rebecca Hardgrave

  • 14 Posts
  • 0 Reply Likes
I would LOVE to send you files to look at. If you like, I can shoot some that never even go through my photoshop and let you convert them yourself. I can send you converted files, I can send you files that are right and files that are wrong. Just tell how many you want and where and how to send them.
I would also like to know if there is a way to check a log noting when the newest update occured, because I know the exact date the problem came into being in my workflow. I am not blindly pointing fingers or assuming any thing, just trying to get down to the problem, that obviously I am not the only one having.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
ccox at adobe dot com
Photo of Rebecca Hardgrave

Rebecca Hardgrave

  • 14 Posts
  • 0 Reply Likes
I tried to email the raw/nef files but they would not send because of their size. I did send you some jpgs to look at and put the others in my box.net account and sent you an invite.
Also sending with yousendit, so you might have to look in junkmail for it.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
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.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Already fixed and released. How are you doing on the CS5 bug?
Photo of G. McCurdy

G. McCurdy

  • 1 Post
  • 0 Reply Likes
I'm going to chime in with something I ran into with with 12.0.4 x64 yesterday.

I finished working on a re-sized JPEG saved in 'Adobe 1998' to send via my Excite.com account through AT&T/Yahoo! DSL and the server sent back an error message: "File is corrupt, or larger than 25MB limit. Try again?" That was new. I tried over and over and got the same message in about 10 seconds from their server. I've never seen a "Corrupt file" message from a server on a JPG before.

I redid the same JPG file and saved it with Paint Shop Pro X3 (same 'Adobe 1998' colorspace) and it went through without a glitch. File size report by Windows Explorer was 328 KB in CS5 and 325 KB in PSP X3.

From CS5 12.0.4 x64:
Format : JPEG
File size : 329 KiB
Image Format : JPEG
Width : 656 pixels
Height : 900 pixels
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy

From PSP X3:
Format : JPEG
File size : 324 KiB
Image Format : JPEG
Width : 656 pixels
Height : 900 pixels
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Photo of Rebecca Hardgrave

Rebecca Hardgrave

  • 14 Posts
  • 0 Reply Likes
I was wondering if anyone at Adobe Family has opened any of the files I sent? If not, please get with me so I can send you files and you can help determine the problem and solution.
Also, still wondering if there is a way to revert back to an update before 12.0.4 or to see when that update actually took affect?
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Based on a search, looks like 12.0.4 was released May 3, 2011. When you actually got it on your particular computer... that could be a different story.
Photo of Rebecca Hardgrave

Rebecca Hardgrave

  • 14 Posts
  • 0 Reply Likes
The first time the problem I had occurred was on July 15th, might help to pinpoint the problem if there was a way to see if it was as soon as 12.0.4 was installed. If it installed May 3, it might not even be the problem. I have my PS set to auto update, and I cannot remember if it asked to update or anything specifically on that day. I did not notice the problem till a few weeks aftewards, when orders from that session and the following sessions started getting printed.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
It'd probably be difficult to prove anything. You'd have to know when the update was pushed to your computer, how long after that it was until you used the image processor on raw files, AND the problem is not consistent: doesn't always happen unless the conditions are right. I think Adobe has enough info now to find/solve it. Let's give them time to respond. Only thing I can say for certain is that 12.0 did not have the problem and 12.0.4 does. I have no idea which version in between actually caused it but I suspect it is the latest (12.0.4) just because of the increase in reports of this problem from my customers in recent weeks. Nothing before May.
Photo of Jerry Van

Jerry Van

  • 3 Posts
  • 0 Reply Likes
I have 12.0.4 and am having a similar problem that is costing me alot of time and frustration. I am opening files in ACR and then working the files and saving them as jpegs in RGB space. When I open them to print in Q-image some of them are in sRGB on no profile at all! This is not user error, I have not changed my system here for a long time. Please help us out.
Photo of SG...

SG..., Employee

  • 119 Posts
  • 21 Reply Likes
Hi,

For those having problems, can you reply back with the version of the Camera Raw plug-in you have installed and the workflow settings? Also what OS are you using?

You can quickly find the CR version this way using Photoshop menus:
Win: Help> About Plug–In> Camera Raw...
Mac: Photoshop>About Plug–In> Camera Raw...

regards,
steve
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
6.4.1.145 here
Photo of Rebecca Hardgrave

Rebecca Hardgrave

  • 14 Posts
  • 0 Reply Likes
6.4.1.145
Windows 7
Photo of Jerry Van

Jerry Van

  • 3 Posts
  • 0 Reply Likes
6.4.1.145
Windows 7
From camera raw I open as Abobe RGB(1998)
After I finish working on the files I save them as jpeg's Quality 10 Baseline Standard
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
6.4.1.145
Windows XP Home Edition with SP3
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
I have been having a great deal of trouble with colour instability since recent updates to CS5 also. Am running XP64, CS5 12.0.4, Camera Raw 6.4.1. I run Adobe RGB 1998 workflow from camera to printer.
Seems to be totally random result of some files returning an sRGB colour space and some returning AdobeRGB 1998 when converted to jpegs for printing. Same result for scanned images too, so it is not the camera. The 32bit version appears to be worse, but the 64 bit version does it too.
EXIF details in Bridge show Adobe rgb but this is not the case when viewed with a hex editor. I processed the same two files (one a psd & the other a tiff) no less than seven times with totally random results. I could not return a pattern. Sometimes sRGB & sometimes Adobe!

The only way I can get around it is to include a new line in the action that sends the files to the print output folder which is: Edit/Convert to profile/AdobeRGB 1998.
This seems to ensure me the result I need to print accurately.

Note to ADOBE - NOT HAPPY!!
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
I have applied my modified action as mentioned above, but it still does not provide a sure thing cure to the problem. I have found that if I reload the offending file into CS5 and Convert to profile/Adobe RGB and then Save As over the original Tiff or PSD manually, it seems to save the following jpg file as Adobe RGB okay.

BTW, how do I get the addition of the Convert to profile in the action to apply it without stopping to ask me to press Enter. Have I missed/forgotten something?
Col
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
Hi Chris
As I mentioned in my post 3 days ago above "I run Adobe RGB 1998 workflow from camera to printer. " I also get the problem from files that have been sent to me via email and also scanned images which rules out the initial recording method. Many of these files are years old too. Some are quite new. I do this for a living and am quite comfortable with the operation of CS5 and printing on a large scale. This has only happened since the update. I was complaining to Mike Chaney (see above) as were other folk (see http://ddisoftware.com/tech/qimage/of... ) and he could not duplicate the problem until he updated his copy of CS5 v.12 to 12.0.4 then he too had the problem.
I am not alone here Chris. It is recorded that as many as four profiles are embedded in some files.

I can run the action to save the file as a jpg and it embeds an sRGB profile. I can do the same manually (without the action) and get the same result. If I manually Convert to profile/AdobeRGB, then SAVE AS over the original TIFF or PSD it will then save a jpg with AdobeRGB profile! I can get a clean print run, but where it used to be a quick and clean process, I now have to check each file and re-save it as mentioned above. Queer for sure, but V.12 appears to be clear of this problem.
Can I roll back to V12 pre-update? Serious!
Thanks
Col
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
And yet the sample files we have been provided have exactly one profile in them (again, it would be near impossible for the file to have multiple profiles, and then the chance would be due to disk errors). We have not reproduced the problem, nor have we seen evidence of the problem, just anecdotes with confused descriptions. Steve and I have both tried to reproduce this on Windows 7 with zero success.

It sounds like your document has an sRGB profile, and saves correctly. Then when you convert to AdobeRGB, it saves correctly. That really sounds more like user error than a bug.

So you're gonna have to give us more to go on.
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
Bridge shows the file as having AdobeRGB space every time even after saving with the "troublesome" format, yet they appear to the eye as wrong colour and (in my case) the printing software I use, Qimage, shows it as sRGB and it prints as sRGB with bad colour. When I "force" it to save as AdobeRGB Qimage reads it correctly, it looks and prints good.

If you read the thread carefully you may glean a hint of what to look for? As I mentioned above I have opened and processed two files seven times with varying results. They started with AdobeRGB and sometimes they were but when Qimage said they were sRGB they WERE the wrong visible colour on screen. I can appreciate your doubt as I have just now once again ran the action that saved the files to the printing folder as follows:
Selected six of them in Bridge, check that ALL are AdobeRGB in metadata
Load them into CS5 and run the action through File/Automate and all but one in the output folder has AdobeRGB. One has sRGB. This file was a scan, saved originally as AdobeRGB and to make it more interesting, one of the AdobeRGB files in here is a smaller resize & SAVE AS from the file that returned sRGB yet the two are different colour spaces with different visible colour!
NOW! The frustrating part. 30 seconds later, I load the same selected files from Bridge, run the same action and look in the output folder and ALL of them are AdobeRGB & the colour look right throughout!
2nd test:
Loaded six more files at random including two that did not contain correct colour profiles.
Ran the action and in the output folder one had sRGB (not one that had to convert upon loading into CS5) The two that converted to Working profile upon loading showed AdobeRGB.
Ran the same sequence again immediately and TWO of them showed sRGB this time!

I could do this all day, it would seem, with varied result.
Do you see why we hate computers so much?

I cannot speak for others, but I am using XP64 would there be a glitch there? Try it on an XP system if you can.

Can you ask around & see if anyone has a clue as this is real and affecting more than one or two, but as yet, we have have not pinned a pattern to it.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
I have read carefully. Much of what has been claimed is near impossible, so I have to guess that the descriptions are most likely inaccurate. And it really sounds some files might contain the wrong profile, or QImage has problems reading the profiles.

Throwing QImage into the description of the problem is just confusing the issue (or maybe is the issue?).

Yes, XP64 could be part of the problem - it is not a supported OS version for many, many reasons (bugs never fixed in the OS, drivers never updated, etc.)
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 685 Reply Likes
Turns out QImage was the problem -- bugs in the QImage JPEG parsing caused it to read the wrong color profile.