HDR10+ workflow

[vastunghia]

Thought I'd share my current workflow for rendering HDR10+ videos. [EDIT 7-8 apr 2022 highlighted in red] [EDIT 28 apr 2022 highlighted in blue]

Battle plan

• 
  Convert MLV to DNG (via MLV APP or any other tool capable of that)
  
• 
  Import DNG in DaVinci Resolve Studio (DVR in what follows) and grade HDR footage using an external HDR monitor (even your TV display could do the job, more on this below)
  
• 
  From DVR, export
  
  
  
  • 
    HDR10 graded footage as high-quality lossless Apple ProRes master
    
  • 
    HDR10+ metadata (JSON file) as prepared by DVR
    
• 
  Taking advantage of FastFlix (based on ffmpeg, in turn based on x265), render an H.265 Main10 HDR10 video with HDR10+ dynamic metadata built-in
  
• 
  Check for final video to embed correct HDR10 metadata (as DVR may fail in my experience): if not, correct HDR10 metadata using mkvmerge [This step should not be necessary anymore if HDR10+ analysis is performed before exporting the HDR10 Apple ProRes master video -- which is reflected in the amended detailed workflow below]
  

Requirements (apart from camera with ML of course)

• DaVinci Resolve Studio (not free)
• An external HDR monitor for grading*
• MLV APP (or any other free tool to convert MLV to Cinema DNG's)
• A recent version of ffmpeg (free)**
• FastFlix (free, available here: http://fastflix.org)
• MediaInfo (free, but not a strict requirement, just useful to check that the final result is ok)
• mkvmerge (available via mkvtoolnix**; free, may be not should be nomore necessary if DVR embeds correct HDR10 metadata, which is not always the case in my experience)

* Even though this is far from optimal (I know!), and since I am just an amateur and not a pro, to grade in HDR I use my Samsung LED TV: I got a Blackmagicdesign UltraStudio Monitor 3G to connect it to my Mac, it costs ~100 bucks. Also, to use UltraStudio Monitor 3G, make sure you have a real Thunderbolt 3 cable, not just USB. And an HDMI cable which is at least compliant with specs 2.0a.
** On my Mac, I installed it using Homebrew, which is a very convenient way to get it.

Detailed workflow

• 
  Take Raw footage (I use a 5DM3 with Danne's build, and my favorite preset currently is 3.5K 1:1 x5 @14bit)
  
• 
  In MLV APP, just load the MLV file and export as CinemaDNG
  
• 
  Load the cDNG's in DaVinci Resolve
  
• 
  Connect your external HDR monitor to your pc / Mac
  
• 
  In DVR, make sure you have the following settings (as a reference, I'm using v17.4.3: different versions may have slightly different, or even totally different options):
  
  
  
  • 
    Master Settings tab
    
    
    
    • 
      Video Monitoring section
      
      
      
      • 
        Video format: play with this till you get good output on your external monitor (if you use UltraStudio Monitor 3G, please note it is only capable of outputting HD video, so you will have to pick HD1080 here: in this case you may even want to temporarily downscale timeline resolution in DVR when working with higher resolutions, or you will end up with a cropped image being displayed on the external monitor).
        
      • 
        Video bit depth: 10 bit
        
      • 
        Enable HDR metadata over HDMI: enabled
        
  • 
    Color Management tab
    
    
    
    • 
      Color Space & Transforms section
      
      
      
      • 
        Color Science: DaVinci YRGB Color Managed
        
      • 
        Automatic color management: enabled
        
      • 
        Color processing mode: HDR
        
      • 
        Output color space: HDR PQ
        
      • 
        Display HDR on viewers if available: enabled
        
      • 
        HDR mastering is for X nits: even though this is not so clear, I think that you should enter the maximum luminosity your external monitor is capable of is expecting to be able to correctly display. For instance, I used the value I found in a technical review of my Samsung LED TV screen (550 nits: yes I know, not so good). To determine this value, personally I started from a low value of 500 nits, increased this value by steps of 100, and stopped when I noticed that my TV monitor was starting to adjust (darken) the image to accomodate higher luminosity data (this happened passing from 1000 to 1100, so I set this value @1000). If unsure, I would recommend to keep this value @1000, which is also the default suggestion made by DVR.
        
    • 
      HDR10+ section
      
      
      
      • 
        Enable HDR10+: enabled
        
• 
  In DVR Color page, grade footage to taste using your external HDR display as a reference (you will notice that same footage appears over-saturated and clipped on your pc/Mac, and that's exactly why we need external HDR displays to grade HDR footage)
  
• 
  [Anticipated this step as apparently this is necessary for correct HDR10 metadata to be embedded in the delivered ProRes master video file] When you are satisfied with the result, in DVR Color page go to Color menu > HDR10+ > Analyze All Shots. Wait till it finishes. Please note that this will enable by default the "Enable Tone Mapping Preview" checkbox in the HDR10+ tab of the Color page. You will notice that this has an effect on the footage preview as being displayed on the external HDR monitor. Not sure whether this should be enabled when grading to be honest -- but I think it should not (and indeed DVR manual says "The Enable Tone Mapping Preview checkbox lets you turn the tone mapping trim being applied off and on, so you can evaluate how the downconverted SDR version looks on your HDR display". So this checkbox seems to be relevant only for HDR-to-SDR tone mapping, i.e. I think it is trying to simulate how the result will look if you render the output video with "Tone Mapping" option enabled -- which is not an option we are interested in here. So let's leave it alone). So that's the reason why I'm suggesting to take this step after finishing grading. should you go back to grading after this step, I would suggest you disable this checkbox.
  
• 
  Then go to Deliver page, start with ProRes Master preset and then apply the following settings:
  
  
  
  • 
    Type: Apple ProRes 4444 XQ (if you have enough disk space... or else something a bit less space-consuming)
    
  • 
    Embed HDR10 Metadata: enabled
    
  • 
    Export HDR10 Metadata: enabled (this will save a .hdr10 text file that will serve at a later stage as a check that DVR really embedded the correct HDR10 metadata, even though this should be always the case now)
    
  then add to queue and render.
  
• 
  Now head to the Media page in DVR, right-click on your clip and select Timelines > Export > HDR10+ JSON: save the JSON file somewhere near your exported footage, choosing "HDR10+ Profile B Files (*.json)" from the drop-down menu [found out that this seems to produce more consistent data; also, Profile B includes more information than Profile A, in particular BezierCurveData metadata consisting of 9 Anchors and two (x,y) kneepoints]
  
• 
  We are finally done with DVR. We now have to encode our graded HDR video in H.265 format, also embedding HDR10+metadata. So we open FastFlix and
  
  
  
  • 
    make sure that rendering is set to x265 (the encoder used by ffmpeg to encode H.265 videos)
    
  • 
    load the previously rendered ProRes file
    
  • 
    feed the HDR10+ metadata JSON file ('HDR10+ Metadata' field)
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor] add option -profile:v main10 from the 'Profile' dropdown list, choose main10
    
  • 
    make sure that Bit Depth is set at 10-bit: yup420p10le
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor] if we want to fix the problem where the resulting file will not be loaded properly by QuickTime Player on Mac, we also need to add the following option in the 'Custom ffmpeg options' field: -tag:v hvc1
    
  • 
    [moved this step up as this can be managed directly in FastFlix instead of being adjusted in a text editor]I also suggest to change the output file extension to '.mov' '.mp4' instead of '.mkv', as I understand that Matroska container is not universally supported (while QuickTime MPEG-4 container has a much broader universal support base)
    
  • 
    all of the remaining options / parameters could be left untouched, however set them to taste (for instance I suggest Preset = slow, CRF = 20, and in the Audio tab you may want to convert PCM to AAC)
    
  Finally, we hit the "Convert" button and patiently wait.
  
• 
  [Bug corrected in FastFlix 4.8.0, so this workaround is nomore necessary] In FastFlix, don't click 'Add to queue' or 'Convert' buttons, as we do not want to do the encoding within FastFlix. The reason for this is that, at the time of writing, the most recent version of FastFlix (4.7.1) will force you to encode with a bit depth of 12 bit (equal to the input Apple ProRes video), and this will (for some reason) break HDR10+ compatibility. I have opened a bug report on GitHub by the way (https://github.com/cdgriffith/FastFlix/issues/311). So instead we
  
  
  
  • 
    head to "Raw Commands" tab
    
  • 
    copy the command-line command (invoking ffmpeg with a bunch of options and arguments)
    
  • 
    edit this command in favorite text editor as follows:
    
    
    
    • 
      option -pix_fmt yuv420p12le must be changed to read -pix_fmt yuv420p10le
      
• 
  [Bug corrected in FastFlix 4.8.0, so this workaround is nomore necessary] Now we take this command, paste it into Terminal / command prompt, and finally encode our HDR10+ video.
  
• 
  To check that everything went smooth, you can even inspect your final video file within MediaInfo, 'HDR format' should read SMPTE ST 2086, HDR10 compatible / SMPTE ST 2094 App 4, Version 1, HDR10+ Profile A B compatible
  
• 
  As a final step, you need to make sure that DVR embedded the correct HDR10 metadata in the rendered video, as my experience is that sometimes for some unknown reason DVR will just embed MaxCLL = 1000 and MaxFALL = 400, that seem to be some sort of default value for DVR [turns out this happened probably because HDR10+ analysis needs to be performed before exporting HDR10 video, and not later, so this problem should not occur anymore after fixing workflow as per above]. To do this, compare these two values in your final video file (using MediaInfo) with the values you will find in the last row of the .hdr10 file that DVR exported while rendering. If the two couples of values coincide, then everything worked fine. If this is not the case, you should adjust MaxCLL and MaxFALL in your video file in order to reflect the values that are found in the .hdr10 file. One way I found to do this is the following:
  
  
  
  • 
    transcode your MPEG-4 file (or whatever container you chose) to Matroska by simply invoking ffmpeg like this: ffmpeg -i myVideo.mp4 -acodec copy -vcodec copy myVideo.mkv. Note: this is not re-encoding your video / audio, it is just changing the multimedia converter format
    
  • 
    Change your Matroska video MaxCLL and MaxFALL values like this: mkvmerge -o myVideo_correctHDR10.mkv --max-content-light 0:m --max-frame-light 0:n myVideo.mkv, where of course m and n represent respectively the values for MAXCLL and MaxFALL that you find in your .hdr10 file (last line of the file!)
    
  • 
    transcode back to MPEG-4 (or whatever container you chose above) from Matroska with ffmpeg -I myVideo_correctHDR10.mkv -acodec copy -vcodec copy -tag:v hvc1 myVideo_correctHDR10.mp4
    
  • 
    finally check again in MediaInfo and HDR10 metadata should be fine
    

Happy to receive feedbacks, comments and suggestions.

Thank you

Sergio

[timbytheriver]

Thanks for sharing this detailed info Sergio.

I've been experimenting with HDR10+ for awhile also, and share much of the same workflow, except that I use Hybrid instead of FastFlix for muxing the json file into the H265 file.

I find it frustrating that although HDR10+ is supposedly open-source, we cannot yet gain access to the trim controls in DaVinci Resolve. This means that DR is writing some strange arbitrary nit metadata which makes it almost impossible to judge what is happening when we compare an x-nit target with a y-nit target display. e.g. Though my Panasonic TV is HDR10+ and displays the label when I view exports – I cannot see any different tone-mapping happening from straight HDR10. I suspect this maybe because my display is already close to 1000nit anyway – so I'm guessing that the metadata changes are not being required.

Do you have a similar experience?

The only way so far of getting access to HDR10+ trim controls is via hyper-expensive mastering apps like Transkoder – or a slightly less pricey solution here: https://ff.de/products/ It's a bit of a bar to users wanting just to dip their toe in the HDR10+ eco-system!

I posted a question along these lines to the HDR10+ Technologies people on this video, but there are no replies yet.  https://www.youtube.com/watch?v=jqDC2J2bQ44

[vastunghia]

Hi Tim,

thanks for your comments! You are definitely a few laps ahead on HDR10+

Yes currently the HDR10+ trims are applied on the basis of a black box by DVR, and cannot be changed... not exactly sure I would be able to obtain better results via manual settings though, to be honest. But yes, pretty weird that there is no possibility to change them.

I too will need to experiment to see if same HDR10 footage with and w/o HDR10+ metadata looks different on my entry-level LCD TV (~ max 550 nits). Also, not clear to me whether I should keep 'Enable Tone Mapping Preview' enabled during grading. Is DVR trying to simulate how my final rendered video will show on my TV with HDR10+ metadata? And if so, is it reliable? What I see for sure is that enabling it has the effect of lowering overall luminosity a little bit, in my case.

More experiments needed for sure...

S

[timbytheriver]

Also, not clear to me whether I should keep 'Enable Tone Mapping Preview' enabled during grading. Is DVR trying to simulate how my final rendered video will show on my TV with HDR10+ metadata?

This is the theory I believe. In practise I believe it's still work in progress. 

Another unknown to factor-in is the TV's own tone-mapping when it gets near to its max-nit value. Each TV manufacturer has its own black-box to achieve this. So how exactly DVR can accurately simulate this remains to be seen.

My experiments were so frustrating because I never saw any noticeable changes with/without HDR10+ metadata. After this I lost heart in testing further!  Maybe you will fare better since your target display max-nit level of ~550 is a better test case for metadata control  – if you are grading say to 1000nits max. The rule of thumb seems to be that the nearer the target display is to the max grading nit level – the reduced need for metadata to produce a 'roll-off'. And if the TV is doing this anyway – what's the point of the metadata at all? So many questions!

This guy's channel has some very informative info on HDR10+ https://www.youtube.com/channel/UCyzCqHyxr0uIF3eVFc9KPEQ

We can though all agree that Magic Lantern files are capable of out-puting excellent source material for HDR! 

[vastunghia]

Stumbled upon a weird behavior of DVR today, as I realized that it was not embedding correct HDR10 metadata (MaxFALL in particular) in another video project I was working on. The exported .hdr10 file read MaxFALL = 659, but the DVR-rendered ProRes video had 400 (which appears to be DVR default value) according to MediaInfo.

HEVC encoding of the ProRes master with x265 did not help even when passing x265 the –max-cll "1000,659" option, as for some reason the input ProRes master file metadata (400) was passed on to the output HEVC rendered file, regardless of my specific use of the -max-cll option.

So I had to figure out a way to fix this in the rendered HEVC file, and I think I succeeded. Details in the first post.

Sergio

Ps: still need to investigate whether the inclusion of HDR10+ metadata does add anything to visual experience vs plain-vanilla HDR10 metadata on my 550-nit capable TV. Hope to find the time soon.

[vastunghia]

...and I still don't get exactly how the HDR10+ grading workflow should be carried on in DVR. As of now, I

• do a first grading pass using external HDR monitor
• select HDR10+ > Analyze All shots
• leave "Enable Tone Mapping Preview" checkbox active in HDR10+ color tab
• do a second pass using external HDR monitor
• [not sure this makes any sense at all] repeat step 2
• render master video

Main question here is: does step 5 make any sense at all? Does this mean there is an iterative process, repeating steps 2-3-4-5 over and over again? Or, put another way, will the "Analyse All shots" command induce a change in HDR10+ trims after a small correction in grading?

Guess I will try and ask on the DVR forum. If any luck, will post back here.

Sergio

[vastunghia]

DVR manual says "The Enable Tone Mapping Preview checkbox lets you turn the tone mapping trim being applied off and on, so you can evaluate how the downconverted SDR version looks on your HDR display", so I draw these (hopefully) final conclusions:

• 
  When grading using an external HDR monitor, DVR is sending some HDR metadata over HDMI -- not sure which ones and how they are generated though, but for sure the "HDR mastering is for X nits" setting does have an impact on the image being displayed on my HDR tv (anything above 1000 nits will result in a more and more dark image, while lower values seem to have little to no impact). Incidentally, I find that my "HDR mastering is for X nits" setting is reflected, in the rendere video, in the "Mastering display max luminance" metadata, that however is not part of the HDR10 specs if I understand correctly -- that would be the triplet Mastering display color primaries / MaxCLL and MaxFALL, right?
  
• 
  Rendering in DVR choosing "Embed HDR10 Metadata" makes DVR calculate (on-the-fly I presume, i.e. frame by frame during rendering) CLL and FALL levels for each frame, eventually appending HDR10 metadata to the video stream / video container (guess the former).
  
• 
  "HDR10+ > Analyze All shots" makes DVR run through each clip in the timeline and apply HDR10+ analysis, resulting in 9 (non-editable) percentile anchor points for each clip (BTW this sucks a bit IMO, as I may have two different clips that are actually taken from the same exact scene, and HDR10+ may apply different anchor points for the two, while this should not occur). My understanding is that having performed the HDR10+ analysis has no impact on the external monitor, i.e. DVR is still passing the same metadata over HDMI, so actually there is no way to have a correct HDR10+ preview on external monitors during grading -- the only way to be sure is to render final HDR10+ video and check results. In fact, the "Enable Tone Mapping Preview" (that is enabled by default after HDR10+ analysis) has nothing to do with previewing HDR10+ grade on our monitor -- it just tries to mimic how the downconverted, tone-mapped SDR video will look on our monitor should we render the video with the "Tone Mapping = HDR10+" setting in the Deliver page.
  

Adjusted once again first post to reflect this.

Sergio

[timbytheriver]

Hi Sergio

Very interesting re the incorrect MaxFALL values being passed by the ProRes file. I hadn't noticed this. Thanks for the fix!

Just out of interest, have you used this HDR10+ metadata test file with your 550nit panel? https://ff.de/hdr10plus-metadata-test/ I see no change on my panel running the clips. It would be useful to know your result!

Re the 'HDR Mastering is for X' and bezier curves, anchor points et al, you might also be interested in this thread on the DVR forum: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=97953&p=824715#p824715

The HDR10+ workflow is very poorly implemented and documented at present imo. 

[vastunghia]

Just out of interest, have you used this HDR10+ metadata test file with your 550nit panel? https://ff.de/hdr10plus-metadata-test/ I see no change on my panel running the clips. It would be useful to know your result!

Thank you Tim, nice test, I tried it on my TV and I definitely see very different results as HDR10+ metadata change, e.g. severe clipping in highlights in the second version of the clip and so on.

Re the 'HDR Mastering is for X' and bezier curves, anchor points et al, you might also be interested in this thread on the DVR forum: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=97953&p=824715#p824715

Very useful, thank you! From this I understand that (1) from DVR there is the possibility of exporting also Profile-B json HDR10+ metadata (didn't notice!) and that (2) currently TargetedSystemDisplayMaximumLuminance seems to be hard-coded @400 nits in HDR10+ json file. This may be somehow related to DVR exporting HDR10 metadata with MaxFALL = 400 maybe? Heaven knows. Probably not.

The HDR10+ workflow is very poorly implemented and documented at present imo. 

To say the least. This is an understatement actually .

Planning to prepare PQ10 / HDR10 / HDR10+ prof-A / HDR10+ prof-B versions of the same video to test on my TV. Will take some time, but keep you posted.

Sergio

Ps: I also had a closer look at HDR10+ json exported from DVR and noticed that in some cases TargetedSystemDisplayMaximumLuminance is set @0 nits Not clear what's going on here at all. Whole process looks pretty buggy, manual inspection is needed everywhere. EDIT: looks like Profile-A json files have TargetedSystemDisplayMaximumLuminance and MaxScl incorrectly set @0 nits, while Profile-B files have them respectively set @400 and 10000 nits (which is probably not optimal yet, but better than 0)! Updating post #1 to suggest exporting Profile B HDR10+ metadata.

[timbytheriver]

I tried it on my TV and I definitely see very different results as HDR10+ metadata change

Ha! Now I'm confused – and a bit jealous!

[vastunghia]

Ha! Now I'm confused – and a bit jealous!

Maybe you should not. I can think of 3 causes for your TV behavior:

• it is capable of a far higher luminosity than mine, so you will not see any highlight clipping (however maybe you should see anyway brighter areas in clip #2 versus clip #1?)
• it is taking HDR10+ metadata as an input, but then it is also doing some black magic of its own on the image being shown, avoiding highlight clipping for instance (I think I read somewhere that Sony TV's discard HDR10+ metadata basically as they are analyzing frames on the fly and adjusting image based on internal parameters)
• your TV is not interpreting correctly HDR10+ metadata (on my Samsung TV there is a way to check if it is, I don't know in your case)

S

[timbytheriver]

1. On paper yes – the Panasonic FZ952 luminance curve hard-lines at 900. Clips #1 & #2 highlights look identical though.
2. I think black-magic stuff certainly! This is the achilles-heel of the whole metadata thing: if it's just being overridden by the TV's black box, we might as well pack up and go home.
3. The on-screen badge changes to HDR10+ – so notionally it's seeing it correctly.

[vastunghia]

This is the achilles-heel of the whole metadata thing: if it's just being overridden by the TV's black box, we might as well pack up and go home.

Very well said. And indeed I think that is the case.

I think I read somewhere that HDR10+ suffers a lot from this (tv's doing magic on a not-so-strictly defined standard) while Dolby Vision does not, i.e. remains more consistent across different displays. But I may be wrong.

S

[timbytheriver]

7. When you are satisfied with the result, in DVR go to Deliver page, start with ProRes Master preset and then apply the following settings:
...
• Embed HDR10 Metadata: enabled

I've noticed that if this checkbox is enabled for the final ProRes render, the metadata may contain two sets of MaxFALL, MaxCLL data: One set is marked as MaxFALL_x_Original. I've taken to rendering the ProRes master without the Embed HDR10 metadata enabled, and just using the exported .json file as the definitive source for the metadata. This might avoid these duplicate data sets. Who knows...!

As a PS I seem to be able to throw plain HDR10 files up to 4000nits Max at my TV – and it does a great internal job of tone-mapping the overs! The same HDR10+ file with all the nice metadata in place is recognised as such – but there really doesn't appear to be a visually superior roll-off happening. This tells me that either the TV is doing a good job, or the metadata is being overridden by the TV (bad).

Obviously we need the correct valid metadata present in a production environment, but I wonder how many TVs out there in the wild are just ignoring the colourist's carefully crafted mastering, and quietly 'doing their own thing'... 


 

[vastunghia]

I've noticed that if this checkbox is enabled for the final ProRes render, the metadata may contain two sets of MaxFALL, MaxCLL data: One set is marked as MaxFALL_x_Original.

Yes, I noticed too, I think this is what is going on under the hood:

• DVR writes MaxFALL and MaxCLL metadata to ProRes master file -> the resulting file has just this couple of parameters
• Then as per the above workflow you render a HEVC video starting from the ProRes master, embedding dynamic HDR10+ metadata as well as re-embedding HDR10 metadata -> I think that during this process, x265 / ffmpeg decides to do a back-up copy of original HDR10 metadata (MaxFall, MaxCLL) as embedded in ProRes master file by DVR, simply by appending '_original' to this original metadata -- and then re-embeds new metadata (as being instructed by you, via command line).

So in my view this should be harmless, but I can also understand the reason one could feel more comfortable in avoiding any unnecessary metadata here.

This tells me that either the TV is doing a good job, or the metadata is being overridden by the TV (bad).

I think you should be happy as long as you do not see any clipping occurring whatsoever, at least in the first place. I still do not fully understand why a TV should display clipping as a result of its incapability to reach extreme nit values. So I guess your TV manufacturer is sharing my view somehow.

I wonder how many TVs out there in the wild are just ignoring the colourist's carefully crafted mastering, and quietly 'doing their own thing'... 

Yup, you just have to walk into a TV store where they are typically displaying the same video on dozens of different TV models... they all look so different. I think we just have to live with it. But that's why I'm happy I'm not a professional video maker... I just want my private footage to look the way I want on my particular TV (which I use for grading). So guess I'll have to stick to my TV forever

S

[timbytheriver]

I still do not fully understand why a TV should display clipping as a result of its incapability to reach extreme nit values.

I believe only grading reference monitors are designed to display the results of actual clipping – they have a hard clip in other words, so that colourists can actually see the effect of over-driven signals, and should have the technical skills to limit this to avoid damage. Modern consumer TVs are I think designed never to hard-clip, because a) Most consumers would think it was a visually 'broken'. b) Constant high-nit values would cause damage.

Tbh, I'd prefer it if I could switch my TV into a hard-clip mode, especially when trying to work with dynamic metadata in HDR flavours. I wonder whether there's a way... Maybe a custom calibration LUT?

Btw, did you ever get to actually see the effect of your HDR10+ metadata on your display? 

[vastunghia]

Btw, did you ever get to actually see the effect of your HDR10+ metadata on your display? 

I prepared 4 versions of the same clip, namely

• PQ10, i.e. PQ transfer characteristics and BT.2020 color space (no metadata at all!)
• HDR10, namely (1) + static HDR10 metadata (mastering display color primaries + min and max luminance + MaxCLL + MaxFALL)
• HDR10+ Profile A, namely (2) + dynamic metadata consisting of luminance distribution parameters
• HDR10+ Profile B, namely (3) + dynamic metadata consisting of Bezier curve parameters

The clip included some very bright scenes, some more balanced scenes, as well as some very dark scenes with a few bright spots.

To assess the four versions of the clip, I photographed the TV screen from a long distance in a dark room, of course taking Raw pictures and baking them with exactly the same (somewhat neutral) settings in ACR.

The results:

• version 1 is slightly darker in all cases (this somewhat surprised me as I expected on the contrary that no metadata could lead to oversaturated / clipped highlights)
• versions 3 and 4 look apparently identical (no surprise), but they seem to roll highlights (as well as shadows) slightly differently from 2, in a non-trivial way (in most, but not all cases, increasing contrast slightly)

So yes, in the end I could find some differences with my TV -- but very subtle, in many cases visible more by comparing the sample pictures histogram rather than really perceivable with the naked eye.

Sergio

[vastunghia]

Edited post #1 to reflect further findings, namely

• 
  HDR10+ analysis must be carried on before exporting master video, as this seems to be a prerequisite for embedding correct HDR10 metadata (this may explain why in some cases I obtained wrong HDR10 metadata and needed to adjust it ex post)
  
• 
  Regarding the "HDR mastering is for X nits" setting in DVR, I decided that X should match what your TV / external monitor is expecting you to throw at it as max luminance, not what it is actually capable of achieving in terms of luminance -- and I think that a good way to determine this parameter is to start, say, from 500, and increase it by steps of 100, stopping when you note that your TV / external monitor is starting to adjust (darken) the image to accomodate higher luminosity data
  
• 
  Simplified encoding steps thanks to bug being corrected in FastFlix
  

[timbytheriver]

Hi Sergio

Thank you for your comprehensive testing and feedback. I'm still digesting it. It certainly seems to agree broadly with my own, in that the 10+ metadata seems to be doing only very subtle things – a good thing I guess. And still we don't know if/how the TV is doing its own 'trim'. If DVR allowed us access to the trim controls we could I suppose make extreme adjustments – the easier to see the metadata at work.  Is there any change in DVR v18 I wonder?

I read on some forum the other day that a major Hollywood studio has just withdrawn from the HDR10+ alliance. Words like "Dead duck..." were being used with reference to HDR10+ future... Sadly this might all be a bit Betamax in a year's time...

*Edit I note with a slight *groan* that a) No talk of HDR10+ update in DVR18(beta), but b) oddly this is added: "Support for the HDR Vivid standard." This is apparently a version of the HDR10/PQ standard that the Chinese market is leaning toward. I think it sounds like one of those dodgy showroom picture styles on a TV – to be avoided! :0

[vastunghia]

I read on some forum the other day that a major Hollywood studio has just withdrawn from the HDR10+ alliance. Words like "Dead duck..." were being used with reference to HDR10+ future... Sadly this might all be a bit Betamax in a year's time...

Yup they've been saying that HDR10+ is dead for a long time already. And I think they are right. Personally, if I didn't own a TV which is capable of HDR10+ only (and not Dolby Vision), I would not have much interest in this technology. Even though I don't see a royalty-free contender to Dolby.

But then again, considering the very limited benefit that dynamic metadata seems to bring to my TV (at least with respect to static metadata HDR), maybe the real point is that we should not be joining the dynamic metadata hype.

At this stage this is more a style exercise to me, fueled by some curiosity in how these technologies work (not very well I must say after digging into it).

S

Ps: I had to google Betamax 

[timbytheriver]

Ps: I had to google Betamax 

Oops. Just showed my age...