Hideous Artifacts in RCM HDR Color Wheels

Hello everyone, working on a film and noticed that HDR Contrast specifically creates random, hidious artifacts that "flicker".

This only happens with HDR color wheels and is completely random. Some clips can have HDR Contrast and be totally fine, while others will result in horrible artifacts.

RCM: HDR Davinci Wide Gamut Intermediate
Output: R709 G2.4


I've been able to successfully "fix" it by turning off HDR Contrast. Can Resolve please address this? It's a QC ender and is ruining workflow for projects.

Thanks.

Computer specs:

M4 mac Mini Pro (fully specced)
DR 19.1.1

HDR Color Wheels should be color managed and depending on your color management settings you might be causing artifacts by inappropriate settings for the action you are performing. Its been few threads about this in the past.

Doesn't really make sense for adding slight HDR contrast to create artifacts.

HDR Color Wheels should be color managed and depending on your color management settings you might be causing artifacts by inappropriate settings for the action you are performing. Its been few threads about this in the past.

Doesn't make any sense for a small contrast in the HDR pane adjustment to cause artifacts like this at all. What's stranger is that it is only viewable in 8K, and in 1080 it's fine.

What's stranger is that it is only viewable in 8K, and in 1080 it's fine.

Sounds like some kind of tiling issue where image is processed in chunks for larger resolutions and there is something going slightly different per tile.

Does the flicker always "flick" the same regions?

Doesn't make any sense for a small contrast in the HDR pane adjustment to cause artifacts like this at all. What's stranger is that it is only viewable in 8K, and in 1080 it's fine.

The manual mentions : Apply Resize Transformations In... setting

When you’re using Resolve Color Management, a new “Apply Resize Transformations In” Project Setting is available in the Color Management panel while the Resolve Color Management presets menu is set to Custom Settings. This setting lets you choose which color space is used for resizing operations. Ordinarily, resizing is done in Linear, but certain specialty workflows benefit from doing resizing in other color spaces, so this option lets you choose which is best. The available options are:

Timeline: Uses the Timeline Color Space to perform all resizing operations.

Log: Uses a Log Color Space for resizing. Good for avoiding artifacts in certain high-contrast images, such as titles and star fields.

Linear: Usually provides the best results with most SDR media.

Linear Mapped: Usually provides the best results with most HDR media.

Gamma: Provided in case you find a need for this option.

Gamma Mapped: Usually provides best results when mixing SDR media with wide gamut and log-encoded media on the same timeline.

Do you have any of those elements in your project and do you apply resizing transformations? And does the same problem appear in rendering or only in the preview? You can also try to change resizing algorithms. Try linear for example.

Do you mind pointing to where this setting exists?

It does not exist in HDR Wide Gammut's project settings or I'm very confused or where I can locate this. The problem exists in rendering and Preview of 8K, not 1080 where it was being monitored.

Apply Resize Transformations In... setting can be found in the project or timeline color managed settings. And resize filters can be found in the transform controls of inspector panel. HDR color wheels react to tags from color management settings.

Resize Transform.png (87.4 KiB) Viewed 1730 times

Hi everyone, thank you for the advice here!

I was able to fix it with going custom --> HDR 500 instead of SDR 100 (SDR 100 was changing color decisions) instead of HDR 100 and changing that resize transformation to LINEAR.

Thank you all!

This is a huge issue and could've cost jobs and an incredible amount of man hours -- really hope Resolve addresses this and hope this thread stays alive for anyone else who comes across this issue.

This also gets rid of the random pixelated dot artifacts that HDR contrast can introduce at lower luminance levels!

Ordinarily, resizing is done in Linear, but certain specialty workflows benefit from doing resizing in other color spaces, so this option lets you choose which is best. The available options are:

Timeline: Uses the Timeline Color Space to perform all resizing operations.

Log: Uses a Log Color Space for resizing. Good for avoiding artifacts in certain high-contrast images, such as titles and star fields.

Linear: Usually provides the best results with most SDR media.

Linear Mapped: Usually provides the best results with most HDR media.

Gamma: Provided in case you find a need for this option.

Gamma Mapped: Usually provides best results when mixing SDR media with wide gamut and log-encoded media on the same timeline.

Then why in the world Resolve defaults to Gamma when you switch from automatic RCM to custom one?

And which one you would recommend, please, for those of us that process SGamut3.Cine+SLog3 footage on SGamut3.Cine+SLog3 or DWGI timeline?

Then why in the world Resolve defaults to Gamma when you switch from automatic RCM to custom one?

And which one you would recommend, please, for those of us that process SGamut3.Cine+SLog3 footage on SGamut3.Cine+SLog3 or DWGI timeline?

Custom settings are inherited from the preset you came from. If that's SDR the resize will be set to gamma. If you come from an automatic HDR or DWG/I preset for example, the resize will be set to log when flipping to custom.

There is no need to use a custom setting if you want to use DWG/I. The preset uses already appropriate settings. Resizing in log is typically preferred but you can lose some 'energy' in small detail. Linear tone mapped is worth a try if that's the case. You'll want to avoid full linear in resizing because most resize methods use sharpening algorithms that will potentially create negative values when in that state.

I was able to fix it with going custom --> HDR 500 instead of SDR 100 (SDR 100 was changing color decisions) instead of HDR 100 and changing that resize transformation to LINEAR.

Thank you all!

This is a huge issue and could've cost jobs and an incredible amount of man hours -- really hope Resolve addresses this and hope this thread stays alive for anyone else who comes across this issue.

This also gets rid of the random pixelated dot artifacts that HDR contrast can introduce at lower luminance levels!

I'm not fully confident that we're talking about a bug here. What were your full color management settings when you had the issue? Would you be able to share a frame and a .drp that demonstrates the issue?

Then why in the world Resolve defaults to Gamma when you switch from automatic RCM to custom one?

In my expriance, Blackmagic developers rarely make random choices for not reason. Usually they know their stuff and choose settings in relation to other settings. So I assume they have their reasons. What they are, I can only speculate. I don't know for sure.

I think a while back, you posted a question for this, but got no answers at the time.

viewtopic.php?f=21&t=180249

Personally, I tend to use non color managed project settings most of the time and do my CST or ACES or third party color management on clip by clip basis. And sometimes I use color managed settings, mainly to send appropriate metadata to color aware tools so they behave accordingly.

I had some issues with fusion view luts and red X, probably a bug. So I stopped using the color managed version and since I also use fusion studio a lot, where those settings don't exist, I simply do it all manually using CST, ACES or third party tools.

And which one you would recommend, please, for those of us that process SGamut3.Cine+SLog3 footage on SGamut3.Cine+SLog3 or DWGI timeline?

Do you deliver to rec709? Is this only your project, or do you collaborate and have one or multiple delivers etc?

Anyway, I would probably go with scene referred space if I'm using more than one camera or asset and work with VFX and have more than one deliverable and if its personal project with one camera, just color grading and one delivery. for example Rec709 like the monitor, than I would be ok working with display refereed color space.

I've worked that way before and I build my own luts for everything. And since I was always choosing to shoot in the same way and there is only one color space and camera and one delivery, its all good. Than when I had to work with many cameras and many deliverables, I found it to be limiting so I switched to scene referred color space.

First I used ACES but found some problems with it, so I used CST and still do often, and lately I've been using third party workflow in resolve, not fusion, just resolve. From color lab company. More on this later.

I've made a post with all the links and resources not long ago here on forum, but for some reason I can't find it neither in forum or in my notes and I don't feel like re-posting all that again from scratch. But If I find it, I'll re-post here.

Like I've mentioned, lately I've been using and testing ColorLab products, which are like using CST system, but its third party with more emphases on film emulation. So the set of tools they provide are something you can find on their website.

They have a collection of tools they call film lab. Creative I know. But its actually pretty good set of tools when used togeather that replaces most other tools. I've been testing it and I'm quite happy so far.

https://colourlab.ai/filmlabai/

So my current workflow would be something like this. I also shoot with Sony, and just the other day I was testing some night time shoots with neon signs and lot of colors and grain, and this is was my workflow that gave be very good results. With dynamic range, gamut and all the details preserved.

INode CP (JPLOG2 | AP1) > (converts from sLog to JPlog2 and works as IDT (Input Device Transform): Converts camera-specific color space into the common ACES color space, normalizing base images for color grading.)

Lenslab CP (JPLOG2 | AP1) > (does simulation of lens effects as open FX plug in)

parallel nodes: > Halolab CP (JPLOG2 | AP1) and Grainlab CP (JPLOG2 | AP1) > (this is another set of open FX plug ins they offer which simulate grain and halation effects, but I use them in parrarel to simulate real lens situation. Lens simulation before these two, and than they are happening at the same time so I use them in parallel nodes)

PrintLab (JPLOG2 | AP1) > (a 128 lut high precision of film print)

Resolve Adjustments > parallel nodes :

(Power Windows / Magic Mask / Qualifiers) > OpenFX >

Than I would add ONode (SDR / Rec709 JP LowCon) > acts as ODT (Output Device Transform): Converts JPLG2 to rec709 flavor.

LookDesigner CP or Dehancer OpenFX (rec709) for finishing. if I use Look Designer from same company I can do final conversion from JPLog2 to Rec709 there, otherwise if I use Dehancer plug in from another company I usually work in rec709 but not always.

JPLOG2 is just log they provide which is almost linear and has AP1 gamut like ACES CCT. And for VFX work in fusion I would either go with ACEScg (linear | AP1) to ACEScct (log | AP1) to (JPLOG2 | AP1) and final delivery in Rec709 for my personal needs.

But I would also more and more work in fusion using CST from resolve and set it to DaVinci Wide Gamut and linear while in fusion. Mainly because CST does better tone mapping than ACES transform.

..........................

That is what I work with now and I'm quite happy. But depending on how you are working, solo or in collaboration, finishing started projects or working on your own, multiple inputs or outputs or single input and output. VFX or not. Motion graphics or not. etc. All that can lead you to choose best tools for the job. There is more than one way to skin the color managed cat. sort to speak. Keep experiment and evolving.

Then why in the world Resolve defaults to Gamma when you switch from automatic RCM to custom one?

My theory is because Automatic is actually using Gamma.

The default options when switching out of Automatic are what Automatic is actually using.

I think.

shebbe, Kruno, and Jim, thank you for your very thorough and educational replies!

Then why in the world Resolve defaults to Gamma when you switch from automatic RCM to custom one?

Custom settings are inherited from the preset you came from. If that's SDR the resize will be set to gamma. If you come from an automatic HDR or DWG/I preset for example, the resize will be set to log when flipping to custom.

I figured when switching to custom mode Resolve defaults to whatever preset it switches from uses, I am just wondering why they chose Gamma as default for SDR preset when based on their description (Linear: Usually provides the best results with most SDR media vs Gamma: Provided in case you find a need for this option) one would think Linear is much better choice when working with SDR media and thus much better choice for default for SDR preset.

You'll want to avoid full linear in resizing because most resize methods use sharpening algorithms that will potentially create negative values when in that state.

Can resizing in linear tone mapped result in negative values or it is safe?

And which one you would recommend, please, for those of us that process SGamut3.Cine+SLog3 footage on SGamut3.Cine+SLog3 or DWGI timeline?

Do you deliver to rec709? Is this only your project, or do you collaborate and have one or multiple delivers etc?

At the moment, and for the foreseeable future, I am a one-man-show recording with single camera (FX30) in SGamut3.Cine+SLog3 delivering Rec709 to Web social media.

Anyway, I would probably go with scene referred space ...

Currently I do conversion to Rec709 as very last node and do grading in nodes prior to it. Am I correct that means I am working on SGamut3.Cine+SLog3 as scene referred space?

Like I've mentioned, lately I've been using and testing ColorLab products ... I also shoot with Sony, and just the other day I was testing some night time shoots with neon signs and lot of colors and grain, and this is was my workflow that gave be very good results. With dynamic range, gamut and all the details preserved.

JPLOG2 is just log they provide which is almost linear and has AP1 gamut like ACES CCT.

Thank you VERY much for pointing me in direction of ColorLab! While I haven't been able to find pricing for FilmLab (and everything indicates it would be out of my reach) your comment made me check them out and, in turn, brought FreeLab and JPLOG2 to my attention. They promise many nice things that picked my curiosity so I will have to try them as soon as I can. In the meantime, I am little confused with statements about JPLOG2's dynamic range. On one side I have seen statements that it exceeds dynamic range of modern cameras and that it covers 12.46 stops. It is my understanding 12.46 would be still less than some Sony cameras do with SLog3. On the other side I have seen statements JPLOG2 covers 12.46 stops _above_ middle gray (which is definitely more than SLog3 does) and your statement all the dynamic range in your Sony recording has been preserved. Could you please clarify for me which one is correct, 12.46 stops total or 12.46 stops above middle gray? In other words, does JPLOG2 cover complete range SLog3 can record?

Thank you again!

At the moment, and for the foreseeable future, I am a one-man-show recording with single camera (FX30) in SGamut3.Cine+SLog3 delivering Rec709 to Web social media.

To start, whether you use a display-referred or scene-referred color space is likely fine for your needs. I personally began with display-referred and switched to scene-referred because I needed to handle multiple input assets and output deliverables. Once I learned how to do this using a scene-referred approach, I decided to continue using it because I find it more flexible overall, once you're used to it and have your workflow set up.

Regarding the scene-referred approach, I've tried three different options, and they all work. I've settled on one of them, at least recently, but you can use whichever works best for you.

I tried ACES, Resolve's native CST, and FilmLab from the ColorLab workflow. They all ultimately allow you to achieve the same results but use different approaches, and some of the tools differ. There's also OpenColorIO (OCIO), but that's probably not what you'll be using.

I personally find ACES the least user-friendly, but it's often promoted as a standard, especially in VFX-heavy workflows. Resolve's native CST color management is very good and freely available, even in the free version of Resolve. ColorLab is a more colorist-niche-based approach that I would say is the most user-friendly once you get used to it. It also includes specialized film simulation tools, but it's the least accessible of the three because of extra cost. Therefore, you should probably stick with CST, and you'll be fine.

If you are looking into luts, there is some good resources I've used in the past.

there is a really good free lut creator which can be used for custom lut making.

LUTCalc - 1D & 3D Cube LUT Calculator v4.09 by Ben Turley
https://cameramanben.github.io/LUTCalc/ ... index.html

And the guy behind JPLog2, Josh Pines (Saving Private Ryan, Forrest Gump, The Revenant) was involed also in making luts for Sony Venice which can be used with Slog3.

https://sonycine.com/resources/luts/

I like 50-50 lut. Which is also part of the whole FilmLab product.

Anyway, I would probably go with scene referred space ...

Currently I do conversion to Rec709 as very last node and do grading in nodes prior to it. Am I correct that means I am working on SGamut3.Cine+SLog3 as scene referred space?[/quote]

Well to avoid any confusion, here is basic idea behind scene vs display refereed. From that you should be able to make sure you are where you want to be. Its a bit more technical, but I guess you that is something you don't have such problems with so I'll post some resources.

Color Management Fundamentals & ACES Workflows in Nuke [PARTNER PROVIDED] (720p_30fps_H264-128kbit_AAC).mp4_snapshot_01.11.41_[2025-02-28_19.34.12].jpg (193.9 KiB) Viewed 1378 times

This is aimed more at VFX and ACES with VFX Supervisor, Victor Perez, but it is good at explaing many technical terms. Color Management Fundamentals & ACES Workflows in Nuke

Another good technical resource is here:

Color Management in DaVinci Resolve via mononodes.com

https://mononodes.com/color-management- ... i-resolve/

and here:

https://chrisbrejon.com/articles/ocio-d ... nceptions/

Thank you VERY much for pointing me in direction of ColorLab! While I haven't been able to find pricing for FilmLab (and everything indicates it would be out of my reach) your comment made me check them out and, in turn, brought FreeLab and JPLOG2 to my attention. They promise many nice things that picked my curiosity so I will have to try them as soon as I can. In the meantime, I am little confused with statements about JPLOG2's dynamic range. On one side I have seen statements that it exceeds dynamic range of modern cameras and that it covers 12.46 stops. It is my understanding 12.46 would be still less than some Sony cameras do with SLog3. On the other side I have seen statements JPLOG2 covers 12.46 stops _above_ middle gray (which is definitely more than SLog3 does) and your statement all the dynamic range in your Sony recording has been preserved. Could you please clarify for me which one is correct, 12.46 stops total or 12.46 stops above middle gray? In other words, does JPLOG2 cover complete range SLog3 can record?

Here is the official website for JPLog2, I think they offer free luts and DCTL as well, and there should be white paper in there somewhere.

https://colourlab.ai/jplog2/

And here is their presentation. Or sales pitch, depending on how you want to look at it.

COLOR LOVESTREAM 03 - JPLOG2 REVEAL

...................................

Like I mentioned I am mostly using their film lab pack myself as if late, and I'm quite happy with it, but I still rely on CST and ACES for Fusion work, and do grading with color lab tools.

For more clarification about them, and how they work here are some tutorials that helped me understand what should I use.

And here is simple screenshot of my very basic node tree with no extra local adjustments, just going from fusion ACEScg to ACEScct in the his case than using filmlab tools to JPLog2 and finally to rec709 with dehancer for finishing touches.

sshot-891.jpg (254.33 KiB) Viewed 1378 times

Filmlab Ai - Deep Dive

IO Nodes - Quick Start Guide

Lenslab for Davinci Resolve - QUick Start Guide

Halolab - Quick Start Guide

Grainlab 3.0 - Quick Introduction

Printlab from Colourpro for Davinci Resolve

Colourlab Ai for HDR & Dolby Vision

.........

Some extra resources.

ACES 1.3 with Davinci Resolve 18 - NEW! and UPDATED! training

CSTs vs Resolve Color Management

To start, whether you use a display-referred or scene-referred color space is likely fine for your needs. I personally began with display-referred and switched to scene-referred because I needed to handle multiple input assets and output deliverables. Once I learned how to do this using a scene-referred approach, I decided to continue using it because I find it more flexible overall, once you're used to it and have your workflow set up.

Understood. I just want to make double sure my understanding of what I am doing is correct as I prefer to follow best practices and flexible approaches as early on as possible in everything I do.

Thank you VERY much for again going way above and beyond in the rest of your post, it is truly educational and hugely appreciated, I have already learned some things from materials you linked to.

P.S. To anyone that might wonder what is answer to my question about dynamic range of JPLog2 vs. SLog3 material I have found indicates to me that JPLog2 seems to have around 20 stops of dynamic range (around 12.5 above middle gray and 7.5 below) while SLog3 has in theory bit under 16 (bit under 8 above and below middle gray) and in actual files around 14 stops (they cut off above IRE 94).

Thank you VERY much for again going way above and beyond in the rest of your post, it is truly educational and hugely appreciated, I have already learned some things from materials you linked to.

No problem. Cheers!

P.S. To anyone that might wonder what is answer to my question about dynamic range of JPLog2 vs. SLog3 material I have found indicates to me that JPLog2 seems to have around 20 stops of dynamic range (around 12.5 above middle gray and 7.5 below) while SLog3 has in theory bit under 16 (bit under 8 above and below middle gray) and in actual files around 14 stops (they cut off above IRE 94).

Excellent.

I think one argument I might have heard in one of the videos I linked was that during specular highlights capture, even if the camera cannot have such dynamic range to capture the detials, it helps for eye pleasing effect to have them roll-off nicely. So having extra room, could help with that and while I think its possible to do it manually in other ways, its maybe easier to have so wide and smooth rolloff in the log itself, that you don't have to worry about it and do it manually, but can use existing sliders to town down the specular and out of range highlights.

I know on old sony camera, a6300 I used their custom options to create a knee for the highlights making a custom profile in the camera. Which helped even when shooting with much smaller dynamic range profile to keep the highlights rolloff and they look quite a bit more eye pleasing. There are some cool things you can do in custom settings for custom in camera profiles. Its in their manual if you want to experiment. It made my old camera much more usable. It also has great options for noise reduction by basically no recording it in the first place. Look into those custom settings if you like.

sshot-1174.jpg (90.08 KiB) Viewed 1242 times

sshot-1175.jpg (90.71 KiB) Viewed 1242 times

I think one argument I might have heard in one of the videos I linked was that during specular highlights capture, even if the camera cannot have such dynamic range to capture the details, it helps for eye pleasing effect to have them roll-off nicely.

While I don't have neither the knowledge nor experience to authoritatively argue whether that is correct or not I believe it is true because to me personally how highlights and shadows are rolling off makes huge difference between will I find them pleasing or not.

While I don't have neither the knowledge nor experience to authoritatively argue whether that is correct or not I believe it is true because to me personally how highlights and shadows are rolling off makes huge difference between will I find them pleasing or not.

Indeed. Most top camera brands, especially in cinema class, like Sony, Arri, Red etc. tried to put a lot of emphases on this. And many filmmakers want it. And indeed it does look cheap when you see sudden cut off vs nice smooth roll off.

A camera sensor does not roll off highlights, (in scene-referred captures) this is a typical misconception. A sensor only sees light in a linear way. Camera encoding to a log file also does not apply any kind of roll off to the highlights. If this was the case there would not be a simple mathematical function to turn it back to scene linear light values.

See Fuji F-Log for example, it starts with toe towards 'camera black' and the linear portion extends all the way until the clipping point of the container. The camera sensor capturing and encoding to this format may have less that this and clip sooner.

1528-FRONTPAGE-FLOG_curve.jpg (494.75 KiB) Viewed 1079 times

A camera may capture in a non log format that does include highlight roll offs and other things but this is pretty much the same as doing it in post with RCM or using a (camera vendor)LUT. But this is typically intended to be 'ready for display' in Rec.709 without further tweaks needed.

Camera log spaces tend to be only slightly 'larger' than what the camera sensors they use can capture. Anything more would be a waste of available encoding bits. There is no 0-1 range restriction when working in log in software like Resolve where the domain is in 32bit float instead of 10bit integer. But even then it's not desirable to work in a log space that puts a lot of stops inside 0-1 because legacy tools like lift gamma and gain will all feel pretty much the same if most of the actual information inside the image sits only in a very small portion in the middle of the range.

Unfortuantely, I spoke too soon.

Utilizing Custom --> HDR 500 for Luminance levels and setting the resize filter to Gamma results in washed out color in specific shots.

I'm at my wits end.