Log in

View Full Version : [DoVi_Scripts] Multi-Function Scripts for Dolby Vision processing and a lot more...


Pages : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

en6ads
8th June 2025, 20:32
I was expecting that answer from Kuler....

He'd probably need to buy an Intel GPU, and why should he, when nVidia is the way to go.

I bought a 4080 Super (with the 9950X3D) just to use DS better, I now also have a 5070 Ti, (with the 7970X) but I've yet to use it with DS...be interesting to compare.

What CPU have you got ??

what average framerate do you get software encoding (x265) a baking FEL workflow 8-2-1? I tried my first FEL bake with default settings (Mission Impossible Fallout) and got 1.5fps!! Plus the output was 15gb smaller than the source (84gb vs 69gb output). I wasn't pleased with the baked image either, doesn't look as good as the original base layer.

Kuler087
8th June 2025, 21:30
There is no visual difference between the original FEL P7 and the script 8-2-1 (FEL baked) output. The script’s default settings produce quality that is very close to the source, but the output size in a CRF encode will depend on many factors such as the complexity and type of the source: grain, dark scenes, bright scenes, action, letterboxing, etc. In the end, regardless of the output size or bitrate, the compression quality remains consistent, and you may notice that some P7 FEL grainy action movies can result in a higher bitrate than the original source so you may want to increase CRF to 17-18 for those and reduce it to 13-14 for the cleaner darker movies.

Do a screenshot comparison in 7-2 if you are not sure. EG: https://slow.pics/c/bQQ40JlG


I get about 3-4fps depending on the source type with my i9 13900ks with the script default settings (CRF-15 with slow preset)
https://i.ibb.co/TBDfhQjZ/Windows-Terminal-d-Lqfj-RQYpf.png

Gatorman3385
8th June 2025, 21:40
Encoding a FEL Baked x265, I average 1.5fps with a Ryzen 2700X. The AM5 platform is at least twice as fast.

coopzr
14th June 2025, 07:05
I've played around with the ProRes encoding settings.

The default setting is:
set PRORES_settings=-c:v prores_ks -profile:v 3 -vendor apl0 -qscale:v 1 -pix_fmt yuv422p10le -an -hide_banner -y
I can conclude that qscale 1 is almost identical to using qscale 0 (which is the same as removing the qscale parameter entirely).

qscale 0 encodes at a lower bitrate than qscale 1 and appears to be a viable solution for those who are limited on storage capacity. I observed 200-300GB file size reductions in my tests. It's worth noting, however, that using qscale 0 doubled the encoding time, at least with my hardware.

I also compared other qscale settings: 2, 5, 9, and 11. While the final product would probably be indistinguishable to the human eye, the HDR and cm-analyze measurement graphs differed much more from each other compared to qscale 0 vs 1.

All other qscale settings I tested had slightly different scene cut detections, nits, and so on. qscale 0 and qscale 1, however, each had the same scene cut detections, and the nits only differed by 0.1 nits on some occasions.

I then ran each ProRes test through cm-analyze, and qscale 0 vs qscale 1 were once again almost identical. See the comparisons below - you need to zoom in quite close to see any differences in the charts.

In my circumstances, I'll continue to use qscale 1 since it's twice as fast. However, some movies will encode over 1TB, like one of the John Wick movies did, so then I'd have to encode it with qscale 0 for a significant reduction in file size, as I only have a 1TB hard drive.

Just thought I'd share my findings.

Comparisons:

Deepwater Horizon (https://slow.pics/c/xh3YTgj5)
John Wick Chapter 3 (https://slow.pics/c/OLrSMv9R)
Hunger Games Mockingjay Part 1 (https://slow.pics/c/wmXTOtTy)
Hunger Games Mockingjay Part 2 (https://slow.pics/c/t8EGVGB8)
Us (2019) (https://slow.pics/c/3HnXwZ80)

LLM disclaimer: I used an LLM to format this message to make it legible and free from grammatical errors, because I am lazy.

Kuler087
14th June 2025, 14:39
thanks for the tests/comparisons man

tormento
15th June 2025, 09:58
Open the measurement file in the analyzer and look at the 99% peak values

Which one, of the many ones, should I choose?

P.S: Is madMeasureHDRDynamicOptimizer of any use? In my case, I just want to feed PQ2HLG to have a proper lut file.

ac777103
15th June 2025, 12:16
Using 3.0.7 I am having a problem demuxing my disc-sourced UK John Wick 4 to BL and EL hevc files. When I go to workflow 1 and select V for Remover, I get an hevc file for the EL but no BL file (though it's created in the temp folder while the work is in progress. At the stage where the script says "Muxing to MKV" I get the following:

mkvmerge v88.0 ('All I Know') 64-bit
Error: An empty file name is not valid.
Deleting TEMP folder...
WARNING. Input frame rate seems messed up, it was forced to 23.976 but you should fix it in 2-1-3...

The input file is direct disc to mkv via makemkv, any ideas?

Kuler087
15th June 2025, 13:45
Which one, of the many ones, should I choose?

P.S: Is madMeasureHDRDynamicOptimizer of any use? In my case, I just want to feed PQ2HLG to have a proper lut file.

I don't know. Take one that makes more sense to you.

The optimizer was for madvr playback IIRC

Kuler087
15th June 2025, 13:48
Using 3.0.7 I am having a problem demuxing my disc-sourced UK John Wick 4 to BL and EL hevc files. When I go to workflow 1 and select V for Remover, I get an hevc file for the EL but no BL file (though it's created in the temp folder while the work is in progress. At the stage where the script says "Muxing to MKV" I get the following:

mkvmerge v88.0 ('All I Know') 64-bit
Error: An empty file name is not valid.
Deleting TEMP folder...
WARNING. Input frame rate seems messed up, it was forced to 23.976 but you should fix it in 2-1-3...

The input file is direct disc to mkv via makemkv, any ideas?

I may have broken something when I added batch support.. Try directly with 2-2

EDIT: This should fix it. https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=sharing
you must update your dovi_tool.exe for the latest beta.

ac777103
15th June 2025, 14:18
I may have broken something when I added batch support.. Try directly with 2-2

EDIT: This should fix it. https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=sharing
you must update your dovi_tool.exe for the latest beta.

thanks, 2-2 worked with the script version I already had, will check out your update.

ac777103
15th June 2025, 20:12
I may have broken something when I added batch support.. Try directly with 2-2

EDIT: This should fix it. https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=sharing
you must update your dovi_tool.exe for the latest beta.

DV removal via worflow 1 is working with the new beta, thanks for posting it so quickly.

Kontrarian
15th June 2025, 21:58
you must update your dovi_tool.exe for the latest beta.

Link?

Is it in the latest DoVi.Scripts.7z from your github?

Kuler087
15th June 2025, 21:59
https://github.com/quietvoid/dovi_tool/releases

Kontrarian
17th June 2025, 07:33
Ah, thank you!

wyup
17th June 2025, 10:27
Which MaxCLL/MaxFALL detection method is more accurate and reliable: Dolby (cm_analyze), MadVR or DavinciResolve (HDR10+ pass)?
I'd like to have the best estimated values for accurate HDR10 static metadata to further apply libplacebo tonemapping algorithms that take in account specially MaxCLL as source dynamic range limit..
Can I assume that Dolby cm_analyze is the best method as it is calculated by the most respected company?

I would also like to have reliable minimum brightness levels to narrow down the dynamic range (max and min values) to tonemap to SDR. I also try different max values for SDR, since libplacebo chooses 203 nits by default instead of standard 100 nits to encompass more dynamic range. Being SDR a relative system, if you can agment SDR brightness you can store more than 100 nits in SDR, since pure black is anchored the same. I'd only lose gradation.

Kuler087
17th June 2025, 11:53
madvr is the way to go.
DV metadata can vary significantly due to tuning or its restrictions(100/10nits min), and its average_pq is not representative of the actual average at all.

wyup
17th June 2025, 13:34
okay.. well, anyway it'd be nice to have DV cm_analyze plotter in menu 6 to compare to madVR. I've tried 6-3 but it doesn't work if the file doesn't have RPU already.

I am surprised that madVR method, which is not actively developed anymore (only betas from time to time) and made by a single person, madshi, can do better than Dolby own official tool.

Kuler087
17th June 2025, 14:02
It's not that MadVR does better than Dolby.
DV is meant for playback, and the metadata can be manipulated to adjust the tone mapping aggressiveness.
madMeasureHDR.exe just measures the pixels as they are.

You can see how the DV metadata can vary depending on the Dolby algorithm or tuning: https://slow.pics/c/OA0pupEN




anyway it'd be nice to have DV cm_analyze plotter in menu 6 to compare to madVR.
You can plot the CM_anlayze XML/RPU output in 6-2.

bbeny123
17th June 2025, 22:16
Hi @Kuler087

I’ve got a quick question about cm_analyze.

In some scenes, there’s a 1-pixel-high line at the very top or bottom edge of the image that’s much darker than the rest — likely an encoding artifact or gradient into the black bars.

Would you recommend treating that line as part of the image, or should it be treated like a black bar and excluded from analysis using --letterbox?

Thanks in advance!

Examples:
Top:
https://i.imgur.com/x9ydl6l.png
Bottom:
https://i.imgur.com/A1opYEn.png

Kuler087
17th June 2025, 22:30
yep, I always exclude those dirty letterbox edges from the analysis.

bbeny123
17th June 2025, 22:40
Thanks! That makes perfect sense.

Just to double-check — does the same approach apply to L5? Or should L5 contain only the actual black bars?

Kuler087
17th June 2025, 22:42
yes, I always keep the same offsets as the analysis for L5

wyup
18th June 2025, 00:08
You can plot the CM_anlayze XML/RPU output in 6-2.
6-2 is not cm_analyze and extract maxCLL/maxFALL exclusively with cm_analyze.exe tool, but Measure MadVR HDR tool. I don't want to measure with madMeasureHDR.exe, I want to measure the ProRes.mov conversion with cm_analyze. MadVR measure produces the MadVR plot, but I want to get the Dolby L1 plot, just as you show in your captions.
If I do 6-2 on a HDR10 non-DV video, it exits with error: no RPU found.


It's not that MadVR does better than Dolby.
DV is meant for playback, and the metadata can be manipulated to adjust the tone mapping aggressiveness.
madMeasureHDR.exe just measures the pixels as they are.
You can see how the DV metadata can vary depending on the Dolby algorithm or tuning: https://slow.pics/c/OA0pupEN

Well, I'd like to obtain your Dolby L1 plots aswell but don't know how.
I can see that there are variations in MaxCLL and MaxFALL in the various Dolby plots you link depending on cmv version and tonemapping algorithm. I can see there is a a lot of variation between oroginal HDR10+ plot and madVR plot aswell. :confused:

Kuler087
18th June 2025, 00:21
6-2 is not cm_analyze and extract maxCLL/maxFALL exclusively with cm_analyze.exe tool, but Measure MadVR HDR tool. I don't want to measure with madMeasureHDR.exe, I want to measure the ProRes.mov conversion with cm_analyze. MadVR measure produces the MadVR plot, but I want to get the Dolby L1 plot, just as you show in your captions.
6-2 uses madVR only if you input a video file.
When you input CM Analyze metadata (XML or RPU), the script just plots the data and does not use madVR at all.

In the end, both 6-2 and 6-3 use dovi_tool to plot the metadata, regardless of whether it comes from madVR, CM, Resolve, or HDR10+.





I can see there is a a lot of variation between oroginal HDR10+ plot and madVR plot aswell.

Right, because just like DV, HDR10plus is meant for playback.
madmeasureHDR.exe will always be more representative of the actual brightness.

Well, I'd like to obtain your Dolby L1 plots aswell but don't know how.
what do you mean? You can obtain any L1 plot with 6-3.

wyup
19th June 2025, 18:42
6-2 uses madVR only if you input a video file.
Precisely what I intend is to input a HDR10 only video file to be measured with cm_analyse only, that's to say, to obtain a DV Level 1 plot such as those screenshots you link above. Maybe 3 - 1? But I don't need to create a DV stream, only measure its MaxCLL and MaxFALL for comparison sake.
Right, because just like DV, HDR10plus is meant for playback.
Wht do you mean playback? I just want to measure the video, not create any playback stream, be DV or HDR10+. In principle, I don't need any DV tonemapping variants to measure a video.
what do you mean? You can obtain any L1 plot with 6-3
6-3 doesn't obtain any plot without DV RPU.

Kuler087
19th June 2025, 23:33
Wht do you mean playback? I just want to measure the video, not create any playback stream, be DV or HDR10+. In principle, I don't need any DV tonemapping variants to measure a video.
HDR10plus and DV metadata are meant to be used during playback for tone mapping. They don't always represent the actual brightness (1:1) of the shots.

Precisely what I intend is to input a HDR10 only video file to be measured with cm_analyse only, that's to say, to obtain a DV Level 1 plot such as those screenshots you link above. Maybe 3 - 1? But I don't need to create a DV stream, only measure its MaxCLL and MaxFALL for comparison sake.
You have to analyze the whole video with CM (3-1) or Resolve to get the MaxCLL/FALL value from the Dolby algorithm. Then you can plot the data generated in 6-2 or 6-3.
CM also has an option to calculate L6 MaxCLL/FALL, but the script doesn’t use it because it creates values with decimals that dovi_tool couldn’t convert to RPU directly. It would be easy to fix, but I just don’t care enough about L6.

https://i.ibb.co/gMQ2FLvb/firefox-u-JAR8u-Bbwz.png

SamuriHL
20th June 2025, 15:45
I'm clearly missing something stupid. If anyone can shed any light on what I'd be most appreciative. Sorry if this has already been answered.


Faulting application name: AvsPmod.exe, version: 2.7.5.5, time stamp: 0x4918017b
Faulting module name: avisynth.DLL, version: 3.7.5.0, time stamp: 0x6805a882
Exception code: 0xc0000005
Fault offset: 0x000000000011ab10
Faulting process id: 0xCBF4
Faulting application start time: 0x1DBE1F198137B75
Faulting application path: D:\DoVi_scripts\tools\AvsPmod\AvsPmod.exe
Faulting module path: C:\WINDOWS\SYSTEM32\avisynth.DLL
Report Id: 755b43aa-00cd-4b43-ac50-34973fca280b
Faulting package full name:
Faulting package-relative application ID:


Trying to run 6-1 to measure the letter box on The Hunger Games. Thanks!!

coopzr
20th June 2025, 16:04
I know how to edit an RPU to add variable L5, but how do I generate DV with variable L5?

Kuler087
20th June 2025, 16:16
I'm clearly missing something stupid. If anyone can shed any light on what I'd be most appreciative. Sorry if this has already been answered.


Faulting application name: AvsPmod.exe, version: 2.7.5.5, time stamp: 0x4918017b
Faulting module name: avisynth.DLL, version: 3.7.5.0, time stamp: 0x6805a882
Exception code: 0xc0000005
Fault offset: 0x000000000011ab10
Faulting process id: 0xCBF4
Faulting application start time: 0x1DBE1F198137B75
Faulting application path: D:\DoVi_scripts\tools\AvsPmod\AvsPmod.exe
Faulting module path: C:\WINDOWS\SYSTEM32\avisynth.DLL
Report Id: 755b43aa-00cd-4b43-ac50-34973fca280b
Faulting package full name:
Faulting package-relative application ID:


Trying to run 6-1 to measure the letter box on The Hunger Games. Thanks!!

Did you install avisynthplus?

https://github.com/AviSynth/AviSynthPlus/releases/download/v3.7.5/AviSynthPlus_3.7.5_20250420_vcredist.exe

Kuler087
20th June 2025, 16:19
I know how to edit an RPU to add variable L5, but how do I generate DV with variable L5?

I do it in resolve.
https://drive.google.com/drive/u/0/folders/1rXUfhEgNvPdntbNl3EJ8D4rHG4XNSy8x

1- import scene cuts in resolve https://www.youtube.com/watch?v=KVx01kCLLS8
2- go shot by shot and adjust blanking per clip https://www.youtube.com/watch?v=FVSh3oGqfXY
3- export XML and convert to rpu.
4- transfer L5 (2-3)

SamuriHL
20th June 2025, 16:19
Did you install avisynthplus?

https://github.com/AviSynth/AviSynthPlus/releases/download/v3.7.5/AviSynthPlus_3.7.5_20250420_vcredist.exe

Yup. Definitely didn't miss that step. I reinstalled it last night to make sure I was on the latest version.

Kuler087
20th June 2025, 16:21
Can you launch avspmod in
\DoVi_Scripts\tools\AvsPmod\AvsPmod.exe

Kuler087
20th June 2025, 16:25
Do you have an older version of the tool pack? the old avspmod version doesn't work with the latest avisynthplus

SamuriHL
20th June 2025, 16:37
I may. I'll try grabbing the latest. I'm not able to launch avspmod.exe, that's what triggers the error I posted earlier. I worked around the problem for now by finding the crop values another way. I'm exporting my first DV xml! :)

SamuriHL
20th June 2025, 17:40
Updating tools fixed it. Sorry for the distraction. Thanks again for your amazing work! Watching The Hunger Games now. Not a great test as it's like 500 nits max but still the process worked! Time to upgrade to Resolve 20. Any Dolby changes we should be aware of in 20?

Kuler087
20th June 2025, 17:51
Glad it worked :)

no change for our dv workflow in v20

wyup
20th June 2025, 20:19
CM also has an option to calculate L6 MaxCLL/FALL, but the script doesn’t use it because it creates values with decimals that dovi_tool couldn’t convert to RPU directly. It would be easy to fix, but I just don’t care enough about L6.
I do care about L6 MaxCLL/FALL because it is 'as per the blu-ray document', precisely what I want and it produces a xml file to extract the values, no need to convert to RPU, no problem with decimals. This way I don't have to do 3-1 and then 6-3, plus it's not L6. Why create a Dovi file when all I need is to CM plot?

There should be a new Plotter option to Dolby cm_analyse L6 with automated Prores conversion and manual/auto crop.

Kuler087
20th June 2025, 20:31
Just edit the script and add the L6 cmd here:

https://i.ibb.co/ZzfkjT5q/Windows-Terminal-8v-Ckiy-CYXG.png

Kuler087
20th June 2025, 20:59
Actually, I just tried the latest dovi_tool and XML +L6 with decimal now works...

Added in the latest beta (3-1):
https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link

coopzr
21st June 2025, 04:36
Do you think you could show the words "Dynamic L5" in the summary if workflow 1 input has a variable L5?

Kuler087
21st June 2025, 04:55
no, but you can use the metafier for that.

https://i.ibb.co/FkKLjBM3/Windows-Terminal-k9-I1-DA4-SKS.png

coopzr
22nd June 2025, 23:42
Oh, awesome, thats easy.

Just been having a look at metafier and I've found that cm-analyze and resolve produce slightly different DV. The L1 plot is also slightly different.

18975

Have you noticed this?

Kuler087
23rd June 2025, 00:35
yes and it doesnt matter.

wyup
23rd June 2025, 12:09
Actually, I just tried the latest dovi_tool and XML +L6 with decimal now works...

Added in the latest beta (3-1):
https://drive.google.com/file/d/128gq8aDUTKA_aT7SQsM9dkjA1EP1sosR/view?usp=drive_link

I'm doing 3-1 from that beta on a HDR10 video and it is running madMeasureHDR.exe instead of cm_analyse!:angry:
I want to do a cm_analyse pass with L6 to get MaxCLL and MaxFALL.
And it's talking a super long time, and not converting to ks ProRes, just reading .hevc...
Doesn't cm_analyse need ProRes source?

Kuler087
23rd June 2025, 12:27
CM_analyze cannot detect scene cuts, so madVR is used first to generate them. Then, the video is converted to ProRes, and CM performs its analysis.
If you want to skip scene cut detection, enable frame-by-frame analysis in the settings.

:: choose if you want to force frame by frame analysis in 3-1 (default = NO)
set force.FBF=NO

wyup
25th June 2025, 13:26
CM_analyze cannot detect scene cuts, so madVR is used first to generate them.
set force.FBF=NO
By curiosity, how does madVR detect and generate scene cuts and why is it necessary for cm_analyze in 3-1? Dolby Vision generation is independent of madVR, isn't it?

Kuler087
25th June 2025, 14:00
madVR has its own scene cut detection algorithm(worse than Resolve algo). CM and all versions of the Dolby algorithm (Resolve, Transkoder, etc.) do not include scene detection and require an external shot list generated by a third-party tool (automatically or manually).
Just enable CM frame-by-frame analysis to bypass the shot list.

wyup
25th June 2025, 14:59
SDR is not really 100 nits, it is a convention for minimum requirements for a SDR set. Never in the history of television has been 100 nits a hard limit nor a mastering requirement of SDR content. It has been attributed to approx 100 nits in the 2010s to compare it with HDR.

SDR is a relative system. It can scale to whatever brightness capacity.
100 nit is a convention for its minimum viewing requirements. According to Wikipedia source Flatpanels link it "assumes" a max of around 80-120 nits (or cd/m2) and a minimum (black depth) of around 0.05 cd/m2 (or 0.1 nits according to others) for living room TVs. Or as it says "able" to represent a maximum of 100 nits of old CRT displays, but not modern displays.

In reality, wikipedia defines SDR as Rec.709 or sRGB color gamut and gamma curve. Gamma curve is about 2.2 or 2.4 of BT.1886 for HD. There is no nits or cd/m2 requirement.

When placing SDR into a HDR container to compare both sources, we are hard limiting SDR to inferior dynamic range than it is capable, be 100 nits, and not representative of the potential of the image.
I insist, when grading SDR for mastering, there is no requirement to do it at 100 nits or viewing at 100 nits. 100 nits is a minimum assumption for SDR capability, not for a mandate requirement for reproduction.

When converting SDR to HDR by Dovi Script 6-2 Plotter function, script is doing an AviSynth Convert Format to YUV420P10 from Rec709 to Rec2020 and then ffmpeg conversion to ProRes. Yes, it places SDR into 100-nit value for PQ, but that follows the previous "convention" of plotting SDR to 100 nits. In reality, inverse tone-mapping should be applied to compare to the destination PQ range. I.e: if the HDR content is under x nits, SDR sould be inverse tonemapped with Bt.2446 for example to same average nits and placed into the HDR container at that similar dinamic range for comparison. That is because we don't see or need to see SDR content at 100 nits, we see it at whatever brightness we see fit. Same as HDR. Therefore if we are evaluating HDR and SDR source content we need to equalize them at the same dinamic range for a meaningful comparison. As i said, 100 nit is not a requirement for SDR viewing at all. Nobody said movies are graded at 100 nits for SDR.

When a SDR plot shows a graph under 100-120 nits, that is because it has been converted to HDR beforehand, it is not a native measurement in SDR, and YCC 8-bit values are mapped from 235 to 100 nits.

Additionally, there is a mismatch when evaluating SDR stills from HDR using libplacebo library that tonemaps HDR to SDR from 0.202 to 203 nits by default, NOT 100. It is using a specific tonemapping for comparison. It is the same as converting SDR to HDR and placing in 100 nit range, it is a arbitrary decision about downmapping it. SDR can display its 8-bit range to more than a 100-nit image with great and correct results. The 100 nit range is a decision of the avisynth Convert function.

I will always be an advocate for SDR to HDR comparison with inverse tonemapping from SDR to HDR at the same average destination brightness of the source maximum brightness, using for example Bt.2446 tonemapping algorithm, which is in my opinion the best for well mastered content.

I don't think that placing SDR into HDR at 100 nits is leaving it 'untouched'. You are in practice limiting its dynamic range to a subset of destination range. 100 isn't appropiate in a PQ of 10,000 nits and 10 bits.

When filmakers choose to master their films at HDR PQ within 100-200 nits they are actually restricting available gradation of dynamic range. They could grade with the same results at 1,000 nits at the same source dinamic range, it will have more granularity or headroom. We forget that PQ at 10-nits is at the limit of perceived granularity for covering 10,000 nits, it has been said that 12-bit would be more appropiate. So it doesn't make sense to map a modern film to 100 nits, you are needlesly approacing that limit. Probably SDR at 10-bits has more granularity of dynamic range than 100 nits in PQ, when we don't have or need the highlights, as in celluloid. Bear in mind that commercial movies are graded at 12 bits in 2.6 gamma and about 48 nits of minimum requirement. Nits are not that important, what is important is the gradation of the available dynamic range.

Kuler087
25th June 2025, 15:21
Yes, I know all of this and the script does NOT limit the output to 100 nits!! You are incorrect and cleary don't understand how SDR is graded.
It places the content UNTOUCHED into an absolute HDR container without touching the original brightness. I literally have hundreds of SDR plots in my comparisons that show that, and it is all explained how SDR is elastic and relative to your TV brightness.

Do you see this SDR plot as capped at 100 nits? No and please do not start an argument about this here. I do not care about people's opinions who watch SDR on an uncalibrated TV with more than 120nits. I also do not care how HDR gets tone mapped to SDR by any algo.


https://i.ibb.co/9kJNkjfr/The-Mitchells-vs-the-Machines-2021-Kaleidescape-4-K-UHD-HDR-WEB-REVIEW-ANALYSIS-vs-1080p-BD-SDR-100ni.png

wyup
25th June 2025, 15:56
Yes, I know all of this and the script does NOT limit the output to 100 nits!!
It places the content UNTOUCHED into an absolute HDR container without touching the original brightness. I literally have hundreds of SDR plots in my comparisons that show that, and it is all explained how SDR is elastic and relative to your TV brightness.
Do you see this SDR plot as capped at 100 nits?

The SDR content is NOT untouched because you do a colorspace conversion to put it into PQ: you convert matrix coefficients from Rec.709 to rec.2020 and gamma curve from BT.1886 to PQ, and it maps luminance to PQ range to a limit.
If you look at the graph, average MaxCLL is consistent at 102 nits, which is probably the 235 white from SDR.
SDR content has superwhites above 235 luminance, that is why you see values over 100 nits, max 165 nits. That is why all SDR graphs fall under 160 nits. It is a limit of the colorspace conversion.

SDR at tv range is 16 to 235 values in luminance. That is mapped to PQ at around 100 nit range, it's not infinite. 100-160 nits is headroom, it doesn't mean much. It all comes from the 100-nit assumption of SDR from the colormap conversion.

The Average-Joe calibrated TV is meaningless. Nobody sees SDR at 100 nits, calibrated or uncalibrated.