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.Hey, uh, madshi?
Scene Count: 2263
Video Duration: 165084
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.
Scene Count: 6977
Video Duration: 201488
At least it's consistent?
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?
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?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.
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.)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
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%.
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?
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...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.
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.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.
Looks great, thank you!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.
Does it still happen with the latest build? If so, can anybody cut a little sample for me?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.