Thanks for the focus on depricating 'old tech'. I do share similar sentiment as @Mike McCarthy though that Software/CPU can be a good fallback if GPU rendering / memory issues arise. That said, the CPU limitations of certain processing being 8bit is highly undesireable.   Is there a possibility in the future that we still get a CPU fall back option, maybe even internally as a background process for when GPU fails to render/compute certain frames? But an upgraded one that always processes in 32bit float.   On a similar note, it could be practical to also depricate Trilinear LUT interpolation? Would anyone ever needs this interpolation method? It's also there as fallback when CPU rendering is used?   I struggled with this a lot in AE when it would auto switch to CPU when GPU had errors or couldn't render the frame anymore but it would be sticky when switching back to mercury GPU. ... View more

What kind of video file format was it shot in? Is it raw or log footage? In such cases you have the best chance at salvaging the white balance. If not, I would just try to slap a Lumetri Color effect on it and change the temperature and tint and some other basic controls until you feel it's in a better spot and call it a day. ... View more

When I realized MoGRTs were not fully open and editable on the fly I immediately dropped interest in the whole mechanism for Premiere Pro. There is zero efficiency and adaptability. I don't understand the whole idea that they should be separate enteties from actual AE project files and be managed in an entirely different way.  Maybe I don't see the full picture but to me MoGRT should just be the upgraded version of a Dynamic Link where only text fields were editable of your comps. If different mechanisms are required to make it work, it should be implemented directly into AE. The need to build a separate .mogrt file which has to be imported into the Graphic Template library in Premiere but then becomes yet another file (.aegraphic) when imported in the Premiere project itself, but then needs to be re-converted back to .ae file to adjust is so alien to me... ... View more

Super busy with projects, not a lot of time to test/verify but I'm sure it's solved now:). Thanks for notifying us! ... View more

Good to know, thanks. ... View more

Hey @Kylee Pena  Can you tell if this update will be pushed as a hotfix to 25.1 release rather than part of 25.2 (which I believe has many unfinished features still)? We have plans to update to 25 for reasons that isn't SpectrumUI.... but this visual hinderance is pretty significant to us. ... View more

We would use After Effects if talking about a single shot that needs to have a certain appearance and can be prepped for final quality. But such a workaround is not feasible for assets that needs it constantly like blurring a 9x16 video behind itself for 16x9 output, or blurring the end shot to overlay a logo/endcard, which is really common for our work. You want to be able to keep editing fast and stay native within Premiere Pro. For such cases adding AE in the mix is a massive workflow hog for a task that is supposed to be really simple. ... View more

There is a potential problem, and weird as it seems to me, I don't recall testing this in Premiere with it's fancy new CM controls. So I'd like @Shebbe to help with this ... if you have a wider working space timeline, such as the ACES option, and a typical Rec.709 conversion LUT applied in the AL above a clip ... and the Sequence CM set to Rec.709 ... does that work correctly? By @R Neil Haugen   Not really. You can try to enable CM with ACEScct working space and use a log clip tagged as the output space (Rec.709) to 'negate' the conversions. But as I mentioned a couple of times before in this thread, they have no inverses of their DRTs so you don't get the actual unaltered image. You need the exact inverse of the tone mapping decision you make in order to be able to arrive there. You could disable the tone mapping to solve this but what's the point of enabling a bunch of stuff in order to disable them again.   You would also need to load a LUT in the Lumetri Creative slot, which has options to define the LUT space which should be Rec.709. You'd now have a match but doing this does not allow you to take advantage of Color Space Aware grading tools, because they are designed with the idea that the input data == timeline space (ACEScct). The math will be incorrectly applied if any other image state is used.   As you can see it would be most practical to disable color management, apply the LUT on clips or Adjustment Layer and apply Brightness & Contrast effects prior to the LUT which is to my knowledge currently the only possible way to natively manipulate exposure outside of Adobe's CM. ... View more

Hey @Chetan Nanda , I'm finding some inconsistencies.   When I create an ACEScct timeline and place it in a fully unmanaged timeline, it becomes a Rec.709 un-tonemapped image in the viewer when Display Color Management is enabled. This means that the data does get converted from ACEScct ('metadata' from the timeline's clip?) to the display. Attention to -> to display, rather than to the new timeline because it does not have color managemenet enabled. This is weird don't you think? It means Premiere still enforces certain conversions even when the user says not to? This oddity is not observed on Media Files, only on Sequences and I think this should be disabled.   I can set the new timeline to Direct SDR and re-enable tonemapping but in this case Input Tone Mapping to tonemap the still high dynamic range of the nested timeline to the new Rec.709 based timeline. This can, when choosing the same tonemapping method as used on output in the ACEScct timeline, result in the same appearance.   This part totally makes sense to me and is also neatly reflected in the information given in the settings.   Back to the display management oddity, it's actually equally weird that for Media Files you still see the gamma 'shift' conversion from 2.4 to display in a Disable Color Management timeline. Where is it even expecting that the intended timeline space is Rec.709? This setting seems to be removed for this context. So what the viewer does when you load a log or HLG clip is also incorrect? Unless I'm not understanding something here...   Resolve uses a mechanism in unmanaged mode that allows you to specify both a timeline working space and output space. The timeline choice is intended to define the grading space for sake of Color Space Aware effects/tools and the output space is for sake of how the scopes should read the data and what the auto tagging should do on exporting files. Perhaps it is good to think about a similar mechanism to make colormanagement more flexible, consistent and predictable. ... View more

Would be even better if the changes also made on Audio Track Mixer level as well, to see waveforms after applying compressors or limiters for example. Would give a better illustrating of what the compressors and limiters does to the audio as well. By @Strat2024   Such a feature does not exist afaik because compressors and limiters are time dependent operators. There cannot be a previsualization unless it's precalculated. But that would add a redicolous amount of processing time for something that is prone to change constantly. It theoretically could be 'printed on the fly' during playback but then you run into a UI/UX issue where you somehow have to communicate to the user which parts are pre or post effect processing. Tools like compressors and limiters have gain reduction meters built-in to visualise what they do during playback and work just fine. In the context of more visual assistance that caters to such tools, it would help to upgrade the Audio Track Mixer to have built-in compressors and limiters of which you could see a miniature gain reduction meter on the mixer channels themselves similar to how many DAWs approach this. ... View more

That sounds like they are also converting and tone mapping to Rec.709 from each log camera state. It means the LUT files themselves are designed to do the color management as well. This is why it makes the setup complicated when two color management mechanism are enabled at the same time. As I mentioned, it is possible provided you have inverses of one of them to undo their transform but at the same time you are canceling out something you enabled in the first place. Even in Resolve there are caveats/downsides to such a workflow which is why for all of my current color grading work I use full manual management.   I understand your preference of Lumetri's exposure behavior in ACEScct because it's behaving photometrically plausible. You can achieve the same result however without color management/color space aware effects. Just like in Resolve DWG/Intermediate you can do offset operations on the log footage before the conversion. If you grab Brightness & Contrast effect, the brightness slider is actually the same math as offset in Resolve. Becuase of the nature of log encodings, the exposure stops are equally spaced apart from black.. so adding or subtracting equal amount of values to all channels equates to an exposure change. The only finicky thing is that the slider range is really coarse, so it's best to hold down CTRL/CMD while dragging for finer adjustments. The contrast slider of the effect is also linear rather than an s-curve so it can also be used to increase or decrease contrast on log. They only operate on all channels equally so you can't do balance changes with it unfortunately. ... View more

It's a bit hard to follow what exactly the issue is or was.   @SpaceCherryFilms how were you using the LUTs exactly before? Were they applied per camera on log before a Rec.709 converson LUT, or after Rec.709 conversion? Were they specific for each camera? What kind of display conversion LUTs were you using before? Different ones per camera?   What I can say about the current standings of color management is that it is not possible yet to use LUTs designed for Rec.709 in ACEScct working space. Whilst Lumetri does now have the option to define the LUT space (which is an internal conversion to and from if that space does not match the current working space), it breaks when using ACEScct because the internal conversion is not the same as the actual conversion that is happening from ACEScct to Rec.709 with tone mapping that you use as Sequence settings.   When you want to use Rec.709 based LUTs or sRGB/Rec.709 graphics in a log working space the conversion of that data into that space needs to be the inverse of the forward conversion to the display. Otherwise you end up with a different appearance where it treats display white as diffuse white resulting in a darker, incorrect image because the tone mapper was making room for 'specular highlights'. Alexis did mention somewhere in this thread that there's still work to be done, but no official statement that there will actually be true inverses of the available tonemappers.   Structuraly it would ultimately be practical to also have the option to roll manual color management with native plugins that do what the colorspace converter and tone mappers do so you can do similar set ups like you would in Resolve with CSTs as nodes and decide when what gets converted, display tonemapped, inverted etc. But most importantly for the project wide management, the inverse tonemappers need to be built otherwise the ACEScct working space is unusable.   Hope that clarifies things. ... View more

Fantastic! Thanks for this update. ... View more

Not sure why I'm in the tag :)... But I agree and already voiced my opinion about it some time ago. Premiere should offer overrides for data/full vs video/legal levels for cases there is a mismatch. It should also allow for full control over what to write them as, including the option to clip after scaling so no 'superwhites' / 'superblacks' are stored.   What I know about VLC on Windows is that it always reads DNx 444 files as legal levels resulting in white and black clipping and increased contrast. This isn't Premiere's issue, VLC fails to read the data correctly. I guess it may be the same case on a Mac.   You'd need to figure out which of the two is actually correct. Easy to measure if that text is intended to be full white. Otherwise you'd have to ask them to send a version with some frames of SMPTE bars run through the same export format. ... View more

What I can say about D-Log M is that it is not a 'true log' encoding that is linearizable with a simple mathematical formula. It's rather a sort of custom curve that is designed to optimize dynamic range as much as possible whilst preventing becoming too 'flat' for 8bit storage. The cheaper DJI products tend to have this as the only option due to cheaper sensors/less dynamic range or limited storage format options. It's intended use is generally to treat it 'as is' (rec.709 tagged) and grade ontop of it, or use/combine it with their LUTs. I would not use D-Log as the input space for D-LogM as this will create handling mismatches which in certain conditions will produce unwanted effects. ... View more

I fully agree with the idiology there. In the ideal scenario, most of the look comes from modifications/creative decisions underneath the DRT.   However, since Premiere doesn't exclusively focus on grading/color management, to some, the out-of-the-box result may be a little off putting compared to their typical LUT based workflow or other software like FCP X or Resolve. It would be nice for future development to implement some kind of core looks set that can be selected in Lumetri on the color end rather than settings. Much like the now pretty old LUTs we have there, just some fresh ones designed to complement and expand on the new color management pipeline. They can be both creative or 'simple' preferrential adjustments but the main goal would be to provide users with either a more finished look as starting point or have it applied on their footage for fast turnarounds with little actual correction/grading needed. ... View more

If you can get by with the more simplistic approach without ACEScct that's great nothing wrong with that.   "Is there than still a reason to use any input log if you overwrite the media color space anyways?" What do you mean exactly?   "Considering the gamma - would it then be better to just work in 2.4 and apply the gamma correction on export to save the headache?" From the perspective of mitigating the differences and washed out presentation it would probably be more practical to disable display color management and work on an sRGB display, then grade towards what you want to see and call it a day so no extra operations are required in the delivery process.   "The only thing that seems pretty clunky for me is, that you have to switch between the settings and edit edit tab in Lumetri color to dial the footage in. Will this always stay in the settings tab or could this be placed at the top spot in the edit tab in Lumetri?" This is a really good question/feature request and requires some considerations.   @Alexis Van Hurkman do you have any thoughts on that? I think that it's great that there is a scene-referred, managed exposure slider available even when using Direct Rec.709 where this especially matters since that of Lumetri's is based on normalized content. But it is incredibly cumbersome that you'd have to switch back and forth. I can think of two possible solutions. 1. As  @Agrarvolution suggested, move the entire sequence clip management over to the main Lumetri Panel as a management step before the Basic section.   Example: 2. Transform the Exposure slider of Lumetri itself to function the same as that of the sequence clip one. This is more complex and requires an inverse DRT for all tonemapping methods but that will inevitably need to be made anyway to make ACEScct workflows work...   I personally would favor option 1 as this cleans up a lot of the messiness that is currently on the management page which mostly comes from the fact that it is all possible features from global/display related down to a clip in a sequence is presented as a flat list of sliders and dropdown menus. It also allows the editor to become more aware of the state of how the clip is processed at any point in the production without the need to go to Lumetri's settings to look for it. ... View more

Ah I see, yea I saw your question on where source clip effects get processed in the chain. There's probably a simple way to test it and figure out but a reply from staff would be more practical. ... View more

Raw files Working with BRAW is easy I think. If you'd want to work in ACEScct working space you can set the raw decoder to that which is possible with BRAW. Then match it in the clip input color space. If you want to handle all color and display conversion from the BRAW file itself, leaving it tagged as Rec.709 in a Direct Rec.709 timeline isn't any different that you'd normally work with. But it would be good if Premiere Pro added BMD Film Gen5 and DaVinci Wide Gamut/Intermediate to the list.   For ProRes Raw, I've never worked with it but the same principle applies. If you can convert it to any of the log color spaces know to Premiere you can use that as a bridge to get it into ACEScct or display. Ideally you use the log space that was 'native' to the camera like SG3.cine/SLog3 if it was a Sony etc. Otherwise it could becomes an ambiguous mess.     Lumetri's vs curves I believe Alexis mentioned ongoing work into Lumetri to make it more robuust in Color Space Aware context but not all aspects of it have been polished. What you're experiencing is the 'default' versus curves math operating on a log image which only holds a very low saturation in that state. The curves were never designed to get predictable results or fine control on such images. Even those of DVR suffer from the same principle.   It isn't super trivial to build more sophisticated tools and in the case of Lumetri, the range of usability is also incredibly limited by how the UI is presented to the user. It's tiny, fiddly and very basic by nature as it is not a real color grading environment. The work Filmlight put in it's newer curve tools is quite inspiring. Perhaps we can get something slightly similar some day in Premiere, that would be quite cool. https://youtu.be/tW4Ieih5LVI ... View more

Looking at your new examples it's looking a lot more sensible. One of my initial feedback on Premiere's colormanagement was that I felt they were putting the shadows/black very high and overall perhaps a little too sparse on contrast but it generally serves as a usable starting point. It would probably be a bit better if they added a bit more so those that don't want to color correct or grade can use it out of the box with a good look.   The gamma story is sure another discussion but also heavily can influence the preception. Premiere works with Rec.709/2.4 only. You can shift the viewer gamma but that only influences your viewing condition, not the image itself. Having Display Color Management in Premiere or Use Display Color Profiles in DVR enabled also impacts your view if the display you are using is not calibrated/set to your deliverable specification.   The last piece in this situation is the point of color operations you're preforming. I forgot to check/mention that when adding contrast in an intermediate/log space this happens underneath the tone mapping. You typically want to grade before display conversion so you have the best control over the image. In your Premiere managed setup this wasn't the case I believe so grading it will feel limited. You can try the Wide Gamut Tone Mapped preset, or manually switch the working space to ACEScct whilst keeping the By Channel tone mapping. Then you will see that Lumetri and Brightness & Contrast effect will feel very different and much better to use.   The only caveat if you've been following this thread a bit is that ACEScct workflow isn't fully usable yet. You can deploy it for grading but you currently can't have display referred images look the same as the source so logos/graphics etc in sRGB/Rec.709 will look off. They say they're working on it so hopefully this is in a near future update. ... View more

It is true that Premiere Pro's tone mapping does not have much of a preferential rendering and 'beefy' contrast going on compared to others but your DVR example looks quite 'overcooked' and I doubt it is a correct 'conversion'. Feels like a lot of contrast and saturation was added on top.   DaVinci uses a per channel style tone mapper by default. You can set Premiere's to "By Channel" to get a more similar look. You can try the Brightness & Contrast effect to add contrast if you feel like the range of Lumetri's sliders are too limiting. The brightness slider is the equivalent of Offset in DVR and contrast is the same as that of DVR too if "Use S-Curve for contrast" is disabled.   Keep in mind that the Shadows and Highlights sliders in DVR are spatial effects. Premiere/Lumetri do not have such operations in their grading tools. Do you really think something is broken? What does DVR look like without any adjustment at all? Just fully disabled color management and a single CST node converting Rec.2020/N-Log to Rec.709/Gamma 2.4.   If it's still a big difference one of the two softwares may have a faulty N-Log transferfunction in place... ... View more

Hey @Alexis Van Hurkman , I'm having a look at the changes to Lumetri's Color Space Aware behavior. It's looking quite good with the Basic section! Quite predictable and smooth behavior. My only feedback there is that I have my doubts on their min/max ranges. Some sliders feel too limited which in some scenarios would require stacking of Lumetri to go further. Maybe there can be a better sensitivity middleground between ease of use and the need to hold down CTRL/CMD to finetune the value.   Where it looks off is the Curves. Clipping black by sliding the bottom anchor to the right starts off making negative values first, then raises the black clipping level up the more you go to the right. The same happens with white dragging to the left. Further more the 0-1.0 clamp is still present so data is not recoverable with subsequent operations. I get that you'd probably never do such drastic operations but I'm trying to battle test the tools here :).   Adding points in between making curves does feel very nice with better distribution across the tonal range compared to unmanged context working on log data. But what I'm also struggling with is highly compressing highlights/specular for 'filmic' curves. Even when smashed down to half point, the DRT still plots them quite high. Maybe this is due to the range the curves are covering in managed state? Do you think that can be improved?   ... View more

That's a nice little improvement! Thanks for this and notifying us about it. ... View more