Lumetri Color Effect - Unable to make adjustments?

great post Neil...  this forum is an amazing resource.

The process of color management has changed throughout the 23/23.x series. And that can take some adjustments to workflows for any level of work in Premiere. BTW ... I work for/with/teach pro colorists. It's my thing, sort of. I'll include details as of course I don't know how much you know, but many of the folks reading this over time are guaranteed to know a lot less than you do. I'll write so most can follow along.

The type of issue you are getting is when your Premiere CM controls aren't set correctly for the project/media/sequence you are working towards. The controls are in the Lumetri Panel, the SETTINGS tab, the one named Settings.

For most users, if you set up your Premiere color management to do so, you can normalize most S-log3 variants with the built-in algorithmic processing, and skip adding a normalization LUT. Algorithmic normalizations and transforms are safer for your pixels than LUTs, and for most users, this is easily the faster and cleaner way to normalize log-encoded footage.

Most colorists using a normalization LUT put it after the first node or layer of color controls, so they can properly trim the clip into the expectations (and limitations) of the LUT in use. Applying the normalization LUT in the Basic tab is not recommended by any of the many colorists I work for and with. Applying the LUT in the Creative Tab's "Look" slot is technically a better working process. Then go up to the Basic tab to 'trim' the clip to fit the LUT.

Algorithmic and DCTL normalization processes are often clean and safe enough they are applied directly to the clips in the bin or media pool.

As additional data, there are a couple variants (by camera options) for "S-log3" ... that aren't actually log-encoded, they are simply an in-camera process that sets the contrast and saturation way down so it "looks like log". But the encoding isn't actually in logarithmic math. That trips up a lot of users of those mid/lower Sony cameras.

The best setup for color management for most workers in Premiere at this time:

• Display Color management ON
• Auto Detect Log and Auto Tonemapping both ON.
• Set your sequence CM color space to the desired output color space.
• Use ONLY export presets built for the color space of the sequence.

I'll about guarantee that their algorithm will get a slightly different image than your current LUT. Just remember, no normalization process is "the perfect and only CORRECT normalization for X media" ... all normalization processes involve decisions both for technical requirements and aesthetic choices. It's why the makers typically have several LUTs per log variant/camera. It's why so many colorists "roll their own" for many of the cameras they routinely work with.

Or now, with so many normalization variants built into Resolve, and of course all the DCTLs you can make or acquire, they will have normally several options per camera, and apply the one that fits this scene of this project.

In Premiere, it's easy to make Lumetri presets that you can then apply in bulk operations to entire groups of clips in a bin. This gets you to a good starting point fast and easy.

Specific workflows may need to stay with normalization LUTs, and if so ...

Have the Auto detect log on, but leave auto tonemapping off.

Then use the Override-To options to set the normalization process you want to use.

Viewing Gamma Settings

This is something not all that well understood. It doesn't directly affect the encoding of the file at export, only the viewing transform while working in Premiere. So you set this according to your working process and desires.

For non-Mac users, the choice is either gamma 2.4/broadcast or gamma 2.2/web. Which is also confusing. And so often misunderstood.

Set the viewing gamma according to your ambient light environment! Not the intended delivery output.

If you are in that properly semi-darkened room with neutral walls, and it's pretty dark indeed, then use the gamma 2.4/broadcast viewer gamma. This is the recommended working environment for all professional colorists.

If you are in a moderate to brightly lit "office" type environment, use the gamma 2.2/web setting.

The web isn't actually gamma 2.2 for Rec.709 video, that is only for still images. Nearly all software and players on non-Mac systems will default to a display transform of gamma 2.4 for Rec.709 video. But your grading environment is according to the professional standards the determinant for your display transform while grading.

Mac Users ... yeah.

On Macs without Reference modes, the OS will use essentially gamma 1.96 rather than the 'correct' 2.4 for the display transform. And from some super-sleuthing detective work by a couple high-end colorists, they don't perfectly handle putting Rec.709/sRGB color on that P3 Mac screen either. So there is both a tonal difference and a saturation/hue difference from "typical" Rec.709 standards.

So it's pick your poison ... do you only care about viewers with Macs without reference modes that only use QuickTime Player, Chrome, or Safari? Then set the viewing gamma to 1.96/QuickTime. Grade so the image looks good to you in Premiere, and in Qt player, Chrome, and Safari, you'll see something similar.

Understand, everyone else, whether on PCs, Android, broadast compliant setups, and even Macs with Reference modes will see a darker, oversaturated image.

Macs with Reference modes set to HDTV ... will see Rec.709 video with the normal display transform of gamma 2.4. While working, you probably want to stick to the choice defined by your working ambient light ... gamma 2.2 in a brighter room, gamma 2.4 in a darkened room.

Can you try to apply Lumetri on an adjustment layer instead directly applying to the clip?

is this a Lumetri preset you save from an older version of premiere pro?

Try not to use any LUTs, just work with Lumetri from scratch, how does it behave?

if you try the beta version, does the issue persist?

if you haven't done too much work and can roll back to a previous working version,

try and let us know, so that this is confirmed as a bug.