Canon Panny Sony log users: how are the CM transforms working?

[R Neil Haugen]

Now there are transforms for Canon, Sony, and Panny log formats in the Modify/Interpret Footage color management "Override" options.

I'm curious as to how the transforms are working for the various cameras and formats? Any posts of experience would be very helpful!

Neil

[Shebbe]

Hey Niel,

What do you mean exactly with "how the transforms are working"? They simply convert from said camera or display space to the sequence's timeline color space. The only difference it could have versus conversions in other software is the chromatic adaptation model used to convert the white point but I think all the color spaces they have at the moment are D65 so it never converts.

Furthermore there is no tonemapping or rendering intent in the transforms but you know they added a very rudimentary tonemap option checkbox in the sequence settings which doesn't solve at all the goal of mapping camera scene referred to display. To me it sounds like they just wanted a quick band aid to 'fix' Rec.2100 HLG material from iPhones for SDR video distribution...

This is what SGamut3.cine bright blue light capture looks like with tone map enabled. Not very pretty 🙂

At it's current state there is no point in using it. Even the most incorrect and inconvenient way of just creating your own curve and adding in saturation will probably yield better results.

[R Neil Haugen]

Exactly what I said ... I wanted to know how the transforms were working for the different log formats in practical use for different users.

They apparently may have some tonemapping involved in the transforms, from conversations I've had with the devs. It can be hard to suss out, as they try and qualify about everything. But ... I think tonemapping is part of at least some of these transforms. Especially the HDR to Rec.709 things. But even some of the log-x to y color space may have some tonemapping involved.

I'd love to have that clip to test on my rig. I've done quite a few S-log3.cine clips testing, and have found most of them to work quite well to get within the necessary timeline space. Not perfect, but totally usable without crushed/clipped or over-saturated pixels.

I know even Resolve can't handle a lot of the colored LED light setups. So I'd be testing that both in PrPro and Resolve.

And ... to get proper exports, for so many things now you need to use the new CM controls. Most log-encoded or HLG clips have to be user-set in the Project panel to be able to export on a Rec.709 sequence in any usable form.

Past that ... yea, I tend to roll my own normalizations ...

Neil

[Shebbe]

Ah you meant working out for users instead of working 🙂

Yea I don't know, we have iPhone HLG footage coming in quite often. We change their colorspace to Rec.709 to match your timeline so the operation nulls. Wish they'd add a disable management option though similar to PerserveRGB in AE otherwise it will still treat it as Rec.709 and convert again if you place it in an HDR timeline instead. Totally broken. 

But anyway, after the disabling we use a LUT of the DaVinciDRT HLG to Rec.709 Gamma 2.4 so we can include tonemapping. We can grade under the LUT for further adjustments. Actually pretty much the same as we handle any other log encoded material when managing/grading in Premiere

We'll likely switch to ACES if OCIO will make it to Premiere Pro and ACES 2.0 releases and stay away from what Adobe is doing at the moment.

The current conversions + tonemap impelmentations don't really clip anything as Premiere operates in 32bit float but having to do half of what is supposed to be the task of a solid display rendering transform in grading is very clunky and counterintuitive especially with the crude tools we have available like Lumetri Color where most of the controls are designed to operate only on 0-1 range.

[Shebbe]

PS. Sorry, I can't share that clip as it's property of a client hence the crop. If I ever have some test material happy to share.

But if you're curious, this is what it looks like through the DaVinciDRT. 

I'd say a pretty good job as the clipping or clumping against the target display hull doesn't really feel that harsh. And the desaturation towards the core is not physically accurate but a welcome side effect of the type of DRT (or it was engineered) to simulate higher brightness than the brightes color the target display can show.

[R Neil Haugen]

Definitely a better presentation. Not surprisingly since it's well, a major grading app. It better be better, right?  lol

Premiere is an editing app with some color capability. And they're (thankfully) trying to bring it into the Modern Era for user color management controls. It's come a long way in the last couple years ... but has a long way to go yet for 'total' color control.

If you back the sat off a bit, can you clear up that image in Pr at all? Curious.

Neil

[Shebbe]

Yes ofcourse you can lower the saturation but doing so reduces it for that hue on the entire range if done with simple math like global HueVsSat curves. What you want is a solid way to tonemap the captured dynamic range and compress the gamut in such a way that you can retain as much information as possible without clipping/sticking to the edge of the display as soon as you hit it. Desaturation towards white is the 'obvious' fix and behave similar to shooting film, but not always the most beautiful for what you're trying to communicate.

But at least you want a DRT to be robust, works 99% of the time, and also have tools available to the artist to manage such outliers like a gamut compressor. Especially for data that is not even on the spectral locus which most cameras have.