Premiere Pro disables automatic log color management for Sony XAVC Slog clips as a default in this latest beta. It now has a new preference setting for easy enabling of the feature.
This is a change from the previous behavior where automatic log space detection and color management for Sony XAVC Slog video was enabled as a default, and imported XAVC clips were color managed.
For Premiere users that did not want their XAVC Slog clips color managed, they had to manually override color management and set each clip to Rec 709.
In this beta, the behavior has changed -- automatic detection and color management of XAVC Slog clips will not be the default behavior. Premiere users will have to “opt in” to use it.
Premiere Pro users can decide if they want automatic detection of Sony XAVC Slog clips, and color management by enabling the new “Log Color Management” setting in the preferences panel, by going to File > Preferences > General and checking “Log Color Management”
FOR LEGACY PROJECTS WITH XAVC CLIPS INTERPRETED AS SLOG
If you have legacy projects with XAVC SLog color managed clips, and you want to keep working with this workflow, you’ll have to enable the Log Color Management preference after you open your project. Clips that were automatically detected and interpreted into log color space will only be color managed if Log Color Management is enabled.
ADOBE MEDIA ENCODER
The Log Color Management preference is also in AME so Premiere users can enable and disable automatic Sony XAVC Slog detection and color management on export.
COLOR MANAGEMENT GOING FORWARD
Sony XAVC Slog is currently supported for automatic detection and color management with this new feature, support for Panasonic and Canon Log formats are coming soon.
Automatic detection and color management for log video formats is one part of a larger color management and tone mapping system in development for Premiere Pro that will be introduced and validated through the beta program.
Automatic detection and color management will always be opt-in for Premiere users, the Rec 709 and LUT-based color workflow will remain as the default.
We want to know what you think. Please join the conversation below.
21
Replies
This is good on two levels - having the option to turn it off is great and the fact that the actual colour management works now (compared to say v22.5 which was the last I looked at it when it was blowing out highlights on Sony log footage - screenshot is same clip, same settings in Pr).
I agree with @Shebbe — this is just a temporary "band-aid". By trying over simplify color management without proper color science, you eventually end up forcing your professional customers to use other tools for color critical work. I understand the goal of trying to simplify color management, but the direction that lead to this "Log Color Management" enable/disable option, unfortunatley seems like a result of making fundamental changes to the image processing and color pipeline, without fully understanding the complexity and needs of your professional customers.
I know you are working hard on improving color management and I appreciate that you publicly share new features and ideas with your Beta community like this. However, I do not think any of your professional customers feel confident about the direction you are heading in, based on features and ideas shared in a context like this.
I would highly recommend that you try to communicate a clear direction for where you are heading in terms of color management. In fact, at this point I think you owe it to your professional community. There is already a statement that was made back in 2021, regarding OpenColorIO and ACES from Adobe, shared via the ASWF community: https://www.aswf.io/blog/industry-support-for-ocio-v2/
Adobe
Adobe is currently working to implement an ACES workflow inside an OpenColor IO v2 wrapper for its tools most often used in production pipelines: Photoshop, After Effects and Premiere Pro. Lars Borg, a SMPTE Fellow and one of the developers of ACES, is a core leader in Adobe’s color team who is leading the charge. His colleague Patrick Palmer, Principal Product Manager for Professional Video, notes that the ability to support ACES in OCIO v2 without a 3D LUT is a significant step forward to driving broad-scale support for ACES, and that the improved GPU renderer in OCIO v2 is a critical area that will drive adoption.
Palmer also shared the following about Adobe’s roadmap: “We are looking forward to having one means of setting up a consistent viewing environment for high dynamic range (HDR) footage. Adobe tools are found in nearly every production pipeline. While our tools have supported almost any colour working space, creating a viewing environment consistent from the set through to post-production, which often spans multiple vendors, was complex and required a high degree of management. We feel that by supporting OCIO, our users will work with higher confidence about what they are viewing. OCIO is becoming standard and allows us to have the same framework as other applications – which yields the same results in all participating products.”
If this really is your goal, why not share that here in the Community forum as well? ACES via OCIO is already in beta for After Effects. Clearly, you would need to also support ACES via OCIO in Premiere Pro, in order to handle color management with Dynamic Link and After Effects.
To those of you in this user community, who still don't understand or appreciate the complexity of the whole situation. Here is an attempt at showing an example of why many professional customers are confused and frustrated.
Transforming Wide Gamut High Dynamic Range images to SDR BT.709, without proper color science, tone mapping, gamut mapping and gamut compression, leads to critical issues like the example in the attached image, with clipping colors and horrible looking images.
If you think this is just an "edge case", think again. Lots of very smart people spent months, if not years, on this particular problem within the Open Source ACES Working Group community. As we speak, they are working actively on ACES 2.0 with new and improved Output Device Transforms: https://community.acescentral.com/t/aces-2-0-cam-drt-development/4700
For those of you unfamilar with the fundamental understanding of color gamuts, gamut mapping and gamut compression, have a look at this introduction to the topic: https://github.com/jedypod/gamut-compress/blob/master/README.md
If some of you still wonder why the use of "Log Color Management" in Premiere Pro in its current state is an issue, have a look at the difference in the attached image below. This is one of many reasons why real professional workflows don't rely on Premiere Pro for color grading and finishing. It is also one of multiple reasons why many who are forced to use Premiere Pro for color critical work still rely on LUT based workflows, using professional LUTs created by color scientists and camera vendors as their Output Device Transform (ODT), and do any color adjustments before/under the LUT (ODT).
Thank you for the reply Eric.
I understand your idea of Premiere Pro not being a grading/finishing app but I don't believe that is a good enough excuse to have a very sub-optimal workflow environment which is what currently is being implemented. I think with the right changes to the current workings Premiere Pro can greatly improve as an editing software and become a very capable grading and finishing app for anyone that wishes to stay within Adobe's package.
Looking at the current beta I see that a new box is present in the preferences: Auto Detect Log Video Color Space.
While I think it's already a much better descriptor to the function, there is still the big color management design problem.
If we use log footage in a Rec.709 timeline there's no conversion. If in a Rec.2100 timeline the log clip gets converted from Rec.709 to Rec.2100. This disables the ability to use the clip for both SDR and HDR output at the same time. And even for HDR only we are forced to tag the clip the same as the timeline to get rid of the conversion to be able to actually treat is as non managed data. Further more, dynamic linking a clip from AE removes the colormanagement and thus the ability to use Adobe's tone map feature.
That's why I said in my initial feedback that all colormanagement should be removed by default and we should have full control for when we do want to utilize it regardles of file type. So like AE don't do anything, but if CM is active give the option to perserve rgb instead of being forced to pick a colorspace.
We are of course working to expand what's possible and, more important, useful to the largest number of Premiere users. Lumetri is limited in the kinds of corrections it can make, and currently can only make those corrections downstream of our tone mapper. If you need to make adjustments to the pre-tone mapped image, you can't. Not right now. The current workflow doesn't support that.
By @eric escobar
I think Lumetri could use some very easy to implement improvements to support professional workflows. I made a suggestion here. To get it to work with the tone mapper it would have to be applied before tone map ofcourse. But it would be gold already for custom DRT/LUT managed workflows.
A user who has a mixed bag of source clips (iPhone, S-log, V log, etc) that don't need pre-tone mapped adjustments can drop them all on to a timeline. They don't have to use LUTs and get to see a nice looking image "right out of the box" for most of their shots. Maybe they have a couple shots like the Elvis clips you shared. This kind of shot, even with a LUT, require a pre-LUT operation (-1 exposure in this case) to get a correct image.
So this is where a user can just interpret that clip as Rec 709, do a pre-LUT operation on it, then apply a LUT. Both color workflows can exist on the same timeline.
By @eric escobar
I can't fully agree on "nice looking image ootb" with the current tone mapper. That Elvis shot may be an extreme example, but bright colored lights and displays are incredibly common and easily generate such problematic data. Most of it is handled much better by other DRTs out there.
This is that same clip through other renderings without any extra adjustments.
The tone map feature also doesn't feel like a DRT at all. It feels like a straight conversion with a very simple highlight compressor for values above 1.0. Even for "simple" shots it looks unusable to me. A DRT should render the scene as closely as possible as observed in real life within the limits of the target display.
I get that you mention there is much room for more robust pipelines and tools, but I have a hard time seeing the point of even implementing one that is already sub par everything else. Especially if this launches but gets improved by the next itteration and people end up having differences in older projects unless the new, better tonemap lives as second option next to the now already legacy old one.
That's far from desirable I would imagine. 😉
AdChoices
