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

    Sorry for another reply - is there a way to edit posts on here? Anyways, I tried separate instances of Lumetri vs one instance, doesn't seem to change output quality. The only thing that makes a difference is by using Media Encoder to export, which I believe is processing the colors more accurately.

    R Neil Haugen
    R Neil Haugen
    Legend
    January 8, 2021

    Due to the known nature of the 'net, where some people are rather wild juveniles, you're not allowed to edit your posts on this forum until you've posted some X number of times. Sorry ... yea, it's a pain.

     

    When applying a corrective Tech-type LUT to a clip, it can as noted crush or clip or over/under saturate without malice, simply because the current clip wasn't exposed under  the identical conditions as in use for the clip the LUT was created from.

     

    This is where trimming a clip with controls applied before the LUT, but viewed after the LUT, is needed. Adjusting or "trimming" exposure, blacks, whites, over-all contrast and saturation to get to the "neutral" or normal look of that media. Normally not huge changes, but very often at least small adjustments are needed per clip.

     

    Then you get the "expected" behavior from the LUT. This is a process drilled into colorists, that in my experience, many editors don't know about.

     

    8 bit/10 bit is irrelevant though for things that don't change the relationship of color data. Bit depth refers to bit depth per channel of R/G/B. If the effect is not affecting that, bit depth is not involved.

     

    Where Warp is somewhat different is simply the same thing as is oft noted when people 'zoom' an image, and in the enlarging, they start to see banding. They think the enlarging process caused the banding.

     

    It is far more likely that there was actually slight banding going on, it simply wasn't quite noticeable, but as soon as the image was enlarged, the banding became noticeable. I've had several posts on this over the years, where I've had them go to 100% or more on their Program monitor image of that area, and gee ... at that level, you could sorta see the banding.

     

    Oh ... yea, well, it was already on the edge of visibilty.

     

    As to a difference between Premiere and Me, I would think that would fall onto the settings used. Did one do MRQ or Max Depth, the other not? Did one apply composite in linear color the other not? These are settings that sometimes mess with such things. The basic encoding engine of Me is the encoding engine for Premiere.

     

    Queueing to Me simply allows the user to run that engine as a separate process while they get on with working in Premiere.

    Neil

    Everyone's mileage always varies ...
      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