Lumetri color causes pixelation

Report · Jun 10, 2023

I used lumetri color to change my footage's background color but it left pixelation.

I added an adjustment layer with the "change to color" effect to adjust the background color which I am certain is what caused the pixelation but using HSL Secondary didn't give me the result I wanted.

Can someone please help me fix this problem?

I'm using Premiere Pro 2023 on a Macbook Pro with a Seagate external hard drive.

Operating System: Ventura Version13.4

Processor is: 1.4 GHz Quad-Core Intel Core i5

Graphic: Intel Iris Plus Graphics 645 1536 MB

Memory: 16 GB 2133 MHz LPDDR3

I'm using a Mercury Playback Engine GPU Acceleration (Metal) renderer in Premiere Pro.

I am unsure what kind of camera was used to shoot the footage as it was not shot by me.

Footage image size: 1920 x 1080

Frame Rate: 59.94

Pixel Aspect Ratio: 1.0

Color Space: Rec. 709

Input LUT: None

Video Codec Type: MP4/MOV H.264 4:2:0

Report · Jun 10, 2023

Report · Jun 10, 2023

That looks like macro blocking, so I'm curious what the original color was? Any tonal changes to brightness or contrast applied?

A lot of long-GOP media ... H.264/5 ... is very prone to macro blocking on color work.

I've had to help a number of people rescue what they could from drone shoots, phone cameras, or just 8 bit DSLR video recorded in H.264. Sometimes it's not too hard, sometimes ... ah well.

Report · Jun 10, 2023

Thank you for helping me.

This is what the original footage looks like with no lumetri color applied:

and this is after adding exposure/contrast in lumetri color:

Report · Jun 10, 2023

That is a lot of tonality (brightness) change to an area of low initial contrast. Meaning that there would not have been a lot of individual pixel data kept in the initial recording. That's how that form of compression works.

Say you've got a block of pixels that are 120/106/38 - 122/107/40 - 121/108/40 - 119/105/37. Gee, that's all pretty close to 120/107/39, right? So all it records are a block of four pixels at 120/107/39. Less data to record to the card in-camera. It gets a smaller file written faster.

And because that area is a wall or sky or some other large surface, with pretty close color/brightness, it writes a WHOLE bunch of these blocks that are all a bit different, but close enough you don't see them if nothing changes. But within each block, the pixels are identical.

But now, raise the contrast or saturation ... doing something quite notable with at least the brightness or color ... and the image shows as irregular blocks of color/tone. Because each block moves together, but all a bit differently than the next one. And as each block is slightly different, those differences are made massively visible.

Depending on the image, you can get either macro-blocking like this, or banding.

Sometimes adding "dithering" ... "grain" or noise, to the image, small bits of dots like unto film grain ... then doing color changes, can get the image through with far less notable blocking or banding. And the problem wasn't created by say Lumetri, it was already there, just so slight you couldn't see it. Ah, the joys of "visually lossless" data.

To do what fix you can, besides adding dithering/grain, using small amounts of several different tools to make the same final, overall change can help. And do better visuallly than all the change with one tool.

So maybe start with a small change of the Lumetri Curves control for hue to hue, and a small amount of hue brightness curve change. Then do a very small amount of change with the HSL tab of Lumetri, selecting the area, checking with the mask option, then applying some denoise and softening, before slightly changing the color and lifting brightness.

Neil

Report · Jun 19, 2023

Neil,

Thank you so much for your help and knowledge. I was able to fix the pixelation but I've run into another issue. When I take a still from my project (export frame) in Premiere it looks the way I want but once I exported the project, the color is more muted and cold. I'm not sure what is happening during export that is causing this.

Export Frame

Screenshot from exported video file

Here are my export settings:

Basic Video Settings:

Preset: Match Source - Adaptive High Bitrate

Format: H.264

Frame Size: Full HD (1920 x 1080)

Frame Rate: 59.94

Filed Order: Progressive

Aspect: Square Pixels (1.0)

Encoding Settings:

Time Interpolation: Frame Sampling

Performance: Hardware Encoding

Profile: Main

Level: 4.2

Export Color Space: Rec. 709

HDR Graphics White (Nits): 203 (75% HLG, 58% PG)

Mastering Display Color Volume:

Color Primaries: P3D65

Luminance Min (cd/m^2): 0.01

Luminance Max (cd/m^2): 1000

Maximum (cd/m^2): 1000

Average (cd/m^2): 200

Bitrate Settings:

Bitrate Encoding: VBR, 1 Pass

Target Bitrate [Mbps]: 38

Can you please help me figure out how to match the final exported video file to what I see in Premiere?

Warm thanks,

Jay Michelle

Report · Jun 19, 2023

The standard Rec.709 presets ... I don't think ... have the Mastering stuff set to P3D65 ... ?

Report · Jun 19, 2023

The Mastering Stuff?

Report · Jun 19, 2023

Mastering display color things set by your comments to P3-D65.

Report · Jun 19, 2023

I'm not sure what to do. Do I need to change my mastering display color settings? If so, to what?

Mastering display color things set by your comments to P3-D65.

By @R Neil Haugen

Report · Jun 19, 2023

Did you start with a Rec.709 export preset? One without HLG or PQ in the name?

Report · Jul 22, 2023

Hi Jay,

how did you fix the pixelation in the end? Cause I'm having the same issue. Did you add grain?

Report · Jul 22, 2023

Pixelation is typically caused by either expanding resolution (framesize) or by pushing the color correction past what the depth of tonal and color information can handle.

It can be simply "bad math", but actually, though I don't agree with all the design considerations for Lumetri ... I'd rather we be allowed to do with our pixels what we wist, not be so limited ... in general, the math in Lumetri is actually excellent.

So ... what is that media? Created by what? What framesize and bit depth? What color space is the media, the color space of the sequence, and of any export?

What are you doing with the Lumetri controls that induce pixelation?

Neil

Report · Jul 23, 2023

Hi Neil,

thanks for replying.

To answer your questions:

1. The media is a gopro footage grabbed by gopro 11 hero black.

2a. Footage: Frame size: 3840x2160; bit depth: 10 bits; 100 frames/seconds; bitrate: 119020 kbps

2b. Sequence: Frame size: 3840x2160; 25 frames/seconds (i started with 100frames/sec and had same issue). The pixelation happens already in the preview.

3. Color space is Rec709, same as the sequence.

4. Export settings: I attach the screenshot. I also tried VBR 1 pass, with different bitrates with no improvements.

5. With lumetri I basically try to color grade the footage. I modify the white balance, curves, HSL secondary.

I also attach the original footage without lumetri and the one after lumetri.

Rosario

Report · Jul 23, 2023

Also, I have a NVIDIA GeForce MX250, driver: 536.67, updated yesterday. but had same issue with driver: 517.66. I read that this could be an issue (from some discussions here in 2020), but I cannot find the driver people were talking about (445.xx) for my graphic card.

Report · Jul 23, 2023

I'd be very interested in what the scopes show of the original image ... both RGB Parade and Waveform YC no chroma. I want to see how much data is actually there to begin with. I'm suspecting this was somewhere mildly to rather underexposed.

Which can really be an issue. In my experience, the GoPro "10 bit" media I've worked with has been rather ... thin ... 10 bit. Not nearly as robust to grade as my BMPCC4K 10 bit ProRes.

If this is at all underexposed, with the way the GoPro records data ... doing much past basic white balance and a bit of lifting contrast can get into pixelation/artifacting (including macro blocking) pretty quickly.

Neil

Report · Jul 23, 2023

Hi Neil,

here you find the waveforms.

So basically what you´re saying is that there could be not enough information stored and therefore the pixels are clipping. Isn't it possible to do any sort of interpolation/extrapolation to make this transition pixel-to-pixel smoother?

Report · Jul 23, 2023

I'd have hoped that for that log and scene choice, the original data hit about 70IRE in the Waveform.

Being that it is underwater media, where the red channel is naturally SO heavily under-exposed, there's not a lot you can do to that clip without pushing things where they might not go politely. Grading underwater media is flipping hard.

Because realistically, it takes having someone produce exceptional underwater recorded media ... which takes experience and a certain level of gear quite possibly also.

Especially as there's another thing that really bits us in long-GOP compression forms. Notice how so much of that image is of similar color/brightness? That's ... problematic with long-GOP.

The long-GOP compression is partially done by looking at pixel blocks ... could be four, six, nine or so pixels. Looking to see if they are close enough that they can say dump some numbers from a few pixels, so that all the pixels of that block can share the same numbers. Less data to store, right?

So ... pixels that are say:

24/68/72

25/70/70

25/67/69

23/69/73

Might suddenly become a four pixel block at 24/69/71.

Which you might not see as a uniform block, in a playback of the clip at speed.

But consider you have a bunch of these blocks, all slightly different, and now, you apply some tonal and color changes.

Each block behaves as a concrete whole, every pixel taking the same correction. BUT ... each block, being different than the ones around it, takes a different amount, though all have been "pushed" somewhere now.

And suddenly, you see all the blocks that actually were there in the original image. But not ... different enough ... to notice.

Neil

Report · Jul 23, 2023

Ok, understood. Thank you very much for your explanation.

Rosario