Import MXF files Gamma Shift

[Artem_Stolyarov]

Hello everybody!

I am working with MXF AVCIntra100 50i format files with audio from 2 to 16 channels.
Sample file  

File characteristics in the attachment.

On request, I perform visual masking of objects, such as cigarettes, drugs, etc.
The main task is to minimize the modification of the video file, we do not change the colors, levels and other characteristics that may affect the file from the visual side, but only apply a small Gaussian blue mask.

The problem occurs on Mac M1 12.6.2. Adobe version 25.1.2
The problem occurs on Win 10 i9-14900KF 64.0 GB RTX 5080 1Tb (+1Tb for Cache). Adobe version 24.1.0

I open the same file in DaVinci 19 (Mac M1 12.6.2)

I tried all possible settings of the Lumetri Color window. But none of this brings the signal back to normal values (as in the screenshot in DaVinci).

The attached screen recording shows that the Display Color Management Button affects the color in the Program window, but the signal itself in the Lumetri Scopes window remains unchanged.

The fact is that in Premiere version 22.3.1, this file opens correctly.

What am I doing wrong? So far, it seems that in the new versions (24, 25) Adobe has changed something in the principles of importing mxf files. What should I do in my situation?

[Artem_Stolyarov]

Upon closer inspection of the file, the Black Reference Level is 0, the White Reference Level is 1023, and the Color Range Levels are 1023.

The file that, in my opinion, is displayed correctly in the Lumetry Scopes window has different values.

I assume that the issue is in the interpretation of the video with the Nominal Video Range and Total Video Signal Range metadata.

Updating to the latest version of Adobe Pr 25.5 did not produce the desired result. Full-range video is imported in a compressed state (gray).

Changing the project settings, file color space, and Lumetri Color settings window settings does not restore the video to its normal appearance.

[R Neil Haugen]

I think your problem is the file was encoded as YUV (technically Y/Cb-Cr) and also as Full range ... while by the standards of the format, Rec.709/YUV files are expected to be encoded as legal range.

There is ABSOLUTELY no difference in the data levels between the two mathematical encoding processes, but Premiere expects YUV media to follow the rules ... and be encoded as legal range. Which is of course then always displayed full. That's how the whole thing is designed to work.

Premiere doesn't have a switch to handle this conversion, so there's a couple things to do ... one might work, the other should work.

The first is set the Display Color Management, auto detect log, and auto tonemapping to on. See if that fixes this.

Alternatively, in the Effects Presets Lumetri section, there are conversion presets that change 8 or 10 bit files from full to legal or the other way around. Drop a 10 bit full to legal on the file in the bin, and Premiere should handle it correctly.

[Artem_Stolyarov]

Hello @R Neil Haugen 

Thanks for the answers!

Display Color Management changes the display in the Program Monitor window, but the signal strength in the Lumetri Scopes window does not change.

Control Manage Auto Detect Log And Raw Media and Input Tone Mapping does not change the signal level in the Lumetri Scopes window and Program Monitor window.For example, DaVinci has a data level setting with auto, video, or full options. It works correctly.

Applying the preset Legal to Full Range, 10-bit worked for me! How did I not find it before(! Thank you very much, Mr. Haugen!

I see that files with the full range were created in older versions of Pr, for example 12.1.2.
Therefore, it is strange for me to see how the Premiere imports his own files in a different way.

Based on which document does SMPTE or ITU Premier handle levels for YUV/BT.709 now? ITU-R BT.709-6?

[R Neil Haugen]

Resolve was Davinci Resolve once upon a time ... I refer to it now as BlackMagic Resolve, as it is a very differently built app anymore.

Davinci was originally purely designed for grading, and as the current Resolve is a derivative, and still has a large pro colorist user base, it has retained that undelying 'nature' ... mostly. And all the setup things that colorists over time have wanted and become used to having for some specifice, rather esoteric, workflow needs. Ergo, the bewildering array of user-changeable options for handling a truly massive array of color management things.

As there are specific reasons, for those working in say compositing 'plates' being meshed with various color management processes in complex cross-app/image creation workflows ... need to have really bonkers control of the underlying setup.

Most of which controls, the vast majority of users should never, ever, change ... according to most upper-end colorists. Unfortunately, there's a ton of YouTubers who suggest changing things to get "real professional grading" ... advice that actual colorists look at and go, oh, Hades no ... dude, just don't go there.

Things like setting the scopes anything but Auto. Or the timeline CM anything but the default for Rec.709 workflows. Unless you know enough to know exactly what and why, the defaults are there because those are the normal and expected workflow choices.

So when comparing workflows between Pr and Re, I like to know the actual knowledge level. As that is both informative, and helps avoid giving advice that for a specific person is on the "like, um, duh?" level, and therefore extremely irritating ... but which for another person is necessary knowledge they do not yet have.

You discuss setting the scope levels ... which actually, most colorists I know do not ever modify. Why? Because for nearly all applications, the Auto setting is the correct one. And yes, I've had to work with a ton of people over the years who should not have been mucking about with 'deep' CM settings in Resolve, and should have been totally auto or 'default' for most things. (Which is how most colorists work, btw.)

Once someone has messed the Resolve auto/default settings of scope or general CM stuff, they then had to mess with their monitor or GPU settings and maybe go back to the camera settings ... and then when they exported, it was displayed wrong!

Well, no ... the export displayed exactly the mess they had created by 'breaking' the system. That's the first lesson for most pros on working in Resolve ... don't break the System. You can do a lot of stuff, change a number of things, without breaking things after you know that if you change 'this' here, you also have to change it back 'there' in the process. As is done in manual CM node tree structures by heavy Resolve users.

But I don't know anyone who mucks with the basic scope settings. If they do, it's in the outboard scopes they actually rely on, not Resolve's internal scopes.

Premiere scopes show the signal according to the lastest SMPTE Rec.709 specifications. And you are correct, they don't allow users to change the scopes as that is not recommended, nor needed, for any normal operation. 

Personally, I've worked in Resolve over a decade, and I have never had a circumstance where I needed to change the scopes from Auto. I can't even imagine one! Because all the media I work with is 'normal' camera or screen capture media, which the system simply handles correctly.

Why? Because in auto, both full and limited range media are shown correctly on the scopes. As they will be displayed in playback. Not as they were encoded, which was never intended as how they would be viewed.

And in Premiere, the built-in is the equivalent of 'auto', and it also works correctly ... it shows that data according to signal levels as expected for playback,  and as that encoding will be displayed by monotors, for media produced by the standards.

All RGB media ... that 12 bit and up stuff, that is supposed to be encoded full, is displayed as 0-255 on the left-side graticle scale (or 0-1064 if you prefer 10 bit scale numbers).

All YUV (Y/Cb-Cr) 8/10 bit media which has been properly encoded legal, is also always displayed 0-255 in the scopes, as it will always be displayed in any correctly set monitor.

There is no need for different scope displays for full or legal encoded data. Both are shown in most proper scopes setups as they will be displayed in the monitor and exported, which is correctly 0-255 or 1064.

And as always, the graticle numbers of the scopes in Premiere are simply a percentage thing. It doesn't matter whether you have them set to 8 or 10 bit, they show the identical percentage signal strength. So having it show 0-255 does not indicate that there are only 254 levels present whatsoever ... just that you are using that scale number set to represent essentially 0-100%. Either works, and they both show exactly the same thing as a percentage.

I hope that clarifies a few things.