June 2016: From time to time it makes sense to check what changes with the color handling of compressed file in OSX…again and again as with El Capitan new color profiles like REC.2020, ACES CG and Display P3 were added to the system. At this time I test on OS X 10.11.5 with FFMpeg 3.0.2, Nuke 10.0v2, Resolve 12.5, VLC 2.2.4, DJView, Quicktime Player X (10.4) and FCPX (10.2.3 together with Motion 5.2.3 and Compressor 4.2.2)

As always I use my own color chart (100 frames sequence with color noise) in different file formats and the Digital Color Meter from OSX  to check results.

The goal is to encode files from a Tiff 16-Bit image sequence to formats like ProRes 444, ProRes422HQ and MP4 and maintain the same color&luma values as seen above (you can measure them in Nuke or directly with the “Digital Color Meter” set to sRGB. For more information please check the older Compression Series pages.

I need the following workflow in my day to day business:

• I have ProRes files from different cameras. (PR444 or PR422HQ from ARRI Alexa or converted camera RAW files from Resolve or Nuke)
• And image sequences such as JPG, TIFF, DPX (in Log Formats or sRGB) and EXR.
• These files need to converted/compressed to ProRes for further steps or smaller files like MP4`s for client review.
• The goal is to keep the colors/luma values consistent in every step in the data of the files!
• Sadly it is nearly impossible to have or keep the important metadata in the files. That results in measurable color/luma shifts in Quicktime Player X & FCPX, Nuke and VLC.

What works:

• Open a TIFF file in Preview and check the color values (with Digital Color Meter / sRGB). All colors match exactly.
• Take the 16-Bit TIFF image sequence into Motion 5 and compress/export the 100 frames to a PRORES 444 and PR422HQ directly from Motion. This file looks&measures exactly the same values in Quicktime Player X and FCPX …but are values actually okay?

What does not work:

• VLC cannot display this PR444 file, but the PR422HQ file it can, but nearly all values are off.
• Nuke imports the files with 1.8 and 2.2 gamma, by setting the colorspace to sRGB both files look identical apart from the 4:4:4 and 4:2:2 compression, but the values are also all off and not matching the superimposed values.
• And even opening the files in Compressor and check the preview window, show all values off.

To sum up: The TIFF (sRGB) in preview, Motion, FCPX, Compressor and Nuke show all the right values.
The compressed PR444 and PR422HQ files only inside FCPX, Motion and Quicktime Player X. Compressor, VLC and Nuke are showing different results.

---

Nuke`s perspective: I created the color bars anyway initially in Nuke so why not starting from there.

• Open the EXR32 image sequence and create two write nodes as PR444, PR422HQ and .H264 (MPEG-4-Video is not supported in the NON-Commercial version of Nuke and anyway direct exports to this kinds of formats doesn’t make much sense to me on a daily basis).
• The Nuke default gamma of 1.8 for PR444 and 2.2 for PR422HQ and .H264 seem weird so I change them to sRGB. 
• Inside Nuke it doesn’t matter of course, but the standard OSX programs to view ProRes files won’t show me the right values anyway, not Quicktime Player X, nor in FCPX but VLC, DJView and Compressor! VLC let me measure the exact values only if I export the PR444 from Nuke with sRGB. So I stick with that.

Summary: Although you can assume Nuke is writing proper ProRes files, but only VLC and Compressor are showing the right results visible on the screen. Quicktime Player X, Motion and FCPX are doing something internally that alters the values on the  screen.