Back To Listings RSS Print

ProRes: A Closer Look

An in-depth examination of ProRes

By Gary Adcock | March 03, 2009

The largest issue in post production is maintaining the highest quality for compositing, graphics, effects and delivery; whether that content is used in broadcast, theatrical or direct to DVD release.

Camera native codecs are amazing for their ability to capture light at the highest quality, yet this "native" camera data was never meant to work directly within the editing process, only within the manufacturers proprietary camera hardware.

This intermediate codec, called ProRes, was designed specifically to maintain full colorspace and 10bit workflow throughout the post process allowing Final Cut Pro to finally take its place as a truly professional editing platform.

Topics


  • What is ProRes

  • Properties

  • ProRes Data Rate and Compression Ratio

  • ProRes Standard vs. HQ

  • Scalar Playback and Performance Enhancement

  • 8bit vs. 10bit

  • Compressed vs. Uncompressed workflows

  • Advantages with HDV content

  • Hardware support for ProRes

  • Acknowledgements

  • Tech Notes


Recently, when asked to take a hard look at Apple's ProRes codec, I hesitated. I was a big fan of working with Panasonic's DVCProHD in Final Cut Pro, converting virtually every tape format that came to me into this camera codec.

I understand the issues of working with a camera's native 8bit codecs, where manufacturers custom design the best conversion possible in hardware, allowing 8bits of gray per channel to use every one of the 256 levels of gray possible. While useful for the immediacy, outside of customized solutions the results can often be very different when used for editing. Whenever motion graphics or compositing is needed, these 8 bit camera native codecs do not maintain non-camera materials or composites at optimum quality.

It was the release of AJA's IoHD that prompted me to follow up on what the ProRes codec is, how it works and what the advantages are to my workflow. I found that while DVCProHD and Long GOP Mpeg files can offer exceptional quality for acquisition, their use in post could be a detriment to achieving high quality work.

What is ProRes?
ProRes was designed to be the highest quality intermediate codec to keep the postproduction workflow data at 10bit quality, yet at a low enough bandwidth to be usable for the majority of FCP users. ProRes is currently available only on Apple OSX platform and requires components from the FCS2 suite to be installed on your computer, either from FCP or the Qmaster rendering engine.

The process of using intermediate codecs in postproduction is not uncommon. In fact, they have been used some form or another since the start of non-linear editing. The advent of IEEE 1394 "Firewire" specification allowed us to see and natively edit the information as the camera recorded it. The use of the DV codec is synonymous with the burgeoning growth of video as an artistic medium, just as P2 and HDV guided FCP users into HDTV. However, with many complaining about the quality of their imagery or the need for constant rendering in the HDV codec, widely used in Prosumer and Consumer HD camcorders, something was needed.


ProRes solves many of the issues that haunt these formats, albeit at a cost of an Intel Mac and somewhat greater needs for attached storage because of ProRes's lower compression level and the resulting larger file sizes.

ProRes Properties
Apple's ProRes codec is a 10bit, full raster (i.e.: full frame geometry) discrete cosine transform (DCT) based compression algorithm that allows for frame geometries covering all of the standard HD and SD formats, assorted smaller geometries for proxy-based editing and playback in Final Cut Server. In addition the DCI (Digital Cinema Initiative) specific outputs for digital cinema delivery at 2048 x 1080 and standard 2K digital intermediate frame geometries of 2048 x 1566 and 2048 x 1152 are also supported.

image

ProRes currently comes in 2 levels of compression. Originally called HQ (high quality) and SQ (standard quality) in Apple's documentation, the 220Mbits version is now called HQ, and the lower bandwidth 145Mbits version is just now referred to as ProRes.

For comparison on what this means, Sony's HDCam camera format is approximately 136Mbits, while Panasonic's DVCPROHD is listed as 100Mbits. Even delivery formats like Panasonic's D5 mastering format is only slightly less compressed than ProResHQ at 250Mbits for 1080 23.98sF, while HDCam SR's mastering format is usually recorded in 4:4:4: Dual Link mode at 440Mbit (880Mbits is now available).

image

ProRes is considered a variable bit rate codec, where the amount of compression varies based on frame rate, interframe differences and motion interpolation. Much like h.264, it operates as a DCT scalar codec, with the ability for full frame playback previews from ½ or ¼ size frame data, lowering the data throughput while maintaining high image quality. This functionality allows the user advantages in playback of additional tracks of video, higher quality previews and increased RT functionality. However Apple errantly allows for ProRes to support native compressed aspect ratios found in DVCProHD and HDV when converting in software. While this sounds like a great idea, it causes severe issues when applications outside of the FCS Studio package are part of the ProRes workflow.

Data Rate / Compression Ratio



image
Waveform and Vectorscope images indicating the difference between the original uncompressed 10bit image and the first generation conversion to DVCPROHD.


As previously stated, the specifications for compression are for 220Mbps for the HQ version and 145Mbps on the standard version. The data rates for Standard Definition geometries are 63Mbps and 42Mbps respectively, allowing ProRes to be more efficient in SD workflows than any other 10bit codec.

The "Bit Rate" refers to average amount of data that is transferred or processed per second. ProRes, being a variable bit rate (VBR) codec, allows the more complex parts of the video to be encoded at a higher bit depth for more detail, while the less complex areas are encoded at a lower bit depth, thereby allowing for overall smaller file sizes. ProRes is approximately a 5.5:1 compression ratio at its maximum and slightly more than 3:1 at its minimum compression level for SD content.

This means that despite the quality there is still a fair amount of compression being done on each file. I initially loved DVCProHD, but quickly found that if any color correction or motion graphics were to be part of the edit process, material processed with DVCProHD would fail my quality standards. Because of this, many facilities have endured postproduction using compressed formats despite the pantheon of postproduction issues compression brought.

Standard vs. HQ versions


image
Waveform and Vectorscope images indicating the difference between the same original uncompressed 10bit image and the first generation conversion to ProResHQ.


In trying to discern the differences between the Standard and HQ versions of ProRes on live capture, I was hard-pressed to see any differences between the 2 compression levels on live content except under very close inspection. While I could see differences on my Leader 5800 WFM monitor, it was only when viewing was set to a 5X magnification. Seeing the differences in compression with the naked eye was difficult despite the fact that I was viewing the images split-screen on a Cine-tal reference monitor.

The only intermediate format that has ever maintained true mastering quality for me has been 10bit uncompressed. I could reprocess, capture and convert imagery endlessly when working with uncompressed originals. I was able to handle the files over and over again without fear of loosing data. With ProResHQ I found nearly that same quality at about 1/5th the file size and throughput needed for a standard uncompressed 10bit HD workflow.

While re-compressing the video in software (or with content captured in the standard version) the image started to degrade after about 10 round trips through the decompression / recompression cycle. In the hardware solutions (the IoHD and Kona 3) I found something very different. I could not see any noticeable differences between the 1st generation ProResHQ file and the 50th version after being run thru AJA's hardware. While that is more generations of capture and playback that one file should EVER need, I was stunned that even in the process of capture the files held up better than I ever imagined, certainly as well as staying uncompressed could give, not to mention considerably less storage is required for the ProRes compressed files.

While comparing the software-converted files I noticed a couple of interesting issues. My testing found that when the camera native codecs (DVCPROHD, HDV or SxS) were converted to ProRes in software they universally ran better when using the Standard version of ProRes rather than choosing the HQ version. This was most noticeable on HDV and DVCProHD originals that seem to consistently stutter or choke when playing back software-converted HQ content from compressed camera originals. The best explanation I have is ProRes HQ wants to fill in 10bits of information from the 8bit native compressed files. Due to the massive amount of processing needed to handle this conversion, it overwhelmed most systems on playback, whereas the standard version of ProRes is not trying to over-sample the 8bit data but rather it allows that data to move freely within the larger 10bit color space, easing the load on the CPU when processing the video for output.

One thing to note, the worst software conversion was using Final Cut Pro's (v6.0x) Media Manager to handle the process. Not once did MM ever do the conversion in a manner I deemed correct. The most glaring example of this error was when P2 or native HDV files were converted inside Media Manager, they would retain the "native" aspect ratio of the original content even after conversion to ProRes. This caused applications like Apple's Shake and Adobe's After Effects to have playback errors in the software-converted versions due to the "incorrect" aspect ratio of the conversion, despite the fact the files play fine within the Final Cut Studio apps.

image
The Kona 3 Control Panel indicating that Final Cut Pro is
receiving sending less that 100% of the full frame


The best conversions were done in Compressor (#1 overall) or making the conversions one at a time in the QuickTime player. Both of these methods produced working ProRes files from the camera's native codec in the correct aspect ratio every time.


Page 1 of 3 pages 1 2 3 Next »

Share This

Back To Listings RSS Print

Get articles like this in your inbox: Sign Up

Comments

wsmith: | March, 04, 2009

Mr. Adcock,

Thank you for this highly informative review of proRes. I’m on Windows and have used Cineform’s prospect HD, once on big corporate project, with similar great satisfaction. Many of the points you make regarding the advantages of a 10bit workflow are the same.

Not having used ProRes, I was under the mistaken impression that it, like Cineform, used a wavelet based compression scheme.

Cineform, as you probably know, is capable of allowing work in uncompressed, 100Mbit, or various lower quality data rates.

CIneform now has support for AJA Xena 2K for timeline playback and scrubbing, working on it for Blackmagic, export to ProRes, etc.

Insofar as Cineform is compatible with Mac, might you consider taking a similarly indepth look at it?

Is Cineform’s wavelet better than ProRes’s DCT?

Is Cineform’s 100Mbit as good or better than ProRes’s HQ highest bit rate mode?

Does it hold up as well under a multi-generational workflow? 

I’m considering taking on a partner on the Mac side and Cineform is obviously the only choice due to the cross-platform compatibility. I could switch to Mac but…

Thanks again!

wsmith

Mike Curtis: | March, 09, 2009

FYI, ProRes is available on Windows, albeit in read only format - so if you capture on Mac, it can be read on Windows, you just can’t write to the ProRes codec/s from Windows. But it does open up some workflows, especially for compositing etc. of backgrounds, reference material, etc.

-mike

PS - AFAIK, ProRes is DCT not wavelet

IEBA: | March, 10, 2009

Phenomenal overview.

I suspected something was up with (HQ) when my MacBook seemed to work harder with the “less compressed” footage than with ProRes. Thanks for uncovering and confirming this effect.

Your testing of concatenation errors also gives me more confidence in using ProRes for our PBS series.

IEBA: | March, 10, 2009

Now if you could _write_ ProRes on a PC (like in Premiere) then there’d be a whole lot more use!

Gary Adcock: | March, 16, 2009

Mr Smith

Sorry for the delay in my reply.

While I was in LA for HDExpo, I met with David Taylor, head of Cineform and working towards testing all of the 10bit compressed codecs after NAB, I am planning on taking a look at Sheer, AVC-I and Cineform as part of this test.

I am also hoping that a couple of the things coming at NAB will also be available cross platform as requested.


IEBA- thank you, very kind words indeed.


gary

kaaf2009: | October, 08, 2009

Great article Gary.

The issue you raised (below) about standard vs. HQ ProRes 422 is interesting.  The standard seemed better after conversion, but what about after being manipulated in Color?

Once it is manipulated in 10 bit color space wouldn’t that change everything based on your theory that it’s left in 8-bit space after conversion?  That is to say, once you make one adjustment in 10-bit space aren’t you now dealing with a 10-bit image and if so, how do the two versions of the codec compare after that?


from the article:

My testing found that when the camera native codecs (DVCPROHD, HDV or SxS) were converted to ProRes in software they universally ran better when using the Standard version of ProRes rather than choosing the HQ version.

Dan: | October, 30, 2009

What a great article. 

Answered almost every question I’ve had about ProRes.  Just one requested clarification.  When mentioning software conversion options (with caveats), did you mean for example, HDV material captured to disc via the QT HDV codec that is then transcoded (exported) to non HQ ProRes422?  Would that be an reasonable compromise alternative to a direct hardware-based capture/conversion?

The reason I ask is that I currently lack the budget for a hardware capture/conversion solution so it would be great to use the old-fashioned HDV capture approach for the time being.

Thanks

Gary Adcock: | November, 02, 2009

Sorry people- I have been working on the Update for this article and not had a chance to responds

Kaaf2009 goes first.

The standard seemed better after conversion, but what about after being manipulated in Color?
Once it is manipulated in 10 bit color space wouldn’t that change everything based on your theory that it’s left in 8-bit space after conversion?

Once the conversion happens the file is now 10 bit, so the pass thru Color does not change anything, other than to completely render out the file with all 1024 levels.

The entire point of rendering to ProRes standard was reduce the strain on your CPU when handling the file during Output. Once the files have been re-rendered by Color- the file will actually playback even smoother since your computer will no longer be compensating for the 8bit file in a 10bit container, but be a full 10bit via the render in Color- easing the load on the CPU even more.

Make sense?

Gary Adcock: | November, 02, 2009

Dan.

I am try to wrap my head around your statement

When mentioning software conversion options (with caveats), did you mean for example, HDV material captured to disc via the QT HDV codec that is then transcoded (exported) to non HQ ProRes422?

Software conversion is just that, any conversion done from any native camera codec ( HDV, AVC, EX AVCHD or DVCProHD) where the camera generated as a file format on a card or transferred via FW or USB and then is converted to ProRes using any software application( FCP, Compressor, QT player)

I do not recommend conversion to another Apple codec prior to the conversion to ProRes.

does this answer the question?

kaaf2009: | November, 02, 2009

I think I do understand now.  When you said “ran better” below, you’re not referring to the image quality.  You just mean it was less taxing on the CPU to playback right? 

I’ve run across some articles which gave the impression that ProRes 145 actually produces better image quality (coming from HDV) than the HQ version.  Maybe they were all just referring to performance and not image quality.

When mixing formats one obviously wants to choose
the best codec they can handle (presumably HQ), but these reports of HQ having trouble with HDV
gave me pause.


from the article:

My testing found that when the camera native codecs (DVCPROHD, HDV or SxS) were converted to ProRes in software they universally ran better when using the Standard version of ProRes rather than choosing the HQ version.

Gary Adcock: | November, 04, 2009

When you said “ran better” below, you’re not referring to the image quality.  You just mean it was less taxing on the CPU to playback right?

Yes, “run” would indicate something regarding performance,  not the image “look” or “quality”.

I’ve run across some articles which gave the impression that ProRes 145 actually produces better image quality (coming from HDV) than the HQ version.  Maybe they were all just referring to performance and not image quality.

No codec will make your content look better, in the case of HDV if you are talking about converting content AFTER it was captured, the original file is 8 bit with a 4:2:0 color space.  Working in ProRes will allow any thing done in post to maintain quality without additional loss of color or detail. 

Working in ProRes will allow you to work faster in Final Cut, at higher quality, with little or no additional lost of detail or color.

Users IMHO have nothing to gain from a software conversion from a highly compressed compressed camera codec to ProRes HQ, especially when the Standard version works just as well with that type of file as the HQ version does without the need for ±50% more CPU power to handle the same file.

The issue has to do with how much processing is done. ProRes has to be compressed then decompressed for playback. It is that CPU heavy processing required during decompression of the HQ format from files that originated as 8bit being processed during playback that people are referring to.

wsmith: | November, 04, 2009

Mr. Adcock,

Your latest post on this subject does not make any sense to me and seems to contradict the thrust of your article.

There certainly is a big benefit in transcoding to ProRes or - more so - from AVCHD to ProRes, because of AVCHD’s comparatively heavier compression.

ProRes completely transcodes a long-GOP source, taxing on all but the fastest systems due to costant de-compression/re-compression, to a CODEC that is far easier to edit on a given system.

Transcoding also converts an 8 bit source to 10 bit, conferring a big advantages in post by expanding the color space. We are referring to “I/O precision” and a 10bit file can be withstand more compression and decompression without degrading as much, especially when compositing graphics, for example.

It’s been quite a while since I read your article but I believe that you made an effective case for ProRes but perhaps not explicitely expounding on those specific points.

Your last sentence in your latest response:

“It is that CPU heavy processing required during decompression of the HQ format from files that originated as 8bit being processed during playback that people are referring to.”

This is not correct. A prime purpose of transcoding a file to ProRes is to make it easier to edit. Once transcoded it is easier to playback (and edit) and is, in fact a completely separate file and doesn’t care if the original file has been dumped into the void. After post you can then take the ProRes file and transcode to some other file for delivery, including back to HDV or AVCHD, with no discernable quality hit.   

Personally, I don’t use ProRes but I do use use Cineform and I understand fully how it and why it works and I know that ProRes works on the same underlying principles.

Please login or register to comment