I nearly wrote this piece over a year ago when I noticed that a particular image I had uploaded to my site had very wrong skintones. I kept quiet in the end because I am well aware that 99.9% of colour management issues are user error or bad profiles, but since bad profiles are not the problem here because sRGB is a standard, that left only me. I've been working with colour management for about 12 years, and think I know what I'm doing, and it would be downright embarrassing to find I had made a stupid mistake somewhere. However I've checked and double checked and quintuple checked and still don't see anything wrong with my workflow. From camera to print, it works with fine accuracy. I still don't know what is going on here, but the recent thread 'sRGB differences?' on ProDig looked very much as if I am not alone with this puzzle. So time to come out of the closet...
My original file was in Adobe RGB and I had done the usual profile conversion to sRGB for web use and saved it untagged. It looked fine when opened on my profiled system in Photoshop as sRGB, but terrible via a web browser on the same machine and every other I tried. Below is the sRGB version that sparked this inquiry, which I have little doubt will portray this lady rapper in a repulsive shade of maroon to you as well.
Baby Chan in sRGB with no profile
This worried me a lot because screen accuracy is fundamental. Sure, on the web monitors will vary considerably, but I know the screens I have access to and not even the unprofiled ones are this bad. So I looked more closely at some other sRGB files I had online. Some appeared as OK as you can expect in a non-colour-managed environment, but others had some of the same hues and wrongness. This particular image just seemed to be one that showed up the problem more than most. Most liikely something was badly wrong with my profile setup, and if that was the case, had I been sending off-colour images to clients? For how long?
First thing I did was to check my PS settings and then recalibrate the monitor and use the Spyder to create a new profile for it in OptiCal. It didn't make the slightest difference.
Eyeball checking of known good reference images showed nothing wrong in Photoshop. They looked right, they printed right, it was only when I saved as sRGB things went awry. I checked the Baby Chan image in some apps that don't understand colour management, like Irfanview, and still she was maroon, either on the same profiled screen as PS or on other systems with and without profiled screens. I tried changing my working space to sRGB from Adobe98, it made no difference. What on earth was going on? sRGB in PS looked correct and completely different to sRGB anywhere else.
Then I discovered something very odd. As you'd expect if I copied an image from PS and pasted it as a new sRGB image in PS, it was the same, the colour was fine. But if I pasted instead into a non-CM aware application like Irfanview it was wrong, the maroon skin was back. Yet both are supposed to be sRGB - which PS had been explicitly told, and Windows assumes for untagged files in Irfanview and everywhere else. The RGB values could not be changed by copy & paste, so whatever was going on must be at some arcane CM level.
And then I found that if I opened the Irfanview version into PS 'as sRGB' then it was identical to to the PS one and just fine.
Just in case you're getting confused here, let me summarise the problem : sRGB looks different in Photoshop than it does outside Photoshop. Even on the same system with the same profiled screen.
How? Windows uses sRGB as the assumed and default colourspace for images without tags, and monitor profiling applies not only in Photoshop but system wide. The same sRGB image that looks fine in PS looks different and wrong outside PS. This is nuts! How then can we hope to put images on websites that look anything like the version we see in Photoshop. Even allowing for the obvious variables that we can't control, like monitor calibration across unknown systems, even on the same system -with a profiled monitor, a file in sRGB looks considerably different!
So I thought about that. The 'wrong' sRGB I was seeing in Irfanview and web browsers was pretty much how my monitor would display it without any monitor profile. It's a 19" Sony G420 and has always run rather red in darker tones. In fact it's that blue and green are slightly weak. Yet the correction curve is applied at system boot - you can see it kick in and the display turn neutral - so even Irfanview and browsers on that PC should display corrected colour.
That meant something unexpected was happening within PS itself, in the process of converting to sRGB. It was as if PS was subtractting the monitor profile effect from the image and skewing the RGB values. Surely it shouldn't do that? I can see why it might for its own sake, because it will apply the correction to displaying the file next time it is opened. But if that's what is happening, sRGB can't possibly appear correct in other non-CM applications even though it should where the monitor displays sRGB either natively or through application of a corrective profile.
So then I tried converting to monitor space instead of sRGB, and saving the image without a tag. And this is what I got:-
Baby Chan in monitor space with no profile
And the disturbing thing is that in a web browser or non-CM-aware Windows application this version is close to being identical to what I see in Photoshop.
However if I open it as sRGB in Photoshop, it's wrong
This has probably all confused you as much as it has me, so here's a screengrab showing the various flavours
Baby Chan composite
- Is in sRGB space saved out of Photoshop with no embedded profile, displayed in Irfanview - the first large image displayed in this blog. This is the correct method yet clearly the result is wrong. It was how this file looked that opened this can of worms.
- Is the same file used in 1. but displayed in Photoshop. Here it looks identical to the original in Adobe 1998 RGB and the colour is as good as I could get from this image, which was shot in rather awkward mixed ldaylight and flourescent.
- Is in monitor space saved out of Photoshop with no embedded profile, displayed in Irfanview - the second large image displayed in this blog. This looks pretty muchi identical to 2 and appears to be the only route whereby I can get close to what I see in PS for display in a web browser.
- Is the same file as 3 but opened into Photoshop which was told to assign sRGB to the untagged file. Clearly it's wrong, with a double-profile-ish overcorrection.
(and yes, to get the above composite image to display approximately as it does in PS I had to convert it to monitor space).
Note that it's only the skintones that are really affected, the neutrals in the image stay fairly constant and clean. This points to profiling issues rather than simple gamma or hue errors. My screen is natively well aligned in the top-half of the luminance range and the profile does little there. It's only the bottom half where blue and green gamma diverge from the target curve (red is bang on) and correction by the profile kicks in.
What's more, if I 'save for web' in Photoshop (which normally I do not use because it strips metadata), here is what I get in the the preview window.

A screen grab of Photoshop with the 'save for web' preview in the foreground
What is going on here? All I can be sure about is that Photoshop does not appear to do what I thought it did with respect to the monitor profile. I believed it mapped the display of working space RGB values so that amended values were sent to the graphics card but the working space values themselves remained unchanged.
As far as I can see, either this is not the case and PS actually adjusts working space values in order to achieve correct display, or the OS handles similar adjustments very differently and its idea of sRGB->monitor space is considerably different from Photoshop's adjustments.
Either way, here at least, with a monitor that natively diverges significantly from sRGB (ie, profiling makes a significant improvement), the practical problem is how to create images that will look in a browser as close as possible to how I see them in Photoshop. Saving them in sRGB tagged or not usually works acceptably, but with this image in particular is completely unsatisfactory. Converting and saving to monitor space, untagged, works far better.
I would welcome second opinions, especially from anyone else who finds puzzling anomalies is the browser display of specific images. Please pick an image that presents poor colour and/or gamma errors in sRGB and try this:
- Convert your image to your custom monitor profile
- Save the image but without an embedded profile
- Open it in a web browser or other application that does not understand ICC profiles and see if the anomalies are reduced
I suspect people with monitors that are natively close to sRGB will see this issue far less or not at all. But let me know, please.
To make this issue even more frustrating, it does NOT affect most images significantly. Most are best converted to sRGB, not monitor space. This particular Baby Chan pic is far the most extreme example of bad colour that I've come across. The general case is not so clear cut, and converting to monitor space instead of sRGB is no panacea : it can make things worse rather than better. So I would only suggest trying this where you have a particular problem image.
For those of you who know the PDI target, here are alternate versions by each method. Neither is quite right.

PDI Target-converted to sRGB but untagged

PDI Target-converted to monitor space but untagged
On my profiled screens the monitor space version looks rather closer to how the original refence file appears in Photoshop.
Thanks for confirming that you encounter similar effects. Does 'converting-to' your monitor profile help for these problem images, as it does for me?
I don't believe the monitor profiling software is implicated, I am using PhotoCal with Spyder2. I think Photoshop just doesn't do what we've been told it does, and I rather suspect it's a legacy from the early days of PS4, when the monitor space was the working space. Or something... I have mentioned this topic on the Pro-dig list and none of the PS/colour management gurus had anything to say.
Regards, Tony Sleep