'Auto' button in Lumetri doesn't work properly after Warp Stabilizer applied to clip

Would I prefer this worked as you and I would like? Sure!

I have never dismissed the presence of what you feel is a bug. Period.

But I am at heart a very practical person. "Fixing things" can take months or years. So giving the many users who will read this thread, a workaround on this public forum, is simply a way to help other users get stuff done no matter the crud the app pulls on us. That is all. 

And this, to me, is an issue where you may feel it's a bug, as it doesn't do what you expect. The devs might see it differently. And we all have to allow that others will see about everything differently, right?

To the devs, this might seem simply a result of necessary coding practices, and as there is no consequence with a two-second "fix" option, they may figure with the billion other things on their plate, this isn't a serious enough issue to merit the many hours of time it might take to change.

And that could be a very valid decision. There are a fair number of other things where "do this in X order works, but Y order hits a processing order issue and dorks". Sorting out processing order things in two of the heaviest effects laid on top of each other can be a massive undertaking. And whether it's Resolve, Nuke, Premiere, whatever ... doesn't matter.

And just for the record, I talked about this with the devs years ago, when the Auto button first appeared. Noting that it was causing problems with users applying Warp and Lumetri to a clip. A bit ahead of your post ... around maybe 6-7 years or so ...

@R Neil Haugen  Hi Neil, I know that nesting would bypass this bug but it doesn't remove this bug for me or other users, does it?  Besides, it seems you've missed the part where I wrote that placing the Lumetri Effect above Warp Stabilizer in the ECW makes it possible to use the Auto button, bug-free.  So I already know of a work around.

I know you're trying to be helpful, but suggesting work-arounds while completely dismissing the presence of a bug comes across as calous FYI.

@IanB_360 Here's another Lumetri related Feature Request that would be extremely helpful for your users!  Please take a look and share it with your team: https://community.adobe.com/t5/premiere-pro-ideas/please-allow-copying-lumetri-color-effect-directly-from-the-lumetri-color-window/idi-p/15468447

Out of curiosity, have you applied Warp, then nest, then Lumetri? Just a practical question.

Hi @IanB_360, I just tested it in version 25.4 on my MacBook Pro (running MacOS 15.5).  The bug is still present.

Hi Ian, thanks for your response! 🙂  I'm currently using Pr 25.3.0 Build 84.  You say that it works fine for you in version 25.4.  If that's the case, it's great to hear this bug got sorted out (either on purpose or just as a happy result of the update 😉 ).  I don't remember when this bug first appeared, but it was probably in version 25.3 or 25.2.  It used to work fine, so if you got it working once again, that's great to hear.  I'd love to update to 25.4 right now and report back but I'm in the middle of a big project for a client.  As soon as I'm done, I'll update and confirm if the bug is present or not on my machine in the new version.

BTW, there's 2 Feature Requests I posted that would be tremendously beneficial to your users but unfortunately haven't gotten any traction on this platform.  I did videos to explain the ideas.  I'd really appreciate it if you could share these links with your team.  Hope you enjoy these ideas!

AE-Level Warp Stabilization in Pr:  https://youtu.be/vDpZK3ruET0

Media Overwrite Warning: https://youtu.be/S5yjiwsWrZE

Well, we both have things we don't understand, it seems. I don't understand why so many think a practical explanation ... is a defense!

They aren't the same thing at all, ok?

And it seems pretty simple to me to understand order of processing errors will occur in most of these apps if the process chosen by the user isn't in line with the way the app is coded to work.

That is not a bug, as the processing works perfectly fine ... as you note ... if you use it the way it's coded to work.

There are many things done in Resolve that have the same issue. I'm a user/teacher of both apps, and wow, do users do things in an order there that really screws up their results. Their forums are filled with user's problems with this sort of thing.

And again, even in Resolve, those aren't bugs, they are part of the way the app is designed to work. Processing order matters.

And by the way, did you try nesting after Lumetri, then Warp?

Providing practical suggestions for users to use now, not in some more-perfect future, is a large part of how these forums help users get work done today. Which again is not a defense of Adobe, but a help for other users.

Hi Neil, what you say doesn't explain at all why the Auto button doesn't work if Lumetri comes after Warp Stabilizer, but works perfectly fine if it's before.  It's a BUG!  Not sure why so many highly active forum members (Community Expert, LEGEND) seem to want to defend Adobe rather than call them up on their bugs and ask them to FIX THEM!  What you and Rob might think are positive contributions in fact end up creating a toxic forum environment where zero support is given to fellow users (case in point, both of you chimmed in in defense of Adobe and didn't bother upvoting for a bug to get fixed).

As for your suggestion that users always render and replace warp stabilized clips or nest them because Adobe can't seem to get its software to work properly... are you kidding me?!  Why sould we resign ourselves to do more unnecessary work rather than call out bugs in the hopes Adobe will fix them?  And no, users DO NOT "have to understand the coding issues involved".  That's Adobe's job.  Us users just want our software to work properly, as expected, bug free!  Perhaps stop playing devil's advocate?

You have to understand the coding issues involved. 

First, Warp is by far the heaviest computational load on the system for any effect, even greater than Neat Video noise reduction. It is intense on the entire system.

Second ... Lumetri is nearly as hefty ... and when you have Lumetri after Warp, all sorts of processing order issues can arise. That is an incredible combined load to throw at any machine.

For instance, I've got a 24 core system, 128GB of RAM, and 11GB of vRAM on my GPU. Running on one internal Nvme for OS/programs, a second Nvme for all cach files. All projects of my Production and all media files are on high-speed large internal SSD drives.

And I never apply Warp and just leave it on a clip. I always apply, check the analyzation, and if it's good, immediately do a full render & replace to ProRes422 normally. No more Warp processing, no chance of order of processing errors, and playback is sweet.

But then, I'm just a totally practical person ... what works is how it works. Whatever.

For you, if you want to keep Warp sitting on the sequence, and Lumetri and stuff ... try applying Warp, then nest the clip, then apply Lumetri. 

That might get better behavior for your wants.

Bug or not, why on earth should the Auto button in Lumetri not work when the effect is under Warp Stabilizer, but works fine if it's above it (or above/under any other effect for that matter)?!  If you can give me a single reason that this makes any sense, I'll remove my bug request.  As for debating if something will be considered a real bug or not, it's doesn't help anyone in the Pr community.  I'd expect a better response from a 'Community Expert'.