樓主: 6hzzz
收起左側

[分享] MPC-HC/BE+LAV+madVR自動識別轉換BT.2020 HDR10動態映射SDR〖更新〗

  [複製連結]

發表於 2018-12-14 16:10:23 | 顯示全部樓層
And here's yet another test build:

http://madshi.net/madVRhdrMeasure31.zip

增加了一個修復亮度的演算法,速度仍有改善的空間,歡迎大家測看看。
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2018-12-15 10:36:07 | 顯示全部樓層
真快,新版的又來的,但修復亮度的演算法似乎更慢了,耗損更多GPU的資源

http://madshi.net/madVRhdrMeasure32.zip
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2018-12-16 16:55:08 | 顯示全部樓層
修復亮度的算法多了個mixed

http://madshi.net/madVRhdrMeasure33.zip
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2018-12-20 09:42:44 | 顯示全部樓層
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.
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2018-12-24 19:20:56 | 顯示全部樓層
New test build:

http://madshi.net/madVRhdrMeasure36.zip

增加了修復亮度算法的補償機制。
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2018-12-27 20:50:05 | 顯示全部樓層
here's a new test build:

http://madshi.net/madVRhdrMeasure37.zip

變動非常大,之前測量過的,因格式改變,要重新測量了。
回覆 支持 反對

使用道具 檢舉


發表於 2018-12-28 07:26:36 | 顯示全部樓層
測量工具更新:Tool Update!
Download: http://download.seven-c.de/files/madvr/htpccontrol.zip

修復37版的一些小bug,38版快速釋出:
http://madshi.net/madVRhdrMeasure38.zip
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-1-14 09:37:51 | 顯示全部樓層
轉貼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.
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-1-15 13:18:22 | 顯示全部樓層
真的不必如此麻煩了,裝了KODI 18 RC5.2 64BIT版後,一堆4K 10BIT HDR影片都能正常播放了,本想年前買入Q5 4代,現在也不必了。(播放機 自組 INTEL 4560 H110M-ITX 8G)
回覆 支持 反對

使用道具 檢舉


 樓主| 發表於 2019-1-15 16:14:06 | 顯示全部樓層
man3000 發表於 2019-1-15 01:18 PM
真的不必如此麻煩了,裝了KODI 18 RC5.2 64BIT版後,一堆4K 10BIT HDR影片都能正常播放了,本想年前買入Q5  ...

不錯不錯,但能播和播好還是有區別的,madVR動態映射能彌補HDR10的天生缺陷。
回覆 支持 1 反對 0

使用道具 檢舉


 樓主| 發表於 2019-2-11 20:52:10 | 顯示全部樓層
“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.)”
回覆 支持 反對

使用道具 檢舉


 樓主| 發表於 2019-2-13 14:34:36 | 顯示全部樓層
本文最後由 6hzzz 於 2019-2-13 06:56 PM 編輯

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.

gdzy4kpq.JPG
串流測試


回覆 支持 反對

使用道具 檢舉


發表於 2019-2-15 09:26:43 | 顯示全部樓層
Here's the next test build:

http://madshi.net/madVRhdrMeasure45.zip

和44版最大的差異在多了 brightness speeds 數值調整
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-2-17 21:17:18 | 顯示全部樓層
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.
回覆 支持 反對

使用道具 檢舉


發表於 2019-2-18 16:48:11 | 顯示全部樓層
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.
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-2-19 12:55:46 | 顯示全部樓層
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.
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-2-21 09:07:24 | 顯示全部樓層

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.
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-2-22 20:55:52 | 顯示全部樓層
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).
回覆 支持 反對

使用道具 檢舉


發表於 2019-2-23 08:08:54 | 顯示全部樓層
回覆 支持 1 反對 0

使用道具 檢舉


發表於 2019-2-23 10:15:02 | 顯示全部樓層
knk 發表於 2019-2-23 08:08 AM
http://madshi.net/madVRhdrMeasure57.zip

修復bug

感謝分享。
回覆 支持 反對

使用道具 檢舉

您需要登錄後才可以回文 登錄 | 註冊

再次提醒,當您點擊發表回覆,視同您已經明白本討論區的版規,如不明白請先參見各版版規。

熱門推薦

BenQ 推出HDR舒視屏護眼螢幕EW3270U
BenQ 推出HDR舒視屏護眼螢
發展獨家類瞳孔技術 復刻視界 帶來雙倍舒視 護眼螢幕領導品牌
請問 有大大聽過 Creative Sound BlasterX Katana 全頻電競音箱
請問 有大大聽過 Creative
小弟 對這一組 還滿感 興趣的 可是 網路上 很少人在 討論 想問
HTPC校色的福音--DisplayCAL + MadVR
HTPC校色的福音--DisplayC
本帖最後由 JUDAS 於 2018-3-5 10:47 AM 編輯 用HTPC當訊源10
小試身手就可以越級打怪-秦朝3115D
小試身手就可以越級打怪-
音響其實是比較級的東西,早期剛開始接觸沒幾年的時候都會有很比
LCT小劇院
LCT小劇院
2010年看到小呆被家訪的文章後,其實認識很久了,也因此又和小呆

聯絡我們| 問題反映| 小黑屋| 手機版| Archiver|  本網站特別聘請 蔡家豪律師 為本站法律顧問

快速回覆 返回頂部 返回列表