Problems with ProRes

I have a friend my kids call Surfing Jono. He ribs me occasionally on a mis-perceived bias towards the Canon DSLR ecosystem. I’ve given up reminding him that my glass is EF so Canon is a logical choice. Same for ProRes; my editing suite of preference is genetically bound to ProRes. For a balanced approach, everything about ProRes must be considered… 

Problem #1 – Bad Headers

The first problem is currently not the most prevalent: incorrect information in the ProRes compressed frame header.  When compressed with Apple’s codec, or other well implemented ProRes codecs, the information in the header is correct.  Some open source implementations play fast and loose, often just putting in default parameters that have no relationship to the original material or how it was converted.  Even if the header info makes sense, it is not a guarantee that that was how the conversion was actually done.  There is nothing that can be done for these files, other than correction in post by eye.

Problem #2 – The ‘colr’ Atom

Apple added the colr atom to the MOV specification to specify the same three parameters (primaries/transfer/matrix) for conversions ProRes specifies for codecs that don’t have that information specified.  If this atom exists in the MOV file, and it matches the settings in the ProRes header, then there is no problem.  If, however, the information in the colr atom is different than in the header, it will override the ProRes header and result in bad color and shifts.

Problem #3 – Decoders Ignore The Information

All the information in the world is pointless if it is not used.  Decoding (and encoding) ProRes properly requires that all the cases are tested and working.  While 90% of the cases are covered by simple REC.709 and CCIR 601 conversions, it is the corner cases that will show which software can truly be trusted.

Problem #4 – Apple QuickTime SDK/API

Apple’s QuickTime libraries under Windows and OS-X ARE capable of properly decoding ProRes, but this is not what they do by default.  By default a simple RGB conversion is used, or possibly a correct/incorrect conversion based on the colr atom, depending on the file.  The QuickTime API is end of life and no longer being developed (AVFoundation et al taking over on Mac OS-X, nothing on Windows).  The best way to use this access method is to decode to v210/v410, get the conversion information and then do the color transforms yourself.

Problem #5 – QuickTime Player (especially on Windows)

QuickTime Player is not to be trusted.  Period.  On Windows, with ProRes, it is actually always wrong, using a 1.8 gamma when a 2.2 display gamma is necessary.  This is true no matter what the ProRes header says or any colr atoms.  Interestingly, you can get the correct gamma briefly with QuickTime Player on Windows:  Load 2 ProRes MOVs and switch between them:  The one that does not have focus will have the correct gamma!  Useless, but interesting.

With QuickTime X on OS-X, there are less playback issues than Windows, but when you export ProRes it adds a strange red hue to the video.  The workaround is to post install QuickTime 7 and use that instead.