Using Gamut Limiter doesn't produce LUT to save as file

[evilstiefel]

I've been trying to use LutCalc for the purpose of just converting gamuts without touching the gamma at all (I use a Sony a6300 and sometimes I just shoot in Cine4 which isn't currently supported in LUTCalc as a Rec Gamma).

For these purposes, I simply set the Rec Gamma to the same as the Out Gamma (which in my understanding shouldn't touch the luminance or adjust the gamma in any way) as a workaround.

Still, when e.g. trying to convert S-Gamut3.cine to Rec709, especially comparing it to results that Davinci Resolve would produce, I get clipped colors (especially in orange tones). Since you introduced the Gamut Limiter for these purposes in 2.90 (I'm running the Chrome App 2.91 on Windows), I wanted to give it a go.

As soon as I set the checkbox though, clicking "Generate LUT" doesn't open the popup to save the file anymore.

Maybe I should open a different issue for the difference in color space conversion. This is just to point out that the new option doesn't appear to be working for me.

[nick-shaw]

For these purposes, I simply set the Rec Gamma to the same as the Out Gamma (which in my understanding shouldn't touch the luminance or adjust the gamma in any way) as a workaround.

To do a colour space conversion, even if you are not changing gamma, it is necessary for the gamma of the source to be set correctly. A colour space conversion requires a linearisation, followed by a 3x3 matrix, followed by adding "gamma" again. If the source gamma is not set correctly, the linearisation will not be correct, and you won't get the right result.

[cameramanben]

Hi evilstiefel,

about the 'Gamut limter' bug. Thanks for spotting that! No idea how I managed to include this bug without spotting it. It's a variable name typo in the output code which doesn't get used for the preview. That's why the preview window (and vectorscope) show an effect, but trying to generate a LUT with 'Gamut Limiter' causes a hissy fit.

Already fixed in my computer, I'll have that in an update as soon as I can.

As Nick says, for a straight colour space conversion, the gamma settings need to match each other and the original recording, for the correct linearisation before conversion. The input and output ranges should also match the recording, for the same reason.

You can probably leave this post at that, but diving into the deep end...

Resolve has always been a bit of a headache to me. The 0-1023 scale on the side of the Resolve waveform is just a guide and can actually be misleading if thought of as 10-bit recording values. Depending upon setup 0 can mean 10-bit 0 or 0% IRE (i.e. 10-bit 64). Consequently, the 1023 at the top may refer to 10-bit 1023 in the recording, or 100% IRE (10-bit 940). As such, LUT Range settings for Resolve are dependent upon what 'auto' decides unless you manually set clip ranges in Resolve (Sony has a workflow paper which explicitly recommends setting Sony log clips to 'data' in Resolve; the Sony looks included in Resolve under 3D LUTs expect that).

Personally I'm more of a CC person than a Resolve one, so I haven't been playing around with 12.5 as much as I probably should have. Looking at it now, I see that Resolve seems to be rather stricter with the 'auto' range setting than in the past (and ditched the word 'data'). Feeding some F55 XAVC footage in, plus some 12-bit C300mkII RGB footage, I found that it doesn't seem to be keen on disabling the 'auto' range (as was Sony's recommended workflow).

In my terms (sorry Nick!), the way that Resolve 12 seemed to want LUTs out of the box with the footage I was importing was legal in to legal out. With S-Log3/S-Gamut3.cine this means trying legal in to legal out in LUTCalc.

You can quickly tell if this is right by shooting a clip with the lens cap on. Black in S-Log3 is 10-bit 95, so if Resolve is showing the full 'data' or extended range on the waveform, you should see a line around 95 or a little above on the scale. That would mean data in to data out in LUTCalc for your purposes.

Now, 95 is (95-64)/8.76 = 3.54% IRE. Going by Resolve's wonderful insistence upon a 0-1023 scale on the waveform, that would appear to be (3.54/100)*1023 = 36 on the waveform scale. If black looks to be around there with your S-Log3 footage, set input and output in LUTCalc to 'legal'.

With extended logs such as S-Log2 and C-Log1 / C-Log3 an added point is that you would need to include a bit of input scaling, so that values beyond 100% IRE don't get clipped. Using the 'DaVinci Resolve (.cube)' preset as it stands, that means putting 1.09 into the 'Max' box.

I think that I need to add a second Resolve preset (i.e. Resolve 12+) to simplify all this.

Sorry for the waffly answer and thanks for picking up on the bug!

Ben

PS I'm overhauling the interpolation code to be quicker and clearer with potentially a better approach to extrapolation (it is something I've put off for far too long ;-) ), so along with the time it takes to be passed by app stores the update might be a little while, but I should have something uploaded online to LUTCalc testing pretty soon.

[evilstiefel]

Makes sense - I guess also for the purposes to determine saturtation etc for colors in darker vs brighter areas, for a neutral reference among all gammas.

Means I will be out of luck to get "correct" color conversion unless the specific gamma for Cine4 is supported?

Regarding full swing vs. studio swing, I've definitely noticed these effects on some clips, but if you specify (with the somewhat new Color Science setting Davinci Colormanaged YRGB ) the source file gamma to be SLog3 and color space S-Gamut3.Cine, you don't need to worry about applying LUTs for conversion purposes anymore - with one caveat: I guess Davinci Resolve's mathematics assume a certain exposure, which results in wildly "overexposed" results when importing footage that was shot in SLog3 that is overexposed on middle grey (as opposed to Sony's exposure recommendation).

For that reason, I have this weird mixed workflow right now where I set source gamma to Rec709, source gamut to S-Gamut3.cine, let Davinci Resolve handle the color conversion, and then just apply a 1D LUT from LUTCalc afterwards to get the luminance levels right with exposure compensation without having to fiddle around with the wheels in Davinci to bring it down with their included interpretation.

That doesn't even include my dilemma with Cine4, since I can't always shoot in SLog3, especially then the scene doesn't require the super flat curve of a log profile - it's an 8-Bit XAVC-S codec after all, and I don't want to waste half of my tonality values for portions of a curve that doesn't have any information in it.

Sorry for this kind of convoluted and waffly answer in return ;).