P: Jpg exposes bugs in QImage and ZoomBrowser

sorry, very irritating here getting help, ended up in the community instead of being able to place this request to adobe. anyway, very annoying problem having bought new lr6

as you can see below i cannot see the needed data to the right anymore

Ok Thanks Chris, No I checked that - my settings are the same. Even if they were different I would expect a constant difference if you know what i mean. It remains a mystery to me - but at least I know it sometimes happens so am aware of it and my workaround is ready. I really thought a jpeg was a jpeg - I never knew that they could be different! Ive learnt something! Anyway thanks for the time - Ill mark it down as closed and await cs6 or 7 or whatever! N

Unless you make different choices in the options (saving profiles, etc.), I do not know why they would be different. The only bug we know of that makes them different relates to the length of the filename (save as trims it to 32 characters by mistake).

Lightroom and ACR share their file IO code - their files should be the same.
But they do not share the exact same code as Photoshop.

And no, different apps have different histories, different codebases, different needs, and release at different times -- they will not often sync up.

Hi chris -
"Save and Save As in Photoshop are the same" - any idea why they sometimes behave differently when saving jpegs?.
Does lightroom save jpegs with the same (jfif or whatever!) as cs5 (Im not talking about ACR - just the plain cs5. My point is that they should be the same across the adobe range but my issue seems to only appear with "save" commanded jpegs, and only in cs5.
It is really wierd but Im going to mark it as "parked", use my workarounds, and see what happens with future upgrades.
Thanks everybody for the time, N

My reply was to Mike.

Save and Save As in Photoshop are the same.

Lightroom may generate something different, but it should be the same as saving from ACR.

Hi again, Not sure if "Please, don't exaggerate the scope of the problem.

QImage had a bug, and that bug has been fixed by the author of QImage" was meant for me or Mike but Im not exaggerating the problem. Im simply telling you the behaviour Im seeing on my system. Leaving qimage out for a moment. Again I dont know anything about jfif headers I have one more question before I park it - I feel Im generating negative energy here which is not my intention!

"Is a jpeg generated by cs5 EXACTLY the same as one generated by lightroom 3.6? If they are (and I think they should be!) why am I only having issues with cs5 and only when I use the "save" command?"

Using the "save as" command I cannot remember ever having had the issue. This is the part I dont understand, but as I said I can live with it.

Incidently Mike I didnt know that "your bug" was only fixed in ultimate. (I obviously dont spend enough time on these forums - and my typing is too bad!). I have no problem upgrading to ultimate although I felt when I trialled it some time ago that I only needed the basic functions and didnt want to complicate matters. I will try again!

If Chris can answer my question I would appreciate it - I,m not trying to stirr up anything but simply to understand what is happening,
Thanks for the time, Nigel

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.

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

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

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