Dolby Vision now possible through MP4 Mux.

[spl147]

do we need to download ALL these tools listed in the readme seperately?

[speeddemon]

Why set the project to CMv4.0 instead of CMv2.9 then? Would you not get better results just initially setting to CMv2.9 to avoid the issues you demonstrated here with CMv2.9 when CMv4.0 analysis is used?

This video doesn't show issues. It just shows the difference between the format.
CMV4.0 is the latest dolby algo and it produces better metadata and Dolby recommends using it even if you're going to deliver in CM v2.9

NOTE It’s currently recommended for all users to choose Dolby Vision v4.0 for analysis
and trimming, as it provides superior results. If you’re required to deliver Dolby Vision v2.9
metadata when mastering for backwards compatibility, DaVinci Resolve can now export
v2.9 metadata from projects using v4.0 workflows.

Maybe it's just the camera, but it looks to me like CMv4 analysis presented in CMv2.9 is crushing shadows in this image:


Is that not the case in real life?

[RESET_9999]

My camera dynamic range is very limited. it will always make the black crush or blown highlight worse than they are in reality.
In reality that shot does look darker but not as crushed as you can see in the video. The video just shows how avg_pq metadata generation is different in cmv4.0.
If you compare cmv4.0 vs cmv2.9 with the same L1, its closer but overall, CMV4.0 always outperforms 2.9.
https://www.youtube.com/watch?v=c8aySWARxyM

FYI, most of the movies(90%+) are done in CM v4.0 but delivered in CM v2.9. You can know that by looking at the avg_pq metadata minimum: 10nits in 4.0 and 2.5nits in 2.9.

[speeddemon]

My camera dynamic range is very limited. it will always make the black crush or blown highlight worse than they are in reality.
In reality that shot does look darker but not as crushed as you can see in the video. The video just shows how avg_pq metadata generation is different in cmv4.0.
If you compare cmv4.0 vs cmv2.9 with the same L1, its closer but overall, CMV4.0 always outperforms 2.9.
https://www.youtube.com/watch?v=c8aySWARxyM

FYI, most of the movies(90%+) are done in CM v4.0 but delivered in CM v2.9. You can know that by looking at the avg_pq metadata minimum: 10nits in 4.0 and 2.5nits in 2.9.

Thanks for the explanation!
What would it take to actually export properly in CMv4 outputting proper L2 & L8?
Also, how far off are these results from what a professional colorist would come up with?

[RESET_9999]

What would it take to actually export properly in CMv4 outputting proper L2 & L8?
Also, how far off are these results from what a professional colorist would come up with?

You can't edit L2/L8 without a DV license so what you get is the default values from the dolby algo.
see my explanation of why you should remove them here: viewtopic.php?p=137417#p137417

[speeddemon]

What would it take to actually export properly in CMv4 outputting proper L2 & L8?
Also, how far off are these results from what a professional colorist would come up with?

You can't edit L2/L8 without a DV license so what you get is the default values from the dolby algo.
see my explanation of why you should remove them here: viewtopic.php?p=137417#p137417

Is that a Dolby Encoding Engine license or a special DaVinci DV license? I'm wondering if I already have access to that through my work.

[RESET_9999]

Is that a Dolby Encoding Engine license

DEE license is not the same AFAIK...
The one available in the cracked version online does not work in resolve.

[valington]

Is that a Dolby Encoding Engine license

DEE license is not the same AFAIK...
The one available in the cracked version online does not work in resolve.

Please give me a TOOLS PACK latest version

[speeddemon]

What would it take to actually export properly in CMv4 outputting proper L2 & L8?
Also, how far off are these results from what a professional colorist would come up with?

You can't edit L2/L8 without a DV license so what you get is the default values from the dolby algo.
see my explanation of why you should remove them here: viewtopic.php?p=137417#p137417

I processed Mario (2023) with your 1080p scaling settings and original 2160p non-scaled settings with both v4 and v2.9 analysis to see the difference in results. The overall summary seems to be:
1. v4 always results in higher L1.
2. v4 seems to not be quiet as variable in the L1 plot.
3. 1080p cubic appears to not have as dramatic of peaks in the L1 plot.

Here's a comparison between all 4 different options: https://imgur.com/a/OLJ6B7F

Do you know why cubic scaling to 1080p is less variable?
Same question with v4 analysis... any idea why it is less variable?
And, any idea why being less variable is the preferred outcome?
Also, why does the Max/Avg CLL/FALL get lifted higher with v4 analysis? It seems like some of the dynamic detail is lost at the bottom end with v4 analysis.

To my eyes, Mario (2023) "pops" more on my LG C9, C2, and Sony A95K with 2160p v4 analysis. Whether this deviates from the creator's intent or is less accurate is what I'm trying to figure out...

[RESET_9999]

1080p+cubic:
I dont know but of the many tests I did, it is the way to go. The peaks are always identical to madvr and most of the time, VERY close to the studio's original RPU (when they don't cap too much the peaks). Because they cannot directly modify L1 like they can with L2/L8 but they can copy the L1 metadata from one shot to another or blend shots together.

CMV4.0:
No idea why they completely changed the algo for avg_pq. max_pq is indeed higher but it doesn't make a big difference in reality.
raising the avg_pq floor from 2.5 to 10nits makes the low end slightly brighter but avg_pq almost has no effect when the RPU source_pq is 1000nits.

FYI, the earliest version of the CMv2.9 algo was even more dynamic. It didn't have the 2.5nits avg floor and min_pq too didn't have any limit.
see: https://slow.pics/c/WlGwchoE

[speeddemon]

1080p+cubic:
I dont know but of the many tests I did, it is the way to go. The peaks are always identical to madvr and most of the time, VERY close to the studio's original RPU (when they don't cap too much the peaks). Because they cannot directly modify L1 like they can with L2/L8 but they can copy the L1 metadata from one shot to another or blend shots together.

Is there any reason to not just scale in Staxrip while outputting the ProRes file? Seems like an easy way to kill two birds with one stone and work with a smaller ProRes file, but I might be misunderstanding the purpose of this step.

[RESET_9999]

Is there any reason to not just scale in Staxrip while outputting the ProRes file? Seems like an easy way to kill two birds with one stone and work with a smaller ProRes file, but I might be misunderstanding the purpose of this step.

no this will produce wrong l1... its the downscaling in resolve that somehow fix the problem.
I guess you could encode prores to 1080p and set the scaling to 2160p in resolve but I never tried.

[speeddemon]

Is there any reason to not just scale in Staxrip while outputting the ProRes file? Seems like an easy way to kill two birds with one stone and work with a smaller ProRes file, but I might be misunderstanding the purpose of this step.

no this will produce wrong l1... its the downscaling in resolve that somehow fix the problem.
I guess you could encode prores to 1080p and set the scaling to 2160p in resolve but I never tried.

It's such a weird step to produce proper L1. Totally believe you, but just a little baffled on the why. How did you learn about this or was it truly from testing every permutation and comparing results?

[RESET_9999]

It's such a weird step to produce proper L1. Totally believe you, but just a little baffled on the why. How did you learn about this or was it truly from testing every permutation and comparing results?

I always found that my L1 peak was too high compared to the original and madvr so indeed, I tried every setting one by one lol.

I wonder if this could be related to this comment from Stacey Spears (3.):

Speaking of Dolby Vision, so far we have found three issues with it on BD. This has led me to buy the madVR Envy Extreme and bypass Dolby all together.

1. Low Latency is broken on BD. This we have reported before. We are including a hidden test pattern called Dolby Vision Quality Check, targeted at the press, to report on this issue. You can see a sample of the pattern in a recent video by Vincent on his HDTVTest YouTube channel. It shows a big red X when DV is not working correctly.
2. DV on BD is using 709 chroma upsampling. Dolby's tools create proper 2020 downsample, so you get a .5 pixel delay between luma and chroma in the vertical direction.
3. DV seems to be applying some type of horizontal chroma filter on UHD content. Does not seem to appear at HD resolution. This results in a total loss of high frequency chroma detail. Here is the chroma zone plate, the left and right sides of the image should not be luma only. Not sure if this is a player or display side problem yet. Hopefully I will know before the disc ships.

[speeddemon]

CMV4.0:
No idea why they completely changed the algo for avg_pq. max_pq is indeed higher but it doesn't make a big difference in reality.
raising the avg_pq floor from 2.5 to 10nits makes the low end slightly brighter but avg_pq almost has no effect when the RPU source_pq is 1000nits.

I wonder whether the contemporary mastering monitors at the time of Dolby developing the Content Mapping versions is related to the avg_pq floor being raised between specs... I'm guessing the standard mastering display was likely a BVM-X300 OLED when the CMv2.9 spec was developed, and then a BVM-HX310 LCD by the time the CMv4 spec was being developed.

Also, I'm guessing they raised the avg_pq floor for optimized viewing on uncalibrated consumer displays since most either crush or wash out shadows.

It would be amazing if Dolby were more open about this stuff.