Skip to main content
JacobJC
JacobJC
Inspiring
January 6, 2021
Answered

Warp Stabilizer + Lumetri is causing issues with my Color Grade export?

  • January 6, 2021
  • 4 replies
  • 6087 views

So I'm having an issue with Warp Stabilizer, it's seemingly crushing the colors and or bitrate of my color grade. I have a video in 4K uploaded to YT showcasing the problem: https://www.youtube.com/watch?v=0NELy3KEj6Y 

 

This footage was shot on a Sony PXW-FS7 ii with Zeiss CP.3 35mm T2.1 cine lens in SLOG-3. I understand that the camera can have some color banding, but that is not the problem here.

My workflow is: Import LUT from another program as an "Input LUT" in Lumetri > add additional grading in Lumetri.

 

When I add or remove Warp Stabilizer on this clip, it causes this weird color banding / bit rate crush on certain parts of the image, like the sky in this example shot. I've tried different Warp settings, but this doesn't change anything with the export. I tried a different stabilization technique - with the Mocha Plug-in - and even without doing any stabilizing, just enabling the effect causes the issue again. So it seems as if this is an issue with trying to use certain effects + a color grade with an Input LUT. I've tried nesting, adjustment layers, CUDA/hardware accel/"maximum render quality" settings, and different order of effects. I even exported the clip (lossless) with only the Warp Stab, reimported it and then added the grade, which results in the same issue. I do have HSL Secondary enabled to desaturate some blues, but this is not the issue, as disabling it still presents the same problems between using / not using an stabilization effect.

 

The only (terrible) solution I've been able to come up with, is exporting the clip (lossless) with the grade first, then adding the warp stabilization after. I really don't want to do this for a lot of my clips.

This is not a codec/file format issue, I've tried using ProRes and others as the export, and even as the input file (converted before adding the effect), which did not solve the isssue. In terms of the 32-bit / 8-bit effect pipeline, this is making no sense to me. I'd really appreciate any assistance.

Other info:

  • Not using proxies for this project

  • Happens on multiple computers (windows 10)

  • Rendering at 2160p UHD, 23.98fps, 50.00mbps CBR with h.264

  • I need to solve this issue for many clips, this is just an example of one

This topic has been closed for replies.
Correct answer JacobJC

UPDATE 2: I have found a proper solution. TLDR: Queue your render into Media Encoder and enable CUDA rendering there.

 

Essentially, what the problem seems to come down to is an exporting error with non 32-bit effects (aka 8-bit effects). Warp and Mocha are 8-bit. In fact, a lot of effects are 8-bit, and they all caused the render issue. 
 
The solution is quite simple. In Premiere, both software and hardware encoding modes will not convert 32-bit effects into 8-bit footage properly, even with the "maximum render quality" and "maximum bit depth" options checked or unchecked. It will not calculate these effects properly, everytime. At least while working with an Input LUT.
 
This may be a bug, I am unsure. But it is present as of 14.7.0 (Build 23).

4 replies

R Neil Haugen
R Neil Haugen
Legend
January 7, 2021

One thing may be Lumetri's application of the LUT in the Basic tab. As colorists all say it, LUTs are the dumbest math out there. They can do marvelous things quickly, but they will also clip, crush, and otherwise mangle your pixels without caring.

 

In Resolve, when you apply a LUT to a node and then do any 'trim' work to tonal/chroma values in that node, your changes are applied before the LUT is processed ... so you're trimming the clip's values to fit into the LUT.

 

You get the same option in Lumetri if you apply corrective/tech LUTs in the Creative tab, and use the Basic tab tonal controls to trim the clip into the LUT.

 

With the Basic tab input LUT slot, the LUT is applied before any 'trim' controls. So if it is doing something to your pixels, you can't change it.

 

Therefore, I always suggest to people to skip the Basic tab Input LUT option unless you also run a prior instance of Lumetri to trim the clip into the LUT.

 

Out of curiosity, which 8-bit effects are you using there?

 

Neil

Everyone's mileage always varies ...
    JacobJC
    JacobJCAuthor
    Inspiring
    January 7, 2021

    Yeah, so we used an X-Rite Color Checker on set, and since Premiere doesn't have support for that, I was doing a base color correction grade in Resolve, then exporting it as LUTs for Premiere. I was putting as an Input LUT in order to allow me to do additional corrections afterward like HSL secondary (as applying any adjustments before the LUT would change the image differently than intended). I could try using the LUT in the creative tab in a separate Lumetri effect, then add basic tab corrections in a different Lumetri effect below it (but I think this would still cause the same effect).

     

    In terms of 8-bit effects (I'm assuming any non-32bit effect classifies as such), I'm using a lot of different things over the course of the film. Warp, Mocha, Lens Distortion, and I may have some 8-bit keys/mattes and some blur/sharpen effects.

    R Neil Haugen
    R Neil Haugen
    Legend
    January 7, 2021

    Effects that change color/tonality at all should of course be 32-bit. Effects that don't deal with color/tonality can be 8-bit and work fine.

     

    The order of processing, and how things are done, matters immensely.

     

    So with incredibly heavy effects like Warp Stabilizer and Lumetri, if you're applying both to a clip, it is simply wiser to at least nest the clip after the one and before the other.

     

    With Warp, realistically, I strongly suggest getting to your final Warp settings, doing a full render & replace of the clip on the timeline, then doing the other effects you'll apply to it. As this completely eliminates the Warp analyzation step from further computer load.

     

    One of the potential issues with Warp especially with 8-bit media is that as it works by resizing the media, if you've got sections like skies or blank walls that are close to banding (low bit data) ... resizing the media can cause visible banding to occur. It's best to sort out your Warp, and finalize it, before applying any color changes. As color applied to stretching of the Warp in processing may easily result in banding.

     

    Neil

    Everyone's mileage always varies ...
      M
      Michael Grenadier
      Legend
      January 7, 2021

      like usual, Neil's dead on but, fwiw, in my experience, I much prefer setting warp stabilizer up in AfterEffects and rendering it out in AE and placing it above the camera original (and the ae comp if that's how you sent the shot to ae) in my premiere timeline.  Generally for this sort of heavy lifting, I find the AE interface much more responisive and easier to manipulate (bwdik).

        JacobJC
        JacobJCAuthorCorrect answer
        Inspiring
        January 7, 2021

        UPDATE 2: I have found a proper solution. TLDR: Queue your render into Media Encoder and enable CUDA rendering there.

         

        Essentially, what the problem seems to come down to is an exporting error with non 32-bit effects (aka 8-bit effects). Warp and Mocha are 8-bit. In fact, a lot of effects are 8-bit, and they all caused the render issue. 
         
        The solution is quite simple. In Premiere, both software and hardware encoding modes will not convert 32-bit effects into 8-bit footage properly, even with the "maximum render quality" and "maximum bit depth" options checked or unchecked. It will not calculate these effects properly, everytime. At least while working with an Input LUT.
         
        This may be a bug, I am unsure. But it is present as of 14.7.0 (Build 23).
        JacobJC
        JacobJCAuthor
        Inspiring
        January 7, 2021

        UPDATE: I've discovered my color grading export issue is happening when I use ANY non-32bit effect on a clip, not just Warp Stabilizer. All 32-bit effects don't cause this issue.

        Terms & ConditionsAccessibility statement
        Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices