What Color Space for web?

[digitaldog]

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).

I know you are. And that has zero to do with CMMs. Unless you can provide one that produces vastly, vastly larger dE values then what I provided. The CMM should play no role here!
A visual mismatch is obviously possible. Just get two users to calibrate to differing aim points using the same display!


Your idea that it's somehow caused by the CMM needs some serious proof of concept. Again, simple as that.

[Simon Garrett]

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

Right.

Each blob has RGB values of either 0 or 255, depending on the colour.  For exmaple the red blob has RGB values of 255,0,0 in both files.  The only differerence between the two files is the colour space, and the corresponding profile that's embedded.  The red value 255,0,0 is a much more intense red in ProPhoto RGB than in sRGB.  A colour managed browser should map that to the equivalent colour in the monitor's colour space, or the nearest equivalent if the red is outside the monitor's gamut (which it almost certainly will be with ProPhoto RGB colours). 

As all the colour blobs in the ProPhoto RGB image are outside the gamut of sRGB, then a normal gamut monitor (roughly sRGB normally) will show the colours as the nearest within sRGB, which will be almost the same as for the sRGB image colour blobs, which are within sRGB.  So the images will look the same on a normal (narrow) gamut monitor, but the ProPhoto RGB image should look more saturated on a wide-gamut monitor. 

Edge and IE appear not to use the monitor profile, but convert everything to sRGB, and send the sRGB image data to the monitor, ignoring the monitor's profile.  That means that both sets of colour blobs will look the same (as they're converted to sRGB) on any monitor.  But as Edge and IE don't use the monitor profile, the colours will look much more saturated on a wide-gamut monitor. 

I can sort of see a reason why Microsoft might do that.  For users that don't use colour management (monitors aren't profiled) and have normal gamut monitors with a gamut very close to sRGB, then Edge and IE will display colours roughly correctly, whatever the colour space of the image.  But that behaviour means that colours are absolutely 100% guaranteed to be wrong on any monitor whose colour space is not identical to sRGB.  On wide-gamut monitors, Edge and IE are completely hopeless. 

Given that colour management is built-in to Edge and IE, why not have an option to use the monitor profile, instead of converting to sRGB?  It would be a tiny amount of code to do this. 

[digitaldog]

Given that colour management is built-in to Edge and IE, why not have an option to use the monitor profile, instead of converting to sRGB?  It would be a tiny amount of code to do this.

Safari used to use the display profile as an assumption for the untagged RGB data. But that's not useful since you're the only person with that display profile.
The data in question is either in an tagged RGB color space or it's not and the software assumes something. Seems far more reasonable to assume sRGB. IF it looks OK on your display, of course using your display profile but happens to be in sRGB, great. The likelihood that some untagged RGB document will look good previewed assuming it's in your display profile will only work on one system and 'fail' on all others. That's not the case when the software assumes sRGB. And if indeed the user isn't color managed and happens to be real, real lucky and their display does behave closely to sRGB, the image should look OK as well.

[Simon Garrett]

Safari used to use the display profile as an assumption for the untagged RGB data. But that's not useful since you're the only person with that display profile.
The data in question is either in an tagged RGB color space or it's not and the software assumes something. Seems far more reasonable to assume sRGB. IF it looks OK on your display, of course using your display profile but happens to be in sRGB, great. The likelihood that some untagged RGB document will look good previewed assuming it's in your display profile will only work on one system and 'fail' on all others. That's not the case when the software assumes sRGB. And if indeed the user isn't color managed and happens to be real, real lucky and their display does behave closely to sRGB, the image should look OK as well.

I quite agree with that.  Very sensible to assume that the image is sRGB if not tagged. 

What IE and Edge do is assume that the monitor has a colour space of sRGB, whether or not there is a monitor profile.  Again, it's a reasonable assumption that the monitor has a gamut close to sRGB if there's no monitor profile, but why ignore the monitor profile when there is one? 

I can see no way of making Edge or IE use the monitor's profile.  They ignore the monitor profile, and send sRGB data to the monitor.  To me, that seems bonkers.  But perhaps I've missed something. 

[digitaldog]

What IE and Edge do is assume that the monitor has a colour space of sRGB, whether or not there is a monitor profile.  Again, it's a reasonable assumption that the monitor has a gamut close to sRGB if there's no monitor profile, but why ignore the monitor profile when there is one? 

I can see no way of making Edge or IE use the monitor's profile.  They ignore the monitor profile, and send sRGB data to the monitor.  To me, that seems bonkers. 

What you report IS bonkers if that's what they are doing. If so, they should not be considered color managed. What you describes makes no sense.
A document has numbers that are represented in CMYK, RGB, whatever that are the color space scale of the numbers. The only way that data can preview correctly is with a display profile using Display using Monitor Compensation. Assuming the display profile is sRGB is ridiculous and just wrong. Further, I know of no conditions, at least on a Mac where there is not a display profile (right or wrong).

[Doug Gray]

What you report IS bonkers if that's what they are doing. If so, they should not be considered color managed. What you describes makes no sense.
A document has numbers that are represented in CMYK, RGB, whatever that are the color space scale of the numbers. The only way that data can preview correctly is with a display profile using Display using Monitor Compensation. Assuming the display profile is sRGB is ridiculous and just wrong. Further, I know of no conditions, at least on a Mac where there is not a display profile (right or wrong).

Yep. I can confirm that is exactly what Edge and I11 does. I get around it by switching my CG318 to sRGB for everything except actual color managed apps like Photoshop then I have to remember to switch it back to full gamut the need arises. Makes my eyes hurt.

It's "color managed" so long as you have a monitor that is reasonably close to sRGB. Yuck.

[digitaldog]

Yep. I can confirm that is exactly what Edge and I11 does. I get around it by switching my CG318 to sRGB for everything except actual color managed apps like Photoshop then I have to remember to switch back to full gamut the need arises.

Better still, just trash Edge. These folks don't have a clue about color management of image data IF that's what they do. Sad. We've only had modern ICC color management in mass since 1998 and of course it was around and working correctly years before that milestone (the release of Photoshop 5).

[AlterEgo]

I know you are. And that has zero to do with CMMs. Unless you can provide one that produces vastly, vastly larger dE values then what I provided. The CMM should play no role here!
A visual mismatch is obviously possible. Just get two users to calibrate to differing aim points using the same display!

same display, two different profiles aiming @ the same parameters like temp, etc, but one say matrix+gamma and one LUT - you will have different outcome from different CMMS when dealing with deep shadows... because CMM does use the info from monitor profile, hence they play role in how BPC will be done

[digitaldog]

same display, two different profiles aiming @ the same parameters like temp, etc, but one say matrix+gamma and one LUT - you will have different outcome from different CMMS when dealing with deep shadows... because CMM does use the info from monitor profile, hence they play role in how BPC will be done

You are barking up the wrong tree again. I illustrated the tiny differences in two CMM's. Colorimetrically. Again, for the last time (because you need to hear it reinforced); unless there's a bug in a CMM's, the results should be visually the same. And between ACE and Apple CMM's, as colorimetrically proven above (or below), that's the case.

You have any colorimetric facts at your disposal to prove that the differences here have anything to do with the CMM?

[AlterEgo]

And between ACE and Apple CMM's

you intentionally selecting 2 specific (convenient) cmms to support your point, move to the realm of ACE, MS CMM, LCMS of different versions or older ones 

[digitaldog]

you intentionally selecting 2 specific (convenient) cmms to support your point, move to the realm of ACE, MS CMM, LCMS of different versions or older ones 

Then you can specifically pick any two CMM's that don't. But have not. Telling.
Again, because you don't seem to have an ounce of evidence to support your first post here (and then you might have different CMMs to use too...)
DO YOU have any colorimetric facts at your disposal to prove that the differences here have anything to do with the CMM? Prove it or be ignored, your call.

[Doug Gray]

same display, two different profiles aiming @ the same parameters like temp, etc, but one say matrix+gamma and one LUT - you will have different outcome from different CMMS when dealing with deep shadows... because CMM does use the info from monitor profile, hence they play role in how BPC will be done

Most all the differences when using a matrix v LUT monitor profile are due to:

• The way that out of gamut colors are mapped to the monitor's primaries which is typically not the same as with a matrix profile. The latter is well defined and is simple clipping to bring them in gamut. The former is not.
  
• The inherent inaccuracies of the LUT grid approach. The bigger the grid, the better the match.

CMM variations have smaller impacts.

[digitaldog]

CMM variations have smaller impacts.

The colorimetry with the tests I did, admittedly with two CMM's appear to agree with you. Not that this will help us with AlterEgo. 

[AlterEgo]

Most all the differences when using a matrix v LUT monitor profile are due to:

• The way that out of gamut colors are mapped to the monitor's primaries which is typically not the same as with a matrix profile. The latter is well defined and is simple clipping to bring them in gamut. The former is not.
  
• The inherent inaccuracies of the LUT grid approach. The bigger the grid, the better the match.

CMM variations have smaller impacts.

but they DO... consider the case of JPG with the old good sRGB for example and monitor with v2 matrix+gamma profile... how and if BPC is solely CMM code doing - so you can have differences in what you see when the same image is displayed (deep shadows) by 2 different apps using 2 different cmms

[AlterEgo]

The colorimetry with the tests I did, admittedly with two CMM's appear to agree with you. Not that this will help us with AlterEgo. 

so you agree that there is a difference (because smaller impact != no impact)... 

[digitaldog]

so you agree that there is a difference (because smaller impact != no impact)... 

I absolutely do not agree and have said so too many times already. The difference in my test showed ONE patch of 990 that was just slightly above a dE 2000 of 1. The stinking average dE is 0.02 for dogs sake man! And if you pay attention to the screen grab, you'll see that of the 990 colors tested, we get to a dE of 0.00 real, real fast!
When you're ready to provide a similar test using sound colorimetry, we're all ears. In the meantime, the last thing the OP needs to be concerned with is the CMM. Find one with a big honking bug if you can, you'll do us a service by allowing us to bypass it. At least with ACE and Apple CMM, the differences are visually invisible.

[AlterEgo]

At least with ACE and Apple CMM, the differences are visually invisible.

you just noted yourself that one patch even with those 2 good CMMs you have a case de2000 > 1  ... it does not matter 1 or more than 1 - what matter is that it exists

[Jim Kasson]

Most all the differences when using a matrix v LUT monitor profile are due to:

• The way that out of gamut colors are mapped to the monitor's primaries which is typically not the same as with a matrix profile. The latter is well defined and is simple clipping to bring them in gamut. The former is not.
  
• The inherent inaccuracies of the LUT grid approach. The bigger the grid, the better the match.

The way I think of it is: the finer the grid the better the match.

Bigger is open to different interpretations here, like saying, if you're at f/8, "Go one stop bigger." Is that f/11 or f/5.6?

Jim

[hjulenissen]

As television sets try to sell "UHD" that includes BT.2020 as part of the package
10/12-bit per primary,
increased DR (>20000:1 of physical contrast)
increased color gamut (>90% of P3 color)

I wonder how we will be able (if at all) to use that display for (better than sRGB) still images. JPEG with some metadata? One might hope that this drives higher expections into internet, PC and hand-held devices as well...

http://www.businesswire.com/news/home/20160104006605/en/UHD-Alliance-Defines-Premium-Home-Entertainment-Experience

-h

[digitaldog]

you just noted yourself that one patch even with those 2 good CMMs you have a case de2000 > 1  ... it does not matter 1 or more than 1 - what matter is that it exists

It doesn't matter! We can't see the difference. It's ONE patch of 990 for dogs sake at a mere 1.1! Do you not understand the basics of colorimetry and deltaE? Again, look at the average dE between two CMM's! They are visibility identical. Your original post about CMM's doesn't have a lick colorimetric proof nor make any sense. Prove your point or move on.