Enabling Hardware Encoding Changes Color/Contrast

[BradR.]

Have a project in Premiere 22.1.1 with footage from an Alexa Mini: ProRes 4444 2.8K 4:3.

When enabling Hardware Encoding it changes the color, saturation, and contrast. Its crushes the blacks and jacks up the contrast. If I set it to Software enbcoding, it looks flat, like its supposed to. 

As an example, I sent the timeline to Media encoder for a .264 export, in the images I attached, one is where in Media Encoder I select GPU Hardware Acceleration, and the other is Software Only. Nothing else has been changed, and yet you can see its two totally different color outputs.  If I export with each I get a video that looks the same as the preview window. 

This also happens if I set the Renderer in the Project Preferences to Hardware Encoding. The timeline shows the same color problem. 

What am I missing? I have an NVidia GPU and its set to 0-255 Full color. 

[John V Knowles]

Hi there,

Does this only affect your Alexa footage? Do you have other clips you can test this with -- some ProRes from a different camera or even iPhone footage?

JVK

[BradR.]

Hi john,

Thanks for the reply. A couple interesting developments. I did notice that a handful of clips I had that was blackmagic raw files were not showing that problem. I know there was always the annoying Embedded AMIRA LUT for Arri footage on older versions of premiere, and so I had gone in and made sure through Interpret Footage that the embeded LUT was no longer applied, but since 99% of my footage for this project is Alexa I didn't notice until you pointed that out. The braw or prores from BlackMagic cameras didn't have that problem. Could be that Amira LUT problem again.

The other development is I realized I had exported the project last week and didn't have that probem and since then had updated from 22.0 to 22.1.1. So I rolled back to 22.0 and that problem is no longer happening. My guess is maybe a reemergence of the hidden Amira LUT problem with the new version 22.1.1

[Andy 1968]

I only edit H.264 video files and export to H.264. I want the quick encoding speeds of Quick Sync and Nvenc so I simply use and adjustment layer to compensate for the image shift. You could also apply a LUT at export. I think Adobe had a LUT just for that purpose. The video below may not be helpful to you but it might help others. 

 

[BradR.]

Hi Andy,

Yeah not quite useful for this instance, as the diffference in iomage is when changing the renderer from software to GPU acceleration. It seems to add a LUT which heavy crushes the colors in the preview window as well as the final export.  I do have a LUT that I use for the final export which was made in camera, but this is without it applied. I want the footage to be log/flat before I apply my LUT so its an accurate color scheme to what I made in camera.   Adding another Adobe LUT or adjustment layer is not something I want to do. I would rather just use the software renderer. 

[John V Knowles]

A few questions:

1. Did you clear your media cache after you upgraded?
2. Are you seeing the Amira LUT listed in the Source Effects on the clips or else in the Interpret Footage dialogue?

They are still chasing bugs in the new release so if this is indeed a case of somehting that "broke" in the .1.1 update then we'll run it up the chain and report it.

JVK

[BradR.]

After I upgraded I didn't clear the media cache, although all the rendered files would not reconect on the timeline so I deleted all of them and rebuilt by Rendering Work Area to start fresh again.

When I went to Intepret Footage of one of the source clips, the input LUT was listed as "None". I even selected one and selected it back to None just in case. I even went into the properties and confirmed that there was no Input LUT listed. 

Right now I'm back at 22.0 and everything is working normally. When I go to export its the same in the preview/export whether I chose Software or GPU Acceleration. It does seem like 1.1 is auto applying that AMIRA LUT when using GPU, which was a problem in previous Premiere versions. 

[John V Knowles]

Okay that is really weird. I'm going to start a new topic and see who else is experiencing this.

JVK

[Richard van den Boogaard]

All I can think of is that a LUT is being applied to your footage.

Have you checked the Source settings of the clips? This can be found next to the tab that holds the motion settings. Please double check to see if a LUT is being applied there.

Also, often there is no real need to check Use Maximum Render Quality, with a few exceptions: https://www.youtube.com/watch?v=rAruFYIvrXM

[BradR.]

I did check and there is no LUT being applied, however I think you are missing the point of the post. Changing *only* the renderer applies some kind of LUT or color/contrast.  If there was a LUT on the footage it would be uniform no matter whether software or hardware is selected. 

[Jeff Bellune]

Another post in this thread mentioned not using Maximum Render Quality generally, but I did not see a post where you said you tried it.

To the best of my knowledge, hardware accelerated Mercury playback always uses MRQ as part of its thing.

To maybe isolate it to that feature, please try turning on MRQ while you are simultaneously using software rendering. Do you get the same color/contrast shift as with hardware rendering?

[BradR.]

I always use MRQ regardless of which renderer used. Just to repeat, all settings are the exact same, the only change is the renderer.  Also this problem does not happen in 22.0. 

[Richard van den Boogaard]

Ok, check.

Then I presume this must be somekind of bug. Is your team aware of this @Kevin-Monahan?

[R Neil Haugen]

The first problem, and it's a big one, is that you have your GPU set to 0-255 "full" ... which should never ever be done UNLESS you have a very unusual and specific need. The colorists I know say they've had a need to do this on a very rare occasion, but it's always because someone mucked up the camera settings or the encoding of a file that was sent to them.

Because that full/legal basis has absolutely nothing to do with the proper display of video media! It only has to do with the encoding practice 'expected' because of the standards for two very differently encoded media.

All YUV encoded (technically Y/Cb-Cr) media is by standards encoded 16-235, all RGB encoded media is by standards encoded 0-255. It has nothing whatevever to do with available "visual levels" in the media.

And both are displayed 0-255 on any normally set display.

So set the card back to auto or legal. It will work as it is supposed to, and Premiere will know what's going on. And yes, this could be part of the problem for this clip. With this set wrong, RGB encoded media may be displayed wrong ... the value 16 will be set to 0, crushing everything between 0-16. And values above 235 will be clipped also.

Another thing that can be a problem with Pr2022 is if it decides that a clip is HLG, it may display that as if it was on a Rec.2100/HLG timeline. Which is even more common than you might expect because of how Rec.709 and HLG are encoded.

SDR media is encoded with 'full integers', and HDR media is encoded ... logarithmically. For some log encoded files, Pr2022 defaults to showing them as if they were on an HDR sequence. Even on a Rec.709 sequence. Which is not what the engineers were expecting, and yes, I've had some communications on this.

So ... if setting the card to 16-235 doesn't fix that Arri media, go to the clips in the bin, see if you can right-click/Modify/Interpret Footage, and set an Override to Rec.709 on it.

Between the two, I think this can be 'fixed'.

Neil

[BradR.]

I only have the video card set to Full because when I first encoutered this problem I did some searching around on here and some people suggested that the video card settings can have an effect on rendering. The problem was occurring before I set it to Full. Also I have tried going into Interpret footage, all of the clips are using rec709, but I have tried overriding to Rec709 as well. I have actually tried all of the presets to see if there was a difference.

Even if the two things you mentined were true, why would just changing the renderer change the output?  Either way there is a problem. Also, rolling back to 22.0 doesn't show this behavior. 

[R Neil Haugen]

There are several things there.

First, the folks that suggest setting to full are just wrong. It's easily demonstrated with using bars & tones that you will get improper surprises if that's changed. The problem is that it's counter-intuitive, right? It sounds good at first, I mean, who doesn't want all their levels, right?

But again, it's all about the way the file is encoded not how the file is displayed. And the 'system' such as it is is designed to work with most media (YUV) encoded 16-235/displayed 0-255, and RGB media encoded and displayed 0-255.

It's a hang-over from the video tape days when those outer values were needed for other technical uses. But we're stuck with it.

As to the software/hardware difference ... they aren't the same thing, actually.

"Hardware" means it is using a separate part of the physical CPU chip that has specific bits in it to handle the encoding or decoding. So how that particular bit of hardware is built is the contolling factor for what it does. Different chips actually will have different capabilities and performance. Neither Premiere nor any other application has any control really over that, it's a physical object.

Hardware encoding is normally faster, often a lot faster. But not always better, or even ... as good.

"Software" means it's using a mathematical set of computations in the regular CPU processing cores. And the application can have more control/effect this route. Plus ... in some cases, software encoding is somewhat to a lot better quality.

Such that if the total quality is the prime controlling factor of the deliverable, software may well be the better choice.

Neil

[BradR.]

That's interesting info, but I have no real preference here. I had been using Hardware simply because it was the default, then after upgrading to 22.1.1 my outputs started adding this strange LUT look to the Arri footage. I found that if I changed it to software, it fixed it, and so I went about trying different things to troubleshoot. Finally, after doing a bunch of things that had no effect, I rolled back to 22.0, and it went back to working as expected. 

[R Neil Haugen]

I've not worked any Arri in 2022 yet. One thing I wonder ... have you checked the Source tab in the Effects Control Panel with an Arri clip selected ... do they have a panel of Arri-specific controls there now? They do for RED, for those with a BRAW plugin, several other types of metadata driven clips.

Neil