How do I change the color range of a source file from limited to full range?

[rgr2]

I have .mts files from a camera that have no color range flag, but in fact have a range of 16-255. Premiere recognizes them as "limited range", which is mostly correct. But how do I change the range to 0-255 (full range)? So far I have blown out bright colors in Premiere.
I've cursed the program -- I can probably change the values, but I can't find the option to change the color range. Where is it hidden? 

I think this should be in the basic properties of the file.

[Ann Bens]

Effects > Lumetri presets > Technical

Not sure this is going to fix the blown out hightlights.

Might want to read this doc about color managment

Color management in Premiere Pro

[R Neil Haugen]

All YUV Rec.709 by the standards is to be encoded to limited range, and will be displayed correctly as full 0-255 by the display device. IF the user hasn't mucked up their display device settings.

So if the limited range isn't being displayed correctly there is probably an issue with your color managment settings, which are ALL in one place.

Lumetr panel Setttings tab, the tab NAMED Settings.

Set Display Color Management, auto detect log, auto tonemapping to on. Set the Sequence to Rec.709 and your vieiwing gamma to your preference.

On Macs, also set Extended Dynamic Range when availablt to on ... and you have an odd choice for viewer gamma.

Viewing (and working) gamma choices

On Macs, especially without Reference modes set to HDTV, Apple's ColorSync utility is set WRONG. It will use a wrong display tranform for Rec.709 video, using essentially a gamma of 1.96 rather than the correctly specified display transform of essentially gamma 2.4.

Through testing I've seen, Apple also doesn't stick the landing for color space transform of the colors of the Rec.709 sRGB space into the display's native P3 color space. So it isn't that the colors are visually less saturated, they're actually 'off' a small amount in hue values.

So outside of Premiere on Macs without a Reference mode set to HDTV, the image will be lighter in the shadows. And the colors will be less saturated and vibrant.

If on such a Mac, you set the viewing gamma option to gamma 1.96, you will see a similar image inside Premiere and outside, as long as the outside app or player allows ColorSync to manage color.

This means QuickTime player, Chrome and Safari browsers.

Some apps/players, such as VLC, PotPlayer, and Firefox, will normally not let ColorSync manage the display transform, and will show a darker, more saturated image than Qt player, Chrome and Safari.

ALL other screens will show the image more similar to the VLC/Potplayer/Firefox image.

So you get to "pick your poison" ... who gets what image.

Viewing gamma of 2.2 or 2.4 choice explained

This should not be chosen based on where you will 'send' your deliverable, make this choice based on how bright your working environment is while doing color changes in Premiere.

This is the proper method as set in the professional standards. 

Colorists will be working in a very dark, near but not quite completely black room. And that is so their color sensitivity will be 'best' according to many tests of this. Pro colorists are required to use a display gamma of 2.4 while working in such a dark environment.

BUT ... if you are working in a normally lit room, then you are supposed to use a screen display of gamma 2.2 so that it mimics the view of the screen at gamma 2.4 in a very dark room.

ALL users should have their screen set to simply the "Rec.709" setting of the device, without mucking about the underlying controls other than properly calibrating the device.

Past that ... set your screen accordingly. Most people should be using viewing gamma of 2.2 in Premiere, as very few people work in that really dark room environment.

But if you are on a Mac without Reference modes set to HDTV, and only worry about how it looks in such screens, use viewing gamma 1.96. All those using correctly set screens will see a much darker image of course.

[rgr2]

Thanks for the advice, but that's not the point.

My source MTS file is full range -- YUV 0-255 (exactly in the range of 16-235, but I have to read it as full range so I don't lose the range of 236-255).

This is what it looks like in Premiere -- you can see on the graph that the whites are blown out.

I need to change the input range like I do in Vegas (pic below).

[R Neil Haugen]

Speaking from historical perspective, Premiere will only work in limited range with Rec.709 YUV files, following the long-accepted professional standard. (There may be another option in the 25.2 version using the newer CM tools I'm not aware of.)

So to use a YUV file encoded as full range, in Premiere, we have always had to go to the Effects Presets dialog. The Lumetri or Color section, and find the Full to Limited preset that fits your media. One is for 8 bit, another for 10 bit files.

Drag/drop onto your clip in the bin, and now it will be correctly transformed to YUV/limited range, and you can work normally with it.

I don't know of a way to use the new color management tools to change the way you handle this in Premiere, but there might be one. I'll certainly be asking about this at NAB next week.

[rgr2]

Thanks Anna and Neil, that's more or less what I meant.

I understand that in Premiere you can't work in the full range? Without using this filter unfortunately I see that the ranges 0-15 and 235-255 are simply cut out.

We'll see how it goes -- for now +1 for Vegas 🙂

[R Neil Haugen]

Huh?

I think you have a basic misunderstanding of what is going on technically. I'll be as clear as possible.

Full and limited Rec.709 video files contain exactly the same data. Exactly the same levels. Only the math used to encode the data to the file is different. 

You do not lose or gain data between full and limited.

All YUV, standard Rec.709 files, have always been encoded to the file in limited range, and always properly displayed in full range. That's how the entire Rec.709 system was designed to work.

Only 12/14 bit full on RGB Rec.709 files have always been encoded in full, and also displayed in full.

Your system should automatically and correctly handle both simultaneously.

You can set your monitor to full range for Rec.709 YUV, and set the file in say Resolve to full, and it will look fine.

But ... if you show that same file on any normally, correctly set system, it will show it with crushed shadows and clipped highlights. Because it will expand the file so that 16 goes to 0, and 235 to 255.

And yes, this confused the heck outta me at first!

[rgr2]

You're making a mistake right from the start.

Not "the same data", but "the same image". Only encoded in a larger data range, ~15% larger. Or, if you prefer, with 15% greater accuracy.

You could just as well write that 10-bit doesn't do anything, because "it's the same data".

Of course, there are situations where it doesn't make sense to use full-range (e.g. recoding a limited-range image to a different format).

[R Neil Haugen]

First, understand, I thought that full was better when I first started. It seems to be obivous. And I really messed things up, and learned how wrong I was in the School of Hard Knocks. It ain't what it sounds like it it.

I'll assume you have basic math skills.

You can encode the exact data on different scales ... one say 0-10, another 0-1,000 ... and do processing either way ... and again, have the exact same result to the end of the processing chain ... if your scaling of the data is correct mathematically.

I think you are still assuming there are fewer encoded levels in limited than full. WRONG.

In the encoding process, full and limited have the same number of levels. This has been the noted process, and has been displayed over and over by color scientists and noted colorists.

Which is why if you sent a full-range YUV file to a broadcast system it would be rejected out of hand immediately. They need full quality, and doing this would mean that on most systems, in the display transform of the screen ... 16 becomes 0, so that all values below 17 in the file are crushed to black. No detail, period.

And all values from 235 and up will be stark white. No detail, period.

If things were as you think they are, this couldn't happen. But guaranteed, if the user hasn't messed with the settings of a screen, it will.

Now ... I've been through this a couple dozen times at least, with Premiere users. Including with people who'd "properly" set their computer monitors and TVs, following advice they found in YouTube or gaming group discussions, so that in their system, it looked like it all "matched'". But they got frustrated when they sent a file to the forum, and ... it didn't "match" on any other pro user's system.

Why? On fully, properly calibrated systems ... we got a totally crushed and clipped image.

Is your screen calibrated with a good puck & software system, set to complete Rec.709 settings? Have you run a profile pass to check ... to verify ... the accuracy of the calibration?

If not, you really have no clue what that screen is showing, and I don't care what fancy certificate came with the screen. My BenQ had a fancy certificate, including charts, showing a tight Rec.709 compliance from the factory.

In testing right outta the box, with Lightspace, well gee ... white point was around 6800 or higher, the color volume was really skewed in a couple different directions as brightness increased, as each RGB curve shape was ... individual. Not matching the others. And it was topping out white at about 220 nits or so. Not the 100 nits spec for Rec.709.

WAY outta whack. To get that thing back into compliance, I had to go into the manual settings (not normally needed nor advised unless one has some training) and push the color channels around, and then do a calibration run plus a profile, but eventually, I could get a calibration that then running a full profile, using Lightspace as the controller, and Resolve as the patch generator ... that was solid at about 64.9K for color, close to the D65 spec, and was very tight from bottom to top for the RGB actual versus signal numbers. Well under the dE >2 variance spec.

I've been through this whole levels discussion a number of times with Resolve users that have used that app's many over-layed color management controls to really mess things up. Because? They'd been through several YouTube and/or gaming discussions saying to do so.

And they couldn't get it to show up correctly between certain devices, or when others viewed their outputs.

After finally getting them clear back to default settings on all the system, their computer, Resolve, and their monitor ... they were able to produce a file that displayed "as anticipated" everywhere.

Gee, follow the designed intended process, it works ... huh!

Note also ... none of your devices actually knows or "sees" color. Whether cameras, displays, or software, they only deal with brightnesses. Period. Some very brilliant people figured out how to get them to create color from brightnesses involving color filters over sensors and a ton of complex math.

And as we cannot make either filters materials or sensors or even the computer processing chips such that they totally match, no two screens ever show an identical image. Period.

This has also been demonstrated over and over by colorists and color scientists. With high-end Grade 1 Reference monitors, sitting side by side, fed identical signals from a calibrated/profiled breakout device from either BlackMagic or AJA. With an audience of high-end colorists ... and yea, the screens were not completely identical. Very close, but not visually identical.

Now go out "into the wild" with every screen in a different ambient environment if not moving around like phones, tablets, and laptops. Every change of ambient will change the viewed image on that screen.

Add the differences in manufacture of the screens, operating systems, apps, and user settings ... this is why colorists are taught that no one ever, on any screen, through any delivery system, sees exactly what you saw when you graded the show. EVER.

It simply isn't possible.

[Andrzej-K]

Premiere needs (which every other NLE has) a range setting on Clip attrbute level. It has other elements, eg. field order etc overwrite and same is needed for range. YUV  has nothign to do with it (YUV can be full level as well).

There are pelnty issue where files are wrongly marked in provate headers (eg DNxHR, DNxHD, h264/5) and Premiere follows it and decodes it wrongly. Sometime files are not marked, eg .h264 but use full range and then they are imported incorrectly as well. This is a MUST option, so user can ovewrite an auto detection.

There were plenty issuses with eg ProRes444 or DNxHR444 traveling between Premiere and Resolve as each compay had own idea if those files should be full or limited levels. DNxHR has setting in private heards to flag range, so this shoudl be read (not based on hard coding like Premiere still does) and decoded accordingly. Every ProRes shoudl be legal levels as per Apple spec as there is no way to flag range, so everythign is just an assumption. Still many people when epxorting HDR files used full levels in Resolve because Dolby said- HDR is full levels (which is missleading). It all got bit better now, but rnage overwrite in Premiere is still a must.

[rgr2]

Thanks Andrzej.

I understand that there is no way I can change the color range at the program level -- I just have to edit the source file and enter the appropriate flag in the header? Will Premiere then correctly recognize the color range?

However, in my case it turned out that the files are in xvYCC format. I started a new thread so as not to mix things up.

https://community.adobe.com/t5/premiere-pro-discussions/xvycc-file-support-in-premiere/td-p/15252245

[rgr2]

PS. But not every NLE needs it -- Vegas recognizes this flag, but I can change it to my own (limited<->full range) at any time. I don't know about others, I'll check Resolve.

[R Neil Haugen]

I understand there have been dev discussions in probably all the pro level NLEs as to how much controls to give to the users ...

One of course, starting out as a $250,000/seat grading app, had to give all options, even ones not normally used or following "standards. Which it was admitted allowed many users to do stupid things that really fouled up their outputs. BUT ... which were necessary to have at times for certain high-end video post needs.

One alllowed some things to be set by the user, but under the assumption that virtually all users were highly trained pros. But fewer options than the one above.

And Premiere has been used by more of a crowd that weren't necessarily as trained in high-end work, and at times I think the staffers used to be concerned with people doing stupid things to wreck their outputs. So they started from "as few options as necessary" as a default.

But even Premiere is now rapidly changing. Thankfully.

I can tell you why some things aren't .. wise, perhap? ... to be polite about it ... but even then, I will also always opt for expanding user control options. Always.

Even many things I will never need or choose to do. Because someone may find them usable, so ... yes.

[rgr2]

As you can see in my case, the standard recording in Rec.709 in full range is absolutely correct and the only correct one in the case of XvyCC. If I had listened to advice like yours and recoded these files in limited range, today I would have incorrect video files. Now all I need to do is set the appropriate flags correctly in the output files.

[R Neil Haugen]

First, have you tried the full to legal presets in the Effects bin?

The entire full versus legal thing is over the exact same data, same number of brightness levels, same chrominance data, simply encoded differently.

Which is why of course the full/legal toggles in Resolve work without losing file data, and why the full-legal and vice versa Lumetri presets in Premiere work fine.

And for the record, again, I always suggest more user controls. So yea, I've pushed for user control settings for this probably for over a decade. As there are situations where you can ge something encoded in full for some odd reason, and need to work with it.

[rgr2]

Read the thread I linked to.

With Rec709/xyvCC you can't make any changes to the range from Full to Limited/Legal -- U and V have to be in the range 1-254.