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.
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.
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.
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.
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.
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.
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?
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.
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.
This was from Michael Stokes who was an author on the original standard talking about building the sRGB ICC profile.
In Figure 1 (the simplified block diagram of the profile math) it shows “sRGB Monitor space” → “2.2 gamma” then in Figure 4 (the final profile math) it’s RGB → sRGB Transfer Function
While this is not in the specification, I’m wondering how one projects the “2.2 Gamma” to be anything but, again, the “monitor”? How does the flow chart not specifically point out the encoded R’G’B’ between the display EOTF, and outline specifically how to encode the R’G’B’ in the following block?
If we want to speculate wildly, we can offer up two paths:
The authors were trying to create an EOTF that flies in the face of all existing technology at the time to implement a “new” EOTF that would take many decades to implement.
The authors were attempting to sort out a standardized encoding for digital code counts that was an “…attempt to end the “RGB wars” that were devastating several industries in the mid 1980s and much of the 1990s.”
How is it how a display work? Ignoring HDR metadata, a display is typically fully agnostic about the input signal encoding. Then, why is the exponent stated for input?
Reading top down is enough to get there! v'{sRGB} is the input signal so given the Reference Conditions and the 4. point, it is 2.2 unless input was put by mistake Or that it is an approximation that can be replaced by the close fit piece-wise function given in the Encoding Characteristics section.
I emailed Motta about that last year and never got a reply, @Alexander_Forsythe talked to him right after at CIC I think and then:
If some people find the standard unambiguous good on them, some others are finding it ambiguous (I’m certainly one of them) and having disambiguation from the IEC would not hurt.
This is simply false because the piece-wise function is defined as a close fit by the standard itself, so not only it would NOT make the displays non-compliant, they would still be, but most people would probably never notice. Practitioners who care have means to change the calibration to taste and needs, and do it accordingly. It is much easier to change the calibration of a single end-point rather than changing a ton of software and libraries that encode with the piece-wise function to now use a pure exponent.
it’s certainly easy to calibrate an artist’s monitor in a studio, but ultimately we want it to look good on the audience’s consumer monitors at home, which they are definitely not going to calibrate. That’s the whole idea of preserving artistic intent, right?
Hense the “best practice” proposed by @daniele of using pure 2.2 to avoid the crushed toe that you get with an sRGB ODT going to a 2.2 display. After all, no one likes having their toe crushed
This approach was really helpful to me as an artist, and I believe that is also the point @meleshkevich is making in the OP.
Because that’s how all displays work? The relationship between the output emissions and the input must be known.
Where is “can be replaced” listed in the reference image display system characteristics or elsewhere in the specification?
It will be wonderful if and when such disambiguation were available. Until such time, it is probably prudent to stick to the standard itself, and the specific sections. Perhaps in the not-too-distant-future, some (further) clarity, for those whom the document is unclear, will be made available.
Great point. Perhaps there’s a reference image display system characteristic listed somewhere so that we could avoid the “close fit” portion of your statement? Any idea on what the reference image display system characteristic might be?
I’m pretty sure this is false, as most every system follows the current specification as I outlined above. I think that changing everything to be a pure no-operation is probably more challenging.
Add Gamma 2.2 display ODT. Name it “Gamma 2.2 sRGB display”. Ideally make it default, to match most likely the most common computer display EOTF in the world.
Rename current sRGB ODT to something like “sRGB Piecewise”, or “sRGB EOTF sRGB”, or whatever, that would reflect that it’s not about the gamut only, but EOTF. Avoid using “gamma ~2.2”. Never understood what does it mean. Does it mean 2.22 or sRGB?
Rename Rec709 ODT to “Gamma 2.4 Rec709” or “BT.1886”. But the first one better matches the naming scheme where it’s EOTF at first and then the gamut. And I’ve measured dozens of different modern TV’s with a colorimeter and I found just one TV offering 1886 preset (not default one of course). The rest are (something around) pure gamma 2.2 by default and optionally 2.4, usually in Cinema Pro presets or something like that.
It clearly states a mismatch between encoding and EOTF, making it really clear what the EOTF is.
Posts which cherry-pick parts of information to increase confusion or push towards an agenda are the source of the mess with have with sRGB.
Acknowledging a mistake, correcting it and moving on is much more constructive.
The only agenda I have, if any, is to get the standard clarified, I’m certainly happy to be wrong.
The sentence you quoted, even more so with what Motta et al. said, I read it as the explanation that there is a theoretical reference and an effective implementation and that they differ for coding (both encoding and decoding since both formulas are given) purposes.
