Now in Beta: Dramatically updated color management in Premiere Pro

[Alexis Van Hurkman]

We’re pleased to bring to public beta some dramatic improvements and expansions to the color management experience, tailored specifically to the needs of the Premiere Pro editor. With the right source clip metadata, color management automatically adjusts the color and contrast of each clip in your sequence so that every source clip from every camera is converted into a shared color space for further adjustment, and then output to the color space of your choice with automated color space conversions, tone mapping, and gamut compression creating high-quality output with the correct color.

In this new version, color management becomes more automated, handles more formats, preserves more image data, and gives you more flexibility to choose just the right workflow for your needs, even turning it off either partially or completely if you would rather work manually using Input LUTs, Creative LUTs, and effects.

After installing the public beta, your default Premiere Pro experience shouldn’t seem that different from before, but there’s a lot under the hood to explore. Here’s a rundown of the new features we’ve made available when using Premiere Pro color management:

• Each sequence’s color management is easily configurable in the Sequence controls of the Settings tab of the Lumetri panel. By default, color management works similarly to the Premiere Pro color workflows you’re already used to when using the default Direct Rec.709 (SDR) preset. Alternately, you can choose to use one of our wide-gamut color processing presets to maximize the image quality of all grading and timeline effects when using wide-gamut or wide-latitude source media. Regardless of how you choose to work, Lumetri and other effects have been made color space aware, so they work well in any preset.
• Users who don’t want to use automated color management can now turn it off from within the same Color Setup menu. This is useful for pass-through workflows when you don’t want the color space of media being processed at all, or when engaging in traditional display-referred grading workflows using LUTs and manual adjustments.
• Premiere Pro now automatically color manages camera raw media, including Apple, ARRI, Canon, RED, and Sony raw media formats. As long as color management is enabled, raw clips will be automatically processed.
• The Override Media Color Space menu has been expanded to support even more color spaces for more cameras and formats, making it easier than ever to color manage media that were either recorded or transcoded to standard file formats such as QuickTime and MXF, without needing to track down the right input LUT.
• For clips you don’t want to be automatically color managed, a new Preserve RGB setting in the Color tab of the Modify Clip dialog prevents input to working color space conversions, allowing you to manually convert clips either using LUTs or manual filter adjustments.
• Program Monitor, Video Scopes, Transmit, and Media Export all output the image as it appears after conversion to a new Output Color Space setting. While the working color space lets you choose how media is processed, the Output color space lets you choose the specific color space you want to monitor (SDR, HDR PQ, or HLG) and deliver your program to. This guarantees that the working color space never needs to be changed, while making it easy to change color spaces at any time to create multiple deliverables using the same grade (e.g., delivering both HDR and SDR versions of the same sequence).
• Improved tone mapping algorithms and new gamut compression settings improve quality when automatically converting wide-gamut source media to standard dynamic range. Additionally, there are now two ways  of using tone mapping, on input or on output.
• Premiere Pro color management has been improved to enable smoother interoperability and color consistency using Dynamic Link for round-tripping color managed sequence clips between Premiere Pro and After Effects whenever you use the Replace with After Effects composition command.
• Last, but certainly not least, if you import projects and sequences created in older versions of Premiere Pro that have grading and effects already applied, these will automatically be configured to appear the same as before, while the color management will function exactly the same as before. If you decide you want to override these legacy settings and use the new color management, you can override the custom settings the sequence was set up with and choose a different color management preset (and you can use Undo if you find this was a mistake).

As you can see, color management in Premiere Pro has become quite a bit more sophisticated. However, the best way to experience this is by upgrading to the public beta, creating a new project, importing some media, and experimenting for yourself:

• By default, new sequences use the “Direct Rec.709 (SDR)” preset with the output set to Rec.709. This preset is best used when most of your source media is SDR but you’re importing some wide gamut camera raw or log-encoded media as well, and will give you the most familiar color handling experience.
• If you want to try working completely manually, you can open up the Sequence Settings and set the Color Setup menu to “Disable Color Management.”
• If you’re more adventurous, you can change the Color Setup menu to “Wide Gamut (Tone Mapped)” to try using the wide gamut workflow we’ve created to maximize the quality of sequences using primarily wide-gamut media.

As you experiment with the new color management options, be sure to share your questions or comments in this forum. We also encourage you to view the new color management documentation on our website: https://helpx.adobe.com/premiere-pro/using/color-management-improvements.html. 

Keep in mind that we’ll be continuing to bring improvements throughout the public beta period as we respond to issues reported, so details may change as time goes on.

We look forward to your feedback!

[MyerPj]

This is so cool, excellent from Adobe and the PP team, thanks.

I downloaded the clip in discussion here and simply dropped it into 24.6 and 25.0b32 and here's the program monitors (no luts):

[johnpooley3]

RIP SpeedGrade and the Reference Monitor. I have a lot of trouble getting the same control over black gamma in Lumetri that I used to have in SG. And the Lumteri Waveform is not nearly as good as SG's. 

[Hector Berrebi]

RIP SpeedGrade and the Reference Monitor. I have a lot of trouble getting the same control over black gamma in Lumetri that I used to have in SG. And the Lumteri Waveform is not nearly as good as SG's. 

By @johnpooley3

SpeedGrade had its advantages - but also was somwhat un-likeable maybe its UI, maybe a bit of anachronism - it faced Apple color at first - which felt more baked at the time, then Da Vinci became an option - I don't think they even tried to compete or further develope 

as for Lumetri - I think what you experience is a general issue with very limmiting slider ranges in most Lumetri sections. if you pile up a few instanses of Lumetri and use the same sliders  - you get better (yet a bit sloppy)  control. 

I did notice in the Beta that sliders react differently if color managed - not sure if its related to the "color space aware fx" checkbox - need to test it a bit more 

Hopefully the new CM is just the begining and the whole tool will get a re-tweak  

[Christine Steele]

Alexis this is fantastic - extremely helpful - thank you! I'm excited about these important changes that "auto detect" formats, perform analysis for us and detect/display proper color space fir my many different clip types. How exciting! I suspect significant changes like these require some time to finesse and perfect the code, so I look forward to hearing what professionals here encounter while playing with the public beta. 8)

[MyerPj]

This has really be a great year for PP, following along, with the changes and new implementations. So, cool.

Thank's to Adobe, and those on this post, providing some great insight. My eyes are wide open! 🙂

[Shebbe]

Hi @Alexis Van Hurkman ,

I want to highlight my concern again looking at the differences between direct log to Rec.709 conversion and working in ACEScct. The squish I was talking about can be more clearly seen in the higher resolution scope Resolve has.

The image below is a ramp going from 0-1 in linear converted to ArriLogC3 so it could be interpreted by Premiere's color management.

The curve going above then below the other one is with ACEScct working space.

This means that in the tone curve something is causing a non smooth curve to appear. I won't make guesses why this is but I'm really certain that this is undesireable, especially because it's happening in the 'standard range' of the display rather than the 'tonemapped highlights'.

The main problem is also that the direct Rec.709 tone mapping is different than that of ACEScct at all. They should render the same when the same DRT is used.

[Alexis Van Hurkman]

Hey Shebbe, we're well aware of the "squish" and have a short-term feature that will help with this behavior, and a longer-term plan to deal with it more comprehensively that requires some R&D, and both are future features. The non-smoothness of the curve is interesting so we'll look into it. I'll make an announcement when we make further developments around this.

[Shebbe]

That's good to hear. I also hope the team will be very careful in decision making. Ideally the whole color management system is a fixed mechanism not subject to change once released (at least for some years). We already have a Legacy Hue Preservation tone mapper when the full management system hasn't even been released yet.

I hope that is something that will be depricated. Perhaps if mechanically possible it would be a good idea to only enable it in the case of backward compatibility of older projects but hidden for new. And upon selecting a different tonemapping method in such older projects have a message pop up that states that you can't undo. This would allow full deprication of it later down the line.

[sachag37368285]

Hi all

Relative newbie to Slog and color space management here and just getting to grips with the new color management system.

1st, worth pointing out we expose 'to the right' as per best practice for Sony Slog

Previously to date we'd applied the Sony Slog3 LUT to our sequence via an adjustment layer (applying it on the clip in the bin as an *Input* LUT causes it to er...clip before we try to adjust the exposure.)

After digging around in forums the trick is to apply the LUT transform *after* any exposure adjustments so you either add another Lumetri effect in the clip effects or you add the LUT via a look. All great but seemed ... well odd.

New mechanism makes more sense, understand the clip's colour space when you import it and allow exposure/saturation adjustments directly via the new Lumetri settings option.

Two things -

1 - Apply to all clip instances doesn't apply the exposure adjustments to the other clips in the sequence, and neither does copy/paste attributes.

2. Given the exposure adjustments only happen to the clips in the sequence, all the thumbnails in the bin are now overexposed and looking a bit rubbish.

Have I missed a trick here?

[Shebbe]

There would be a lot to explain about working with log and color management but I'll keep it consolidated to your specific questions. 

"Previously to date we'd applied the Sony Slog3 LUT to our sequence via an adjustment layer (applying it on the clip in the bin as an *Input* LUT causes it to er...clip before we try to adjust the exposure.)

After digging around in forums the trick is to apply the LUT transform *after* any exposure adjustments so you either add another Lumetri effect in the clip effects or you add the LUT via a look. All great but seemed ... well odd."

Workflow-wise what you've been doing before where you make your adjustments before applying the Sony LUT is roughly the same as how it is handled in the settings tab. There's nothing odd about it. It comes down to how the used math works against the order of operations and the image state. If in manual managed context you'd like to adjust exposure before applying a LUT without loading a full second Lumetri instance you can also use the Brightness & Contrast effect. The brightness slider's math is addition/subtraction in grading also referred to as offset. Because log is encoded with equal distribution of stops this will behave as changing the exposure. You just need to hold CTRL/CMD when changing the slider because it's very sensitive. Contrast can also be managed in that same compact tool. The reason I explain this is because the exposure slider in Lumetri is not behaving in the same way so even if you apply the LUT after it via a second instance or in the Creative slot, you won't get the proper results.

About your two things:

1. I believe you are talking about the exposure adjustment you have available on the color management settings tab of Lumetri. This function seems to be designed to transfer the chosen properties to the other instances of only that same clip. That works as expected on my end. I think the copy/paste attributes does not (yet?) contain transferable Lumetri Color data.

2. There is no trick, the thumbnails will simply be whatever it is you shot, with the display conversion applied. It cannot auto compensate for any exposure differences.

[R Neil Haugen]

Welcome! It's good to get the widest possible 'crowd' commenting here ... always.

Some context ... I'm a long time stills pro, including running our own wet lab for years, and among the first to 'go digital', so I've got over 20 years of digital image creation down also, with over a decade in video. I work for/with/teach pro colorists, so I'm always "around" discussions on both proper image creation and proper video post workflows.

Shebbe is a solid pro colorist, and I'm thrilled he's now participating here, adding his experience and knowledge to the discussion.

"1st, worth pointing out we expose 'to the right' as per best practice for Sony Slog"

While there are some folks suggesting that, personally I don't agree it's a 'best practice'. I've both tested this sort of thing for years, and also, I've heard and read long disussions on this. Naturally,  I suppose ... most of the top pro colorists I know, and know of, and many DPs, would also not agree with "expose to the right'. Although, as a practical guy myself, what they may suggest to do instead, can at times look like it's mostly kind of "ettr".  But the point they are getting at isn't.

Sony, like other manufacturers of solid professional gear, has established "middle gray" values, and that is what those folk would feel you need to 'hit' in exposure. If they say middle gray for X camera is 38IRE, then that is where that value should sit when exposed correctly in-camera.

A factor that drives a lot of this is the concept of what is acceptable as a noise 'floor'. And how you 'build' the image/scene exposure to get best practical results. Both in the file, and for post work.

So the "best practice" as seen by many is to nail the middle gray, and use camera settings and lighting kit to shape the needed image values.

But everyone works differently. So what works for you, works ... but will be better in the long run if you have more understanding of how others also function. That always leads to more, and more effective, working options.

The camera manufacturer LUTs for log-to-linear are all built around such exposure, based on scenes with controlled contrast and lighting, with the camera settings correct for that scene as presented. At least, as far as any documentation I've ever seen.

And in Resolve, when you apply a LUT in a node, then touch any controls to trim the image in that node, the controls are applied prior to the LUT. As discussed above in this thread.

This is correct behavior, as you need to trim exposure/contrast/sat of the 'field produced clip' to match the expectations of the LUT. 

This is exactly the same operations order, as applying the LUT in say the Lumetri Creative tab, then using the Basic tab controls to trim it, or as Shebbe mentions, applying the LUT in a Lumetri Basic tab Input slot, and using the Brightness & Contrast effect prior to it.

Again, order of operations is the key.

Shebbe's got everything else covered. And well.

[sachag37368285]

Thanks guys, despite being in this business for over 20 years now it's good that there's always something new to learn and old habits and assumptions to break!!

We were using 'best practice over exposure' since that was what was recommended when using for our FS5's & A7SII's in log.

It transpires that the FX3's we've bought to replace them have much better S/N but we weren't aware until, well, today:
https://sonycine.com/articles/how-correctly-expose-s-log3---a7s-iii---fx3---fx6---fx9/

Part of the reason I wanted to get my head round all this was ensuring that I had as clean and tanglefree editing process as possible when using log with FX, multicam, non-log material etc and also ensuring my S/N throughout the chain was as good as possible (headroom with my audio hat on)

So now having dived into the rabbit hole that is colour management in Premiere I've now stumbled into the world of gamma in display monitoring and the 'Quicktime bug', and why deliverables don't always look like you thought they should....

[R Neil Haugen]

Oh my ... remember, I work for/with/teach pro colorists, right?

And you wouldn't be shocked to know the majority of them are total Apple geeks, right?

Yea ... they are so ticked at Apple over the mess they made of Rec.709 display on Apple machine without Reference modes!

But ... Apple isn't even internally consistent, as on Macs with Reference modes, set to HDTV ... those use the correct by-the-specs Rec.709 display transform!

So you get different images, on Macs!!!! ... depending on whether the rig is "Reference Modes" or not.

What a .... joy.

[jakew39230329]

Even the reference modes are difficult to work with. The gamma settings dont actually change the gamma at all when creating custom presets. I believe the HDTV preset is designed to work on top of colorsync, as it just applies a 1.22 system gamma to the whole display. So in final cut and quicktime it looks correct, because 1.96 x 1.22 is roughly 2.4 gamma. So in premiere or resolve you still need to use a viewer gamma of 1.96 or rec709-A to use underneath the reference mode to make it correct for 2.4 😴

[Fergus H]

@sachag37368285 On the issue of gamma, the article I usually suggest customers read is this one: 

https://blog.dominey.photography/2021/01/24/why-are-videos-washed-out-on-the-mac-exploring-quicktime...

It's a great overview of the root cause of this issue. Be sure to scroll to the very bottom: there's an update about how we added a Viewer Gamma option last year to make this issue easier to deal with. 

Regards,

Fergus

[R Neil Haugen]

Overall a good article. Plus he does mention a slight color shift at one point. Which is useful data.

One colorist did extensive testing of color gamut operations in ColorSync, and demonstrated that the gamut mapping used by Apple is not quite as accurate as would be preferred in remapping sRGB huev values within the native P3 color space of Retina monitors.

So there's the very notable gamma issue, which is a tonal or luminance issue.

And a gamut issue, which is a hue or chrominance issue.

Oh. Joy.

[Shebbe]

Hello! I have some more feedback.

What exactly is Adobe's definition of Colorspace Aware? In my books the whole point of color space aware tools is that the appearance does not change when the working space is altered, because mechanically it converts from it to it's own optimized working space and back to the working space after. The fact that Lumetri does change means that it is not color space aware? It's only applying different math to the ACEScct working space version over Rec.709 based management? If say ARRI LogC3 would be added as a second log working space option even between those using the same settings would result in a different apperance because the math is still applied directly on the incoming r,g,b data like any other non color space aware tool.

Can we have some insight as to what the tool actually is doing? I know the kind of operations it makes in unmanaged / Rec.709 context because there the working space == output == scopes making it easy to visualize. In ACEScct I cannot see it. What is exposure doing? What is white/black doing? Are they still behaving in an assymetrical way (different math going up vs down from unity value) just like the 'default' mode? How is the curves range distributed?

I think it's fair to give insight to these workings so we can make informed decisions on how we manipulate the image. Just going off by the name of the sliders is too vague in professional context.

If Lumetri Color is really designed to operate properly and predictably for ACEScct/log, why not give the user the option to switch it's mode when managing the color manually? This is something I suggested a while ago already and it would be of great help to those that want to use Lumetri Color in conjunction with their own display LUTs in manual management rather than Color Management based display conversions.

Lastly, I did a quick test on the shipped Creative LUTs that are shipped with Lumetri. They go completely bonkers in ACEScct. I think it's really cool that a mechanism is designed to define the intended color space for the LUT but the appearance does not match at all to that of direct 709 conversion based management. Data looks clamped/squashed.
The problem seems to be the same as what I established in my first post. The DRTs do not have inverses. This is making ACEScct useless to work with for both this purpose and the use of graphics/logos that need to remain 'untouched'. Unless I'm missing something here, feel free to prove me wrong.

ACEScct:

Rec.709:

[hurkman]

What exactly is Adobe's definition of Colorspace Aware? In my books the whole point of color space aware tools is that the appearance does not change when the working space is altered, because mechanically it converts from it to it's own optimized working space and back to the working space after. The fact that Lumetri does change means that it is not color space aware?

 Our definition of this is somewhat pragmatic because redoing all of the Lumetri math to become fully invertible in all color spaces is beyond the scope of what we're aiming to achieve in this release. The goal we've set for ourselves is (a) to preserve what Lumetri does today, and (b) to make Lumetri work as close as is feasible in a wider gamut as it does in Rec.709, while allowing a bit more adjustibility to better account for the additional lattitude that's available. It's imperfect, but pragmatically we're aiming to improve the experience without having the controls feel completely different.

Lastly, I did a quick test on the shipped Creative LUTs that are shipped with Lumetri. They go completely bonkers in ACEScct.

 There's a bug currently in that there is clamping happening in wide gamut. We're working on eliminating the clamping, at which point you should be able to apply LUTs designed to work in other color spaces to ACEScct and have a comparable look to what you'd expect.

[Mike McCarthy]

I am super excited about this development, and while I have not had the time to dig into the minutia as much as some of the others on this amazing thread, I am impressed with what I have tested so far.  The one issue I have discovered, is that while R3D files default to importing with the decoding settings set to Log3G10/RedWideGamutRGB (Which was a great improvement a couple years ago) the new color management system identifies the Media Color Space as Rec709.  As soon as you go to 'Interpret Footage->Color>Override Media Color Space' and select Red Log3G10/WideGamut, then things seem to work correctly.  But really that should probably be the default color management setting for all R3D files upon import into Premiere.  And hopefully that should be simple to fix.

[R Neil Haugen]

Agreed.

[Fergus H]

Hi Mike, 

We do recognize the color space of R3D media automatically. However, for this to happen, you first have to enable Lumetri Settings > Project > Auto Detect Log Video Color Space. 

While color management is by default turned on, we've taken a fairly conservative approach to how it’s applied. Auto Detect is turned off and the Color Setup (under Lumetri Color > Settings > Sequence) is Direct Rec. 709. 

We’re doing this to maintain backwards compatibility with previous version files but also to ensure that the changes we’re making to color management in Premiere Pro aren’t too jarring to customers more familiar with using a LUT-based workflow. 

Personally, I like to have Auto Detect Log Video Color Space on and pick the Wide Gamut (Tone Mapped) color setup. 

Let us know what you think!

Regards,

Fergus

[Shebbe]

Hi @Fergus H,

That's an interesting point. I think we can agree that raw files do not have much to do with "Log Video Color Space". This feature should ideally be renamed to properly reflect it's function.

- Auto Detect Camera Color Space

- Auto Manage Color Space For Known Camera Files

- Automatic Management For Known Camera Files

are some ideas.

[Fergus H]

@Shebbe It's funny you mention this: Alexis and I had a conversation about the name recently. I've never been a big fan of the current terminology (and it was challenging to translate it into all the different languages Premiere Pro supports!) and I believe Alexis and the Color team are considering options. Thanks for the suggestions!

Regards,

Fergus

[Mike McCarthy]

Regardless of what you name the new setting (which needs improvement), it should be on by default for NEW projects, even if it is OFF by default for projects upgraded from V24.  It might be even better to have it ON for upgraded projects, and have all 'legacy' media already imported into the project set to Override to Rec709, unless it was previously a color managed clip.

[R Neil Haugen]

Agreed, Shebbe ... it's not at all expected that raw and log use the same 'auto detect' things, when some raw is recognized and some is by plugins. There needs to be 1) clear nomenclature that doesn't obfuscate the intended operation and 2) consistency.