AVS Forum banner

4061 - 4080 of 10302 Posts

·
Registered
Joined
·
8,053 Posts
Hey, uh, madshi?

w:\MKV\Atomic Blonde.mkv.measurements
maxCLL: 649
maxFALL: 364
avgFALL: -2147483648
Scene Count: 2263
Video Duration: 165084
flags: 1
version: 5

I don't think that's supposed to look like that in bold....right? LOL That's from my modified tool but I checked the output from madMeasureHDR and it says the same thing. It's currently processing the rest of my movies so I'll see what they look like.

EDIT 2:

w:\MKV\Batman Begins.mkv.measurements
maxCLL: 1174
maxFALL: 563
avgFALL: -2147483648
Scene Count: 6977
Video Duration: 201488
flags: 1
version: 5

At least it's consistent? :)
That's very strange. I've checked my math and I don't see how that could possibly happen, unless the histogram data is completely screwed up! I can't seem to reproduce it on my PC.

Does it happen for all videos/movies for you? If not, is there any pattern you can see when it happens and when it doesn't?

From 4 measured files, AvgFALL shows as 26/24/16/9 nits in the output measurement info for me.
That sounds pretty low so not sure if it's supposed to be different? Otherwise I don't know what it could be used for.
Please understand that this is the average of all pixels in the movie. Considering that diffuse white (non-reflective/highlight peak white) is at 100nits, it is to be expected that AvgFALL should be significantly below 100nits for most movies. Hmmmmm... So maybe it's not that useful overall? I'm really not sure... It definitely is much lower than the other numbers, but maybe it's still a useful number?

Highlights are blown out in Mother! scene, not better than 0.25s :(

Static 0.10s / Static 0.25s / Dynamic

The first frame where the luminance increase dramatically, the "flicker risk" value is only at 0.12% and the nits peak goes from 6 to 670nits, but the tone mapping target is as low as 152nits :eek:
Then, the nits peak increase even more to 977nits, but the target is still lagging behind at only 229nits. Flicker risk is only 0.31%.
I've changed the whole logic. The old "brightness reaction time" increased the tone mapping target from the "current" target to the newly measured peak always in the same "brightness reaction time", regardless of how high the necessary adjustment was. So if you selected e.g. 0.1s, that's 2.4 frames. So even if the "current" tone mapping target is 1nits, and the newly measured peak is 10,000nits, a brightness reaction time of 0.1s still went up from 1nits to 10,000nits in 2.4 frames. I think it was rounded down to just 2 frames. So 1nits -> 5000nits -> 10000nits. That's pretty extreme, isn't it? The 0.1s reaction time also meant that if e.g. the current target was 200nits, and the newly measured target was 250nits, then it still adjusted in 2 frames. So 200nits -> 225nits -> 250nits. (Or maybe it was 3 frames instead of 2, don't know for sure right now.)

IMHO the above logic didn't make too much sense. It doesn't make sense to always adjust in a specific number of frames, regardless of how big the adjustment is, IMHO. So I changed the logic to instead adjust a certain max brightness percentage per frame. For example, let's say the new reaction speed is "double the tone mapping target each frame". So we could go from 200nits -> 250nits in one frame. But going from 200nits -> 1000nits would go in steps like 200nits -> 400nits -> 800nits -> 1000nits. That makes more sense, no?

So the new logic now calculates a specific "max brightness adjustment factor" (based on flicker risk) which is applied to each frame. So if we need to get brighter, in each frame we do "newToneMapTarget = currentToneMapTarget * factor", until we've reached the target.

Now "Mother" is a pretty extreme example, because it goes from 5nits up to 977nits in 2 frames. Even if we use a max brightness adjustment factor of 10x (which is pretty extreme), we'd still go 5nits -> 50nits -> 500nits -> 977nits. You can see that Mother is still not behaving worse than 0.25s reaction time, though, so you can see that my flicker risk -> max brightness adjustment factor is still allowing very large adjustment factors, as long as the flicker risk is low. E.g. check the Harry Potter scene, I think it adjusts faster than even 0.1s? That's because it starts at higher nits, and doesn't ramp up as extremely quickly as the Mother scene.

I suppose I could allow even higher max adjustment factors, to make the Mother scene better, but I think that's probably one of the most extreme examples we'll ever see. If we optimize for that scene alone, I'm worried that we might introduce artifacts in other scenes. So I thought it would be "ok" if Mother just looked similar to how the previous "default/recommended" setting of 0.25s brightness reaction time looked. At the same time Harry Potter looks better, and there are no brightness jumps in either the Jurassic World or Matrix 2 test scenes. So the new logic should be a big improvement over using a fixed brightness reaction time, no?

Yes MaxFALL related data might be very useful, I thought you couldn't/didn't want to provide MaxFALL so I had given up on it.
Well, it was hard to provide a halfway correct number with the low histogram resolution we had before. The higher resolution histogram helped make MaxFALL calculation more exact/reasonable. That's why I can provide it now. However, I'm not 100% sure how exact the calculation really is. Will need some testing, I suppose...

Question: are all these values time-weigthed?

Also I couldn't see the AVGScenePeakTW, any reason why you ruled is out as potentially useful? I liked the fact that it was time weighted, it could be more significant measurement than simply an average.
You need time weighting only if you calculate on scenes, because every scene has a different runtime. My math is applied on each frame instead of the scenes, which makes time weighting useless, because all frames have the same runtime. AVGScenePeakTW should be roughly the same as AvgFmll, as far as I understand.

Update of the simple measurement file analyzer.

1. support both version 4 & 5
2. speed up the data processing
3. you can define your own X%, and it will be saved.
Looks great, thank you!

After then i watched 2001 A Space Oddssey with mesaure file. The result was phenomenal. I didnt find any problems except at duration 54:39 when the sun shines over the monolith there is a little flicker visible at the target nits 200.
Does it still happen with the latest build? If so, can anybody cut a little sample for me?
 

·
Registered
Joined
·
173 Posts
maybe it's still a useful number?
I'd say it's the most useful number as far as using profiles is concerned. I'm currently measuring a bunch of movies with different overall brightness levels and this number is the only one that is consistently higher with brighter movies.
 

·
Registered
Joined
·
8,053 Posts
I'd say it's the most useful number as far as using profiles is concerned. I'm currently measuring a bunch of movies with different overall brightness levels and this number is the only one that is consistently higher with brighter movies.
That sounds promising!
 

·
Registered
Joined
·
108 Posts
Update :

- Adapted to the new file format of the measurement file
- All outputs of madMeasureHDR are written to the logfiles
- If you have 4K monitor you might have the wrong printscreens, In this case you can use the new setting "4K Monitor"
- If the tool is installed in the "program files" folder the update files are written to the appdata folder.

Download : http://download.seven-c.de/files/madvr/htpccontrol.zip

Bernd
 

·
Registered
Joined
·
1,479 Posts
Discussion Starter #4,066
@madshi

Great build! :)
Sounds very promising!

Thank you for the higher and resolution histogram with the better distributed nits. :)

It will be very useful :)

The avg of the nits of all pixels is a good indicator but as we know will be almost always way lower than 100nits.

Maybe in the same idea, we could look instead at the median nits of all the pixels above 100nits?
Basically the highlights median nits?

This should be even more representative and would provide a number above 100nits.

We will try this evening in the excel to see what kind of number we would get.
 

·
Registered
Joined
·
8,053 Posts
Update :

- Adapted to the new file format of the measurement file
- All outputs of madMeasureHDR are written to the logfiles
- If you have 4K monitor you might have the wrong printscreens, In this case you can use the new setting "4K Monitor"
- If the tool is installed in the "program files" folder the update files are written to the appdata folder.

Download : http://download.seven-c.de/files/madvr/htpccontrol.zip
Thanks!

Dynamic HDR is absolutely fantastic!! :eek:
I highly appreciate all the hard work going into Madvr👍
Wow, that's a really nice example! Which movie and runtime is that?

The avg of the nits of all pixels is a good indicator but as we know will be almost always way lower than 100nits.

Maybe in the same idea, we could look instead at the median nits of all the pixels above 100nits?
Basically the highlights median nits?

This should be even more representative and would provide a number above 100nits.

We will try this evening in the excel to see what kind of number we would get.
I'm not sure myself which attributes of a movie decide which is the best profile (target peak nits) to use. E.g. is it the amount/numer of highlight pixels? Is it the highlight peak? Or maybe the highlights don't matter that much at all, after all, and the distribution in the 0-100nits range is key? I don't really know.

FWIW, I think the two numbers AvgFall and AvgFmll should cover both possibilities: AvgFall mostly shows the distribution in the 0-100nits range. AvgFmll shows the average HDR peak. I suppose by combining those two numbers, all key information is already available?
 

·
Registered
Joined
·
3,535 Posts
Thanks!


Wow, that's a really nice example! Which movie and runtime is that?


I'm not sure myself which attributes of a movie decide which is the best profile (target peak nits) to use. E.g. is it the amount/numer of highlight pixels? Is it the highlight peak? Or maybe the highlights don't matter that much at all, after all, and the distribution in the 0-100nits range is key? I don't really know.

FWIW, I think the two numbers AvgFall and AvgFmll should cover both possibilities: AvgFall mostly shows the distribution in the 0-100nits range. AvgFmll shows the average HDR peak. I suppose by combining those two numbers, all key information is already available?


It's Ready Player One At 00:11:09 on the UHD Disc

 

·
Registered
Joined
·
173 Posts
I've measured a bunch of movies and recorded the numbers which I thought might be useful for selecting profiles, I didn't use the correct names for things but these are the results:

Soylo

Video Peak: 995
Average peak: 215
average FALL: 11
MaxFALL: 810

2001

Video peak: 992
average peak: 643
average FALL: 49
MaxFALL: 469

Blade Runner 2049

Video Peak: 199
average peak: 95
average FALL: 12
MaxFALL: 182

Edge of tomorrow

Video Peak: 206
average peak: 84
average FALL: 6
MaxFALL: 112

Ghost Busters II

Video Peak: 4427
average peak: 697
average FALL: 31
MaxFall: 791

Chamber of secrets

Video Peak: 2856
average peak: 262
average FALL: 16
MaxFALL: 3621

John Wick Chapter 2

Video Peak: 1000
average peak: 676
average FALL: 20
MaxFALL: 831

Jupiter Acesnding

Video Peak: 260
average peak: 112
average FALL: 6
MaxFALL: 189

Kong Skull Island

Video Peak: 456
average peak: 244
average FALL: 30
maxFALL: 567

Pacific Rim

Video Peak: 2465
average peak: 947
average FALL: 39
maxFALL: 5797

Fury Road

Video Peak: 9918
average peak: 1059
average fall: 44
maxfall: 3117

Perfume

video peak: 947
average peak: 436
average FALL: 33
maxFALL 851


average FALL seems to be consistently representative of the brightness of the movie so I put together some test profiles to test it and already it has fixed some of the movies which were too bright when using a static target nits of 212 (my measured display peak). This is the profile script, I added a avgFmll check above the avgFall but I think if I spent more time on it I could get the same result with only avgFall.

if (hdrVideoPeak
 

·
Premium Member
Joined
·
9,944 Posts
Please understand that this is the average of all pixels in the movie. Considering that diffuse white (non-reflective/highlight peak white) is at 100nits, it is to be expected that AvgFALL should be significantly below 100nits for most movies. Hmmmmm... So maybe it's not that useful overall? I'm really not sure... It definitely is much lower than the other numbers, but maybe it's still a useful number?
I've done some quick tests and personally don't find AvgFALL useful at all. Not enough granularity, and not representative of the actual brightness of the movie, at least from a brightness factor point of view.

Well, it was hard to provide a halfway correct number with the low histogram resolution we had before. The higher resolution histogram helped make MaxFALL calculation more exact/reasonable. That's why I can provide it now. However, I'm not 100% sure how exact the calculation really is. Will need some testing, I suppose...
Makes sense, anyway, great to have it, although based on the few titles I looked at, unless there is a bug in the utility I used, it seems to be very different from the MaxFALL in the metadata (see examples below).

You need time weighting only if you calculate on scenes, because every scene has a different runtime. My math is applied on each frame instead of the scenes, which makes time weighting useless, because all frames have the same runtime. AVGScenePeakTW should be roughly the same as AvgFmll, as far as I understand.
Yes, that's precisely why I liked it as an indicator of the average brightness of the movie. Because it took the average of the peak of the scenes, time weighted.

AVGScenePeakTW is completely different from AvgFmll [EDIT: due to a suspected bug in the utility I was using, it looks like AVGFALL was displayed as AVGFmll, causing the confusion below. Please ignore].

For example, on HP and the Deathly Hallow Part 1, AVGFmll is 10, AVGScenePeakTW is 547. MaxFALL is 2008 as per MadVR, 431 as per the metadata.

In HP and the Chamber of Secrets, AVGfMll is 11, AVGScenePeakTW is 359. MaxFALL is 2670 as per MadVR, 222 as per the metadata.

Unless there is a bug in the MadMeasurementsHDR analyzer utility (I haven't been able to play any files yet, I'm doing this remotely), I find the delta between AVGScenePeakTW, and possible the MaxFALL metadata, far more representative of the brightness difference between the two movies (see attached).

If you look at AVGFmll, there are supposed to be the almost the same (10/11).

So personally, I won't use AVGFmll. [EDIT: I will, now that I can get the correct value]

I'll try to see if I can get good results with MaxFALL, possibly AVGFALL but I'd really like to get AVGScenePeakTW if at all possible, because when I looked at all the calculated data from the last cycle, it looked like the most promising/indicative/reliable data, that's why I asked for it.
 

Attachments

·
Premium Member
Joined
·
9,944 Posts
Update :

- Adapted to the new file format of the measurement file
- All outputs of madMeasureHDR are written to the logfiles
- If you have 4K monitor you might have the wrong printscreens, In this case you can use the new setting "4K Monitor"
- If the tool is installed in the "program files" folder the update files are written to the appdata folder.

Download : http://download.seven-c.de/files/madvr/htpccontrol.zip

Bernd
Hi Bernd,

Thanks for this new build.

The settings don't look right on my 4K monitor irrespective of the 4K monitor settings in the settings :)

The log doesn't seem to be written for the files I've measured with the new build. Do you need to select a specific option to get the log generated? I would expect it to be generated whenever the measurements file is created.

I would also like it to be generated when a measurement is skipped because a valid measurements file is present, from that measurements file. The last time I checked, it didn't work.

I don't enable the MaxCLL option because I don't want all the alternate measurements files to be created. Just the standard measurements file, and the log, whether the file exists or not.
 

·
Registered
Joined
·
69 Posts
each time i delete the measurements file and play the file with mpc-hc or mpc-be (no kodi, no jriver)


in v26 i create a file in a d:\video_d\madvr_mesures : e.!audio_video_test!bt2020!The_World_in_HDR_in_4K_HDR10.mkv.measurements was create and when i play the mkv all is ok i see frame/scene/movie xx/xx/xx nits tone maps xx nits in osd



if a do the same thing in v27 or 28

when i play the file i see : measured frame xx nites tone map xx nits.
i need to rename the file The_World_in_HDR_in_4K_HDR10.mkv.measurements and put it in the same folder as the mkv file to see again
frame/scene/movie xx/xx/xx nits tone maps xx nits


(i have reinstall madvr, and lavfilter to be sure, measurments are create using d3d11 copy back but d3d11native do the same)
 

·
Registered
Joined
·
38 Posts
I've measured a bunch of movies and recorded the numbers which I thought might be useful for selecting profiles, I didn't use the correct names for things but these are the results:

average FALL seems to be consistently representative of the brightness of the movie so I put together some test profiles to test it and already it has fixed some of the movies which were too bright when using a static target nits of 212 (my measured display peak). This is the profile script, I added a avgFmll check above the avgFall but I think if I spent more time on it I could get the same result with only avgFall.

if (hdrVideoPeak
 

·
Registered
Joined
·
2 Posts
AvgFALL doesn't really work for some files. This is some measurements I got:

Dunkirk (2017)
Frames: 153404, MaxCLL 100%: 352, 99.9%: 328, 99.8%: 325, 99.0%: 317, MaxFALL: 270, AvgFALL: 38, AvgFMLL: 189
Ant-Man and the Wasp (2018)
Frames: 169978, MaxCLL 100%: 1098, 99.9%: 1017, 99.8%: 981, 99.0%: 805, MaxFALL: 862, AvgFALL: 9, AvgFMLL: 181

For Dunkirk you'd end up with a target peak nits that's too high, because the brightness is pretty consistent and there's little dark scenes.
For Ant-Man and the Wasp, MaxFALL is 862 which is pretty high so you'll end up compressing a lot of highlights.

So I think I'd agree with Manni that it's not really representative.
Interesting....

On Ant Man i get this :
Frames: 169978, MaxCLL 100%: 1078, 99.9%: 1026, 99.8%: 1012, 99.0%: 869, MaxFALL: 647, AvgFALL: 7, AvgFMLL: 220


I've measured a bunch of movies and recorded the numbers which I thought might be useful for selecting profiles, I didn't use the correct names for things but these are the results:

Soylo

Video Peak: 995
Average peak: 215
average FALL: 11
MaxFALL: 810

2001

Video peak: 992
average peak: 643
average FALL: 49
MaxFALL: 469

Blade Runner 2049

Video Peak: 199
average peak: 95
average FALL: 12
MaxFALL: 182

Edge of tomorrow

Video Peak: 206
average peak: 84
average FALL: 6
MaxFALL: 112

Ghost Busters II

Video Peak: 4427
average peak: 697
average FALL: 31
MaxFall: 791

Chamber of secrets

Video Peak: 2856
average peak: 262
average FALL: 16
MaxFALL: 3621

John Wick Chapter 2

Video Peak: 1000
average peak: 676
average FALL: 20
MaxFALL: 831

Jupiter Acesnding

Video Peak: 260
average peak: 112
average FALL: 6
MaxFALL: 189

Kong Skull Island

Video Peak: 456
average peak: 244
average FALL: 30
maxFALL: 567

Pacific Rim

Video Peak: 2465
average peak: 947
average FALL: 39
maxFALL: 5797

Fury Road

Video Peak: 9918
average peak: 1059
average fall: 44
maxfall: 3117

Perfume

video peak: 947
average peak: 436
average FALL: 33
maxFALL 851


average FALL seems to be consistently representative of the brightness of the movie so I put together some test profiles to test it and already it has fixed some of the movies which were too bright when using a static target nits of 212 (my measured display peak). This is the profile script, I added a avgFmll check above the avgFall but I think if I spent more time on it I could get the same result with only avgFall.

if (hdrVideoPeak
 

·
Registered
Joined
·
173 Posts
For Ant-Man and the Wasp, MaxFALL is 862 which is pretty high so you'll end up compressing a lot of highlights.
Well with ant-man the average peak is quite low at 181 so I don't think you'd be compressing much in most scenes. I'll have a look at dunkirk but I have noticed that movies with peaks bellow 1000 you can get weird results which is why I put in the avgFmll part. I pout that together just to test, it's not optimised at all.

Ultimately I don't think you can set a single target for a movie that will give good results in every scene, and the best way to do it would be to do it dynamically. But with profiles, my impression from the few movies I've measured is that most of the numbers are all over the place but avgFall is pretty close in the sense that a movie with an avgFall above 10 is brighter than one bellow 10 and so on.

But I was thinking that if the goal is to reduce compression then maybe we should be looking at a value in to 0-100 nits range which is lowered when compressed and then set the target to a value which gives the same display brightness for that value. If that makes any sense.
 

·
Registered
Joined
·
2,033 Posts
Not sure if this is the article that you were thinking of with regards to looking at the scopes?

From an article on HDR and the Sony BVM-X300 OLED Master Monitor

available at

www.pro-media.at/content/download/4156/24716/file/HDR.pdf

On the issue of a trim pass according to the mastering monitor:

More information here

http://www.digitalvision.tv/w/images/3/37/Dolby_Vision_in_Nucoda.pdf
The first article was posted earlier in this thread, but I didn't remember any of those specific details.

So it is possible to start a project on the Dolby Pulsar and finish it on the Sony BVM? And you can grade a video on a 1,000 nits monitor and then view it on a brighter consumer display before releasing it to the public? Those are two arguments for tone mapping pixels above the mastering monitor, maybe not above 4,000 nits.
 

·
Premium Member
Joined
·
9,944 Posts
[EDIT: updated algo can be found here]

I haven't had the time to do any testing but here is an untested modified algo based on MaxFALL for those who would like to test. Note: The MaxCLL values below are based on the metadata MaxFALL, not the MadVR MaxFALL. So they might need some correction later as there seems to be quite a difference between the two.

I've changed my profile names so that the name indicates the target peak nits, and I've added a few for more granularity. That way the profiles names and targets will stay the same whichever algo I suggest/use. It also makes it easier to read.

I've also added a default in case MaxFALL = 0, for example when there is no metadata for MaxFALL and the measurements file doesn't exist:

if (hdr) and (srcWidth
 

Attachments

·
Registered
Joined
·
5,411 Posts
That's very strange. I've checked my math and I don't see how that could possibly happen, unless the histogram data is completely screwed up! I can't seem to reproduce it on my PC.

Does it happen for all videos/movies for you? If not, is there any pattern you can see when it happens and when it doesn't?
Not all, no. 9 of them and I don't see any pattern.

http://www.mediafire.com/file/9qrziyckhvpf4z8/Atomic_Blonde.mkv.zip

I zipped one up so you can take a look and maybe see what's going on. Happy to help if you need any additional tests or information. Thanks!

Please understand that this is the average of all pixels in the movie. Considering that diffuse white (non-reflective/highlight peak white) is at 100nits, it is to be expected that AvgFALL should be significantly below 100nits for most movies. Hmmmmm... So maybe it's not that useful overall? I'm really not sure... It definitely is much lower than the other numbers, but maybe it's still a useful number?
Good to know. Thanks for the explanation.
 

·
Registered
Joined
·
788 Posts
@madshi

FYI. I did (still crunching thru them) about 60 files and none of them reported negative AvgFALL. I will do some actual testing tonight.

@Manni01
Thanks for sharing with your profiles. :) I will try them tonight. BTW.. Do you have "enable dynamic HDR" checked with your JVC projector?
 
4061 - 4080 of 10302 Posts
Top