AVS Forum banner

madVR Tool: MadmeasureHDR Optimizer (Measurements, Dynamic Clipping & Target Nits)

318K views 1K replies 110 participants last post by  ksof 
#1 · (Edited)
madVR Tool: MadmeasureHDR Optimizer (Measurements, Dynamic Clipping & Target Nits)

This Thread will be dedicated to our tool "MadmeasureHDR Optimizer" to help optimize measurements files generated by the process "MadmeasureHDR" from beta 38 onwards.


Please use madVR Beta V40 in combination with this tool:
http://madshi.net/madVRhdrMeasure40.zip

It was previously called madmeasure dynamic clipping tool since it all started with dynamic clipping.

Now the tool can also automatically choose a Target Nits in the measurement file for a movie.

More importantly, it can adjust dynamically the target nits DURING the movie in order to optimize the brightness and picture contrast at all time. :)


ps: goal is to offset the discussions about the tool here instead of the original madvr HDR Tone mapping developpement thread:
https://www.avsforum.com/forum/24-d...mproving-madvr-hdr-sdr-mapping-projector.html


The main focus of the measurement file and its optimization through our tool is to improve quality of madVR HDR tone mapping.

1 - madVR SETUP tutorial and explanations

2 - Madmeasurehdr Optimizer Tool Tutorial (German, please use google translate)

3 - Explanation / Tutorial for the dynamic tone mapping ala madVR (German, please use google translate)

Here a bit of explanation /history:

1) The measurement process was introcuded by Madshi to know in advance all the scenes cuts and all the frames peak nits.
Initial goal was there to get rid of ANY unwanted clipping (through knowledge of the future) while changing the peak value used in the tone mapping with a fixed speed to stay invisible.
-->The LIVE algo does not know what are the next frame which are coming. Therefore if it's currently tone mapping up to 500nits, but the next frame peak is 2000nits, it will NOT tone map to 2000nits because it would create visible flicker. Instead, it will maybe tone map slightly higher than 500nits, maybe 510nits, and everything between 510nits and 2000 will be clipped.

2) Then, madshi explained us the structure of the measurement file and we created in the tool something called "dynamic clipping".
For every frame, we look for a highlight knee to overwrite the real frame peak with an "effective peak" to gain back brightness and contrast/HDR in the picture at the cost of clipping only a few pixels above the said detected "highlight knee".
The algo was partially implemented in the LIVE algo, but because of 1), it can lead to visible clipping since it then combines the uncontrolled clipping of the LIVE algo + the controlled clipping from the dynamic clipping. That's why most people keep "dynamic clipping" deactivated in the LIVE algo but keep it activated at 100% with the optimizer tool to get an extra "punch in the picture".

3) Then we wanted for a long time to try out a "dynamic Target nits" per frame. For Christmas , madshi allowed the measurement file to hold such "Target Nits per frame" so we could play around but there is dynamic target nits present in the measurement file to begin with.
We then started a small journey with the madVR testing community here to develop a nice method and algo for a target nits per frame.
We came up with the FALL algo, chapter detection (containing mutiple camera cut) and centered rolling avg.

Since the the dynamic target nits idea and result was a success, it was implemented by Madshi in the LIVE algo. Only, once again, the LIVE algo does not know the future which means it can get surprised if the FALL gets higher or lower which can result in a too bright or too dark picture when this happen.
Also, to mitigate this, the LIVE algo logic is to reset the target nits at every camera cut, since it is mostly invisible when you do it there.
But, resetting at every camera cut can lead to strong brightness change between 2 following camera cut for 2 persons speaking in the same room or outside (Little girl intro scene in the MEG, Interrogation scene in Venom, are both good examples).

The optimizer tool however has access to the whole movie histogramm per frame saved in the measurement. So it knows in advance what's coming in the future.
Therefore, the tool can completely smooth out all the camera cut and just roll smartly over everything because it knows in advance what's coming and can prepare for it (same logic that was madshi implemented for the peak nits with the measurement).


Conclusion: the LIVE algo looks great in itself but since it cannot know the far future it has limitation that the optimizer tool together with the measurement file does not have.
So best quality, per frame but also smoothness wise will be adchieved with the measurement process introduced by madshi.
In itself, the LIVE algo still looks pretty awesome and does not need any measurement and can/will be integrated in the ENVY to get madVR awesome tone mapping for ANY source!

Like always, the last few percent of quality are always the hardest to achieve, and therefore that's not always for "everybody".
Here it means you have to perform a full measurement of the movie before hand and optimize it. So you loose the convenience of just starting a movie at anytime IF you did not do those steps yet.
But the tool makes those steps simple, even it measurement stays time consuming (~15min per movie with a GTX1080ti).


Hopes this clarify what our tool is for.
And my thanks to Madshi for making all this possible!

Flo
UPDATE 2019-08-25
V4.0.2
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-40.html#post58469164

UPDATE 2019-07-20
V4.0.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-36.html#post58319000



UPDATE 2019-05-27
V3.9.3
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-35.html#post58104732

UPDATE 2019-05-23
V3.9.2
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-35.html#post58089690

UPDATE 2019-05-19
V3.9.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-35.html#post58069964

UPDATE 2019-05-18
V3.8.8
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-35.html#post58065216

UPDATE 2019-05-12
V3.8.7
https://www.avsforum.com/forum/26-home-theater-computers/3040072-madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits-34.html#post58035720

UPDATE_ 2019-03-17
V3.7.9
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-31.html#post57761800


UPDATE: 2019-03-10
V3.7.7
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-29.html#post57723936


UPDATE: 2019-02-13
V3.6.2
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-26.html#post57597756

UPDATE: 2019-02-09
V3.6.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-25.html#post57575494

UPDATE: 2019-02-06
V3.5.8
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-24.html#post57561252

UPDATE: 2019-02-03
V3.5.6
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-22.html#post57544558

UPDATE: 2019-01-21
V3.5.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-17.html#post57475508

UPDATE: 2019-01-20
V3.4.1
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-16.html#post57468496

UPDATE: 2019-01-19
V3.4.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-15.html#post57464522

UPDATE: 2019-01-19
V3.3.3
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-15.html#post57463528

UPDATE: 2019-01-16
V3.3.2
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-13.html#post57448962


UPDATE: 2019-01-14
V3.3.1
https://www.avsforum.com/forum/26-home-theater-computers/3040072-madvr-tool-madmeasurehdr-optimizer-measurements-dynamic-clipping-target-nits-12.html#post57437966

UPDATE: 2019-01-13
V3.3.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-11.html#post57431312

UPDATE: 2019-01-13
V3.2.0
https://www.avsforum.com/forum/26-h...mic-clipping-target-nits-10.html#post57428292

UPDATE: 2019-01-09
V3.1.0
https://www.avsforum.com/forum/26-h...amic-clipping-target-nits-8.html#post57408890


UPDATE: 2019-01-08:
V3.0.0
https://www.avsforum.com/forum/26-h...amic-clipping-target-nits-7.html#post57401504


UPDATE: 2019-01-06
V2.9.9
http://projectiondream.com/wp-content/uploads/2019/01/madMeasureDynamicClipping-V2.9.9.zip

UPDATE: 2019-01-04
V2.9.8
http://projectiondream.com/wp-content/uploads/2019/01/madMeasureDynamicClipping-V2.9.8-Download.zip
:D
 
See less See more
1
#305 ·
Strange thing:

When "high" values for "Minimal chapter duration in frames" and "Time for rolling average in frames" are defined, the target seem to be most of the time not moving at all inside the chapter.

The "Time for rolling average in frames" does not seem to be in use.

I tested with these settings:

Algo: Flo Chapter
Minimal target nits / real display peak nits: 100
Maximal target nits: 10000
Time for rolling average in frames: 1440
Dynamic Target Nits Tuning [50-100]: 100
Merge scenes [FALL change in %]: 325
Minimal chapter duration in frames: 480
Merge chapters [avgFALL change in %]: 0

The Meg with madMeasurementAnalyzer:

 
#308 ·
Strange thing:

When "high" values for "Minimal chapter duration in frames" and "Time for rolling average in frames" are defined, the target seem to be most of the time not moving at all inside the chapter.

The "Time for rolling average in frames" does not seem to be in use.

I tested with these settings:

Algo: Flo Chapter
Minimal target nits / real display peak nits: 100
Maximal target nits: 10000
Time for rolling average in frames: 1440
Dynamic Target Nits Tuning [50-100]: 100
Merge scenes [FALL change in %]: 325
Minimal chapter duration in frames: 480
Merge chapters [avgFALL change in %]: 0

With rolling avg set to 1440 frames, any chapter shorter than 1440 frames (1min) will have a constant target nits.

Also what is new: if it's a 2 minutes chapter, what will happen is the following:
First and last 30s will be hold to a constant target nits because they don't have enough frames to build the avg. See my explanation in the release note.

So I don't think there is anything strange:)
 
#306 ·
up until now, I didn't feel the need to measure my movies before watching them.
But after seeing ''- Dynamic Target Nits (changing live during the movie)'', I had to try your tool and man, it looks GREAT! I'm now measuring all my files and deleted my profiles :)



THANK YOU so much and keep up your amazing work !!







 
#309 · (Edited)
madmeasuredynamicclipping Tool V3.3.0

Update V3.3.0 :)

The "bug" with madVR is solved ( @Dexter Kane ). Tone mapping is now using properly using the measurement file and madVR OSD is back to what it should look like with measurement.

My thanks to @madshi!
He explained me that you have to SUM the flag and not replace them.
So when he said you should set the flag to "2" to activate dynamic target nits, you have to add it to the "Complete" flag "1" and so you need to put the header flag to "3".
We had it put to 2 (0 + 2) instead.
--> So it considered the file incomplete and that's why LIVE measurement was ON.

Download:
http://projectiondream.com/wp-content/uploads/2019/01/madMeasureDynamicClipping-V3.3.0.zip

:)
 
#313 ·
Update V3.3.0 :)

The "bug" with madVR is solved ( @Dexter Kane ). Tone mapping is now using properly using the measurement file and madVR OSD is back to what it should look like with measurement.

My thanks to @madshi!
He explained me that you have to SUM the flag and not replace them.
So when he said you should set the flag to "2" to activate dynamic target nits, you have to add it to the "Complete" flag "12 and so you need to put the header flag to "3".
We had it put to 2 (0 + 2) instead.
--> So it considered the file incomplete and that's why LIVE measurement was ON.

Download:
http://projectiondream.com/wp-content/uploads/2019/01/madMeasureDynamicClipping-V3.3.0.zip

:)
I haven't had the time to check the results visually, but I wanted to report a small bug in the info you extract from the MadMeasureHDR.exe output.

The original MaxCLL and MaxFALL (those from the metadata) are missing in your details file. We only have the calculated values.

Here is the difference:

MadVR (as saved by my batch file):

Measuring video file "N:\@MadMeasureHDR\Meg (The)\The Meg.mkv" using D3D11 (native)...
Metadata:
Mastering display luminance: 0.005/4000, gamut: 0.68 0.32, 0.15 0.06, 0.265 0.69, 0.3127 0.329
MaxCLL: 4000, MaxFALL: 1193 nits
Measurements:
Frames: 162883, MaxCLL 100%: 4718, 99.9%: 4289, MaxFALL: 2348, AvgFALL: 154, AvgFMLL: 1745 nits

Now the content of your details.txt:
madMasureDynamicClipping V3.3.0 results
----------------------------------------------
madMeasureHDR output (13/01/2019 18:07:37)
Metadata
Mastering display luminance: 0.005/4000
gamut: 0.68 0.32
0.15 0.06
0.265 0.69
0.3127 0.329


Measurements
Measurements:

----------------------------------------------
Header
Version: 6
Header size: 10
Number of scenes: 4831
Number of frames: 162883
Complete flag: 1
MaxCLL: 4718
MaxFALL: 2348
AvgFALL: 154
----------------------------------------------
Calculated values before clipping
Average FMLL: 1745
Avg % of pixels below 100 nits: 80.78
Avg % of pixels below 200 nits: 85.82
% of frames with highlights (>100 nits): 97.99
Avg median of highlights: 333
Avg avg of highlights: 400
----------------------------------------------
 
#310 · (Edited)
Thanks for the explanation.

I find the "Merge chapters" option very useful in addition to "Merge scenes" to get longer chapters (while not merging scenes with big changes) and allow to use a dynamic target per chapter.

I ended up with this for now:

Algo: Flo Chapter
Minimal target nits / real display peak nits: 100
Maximal target nits: 10000
Time for rolling average in frames: 1440 (less than this is too fast for me)
Dynamic Target Nits Tuning [50-100]: 100
Merge scenes [FALL change in %]: 325
Minimal chapter duration in frames: 480
Merge chapters [avgFALL change in %]: 100

It works for every problematic case I encountered with previous settings :cool:

Thanks again!

Edit:

New settings, because I encountered an issue at the very end of Lucy:

Algo: Flo Chapter
Minimal target nits / real display peak nits: 100
Maximal target nits: 10000
Time for rolling average in frames: 1440 (less than this is too fast for me)
Dynamic Target Nits Tuning [50-100]: 100
Merge scenes [FALL change in %]: 325
Minimal chapter duration in frames: 720
Merge chapters [avgFALL change in %]: 100
 
#338 · (Edited)
Thanks for all the testing. I will try your new best settings.

And put them to default if they are better than mine.

@madshi

Many users here (and in the madVR Germany Facebook group) have been testing our dynamic target nits algo quite a lot. Testing it for stability for big brightness change and so forth.

We started with only using a 10s centered rolling avg. This worked very well but did not pass smoothly abrupt brightness change like in "THE" famous testing scene from harry potter and the goblet of fire.

Since the chapter have been introduced and refined, those issues have been reported gone.

Neo-xp is still fine tuning. ;)

But with the default settings, I have watched 4 full movies without any stability issues. Our algo was simply invisible.
:)
 
#312 ·
Question mainly to Manni01, but also to everyone else, of course:

Originally there was some concern, mainly from Manni and me, that adjusting the display target peak nits setting dynamically within a movie might harm director's intent to a certain extent, because it could result in a dark scene being shown brighter (than it would otherwise be shown) and a bright scene being shown darker. So basically the difference between dark and bright scenes is reduced.

Is this no longer a concern? Did Soulnight's work remove any worries about that?

That would be great news, because if that's the case, I think we could forget about Manni's suggestion (to use a fixed 2:1 compression range for 0-100 nits, and a stronger compression range for brighter pixels). Of course it would still be possible to test that, too, but Soulnight's approach is a lot easier for me to implement. And if it doesn't hurt director's intent, then I believe it has more potential to improve image quality.

When doing a weird curve mix like Manni suggested, we'd have to do a lot of trial and error to figure out which kind of curve blend operation looks good (if any!), and it would probably also depend on various parameters like movie nits, display nits, and many other things, so we might have to redo every trial and error testing at every possible movie nits vs display nits combination. And I think the end result will always be of limited benefit because if the display target peak nits setting stays static, neither very bright nor very dark scenes (compared to the movie average brightness) will look optimal, when watched in isolation. In contrast to that, Soulnight's approach should optimize each scene separately, so results should be near perfect for each scene. BUT, does it hurt director's intent to adjust the tone mapping parameters so dramatically within a movie? If not, then I think we should simply stick with Soulnight's approach and forget everything else.

Thoughts?
 
#316 ·
For sure the way the utility improves things makes my original suggestion less crucial. I haven't had the time to test situations where going from a bright scene to a dark scene would be objectionable from this point of view. I haven't seen anything obvious during my limited testing.

If we could get this in MadVR, it would be a great step forward. :)

The main drawback with the current implementation, which is much better from that point of view now that we have longer chapters, is that it can't work without measurements files.

My approach would work with the live algo.

The other advantage of my approach is that you would need only one user input: display real nits.

So even if only for these two reasons, I think there is value in trying my suggestion, provided you have the time of course.

I don't think we need to do a lot of testing to decide whether there is any value in it.

I think that with a "proof of concept" build with limited options, we could see whether what we get could be better or would be worse than Soulnight's approach.

If there was no need for measurements files and if we don't find situations where the current algo goes against director's intent, I'd be happy to live with the current implementation. It's really excellent (note: I haven't had a chance to test V3.3.0 yet).
 
#314 ·
Hi Madshi!

Nice to read you again.

Regarding the main topic, for me this implementation is superb, just how I was expecting hdr to behave in protectors.

Before it was always a compromise with the settings searching a value that could work during the whole film but never was the best you could get out of each scene.

Now it works wonderful keeping dark scenes dark but with details and contrast and bright scenes never look overblown and the hdr effect is there always.

So from my understanding and what I speak with my colleagues, this is a dream come truth.

We could not imagine our projectors could deliver such a beautiful and rich of contrast picture in hdr.

Regards!
 
#334 ·
Regarding the main topic, for me this implementation is superb, just how I was expecting hdr to behave in protectors.

Before it was always a compromise with the settings searching a value that could work during the whole film but never was the best you could get out of each scene.

Now it works wonderful keeping dark scenes dark but with details and contrast and bright scenes never look overblown and the hdr effect is there always.

So from my understanding and what I speak with my colleagues, this is a dream come truth.

We could not imagine our projectors could deliver such a beautiful and rich of contrast picture in hdr.
I just can speak as standard user with a projector currently at arround 70nits. For me watching movies with optimized measurement files is more enjoyable than ever before. It might not be directors intent anymore, which I would prefar as well, but it's the best compromise we can get at least with a projector.
I only watched a couple of hours with the dynamic target nits and I really like it. I didnt notice anything off or wrong, just perfect brightness all the way long.
Ok, thanks for your feedback!

I understand your theoretical issue with changing target nits in the same movie.
However, there is not only one key aspect for director intent but multiple.

1)
If you have 100nits on your screen, and you have a target nits of 100, and the frames peaks are all below 100, then you are watching the content untouched following director intent for brightness, color, saturation and everything else.

Now, if you put a static target nits of 400 nits, but your display is still 100nits, and the frames peaks are still below 100nits in that chapter, then you are watching the content 4 times to dark compared to the director intent.

2)
Watching "The MEG" or "The shallows" enable to understand another key point of director intend.
--> The director didn't want us to compress A LOT all the highlights. When doing that, it changes director intend.

For the MEG outside scene, 1000 target nits shows you the picture much closer to the director intend than if you use a fixed target nits of 500 or so.
Even with a target nits of 500, highlights are completely blown out and it was definetly not how it was meant to be seen.
With 1000nits target nits or more, now the picture looks much better balanced and the highlights are compressed much less.
With 1000 target nits, it still looks bright enough as well.

So respecting the original picture and not compressing as much (even if it costs global brightness) goes more toward respecting original intend than not.
Fair enough. But isn't The Meg arguably encoded incorrectly? I mean just imagine watching it on a *true* 10,000 nits display. Wouldn't you need to wear sunglasses to be able to bear it?

In my opinion and to my eyes, we are now much closer to the director intent with our "dynamic target nits" algo that we were ever before with a static target nits. ;)
There is no doubt that we are overall closer to the director's intent with dynamic targets using chapters than we were with static target nits.
Ok, good to hear that.

Soulnight's current implementation only works well enough from a "director's intent" point of view with chapters. I don't see how you could achieve this with the live algo, because you need to parse the whole file to identify chapters in order to assign stable targets over time. Or you'd have to have a buffer of at least 90 seconds before the film starts. Hardly something that most users would be happy with...

[...]

Agreed regarding director's intent, but again the current results can't be obtained without a measurements file.
Why are you already concluding that it can't be done without a measurement file, before I even started trying? Don't you know that Tinkerbell keeps me nicely stocked with fairy dust?

In any case, let's assume that I can achieve similar results to Soulnight's chapter solution, without having a measurement file: In that case, do you still have any worries about director's intent? If not, IMHO we can consider the matter closed, and we don't even need to try your approach, because when looking at each video frame separately, there's zero doubt that Soulnight's approach will have higher image quality, because the tone mapping curve is simply better. The only area where your approach could have advantages is temporal stability. But if you don't see any problems in that area with Soulnight's approach, then it doesn't really seem to be an issue, after all?

(Of course if it should play out that I can't achieve the same results without a measurement file, we'll have to reinvestigate. But as I said before, I see no reason why it shouldn't work well without a measurement file.)

Soulnight's approach is still a preference thing, because it remains a compromise between target stability and resolution of shadows / highlights.
So you do still see issues with stability?

On the other hand, if we say that what we're trying is to emulate a Dolby Cinema grade for projectors in a dedicated room (which is what I'm advocating for), you can in fact have zero user input for this mode. The user only has to set their peak brightness to 107nits (in reality it should work fine for anyone with a peak brightness between 90nits and 120nits or so).
FYI, it seems DCI is re-evaluating the 48 nits. See here:

http://www.dcimovies.com/announcements/DCI-Image-Evaluation-Summary_20180511.pdf

FWIW, it's related to HDR, so I'm not completely sure if they just want to raise the peak luminance but keep diffuse white at 48 nits, or if they want to increase diffuse white, as well.

In any case, I do wonder if the reason why they picked 48 nits in the first place was really that they thought it looked better than 100 nits, or maybe it was because they knew aiming for 100 nits would have increased costs too much?

The question is whether having a "hybrid" curve with 0-100fixed and 100-10000nits dynamic would work better than the current dynamic implementation or not.

Your examples above is why I keep saying that watching HDR in a dedicated room means at least 100nits peak brightness (Dolby Cinema HDR uses 107nits, vs 48nits in SDR):

That way you have 0-48 nits for 0-100nits in the content (100% stable, and as the director intended for a Dolby Cinema grade with has a diffuse white at 48nits, not 100nits as with the consumer UHD bluray grade). 48 nits (50nits to simplify) is where you want diffuse white in a dedicated room with a projector.

And 48-real peak (at least 100nits) for 101-10000nits in the content (peak brightness wouldn't change, but the target would be adjusted dynamically for that part of the curve).

This fixed 2:1 ratio for below diffuse white (or whatever we decide on, it could be adjusted depending on the actual brightness of the content) is what we want for best stability. All the time. During the whole film.

Your algo works better for users with 50nits peak nits or less.

I think mine might work better for close to 100nits actual peak or more (if it works at all).

Although your algo works already very well for 100nits and more, as we all know :)
I wonder if maybe DCI masters are mastered differently to account for 48 nits maybe needing a little push to render shadow detail nicely? Obviously UHD Blu-Rays were mastered with displays in mind which can do 400nits+, so shadow detail was encoded with diffuse white set to 100 nits. Now if we take that content and render it with diffuse white at 48 nits, isn't there a danger that we might lose some shadow detail? Wouldn't it be better to actually (try to) reproduce UHD Blu-Rays at 100 nits diffuse white even with our dim projectors?

E.g. using the dark The Revenant scene, does it look better with "Minimum target nits" set to 100 or to 200, using Soulnight's tool?
 
#317 · (Edited)
@madshi I just can speak as standard user with a projector currently at arround 70nits. For me watching movies with optimized measurement files is more enjoyable than ever before. It might not be directors intent anymore, which I would prefar as well, but it's the best compromise we can get at least with a projector.


Edit: Sure getting similiar (don't even have to be the same but close) results without measurement files it would be even better.


NoTechi
 
  • Like
Reactions: Soulnight
#318 · (Edited)
@Manni01

There is no issue with our "Detail file" and madmeasurementHDR output with madVR in V38.
As @madshi mentionned the bug is only in combination with new output with 1 more line with V39 ;)
This will be fixed in the next version ;-)

Here is how it looks in combination with V38:

Btw. @madshi you can see in there that the original number of scenes defined by madVR was 4753.
We have reduced it with some rules looking for example for:
- minimum chapter length
- relative FALL change
to get in this example to 100 "chapters" in the end.

Having some chapter where the rolling avg can be resetted at chapter cut effectively avoids the Target Nits to change too quickly for large brightness jumps at scenes cuts.
At the same time, having longer chapters (compared to scene) allows the target nits to stabilize which avoids that IF for example the camera keeps switching between the different people discussing in the same room, you get different target nits every few frames (which would be unwanted).

Code:
madMasureDynamicClipping V3.3.0 results
----------------------------------------------
madMeasureHDR output
Metadata
Mastering display luminance: 0.005/1000
MaxCLL: 1000
MaxFALL: 400 nits


Measurements
Frames: 128721
MaxCLL 100%: 1206
99.9%: 1003
MaxFALL: 505
AvgFALL: 30
AvgFMLL: 363 nits

----------------------------------------------
Header
Version: 6
Header size: 10
Number of scenes: 4753
Number of frames: 128721
Complete flag: 1
MaxCLL: 1206
MaxFALL: 505
AvgFALL: 30
----------------------------------------------
Calculated values before clipping
Average FMLL: 363
Avg % of pixels below 100 nits: 93,62
Avg % of pixels below 200 nits: 97,7
% of frames with highlights (>100 nits): 96,46
Avg median of highlights: 174
Avg avg of highlights: 184
----------------------------------------------
Target nits selection
Recommended static target nits by Flo: 189

Selected target nits calculation method: Flo-Chapter
Selected static target nits: 189
Real display peak nits: 50

Dynamic target nits: Yes
Minimal target nits: 50
Maximum Target Nits: 1500
Time for rolling avg in frames: 480
Dynamic Target Nits Tuning [50-100]: 60
Merge scenes [FALL change in %]: 100
Minimal chapter duration in frames: 240
Merge chapters [avgFALL change in %]: 50
Number of identified chapters: 100
----------------------------------------------
Dynamic clipping
Dynamic range recovery strength in %: 100

Dynamic clipping statistics for all frames clipped more than 10 Nits
% of frames clipped more than 10 Nits: 30,68
Avg of clipped nits: 92,96
Avg of clipped area in %: 0,06
Avg of decompressed area in %: 8,54
Avg highlights knee in nits: 292,25

Calculated values after clipping
MaxCLL: 1206
AvgFMLL: 334
 
#327 ·
@Manni01

There is no issue with our "Detail file" and madmeasurementHDR output with madVR in V38.
As @madshi mentionned the bug is only in combination with new output with 1 more line with V39 ;)
This will be fixed in the next version ;-)
Thanks :).
 
#324 ·
ok, most of the time the dynamic target nits works but some other times it doesn't. or am I doing something wrong?

before using this tool i watched movies at about 150- 250 nits.


i did a some quick comparison to show what im talking about:


here its perfect:
http://screenshotcomparison.com/comparison/127780/picture:1
http://screenshotcomparison.com/comparison/127780/picture:2



here, i think 562nits is way too high ? is it because the tool / madvr detects the lights in the back and think this is a bright scene ?



http://screenshotcomparison.com/comparison/127780


sorry for my english
 
#325 ·
Can you put a screenshot from your settings?

How many nits do you really have on screen?

This case "dark scene" + "small area bright highlights " has already been discussed and improved once.

It is in the plan to improve this situation further using a new version of the old fix + @Dexter idea or something similar :)
 
#330 · (Edited)
Simple Analyzer for madMeasureHDR

1. Read @madshi version 4-6 madMeasurement scenes, histograms and @Soulnight's dynamic target nits data and display the chart. (click column header on grid to sort the data, scale the chart on mouse wheel, double-click on the scene data to view the scene histogram data, double-click on histogram data to view the lum and hue charts)
2. Fields of "flag", "maxCLL", "Target Nits", "maxFALL", "avg FALL" can be overwritten. (right-click on "maxCLL", "maxFALL", "avgFALL" fields to pop up quick set menu)
3. Implement @Soulnight early version of measurement data calculation. (click on avg % frame peak cell to view addition chart on scene and frame chart)



 

Attachments

#331 ·
@Soulnight I'm looking forward to trying it out tonight with dynamic tone mapping working.

Last night I had a quick look at using a low value for minimum chapter length (48) and while it improved some scenes there were obvious problems with others. The default chapter settings are pretty good, it's very stable and smooth but there is the occasional 'bad' target change. Although I think these can be resolved if the way the algorithm handles bright spots is improved as the only target changes which stood out to me were when the target was too high. I'm not sure if that's similar to what @Neo-XP has seen too.

Having the new options is great though and now being able to see the FALL in the OSD will help a lot dialing in the settings 😉

I like when it reacts quickly to scenes which are at or close to the minimum target (dark scenes) but when it reacts quickly to brighter scenes the targets can be all over the place and it can be distracting.
 
#332 ·
Sorry SOULNIGHT I came a doubt, having my screen a REAL brightness of 91nits in "Minimal target nits / real display peak nits" I put 91, but in:

1.Maximal target nits
2.Time for rolling average in frames:
3.Dynamic Target Nits Tuning [50-100]
4.Merge scenes [FALL change in%]
5.Minimal chapter duration in frames
6.Merge chapters [avgFALL change in%]

what do you suggest to set up?
 
#339 ·
I'm actually having pretty good results with these settings. I really liked the 10 second rolling average but it needed to adjust instantly to large scene changes and these settings basically do that. But it seems to produce long chapters so a longer rolling average would work too.

Minimal target: 225
Maximal Target: 10000
Rolling average: 240
Dynamic tuning: 90
Merge scenes: 350
Minimal chapter duration: 24
Merge chapter: 250

It even goes alright in the fury road sandstorm scene which is my current chapter torture test.
 
#349 · (Edited)
Maybe I did not understand something and/or I am doing something wrong, but if I put all the .measurements files into one single folder and I define this folder in "configuration" -> "files & folders", madVR should load them, right?

The only way to make it work for me is to copy/move the .measurement file and put it in the same folder as the movie.

But if I measure a movie with madMeasureHDR, the .measurement file is created in the folder specified in madVR. :confused:

Any idea?
 
#350 ·
If you decide to have all the measurements separated from the movies in madvr, madmeasurehdr will rename the files to includ the path to the mkv IN the name.

If you let the measurement files next to the movie, the files are not renamed.

Putting not renamed files all together in a measurement folder separated from the mkv does not work.
 
#352 ·
madmeasuredynamicclipping Tool V3.3.1

Another small update: V3.3.1

http://projectiondream.com/download/madmeasuredynamicclipping/

New:

1. The *_Details.txt log file is now compatible with the new madMeasureHDR output from madVR version 39 (it still works with version 38)
2. the tool now remembers all checkboxes (though I wouldn't uncheck dynamic clipping and target nits :D )


Enjoy!

Anna&Flo
 
#360 ·
Another small update: V3.3.1

http://projectiondream.com/download/madmeasuredynamicclipping/

New:

1. The *_Details.txt log file is now compatible with the new madMeasureHDR output from madVR version 39 (it still works with version 38)
2. the tool now remembers all checkboxes (though I wouldn't uncheck dynamic clipping and target nits :D )


Enjoy!

Anna&Flo

Thanks! It appears that 75 instead of 100 is now defaulted in the "Dynamic Target Nits Tuning" box. Have you found 75 to be that much better than 100 to change the default? Just curious as I haven't seen any mention of this yet.

Btw, I'm super impressed with your developments lately with the chapters! I see no issues and really sense I'm seeing the directors intent; especially with Solo and Meg as I remember both being a much better experience at the Dolby Cinema / IMAX where I initially saw them... and now the UHD is finally matching that initial experience visually.
 
#353 · (Edited)
@Soulnight: thanks for the fix in the log, working fine now!

Looks like I can finally switch to your tool for measuring as well and retire my batch file :)

Thanks again. I'll do some visual tests with the latest build as soon as I can after some remeasurements, but it might take a couple of days before I can make the time.
 
#354 ·
Question for anyone who knows:

Do any the properties in the tool affect how blacks are rendered (e.g. shadow detail)? Or does the tone mapping leave that alone and concentrate on mapping the higher nit values only?

I ask because I'm trying to see if I can improve contrast in the shadow details.

Thx.
 
  • Like
Reactions: chros73
#362 ·
You will get the best shadow detail by lowering the Minimal target nits / real display nits.

If you think you are losing shadow detail at a low target nits, try changing the gamma value in madVR. If you are using 2.20 in madVR, try 2.40 instead.

You can also check for black clipping with HDR10 black clipping patterns like the ones found here: https://drive.google.com/file/d/1PYY37NqZLPEo1ZOwFmbUZ3T8JqyuGH7-/view
 
#355 ·
Hi guys,
My measured peak luminance on screen is 80 nits.
Can someone suggests me settings to use with flo's tool?

And more: do I need different settings for special titles like the Meg?

A suggestion for Soulnight :

I think that it will be very helpful (only if you want to make your tool near to not expert users) to include to the download an instruction pdf file with the explanations of all voices and functionalities of your tool, maybe also with pratic examples.
In this pdf you can include the logic for users to set by themselfs settings in relationship to measured peak luminance...

I know that those things where discussed too many times in this thread but.... In this way a new user is not forced to read this thread from the beginning.

Just my two cents.

Thank you so much for your fantastic work.
 
#358 ·
Hi guys,
My measured peak luminance on screen is 80 nits.
Can someone suggests me settings to use with flo's tool?

And more: do I need different settings for special titles like the Meg?
Set the Minimal Target Nits/ Real Display Peak Nits property to 80. Leave all the other settings at their default values.

The idea isn't to have different settings for different movies but one setting that works for all. The Meg is different and might benefit from a higher Maximal Target Nits (e.g. 4000) but I'll leave that for more knowledgeable people to address.

I'm just trying to help you now as most of the experienced people are in Europe and probably sleeping at the moment. :)
 
#356 ·
I keep getting an error every time I click start it says

"Unhandled exception has occurred in your application. If you click Continue, the application will ignore this error and attempt to continue. If you click Quit, the application will close immediately. The system cannot find the file specified."

Anyone know what file I could be missing? I chose the pathway that has all my HDR movies so I dont know why its giving me this error.

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.ComponentModel.Win32Exception (0x80004005): The system cannot find the file specified
at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
at System.Diagnostics.Process.Start(ProcessStartInfo startInfo)
at madMeasureDynamicClipping.FrmMain.MadMeasureHDR(String file)
at madMeasureDynamicClipping.FrmMain.StartAnalysis()
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Loaded Assemblies **************
mscorlib
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3260.0 built by: NET472REL1LAST_C
CodeBase: file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/mscorlib.dll
----------------------------------------
madMeasureDynamicClipping
Assembly Version: 2.9.8.0
Win32 Version: 2.9.8.0
CodeBase: file:///C:/Users/Dominic%20Mathurin/AppData/Local/Apps/2.0/HEMPQ0HC.5J4/08BDHKJT.7ZV/madm..tion_9e4aaf119d852000_0002.0009_218a4d342aa036d8/madMeasureDynamicClipping.exe
----------------------------------------
Microsoft.VisualBasic
Assembly Version: 10.0.0.0
Win32 Version: 14.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Microsoft.VisualBasic/v4.0_10.0.0.0__b03f5f7f11d50a3a/Microsoft.VisualBasic.dll
----------------------------------------
System
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3314.0 built by: NET472REL1LAST_B
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Core
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3221.0 built by: NET472REL1LAST_C
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll
----------------------------------------
System.Windows.Forms
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3221.0 built by: NET472REL1LAST_C
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System.Drawing
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
System.Configuration
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll
----------------------------------------
System.Xml
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll
----------------------------------------
System.Runtime.Remoting
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Runtime.Remoting/v4.0_4.0.0.0__b77a5c561934e089/System.Runtime.Remoting.dll
----------------------------------------
Accessibility
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/Accessibility/v4.0_4.0.0.0__b03f5f7f11d50a3a/Accessibility.dll
----------------------------------------
System.Deployment
Assembly Version: 4.0.0.0
Win32 Version: 4.7.3056.0 built by: NET472REL1
CodeBase: file:///C:/WINDOWS/Microsoft.Net/assembly/GAC_MSIL/System.Deployment/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Deployment.dll
----------------------------------------

************** JIT Debugging **************
To enable just-in-time (JIT) debugging, the .config file for this
application or computer (machine.config) must have the
jitDebugging value set in the system.windows.forms section.
The application must also be compiled with debugging
enabled.

For example:





When JIT debugging is enabled, any unhandled exception
will be sent to the JIT debugger registered on the computer
rather than be handled by this dialog box.
 
#357 ·
This usually happens when you the tool tries to measure a file and it can't find the madVR exe. Make sure you've set the path to where madVR is installed properly.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top