Hi - I’m scratching my head over this seemingly basic bit of stuff.
Using Nuke’s internal colour management (ie, not using OCIO), when I switch thew viewer between sRGB and rec709, the image appears more lifted (like higher gamma) set to sRGB than rec709. This is what I’d expect, with the pixel values being compensated for the monitor being calibrated to sRGB vs rec709.
When I switch to using OCIO with config set to aces_1.0.3 or aces_1.1, then this effect is reversed. rec709 (ACES) is more lifted than sRGB (ACES).
It has taken me a while to figure this one out ! And hopefully I have understood this right.
By default in Nuke, the Rec.709 Viewer is actually a Rec.709 camera encoding (OETF), so approximatively (or exactly ?) a gamma of 1.95. It is using a rec709.spi1d LUT in the config so I don´t know exactly what has been used.
And with the Rec.709 ACES Output Transform, it is the Rec.1886 EOTF that is used which I think is a Gamma of 2.4. From the ctl reference code :
// Display EOTF :
// The reference electro-optical transfer function specified in
// Rec. ITU-R BT.1886.
(it’s late here… not a good time for cg guy to be thinking about colour space… but…)
OK - so not to put too fine a point on it - my take away is that nuke has had it wrong the whole time.
This makes so much sense, explains so many times trying to follow the correct steps to take ref material from dailies in rec709 and display on sRGB monitor and always thinking it’s washed out.
I’ve just done a quick test in nuke comparing rec709->linear versus 1/2.4 gamma and this totally checks out. As you say, it’s actually pretty close match to 1/1.95.
Holy cow.
Thanks guys. And thanks for the very interesting link Liam - will read more when my head stops spinning over this.
I hope someone will correct me if I say something (or everything) wrong, but:
Rec709 is OETF, that is piecewise function with linear segment (multiplied by 4.5) below 0.018 and gamma 0.45 encoding above 0.018.
It has been intended to be displayed on a display with power function 2.35 EOTF. 2.35 was rounded to 2.4 just to have one decimal.
Linear segment deals with the noise and 0.45 gamma is for surround compensation, when you look at the small rectangular image in a dim room, and the image doesn’t cover the whole field of view. So contrast feels different.
sRGB OETF is also piecewise encoding function. And here we are starting the old inverse sRGB vs gamma 2.2 war.
From my point of view (I’m from gamma 2.2 club), sRGB was made as encoding function for displaying images on CRT displays, which, I believe, have more or less pure gamma (whatever number it is). So this concept of not undoing that darkening of the shadows, but displaying them dark, was still there.
But then, for some reason, monitors with inverse sRGB decoding function began to appear. Which are actually undoing all the things that were introduced by sRGB piecewise. So in the end you get roughly the same linear light that was in the original scene.
This is why you get brighter shadows on sRGB piecewise display with sRGB OETF encoded images. But even if you use power function 2.2/2.4 as a decoding curve in your display, sRGB encoded image is still overall brighter than Rec709 encoded image. This is expected and this is what their formulas actually are.
And regarding ACES sRGB Output Transform vs ACES Rec709 Output Transform - sRGB ODT has darker shadows that compensate for brighter shadows of sRGB piecewise decoding display.
ACES output transforms are actually devices, not the encoding standards. But it is a bit confusing now. sRGB means display. But there is no Rec709 displays, while Rec709 output transform is for gamma 2.4 display. So I hope it will be renamed to 1886 or 2.4 instead of rec709.
Let’s not start that war again shall we . My point of view on it is to do it per-spec : encode with piecewise and hope for god sake that the monitor you’re displaying on uses pure 2.2 gamma because that’s what’s expected in order to create the bright surround compensation.
. My point of view on it is to do it per-spec : encode with piecewise and hope for god sake that the monitor you’re displaying on uses pure 2.2 gamma because that’s what’s expected in order to create the bright surround compensation.