Messages

Ps: I had to google Betamax 

Oops. Just showed my age...

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

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? 

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'... 


 

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.

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!

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. 

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! 

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

The overview (in DaVinci Resolve) is to grade in HDR Rec.2020, ST.2084(PQ), Analyse using Dolby to produce an SDR 100nit version, and finally export as SDR Rec.709.

I've no idea precisely what's going on in the 'black-box' of Dolby, (and unless you have the annual ££$$ license from Dolby, you can't access the trim controls) but tests have shown that in shots containing extreme dynamic range (see the Android Pop video posted above) something good happens to the treatment of highlights versus simply just grading all the way along in SDR Rec.709.

Basic flow:

1) Set your Resolve project up as above, with mastering and scopes set to 1000nits
2) Grade in HDR – push your extreme highlights [only] up to the 1000nit mark, pay attention to saturation
3) Use the Dolby controls to 'Analyse clip(s)' at the selected SDR level from the drop-down e.g. SDR 1886 Rec.709 100nits
4) Check the results with the 'tone mapping preview' ON
5) If the Dolby Gods have willed it, there will be enhanced 'detail' and colour in the highlight roll-off
6) Export the clip in the Delivery tab as Rec.709/2.4 or Rec.709-A if on Apple device, and select the Dolby tone-mapping preview from the bottom of the Advanced controls.

Your mileage may vary...!

Ok. Thanks all for help. Now it works fine:

Code Select Expand


#!/bin/bash
FILES="/Users/me/Desktop/media/*.MLV"
for f in $FILES
do
echo "0000068: FF 3F" | xxd -r - "$f"
done



Save as foo.sh script, run chmod u+x on it, and run it from anywhere (not within the MLV folder itself). 

get

Code Select Expand

line 2: syntax error near unexpected token `|'

@Danne

You could be right about the wildcard. If I remove it,

Code Select Expand


FILES="/Users/me/Desktop/media/"

the output is without the crazy characters, now just

Code Select Expand


xxd: /Users/me/Desktop/media/: Is a directory
cat: /Users/me/Desktop/media/: Is a directory


Sheesh!

Thanks. Looked promising – as the code syntax highlighting in Sublime Text looked more correct – but now random characters on output has returned!

Original command on a single file always worked. I used this:

Code Select Expand


echo "0000068: FF 3F" | xxd -r - Input.MLV


Thanks, but case doesn't seem to make a difference. I have this now:

Code Select Expand


#!/bin/bash
FILES="/Users/me/Desktop/media/*.MLV"
for f in $FILES
do
  echo "0000068: FF 3F" | xxd -r - $f"
  cat "$f"
done

Random gibberish output has been replaced with this:

line 6: unexpected EOF while looking for matching `"'
line 8: syntax error: unexpected end of file

A Google search reveals stuff about making sure text editor is using correct double quotes – which Sublime text is.
Anyone spot any schoolboy errors? 

Hey! Thanks, but still the same output with

Code Select Expand


  echo "0000068: FF 3F" | xxd -r - $f


Hi

I'm trying to run a command on Mac OS in Terminal to batch modify a folder of MLV files to rewrite their WhiteLevel.

I have a [working on PC] Powershell command that I'm attempting to rewrite into bash that is not working on Mac so far. When I run it, the terminal beeps, and the screen is filled with a flood of random characters until I stop it. The mlvs remain unmodified.

Can someone help please?

Powershell (working)

Code Select Expand


$FILES = Get-ChildItem  .\\* -recurse -Include  *.mlv
foreach ($file in $FILES) {
  echo "Processing $file..."
  echo "0000068: FF 3F" | xxd -r - $file
}


Bash (not working)

Code Select Expand


#!/bin/bash
FILES="/Users/me/Desktop/media/*.mlv"
for f in $FILES
do
  echo "0000068: FF 3F" | xxd -r - $file
  cat "$f"
done

Many thanks.

Righto. Thanks. That's hardcore! I'd better learn me some functions math. 

Ah, thanks! I see now. But if you don't know maths, there is no label to understand what has been selected. 

I see the tags now in ProRes export ffmpeg Anatolyi. But whatever preset/space/gamma is exported it just writes default 1-1-1 tags. Maybe this is mac only?

Oh. Not sure what you mean exactly. How do I restore the 'old' preset values dropdown? I can't write math expressions!

The 'Transfer Function' is just raw text code. I can't select anything here. Shouldn't it be a dropdown selector?

Updated ver1.11 shows me error for 'Transfer Function' dropdown:

Ah! None of the following exports show these tags (Color primaries, Transfer characteristics, Matrix coefficients) on my Mac with Media Info app (or Finder > Get Info). 

422LT
422
422HQ
4444
H264_AppleAV

The only export so far that has tags (1-1-1) is H264_FFMpeg! How strange.

Here's 422 Anatolyi (MLVApp v1.11, OSX Mojave)

See https://www.magiclantern.fm/forum/index.php?topic=25440.msg232207;topicseen#msg232207 Gamma shift issues on Mac / NCLC tags

Is it possible for correct metadata colour tags to be added to ProRes output from MLVApp? In ProRes outputs the tags are missing.

Untagged files are at the mercy of being displayed un-colour managed by apps and OS.

If you've ever battled with the Apple 'QuickTime Gamma shift mystery', then the following links should be required reading (and watching). This is peculiar to Apple devices, but should make informative reading for all involved in colour pipelines.

Short answer in first post here: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=101253

Resolve 16.2 latest solutions described first post here: https://forum.blackmagicdesign.com/viewtopic.php?f=21&t=114047

Excellent video explanation here: https://vimeo.com/349868875

Summary: Our rendered files must include the correct colour tags for other apps to do correct display transforms and so avoid the gamma shift peculiar to Apple display devices.

The tags in question are visible in the 'Get Info' dialogue. More detailed info can be accessed by installing https://mediaarea.net/en/MediaInfo

Resolve 16.2 now has a way to accurately tag exported files for display consistency (see the extensive Blackmagic Forum thread).