in ACES with Resolve & Nuke and review the results with Quicktime Player X & VLC and a bit FCPX/Compressor.
Trying to bridge a gap to the outdated “Compression Series” articles and the not so outdated “Compression Reboot” article.
At the time I was working on my new ACES Colorbars_v10 I was speaking with a colleague who just recently jumped into ACES. And he found out that writing out ProRes files from Resolve result in different metadata tags depending on the ODT.
The following tests are made with Resolve 16.2, Nuke 12.1v2, Final Cut ProX 10.4.8, VLC 3.0.8 and ACES 1.1 (04/2020)
In my working environment I am used to judge the work with Autodesk Flame or DaVinci Resolve on a HD or UHD reference monitor from Sony before sending out client master copies. At the moment both reference monitor types are showing Rec.709. The whole workflow is based on Rec.709. Although a big chunk of work is not airing on TV anymore but ending up in social media which is more sRGB than Rec.709. A lot of the mobile screens gamut range from sRGB to P3 (both with a “sRGB gamma of approx. 2.2”). HD Rec.709 content is viewed with a gamma of 2.4.
Only a small portion of the projects that I work on are kept in ACES until the very end. Usually they end up as Rec.709 ProRes4444 master files from Flame where the material is already imported as display referred DPX files from Resolve.
If a project would be kept in ACES in Resolve for grading until the very end (which has its problems with titles and client logo endings, corner logos and so) I could actually choose the right ODT for each delivery. Files for social media could be viewed and mastered in sRGB and a TV commercial in Rec.709.
I think this is the way it is intended.
So I setup a UHD Resolve project in ACES and loaded my new ACES “Color Bars v10” into a timeline and exported each a ProRes 4444 with both ODTs. From there I checked the files in the QuicktimeX and the VLC player on MacOS. As a second step I converted the ProRes files to MP4 (and HEVC) with Apple Compressor.
I am working for over two decades now with Flame and although I prefer to do composing work in Nuke – I never want to miss flame for conform and online work and the flexibility for the deliverables. Here I see a biggest weakness of Resolve. Is is very inflexible in the deliver tab. In ACES you still need to to the projects settings to change the ODT and so you cannot queue a batch of exports with different or no ODT selected. And don’t get me started from loosing even the reel name of a camera clip when you export it as ACES EXR files…
Funny or not so funny note – the title that I added in Resolve appears display white so it has actually a scene linear value of over 16 with the selected ODT’s – that’s very bright for a title indeed 🙂
The ProRes 4444 file that is exported with the sRGB ODT has a color tag of (1-13-1) whereas the file with the Rec.709 ODT shows (1-2-1).
The numbers stand for primaries-transfer function-matrix(color).
The BBC developed a tool on GitHub called qtff-parameter-editor (QuickTime File Format and ProRes Video Parameter Editing). You can find it here: (www.github.com/bbc/qtff-parameter-editor)
On this page I found the list of formats behind the numbers – these are actually more updated than the apple developer pages that I found.
Rec.709:
1=ITU-R BT.709 – 2=Unspecified – 1=ITU-R BT.709-2
sRGB:
1=ITU-R BT.709 – 13=IEC 61966-2.1 (sRGB) – 1=ITU-R BT.709-2
Viewing the files in Quicktime Player X (10.5)
If you open both ProRes files with the Quicktime Player X and switch between the two files – they look nearly identical. The only difference you can make out by eye are in the dark shadows in the last row of the chart with values up to 0.06 and the next row up until the values of 0.6 in ACEScg (check it below no on the first video). Although the files are exported with two different ODT’s, the Quicktime Player X uses the metadata and ColorSync inside of MacOS to compensate for the differences and shows both files as sRGB, because my iMac 27″ (2013) screen is (very close to) sRGB.
Is this a bug or a feature?
Use the command “windows/combine all windows” in the Quicktime Player X and hit CTRL-SHIFT-TAB to flip through the opened files.
Next I open the apple tool Digital Color Meter (default is set to sRGB on my 2013 iMac) and hover over the patches of the sRGB ODT file – most of the values are matching, some with little rounding errors.
But when I compare the values in the Rec.709 ODT file the measured numbers are more off from the ones printed on the patches all across the color bars.
A quick comparison to the results when writing out ProRes4444 files from Nuke 12. The file info in quicktime player X shows (1-1-1), means ITU-R BT.709 for all three values. These are also the same values that ARRI is writing in their LogC ProRes4444 camera files for example. The Digital Color Meter shows the values are way off nearly everywhere in the chart. And visually there are a more differences visible between the sRGB and Rec.709 ODT files.
This begs the questions – this means the Quicktime Player X is reading the color metadata tags and compensate the for the display that you use to view a file that was not meant to be shown on your display – e.g. Rec.709 on a sRGB display? If so, why is the viewer from FCPX is not doing that as well? The viewer shows visually the same difference that I see with the files written out by Nuke. Does it mean inside FCPX the color tags are not being used? It would make sense if you put the viewer on a separate video Rec.709 monitor – I find this confusing. To make things better or worse I switched the video player app and did some more tests.
Viewing the files in VLC (3.0.8) – in a better way?
I personally don’t like VLC that much, I find it too distracting when reviewing media on it – but it supports now way more formats than the Quicktime Player X.
Starting off with the ProRes files from Resolve. There is a visual difference between the file written out with the ODT Rec.709 and sRGB. And the Media-Info in VLC shows the color metadata.
The Digital Color Meter shows exactly the values that are overlaid in the patches in both files for Rec.709 and sRGB. This is what I always wanted – seeing the same values that I measured on the screen before.
Next are the ProRes files from Nuke. There is a visual difference between the file written out with the ODT Rec.709 and sRGB. And the Media-Info in VLC shows the color metadata tags which are in this case the same for both files. Nuke does not write the proper metadata into the files depending on the ODT you select.
But the Digital Color Meter shows again the same values as the files from Resolve. This means VLC is showing you the encoded metadata in the Media-Info, but doesn’t apply any “color transform” or color profile like the Quicktime Player X does.
So what does this all mean? VLC shows you exactly the color information that is encoded in the files. The Quicktime Player X shows you the color values on your display simulated in a way how they would appear on the display that they are encoded for? And why is the Quicktime Player X is showing you different values when comparing the same file, but inside Final Cut Pro X? If they would be at least the same, but the aren’t. So I don’t get what ColorSync is doing under the hood for you.
Changing the Color Space metadata in FCPX
Final Cut Pro X is a very strong metadata driven tool. And in fact you can overwrite the color space for a file if needed. But no other option is possible than video formats from Rec.601 over Rec.709 to Rec.2020
Using Apple Compressor and everything is different …again
I use Apple Compressor to make smaller MP4 or MV4 files (both as H.264 or HEVC 8Bit with hard acceleration on my MBP2018). So I take the four Apple ProRes files from Resolve and Nuke and compress them to smaller files. As it was already strange that I cannot use anything other than video formats to override the color space metadata tags in FCPX, in Compressor its the same behavior.
All four files end up being tagged as Rec.709 (1-1-1) and all four files showing different results in the Digital Color Meter. It feels like whatever you throw at Compressor which is not originally coming from FCPX – the color metadata tags are forced to be converted to Rec.709. But why? This is not only compressing files, but also depressing me. I don’t get it.