'White' text is grey in a Colormanaged environment?

Most of the argument revolves around different understanding of what ”white” actually means in the context of high dynamic range working space or display. There is no physical absolute white, it is more of a relative measure. Diffuse surface like piece of paper is white, but compared to some light source it is gray. Their luminance can differ by orders of magnitude but does that make piece of paper actually gray…

Most of the argument revolves around different understanding of what ”white” actually means in the context of high dynamic range working space or display. There is no physical absolute white, it is more of a relative measure. Diffuse surface like piece of paper is white, but compared to some light source it is gray. Their luminance can differ by orders of magnitude but does that make piece of paper actually gray…

I agree

I don't know what they did in the background to make 1.0 act as white in SDR but to 'fix' the colors you need to convert the Fusion comp from display space back to the working space to create an inverse.

So for example DWG/Intermediate working / Rec.709 2.4 Out:
Add a CST at end of Fusion node tree and convert from Rec.709/Gamma 2.4 to DWG/Linear without tone mapping and no forward or inverse OOTF checked.

Now the color will match the picker. However the way the alpha channel is treaded will result in dark edges. I'm not fully sure how to properly combat this. If I AlphaDivide before the transform and then add the original alpha on top, the edges are lighter instead.

Maybe someone more savvy with compositing / Fusion can explain a proper approach.

They either map 0.0-1.0 range to whatever the range of working space is, map 1.0 to select graphics luminance or do the inverse of view transform. Could be deduced with some testing. Surely the behemoth manual has all the info, it is after all very long

For alpha handling, unpremult, transform, premult should give proper result, if you simply swap in original alpha without premult after that you get additive blend on edges == lighter edges. Alpha shouldn't go through any transforms at all because it is not color data...

There is no physical absolute white, it is more of a relative measure.

Absolutely true. But the issue here is that they "fixed"/changed the behavior of Text+ to somehow makes 1.0 linear act as white in SDR whilst the working space is still linear.

After some more tests I finally understand what they did...

"Improved handling of Text+ in RCM projects with DaVinci Wide Gamut."

I'm quite mad about this stated release note because it's both uninformative and false. BMD really needs to be more honest and elaborate when it comes to changes like this.

What they really did is change the behavior of all Fusion comps to be the linear variant of the chosen working space but including tone mapping! This is the reason why white inverses back to display white for SDR. It's not exclusive to DWG either as I already mentioned in earlier posts. Not only that, it messes up compositing in linear because everything is scaled to 0-1.0! If you use MediaIN with the proper input color space selected, your scene linear data won't exceed 1.0 anymore.

At first the behavior was conversion from timeline space to linear for compositing and then back. Now they butchered it for sake of Text+ and you have to go through new hoops to fix what was first the default behavior. Bringing in a file through a Loader now not only requires conversion to the working space, you also need to tone map to match project settings again making the comp process within 0-1 range... And remember it's not scaled, it's tone mapped...

This is super counter productive if you ask me and is definitely not the solution I had in mind when it comes to improving compatibility between Resolve and Fusion color management.
I really hope that somewhere in this madness I can be proved wrong or that it's not as bad as it seems but from the looks of it this update ruined the use of Fusion in color managed projects for both Text+ and linear compositing.

2022-11-21 14_00_04-Window.png (221.46 KiB) Viewed 2694 times

2022-11-21 14_02_30-Window.png (15.24 KiB) Viewed 2694 times

2022-11-21 14_01_17-Window.png (231.28 KiB) Viewed 2694 times

it seems big changes changes in fact. I need to understand that in details .....

So I'm thinking again about Resolve 17 and the Fusion Page. What had understood with RCM and Fusion was :
Source file has it's own CS aka Input Color Space (Input Gamut and Input Gamma)
Then it was Color Transformed/managed to Timeline ColorSpace (Timeline Gamut and Timeline Gamma) ... with tone mapping (Input DRT)
Then (again) if you worked in fusion to "Fusion color Space" (Timeline Gamut and Gamma=1)

Then back to the Timeline color Space (Timeline Gamut and Timeline Gamma)
Then Color Transformed/Managed to output Color Space (Output Gamut and Output Gamma) .. with Tone mapping (output DRT)

May be it's not 100% accurate but that was the idea I made by my own about Rv17 RCM
Is it totally wrong ?

What has change with Rv18 about SourceFile?

What they really did is change the behavior of all Fusion comps to be the linear variant of the chosen working space but including tone mapping! This is the reason why white inverses back to display white for SDR. It's not exclusive to DWG either as I already mentioned in earlier posts. Not only that, it messes up compositing in linear because everything is scaled to 0-1.0! If you use MediaIN with the proper input color space selected, your scene linear data won't exceed 1.0 anymore.

Hilarious. They a) don't have anyone in-house who knows anything about actual comping; b) they don't have a color scientist working in BMD who would actually have any knowledge of color management workflows in relation to compositing. I'm all ears to any examples from last 5 years to prove otherwise.

Installed 18.1 now to see this circus with my own eyes and I can confirm. Comp is butchered with implicit tonemapping to 0.0-1.0 range, invalidating scene-linear assumption and making viewers, all comp procedures (think defocus of highlights etc) and so on just plain wrong. Loading the same source through mediain and loader, each with proper interpretation, gives wildly different results in same comp because loader-ed looks plausible (altough still wrong due to viewer behavior) and acts correctly, other is just a hot mess.

I'm trying to follow, somewhat unsuccessfully...

If I'm working in RCM with a DWG intermediate timeline color space, does that mean that what comes out of a MediaIn node in the Fusion page should be treated as DWG linear?

It looks like it also creates a managed display LUT that tries to take the viewer to sRGB by default... regardless of the output color space defined for RCM.

One question I have is regarding how it treats colors generated within the Fusion page. For example, if I create a background and set it to 'white' - what color space is that white defined in?

Also - @Shebbe, how do you know that tone mapping is applied within the Fusion page? Is that because of the way the generated colors are treated (such as a white background - my question above).

Much of the details discussed in this thread are beyond my current understanding but I'm trying to keep up.

There is no physical absolute white, it is more of a relative measure.

Absolutely true. But the issue here is that they "fixed"/changed the behavior of Text+ to somehow makes 1.0 linear act as white in SDR whilst the working space is still linear.

After some more tests I finally understand what they did...

"Improved handling of Text+ in RCM projects with DaVinci Wide Gamut."

I'm quite mad about this stated release note because it's both uninformative and false. BMD really needs to be more honest and elaborate when it comes to changes like this.

What they really did is change the behavior of all Fusion comps to be the linear variant of the chosen working space but including tone mapping! This is the reason why white inverses back to display white for SDR. It's not exclusive to DWG either as I already mentioned in earlier posts. Not only that, it messes up compositing in linear because everything is scaled to 0-1.0! If you use MediaIN with the proper input color space selected, your scene linear data won't exceed 1.0 anymore.

At first the behavior was conversion from timeline space to linear for compositing and then back. Now they butchered it for sake of Text+ and you have to go through new hoops to fix what was first the default behavior. Bringing in a file through a Loader now not only requires conversion to the working space, you also need to tone map to match project settings again making the comp process within 0-1 range... And remember it's not scaled, it's tone mapped...

This is super counter productive if you ask me and is definitely not the solution I had in mind when it comes to improving compatibility between Resolve and Fusion color management.
I really hope that somewhere in this madness I can be proved wrong or that it's not as bad as it seems but from the looks of it this update ruined the use of Fusion in color managed projects for both Text+ and linear compositing.

2022-11-21 14_00_04-Window.png

2022-11-21 14_02_30-Window.png

2022-11-21 14_01_17-Window.png

tbh I'm not quite sure that's entirely correct. I tested with an Arri LogCv3 clip inside a RCM project in fusion. The clip is tagged as LogC through the metadata. Inside fusion it's set to Auto wich reads the clips IDT as set above and automatically converts to linear. The fusion display LUT / management takes care of the viewer, but if toggled OFF you can see the linear image.

Those values did not look like they're scaled to 1.0, rather they looked as expected. Also it did not look like tone mapping was applied.

Color management in fusion is kinda tricky because the gamut node transfers some metadata bts that can be read by other gamut nodes and the display preview management. but the Cineon node does not write d
those metadata it seems. Both are recommended by the manual, only the Cineon node is able to convert log-to-lin and lin-to-log. Kinda over the place.

it seems big changes changes in fact. I need to understand that in details .....

So I'm thinking again about Resolve 17 and the Fusion Page. What had understood with RCM and Fusion was :
Source file has it's own CS aka Input Color Space (Input Gamut and Input Gamma)
Then it was Color Transformed/managed to Timeline ColorSpace (Timeline Gamut and Timeline Gamma) ... with tone mapping (Input DRT)
Then (again) if you worked in fusion to "Fusion color Space" (Timeline Gamut and Gamma=1)

Then back to the Timeline color Space (Timeline Gamut and Timeline Gamma)
Then Color Transformed/Managed to output Color Space (Output Gamut and Output Gamma) .. with Tone mapping (output DRT)

May be it's not 100% accurate but that was the idea I made by my own about Rv17 RCM
Is it totally wrong ?

What has change with Rv18 about SourceFile?

That was fully accurate yes. Fusion would just be fully scene linear. Not fully sure if it was a conversion from timeline working space or directly from the MediaIN but it did the job without tone mapping. This was always the behavior until 18.1. Now to work in scene linear you'll have to remove the implicit tone mapping before you start comping. For DWG/Intermediate default preset that would be 100nits in, 4000nits out. Then you'd have to do the inverse again at the end of your comp to make sure it's correctly mapped back to timeline space. Even worse about it is it's not even adaptable to your project settings like Use Timeline option for Color Space or Gamma (although even that has it's limitations).

2022-11-21 15_28_38-Window.png (26.96 KiB) Viewed 2664 times

tbh I'm not quite sure that's entirely correct. I tested with an Arri LogCv3 clip inside a RCM project in fusion. The clip is tagged as LogC through the metadata. Inside fusion it's set to Auto wich reads the clips IDT as set above and automatically converts to linear. The fusion display LUT / management takes care of the viewer, but if toggled OFF you can see the linear image.

Are you sure? The image is darker yes but it's not truly linearized. This is an Arri clip first in RCM Fusion with Input Color Space assigned, second in non managed with CST LogC3 to Linear (no tone mapping of course). If you do this in older Resolve versions you get the same as the bottom image which is what it should be.

2022-11-21 15_46_28-DaVinci Resolve Studio - kljjl.png (584.21 KiB) Viewed 2645 times

2022-11-21 15_47_30-DaVinci Resolve Studio - kljjl.png (601.96 KiB) Viewed 2645 times

If I'm working in RCM with a DWG intermediate timeline color space, does that mean that what comes out of a MediaIn node in the Fusion page should be treated as DWG linear?

As it is now in 18.1, it is not linear. What it is, can't really tell, I was unable to find matching conversion to make it look like data from loader.

It looks like it also creates a managed display LUT that tries to take the viewer to sRGB by default... regardless of the output color space defined for RCM.

Looks like it to me, but not sure.

One question I have is regarding how it treats colors generated within the Fusion page. For example, if I create a background and set it to 'white' - what color space is that white defined in?

Any generators generate data in working space because values they create are taken as-is, and as-is is always working space. There don't seem to be any implicit conversions going on.

Also - @Shebbe, how do you know that tone mapping is applied within the Fusion page? Is that because of the way the generated colors are treated (such as a white background - my question above).

Probing image values reveals it quickly. Highlights that are known to be superbright, way above 1.0 are all within 0.0-1.0 range. Image itself looks relatively normalish so it is not pure linear scaling, thus indicating nonlinear tonemapping.

Thanks Hendrik.

I suspect once in Fusion it really is linear, but tone mapped. So a timeline/linear in, timeline/linear out with inverse tone mapping as Shebbe stated should work to take you into a working space that will allow for super-whites, etc. but what drives me crazy (and I still need to test) is why this tone mapping would be performed if your output color space for RCM was set to some HDR where super-whites would be allowed.

My brain is melting...

I suspect once in Fusion it really is linear, but tone mapped.

These two aspects are opposing, can't have both at the same time. It is either linear or tonemapped, not both. And if superwhites are below 1.0 and diffuse midtone surfaces are around 0.2 at the same time it can't with any stretch be linear.

Thanks Hendrik.

I suspect once in Fusion it really is linear, but tone mapped. So a timeline/linear in, timeline/linear out with inverse tone mapping as Shebbe stated should work to take you into a working space that will allow for super-whites, etc. but what drives me crazy (and I still need to test) is why this tone mapping would be performed if your output color space for RCM was set to some HDR where super-whites would be allowed.

My brain is melting...

Yea that's what all the fuss is about. It all just simply feels like they wanted a quick fix because of the countless threads about white text being grey. And all the people pointing it out regardless of their understanding why it happened were more than right to complain about it because we were never given the tools to make it work the way we want. Now someone has decided that this is the way to do it but it's broken on both fronts because colors are still not display referred when we want them to be. It's just white mapping to white and we are left with quasi-linear Fusion comps where we need to remove the tone mapping should we want to composite any CG or plates properly.

I really hope BMD will acknowledge these shortcomings and come up with a proper way of working because these secret background "fix" shenanigans isn't helping anyone. Not amateurs and not professionals.

I really hope BMD will acknowledge these shortcomings...

The way this "fix" was implemented hardly gives any hope. To do what was done takes proactive stupidity, so someone in BMD actually laid out a plan to do it this way, it got approved, and executed. Where in this line is the acknowledgement supposed to kick in I don't see. If there weren't abundant years-and-years long history of similar antics one could discard this as an error but due to history it looks a lot more like pre-meditated "improvement" in the long list of other "improvements".

I suspect once in Fusion it really is linear, but tone mapped.

These two aspects are opposing, can't have both at the same time. It is either linear or tonemapped, not both. And if superwhites are below 1.0 and diffuse midtone surfaces are around 0.2 at the same time it can't with any stretch be linear.

How can this be true when in a CST you can specify output as linear but with a tone mapping applied? I guess that's one of several aspects to this that is causing me some confusion.

How can this be true when in a CST you can specify output as linear but with a tone mapping applied?

Ask the color scientists in BMD, it is their terminology. Outside Resolve it makes no sense whatsoever.

Can you be more specific of you would expect

Sure.

I expect the Fusion title to look the same whether I export in SDR or HDR, without having to do anything specific to make it look the same.

tbh I'm not quite sure that's entirely correct. I tested with an Arri LogCv3 clip inside a RCM project in fusion. The clip is tagged as LogC through the metadata. Inside fusion it's set to Auto wich reads the clips IDT as set above and automatically converts to linear. The fusion display LUT / management takes care of the viewer, but if toggled OFF you can see the linear image.

Are you sure? The image is darker yes but it's not truly linearized. This is an Arri clip first in RCM Fusion with Input Color Space assigned, second in non managed with CST LogC3 to Linear (no tone mapping of course). If you do this in older Resolve versions you get the same as the bottom image which is what it should be.

2022-11-21 15_46_28-DaVinci Resolve Studio - kljjl.png

2022-11-21 15_47_30-DaVinci Resolve Studio - kljjl.png

I tested with the exact same clip. yes. And I guess I got something wrong in my comment previously.
You are right. There is a DRT applied to the footage. But
it actually happens before the fusion color pipeline even starts. The difference being my color management settings have been set to Custom: Timeline being LogC

Having an LogC clip as input feeding into a LogC timeline basically bypasses the tonemapping, therefore I did not see any of that in my test. If the project is set to something else like DWG or anything else the tonemapping will make a difference.

Best practice would therefore be to disable the input DRT in the project settings, since this is the stage where the problematic tonemapping occurs.

Can you be more specific of you would expect

Sure.

I expect the Fusion title to look the same whether I export in SDR or HDR, without having to do anything specific to make it look the same.

Then your expectations are kinda wrong. Of course a title in HDR does look different than in SDR. That's the nature of the DRTs you use to convert to output color spaces and the nature of the displays.

Then your expectations are kinda wrong.

Well, let's call it a want or need, then.

Don't much care about the underlying workings. I want the title to look the same in both cases, without having to fiddle with it.

White text as gray is exactly the ”looks same” solution. It will map that text to some low luminance on hdr displays, so it matches (more or less) the luminance of same text on sdr display. So ”looks same” really isn’t a good description of what one actually wants.

Having an LogC clip as input feeding into a LogC timeline basically bypasses the tonemapping, therefore I did not see any of that in my test. If the project is set to something else like DWG or anything else the tonemapping will make a difference.

Best practice would therefore be to disable the input DRT in the project settings, since this is the stage where the problematic tonemapping occurs.

It doesn't really bypass it. The timeline working luminance still influences what the Fusion comp maps to. The only scenario where the math seems correct is when timeline working luminance matches output luminance (100nits) and the Input DRT is disabled. This is completely unusable of course because then outside of the Fusion comp you won't have a properly tone mapped image, which puts you back to square one where text is grey again if you would add it post everything on the color timeline

2022-11-21 17_31_04-DaVinci Resolve Studio - kljjl.png (918.27 KiB) Viewed 2557 times

The entire 'working luminance' and Input DRT are totally unnecessary components to begin with. I can't think of any other display rendering system that works like this and it only creates all kinds of wonky hoops when working with scene referred data. Maybe someone can proof me wrong..

Having an LogC clip as input feeding into a LogC timeline basically bypasses the tonemapping, therefore I did not see any of that in my test. If the project is set to something else like DWG or anything else the tonemapping will make a difference.

Best practice would therefore be to disable the input DRT in the project settings, since this is the stage where the problematic tonemapping occurs.

It doesn't really bypass it. The timeline working luminance still influences what the Fusion comp maps to. The only scenario where the math seems correct is when timeline working luminance matches output luminance (100nits) and the Input DRT is disabled. This is completely unusable of course because then outside of the Fusion comp you won't have a properly tone mapped image, which puts you back to square one where text is grey again if you would add it post everything on the color timeline

2022-11-21 17_31_04-DaVinci Resolve Studio - kljjl.png

The entire 'working luminance' and Input DRT are totally unnecessary components to begin with. I can't think of any other display rendering system that works like this and it only creates all kinds of wonky hoops when working with scene referred data. Maybe someone can proof me wrong..

I totally agree on the last bit. Timeline luminance makes a whole bunch of stuff really complicated and even creates problems with existing tools that simply don't work anymore. In a different post I showed how the timeline luminance setting makes the layer mixer unusable because of clamping.

Input DRTs should only be necessary for display referred footage. For scene referred footage it doesn't make sense.

I'm still not clear as to whether there is a way to add CSTs within Fusion to undo this damage and to create a pipeline that works. Prior the change in 18.1, I was able to follow the work-a-round published by VFXStudy and that seemed to do the job. That no longer works from what I can tell, although with what has been discussed in this thread, perhaps it can be adapted (I'm a bit lost, actually).

It doesn't really bypass it. The timeline working luminance still influences what the Fusion comp maps to. The only scenario where the math seems correct is when timeline working luminance matches output luminance (100nits) and the Input DRT is disabled. This is completely unusable of course because then outside of the Fusion comp you won't have a properly tone mapped image, which puts you back to square one where text is grey again if you would add it post everything on the color timeline

Ok after some further investigation I found that yes, working luminance does influence the behavior of the Input DRT and therefore also influence the luminance inside of fusion. For the timeline color space being Arri LogCv3 the correct setting would actually be 5506 nits (I don't exactly remember where I got that number from, but it's basically what a value of 1.0 in LogCv3 describes). And defining it as such leads to the exact same result as bypassing the Input DRT at all.

I still believe disabling the Input DRT is the way to go. That way the working luminance only affects the Output DRT.

This comes with a major drawback, tho. You would actually have to know each very specific number for each (timeline) color space to get an accurate mapping. BlackmagicDesign on the other hand could just set this value automatically the same way they are doing it inside the CST OFX. Here each color space has its specific max. nit value defined bts. I don't know why they made the working luminance setting different from that. (@BlackmagicDesign here is a feature request )

So many thing to catch up. I have no time to do my own tests
I think I can understand the issue,
It means that a Resolve 18 RCM fusion SFX work will look different in Resolve 18.1 RCM ??
Thanks you all

I'm still not clear as to whether there is a way to add CSTs within Fusion to undo this damage and to create a pipeline that works. Prior the change in 18.1, I was able to follow the work-a-round published by VFXStudy and that seemed to do the job. That no longer works from what I can tell, although with what has been discussed in this thread, perhaps it can be adapted (I'm a bit lost, actually).

I'm going to quote myself here - I would greatly appreciate a summary workaround or guidance to this issue if one is possible? TIA.

One thing I wanna test later (not at the machine atm) is if it makes a difference if you are using a MediaIn or a Loader Node. MediaIn get's the image after it's converted to the timeline color space (with DRT if enabled), bjt what does a Loader node do?

Looks like the loader brings it in in the file's color space / gamma curve and then to work with it you probably need a CST taking it from that color space / gamma to the timeline color space / linear...

”looks same” really isn’t a good description of what one actually wants.

OK.

How about "looks white"?

C'mon guys, this can't be that difficult to understand. Even HDR movies have white titles. We want that without having to tweak the title in any special way. By default.

I can understand what you want but it needs to be quantified. Do you want titles to blast through your scull at 10000 nits? It will be white allright.

Does a piece of normally exposed paper look white to you on hdr screen?

may be 200 nits like "Graphic white level" ??

”looks same” really isn’t a good description of what one actually wants.

OK.

How about "looks white"?

C'mon guys, this can't be that difficult to understand. Even HDR movies have white titles. We want that without having to tweak the title in any special way. By default.

you could argue that a Text at let's say 300 nits already looks white, or should it be 600? 1000? it's hard to answer. In the scopes you will never see white hit 100% brightness because of a) the output color space that is used and b) the way the scopes are set up.

but actually, to get back to the original topic of this post, the question if fusion allows text+ elements to be "white" in a color managed environment has already been answered. and to define how bright you could make it and how to even do that, there are already some solutions given. like for example adding a simple Gain operator (Brightness Node) in fusion and scaling everything to the desired nit value.

plus if you are using the project wide setting "use 203 nits diffuse white" the text+ elements will actually already get boosted to your desired "white level" that works in HDR

I would greatly appreciate a summary workaround or guidance to this issue if one is possible? TIA.

Sorry Steve, to what precisely? I think all was covered somewhere in this thread already but to sum up.

18.1 kind of switched around the VFXStudy workaround with the true linear Fusion comping when working in RCM. Or at least it sounds similar to his approach in terms of what they 'fixed'. So now Text+ by default renders white for 1.0 in SDR. But all Fusion comps are in linear, but tone mapped, space controlled by the project timeline luminance. On top of that the working gamut is still the same in Fusion as RCM. So:

Text+ -> white -> good to go
Text+ -> any other display referred color -> Jump in to Fusion and add a CST to convert from display out to working space. So for DWG/Intermediate preset that would be e.g. Rec.709/Gamma 2.4 -> DWG/Linear. Disable tone mapping. Inverse OOTF enabled -> Color will match, only issue is darker edges, alpha mess up. Not sure yet how to fix that.

VFX work -> when using mediaIN like jumping from a clip on the edit page to Fusion the clip will be in tonemapped 'linear' timeline working space. To revert back to true linear add a CST right after the MediaIN and go from Linear to Linear with DaVinci tone mapping: custom max input nits of 100 and max output nits of 4000 (or whatever you used as timeline working luminance)

VFX with Loader node -> load as usual and convert to desired linear working space

Then for both ways to work with VFX at the end of your node tree you'll have to convert back to the tone mapped linear space to make it match again with the hidden assigned conversion from fusion to timeline working space. So Lin to Lin but with the tone mapping order in reverse. 4000 to 100.

Does that help?

Thanks Shebbe. My only hiccup is that the text color with a CST applied to go from Rec709/Gamma 2.4 to DWG/Linear (no tone mapping) does not seem to achieve correct color in Fusion. I think I followed this:

Text+ -> white -> good to go
Text+ -> any other display referred color -> Jump in to Fusion and add a CST to convert from display out to working space. So for DWG/Intermediate preset that would be e.g. Rec.709/Gamma 2.4 -> DWG/Linear. Disable tone mapping. -> Color will match, only issue is darker edges, alpha mess up. Not sure yet how to fix that.

Maybe I did something wrong (I'm using the default RCM for HDR DWG intermediate which sets the timeline to DWG intermediate and the output to Rec709/gamma 2.4).

When you tried this, did colored text look ok?

VFX with Loader node -> load as usual and convert to desired linear working space

This was just an idea I had. did you test it? can you confirm it really makes a difference? I haven't tested yet.

EDIT: forget that idea. the Loader Node is just useful for loading still images. the manual even states it's only for loading EXRs. It's a different thing in Fusion Studio, but for Resolve you basically are stuck with MediaIn Node if you want to load any sort of video footage.

I have to admit I get humongous headhurt from just trying to follow the logic shebbe outlined. This stuff is now made so complex that it is in practice useless. I don't see anyone in their right mind jump all these hoops to get something done because it is massively error prone workflow.

What I would suggest for BMD to do:

1. Follow the simplicity of ACES and lose the additional custom tonemapping on input end.
2. Allow output transforms to be used as input transforms (as in ACES) if it is necessary to revert a baked in tonemapping (as in ACES if choosing Output > rec709 as IDT it will invert the RRT too in proper implementations).
3. Separate view transforms from output transforms on delivery and Fu render stage
4. Add option to choose Fusion working colorspace in project settings
5. Fix the Fusion viewer transforms, they are broken. Managed doesn't really manage squat right now.
6. Do not try to "fix" generators, rather explain how generated values get transformed to output end and how to manipulate graphics on output nits level. Optionally add some kind of param in generators to explicitly state that set value is meant to be produced on output end. Problem with this is handling of switching output transforms and differing view vs output transforms.
7. Loose all implicit "black-box" conversions in Resolve, choose reasonable defaults but allow overrides for all aspects. Looking at you, exr renders in ACES CM mode.
8. Add color journey to see what kind of transforms a piece of data goes through

Maybe I did something wrong (I'm using the default RCM for HDR DWG intermediate which sets the timeline to DWG intermediate and the output to Rec709/gamma 2.4).

When you tried this, did colored text look ok?

Sorry, forgot to mention. You do need to enable Inverse OOTF. Then the color will fully roundtrip. It will still look wrong in Fusion of course but on the edit/color page it will match. Edited my previous post to reflect this.

2022-11-23 12_21_49-Window.png (64.67 KiB) Viewed 2319 times

forget that idea. the Loader Node is just useful for loading still images. the manual even states it's only for loading EXRs. It's a different thing in Fusion Studio, but for Resolve you basically are stuck with MediaIn Node if you want to load any sort of video footage.

Yea yikes. Didn't realize this as I tested only with EXRs. The integration of Fusion into Resolve is painful to say the least.

I have to admit I get humongous headhurt from just trying to follow the logic shebbe outlined. This stuff is now made so complex that it is in practice useless. I don't see anyone in their right mind jump all these hoops to get something done because it is massively error prone workflow.

Yea it's very far from anything sensible. I almost feel bad for even suggesting it. I couldn't agree more with all the points you have for BMD to really make it work properly.
FWIW if you are really 'stuck' in the fact that you have to use RCM this is to my knowledge the only way to deal with it in v18.1. But what I'd really suggest to anyone using DaVinciDRT or even ACES is to run manual color management. It really is the only way to gain full control over what happens when and isn't that far off from project wide management in terms of things you have to do your self. It's just as a slight limitation in terms of having to use nodes for conversions. They limit flexibility with using groups on the color page.

This is how I would set up a basic DaVinciDRT pipeline with DWG working space.

Colorscience: DaVinciYRGB
- Timeline Color Space: Davinci Wide Gamut / Intermediate
- Output Color Space: Rec.709 / Gamma 2.4

Footage (Color Page):
- Use group pre-clip nodes to convert log/raw material to working space via CSTs without tone mapping.
- Use group post-clip for camera/group wide color adjustments.

Timeline node tree (Color Page):
- Apply CST to convert DWG/Intermediate to Rec.709/Gamma 2.4 with DaVinci Tone Mapping.

Fusion compositing:
- Convert MediaIn from camera source to DWG/Linear without tone mapping.
- Set up the Fusion viewer like explained in my thread here: viewtopic.php?f=22&t=165934
- Change the clip's Input Color Space on the color page group pre-clip from what first was your camera source to DWG/Linear to reflect the new input space that comes from Fusion.

2022-11-23 13_16_29-Window.png (182.93 KiB) Viewed 2319 times

Fusion graphics that you want display referred (Text+ etc):
- On the edit page put a CST on the clip and inverse the output transform.
Rec.709/Gamma 2.4 to DaVinci Wide Gamut/Intermediate
DaVinci Tone Mapping, Inverse OOTF enabled.
It should now null the the output conversion making the color display referred.

This is the 'simplest' way I can think of when rebuilding that which RCM lacks control over.
What may work suboptimal is when you also want to incorporate a look into the entire film.
For just color grading projects you'd simply put that on the timeline as well below the DRT but it would mess up your graphics again. The alternative to that would be to sacrifice your groups to put the look there instead post-clip, or if your edit structure allows it, use adjustment layers to place the look on top of your footage with the text elements above that. Keeping the timeline node tree for the output DRT only.

Our projects only come in to Resolve for color grading so luckily I don't suffer as much but I fully understand all the frustration that comes with it as we use Adobe software for the other stuff .

Maybe I did something wrong (I'm using the default RCM for HDR DWG intermediate which sets the timeline to DWG intermediate and the output to Rec709/gamma 2.4).

When you tried this, did colored text look ok?

Sorry, forgot to mention. You do need to enable Inverse OOTF. Then the color will fully roundtrip. It will still look wrong in Fusion of course but on the edit/color page it will match. Edited my previous post to reflect this.

2022-11-23 12_21_49-Window.png

forget that idea. the Loader Node is just useful for loading still images. the manual even states it's only for loading EXRs. It's a different thing in Fusion Studio, but for Resolve you basically are stuck with MediaIn Node if you want to load any sort of video footage.

Yea yikes. Didn't realize this as I tested only with EXRs. The integration of Fusion into Resolve is painful to say the least.

I have to admit I get humongous headhurt from just trying to follow the logic shebbe outlined. This stuff is now made so complex that it is in practice useless. I don't see anyone in their right mind jump all these hoops to get something done because it is massively error prone workflow.

Yea it's very far from anything sensible. I almost feel bad for even suggesting it. I couldn't agree more with all the points you have for BMD to really make it work properly.
FWIW if you are really 'stuck' in the fact that you have to use RCM this is to my knowledge the only way to deal with it in v18.1. But what I'd really suggest to anyone using DaVinciDRT or even ACES is to run manual color management. It really is the only way to gain full control over what happens when and isn't that far off from project wide management in terms of things you have to do your self. It's just as a slight limitation in terms of having to use nodes for conversions. They limit flexibility with using groups on the color page.

This is how I would set up a basic DaVinciDRT pipeline with DWG working space.

Colorscience: DaVinciYRGB
- Timeline Color Space: Davinci Wide Gamut / Intermediate
- Output Color Space: Rec.709 / Gamma 2.4

Footage (Color Page):
- Use group pre-clip nodes to convert log/raw material to working space via CSTs without tone mapping.
- Use group post-clip for camera/group wide color adjustments.

Timeline node tree (Color Page):
- Apply CST to convert DWG/Intermediate to Rec.709/Gamma 2.4 with DaVinci Tone Mapping.

Fusion compositing:
- Convert MediaIn from camera source to DWG/Linear without tone mapping.
- Set up the Fusion viewer like explained in my thread here: viewtopic.php?f=22&t=165934
- Change the clip's Input Color Space on the color page group pre-clip from what first was your camera source to DWG/Linear to reflect the new input space that comes from Fusion.

2022-11-23 13_16_29-Window.png

Fusion graphics that you want display referred (Text+ etc):
- On the edit page put a CST on the clip and inverse the output transform.
Rec.709/Gamma 2.4 to DaVinci Wide Gamut/Intermediate
DaVinci Tone Mapping, Inverse OOTF enabled.
It should now null the the output conversion making the color display referred.

This is the 'simplest' way I can think of when rebuilding that which RCM lacks control over.
What may work suboptimal is when you also want to incorporate a look into the entire film.
For just color grading projects you'd simply put that on the timeline as well below the DRT but it would mess up your graphics again. The alternative to that would be to sacrifice your groups to put the look there instead post-clip, or if your edit structure allows it, use adjustment layers to place the look on top of your footage with the text elements above that. Keeping the timeline node tree for the output DRT only.

Our projects only come in to Resolve for color grading so luckily I don't suffer as much but I fully understand all the frustration that comes with it as we use Adobe software for the other stuff .

How would you convert footage if you're just grading?Would you use an input DRT when you go from LogC to DWG Intermediate? or from Red Log3G10 or sLog3? I would usually say, no input DRT except for display referred footage.

Fusion converts to linear from the timeline color space, no matter what footage it is, in auto mode it goes to linear from timeline color space. Elements inside of fusion are treated as linear. So basically it's pretty simple on that end.

If you want to work in a display referred comp simply add a gamma 2.4 to linear (with inverse tonemapping) at the end just before the MediaOut node.
That does not affect the preview if you're looking at a node earlier in the tree. so maybe either disable preview management or tag it correctly early on with a gamut node and let the preview management expect "From Image".

Let me know if it works the way you wanted it to behave.

How would you convert footage if you're just grading?Would you use an input DRT when you go from LogC to DWG Intermediate? or from Red Log3G10 or sLog3? I would usually say, no input DRT except for display referred footage.

Like I said, you convert it from it's current camera encoding to DWG/Intermediate without tone mapping, so yes no input DRT.

Fusion converts to linear from the timeline color space, no matter what footage it is, in auto mode it goes to linear from timeline color space. Elements inside of fusion are treated as linear. So basically it's pretty simple on that end.

When using RCM in 18.1 this is not the case anymore. Like discussed earlier the 'linear' space is now tone mapped and you can't change this. In non managed setups like I was explaining, you convert it yourself because Fusion happens before Color page operations and doesn't do anything by itself.

If you want to work in a display referred comp simply add a gamma 2.4 to linear (with inverse tonemapping) at the end just before the MediaOut node.
That does not affect the preview if you're looking at a node earlier in the tree. so maybe either disable preview management or tag it correctly early on with a gamut node and let the preview management expect "From Image".

You'd need to convert the gamut as well, but yea that workaround was what I was suggesting. Doing it on the edit page is cleaner because it's not in the way of your viewer and node tree inside Fusion.

I can understand what you want but it needs to be quantified.

I want the results of the trick we had to do to make titles white, without having to do the trick.

Whatever that trick did behind the scenes, it worked.

BMD needs to give us those results, without the trick.

When using RCM in 18.1 this is not the case anymore. Like discussed earlier the 'linear' space is now tone mapped and you can't change this.

I could not see this in my tests tbh. So I double checked and it fell back to the conclusion we previously had. It depends on if the project was created before or after updating to 18.1 and I somehow forgot to consider that.

But I may have found the problematic setting, that causes the problem. In project settings "Use inverse DRT for SDR to HDR conversion" is checked and makes the fusion linear space tone mapped. Once you turn this OFF, you will see the fusion linear space work correctly. See attached image (18.1 entirely new project)

This of course is not achievable in the color management presets.

But I may have found the problematic setting, that causes the problem. In project settings "Use inverse DRT for SDR to HDR conversion" is checked and makes the fusion linear space tone mapped.

Yes we did find that to be the case, but this basically reverts the behavior and your text is 'grey' again. On top of that it breaks your invertibility of display referred data when working scene referred. Or SDR when working in HDR as BMD likes to call it....
So a Rec.709 clip in DWG/Intermediate timeline with Rec.709 output would become tone mapped while you typically don't want to do this.

When working in a color managed environment (with timeline set to DWG/intermediate, for example) what color space and gamma is output from a MediaIn node? Is it DWG/intermediate linear already or must we convert it to linear ourselves?

Similarly, in a non-RCM environment, does the MediaIn node output the color space of the associated clip in a linear gamma or is it the color space / gamma of the original clip?

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?

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).

Not very well thought out questions but I'm testing both RCM and non-RCM Fusion workflows using a combination of CLog3/cinema gamut footage, Rec709/gamma 2.4 and some graphics and generator colors and trying to see how these can be successfully combined on the Fusion page and quite frankly, I'm getting mixed results.

Maybe it's because my original CLog3 clip is being processed by a pair of CSTs in the color page (for manual RCM) which means that everything within the Fusion page will be processed by that same pair of CSTs suggesting that I need a uniform color space within the Fusion page across all media and my first CST on the color page needs to be adapted to whatever that uniform color space is (where the first CST takes the media from that uniform space to DWG/intermediate). Understanding how this differs with an RCM workflow would also help because I presume that with RCM, the MediaIn does not arrive in the original clip's color space.

Writing this lengthy, rambling post has given me several ideas of things to try to get a better sense of what is actually going on here. I'm going to need therapy at the end of this ride.

Yes. Disabling that checkbox get's you back to the grey text, but that makes total sense. If the text was not a generator but an imported Tiff you'd get the same result (if you interpret the tiff as linear). for the white to be actually white it would need to be really bright. one way to get there is either boost the gain. another would be to add an inverse DRT pre MediaOut node in order to tell Resolve "hey, this comp I am in has a range of 0 to 1. please convert this properly to the timelines max nits in order to work as expected later on when it get's mapped down to the display output"

Also another way ignore all of this stuff is to simply bypass color management on the title entirely (bad for multi format delivery but probably the best solution for most people anyway). this is easily possible by rightclicking on the clip in the timeline.

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.