樓主: 6hzzz
收起左側

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

  [複製連結]
 樓主| 發表於 2019-2-23 11:03:34 | 顯示全部樓層
knk 發表於 2019-2-23 08:08 AM
http://madshi.net/madVRhdrMeasure57.zip

修復bug

沒有元數據的HLG也能這麼玩就好咯。。
回覆

使用道具 檢舉

發表於 2019-2-23 19:20:26 | 顯示全部樓層
http://madshi.net/madVRhdrMeasure58.zip

Here's a new test build, just added Bicubic125 and Bicubic150
回覆

使用道具 檢舉

發表於 2019-2-24 08:26:44 | 顯示全部樓層
http://madshi.net/madVRhdrMeasure59.zip

I expect much larger differences for metric2 here, compared to using different downscaling algos.

1) There are 3 different options with 3 different settings each, which combines to 3 * 3 * 3 = 27 different variants, all fused into one drop-down-box. Don't be alarmed by the high number of options. You don't have to test them all. You can test the 3 options separately, with 3 variants each.

2) Generally, for your information: While metric1 looks at the histogram, metric2 does a pixel-wise image comparison between 2 frames, but in a much smaller resolution, with a little bit of motion matching included.

3) The "small" vs "medium" vs "large" option decides how far madVR downscales the two comparison frames, before it does pixel-wise comparison + motion matching. Using "small" has the advantage that wider motion vectors can be matched, but it might lose a bit of accuracy because of the smaller resolution. Using "large" has the opposite effect, obviously. The previous builds used "medium".

4) The "normal" vs "wide" vs "extra wide" option decides how far away madVR looks to match motion vectors. Looking further away makes processing slower, but should improve accuracy. Looking further away reduces the metric2 numbers quite a bit, both for real scene cuts, and for false positives. So if you look further away, you need to lower the metric2 threshold a bit. The previous builds used "normal", which is the smallest possible supported motion vector distance.

5) The "simple" vs "complex" vs "wildly complex" option decides how accurate the motion matching is. Simple is stupid, but kinda works and is fast. The more complex we go, the slower the algorithm becomes, but the results will also get more accuracte. Going more complex will increase the metric2 numbers, so if you go more complex, you may have to increase the threshold a bit. Going more complex is supposed to increase true scene cuts more than false positives, but both are increased to some extent. The previous builds used "simple".

6) Probably "wildly complex" + "extra wide" should give the best scene detection results, but will also cost quite a bit of extra performance. So the big question is: Is it worth it? How much speed does it cost you? And how much does it improve metric2 quality? The speed hit will depend on "small" vs "medium" vs "large". The smaller we go, the fast it becomes.

7) I've no idea right now if "small" vs "medium" vs "large" is best. FYI, if you go large, using "normal" might not be good enough, you may have to use "wide" or "extra wide" then. While when you go "small", maybe you can get away with "normal" or "wide".
回覆

使用道具 檢舉

發表於 2019-2-25 16:25:55 | 顯示全部樓層
Here's yet another new test build:

http://madshi.net/madVRhdrMeasure60.zip
回覆

使用道具 檢舉

發表於 2019-2-26 17:16:43 | 顯示全部樓層
一下子就64版了
http://madshi.net/madVRhdrMeasure64.zip

This has the same old "always adjust" and "choose lowest diff" as the previous build, but it adds one new "always adjust" and two new "choose lowest diff" variants. So there's 5 options overall, but for 2 of them you can simply copy the data from build 63.
回覆

使用道具 檢舉

發表於 2019-2-27 11:25:57 | 顯示全部樓層
here's a new build with an option to disable the FALL tweak for Metric2:

http://madshi.net/madVRhdrMeasure66.zip
回覆

使用道具 檢舉

發表於 2019-2-28 20:09:42 | 顯示全部樓層
本文最後由 knk 於 2019-2-28 08:10 PM 編輯

http://madshi.net/madVRhdrMeasure67.zip

Some of the new options don't work on my AMD GPU, for whatever weird reason. But I hope Fer15 and Neo-XP have Nvidia GPUs? Of course if the new options prove useful, I'll fix it for AMD somehow. Also, some of the new options aren't speed optimized (yet). So don't worry too much about performance right now.

There are 4 different "high freq" variations. They're pretty similar, just with different parameters. If you guys find that these don't work well at all, you can skip the whole bunch of them.

The first option is "CLD - New 2", which is the best of the previous test build. This option should produce the exact same results as in the previous build. All other options are new.
回覆

使用道具 檢舉

發表於 2019-2-28 20:09:54 | 顯示全部樓層
回覆

使用道具 檢舉

發表於 2019-3-2 19:35:47 | 顯示全部樓層
here's a new test build:

http://madshi.net/madVRhdrMeasure69.zip

The first option is the same as always (CLD New 2). The next 3 options are slight variations of CLD New 2. These variations are independent of each other. Which means every one which seems useful can probably be combined. So even if one of these look much better than the others, it's still worth testing all, because every small improvement can add up, if we combine these.

The next 3 options I'm not sure about. They could work, or maybe not. If you find in early testing that some of these don't work well, you can ignore those which don't appear to be useful, of course.
回覆

使用道具 檢舉

發表於 2019-3-6 09:47:03 | 顯示全部樓層

http://madshi.net/madVRhdrMeasure70.zip

This comes with my last new "big" idea for improving Metric2 (looking at the (spatial) smoothness of the detected motion vectors). If this doesn't help much, we're probably at the end of improving Metric2. Otherwise, if it does help, maybe we can tweak the new idea a bit more. But we'll soon be done with optimizing Metric2.
回覆

使用道具 檢舉

發表於 2019-3-7 07:25:14 | 顯示全部樓層

http://madshi.net/madVRhdrMeasure71.zip

It has 4 options with different values (0.1, 0.25, 0.5 and 1.0) for one parameter which helps fix the issue coming out of black. The previous build's "motion smoothness" option had this parameter set to zero. I'm not sure which is the best value to use here. In my quick tests 1.0 worked well, but I suspect that with certain motion speeds it might cause false positives, so it might make sense to use the lowest value which still detects high APL changes well (?). But I guess if the test shows a clear preference for higher values of this new parameter, I could live with that, too.

Not sure what to do with the Lucy white background sample, but at least the new "motion smoothness" algo doesn't seem worse with that sample than the old "CLD New 2 - max 4" algo?
回覆

使用道具 檢舉

 樓主| 發表於 2019-3-7 23:09:55 | 顯示全部樓層
New test build:

http://madshi.net/madVRhdrMeasure72.zip

The algos have actually changed quite a bit. I think/hope for the better. Included are 5 options, which should all work with the IT scene. The first one should probably not be used, because it doesn't detect the La La Land cut from black. However, other than La La Land, it gives me the best numbers (in a very quick and short test), so I've still decided to include it. The other 4 options should work for La La Land.
回覆

使用道具 檢舉

發表於 2019-3-9 11:28:15 | 顯示全部樓層

http://madshi.net/madVRhdrMeasure74.zip

Should now properly reproduce build 71. Furthermore, the bug fix which made this happen should also improve all 72 algo variations. So 74 can not be used to reproduce 72, anymore. But it should be better than 72, with the "same" settings.
回覆

使用道具 檢舉

發表於 2019-3-11 08:27:13 | 顯示全部樓層
回覆

使用道具 檢舉

 樓主| 發表於 2019-3-12 00:04:52 | 顯示全部樓層
http://madshi.net/madVRhdrMeasure76.zip

This build has options from 0% to 100% for a new setting which hopefully fixes high APL changes etc, without harming other scenes too much. In theory the 0% setting is identical to build 75, using "1 smooth iteration". However, I've found that APL changes from bright to dark were valued differently to APL changes from dark to bright. I've fixed that in build 76, so please also test 0%. Thanks!

https://www.avsforum.com/forum/2 ... 8.html#post57726920
回覆

使用道具 檢舉

發表於 2019-3-12 07:46:40 | 顯示全部樓層
http://madshi.net/madVRhdrMeasure77.zip

All options include the 76 tweak to hopefully detect high APL changes better. There are 4 options now which define how APL differences are adjusted, when comparing two consecutive frames. From Fer15's results it seems that the 2nd option (what build 76 did) doesn't work well. But of course you can run a very quick test to see if you get the same results. I did a very minor change to that algo, but I don't think it will make a difference, so I believe Fer15's results will stand.

Will be interesting to see if:

1) Does detection of high APL changes actually work? Or is at least improved?
2) Using the "75" option, are the number of misses the same compared to the 75 build, or better/worse?
3) Are the last two options better than the "75" option or worse?
回覆

使用道具 檢舉

 樓主| 發表於 2019-3-12 23:27:08 | 顯示全部樓層
Here comes the next test build:

http://madshi.net/madVRhdrMeasure78.zip

I've had to change the algorithm parameters slightly because Fer15 had some new false positives when using the settings that Neo-XP got the best results with. But I also found a small improvement (I hope). So I hope the first option in this new build will perform ok for both Neo-XP and Fer15? I guess if there's 1-2 more misses for either of you, we could live with that, but it shouldn't be worse than that, or otherwise we may have to re-investigate.

There are 3 new options, which I'm not sure about. They could potentially improve things slightly, or make things much worse.

FWIW, I've tried making the weird La La Land scene change work, which currently is not detected, but somehow my Metric2 algo doesn't like to detect this scene. It's caused by both frames having large "flat" areas with no image detail/features in them. At this point I don't think I can fix it, at least I don't know how.

We're nearing the end of Metric2 improvements. I've one "bigger" idea to still try (probably in tomorrow's build), but then I'm out of ideas...
回覆

使用道具 檢舉

發表於 2019-3-22 13:04:14 | 顯示全部樓層
本文最後由 PAC 於 2019-3-22 01:07 PM 編輯

2.jpg 請問這樣是否在Measure嗎?行了很久無反應的,工作管理員內也不見madVRhdrMeasure.EXE走運作‧謝謝
回覆

使用道具 檢舉

發表於 2019-3-22 14:02:20 | 顯示全部樓層
PAC 發表於 2019-3-22 01:04 PM
請問這樣是否在Measure嗎?行了很久無反應的,工作管理員內也不見madVRhdrMeasure[/backcolor ...

2.jpg 用了一個多鐘唯有取消
4.jpg
回覆

使用道具 檢舉

 樓主| 發表於 2019-3-22 14:02:51 | 顯示全部樓層
本文最後由 6hzzz 於 2019-3-22 02:06 PM 編輯
PAC 發表於 2019-3-22 01:04 PM
請問這樣是否在Measure嗎?行了很久無反應的,工作管理員內也不見madVRhdrMeasure[/backcolor ...

改用這個工具吧:

madMeasurementMakeHardLink v1.1.0.0.zip (16.42 KB, 下載次數: 198)

"Simple AutoMeasure Tools for UHD clones" created by pandm1967 (use download link in pandm1967's signature):
https://www.avsforum.com/forum/24-di...l#post57434744
回覆

使用道具 檢舉

你需要登入後才可以回覆 登入 | 註冊

本版積分規則

熱門推薦

Sony 首款BRAVIA True RGB 系列出色亮相 - 旗艦級BRAVIA 9 II、高階款BRAVIA 7 II 實現極致原色
Sony 首款BRAVIA True RGB
Sony今日 (2026/6/16) 正式在台發表全新革命性的BRAVIA True RG
「買進美好生活!」榮幸參訪實踐精緻C/P精神美宅客廳Starke Sound 5.1.2多聲道系統!
「買進美好生活!」榮幸參
「買進美好生活!」榮幸參訪實踐精緻C/P精神美宅客廳Starke Soun
空間和揚聲器數都不能限制的Hi-End沈浸感 - Storm Audio風暴/Wilson Audio 5.2.4客廳劇院系統開箱!
空間和揚聲器數都不能限制
空間和揚聲器數都不能限制的Hi-End沈浸感 - Storm Audio風暴/Wil
A1 EVO AcoustiX 空間校正與實測心得分享
A1 EVO AcoustiX 空間校正
A1 EVO AcoustiX 空間校正與實測心得分享 好友陳治學使用近來網
將「頂級 Hi-End 兩聲道」與「旗艦多聲道劇院」完美融合的7.2.2 StormAudio風暴/Burmester/dCS客廳超級多聲道系統
將「頂級 Hi-End 兩聲道」
將「頂級 Hi-End 兩聲道」與「旗艦多聲道劇院」完美融合的7.2.2

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

快速回覆 返回頂端 返回清單