MPC-HC/BE+(LAV)+madVR/MPV:DV2SDR,BT.2020 2 BT.709, HDR10(PQ)/HLG 2 SDR動態映射〖更新〗

knk

And here's yet another test build:

http://madshi.net/madVRhdrMeasure31.zip

增加了一個修復亮度的演算法，速度仍有改善的空間，歡迎大家測看看。

knk

真快，新版的又來的，但修復亮度的演算法似乎更慢了，耗損更多GPU的資源

http://madshi.net/madVRhdrMeasure32.zip

knk

修復亮度的算法多了個mixed

http://madshi.net/madVRhdrMeasure33.zip

knk

Here's the next test build:

http://madshi.net/madVRhdrMeasure35.zip

1) Added 200 blur strength and 0.0085 ringing threshold.
2) Added a new option called "make sat vs lum decision in...".

Some hints about the new 2) option:

a) If you have "this display is calibrated" set to BT.2020, the new option is without any effect.
b) If you have "this display is calibrated" set to DCI-P3, the new option will only show a difference between BT.2020 and DCI-P3, but BT.709 will behave the same as DCI-P3.
c) If you have "this display is calibrated" set to BT.709, all 3 variants of the new option will show a difference.
d) DisplayCAL always does it in BT.2020.
e) All recent madVR test builds did it in BT.709 (or wider, depending on "this display is calibrated").
f) Making the decision in a wider color space means there's a lower need for "repair luminance", which explains why DisplayCAL doesn't need it as much as madVR's pixel shader math.
g) Making the decision in a wider color space tends to make highlights brighter, but less saturated.

knk

New test build:

http://madshi.net/madVRhdrMeasure36.zip

增加了修復亮度算法的補償機制。

knk

here's a new test build:

http://madshi.net/madVRhdrMeasure37.zip

變動非常大，之前測量過的，因格式改變，要重新測量了。

knk

測量工具更新：Tool Update!
Download: http://download.seven-c.de/files/madvr/htpccontrol.zip

修復37版的一些小bug，38版快速釋出：
http://madshi.net/madVRhdrMeasure38.zip

knk

轉貼39版，New test build up here:

http://madshi.net/madVRhdrMeasure39.zip

Only 3 changes:

1) Went back to the RR3 "repair repair luminance" blur algo. It's a bit slower, but not that much.
2) Added metadata gamut information to madMeasureHDR.exe output.
3) All files are properly signed again.

man3000

真的不必如此麻煩了，裝了KODI 18 RC5.2 64BIT版後，一堆4K 10BIT HDR影片都能正常播放了，本想年前買入Q5 4代，現在也不必了。(播放機 自組 INTEL 4560 H110M-ITX 8G)

6hzzz

man3000 發表於 2019-1-15 01:18 PM
真的不必如此麻煩了，裝了KODI 18 RC5.2 64BIT版後，一堆4K 10BIT HDR影片都能正常播放了，本想年前買入Q5  ...

不錯不錯，但能播和播好還是有區別的，madVR動態映射能彌補HDR10的天生缺陷。

6hzzz

“So here comes the next test build:

http://madshi.net/madVRhdrMeasure43.zip

Changes:

1) Default value for scene change threshold changed to 22.

2) Added some logic to avoid flickering even with fast reaction times.

3) You can now choose "safe" and "fast" brightness/darkness reaction times. The "safe" reaction time is used if the difference between current display peak and ideal display peak is only a factor of 2x or less. The "fast" reaction time is used if the difference is 8x or more. In between 2x and 8x madVR linearly interpolates between "safe" and "fast" reaction times.

I'm not really a big fan of 3), but I guess it's necessary, because although visible dimming/brightening is an artifact we want to avoid, adjusting too slowly to big brightness changes is also a visible problem in itself. So I hope that 3) can help to achieve a decent compromise?

I'd suggest a max value of 20 for the "safe" options. Maybe even less than 20, but not more, I think. For the "fast" options I'm not sure. I've tried 200 as a crazy high value and it still seems to work reasonably well. But it might be too high, I don't know.

(In order to test your "safe" and "fast" options in a worst case scenario, you can do this little trick: Use the same value for "safe" and "fast" and disable scene detection. This way you can at least get an impression of how slow or fast the values you've chosen will be on either extreme end of the scale.)”

6hzzz

Here comes the next test build:

http://madshi.net/madVRhdrMeasure44.zip

Changes:

1) Changed defaults to safe: 30; fast: 1000; threshold: 26.

2) Added options that let you specify when to use "safe" vs "fast" exactly. Defaults are 20 and 80 (which means a 2.0x and 8.0x target nits difference), which are identical to build 43. It might make sense to use a lower values than 20 to define the "safe" starting point, and then to lower the "safe" speed to something less than 30.

3) Added the following line to the OSD: e.g. "target nits dif: 2.00, speed: 30.0". Or e.g. "target nits dif: 8.00, speed: 1000.0". This lets you see which "safe" vs "fast" speed madVR selected for each scene and why.

4) I copied the "merge scenes (FALL change in %)" feature from Anna&Flo's tool to the live algo. So now there are 2 thresholds which both have to be fulfilled to trigger a scene/chapter change: There's the scene detection threshold, with a current default of 26%. And then there's the FALL change in %, which currently defaults to 20%. The default for the FALL change in Anna&Flo's tool is set to 100. But that's far to high for my math. I'm not sure where the difference is coming from, to be honest, but it shouldn't matter. In any case, you will probably have to use different values for this setting in madVR, compared to Anna&Flo's tool.

I'm not actually sure if the new "merge scenes (FALL in %)" feature is a useful addition to the live algo or not. Please give it a try and let me know. You should be able to disable this by entering a 0 value to go back to the previous behaviour to only look at the scene change threshold.

5) I've added the detected FALL % change to the luminance histogram (the 2nd number), for your information.

Sorry to add even more options than before! I know it makes testing even more complicated and time consuming. But I guess it can't be avoided if we want to optimize the sh** out of the live algo.


串流測試

knk

Here's the next test build:

http://madshi.net/madVRhdrMeasure45.zip

和44版最大的差異在多了 brightness speeds 數值調整

knk

Here comes the next test build:

http://madshi.net/madVRhdrMeasure50.zip

Changes:

1) Improved the first/main scene detection algo to be (much) less sensitive to brightness variations, e.g. fades in/out.

2) Dramatically improved the secondary scene detection algo. Maybe it's useful now?

3) Scene change detection is now blocked during a fade in/out.

knk

New test build:

http://madshi.net/madVRhdrMeasure51.zip

1) Added option "adjust for brightness" for primary scene detection algo: turned on = build 50; turned off = build 49.
2) Fixed: measurements not working in build 50.

knk

http://madshi.net/madVRhdrMeasure53.zip

1) Instead of enabling/disabling "smooth histogram" you can now choose how many smooth iterations to perform. 0 means none. 1 is not recommended. Previous builds used 7 iterations.

2) You can now choose the rolling average duration. Previously hard coded to 500ms. Instead now the rolling average percentage is hard coded to 100%. You can choose 0ms to disable the rolling average.

3) Rolling average is now reduced to 1 frame after a scene change detection, as suggested by Neo-XP.

knk

http://madshi.net/madVRhdrMeasure54.zip

This one will need some explanations:

1) The new option "adjust threshold 2 strength (in %)" tries to scale the 2nd scene detection algorithm to work better with dark scenes. By using 100%, dark scenes get *MUCH* higher values than before. Bright scenes also get some higher values, but not as much higher as dark scenes. If you use 0%, you get the exact old numbers. Any value in between 0% and 100% will scale linearly. If you use more than 0%, you will have to increase "scene change threshold 2", maybe even by a lot, to make it work properly, because any percentage above 0% increases the numbers overall (but dark scenes more than bright scenes). FYI, the substraction of the previous frame's metric from the current frame (previous known as the "rolling average substraction" feature, which is now always active) hides the fact the metric 2 gets higher numbers, so don't be confused by that.

2) Currently actual scene detection still uses algos 1 and 2 separately, with the separate thresholds. The reason for that is that a simple average of both metrics doesn't make sense if one has much higher values than the other. So first we need to find proper thresholds for both metrics separately, before we can combine them.

3) The histogram now has 3 numbers. The first 2 are the same as always (metrics 1 + 2). The 3rd number is now a *weighted* average. It's weighted like "(metric1 / threshold1 + metric2 / threshold2) / 2 * 10". Or to say it in words: The 3rd number now combines both metrics according to their thresholds, so that both have roughly equal weight. If the 3rd number exceeds 10.0, that's where a combined average metric would signal a scene change. But the 3rd number is not actually used anywhere yet. It just shows what a combined metric would output, using the 2 thresholds (you chose) as weights.

4) You can still disable the 2nd metric by setting "scene change threshold 2" to 0.

5) You can now choose different smooth strengths (iteration counts) for different FALL levels. Also an iteration count of 1 is now acceptable, I modified the smoothing algo accordingly. Using an iteration count of 0 is also perfectly legit, if you prefer that at very low FALL levels. You can go up to 50 iteration levels, IIRC. I doubt using that much smoothing will work well, though. But I'll leave that up to you.

knk

http://madshi.net/madVRhdrMeasure55.zip

metric2 involves a heavy downscaling step. So far I've used Mitchell downscaling for that in gamma light without AR. I've no idea if the downscaling algo is important, though. So this test build lets you try various algorithms, with and without AR and with and without linear light.

For speed purposes, of course not having to do linear light, anti-ringing and not having to use Lanczos would be beneficial. But if it helps metric2 reliability, I guess we'll have to bite the bullet. It's not that dramatic (compared to other stuff).

knk

http://madshi.net/madVRhdrMeasure57.zip

修復bug

ejizhan1978

knk 發表於 2019-2-23 08:08 AM
http://madshi.net/madVRhdrMeasure57.zip

修復bug

感謝分享。