Photoshelter and Color Management

I’ve been using Photoshelter pretty heavily these days. I like Zenfolio. I like SmugMug. But, the feature set at Photoshelter is right on target for what I need. I should write up a blog post comparing all these services at some point and what some of the decision points are. For right now, however, I’m going to pick on a problem.

When Photoshelter generates resized images for their website, they convert everything to sRGB. As described in the Color Profiles section of their tutorials, this is actually a good thing. Most web browsers are still woefully ignorant of color spaces and really, the sanest thing to do is convert to sRGB. At least it’s the sanest thing to do in 2009.The problem is that Photoshelter doesn’t tag the images with an sRGB profile. They make sure the data is in the sRGB colorspace, save it off, and send it on its way untagged. Why is this a problem? Well, if you’re using a color managed browser, such as Safari, you could be seeing a better representation of the image. Instead, since the images aren’t tagged, they get displayed in an unmanaged way.

On my MacBook Pro, the result is that everything on Photoshelter is slightly desaturated. It’s not a huge problem, but it is a surprise to see when you know that every application you are using is color managed and you are running with a profiled display. It’s safe to say that it’s an annoyance. With my Mac Pro at home with a wide-gamut NEC 2960 WUXi display, on the other hand, things go nuts. Since the display has a huge gamut, the effect on all images that aren’t tagged with a profile is to over saturate.

To show you an example, here’s a view of how a photo of Jack Dangermond I took at Where 2.0 last week looks on both of my displays, as rendered in Safari viewing the Photoshelter page the image is on. I took screenshots (tagged with the display profiles) on each machine, then combined them, converted into sRGB, and then saved off this JPG. The result, even if you’re not viewing this with a managed application, should give you an idea of the deltas involved in what I see.

The end result is that Mr. Dangermond looks like he has a pretty good sunburn on the NEC display, and is slightly drained of color on my MacBook. Nether result is what I want somebody using a color-managed browser to see.

I know. Color managed browsers are in the minority still. But if you’re on a Mac and using the default browser like some large percentage of creative types, then I want you to be able to see my images with the right intent. And, even if you’re not using Safari, Firefox 3 has some switches to enable color management, though why it’s not on by default in 2009 is beyond me.

Bottom line: I totally dig Photoshelter and I’m really digging most of its feature set. Hopefully, this is something that folks over at Photoshelter can turn on pretty easily. From my vantage point, it would seem that they just need to include the sRGB profile in outbound images. But what do I know?

N.B. Ordinarily, I would have posted this in the Photoshelter forums (to this thread, in fact) rather than using my blog, but I was having problems posting this evening. So, I posted it here so that I can send on a pointer and not forget to do this later.

Update 2009/06/02

I got a very nice email today from a Photoshelter representative explaining their position. It was a perfectly great reply, except for the statement an assumption on the part of Photoshelter that is probably at the crux of the matter. The salient part of the message is the following:

The way to force all browsers to see the same way (meaning browsers that can color manage and those that can't) is to strip the color profile from the web preview. By stripping the color profile we are telling the browser to render the image as sRGB, which should be the default behavior of all browsers when no profile exists. Basically, all browsers should rendering images on PhotoShelter as sRGB -- the standard color space for web presentation of images.

Let me step back a minute and provide just a touch of context for those of you that haven’t dealt much with color management. Software that doesn’t use the system’s color management services draw, by definition, in the out device’s native color space. This means that when an application draws a red pixel (say 255,0,0 on an 8-bit device), the result is as red as the display can manage. On a laptop, it’ll be the best red the laptop display can do. Most desktop monitors can do better with pure red. And the best wide gamut monitors will produce a red that will knock your socks off. While the 8-bit value is the same, they’re all different reds.

The different shades of red that can be generated with thes same value of 255,0,0 is why we have abstract color profiles like sRGB, AdobeRGB, and many others. When a value of 255,0,0 is in a file tagged with a profile, the system can do a bit of math to display a red that better fulfills the intent of the creator of the image than it can without this bit of information. It’s sometimes not perfect, especially if the gamut of the display can’t encapsulate the color space of the image, but it’s a lot better than without the profile. Without a profile, even the best color management software can make no determination of what red it should be, so it just tells the monitor to draw maximum red and damn the torpedos!

Now, the W3C would like all browsers to render untagged images in sRGB, as written in A Standard Default Color Space for the Internet - sRGB. As an owner of a wide gamut display, and in the interest of better color for all, I’d like that too. But, as far as I know right now, the only place the guidelines outlined in that document happen with respect to untagged content is on Windows Vista. At least that’s what I’m told. I’ve also been told me that while it works to some degree, it’s not nearly as reliabily as just including the profile in the first place. (yes, you’re right. I should fire up Vista myself and check it out). Even if the implementation in Vista was perfect, since Microsoft’s latest released effort hasn’t had the greatest of adoption, you can hardly say that most browsers exhibit the behavior of treating untagged image data as sRGB.

If you want to see some of the ways browsers do act in the real world, point a few at G. Ballard’s Web Browser Color Management Tutorial. Maybe that can put into visual terms what takes so many words to say.

By stripping the profile, Photoshelter is trying to tell the browser to draw in the sRGB colorspace. In fact, they are telling most browsers nothing. Windows Vista is the only place where this works out well. In all other cases, the browsers just draw the image into the display’s color space. This means an area of pure red will be drawn as red as the display can draw it. Likewise for every other color. No color management math will be applied to the equation, even with browsers that know how to apply that math when given the profile.

The reason the convert-to-sRGB-with-no-tagged-profile method works at all well is that the native color space of consumer monitors usually aren’t so far away from sRGB as to make the issue too noticeable. It’s noticeable a bit on many monitors, but it isn’t too terribly bad. The problem comes in on displays that do differ considerably from sRGB. There aren’t a lot of users of wide gamut displays yet, but the bulk of these new displays are being used precisely by those that care the most about color.

If you do what Photoshelter is doing—convert an image into sRGB and fail to tag it with a profile—then you choose mediocrity in most circumstances, even when displayed on a browser that is color managed. On monitors that are close to sRGB, this leads to the same sorta almost ok presentation that Photoshelter intends. On better monitors, well, it leads to exactly the results that you see in the example illustration in the original post.

In any case, there should be zero impact from including the profile in the images. None. Zip. Nada. By including the profile, the images will look their best on browsers that support color management, and will degrade as best as we know how on browsers that don’t. Really, what’s not to like?

Update 2009/06/10

After trading a few more emails back and forth with PhotoShelter, it’s clear that they know the tradeoffs they have made with their implementation decisions. They’re happy with those decisions and really, who am I to argue? I can file a bug report, but if it’s not classified as a bug, then that’s that.

This does create a problem for me as color management of content is critical in my book. I’ll have to evaluate how this stacks up with the rest of the feature set that PhotoShelter provides, along with other alternatives that do preserve profiles.