I got an email this morning asking if I knew anything about the iPhoto color shifting issue with edited images. I hadn’t been paying much attention to this while working on other stuff, but once I looked for the problem it it was very apparent and troubling.

Based on a lot of good information in the MacInTouch iPhoto Report, a massive thread on Apple Discussions and my own experience with Apple’s image manipulation tools, I think I’ve found the basis of this bug. James Bailey’s observation on MacInTouch specifically identifies the problem:

Using Photoshop 7.0 to help diagnose this, here is what seems to be happening. My original photo seems to have an embedded ColorSync profile of sRGB IEC61966-2.1. […] Opening the duplicated and cropped photo I do not get the same warning which means that Photoshop thinks the embedded color profile is now ColorSync RGB – Generic RGB Profile for the new file. [emphasis added]

That describes exactly what I’m seeing.

SIPS, Apple’s Scriptable Image Processing System offers tools for working with images and manipulating things like ICC color profiles. I have two photos, DSC04737.JPG and DSC04737_1.JPG, the second is a duplicate of the first with a few lines cropped off the bottom to trigger the color change.

When opened in Photoshop, I see the following Color Management warnings:
DSC04737.JPG
Embedded: sRGB IEC1966-2.1

DSC04737_1.JPG
Embedded: Generic RGB Profile

However, when checking with SIPS, I see this:

$ sips -g profile DSC04737.JPG
profile: Generic RGB Profile

$ sips -g profile DSC04737_1.JPG
profile: Generic RGB Profile

SIPS appears to wrongly identify the embedded profile in the original image, believing it is Generic RGB. It gets slightly more interesting, and confirms another suspicion of mine: With 10.3.9, SIPS can’t find a profile in the unmodified image and returns the following:

$ sips -g profile DSC04737.JPG
profile: <nil>

$ sips --extractProfile profiledump.icc DSC04737.JPG
Error: No profile in image

At this point I’m comfortable pointing to the underlying ColorSync foundations updated in 10.4 as the culprit. (These are used by SIPS and presumably by iPhoto too, despite iPhoto’s unique EXIF parsing engine, the foundations are meant to be used throughout the system.) My only hesitation is whether or not this problem appears on 10.3.x after installing QT7.

Comparing the two images without color management in Photoshop shows that the image is permanently changed. Unfortunately, this means that whatever caused the conversion applied a lossy correction to all pixel values. While there is the potential to somewhat reverse this problem with some profile voodoo and dumb luck, the result would be twice shifted and especially prone to visible artifacting and posterization.

Based on the above, I’m guessing that when iPhoto reads the originals, it wrongly interprets the files before applying changes to it. This would mean the modified files are ruined before iPhoto’s adjustments are even applied.

If I were feeling especially adventurous and had lots more time, I might try replacing all or some of the ColorSync frameworks with versions from 10.3.9. I’d find the files to replace here:

/System/Library/Frameworks/
ApplicationServices.framework/Versions/
A/Frameworks/ColorSync.framework
/Versions/A/

Of course I’d be doing that at my own risk, with the knowledge that I could render my computer unbootable and only with a full backup ready to go. But it is an interesting theory and I wonder if anyone’s tried it yet.

Rumor has it that this is all fixed in 10.4.2. (update: not fixed