NR at the end can cause JAUNDICE : Newbie Error

This NR issue is because I am a newbie to NR.
Thankyou Michael for your educational input in the Reply below:

====================
I have noticed what appears to my eyes as a JAUNDICE like colour shift on white peoples SKIN tones.

Does anyone have experience of this?

I put NR at the end of my workflow (BECAUSE IT LOCKS UP THE GUI on a Mac Pro)- but am now thinking that you need to have an additional COLOUR CORRECTION NODE after NOISE reduction.

Has anyone got a workflow - or tips on how to avoid the JAUNDICE problem in the first place.

Attached is an example of some very basic NR settings I am using (because I am new to NR).

AJ

Here is a comparison of NR node ENABLED & DISABLED

Is is me ... does this also like Jaundice on your screen?

AJ

Antony,

Nearly every Resolve tutorial that discusses Noise Reduction (NR) counsels that it should be at the front of the grading chain, not the end. Your post might give yet another reason as to why. Ask yourself this: what is Chroma Noise? How do you describe it? How do you counteract it? We all know that Bayer Pattern data has 2x more green pixels than red and blue. We also know that silicon happens to be much more sensitive to red light than to blue light, meaning that all else being equal, we expect more noise in the blue channel than the red channel, and more noise in the red and blue channels than the green channel. As we go about bending the pixels to our will, what happens? Green pixels, having the least noise, have the strongest vote, even when they are not the most important.

Please try turning off Chroma NR in both spatial and temporal, and see if the shift persists. If it does, then I don't have a good explanation. If it doesn't persist, see whether TNR or SNR Chroma contributes more to the shift. But, ultimately, put NR at the front of your chain and corrections afterward. And find a way to defeat the GUI lockups you are experiencing.

Michael,

+) You input was very much appreciated. I have never investigated the way NR algorithms have been implemented before. Perhaps there is room for improvement with a Machine Learning model 'perceived colour' model that is applied in conjunction with the Chroma controls. (even if this does cause the machine to slower).

+) Perhaps the BM team will bring over the FUSION Render window within the View so that NR is only applied to a section of the window so that you can see the effects of the change of controls without having to wait 15 seconds (on my evidently very slow machine)

+) My colour correction was
-> 1 : REDCINE-X : Find a Colour Temp (as the internal Auto White balanced guessed wrong )
-> 2 : REDCINE-X : Find a Tint
-> 3 : RESOLVE : Import clip : (which sets the values in Raw tab) : IPP2 pipeline
-> 4 : RESOLVE : Add Noise Reduction NODE.

As NR was altering the colour .. I was thinking that an additional Colour Correction was required - UNTIL you post that is.

THANKYOU : Turning down Chroma to 0.0 on TEMPORAL and SPATIAL fixed the colour shift.

I can see that there there a skill (which I don't yet have) in capturing the Chroma that does not ALSO capture the colour from your moving image.

AJ

+) GUI Lockups.

-> I have noticed that RESOLVE POLLS at 30% ... when nothing is happening and no GUI changes.
-> If you minimised the Screen - and nothing is happening ... it POLLS at 30%.
-> If you happen to be on a Node with NR enabled ... Any change to NR cause GUI stuttering (mouse getting stuck) until the frame is ready for display (up to 20 seconds).
-> There is a RESOLVE config option to NOT USE the Display GPU for compute. This has NO EFFECT. Either Resolve is Still using the display GPU ... or Resolve is using all the CPUs. (my guess is the latter)
-> I have noticed that Pressing 'Command-D' breaks through the (guessing) Mutex blocking in the Resolve code and Forces a screen update so at least you can see the NODE graph (which is not updated until the NR screen is ready .. and is maybe not the wisest priority choice on BM's part, as after 10 seconds .. you might end up modifying the wrong Node).
-> Mac : I uninstalled Tangent elements - not sure if this will help.
-> TIME MACHINE : MacOs does not allow you fine controls - and has backupd process that wakes up all the time (to index and prepare for Backups). Found a free programs called TimeMachineEditor and have now reconfigured Timemachine backup processing to NOT happen every Minute (this doesn't help with the lockups .. but might have exacerbates RESOLVE’s crashing during DELIVERY?).
-> Trawling through some of the system logs .. it looks like MacOs has protection in place for Apps that spend most of their time MALLOCing. Some of the hangs seem to coincide with other parts of the GUI slowdown (eg in FUSION).

AJ

Another suggestion: drop frame count in TNR from 5 to 2. That might help your lockups. I often use only 1 frame (+/- 1 = 3 frames total).

Great advice.

I will definitely experiment more (and actually read the manual on NR).

Side note : I am hoping that the BM team leverage the GPGPU like functionality in Metal 2.
CTra : If 3000+ threads running (designed for single thread compute) OPEN CL is converted into a handful of threads in Metal2 (designed for multi thread compute) - my Trashcan could well avoid being put inside one ...

AJ