Skip to main content
Adobe Photoshop Family

9 Messages

 • 

260 Points

Wed, Jun 22, 2011 10:52 PM

Photoshop: jpg exposes bugs in QImage and ZoomBrowser

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.

Responses

14 Messages

 • 

202 Points

9 years ago

The first time the problem I had occurred was on July 15th, might help to pinpoint the problem if there was a way to see if it was as soon as 12.0.4 was installed. If it installed May 3, it might not even be the problem. I have my PS set to auto update, and I cannot remember if it asked to update or anything specifically on that day. I did not notice the problem till a few weeks aftewards, when orders from that session and the following sessions started getting printed.

26 Messages

 • 

280 Points

9 years ago

It'd probably be difficult to prove anything. You'd have to know when the update was pushed to your computer, how long after that it was until you used the image processor on raw files, AND the problem is not consistent: doesn't always happen unless the conditions are right. I think Adobe has enough info now to find/solve it. Let's give them time to respond. Only thing I can say for certain is that 12.0 did not have the problem and 12.0.4 does. I have no idea which version in between actually caused it but I suspect it is the latest (12.0.4) just because of the increase in reports of this problem from my customers in recent weeks. Nothing before May.

3 Messages

 • 

80 Points

9 years ago

I have 12.0.4 and am having a similar problem that is costing me alot of time and frustration. I am opening files in ACR and then working the files and saving them as jpegs in RGB space. When I open them to print in Q-image some of them are in sRGB on no profile at all! This is not user error, I have not changed my system here for a long time. Please help us out.

Employee

 • 

142 Messages

 • 

2.5K Points

9 years ago

Hi,

For those having problems, can you reply back with the version of the Camera Raw plug-in you have installed and the workflow settings? Also what OS are you using?

You can quickly find the CR version this way using Photoshop menus:
Win: Help> About Plug–In> Camera Raw...
Mac: Photoshop>About Plug–In> Camera Raw...

regards,
steve

26 Messages

 • 

280 Points

9 years ago

6.4.1.145 here

14 Messages

 • 

202 Points

9 years ago

6.4.1.145
Windows 7

3 Messages

 • 

80 Points

9 years ago

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

9 Messages

 • 

260 Points

9 years ago

6.4.1.145
Windows XP Home Edition with SP3

6 Messages

 • 

120 Points

9 years ago

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

6 Messages

 • 

120 Points

9 years ago

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

15.1K Messages

 • 

195.8K Points

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

6 Messages

 • 

120 Points

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

15.1K Messages

 • 

195.8K Points

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

6 Messages

 • 

120 Points

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

15.1K Messages

 • 

195.8K Points

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.

6 Messages

 • 

120 Points

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.

15.1K Messages

 • 

195.8K Points

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

15.1K Messages

 • 

195.8K Points

Turns out QImage was the problem -- bugs in the QImage JPEG parsing caused it to read the wrong color profile.

26 Messages

 • 

280 Points

Qimage had a bug, yes, but it only surfaces when the CS5 bug produces JPEG's with inapplicable profiles attached to multiple thumbnails in the header.

26 Messages

 • 

280 Points

9 years ago

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

15.1K Messages

 • 

195.8K Points

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

26 Messages

 • 

280 Points

9 years ago

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

15.1K Messages

 • 

195.8K Points

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.

26 Messages

 • 

280 Points

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

15.1K Messages

 • 

195.8K Points

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.

26 Messages

 • 

280 Points

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

15.1K Messages

 • 

195.8K Points

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

15.1K Messages

 • 

195.8K Points

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.

6 Messages

 • 

120 Points

9 years ago

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

15.1K Messages

 • 

195.8K Points

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.

6 Messages

 • 

120 Points

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?

14 Messages

 • 

202 Points

Chris, I would LOVE to have the answers to the above three questions. Ask another aunt or uncle in the "Photoshop Family". Not trying to return the condesending attitude, but could your method of trying to discover the problem be erred? Can you give us a detailed procedure we should try to see if we can get the same results you are getting? What is your definition of a bug in the program?

15.1K Messages

 • 

195.8K Points

Where is "the color wrong every time"? Is it QImage that displays the files incorrectly? Photoshop appears to read the "bad" file and displays it correctly with the AdobeRGB profile in the file (ignoring the extras in the thumbnails like it should). Photoshop prints the good and "bad" files identically. (yes, I just did that)

Shouting won't help the fact that you are leaving out important details and ignoring the findings from the evidence provided.

Yes, you have problems. But that does not mean that you understand the problems, or are assigning the blame correctly. Again, there is apparently a minor bug in Photoshop that causes profiles to be included with the thumbnails sometimes (possibly randomly). Again, that should be completely harmless because the profiles in the thumbnails have no relation to the full resolution document.

Yes, insulting the senior developer who is taking his own time to investigate the problem and help you is really going to help your case. Oh, and I am the developer most knowledgable about file formats, standards, parsing, profiles, and all the related bits.

So far, we can't reproduce your results. Maybe there is a random bug, but we haven't found the triggering factor yet. Now that we know that something is writing profiles in the thumbnails, we'll investigate that code more closely.

But the claims of corrupted files, wrong color, and incorrect printing are still completely unproven. And it still sounds like you are leaving out important details.

You aren't getting any condescension -- but I'm having a hard time determining the facts of the case because you're making a variety of wild claims but providing scant evidence to back up those claims.

14 Messages

 • 

202 Points

So please ask me the questions you need the answers to. Do you need a detailed procedure with settings on my workflow? I am willing to tell you every step I do, I just need to know what you need know. As far as unproven, what do you need us to send you to show you the results we are getting? I can send you prints, files, screen shots, just let us know what you want to see and where to send it.
And, lastly, can you please tell me if there is anyway to "un update" and let us see if we get any better results. It may be coincidence, if that would make my workflow go smoothly again, I can live with that and turn off Adobe updates.

15.1K Messages

 • 

195.8K Points

See Mike's comments below. I think we've found the root cause: bugs in the way QImage parses JPEG files.

26 Messages

 • 

280 Points

Which surfaced due to the CS5 bug that inconsistently produces a header that has inapplicable profiles attached to multiple thumbnails in the header.

9 Messages

 • 

260 Points

9 years ago

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.

15.1K Messages

 • 

195.8K Points

The original issue was about Canon's ZoomBrowser software being slow to read files. Brett requested samples, which I don't recall ever seeing (but maybe he forwarded them to Canon without sending them to me).

Also, that still sounds like a bug in Canon's software which Canon would need to debug. I can't do much for Canon's software because I don't have the source code for their software. Even a minor change in metadata (ie: changing the date) could cause a problem if they have a bug in their code (and yes, dates have caused crashes in other software before).

9 Messages

 • 

260 Points

Brett told me on 29-Jun that he'd passed the files over to the engineering team.

OK let's start again. here's what Canon told me:
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.

15.1K Messages

 • 

195.8K Points

What Canon told you translates to: the files have a different size. That's all it means. It doesn't tell us anything about why they take so long to read the files.
And it really sounds like that came from someone, um, not technically savvy. The issue really needs to go to Canon's developers so they can debug their code and find out why one file takes longer.

I'll check with Brett (and check the SPAM trap to see if I missed his email).

15.1K Messages

 • 

195.8K Points

OK, I did get the files from Brett back in June and just forgot about them.

Yeah, what you're looking at is definitely a bug in ZoomBrowser's code.
We've tried to talk to Canon independently, and haven't gotten anywhere.
So it's in Canon's court - if they want help identifying the bug in ZoomBrowser, they need to contact Adobe. We've done all we can.

26 Messages

 • 

280 Points

9 years ago

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

15.1K Messages

 • 

195.8K Points

The profiles are not leftovers, and are correct for the thumbnails (which according to EXIF standard, are converted to sRGB). There is no garbage, and no corruption -- just the inclusion of the profiles. Parsing the JPEG tag tree does avoid the thumbnails, unless you're extracting only the thumbnails. Those are correctly embedded profiles in the thumbnails, completely parsable within the thumbnails. Um, no, embedded JPEG thumbnails are valid JPEG streams within the main JPEG file. That's how the EXIF standard works, plus another thumbnail/preview is embedded in a private tag for Adobe data. Again, there is no garbage, and no need to "skip around". The file parses just fine.

I hope you are mistaken about the way QImage reads JPEG tags - professional software should never be that sloppy, and should be parsing the file structure correctly. That sort of bug could lead to lots of mistakes in file parsing, especially when working with EXIF standard JPEG and TIFF images.

So, the bottom line appears to be that Photoshop has a minor bug that sometimes includes profiles in thumbnails. And QImage has some major bugs in the way it attempts to read JPEG images and picks up the thumbnail profiles by mistake.

26 Messages

 • 

280 Points

Chris,

You're welcome! Took 10 days but you do finally see that there is a bug in CS5. We started at "deny, deny", went to "that's impossible", and we've now ended up with "oh yes, there ARE three profiles in the file, but two of them are attached to thumbnails". You and I both know that those two extra APP2 profile tags don't belong in there attached to thumbnail(s) or not, which is why no previous version of PhotoShop (or any other software) has ever done that, nor should 12.0.4. That's probably why you never thought of looking there even when I pointed out the exact file offsets: because they don't belong there.

And no, it's not a minor bug. If you want to define sloppy, the fact that CS5 12.0.4 cannot consistently save the same file the same way twice, randomly inserting extraneous data into the header is a MAJOR bug. I'm sure people who regularly use file cataloging/archiving/backup software are pleased that CS5 will create completely different files on two different runs even though the image, settings, and software version are the same. Kinda makes it hard to tell if your latest conversion is really any different from the previous! Professional software can at least save the same file the same way twice.

And yes, now that you've finally looked in the file where I've been pointing for the last 10 days and you realized CS5 was embedding color spaces into thumbnails (sometimes), you found the CS5 bug and pointed out a minor issue in Qimage as a result of that info. Headers are not parsed correctly if they have undefined data chunks not defined in the EXIF specs (embedded color spaces should not be in thumbnails: thumbnails are sRGB as you pointed out above). Easily fixable and that's a lot less of a problem because I've been doing this for 13 years and Qimage does not misread an embedded profile unless it encounters a malformed header: that combo did set off a bug which I need to fix. So thank you for pointing that out. See, help can go both ways so in the future I hope we can do this without the condescending words and the Adobe pedestal.

15.1K Messages

 • 

195.8K Points

The extra tags are harmless to any correctly written JPEG parser. This entire issue has been about a major bug in QImage that just happened to be triggered by a very minor inconsistency in Photoshop. Inaccurate and incomplete descriptions of the problem didn't help. Someone who jumped to incorrect conclusions about the cause didn't help. Not providing the examples requested didn't help. Repeatedly insulting the people trying to help you didn't help. Etc.

I couldn't find anything at the file offsets because you posted the wrong ZIP archive and had me looking in the wrong JPEG file. You only posted the "bad" file 23 hours ago, and I responded about 2 hours later with the diagnosis. Before that you only gave us source files that failed to reproduce the problem.

Failing to parse JPEG images correctly isn't exactly a minor issue. That's like claiming to read a language because you recognize 4 or 5 words, most of the time.

Next time, consider asking for help debugging your software instead of making inaccurate claims about other companies and dragging out what should have been a 5 minute debugging session.

26 Messages

 • 

280 Points

I see you've spent extra time replying to each individual thread trying to shift blame to Qimage and away from the bug that we both know exists in CS5. Without the CS5 bug, I would never have found the Qimage bug so yes we both have bugs. Have you fixed yours yet? I've fixed and released mine.

Bottom line: there is a CS5 bug in 12.0.4 and there *was* a bug in Qimage Ultimate v2012.103. To outline the bugs we've found in this thread (as I will not be back here because it serves no further purpose for either side at this point):

CS5 bug: Exact same file and program settings can cause a bug depending on what was converted prior. The bug is that under the right (inconsistent) conditions, CS5 12.0.4 will embed sRGB profiles into all embedded thumbnails. When it works properly (again depending on what was converted prior, even in a separate session), the thumbnails don't have the inapplicable (extra) profiles.

Qimage bug (fixed): A bug in the algorithm used to extract the embedded profile was inappropriately following the parse tree and parsing both the original image and the thumbnail images when looking for an embedded profile. The bug has never surfaced because the condition simply has never been encountered in order for it to surface: there really should only be one profile embedded in any file (including the thumbnails within). Until CS5 12.0.4, no program has ever tried to embed color spaces into embedded thumbnails as they should be sRGB by definition. With the extraneous data, the bug surfaced. The bug is fixed in Qimage Ultimate v2012.104.

BTW, I never posted the wrong file. If you follow the directions in the original ZIP file which were detailed and WILL reproduce the CS5 bug (call it a minor bug if you want, doesn't matter any more), this whole thing could have been solved 9 days ago. Instead, you're looking in the JPEG I included in the ZIP which the instructions clearly say is only there because that is a JPEG that (when present), causes CS5 to inappropriately start embedding color spaces in thumbnails. The instructions very clearly say to use that JPEG as test conditions and *examine the output files from CS5*. Had you done that, this would have been so much easier. Instead, you were so convinced there couldn't possibly be a problem in CS5 that you completely ignored the readme file in my original ZIP. I know you ignored it: or you wouldn't have been examining the sRGB profile embedded in the (superfluous) JPEG that was included. And that would have prevented you from posting the comments like all you've seen are "anecdotes and confused descriptions": a post I see you've now deleted.

Anyway, over and out. No more gained from posting here.