An implementation bug in ACM/HDR

[Headcrabed]

The readme says that Windows SDK headers suppose a gamma 2.2 transfer (OUTPUT_WIRE_COLOR_SPACE_G22_P709) but experiments show that assuming an sRGB transfer function gives better average delta-E on verification (this may vary on GPU vendor). This is possibly due to Windows uses piecewise sRGB transfer function for sRGB contents, and this behavior is completely wrong according to sRGB spec.

In IEC 61966-2-1-1999 chapter 4.1 "Reference image display system characteristics", the specification requires the reference display to be calibrated to gamma 2.2 tone curve when directly displaying sRGB signal. So power 2.2 gamma curve should be applied rather than sRGB curve when converting sRGB content to linear scRGB blending space to accurately follow the spec behaivor. And we can see some display problems caused by this issue: https://github.com/dylanraga/win11hdr-srgb-to-gamma2.2-icm

I also created an issue at windows feedback hub, please give me an approve ticket, this might be helpful to get this issue fixed: https://aka.ms/AAw09zz

IEC 61966-2-1-1999.pdf

Some related discussions about this:
https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/30
https://gitlab.freedesktop.org/pq/color-and-hdr/-/issues/12
https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/wayland_qa.md?ref_type=heads#q-should-srgb-content-be-decoded-with-the-piecewise-srgb-transfer-function

Btw, currently KDE Wayland + Linux would do the convert correctly for sRGB contents: https://discuss.kde.org/t/whats-the-transfer-function-for-sdr-content-under-hdr-mode/33259/3?u=stat_headcrabed

[dantmnf]

Also check https://github.com/ledoge/dwm_eotf

[allenwp]

When reading IEC 61966-2-1-1999, it is very clear that sRGB content should be decoded using the piecewise functions rather than simulating the mismatch of the 2.2 power function reference display. I've shared my full thoughts on that matter, based on research of all the related standards documentation and literature, in a blog post.

The difference between 2.2 power function decoding and piecewise function decoding is definitely visible and affects the dark values of an image. I really don't want to dismiss this entirely. But my guess is that a lot of the users that much prefer the look of SDR instead of HDR in Windows are comparing sRGB SDR presented on a TV that is using a 2.4 power function (BT.1886) to decode the signal, which would give a dramatically higher contrast and saturation than sRGB decoded with either 2.2 power function (sRGB reference display) or piecewise function (Windows HDR decoding, as sRGB standard instructs to do).

(Also, thanks for sharing the sRGB standard doc. I had been looking for a PDF of this for a while!)

[Headcrabed]

When reading IEC 61966-2-1-1999, it is very clear that sRGB content should be decoded using the piecewise functions rather than simulating the mismatch of the 2.2 power function reference display. I've shared my full thoughts on that matter, based on research of all the related standards documentation and literature, in a blog post.

The difference between 2.2 power function decoding and piecewise function decoding is definitely visible and affects the dark values of an image. I really don't want to dismiss this entirely. But my guess is that a lot of the users that much prefer the look of SDR instead of HDR in Windows are comparing sRGB SDR presented on a TV that is using a 2.4 power function (BT.1886) to decode the signal, which would give a dramatically higher contrast and saturation than sRGB decoded with either 2.2 power function (sRGB reference display) or piecewise function (Windows HDR decoding, as sRGB standard instructs to do).

(Also, thanks for sharing the sRGB standard doc. I had been looking for a PDF of this for a while!)

@allenwp Thanks for reply. But I still think we have to simulate 2.2 reference display. Most modern monitors are still calibrated to gamma 2.2 for their factory calibration. And windows also assumes monitors are calibrated to 2.2 when ACM is enabled. So changing current HDR/ACM implementation to 2.2 EOTF is the best way to get the most accurate display result.

[Malus-risus]

When reading IEC 61966-2-1-1999, it is very clear that sRGB content should be decoded using the piecewise functions rather than simulating the mismatch of the 2.2 power function reference display. I've shared my full thoughts on that matter, based on research of all the related standards documentation and literature, in a blog post.
The difference between 2.2 power function decoding and piecewise function decoding is definitely visible and affects the dark values of an image. I really don't want to dismiss this entirely. But my guess is that a lot of the users that much prefer the look of SDR instead of HDR in Windows are comparing sRGB SDR presented on a TV that is using a 2.4 power function (BT.1886) to decode the signal, which would give a dramatically higher contrast and saturation than sRGB decoded with either 2.2 power function (sRGB reference display) or piecewise function (Windows HDR decoding, as sRGB standard instructs to do).
(Also, thanks for sharing the sRGB standard doc. I had been looking for a PDF of this for a while!)

@allenwp Thanks for reply. But I still think we have to simulate 2.2 reference display. Most modern monitors are still calibrated to gamma 2.2 for their factory calibration. And windows also assumes monitors are calibrated to 2.2 when ACM is enabled. So changing current HDR/ACM implementation to 2.2 EOTF is the best way to get the most accurate display result.

A large number of monitors use the sRGB EOTF instead of gamma 2.2, and Windows defaults your display device to the sRGB EOTF instead of gamma 2.2 when ACM is enabled.

[sobotka]

Is there a section that outlines the reference display input output characteristic in the specification? Or perhaps a specific reference to the formula?

it is very clear that sRGB content should be decoded using the piecewise functions rather than simulating the mismatch of the 2.2 power function reference display.

The vast majority of displays are indeed a pure 2.2 EOTF, as that's the common hardware baseline. To try and suggest it is "very clear" is ahistorical, and doubly against the outlined function and reference conditions.

The history of sRGB is one riddled with political backroom fighting. The two part encoding function was not even authored by the primary author of the specification, and instead was a byproduct of another company insisting on including their encoding characteristic, due to IP, before being willing to back the specification.

A large number of monitors use the sRGB EOTF instead of gamma 2.2

If by large you mean every single Apple hardware by default uses a pure 2.2, or the vast majority of consumer displays, or otherwise, then yes. We could likely speculate that those displays that have a hardware based interpretation of the non-specification input output characteristic are so proportionately low quantity in normative contexts as to be equivalent to a statistical error.

As someone who actually spent several years trying to discuss this matter with the primary author, the best thing we can do is follow the specification. Look at the specification. Read it carefully. Note what "encoding" and "input output" characteristics are.

In 2025, there's no benefit beyond confusion in using two part functions.

[Headcrabed]

When reading IEC 61966-2-1-1999, it is very clear that sRGB content should be decoded using the piecewise functions rather than simulating the mismatch of the 2.2 power function reference display. I've shared my full thoughts on that matter, based on research of all the related standards documentation and literature, in a blog post.
The difference between 2.2 power function decoding and piecewise function decoding is definitely visible and affects the dark values of an image. I really don't want to dismiss this entirely. But my guess is that a lot of the users that much prefer the look of SDR instead of HDR in Windows are comparing sRGB SDR presented on a TV that is using a 2.4 power function (BT.1886) to decode the signal, which would give a dramatically higher contrast and saturation than sRGB decoded with either 2.2 power function (sRGB reference display) or piecewise function (Windows HDR decoding, as sRGB standard instructs to do).
(Also, thanks for sharing the sRGB standard doc. I had been looking for a PDF of this for a while!)

@allenwp Thanks for reply. But I still think we have to simulate 2.2 reference display. Most modern monitors are still calibrated to gamma 2.2 for their factory calibration. And windows also assumes monitors are calibrated to 2.2 when ACM is enabled. So changing current HDR/ACM implementation to 2.2 EOTF is the best way to get the most accurate display result.

A large number of monitors use the sRGB EOTF instead of gamma 2.2, and Windows defaults your display device to the sRGB EOTF instead of gamma 2.2 when ACM is enabled.

@Malus-risus You can have a look at monitor reviews here and would find most monitors are factory calibrated to power 2.2: https://www.rtings.com/monitor

Windows defaults to power 2.2 EOTF for moniors according to last section here: https://github.com/dantmnf/MHC2/blob/master/README.md

[dantmnf]

Windows defaults to power 2.2 EOTF for moniors according to last section here: https://github.com/dantmnf/MHC2/blob/master/README.md

This is not the case for ACM/HDR. Current implementation always use sRGB piecewise function to process SDR content.

[Malus-risus]

@Malus-risus You can have a look at monitor reviews here and would find most monitors are factory calibrated to power 2.2: https://www.rtings.com/monitor

I am unable to determine whether rtings is data measured while the monitor was in SRGB mode.

[Headcrabed]

@Malus-risus You can have a look at monitor reviews here and would find most monitors are factory calibrated to power 2.2: https://www.rtings.com/monitor

I am unable to determine whether rtings is data measured while the monitor was in SRGB mode.

@Malus-risus When the monitor have sRGB mode and is being used, it would be listed in pre-calibration test info, for example: https://www.rtings.com/monitor/reviews/asus/proart-display-pa279crv

Also Apple’s display p3 monitors are doing the same as sRGB, report EOTF curve in TRC tag as sRGB, while actually calibrated to power 2.2

[Headcrabed]

@allenwp @Malus-risus I found this video: https://www.youtube.com/watch?v=NzhUzeNUBuM

According to the video, piecewise OETF encoding + power 2.2 EOTF monitor is a very old implementation for implicit flare light compensation, which should be done explicitly now. Also their newer version of software sets to power 2.2 EOTF/OETF as default now.

[Headcrabed]

Windows defaults to power 2.2 EOTF for moniors according to last section here: https://github.com/dantmnf/MHC2/blob/master/README.md

This is not the case for ACM/HDR. Current implementation always use sRGB piecewise function to process SDR content.

@dantmnf Does this mean windows always use piecewise OETF for encoding colors that would be send to monitors when ACM/HDR enabled?

[dantmnf]

Does this mean windows always use piecewise OETF for encoding colors that would be send to monitors when ACM/HDR enabled?

Windows uses the piecewise EOTF - matrix - piecewise OETF pipeline in SDR/ACM mode by default, but the OETF can be altered with MHC2 LUT. MHC2Gen uses inverse TRC in the input ICC profile as OETF in the pipeline.

[clshortfuse]

This has been asked by the ACES crew and answered by Jack Holm, the technical secretary for IEC/TA 100/ TA 2 which developed the IEC 61966-2-1 sRGB standard.

from https://community.acescentral.com/t/srgb-piece-wise-eotf-vs-pure-gamma/4024/2

The "preferred" EOTF is not 2.2, but piecewise sRGB. BT.2380 also states the EOTF noted here:

The reasoning behind sRGB was to define a standard. If you look in BT.709-3, there's no standard gamma to be found: https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-3-199802-S!!PDF-E.pdf

If you look at BT.470-6 this was the table:

which had different illuminances and assumed gamma, which was always an approximation of the analog displays. Today the BT.709-6 just says to use BT.1886 which is 2.4 gamma.

Even in 2002, it was still decoded in sRGB under reference viewing conditions:

The idea was to be close enough to 2.2 to be acceptable. Yes, it's extremely ironic that an standard to make things clearer ended up being more confusing. You can also look at the original draft at https://library.imaging.org/admin/apis/public/api/ist/website/downloadArticle/cic/4/1/art00061 and see that, in reality, the idea was to be as close to 2.2 as possible. The majority of displays were basically 2.2 and sRGB was looking to push that as the actual standard and built around that.

But, at the same time the spec discusses this is an "optimization". It will mismatch:

One impact of this encoding specification is the creation of a mismatch between theoretical reference display tristimulus values and those generated from the encoding implementation. The advantages of optimising encoding outweigh the disadvantages of this mismatch.

My understanding is the "theoretical reference display" would be pure 2.2 which was always just an approximation of CRTs, calling back Jack Holm said. But now, we can target symmetry thanks to our digital display technologies and see the differences in black floor due to OLED displays. It was never going to be perfect, but be "consistent" or "compatible".

At the same time you have to consider how content was authored. The intent was to be viewed on 2.2 despite the inaccuracies. Do you want to have the disadvantages as stated by the spec, and accept them (ie: 2.2 on sRGB is mismatched)? Or do you want to "improve" on the original intent and have something without the mismatch (ie: sRGB decode for sRGB content)?

I don't think it's a "bug" as stated in the topic title. But it's a understanding that the original 2.2 was an approximation with trade-offs that are no longer needed. There's no right answer either. Digital displays were adjustable enough to be able to choose between 2.2 and sRGB, so IMO, it really depends on what displays were used at the time of the time of authoring. It's better as an option, because even content designed for CRTs could have been 2.35 not 2.2 either.