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

Explorer ,
Jan 06, 2021

Copy link to clipboard

Copied

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

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).
TOPICS
Error or problem, Export, Performance

Views

96

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more

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

Explorer ,
Jan 06, 2021

Copy link to clipboard

Copied

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

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).
TOPICS
Error or problem, Export, Performance

Views

97

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Jan 06, 2021 0
Explorer ,
Jan 06, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 06, 2021 0
Explorer ,
Jan 06, 2021

Copy link to clipboard

Copied

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).

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 06, 2021 0
Adobe Community Professional ,
Jan 07, 2021

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 1
Adobe Community Professional ,
Jan 07, 2021

Copy link to clipboard

Copied

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).

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 1
Explorer ,
Jan 07, 2021

Copy link to clipboard

Copied

Yes, I agree, however as I mentioned in the original post, both nesting, and applying the grading effect before the warp, did not solve this issue. Render & replacing the clip with warp applied, before doing the color grade, also did not fix my issue. Do note, this issue was happening with any effect that wasn't 32-bit, per my first update comment. The problem I have been experiencing is not a normal one. I strongly suspect the issue lies within the Lumetri effect, specifically with using an Input LUT. Thankfully, I found a solution by using media encoder. I've spoken to some other professionals on the premiere discord who can't seem to understand the exact cause of the problem either.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 0
Adobe Community Professional ,
Jan 07, 2021

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 1
Explorer ,
Jan 07, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 0
Explorer ,
Jan 07, 2021

Copy link to clipboard

Copied

Btw, I've seen your Demystifying color management videos, very useful stuff. 

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 0
Explorer ,
Jan 07, 2021

Copy link to clipboard

Copied

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.

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 07, 2021 0
Adobe Community Professional ,
Jan 08, 2021

Copy link to clipboard

Copied

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

Likes

Translate

Translate

Report

Report
Community Guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
Reply
Loading...
Jan 08, 2021 1