OK, I wrote about this without digging deep enough. If you read the original article I claimed that ProRes was clipping my files at 104%. Well it’s NOT. The ProRes files are just fine, BUT some Quick Time applications are clipping the files at playback. In FCP the files are OK. Premiere appears to be reducing the level of the files a little and Quick Time player is clipping the files at approx 104. So this isn’t as big an issue as I thought, but you do need to keep an eye out as to what is happening with highlights and super whites depending on what software you are using. I was wondering why I hadn’t seen this before. In part it because I am no longer using FCP.
Tag Archives: clipping
Convergent Design Gemini throws up a ProRes Issue. NOT THE PROBLEM I THOUGHT IT IS
OK, I wrote about this without digging deep enough. If you read the original article I claimed that ProRes was clipping my files at 104%. Well it’s NOT. The ProRes files are just fine, BUT some Quick Time applications are clipping the files at playback. In FCP the files are OK. Premiere appears to be reducing the level of the files a little and Quick Time player is clipping the files at approx 104. So this isn’t as big an issue as I thought, but you do need to keep an eye out as to what is happening with highlights and super whites depending on what software you are using. I was wondering why I hadn’t seen this before. In part it because I am no longer using FCP.
Whites, Super Whites and other Bits and bobs.
Do you know how your NLE is handling your video, are you whites white or whiter than white or does this sound like a washing powder add?
In the analog world you shot within the legal range of black to 100% white. It was simple, easy to understand and pretty straight forward. White was white at 100% and that was that. With digital video it all gets a lot more complicated, especially as we now start to move to greater and greater bit depths and the use of extended range recording with fancy gamma curves becomes more common. In addition computers get used more and more for not just editing but also as the final viewing device for many videos and this brings additional issues of it’s own.
First lets look at some key numbers:
8 bit data gives you 256 possible values 0 to 255.
10 bit data gives you 1024 possible values, 0 to 1023.
Computers use bit 0 to represent black and bit 255 or 1023 to represent peak white.
But video is quite different and this is where things get messy:
With 8 bit video the first 16 bits are used for sync and other data. Zero or black is always bit 16 and peak white or 100% white is always bit 235, so the traditional legal black to white range is 16 to 235, only 219 bits of data. Now in order to get a better looking image with more recording range many cameras take advantage of the bits above 235. Anything above 235 is “super white” or whiter than white in video terms, more than 100%. Cinegammas and Hypergammas take advantage of this extra range, but it’s not without it’s issues, there’s no free lunch.
10 bit video normally uses bit 64 as black and 940 as peak white. With SMPTE 10-bit extended range you can go down to bit 4 for undershoot and you can go up to bit 1019 for overshoots but the legal range is still 64-940. So black is always bit 64 and peak white always bit 940. Anything below 64 is a super black or blacker than black and anything above 940 is brighter than peak white or super white.
At the moment the big problem with 10 bit extended (SMPTE 274M 8.12) and also 8 bit that uses the extra bits above 235 is that some codecs and most software still expects to see the original legal range so anything recorded beyond that range, particularly below range can get truncated or clipped. If it is converted to RGB or you add an RGB filter or layer in your NLE it will almost certainly get clipped as the computer will take the 100% video range (16-235) and convert it to the 100% computer RGB range (0-255). So you run the risk of loosing your super whites altogether. Encoding to another codec can also lead to clipping. FCP and most NLE’s will display super blacks and super whites as these fall within the full 8 or 10 bit ranges used by computer graphics, but further encoding can be problematic as you can’t always be sure whether the conversion will use the full recorded range or just the black to white range. Baselight for example will only unpack the legal range from a codec so you need to bring the codec into legal range before going in to baselight. So as we can see it’s important to be sure that your workflow is not truncating or clipping your recorded range back to the nominal legal or 100% range.
On the other hand if you are doing stuff for the web or computer display where the full 0 to 255 (1023) are used then, you often need to use the illegal video levels above 100% white to get whites to look white and not bright grey! A video legal white at 235 just does not look white on a computer screen where whites are normally displayed using bit 255. There are so many different standards across different platforms that it’s a complete nightmare. Arri with Alexa for example won’t allow you to record extanded range using ProRes because of these issues, while the Alexa HDSDi output will output extended range.
This is also an issues when using computer monitors for monitoring in the edit suite. When you look at this web page or any computer graphics white is set at bit 255 or 1023. But that would be a super white or illegal white for video. As a result “in-range” or legal range videos when viewed on a computer monitor often look dull as the whites will be less bright than the computers own whites. The temptation therefore is to grade the video to make the whites look as bright as the computers whites which leads to illegal levels, clipping, or smply an image that does not look right on a TV or video monitor. You really need to be very careful to ensure that if you shoot using extended range that your workflow keeps that extended range intact and then you need to remember to legalise you video back to within legal range if it’s going to be broadcast.