More on Digital Color Spaces: a Reply to Chris MacAskill

After publishing my writeup on Digital Image Color Spaces four months ago, I got into a discussion on color spaces and photo-hosting sites with one Chris MacAskill on a forum at Digital Photograph Review. I didn't realize it until today, but it turns out that this Chris MacAskill guy is the president of the popular SmugMug photo-hosting site.

Fast-forward a few months to earlier this week, and Chris posted his own comments on the Mac/OSX aspects of the issue. In just a few days, his post got over 100 comments, including some from the main players in this arena. I guess that's one benefit of, well, having your own popular photo-hosting site. 🙂

Chris left a comment on my color-space writeup pointing to his post, and as my response to him and his writeup got longer, I decided to just include it here in my blog as a post.....

Chris MacAskill wrote:
|> I'd love it if together we could get some momentum for
|> Apple to implement the easy fix that makes this right.

Wow, Chris, well, if it's momentum you wanted, I think you got it, considering that you got more comments on your post than I have pageviews on mine, I guess there's some benefit to being the head of a popular site like yours. 🙂

I see that even Dave Hyatt responded to your note, which is excellent. I wrote to him directly myself, but got no reply. He's someone who can actually do something at Apple.

One thing I got from the article and from the comments is that people seem to think that setting the monitor profile is a good way to address this situation. However, that's trying to cancel out one mistake with another.

The monitor profile is data that indicates how to convert device-independent color data into actual photons, and that data is necessarily dependent on the physical characteristics of the individual LCD or CRT. sRGB was designed to mimic the average such device (circa 10 years ago), but it would be a remarkable coincidence for any particular display's physical characteristics to actually match sRGB, so setting its profile to sRGB is correct only in a remarkablely coincidental situation.

The root of the OSX problem is that it makes a poor guess as to the color space of an unprofiled image, and so given that, how can it possibly hope to convert properly from the (misunderstood) device-independent color data of the image to the device-dependent data required of the display device? You can try to compensate by changing the monitor profile to something less accurate that seems to give nice results, but you can probably get the same effect by smearing an appropriately colored block of Jello™ in your eyes. Both seem effective in the short run, but are probably not good solutions. 🙂

The consensus among the comments on your post seems to be that the paramount importance is for colors to match across technologies.... images, flash, html/css, etc., and that such matching should take precedence over accurate color rendering. Clearly, the matching is important because, as you point out in your post's examples, not doing so can create a worse effect than coordinated-but-inaccurate colors.

However, what no one seems to mention is that the need for coordination tends to be restricted to, well, when it's needed, and that there are times when proper colors are clearly more important, such as when displaying the rich beauty of one's photographic work (such as on a web page with a colorless background, like your photo-hosting site does.)

I don't doubt the difficulty faced by Dave Hyatt at Apple, but here's a suggestion I've made before for OSX that goes a long way toward solving the issues in a way that is sensitive to the context: respect an image's color-space information if it's there, and if not, coordinate the color space with that of flash/css/whatever.

This might sound to be exactly like what OSX does now, but the big difference is that OSX currently ignores tagged color profiles. All digital cameras today (well, at least any I've ever heard of) mark the color space in the image metadata with a simple one-word note, rather than with a full-blown embedded color profile. The EXIF/DCF standards that cameras tend to adhere to currently allow sRGB and AdobeRGB to be noted this way. The benefit is that it takes only a few bytes, but the drawback is that no browser recognizes it, not even Safari.

May 2007 Update Much to my embarrassment, I've only just realized that Windows browsers do not default to sRGB, but rather, are unmanaged, and so they treat all images in the same sort-of-random, sort-of-close-to-sRGB way that Safari treats unprofiled images. As such, the next paragraph is wrong.

(Outside of OSX, it's not usually an issue because most cameras produce only sRGB, and most browsers are on Windows which blindly assumes sRGB, and hence it becomes an issue mostly for Safari and other OSX browsers).

The beauty of this approach is that it keeps color coordination among page components when needed (because web designers making mastheads and logos and stuff don't tag their images with color-space information), yet allows people who upload images from their point-n-shoot or pro-dSLR to expect them to be seen with the most accurate colors their audience's monitors can produce. It would even let SmugMug have color-managed thumbnails!

One would hope that in the future, Flash and such will all be properly color managed (and no one is waiting for this more than Dave, I'm sure 🙂), but until then, doesn't this seem like a reasonable compromise? You can then get proper colors where it matters most, and people can leave their monitors set with the profile that's most appropriate for the monitor and not to an artificial profile designed to cater to some specific misinterpreted content.

The next step, then, would get the folks in Redmond to respect color profiles.....but I won't be holding my breath!

xref

One comment so far...

Hey Jeffrey,

Thanks for the response! Here I am 11 months later because I missed your response, which was a good one. Sorry.

We actually implemented what you were suggesting, attaching ICC profiles to images if we detect that the user has an ICC-aware browser. We don’t so it for non-ICC aware browsers because then they’re just dead weight and the weight can be important if you’re on a wireless connection with a handheld device, for example.

Unfortunately, attaching profiles wasn’t the cure we hoped because by popular demand we have to offer Flash slideshows and Flash ignores your profile even if you’re in Safari. Ugh.

Hey, we’d love you to weigh in on a thread if you have something to add about why the shift between IE and Safari when you just calibrated your monitor with a gamma of 2.2 and white point of 6500. Here’s a post and you can catch the thread by clicking in upper right:

http://www.dgrin.com/showpost.php?p=735323&postcount=72

Thanks!
Chris

— comment by Chris MacAskill on January 27th, 2008 at 11:58am JST (9 years, 10 months ago) comment permalink
Leave a comment...


All comments are invisible to others until Jeffrey approves them.

Please mention what part of the world you're writing from, if you don't mind. It's always interesting to see where people are visiting from.


You can use basic HTML; be sure to close tags properly.

Subscribe without commenting