How do I keep Premiere from changing the gamma of an image in a rendered video?

[Kizzume]

When I'm in Premiere, the image looks normal, but when I render the video, the image looks like the gamma has been turned up and it seems a little more washed out.  I can't seem to represent a nice fade to black.  Pure black shows up black, but anything else shows up lighter than it should be.

Here is an example of this happening.  The darker image is the original, and the lighter one is what Premiere renders in the final video.  Depending on your monitor settings, this may be a little hard to see in the examples I provided. 

Either way, is there a setting somewhere that can stop this from happening?  This problem started showing up in v13.

Thanks.

[Andy 1968]

DaVanci Resolve does the same thing when played on the Quicktime Player or YouTube.  If you drop your rendered video in the Premeire Pro timeline does it look correct? If so everything is working correctly. Dropping luts on the video clip will not work because YouTube and Quicktime do not have the same color space. You can use an adjustment layer as seen in the video below. Simply enable it at the time of rendering. It is that simple.

https://youtu.be/K7EGNJop_HE

[Kizzume]

No, it doesn't, actually.  I just tested it.  Davinci Resolve does NOT have this issue.  Am I really going to have to switch to Davinci Resolve because y'all want to pretend there's not an issue in Premiere since v13?

[Kizzume]

Also, just to clarify:  Adding gamma correction changes the entire image to be darker.  It's awful.  Here's a comparison between what Davinci Resolve puts out and what Adobe Premiere v14 puts out with an adjustment layer with gamma set to 14.  If the gamma is any less than 14, the problem with lost color resolution still shows.

I'm still astounded that suggesting that adding filters to solve this problem is somehow an answer to this.  Premiere shouldn't be doing this in the first place, it didn't start until v13.  And as I said, Davinci Resolve clearly does not have this issue.

[salvo34]

Andy knows what he's talking about so please watch the video thing he posted. I didn't but I don't have a dog in this happy dog run, Your issue is very complicated at it's core, re: gamma gamut and color. So, using 'workarounds' to fix things is a good idea. Switching to resolve would cost you a year in learning curve, and money for new hardware ( like SDI out to video monitor etc.)

You would need tens of thousands of dollars to do that and spend a year learning the resolve program(s) cause they are now combined ( edit, color, sound, FX, etc. ). Different animals.

I worked on movies my whole life as a grip ( lighting, set construction, rigging) in NYC and video playback and DIT stations and pro camera crews were some of the best in the world. The equipment is extremely expensive and 'rentals' is a big market ( or vendors if you do playback). This is a hobby for me now and I am in the same boat as you re: home computer stuff and available NLE stuff.

You know what my main impression is from your posts ?

a) I like either one of your sample images ( which when you go from film to jpg is introducing new values maybe )

b) I just want to see the story you tell cause what I see it on is a different screen from what you have.

I hear the frustration you have but trust me, you are wasting your time being mad at adobe if there are ways to fix it there. We are just users like you. Nobody ( NOBODY) here programs the stuff or has any infuence on that stuff. So we all work with what we have and choose the tools that work for us as INDIVIDUALS.

🙂

good luck !

[Kizzume]

"Switching to resolve would cost you a year in learning curve, and money for new hardware ( like SDI out to video monitor etc.)  You would need tens of thousands of dollars to do that and spend a year learning the resolve program(s) cause they are now combined ( edit, color, sound, FX, etc. ). Different animals."

That's actually not true about cost.  Yeah, I'd have to dish out $300 for the studio version of the software if I want better render speeds, but their software doesn't require a bunch of extra hardware.  Sure, that hardware can make things easier, but it's not required.

It definitely requires learning new software, and I especially dislike their "node" interface, it's cumbersome, clunky, and inefficient.

"I hear the frustration you have but trust me, you are wasting your time being mad at adobe if there are ways to fix it there."

But they don't actually fix the problem, they just slightly cover it up and offer other problems with the image.  Any of these workarounds make the whole image darker.  Nothing, as of so far, makes it look like the original input files.  To me there's no excuse for Adobe making all exported/rendered files look different than the originals.

"We are just users like you. Nobody ( NOBODY) here programs the stuff or has any infuence on that stuff. So we all work with what we have and choose the tools that work for us as INDIVIDUALS."

Well, it seems there are some Adobe employees that come here too, but yes, in general, what you say here is true.

My big issue is that everything was fine until v13, then the panels issue came up (where saved workspaces put panels in completely different places and I have to drag panels to other screens every time I create a new project), as well as this gamma issue.  I really don't want to chance putting pirated software on my computer, but it might end up being my only reasonable choice.  It's quite unfortunate that Adobe has this subscription model that disallows installing older versions.

EDIT:  BTW, I did watch the video, and I offered images showing that it makes the whole thing darker than the original.

Anyway, thanks for your input.

[salvo34]

focus more on what you CAN do rather than what you CAN'T do.

🙂

[R Neil Haugen]

Full sympathies.

Something I don't think we've talked of in this thread, what do the scopes, particularly the Waveform (YC no Choma mode) show for the original image? Are the blacks down to black in the scope or lifted a bit? It has occured to me that if your monitor was set to 'full' range 0-255 for Rec709 in the video card settings, you would get about exactly this result if you then set the image by visual black in Premiere.

Many users think that they want full black to white, so the video card should be set to 'full' or 'data' range for video, rather than the 'limited' or 'legal' range. Which is actually backwards. Nearly all video media is 'limited' range unless it is 12-bit DPX or HDR. The monitor will then display the image 0-255.

But if you have it set for 0-255, and work in Premiere, the monitor will actually be taking the area at file level of 16 to black ... so if visually you set 'blacks' in Premiere, and export ... you now have a file with 'black' set about 32, which the monitor will drop to around 16.

Set the video card correctly for video to show in limited/16-235, and re-work with the file in Premiere, and it will fix the problem.

So ... curious about your video card's setting for video range.

Past that, I've just read through a LONG post on the LGG (LiftGammaGain) forum, a mostly pro forum of mostly colorists. A guy did a TON of testing of NCLC tag use in Resolve, to 'flag' exports so they would look similar across platforms/players. His system was a typical colorist system with highly calibrated/profiled Grade 1 Reference monitor. Everything up to full b-cast standards.

It was an intense, dense set of testing he performed, I'm guessing setting up to start was 2-3 hours of work, and doing the entire set of controlled tests was a couple days. He worked both on a new Mac and in Windows. Using all browsers and services, and several players plus the OS included players to test the output.

The end conclusion: color management is a freaking MESS. With any particular X setting of the NCLC tags, the image was correctly displayed (and his included charts and ramps so there were very tight measurements that could be made) in one or two things, but was not in others. It was a mix & match, pick your pick, there simply wasn't a setting he could export to that would look correct on any one system across services, browsers, and apps.

Very frustrating ... maddening ... infuriating. It should NOT be this impossible.

Resolve gives you the export options to set a few things differently for NCLC tags, which Premiere doesn't. I've argued with the program heads & engineers to get them, but they've said it simply wouldn't be any panacea. Well ... it would be something that some users could use for their specific needs.

But as that guy's testing shows, they are right: it wouldn't be a panacea like everyone wants.

Neil

[Kizzume]

"Something I don't think we've talked of in this thread, what do the scopes, particularly the Waveform (YC no Choma mode) show for the original image? Are the blacks down to black in the scope or lifted a bit? It has occured to me that if your monitor was set to 'full' range 0-255 for Rec709 in the video card settings, you would get about exactly this result if you then set the image by visual black in Premiere."

I don't use scopes to analyze this stuff, I use actual color value numbers.  It doesn't matter which setting I have set for video playback.  Premiere changes the images regardless.  Again, since v13.  Before v13 it was always just fine.

Here are examples of what happens between the originals and what happens to the images when I run them through Premiere.  The images that only have text on the left are the original images.  On the images that has text on both sides, the text on the left shows the original values, and the text on the right show what the values become once they're ran through Premiere.

As an example, the color 1,1,1 becomes 9,9,9 after it's ran through Premiere.

[R Neil Haugen]

You didn't answer what your GPU card setting is for video range ... full or limited? As I said above, if it's set to full, that would cause about precisely this situation. And yes, it would matter what setting is used by the GPU to send data to the monitor, or in some monitors, the setting inside that monitor.

As has been demonstrated in several apps especially Resolve be a number of colorists when teaching about color management. And also the color management specialists who make the software to calibrtate the pro colorists systems.

The more I've read through this thread, the more I think a setting in either your GPU controls or your monitor is incorrect. It would give exactly this result.

And I cannot replicate this on my machines, neither my laptop nor my desktop. The laptop isn't fully calibrated of course, the desktop is and profiled. Exports of both video and still media exhibit the same tonal range after export as before, when brought back into Premiere. And when played on the screen in Potplayer and VLC.

Neil

[Kizzume]

On my current setup, I have the GPU set to display limited video range.

There's nothing incorrect about seeing all the colors.  I specifically set my monitors and the GPU settings so I can actually see everything.  If there's literally no difference between 0,0,0 and 10,10,10, then it's set incorrectly.  On the flip side, if 0,0,0 black looks gray, then that is wrong as well, and I've had that problem with other monitors in the past.  As it stands, 0,0,0 looks completely black, and I can see a tiny hint of difference between 0,0,0 and 1,1,1 if the image fills most of the screen.

There is absolutely no reason why Premiere should change gamma of the original files.  The imagery that goes in should match the imagery that goes out.  If people want it to be different, that should be an option that they set, it shouldn't be forced on everyone.

It just seems that my only choice at this point is going to be to get a pirated version of v12 and be done with it.

[Kizzume]

I must admit, I'm quite confused at the logic you're using here.  You make it sound like what someone has the GPU set for will literally change the content of files, rather than simply change the way those files are viewed.  How I view images on my screen does not change whether Premiere changes the gamma of content of exported files.

If we were talking about audio software, and I was reporting that the software was automaticlaly compressing the audio, changing it from the original files even though I never asked it to, it wouldn't matter whether compressed audio is what people using high end equipment would want, the program would still be compressing the audio.  If many people wanted the option for it to compress the audio, that would be fine for the option to be there, but to force it on people with no way to turn it off would be messed up.  In my view, this is exactly what Adobe is doing here but with images/video.

[Andy 1968]

Kizzume,

I do not have the latest version of Premiere Pro. Having said that does the rendered video look correct if you place it in the Premiere Pro timeline? If not there could be a bug.

You stated you tried my method but it made the whole video darker. In my video I demonstrated you have to set the parameters correctly. You can add the proc amp filter to control contrast and brightness as well as use the gamma filter. You have to do a few render tests but once you get it setup correctly save the filters. Unless things have changed DaVinci Resolve resolve will have the same issues by defualt. You can get it to export correctly by switching paramters. Let me put it to you like this. My videos looks different on my laptop than my desktop computer. If I uses the Intenisty Shuttle with broadcast compliant hardware the colors will look different than my desktop PC. You do realize your video will look different if broadcast to someone's TV as opposed to being played back on a computer monitor? Does that mean Premiere Pro has a bug or is there a difference in YUV vs RGB? Things for print need to be converted from RGB to CMYK.

There are video codecs you can render to in DR and Premiere that will not get the gamma shift.

Below is DaVinci Resolve in action.

https://youtu.be/nN2XlWWd26Y

[Kizzume]

Sorry for not answering this earlier. When it comes to using the gamma adjustment layer and what number I have it set for, 14, which the guy in the video also agreed on, looks the closest to what it's supposed to look like.  15 is way too dark and 13 is way too light.

Here's what happens to the gamma of a test image when I run it through Premiere with the gamma adjustment layer.  The first image is the original, with the color values notated, and the second image is the same image ran through Premiere with the gamma adjustment layer, with the modified color values notated in red.

[Kizzume]

(continued) "Unless things have changed DaVinci Resolve resolve will have the same issues by defualt."

It doesn't, I've tested that already, just like Premire v12 and earlier didn't.

[Kizzume]

You said:

"And I cannot replicate this on my machines, neither my laptop nor my desktop. The laptop isn't fully calibrated of course, the desktop is and profiled. Exports of both video and still media exhibit the same tonal range after export as before, when brought back into Premiere. And when played on the screen in Potplayer and VLC."

Ok, if what you're saying is true, then please post some examples.  For consistency, let's use one of the test images I made. https://kizzume.com/testigy.png 

Go ahead and export it as a png in Premiere and post the image here.

[Kizzume]

Just one more clarification:  Workarounds for this issue wouldn't ever have been created if it wasn't a problem for other people in the first place.  Now, if it's just something you don't notice because you have your monitor set a certain way, that's not proof of anything at all.

[R Neil Haugen]

If your computer and monitor are set as you say for limited range, then that answers that question. I wanted that specific information as that would cause what you're been getting. So we can move past that.

Sometimes, some of this is difficult to both explain and follow. Pat Inhofer over at MixingLight.com did a somewhere around 15 minute tutorial in Resolve a couple years back showing how the settings of the GPU/monitor and color prefs in the app when set to full vs limited caused problems. For quite a few people seeing his work through examples using a bars & tone clip while changing things, exporting/reimporting, viewing in other apps.

He also pointed out why that showed how crucial using scopes were to check for such inaccuracies.

I'm in a meeting (stupid online meetings ... ) at the moment. When I get to the studio later today I'll test out that image on my gear.

Neil

[Kizzume]

Thanks.  I look forward to that.  I hope the meetings go well. 

I just wanted to point out again that it doesn't matter what I have the GPU settings for my monitor set for, and then quit and restart Premiere after I make the changes, Premiere does the same thing to the images regardless.  It's why I'm pulling out my hair over your responses to this.  

I absolutely acknowledge that these ranges look different depending on the settings.  Yes, absolutely.  But the answer to Premiere changing the gamma of the outputted files shouldn't be "just adjust the GPU and your monitor to make it so 8,8,8 looks the same as 0,0,0 and you won't notice the problem".  It shouldn't matter whether I can adjust my settings so I don't notice it--I don't want the problem to be there at all.  

As I've said many times, this was never a problem in v12.  Last year I tinkered with v13 and didn't like it--it's slower on editing, it has the panel placement issues (it doesn't fully remember where I place panels, so every time I open a new project, I have to drag panels around), it crashes more, and most of all, it has this gamma issue.  I hoped that v14 would fix those things, but all those problems remain.  And again, I've tested this in DaVinci Resolve, and it doesn't have these gamma issues.  DaVinci Resolve has AAC audio issues in Windows, everything sounds like a 128kpbs or 96kpbs mp3.  Sure, I can export as a mov and use uncompressed audio, but not all websites take that format.  That's the only reason I didn't switch to Resolve.  Blackmagic is even more stubborn about fixing issues than Adobe is.

If Adobe didn't take away the ability this year to install earlier versions than one whole version number, this wouldn't be a problem.  I'd be using v12 and would be happy about it.  I loved v12!  I hate v14--and now, to fix the issues in v14, I'm supposed to either use an LUT or a gamma adjustment layer, both of which result in the image looking darker than the original.  If the workarounds worked right, I may have complained a little, but I certainly wouldn't have complained nearly as much.  At leat there would have been a workable solution.  As it stands, there is no workable solution other than using different software completely.

Anyway, thanks for your response.  Again, I hope your meetings went well.  I look forward to seeing if you have the same luck using the image I created.

[Andy 1968]

Another video that migt be worth watching.

https://youtu.be/7kjZZNT5js4

[R Neil Haugen]

But the answer to Premiere changing the gamma of the outputted files shouldn't be "just adjust the GPU and your monitor to make it so 8,8,8 looks the same as 0,0,0 and you won't notice the problem".

Clearly, I've not communicated my concern about the monitor settings. Because I was not talking about fixing it after the issue, but preventing the issue from happening. As if one works with a monitor set to 'full' within Premiere, and adjust things according to how they look ... one will adjust things too high on the bottom end to keep from crushing things to black.

And after export, wonder why one's blacks are milky.

However, when you listed your current settings for video media as correctly set to limited, that took care of my concern. Again, never ever suggested as a work-around, but trying to get to the bottom of the problem.

I exported your PNG file as both ProRes LT and checked it within Premiere, and as a png. Here's the png file I got.

On my system, there was no movement in the scopes or on the reference monitor when I went from your original to the ProRes LT or the exported png file.

It will of course be interesting to see how the file comes into your system.

Neil

 

[Kizzume]

It's exactly as I've been saying. Premiere changes the gamma.

I imported your image you attached into Photoshop and checked each color bar to see what the new values were, and notated them in red.

[Kizzume]

(Continued)

"On my system, there was no movement in the scopes or on the reference monitor when I went from your original to the ProRes LT or the exported png file."

You're trying to use the program that messes up the gamma to judge whether the images have changed.  It's absurd.  It doesn't matter if the scopes show no movement in Premiere.  Please import my original image into Photoshop and import your image you attached to the forum into Photoshop and look at the raw numbers.  They're clearly different from each other.  1,1,1 becomes 9,9,9, and 2,2,2 becomes 12,12,12, and 3,3,3 becomes 14,14,14, and 4,4,4 becomes 16,16,16, and 5,5,5 becomes 17,17,17.

I understand that in Premiere, you don't see a difference in the monitor.  But as I said, Premiere is the program that's messing this stuff up, so you can't count on that.

Premiere changes the gamma.  There's no denying it at this point.

[Andy 1968]

Kizzume,

There might be a bug in the newest version of Premiere Pro but I cannot say for sure since you have avoided my questions. That being said is there a difference between software only mode and GPU acceleration? 

[Kizzume]

"is there a difference between software only mode and GPU acceleration?"

I'm not fully sure what you mean.  If I turn off "display color management", it shows in the Premire monitor how the video or image will actually render.  When I have that option turned on, it shows in the Premiere monitor what it's supposed to look like, but doesn't in the final render.

When it comes to the recent tests, we've been exporting as a png, which looks identical to the exported videos of the same image, so to make it easier, we've been working with png files.  When exporting as a png, there is no option to choose between software encoding and hardware encoding.

If you're talking about a totally different setting than either of those, I don't know what it is, and I can test it out if it's different than anything I've tried so far.

[Kizzume]

(continued) There's one more option that I didn't mention, and that's in Sequence Settings, which is "Composite in linear color", which I sometimes turn off so images blend in a consistent way that matches the alpha values that are in the original images.

Going back to choosing between hardware and software encoding, I've tested that as well, and it makes no difference.

If I could get the rendered video or image to look the same as what it looks like in the Premiere monitor when I have "display color management" turned on, I would never have posted that there's a problem in the first place.  That's how v12 and earlier acted.