P: Jpg exposes bugs in QImage and ZoomBrowser

Chris,

You say "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."

OK, at least you admit there is a problem. CS5 should not be producing different output depending on the phase of the moon and the alignment of the planets (what other files might be present in the same folder).

If Adobe is okay with the fact that CS5 inserts leftovers from other images inside saved files and it does so inconsistently (sometimes but not others), I'll find a way to work around the Adobe bug. Personally, I don't believe you should just accept "randomly" garbaged-up headers even IF parsing the JFIF tree avoids those areas, but if that's what you want to do, fine. The JPEG spec specifies an APP2 (FF E2) tag followed by "ICC_PROFILE" as the proper tag for an embedded profile. Look at the file offsets I posted and you will see that there are three APP2 tags in that JPEG file and three ICC profiles inside the file: each properly formed JPEG should only have one APP2 tag whether it is in the parse tree or not! The fact that some programs "skip around" the garbage is fine, but you still are producing garbage headers and that needs to be fixed.

Qimage is not the only program that recognizes the extra APP2 color space tags. Other programs are having issues with the extraneous data in the files which is why you have people reporting that files saved that way take ages to load in some programs, files being rejected as invalid images in other programs, etc. As I said, I can work around the problem so this has never been an issue for me and my software, but that's like fixing the effect, not the cause. I just thought Adobe might want to fix the *fact* that under the conditions I specified, CS5 is inserting chunks of JFIF headers from previously processed files into some saves. Whether that data gets parsed as part of the JFIF tree is not really relevant to the bug: it's still a bug. There's more than one way to parse a JFIF header particularly if you are searching the header for a particular tag (like APP2, of which there should only be one).

Mike

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.

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?

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.

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

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.

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

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

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.

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