I think being precise is key, so as @jack.holm stated earlier, we shouldn’t refer to displays with a max luminance of anything other than 80 nits in an average surround as sRGB
So we should remove the sRGB ODT then?
2 Likes
I’d be fine with renaming for clarity
• Most of the sRGB encoded content had been produced on pure gamma displays, especially in the earlier years.
I feel like most sRGB encoded content has been produced in an ICC color managed environment which has produced an end-to-end system gamma of 1.0 like you mentioned above. sRGB encoding/decoding to PCS (Profile Connection Space) to Display Color Space (determined by an ICC profile)
If we say “most”, we’d be suggesting the vast majority of installations?
In that case, the statement above is false.
Defaults shipped with Windows and Apple indeed abide 100% to the letter of the IEC specification. Specifically, given that the default encodings stipulate the two part transfer function on the display side, including in default factory shipped characterizations on Apple devices last I looked, this leads to:
- Encoding state two part OETF.
- ICC / ColorSync checks EOTF description, which is incorrectly identified as the two part, and leaves the encoding “as is”.
- The actual EOTF, being a pure 2.2 exponent, is applied to the code values.
That means I believe, by default, all installations will conform to the standard.
Sadly it appears not to be that simple.
I just measured the “Liquid Retina XDR Display” of my 14" M2 MacBook Pro in a couple of the out-of-the-box preset profiles.
Using the default Apple XDR Display (P3-1600 nits) profile, the EOTF is indeed a close match to a pure 2.2 power curve for an Apple Display P3 tagged buffer.
However when set to the HDR Video (P3-ST 2084) profile, it appears that an Apple Display P3 tagged buffer is converted to ST.2084 using the piecewise sRGB curve.
So the HDR “reference mode” acts like a PQ display emulating the piecewise sRGB EOTF, but in “normal” mode it matches the behaviour of older Apple displays, where an image with an sRGB profile has its pixel values left “as is” and sent to a display with a pure 2.2 exponent EOTF.
MBP14_XDR_Display_plots.pdf (38.9 KB)
1 Like
Nifty comparison!
I am not sure what other option is feasible given it is a totally different encoding specification?
I don’t think much of this matters; our visual cognition systems appear to have no agency to identify discrete time magnitudes. On a practical level, it becomes mostly an exercise in number fornicating, which I suppose is popular from what I’ve seen.
The only reason it holds a degree of value to discuss is broadly what Daniele has pointed out; it is ahistorical to debate what is outlined at several places within the specification, rather rigidly, as well as logically sound.
It is also worth considering that the explicit management chain, such as is present in the ICC protocol principles, has never addressed the notion of picture quality constancy beyond that of vendor supplied secret sauce “Perceptual” and “Saturation” “rendering” intents, and neither of those address surrounding field articulation. In fact, spatiotemporal field articulation of the surrounding environment remains solely a concern of an implicit management chain.
Remove or rename?
The name is purposely ODT.Academy.sRGB_100nits_dim.ctl and not ODT.Academy.sRGB.ctl to denote that it is not sRGB as per-the-standard and the description is rather clear about it:
// <ACEStransformID>urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_100nits_dim.a1.0.3</ACEStransformID>
// <ACESuserName>ACES 1.0 Output - sRGB</ACESuserName>
//
// Output Device Transform - RGB computer monitor
//
//
// Summary :
// This transform is intended for mapping OCES onto a desktop computer monitor
// typical of those used in motion picture visual effects production. These
// monitors may occasionally be referred to as "sRGB" displays, however, the
// monitor for which this transform is designed does not exactly match the
// specifications in IEC 61966-2-1:1999.
//
// The assumed observer adapted white is D65, and the viewing environment is
// that of a dim surround.
//
// The monitor specified is intended to be more typical of those found in
// visual effects production.
//
// Device Primaries :
// Primaries are those specified in Rec. ITU-R BT.709
// CIE 1931 chromaticities: x y Y
// Red: 0.64 0.33
// Green: 0.3 0.6
// Blue: 0.15 0.06
// White: 0.3127 0.329 100 cd/m^2
//
// Display EOTF :
// The reference electro-optical transfer function specified in
// IEC 61966-2-1:1999.
// Note: This EOTF is *NOT* gamma 2.2
//
// Signal Range:
// This transform outputs full range code values.
//
// Assumed observer adapted white point:
// CIE 1931 chromaticities: x y
// 0.3127 0.329
//
// Viewing Environment:
// This ODT has a compensation for viewing environment variables more typical
// of those associated with video mastering.
//
I just noted that the ACEStransformID was kept as RGB: urn:ampas:aces:transformId:v1.5:ODT.Academy.RGBmonitor_100nits_dim.a1.0.3
Cheers,
Thomas
Actually, we do. A lot. Display swapchains are quantized to 8 bits in 95% of the cases. You can request a 10:10:10:2 or a 16:16:16:16 swapchain but the OS is free to return a 8:8:8:8 display surface and pretend. Textures in real-time rendering use compression formats with 5:6:5 bit precision. Shaders work in full float because of reasons but the extra precision is only for the duration of the calculation since moreoften than not render targets are created in 8:8:8:8 precision because 16:16:16:16 takes twice the amount of cycles to write to. And nobody in the real-time rendering community does 32:32:32:32 because of the memory and bandwidth cost.
Now that this is settled, I will also add extra context about why game developers care about nothing else than the following three configurations : sRGB, PQ, linear gamma 1.0. Among all the color spaces listed in Microsoft documentation, those are the only valid values that you can pass to a program and get the API to return success. The documentation is quite unequivocal about the fact that DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 means sRGB not 2.2.
Full documentation here for programmers :
As a consequence, when implementing ACES, we remove everything that is not those and, in the case of ZCAM DRT, I also added sRGB.
Hope that helps,
Jean-Michel
It is clear to us all what sRGB encoding means. It is also clear why Apple and Microsoft specify the compound function in the encoding facing side of their profiles.
What seems not clear to all is that the actual display in fact is 2.2 Gamma according to sRGB.
The words reference electro-optical do not appear in the sRGB ISO standard. The above is just made up. It is clearly stated a pure 2.2 Gamma as display characteristics.
This is another example of misleading second-hand source posting.
3 Likes
Yes, you are right, only the wording transfer function is used, for the display:
and also for the Encoding Characteristics section which starts with the decoding function transfer function relationship:
The fact that display characteristics/charaterisation and transfer function are interchangeably used does only serve ambiguity here, even more so when the authors and secretary states that the EOTF is the piece-wise function, then you end up with the ODT description quoted above.
For good reasons no?
An sRGB implementation by the books you can find in the ColorLCD.icc profile shipped with every Apple Computer:
The encoding side is piecewise:
The Display characteristics is pure power law 2.2:
If we would acknowledge that, we could pivot the discussion to best practices and how we deal with this mismatch as an industry.
2 Likes
It’s easy to make an output transform for whatever combination of display white point and EOTF you might be using, the ACES 2.0 output transforms will make it even easier.
Surely what that describes is Apple’s interpretation of the intent of the sRGB standard. The word “sRGB” does not appear anywhere in that profile. I realise of course that the profile I am looking at is on my MacBook Pro, so would be Apple Display P3 based, not sRGB.
It does, nonetheless, give helpful clarity on the behaviour of an Apple display when that profile is loaded - an image buffer tagged as sRGB gets a colorimetric conversion to P3-D65 applied, with the transfer function unaltered before sending to the display.
The behaviour discrepancy between Display P3 and ST.2084 that I describe above is a separate issue.
2 Likes
I’m re-reading that post and, while I haven’t seen for myself how Apple devices behave, it makes me think of how Windows handles SDR applications in HDR mode. What it does is assume that they are outputting sRGB so it removes the piecewise encoding, convert from 709 colorspace to 2020 colorspace then apply PQ encoding limited to the max capability of the display which it fetches from the EDID of the monitor.
The secretary, who was not part of the design of the documentation, nor listed in the authors, or acknowledgements. I believe Mr. Holm’s participation was at the IEC level, but the specification made the rounds to other standards committees prior.
The “authors” is questionable here. Perhaps other people have spoken with an author? Not that it would matter, at all, as the standard remains the standard, and as such, we ought to be following the outlined approach.
None of the authors have publicly stated anything to contradict the standard.
Side note on this:
If the industry made it (more) clear that the intended EOTF of the sRGB standard is as written in the standard, the vast majority of displays would be congruent with the (revised and even more clear) standard overnight.
If on the other hand, a two part EOTF were ratified, the vast majority of displays would be out of specification overnight.
1 Like
I don’t disagree but what is industry here and who is revising/amending the standard? It is ultimately the crux of the problem.
I don’t see much issue here at all.
Most implementations follow what is outlined in the specification. It would seem to place the onus on folks who utter the term “sRGB” to do their due diligence and stick to it, or at least provide sufficient explanation where deviating.
Seems to me that if someone is confused at reading the exponent, and they believe it could be clarified, then the direct line is to approach the IEC with a suggested amendment to further clarify the reference EOTF as being the 2.2?
I’m not sure how, as it is literally written in the specification, including a formula that describes the encoding code values with a prime, routed through a pure 2.2 exponent. Perhaps those who are confused might want to take that up with the IEC, and formulate what is confusing to them?
I think it needs to be clarified, people read the 2.2 exponent but tend to miss some part of the story:
Let’s read the Reference Conditions, the standard says that both the input and output characteristic follow 2.2, which is an exponent:
Reading the definition, we confirm that input is the input signal:
Should we stop reading here, the EOTF and its inverse are using a pure exponent.
At this point, we can assume that V'_{sRGB} is some linear signal raised at the \cfrac{1}{2.2} exponent.
Then the standard gives a piece-wise function for encoding, that closely fits a simple power function with an exponent of 2.2 and goes to providing its inverse:
Nowhere it is stated that the piece-wise inverse should be used for the output characteristic but nowhere it is stated that it should not be either! The standard took great care at providing an approximation and its inverse for the 2.2 exponent so why would not it be used all the way since the approximation has been deemed close enough and thus compatible? The key point is that both normalised input (signal) and output (luminance) characteristics are defined as pure 2.2 exponent.
I could see 4 potential valid implementations, the transfer functions for input signal and output luminance being:
- \cfrac{1}{2.2} \rightarrow 2.2
- PieceWise \rightarrow PieceWise^{-1}
- PieceWise \rightarrow 2.2
- \cfrac{1}{2.2} \rightarrow PieceWise^{-1}
Holm, Motta et al. said that 2 should be used.
I had planned to contact IEC and will do when back at home in a few weeks. probably using something like what I wrote above.
Cheers,
Thomas
2 Likes
Doesn’t that say “Display”? It states “input / output” because that’s how displays work, for input and output.
I am shocked at how one must bend themselves into knots to misread that line. Why wouldn’t v'_sRGB be written as simply (1.0 / 2.2)? 
Can we cite where Motta, or any of the authors, have stated this anywhere, including CIE 122? If we are taking hearsay, what is to say that someone else hasn’t emailed folks and received a reply?
Again, however, making this statement still would not matter, as the specification is written already, and states that the display is 2.2.
Even the most charitable reading of anything but the 2.2 EOTF would render hundreds of millions of displays non-compliant overnight.