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 188.8.131.52 (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.
Help get this topic noticed by sharing it on Twitter, Facebook, or email.
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
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
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
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
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