ProRes RAW linear 2020 to LOG?

[joe-scotto]

Hi, I'm trying to convert my ProRes RAW footage with this tool but it doesn't seem possible.

The footage itself is Rec.2020 PQ

[joe-scotto]

Below are my settings in LUTCalc, this gives a decent result but does not match the linear to LOG conversion from FCPX.

The left is the LUTCalc LUT and the right is the FCPX conversion, both are S-Log3 / S-Gamut3

[cameramanben]

Hi Joe,

that looks to be a scaling issue. Try setting 'Input Range' to 100%. that should normally be the setting for linear / conventional gamma files, and should draw the S-Log3 highlights down as per the Final Cut side, and potentially give correct shadow detail.

I'm prepping some updates, so will check the circumstances where LUTCalc doesn't automatically set linear ranges.

My initial LUT experiments involved testing in Resolve, which tries to automatically rescale clips to what it thinks appropriate for grading on the waveform. As I started developing LUTCalc I realised that different bits of software and hardware sometimes rescale, sometimes do not (eg Adobe CC), and I tried to keep a tab on how different apps approach things.

I've generally set things according to my own software use, and from people getting in touch with stuff I don't have.

As I say I'll check out the linear range stuff before committing some updates, including the option to increase LUT fixed point precision for linear output.

Thanks,

Ben

[cameramanben]

Depending upon your use case, it might also be worth separating the gamma and colour elements into separate 1D and 3D LUTs.

Linear input on a LUT means lots of interpolation in the shadow stops, much less in the highlights (compared to the whole point of log being efficient distribution per stop), and considering your -1 - 16.3 input scaling a 1D linear to S-Log3 (100% to 109% ;-) ) at 4096 or 16384 (for 16-bit RAW) followed by a 3D S-Log3/Rec2020 to S-Log3/S-Gamut3.cine (109% to 109%) at 32x32x32 should give a much more precise result for grading.

Thanks,

Ben

[cameramanben]

On second thoughts, it might be better going 3D linear to linear (100% to 100%) Rec2020 to S-Gamut3.cine first, followed by 1D linear to log. Let me know if you give either way a try,

Ben

[joe-scotto]

Hi Ben,

I ended up getting really close by using the following settings:

I don't have the option of using 1D LUTs because I'm in Premiere. Would a 32x32x32 .cube get me close enough to be accurate, it seems close enough on my end but the technical side I'm not too sure. In addition to that, I'm not too sure what exactly the -1 and 16.3 scaling values are doing or if those are correct. I definitely need that in order to prevent clipping but other than that I'm not sure that the values are right.

As a side note, it would be great to see Nikon N-Log added to LUTCalc, there is a spec sheet available here

[nick-shaw]

Premiere does support 1D LUTs. It just doesn't support 1D + 3D in a single .cube file. The domain declaration in Adobe / Iridas .cube files is different to that for Resolve .cube, so you need to make sure you build a "Lumetri / Speedgrade" 1D LUT.

You can build a 1D linear to S-Log3 LUT and put that in Lumetri's Input LUT slot, and then a 3D S-Log3 to S-Log3 LUT with the colour space conversion, and put that in the "Creative" LUT slot.

[joe-scotto]

@nick-shaw Oh wow, thank you!

Do you happen to know if the -1 to 16.3 scaling is correct for linear?

[nick-shaw]

If your source is PQ then there is no point in going below zero. PQ is undefined for negative values.

As for the 16.3, S-Log3 encodes 38.42 linear as 1.0, so in theory you might need to go up to that. But it depends where your source image data comes from. You could examine that and find the clipping point in linear. Covering a wider range than necessary will obviously reduce the precision of your LUT.

[nick-shaw]

I notice that you are looking to convert images that were originally PQ 2020 to S-Log3. I obviously don't know the detail of your workflow, but bear in mind that PQ is display-referred, and S-Log3 is scene-referred. Normally when converting scene-referred to display referred some picture rendering is applied (e.g. the RRT in ACES). Going the other way you may need to invert that, which makes it tricky when you don't know what (if any) picture rendering was applied.

[joe-scotto]

@nick-shaw

To my knowledge I was incorrect on it being PQ, the specs for ProRes RAW aren't very clear.

To give you some background, I'm essentially trying to mimic what FCPX and Assimilate Scratch do with ProRes RAW which converts it to LOG (specifically S-Log3 is what I use mostly). The problem is that Premiere Pro offers no such option so I have to create LUTs via LUTCalc in order to do this.

I've narrowed it down I believe to where the ProRes RAW itself is just linear 709 gamma and 709 gamut so that's simple enough, finding the clipping point I'm not sure exactly how to do though. I think once I get that clipping point the rest should fall into place. I tried the approach with separating the gamma from the gamut and it worked very good, it's just the specifics that I need to figure out now.

What would you do in order to figure out the clipping point, just trial and error with the input/output options or is there something I can do in Premiere/Lumetri?

I really appreciate all your help so far with this!

[cameramanben]

Hi Joe,

In Premiere, when you use the Lumetri plugin, you can put a LUT under basic correction and a second under 'creative'->'look' if you are not already using it. Equally, if you want to keep it in one LUT 64x64x64 would probably be a better bet.

I missed the bit about PQ - my bad. However, looking at your test image and the fact that you have -1 to 16.3 input scaling (assuming that scaling is being used) it looks as though the LUT is being fed a linear input (as you have set up in LUTCalc), but that the range is screwed up making things brighter than expected (and clipping the input shadows - your -1.0 setting). I'd expect a PQ input to give a very dark image with the LUTCalc settings you have there.

If you do have a pure linear input, then a value of 0.0 is black, -1.0 is WELL into super black, 0.18 (with the setting you have) is appropriate for an 18% gray target, 0.9 is a 90% white target (the finely calibrated bit of file paper or t-shirt we tend to use on shoots ;-) ) and 16.3 is log2(16.3/0.18) = 6.5 stops above the 18% gray target.

I don't know what camera you are using, but 6 stops is the ballpark of Sony / Canon / Arri / Varicam headroom, so if you have fallen upon -1 to 16.3 that sounds a lot like it is a linear signal with an incorrect input range. 0.0 - 11.52 with 100% range should be worth a pop (log2(1152/0.18) = 6 stops).

Nick mentions 38.42 as 1.0 on Sony S-Log3, but in reality Sony is very strict about their cameras (OK, I haven't checked with a Venice ;-) ) feeding values more than 6 stops above mid gray. That's 94% Ire / 10-bit 886, on the range that Nick mentions (886/1023) = 0.866.

That is not to say that 38.42 is not the way to go, but if 16.3 comes from experiment it does sound like the ballpark of a 6 stop camera with the LUT input range up the fritz. I need to revisit Premiere presets - it has been a while since my last update!

Ben

[cameramanben]

Joe,

one last thing. LUTCalc (and my own brain) is very much scene-referred. Gammas are converted to a linear scale based upon the levels in the original scene (gray card, white file paper). As Nick mentions, coming from display referred (eg PQ) things get difficult.

Thanks for the N-Log tip - love a good white paper, I'll be straight on that, and i'm Nikon all the way for my stills!

Ben

[cameramanben]

Joe,

it's my anniversary and we've just been out to lunch. To shorten the waffly drivel, try this and let me know how it goes:

Ben

[joe-scotto]

Happy anniversary, I won't keep you any longer and will just post what seems to be working.

1. The first thing I do is convert to LOG via a 1D LUT. Turns out that Premiere actually decodes to Gamma 2.4 in order to match the timeline.
2. After converting to LOG, I then convert the color space with a 3D LUT.

I'm not too sure about the slight difference between the two but I believe that's due to the discrepancies in how the two programs handle the footage on the timeline. I think FCPX is doing something with exposure because if I bring it up to match in Lumetri, the two are identical. I might play around with the stop correction in LUTCalc because it seems to be about +0.6 exposure in Lumetri to match.

I'm going to rely more on the Premiere conversion since I'm at least 95% sure my inputs are correct (when in regards to how Premiere handles ProRes RAW).

As for what camera I shoot, it's a Nikon Z6 (hence my request for N-Log 😄 )

Thank you both @nick-shaw and @cameramanben for all your help on this, I think I'm going to settle on these settings for the time being as they seem extremely close!

[cameramanben]

Thanks for the update Joe and glad you've got it working!

I need to make sure that the linear and basic gamma options click to 100% on the Lumetri preset. Thanks for bringing it to my attention,

Ben

[cameramanben]

One last thing you might try now that things are, er, a little clearer in my head. Try setting the input scaling on the 1D to 0.0 to 4.779. Depending upon how Premiere feeds values into the LUT, I have a feeling that that will account for the brightness difference.

As Nick mentioned, 1.0 (or 10-bit 1023) in S-Log3 maps to 38.42 linear and actually that would probably have been the appropriate values if your input was scene linear / gray @ 0.18 (rather than my 11.52 suggestion), but in a 2.4 gamma 1.0 in S-Log3 maps to 4.779.

Ben

[joe-scotto]

Same exposure difference still, I really think that's just a byproduct of the timeline export and not an issue anywhere else. Everything else looks identical, it's just roughly a half stop off.

How exactly are you finding the input number? For example if I wanted to switch to C-Log2 or V-Log, how would I find the appropriate input number for that... is there just a formula I can plug values into?

[cameramanben]

Thanks Joe, that is actually reassuring. It actually means that Premiere is handling input scaling as I have always thought, and as such you don't see a difference between input scalings, provided they are at least as wide as your camera's dynamic range.

As such, I wasn't giving duff advice on the 11.52 for linear (@ 0.18 gray, 12.80 @ 0.2 gray) with 6 stops headroom. Phew!

Linear to log is not my usual way around, but going back to the reason for suggesting a separate 1D LUT, for a linear input the less wasted space in the input highlights (ie values your camera won't provide), the better interpolation should be in the shadows. That would certainly be the case for a 3D combined gamma / colour LUT or a small 1D LUT, but with your 14-bit, 16,384 point 1D LUT as you point out all those input scales are giving the same result.

I get the values by knocking up a 1D cube LUT the other way around (log to linear or 2.4 gamma) leaving input scaling be (0.0-1.0) then reading the last value in the file. cube LUTs are text files, so human readable in a text editor. I'll have a think about adding a display of input / output peak levels to LUTCalc, once I've added N-Log ;-)

Ben

[cameramanben]

Hi Joe,

I've just pushed some updates to a 'testing' version: LUTCalc 3.3 Beta 1

I've added the Nikon N-Log (and added Z6 and Z7 as presets) and hopefully made the Lumetri preset go to more appropriate scaling for linear inputs and outputs. Other stuff as well, but those are the pertinent ones to this thread,

ben

[joe-scotto]

Awesome, that looks to work pretty well!