Expected behavior with Premiere's new Wide Gamut color setup?

[joshr70948262]

I am excited to make use of Premiere's new Wide Gamut color setup but trying to integrate my older colour workflow has me confused.

My sequence is set to Wide Gamut (Tone Mapping) and I am using Panasonic v-log footage.

Selecting Panasonic v-log/v-gamut colourspace in the source clip results in an expected behavior- the footage looks the same as if Panasonic's official log-to-rec709 LUT is applied, but when corrections are made in Lumetri, it retains the benefits of the wide gamut- better highlight recovery etc. Perfect.

However, overriding a source clip to rec709 and adding a log-to-rec709 LUT seems to remove its Wide Gamut benefits (highlights respond like the sequence is rec709). Ok fair enough- so the most logical move would be to disable input color management and then apply the LUT...

But disabling input colour management (and no LUT) on the source clip immediately makes it look like it once again has that Panasonic v-log/v-gamut colourspace turned on (though the curves are slightly different). Is this expected behavior?

With no input colour management and no LUT, I would expect the footage to look exactly like its RGB information (ie what it looks like in VLC player) ... so what is happening that I don't understand?

[Kevin-Monahan]

Hey Josh,

Thanks for the detailed post. I let the product team know about your issue. I am waiting back to hear guidance. I hope we can solve your issue soon. Sorry for the frustration.

Cheers,
Kevin

[R Neil Haugen]

There's a whole series of options ... such as whether you have auto detect log on, auto tonemapping, and even whether you have tonemapping before the sequence CM or for the sequence.

So what are the settings in use for auto detect log, auto tonemapping, and whether or not you have input tonemapping on for the sequence? Do you have the Wide Gamut Tonemapped, Limited tonemapping, or no tonemapping?

To get 'full' log look, use the diasble CM option up top. Or you can have Premiere auto-detect log and apply an algorithmic tonemapping, either to the clip itself with sequence Input Tonemapping on, or to the clip as part of the sequence CM, where it's after any color corrections in Lumetri without the sequence input tonemapping.

The options are almost bewildering ... and I could go deeper into this rabbit hole so easily ... lol.

[Kevin-Monahan]

Hi,

Since you have disabled the input color management, Panasonic/V-Log gets to ACEScct timeline unconverted. But there still an output color management that still converts from ACEScct (wide gamut ) to Rec 709 (output color space).

If you want to use LUT for the workflow, you can disable color management at the sequence level. However, if there still an output color management that still converts from ACEScct (wide gamut ) to Rec 709 (output color space)

I hope the response helps guide you. Let us know if you have further questions.

Thanks,
Kevin

[joshr70948262]

Thanks Kevin,

Disabling color management at the sequence level and applying a LUT seems to remove the benefits I was getting with Wide Gamut (Tone Mapping), the highlights respond differently for example.

Is this because LUTs designed for rec709 are clipping information that would otherwise be usable in ACEScct?

[joshr70948262]

Thanks Neil.

To put it another way, I am trying to achieve a 'starting point' that resembles the footage's RGB information (very flat) but retains the Wide Gamut benefits.

Here are my settings. These result in a vivid image that looks nothing like the RGB information. I'm trying to understand why.

[R Neil Haugen]

Preserve RGB., as they note, disables CM on the clip. It's used for pass-through work, where you want the log data to export as log data. So that isn't what you really want.

I still don't know if you want the log-look on your sequence, or to have it normalized?

My suggestion in general would be to use auto detect log, auto-tonemapping in the limited form, wide-gamut ACESss working space, no input tonemapping, and sequence of Rec.709. And to use color space aware corrections.

As then you get the great advantage of the algorithmic tonemapping to Rec.709, but that is applied after any color corrections, which are applied to the wide gamut data.

[joshr70948262]

That's right, I'm trying to get the log-look, but 'preserve RGB' isn't giving me this if the sequence is set to Wide Gamut (Tone Mapping). Instead I'm getting something very vivid, as if the vlog/v-gamut colorspace or some other lut is being applied. Is this an effect of ACEScct in some way?

Disabling color management on both input and output doesn't give me the responsiveness in the highlights as in the same way as if 'Wide Gamut (Tone Mapping)' is present.

[R Neil Haugen]

Now I'm thoroughly puzzled. I'm guessing you want to manually do the normalization then? Or ... what?

While I can normalize any log media manually, and that right quickly ... especially using that Tangent Elements panel ... I normally prefer the algo based options now in both Premiere and Resolve for 'basic' normalization to display space. 

The algos do a very 'fast' normalization, totally safely as they cannot clip, crush, or over-saturate as LUTs can easily do. So as a first step, it just seems faster to me.

If you want full manual normalization from log, then set the working space to wide gamut AcesCCT, and turn off the auto detect log and auto tonemapping. As you will be then able to do your manual normalization process.

[joshr70948262]

That's right, I want manual normalization whilst also retaining the benefits of wide gamut. 

'If you want full manual normalization from log, then set the working space to wide gamut AcesCCT, and turn off the auto detect log and auto tonemapping. As you will be then able to do your manual normalization process.' --->  Yes this allows manual normalization but I do not appear to be getting the ACEScct benefits. For example, pulling the exposure down makes all the white go grey, just like in rec709.

[R Neil Haugen]

Your settings include color space aware, right? I would suggest trying setting the auto detect log on but no tonemapping option on. Setting the sequence CM simply sets the display/export color space, does not affect the working color space.

You might also try the Override-to option to the specific log you are using.

[joshr70948262]

I appreciate your continued suggestions. 
I'm still not getting the results that I expect, other than through 'Creative' LUT option field and selecting ACEScct as the Color Space.
Here's a screenshot board that might shed some light on why I'm confused.

[R Neil Haugen]

Well, that makes two of us. lol.

As going back to your original post, the standard process now of auto-detect, wide-gamut working space, and Rec.709 sequence/output was fine. Your question was it seemed about wanting to get the grayish original log look on a Rec.709 sequence, it seemed. For then to manually normalize.

Apparently that wasn't the question though ... ?

And I'm also curious now as to which Panny camera you were shooting, and which specific in-camera setting and eventual media. As there is a setting in some Panny's that is not actually log-encoded, it's log-ish looking. Low contrast and sat, but recorded as straight Rec.709/sRGB math data, in mathematical terms.

That behaves very differently than the actual log encoded media.

[joshr70948262]

Ah you are talking about Cinelike D. I'm not using that.

At this point I think its going to be easier for me to adopt the new workflow than what I'm trying to do here lol 

I am trying to get that grayish original log look, so I can then manually normalize, apply effects and LUTS all in the style of the old workflow BUT retain the advantages of Wide Gamut. All suggestions tried so far do give me the log look, yes, but seem to nullify the wide gamut advantages. Loading a LUT in Creative *does* seem to give me wide gamut response inside a rec709 sequence, so I know its *possible* - but I shouldn't have to do that. 

To clarify how this fits into my original post: the way I expected it to work is to disable input CM and set sequenec to ACEScct and that's it. It should work. There would be rgb data going into ACEScct. But instead, this results in a very vivid image... (as if ACEScct itself were some strong LUT...I don't understand it). 

[R Neil Haugen]

Disabling CM means Premiere has no clue what color space, nor cares about it. That's the entire point of disabling the CM. For pass-through workflows, for example. So trying to do something mushed in after telling Premiere to ignore color spaces ... not sure how that would work, personally.

Telling Pr what color space you wish to use ...such as the color space choices, or the override to a log format from the many choices ... but carefully not using any tonemapping would be the way you would want to work. Then, using the wide gamut working space, the LUT used in Lumetri would be starting with the wider gamut/dynamic range. Displayed of course in the sequence/export space of Rec.709.

I am curious about the wish to manually normalize. And the use of the old style LUTs ... it's fascinating to understand the whys of what others do.

[joshr70948262]

Because the Panasonic log to rec709 LUTs haven't always seemed quite right to me; enabling the new auto-detect gives me something that seems optically the same (I'm sure its better once I start making adjustments) and I'm not 100% sure I want that as a starting point.

Putting aside my confusion with disabling input cm, we are on the same page-- I understand what is supposed to happen, but once its setup, I test it- I push the contrast up, pull down the exposure to see what happens to the highlights and the image reacts *exactly* like rec709 and not wide gamut.

Overriding the source clip to rec709, even when working in the ACEScct color space, is resulting in a clip that can't be manipulated in wide gamut (no matter the sequence CM settings)... I can override to anything else and get the 'width' of the wide gamut, but then I don't get that grey log look. A halfway solution to this is 'Override to CEScct' which gives me something very vivid, then normalising in a different direction to create the log look. I could then throw my old luts on there or do whatever I needed to do. But that sounds like bad practice lol

[R Neil Haugen]

You are aware, I hope, that the tonemapping does not use LUTs ... it's the vastly superior algorithmic process? As someone who works for/with/teaches pro colorists ... LUTs can be wondrous but ... it's always user beware.

Because they must be precisely fitted for the media in use ... contrast/exposure/sat ... or they can and will crush or clip data.

The algorithms do not crush or clip ... period.

So I tend to prefer the algos either in Resolve or Premiere to LUT based normalization of log media.

And as any normalization routine is by design simply the first step in working a clip, the algo's are as good as any LUT I've ever worked with. 

[joshr70948262]

Yes I am aware; its all the corrections before the LUT that I would like to have the Wide Gamut advantages for. I realise the LUT itself is going to clip values, but all the corrections are happening before the LUT...surely I should see a difference in behavior when playing with the contrast and exposure, which are before the LUT.

I really appreciate you sticking with me on this. I'm going to start using the auto detect algorithmic transform and develop a new workflow based around that instead of pottering about here trying to pidgeon-hole an older workflow. 

[R Neil Haugen]

Yea, the change to the algo-based normalization seems kinda weird at first. Even in Resolve, a lot of colorists stayed with the wide array of LUTs they knew at first. But the algos never clip or crush, and seem to be fairly consistent, so ... they actually create a pretty solid normalization base to start working.

It's of course a different base than what we had before, but actually is a cleaner more repeatable process. Most colorists had a variety of LUTs they would try to normalize each specific media, as per how they were shot, and the scene ... all sorts of things influenced how well any LUT worked with any one specific clip.

Something to remember ... no camera or other capture device senses or records color ... they only record brightnesses. Period.

The "color" we see is the result of amazing engineering, putting an array of colored filters over sensors in the camera, then computing what the 'hue' response of any particular 'pixel' should be recorded at in triplicate RGB data. The same on the other end ... they do amazing things to take digital numbers and recreate something that to human visual systems looks like (mostly) normal color.

That it works at all is amazing, but ... nothing is exactly identical. They can't make all the pixels on one sensor behave identically right at manufacturing. They can't make the colored filters identical even to begin with. And the chips to process things all have tiny discrepancies involved. So they have to compute that also into the system.

You see people say "well, this $250 monitor users the same screen as that $9,500 Flanders, so why pay so much?" .... well, they aren't the same screen. The company making the screen panels tests them off the assembly line ... the ones most even and up to spec consistently across the panel sell for a TON more than the general run of the mill panels, that all have more variances. Then Flanders puts a lot more complicated and expensive planning and parts for getting the signal to that screen.

It's like that all the way through the 'system'. "The same part" sells for different price levels depending on how 'high' it tests. No two cameras, even off the same model line sequentially, will produce identical images ... there will be slight differences. Close, hopefully, but not identical.

And so we have to learn to make all this different mish-mash look enough similar it isn't jarring or perhaps, even really notable.

Oh ... joy.

[joshr70948262]

To anybody else who comes across this- I discovered that in order to get Wide Gamut responsiveness on LUTS you can use the 'Creative' LUT option field and select ACEScct as the Color Space. 

Source clip and Sequence can remain as rec709 but you *must* enable 'Colour space aware effects' in the *sequence* settings for this to work.

You cannot use the Basic Correction option field or the newer Lumetri Colour settings field to achieve this.

For many people, following Neil's suggestions about how to setup colour management, with auto-detect log, is the better option- but if you have LUTs you want to get a wider responsiveness out of, this is the only way I've found that currently works.