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

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

Cheers!
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 24, 2024

Thank you for the response, Alexis! To answer your question I was only using the Canon supplied transform lut which I downloaded over a year ago from the Canon website. I actually found the solution to my issue though, after perusing that HelpX article again there was one paragraph that said to use "By Channel" for the Input Tone Mapping instead of "Hue Preservation" to avoid color shift and that worked!

 

Here is a sample with scopes and settings: (The sequence is set to Direct Rec.709 with no settings changed except the input tone mapping under "Sequence Clip" settings, so it's using the premiere default conversion. Is there a way to batch change this settings for selected clips? When set to auto input tone map it just uses hue preserve.)

 

Hue Preservation

By Channel

 

The difference is subtle but very obvious looking at the orange vest. I'm sure some people might not see any difference at all. I did hear from Neil Haugen and he mentioned that with color grading there is no right answer since these are just different starting points. However, the bottom photo is accurate to how the scene looked in person and looks just like all other footage I've shot with the C70. My grades tend to be more natural and not overdone so I like to get the most neutral look possible in camera and just make light adjustments in post. Less is more in my opinion.

 

Here is the same tone map difference on that original clip (using the new built in transform):

Hue Preserve

By Channel

 

If you still want the source media and the original lut I used here is a dropbox download (790 MB):

https://www.dropbox.com/scl/fo/9vir3pbkeqbue3bzyylnc/ACr3aOAP5ILcdKIWhoSuk_w?rlkey=7tjgsdus25d0sry7kz5pka5b9&st=ib5h4ywc&dl=1

 

I really appreciate you taking the time to respond and I hope this was a meaningful contribution. I've only used Premiere for 8 years but I truly believe it's back on the upswing now with all the new tools and updates. Thank you.

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 24, 2024

Hi Shebbe, here's the detailed response I promised...

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

 

Here's my response from an upcoming FAQ (still in editing). Whenever you configure a sequence to use output tone mapping to convert from a wide gamut working color space (as set up by the Wide Gamut presets), this can slightly darken the highlights of the SDR source media you’re editing into that sequence. The reason is that on input, both wide gamut and SDR source media are converted to the same single wide gamut working color space (which is ACEScct); at that point, all media is in the same format, and the same tone mapping that compresses the highlights of wide gamut media to fit within Rec.709 output ends up also compressing the highlights of SDR media.

This isn’t a problem for camera original SDR media that needs to have its color adjusted anyway, keeping in mind that all color adjustments happen before the output tone mapping is applied, so you’re always adjusting the source levels. Just grade these clips as you normally would, and you’ll find plenty of latitude and a smooth roll-off in the highlights as you work. However, this can be a problem for mastered SDR media that’s been previously graded and now looks different. This issue can be minimized using the Wide Gamut (Minimal Tone Mapping) preset, which limits tone mapping to only the highlights of SDR clips and has the added benefit of tone mapping out-of-gamut highlights.

 

What I'll add in this conversation is we're aware this could be improved upon, and we're examining how to address this in the future. Additionally, this is one of several reasons we make the "Direct" presets available, so that projects that need to pass those formats through without alteration have the traditional Premiere Pro workflow. The Wide Gamut presets are, as we describe, ideal for projects consisting primarily of wide gamut material, or ungraded SDR that you intend to grade to a peak of 100 nits from the get-go.

quote

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

 

Input tone mapping, as the name implies, tone maps on input. As designed currently, this is meant to be an option when the working color space is Rec.709, and to support color fidelity for older projects being imported that used this order of operations. However, being applied on input means that the highlights are compressed before all color and effects adjustments, and image data being squeezed prior to your operations can make further detail difficult to retrieve. This is why we have Output tone mapping and gamut compression available, and in wide gamut workflows Output tone mapping is recommended instead of Input tone mapping, the two aren't meant to be used simultaneously at this time. (for a variety of reasons, Gamut compression is applied, in our presets, on both input and output, and that's fine).

 

And to further elaborate, Input tone mapping maps to the working space (and Rec.709 corresponds to 100 nits), while Output tone mapping maps to the output color space (100 for 709, or your choice for the HDR formats).

quote

- 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?

 

Regarding the different tone mapping algorithms, it's horses for courses as different algorithms will provide different handling for different source images. We have no specific guidance to give at this time other than that, and we're looking for feedback from users during public beta about what seems to be working best and worst for them to guide our continued development efforts.

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

 

We understand there are a lot of controls being exposed. Some of these are a legacy of Premiere Pro's history of development, and for a variety of reasons must be maintained to maintain compatibility with older projects. If it helps, the primary mechanism of color management is found within the Sequence controls, and those are the settings affected by which Color Management Preset you choose.

 

Regarding Sequence Clip settings, this is a concept introduced previously that we need to maintain compatibility, but it enables sequence-clip-specific gamut compression and tone mapping settings, which are valuable for input tone mapping workflows.

quote

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

 

We appreciate the feedback. We've been trying to find ways of presenting information about what's happening in a space-efficient manner. We'll take this into consideration.

quote

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

 

Good to hear there's interest in F-Log2, we'll take that under consideration.

 

Regarding OpenEXR, that format is not color managed at this time, but we're well aware this is something many customers want, and plan on addressing this in the future.

quote

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

 

We're being very deliberate about the working color spaces we're exposing as we're trying to keep things streamlined, but are open to feedback about which specific working color spaces would have the most value to the most people.

quote

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

 

We're aware of customer interest in OCIO. As you mention, we had work to do overall to support more detailed color management in any event, and we've prioritized improving upon Premiere Pro's own color management pipeline as the way to deliver the most value to the most people with the least complexity. As you can imagine, since OCIO has appeared in Ae, the chances of it appearing in other Adobe products in the future are not poor.

quote

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!

 

We look forward to your feedback on Ae interop, and as always appreciate the detailed feedback and the time you took to give it. Cheers!

Shebbe
Community Expert
Community Expert
August 24, 2024

Hey Alexis, thanks for touching on all my points!

 

One important thing I need to clarify is that my input image was an ARRI clip.

Re: Appearance
I think there is a design/mechanical issue when converting scene to scene to display presents a wildly different appearance than direct scene to display.

I'm also not entirely sure what is going on but the precieved 'squish' I was talking about now actually appears in SDR as 'unsquish' rather than ACEScct working space. But in ACEScct now the entire contrast/tonescale gets 'squished' whereas before it was only everything above ~0.41float. The visible line I talked about in the scopes is now seen in SDR as more streched instead of the squished line in ACEScct...

I'm also slightly concerned about the overall rendering/tonescale of the DRT as it seems to be heavily lifted in the shadows. Almost like there is no (preferrential) rendering of the image. Is this desireable/by design? The direct AWG3/LogC3 to Rec.709 conversion also looks more like a rendered image than that of going to ACEScct first.

Re: Gamut compression algorithms
I understand their differences and usecases. I'm actually concerned about managing the image and remaining negative values since Premiere Pro does not offer any export levels management. AFAIK exporting to h264/5 or prores will always scale full to video levels without clipping. So these 'superblacks' would come out in broadcast as illegal. This would necessitate the addition of a Video Limiter in your pipeline which is far from ideal imo. But perhaps this is more a matter of implementing proper video levels input and output scaling management which Premiere really lacks at the moment.

Re: Input tonemapping in ACEScct clipping
Again something seems to behave different now that I booted the project up again. Checking input tone mapping for an Alexa clip now does not alter the image with the working space set to ACEScct as I would expect. It must have been a bug.

Re: Offering choice of working space
I appericiate the caution, but there are also technical reasons to why one would like to have access to the data before converting to another space but still utilize integrated colormanagement. Hope to see it being considered in the future.

Now some new concerns I'd like to express regarding the DRT:
There seems to be no inverseDRT options am I correct? This means we cannot work in ACEScct or any other scene-referred space (if more are added in the future) and use display referred imagery for which the appearance should not change (other than possibly sRGB->Rec.709 gamma change). This makes working in 'wide gamut' a really hard sell. I can't imagine anyone working in Premiere doing only log camera based editing and colorgrading with no addition of text or graphics anywhere.

Mechanically we need to have an option to do Input Tone Mapping on a per clip (at source clip level ideally) basis. But by default preferably that the sequence based Input Tone Mapping checkbox does HDR to SDR tonemapping but also inverseDRT for SDR to HDR so the forward transform nullifies it enabling the use of graphics in a scene referred workflow.

 

Any plans to make this work?

After Effects Dynamic Links:
Looks like it's being hooked up to the Adobe Managed environment. Surprisingly it automatically adjusts the used working color space as the input color space on Premiere's end. Very nice. But it's also clear that After Effects needs to get away from this legacy ICC based workflow and hopefully implement the exact same mechanism as Premiere has now so we can also get away from that 'scary' list of profiles from the OS that should not be used in almost all cases. And mostly to get parity with appearance so we can make better informed decisions.

 

I did notice a discrepancy in this current implementation when using ACEScct as working space. All available camera log spaces in After Effects resulted in a white balance shift on Premiere's end. You may want to verify the same chromatic adaptation is used and if even used at all since ACEScct has a different white point. The appearance inside AE did not change when switching the working space there.

All my testing was done on the ALEXA LF sample footage which you can grab here if you'd like to do the same.

 

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