This test started out to check color fidelity with Apple ProRes and The Foundry products like Nuke and Hiero. We knew from earlier that results wouldn’t be ideal.
Later we expanded the test to other video applications and encoding software to see what that would give us. The outcome was quite disturbing. A format most people believe to be stable in terms of color turns out to be not so “Pro” at all.
The problem is that QuickTime YCbCr files being written by one application needs to be interpreted correctly by another. This is easier said than done. In QuickTime the API uses flags embedded in the movie to determine what color space and transfer function the movie is encoded with and so how to convert it to RGB. However not all applications or hardware that write QuickTime correctly set these flags – or even set them at all – so the API has to make its best guess. Additionally the Colorsync profile of what QuickTime thinks is the target display device may also come into play. Add to that problems related to OS platforms and codec bugs. And on Linux we have everything going through FFmpeg.
There may also be multiple QuickTime decompressors registered on your system (software vendors sometimes roll their own versions) which will decompress the same format but offer different results.
And now with Apple moving over to Quicktime I/O through AV Foundation who knows what glitches that will introduce?
So in other words this is a mess that is really hard to stay clear of and all the variables in this mix makes it impossible to guarantee any kind of color consistency. The only way to do that is to test your pipeline first. See image one.
Our test was done in the following way: a TIFF Color bar was used as source. This file was encoded to Apple ProRes in two sizes HD (1920×1080) and HalfHD (960×540). Two flavors of ProRes were used, 422HQ and 4444, so 4 files in total for each application. All ProRes files were then imported and compared to the original TIFF source. If there were a color shift this was marked in red in the test chart (the shift could differ in appearance but that is not explored further in this test). If the file matched it was marked green.
Most files (with a few exceptions) were encoded and read on the same system: a MacbookPro and OSX 10.6.8.
You should also note there are quite a few parameters to set during import/export (for the most part they have been left at default) so you could possibly get other results adjusting them. So don’t read this test as the law but more a pointer to where things could go wrong. If this test were to be expanded to other OS platforms and QuickTime versions you would probably find even more errors. However we think the chart below, more than enough, shows how easy it is to get bitten by QuickTime.
If you are concerned with color staying the same you should perhaps consider using another format (file sequences) or at the very least test your files and workflow first.
The problem is that you quite often don’t have control over where your files will end up. A tip is to provide a color bar with known values with your main sequence, that way it is possible to sample and measure if anything has happened to your files.
So to sum this up we think you should take the “Pro” in ProRes with a pinch of salt. Good luck.
Note: There were previously a mention in the PDF-chart that some files were encoded with BBC’s version of FFmpeg. This information was not correct. The encoder used was FFmbc. Sorry for any confusion.