Problem with Lumetri curves

[cctriad]

Hi,

first of all, my English is a bit rusted, so sorry for any mistakes.

I'm using the latest version of Premiere and for some days now I experience a problem with the Lumetri curves.

Whenever I start to alter the lower tones the image gets a yellow-ish tint.

Same happens when I touch the "shadows" and it happens with any footage of any codec I want to use.

This effect does not show when I use the obsolete curves.

I'm right now in the postproduction of a big project, so I hope you can help me out quickly.

Thank you very much,

Chris

[cctriad]

Just talked to a friend and he confirmed the same problem.

[kokmanos]

It is a known behavior that has now been acknowledged officially by Adobe. The User-Voice is full with such reports. It makes Lumetri completely useless. Right now the only option is to use good old RGB curves and/or fast color corrector.

Also there are several bugs regarding LUTs, where you see a color shift while playing/pausing.

Alternatively, if you have time, have a look at DaVinci Resolve. It seems Premiere is really far behind in color science from competition.

[cctriad]

Depressing to hear that.

As you said, it makes Lumetri completely useless.

[R Neil Haugen]

I use Lumetri a ton ... daily ... and just got back from NAB. Spending a lot of time talking with other users, and actually colorists in general.

Not only can I NOT replicate this, I didn't hear a word about something like this from anyone.

I went to the UserVoice system to see how many reports there were ... and with "yellow", "yellow lumetri", "curves", and "curves shift colors". I got one or two actual things of possible similarity on each. Several of them referring to issues from a couple years back that have been changed.

So sorry, I can't see that this is a huge problem across the user-base. Which does NOT change that if you're the user getting this sort of thing, it's gonna be a right royal pain. THAT I most certainly do get, as I've been there myself of course.

Understand, I have my own issues with Lumetri and many things in the operations of Pr ... I've a vast number of bugs & feature requests filed, the engineers at NAB know me and know they'll get an earful.

So ... if you're having this problem, more details on your system, media, and the way it shows up ... the steps involved, posted both here and the UserVoice system would be helpful.

Let's see what the heck is going on.

Neil

[R Neil Haugen]

This is NOT normal behavior in Lumetri ... so let's start with some troubleshooting basics.

First, of course, the standard OS/CPU/RAM/GPU/vRAM, and what Mercury Acceleration option is in use? (Not to blame the hardware, just to see if commonality can be found along the way.)

Next ... what is the media involved, created by ... what? What other effects are involved? And what exact steps did it take to get the behavior?

If you could share a couple frames of a clip, I'd be happy to try and replicate.

Neil

[cctriad]

I'm working with Premiere everyday, that's my job.

I experienced the problem the first time a few days ago, but I thought that I had maybe done something wrong before

locating the problem within the Lumetri curves.A week ago everything was fine. (As I said earlier: I talked to another Premiere

user some hours ago and he told me he had the same problem, waiting for a fix)

For this project I'm running Win 10 (64Bit) on a Dell notebook with an i7-7700HQ , NVidia GTX 1050 Ti, 16GB RAM.

I can't really understand what is happening. As soon as Im touching the curves towards the lower tones, something goes out of control.

[R Neil Haugen]

I think I may understand your puzzlement ... ?

There are two parts to the 'contrast' we see ... Luma (pure brightness, apart from color) and Chroma (color, apart from brightness).

However ... in the file, they are completely linked. If you increase contrast, you are naturally increasing both forms of contrast, Luma and Chroma. And in dropping a section of a curves, you are increasing the overall contrast. These curves are SO fast to respond, that it is easy to add a TON of contrast fast.

A very common thing in tutorials for colorists who love working with curves, is the continual balancing act between the curves tool and the saturation controls. Because of the interlinked nature of visual contrast.

I get the same reaction on my computer's "confidence" monitor. That is very tightly spec'd for video sRGB/Rec.709/gamma 2.4/brightness 100 nits, in my moderately dark room with measured bias lighting between the monitor and background was. And after profiling by Lightspace, nothing ever goes above the all-important delta-E 2.3 line. So I'm comfortable with a proper viewing situation for Premiere.

If you drop the lower end, via either the general RGB Curves tool or the Color Wheels ... Saturation as shown in the Vectorscope YUV goes up. If you raise shadows, Sat goes down. And ... the actual same reaction ... if you raise Highlights, Sat goes up as you've increased overall contrast. Lower highlights, Sat goes down, as you've decreased contrast.

But I get the same changes whether done in Curves or the Color Wheels ... or just raising Contrast with the contrast tool in the Basic tab.

I know this will happen, and just expect it ... in fact, depend on this as I work in the process. So it's become very natural to me. Whether in Pr or Resolve.

Neil

[Ann Bens]

Did you try trashing preferences?

[kokmanos]

Ann, I understand you want to help but not every problem is a preferences problem. We have to accept at some point that Premiere is full of Bugs. We are all tired of trying to debug and delete our preferences once every now and then. Setting up our preferences again is a time consuming process, which almost every-time has no effect on solving our issues.

Neil, There are 2 or 3 posts with video, if you search for better terms such us lumetri color shift, play/pause, etc, showing why you should not use Lumetri for important jobs. Sure, I've used Lumetri a TON myself for quick projects that I don't care about the color too much. I would NEVER color-correct or grade a commercial or an important job with Lumetri however, knowing It's algorithms are faulty. Several adjustments (exposure, saturation, ect.) produce weird results compared with PRO tools such us DaVinci Resolve. I don't know who you talked to at NAB but that is something almost every PRO editor know.

[Ann Bens]

I know there a bugs but trashing preferences can solves issues and if you dont try you wont know..........

On a side note I cannot reproduce on my machine, makes me think it is system related.

Windows updates can also mess up the system. Recently a entire program was deleted....

[R Neil Haugen]

Besides being around 'here' a few minutes at a time, I also am one of the few "contributing authors" for mixinglight.com, past the three founding colorists. That's a pro colorist's subscription website. My "beat", not too surprisingly, is Premiere, focusing on color. I taught in the Flanders/MixingLight booth at NAB this year, and you can find the chart listing speakers and times online. Tuesday was after the guy in charge of HDR for a major player in creating standards and delivery systems (including certified setups for colorists and theaters) ... and Wednesday was after a guy for whom "He wrote the book ... " would be inaccurate. He's written several of the most-read books among pro colorists.

The MixingLight guys/gals, the colorists in general ... those are the people I tend to be "around" at NAB. They use Resolve, Avid, Baselight, Mistika ... all just tools. None of which are perfect. Oh, and the engineers and program heads at the Adobe booth, of course.

When the colorists I know and work with get a grading project that comes with one or more LUTs, they immediately do stress-tests, as of course nearly every LUT made will break and do not-good-stuff if pushed the wrong way. Then need to know ... and/or create a replacement that accomplishes the main goals without creating problems.

They know how to break every grading app out there. It's their job to know this, right? (Love hanging with those guys & gals.) Some of their shops are still locked down to Resolve 14 as they never found a version of 15.x that was either/both stable and with tools that weren't "broken" in their use. Some are on 15 eager to move to 16 as they test and find it stable. One guy was the major in-booth demonstrator of Resolve 16 run by the big Resolve panel. Good friend.

What ... did I say some think Resolve isn't perfect?

Of course not ... it's a tool made by humans, and well ... if you do certain things in it, weird ... stuff ... happens. As in anything.

Some of the major colorists ... who I am quite comfortable in thinking know a ton more about this than the "almost every pro editor know" ... are quite comfortable and confident of the color science and tools of Lumetri. There are major, award-winning teams that have used Lumetri extensively in their 'film'. And some who've had something odd happen on their system.

Which is a natural part of Life. And is why some shops never moved to Resolve 15 ... on their system, it had problems. For many others, undoubtedly most users, Resolve 15 had at least one version that was both stable and reliable for the tools.

I can't replicate many of the 'issues' that some have with Premiere. And some things I see people having problems with are caused by not running it on a system set up for the intense, hardwired, internal color management that Pr does. Confirmed by the MixingLight founders among others ... Pr is built to tight standards for color. It must be run on a system with OS and monitor set for long-time broadcast standards ... video sRGB, Rec.709, brightness 100nits, D6500, gamma 2.4

Run a calibrated and profiled system for what it is designed to run on, and gee ... suddenly, you can load say RED clips in Pr and Resolve, and pop them both open ... and see identical images. I do ... that's the kind of thing I test for.

And if Robbie, Pat, and Dan couldn't replicate my work, they woudn't 'publish' it.

I'll have a new tutorial up soon there, based on my NAB program ... start to finish, including SDR/HDR viewing, monitors, and exports. Really, at least half the information from that has never been published by Adobe before. And the rest has never really been talked of clearly in one place.

Neil

[cctriad]

Sorry to say this and I dont mean it disrespectful, but your long text doesn't help in any way.

The curves worked, now they don't. Havent changed anything on the system, same happened to a friend of mine.

Guess:something happened within the last updates of Premiere.

[R Neil Haugen]

That previous post was an answer to a different person's post, not your issue.

EDIT: From Lars Borg, Chief Color Engineer, Adobe Video applications ...

That's the normal effect of RGB grading.

If the curve is convex, it desaturates
If the curve is concave, it saturates.
If the curve is a straight line anchored at 0 0, saturation is unchanged. This applies to curves and wheels.

Let's say you have a start color 255 128 64:

- Bring down the shadows or apply a gamma > 1: 255 64 32 => More saturated color
- Bring down the highlights or apply a gamma < 1: 128 100 64 => Less saturated color

View it in the HLS scopes

The action of the 2019 version curves to movement of the mouse seems a bit ... touchier. More change with similar movement. Which naturally exaggerates the viewable result. But it doesn't change anything as far as color shifts with similar contrast changes. That's all math.

This is common across color correction apps. Including SpeedGrade, which I still have loaded and operable. Previous versions of Pr, which I still have loaded and operating. Resolve, which I use regularly ... and in fact has a separate set of tools that "decouple" luma/sat changes ... by internal wiring that is designed to counter-act (without user assistance) what naturally happens to the image data. Because it is a very predictable, mathematical, reality.

It's something that colorists deal with constantly ... and are taught to use to their advantage.

Your sample image has a predominant color palette ... yellow/orange/red. When you increased the contrast by dropping the shadows, mathematically you increased the color saturation of that area. You cannot do otherwise.

And yes, I just went to play in Resolve, and watch the exact same thing. Because ... it's the math. The science.

Again, unless you use say Resolve's "decoupled" tools, which work by doing the saturation changes auto-magically for you.

I do get a faster, or perhaps, "larger" change with the same mouse movement in 2019, something I've complained to the engineers about. I think the curves are way too fast to the touch. We've had some energetic discussions. In that way, yes, it can "seem" like it does this "more", but it's only because you are getting more change in contrast ... therefore, mathematically, more change in saturation.

Neil

[cctriad]

I did trash the preferences, but nothing changed.

As I said, the problem appeared just a few days ago. Before that point everythung was working fine.

[cctriad]

The new update was just installed and BANG: the curves behave completely different.

I'm "careful" saying that, but the main problem is gone now. There is no yellow-ish tint anymore.

[Jorge Jaramillo Hdz]

Hello, I just notice the same Problem (Premiere Pro 2022) the yellow tint added in the curves in lumetri. I tough at first that it was the footage (V-Log Lumix S5), but then I tried to use the RGB Curves (obsolete) and it worked perfectly, no yellow tint, so I'm no longer using the Lumetri Curves. 

Have you still experience this problem in recents versions?

[R Neil Haugen]

Haven't heard of anyone getting this in a couple years.

Could you share screengrabs, just drag/drop them onto your text reply area.

Aand also make a clip available to download so others can test via Dropbox or whatever?

Neil

[Jorge Jaramillo Hdz]

Thanks

It affects yellow and red tones as you can see. 

Up Lumetri Curves

Down RGB Curves (obsolete)

Same settings in Lumetri in both images, just one with Lumetri Curves and the other one with RGB Curves obsolete

[R Neil Haugen]

It's difficult to see in those two images. Could you post a clip on Dropbox to test also?

Neil

[Jorge Jaramillo Hdz]

Here is an example and raw:

https://drive.google.com/drive/folders/11ptb59hiXYuQTG7ysZAYQdtdsmVCYVzQ?usp=sharing

Thanks!

[Jorge Jaramillo Hdz]

Hi Neil, did you had the opportunity to check the clips? I've been testing and the problem is also present in the Beta Version.

Thanks

[R Neil Haugen]

I'll have to get to that later today.

Neil

[R Neil Haugen]

So did get a chance to test this just now. Yes, I can replicate, there is a small shift in Red->Yellow and another subtle shift of Green to slightly less saturated, very slightly more yellow-Green.

I also tried this with both BRAW and mov from my BMPCC4k, and a few other clips I've got on sequences. This media was the only one that got that result, though. I couldn't replicate it with the other clips.

The thing that jumps out at me is that it is a V-log clip. They've not publicly stated so, but to me it's pretty clear their underlying color system is completely rebuilt. The "feel" on my Elements panel working in Rec.709 and HLG for similar clips is different now, and in 2020, it was essentially the same.

Prior to 2022, Pr was a totally Rec.709 hardwired program. They had added "an ability to work with what we call over-range values" for both dynamic range and color gamut, so one could sorta work with some HDR. But it was a temp fix, really.

Now, the app seems totally agnostic between Rec.709/Rec.2100 (using HLG or PQ). Essentially, all HDR media is log encoded, compared to the 'integer encoding' for Rec.709. And some log-encoded media that is supposed to be Rec.709, the app is defaulting to seeing it as HLG, though it is not supposed to.

So some log-encoded media is getting ... odd ... applications now, within Pr, while other log-encoded media isn't.

That's just one of several issues that have arisen, most of which the engineers have acknowledged.

And being as I couldn't replicate this with BRAW, which is also a log-encoded media, nor a couple others I've got in for testing, I'm wondering ... is this something to do specifically with that particular camera, or with Panny V-log in general at this time?

I'll definitely post this where an engineer can see it.

Neil

[jennifers50562858]

Im experiencing the same issue exactly on footage that was shot with canon C-log.

Same yellow-ish tint when messing with lumetri curves.

My footage is from a Canon EOS-R, shot in canon C-log1.

Any news on this issue?