P: Jpg exposes bugs in QImage and ZoomBrowser

Report · Jun 22, 2011

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.

Report · Jan 05, 2012

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

Report · Jan 05, 2012

Please see the previous discussions.

Report · Jan 06, 2012

email back from Canon, they are at least aware of it...

"Thank you for your e-mail and for contacting Canon. Apologies for the delay in our response over the festive period.

I have been reading the description of your problem, and also the link to the forum that you have provided a link to. I was previously aware of this discussion with the CS5 issues that my colleague was dealing with. I have spoken with him to see what his latest knowledge of the situation is, who has referred me to the relevant person at Canon Europe. I will contact him and hope to hear back from him very soon. I am glad to see that you have been provided with a workaround by another user for the meantime."

Report · Jan 10, 2012

Update from Canon again. Sit and wait I suppose...

"I have received a reply from the European Technical Coordinator who advises that he is not able to give a timescale, but Canon Inc are aware of the issue and will be releasing updates for ZoomBrowser EX and Digital Photo Professional as a result.

My apologies that I am unable to provide you with any more specific information. Apologies for any inconvenience caused in the meantime."

Report · Jan 13, 2012

i have exactly the same issue, pls also let me know when this problem gets addressed. thanks!

Report · Jan 23, 2012

And I have the same issue, too! Only after upgrading/installing PS CS5 (from CS3) - and using Zoombrowser with a Canon 60D - the load time of a jpeg is unbelievably and incredibly slow. Also crashes Zoombrowser at times. I never had this problem when using CS3 + Canon 60D + ZB.

Report · Feb 04, 2012

I have the same issue also.

I look forward to the fix in zoombrowser. Until then the work around (described above) of not saving the thumbnail seems to work.

Report · Mar 24, 2012

I've just tried the update to 6.9.0.1 available from

http://www.usa.canon.com/cusa/support...

and it works!

Whether it was or wasn't Canon's fault after Adobe made the change In May it's still very disappointing it took Canon so long - almost 11 months and Adobe still haven't produced an update to CS5. But better late than never!

Report · Mar 25, 2012

Thanks for the update - I have passed on the good news to Photoshop Elements users who also suffered from the problem.

I do wish the Canon sites would make it a bit easier to get the software fixes - they seem to want to stop you or is that just me?

Thanks

Brian

Report · Mar 25, 2012

I have this same issue, too. Not until I upgraded to CS5 did I have the same disappointment. It takes forever to view an image in ZB, once it has been processed in CS5. Without processing in CS5 there is no issue. Canon does not take responsibility, nor does Adobe. So I sit around unhappy with both...not knowing which direction to turn, except to uninstall ZB...which is unfortunate, because I like the product. Been a Canon user since 1969, and a user of ZB since it first released.
Would enjoy finding the solution.
Thanks,
Ed

Report · Mar 25, 2012

Read the previous comments -- it was a bug in ZB, which Canon has fixed.

Report · Mar 26, 2012

Chris from your earlier message "Yes, the extra profile does violate the strict specification"

Does this mean that Adobe are deciding to do their own thing now?

Brian

[edited to correct spelling]

Report · Mar 26, 2012

No, as already stated: it was a very minor bug in Photoshop. But while it violates the strict specification, it is not a problem for any correctly written parser.

Report · Mar 26, 2012

Thanks for that.

I am assuming that the "minor bug" will be fixed in some future version. The problem I have is confidence in your program. If I send pictures to people I had been hoping that the defined "jpg" standard was old enough for most applications to be able to read. If the peolpe that I send to can no longer read them, it doesn't seem good to have to say to them that they will have to check for updates.

Report · Mar 26, 2012

My thanks to Andrew Carter - his info on the update from Canon worked for me too! Finally I can use the two programs I always enjoyed - together.
Cheers,
Bill

Report · Mar 26, 2012

Whenever an application changes anything in files, some file parser somewhere is going to break - even if the change is 100% to spec.

In this case there were bugs in ZoomBrowswer and QImage that made them break while reading valid JPEG files (again, the file is fine, even if it violates the strict specification for EXIF).

There are a large number of file parsers out there, and some are more robust than others. And some fix their bugs faster than others.

We've even had releases where we changed nothing in the files except the string identifying the version of Photoshop, and some third party parser breaks (because they had bad assumptions and bad code).

So, no matter how little changes in Photoshop - there is always a chance that a third party file parser is going to fail due to bugs in that parser.

We work hard to keep our files clean and compatible, but we cannot control everyone else's code.

Report · Jun 28, 2012

Not sure if I am off topic but I have been having issues with jpeg saving sinse i upgraded to cs5 over a year ago. Working pro 25 years, Digital Fully profiled system since 1999 - adobe rgb from camera (D3 Nikon Raw) to Lightroom to QImage for print. Win 7 Cs5 64x latest upgrade, I flagged this on the forum over a year ago but was getting suggestions of monitor issues so I gave up and never sorted it. Basically if i take a batch of jpeg files processed in lightroom (although i have tried nikon browser, and canon also) in adobe rgb space and open in cs5, work on them and then resave, approx 5% will randomly change to srgb. I have confirmed they are srgb, they look "flat" (no matter what software I view them in) and the print flat (Matching the screen as they should) in Qimage. Also qimage picks them as srgb when I place the mouse and the previews are flat too. I have printed from cs directly (Hate the interface!) and the same issue arises so it is NOT Qimage on my system.
My workaround is to reopen in cs (which is set to "warn when profile mismatch" which it doesnt!) make any change, ctrl z and SAVE AS. This gives the adobe tag. If I SAVE it saves again as srgb. As soon as I do this the preview changes in QImage (and no matter what software I view it with) and we are good to go. I now have an action to "change curves/ undo and save as" set up as a workaround.
I have tried it every way and in my ho it is definitely a cs5 issue as I have tried to rule out all others. It is completely random (yesterday it happened on 4 files from a batch of 80 wedding images) I see it immediately, win photo viewer sees it, lightroom and qimage see it and it is not my imagination.
Anyway, sorry for you guys but I feel better that I am not the only one! Maybe next cs will fix!

Report · Jun 28, 2012

Sorry one more thing - It only happens with jpegs - If I save as tiff or psd all is good!!

Report · Jun 28, 2012

There is no such problem known in Photoshop - so nothing to fix.
But what you're describing does sound a bit like the bug which QImage fixed in their code.

Report · Jun 28, 2012

Oh dear Chris....Im now sorry I even brought it up again! Rereading the entire thread it seems to me a waste of my energy typing. I wasted 3 weeks testing every combination last year and just ended up giving up. I know very little about exif headers and app2 tags etc. All I know is that on my system cs5 is randomly creating srgb space images on batch conversions - cs4 did not and does not (again on my system). These random srgb images DO EXIST - Even my old version of cs3 bridge recognises them as such, and canon browser, nikon browser, and windows own viewers (before you say it I know they are not colour compliant!) all see the difference. Unfortunately it is completely random and what I cant do is reproduce the error to order. (as I said today I had 4 files). Process the batch again and you might have 4 different files and you might have none! The only thing that I am certain of is that I did not have the problem in any other versions of photoshop.Notice I didnt put Qimage in the list as I get the impression you guys are not talking! (Pity as a large number of pro photographers use this combination - you have two of the best softwares going.)
What is very strange is that the problem never happens (on my system!) with lightroom - all jpeg conversions are fine. (and all the softwares above sees them as it should and the adobe rgb space is read by all (even qImage with its buggy code reader!!) It only happens when I open a jpeg in cs5 and click "save" . If I click "save as" i generally dont have the issue. Sorry but (on my system!) there IS an Issue. I presume lightroom and cs5 would be producing the same "type " of jpegs. But sometimes cs5 doesnt. So....I realise that this wont get fixed as "There is no such problem known in Photoshop - so nothing to fix." so Ill have to live with my workaround of avoiding jpeg conversions from cs when Im in a hurry. Just convert to tiff/psd or running my action to reconvert the oddballs.
Im going to park this now as I got the feeling I was wasting my time a year ago and Im not going to waste any more on this. I recon the problem that doesnt exist will be fixed in the next version of cs! Hoping anyway!
Thanks for reading, N

Report · Jun 28, 2012

You're talking about the thumbnail images, which do exist. But they were only exposed because of a bug in QImage that was incorrectly reading the JPEG file. In a correctly working JPEG parser, they are not an issue.

Bridge and other applications will ignore the profile in the thumbnail, and deal only with the profile in the actual image.

If you downloaded the patched version of QImage that fixed the bug (and Canon Zoombrowser that fixed a similar bug) - then you should have no problem with the files from Photoshop.

Other than the known bugs in QImage and Zoombrowser, we have not seen any other issues.

Report · Jun 28, 2012

ok to expend a little more midnight oil .. Im viewing the thumbnails ok. So when i see a difference in the displayed thumbnail when viewed in cs3 bridge too..? also seeing it in prints from the dreaded qimage and when printed directly through cs3! No (on my system) we are not just talking about thumbs. the image either is tagged srgb or is being read as srgb and prints as srgb. Also what is the difference between a jpeg created in cs3, cs5 and lightroom 2 and 3? Ive tried them all and only cs5 gives me this random behaviour. Also if I print one of these random srgb images with windows print ( which is not colour managed I know) it prints better than the similar "saved as" adobe rgb file. I presume this is because win print defaults work best with srgb. ( I didnt say well - only better!). My question is:
If I open a jpeg #1234 adobe rgb file, work on it and save as #1234 tif,
#1234 psd and "save as" (note "save as") #1234 the files are identical colourwise.
( all thumbs are the same, and print the same no matter what program i use)
However if i click "save" on the file I (randomly) get a srgb image - maybe it is a thumbnail but it affects the print (again no matter what software i use to print.) To me there is a difference in (some) jpegs created by the "save" command. My point is that they should always be the SAME and they are not. (looks like a duck, quacks like a duck - its probably a duck!) I just cannot see how qimage could be at fault as surely it would read all the jpegs the same? Again my problem seems to be the "save" command in cs - if I "save as" no problem. Of course this causes a problem with actions which use save.....and i randomly get this issue as described. If i open the file again, tinker, hit ctrl z and "save" I sometimes get a srgb file (or perhaps thumbnail) but if I hit "save as" i get different. What has that to do with qimage, zoombrowser etc? Again (looks like a duck, quacks like a duck - its probably a duck!)
I am convinced that there is a bug is cs5 (on my system- maybe regristry or something) but I had the same issue on a xp machine (It was the reason I changed to win 7). It makes no sense to me that it is anything other than a cs5 bug - minor but very annoying when you are working and batch printing. Anyway hopefully it will "go away" when cs6 or 7 comes out. Again hopefully! n

Report · Jun 28, 2012

Sorry just to be clear: # 1234 jpeg and "save" gives a different profile (sometimes!) to #1234 and "save as" to give #1234 jpeg.

Report · Jun 29, 2012

Let's be honest as this is very simple. BOTH programs (Qimage and CS5) exposed bugs in the other! The bug in CS5 is that it produces JPEGs that violate the EXIF specification. The problem with Qimage was a bug in the parser that read the wrong profile *when the spec was violated*. I fixed the bug in the production Qimage (Qimage Ultimate) 10 months ago. If Adobe chooses not to fix the bug in CS5, that's up to them. But again, let's be honest; it is a bug when you violate a spec. Reference this post from 6 months ago where Chris said, "Yes, the extra profile does violate the strict specification." You need read no further than that to know it's a bug: http://feedback.photoshop.com/photosh...

This spec violation is also what caused BreezeBrowser, mail readers, and other programs to fail when reading the files: their parsers were coded to read properly formed JPEG headers and had a problem when the spec was not followed. I don't plan to come back since I've fixed my part. This thread lights up every so often because Adobe hasn't fixed the spec violation bug and people are using old Qimage software. Then Chris claims that violating a spec is not a bug. Then I dig up the specs showing that insertion of a profile into a thumbnail in a JPEG header violates the spec. Then we're back to square one. No point in repeating it. My only useful advice would be: if Adobe doesn't intend to fix the bug in CS5, your only option is to save in something other than JPEG format or upgrade to the production version of Qimage Ultimate.

Mike

Report · Jun 29, 2012

Only QImage seems to have failed to read profiles correct from JPEG (and would have failed on other files by other applications as well).
ZoomBrowser seems to have failed on something else (but the email we got from Canon just said it was an old bug in their code).
The only other reports we have of applications failing with Photoshop JPEG files are for older JPEG parsers that read only JFIF and cannot read EXIF (and those mostly just lose resolution information).

Please, don't exaggerate the scope of the problem.

QImage had a bug, and that bug has been fixed by the author of QImage.
Done.