Blackmagic Forum

Hi everyone,

I am greatly enjoying the resolve color mangemed (RCM) workflow. To better match my monitor and footage, I have increased the max. timeline luminance from 100nits to 300nits. I find that this greatly helps me to achieve better image.

However, whenever I use the text tool for white text or solid color generators for white backgrounds, instead of plain white, I get a washed out grey. I know, this is due to the increase in timeline luminance, but can it be fixed? Or is there a workaround at least? I don't want to limit my dynamic range of my video because of the text tool...

Thanks,
Andreas

A bit more info needed Andy.

Are you saying, on the output video monitor you have washed out grey? IS this for all the screen space or just the text? How do the scopes look?
Could this be your monitor limiting the amount of 300 nit it can display?

Sorry, here is a bit more context:

I am shooting in Hybrid Log Gamma 2 (not for HDR output, just because I found the footage to be cleaner than S-Log on my Sony a7rIII). I am using color managed mode to apply a HLG input color space. Output is Rec.709. In order to use the increase dynamic range of the footage and not having to "jam" the footage’s luminance into 100nits, I expand the max. timeline luminance to 200 - 300nits, which matches my monitor (300) and overall gives me more flexibility.
When changing the nits value, the top end of the scopes expand and the highlights of the footage no longer clip.
The text, which is set to RGB white in the text tool, sits at the top of the scopes at 100nits. When I expand to >100nits however, the text stays at the same position in the scopes as the headroom expands. The greater I increase the nits value (everything above 100nits), the more grey the text becomes (or a solid white color from the color generator).

In my perception, the luminance of generators and the text tool should also adjust with increased nits value (move up) and therefor stay white, but they don’t. They stay on an absolute position (e.g. 100nits) in the scopes, while the overall luminance of the timeline increases (e.g. 200nits), causing white to become grey. Is this fixable?

I am on the go, I can only include a screenshot later.

Thanks!
Andreas

andygrabo wrote:I am shooting in Hybrid Log Gamma 2 (not for HDR output, just because I found the footage to be cleaner than S-Log on my Sony a7rIII). I am using color managed mode to apply a HLG input color space. Output is Rec.709. In order to use the increase dynamic range of the footage and not having to "jam" the footage’s luminance into 100nits, I expand the max. timeline luminance to 200 - 300nits, which matches my monitor (300) and overall gives me more flexibility.

I would not do that.

The basic principle to go from high(er) dynamic range sources to the narrow Rec.709 is to maintain contrast in the mid-tones and curve both the blacks and highlights.

Cary Knoop wrote:I would not do that.

The basic principle to go from high(er) dynamic range sources to the narrow Rec.709 is to maintain contrast in the mid-tones and curve both the blacks and highlights.

I am not sure I understand. Are you saying I shouldn't increase timeline luminance (how can I prevent my highlights from clipping without going crazy on the grade) or I shouldn't shoot in HLG for Rec.709 (I have the same issue with S-log)?

andygrabo wrote:

Cary Knoop wrote:I would not do that.

The basic principle to go from high(er) dynamic range sources to the narrow Rec.709 is to maintain contrast in the mid-tones and curve both the blacks and highlights.

I am not sure I understand. Are you saying I shouldn't increase timeline luminance (how can I prevent my highlights from clipping without going crazy on the grade) or I shouldn't shoot in HLG for Rec.709 (I have the same issue with S-log)?

You prevent your highlights from clipping by operating the many controls in Resolve, it's called color correction! Provided you apply the correct transforms if you use color managed mode it does not matter if your source is Rec.709, log or HDR.

Alternatively you could use ACES which should get you to the right starting point for grading provided you use the correct transforms. ACES is currently re-doing HDR and currently HLG is not supported, I would wait with using ACES for HDR deliverables.


The only time I would use a luminance other than 100 is if your target grade is HDR. A 300 nit Rec.709 monitor is not HDR.

Ah, all bow to the text tool, then? ...and I am not trying to do any HDR stuff.

Kidding aside, this really sounds counter intuitive. Firstly, increasing the timeline luminance works very well for me and with all my different footage and images except the text tool. The results look very nice and I am reluctant to change my workflow to adapt to the text tool.
Secondly, I would argue that the great majority of displays of my audience is able to displaying much more than 100 nits. Why should I force my footage into 100 nits, potentially loosing dynamic range?

I don't even have to extend the luminance to 300, the same problem exists when extending to 150 nits.

To put it differently, say I decide to buy a HDR monitor and do HDR videos. How do I fix the color of the text tool?

andygrabo wrote:Ah, all bow to the text tool, then? ...and I am not trying to do any HDR stuff.

Kidding aside, this really sounds counter intuitive. Firstly, increasing the timeline luminance works very well for me and with all my different footage and images except the text tool. The results look very nice and I am reluctant to change my workflow to adapt to the text tool.
Secondly, I would argue that the great majority of displays of my audience is able to displaying much more than 100 nits. Why should I force my footage into 100 nits, potentially loosing dynamic range?

I don't even have to extend the luminance to 300, the same problem exists when extending to 150 nits.

To put it differently, say I decide to buy a HDR monitor and do HDR videos. How do I fix the color of the text tool?

Stupid questions but what is your monitor? what is your BMD hardware card? (Decklink, miniMonitor, etc ...)

Are you monitor properly calibrated?

andygrabo wrote:Secondly, I would argue that the great majority of displays of my audience is able to displaying much more than 100 nits. Why should I force my footage into 100 nits, potentially loosing dynamic range?

Assuming you deliver for Rec.709 limiting timeline luminance has nothing to do with limiting dynamic range.

andygrabo wrote:To put it differently, say I decide to buy a HDR monitor and do HDR videos. How do I fix the color of the text tool?

It all depends on your destination, if you want to grade for HDR then you set the appropriate output transform which has to correlate with your monitor settings.

I would really advice you to get to understand RCM because right now I think your are using it incorrectly.

The principle is really simple you set the input transform to the gamma and gamut you recorded with, the timeline transform you can set to your liking, typically that would be Rec.709 or, if you prefer, a log format and the output transform is the gamma and gamut for which your monitor is calibrated and your deliverable format, which typically will be Rec.709 or HDR provided you have a HDR monitor or DCI P3 for digital movie formats.

Alright, I REALLY don't understand this (which is absolutely possible) or we are talking about slightly different things. I have attached a screenshot from my workspace to maybe aid the discussion:
I have loaded the HLG2 footage, set up my RCM and increase luminance to 200 nits. I haven't applied any color correction or grades. The footage is as shot in camera.

As you can see on the screenshot, the subtitle, which has been set to white, sits somewhere below 896 in the waveform. As it is pure white, so the brightest it can be, shouldn't it be on top at 1023?

Answers to the other questions:
I am working & monitoring on a computer monitor. The final delivery will be rec.709 intended for computer monitors. I don't use BMD Hardware cards. As I am a photographer, my computer monitor is (color) calibrated. But you probably mean something else...

Cary Knoop wrote:Assuming you deliver for Rec.709 limiting timeline luminance has nothing to do with limiting dynamic range.

Okay, in my head the rational was higher nits equals more room for luminance equals more room for data equals more detail?

Cary Knoop wrote:The principle is really simple you set the input transform to the gamma and gamut you recorded with, the timeline transform you can set to your liking, typically that would be Rec.709 or, if you prefer, a log format and the output transform is the gamma and gamut for which your monitor is calibrated and your deliverable format, which typically will be Rec.709 or HDR provided you have a HDR monitor or DCI P3 for digital movie formats.

Yes, I know this part. That's why I like this workflow so much. But if you can point me to any resources that go into greater detail on that, I'll be happy to study that on my own.

Thanks.

andygrabo wrote:Alright, I REALLY don't understand this (which is absolutely possible) or we are talking about slightly different things. I have attached a screenshot from my workspace to maybe aid the discussion:
I have loaded the HLG2 footage, set up my RCM and increase luminance to 200 nits. I haven't applied any color correction or grades. The footage is as shot in camera.

The input transform maps the HLG2 footage onto Rec.709. Now obviously the dynamic range and gamut of the camera is larger than Rec.709. So it is as-designed that values go over 1023 as Rec.709 can't handle it. Now what you could do, but I still think it is not the best option, is to tone-map and gamut map the values to Rec.709 gamma/gamut in the RCM controls or using the OFX color space transform.

Better, I think is to keep the mid-tones as natural as possible (but you may have to limit gamut) and map shadows and highlights as good as you can within legal values (which is a test for Rec.709).

Cary Knoop wrote: Now what you could do, but I still think it is not the best option, is to tone-map and gamut map the values to Rec.709 gamma/gamut in the RCM controls or using the OFX color space transform.

But that’s exactly what I am doing, isn’t it? (I included the settings in the screenshot)
But disregarding that, that would still not solve my text-tool-white-problem, would it? (And this is not meant sarcasticly, I honestly don‘t know.)

Thanks for your patience.

andygrabo wrote:

Cary Knoop wrote: Now what you could do, but I still think it is not the best option, is to tone-map and gamut map the values to Rec.709 gamma/gamut in the RCM controls or using the OFX color space transform.

But that’s exactly what I am doing, isn’t it? (I included the settings in the screenshot)
But disregarding that, that would still not solve my text-tool-white-problem, would it? (And this is not meant sarcasticly, I honestly don‘t know.)

Thanks for your patience.

No, you would tone-map to exactly 100 nits, that would compress the highlights. But again I do not think that is your best option.

Let me ask you this, why don't you want to use the Resolve controls to color correct/grade?

Your "text tool white problem" is a problem you created by misapplying Resolve functionality.

I have the same problem. BMPCC Film clips in my timeline.
Input Color Space=BMD Film,
Timeline & Output Color Space=DRAGONcolor2/REDgamma4

White Text and white Solid Color Generator sit around 880 IRE.

There needs to be a way to bypass RCM for Text, Generators in general and Fusion Compositions.
The only workaround I found is to duplicate white text / solid color, layer it on top and set it to Add, but this creates some aliasing.

Christian Korahyn wrote:I have the same problem. BMPCC Film clips in my timeline.
Input Color Space=BMD Film,
Timeline & Output Color Space=DRAGONcolor2/REDgamma4

White Text and white Solid Color Generator sit around 880 IRE.

There needs to be a way to bypass RCM for Text, Generators in general and Fusion Compositions.
The only workaround I found is to duplicate white text / solid color, layer it on top and set it to Add, but this creates some aliasing.

Output Color Space=DRAGONcolor2/REDgamma4?

What kind of monitor would display that?

The output color space must match the monitor settings.

When white isn't white it is because your text has normalized color value of R=G=B=1.0, but value 1.0 does not map to peak white in your timeline colorspace and will appear grey in output. Increase the intensity of your text to make it white.

There's a strange bug in Resolve 15 (I say a bug because I can't imagine it being intentional) where generators are assigned Rec709 gamma instead of the timeline gamma (which is what Resolve 12/14 did); also, Fusion generators seem to be assigned linear gamma. That's why your titles are appearing grey, they are being transformed from Rec709 gamma to REDgamma4.

Really hope this gets fixed as it wrecks RCM workflows somewhat!

Tom Early wrote:There's a strange bug in Resolve 15 (I say a bug because I can't imagine it being intentional) where generators are assigned Rec709 gamma instead of the timeline gamma (which is what Resolve 12/14 did); also, Fusion generators seem to be assigned linear gamma. That's why your titles are appearing grey, they are being transformed from Rec709 gamma to REDgamma4.

As they should, the problem is using REDgamma4 as output transform, that does not make any sense (unless you are explicitly converting footage).

Cary Knoop wrote:

Tom Early wrote:There's a strange bug in Resolve 15 (I say a bug because I can't imagine it being intentional) where generators are assigned Rec709 gamma instead of the timeline gamma (which is what Resolve 12/14 did); also, Fusion generators seem to be assigned linear gamma. That's why your titles are appearing grey, they are being transformed from Rec709 gamma to REDgamma4.

As they should, the problem is using REDgamma4 as output transform, that does not make any sense (unless you are explicitly converting footage).

No, they shouldn't! The fact that the OP shouldn't be using REDgamma4 as an output transform for viewing on their monitor doesn't mean that the titles should look wrong - there is no transform occurring from Timeline to Output, therefore generators shouldn't be modified at all!

(Try adding a greyscale from the Effects tab into a timeline with colour science set to DaVinci YRGB and timeline space set to the default Rec709 Gamma 2.4. Now switch to RCM and set everything to Rec709 Gamma 2.4 with no tone mapping. The gradient will look completely different - are you saying this is OK when none of your footage will change?)

Of course, there were potential problems with RCM and generators before, but assigning them a specific gamma curve no matter what you are doing is not the answer and it will mean that you will only get the correct transform if either your Timeline or your Output is set to Rec709(Scene) - and that's for normal generators; if you have a Fusion generated lower third for example, it will output incorrectly no matter what your settings if you use RCM. Linear is the closest match but I don't suppose anyone fancies outputting like that do they?

The best solution would be to add an option to define the colour space for generators separately, as that will cover both the use of the Timeline space being a display referred space AND a scene referred space. The way things are however, it is suitable for no one.

Tom Early wrote:(Try adding a greyscale from the Effects tab into a timeline with colour science set to DaVinci YRGB and timeline space set to the default Rec709 Gamma 2.4. Now switch to RCM and set everything to Rec709 Gamma 2.4 with no tone mapping. The gradient will look completely different - are you saying this is OK when none of your footage will change?)

I see what you are saying, no I agree, that's not ok.

Interestingly there is an input color space option on a compound clip in the color page, however, it does not do anything.

Tom Early wrote:The best solution would be to add an option to define the colour space for generators separately, as that will cover both the use of the Timeline space being a display referred space AND a scene referred space. The way things are however, it is suitable for no one.

I agree.

Hi everyone,

I am having the exact same issue, RCM is making the grading of log footage (vlog from the GH5) really fast and beautiful if setting the nits level somewhere at 270 nits to match my monitor settings.

However, if needing to ad text or solid colors of a specific value to match clients requirements, it is all wrong as described above.

Did anyone found a clever way around that?

The most reasonable and qualitative option I could see would be to :
1- while it is set to 270 nits (in my case) export a first time without any text or logos or solid colors in the edit.
2 - Then re-import the rendered file into the project.
3- re-activate all the lower thirds / logos / solid colors to show on top of the rendered file
4 - change RCM settings to rec709 inputs and de-activate "timeline to output" tone mapping
5 - export a second time... whites should be white this time... shouldn't it?

Any better options?

Hi everybody ! I'm having the same issue here on a project, when I use imported pngs, imported prores 4444 with alpha, Davinci titles and now with subtitles.

Here is my Project configuration :
Davinci Resolve : 16.2
Mac OS X 10.14.16 // Mac Pro 2013
RCM using :
Input Color Space : BMD Film Pocket Cinema Camera 6K
Timeline CS : Arri Log C
Output CS : REC 709 2.4

For the imported files, the workaround i've found is to set the Input Color Space to Bypass. For Davinci Titles, I can double them in the timeline, and set the composite mode to ADD. But for the subtitles I can't find a workaround while still using RCM.

I think that this RCM related bug (And ACES too), is caused by the fact that generators are assigned a default color space and that you can't change it manually. Please, this issue has been reported 1 year ago (viewtopic.php?f=21&t=85167) ! I hope that you, folks at BM are aware of this very annoying issue, and are working on a fix that will be released in the next version.

I too am having the same issue working in Davinci YRGB Color Managed with Red R3D footage that works great for the Red clips but dulls any generated white text or solid colors.

Is there a way to bypass RCM's input on text and solid colors?

a "trick" you could use is to export your final edit in lossless format without the text/graphics, import it back and change the color management setting back to standard, so you can have pure white / acurate colors and do a final export that way...

johnsmith06 wrote:a "trick" you could use is to export your final edit in lossless format without the text/graphics, import it back and change the color management setting back to standard, so you can have pure white / acurate colors and do a final export that way...

Yes, that's what I've been doing but it's a time consuming workaround when the client comes back to make changes in the edit.

Hoping that this could be looked at in the next release.

Mark Bramley wrote:I too am having the same issue working in Davinci YRGB Color Managed with Red R3D footage that works great for the Red clips but dulls any generated white text or solid colors. Is there a way to bypass RCM's input on text and solid colors?

There are a lot of reasons I don't like working in ACES or RCM, and this thread has covered quite a few of them.

If you're going to deliver in Rec709/2.4 gamma, just do the whole thing in that specific color space and monitor in that color space. Keep it simple.

If you want to hit certain camera original shots with a Color Space Transform node, you can do that in the node tree but keep the actual project in Rec709. It's not my preferred way of working, but it can work.

The beauty of Resolve is that it'll let you work a number of different ways, whichever one in which you're most comfortable and productive. The danger of this is that neophytes can go right off the cliff and make bad choices, including some that can really damage the final results.

If it's a Sony A7 camera, I'd say, "jesus, it's a little cheap camera, just do it all by hand." Don't overthink this. These little cameras are not that hard to work with, provided they're lit and exposed well. There are a thousand YouTube videos that can show you how to come up with a decent starting point correction that will get the camera signal workable to a point where you can do something with it.

Marc Wielage wrote:

Mark Bramley wrote:I too am having the same issue working in Davinci YRGB Color Managed with Red R3D footage that works great for the Red clips but dulls any generated white text or solid colors. Is there a way to bypass RCM's input on text and solid colors?

There are a lot of reasons I don't like working in ACES or RCM, and this thread has covered quite a few of them.

If you're going to deliver in Rec709/2.4 gamma, just do the whole thing in that specific color space and monitor in that color space. Keep it simple.

If you want to hit certain camera original shots with a Color Space Transform node, you can do that in the node tree but keep the actual project in Rec709. It's not my preferred way of working, but it can work.

The beauty of Resolve is that it'll let you work a number of different ways, whichever one in which you're most comfortable and productive. The danger of this is that neophytes can go right off the cliff and make bad choices, including some that can really damage the final results.

If it's a Sony A7 camera, I'd say, "jesus, it's a little cheap camera, just do it all by hand." Don't overthink this. These little cameras are not that hard to work with, provided they're lit and exposed well. There are a thousand YouTube videos that can show you how to come up with a decent starting point correction that will get the camera signal workable to a point where you can do something with it.

Working in a Rec709/2.4 gamma color space with R3D clips means that to view them properly you need to add a color space transform node to each clip. Which you wouldn't do in any logging/editing process.

I would hope that Blackmagic could enable elements like generated solid colors, text, imported jpegs etc to bypass RCM so we don't have to do these workarounds.

Some kind of semiautomatic method or option to force generated graphics to convert to working colorspace trough inverted display transform would be preferrable to bypassing I think. For solids and text, this would scale the 1.0 white to appropriate max value in working space, which eventually will land back to 1.0 when going through output transform.

Elements that eventually get composited with something else can't be bypassed, they will be merged into some color managed element and thus will land in some colorspace anyway. Text for example.

Hendrik Proosa wrote:Some kind of semiautomatic method or option to force generated graphics to convert to working colorspace trough inverted display transform would be preferrable to bypassing I think. For solids and text, this would scale the 1.0 white to appropriate max value in working space, which eventually will land back to 1.0 when going through output transform.

Elements that eventually get composited with something else can't be bypassed, they will be merged into some color managed element and thus will land in some colorspace anyway. Text for example.

Agreed, there really is no reason for generated or imported graphics to be "processed" by an RCM timeline color space, especially when the output color space is Rec709 Gamma 2.4.

How can this be flagged with the developers at Blackmagic?

Been dealing with this as well. Cheap workaround for pure RGB white text layers is to just crank the gain in the color panel to compensate.

Having the same problem on Resolve 17 beta 6 – and been having it since Resolve 15. This is clearly a color management issue regarding Fusion and Generators and has nothing to do with any input or output transforms.
Text+ and Fusion Titles have incorrect chromaticity and luminance values as soon as any type of color management is applied. This affects ACES as much as Resolve Color Management and isn't even fixed with Resolve 17's new Color Management engine.

Simple text respects the graphics white luminance level selected in the project's color management settings – be it 100nits, 203 (HDR recommended) or higher – but Text+ and all Fusion titles completely disregard this and are mapped incorrectly. This also applies to Blackmagic's new DaVinci Intermediate color space.

This means that as soon as you're not using Rec709 as Timeline and Outpur Color Space, Text+ and Fusion Titles are rendered (pun intended) useless. It's an issue that has lingered around for years and desperately needs attention from Blackmagic's engineers!

Hey guys!
Can you explain me a little better the workaround? Which settings with the "color transform" should I use? (tried various combinations but without success)

I want to use the DaVinci Wide Gamut. But have the same problem, that text is grey and not white.

Thank you very much!

So.. I think I just found a solution that is suitable for me.

On my fusion clip I make a color grading
In this grade I add just one node with a "color space transform".
In this fx I just check the "use custom max. input"

Done! All colors and whites are set correctly. So I think this could be a good workaround, without render it twice. And with color groups you can apply this grade very fast to all fusion clips.

Maybe this saves you a lot of time!

That's interesting! I have to test it... But how can you do a right color graphic fusion comp, if your output color are over brightness?

timonf wrote:So.. I think I just found a solution that is suitable for me.

On my fusion clip I make a color grading
In this grade I add just one node with a "color space transform".
In this fx I just check the "use custom max. input"

Done! All colors and whites are set correctly. So I think this could be a good workaround, without render it twice. And with color groups you can apply this grade very fast to all fusion clips.

Maybe this saves you a lot of time!

Thank you for sharing this. It really seems to sort out the issue. What I recommend is to make a color correction group and then apply the CST to "post" the group. Few extra clicks but it works.