Imported Video - Different Gamut?

[teedeecee]

In setting up for a new project this morning, the imported Video has arrived with a very different look to it. Its as though the black level has been raised by about 10 percent, or the Gamut has been changed.

Viewing the QT Apple Pro Res Proxy in PT12HD and Apple Quicktime Player side by side indeed reveals that for some reason Tools is displaying the Video in very different colour space.

I have tried re-rendering the vision out from FCPx using different methods and settings but no luck. Its annoying as it puts the director off working with vision that looks washed out.

Any thoughts?

[AndrewAction]

Originally Posted by teedeecee

Viewing the QT Apple Pro Res Proxy in PT12HD and Apple Quicktime Player side by side indeed reveals that for some reason Tools is displaying the Video in very different colour space.

Sadly this has been a thorn in the side of Avid video editors for a long time. Apple changed how the colour space and or Gamma was identified in the Pro Res codec header data.
Andrew

[Reckless Erik]

Is this only in the ProRes codec?

[BScout]

There are two different gamma setups for ProRes: 1.8 and 2.2. 2.2 is the standard for most everyone else but Apple had 1.8 as their own standard previously (sometimes referred to them as the animation gamma.) On export and from QT 7 Pro, you can tell the video to be saved with the flag to recognize which gamma setting you want used but it depends on the playback engine (which Avid's Video Engine is different than QT X or QT 7 engines) to recognize that flag. So playback will be dependent right there. Also, Mac OS X isn't colorspace aware though some programs are (like Avid MC, FCP, CinemaTools, etc.) which means depending on which program is playing it the exact same file will play differently.

This gets even more complicated if the source material started as DNxHD (say from an Avid editor) and was saved as ProRes on export since you also have different color spaces to contend with and settings to make sure black/white isn't crushed/clipped. Interestingly, the color space info isn't discarded with ProRes or DNxHD (unlike other codecs when you do this) -- it's just limited by a flag again. So the color info is there but it's just not being read.

On top of that is you're using the Proxy version which not only creates a moire in certain degrees of grey but is an "offline" codec in the first place.

What it comes down to is unless the whole project has stayed at one codec from NLE ingest to output, there's no way to guarantee perfect true color, saturation, gamma, black/white. Thankfully color grading/assembly happens after sound so QC isn't music's problem.

[Chief Technician]

I think there is some confusion with the terms used here.

Gamut - The range of colors that a device is capable of (or limited to) reproducing. ITU-R Rec.601 is the standard definition (SD) color gamut. ITU-R Rec.709 is the high definition (HD) color gamut. In the interest of being thorough, ITU-R Rec.2020 is the ultra high definition (UHD) color gamut.

Gamma - To use an analogy with audio, these are the mids when it comes to your equalizer. Depending on which NLE or CC software you use, the term gamma may not be used. Continuing the audio analogy, some refer to the lows, mids, and highs as lift, gamma, and gain. Others refer to the lows, mids, and highs as shadows, mid tones, and highlights.

Mac OS X Snow Leopard v10.6.0 and later uses a gamma of 2.2. Mac OS X Leopard v10.5.8 and earlier uses a gamma of 1.8.

I suspect that the problem described is neither a gamut problem or a gamma problem. What I suspect may be happening here is that the range of the video is being misinterpreted (or ignored) by the Avid Video Engine included with Pro Tools v12.4. There are two ranges that video signals can occupy, depending on where they originated and what is being done with them. They are:

1. Legal, 16-235
2. Full range, 0-255

If you have video that is full range (0-255), and it is displayed as if it were 16-235, then it can appear washed out, because what is supposed to be viewed at the zero level (black) is now not entirely black (16). What is supposed to be white (255) is now not as white (235).

[teedeecee]

Thanks everyone for great feedback and info.

And thanks for correcting me, yes I meant Gamma, not Gamut.

Have been doing a lot of tests to see if there is a work around but nothing seems to help. I have true DNxHD codecs, all sorts of settings in Apple Compressor.

It's curious that this situation exists though given PT's place in the production chain.

My solution at present has been to use a third party app to play the QT in sync via Ethernet TC.

Cheers,

Tony

[Postman]

I'll lay strong odds, very strong odds, that Chief identified the root cause. That said, something doesn't make sense (if Chief is right as I think he is).

Pro Tools assumes video files are encoded per standards with legal range values of 16-235. That is the broadcast standard after all. QT, though, assumes video files are encoded with legal range values of 0-255. (Not talking about 10 bit video here, only 8 bit).This difference between 16-235 and 0-255 has confounded many many since the beginning of digital time and is tied to black setups and video headroom and other things beyond my limited brain's color space. The important point being, QT should display a 0-255 video file as "washed out" compared to PT, which is NOT what you said. So, I think there may be more variables here than just Pro Tools. Perhaps monitor settings between different input sources, different video hardware, I don't know but I'll still vote that Chief's post tickles the root of your problem. There are two standards for video levels encoding, one is typical of broadcast workflows, the other is typical of nearly everyone else. Pro Tools and Media Composer (we're all agreed that MC can handle video properly, right?) both reproduce identical video quality through the same IO hardware and monitors, WHEN MC is using 16-235 range. Therefore I would say it is not a PT problem, at least not directly.

THAT said, it would be super-friendly of Avid to include a switch in PT to use one or the other. There are two standards after all. When I get video from "normal" clients, it is encoded at 0-255. When I get video from enlightened clients and a few others by mistake, it is encoded 16-235. IMO Pro Tools should be able to handle either with just a switch.

Oh and, give us realtime timecode windows too!

[teedeecee]

I have done some tests to try and learn a little more, and as Chief theorised, it appears to be a Legal vs non-legal range issue.

Attached are two images, one with a a side by side comparison of PT and QT accessing the same file on the same monitor at the same time. PT clearly has a washed out look.

The Second file is a Grey Ramp, created in PhotoShop, 0-255 Grey, rendered in FCPx and Compressor. Image shows PT vs QT, with PT clearly showing a reduced range.

[Postman]

I did the same comparison here, and see the same that you see when I compare QT and PT windows on the same desktop monitor. I had expected PT window would appear darker but I misunderstood how PT works through the desktop. I have SMPTE bars up now and can clearly see the "blacker than black" band in the PT video window, which means the full bit range is being displayed on the desktop. A video monitor should not display blacker than black while a typical RGB monitor does. In the QT window blacker than black is not visible, so I will venture a guess that QT adjusts the image to appear on the desktop as if it is a video monitor. I don't know the details of this, someone with more video smarts may wish to step in here. PT11 and 12 use a video engine from Media Composer so I checked Media Composer and see the same behaviors. I will guess it is not a bug.

What I know is PT handles video correctly out to video monitors, where the gamma appears as it should (assuming proper setup). Maybe you should consider going that route.

[Chief Technician]

Originally Posted by Postman

it would be super-friendly of Avid to include a switch in PT to use one or the other. There are two standards after all.

Oh and, give us realtime timecode windows too!

Are either of these already logged at protools.ideascale.com? If so, vote for them. If not, submit them as feature requests. Either way, links for voting would be helpful.