Photoshop: jpg exposes bugs in QImage and ZoomBrowser

  • 7
  • Problem
  • Updated 7 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 8 years ago

  • 7
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Chris,

Not sure why only Adobe is unable to reproduce the problem yet everyone else is. I just sent you another file with two JPEG's showing the output that I get using the instructions (and files) I provided to you earlier. CS5 produces two different output results (one being 3K larger with 3 profiles embedded) for the same raw file depending on whether or not an sRGB JPEG is present in the same folder. That should not happen. So because, as I indicated earlier, I believe it is a memory use/initialization problem, we need to determine if: (a) the problem doesn't occur under all OS/machine configurations and that's why you are not seeing it or (b) it really IS happening but you aren't using the right tools to find the extraneous profiles in the resulting files. I don't know what you've done: did you use my detailed instructions both ways and compare output (JPEG) file sizes for that 1900.CR2 file? We should be able to at least agree that the output I sent you shows one "good" file and one "bad". Let's go from there.

Mike
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
>> everyone else is.

3 people != everyone.

a) possible
b) I'm parsing the file. There can't be more than one profile and still have a readable file.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Colin,

Your description above is what is happening to the several people I've talked to including myself. You can do the exact same conversion twice and get two completely different results on one or more files. The files are different sizes, so it doesn't even matter what program you use to "detect" that fact: the files are different. That's obviously a PhotoShop bug because a program should give consistent results with the exact same settings. I've tracked it down as far as being able to "force" the problem to happen. At least on my machine, the file I sent to Chris over a week ago reproduces the problem 100% of the time on my Win7 x64 machine with the x64 version of CS5. To force the problem, if an sRGB file is converted in a folder with other (raw) files, the following raw photo that gets converted immediately afterward creates a corrupted output JPEG. As I said, this smells of "leftover" memory or something not being initialized.

It might be possible that it is still machine/config dependent since memory initialization bugs can be that way. To that end, anyone with Win7 x64 and CS5 x64 who wants to try my test (the one I sent to Chris), just download http://www.ddisoftware.com/testpics/c... and see. Since Chris says all he's gotten are "anecdotes and confused descriptions", I'm letting people see the file I gave to Chris since there's really no reason not to share and it may lead to more info (some machines having the problem, some not). See if anyone else can reproduce it given the instructions in the above file. If not, then color me anecdotal and confused. If others can readily reproduce it, maybe I'm not the one who is confused!

Mike
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
3 people = everyone I've talked to who has tried the exercise so far except you (Adobe), which is what I said. So let's get to the bottom line. I sent you two files in a ZIP this morning: output from running the CS5 image processor with identical settings two times. Both were labeled: "bad" and "good". Are you denying that the one labeled "bad" has sRGB in it twice and Adobe RGB once and is 3K bigger than the one labeled "good"? Are you not seeing the three embedded profiles in the bad file? If not, I can give you the file offsets where all three occur. File offset 856: "icc_profile" tag with an sRGB profile. File offset 11769: "icc_profile" tag with sRGB again. File offset 27912: "icc_profile" tag with Adobe RGB. All offsets in decimal. You mention "parsing" so you should probably try looking at the actual file rather than parsing it using the same program that created the problem to begin with (if that's what you are doing). Sounds like the problem might be happening for you too and you're just not thoroughly examining the file contents.

Next, what does metadata have to do with processing the exact same file(s) twice and getting a different result both times? Metadata cannot be the excuse for a program producing inconsistent results with the exact same workflow performed back to back. The file has not been changed between the two runs so it has the same metadata both times. Only way it can have different metadata on the two conversions is if a bug is causing carryover of metadata from another file. Do a file compare of the two JPEG's I sent you this morning and you'll see the inconsistency.

And lastly, that "bad" JPEG contains an "icc_profile" tag in it three times: sRGB twice and Adobe RGB once, yet it loads in CS5 which blows your theory that if a file has three profiles, it won't load. Have you even performed the test outlined in my original ZIP file's readme? Have you run that test both ways (with and without the "stray" JPEG in the folder when you convert), comparing file sizes of the 1900.jpg output files both ways? You'll see they don't match and that is proof positive of a bug. No way should the exact same conversion produce two different 1900.jpg output files depending on whether a separate JPEG is in the folder or not and got converted *before* the 1900.CR2 file. Forget about the fact that your own (Adobe) software ignores the two sRGB profiles. They are there. And the fact that you can make them appear/disappear by just putting other non-related images in the same folder means it's an Adobe bug.

Mike
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
The document you sent me contains only 1 ICC profile, the sRGB profile. I can't find any Adobe RGB data in it.

I've tried every JPEG parser I have available. None of them complain, none of them see any phantom profiles or mangled data in the file.
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
The file that I sent today is this one: http://www.ddisoftware.com/testpics/c...

There are two JPEG images in that ZIP. The 1900-bad.jpg file has three profiles in the file at the file offsets I posted above. The 1900-good.jpg file, converted exactly the same way, only has one profile and is ~3K smaller. To see the problem, you may need to stop using JPEG parsers and actually look at the file contents.

Mike
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Check your link, that's not the same archive you sent earlier.
csproblem.zip vs. csproblem2.zip
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
You might want to use exiftool to compare the 2 images and look at where the profiles are located (where the files differ by 3162 bytes in each thumbnail).

Yes, the files differ. But I doubt that the presence or absence of profiles in the thumbnails is going to hurt anything other than adding 6324 bytes to the total image size of 6.8 Meg.
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
Chris, I realise it is hard for you to help when you say that you cannot reproduce the problem, but please bear in mind that you are dealing with VERY experienced people here and we are not fools. Your comments are sometimes appearing to be tad glib. e.g. "Much of what has been claimed is near impossible, so I have to guess that the descriptions are most likely inaccurate." - Not so my friend. We have many years of "near impossible" experiences with computers. 40 of them in my case! Our descriptions are quite careful & detailed. If you want us to try something, tell us & we will do whatever you say if you think it will help.

"Throwing QImage into the description of the problem is just confusing the issue (or maybe is the issue?). " - That was merely an example of a program that DOES show the errant profile easily and NO it is NOT the problem as all I am doing in Qimage is viewing the file as a thumbnail. A simple mouse over shows the sRGB and don't forget that the colour change is VISIBLE onscreen!

"XP64 could be part of the problem" - I doubt it as the problem is appearing on various OS.

User error is ruled out when I can load the same files with one keystroke from Bridge (all with metadata showing AdobeRGB), run one action (File/Automate/Batch) that saves those files as jpgs and closes them. Virtually untouched by human hand so to speak. I can do multiple times with the self-same files and the result is different each time. Sometimes all correct and sometimes one is wrong and the next time two different ones are wrong.

User error is ruled out as soon as more than one person gets the same result.

We are the first to acknowledge that it is weird and so far lacking in a pattern which would aid in the search for an answer. Can you ask around other folk in the company (India maybe, they seem to be pretty switched on!).

We await hopefully.
Thanks
Col
Photo of Colin Sheehan

Colin Sheehan

  • 7 Posts
  • 0 Reply Likes
You are not allowing for one thing in your replies that state that we are mistaken or that it is a "minor problem that should not affect anything other than a few K of file size.". THE COLOUR IS WRONG EVERY TIME! That is what started the whole thing in the first place. It is NOT about a few k of file size at all. That is simply an added effect.

Multiple users are experiencing bad colour. It is that simple. It appears that it only started after the 12.0.4 update.

You say "If QImage is seeing a different profile, then most likely there is a bug in QImage. " - Don't get hung up on Qimage. It is merely a tool that shows the sRGB profile as soon as I mouse over the thumbnail, BUT whenever it does, THE COLOUR IS WRONG BOTH ON THE SCREEN AND WHEN PRINTED.
Sorry to shout Chris, but you appear to be looking for a scapegoat rather than aiding us in our search for an answer. Please make a note that only the files that ARE WRONG (actually discoloured) in colour are returning sRGB and they are printing wrong. I personally don't care about file size as long as the colour is right.

You say "What was claimed, turned out to be wrong in multiple ways" - Too many people are experiencing this. You may not have the trouble, but as you can plainly see, others are and it is a simple matter to make it happen. How do you explain the fact that I can make it happen with an action in PS that does not change and has not changed in the last ten years of operation? That is not a "many people can be under the same mistaken impression, habit, etc." sort of error.

Question one - Can you ask around the firm, post a message on the lunch room bulletin board go to the programmers, etc. PLEASE?
Question two - Serious. Can I roll back to v.12 of CS5 as this is costing me money. I am a professional Photoshop user and cannot afford the time. It is that simple.
Question three - Is there another avenue for official Photoshop support?
Photo of Rebecca Hardgrave

Rebecca Hardgrave

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Rebecca Hardgrave

Rebecca Hardgrave

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
See Mike's comments below. I think we've found the root cause: bugs in the way QImage parses JPEG files.
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
Hey guys can we please get some focus on the original issue of whatever corruption has occured when CS5 was patched that is causing very severe delays in opening the files. I did a shoot yesterday, only processing needed was slight cropping. One of the subsequent jpgs opens fine and the other takes 20s to open.
So as has been said on this forum there is a random element here.

Yes I know I can use the workaround I came up with to re-open the jpg and invert it twice in CS5 and then save it again. Having been a user of CS since 6.0 I do think having a bug or bugs that have been going on for 3 months is pretty poor show, especially when it impacts the time, the workflow and the quality of the final image.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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).
Photo of Andrew Carter

Andrew Carter

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

Chris Cox

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

Chris Cox

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

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Chris,

You say "Yes, the files differ. But I doubt that the presence or absence of profiles in the thumbnails is going to hurt anything other than adding 6324 bytes to the total image size of 6.8 Meg."

OK, at least you admit there is a problem. CS5 should not be producing different output depending on the phase of the moon and the alignment of the planets (what other files might be present in the same folder).

If Adobe is okay with the fact that CS5 inserts leftovers from other images inside saved files and it does so inconsistently (sometimes but not others), I'll find a way to work around the Adobe bug. Personally, I don't believe you should just accept "randomly" garbaged-up headers even IF parsing the JFIF tree avoids those areas, but if that's what you want to do, fine. The JPEG spec specifies an APP2 (FF E2) tag followed by "ICC_PROFILE" as the proper tag for an embedded profile. Look at the file offsets I posted and you will see that there are three APP2 tags in that JPEG file and three ICC profiles inside the file: each properly formed JPEG should only have one APP2 tag whether it is in the parse tree or not! The fact that some programs "skip around" the garbage is fine, but you still are producing garbage headers and that needs to be fixed.

Qimage is not the only program that recognizes the extra APP2 color space tags. Other programs are having issues with the extraneous data in the files which is why you have people reporting that files saved that way take ages to load in some programs, files being rejected as invalid images in other programs, etc. As I said, I can work around the problem so this has never been an issue for me and my software, but that's like fixing the effect, not the cause. I just thought Adobe might want to fix the *fact* that under the conditions I specified, CS5 is inserting chunks of JFIF headers from previously processed files into some saves. Whether that data gets parsed as part of the JFIF tree is not really relevant to the bug: it's still a bug. There's more than one way to parse a JFIF header particularly if you are searching the header for a particular tag (like APP2, of which there should only be one).

Mike
Photo of Chris Cox

Chris Cox

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

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
Chris,

You're welcome! Took 10 days but you do finally see that there is a bug in CS5. We started at "deny, deny", went to "that's impossible", and we've now ended up with "oh yes, there ARE three profiles in the file, but two of them are attached to thumbnails". You and I both know that those two extra APP2 profile tags don't belong in there attached to thumbnail(s) or not, which is why no previous version of PhotoShop (or any other software) has ever done that, nor should 12.0.4. That's probably why you never thought of looking there even when I pointed out the exact file offsets: because they don't belong there.

And no, it's not a minor bug. If you want to define sloppy, the fact that CS5 12.0.4 cannot consistently save the same file the same way twice, randomly inserting extraneous data into the header is a MAJOR bug. I'm sure people who regularly use file cataloging/archiving/backup software are pleased that CS5 will create completely different files on two different runs even though the image, settings, and software version are the same. Kinda makes it hard to tell if your latest conversion is really any different from the previous! Professional software can at least save the same file the same way twice.

And yes, now that you've finally looked in the file where I've been pointing for the last 10 days and you realized CS5 was embedding color spaces into thumbnails (sometimes), you found the CS5 bug and pointed out a minor issue in Qimage as a result of that info. Headers are not parsed correctly if they have undefined data chunks not defined in the EXIF specs (embedded color spaces should not be in thumbnails: thumbnails are sRGB as you pointed out above). Easily fixable and that's a lot less of a problem because I've been doing this for 13 years and Qimage does not misread an embedded profile unless it encounters a malformed header: that combo did set off a bug which I need to fix. So thank you for pointing that out. See, help can go both ways so in the future I hope we can do this without the condescending words and the Adobe pedestal.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
The extra tags are harmless to any correctly written JPEG parser. This entire issue has been about a major bug in QImage that just happened to be triggered by a very minor inconsistency in Photoshop. Inaccurate and incomplete descriptions of the problem didn't help. Someone who jumped to incorrect conclusions about the cause didn't help. Not providing the examples requested didn't help. Repeatedly insulting the people trying to help you didn't help. Etc.

I couldn't find anything at the file offsets because you posted the wrong ZIP archive and had me looking in the wrong JPEG file. You only posted the "bad" file 23 hours ago, and I responded about 2 hours later with the diagnosis. Before that you only gave us source files that failed to reproduce the problem.

Failing to parse JPEG images correctly isn't exactly a minor issue. That's like claiming to read a language because you recognize 4 or 5 words, most of the time.

Next time, consider asking for help debugging your software instead of making inaccurate claims about other companies and dragging out what should have been a 5 minute debugging session.
Photo of Jerry Van

Jerry Van

  • 3 Posts
  • 0 Reply Likes
Well I ;have jsut fininshed working 20 files for a client and when sent to Qimage to print only 2 of them were messed up and had re-open them in raw as jpegs and re save as. this fixed the problem and they are now ready to print. Please stop being little kids and fix the problem. I have been printing and loving Qimage for many years and this problem has only been happening for a short time now. As mentioned but not noted by me with the latest release.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Supposedly QImage has a new version out that fixes the bug.
Photo of Klavs Hilden

Klavs Hilden

  • 2 Posts
  • 0 Reply Likes
I have a problem with pse 10
When I have processed an image in pse 10 and store in as a jpg-file,the canon zoombrowser has big problems with showing it (it takes appr. 20sec). If I then open the same image in pse 8 an then save again in jpg the canon zoombrowser has no problems with showing it. Can anyone tell me what to do ?

This reply was created from a merged topic originally titled
Photoshop Elements: JPEG saved from PSE 10 loads slowly in Canon Zoombrowser.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Talk to Canon about getting an updated version of Zoombrowser that fixes the bugs.
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
Hi, I've got an issue as above since changing from APE8 to 10

The problem occurs when opening a folder containing an edited image or images in Canon's Zoombrowser software which I use for collecting, collating and viewing images.

Problem is only when opening folders containing images (and the images themselves) which have been edited in APE10. Unedited folders and pictures or those edited with other software (including elements 8) open immediately as usual.

However, if a folder contains an APE 10 edited image, or images, it takes about 30 seconds before the folder completely opens for each picture it contains that's been edited in APE 10. So for example, a folder with 1 APE 10 image takes about 30 seconds to open, while a folder containing 4 APE 10 images takes 2 minutes to open and a folder with 6 APE10 images takes about 3 minutes etc.. If I then want to view an APE 10 edited image, it then takes about another 30 seconds to open that particular image.

As stated, never had the problem viewing images edited with APE 8 or other editing software.

Picture sizes (all jpegs) are the same and if I edit in APE 8, all is still fine in opening and viewing through Zoombrowser, the problem only occurs with images that have been through APE10.

This was the response from Canon:

"This still reads as an Adobe issue due to the fact that you state APE 8 was compatible with Zoombrowser and the problems occur since upgrading to APE 10. The only suggestion I have is make sure you are using the latest version of Zoombrowser. As for the compatibility issue with APE 10, I am unable to offer support on third party software."

Any help would be much appreciated

Thank you

This reply was created from a merged topic originally titled
APE10 edited images very slow to open in Canon Zoombrowser.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
See previous comments. Canon needs to debug their code, or contact Adobe and we can help them debug their code.
Photo of Bill Hulse

Bill Hulse

  • 4 Posts
  • 0 Reply Likes
Technic al BS aside I have windows 7 new adobe elements 10 and zoom browser 6.7 (newest).
Don't care about who or what causes this issue but now I have it and I can't use my zoom browser as I have in the past as it's too slow to load adobe edited images. As a simpleminded consumer I just want this fixed - don't care by whom - seems to me that the company that helps me 1st wins my dollars in the future. Who wants my money most?
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Again, Adobe can't do a thing about the bugs in Canon's code. Adobe has investigated and found nothing wrong on our side, but we don't know the nature of the bug in Canon's code, nor can we change Canon's code.
Adobe cannot help you fix bugs in Canon's product.
Canon is the only company that can fix the bugs in Canon's code.
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
So, how do we get the two firms talking to each other?

Adobe seem to be putting the ball in Canon's court and are asking us to get Canon to contact Adobe. Canon point blank say it's an Adobe issue as earlier versions are OK.

Seems to me that given there are more than one or two Canon users out there in the big world who also use Adobe software and are going to be deeply frustrated by this. Adobe are coming across as a little more user friendly than Canon at present, so how about Adobe contacts Canon so that the two tech teams can talk to each other and sort it out?

In the mean time, I'll pin this stream to an email to Canon and see what they come back with.
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
We keep trying to contact Canon, we send in bug reports, but we don't hear anything back. We've provided more than enough evidence to identify this as a bug in Canon's code.
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
Canon told me a month ago that a fix was being planned. Here's what their Canon Consumer Support told me:

Sorry for the delay in answering your last correspondence, and thank you for the detailed report that you provided, the information you supplied to us was very useful it allowed us to use the system as you would and doing so we managed to replicate your problem.
I then escalated this to our HQ in Europe who intern escalated it to our quality assurance in Tokyo. The carried out an investigation and have confirmed that there is an issue.
The found out that Photoshop CS5 add an ICC profile to the thumbnail during this process which was not done in previous versions like CS4 etc. our QA division have informed us that they will implement a fix when they release the next version of software. Until then they advise us to inform you of a work around, the work around, please use the “convert and save” feature as this will not add the ICC profile to the thumbnail.

Please check our download centre to see when the next update to the software is release which would have the fix.
Photo of Bill Hulse

Bill Hulse

  • 4 Posts
  • 0 Reply Likes
Minor issue for some...
Could you send those on this message board the fix when it arrives? We'll test it really well for you!
Bill
Photo of Mike Chaney

Mike Chaney

  • 26 Posts
  • 0 Reply Likes
The only thing that I see that is poor or "poorly written" is the code that is generating the corrupted JPEG's, and the fact that the problem has gone 4 months without a fix. The problem with the other software (what you call the poorly written parsers) is one of *error correction* because they are not properly handling an error when being fed a JPEG that does not follow JPEG standards. A JPEG that has an ICC profile embedded in the thumbnail is corrupted because embedding *ANY* JFIF markers inside a thumbnail is a violation of the standards. My recommendation if you are still claiming that a JPEG with an ICC profile embedded in the thumb is not corrupted: look it up. Learn the standards. Then follow them... rather than trying to create your own.
Photo of Chris Cox

Chris Cox

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

Mike Chaney

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
OK Great, do you know if this is likely to fix similar issue in APE 10 by any chance?

"Convert & Save"? Is that something in CS5?

I have Zoombrowser 6.7.2 installed, still Canon's latest version...
Photo of Bill Hulse

Bill Hulse

  • 4 Posts
  • 0 Reply Likes
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
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
No idea, most the above is beyond my ken but thanks for that work around Bill
Photo of Little Pale Face

Little Pale Face

  • 63 Posts
  • 3 Reply Likes
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
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Little Pale Face

Little Pale Face

  • 63 Posts
  • 3 Reply Likes
Accepted that other software may be at fault as well but are Adobe working on a fix to their software?
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Little Pale Face

Little Pale Face

  • 63 Posts
  • 3 Reply Likes
My main concern is why was this minor issue introduced? What other things are lurking around?
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Please see the previous discussions.
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
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."
Photo of james clapham

james clapham

  • 6 Posts
  • 0 Reply Likes
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."
Photo of david xu

david xu

  • 1 Post
  • 0 Reply Likes
i have exactly the same issue, pls also let me know when this problem gets addressed. thanks!
Photo of Edward Hamilton

Edward Hamilton

  • 2 Posts
  • 0 Reply Likes
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.
Photo of Richard Harrison

Richard Harrison

  • 1 Post
  • 0 Reply Likes
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.
Photo of Andrew Carter

Andrew Carter

  • 7 Posts
  • 2 Reply Likes
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!
Photo of Little Pale Face

Little Pale Face

  • 63 Posts
  • 3 Reply Likes
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
Photo of Edward Hamilton

Edward Hamilton

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
Read the previous comments -- it was a bug in ZB, which Canon has fixed.
Photo of Little Pale Face

Little Pale Face

  • 63 Posts
  • 3 Reply Likes
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]
Photo of Chris Cox

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Little Pale Face

Little Pale Face

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Bill Hulse

Bill Hulse

  • 4 Posts
  • 0 Reply Likes
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
Photo of Nigel Gillis

Nigel Gillis

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

Chris Cox

  • 20280 Posts
  • 842 Reply Likes
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.
Photo of Nigel Gillis

Nigel Gillis

  • 8 Posts
  • 0 Reply Likes
Sorry one more thing - It only happens with jpegs - If I save as tiff or psd all is good!!