DaVinci Resolve and ML Raw

[baldavenger]

I put together a small set of LMTs for editing photos in Resolve

The ACES TOOLS set consists of the following:

IDT_INV_REC709
IDT_INV_SRGB
LMT_DNG_OFX
LMT_COLOR_BALANCE_OFX
LMT_HSL_OFX
LMT_HUE_VS_LUMA_OFX
LMT_PFE_OFX
LMT_PFE_OFX_NEUTRAL



LMT_DNG_OFX helps with images that are a little compressed in the shadows.










LMT_COLOR_BALANCE_OFX, LMT_HSL_OFX, and LMT_HUE_VS_LUMA_OFX emulate some of the controls familiar to users of Photoshop and Camera Raw. They can be used separately, or in conjunction with other LMTs (including LMT PFE)


https://github.com/baldavenger/DCTLs/tree/master/ACES%20TOOLS

The tools work with either CUDA or METAL in Resolve 15 and upwards.

[baldavenger]

This video covers some of the LMT PFE OFX DCTL code.

https://github.com/baldavenger/DCTLs/blob/master/ACES%20TOOLS/LMT_PFE_OFX.dctl

[allemyr]

I looked into the effects of extending the White Level value in the DNGs metadata. With 5D MkIII footage it is 15000, which is mapped to the value 1.0 in Resolve. The reasons for White Level being lower than the full 14bit limit (16383) are well documented - Peak Saturation, non-linearity past that point, magenta cast - but when Highlight Recovery is enabled these extra values come into play anyway.

I ran some tests with DNGs whose White Level I altered using Exiftool. There were three varieties: Normal 15000, Full 16583, and Bright 10000

In Adobe Camera Raw they appeared as expected, with Full 16383 slightly darker than Normal 15000 (due to the values being mapped lower to accommodate the additional 1383 values) and Bright 10000 much brighter in keeping with the fact that the lower value is mapped to peak white thereby raising all values accordingly.

Using the Exposure and Highlight controls it was very easy to bring back the highlight values that got clipped or heavily compressed, so in this case the White Level is really just a convenient guideline for Adobe Camera Raw to map Peak White, and no actual raw data is compromised by altering the metadata.

In Resolve it is a somewhat different matter. When the three DNGs are initially brought in the appearance is more or less the same as in ACR, but then using controls like Exposure and Gain to bring back highlight detail it is revealed that this information has been clipped, with Bright 10000 clearly showing the missing information. Only by enabling Highlight Recovery is that signal information brought back into play, but only though whichever algorithms Resolve uses to rebuild signals.

Now, even with Highlight Recovery on Full 16383 Resolve tries to build more highlight detail, even though there is no reserve signal to call upon. I prefer to use the signal splitting techniques mentioned earlier in the thread to do highlight rebuilding, but that can be combined with Highlight Recovery to increase dynamic range if done judiciously. The less of a signal Highlight Recovery has to anchor to initially, the more control you'll have overall, which is why I now recommend (for those using Resolve and willing to put in the extra work in order to achieve superior results) that you change the White Level of your DNGs to their max, which is 16383 for regular and 65535 for Dual-ISO. This process will involve the Exposure control to scale the signal such that the exposure value of a white diffusing reflector is 1.0

This is a deliberate attempt to take the DNG process away from its originally intended display referred/stills approach, and adapt it towards a more scene referred/film approach like that of Cineon and LogC.

With the sterling aid of the two Daniels (@Danne and @dfort) I've been able to convert with relative ease the White Level of both DNGs and MLVs.

Code: [Select]

$ exiftool -IFD0:WhiteLevel=16383 * -overwrite_original -r.
Is a quick and dirty way to convert every DNG in the folder (and subfolders)

Code: [Select]

echo "0000068: FF 3F" | xxd -r - Input.MLV
Converts the White Level in the header of a MLV. Very handy if you're using MLVFS in combination with Resolve.
@dfort figured out the code and the HEX values needed.

15000 = 98 3A
16383 = FF 3F
10000 = 10 27
60000 = 60 EA
65535 = FF FF
30000 = 30 75

I finally have read thru the thread once and twice, haven't understand everything yet. Thank you very much for this tip! It looks better in Resolve with the 16000 ish white level. What do you think about the 2048 black level on the 5D3? I use pre tone curve still, the image looks overall better now, thx!

[baldavenger]

What do you think about the 2048 black level on the 5D3?

I wouldn't mess with the black level value. It will screw up the white balance, and more than likely you'll just be introducing more noise into the shadows. However, you can experiment with the raw white and black levels in MLV App to see for yourself the effect.

[baldavenger]

Demonstration of some of the LMTs in ACES TOOLS, as well as an approach to grading CinemaDNGs in ACES

https://github.com/baldavenger/DCTLs/tree/master/ACES%20TOOLS


https://github.com/baldavenger/BaldavengerPlugins/blob/master/Frequency.ofx.bundle.zip

[Danne]

This is highly interesting. You have done some serious work on this. Thanks for sharing.

[Kharak]

Very nice tools baldavenger.

I've been using your Frequency separator to deal with moire, very easy to remove the color cast of moire with YUV or LAB, but do you know a way to deal with the spatial frequency of moire? Maybe someway to trick Resolve in to Baselights texture management?

I feel like there could be something better than masking and blurring it away, as it just looks blurred. Any ideas?

[baldavenger]

Very nice tools baldavenger.

I've been using your Frequency separator to deal with moire, very easy to remove the color cast of moire with YUV or LAB, but do you know a way to deal with the spatial frequency of moire? Maybe someway to trick Resolve in to Baselights texture management?

I feel like there could be something better than masking and blurring it away, as it just looks blurred. Any ideas?

It's a tricky one, because the spatial frequency you speak of i.e. high frequency pattern, is often burnt into the image by the time you get to grade it. You can be quite aggressive with the colour component of an image without fundamentally altering the perceptual structure, but even the slightest adjustment to the luma component stands out a mile.

The Frequency Separation OFX Plugin only has the option of sharpening high frequency data. It's literally applying gain to the isolated image data, and because the values lay either side of 0 this is, in effect, a pure linear contrast. If the parameter (which returns a value between 0 and 3) would also have the option of returning a negative value, then this would allow for reducing sharpening (contrast) of the high frequency data, therefore blending it back into the low frequency domain. However, it may not produce the effect you're looking for and, to be honest, it's never going to be a simple task. If it's hardcoded part of the luma signal then it's a VFX removal job (and all that entails).

[Danne]

I have an issue where cdng sequences will not embed teh folder/dng files into one movie file like was the case before. I´m on resolve 15.3.1. I search the web and there´s mention of ditching cdng format in favour of bmraw, resolve own raw format but will this include davinci resolve not even reading cdng files as before too?
Tested cdng sequences produced in mlv app and in Switch. Only opens single files. Or I can open all files in the folder and it´s treated as a sequence but the smooth folder embed workflow seems gone?

[Kharak]

i think of two posibilities.

Its either the naming of your folders/files, because with your windows batch converter, which has resolve naming, it works. Or you checked the import setting that makes images being imported individually and not sequenced, i dont remember where that setting is. I believe its in the media window somewhere, you click the (...)

Ps, you should stay on 15.3.1 it is way faster and stabile compared to ver 16 with cdng. Also the layer mixer when applied to a timeline node does not work properly in the versions after 15.3.1 and reverting back to 15.3.1 does not fix it, once you brake it you lose it.

[Danne]

i think of two posibilities.

Its either the naming of your folders/files, because with your windows batch converter, which has resolve naming, it works. Or you checked the import setting that makes images being imported individually and not sequenced, i dont remember where that setting is. I believe its in the media window somewhere, you click the (...)

Ps, you should stay on 15.3.1 it is way faster and stabile compared to ver 16 with cdng. Also the layer mixer when applied to a timeline node does not work properly in the versions after 15.3.1 and reverting back to 15.3.1 does not fix it, once you brake it you lose it.

Shoot. I just upgraded...
I can't seem to find that particular import setting. I try to import by choosing 'import file'. Other ways to import?
Dang. Noob...

EDIT:





EDIT2: OOOps! HAd to go through media storage. Simply importing file not working the same. SOLVED!

[Dmytro_ua]

you should stay on 15.3.1 it is way faster and stabile compared to ver 16 with cdng.

I don't see the speed difference. The only one is 15's version uses GPU by default (a dedicated Graphic Card) and 16's ver it may choose an internal Intel GPU.
You should change it in preferences.

[DeafEyeJedi]

Has this been tested on V.16 (while running on Catalina) or am I better off leaving it in V.15 for DR re: on OS X?

[timbytheriver]

@baldavenger

Hi Paul

Firstly, thank you for your development and a highly informative read here.

I'm continuing this discussion from over on the MLVApp thread here: https://www.magiclantern.fm/forum/index.php?topic=20025.msg225175#msg225175

With help from @ilia3101 I've taken the CTL data from the test results in this thread *edit* https://acescentral.com/t/results-from-an-idt-evaluation/2229 and translated it into DCTL. Now I have some questions!

1) To what extent do your existing tools offer this already? (e.g. An IDT or DCTL for 5D3 ML raw to ACES in Resolve). I have your ported DCTL files installed and am not sure whether they cover the same ground, or exactly which DCTL to compare.

2) With the translations we have done today (from the data on that acescentral link above) the files look very biased towards purple. Can you spot something amiss in the translation?

Cheers!

[henrikolsen]

2) With the translations we have done today (from the data on that acescentral link above) the files look very biased towards purple. Can you spot something amiss in the translation?

When trying these out today in Davinci Resolve 16.1, I'm noticed a difference in color rendering using the DCTL between applying it through

1) A right click on the clip, choosing Davinci CTL (very purple, at least the blues)
2) A DCTL transformation node (much better, perhaps still too purple blues, very early and fast test)

Just a heads up. If the difference is an error in Resolve, I don't know.

[ilia3101]

Just a note for everyone - looking at aces on your rec709 monitors is not going to show anything related to true colours. It will look wacky and purple/green.

@timbytheriver Have you tried applyuing an ACES to rec709 conversion to your images?

[henrikolsen]

If you have rec709 as output in Resolve in the ACES workflow, colours are being converted for you on-the-fly, no problem.

[ilia3101]

Okk, don't know anything about davinci resolve myself

@ ilia3101 Yay! It works. Awesome work. Thank you!

If this is what the ACES converted to rec709 looks, it is wrong. While I don't know what the scene looked like, I don't believe it looked like that.

If that is just the ACES being viewed, then I could believe it is correct. It always looks wacky like that.

[Luther]

PS This is the dropbox link that has all the sensor data files in: https://www.dropbox.com/sh/xepdrlu8qtubhhl/AADR_QuBf5Sn2WO7lp5MDNGOa?dl=0

@timbytheriver where did you got this link? AFAIK, it's not on the acescentral thread...
The result above looks decent for a quick experiment. Would be nice to have a reference rendering (direct Rec.709 output). Also, the data from the link above is in D65? This might be the cause of the purple-bias.

[ilia3101]

The link is on this thread https://acescentral.com/t/results-from-an-idt-evaluation/2229/15

[Luther]

The link is on this thread https://acescentral.com/t/results-from-an-idt-evaluation/2229/15

Got it. I didn't see it there the first time I read, my bad.

[henrikolsen]

I have made screenshots of how the Macbeth Classic colour chart renders using the DCTL (3200K), using the .CR2 from the Canon 5D III folder in the mentioned dropbox link where the spectral measurements were done.

Unfortunately I cannot see how to attach the images in this forum.

The colours don't look right, they go purple and green.

Screenshots include misc relevant settings in Davinci Resolve.

[Luther]

Unfortunately I cannot see how to attach the images in this forum.

Use the tag img:

Code: [Select]

[img=https://example.org/0.png width=640][/img]

[henrikolsen]

Use the tag img:

Code: [Select]

[img=https://example.org/0.png width=640][/img]

OK, I thought they could be hosted in this forum, and not have to be uploaded somewhere else.

[timbytheriver]

I am asking some questions on the acescentral thread re this IDT/DCTL issue. Will report back here with any pertinent findings.