[ This article was first published in the June, 2007, issue of
Larry’s Final Cut Pro Newsletter. Click here to subscribe. ]
ProRes is the new QuickTime codec Apple released with Final Cut Studio 2. The reason it needed to be invented was that none of the HD codecs currently shipping with QuickTime supported both small file size and 10-bit quality. You could get one or the other, but not both.
The reason 10-bit quality is important is illustrated in this simulated picture.
All shades of gray, and shades of a color, are represented by a numeric value. In 8-bit video, these values range from 0 – 255. In 10-bit video, these values range from 0 – 1023. In both cases, 0 represents the absence of something, either white or a color, while either 255 or 1023 represents the maximum amount of white, or a color.
Research has shown that an 8-bit gray scale is essentially sufficient to smoothly represent all the shades of gray our eye can perceive. However, 8-bit color shows banding, that is, clear divisions between different shades of color. I’ve simulated this in the lower portion of the illustration above.
To prevent banding, color needs to be stored in 10-bit files. This provides smaller differences between color values, which prevents banding, but at the expense of much larger files.
DV, DVCPRO-50, DVCPROHD, HDV, XDCAM — the formats that many of us use every day — are all 8-bit formats. This means that they will have a tendency to exhibit banding in saturated colors.
This problem is made worse as we start using Color for color correction. This is because Color needs to render your color corrections into video files as part of its final output process. If you output 8-bit video, you could easily inject banding into your final masters.
To solve these problems, ProRes allows you to store both SD and HD video using 10-bit values, but at file sizes up to 33% smaller than uncompressed SD files and 90% smaller than uncompressed HD files. This allows us to take advantage of the improved image quality 10-bit video offers, without totally overloading our hard drives with massive files.
Here are some general rules you can use:
Note: Frame rate and image size will impact file size, these estimates assume worst case. Apple indicates under “normal conditions” we should expect file sizes about 30% smaller than my numbers.
As video editors we are constantly balancing image quality with file size. With ProRes, we have another tool we can use to help us in this process. While no one codec meets all possible needs, ProRes deserves to be seriously considered.
5 Responses to Why Video Bit Depth Matters
I just found out today that practically 100% of monitors and TVs Display in 8 bit color. I own a Blackmagic Ursa mini 4.6k and have been bought into the idea of a higher bit depth for years, but this jars me. Why in the world does 12 bit matter if in the end, we will only see 8 bits of color? (And because I’m on a mac and don’t have 10 bit monitoring available- I’m editing in 8 bit)
Kim:
You are correct, mostly, but looking at this the wrong way.
“Why, oh Why, should I consider HD video when 100% of the TV sets in the world only display standard-definition?”
The situation is very similar. HDR requires new TV sets, along with new hardware and workflows in both production and post. But once you see well-shot HDR material, it is very hard to go back.
Also, just so you know, you can capture and edit up to 16-bit material on a Mac, but you can’t – yet – display it. Both FCP and Premiere fully support HDR material.
Larry
“8-bit video files are smaller than 10-bit, however, color fidelity can suffer”
As a general rule that works, even more for uncompressed files but for compressed files how much can a file size can differ from using 8-bit and 10-bit when both have the same chroma subsampling, codec and compression ratio.
For instance, Canon has a 8-bit 422 H.264 Intraframe codec for their XC10/15 with 305mbps, for their higher end cameras they have the same codec but with 10-bit color depth. I’m not sure if they also change the compression ratio but their 10-bit 422 files have a bitrate of 410mbps.
Should I expect about 33% increase even for other Intraframe codecs when using 10-bit?
The tricky part is how each codec compression works, right? An Interframe codec should work differently and I guess that the file size difference will decrease between 8-bit 422 and 10-bit 422, is that correct?
It’s kind of hard to gather parameters for 8-bit/10-bit, 420/422 and Intra/Inter because most files are either 10-bit 422 Intra or 8-bit 420 Inter, I wanted to isolate and understand how each of the 3 factors affect the file size under the same quality.
Interframe seems to be about 2x-3x smaller than its Intraframe counterpart for H.264 with similar quality. But while I’m guessing that the difference between 10-bit and 8-bit varies differently between Inter and Intra, I don’t know by how much it would differ.
Supposing it’s the same codec and a 420 file is 100MB, how much bigger the 422 file will be? In theory you have double the amount of color data per sample, but since it’s compressed how much bigger would it be for an Intraframe codec compared to an Interframe codec?
Thanks!
Renato:
These are all interesting questions, but it requires someone who understands the math behind compression more than I do to answer them.
Larry
You can calculate compression ratio by taking the uncompressed variation of an image’s bit rate and dividing it by the compressed codec variation. To be clearer an example would be to calculate the compression ratio of (10-Bit) ProRes 422 LT at 1920x1080p29.97 you first need to determine that the bit rate of that is 14.3MB/s (for mbps just multiply by 8), now you look at Uncompressed 10-Bit 4:2:2 (YUV) 1920x1080p29.97 and determine it has a bit rate of 165.7MB/s. 165.7 / 14.3 = 11.5874 which corresponds to Apple’s claim of about a 12:1 compression ratio for ProRes LT at 1080p29.97. I HIGHLY SUGGEST the AJA Data Calc app for iOS. The same method can be used for 10-Bit 4:4:4 (RGB), ProRes 422 HQ, ProRes 4444 XQ, etc. and to a certain extent other codecs. This may not answer your question fully but it is a good starting point.
-Nate