Skip to main content
Participating Frequently
December 17, 2021
Question

Enabling Hardware Encoding Changes Color/Contrast

  • December 17, 2021
  • 3 replies
  • 2558 views

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. 

 

This topic has been closed for replies.

3 replies

R Neil Haugen
Legend
December 28, 2021

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

Everyone's mileage always varies ...
BradR.Author
Participating Frequently
December 28, 2021

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
Legend
December 28, 2021

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

Everyone's mileage always varies ...
Richard van den Boogaard
Community Expert
Community Expert
December 28, 2021

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.Author
Participating Frequently
December 28, 2021

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. 

BradR.Author
Participating Frequently
December 28, 2021

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?


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. 

Community Expert
December 17, 2021

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

-------------------------------------------------------------------------JVK | Editor/Designer/Software Instructor. Pr, Ae, Ch, Ps, Ai, Id
BradR.Author
Participating Frequently
December 17, 2021

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

Inspiring
December 17, 2021

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.