P3D65 / HDR->SDR / Workflow issues

Hi all,

I already posted on Lift Gamma Gain forum but I wish to know more opinions here. I plan to make a new color grading in Dolby Vision (Rec 2020 - P3D65 lmited - PQ curve - 1000 nits) without the licence in DaVinci (still too expensive for rare projects). So no custom trims. I'll have to a make DCP in SDR later from this grading. I'm not used to take HDR sources for this. So I see two options at the moment:

1/ Render a SDR source in Rec 709 - Gamma 2,4 - 100 nits using the Tone Mapping
Pros: Best tone mapping
Cons: Smaller color space

2/ Take the master source in Rec 2020 - P3D65 limited - 1000 nits and then apply a Color Space Transform *
Pros: Bad tone mapping?
Cons: Native color space kept

* not sure about the settings

=> What would you recommend?

--

During the same conversation on LGG forum, I've been adviced not use my Eizo Prominence in P3D65 - 100 nits for SDR projects... but to stay with Rec 709. I'm a bit surprised because it covers 99% of P3 color space. It is also "compliant" for P3D65 workflows in HDR. So why not SDR? I know tbe Prominence comes with a P3DCI preset at 48 nits but I never work with it because of the white point and the luminance. I use instead a custom preset made by a calibration company in P3D65 - 100 nits - gamma 2,4. I know they could create it in gamma 2,2 as it is usually done for "Display P3" but they argued that it would be better to keep the same EOTF than BT-1886.

=> Do you think I'm going wrong?

Thank you.

There is something fairly new called Dolby Cinema Trims.
If you have latest Resolve (18.1) you may use it to create SDR Cinema P3 master auto fHDR master for cinema usage.

Follow this:
https://professionalsupport.dolby.com/s ... uage=en_US

So basically same as Rec.709 SDR trim, except you choose Cinema trim as target (eg. 48-nit, P3, D65, Gamma 2.6) and then during render apply this trim and export as DCP. Make sure that DCP metadata properly describes gamut, white point and gamma, so during playback it's properly handled.

I think as for today this is correct approach to create SDR Cinema master of of HDR Dolby master.

Thanks Andrew.

I want to make a SDR master with the best tone mapping from my HDR grading. This SDR master would be used to create a DCP afterwards. That's why I'd go with the Dolby Vision trimming process. However, the problem is that I'd be forced to make it in Rec 709 (then, losing my initial P3-D65 color space). So I was looking for a possible alternative during the HDR->SDR tone mapping.

I understand now what this new Dolby Cinema Trims does. So I should deliver a SDR master in P3-DCI at 48 nits and then doing the DCP from it. Correct?

Yes, you have few choices. 48nits means SDR. Then it's just a matter of white point- maybe best to stay with D65? Maybe best to check with cinema if there is no issue with it. As I said- always make sure final DCP metadata describes your used parameters correctly.
You can also contact Dolby if needed- they may be able to help you (or use their forum- Michael is your guy).
I think it should be fairly easy process though in Resolve 18.1.

So the DCP in HDR for Dolby Cinema have a D65 white point. Different from the SDR DCP's. That's interesting! I probably won't make any since there are very few compliant cinemas. My clients in indie world won't probably go there.

What do you think about my initial second question about P3-D65 workflow in SDR? I don't understand why the user from LGG forum warned about it.

No idea what they are talking about. Maybe did not understand you properly. Maybe think that SDR has to be in Rec.709 (as HD is). SDR even for broadcast doesn't have to be in Rec.709.
If it's UHD SDR then it has to be in Rec.2020 actually. I would ignore it.

If you want to go to cinema I would stay with P3. Just follow Dolby route and you should end up with good cinema master.
You can try watching final DCP on Eizo with 48nits preset (assuming it uses same gamma+ white point), but this is still not really representative as cinema delivers different visual experience. It may give you some idea about the look though.

I've just made some tests and I've got strange color results...

Here is the first workflow:

DaVinci in RCM
Rec 2020 (P3-D65 limited)
PQ ST2084
1000 nits
DV 4.0

=> Import with this source: https://fromsmash.com/gOIXejqdWd-ct
=> Exports files with 3 different DV tone mapping applied : https://fromsmash.com/zF0jOFUol--ct

Please note that :
- the source is also Rec 2020 (P3-D65 limited) - PQ ST2084 - 1000 nits
- the 3 different exports are in Rec 709 - gamma 2,4 - 100 nits // P3-D65 - 48 nits // P3-DCI - 48 nits

--

Then, here is the second workflow to generate the DCP's :

DaVinci in RCM
Rec 709
Gamma 2,4
100 nits

DaVinci in RCM
P3-DCI
SDR

DaVinci in RCM
P3-D65
SDR

=> DCP exports from the tone mapping files: https://fromsmash.com/wY8j1g_T5O-ct

--

If I compare the three DCP's, I get different color results, which can't be due to the different tone mapping in my opinion. They should look at least closer.

How you monitor?
Each case properly with matching monitor mode ?
If you import all to project with eg P3 setting then Resolve should bring them to about same look (once they are all integrated properly at source stage). Actually no- they are going through some tonne mapping, so they won't look the same. It's not some perfect math which is reversible during displaying.
If you watch them in some color unmanaged player of course they will look differently.

I monitor with the Prominence and the matching preset

To compare the results, I bring all the DCPs in a same timeline in P3-DCI: one per track.

More accurate would be to set monitor to each file parameters. In this case you normalise all to one colorspace+gamma and then display. This is not necessarily accurate and will depend on Resolve processing as well.

The DCP's have all the same colorspace in DCI X'Y'Z". Why can't they be compared in a same project / same preset monitor? I know I won't get the exact same results because these come from three different tone mapping. But they should look closer, no?

Have you been able to download the files to have a look?

Thanks for helping.

Set project to Davinci YRGB as on grab.
Then put them on timeline one after another and for each apply color space transform filter and set it like this:


so each input has proper input parameters set (of course grab is for DCI one). Turn off all Resolve adaptation (as on the grab) and you should get about the same preview, which is the case for your files. Only difference is color for Rec.709 output as it has smaller gamut and this blue is out of Rec.709. Other small differences are due to fact that Dolby trimming is adaptive, so depending on target gamma etc. it behaves slightly different.
For me all looks as expected. They all look about the same when normalised to Rec.2020 Intermediate Resolve colorspace.
I was even able to get HDR to map close to Dolby.
If you set project to Rec.709 you will actually get about same look for all 3 files (both P3 based files will be clipped to Rec.709)
This is also a way to check if Resolve/Dolby doesn't do anything crazy/wrong

Also - as I said. If you monitor each file directly with corresponding monitor setup then all should look also very close on monitor. The way you wanted to do it involves a lot of uncontrolled processing by Resolve and it won't work. Best to have 3 monitors and feed each with own file at the same time

Thanks a lot Andrew.

That's right, I've noticed the blue becomes clipped with the RCM configured in Rec709 - gamma 2,4. Then, the 3 files match much better! I suppose I got confused because of that large part of blue out of Rec 709 color space. However, between the P3-DCI and the P3-D65 tone-mapping exports, there's still a little difference about luminance. It's still confusing. So my last question would be this one:

Should you advice to use the P3-D65 tone mapping in order to make a DCP from the SDR master? Then, the white point should be kept among the HDR->SDR process... but be transformed to the last DCI X'YZ' conversion? Or should I directly export with the P3-DCI tone mapping which won't modify the white point at the last step? My goal is to know in which step it's better to convert the white point: DV tone mapping or DCP color transform. I hope the question is clear

I think this sort of difference is acceptable and not sure what to answer. In any case conversion from D65 to DCI has to happen- it will be just in differ place. I don't think you should worry about it much as both versions are adaptive, so it's not easy to say which one is correct/better. Both are just representation of HDR master, not some perfect conversions to different color space/gamma. Also- this is will look slightly different in actual cinema. Ask Dolby
From what I have seen Dolby auto trim seems to make thing bit too dark, so maybe go with brighter version. I analysed some masters which had Dolby trim + manual offsets done by colorist and about always it's was related to shifting mid-tons up. In the same time better to ask someone who does it every day and has more exposure to this. I don't. You actually should get preview after trim and maybe go through scenes and check how they map and adjust if needed. If you don't have Dolby license then you can do it with Resolve tools as you going to render it into video anyway.

Actually read this:
https://www.liftgammagain.com/forum/ind ... nts.11109/

You can start with D65 based master when going to DCP. In this case this is "cleaner" option for you.
XYZ data holds final image look, so starting white point in meaningless in this case. Same as Rec.2020 can hold P3 inside.

I don't have the DV license so I might apply some corrections on the SDR master generated by the tone-mapping, like you described. If this is the case, the following issue appear.

I remind that my SDR P3-D65 custom preset has been created on a 2,4 gamma value. The DV tone-mapping apply 2,6. So maybe I'd better to use the P3-DCI one instead. The default preset in the Prominence would match then. I know it's not adviced to grade at 48 nits with a hot white point on a monitor. But I'm afraid the gamma curve mismatch in P3-D65 would be worse. Or maybe I'd just need to ask the calibration company to make another P3-D65 custom preset at 2,6.

Hm... I'm not a colourist and have no experience with this.
You can try to do corrections at standard P3 SDR preset and then convert to DCP.
If you have no access to projector then I assume this is the best you can do.
It would be cool (even just for fun) to see how 48nits preview from DCP compares to P3 SDR preview though on Eizo (and if you could preview in cinema and compare then you would have some idea how these things translate). Maybe it's better to do correction on standard SDR or maybe at 48nits cinema preview. No idea. Sony X300 against Christie projector did look fine, but it's hard to compare tiny screen to cinema screen
If you do everything as needed (correct gammas etc. in setup) I think you will be fine one way or another. Use preset which you have calibration for instead of some non-verified.

Maybe Walter can comment on this.

I'll probably use the DV P3-D65 tone mapping when there will be no SDR trim pass inside the SDR master, and then will use the P3-DCI one if the trim pass becomes necessary so it can match perfectly to the Prominence calibration preset.

I'm curious so I've been searching in Resolve if it's possible to convert the P3-D65 - PQ- 108 nits created by DV tone mapping in order to make a DCP HDR meeting Dolby Cinema specs. The ACES IDT exists as "P3-D65 ST2084" since version 1.1. But I can't find an ODT matching to DCI X'Y'Z'. Or maybe it's just the DCDM one?

HDR to Dolby Cinema HDR?
Don't know. Not a fan of ACES. I rather use YRGB.

HDR to Dolby Cinema HDR?

Yes. It seems possible since this new tone-mapping: P3-D65 - PQ- 108 nits.

Don't know. Not a fan of ACES. I rather use YRGB.

Me neither. But at least, the matching IDT exists: https://acescentral.com/uploads/default ... dd8c97.pdf (page 45)

I just don't know how to translate that to DCI X'Y'Z now.

If you have your HDR PQ master and want Dolby Cinema trim then just do DV trim and export to DCP.
I would just make sure output color space matches DV trim settings, so eg. P3 D65 ST. 2084 as white point info is taken into account when conversion to XYZ happens (so I assume it has to match DV trim settings).

Dolby trim is per scene and anything like LUT or ACES is global, so never will be overall as good (at leats by my understanding).

You mean rendering the DCP with the tone mapping at the same time, like this?

Yes, should work as any other render.
Make sure correct mastering display is set in Dolby preferences.
Use to affect trimming, not sure if still does.
Just to check- bring back DCP and compare to your timeline.

Bringing back the DCP on the timeline doesn't match, even with a workflow in ACES (P3-D65 ST2084 108 nits as IDT / P3-D65 ST2084 1000 nits as ODT). I think this operation works for SDR DCP only.

However, the metadatas look fine inside the DCP's XML:

Code: Select all

          <meta:ExtensionMetadataList>
            <meta:ExtensionMetadata scope="https://www.dcimovies.com/schemas/2018/HDR-Metadata">
              <meta:Name>Image Encoding Parameters</meta:Name>
              <meta:PropertyList>
                <meta:Property>
                  <meta:Name>EOTF</meta:Name>
                  <meta:Value>ST 2084</meta:Value>
                </meta:Property>
              </meta:PropertyList>
            </meta:ExtensionMetadata>
          </meta:ExtensionMetadataList>

Same with mediainfo:

Code: Select all

ID                                       : 2
Format                                   : JPEG 2000
Format profile                           : D-Cinema 4k
HDR format                               : SMPTE ST 2086, HDR10 compatible
Format settings, wrapping mode           : Frame
Codec ID                                 : 0D010301020C0100-0401020203010104
Duration                                 : 3 s 760 ms
Bit rate                                 : 250 Mb/s
Width                                    : 4 096 pixels
Height                                   : 2 160 pixels
Display aspect ratio                     : 1.896
Active Format Description                : 0
Frame rate                               : 25.000 FPS
Color space                              : XYZ
Chroma subsampling                       : 4:4:4
Bit depth                                : 12 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 1.132
Stream size                              : 112 MiB (100%)
Title                                    : VIDEO_5bc2fc72-0991-4a4d-a626-edd8b3343492_v1
Color range                              : Full
Color primaries                          : Display P3
Transfer characteristics                 : PQ
Mastering display color primaries        : Display P3
Mastering display luminance              : min: 0.0001 cd/m2, max: 1000 cd/m2

(except this boring default values for MaxFALL and MaxCLL that DaVinci always apply)

Here is the DCP test if you're curious to have a look: https://fromsmash.com/x8g8~EpciF-ct

So the question is: bad or wrong colors?

File is fine. You can't set P3 D65 IDT as it's XYZ file.
You have to use same Resolve project setting in order to accurately preview it as last time and set input color space as XYZ (Resolve thinks it's P3 D65) in color space conversion filter. If you then take HDR PQ master and play with mapping you cna make them look close, so DCP is fine.

You can also use color managed project with separate gamma and then properly interpret file as XYZ + ST2084.
Metadata is okish as the info is for mastering display. Anyway I would not worry about it as it will be most likely discarded at cinema anyway. I would say all looks fine (surprisingly fine as for Resolve )

File is fine. You can't set P3 D65 IDT as it's XYZ file.
You have to use same Resolve project setting in order to accurately preview it as last time and set input color space as XYZ (Resolve thinks it's P3 D65) in color space conversion filter. If you then take HDR PQ master and play with mapping you cna make them look close, so DCP is fine.

You can also use color managed project with separate gamma and then properly interpret file as XYZ + ST2084.
Metadata is okish as the info is for mastering display. Anyway I would not worry about it as it will be most likely discarded at cinema anyway. I would say all looks fine (surprisingly fine as for Resolve )

In your workflow (DCI X'Y'Z' + ST2084 to interpret the DCP), I see it much darker than the source. I suppose because of the 108 nits limit? The scope in ST2084 confirms it reachs around 100 nits.

** The source **


** The DCP HDR **


Thanks again!

Darker than what -1000 nits master ?
It's tonne mapped 108nits preview so it's going be different for sure.
What you need to compare is HDR on mastering monitor vs cinema HDR on actual screen. This is when they should give similar visual experience. You can't simulate accurately cinema HDR with your Eizo.

What matters here is that DCP matches 108nit trim made by Dolby. Rest is you trusting Dolby with their trim tech and how it translates to cinema experience.

Darker than what -1000 nits master ?

Yes.

It's tonne mapped 108nits preview so it's going be different for sure.

That's what I supposed. I mean, DaVinci won't remap the 108 nits source to 1000 nits even if you specify the ST2084 EOTF. The curve is separate from the luminance.

I know I can't simulate the Dolby Cinema specs on the Prominence. That's why I compare the signals at the scope. It looks coherent anyway.

Yes, all seems to be fine. How it translates to final cinema look- no idea

I've just found this interesting doc: https://www.dcimovies.com/specification ... 2-0330.pdf

The CPL metadatas' match from what I found inside the DCP I generated.

It also mentions that the MXF's UL for "Generic Picture Essence Descriptor" shall contain this value:

Code: Select all

06.0E.2B.34.04.01.01.0D.04.01.01.01.01.0A.00.00

I've found back this value inside the MXF generated by DaVinci:

Code: Select all

<rp210Elements:TransferCharacteristic>06.0e.2b.34.04.01.01.0d.04.01.01.01.01.0a.00.00</rp210Elements:TransferCharacteristic>

So it should be 100% compliant. By the way, a new discover: only 24/48/60/(96)/(120) fps are supported. No more 25 or 30 fps. Anyway we should not exceed 48 fps for compliant issues, in my opinion.

I have no idea how compliant is Resolve DCP exporter. You can always rent easyDCP license if needed. This one is used a lot.

I have no idea how compliant is Resolve DCP exporter. You can always rent easyDCP license if needed. This one is used a lot.

easyDCP doesn't support Dolby Cinema. But everything indicates it's compliant: CPL metadatas, MXF essence, etc.

Ah...ok. Should be fine then.

I should rent a Dolby Cinema instead

But I don't want to know the price.

Is Dolby using own hardware or eg. Christie?

Is Dolby using own hardware or eg. Christie?

It's a Dolby / Christie collaboration.

That's incredible to be able to reach 120 fps in a cinema...

24 looks fine in cinema. Very different experience compared to TVs.

I agree 120 fps may look like more a videogame than a film. However, 3D content should be in 48 fps, like for SDR DCP.

When I first watched a film in HFR, I felt like watching actors on a stage behind a very clean window.
3D Stereo needs twice the fps for sure.