LOG footage not displaying correctly in 2025

[David24494391e3h5]

I tried updating to 2025 this morning and opened a project I had been working on the day before. All of my c-log3 footage from my C70 looks washed out. I use LUTs to convert from clog to rec709 not premiere's color management. I double checked to make sure my clips, timeline and program were all set to rec709 and they were. This is the worklow I have used daily for many years and have never encountered this problem. I tried making new sequences, new projects, importing new footage, reapplying LUTs and always got the same result. I cleared the cache, reset preferences, all the ususal troubleshooting tips and rolling back to 2024 was the only thing that worked. 

The issue is only affecting my raw camera footage. Stock asstets and previously exported footage all look like they should. Here is a screenshot of an exported test clip from 2025 next to the program view in 2024 showing what the footage is suppoed to look like along with my computer specs:

 

 

[Kevin-Monahan]

Hi,

Please provide the developers with more information. See, How do I write a bug report?

See if the issue is resolved in 25.1 Beta.

Thanks,
Kevin

[David24494391e3h5]

I tried using 25.1 today and had the same issue. I have since tried going through other versions from last year and discovered that this issue first began with 24.4.1. Any version 24.3 or older works just fine, but 24.4.1 onwards I am seeing the same result.

I also tried opening it in Davinci Resolve and it looks just fine over there…

2019 Retina 5k iMac 27-inch

macOS Sequoia v15.1.1

CPU: 3.7 GHz 6-Core Intel Core i5

GPU: Radeon Pro 580X 8 GB

RAM: 16 GB 2400 MHz DDR4

Hard Drive: Macintosh HD

The videos I’m using are 1080 XF-AVC YCC422 10-bit .MXF files recorded in Canon Log 3 / C.Gamut on a Canon C70

[David24494391e3h5]

My assistant editor and I stay on the same versions to preserve compatibility between our projects but I had him roll forward to 24.5 to see if he is getting the same result with the same files and he is not. I tried 24.5 once more just to make sure and and I am still getting the same problem.

His Mac is a newer model than mine:

2021 24-inch iMac

macOS Sonoma 14.4.1

Chip: Apple M1

Memory: 8 GB

Hard Drive: Macintosh HD

[R Neil Haugen]

You aren't providing a good share of the crucial information to troubleshoot this.

Exactly what are your full color management options set to? Color Workspace, Lumetri panel, SETTINGS tab. The one named Settings.

Give us your settings, we can sort this easily enough. Personally, as LUTs will clip/crush any out-of-expected data, and the tonemapping algorithms don't, I highly recommend where possible using the built-in algos as the normalization process.

LUTs are simple triplicate look-up/replace data tables, with a limited number of "points", and the computer tries to run a straight line between the given points. Anything on either end is chunked. 

Algorithms use rather complicated mathematical forumulas ... and do not normally ever 'chunk' darks or lights.

All normalization routines, whether LUTs or algos or manual, involve both technical and aesthetic choices. Which is why makers typically provide mulitple LUTs for their cameras.

An algorithmic tonemapping, like a different normalization LUT, will look a bit different. But being as the normalization is only the starting point for using the clip, it's just a difference in the settings you then use to finish the clip.

Now, if you're on a project where the producer or DP says use X LUT, well now ... you use X LUT. They who pays the bills makes the rules ...

[David24494391e3h5]

I am aware of the differences between tone mapping and LUTs for rec709 conversion. There are still many scenarios where using LUTs are a better fit for my worklow. 

I have tried using the tone mapping in 25.1 on my C log files and am still experiencing the same low-contrast look which does not reflect what was captured in camera or what the image looks like in other NLE's or how it looks on my assistant editor's Mac.

I have included screenshots of my color settings with the program view to show how my image appears in 24.4.1 and 25.1 using both a LUT and tone mapping for conversion. 

[R Neil Haugen]

First, you may be misunderstanding color in all of this. It isn't "rock solid" or even close screen to screen. 

No two screens ever show the same image. Color specialists and colorists have demonstrated repeatedly that you can have two identical monitors, side by side, calibrated with the same high-end spectro, fed the identical signal from an AJA or BlackMagic breakout box ... and there will be visisble differences in the image.

And then you add in Macs ... are you talking a Mac without Reference modes, using gamma 1.96 in Qt player? Or a Mac with reference modes, using HDTV and therefore the normal Rec.709 display transform of gamma 2.4?

Then how bright is your surround? Even the same screen will have (visually) two different images when in a bright room or a dark room.

The differences between the LUT image and the algo image above is very slight. If you do any post-normalization mod of color/tonality, then it's just a slightly different starting point.

Personally, I've never used an image straight from a normalization LUT or more recently algo tonemapping, whether in Resolve or Premiere. But we all work differently.

[David24494391e3h5]

I think you are misunderstanding the issue I'm having. If you look at my original post, I am not I am not talking about a difference between two displays or two IO devices or two screen brightness settings. I am talking about a difference between the way my video files appear in one version of Premiere Pro vs another on the same system, on the same screen with all the same color management settings.

It is not even the LUT that is the problem, it is the way LOG footage looks even with no efffects applied.  These differences are consistent after export as you can see by this comparison made with frames exported directly from the timeline in Premiere. The conversion LUT makes the differences easier to see but the issue is visable even without it. 

[R Neil Haugen]

They changed the capabilities and behavior of the program a couple different times in the 24.x series of builds. I don't recall exactly which builds had the changes, but there were significant changes that "we" on the forum had to help a ton with during the 24.x cycle.

It seemed like every update release had something new in CM that caught some by surprise.

So that different builds reacted differently is expected due to the changes being made in the program.

[David24494391e3h5]

This is what I've guessed was wrong from the beginning but I always stay open to the idea that I have made a stupid mistake somehere and left a setting unchecked. I didn't update Premiere for most of the latter half of this year because I was expereincing some performance issues, so I mistankenly thought this was a 2025 problem because I had jumped over so many versions but narrowing it down to 24.4.1 makes a lot of sense. I do remeber that that was when color management was recieving a major overhaul. 

[R Neil Haugen]

This 25.x color management is not, in any way, shape, or form, the color management that was used in even the early 24.x builds. Nor was late 24.x the same as early 24.x.

Yea, that much change. And while there was a lot of change during the 24.x cycle, the shift to 25.x was massive.

They do now have a way, if you understand how the various options work and how they interact or not, to do most needed professional workflows.

But as Shebbe has pointed out, especially in user posts on the Beta forum, not all professional workflow needs are yet handled correctly.

For instance, some LUT uses we can do in Resolve, involve applying CM changes into and out of various spaces within the clip on a sequence. You can't do that in Premiere at least yet. With Van Hurkman in charge of color management now, I'm thinking even that will likely come to Premiere.

For specific example, in Resolve, many colorists use node-based CM rather than having Resolve do the CM stuff. And only with their specific and at times extensive "node trees". A node trees is well ... preset, if you will, of many nodes/layers of work, which can be turned off or on individually.

And in Resolve you can apply a color space conversion from X to Y within a node, and at the end, another to go from Y back to X.

For many things that is handy, as it means a color correction tool works more 'normally' for that tool. It's given the type of data it works best with, or is designed to work with.

Such as the general Contrast control, which adds an S-curve to the data shape. If you have a Resolve-controlled CM setup, it can at times put a curve on a curve ... which can really be bad. 

We can't mod the color space within a sequence in Premiere though. So any CM changes have to be set in the extant CM controls. 

So you can apply a normalization LUT as a sequence thing, or even as a "source clip" effect, and do so such that you can trim the clip pre-LUT. But you can't if you apply the LUT as an Input LUT in the CM controls.

And depending on the CM space options the LUT expects, that may not ... work.

[R Neil Haugen]

When using the LUT, where do you apply it, and what are the rest of your CM settings then?

[David24494391e3h5]

I did some further experimenting this morning and found that video recorded in rec709 still displays correctly and looks identical across all versions of Premiere. Here are some comparisons of the rec709 screengrabs along with LOG screengrabs from the same recording session both with and without a coversion LUT applied.