Dolby Vision – Custom ACES SDR to HDR Part 4 – Deliverables And QC

December 24, 2021

In Part 4, learn how to QC and deliver your Dolby Vision HDR and SDR masters, including Video- or Data- level settings for ProRes exports.


Series

Finishing The Dolby Vision Master

If you’ve followed me through this series from the beginning, it’s been quite a journey! From a simple node-based ACES setup to a complex fixed node tree, then an SDR grade. From there – we switched the SDR grade into HDR and made a Dolby Vision version referencing our original SDR creative grade.

Well now, this is the end (of the process, not this series)! The Dolby Vision process is complete, and we need to output and quality-control our work.

Deliverable Files

Dolby Vision requires two things – both an image master that contains the color-graded material and metadata that contains the Dolby Vision analysis and trims. In this example, I’ll be making ProRes 4444 image masters – and exporting the metadata as XML.

Dolby Vision requires both an HDR image master and metadata

These files can then be used by a client or distributor to make final encode for streaming, build IMF packages for distribution, or be used to archive the final product.

Colorspace And Levels Confusion

The two things that confuse people the most about Dolby Vision are colorspace (P3D65 or Rec2020) and data levels (full/data vs legal/video range). The confusion comes from the fact that Dolby Vision image masters can be made using either P3D65 or Rec2020 and output as either full or legal levels!

The right choice depends entirely on the requirement for your deliverables, and the format you are rendering to – but there are best practices that you should know about, which I will go over in this Insight.

Quality Control

The final and possibly most crucial step is quality control. Making sure your outputs are perfect is critical. Remember – you could do the best grade in history but if the delivery is wrong, that’s all the client will ever remember!

Making sure your metadata is correct is just as important as making sure your grade is perfect.

QCing for Dolby Vision is a bit different because you need to check both your image master and the associated metadata together. The image master could be perfect and error-free – but a problem in the metadata could cause playback errors that you never saw when watching your render down.

Putting It All Together

In this Insight – I’m going to walk you through outputting QCing these Dolby Vision deliverables. I’ll also dive into some more advanced workflows for converting colorspaces, and outputting tone-mapped versions. We’ll cover:

  • Outputting image masters and correct colorspace/gamma tagging in a node-based ACES workflow
  • Outputting tone-mapped SDR masters
  • Exporting metadata
  • Converting a P3D65 Dolby Vision Grade to Rec2020, for the image master and XML metadata
  • Validating metadata with Dolby’s professional tools
  • QC checking both the image master and metadata together
  • Guidance for data-level or video-level settings for both image masters and tone mapped outputs

This Insight does make use of the Dolby Vision Professional tools, and the Dolby Vision trim license for DaVinci Resolve. For more information on these products, visit the Dolby Professional site.

To finish out this series, we will also be scheduling a live conference call for members. I’ll be available to answer questions, show examples, and talk through anything related to node-based color management, SDR to HDR workflows, or Dolby Vision finishing!

Until then – leave me any comments or questions below.

Joey

 


Related Flight Path

Member Content

Sorry... the rest of this content is for members only. You'll need to login or sign up to continue (we hope you do!).

Membership options
Member Login

Comments

Homepage Forums Dolby Vision – Custom ACES SDR to HDR Part 4 – Deliverables And QC

Viewing 16 reply threads

    • Chris K
      Guest

      Thanks Joey for all your work on this series so far, its been really helpful.

      One question: Why is your ProRes master of the Rec709 tone-mapped SDR version not tagged Rec709, Gamma 2.4 as opposed to Rec709, Rec709 in the deliver page? Thanks.


    • Willian Aleman
      Guest

      Joey – thanks a lot for this series.

      About the XML: How does someone differentiate between the exported P3D65 and the output Rec.2020 color spaces within the two XML syntax of the original and the modified files?
      They seems to be identical.
      Example, beside the XML file name differences, the date, Resolve two versions used to export the XML, and the Unique ID#, I cannot see where specifically in the syntax is the difference between P3D65, and Rec.2020 as the output color space container. Could you point out the identification of each one within the syntax?

      Once again, thanks a lot for the series. I have learned a lot from it.


    • Joey D’Anna
      Guest

      Thanks Willian! The only difference is in the Color Encoding tag where the primaries are assigned. The actual numbers for the primaries are the ones for rec2020, not P3.


    • Joey D’Anna
      Guest

      That tag doesn’t really actually affect the image at all – just how some players present it. Tagging rec709/rec709 will yield a 1-1-1 NCLC tag, whereas rec709 gamma 2.4 will yield 1-2-1 (which shows up wrong in some players like quicktime)


    • Willian Aleman
      Guest

      Exactly. Something like this is what I was expecting. In your XML files, I cannot see a difference in the Color Encoding syntax between the two files. Please see screenshot below. I might be missing something? I thought the two XML files with different titles were different. They are identical.


    • Joey D’Anna
      Guest

      Hey – I’m not seeing any screenshots? just before 10:00 into the video you can see how i do it – I made a new, 2020 XML from a dummy project, then copy and pasted those values into the duplicate of my original XML. You can verify the difference by running metafier and seeing what color encoding it detects.


    • Willian Aleman
      Guest

      https://uploads.disquscdn.com/images/f029bffe68c852d1be7724db8974cdd558b920a04af7b27c8adc122f06c1d860.png

      Hey Joey – Thanks for the clarification.
      I posted a side by side screenshot of the two XML shown on this insight, where the Encoding>Primary< on the XML files are identical. For some unknown reason, the screenshot has dissappeared. Below is a repost of the screenshot. As you have clarified in the response to my question: the change only happens in the Encoding.
      However, this is not what is seen in the XML files appearing on the video of this insight. And that is what created my confusion and brought my question about it. The Primary in both XML files are identical.

      This video from Dolby Vision further clarified my confusion, “Technical Updates/December 2020” Here Aby —DV Trainer—shows the differences between the two XML when creating different deliverables. Yes. the changes between P3D65 and the Rec.2020 and the XML deliverables occur in the ColorEnconding >Primary<. Accordingly to Dolby Vision on this video, the >MasteringDisplay> syntax is the one that should remain the same when creating different deliverables
      Dolby Vision Video on the topic —Video location TC 40:30+
      https://professional.dolby.com/events/dolby-vision-technical-updates/
      https://uploads.disquscdn.com/images/5e8ae6e673c45ec80dc8fdb44762b4dec6ffa254d88551c87f2bcc4d8a55e402.png


    • Willian Aleman
      Guest

      The screenshot “above” my first paragraph on the previous response is a repost of the screenshot mentioned there. The second screenshot, below, is from DV presentation.


    • Joey D’Anna
      Guest

      Ah I see – you screengrabbed my dummy 2020 XML that I generated to get the correct values for rec2020 primaries. That *should* be identical to the rec2020 xml. it’s the original P3 xml that is different.


    • Willian Aleman
      Guest

      Thanks!
      That explains the identical appearance of the Primary on the two XMLs.
      Everything is clearly in my comparative screenshot from Dolby Vision presentation.

      Great job Joey. So much to grab from this series.


    • Ken S
      Guest

      Why is the REC709 SDR gamma tag REC709 instead of 2.4?


    • Joey D’Anna
      Guest

      Tagging gamma 2.4 will make the output file have 1-2-1 tagging – which means the EOTF is ‘unspecified’. this causes some issues with some player software – doing both as rec709 gets you a 1-1-1 tag.


    • Ken S
      Guest

      And is 709 gamma tag assuming 2.4?


    • Joey D’Anna
      Guest

      Unfortunately that depends entirely on what the playback software chooses to do with it. Most browsers/players will handle 1-1-1 tagging correctly – but there isn’t really an absolute standard that they all go by


    • Stefano M
      Guest

      I grade P3 D65 1000 nit but I must export for youtube HDR.
      Youtube need primary color REC 2020 and color matrix REC 2020 and use tag in delivery page.
      Do I need re-analisys to export correct metadata?


    • Andrzej K
      Participant

      Is it not better to work in Rec.2020 and then only on final stage limit gamut to P3  (opposite to working in P3 and inserting it to Rec.2020)?

      Another question.

      Compressed codecs (even ProRes 444)) do overshoots which create problems when analysing image for HDR stats (max light etc.). If I receive HDR ProRes master and need to create SDR trim does it not going to affect Dolby math behind the process? Is there any study how much it does affect it? Ideally all those stats and trim metadata should be created on original assets, not later on compressed masters. If anything it should be TIFF sequence. Its there any guideline regarding this ?

      Regarding QT tag.

      1-1-1 tag is wrong as it causes OSX color engine to convert our video using about 1.96 gamma (based on original Rec.709 spec) to display profile. We get wrong (to bright ) image.

      Resolve from some point (after many complains) started tagging exports “properly” (Baselight guys also have video about it).

      By properly I mean best what can be done with current specs. It uses 1-2-1 which means Rec.709-unspecified-Rec.709. Unspecified means no transfer function is specified. Instead there is a gamma tag which should be used (current mediainfo started showing gamma tag). Resolve properly writes this gamma tag as 2.4 (for 2.4 projects). Such flagging is according to Apple QT spec and it’s allowed. Currently this is the only way to properly flag QT file which his graded to 2.4 gamma. Problem is in the lack of BT.1886 tag, which was never introduced. Industry forgotten to create such a tag and now we grade to 2.4 gamma, but have no way to properly flag such a files (about all use 1-1-1 which for OSX means 1.96 gamma). Another problem is that extra gamma tag is only a QT tag. When we go to private headers for h264/5 etc. there is no way to specify gamma. It’s well known problem which has been discussed on Resolve forum countless times. There were attempts to bring this to attention of ITU etc. (but failed), as only those bodies can fix it properly. Apple could also change math behind their 1-1-1 tag, but they are somehow not wrong using 1.96 as this tag refers to original Rec.709 spec. We need industry recognised tag for BT.1886.

Viewing 16 reply threads
  • You must be logged in to reply to this topic.

Hundreds of Free Tutorials

Get full access to our entire library of 900+ color tutorials for an entire week!


Start Your Free Trial
Loading...