P: Jpg exposes bugs in QImage and ZoomBrowser

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.

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

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

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

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

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.

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.

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

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

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