Skip to main content
Inspiring
April 3, 2025
Open for Voting

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

  • April 3, 2025
  • 15 replies
  • 1361 views

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.

15 replies

rgr2Author
Inspiring
April 7, 2025

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.

R Neil Haugen
Legend
April 7, 2025

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.

Everyone's mileage always varies ...
rgr2Author
Inspiring
April 7, 2025

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
Legend
April 5, 2025

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.

Everyone's mileage always varies ...
rgr2Author
Inspiring
April 5, 2025

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.

rgr2Author
Inspiring
April 5, 2025

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

Participant
April 4, 2025

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.

R Neil Haugen
Legend
April 4, 2025

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.

Everyone's mileage always varies ...
rgr2Author
Inspiring
April 4, 2025

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
Legend
April 3, 2025

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!

 

 

 

 

Everyone's mileage always varies ...