P: Jpg exposes bugs in QImage and ZoomBrowser

[andrewc94999058]

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.

[RHardgrave]

6.4.1.145
Windows 7

[jerryv99583004]

6.4.1.145
Windows 7
From camera raw I open as Abobe RGB(1998)
After I finish working on the files I save them as jpeg's Quality 10 Baseline Standard

[andrewc94999058]

6.4.1.145
Windows XP Home Edition with SP3

[colin481]

I have been having a great deal of trouble with colour instability since recent updates to CS5 also. Am running XP64, CS5 12.0.4, Camera Raw 6.4.1. I run Adobe RGB 1998 workflow from camera to printer.
Seems to be totally random result of some files returning an sRGB colour space and some returning AdobeRGB 1998 when converted to jpegs for printing. Same result for scanned images too, so it is not the camera. The 32bit version appears to be worse, but the 64 bit version does it too.
EXIF details in Bridge show Adobe rgb but this is not the case when viewed with a hex editor. I processed the same two files (one a psd & the other a tiff) no less than seven times with totally random results. I could not return a pattern. Sometimes sRGB & sometimes Adobe!

The only way I can get around it is to include a new line in the action that sends the files to the print output folder which is: Edit/Convert to profile/AdobeRGB 1998.
This seems to ensure me the result I need to print accurately.

Note to ADOBE - NOT HAPPY!!

[colin481]

I have applied my modified action as mentioned above, but it still does not provide a sure thing cure to the problem. I have found that if I reload the offending file into CS5 and Convert to profile/Adobe RGB and then Save As over the original Tiff or PSD manually, it seems to save the following jpg file as Adobe RGB okay.

BTW, how do I get the addition of the Convert to profile in the action to apply it without stopping to ask me to press Enter. Have I missed/forgotten something?
Col

[FeedbackCommunityMember]

So you're not seeing any corruption, just JPEG files with what you believe to be the incorrect profile?

[colin481]

Thanks for the reply Chris.
Image sharpness is okay, just colour is wrong and that is visible both on the screen and in the final print. Colour prints are dead and lifeless with a narrower gamut, sepia prints that should be brown are slightly green tinge and there IS an sRGB profile in there even though Bridge Metadata says that the file is AdobeRGB. I can get the correct colour profile into the jpg file rather laboriously as mentioned above, but my usual method is to load the files to be printed into CS5, then run an action to save them as jpgs to the printing output folder. This is where they SOMETIMES appear as sRGB and the colour is definitely wrong then. I don't have to print to see it. The sRGB profile is shown in hex editors I am told, but I see it in the status bar of Qimage printing software which shows it instantly and reflects the change when I force it to AdobeRGB.

See the post from three days ago above.
More reference here: http://ddisoftware.com/tech/qimage/of...

[FeedbackCommunityMember]

It almost sounds like the image has the wrong profile -- which means you should use assign profile, not convert.

[colin481]

Hi Chris
As I mentioned in my post 3 days ago above "I run Adobe RGB 1998 workflow from camera to printer. " I also get the problem from files that have been sent to me via email and also scanned images which rules out the initial recording method. Many of these files are years old too. Some are quite new. I do this for a living and am quite comfortable with the operation of CS5 and printing on a large scale. This has only happened since the update. I was complaining to Mike Chaney (see above) as were other folk (see http://ddisoftware.com/tech/qimage/of... ) and he could not duplicate the problem until he updated his copy of CS5 v.12 to 12.0.4 then he too had the problem.
I am not alone here Chris. It is recorded that as many as four profiles are embedded in some files.

I can run the action to save the file as a jpg and it embeds an sRGB profile. I can do the same manually (without the action) and get the same result. If I manually Convert to profile/AdobeRGB, then SAVE AS over the original TIFF or PSD it will then save a jpg with AdobeRGB profile! I can get a clean print run, but where it used to be a quick and clean process, I now have to check each file and re-save it as mentioned above. Queer for sure, but V.12 appears to be clear of this problem.
Can I roll back to V12 pre-update? Serious!
Thanks
Col

[FeedbackCommunityMember]

And yet the sample files we have been provided have exactly one profile in them (again, it would be near impossible for the file to have multiple profiles, and then the chance would be due to disk errors). We have not reproduced the problem, nor have we seen evidence of the problem, just anecdotes with confused descriptions. Steve and I have both tried to reproduce this on Windows 7 with zero success.

It sounds like your document has an sRGB profile, and saves correctly. Then when you convert to AdobeRGB, it saves correctly. That really sounds more like user error than a bug.

So you're gonna have to give us more to go on.

[colin481]

Bridge shows the file as having AdobeRGB space every time even after saving with the "troublesome" format, yet they appear to the eye as wrong colour and (in my case) the printing software I use, Qimage, shows it as sRGB and it prints as sRGB with bad colour. When I "force" it to save as AdobeRGB Qimage reads it correctly, it looks and prints good.

If you read the thread carefully you may glean a hint of what to look for? As I mentioned above I have opened and processed two files seven times with varying results. They started with AdobeRGB and sometimes they were but when Qimage said they were sRGB they WERE the wrong visible colour on screen. I can appreciate your doubt as I have just now once again ran the action that saved the files to the printing folder as follows:
Selected six of them in Bridge, check that ALL are AdobeRGB in metadata
Load them into CS5 and run the action through File/Automate and all but one in the output folder has AdobeRGB. One has sRGB. This file was a scan, saved originally as AdobeRGB and to make it more interesting, one of the AdobeRGB files in here is a smaller resize & SAVE AS from the file that returned sRGB yet the two are different colour spaces with different visible colour!
NOW! The frustrating part. 30 seconds later, I load the same selected files from Bridge, run the same action and look in the output folder and ALL of them are AdobeRGB & the colour look right throughout!
2nd test:
Loaded six more files at random including two that did not contain correct colour profiles.
Ran the action and in the output folder one had sRGB (not one that had to convert upon loading into CS5) The two that converted to Working profile upon loading showed AdobeRGB.
Ran the same sequence again immediately and TWO of them showed sRGB this time!

I could do this all day, it would seem, with varied result.
Do you see why we hate computers so much?

I cannot speak for others, but I am using XP64 would there be a glitch there? Try it on an XP system if you can.

Can you ask around & see if anyone has a clue as this is real and affecting more than one or two, but as yet, we have have not pinned a pattern to it.

[FeedbackCommunityMember]

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

[FeedbackCommunityMember]

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

[FeedbackCommunityMember]

>> 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.

[FeedbackCommunityMember]

I have read carefully. Much of what has been claimed is near impossible, so I have to guess that the descriptions are most likely inaccurate. And it really sounds some files might contain the wrong profile, or QImage has problems reading the profiles.

Throwing QImage into the description of the problem is just confusing the issue (or maybe is the issue?).

Yes, XP64 could be part of the problem - it is not a supported OS version for many, many reasons (bugs never fixed in the OS, drivers never updated, etc.)

[FeedbackCommunityMember]

The file size may differ a bit when metadata is involved. That alone does not indicate a problem. If the files end up with "random" color profiles (or anything other than what they are supposed to contain) - that probably indicates a bug.

But we still haven't seen corrupted files - just files with the wrong profile embedded.

[FeedbackCommunityMember]

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

[FeedbackCommunityMember]

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.

[FeedbackCommunityMember]

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

[FeedbackCommunityMember]

Check your link, that's not the same archive you sent earlier.
csproblem.zip vs. csproblem2.zip

[FeedbackCommunityMember]

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.

[colin481]

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

[FeedbackCommunityMember]

You might want to read the previous comments first.

What was claimed, turned out to be wrong in multiple ways (at least with current evidence). Yes, there is a problem, but a minor problem that should not affect anything other than a few K of file size.

QImage should be reading the file exactly the same way Photoshop and other programs do. If QImage is seeing a different profile, then most likely there is a bug in QImage.

And no, user error is not ruled out so easily because many people can be under the same mistaken impression, habit, etc. It has happened before.

[colin481]

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?

[andrewc94999058]

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.