Skip to main content
Alexis Van Hurkman
Community Manager
Community Manager
August 15, 2024
Question

[Now Released]: Dramatically updated color management in Premiere Pro

  • August 15, 2024
  • 29 replies
  • 44209 views

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 MonitorVideo ScopesTransmit, 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!

29 replies

MyerPj
Community Expert
Community Expert
August 27, 2024

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! 🙂

Christine Steele
Participating Frequently
August 27, 2024

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. 😎

Keep Creating...
MyerPj
Community Expert
Community Expert
August 24, 2024

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
Inspiring
August 27, 2024

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. 

Participant
August 27, 2024
quote

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  

R Neil Haugen
Legend
August 24, 2024

Alexis,

 

I really, really appreciate the detailed comments. This is far more information than we've normally gotten in the past as to how the pipeline functions throughout. And is so useful to know.

 

So ... thanks for both giving us a massively improved CM system, and for such detailed information as to tue practical applications and uses.

Everyone's mileage always varies ...
Participant
August 23, 2024

I really appreciate this massive overhaul to the color management system as it definitely streamlines the whole color issues people have complained about in Premiere forever... for the most part. However I have two main issues with the new system.

 

For context I shoot and edit documentaries for businesses and nonprofits. I go through hundreds of Canon MXF files in Clog2 and color grade everything myself. My workflow requires exporting graded interviews, chopping them up in transcription software, and importing back into premiere with an XML, then layering raw B-roll on top of that. I am by no means an expert in the color science field but I understand how it works.

 

The first issue is that when using the "Direct Rec.709" color management option for my sequence, the automatic conversion for Clog2 built in has a noticeable color shift compared to the official Clog2 lut. Both photos are ungraded.

 

Top: Official Clog2

Bottom: Premiere Clog2 Conversion

 

This brings me to the second issue. The obvious workaround is to just choose "Disable Color Management" for the sequence and convert the clips in lumetri, as I've done for years. Before this update, the infamous "Display Color Management" setting was the solution for making premiere display the correct gamma. This option still exists but when the color management is disabled for the sequence, "display color mgmt" has no effect on the picture. This means when I do my standard correction and grade, I crush the shadows too far because the image appears to have less contrast.

 

I'm not complaining, I think it's great premiere is getting all these updates, however I am just a little confused by all of the different settings. My overall issue is that I'm having trouble knowing what are the correct settings to use. Should I disable color management for all my sequences for consistency? I can't use the Direct Rec.709 option because of the skewed LUT, which would force me to go to each clip by hand and check the "Preserve RGB" option, which I don't have time to do. I have already read through the entire article they posted for the color management update and while did help a lot, It didn't make it clear the right settings to use.

 

I hope this made sense. Please if you have any advice or information that would be helpful I would love to hear it. I've spent a long time building an efficient workflow and this update has set me back. I'm willing to change my ways though I just want to know the proper solution to color management before I start frantically experimenting. Thanks.

Alexis Van Hurkman
Community Manager
Community Manager
August 24, 2024

Hi Grady, thanks for the kind words and the great feedback. I have a few questions if you don't mind. First, when you say the official CLog2 LUT, where is this LUT from (Canon directly?) and how long ago did you download it? We're using manufacturer supplied math for our transforms, so I'm keen to get to the bottom of this. Second, apologies if it sounds obvious but I just want to check, you don't happen to have a LUT applied while also using the Direct Rec.709 preset? I'm not sure if you imported clips into a new project or you've imported a previous project, and there's currently a known issue with importing previous projects that we're working on addressing. Third, I'm curious if turning off Input Tone Mapping and Input Gamut Compression would eliminate the discrepency.

Also, FYI, you should be able to batch change multiple selected clips in the Project Browser at once by selecting all the clips you want to turn on Preserve RGB for, right-click one of the selection, and then choose Modify > Color. The changes you make to the Color Management tab will affect all source media and all uses of that source media throughout all sequences in that project. This makes Preserve RGB easier to turn on and off for bunches of clips, when necessary, and may aid your immediate workflow needs.

The Direct Rec.709 preset should be the right one for you, and if that didn't work and you wanted an all LUT workflow then Disable Color Management is the right choice, so your instincts were right. I'd like to follow up with your issue, though, so if you could share some source media and the LUT you're using, that would be a great help.

Participant
August 27, 2024

Hi Hector,

Appreciate the testing. I'd like to clarify some aspects.

 

1. I wouldn't use the "by channel" tone mapping - as mentioned here it will reduce chroma information from your file and you'll have little control over how - might work differently on different shots - especially with bright saturated colors.

This is not entirely true. If you work in scene-referred which you do if choosing ACEScct as working space you don't lose information in the file/working space. It's just that the display tonemapping which happens after all your editing and effects will desaturate bright colors faster. In almost all scenarios this behavior is preferred. When you'd want to retain more color information you would grade it to lower it's luminance. As general rendering, by channel looks the best out of the box for most scenes, especially with people.

Here's a simple example with Resolve's hue(sat) preservation(left) vs per channel(right) where you can see that skin doesn't look that preferential on the left.

 

 

 

 

 

And another example with Premiere Hue Preserve/PerChannel/ARRIClassicLUT. You do have some degree of control but when adding contrast and saturation, by channel is usually the most natural responding to skin and very bright colors.

 

...the Heu preserve options (both) introduce a hue shift - I didn't get that shift when managing with ACES in DVR nor when I used the LUT

...PPCM ACES - Hue Prs - shift is on orange towards red

You actually have it backwards. The captured color is more red-ish and stay hue linear in Hue Preserving models. By channel tonemappers skew these tones towards yellow (by consequence of math, not by purpose/design) which is evident by the vectorscope. ACES 2.0 which will release very soon actually has hue preservation aspects as one of the characteristics of it's DRT which is generally an improvement eventhough you sometimes might actually want these artificial skews. Getting into SDR vs HDR matching you'll quickly see why not having skews is more desireable in most cases. In wider gamut displays skewing happens less often because then most colors don't quite reach the end of the gamut. When a skew is artistically built underneath a DRT this adjustment will remain consistent between SDR and HDR rather than suddenly look different.

 

Here's a typical example of very hot fire (CG explosion) where we take the left (ACES 1.3) for granted in it's appearance because we are so used to presenting fire core as yellow. On the scope you see the heavy curving bend towards yellow. It's true color is actually orange/red which in SDR looks like the right (ACES 2.0).

 

In this instance we would also prefer the per channel look however in practice this would not match well in HDR whereas with ACES 2.0 in grading the skew could be artistically placed and remain consistent.

 

 

 

Ref - PPCM ACES - no tone mapping at all (I couldn't replicate this result later)

Because you don't apply any added compression or other tweaks of the data you can in fact clearly see that the source colors are more redish and remain linear rather than bending towards yellow.

 

Ref - PPCM ACES - only automatic input mapping - no shift and slightly resembles DVR ACES

The colors do shift due to clipping. ACES 1.x also does not have any gamut compression or hue preservation hence you may think it behaves the same. You shouldn't use no output tone mapping at all though as everything above 100nits will be clipped rather than rolled off.

 

the ACES IDT list in DVR is quite more generous on the Canon category - why is it so skim in PPCM?

It's actually the opposite. In the beginning of ACES, Canon provided separate IDTs for different cameras but almost all of them were the same transform. They updated their provided IDT to be just a single one for each log variant just like all other camera vendors do. Resolve hasn't implemented this change and it's actually a bad thing. It makes the list too long and unnecisarily complicated since not all models are shown. Furthermore, the IDTs you see in ACES are not really the official transforms everyone uses. They are separate documents provided for ACES specifically. The general camera color space defenitions come from either the log encoding white paper, which often is publically available, or is provided directly to implementors.

 

3. still no decent camera manufacturer LUT-list

This is not desireable. Camera vendor created LUTs are a total wild west and the amount of them is crazy at this point. They are also not standardized. You cannot verify it's rigidity, intent or expected input and resulting output. They are just files with a bunch of numbers. Fun fact: The ARRI LogC to 709 LUT shipped in Resolve is actually a monitoring LUT that was scaled to legal levels which makes blacks lifted when used in post. And colorists unknowingly actually liked this appearance despite technically being wrong. Single camera vendors create multiple LUTs for multiple cameras, looks, displays and camera settings. So as you can understand there's simply no point getting into that mess from Adobe's perspective.


What Adobe can do however is as I suggested in another post, offer some mechanic to make the use of LUTs easier. Something integrated into their color management system so it doesn't need to be loaded onto a Lumetri effect per clip or Adjustment Layer.


Hey @Shebbe  Thanks for the time you took to answer. 

I know how time-consuming this can get. Appreciated 

 

1. I definitely didn't phrase myself well - and did not mean information will be lost from any file 🙂 

I also mentioned that this will be more limiting when dealing with brighter, more saturated captured hues 

I Graded different safety reflective jackets over the years, and they tend to be a PITA regardless of workflows.

 

Don't get me wrong... I can see myself relying on a by-channel workflow as implemented in PP just for the sake of going safe(er) and I agree with you that in most common cases it will look just fine as a starting point.

 

but also... if I have the luxury to be picky - setting up my CM this way isn't optimal - and I prefer choosing one where I'm more aware of my captured highlights saturation - furthermore, I find per-channel a tad aggressive in its treatment - especially from the vectorscope trace in this example, even with the slider at minimum (max sat)

 

and at least it doesn't shift hues 😉 

 

2. with the utmost respect to your knowledge and passion - I must stay doubtful on this one. 

the OP stated that these jackets were more to the orange-yellow hues and most tests in different workflows suggest so too (that regardless of real-world common sense - there are many more orange-yellow safety jackets than orange-red ones... at least to my best recollection) 

Furthermore, in your ARRI Isabella test  - the Hue Preserve example clearly shows the same reddish hue shift (i'd estimate it at about 3 degrees) on the orange chip, but also on the pink, yellow and warm-yellow ones - not mentioning her skin that appears shifted too. the 2 other examples seem fine - on a test shot I've used and evaluated countless times. 

measured on your stills -  adding this to the previous test (neither Resolve's ACES or RCM shifted) hints that maybe there is a minor shift involved in the HP tone mapping algorithm 

 

 

quote

Here's a simple example with Resolve's hue(sat) preservation(left) vs per channel(right) where you can see that skin doesn't look that preferential on the left.

 

 

 

 

 

3. by Resolve's hue preserve - you mean Sat Preserve? I don't find is similar to HP in PPCM at all 

firstly its part of RCM not ACES 

Secondly - it offers superior control over the outcome

and... 

😉 it doesn't shift 

 

I guess "by channel" would be somehow the Davinci DRT - which I again find superior in control and its extent. 

both don't display the "maybe a hue shift" 

In Resolve ACES CM - I have no control over tone mapping (expert checking the ref gamut compress on or off) - unless I use ACES Transform OFX where I get the Parametric Gamut Compress (which I rarely need)  

 

and I'm aware of hue skewing - I think it's not the case here. 

I'll run some more tests on my side. but this should maybe be looked into 

 

 

3. you mention ACES 2.0 - I assume you're using the candidate version? I admittingly didn't get a chance - in what tool/software did you test it? 

I'll find time to check out the latest version - I saw Nick Shaw posted a DCTL for release candidate 1 last month

 

4. I do find some value in the simplicity and direct approach of Camera LUT based Color Management - especially in the very vast world of PP users - sometimes (and up until last week... lol) its just easier to throw the manufacturer LUT on an adj layer - and move on. I agree the current state is messy and cluttered - but it isn't hard to narrow down to the most relevant and recent. 

 

and YES - a new, better lut implementation workflow will be pure bliss!  - and a fair alternative to a pre-installed list.

 

again, thanks for your time 🙂

and knowledge 

 

 

regards

 

hector

R Neil Haugen
Legend
August 22, 2024

From a couple quick conversations about this, getting linear and EXR compatibility is a really needed option.

 

And Shebbe's suggestion of adding a LUT application option to the Output settings, to hold perhaps an overall look, also got some nods.

 

But in general this is a massive leap forward, and there's so many new parts, that it will take some time to see if and where it breaks yet.

Everyone's mileage always varies ...
R Neil Haugen
Legend
August 21, 2024

Shebbe's comments are very good.

 

And Alexis, would it be possible to have another wide gamut working space, other than ACES, something like the Arri wide or P3/D65?

Everyone's mileage always varies ...
Shebbe
Community Expert
Community Expert
August 21, 2024

Kudos for finally putting in the hard work to make managing color in Premiere much more robust!
I also think it's a practical choice to incorporate ACEScct (initially) as a working space rather than design your own 'propriotary'.

- There's a lot to unpack here but from my first rounds of testing there seems to be an issue with working in ACEScct where the appearance doesn't match direct 709 conversion. ACEScct makes a squish of the information above ~0.42 float in all tone mapping models but especially By Channel. This squish is even visible in the scopes.

- Checking Input Tone Mapping seems to clip scene referred data and I wonder why since ACEScct is able to cover a much larger range than a camera encoding. To what is it tonemapping to? Feels like 100nits.

- I notice that when dealing with negative values, output gamut compression Luminance Preserving still retains negative values and Saturation Preserving seems to lock down/clip black. Any info/recommendation as to when which should be used?

- It took me a while to understand all the settings, mostly what is where/when override what etc. Not because of lack of knowledge but plain placement and order. Especially the fact that a clip (source) has a different set of settings than it's instance (sequence clip) in a timeline.

From a perspective of higher end productions sequence clip doesn't make any sense at all and the properties of the sequence clip should be hardwired to the source clip instead but I understand where this came from. But I hope this can be heavily streamlined somehow because trying to explain the processing chain and settings to a beginner in this state would be much more difficult over mechanisms like that of OCIO/ACES/Resolve/Baselight.

 

^ This is particularly confusing because effects applied to the clip are in ACEScct and not Rec.709. It feels like a 'redundant' piece of information in the wrong place. Perhaps have a look at the way Baselight presents it's settings as information to the user. I think theirs is well defined.

 

 

- Looks like nearly all commonly used camera log encodings are finally in the list, however:

1. For Fuji users out there, F-Log2 is probably more present than F-Log. Would recommend adding that soon.

2. EXRs are not yet compatible due to missing Rec.709/Linear, ACEScg and ACES 2065-1 color spaces.

 

- Thinking ahead, for advanced users, it would be really cool if custom LUTs could be loaded as 'Output Color Space' where we say work in ACEScct and apply the LUT instead. The only challenge is how to manage a split mechanism where your graphics etc can still be managed as Rec.709 but selectively all camera based material gets converted and recieves a LUT.
It would help greatly with applying custom looks to projects without the hassle of using adjustment layers or applying Lumetri to every clip which manage wise is hell. But haven't given how it exactly should work great thought yet.

 

- I think eventually it would be good to give users freedom of choice for the working color space (if possible with the way the DRTs are designed). Nice to have ACEScct as option, but some may want to grade/work on their native camera space like AWG3/LogC3 or work with CGI only in ACEScg. Perhaps not present it as a full list but some sort of show more option within the dropdown menu would be elegant.

 

- OCIO should also arrive at some point to help with parity with AE and enable the use of ACES without the need to natively implement it. Although given this new management framework, full native implementation can actually happen now... but it means you also get the responsibility of maintaining it.

I need more time to test interopability with AE etc. Will keep reporting what I find.

That's all I have for now! Keep it up!

Alexis Van Hurkman
Community Manager
Community Manager
August 21, 2024

Thanks so much for kicking the tires, Shebbe! If it helps, we've put together a HelpX article that talks through the process and how we've designed it (https://helpx.adobe.com/premiere-pro/using/color-management-improvements.html).

I'll address your feedback more directly, but it may take a day or two as you cover a lot of ground.

R Neil Haugen
Legend
August 16, 2024

Well thank you Alexis! This is all very welcome to read, and tomorrow I will see if I can get some time to test this. Especially curious as to the ability to have working space separate from display/output ...

Everyone's mileage always varies ...