Problem with ProRes 422 HQ codec

[BUS74]

Good morning.
I have a ZCAM E2 F6 with Atomos Ninja V and I use Premiere PRO rel. 22.1.2 for editing and color grading.

I noticed that by recording in ProRes 422 HQ both on the ninja V and directly in the Zcam camera and then applying the Lut Zcam zlog2_ax2_normal, but also by manually intervening in the color grading, halos are created. This is most noticeable in controlled light recording, but it also happens in landscape shots, especially in the sky.
The same clip developed on Apple Final Cut with the same Lut is perfect!
The same recording in H.265 codec in Zcam camera is perfect on both Premiere Pro and Final Cut.

I am attaching 3 screenshots of a frame with the three versions where the halos are clearly visible. Obviously processed with Premiere Pro rel 22.1.2

The problem also occurs in the older version of Premiere Pro.

I use a Macbook Pro 16 "with macos 12.1 64gb ram and AMD Radeon Pro 5500M 8 GB

Has anyone ever had a problem like this?
Is there a particular way to parameterize Premiere Pro?

Thanks for your suggestions!

clauio

Italy

[R Neil Haugen]

 That is 'banding' technically, caused by the application of the LUT.

Are you applying the LUT in the Basic tab slot of PrPro? If so, try applying it from the Creative tab slot instead, then go into the Basic tab and adjust the White and Highlight controls a titch, see if you can get rid of it.

Colorist's call LUTs the dumbest math out there. Nearly all LUTs can and will clip and cause banding and artifacts unless the user has the ability to apply some 'trim' to the exposure, contrast, and saturation before the LUT while viewing the image with the LUT.

Hence my suggestions.

Neil

[BUS74]

Thanks Neil for your support.

I tried to follow your advice but the situation does not change !!

The strange thing is that the ProRes 422 HQ clip without LUT as it was recorded has artifacts while in Final Cut it is perfect.
I tried to upload the same clip to Davicni Resolve and it behaves like Premiere PRO !!
The H.265 codec is perfect on both Premiere Pro, Final Cut and Davinci.

So it seems that already when the clip, without any LUT no color grading, no retouching of the parameters of the basic tab, is displayed by Premiere Pro it reports the problem. Putting the Lut highlights it more.

Tonight I try to make some screenshots to attach with some notes so as to explain myself better.

For now thanks again Neil.

claudio

[R Neil Haugen]

Will be interested to see the images.

Neil

[Andy 1968]

A LUT can affect brightness, contrast, gamma shift, dynamic range and more. What does the video look like from the Ninja when connecting the HDMI port to a TV? 

[BUS74]

The clip as I said is recorded by Ninja V on SSD via Hdmi connected Zcam.

So looking at the clip directly from the Ninja V monitor (playing on the Ninja V) with the zlog2_ax2_normal LUT that I use on Premiere Pro the displayed clip is perfect !!
So it looks like Premiere Pro but also Da Vinci interpreting the ProRes 422 HQ codec incorrectly creating a halo.

For example, if I record in ProRes RAW always from Nina V the clip developed on Premiere PRO is perfect! Same thing for H.265.

So it is already at the base that Premiere Pro interprets the codec by inserting these artifacts which are then amplified by entering the LUT.

However, as soon as I am in front of the Mac I try to do some further tests.

Thank you all for the support. 🙂

claudio

[R Neil Haugen]

Your assumptions are not quite ... supportable. That the Ninja, which recorded the file, can show it proves nothing. Other than that it can process the specifics of the data it recorded.

Andy's comment about the TV is actually valid here. But especially, if NOT played from the Ninja. It would be testing the file header/structure via another processing chain.

And both Premiere and Resolve are built for heavy pro work, and treat LUTs pretty decently. Resolve even better (as it's a full blown grading app) than Premiere. That both Resolve and Premiere show banding with that LUT immediately puts the LUT in use ... in the questionable area.

FCP is applying a lower gamma to the file, an incorrect gamma for Rec.709/SDR standards. I am guessing, but I think that is why you are not getting the banding appearing in FCP ... it isn't that the data issue isn't there, it's likely that the lower gamma means you won't see the issue.

I go back to my earlier comments. LUTs are the dumbest math out there, and they will do things exactly like this unless the user takes control of them. That is why one is SUPPOSED to use a tech or 'corrective' LUT like this one, where you can "trim" the file data by corrections to the image applied before the LUT.

In Premiere, that means applying the LUT in the Creative tab's slot, then using the Basic tab tonal/saturation controls to change contrast/white/saturation/exposure to avoid the problems caused by the LUT being mis-matched to the clip. You would try to use the Basic tab controls to get rid of the banding.

In Resolve, if you apply a LUT in a node, any corrections of the 'normal' controls of that node are processed before that LUT is. So it's easy to apply a LUT, then trim the clip properly to fit the LUT.

Remember ... that LUT was "built" in a studio setup using perfectly set up lighting/contrast/camera controls. No field-produced media will ever come in with exactly the same exposure/saturation/contrast data of the LUT creation.

So that is why you need to trim the clip prior to applying the LUT.

Now, there is another possibility. If that clip has 'stretched' data, that doesn't show as an issue with a low-gamma presentation, but does with proper gamma ... it might be difficult to fix in post. That might be an issue needing different exposure and/or lighting controls in shooting.

Neil

[BUS74]

Hi Neil

your analysis is perfect but I tried to do as you indicated but I have not solved.
I try to put you a link where you can download the original clips. They are not that great but you will notice that the one produced in ProRes 422 HQ is seen in the sky of clouds tending to red that in reality were not there during the shoot.
In fact in the ORIGINAL_H.265 version the sky is clean.
The 2 files starting with ORIGINAL are produced by Premiere PRO and I only put the LUT without making any adjustments.
While the file starting with C003 * is in H.265 and recorded by ZCAM on its CFAST card.
The file starting with NINJA* is produced by the Ninja in ProRes 422 HQ.

Also find the original ZCAM LUT used in Premiere PRO in the folder.

In addition to the clouds I also noticed on the roofs of the houses, down the street, as the clip reaches the end that an artifact is formed! Here it appears that Zcam has re-recorded this way as it appears on both H.265 and ProRes HQ.

Then, as you say, there are many factors that can compromise the final result and your considerations are timely and very interesting.

If you want to try on the original clips ... here the link https://www.dropbox.com/sh/tov5nfdtmaqdy9r/AACaF709JtovjNvonQL1Rwmqa?dl=0

Thanks for your patience!

claudio

[chrisw44157881]

"The same recording in H.265 codec in Zcam camera is perfect on both Premiere Pro and Final Cut."

sorry, did you say that the h.265 original with the lut applied doesn't have this problem? if its only showing up in the Prores, then its a codec issue, not a lut issue. 

for fun, try encoding the prores HQ to prores 444 or DnxHD and try again. maybe premiere has a prores HQ bug?

I know 444 uses full range data instead of video levels.

[BUS74]

Hi
in ProRes I can only record on Ninja V maximum in ProRes 422 HQ and in ProRes RAW.

I will do other tests as soon as I can in the previous post I put a link to download the 2 clips if someone wants to try.
thank you.

[chrisw44157881]

no, i mean, transcode what you got prores HQ to another codec if its a premiere bug, that will hunt it out.

two things you should try:

1. convert the h.265 to prores HQ to see if its a prores HQ issue with adobe media encoder

if it still works, it means the ninja is creating corrupt prores hq files.

2. convert the prores HQ to prores 444 or dnxhd with adobe media encode. if it works, it means media encoder is repairing the corrupted prores hq files from the ninja.

[BUS74]

ok now it's clear I'll try as soon as I can 🙂
good night

[BUS74]

Hi Chris.
I did the tests you asked me using Media Encoder.

1) I converted H.265 to ProRes HQ and the problem occurs using the new file in Premiere PRO. So in H.265 the clip is perfect. The same Clip converted to ProRes HQ manifests the problem as the Ninja V generated clip!

2) I have converted the ProRes HQ clip produced by ninja V to ProRes 444 but this does not solve the problem. It exhibits the same problem as the original ProRes HQ clipo.

3) I have converted the ProRes HQ clip produced by Ninja V to DnxHD but this does not solve the problem. It exhibits the same problem as the original ProRes HQ clipo.

4) I have converted H.265 to DnxHD and the problem occurs using the new file in Premiere PRO. So even converting H.265 to both ProRes HQ and DnxHD the problem arises!

I honestly don't know what conclusions to draw !!

[R Neil Haugen]

Download just finished. Got about an hour long meeting now, then I'll give them a whirl.

Neil

[chrisw44157881]

I got a pretty ouchie conclusion and honestly, I can't believe my eyes. I took the h.265, and encoded it to Prores HQ with shutter encoder. I then did a basic curves adjustment and saturation increase and got really bad banding in the sky. I took the Prores HQ I just transcoded and trancoded it again to h.264, copied the lumetri effect with the settings over and the sky was perfect. Semi-good news, Prores 444XQ works ok. The only conclusion I can draw is that there are many codecs that have premiere bugs. Since the banding is there before the lut, the lut would simply exacerbate the bug.

additional note: I forced Prores 444HQ back to 16-235 and got some banding back, so there may be a corralation of video levels. also h.264 which looked perfect, did have a 10% boost in gamma.

but I think there's enough here that a color engineer needs to sit down and take a look.

[R Neil Haugen]

Ok, just got them into Premiere. This is the original Nikon recorded file. And the signal trace in the scopes is not something I'm used to seeing.

 

That solid line at the bottom is just odd to me. I've not seen that sort of thing before. Plus there's a big divide between where most of the "upper" data would be, I'm assuming the sky, and the bright spots of the buildings on the left. The sky is pretty compressed, but the lights of the buildings are quite a ways above them.

I'll spend a bit more time with all of the clips in a while.

Neil

[R Neil Haugen]

Here's some more images of the scopes signal. This is the Nikon recorded image, frame 1, no LUT:

 

Here's the Ninja recorded frame 1, again no LUT:

 

And here's the Nikon with the z-Log LUT:

 And the Ninja with the z-log LUT:

 Here's the Ninja, Waveform RGB, no LUT:

 And the Ninja, Waveform RGB, z-log LUT:

 

I've got a few comments. First, the media recorded internally is on my system higher quality than that recorded on the Ninja. Look at the smoothness of scopes on the original Nikon versus the Ninja, both without the LUT.

Next, that LUT is stressing the media to, and really, past the breaking point. First, talking about the color changes it makes. Look at the Vectorscope changes, between no LUT and LUT applied, both on the camera recorded clip and the Ninja recorded clip. That LUT is pushing some data out actually slightly past the out-of-bounds lines of the Vectorscope. This is an extreme lifting of color data.

And here's the same image, again, first frame of the Nikon camera clip, lowering of the Shadows Luma control of the Color Wheels tab to bring Black down to about 4-5 nits, and slight boost to the Exposure control of the Basic tab,  just 0.1 up. With Creative tab's Vibrance control to 39. No banding. Image goes from 4 nits to 96 nits, with good "normal" color.

 

From this, I've got a concern with both the Ninja recording and with that LUT. No problem with the original media.

Neil

[BUS74]

Thanks to everyone tonight I will read your considerations better even if it is not easy for me to translate from English.

Neil when you talk about Nikon you obviously mean ZCAM. am I right?

The streaks you see on ProRes HQ compared to H.265 I have noticed too and it seems to me that the H.265 file is cleaner!

However, I read carefully and look at the images and if anything I do other tests also in controlled light.

Neil if you please also take a screenshot of the settings you have set in Lumetri so I can get an idea.

Thank you

[R Neil Haugen]

The camera recorded file seems quite clean to me. The Ninja file has the little gaps in the Parade and Waveform scopes which the camera footage does not. The fine horizontal dark lines running across the scopes. That typically is missing data at that 'level'.

This camera file is not really what I'd call "log".  The black point is lifted to about 20, the highlights dropped to what, 90? And the saturation is low.

So it was simple to 'normalize' For the shadow/black, I went to the Color Wheels, and pulled the Luma slider of the Shadow wheel set down until black point was around 4 or 5 on the nits scale on the left side of the scopes.

Then pulled the image up very slightly ... with the Exposure control. Didn't need much just a tiny amount, so to 0.1 on the Exposure settings. Takes the white point just above 90 on the left-side nits scale.

And I went to the Creative tab and lifted Vibrance to 39. That's it.

Neil

[chrisw44157881]

Neil

Transcode the original H.265 to Prores 422 HQ and then the Prores 422 HQ you just transcoded again to Prores 444XQ.

Why does the RGB parade get better from the same 422 source when becoming 444HQ? That doesn't make any sense.

[R Neil Haugen]

No clue ... huh.

Neil

[chrisw44157881]

upon furthur investigation:

I made a color ramp in AE in trillions of colors and rendered out a PSD, 422HQ and took the 422HQ and transcoded it to 444XQ.

I did notice that 422 HQ goes above 1.0 and below 0.0(negative!) in histogram but 444XQ and PSD image don't so I'm guessing there is a scaling issue and that is why you can recover the image from 422HQ to 444XQ because it gets scaled out again. I'm farely sure this is a bug and that is why you get banding, because the luma gets pulled out of the chroma as it gets incorrectly decoded and explains why final cut is ok as well.

[BUS74]

Here I am sorry for the delay but I made a new folder where you can find a shot at 25 fps in controlled light at 3850 degrees kelvin.

Here the proof is the recording in the ZCAM camera in ProRes HQ and at the same time on the Ninja V always in ProRes HQ.

So you find the 2 original clips and you understand why they are * .MOV where with C003 it is produced in the room by ZCAM and with NINJA by Ninja V.

Also find 2 screenshots of the curves I used in Premiere Pro for the respective 2 ProRes HQ clips.

Also find 3 * .mp4 where you can see the final result highlighted by the circles.

The White one is related to the ProRes HQ clip recorded by Ninja

The Yellow one is related to the ProRes HQ clip recorded by ZCAM

As you will see, artifacts are formed, highlighted by the circles.

Then the third file named “25fps H.265_HD1080p” is the shot in H.265 always with the yellow circle where you can see that it is almost perfect.

You also find the same ZCAM LUT but I also entered the same with +1 +2 +3 stops and -1 -2 -3 stops.

Folder link: https://www.dropbox.com/sh/fk0fmjhks7qlf55/AAAulRTwmPdWHOHSnHldvaxRa?dl=0

Sorry again, but I see that you are an expert and therefore as you can see both that the ProRes HQ is produced by the Ninja V or directly in the room from ZCAM has the same problems and gives the same result while in H.265 in the room it is not bad.

Thanks for everything, your comments are very valuable.

[R Neil Haugen]

Is the 1080 H.264 file direct from the camera? If so, that file is created by down-rezzing the image, which often 'fixes' subtle banding issues, besides 'fixing' a lot of video noise problems.

The UHD Files

What I'm seeing with the new files, is that there is very slight banding going on in that wall to the far right, which is an area that is very low in both luma and chroma contrast. Neighboring pixels are all simply very slightly different one from another. This type of thing is a bugger for digital processing.

Especially, if any compression is involved. H.264/5 files particularly are noted for problems with this sort of thing as they dump a ton of image data as the primary process of the compression they use. Neighboring pixels that are say 22/16/34 and 22/17/33 and 21/17/35 may all end up recorded as 22/17/35. Something like that.

And the compression for most codecs is applied in blocks, which can make such changes show as sublty shifting blocks of tone.

BUT ... it can also be an issue for any non-4/4/4/4 encoding, depending on the subtlety of the tonal gradients of the scene. 4/2/2 codecs are better than 4/2/0 codecs, but not as good for this as 4/4/4/4 codecs.

The 4/2/2 codecs here recorded by the camera and the Ninja show slightly different, very subtle moving blocks of tone. Not entirely unexpected in my experience.

It's the sort of thing colorist's have to deal with quite frequently. Adding 'dithering' or noise can make the problem not be as visible, and is a common 'fix' used because it's quick.

And this is why they will always prefer a 4/4/4 capture to 4/2/2, and 4/2/2 to 4/2/0.

[BUS74]

I produced H.264 from Premiere Pro after LUT and color grading based on color check.