婆罗门
精华
|
战斗力 鹅
|
回帖 0
注册时间 2011-4-2
|
本帖最后由 暁美ほむら 于 2024-10-1 21:49 编辑
new build 207 released
http://madshi.net/madVRhdrMeasure207.zip
Changes:
1) Fer15 has cooked up another new promising TM curve, called "Luna".
2) I've added a new option called "no scene change if APL is within [...]".
3) I've fixed an issue where a Wednesday scene flickered.
New option discussion "no scene change if APL is within [...]":
Looking at the various brightness instability samples that you guys provided and Manni collected, I've noticed that many of them are caused by scene change detection not working correctly. It is very difficult to get scene change detection working well, though, because in heavy action scenes so much is happening on screen that it's hard to understand for a computer program if it's still the same scene or not. Sometimes things move around like crazy, sometimes the whole frame suddenly gets much darker or much brighter (due to lightning or an explosion or things like that). That just makes it incredibly hard to detect scene cuts reliably.
Anyway, several of the collected samples failed because madVR thought there was a scene change when there really wasn't one. So the new option "no scene change if APL is within [...]" now rejects a detected scene cut if the frame before and after the alleged scene cut have an APL (average picture level = overall brighness) that is very near to each other. In simpler words: If you activate this option, madVR will no longer think that there's a scene cut if the average image brightness before/after the alleged scene cut is very similar. This new option seems to fix several of the problems with the collected samples.
The new option rejects a detected scene cut if either the APL is smaller than a specific percentage or if it's smaller than a specific nits difference. E.g. let's say frame 10 has an APL of 20 nits and frame 11 has an APL of 24 nits. Then the scene change is rejected because the absolute nits difference is 4, and the default option for that requires a change of at least 5 nits. Or let's say the APL of frame 10 is 100 nits and the APL of frame 11 is 109 nits, then the scene change is rejected because the relative APL difference is 9%, and the default option for that requires a change of at least 10%.
I assume that the default values I've chosen are probably too aggressive. These values may need to be lowered, most probably. With the current default values, many true scene cuts will probably not be detected as such. Which could cause problems of its own (e.g. image elements being blown out or too dark after a scene cut). So we need to find the optimal values there. Hope you guys can test it and report what works best for you?
Brightness instabilities:
Let's hunt down brightness instabilities. Please understand there are various different issues here:
1) There could be flickering (the image jumping back and forth between different brightness levels very quickly).
2) There could be a sudden and unexpected brightness jump in the middle of a scene.
3) There could be a smooth but unwanted brightness adaptation.
4) There could be image areas blown out or the image staying too dark, due to brightness adaptation not being fast enough.
Problem 1) is something I would consider highest priority and if you have any samples that reproduce this, please provide them.
Problem 2) is probably caused by scene change detection misfiring. This may be very hard to solve (if possible at all), if the new option I introduced (see above) doesn't help.
Problems 3) and 4) are competing against each other: Sometimes there are scenes which start dark and go much brighter in the middle of a scene (or vice versa) and in such situations, we have to live with either a visible brightness adaptation or some image elements being (and staying) blown out or being too dark. It's probably not possible to solve both at the same time. So this might have to be left to anyone's taste. And currently, you can choose your preference by adjusting the "no diff, 20% dif, 50%, 100%, 200%, 400%, 800%" brightness adaptation speed options. In the long run, we should dumb this down to 1 simple dropdown option.
Potentially, it could be possible for problems 3) and 4) to differ between scenes that go brighter vs scenes that go darker? Maybe we want to adapt faster in one case vs the other? That is certainly something we can experiment with.
When testing for brightness instability issues, please disable HSTM / Contrast Recovery for now.
We will look into flickering / brightness instability issues caused by HSTM separately at some point in the future. |
-
|
沪公网安备 31010702007642号 )
发表于 2021-1-4 03:07
难不成我换mpc-be可以画质开高点？！
