What Color Space for web?

[Dave Gurtcheff]

Not sure where to post this: I use Prophoto RGB as my color space when working on images and printing them. When I down size them and convert to JPGs for web use, I sometimes leave the images as Prophoto RGB and sometimes I convert to sRGB color space. Lately I have been leaving the images as Prophoto, but when posted  on several photo  forums, and on my own web site, I note the images are not as color saturated as they appear on my color managed PC at home. Any advice what space to use for web JPGs? Any help much appreciated.
Thanks
Dave in NJ
www.modernpictorials.com

[Slobodan Blagojevic]

sRGB

[digitaldog]

You have to supply sRGB for web use since so many people out there don't have color managed systems.

[bjanes]

Not sure where to post this: I use Prophoto RGB as my color space when working on images and printing them. When I down size them and convert to JPGs for web use, I sometimes leave the images as Prophoto RGB and sometimes I convert to sRGB color space. Lately I have been leaving the images as Prophoto, but when posted  on several photo  forums, and on my own web site, I note the images are not as color saturated as they appear on my color managed PC at home. Any advice what space to use for web JPGs? Any help much appreciated.
Thanks
Dave in NJ
www.modernpictorials.com

sRGB does seem to be the default and this if often assumed in unmanaged workflow. By now most of the major browsers do have color management, at least for Ver 2 profiles and can display the images if they are properly tagged with the profile. One can check the status of their browser here. Microsoft Internet Explorer was formerly lagging in color management, but the new Edge browser with Windows 10 displays all the test images properly.

I recently discovered that my hosting site, Smugmug, automatically converted images that I uploaded in ProPhotoRGB to sRGB. Perhaps they don't want images on their site to look bad and they also offer a printing service which is sRGB based. However, I think they should offer users a choice and not convert behind one's back.

Regards,

Bill

[ErikKaffehr]

Hi,

I agree with Slobodan and "The Digital Dog". I would just add that ProPhoto RGB may need a little bit more than a 8-bit RGB. Using a 16 bit workspace with Prophoto RGB is great, but an eight bit representation may be not large enough.

Another point may be that if your images doesn't have colours that are outside sRGB it will have zero benefit to use a wider gamut (like ProPhoto RGB).

Best regards
Erik

[Dave Gurtcheff]

Thank you all.  Strange, though, the images I post on Facebook look fine; perhaps they automatically convert my images to sRGB. I will use sRGB from now on for my web images.
Thanks again
Dave

[MarkM]

Thank you all.  Strange, though, the images I post on Facebook look fine; perhaps they automatically convert my images to sRGB. I will use sRGB from now on for my web images.
Thanks again
Dave

Facebook does convert colors to a version of sRGB. There's an old post here about what they were (and maybe still are) doing: https://www.facebook.com/note.php?note_id=10150630639853920

[bjanes]

Hi,

I agree with Slobodan and "The Digital Dog". I would just add that ProPhoto RGB may need a little bit more than a 8-bit RGB. Using a 16 bit workspace with Prophoto RGB is great, but an eight bit representation may be not large enough.

Another point may be that if your images doesn't have colours that are outside sRGB it will have zero benefit to use a wider gamut (like ProPhoto RGB).

On reflection, I agree that for images to be posted on the web and viewed on a monitor, there is no need to use ProPhotoRGB since no current monitor can display that gamut. However, AdobeRGB can be displayed on wide gamut monitors even though most do not have such a monitor. With color management I would think that an AdobeRGB image would look fine on an sRGB monitor. Although a 16 bit workflow is desirable for editing with ProPhotoRGB, my experience is that most of the time the final image looks good in 8 bit.

The ProPhoto images that I tried to post were related to a thread where perceptual rendering from ProPhoto to sRGB via a Ver 4 profile was being discussed and I wanted to provide an illustration.

[Simon Garrett]

By now most of the major browsers do have color management, at least for Ver 2 profiles and can display the images if they are properly tagged with the profile. One can check the status of their browser here. Microsoft Internet Explorer was formerly lagging in color management, but the new Edge browser with Windows 10 displays all the test images properly.

That's not quite right, I'm afraid. 

Neither IE nor Edge are properly colour managed.  Neither uses the monitor profile (so won't display correctly especially on a wide-gamut monitor), and they don't even appear to use the image profile properly. 

The link you gave to http://www.color.org/version4html.xalter tests only whether the browser uses the image profile (not the monitor profile), but even that doesn't seem to be giving the whole answer.  For example, see these two links:

Fully saturated colour blobs in sRGB
Fully saturated colour blobs in ProPhoto RGB

On a normal gamut monitor those will look the same.  On a wide-gamut monitor they should look very different, which they do in Firefox, Safari and Chrome.  But they look the same on IE and Edge, which don't appear to be using the  profile correctly. 

Edited to add: what I think happens with IE and Edge is that they colour-manage images with profiles, but then convert (or even assign) to sRGB.  They ignore the monitor profile.  Either way, they are completely useless at rendering colours except on monitors with a gamut and Tone Response Curve very close to sRGB.  It's the way IE has behaved for many years.  I can think of no logical or sensible reason why Microsoft should do this. 

For colour managed browsers, use Firefox, Safari or Chrome.  If you have a wide-gamut monitor, only Firefox will display normal web pages well, as it has an option to colour manage graphics not containing embedded profiles.  (The other two will over-saturate images and graphics that don't contain profiles.)

[torger]

"Proper color management" on the web as I see it is that all graphics that has no ICC profile associated is displayed as sRGB, and all other graphics according to the provided ICC profile. This is how it works on the Mac.

On Windows and Linux it's more complicated. Using Firefox web browser and setting gfx.color_management.mode to 1 you get the desired behavior (and that is how I run it), unfortunately this is not default, the default is instead to only color manage the graphics which has ICC profile, all other is stretched to the maximum gamut. I think this is also how Chrome works currently, not sure about IE/Edge, but it can easily be checked.

The poor color management on key Windows applications is holding back the progress in using wide gamut screens unfortunately. On the Mac you can use a wide gamut screen and not knowing anything about color management, while on Windows you need to know at least something.

Windows as an operating system has good support for color management, but of course you need to calibrate your screen and install a profile for it for it to work. And then it will only work for the applications that choose to use color management and do it right. On OSX if an application does nothing it becomes sRGB automatically, which makes it easier for the we-don't-care-developers. The reason Windows is like it is I think is historical and something to do with the APIs, you're closer "to the metal" in Windows, it's good when you want to do high performance stuff like games and advanced graphics, but less good for less advanced applications as they don't get color management for free.

Until Windows is as easy as the Mac concerning color management and wide gamut screens is the new standard unlike the specialist tools they are today you should publish sRGB to the web. It's always good to embed an ICC profile too.

[bjanes]

That's not quite right, I'm afraid. 

Neither IE nor Edge are properly colour managed.  Neither uses the monitor profile (so won't display correctly especially on a wide-gamut monitor), and they don't even appear to use the image profile properly. 

Fully saturated colour blobs in sRGB
Fully saturated colour blobs in ProPhoto RGB

On a normal gamut monitor those will look the same.  On a wide-gamut monitor they should look very different, which they do in Firefox, Safari and Chrome.  But they look the same on IE and Edge, which don't appear to be using the  profile correctly. 

Edited to add: what I think happens with IE and Edge is that they colour-manage images with profiles, but then convert (or even assign) to sRGB.  They ignore the monitor profile.  Either way, they are completely useless at rendering colours except on monitors with a gamut and Tone Response Curve very close to sRGB.  It's the way IE has behaved for many years.  I can think of no logical or sensible reason why Microsoft should do this. 

For colour managed browsers, use Firefox, Safari or Chrome.  If you have a wide-gamut monitor, only Firefox will display normal web pages well, as it has an option to colour manage graphics not containing embedded profiles.  (The other two will over-saturate images and graphics that don't contain profiles.)

Simon,

Thanks for the correction. I have a wide gamut monitor (NEC PA2411 calibrated with Spectraview). With both Chrome and Firefox, I see a clear difference between your two images. With Edge, the sRGB displays with the same saturation as does  the ProPhoto image. I presume that is the expected behavior with Edge: the sRGB numbers will be closer to 255 because of the smaller gamut and if these numbers are sent directly to the wide gamut monitor, the saturation will increase. Right?

Regards,

Bill

[AlterEgo]

And then it will only work for the applications that choose to use color management and do it right.

and then you might have different CMMs to use too...

[digitaldog]

and then you might have different CMMs to use too...

Unless there's a bug in the CMM, the differences should be visually indistinguishable unless BPC is or isn't supported in each.

[AlterEgo]

unless BPC is or isn't supported in each.

that's the point

[digitaldog]

that's the point

Well the profile may not have any 'need' for BPC (nor should it), so it does nothing, both CMM's would produce visually identical results.

[AlterEgo]

Well the profile may not have any 'need' for BPC (nor should it), so it does nothing, both CMM's would produce visually identical results.

the OP posts images for others to see... hence we can't assume anything about profiles on the other side, no ? it is not like when you design your own environment to view your own images yourself

[digitaldog]

the OP posts images for others to see... hence we can't assume anything about profiles on the other side, no ? it is not like when you design your own environment to view your own images yourself

NO, we can't assume anything other's see, they may or may not be fully color managed. But the CMM isn't the issue. Unless there's a bug, the differences should be invisible.


Here's ACE vs. Apple CMM, one patch of 990 (iStar target) has a dE of 1.1, then it drops down to zero rather quickly!

[AlterEgo]

NO, we can't assume anything other's see, they may or may not be fully color managed. But the CMM isn't the issue.

well - are you saying that 2 people with different monitor profiles (they can be matrix/gamma or LUTs - we don't know - can be anything) using 2 color-managed apps but coded to use different CMMs (adobe, MS, lcms of various versions or whatever) w/o bugs will never see anything different in shadows on their monitors ?

[digitaldog]

well - are you saying that 2 people with different monitor profiles (they can be matrix/gamma or LUTs - we don't know - can be anything) using 2 color-managed apps but coded to use different CMMs (adobe, MS, lcms of various versions or whatever) w/o bugs will never see anything different in shadows on their monitors ?

What I thought I was pointing out rather clearly is the CMM isn't the issue. You raised CMM, I'm simply pointing out that I've yet to see one produce large colorimetric difference values from another unless it's rather old and buggy. So the CMM isn't a factor. Nor should it be. Simple as that.

[AlterEgo]

What I thought I was pointing out rather clearly is the CMM isn't the issue. You raised CMM, I'm simply pointing out that I've yet to see one produce large colorimetric difference values from another unless it's rather old and buggy. So the CMM isn't a factor. Simple as that.

I am talking about what one (some internet user) can see on his/her monitor in deep shadows (blocked or not and if not blocked then how different rendered visually) depending in how the monitor profile was created x colormanaged apps using various CMMs (non buggy - old is __not__ buggy).