Hi Shebbe,   Your feedback has been received, and while we've moved forward with releasing what's been in public beta based on the broader positive feedback we've received, this is only the beginning. We're acutely aware of the tone mapping of SDR media in wide gamut and are in the process of providing a solution for this in a future release. For now, Wide Gamut is being made available for projects for which the current behavior is not a problem. Ideosyncracies such as this are why we're taking such pains to document this behavior for users, and it's why Direct Rec. 709 remains the default, available for people who need SDR to pass through the system as expected.   Regarding your prior observations, EXR color management is a larger issue for which there are no near term solutions, although again we're aware of this and it's on our long term road map. The other issues you'd brought up earlier are being explored internally. As always, we appreciate your detailed feedback, and ongoing improvements to color management are planned in a future release. ... View more

Thanks for providing the sample clip, I can see what you're describing. May I ask which phone you recorded this with? And I'd be interested to know what camera settings are available and were set when recording this image.  ... View more

Looking at your new examples it's looking a lot more sensible. One of my initial feedback on Premiere's color management 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.   We have a lot of customers that are looking for the most straightforward, standards-based mathematical conversion of one format into another, without any bias for making signals look more attractive. I've always viewed the underlying color management that we're providing in this first version as management of your media, and not the grade itself, so that's the spririt of this first release.   Down the road, there's plenty to explore in terms of providing options for more opinionated output, perhaps in the tone mapping, perhaps via other means, and we're exploring what makes the most sense going forward. However, these fundamentals are intended to provide the best starting point for grading, to do no harm to the image, and to be as standards-based as we can. ... View more

@Shebbe There's some work to do to make third party plugins compatible with the new wide gamut option, and now that we're largely finished with this first version of the new system, we're looking at what needs to be done to enable third party plugins to take advantage. Everything should work correctly in Direct Rec.709, though.   The color space of nested sequences is based on the working color space of the sequence. An "unmanaged" sequence is by definition Rec.709 in Premiere, so you're seeing the same "squish" that all SDR clips in a wide gamut tone mapped sequence experience. As I've mentioned, we're in active development of a fix to this behavior, but it'll be some time.    Regarding Exposure, making Lumetri work correctly in Wide Gamut has been a huge, huge challenge that's taken us probably the longest of any single feature in this release. Everything in Lumetri was created to function for Rec.709, and making it function sensibly has taken a lot of time. We've made a few more tweaks that should make some Lumetri controls in Wide Gamut work better (be less twitchy) so long as the color space aware toggle is on. Additionally, we've actually just released another modification to Lumetri to make the Shadow control and the color wheels controls work better in ACEScct (I'm overdue to write an introduction to this). Give it a spin and let us know what you think.  We're getting to the point where we need to lock down changes to Lumetri; once we deliver to GA I don't want us tinkering with the color controls any more (barring anything catastrophic coming up) until the next major release, so as not to version people to death or enforce constant re-learning of a parade of differing behaviors. But rest assured we're hard at work on long-term improvements. ... View more

@Mike_Abbott When making a new sequence based on selected media (for example dragging a clip into an empty timeline or selecting clips and choosing "New Sequence From Clip," the current behavior mirrors Premiere's previous behavior in basing the new sequence's Color Management preset on the format of the clip. Dragging a 709 clip creates a Direct Rec.709 sequence. Similarly, PQ clips create Direct PQ and HLG clips create Direct HLG. We've got users that feel strongly about keeping this behavior so this was our starting point. HOWEVER, I've been exploring introducing a preference mechanism for allowing users to (a) choose a default Color Management preset that they always want to use from a drop-down, with a secondary option to (b) Match the preset to the input color space of selected media if possible (to allow the original behavior to take place). Would this be useful to you? ... View more

@Shebbe We opted for sequence-based color management in order that people with multiple deliverables would be able to have HDR and SDR versions of timelines within the same project. My expereience with other applications that had project-wide color management was that managing multiple projects for multiple deliverables was a drag. Given the schedule, we only had time for one approach, and while I'm not closing the door on someday having project-wide color management with the ability to override individual sequences, the traditional Premiere Pro approach for these things has been to allow sequence specificity, so we're continuing in that spirit for the moment. Incidentally, the Source monitor color management is now governed by new settings we've added in the Monitor Color Management drop-down. The new default is "Gang to Active Sequence Color Management," so that the source monitor shows clips previewing how they'll look when edited into the currently selected sequence. Whichever sequence is currently in focus, that's the color management that will be used to preview clips in the Source monitor, so this is flexible for people creating multiple deliverables. Additional options include "Show Wide Gamut Source Media as Log," which we introduced previously that shows wide gamut media as a low-contrast log preview, giving you an "unmanaged" look at a log signal (while presenting Rec.709 media normally). Meanwhile, "Show Source in Extended Dyname Range" is the original behavior of the source monitor, where clips are simply shown as is, and wide dynamic range media will be clipped if your display cannot show extended dynamic range, or will appear "HDR-ish" if you have dynamic range. You now have your choice of how you'd like wide gamut clips to be represented.     ... View more

Thanks for the feedback, we'll have a look at these items. ... View more

We're exploring other options we can offer to cater to other workflows, and it's good to see what you're referencing. This is a complicated subject with many, many (too many perhaps) opinions, and we're treading carefully and trying to adhere to standards-driven approaches. ... View more

Since Premiere Pro doesn't have a setting for outputting sRGB, I assume you're setting the Viewer Gamma to 2.2. Keep in mind that, in the context of grading and delivering Rec.709 content, the Viewer Gamma setting is for choosing the appropriate gamma for your viewing environment, while the exported output remains Rec 709 (which assumes a signal being played on a display using the BT.1886 EOTF). So, the tagging applied to the exported output and the Viewer Gamma setting are not linked, and the Rec 709 tag that's currently being output is intentional.   This is the intended workflow, as the viewer gamma setting is about making sure you're looking at the image in a way that accounts for the viewing conditions — 2.2 is for a display in a brightly lit environment, while 2.4 is for a display in a dimly lit living room environment. But the same Rec.709-encoded signal is shown in either case. This is how these gamma standards are intended to be used, the idea being that perceptually an image displayed with gamma 2.2 in a brighter ("office") environment will look the same as the same image with gamma 2.4 in a darker ("living room") environment. And in all cases, a Rec.709 signal output via Transmit to a calibrated external display in a reference viewing environment should look identical (assuming the displays are set up identically).   Secondarily, the Viewer Gamma setting helps make sure that the Premiere Pro viewer matches the viewers of other applications (that make different, non-adjustable gamma assumptions) on the same machine, so you can verify client feedback based on what you know they'll be looking at on their computer's display (such as QuickTime).   We're working to make the monitors in Premiere Pro function more as external monitors would, with the different adjustable settings one would expect to make sure you're seeing what you need to be seeing given any one of a host of workflows. Some are automatable (viewing format) while some are not (viewer gamma) as we don't know your environment.   Hope this helps! ... View more

Could you share what was output that doesn't match, and in which way it doesn't match? ... View more

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

I've watched your video, and the first piece of advice I would give you is to change the output color space to Rec.709. Even if you like the results you're getting using the Direct HLG (HDR) preset, what you want is an SDR signal, not an HDR signal, and having the output color space set to Rec.2100 is likely messing you up, as it's what's allowing the clipping to happen (in order to output HDR). Additionally, however, what's really making your footage look better is you retagging it to identify the media color space of each clip (which you can do in batch in the Project Browser selecting multiple clips and using Modify > Color). However, if you want your renders to match your output, you shouldn't change from the Direct Rec.709 preset, that's still the appropriate preset for the SDR output you want. The HLG preset may show more vibrant colors, but it's allowing signal ranges that cannot be output to Rec.709, so using that setting is what's causing your probem. It's really for outputting HDR. That said, if you've already set up your sequence this way, changing the output color space will tone map everything back down to Rec.709 levels, but you'll likely notice that the output becomes similar to what the Direct 709 preset would have given you, which is correct.   The purpose of the presets is to set up color management to correctly transform and normalize all of your media to the neutral state your camera produced, not to make it look different or "better" (that's what Lumetri is for). My advice is to stick to the default Direct Rec.709 preset, make sure all of your clips are tagged correctly using Override Media Color Space, don't turn on Preserve RGB for any of your clips (unless you're assigning an input LUT to those clips), and make sure your output color space is set to Rec.709. You can go ahead and customize the input tone mapping and input gamut compression settings of each sequence clip to taste, that's what those settings are for, but leave the Color setup preset to Direct Rec.709. At that point, adding a creative LUT in Lumetri should work fine, and if you want any particular clip to be more saturated, use the other Lumetri controls. ... View more

Additionally, keep in mind that turning Preserve RGB on results in those clips not being color managed. You may get better results from turning Preserve RGB off on these clips, unless you've tested that and decided you prefer the result of suspending color management for those clips. This setting is mainly for people who want to use LUTs to convert their footage instead of the new color management. ... View more

A few questions will help me help you. It looks like you've chosen an HDR workflow for color management, and you're currently set up to output HDR video with very bright highlights intended for displaying on an HDR display. Is this your intention? In any event, the preset you've chosen for color management is designed to provide a pass through workflow for HDR media, which is why your source media is clipping so badly. If not, if you are intending to output a regular SDR clip you should try duplicating your sequence for safety, and then changing the Color Setup drop-down menu to Direct Rec.709 (SDR) which will set that sequence to work more similarly to how Premiere Pro has worked in prior versions. Particularly since you're using titles, this would be the safest way to get what you need.    When you do this, all color adjustments you made while using the prior preset will need to be redone, because grades are dependent on the working color space, which is now Rec.709. However, you'll be in a better position to output the video you need. Hope this helps! ... View more

Hey Ian, that's great news and I'm glad the new color management worked out for you. Now that you're getting used to the v25 lifestyle, you might want to check out the beta documentation explaining what's new in CM at https://helpx.adobe.com/premiere-pro/using/color-management-improvements.html. The "Direct Rec.709 (SDR)" preset is the safest one to use at the moment, and keep in mind that the new color management system is still in development so things may change a bit when you upgrade the public beta, which might include how certain effects render and how media looks, but otherwise we spent a lot of time making sure that legacy projects would open up and look right, so I'm still interested in seeing your original project to see what looked different.   However, I'm really happy you got your project working using our new system. Cheers! ... View more

Also, upload the entire project... ... View more

My sympathies, we've all been there. I'll inquire with the engineering team to see if there is some recourse for moving your project back to the previous version of Premiere. I can't promise you anything, but we'll see what can be done.   In the meantime, could you duplicate your project, delete all but 4-5 clips and their accompnaying adjustment layers in a single sequence that include clips that respond correctly and clips that don't respond correctly, delete all other sequences, and upload that project and the corresponding media files so we can have a look? Version 25 introduces a significant new color management system, and while it's been created to import previous projects with the original color, and I've just now tested LUTs in adjustment layers to verify that this isn't broken, it may be that the LUT you used in the adjustment layers for the clips that aren't being converted correctly somehow got lost. You may check those LUTs, maybe re-load them, see if that solves your issue. Otherwise, please upload the simplified project I've requested and we'll have a look.   Again, sorry to hear you're having a hard time. ... View more

Sorry you're having a bad time, and as Ann suggests, I think you'll be better served by reverting to v24 since your project was completed there. However, I wanted to get more detail on one of the issues you mention; is the issue that the non DJI clips you graded don't look correct in the Program Monitor of the new version? Or is the problem that the thumbnails in the timeline don't look right but the clips look as they should in the Program Monitor? From the photos you provided it's difficult to know if the clips in the monitor look right as they appear normalized. ... View more

Hi Shebbe, here's the detailed response I promised... - 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. - 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). - 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. - 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. ^ 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. - 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. - 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. - 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. 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! ... View more

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

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

Assuming you've checked the control that @Ann Bens pointed out and are still having a problem, could you provide a copy of the project for us to investigate? ... View more

Thanks to everyone for the insightful feedback! While there's been no reply in a while, rest assured all of these comments have been read and received. Our initial implementation was meant to fit into the current framework of how things are presented in the Wrench menu, but this feature is intended to continue to evolve in the coming months, so it's good to have everyone's thoughts, and any information anyone would like to share about their workflows involving selective channel monitoring would be welcome… ... View more

Good catch, thanks Ann! And thanks for posting your own clarification here… ... View more

We appreciate your feedback! The new Scroll to Zoom behavior was added to ease the process of doing detailed title editing, motion graphics keyframing, and image examination when troubleshooting for artifacts and other visual issues.   Based on early positive feedback, we felt comfortable introducing this new behavior as the original scroll-to-jog behavior remains available in the area above the scrub bar at the bottom of the Program Monitor. In the process, this enables two behaviors without needing to obscure either functionality behind keyboard modifiers.    We understand that changing existing UI can be frustrating, but encourage you to try using the new scroll-to-jog target area (highlighted in red in the image below), to see if it's able to meet your needs.   These features will continue to evolve as we have more plans for refining these sorts of in-monitor behaviors, so we value your opinion and look forward to hearing what you think after continued use. In the meantime, if there's a specific workflow you'd like to share with us, it would be valuable to get more information about how you've used scroll-to-jog in the past. ... View more