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

使用道具 舉報


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

使用道具 舉報


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

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

使用道具 舉報


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

使用道具 舉報


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

使用道具 舉報


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

使用道具 舉報


發表於 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?
回覆 支持 1 反對 0

使用道具 舉報


 樓主| 發表於 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.
回覆 支持 1 反對 0

使用道具 舉報


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

使用道具 舉報


發表於 2019-3-11 08:27:13 | 顯示全部樓層
回覆 支持 1 反對 0

使用道具 舉報


 樓主| 發表於 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
回覆 支持 1 反對 0

使用道具 舉報


發表於 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?
回覆 支持 1 反對 0

使用道具 舉報


 樓主| 發表於 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...
回覆 支持 1 反對 0

使用道具 舉報


發表於 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, 下載次數: 196)

"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
回覆 支持 反對

使用道具 舉報

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

本版積分規則

熱門推薦

Matt88p 的夢想小小影院
Matt88p 的夢想小小影院
小時後便很喜歡去電影院, 最喜歡是進場前那份感覺, 電影院裏面
終於朝聖桃園樓中樓美宅風暴/Genelec 7.2.4劇院!
終於朝聖桃園樓中樓美宅風
終於朝聖桃園樓中樓美宅風暴/Genelec 7.2.4劇院! 「沒ART這種
新視聽室終於好了!! 續~人生第一間視聽室 關箱文
新視聽室終於好了!! 續~人
續上一篇~人生第一間視聽室 "關"箱文 ------------------------
7.2.6 StormAudio風暴/Ken Kreisel劇院強襲苗栗!
7.2.6 StormAudio風暴/Ken
7.2.6 StormAudio風暴/Ken Kreisel劇院強襲苗栗! 這位科技業的
HBO Max串流影音服務將在今年進入台灣在內亞洲市場
HBO Max串流影音服務將在
在日前宣布過去曾帶領推廣Disney+東南亞業務發展的Amit Malhotra

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

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