'White' text is grey in a Colormanaged environment?

I guess I have the same questions of a loader node and also a generator such as Text+ or a background node's color. What color space / gamma are these outputting?

Those just generate RGB values. They are not doing anything in a special color space or whatever. It's just values. You tell the software how to interpret them. But.. (see below)

I understood that Fusion operates in a linear gamma, but I don't know where that conversion occurs, nor do I know if it gets inverted by the MediaOut node or whether we have to invert it ourselves (either on the Fusion page or in the Color page).

In RCM2 resolve expects the fusion comp to be in linear and in the timeline gamut. Therefore you could say the generators produces values in this space. But you can easily manipulate it by adding a CST inside fusion just before the MediaOut.
Does that make sense?

About the conversions. We're talking about several things here. Conversions happening inside of fusion and conversions before/after fusion. The one before is the IDT you set the footage to in the Media Tab. It goes camera color space to timeline color space. So now everything is in timeline color space.

In Fusion there is actually just timeline gamma to linear (start) and linear to timeline gamma (end). It does not care about the original camera color space or the display output color space.

And then there is the ODT at the end of the entire chain.

This is a great explanation and has moved me forward in my understanding of the implicit color space / gamma conversions within RCM/Fusion. What about in non-RCM projects? Does MediaIn still convert to a linear gamma and in that case, what is its implicit color space - is it that of the media or is it still assumed to be the timeline color space? Thanks so much for your help, Sven, as well as to others on this thread.

What about in non-RCM projects? Does MediaIn still convert to a linear gamma and in that case, what is its implicit color space - is it that of the media or is it still assumed to be the timeline color space?

In unmanaged Fusion does no conversion on its own. You have to tell it how to interpret the footage in the Inspector (Remove Curve) or with a separate CineonLog Node.
Definitely do not use the Curve Type "Auto" on this. Because it does not read the correct color space tag from the metadata. Use "Log" instead and tag it accordingly.

It looks like it does a simple log to lin conversion, but in Auto-Mode it thinks the footage is Rec.709. Sadly it does not take into account the timeline color space tag, that you can set in the project settings. So if you're after correct color transforms, do it manually!

Thanks Sven. Looks like with Text and background colors (in a non-RCM project) I can just convert to a linear gamma using a CST setting input color and gamma to DWG and then output color to DWG and output gamma to linear and then these can be mixed with colors from the video media (also transformed to DWG/linear) and then at the end of the pipeline just before MediaOut, a transform back to DWG/intermediate.

I do find with the loader node in an RCM environment that I need to play with whether or not to tone map and if so, how high to set my max output nits... Still a bit of guess work. And then, if 'User DRT for SDR to HDR' is disabled in the project settings... well, many things change. I'll keep at it for a while. It's almost 5 o'clock pm here - time for a drink, lol.

Add - I took what I learned on my PC and then tried the same on my MacBook and found that graphics elements such as text and background could not be converted into linear in a non-RCM clip. Still investigating what the difference is between my PC setup and my MacBook - both are running 18.1.1 - could be a project difference, I suppose. Something to investigate tomorrow. Yippee.

Reviving this thread because BMD just announced that it is now possible to disable tonemapping for fusion comps in Resolve 18.5

If someone has the time as guts to play around with the new beta I'd be happy to hear what you guys find out about that.

I couldn't find the new setting.

Found it.

It's only available with Custom RCM, not with Automatic.

Using 18.5 and disabling tone mapping on an existing project turned the white Text+ title to grey. I hope someone else will test this and report how best to use this new setting.

Using 18.5 and disabling tone mapping on an existing project turned the white Text+ title to grey. I hope someone else will test this and report how best to use this new setting.

I just tested it quickly, yeah selecting anything "HDR" for the luminance option, and activating the "Disable tone mapping.." makes the text+ grey, disabling it make it white

A few questions I have (won't update my system to a beta, so you people have to help me out with this):

- does it work in ACES aswell?
- is there a difference between toggling the button in existing projects and newly created projects? (we previously had issues like these, so it's worth having a look at it)
- what do the linear light values read, when you load in let's say LogC3 footage (clipped highlights) a) with fusion tone mapping and b) without fusion tonemapping?

I just tested it quickly, yeah selecting anything "HDR" for the luminance option, and activating the "Disable tone mapping.." makes the text+ grey, disabling it make it white

Interesting
I'll have to test that

Using 18.5 and disabling tone mapping on an existing project turned the white Text+ title to grey. I hope someone else will test this and report how best to use this new setting.

what are your project settings? input drt / output drt? timeline color space? output color space? what are the pixel values of white text inside of fusion with and without the new bypass button?

Using 18.5 and disabling tone mapping on an existing project turned the white Text+ title to grey. I hope someone else will test this and report how best to use this new setting.

what are your project settings? input drt / output drt? timeline color space? output color space? what are the pixel values of white text inside of fusion with and without the new bypass button?

All good questions. DWG intermediate with Rec709 gamma 2.4 output. Input/output drts are set to luminance mapping with a timeline level of 10000. I haven't checked the pixel values in Fusion or in the color page. If I get some time later. I'm hoping Shebbe will take a look at this and give us a more technical explanation of what is actually going on with this setting.

Add - With the disable tone mapping for fusion conversions checked the Text+ white is set to 185,185,185 - Without the disable tone mapping for fusion conversions checked the Text+ white is set to 255,255,255.

Hello

I believe the setting is introduced to decouple the inverse DRT option from the Fusion behavior. It is a welcome addition because without it, we can't work scene referred in Fusion (without adding a clunky CST) whilst using inverse DRT for graphics or already display normalized footage in our timeline. Turning the checkbox off reverts the behavior on Fusion comps to back before they changed it to tone mapped (18.1) with an update note, quote: "Improved handling of Text+ in RCM projects with DaVinci Wide Gamut."
As I said before in a post here on page 2 that claim was completely vague and false information at the same time compared to what was actually happening. It wasn't even DWG specific...

Unlike what was shown in the update video, the current option is not meant to fix any text, you will have text issues with project management no matter what because of the way a DRT works. Even if you completely give the user the ability to tag individual Fusion comps with different color spaces, it would still present alpha/edge issues.

So again. Turning it on makes Fusion comps be the actual linear variant of the working (timeline) space as it (typically) should for compositing. But makes the text grey again since 1.0 linear isn't mapping to display white through the DRT of course.

Color differences will also remain with it off, because the color choice is still based on the primaries of the working space. So while white or max red might map to Rec.709/sRGB properly, almost everything else won't.

It took me a while to understand these issues as well and they are unfortunately a bi-product of project wide management. I can understand that this is off putting for users that want to use RCM for it's simplicity but it's only complicating things if you need to do more than grading camera clips.

BMD should be more clear and open about the issue and maybe even present some best practices. In the ACES post world most of the times graphics and other elements are placed on top of the output after the fact in a non managed environment, which is something you can much more easily do in manual management in a single pass. Also other effects that you may want to perform post DRT are easily performed. Project color management has it's pros and cons and it just may not be suited for every project.

But I still believe that it could be at least improved by removing the global checkboxes all together (also the inverseDRT HDR/SDR) and just give the options for clips themselves to be flagged as DRT based display referred so it can convert itself to timeline and back without change. Although the sketch part of this is that RCM doesn't have a single DRT. So how would you even start to present that as an input space option... You can even have a different input DRT than output. RCM is just not as clean as it should be. Personally I really dislike the idea of Input DRT and a timeline working nits all together. Having only DaVinciDRT as output would make it a lot easier...

Fusion is always expected to be timeline primaries but Text+ should be interpreted as tone mapped by the DRT Rec.709/2.4 if that is what your output space is.
Doesn't fix alpha, but if the DRT accurately inverts accurately it fixes the color.

Hope that wasn't too vague. If any of my assumptions were incorrect, happy to hear.

Couldn't have said it better. Thanks shebbe.

I believe the setting is introduced to decouple the inverse DRT option from the Fusion behavior. It is a welcome addition because without it, we can't work scene referred in Fusion (without adding a clunky CST) whilst using inverse DRT for graphics or already display normalized footage in our timeline. Turning the checkbox off reverts the behavior on Fusion comps to back before they changed it to tone mapped (18.1) with an update note, quote: "Improved handling of Text+ in RCM projects with DaVinci Wide Gamut."

Did you try it out yourself, or are those only assumptions based of the release notes and videos at the moment?

Unlike what was shown in the update video, the current option is not meant to fix any text, you will have text issues with project management no matter what because of the way a DRT works. Even if you completely give the user the ability to tag individual Fusion comps with different color spaces, it would still present alpha/edge issues.

I somehow gave up expecting BMD to care about alphas won't even start about other channels.

So again. Turning it on makes Fusion comps be the actual linear variant of the working (timeline) space as it (typically) should for compositing. But makes the text grey again since 1.0 linear isn't mapping to display white through the DRT of course.

Color differences will also remain with it off, because the color choice is still based on the primaries of the working space. So while white or max red might map to Rec.709/sRGB properly, almost everything else won't.

So for Resolve 18.1 we already found out that it would be the best option to add a gain operator to the text elements in order to boost them to the desired nit level. How does this behave now with the new button?

But I still believe that it could be at least improved by removing the global checkboxes all together (also the inverseDRT HDR/SDR) and just give the options for clips themselves to be flagged as DRT based display referred so it can convert itself to timeline and back without change. Although the sketch part of this is that RCM doesn't have a single DRT. So how would you even start to present that as an input space option... You can even have a different input DRT than output. RCM is just not as clean as it should be. Personally I really dislike the idea of Input DRT and a timeline working nits all together. Having only DaVinciDRT as output would make it a lot easier...

A clip based input DRT solution (as in baselight) or at least an option to only use inputDRTs for display refered footage would be a much better approach. Scene refered spaces should not be mapped whatsoever!

Fusion is always expected to be timeline primaries but Text+ should be interpreted as tone mapped by the DRT Rec.709/2.4 if that is what your output space is.
Doesn't fix alpha, but if the DRT accurately inverts accurately it fixes the color.

The "problem" basically is that fusion is placed inside of the color pipeline, but people think it is placed beforehand. Both options would have their benefits.
If it were before the color pipeline, you would easily apply an inverse DRT to map to the timeline and forward at the end. Titles could be created in the output primaries, everybody would be happy.

Since it is placed inbetween the color pipeline it actually means that it will only receive the output DRT (as of R18.1.4). Resolve applies a log to lin conversion based on the timeline color space to enter fusion, and a lin to log one to exit fusion. No mapping happening here. Log footage fed into fusion is dependent on the inputDRT settings of the project. Which is why it is so bad to enable input DRT on the project wide settings!!

Did you try it out yourself, or are those only assumptions based of the release notes and videos at the moment?

Tested myself.

So for Resolve 18.1 we already found out that it would be the best option to add a gain operator to the text elements in order to boost them to the desired nit level. How does this behave now with the new button?

It's easy to slap some operators somewhere in the pipe to make something appear white, but your alpha gets boosted along the way and it doesn't solve the issue of display referred color picking / need for client color reproduction.

A clip based input DRT solution (as in baselight) or at least an option to only use inputDRTs for display refered footage would be a much better approach. Scene refered spaces should not be mapped whatsoever!

Agreed, but as I mentioned the RCM mechanism is far too complex and clunky to implement an elegant solution unless it gets an overhaul.

The "problem" basically is that fusion is placed inside of the color pipeline, but people think it is placed beforehand. Both options would have their benefits.
If it were before the color pipeline, you would easily apply an inverse DRT to map to the timeline and forward at the end. Titles could be created in the output primaries, everybody would be happy.

Since it is placed inbetween the color pipeline it actually means that it will only receive the output DRT (as of R18.1.4). Resolve applies a log to lin conversion based on the timeline color space to enter fusion, and a lin to log one to exit fusion. No mapping happening here. Log footage fed into fusion is dependent on the inputDRT settings of the project. Which is why it is so bad to enable input DRT on the project wide settings!!

I don't think it matters when in the pipe Fusion happens, it's before the output DRT so it should be considered as something and then transform to output. That something just happens to be scene linear or 'tonemapped linear' (whatever that's supposed to mean) of the timeline primaries.
Since 18.1 it does tone map to lin automatically which wasn't the case before. So a timeline nit tonemapped linear version is what is Fusion considered as. Now we can revert this with the new checkbox but it doesn't matter since the color data remains considered from the timeline and we have no control to override it.

I would recommend to either use manual management or in RCM simple deal with the fact that it's designed like this and per Fusion text add a CST to give it the display referred data you want it to have before it gets to the color page. Edges are nasty though.

image.png (28.44 KiB) Viewed 888 times

Those settings apply to DWG/Intermediate with Rec.709/2.4 out but you could match any custom setting and timeline nits ofcourse. The debate on whether the input for client colors should be sRGB gamma instead I'll leave off the table hehe...

It's easy to slap some operators somewhere in the pipe to make something appear white, but your alpha gets boosted along the way and it doesn't solve the issue of display referred color picking / need for client color reproduction.

Well you need to define it somewhere. A brightness / Contrast node (only rgb) to me seems like the most elegant solution. 1.0 defaulting to 100nits, 2.0 to 200nits and so on. That does actually make sense to me. (I remember my tests showed that behavior some time ago. correct me if I'm wrong)

I don't think it matters when in the pipe Fusion happens, it's before the output DRT so it should be considered as something and then transform to output. That something just happens to be scene linear or 'tonemapped linear' (whatever that's supposed to mean) of the timeline primaries.
Since 18.1 it does tone map to lin automatically which wasn't the case before. So a timeline nit tonemapped linear version is what is Fusion considered as. Now we can revert this with the new checkbox but it doesn't matter since the color data remains considered from the timeline and we have no control to override it.

That's where I partly disagree. Of course, if you really want to, the position in the pipeline does not matter, but if you assume Fusion was before the pipeline when it actually isn't for sure makes a difference. Fusion utself does not contribute to the tone mapping at all. All of that happens before that, as we already found out in our previous posts. The problem lies in the mapping-to-timeline-luminance. If you set up CM with no input DRT you will see that linear light reads as expected. Fusion itself only does log to lin and back.

Would you mind sending me a screenshot of that arri clip we used earlier with the pixel values in the following setups?
- input drt davinci + fusion tonemap enabled
- input drt davinci + fusion tonemap disabled
- no input drt + fusion tonemap enabled
- no input drt + fusion tonemap disabled

timeline color space shouldn't matter but to be sure set it to Arri LogC, so there is no extra math because of the different primaries.

I see what you mean now. The data is still influenced by the input DRT. Also found a bug while testing: The new color management override for timeline settings doesn't read the disable fusion tonemap checkbox... still read from the global settings instead.

Based on LogC3 timeline 1000nits for exaggerated differences. Measured the small light behind the talent at the center where it clips on the sensor on a crop node left viewer.

2023-04-18 10_39_30-Window.png (386.82 KiB) Viewed 819 times

So even though we can disable the tone mapping for Fusion comps, LogC3 is still being mapped to LogC3 1000nits? I'm honestly doubting my understanding again. There are 4 possible image states of which 3 are totally useless for professional workflows. Only the fully tone mapped "linear" 0-1 space I could see a slight use for manipulating data with tools that can't deal with >1.0 values but even then, working directly on log is the proper way to do that instead.

So it's the exact same construct as before, just that we can use the fusion tone map checkbox to say use inverseDRT SDR/HDR separate from that of clips outside of it. Workflow wise you still pretty much always want the input DRT disabled? Which in turn disables your ability to use display referred graphics/logos etc. (unless you use a CST on every element with all in/out set to use timeline with 100nits input max)
On non color data the input DRT is still irrelevant because the data is directly generated inside Fusion.

But I guess we pretty much got nowhere with this update?....

I see what you mean now. The data is still influenced by the input DRT. Also found a bug while testing: The new color management override for timeline settings doesn't read the disable fusion tonemap checkbox... still read from the global settings instead.

Based on LogC3 timeline 1000nits for exaggerated differences. Measured the small light behind the talent at the center where it clips on the sensor on a crop node left viewer.

2023-04-18 10_39_30-Window.png

So even though we can disable the tone mapping for Fusion comps, LogC3 is still being mapped to LogC3 1000nits? I'm honestly doubting my understanding again. There are 4 possible image states of which 3 are totally useless for professional workflows. Only the fully tone mapped "linear" 0-1 space I could see a slight use for manipulating data with tools that can't deal with >1.0 values but even then, working directly on log is the proper way to do that instead.

So it's the exact same construct as before, just that we can use the fusion tone map checkbox to say use inverseDRT SDR/HDR separate from that of clips outside of it. Workflow wise you still pretty much always want the input DRT disabled? Which in turn disables your ability to use display referred graphics/logos etc. (unless you use a CST on every element with all in/out set to use timeline with 100nits input max)
On non color data the input DRT is still irrelevant because the data is directly generated inside Fusion.

But I guess we pretty much got nowhere with this update?....

Ok, well..

so previously our conclusion was: to get correct linear values you'd have to disable input DRT AND disable inverse DRT for SDR to HDR

I also just found, that there's a difference between camera footage and generators. I use a background node ramp combined with a brightness/contrast node a lot to test those features, and it turns out, clicking buttons sometimes only affects the generator, sometimes only the arri clip. Great ...

To me it looks like in your screenshot option 4 (no input DRT + disable fusion tonemapping) seems to reproduce the same result as no input DRT + disable inverse DRT for SDR to HDR. So basically it gives you the option to use the inverse DRT for regular footage, but not for fusion clips, which sounds like a good thing tbh.

To me it looks like in your screenshot option 4 (no input DRT + disable fusion tonemapping) seems to reproduce the same result as no input DRT + disable inverse DRT for SDR to HDR. So basically it gives you the option to use the inverse DRT for regular footage, but not for fusion clips, which sounds like a good thing tbh.

Yes... but it's not a good thing imo. Having no inputDRT disables your ability to utilize inverseDRT if the desire is 'non-operation' like I said in previous post. Your display referred graphics won't be untouched so I still don't see the use case for a separate no tone map for fusion checkbox. I think it would make more sense to fully disable InputDRT for fusion tonemap checkbox it so that footage MediaIN into Fusion is also without inputDRT meaning true linear, but other files outside of it would have it enabled.

But ultimately that just comes back to the same conclusions I had before where we should actually need individual control over whatever we'd like to flag as tonemapped display referred and what not which is recipe for disaster as long as timeline nits and InputDRT + OutputDRT is a thing with separate mechanisms per in or out as options to the user.

To me it looks like in your screenshot option 4 (no input DRT + disable fusion tonemapping) seems to reproduce the same result as no input DRT + disable inverse DRT for SDR to HDR. So basically it gives you the option to use the inverse DRT for regular footage, but not for fusion clips, which sounds like a good thing tbh.

Yes... but it's not a good thing imo. Having no inputDRT disables your ability to utilize inverseDRT if the desire is 'non-operation' like I said in previous post. Your display referred graphics won't be untouched so I still don't see the use case for a separate no tone map for fusion checkbox. I think it would make more sense to fully disable InputDRT for fusion tonemap checkbox it so that footage MediaIN into Fusion is also without inputDRT meaning true linear, but other files outside of it would have it enabled.

But ultimately that just comes back to the same conclusions I had before where we should actually need individual control over whatever we'd like to flag as tonemapped display referred and what not which is recipe for disaster as long as timeline nits and InputDRT + OutputDRT is a thing with separate mechanisms per in or out as options to the user.

We're on the same page here. it's a big mess. and the why comes down to the placement of fusion inside the color pipeline.

If you care about true linear values AND have to have the input DRT enabled for display refered stuff (I personally would just treat those with a CST inside of fusion or color) you are still forced to do VFX in a clean new project - basically treating yourself as a VFX vendor - and prerendering and reconforming your shots.


... or use ACES lol