ProRes itself is very well defined, and should be completely gamma/color shift free in the YCbCr domain at 10 bits per component.  The transform to YCbCr from RGB can be specified within the compressed frame, and this same specification can be used to properly convert YCbCr to RGB.  With both 4:2:2 and 4:4:4 variants and the metadata/compatibility of the MOV container, ProRes should be an ideal format for post production.  This article explores why it often isn't.

ProRes Internal Color Format

The gamma/color shift problems of ProRes are well known, but the cause is not always clear. 

Internally ProRes is a YCbCr 4:2:2 or 4:4:4 frame with 10 bits per component, or Apple nomenclature v210 (YCbCr 10 bit 4:2:2) and v410 (YCbCr 10 bit 4:4:4). For SD it would normally be CCIR 601, otherwise it would normally be REC 709. Fortunately, the exact relationship between the YCbCr and RGB is actually specified in the header of the ProRes frame. The header includes the following elements:

• Width
• Height
• Chrominance (4:2:2 or 4:4:4)
• Interlaced (with top field marker) or progressive flags
• Color primaries
  • ITU-R BT.709-2, SMPTE 274M-1995, and SMPTE 296M-1997
    white x = 0.3127 y = 0.3290 (CIE III. D65)
    red x=0.640 y = 0.330
    green x = 0.300 y = 0.600
    blue x = 0.150 y = 0.060
  • SMPTE RP 145-1993, SMPTE170M-1994, 293M-1996, 240M-1995, and SMPTE 274M-1995
    white x = 0.3127 y = 0.3290 (CIE III. D65)
    red x = 0.64 y = 0.33
    green x = 0.29 y = 0.60
    blue x = 0.15 y = 0.06
  • SMPTE 240M-1995
  • ITU-R BT601-6 625 / ITU-R BT1358 625 / ITU-R BT1700 625 PAL / SECAM
  • ITU-R BT601-6 525 / ITU-R BT1358 525 / ITU-R BT1700 NTSC
• Transfer functions
  • ITU-R BT.709-2, SMPTE 274M-1995, 296M-1997, 293M-1996, 170M-1994
  • SMPTE 240M-1995 and 274M-1995
  • ITU-R BT470M / ITU-R BT1700 625 PAL & SECAM
  • ITU-R BT470BG
• Color matrix
  • ITU-R BT.709-2 (1125/60/2:1 only), SMPTE 274M-1995, 296M-1997
  • ITU-R BT601-6 625 / ITU-R BT1358 625 / ITU-R BT1700 625 PAL / SECAM
  • ITU-R BT601-6 525 / ITU-R BT1358 525 / ITU-R BT1700 NTSC
  • SMPTE 240M-1995, 274M-1995
• Original color format (source color format)

Based on this information it is simple to encode, decode, convert and display the exact colors at all points in compression and decompression. If this is what all software used to set up conversion, there would be no shifts.

ProRes Problems/Issues

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 provides 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 be trusted.

Problem #4 - Apple QuickTime SDK/API

Apple's QuickTime libraries under Windows and macOS 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 macOS, 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 macOS, there are fewer 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.

Even More Information:

An excellent discussion of just the gamma problem in QuickTime:  Vitrolite The QuickTime Gamma Bug

Another interesting investigation of ProRes issues:  Investigating ProRes

Adobe After Effects specific gamma fix for macOS:  After Effects/FCP Round Trip

Adobe CS4 ProRes fix:  ProRes CS4 Fix

Adobe CS5 and greater ProRes fix:  ProRes CS5+ Fix

Quality comparison of DNxHD, ProRes, FMPEG, CineForm:  Codec Quality

Colr atom discussion:  nuke list

Some Apple information which should not be followed:  Apple Gamma Shifting 

Drastic ProRes Products:

To play ProRes files to your VGA/DVI with the correct color conversions, try videoQC 

To view ProRes files to HD-SDI with AJA/Bluefish444/Blackmagic, try videoQC Pro

To export ProRes from Adobe/Apple/Avid/Assimilate on Windows/macOS, try MediaReactor Workstation