P: Jpg exposes bugs in QImage and ZoomBrowser

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.

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

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.

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

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!

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.

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

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.

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.

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]