Color Space Transform OOTF?

[Douglas Dutton]

Hi everyone!

I noticed those 2 extra options in the Advanced submenu of the Color Space Transform OFX like you can see below:

I noticed that when Forward OOTF is ticked, then the footage appears darker than without it being ticked.

And when Inverse OOTF is being ticked, then the footage appears lighter than without it being ticked.

What are these options for? And when should they be or not ticked? Couldn't find anything about that in the manual.

Many thanks!

 

Douglas

[Marc Wielage]

Chapter 8 of the v17 manual, "Data Levels, Color Management, and ACES" (starting on p. 181), does at least mention OOTF. There's a course here on Lowepost that covers Resolve Color management in detail:

 

[Douglas Dutton]

Hi Marc!

Thank you so much for your anwser! Such a pleasure to read you, I saw you rencently in the Learn with Masters Masterclass and really loved your input!

Actually having seen the lowepost masterclass on colour management and double checked the resolve manual, the only mention of OOTF that i found is this one.

And unfortunatly could'nt find any explanation on what these 2 options do and when they should be used. (Apply forward OOTF / Apply Inverse OOTF in the Color Space Transform OFX).

Many thanks for your reply

 

Douglas

Edited July 11, 2021 by Douglas Dutton

[Daniel Rheaume]

Hello!

Not to hijack this thread, but I too am greatly confused. 

Checked the manual. Checked youtube. Checked Google. Checked Lift Gamma Gain forum. 
No one seems to have a good, simple answer about how to approach this. 

So far the best I can find is that when going from scene referred to display referred - use Forward OOTF.
Conversely, when going from display referred to scene referred -  use Inverse OOTF. 

Okay that makes some sense...but here is where I'm personally getting confused...

If I am doing my own color management in a Davinci YRGB project with a Log C timeline color space (ie, display referred I thought?), I am usually adding a CST to convert my log footage into an Arri color space (alexa/log c) for compatibility with power grades that expect that. Then, my final node is a CST that converts from Arri color space to Rec.709 for target display. So I don't see where I would be converting from display to scene or scene to display, and yet Resolve enables the OOTF checkmark when I select those transform settings. 

Is Resolve making an incorrect assumption, or am I not understanding when the conversion from display to scene is happening in my workflow?

Insight into this confusion is much appreciated!

Thanks!

-Daniel

 

[Bruno Mansi]

There does seem to be a lack of information about these options.

I wasn't even sure what the acronym stood for, but it seems to be 'Optical to Optical Transfer Function'.

Still looking, but I found this in a technical article on colour science...

Output-referred spaces have only an Electro-Optical Transfer Function (EOTF) which defines the relationship between code values (CV) and display light. This may be defined relative to display peak luminance, or as an absolute encoding in terms of display cd/m² . Scene-referred spaces have only an Opto-Electrical Transfer Function (OETF) which defines the relationship between relative scene light and the encoded value. Some encodings, such as Hybrid Log-Gamma (HLG), define a relationship to both scene and display light, so have both an OETF and and EOTF. An EOTF is not necessarily the inverse of the corresponding OETF. The combination of the two is referred to as an Optical to Optical Transfer Function, or OOTF.

Also found this....

Before we proceed, it must be reiterated that there are two aspects of Hybrid Log Gamma – a Scene Referred aspect which is encoded directly from a Camera and a Display Referred aspect which is relevant for displaying on a TV/Monitor. The key differentiator is that in a Display Referred context, HLG normally includes an opto-optical transfer function (OOTF) which transforms Scene Referred content into Display Referred content, such as an HLG 1000 NIT output from a HLG recording. Scene referred content on the other hand is as encoded directly from a camera. When we import footage recorded from a camera, this is almost always Scene Referred.

Not sure this makes it much clearer, but is it suggesting it would need to be used if creating HLG deliverables?

I know the BBC were experimenting with HLG as a solution for terrestrial broadcasting, but I don't know if anyone on these forums has actually worked with this HDR standard.

Edited August 3, 2021 by Bruno Mansi

[Daniel Rheaume]

@Bruno Mansi

 Thanks for sharing that information! Interesting, and still perplexing!

In my example above then....

If I bring in log footage (scene referred according to above) and do a cst into log c, I assume that would just be a scene ref to scene ref transform, since they are both log? So I should have ootf boxes unchecked?

Conversely, when I go from log c to r.709 at my final output cst, that would be scene referred to display referred? 
So then forward ootf should be enabled?

Is that how you would understand it as well?

[Bruno Mansi]

The way I read it is that an OOTF is essentially a combination of an OETF and an EOTF.

I don't see why you would use such a transfer in normal situations. It seems to suggest that HLG is an encoding that has both a scene and display referred relationships, and therefore seems to require an OOTF. 

Maybe a forward OOTF is when you're going to HLG and a reverse OOTF is when coming from HLG?

I'm really clutching at straws here!

[Daniel Rheaume]

@Bruno Mansi

 Thanks for your input, Bruno. 

That is very helpful and makes sense to me!

Cheers,

-Daniel

[Louis NN]

see below

Edited December 22, 2021 by Louis NN
needs to be deleted

[Louis NN]

I still don't know what this OOTF is and how it functions, but It turns on when you input log into the gamma part of the CST.

It turns off if you use HLG, so Resolve is automatically assigning it based on if the input is log or not, which would mean that HLG does NOT require Apply forward OOTF

Hope this makes sense

So basically you don't need to touch it

[Bruno Mansi]

I agree that it's still a mystery to me as to what it actually does!

I've found that it seems to turn on and off depending on various settings  which I haven't really worked out the logic of.

As an example, it turns on the forward OOF when you set the CST Input Gamma to Arri Log C, but if you set the Output Gamma to Cineon Film Log it turns off again.

I guess it's doing what it should (?) but it would be nice to know exactly what this is.

[Louis NN]

On 8/3/2021 at 1:50 PM, Daniel Rheaume said:

@Bruno Mansi

 Thanks for sharing that information! Interesting, and still perplexing!

In my example above then....

If I bring in log footage (scene referred according to above) and do a cst into log c, I assume that would just be a scene ref to scene ref transform, since they are both log? So I should have ootf boxes unchecked?

Conversely, when I go from log c to r.709 at my final output cst, that would be scene referred to display referred? 
So then forward ootf should be enabled?

Is that how you would understand it as well?

Yes that seems to be how it works, but resolve does this automatically for you so we don’t have to touch anything, but just for clarification 

A log to log conversion will have both boxes unchecked

A log to rec709 conversion will have  apply forward OOTF checked

I assume that converting from rec709 back to log would have the reverse OOTF checked (will confirm when back in Resolve)

[Mario Kotlar]

Finally figured this out.  Pages 11, 12 and 13 in the official HDR specification document have details and explanation of OOTF: https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-10-2021-PDF-E.pdf 

But I'll try to explain it in my own words:

Image on the left is the unintuitive result of keeping the light fully linear from real world to the nits on the display. Meaning that camera essentially records the number of photons hitting each part of the sensor. So if a pixel has signal value 0.5 that literally corresponds to double the amount of photons came from there than from the pixel that has a value of 0.25.  But if we preserve that ratio all the way to the display and make sure that those two pixels shine in that same ratio, one is twice as bright as the other, we'd intuitively expect to get perfectly faithful representation of reality, but in most cases we actually don't. There seem to be multiple contributors to this effect, but I noticed in my experiments that it's more pronounced with daylit scenes, with scenes containing some atmosphere, with scenes containing blooming / lens flares, with displays that can't show true black, with displays that have low peak brightness, when viewing the display further away and it depends on ambient light level  in the viewing environment.

But if scene light is actually well matched to the display and issues from viewing environment and all the aforementioned factors are avoided, then preserving 1:1 light ratio actually does produce the most realistic looking image possible that arguably couldn't even be made better by changing anything, provided that real life scene itself is aesthetically pleasing as possible. Since in over 99% of cases that's not the case, grading is needed to compensate for all those effects, and the average grade that one would want, that's what OOTF is. In the above image, it turns it from the washed out looking to having contrast that feels more true to real life (even though it's technically further away from it). 

OOTF is what breaks that 1:1 ratio of light that hits the camera sensor and light emitted by the display, and that pixel that was twice as bright before will now perhaps be three or four times as bright as that other pixel.

So when we're doing grading by ourself, we don't really "need" OOTF, we can use it as a starting point if we like, many may feel it will do half the job for them. I for example find it easier to grade HDR footage without OOTF, as it becomes much easier to control the shadow detail that way. OOTF is necessary for those who record home videos with cameras and then want to immediately watch that video on their TV, without grading it, and it's obviously essential for live broadcasts. If OOTF wasn't a part of the pipeline there, in over 99% of cases people would find that resulting video looks really washed out and just bad.

I'll quote the above document:

Quote

Until recently all displays were based on the CRT which, based on the common physics, all had a similar characteristic function converting the electrical signal to light, the so-called ‘electro-optical transfer function’ or EOTF. The camera characteristic of converting light into the electrical signal, the ‘opto-electronic transfer function’ or OETF, was adjusted to produce the desired image on the reference CRT display device. The combination of this traditional OETF and the CRT EOTF yielded the traditional OOTF.

This means that traditionally, EOTF was hardcoded by physics of CRT. So rec.709 camera recording would in addition to encoding into inverse of this gamma (OETF) at the same time add that basic grade called OOTF, so that footage would look nice on CRTs by default.

These days we use log profiles or record in raw. When we are inverting the log curve via CST effect, we can choose if we want to also apply the default grade which resolve calls "Apply Forward OOTF". This means that two transformations will take place, first the log encoding will be inverted and we'll arrive back at scene referred linear light, and then OOTF function will be applied to that to give a starting point or even a final result that looks more normal in most cases.  If we undo the log profile with both OOTF checkboxes disabled then we'll be seeing scene linear light, and it's up to us to grade it to look good, to create our own artistic improved OOTF for that particular footage by grading the footage ourselves.

But sometimes LUTs that invert LOG profiles already contain OOTF as part of their transformation, so the LUT actually contains the result of two sequential transformations. If the person who is grading instead wants to only undo the log encoding and arrive at scene linear light, then CST effect can be applied which converts from timeline gamma to timeline gamma, and with "Apply Inverse OOTF" checkbox checked we can return the footage back to scene referred linear light, essentially undoing the OOTF grade. One of the benefits of grading in scene referred linear light is that gain, a simple multiplication, will act like a physically correct exposure control for example. The other benefit is personal preference, where I for example find it gives me much better controls over blacks and shadows, as they don't come pre-compressed by the OOTF.

[Bruno Mansi]

Hi Mario

Thanks for sharing your research.

Cullen Kelly covered this a few months ago in his colour management lecture at ResolveCon.

Below is a YouTube link to his presentation. Go to 1hour and 5mins, where he answers a question about OOTFs.

 

 

[Antonios Ara]

My 2 cents...

In DaVinci YRGB, and Rec709 (scene) set as timeline color space (the default setting)...

...if you want to simulate a color managed workflow by working between two color space transform effects that cancel each other...

 ...the right setting for the second effect is:

• Output Color Space: Rec709
• Output Gamma: Rec709 WITH THE "APPLY FORWARD OOFT" SETTING TICKED. 

I don't know what the setting does, and I would appreciate somebody telling me in simple terms. Don't need a full explanation of Gamma, I am a colorist for 10 years.