Is the reference EOTF for SDR missing from GStreamer? From Wikipedia BT.709 article: "In typical production practice the encoding function of image sources (OETF) is adjusted so that the final picture has the desired aesthetic look, as viewed on a reference monitor with a gamma of 2.4 (per ITU-R BT.1886) in a dim reference viewing environment.
I don’t see it here: video color.
Or is this just a list of constants to indicate the encoding, and not actually used for decoding anywhere? If that’s the case, the description should probably be clarified.
(FYI, I’m trying to correctly decode a movie with PsychToolbox, which uses GStreamer.)
Thanks!
When you chose to apply an aesthetic correction, you have to the lie in the stream so it does not get undone before rendering. Most SDR content will advertise GST_VIDEO_TRANSFER_BT709 which is GStreamer default for YUV data in HD to FHD range.
On Linux, it is currently hard to get everything converted and composed correctly (bt709 → sRGB composed and rendered). Your best luck will be using XV extensions on X11 system. There is a CTA-861 compliant Wayland protocol being worked on, that will completely change the game. Meanwhile, when color accuracy is needed, best is to convert everything to use sRGB colorspace and EOTF, as this is the default for most modern monitors.
It’s not ideal, mathematically we should compose using linear space (and something over 14bit per component), but most UI colors are tuned with the fact we currently compose in sRGB (with 8bit per component). It’s likely this will stick around a little since fixing this would give a retro look to today’s software.
Thanks Nicolas
However, I don’t really understand what you’re trying to say with respect to my specific question about BT.1886 EOTF (gamma 2.4) not being listed as an option in GStreamer.
Not sure what you meant there. If you mean that it should be indicated in the metadata, that makes sense, but from Wikipedia, I understand that the BT.1886 EOTF is the EOTF that should be used for BT.709, and not the inverse OETF of BT.709. I can’t tell if this is generally how SDR content is actually processed, but it would make sense if it’s meant for LCDs. So again, still very ignorant about GStreamer, but are these EOTF labels used for any processing in GStreamer, or just informative? I think it’s the latter, but in that case the description for GST_VIDEO_TRANSFER_BT709, that it’s a gamma 2.2 with linear bit, is a little misleading since the reference BT709 EOTF is actually gamma 2.4 (again according to Wikipedia).
What do you think?
Cheers
I will have to check when I find the time regarding which gama is borrowed in a portion of that function. Though, this is used in GStreamer when a colorspace conversation takes place, notably when we move from YUV to RGB.
1 Like
After some initial check, GStreamer transfer functions are all EOTF, rather then their reverse (OETF). So we describe the operation needed to remove what is encoded in the stream. This matches how it is expressed in the media container standards.
This is a higher gamma than the approximately gamma 2.0 of Rec. 709 OETF.
Not sure why they say approximate, but the eotf has a 0.45 gamma curve, which matches a reverse of 2.22 (1/.45). It seems to me that GStreamer documentation is accurate. Bt.1886 is basically telling the display maker to compensate with 2.4 gamma, which most likely relates to modern LCD charecteristics (while the original was designed to CRT characteristics). In practice, it all depends on the ambiant light and most TV adjust themself dynamically.
For GStreamer, if we translate BT709 (gamma 2.2) to SRGB (gamma 2.4), we need to stay mathematically correct, since the LCD will likely still compensate for its own characteristics in a similar way recommended by BT1886.
It’s the exponent of a pure exponential curve fitted over the entire range, including the linear bit near zero; 2.0 is a closer approximation than 2.2 over the full range.
But that’s my (Wikipedia’s) point: it’s not the EOTF, it’s the inverse OETF.
“The display EOTF of HDTV (sometimes referred as the “display gamma”), is not the inverse of the camera OETF. The EOTF is not specified in Rec. 709. It is […] specified in ITU-R BT.1886 as an equivalent gamma of 2.4”
Then if these container standards contradict BT.709/1886, as an end user, it’s completely unclear what we should be decoding with, to respect the intent of whoever encoded it (apart from viewer preference and viewing environment considerations). Which standards are you referring to please?
Edit: All that said, after a little more thought, it seems to me that for what you use it for, e.g. color conversion, it makes sense to use the inverse OETF. You then do transformations in linear space and convert it back with the OETF to eventually be displayed. It’s only the end display that would apply the EOTF. So I think the confusion here is semantics. I guess it’s easy to initially assume these two functions are the inverse of each other, but: “The OOTF is the composition of the OETF and the EOTF and is usually non-linear.”