madVRhdrMeasure changelog

http://madshi.net/madVRhdrMeasure204.zip

1) Removed "alternative histogram" option.
2) Reordered the options once more by topic.
3) Fixed: Custom TM curves weren't working.

After looking at my code, I've moved the "flicker protection" option to the HSTM section, because it only affects HSTM. And I've moved the brightness adaptation speed and "flicker risk multiplier" options to the TM curve sections, because these options are heavily related to the TM curve and brightness adaptation behaviour. The name "flicker risk multiplier" is probably badly chosen because it actually affects madVR's estimate of how risky (= visible) it is to do a quick brightness adaptation.



http://madshi.net/madVRhdrMeasure203.zip (Fixed: 64bit build crashed.)
http://madshi.net/madVRhdrMeasure202.zip

1) Dialed in HS 0.5, Boost 1.75.
2) Reordered the remaining options.



http://madshi.net/madVRhdrMeasure201.zip

1) Replaced "gamut roll-off" controls with a new "highlight saturation" dropdown box, going from -4 (0/17) to +4 (80/17). Value +5 disables gamut roll-off completely.



http://madshi.net/madVRhdrMeasure200.zip

1) "Added headroom" option removed, now hard coded to 10.



http://madshi.net/madVRhdrMeasure199.zip

1) Renamed "baked-in desat" to "global desaturation" and moved it to its new (and final) home as a permanent option.
2) Increased "global desat" range to 0% - 200%, just for testing purposes.
3) Added some finer steps for the "highlight sat & boost" options.
4) Removed "disable luma repair" option.
5) Removed ACES.
6) Moved "custom gamut" options to a different place.

The next few options I want us to dial in are now in the top right of the HDR settings page. And I'd prefer to dial them in in the order the options are listed there. So "added headroom" first, then "highlight sat & boost" and finally gamut roll-off.



http://madshi.net/madVRhdrMeasure198.zip

1) Removed "fix oversaturated luminance" option (now always active).
2) Removed "out of gamut darkening" option.
3) Removed "HS gamut boost" option.
4) Added "highlight sat boost" checkbox to make it easier to turn the HS compression boost on/off.

(Guys, I've heard your wish to have the custom gamut moved. Will do that in a future build. No time for that now.)

@Javs, the most important question is whether we still need ACES. I don't think so. The built-in always-on new "fix oversaturated luminance" algo seems to provide 99% of the benefits ACES brought without costing any visible saturation. But would be great if you could double check.



http://madshi.net/madVRhdrMeasure197.zip

1) Fixed some banding problems with the new "fix oversaturated luminance" option, when using gamut roll-off.



http://madshi.net/madVRhdrMeasure196.zip

1) Fixed new option "fix oversaturated luminance" once more.

When I tried to fix the pinkish hue issue yesterday in build 195, I actually completely broke the "fix oversaturated luminance" option. I'm sorry for wasting everyone's time. Hopefully, the new option is finally working correctly now?



http://madshi.net/madVRhdrMeasure195.zip

1) Fixed: Using the new "fix oversaturated luminance" option together with "gamut roll-off" turned reds pink(ish).



http://madshi.net/madVRhdrMeasure194.zip

1) Fixed: The new "fix oversaturated luminance" option was only active with "gamut roll-off" disabled.



http://madshi.net/madVRhdrMeasure193.zip

1) Added new "fix oversaturated luminance" option.

Great news!!

After thinking about the problems once more, I've figured out a way to improve the gamut handling itself, without needing to activate any fancy complicated options. This is the new "fix oversaturated luminance" option. I believe this option is great, and should be enabled at all times. But just to double check, I've added it as an option in this build, so you can easily compare on vs off.

To give you a quick first impression of what this option does, let's first start by looking at the bobof test pattern with all the fancy options (ACES, gamut roll-off, luma repair) completely disabled. It looks pretty much broken:

naked - before
settings

Now let's compare this to what Fer15's weird settings do. As I explained before, Fer15's settings do not actually do ACES compression, but instead they do ACES expansion, which somehow (in team work with Highlight Sat) improves things to some extent, without actually changing saturation in the end. Here's how it looks, once more with all fancy options disabled:

Fer15
settings

Finally, I've found a way to properly fix the bobof test pattern, simply by improving my gamut handling math/code. This looks even better than Fer15's results. See here:

naked - after
settings

Now as I said, this new "fix oversaturated luminance" option should probably always be on, and the option removed, which I think renders the Fer15 settings superfluous. Can you please double check that and confirm?

Many thanks for Fer15 for breaking the ACES algorithm in such a way that I was "forced" to double check my whole gamut mapping math once more to understand what was going on!



http://madshi.net/madVRhdrMeasure192.zip

1) Undid the change that caused heavy artifacts in some colorbar test patterns.
2) Added "alternative ACES math" option, which may look a bit better (or not, please test and let me know).
3) Added "don't hue correct blue" option which still applies ACES compression to blue, but doesn't try to fix the hue afterwards. This keeps a lot more saturation, for some reason.
4) Added "HS gamut boost" option, which allows you to boost the HS value for pixels that are near to (and beyond) the output gamut boundary.
5) Added "HS compress boost" option, which allows you to boost the HS value for pixels that were compressed a lot by tone mapping.

I'm sorry for the bunch of new options. Please let me guide you through this, so we don't lose focus:

After analysing Fer15's ACES settings more carefully, and studying the algos and my code, I've come to the conclusion that Fert15's ACES settings completely disable ACES compression, and instead what these settings do is they make pixels which are outside of the output gamut slightly darker (which happens due to the way ACES + HS work together). So basically Fer15's ACES settings are somewhat similar to the "darkening" feature. Though, maybe Fer15's settings look better than what the "darkening" does? In any case, his settings do not perform any gamut compression at all. Which of course has the benefit of keeping more saturation. But the results are not always optimal, because only some colors are affected by his ACES settings, but not all, so the results can vary and are not 100% reliable.

You can see some of this when disabling gamut roll-off. The upper red bar is not clearly separated with Fer15's settings, and there are 2 pink squares which seem more saturated than the others. The bars look much more even with Austonrush's settings:

bobof color bars - Fer15
bobof color bars - Austonrush

I'm hoping that the "alternative ACES math" option, potentially combined with the 2 new "HS gamut boost" options, may allow us to beat Fer15's settings in quality, while producing more reliable results overall? I'll leave that to you guys to test in detail.

For now, the focus should be on testing whether we can replace Fer15's settings with something that actually performs proper ACES compression. For now, we do not necessarily need to dial all the new options in perfectly. The short term goal is to dial in just ACES compression, nothing else.

Personally, I'm hoping we can use Austonrush's settings for BT.709, and simply infinite power for all other gamuts.



http://madshi.net/madVRhdrMeasure191.zip

Does this one fix the artifacts in some test patterns, Austonrush? Not sure if it does, I just tweaked the math ever so slightly.



http://madshi.net/madVRhdrMeasure190.zip

1) Removed a whole bunch number of lum method related options.
2) Simplified the code to only support the final Custom Sep and Stim options.
3) Changed the ACES math to properly support "infinite" Power, which actives for any Power values bigger than 50.

Using a very high (or infinite) Power basically simply clips saturation to the gamut boundary. So it's no longer a roll-off in that case, but a simple straight clip. But it still looks good to me, to be honest.

New area of focus:

Two things:
a) Does "clip to 4000 nits" ever harm? If I don't get any complaints, I'll remove this option in the next build and always force it on.
b) Please help dial in ACES compression now. I think if we dial it in carefully, not going overboard, this option should not collide with any of the other options. So we should be able to dial it in properly all by itself.

FWIW, in my ACES tests, I've found that the middle threshold (magenta) seems to be the most important one, it affects e.g. Atomic Blonde and the Mad Max Color Cloud frames. The other 2 thresholds show a difference in the Bobof color bar test pattern, but I'm struggling to see an effect in real world images. So I'm actually wondering if ACES 1.0, 0.8, 1.0 with 0.2 splits and 100 (= infinite) power is a valid option? I'm not sure.

Furthermore, I've so far only tested BT.709. We need DCI-P3 users to experiment with ACES thresholds for DCI-P3, please!



http://madshi.net/madVRhdrMeasure189.zip

1) Custom Sep now has a new "added headroom" option.



http://madshi.net/madVRhdrMeasure188.zip

1) Removes ACES limits, these are auto calculated now.
2) Calc button has no options now, it simply calculates the thresholds based on protecting the colorchecker colors.
3) Removed "improved stim measurements" and "improved hk math" and "process ACES in BT.2020" options.
4) Replaced lum method dropdown box with a "use Custom Sep" check box.
5) Added "clip at 4000 nits" option. See remarks below.
6) Added "stim punch boost" option. See remarks below.
7) Added "dyn tuning boost" option. See remarks below.

"Clip at 4000 nits" always clips content at 4000 nits, except if the mastering monitor metadata says that the mastering monitor was brighter than 4000 nits. In that case the content is clipped to the brightness of the mastering monitor.

"stim punch boost" allows you boost the punch/brightness of Stim from 0 - 100%. This will improve some scenes, but make Atomic Blonde worse.

"dyn tuning boost" modifies the dynamic tuning in such a way that "difficult" frames (like Atomic Blonde) are auto-detected and made darker by 0 - 100%. This new option may allow using some amount of "stim punch boost" without destroying Atomic Blonde. Please note that this option is only effective if you have "dynamic target nits" activated. Also please note that this option works for both Stim and Custom Sep, unlike "stim punch boost", which only works for Stim!

Please test "Clip at 4000 nits" first, using your current preferred settings, to check if it ever does any harm. If it does not do any harm, then I'll force it on in the next build and remove the option. So if you find that it's good and never harms, please in any future tests with this build, simply keep this option checked/activated.



http://madshi.net/madVRhdrMeasure187.zip

1) The frame measurements (peak + histogram) were optimized for Max/Sep/Custom Sep, but not for Stim. So now I've added a new option called "improved stim measurements". This seems to improve stim a bit more, so please give this a go and let me know if this is an improvement for you, as well. FWIW, I've found that it gives back some punch I was missing, e.g. in the Mad Max lightning frame.

2) aron7awol suggested a tweak to his HK math, so I added an option to activate this change. I'm not sure if I like what this change does, but you guys please give it a try and let me know your thoughts.

I'm very much hoping that these will be the last changes before we can make a lum method decision. I'm hoping to make a final decision in 1-2 weeks.



http://madshi.net/madVRhdrMeasure186.zip (fix: wrong files were uploaded)
http://madshi.net/madVRhdrMeasure185.zip

- custom gamut back in



http://madshi.net/madVRhdrMeasure184.zip

1) HK strength can now be adjusted separately for Red, Green and Blue.

The purpose of this change is that for Custom Sep, Blue is already dark enough as it is, so it may make sense to use HK only for Red and Green hues (?).



http://madshi.net/madVRhdrMeasure183.zip

1) Temporarily removed "custom gamut" feature (just to make room in the settings dialog), will be back after we're done with HK lum method testing.
2) Added lum method option back in with "Custom Sep, Sep, Stim and Max".
3) Added "HK effect" option, with a strength option (0-100%). This effects all lum methods except "Max".
4) Added Custom Sep RGB edit fields back in.

Please remember that Custom Sep RGB numbers need to add up to 100.

I'm hoping that we can test and sort out the new HK option quickly? I'd like to end up with only 1 lum methods for low(er) DPLs and 1 lum methods for high(er) DPLs.



http://madshi.net/madVRhdrMeasure182.zip

1) Changed ACES label "rgb" to "cmy", just cosmetics.
2) Swapped order of "split" vs "limit" options, because "thresh" and "split are closely related.
3) Added a "calc" button which allows calculating thresh, limit and split values for your specified output gamut (including support for custom gamuts).

The processing itself has not changed. The only "important" change is that there's a button to let you calculate ACES numbers for various gamuts.

Please allow me to explain how the calculation works:

The "calc thresh - colorchecker 24" option calculates the ACES compression threshold (knee) in such a way that the 24 colorchecker colors are "protected" from ACES compression. I'm not actually sure if this is a good approach or not. For example, since the colorchecker colors are pretty close to the BT.709 gamut boundaries, the thresholds become pretty close to 1.0, so not much desaturation is actually performed, even if we go from BT.2020 to BT.709. However, when the output gamut is DCI-P3, the colorchecker colors are much further away from the DCI-P3 gamut boundaries, so the calculated thresholds are much further away from 1.0, which means that when doing BT.2020 -> DCI-P3, the gamut compression is a bit stronger than when doing BT.2020 -> BT.709. Which seems weird to me. But maybe it does make sense, since maybe we do want to protect those colorchecker colors and only compress colors that are even wider than those?

The "calc limit - to BT.2020 boundaries" calculates the ACES limit in such a way that the compression exactly reaches the BT.2020 gamut boundaries, but doesn't go beyond. I think this calculation probably makes sense (why would we want the compression curve to go beyond BT.2020 boundaries!?). At least there's an argument that we may not want to exceed these limits? Or what do you guys think?

The "calc limit - to DCI-P3 boundaries" calculates the ACES limit in such a way that the compression exactly reaches the DCI-P3 gamut boundaries, but doesn't go beyond. Since many (most?) movies are limited to DCI-P3, anyway, maybe it makes sense to do this? However, this doesn't seem to look much different to the "calc limit - to BT.2020 boundaries" option, as far as I can see. So maybe this option is useless?

So a couple questions we have to answer now:

1) I'm assuming that it makes sense to set the ACES compression "limit" so that the compression curve doesn't go beyond the BT.2020 boundaries, right? If so, maybe we should remove the "ACES limit" option and set it programmatically to match the BT.2020 gamut boundaries?

2) I'm completely unsure about whether the 24 colorchecker approach makes sense or not. I understand the purpose, and it seems logical. But is this really the best approach? I'm not sure. However, that is how the original ACES formula was tuned. So that's an argument for us using the same approach (but based on our gamuts instead)?

3) If we do use the 24 colorchecker approach, when using BT.709 output, the Cyan threshold goes above 1.0. Do we actually want to use it that way? Or should we clip the Cyan threshold to 1.0? It produces different results. So it's something we need to check and decide.

4) The "split" values are currently calculated the way the ACES formula was designed. But I'm not 100% sure if this will always produce the best looking results. E.g. if the Cyan threshold is at 1.0 or even above 1.05, the resulting "split" value would have to be negative (or 0.0), but that basically disables the compression curve and turns ACES compression into a clipping shape, I think (?). So shouldn't we use a small positive split value in this case?

5) Or maybe we should find a different/better approach to find/calculate the ACES thresholds?



http://madshi.net/madVRhdrMeasure181.zip

1) ACES "split" parameter is now separately available for R, G, B.
2) Separated the "map" and "darken" features into separate dropdown boxes. Now you can also apply darken more gradually (in 10% steps).

Atm, I've no more ideas on how to improve out-of-gamut color handling. So I hope that this will be the final build we can use to dial all the new features in, and remove all features that are not needed.



http://madshi.net/madVRhdrMeasure180.zip

1) "map" is now available in 10% steps, to give you more control.
2) The ACES "repair hue & lum" options were removed (always on now).
3) Added ACES "split" option to give you more control over the compression curve.
4) Modified the ACES compression formulas to give us more control.
5) Added ACES "process in BT.2020" option, to allow you to apply ACES compression in BT.2020 instead of the output gamut.

The default option for the "split" parameter is 0.2, which should be roughly similar to how the original ACES compression parameters worked. The "split" parameter defines how much of a curve we have. The bigger this value is, the less clipping we have, and more of a curve. The "split" parameter is important if we increase the "threshold" parameter, because in the previous builds, when using a threshold near to 1.0, the "split" internally went down to near zero (it was calculated like "1.0 - threshold"), which basically turned the ACES "curve" into a clipping graph. Now if you keep "split" set to 0.2, you can increase the threshold up to 1.0, or even beyond 1.0, and there will still be a compression curve applied. The compression does start at the threshold, and it will then compress above that. A split value of around 0.2 look fine to me, but you can experiment with different values, if you like.

In order to find good threshold + limit + split values, I'd recommend to use the same values for Red, Green and Blue as a starting point. Once you're happy, you can still tune the values some more, by maybe trying different values for Red, Green and Blue. In theory, I could also allow the "split" value to be set differently per RGB channel. But I wonder if all of this is even needed. Using the same threshold, split and limit for all 3 channels might be fully sufficient?

I don't recommend using the "process in BT.2020" checkbox. However, if you like it, we can discuss it. It should do roughly what build 178 did - if you set all the other ACES parameters to their default and "split" to around 0.2.



http://madshi.net/madVRhdrMeasure179.zip

1) fixed: ACES compression always worked in BT.2020, ignored target gamut



http://madshi.net/madVRhdrMeasure178.zip

1) added ACES gamut compression with roll-off
2) added "repair hue" and "repair lum" options for ACES gamut compression

The ACES thresholds should be below 1.0. This is the knee where saturation starts being rolled off.

The ACES limits should be above 1.0. This is the saturation amount that is rolled-off to the gamut boundary. Anything above the limit is clipped.

My finding is that ACES gamut compression might actually be feasible (thanks Javs for the suggestion). However, clearly not without "repair hue" post processing. Without the post processing, there are heavy hue shifts. I've no idea how the creators can live with that sort of heavy hue shifts, to be honest.



http://madshi.net/madVRhdrMeasure177.zip

- "out of gamut handling" now has a "darken" feature which can darken out of gamut colors
- "out of gamut handling" now has an improved "map" option
- map option now allows strength with 25%, 50%, 75% and 100%

Please note that the darkening can introduce luminance errors, so the "luma repair" feature is essential to make it feasible. The purpose of darkening is to give highlights more 3D depth, plus to reduce the strength of the needed desaturation. That said, in case you guys like the darkening feature, maybe we should limit it to pixels which have a specific minimum brightness. Otherwise there's a (small) risk that we might hurt shadow detail, if it happens to be out of gamut.



http://madshi.net/madVRhdrMeasure176.zip

1) Fixed: BT.2020 output with "clip" resulted in black or black&white screen.
2) Fixed: HDR output with custom gamut was broken.



http://madshi.net/madVRhdrMeasure175.zip

- added "out of gamut handling" option, with "ignore, clip, map" choices

The "ignore" choice is similar to what older builds did. The "clip" choice is slightly better, improvements show e.g. in the Mad Max "2 color clouds" image and in the green spear. The "map" choice is a difficult one: It properly maps out of gamut hues into the gamut. However, this can desaturate the image quite noticeable in certain situations. So I'm not sure if I really like this option, even though it might be technically/scientifically more accurate.



http://madshi.net/madVRhdrMeasure174.zip

I believe my code in build 173 was alright. However, I noticed that after mapping (with or without roll-off) into a custom gamut, often some of the RGB components went negative. And somehow that resulted in the custom gamut not becoming fully "effective". I'm not sure I fully understand the math, but it almost seems like the negative RGB components allowed some hues to survive within the smaller gamut, when later being converted back into the container gamut.

I'm now clipping negative RGB components to 0, after having mapped (with or without roll-off) into a custom gamut. I hope that solves the issues?



http://madshi.net/madVRhdrMeasure173.zip

Only change is that the following hard coded keyboard shortcuts were added (only temporarily):
Ctrl+Alt+Shift+E / D: modify roll-off start point
Ctrl+Alt+Shift+R / F: modify roll-off power
Ctrl+Alt+Shift+T / G: modify baked-in desat
Ctrl+Alt+Shift+Z / H: modify highlight sat



http://madshi.net/madVRhdrMeasure172.zip

Hopefully custom gamut works now?



http://madshi.net/madVRhdrMeasure171.zip

1) Log Very Very (Very) Low should work now.
2) Re-added "repair luminance" option (temporarily).
3) Simplified gamut roll-off to be hue-independent.
4) Changed "baked-in desat" to a 0-100% setting in 10% steps.
5) Added custom gamut option, but it's not working yet (hopefully tomorrow).

I have to say that disabling the baked-in desat can be quite seductive. There are several frames that benefit, e.g. the Mad Max car explosion, or the orange Sony Camp truck light, or the flower images from the UHD Benchmark disc. However, there are also several that suffer, e.g. the Mad Max 2 clouds image or the Batman vs Superman spear looks noticeably worse.



http://madshi.net/madVRhdrMeasure170.zip

1) Removed a few options which are (probably) no longer needed/useful.
2) Added option "disable baked-in desat".
3) Added "Log Very Very Low" and "Log Very Very Very Low" HSTM / Contrast Recovery options.



http://madshi.net/madVRhdrMeasure169.zip

1) Added the ability to define gamut roll-off per hue (with interpolation in between).



http://madshi.net/madVRhdrMeasure168.zip

Fixed: Noise issue in Travel with my Pet, when using "HSTM: no brightening".
Changed: "HSTM: no brightening" is now only active when HSTM is used



http://madshi.net/madVRhdrMeasure167.zip

1) Hard coded "max3 variant 2" to be the new "max3", with fixed parameters. So all lum methods are "done" now.
2) Fixed: OSD elements didn't show in paused state.

The new build will not complain until start of February 2024, to give us some breathing room.

Some users reported graphical corruption (visible noise pixels) when using Custom Sep. Can you please double check if that still occurs with this new build? Thanks!



http://madshi.net/madVRhdrMeasure166.zip

1) I've removed some lum methods.
2) I've dialed in the parameters of all the remaining "old" lum methods.
3) I've added "max3 variant 1" and "max3 variant 2", which still need to be dialed in.

The reason why I added "max3 variant 1" and "max3 variant 2" is that I've found that the max3 math wasn't fully adding up, so "max3 variant 1" and "max3 variant 2" are slightly different variations of max3 with a bit more exact math. They should look very similar to max3, but are ever so slightly different. With a bit of luck, not much tuning might be needed, and then hopefully we can make a quick decision which of the max3 variants we're going to keep. The other 2 will go.

I'm sorry for adding yet "new" lum methods. But hopefully it will be the last methods added, and hopefully they will be quick to be sort out, because they should be very near to max3.

Other than dialing in max4 and max5, we need to find suitable "Highlight Sat" settings for all remaining lum methods. I'm not sure if we can use the same Highlight Sat settings for each lum method. We may need to assign a specific Highlight Sat value to each lum method, or what do you guys think?

Finally, I've made a few changes to help with the "sep bug". But I've still had trouble reproducing the problems you reported. So can you please double check if there's still an issue? For me, as soon as I activate the "HSTM: no brightening" option, the "sep" lum method doesn't make the image brighter, anymore. I tried one of the "settings.bin" files a user attached to this thread a few days ago (sorry, I don't remember which one), but couldn't reproduce the issue with that one, either. But maybe I had already fixed something accidently in my latest source code? So please double check if the problem is still there with build 166.



http://madshi.net/madVRhdrMeasure165.zip

1) Removed "max3 mix" option, now hard coded to 0.
2) Fixed a Windows 11 specific problem with tons of "identifications" being added all the time, and profile shortcut keys not working (same cause).



http://madshi.net/madVRhdrMeasure164b.zip (fix crash)
http://madshi.net/madVRhdrMeasure164.zip

1) Removed some superfluous options.
2) Reworked the customization algo of the "54" lum method, now renamed to "54 v2". Should be somewhat similar to "max" now.
3) Replaced "max2" (which nobody seemed to use) with "max3 54", which is basically a 54 variant that looks quite similar to max3. You can reuse your preferred max3 values, for the "green/red/blue" options the "max3 54" needs the values to be multiplied by 10, though. So if you used 100/80/60 for max3, please use 1000/800/600 for "max3 54" to get similar results.

In theory the 54 variants should look relatively near to their max versions, but the 54 versions might be slightly better in some situations (?). Can you guys compare especially "max3" vs "max3 54" to see which you like better? As mentioned above, I'd suggest to share the same parameters, just multiple the RGB values with 10 for "max3 54".



http://madshi.net/madVRhdrMeasure163.zip (fix of the blue noise problem)
http://madshi.net/madVRhdrMeasure162.zip

This contains a tweak to the latest "roll-off" algorithm, based on James Freeman's earlier report that yellow is desaturated more than other hues. The desaturation is now scaled with the hue so that it looks roughly similar for each hue. I hope that this doesn't negatively impact the effectiveness of the algo?



http://madshi.net/madVRhdrMeasure161.zip (image quality tweaks to the new option)
http://madshi.net/madVRhdrMeasure160.zip

I've implemented Javs' requested "roll-off of clipped pixels", as an alternative to gamut roll-off. I've not tested it extensively yet, but it seems to do what it's supposed to do in Javs' Atomic Blonde frame, at the very least. It currently does increase rendering times a bit once more. Maybe I can optimize that a bit, for now this build only has the purpose to check if this feature is a keeper or not, from a visual quality point of view.

The "start" option defaults to 80. This is the start of the knee where desaturation starts being applied. If you set this to 0, all pixels are being desaturated. If you set this to 100, no pixels are desaturated. Set to 80, roughly the 20% most saturated pixels are desaturated (only if needed, of course) with a knee.

The "power" option defines the knee curve. If you set this to 10, then desaturation is applied in a simple line above the knee. If you set this to 20, a smooth curve is used, desaturating the most problematic pixels most, and pixels above the knee only very little. You can in theory go below 10, but I don't recommend it. You can go above 20, if you like the look.

Setting "start" and "power" both to 0 applies global desaturation in such a way that it (just) removes the clipping.

Please check if this new algo is A) useful and B) ever harmful in any scenes?



http://madshi.net/madVRhdrMeasure159.zip

Nothing changed, other than (hopefully) fixing the bug reported by kasper93, the files are code-signed again, and I've pushed the time limit back.



http://madshi.net/madVRhdrMeasure158b.zip

Only one change: The "highlight sat" dropdown box now has more options near 0.



http://madshi.net/madVRhdrMeasure157.zip

Changes:
- replaced "smart stim & mix" lum method with separate "use stim for darker pixels" options, which can be combined with any lum method

The basic idea of this new option is that we all like stim for how bright and punchy it is. However, what we like less is how much it desaturates highlights sometimes. So my idea was: Why not using stim only for darker pixels but use a different lum method for brighter pixels? So now you can use your preferred lum method for highlights, and use stim for darker pixels. Whether or not this is actually a good idea I don't know. Needs to be tested...



http://madshi.net/madVRhdrMeasure156.zip

Changes:
- added "smart max/stim mix" lum method

The new method basically uses "stim" for image areas which are below 100 nits, and uses "max" (100-70-40) for image areas that contain pixels above 100 nits. The max params and everything is currently hard coded. Big question is: Is this general idea usable? Since this new lum method adjusts to the local neighborhood of pixels, results could potentially be a bit funky. But on a quick check, it seems to work ok. If the general concept works ok in your tests, we could theoretically also use other mixes for below/above 100 nits.

Please note that the new method is optimized for real world images where different image sections might need different lum methods. So I'm not sure whether test patterns are well suited to test this new method. I suppose since it's a mix of 2 already existing lum methods, you could test those 2 with test patterns. But the new lum method is probably best tested with real world material (?).



http://madshi.net/madVRhdrMeasure155.zip

Changes:
- added two more parameters for max3 tuning

If you set both parameters to 100, you get the same as the old max3. If you want to increase the "luminance" aspect of max3, you can increase the first parameter above 100. I probably wouldn't go above 200 there, but I guess until 300 could be possible. At some point, though, the math will break. If you set the first parameter to 0, you actually get the same as "max". The 2nd parameter allows you to choose between different methods of how luminance is added to max3. A value of 100 gives you the max3 method of adding luminance. A value of 0 gives you a different method of adding luminance. And a value in between 0 and 100 blends between the 2 different ways.



http://madshi.net/madVRhdrMeasure154.zip

New feature: there's a new keyboard assignment in the settings called "take raw screenhot", which defaults to Ctrl+Alt+Shift+Print. If you press this key, madVR will create a folder named "RawScreenshots" on your desktop and store a raw lossless 4:2:0 screenshot of the current video frame in it. You can then seek to other frames in the same movie and take more raw screenshots. Once you stop playback in your media player, madVR will then start "ffmpeg.exe" to encode the raw screenshots into an MKV video file, with 1 second runtime for each screenshot. The MKV video file will not be 100% lossless, but it should be pretty near (very high bitrate), and it's the original 4:2:0 data coming from the decoder. Plus, the MKV file will also contain the full HDR metadata of the original video, as well. Also, madVR will add chapter markers, with the title text containing the original timestamp of the captured frame from the original movie.

So basically this new feature will make it extremely easy to create very small MKV files with problematic HDR frames in it, to help us all create and share good test samples.

You need to download ffmpeg, unzip it and copy it into the madVR folder, so that there's a file "madVR\ffmpeg\bin\ffmpeg.exe". Here's a direct ffmpeg Windows build download link:

https://www.gyan.dev/ffmpeg/builds/ffmpeg-release-essentials.zip

Note: it requires you using software decoding or copyback, it doesn't work with native hardware decoding.



http://madshi.net/madVRhdrMeasure153b.zip (fix x64 build)
http://madshi.net/madVRhdrMeasure153.zip

- fixed: luma repair processing step was skipped accidently
- added option to disable luma repair processing step



http://madshi.net/madVRhdrMeasure152.zip

1) Removed a couple of lum methods which didn't seem overly useful, anymore.
2) Added config options for 54. Seems to not do anything in pure color test patterns. Does have a (small) effect in some movie frames, though.
3) Added lum methods "dumb + hue correction" and "dumb", on Javs' request. These are not really "lum methods" per se, but it was easiest to add that functionality there.



http://madshi.net/madVRhdrMeasure151.zip (max3 reworked, it now tries to fix some of the max artifacts)
http://madshi.net/madVRhdrMeasure150.zip

1) Added customization options for "euc" lum method. The sum of the 3 options should not be above 100, but you can go below if you think it's useful. If you enter 33 for all 3 options, you should get the same as "euc" in previous builds.

2) Changed "custom sep" logic a bit. With the new logic, you have more control and the 3 options don't influence each other (or at least not as strongly as before). Good starting values are 60-30-8, which should be roughly identical to the default Sep, and also roughly identical to Neo-XP's previously preferred Custom Sep values. In this new build, the sum of the options should not go above 100, but you can go below if you think it's useful.



http://madshi.net/madVRhdrMeasure149.zip (changed the math slightly for YRGB processing)
http://madshi.net/madVRhdrMeasure148.zip

1) Added tweak options for "stim".
2) Added "use YRGB" option (instead of ICtCp).



http://madshi.net/madVRhdrMeasure147b.zip

Fixed bug in the "sep custom" math.
Now you can almost match "sep custom" to the old "sep", by using green 66, red 26, blue 8. You can tweak from there. Using 100 for all three is in some way similar to the original "max", but completely different at the same time.



http://madshi.net/madVRhdrMeasure147.zip

For "max", anything goes, but probably you should stay below 100, to avoid similar problems to Lum3/4 Old, when going above 100 for red.

"sep custom" is a new lum method which in theory is the same as sep, but it looks a bit different even with default values of 100, 100, 100. Not sure if it's better or worse with the default values compared to the original "sep"? You can tweak these values any way you like, both below and above 100 is fine. Though, I'd suggest to keep one value constant (e.g. green) and only change the other two, because internally, I sum the multiplications up and then divide through the sum of the factors. Meaning that e.g. 100,100,100 is the same as 50,50,50. The actual height of the 3 factors for "sep custom" doesn't matter, only the ratio between them. So I'd suggest to keep green at 100 and only modify red and blue, to change the ratio of red and blue compared to green. As mentioned, you can go above or below 100 for "sep custom".

Might make sense to optimize the three customizable lum methods (Lum3/4 Old, Max and Sep Custom) separately, to find the best config for each of them, and then compare the final results of all 3 to find the winner?

Sorry to give you yet more things to try... :eek:

P.S: My code signing certificate has run out, I'm in the process of renewing it. Which means the current files are not signed, which means your anti-virus might give you false positives. Please ignore those. They only occur because the files are not signed. Might take a couple of days to get that sorted out.



http://madshi.net/madVRhdrMeasure146.zip

1) Unchecking both "use custom TM curves" and "use predefined TM curves" in build 145 resulted in Venus curve being used. Now back to the original very steep curve.

2) Added "red" and "blue" modifiers to tune "lum3/4 old" further. The green modifier works for both "lum old" and "lum new". However, the new "red" and "blue" modifiers only work for "lum old". In my own quick tests, the "red" modifier doesn't seem to be very useful. But the blue one might just be. Recommended setting for the new "red" and "blue" modifiers are either 100 (same as build 145) or something smaller than 100. Going above 100 probably won't be helpful.



http://madshi.net/madVRhdrMeasure145.zip (fix the flickering issues introduced by 144)
http://madshi.net/madVRhdrMeasure144.zip

1) I've implemented a GPU RAM resource manager, to save GPU RAM (especially when using a lot of processing steps/algos, e.g. NGU). This could potentially introduce new bugs. I hope not. If you find any bugs, please let me know.
2) I've modified "lum3" into "lum3/4 old". There's a new edit box named "lum3/4 green". If you set this to "678", you get the same as the old lum3. If you set this to "500", you get the same as the old lum4. I'd suggest to try values in between 500 and 678. Going below 500 or above 678 probably doesn't make sense, but if you insist, you can try that, as well, of course.
3) I've modified "lum4" into "lum3/4 mod". This is a slightly modified lum3/4 method. The "lum3/4 green" option also affects this new option.

Hopefully this allows fine tuning lum3/4 more? I've thought about what else we could try, but not much came to mind. I've tried adding options to tweak Sep, but couldn't find anything useful to tweak there. So I guess that's it, you guys can experiment with "lum3/4 old" vs "lum3/4 new" now, and with the "lum3/4 green" option. Other than that, the other options are all still available.



http://madshi.net/madVRhdrMeasure143.zip

1) Hopefully the crash (introduced by 142) is fixed?
2) I added a number of new Lum methods. I hope there's something useful in there?
3) I've removed Jupiter, Venus and the blended curves.
4) There's another new curve named "Mercury". This curve is also a "steepness" related curve like Mars. However, while Mars keeps the steepness always the same, Mercury scales the steepness with the movie peak and with the dynamic tuning strength. Whether or not this is a good thing I'll leave to you. FWIW, Mercury may need some more fine tuning, I'm not sure. So might be too early to fully judge it yet.



http://madshi.net/madVRhdrMeasure142.zip

1) Added "tweak fire saturation" option. This options basically detects fire & explosion pixels, similar to how the older "color tweaks for fire & explosions" option works and maxes out saturation for such pixels. This avoids the problem of fire & explosion turning pale (even sort of pink). This comes on the cost of luminance/highlight detail. But I believe it makes fire & explosion look more natural. With this new option activated, I wonder if the older "color tweaks for fire & explosions" option is even needed, anymore? It might just do more harm than good now? The new option is also scientifically more accurate, because it just changes a saturation vs luminance priority setting (which is not scientifically incorrect, but sort of a matter of taste), while the old option intentionally screwed up hue. Please let me know what you think. Of course if the new option is too strong, we can tune/tweak it.

2) Added highlight recovery "strength" option. Default is 100%, which is identical to previous builds. You can reduce this now, if you think that the highlight recovery algo looks too artificial. Applying it in a reduced strength will hopefully (?) look better than not applying it at all. That said, I still plan to add a noise/grain filter in a future firmware build, so that highlight recovery doesn't bring out noise/grain more than it should. What do you guys think? Especially interested in feedback from people who didn't like highlight recovery so far. Do you still not like it? Even at e.g. 25% or so?

3) Added contrast recovery option "with dark scenes, as well". By default, contrast recovery (HSTM) activates only if the frame peak is higher than the display peak. But this new option allows you to always turn HSTM on. Doing this will in some way go against director's intent (or at least against what the disc asks for), so I don't recommend using this new option. But you're the boss of your home theater, of course.

4) Added new predefined TM curve "saturn". Please give it a try and let me know what you think. Recommend "punch" setting for this curve is around 10. Is it better or worse than mars or pluto?

5) Re-added the "clip Y" option. You can either clip to a specific nits value, or if you enter 0 nits, madVR will clip to the mastering monitor peak.

6) Added "limit HSTM" options. Previous builds were hard coded to limit HSTM, using default values "0 min" and "100 max". I wonder if we should limit at all, and if the default values are good. Please note that depending on the scene, sometimes only the min value has an effect, sometimes only the max value, sometimes both.

7) Added "HSTM: no brightening" and "HSTM: no darkening" options. Earlier builds had this hard coded to both options on. I had implemented this to help avoid flickering. But I think it's not good for image quality. I recommend unchecking "HSTM: no brightening". This should result in HSTM no longer making shadow detail worse (at least in many scenes where it did that before). I do recommend keeping the "no darkening" option activated, but you can try it both ways. Please note that you will likely get more flickering with these options unchecked. However, hopefully the "flicker protection" algo will help there?

8) Fixed the black pixel artifacts when using "flicker protection". Hopefully this algo now works properly and can be used to fully solve HSTM flickering?



http://madshi.net/madVRhdrMeasure141.zip (extend expiration)
http://madshi.net/madVRhdrMeasure140.zip

1) fixed one more crash issue.
2) added 2 blended curves for you to test.



http://madshi.net/madVRhdrMeasure139.zip

1) crash fixed
2) improvements to flicker risk estimation.
3) added option to increase sensivitiy of the flicker risk estimation.
4) improved several of the new tone mapping curves (both in stability and quality).



http://madshi.net/madVRhdrMeasure138.zip

1) Improved Venus for 10.000 nits scenes.
2) Fixed and improved "flicker protection" algo.
3) Improved flicker risk calculation.

Hopefully the new and improved flicker protection algo will get rid of any HSTM flickering and thus allow you to use (much) higher HSTM strength? That could potentially allow using "flatter" tone mapping curves, combined with stronger HSTM settings.



http://madshi.net/madVRhdrMeasure137.zip

We have a BLIND TEST now in this build. There are 4 predefined custom TM curves for you to choose from. One is the good old "same steepness" curves variant. One is from Fer15 and 2 variants from QuietVoid. Now I just hope I converted Fer15's and QuietVoid's curves correctly! FWIW, two of these curves automatically scale with the peak luminance of your display. The other two don't. In any case, please compare and let me know:

1) Which curve do you like best, which is worst and which curves are in the middle?
2) Which "punch" setting do you prefer?
3) Which is your TV (projector vs flat panel, and peak luminance ability)?

Looking forward to your votes!!

I recommend comparing the curves with "brightness equalization" activated most of the time. But you can of course also double check with it disabled.

I've also re-introduced a "flicker protection" algo. I had this in a rather old test build once, at the time when HSTM was introduced. But at some point we thought we no longer needed it, so I had removed it. But it seems people have flicker once more, especially when using rather strong HSTM settings. So this algo comes back now. I expect that it might produce some artifacts in some situations. If so, please let me know. Would be great if you could provide samples for such artifact issues. (This algo may also help fixing flickering issues with shadow recovery, btw).



http://madshi.net/madVRhdrMeasure136.zip

1) fixed GPU RAM leak
2) fixed some keyboard shortcuts still didn't work



http://madshi.net/madVRhdrMeasure135.zip

1) fixed: source color keyboard shortcuts didn't work
2) fixed: "don't measure" produced black screen
3) fixed: one GPU memory leak



http://madshi.net/madVRhdrMeasure134.zip

1) fixed: inverted shadow detail when using HDR output
2) turning HDR off should now happen immediately, not when the media player closes
3) added support for custom curves & contrast recovery & shadow recovery for "dumb" tone mapping
4) added even stronger steepnes options



http://madshi.net/madVRhdrMeasure133.zip

1) fix the DVD crash
2) add an option to enable/disable brightness equalization



http://madshi.net/madVRhdrMeasure132.zip (another fix for the 2 line curves)
http://madshi.net/madVRhdrMeasure131.zip

1) Fixed two bugs in the "2 lines" curve creation.
2) Fixed a potential crash problem in madVR rendering.



http://madshi.net/madVRhdrMeasure130.zip

This time I cleaned up the Contrast Recovery (HSTM) options a bit. I've removed the Hill and Hill/Log blend options and instead now added a lot of new Log strengths. The Hill and Log options were very similar, so I had to get rid of one of them. I picked Log because I had an Excel spreadsheet to easily calculate new strength levels for that.

I've also added the "HSTM: protect bottom" option back in, just for testing purposes. I assume it will probably still not be useful. But just in case, you can try it.



http://madshi.net/madVRhdrMeasure129.zip

1) I've removed the clipping to MDL.
2) Overall brightness is now normalized, so all TM curves (including the legacy one) should produce roughly the same brightness.



http://madshi.net/madVRhdrMeasure128.zip (bug fixes)
http://madshi.net/madVRhdrMeasure127.zip

1) Removed HSTM protections.
2) Added "same steepness curves" option, which basically is a formula based version of Neo-XP's custom steepness curves. The formula based version should produce slightly better quality and may potentially avoid some problems/artifacts? Plus, it allows you to quickly compare different steepness values. Plus, it should auto-adapt to all DPLs. Please make sure you have unchecked "custom curves" to use the "same steepness curves" option. If you have both options enabled, the custom curves "win".
3) The curve editor has a new curve type called "2 lines". This curve type is actually very simple: It consists of 2 simple straight lines, with a smooth curve in between them. This new curve type allows to use brighter mid tones without losing highlight detail. But this may make subjective image contrast worse. So I'm not sure if this new curve type is useful. I'll let you be the judge. You can also "blend" this new curve type with the "same steepness curves" BT.2390 based curve, to create a hybrid between the "2 lines" curve type and the "BT.2390" curve type.

I think the new "2 lines" curve type is probably the last addition to the custom TM curve topic. After we've evaluated if it's helpful or not, I'd soon like to "move on", and start revisiting the not-yet-finalized options such as "lum method", "highlight sat", "desaturation" and others. But let's complete the custom TM topic first. I'm really curious to hear if the "2 lines" curve type is helpful in any way or not?



http://madshi.net/madVRhdrMeasure126.zip

The good news is that I've found a way to allow even less steepness for the curves. Meaning, if you enter a 0 steepness, the resulting steepness value will be noticeably lower now compared to what it was before. This means that potentially there's still room left for improvement in the curve design. The bad news is that this means we're not done yet working on the curves, my apologies. So could you guys please double check if using a lower steepness value (potentially combined with a higher knee, or no custom knee at all) might look better overall?

I think that using a 0 steepness for all curves is probably too dark now, so instead of simply entering 0 everywhere, you may have to manually find a good steepness value. But I hope that on the flip side, you can probably uncheck the custom knee in all curves. So if you do that, it's still only 1 parameter you need to optimize for each curve. Only this time it's the steepness and not the knee.

FWIW, I think the x1 curves are the most important ones. If you find consistent steepness and knee values that you like for the x1 curves, I can probably interpolate your preferences for the x2, x4, x8 and x16 curves. Or at least I hope so. @Neo-XP, e.g. instead of a 0 knee and 10000 steepness for 10000x1, try using no custom knee and a steepness of e.g. 600. Does that look better or worse overall?

(The new build also fixes the clipping to MDL.)



http://madshi.net/madVRhdrMeasure125.zip

The main change is that I've reworked the HSTM Top Protection algo, and I've added 2 more options to allow you to fine tune it. Good samples to test with are Neo-XP's "hstm test 3.mkv" (which improves with HSTM Top Protection) and the red faced lady in The Greatest Showman (which gets a lot worse with HSTM Top Protection, IMHO).



http://madshi.net/madVRhdrMeasure124.zip

1) madVR now always clips at the mastering monitor peak brightness (usually 1000nits, 1100nits or 4000nits).
2) fixed: near black frames turning white.
3) fixed: "importing curves failed" problem.
4) added "alternative histogram" option, which (I think) helps HSTM look better, and may help with bright skies.
5) added HSTM "protect bottom" option.
6) added HSTM "protect top" option.

I'm hoping we can tweak HSTM to make it look good together with the custom curves, so that nobody feels the need to disable it, anymore.

Flickering is not solved yet, though, will have to work on that soon(ish). For now I guess we should mostly look at still frames with the latest test builds.

Please test if the "protect bottom" and "protect top" options are useful - and necessary. I think I like the "protect bottom" option. Not sure what to set it to, though. Probably a low value like 10nits or 20nits should be sufficient to avoid a loss of shadow detail? I'm not sure about the "protect top" option. It sometimes helps slightly, and sometimes hurts slightly. I might just prefer it off, but let me know what you guys think.

The alternative histogram option IMHO improves the look of HSTM, but it does have the tendency to produce a lower FALL value, which makes the FALL algo render the frame more brightly. So you will probably have to adjust the dynamic tuning value to adjust. As an example of where the alternative histogram option helps: Check out the cow scene from the UHD Benchmark video. The white heads of the cows used to suffer when enabling HSTM. That no longer seems to happen when using the alternative histogram option.



http://madshi.net/madVRhdrMeasure123.zip

This was a HUGE amount of work. The key problem is that of course we want the curve to be optimal for scenes with high peak nits and low peak nits, with high FALL and low FALL. So how can we possibly handle that with custom curves? Well, I've solved it like this:

A) You can create custom curves for: 110, 509, 2230 and 10000 frame peak nits. These are 4 different curves. And madVR will seamlessly interpolate between them, depending on the measured peak of each video frame.

B) You can create custom curves for 1x, 2x, 4x, 8x and 16x dynamic tone mapping compression. These are 5 different curves. E.g. if your real display nits is 100nits and madVR's dynamic target nits (FALL algo) wants to render the current frame with a 200nits target, then you have a 2x factor, so the 2x curve is used. If the factor is 1.5x, madVR will interpolate the 1x and 2x curves.

Sadly, we want A) and B) to work at the same time, so there are actually 4 * 5 curves you can define. OUCH. I'm sorry about that, but I couldn't think of any other way to make everything work the way we're used to, but still allow fully custom tone mapping curves.

By default, if you just enter the custom curve editor and save the settings without changing anything, the image you get should be roughly the same as without the custom curves. Meaning, the custom curves default to what madVR does right now. But you now have full flexibility over the curves.

Editing curves is possible in various ways:

1) You can change the brightness compression factor.
2) You can change the knee (compression starting point) - but only as far as BT.2390 can handle.
3) You can change the curve steepness - but only as far as BT.2390 can handle.
4) You can apply a contrast modifier (positive or negative) to either the top or bottom of the curve.
5) If all of the above isn't enough yet, you can manually move every of the 21 curve points for each curve up and down to design a fully custom curve.

Please note that the curves you create are made for your real display peak nits. Your curves might not work for another user who has a different display peak nits. Maybe we can find a way to unify this somehow, but I'm not sure it's possible because a user with a 50nits projector will probably want to use different custom curves than a user with an 800nits LED or OLED.

Please also note that this is an experimental build and not necessarily meant for actual movie watching (although you can try). One thing not clearly defined yet is how madVR switches from simply clipping (if the movie peak is below your real display peak nits) to the custom curves. I assume it works well enough as long as you stick with the default curves. But I might need to add special handling in case you do strong changes (e.g. already doing 2:1 compression even if almost no tone mapping is needed).



http://madshi.net/madVRhdrMeasure122.zip

1) Fixed: Black bar measurements were shown for last frame in the queue, not for currently visible frame.

2) Added "FALL highlight mod" algo. This algo might replace the sky detection? I'm not sure. It does result in the image getting generally a bit brighter. So when using this, you will have to adjust your DTN (dynaming tuning) value accordingly. But hopefully it should make scenes with bright skies brighter than other scenes, and generally make brightness overall more "stable" between different scenes. Please let me know if this works for you or not?

3) Added "FALL detail threshold" algo. This is a different approach, but with the same goal as 2). This one actually considers "detailed" pixels as being more important than "flat" pixels, and the histogram and FALL calculation is changed accordingly. So flat skies won't make the image as dark as they currently do. Please note that this approach currently modifies the look of the histogram graphs and will also affect HSTM (Contrast Recovery). So I would atm recommend to test this algo with HSTM disabled. It is possible for me to avoid the mentioned side effects, but I didn't have the time to do that yet. So let's first check if this algo is of any use. If it is, then I can make it not affect HSTM.

Looking forward to your feedback! 😀

P.S: Next up is custom tone mapping curves, which I hope to release later this week. It's quite a bit of work, though. So it might rather be the end of the week than the middle.



http://madshi.net/madVRhdrMeasure121.zip

The only change is that the OSD now shows 2 new values: Namely a measurement of the darkest pixel in the top region of the movie (which is a black bar for scope movies), and a measurement of the darkest pixel in the center region of the movie. You need to create an empty file or folder called "ShowHdrMode" in the madVR folder to get the new measurements in the OSD.

This should help testing how many movies have raised black levels. And how many of them have raised black levels only in the center section or also in the black bars.

Caution: Difficult thing is that studio intros might be different to the actual movie.



http://madshi.net/madVRhdrMeasure120.zip

1) Fixed the madVR test pattern hue shift with clipping disabled.
2) Clipping now results in measurements also being clipped -> brighter image.
3) Added max2, max3 and max4 lum methods.

The new max methods avoid some of the artifacts (only the blue-ish ones) to some extent, but buy this by generally brightening up blue stuff quite noticeably. I'm not sure if that's a good trade-off. It looks good in many scenes. But it looks bad e.g. in the Pan flying ship scene and in Samsung Wonderland Two runtime 2:05.

Thoughts?

Has anyone tried the "desat reduction per source nits" yet? Is it useful? The purpose is to achieve nice skin tone desaturation, while maybe desaturating bright HDR CGI shots less.



http://madshi.net/madVRhdrMeasure119.zip

1) I'm now using a repair space of 100, and the repair range is chosen depending on desaturation strength. The higher the desat strength, the less repair range I use. With no desat, I repair with 0.020. With 175 desat I use 0.010. In between it's interpolated.
2) Added an option to use dumb desat instead of desat 4 in the "mixture", because Neo-XP thought that dumb desat might be superior to desat 4. I've normalized the skin tone desat level at strength 100. But I've already noticed that at different strengths, desat 4 and dumb desat don't have the same strength. Please keep that in mind when comparing.
3) Added an option to clip the source to a specific nits level. FYI, the "hue shift TM instead of clip" option is currently not working yet.
4) Added the option to limit the amount of desaturation for various source nits ranges. This might allow reducing desaturation strength for CGI shots, while still keeping full desat strength for skin tones. No idea if this will be useful.



http://madshi.net/madVRhdrMeasure118.zip

This time there are 2 new options called "repair space" and "repair range", which allow you to fine tune a processing step which madVR has been doing for a long time and which is supposed to reduce artifacts in various scenes. I think this repair step needs some fine tuning. Please double check this with:

1) Dumbledore fight image (from HP5).
2) Voldemort beam (from HP5).
3) Castle/Lake from Samsung Wonderland Two, Runtime 1:30.
4) City from Samsung Wonderland Two, Runtime 2:05.
5) Pan scene 2 (I think), where Captain Hook is flying and there are clouds.
6) Batman vs Superman green spear.
7) Mad Max, the two colored clouds (see attachment).
8) Mad Max, car explosion.

The 2 new options have a potentially big effect on all those scenes above. There will probably not be a setting which works best for each scene, so a good compromise is what we need. Here are some thoughts:

We want a big repair space to help 2).
We want a small repair space to help 7).
We want a big repair range to help 1).
We want a small repair range to help 7).

So what's the best compromise?

P.S: Please don't use "max" or "54" when testing this, because the repair doesn't seem to work very well for these.



http://madshi.net/madVRhdrMeasure117.zip

1) Removed dumb desat.
2) Added more/finer "Highlight Desat" options. And renamed it to "Highlight Sat", because higher values mean higher saturation.
3) You can now choose the desat 2-4 mixture. A mixture of 0 is exactly desat 2. A mixture of 50 is exactly desat 3. And a mixture of 100 is exactly desat 4. So e.g. a mixture of 75 is exactly in the middle between desat 3 and desat 4. This should hopefully simplify testing different mixtures of desat 2-4.
4) There's only one desat strength setting now, with 100 = normal strength.
5) Added a new "avgHighlight ceiling" option, where you can choose factors in between 1.5x and 4.0x.

Would be great if we could narrow down on the "highlight (de)sat" and "desat mixture" options. Would like to pick a specific value for both soon and then get rid of the options, with only a "desat strength" option to remain.

P.S: FYI, I've designed the desat strength in such a way that with a strength of 100, the lady in The Greatest Showman should have roughly the same skin tone, regardless of which desat mixture you use.



http://madshi.net/madVRhdrMeasure116.zip

1) Based on your test results I've decided to drop "desat y, y', r and r'", and stick to "desat i", which seems to be the most reliable desat method to avoid problems like pinkish reds etc.
2) I've added a "don't allow dumb desat to increase saturation" option, which may help with Atomic Blonde. Hopefully with no negative side effects?
3) I've added "desat 3" and "desat 4" options, which work somewhat similar to "desat 2", but are more selective in which hues are desaturated. Basically "desat 2" desaturates all hues more or less similarly. "desat 4" works somewhat similar to dumb desat in that it leaves very pure hues alone while still desaturating mixed colors. And "desat 3" is somwhere in between "desat 2" and "desat 4". Actually, I'm thinking that maybe, if we're lucky, one of these can replace dumb desat?
4) I've added a "power"/strength option for the desat 2-4 options.
5) Dumb desat can now be adjusted in 10% steps.



http://madshi.net/madVRhdrMeasure115.zip

Sadly, after trying a lot of different ideas, I've not found a well working replacement for dumb desaturation. I did find some which worked well for skin tones, but then that algo destroyed ultra bright scenes like Mad Max explosions, desaturating them nearly completely. So for now I'm officially giving up on trying to replace dumb desaturation and I'm willing to "embrace" it (as an option).

The most important change in this build is a special "split screen" mode which allows you to compare saturation at 2 different brightness levels on one display. The left side shows the image normally. The right side simulates a darker display. So the right side actually is much darker. So if you test this on a flat panel display, the right side sort of simulates a projector, so to say. Here's how to use the split screen functionality:

ideally test this on a very bright display which is perfectly calibrated using a 3DLUT
enter the true measured "display peak luminance" value, as usual
activate "split screen desat test"
pick any split screen target nits value you like, you can go as low as 20 nits
check if the saturation levels match, subjectively
how much (if any) dumb desat do you have to add to achieve a subjective saturation match?

A few more changes:

1) Hopefully fixed some of the crash issues of the previous build (?).
2) Removed all the useless "lum method" and "desat method" options.
3) Added a couple new "lum method" options. Maybe you like them?
4) Added a "don't add peak nits" option, requested by Neo-XP.

The "don't add peak nits" changes the way the DTM calculates how bright to render each scene. If you activate this option, things may get slightly brighter. You may want to increase your "dynamic target nits" option a bit to counter this effect.

2 key questions for you guys to test and answer:

A) Do you think dumb saturation is needed to achieve a saturation match when comparing a bright image with a much darker image, using the split screen? If so, how much dumb desat do you think is needed? This may vary depending on the "split screen nits target", though I hope not.
B) Can you please check if "apply desat 2" is useful at all? I think if you do activate some amount of dumb desat, then probably "apply desat 2" does not help much? At least in the Mad Max explosion, disabling "apply desat 2" looks better to my eyes. So I hope that we can get rid of "apply desat 2"? If you do want more desat, I think adding some amount of dumb desaturation might achieve a better compromise?

On a side note, here's a little comparison screenshot from a different DTM product vs madVR/Envy.

madVR - LG Colors of Journey
other - LG Colors of Journey

Some people earlier claimed that Envy would have oversaturated skin tones, compared to that other product. But in my quick test that does not seem to be the case - provided you properly brightness match both products (!). Actually, madVR seems to desaturate more than the other product, even with only "desat i 1". That applies to the lady from The Greatest Showman, as well. Unless I messed up the test somehow?



http://madshi.net/madVRhdrMeasure114_hotfix1.zip  (crash fix)
http://madshi.net/madVRhdrMeasure114.zip

A couple notes:

1) I've done a lot of changes to the madVR source code in the last few months, because some of the source code is shared with Envy. So there's a high probability that I introduced some new bugs. Sorry about that. Let me know, and I'll try to fix them.
2) I'm posting this for you to play with, but I'm still completely booked for at least the next week, maybe a bit longer, so I might not be able to follow-up until after that.
3) There's a new "license.pdf". The new license shouldn't make much of a difference for end users. But a key thing is that we wanted to clarify that we do NOT like the idea of commercial companies using madVR (without our approval) to earn money. We do have agreements with J.River, ZoomPlayer and a couple others. But we don't want especially commercial HTPC builders to use madVR to build products which compete with Envy. Which should be obvious to anyone. The new license.pdf is very clear on this. The old one didn't allow commercial use of madVR, either, but the new one is just even more clear about it.
4) This new build is time limited. It will start to complain nicely (a 10 second OSD message) at February 1st, 2021, and will stop working at March 1st, 2021. This is another measure to stop commercial HTPC builds to use madVR against our will. Of course I promise to create new test builds way before that. So again, should not be a big issue for you guys (I hope).
5) The new build has tons of saturation related options for you to play with. If I may ask, please everyone test whatever material you like, but do include the green spear scene and the Mad Max explosion scene. These 2 scenes alone will help you rule a lot of the new options as being "trash". This will reduce your testing time, because you can then concentrate on those options which pass the green spear and Mad Max stress tests.
6) In terms of saturation, there are 3 different options here: A) The "desat method" has a few different methods you can play with. Dolby & Co recommend "desat i 1". That is IMHO the scientifically correct way to handle saturation. I assume you'll still find it too saturated for problematic movies, though. B) The "dumb desat" option allows you to approach "Compromise On" saturation levels in multiple steps. Personally, I think it's a very bad idea to use, but anyway. C) "highlight desat": This is just for very bright pixels, e.g. green spear and Mad Max explosions. Don't go too high here, or else the green spear will become a flat blob.
7) The previous builds used "lum method: sep" and "use no dumb saturation". "Desat 1" in the previous builds was similar to "desat i 2", while "Desat 1+2" was similar to "desat i 1+2". So actually the most scientifically accurate option "desat i 1" wasn't even available in the previous builds... ;-O

Generally, please understand that what we should all aim for is to follow director's intent, don't we? Meaning: We want madVR's tone mapping to approximate what a true 10,000 nits projector would display, no? So if a true 10,000 nits projector shows overcooked faces with some badly encoded movies, then should madVR not do the same? So let's please be careful not to judge madVR saturation levels by what looks "natural" to your eyes. Instead we need to find ways to judge if what madVR does properly approximates what a 10,000 nits display would show or not. Because that's the true reference. Hopefully we all agree on that?



http://madshi.net/madVRhdrMeasure113.zip

It's been a while, and I've made some changes for Envy in the meanwhile, so hopefully nothing got broken. Important changes in this build:

1) Removed the countless HSTM curve options. Instead there's now only one drop down control with a number of preconfigured curves.
2) Dynamic shadow boost feature is now evaluated after HSTM, not before.
3) Scene change detection metric logic modified slightly, according to Neo-XP's request.
4) Improved rendering speed when there are a lot of rendering steps (should be especially helpful for NGU). Please note that the measured average rendering times in the OSD will not change. However, you should now be able to get nearer to the theoretically max possible rendering times without getting frame drops. This change could potentially introduce new bugs. Hopefully not, but we'll have to wait and see...

Important to test in this build are the 3 curves "Hill Strong" vs "Log Strong" vs "Hill/Log Strong blend". All 3 should have a roughly similar look and strength, but should differ slightly, with the Hill/Log blend being right in the middle between Hill Strong and Log Strong. Which of these 3 do you guys prefer? Obviously these are pretty strong curves. They might be too strong for some (many?) users. So please don't simply pick the one which feels least strong to you. Instead pick the one which looks "best" to you, if you know what I mean.
@Neo-XP, could you please double check that the shadow boost and scene change detection changes (see 2) and 3) in the list above) are working as expected? And of course it'd be great to get newly optimized values for the scene change options. Probably the current defaults aren't optimal yet (?).



http://madshi.net/madVRhdrMeasure112.zip

1) This build allows finer steps in the low region of the HSTM curve.
2) Important: Please multiply all HSTM curve parameters with a factor of 10 in this build. This gives us more rounding precision.

L80: 800-860-920-980-1100-1220-1400-1700-2000-2300-2600-2900-3200-3800-4400-5000



http://madshi.net/madVRhdrMeasure111.zip

Only changes are a fix for the "Mirror" related problems reported by Neo-XP and chros73. Can you guys double check if the problems are fixed?



http://madshi.net/madVRhdrMeasure110.zip

1) Fixed small bug with the "no compression limit" option.
2) Slightly improved quality of the dynamic shadow boost option.



http://madshi.net/madVRhdrMeasure109.zip

1) Removed anti-flicker.
2) HSTM strength can now be defined for each of the 3 lines.
3) There's a separate toggle now to enable/disable HSTM, so you don't have to zero the strength to disable HSTM.
4) Re-added "min compression limit", as requested by Soulnight, for people with very low brightness projectors.



http://madshi.net/madVRhdrMeasure108.zip

1) Several options are now forcefully reset to optimized default values (e.g. brightness reaction speeds, thresholds etc).
2) Removed some superfluous options and hard coded them to the preferred value instead (e.g. "match FALL in PQ", which everybody had activated, anyway).
3) Made the settings window a lot wider (temporarily!!) so we can see all HDR related options once more.
4) Fixed HSTM to properly support compression values. So you can now use values below 100 again without having to fear that HSTM would turn itself off, or would cause flickering.
5) Desaturate 1 works correctly again (and is enforced as new default).
6) Added a dynamic shadow boost option, which lets you fine tune shadow boost to only be applied for scenes which need it (!!).

Questions:
1) Do we still need the "disable avgHighlights ceiling" option? It seems most people have this checked/activated now? So I can forcefully enable it and remove the option?
2) Is it safe to remove the "anti-flicker" option and hard code it to 0? Or is it too early for that?

HSTM tuning:
Since a couple of users insist that starting at 100 doesn't look good, maybe it's worth a try using the new S, Hill and other curve types with a starting point of 75 or 80?



http://madshi.net/madVRhdrMeasure107.zip

1) Fixed a problem which caused flickering when using anti-flicker 0. So please try again to use anti-flicker 0 with build 107. Maybe it works fine now?
2) Sped up HSTM processing a bit. More speed ups to come in the future, but not in the next 2 weeks.



http://madshi.net/madVRhdrMeasure106.zip

1) I think the flickering issues introduced by 105 should be fixed.
2) Saturation is back to the sane (non-overcooked) levels we had before HSTM. But the "don't desaturate" etc options are still available. At this point I don't recommend using "don't desaturate", anymore. E.g. check the green spear scene with BT.709 output using "don't desaturate". Large parts of the spear turn into a green blob. So it's clearly a bad setting. My personal recommendation is to use "desaturate 1" for now. It's a fairly low level of desaturation. I still plan to revisit saturation with additional test builds once HSTM is done. For now please concentrate on finalizing HSTM settings. Thank you! :)
3) I still have the options for "match FALL in PQ" and "anti-flicker" available. Recommended setting for now is "match FALL in PQ" activated and "anti-flicker" set to 0. Please run with these settings, unless you find flickering problems. In that case please try using "anti-flicker" and let me know about it.

So main priority for now is finding the best possible HSTM numbers!



http://madshi.net/madVRhdrMeasure105.zip

1) I've added a "match FALL in PQ" option, which seems to be better at matching FALL correctly. Meaning, if you use strong HSTM settings with high strength, without "match FALL in PQ" the image may become a bit or even a lot brighter. But with "match FALL in PQ" it should stay roughly identical in brightness. Which is how HSTM is supposed to work. Can you confirm that "match FALL in PQ" is working well and that we should use it?
2) I think I've fixed all the HSTM artifacts I got samples for. Please double check.

Due to the artifact fixes, it might make sense to double check the anti-flicker duration once again, just to be safe. Do we still need 1000ms? Maybe we need less now, or even more?

Also, although I don't expect that the "match FALL in PQ" option will change "good" HSTM parameters much, it might still make sense to double check that, as well.



http://madshi.net/madVRhdrMeasure104.zip

found a few bugs in the HSTM algo (ooops).

This time hopefully dark scenes should not be brightened more than the encoding asks for (which previous could happen in specific circumstances). HSTM is really only supposed to improve contrast / detail, but it shouldn't make the overall image brighter or darker.

Also, I've found that HSTM still sometimes did more than it should do if the movie peak was near to the real display nits. This could potentially result in visible flickering or pumping artifacts. So if you had those sort of problems, maybe it's improved/fixed now?

After these fixes, in theory flickering could become a problem again, but I sure hope not. Please double check, just to be safe.

The fixes do modify the way HSTM looks to some extent. The HSTM parameters you're using now might still look good. Or maybe they need some fine tuning now?



http://madshi.net/madVRhdrMeasure103.zip

Only one small change: After a scene change, HSTM adjusts slower, to avoid flickering.
@Manni01, with a bit of luck, does that fix the flickering you're seeing on your 4K monitor?



http://madshi.net/madVRhdrMeasure102.zip

1) You can now store 3 different HSTM curve parameters and quickly switch between them. That should make testing different curves much easier.
2) I've modified the way the FALL is adjusted once more (different than previous "offset" and "curve").
3) I've added the option to smooth HSTM (in time axis). This should take care of flickering. Please check how many milliseconds smoothing we need to get fully rid of all flickering problems. The ideal value should be the lowest number which doesn't flicker.

I hope that the flicker smoothing also doesn't make quick dynamic adjustments within a scene worse (e.g. a scene suddenly becoming much darker or brighter)? Please double check that, just to be safe. Thanks!



http://madshi.net/madVRhdrMeasure101.zip

Only change is a new option called "correct histogram width". This was suggested by Soulnight. It might make HSTM ever so slightly more accurate, from a scientific point of view. But the question is if this option ultimately improves the image quality or not? It does seem to make shadow detail slightly better but it also decreases pop/contrast a little bit. Thoughts?

Ideally I'd like to decide on this new option pretty quickly and then remove it again. So it would be great if you could double check, let me know your vote (use/don't use), so we can continue fine tuning the HSTM curve parameters. Thanks!



http://madshi.net/madVRhdrMeasure100.zip

1) HSTM options are completely reworked. Hopefully default options work fine (?). FWIW, strength has a default of 50 now.
2) Saturation for dynamic tone mapping was reworked. It should now lose a lot less saturation in some situations (but not all). There should finally be no difference in saturation between HSTM on vs off. Please stay with "don't desaturate" for now. The current desaturation options don't work too well.

Notes for people who want to fine tune the new HSTM parameters:

a) One good way to modify the behaviour is to change the value of the 0.00x edit box. E.g. try setting it to 25 instead of 50. Looks great in some scenes, looks bad in others, so I've set it to 50.
b) Another thing worth trying is to use 50/50/100/100/... (or even 50/50/50/100/...) instead of 50/100/100/100/... Again it will look good in some scenes, bad in others.
c) Another thing you can do is vary the position where 100 goes to 200 at the top of the HSTM curve.
d) Good content to fine tune with are the following scenes:

- UHD HDR Benchmark: 0:00:12: grass and trees should not be flat, mountains should have nice contrast
- UHD HDR Benchmark: 0:00:35: horses shouldn't become too bright and flat
- UHD HDR Benchmark: 0:01:20: trees on the right middle shouldn't be darkened too much, but overall contrast should be improved
- UHD HDR Benchmark: 0:04:40: shadow detail should hopefully be improved slightly (compared to HSTM off), the more the better
- UHD HDR Benchmark: 0:05:55: white heads of the cows should not lose too much depth/detail
- Black Hawk Down Helicopter scene should have improved shadow detail (compared to HSTM off), the more the better

Default settings look like a decent compromise for these scenes. Except for 0:04:40, not happy with that scene. Maybe you can find an improvement somehow?



http://madshi.net/madVRhdrMeasure99.zip

1) I've modified the desaturation option. You now now choose to apply no desaturation at all, and I'd kindly ask you to use this option for testing (but not for actual playback, I think). This way hopefully you'll be able to judge different HSTM settings better without being influenced by different saturation levels. Well, at least I hope so... :p

2) Because I thought we didn't have enough options yet, I've added a couple more... :eek::(

3) The "start at nits" option is now split into "don't compress below" and "calculate FALL above", which are both in nits. Would be interesting to check which of these is the one which you think helps quality. I anticipate that it might be the "calculate FALL above" option, which would mean that it basically only influences madVR's decisions on how to bright make the final image (and nothing else).

4) Shadow boost has 2 even stronger settings now (Neo-XP asked for it for testing purposes).

5) There are two more options which let you choose two different areas of behaviour for HSTM. These two options let you go back (to some extent) to the way build 96 worked, just to double check if that looks better or worse than 97. And also to double check if the "blow out" problems with the original 96 build still exists or maybe it was fixed by some of the other improvements I made. Soulnight asked for these options.



http://madshi.net/madVRhdrMeasure98.zip (bug fixes)
http://madshi.net/madVRhdrMeasure97.zip

- I've made a pretty massive improvement for HSTM in this build. I'm having trouble now finding any scenes where I find HSTM to look worse. Sometimes it looks "different", not necessarily better. But usually it does look better. It feels like some sort of clever contrast enhancer now, without costing shadow detail. And it actually often improves shadow detail at the same time.
- reset to default values, if you don't remember them.
- black flat area detection was removed in this build.


http://madshi.net/madVRhdrMeasure96.zip

- added (yet) an(other) option for the desaturation change I had implemented in the last couple of test builds



http://madshi.net/madVRhdrMeasure95.zip

- added histogram shaped tone mapping (HSTM):

I've "overwritten" the scene detection etc options for this test build, because there simply wasn't enough space for all the new options. Of course this is only for the next couple of test build.

Here's an explanation of what the new options do:

1) min / max sky hill height: The min sky hill defines by which factor a potential sky hill must be higher than the average histogram height to qualify as a valid sky hill. Default is 15, which is a factor of 1.5x. The max sky hill height defines how high a potential sky hill must be to be fully cleared. If you set this high, "little" hills won't be modified much, but "high" hills will be modified fully. The default factor of 30 (= 3.0x) means that 100% of the sky hill is removed only if the sky hill is 3.0x higher (or more) than the histogram average. If the hill is below the min sky hill height, it won't be touched at all. If it's somewhere in between the min and max height, the sky hill will be removed partially.

2) I've modified the limiter once more, but only a little bit, to go along better with the min/max sky hill options.

3) Of course you can disable sky detection by using a sky strength value of 0.

4) Histogram shaped tone mapping can be disabled by using a strength of 0. A strength of 100 is "normal" full strength. But you can also go higher. You can use 50 or 200 or 400 or anything, really.

5) "Start at nits" protects the first x nits from being compressed more by histogram shaped TM. Not sure if this is a beneficial setting or not. Defaults to 0 (disabled) atm.

6) initial power and final power are power (gamma) sort of values. The default values of 20 means "value ^ 2.0". Explaining the purpose of these options is difficult. In a simplified explanation, I'd say it defines how much the amplitude of the histogram shape is modified.

7) Clipping point defines where to clip very high histogram columns. The default value of 40 means each histogram column is clipped at 4.0x of the histogram average.

8) The two smoothing options define how much the histogram or tone mapping curve are smoothed. Smoothing the histogram helps keeping things more stable, but smoothing it too much will at some point turn it into a flat line.

Generally, the histogram shaped TM looks interesting, but I'm not always happy with what it does. The image I dislike the most is the frog on black background in the UHD HDR Benchmark. Histogram shaped TM makes this clearly worse, IMHO. However, in many other scenes, histogram shaped TM can be beneficial. Maybe we can find a way to detect and fix the problems this algo might cause with certain scenes somehow?

Important note: The histogram shaped TM is currently not smoothed in the time domain. Which means if you use this feature for playback, there could potentially be some flickering or similar artifacts. Please disregard this for now. Of course I can smooth this later, for now the key question is whether this is an algo we want to use at all, or not. AND if this algo (if we use it) can replace sky detection, or if both should be used at the same time.



http://madshi.net/madVRhdrMeasure94.zip

1) Sky detection never makes the image darker now. (But dark flat area detection still may.)
2) Sky detection tries all potential "hills" now and picks the one which has the biggest (positive) impact.
3) Modified the limiter. It should now do less harm in average scenes, but helps quite a bit with some The Meg scenes.



http://madshi.net/madVRhdrMeasure93.zip

1) There's no separate option to enable/disable sky detection now. But a strength of 0 effectively disables it, and a strength of 100 means it's fully enabled. Of course you can also pick any strength in between. But ideally, we should aim for using 100 strength, and instead improve the way the algo works, instead of dialing down the strength, IMHO (if possible).

2) The "sky width" defines how many different brightness steps in the histogram may be considered to be "sky" at a maximum. Default is 20. Choosing a lower number will reduce the strength of the algo, choosing a higher number will increase the strength. But it depends on the scene. In some scenes changing this won't do much (or anything). Or in some scenes there'll only be a change once you hit a specific threshold. So you'll need to find the optimal sky width by checking as many different movie scenes as possible. (Sorry, this will be time consuming, I guess.)

3) The option "limit sky to avg" changes the way the detected sky is treated. Having this option disabled is what Soulnight's original algo does. Having it enabled should make the algorithm have slightly less strength, but it depends on the situation. I'm not sure if this option has any positive effect? If it just generally decreases the sky strength a little bit (the same way for each movie scene), then we can trash it. But maybe enabling this is "better" than reducing the strength slightly?



http://madshi.net/madVRhdrMeasure92.zip

1) Since both Neo-XP and Fer15 didn't like Gamma or PQ, they're gone. Back to Linear.
2) Updated the "Dynamic Clipping" algo to Soulnight's newest one.
3) Implemented Soulnight's "sky detection" algo.



http://madshi.net/madVRhdrMeasure91.zip

There's now a "shadow boost (for bright scenes)" option, ranging from "low" to "very high". Of course a "disabled" option is available, too. Please let me know which setting you guys end up prefering, so I can pick a "good" default.

There are 2 new options for you to play with:

1) "disable avgHighlights ceiling" disables one part of the FALL algo. This is very technical, I don't recommend using this, but for testing purposes it might be useful for a while.

2) The dynamic tuning is now available in 3 variants: "linear" (which is the original algo used by all previous builds), "gamma" and "PQ". I've tuned these 3 to look very roughly similar with a dynamic tuning strength of 50. Not sure if they stay similar if you compared them with a different dynamic tuning strengths.

I hope that the "gamma" and "PQ" options may be able to make better decisions for how bright each video scene should be rendered? At least both seem to pick lower target nits values for scenes with bright skies (which should be beneficial), without actually searching for bright skies yet.



http://madshi.net/madVRhdrMeasure90.zip

Now you can limit the shadow detail recovery to a specific nits range (e.g. up to 100nits). All pixels brighter than that will stay completely untouched by shadow detail recovery.

This change reduces the strength of the shadow detail recovery, so you'll have to adjust the other option, as well. E.g. try a "curve gamma" of 40 with a "threshold nits" of 100 as a starting point, and fine tune from there. I've no idea if 100nits is a good value to use for the "threshold nits". But in a very quick test it seemed like a reasonable choice, and going too low there doesn't seem to work very well. It will need some experimentation with different content to find a good value that works with most movies/videos.

Hopefully this new tweak might improve the algo even more, so it becomes fully usable now?

(P.S: The shadow detail recovery currently only works with the live algo. If you guys decide that it's a good algo to use, of course I'll also add support for the measurement algo.)



http://madshi.net/madVRhdrMeasure89.zip

Now the "restore shadow detail in percent" edit box actually works very differently compared to before. Basically it allows you to define the curve which is used to restore shadow detail.

In this build:
1) If you use a value of 10, you get a 1.0 power curve (which is a straight line, so it's the same as build 88 with 100%).
2) If you use a value of 20, you get a 2.0 power curve.
3) If you use a value of 40, you get a 4.0 power curve.

Using a higher value will now reduce the amount of shadow detail restauration, and will also reduce the effect on brighter image regions.
For a starting point, maybe try 40. You can also try 20 or 80.



http://madshi.net/madVRhdrMeasure88.zip

1) Fixed bug with some settings not being applied (e.g. display gamut).
2) Removed "Fall Knee" algo, and "APL Threshold".
3) Added "restore shadow detail" option and percentage edit box.

The reason why I added the "restore shadow detail" stuff is because dynamic tone mapping introduces problems with shadow detail. And the "restore shadow detail" option fixes that. It does, however, remove a bit of pop/contrast, and undoes a bit of what dynamic tone mapping does. Still, I think having proper shadow is very important, so we may have to compromise a little here.

In theory the only "correct" configuration is to activate the new "restore shadow detail" option and choose a percentage of 100. However, since it does come with some disadvantages, I'd still like to hear your feedback about which percentage looks best to you guys, subjectively?

Btw, this also helps a lot with scenes where there's a very bright sky, but "important" other stuff which is much darker. So all those scenes where Soulnight added a "sky detection" for.



http://madshi.net/madVRhdrMeasure87.zip

1) The Highlight Recovery bug reported by Neo-XP should be fixed (I hope).
2) The "apply target nits selection" feature has been modified a bit. The "no compression limit" and "max target nits" options are gone (hard coded to 0 and 10000 now), replaced by a new "use alternative FALL Knee algo" checkbox and a new "FALL threshold" control.

"FALL threshold" basically is a nits number which is substracted from FALL measurements, before calculating the final target nits value. The purpose of this option is that we probably don't want the dynamic target algo to darken the image if the measured FALL values are rather low. So by setting a specific "FALL threshold" number, you can tell madVR to only start increasing the target nits value if the measured FALL value exceeds a certain value. If you keep the default value of 0, the algo should behave mostly the same way as the previous build (which some slight modifications). If you use a value higher than 0, that will tend to make the image a bit brighter overall. So you may want to increase the dynamic tuning value a bit, to counter that effect (if you want).

"use alternative FALL Knee algo" was suggested by Soulnight and is available in this latest tool (see the other thread). I thought it was an interesting idea, so you can now try it with the live algo, as well. This algo will make some different decisions compared to the default FALL algo. I suppose that by choosing carefully tuned "FALL threshold" and "dynamic tuning" values it should be possible to make both the new "FALL Knee" algo and the old default FALL algo behave identical on average (while being sometimes slightly brighter or darker than the other algo), but I didn't have the time to find proper values for that. So I'll leave that to you guys.

No other changes in this build. Other than a big number of changes for the Envy. I hope that the Envy changes did not break anything.



http://madshi.net/madVRhdrMeasure86.zip

1) You need to enter all M1 and M2 thresholds multiplied by 10 now. So if you had entered 10 in the last build, now you have to enter 100. This allows more precision. E.g. entering "32" is now practically 3.2. Yeah, I know, I could have allowed true floating point edit controls instead, but that would have cost more development time, so I cheapened out by simply doing a 10x factor on the thresholds.
2) Line 1 is now "AND" operator instead of "OR".
3) Line 2 is gone. So the previous line 3 is now line 2.
4) Your M1/M2 settings are reset to the new defaults now, which are 65|15 for line 1, and 10|3.2 for line 2 (previously line 3).

Now the big question is if these default settings also work well in real life? Or are they only good for the Excel sheet, but make problems during real world playback?



http://madshi.net/madVRhdrMeasure85.zip

There are new options, let me explain them:
1) There are now 3 "lines" of options for how to combine Metric1 and Metric2.
2) First in line 1 of the new options, madVR checks if either Metric1 or Metric2 are below a specific threshold. If Metric1 or Metric2 are below the specified thresholds, madVR considers the frame to definitely *not* be a scene change, and the lines 2 and 3 of the new options are not even looked at, anymore.
3) In case Metric1 and Metric2 are above the thresholds of line 1, madVR checks if either Metric1 or Metric2 are above the thresholds defined in line 2. If either them is, madVR considers the frame to definitely be a scene change, and line 3 of the new options is not even looked at, anymore.
4) If neither line 1 nor line 2 apply, madVR uses line 3 to decide whether we have a scene change or not. Line 3 allows you to choose which Metric1 and Metric2 thresholds suggest that there "probably" was a scene change. Also you can choose which Metric you consider more important here. A Metric1 weight of 50% means that both Metrics are considered equally important.
5) You can disable any of the options in line 1 or 2 by setting them to 0.
6) If you want to disable e.g. Metric2 completely in line 3, you can either set the Metric2 threshold to 0, or you can set the Metric1 weight to 100%.
7) There are 3 OSD histogram numbers: Metric1, Metric2 and "weighted average of Metric1+2".

I think/hope the purpose and behaviour of lines 1 and 2 are clear to everyone now? But line 3 might still be a bit unclear, so let me explain how line 3 works, based on a couple of examples:
--------
Example 1)

M1 threshold: 9; M2 threshold: 8; M1 weight: 50%
measured Metric1: 9.5
measured Metric2: 7.5

Now in the first step madVR "normalizes" Metric1/2, which means madVR divides the Metric1/2 measurements by the threshold you've chosen.

normalized Metric1: 9.5/9 = 1.0555
normalized Metric2: 7.5/8 = 0.9375

The "normalization" has the effect that any value above (or equal to) 1.0 suggests a scene change, and any value below 1.0 suggests no scene change. So looking at the numbers in this example, Metric1 suggests a scene change, and Metric2 suggests that there's no scene change.

Now the two Metrics are combined according to your chosen weight of 50% each:

final metric: 0.5 * 1.0555 + 0.5 * 0.9375 = 0.9965

So the final metric says this is not a scene change. The final metric would have to be 1.0 or higher to suggest a scene change.

Example 2)
M1 threshold: 9; M2 threshold: 8; M1 weight: 90%
measured Metric1: 9.5
measured Metric2: 7.5
normalized Metric1: 9.5/9 = 1.0555
normalized Metric2: 7.5/8 = 0.9375
final metric: 0.9 * 1.0555 + 0.1 * 0.9375 = 1.0437
result: scene change

Example 3)
M1 threshold: 9; M2 threshold: 8; M1 weight: 75%
measured Metric1: 9.5
measured Metric2: 5.0
normalized Metric1: 9.5/9 = 1.0555
normalized Metric2: 6.5/8 = 0.8125
final metric: 0.75 * 1.0555 + 0.25 * 0.8125 = 0.99475
result: no scene change
-------
open questions:
1) "disable sub of prev frame": Currently the previous frame is substracted before evaluating any of the 3 new lines of options. Is that the right way to handle this? Or maybe the previous frame should only be substracted when evaluating line 3 of the new options? I'm not sure.
2) "disable sub of prev frame": I assume this should apply to both Metric1 and Metric2, correct? Or should this maybe only apply to one of them?
3) There can be a "scene change" false positive when there are strong brightness changes multiple frames in a row, e.g. during a fade out. The "sub of prev frame" feature probably solves that. But maybe we should do something extra to make sure there's no false positive scene change detection during fade ins and fade outs, to avoid a sudden brightness jump? If so, what's the best approach? E.g. should be increase the thresholds in line 3 of the new options by 25% during a fade in/out? Should we also change lines 1 and 2 thresholds?



http://madshi.net/madVRhdrMeasure84.zip

This will probably be the last Excel sheet style test build. The options are as follows:

1) "resolution": The resolution in which madVR does motion vector search. Resolution "2" has 4 times more pixels than resolution "1". So it probably also costs 4x as much speed. Consequently, I'd prefer to pick resolution "1", which is also what all the recent test builds used. But I'll let you test resolution "2", just to be sure we're not missing a potentially dramatic quality improvement.

2) "search distance": The max supported motion vector distance. In theory higher should be better because it will detect motion better in very high motion scenes. However, supporting larger motion vectors also means a higher chance to detect a false positive motion vector. So this might not be as clear cut as it seems. A big problem with testing is that supporting a large search distance will only help with those few video samples which really have such large motion vectors, while it might harm a little bit in all other video samples. Generally, I tend to prefer going as large as possible here, though. Unless it comes with a significant quality loss.

3) "block size": The area around each pixel which is compared to find a matching motion vector. In theory going large here is "good" because it helps reject false positives better. However, if there's a small object moving around, we might not detect the movement properly if we require too large a neighborhood of pixels to match. So going too large will also hurt in some cases. So we need to find the best compromise.

Both search distance and block size also depend on the resolution. For example, both block size and search distance must be doubled if we double the resolution, to achieve the same effect. So for the bigger resolution, probably we also need to use bigger search distance and block size, which again costs more speed. One more reason to pick the lower resolution, if it's possible without losing too much quality.

FYI, the setting "resolution: 1, search dist: 2, block size: 3" should produce the same results as the previous test build at 35%. So you don't need to retest "resolution: 1, search dist: 2, block size: 3", you can just copy the numbers.

P.S: We already tried testing some of this a while ago, but it was before we have the "threshold" logic in the Excel sheet, and Neo's and Fer's results heavily contradicted each other. So I'm hoping this time around with the increased number of test scenes, and the "threshold" logic in the Excel sheet, we'll get more conclusive results.



http://madshi.net/madVRhdrMeasure83.zip (fixed +5%)
http://madshi.net/madVRhdrMeasure82.zip (added 5% steps between 0-75%)
http://madshi.net/madVRhdrMeasure81.zip

I didn't work on the fade in/out yet. This test build just modifies the "Metric2 algo" once more. This is probably going to be the last *quality* related Metric2 test build. Afterwards there's just going to be one more test build to maybe improve speed (if possible without losing too much detection quality).

You can now choose a minimum amount of pixels madVR looks at for Metric2. The default of the previous test build was 35%. You can choose a higher percentage. Doing so will help high APL scenes, but it will probably hurt other scenes. So this one could be tricky to choose a "good" value for. I've chosen those 35% to avoid some false positives in Fer15's test set. But maybe choosing a higher value could still be useful. Historically, IIRC Fer15 likes lower values here and Neo-XP higher values, so another reason why this could be tricky.
@Neo-XP, two questions:

1) Would it make sense to maybe add a separate "misses sum" line for high APL scenes and to exclude them from the other sums? Right now you're separating "false positive misses" vs "real scene misses". So there would be a 3rd line for "high APL misses". Doing that would allow us to check if switching from 35% to a higher value only helps high APL scenes, or if it could potentially help other scenes, as well. Generally, I'm not sure if we need to worry too much about high APL scenes, because Metric1 does a great job with those. On the other hand, it we can make Metric2 handle those better without any negative side effects, why not?

2) A good question is how to split the testing work between you and Fer15, since you now merged all his scenes into your sheet. He had some suggestions, e.g. one of you could test false positives, the other one real scenes. Or maybe he would simply continue to test "his" test set and you would skip those and then you could throw your numbers together? It's not important to me how you split the work, of course, you can decide for yourself. Just wouldn't want you both to duplicate each other's work, to not waste any of your time.



http://madshi.net/madVRhdrMeasure80.zip (fixed "D3D11 native" to produce the exact same scene change measurements)
http://madshi.net/madVRhdrMeasure79.zip

1) Metric2 now has higher values for scope movies, but same values as before for 16:9 movies.
2) Brightness adjustment speed is "infinite" during fade-ins now.
3) Added a couple new Metric2 algorithm variants.

The first Metric2 algo variant should be identical to the previous test build, when set to "value RGB equally". However, due to the black bar change (see 1) above), maybe it would make sense to test the first Metric2 algo variant once more, so we can better compare if any of the new variants are better than the first one or not.

FWIW, this test build contains my last/final "big" ideas on how to improve Metric2 quality. I'm curious to see if there's any improvement.



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.



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



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%.



http://madshi.net/madVRhdrMeasure75.zip

So building on the results of the previous test build, here are 3 new variations which may or may not improve the overall number of misses (while still failing at detecting big FALL changes).



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.



http://madshi.net/madVRhdrMeasure73.zip

I apologize in advance because this build has a LOT of different options that can be (theoretically) combined with each other. However, I think testing one option at a time, instead of any possible combination, should make it doable. I could have made a drop-down-box for that, instead of offering a multitude of different controls. But I thought I'd give you more freedom to try what you want.

Some explanations:
1) "apl correction": CLD tries to find the motion vector which produces the lowest error, and does so by adjusting APL levels, if necessary, to achieve a smaller error. This should help in lightning scenes etc. But this can also cause false motion vectors to be detected. With this option unchecked, APL changes are accepted (and adjusted to) up to a factor of 4.0x, without any strings attached. With this option checked, while APL changes are still applied and accepted, the error is increased a bit, if the APL has to be changed a lot. This might help avoid the detection of false motion vectors. In theory I think activating this option should be positive.
2) "apl factor": With this option disabled, APL adjustments are not punished at all. Using "mul" or "avg", pixels which are adjusted for APL are considered for the overall "metric2" number with a higher percentage. "mul" vs "avg" simply decides how to apply the math internally. In theory I think this option at "mul" or "avg" (not sure) should be positive.
3) "unsmooth step": With this option checked, the errors of spatially smooth motion vectors are completely ignored. With this option unchecked, there's a percentage of the error counted, depending on how smooth the motion vector is. I've no idea whether this option helps or hurts.
4) "no movement": This option is kind of a hack, and it was added with the single purpose to detect La La Land scene change from black. Basically it makes sure that pixels with a zero motion vector can't be completely ignored for the Metric2 error calculation. Usually, in a La La Land type of scene change, almost all motion vectors are completely zero. I don't really like this option, if we can avoid it, we probably should.
5) "minFactor": This option defines the minimum percentage (1.0 = 100%) each pixel's error has to be included in Metric2.

Now to make things a bit clearer: With a specific combination of options you can achieve exactly (or almost exactly) what the previous 2 test builds (71 and 72) were doing. Here's which settings those are:

71-0.10: apl correction = off; apl factor = disabled; unsmooth step = on; no movement: 0.10; minFactor = 0.00
71-0.25: apl correction = off; apl factor = disabled; unsmooth step = on; no movement: 0.25; minFactor = 0.00
72-0.00-mul: apl correction: on; apl factor = mul; unsmooth step = off; no movement: disabled; minFactor = 0.00
72-0.00-avg: apl correction: on; apl factor = avg; unsmooth step = off; no movement: disabled; minFactor = 0.00
72-0.10-mul: apl correction: on; apl factor = mul; unsmooth step = off; no movement: disabled; minFactor = 0.10
72-0.10-avg: apl correction: on; apl factor = avg; unsmooth step = off; no movement: disabled; minFactor = 0.10
72-0.25-mul: apl correction: on; apl factor = mul; unsmooth step = off; no movement: disabled; minFactor = 0.25

So Neo-XP, you can now test the 71 algo with "no movement" values of 0.10, 0.15, 0.20, 0.25, as you had requested. And you can also test the 72 algo with different minFactors now (anything from 0.00 to 1.00).

I'm wondering myself which settings we should really test now? It seems 71 worked pretty well and 72 not at all. But which of the tweaks I did in 72 made things worse? Might make sense pick the 71 configuration (but maybe with "no movement" disabled, because some of the new 72 tweaks fix La La Land without needing the "no movement" hack), and then test one 72 tweak added on top, to figure out which 72 tweaks are good (if any) and which are bad?

@Neo-XP, could you kindly run a very short "pre-test" to verify that 73 gets you nearly the same results as 71 and 72, when choosing the appropriate options? This is just a safety check to make sure that everything is working as intended, before you invest too much time into this, only for us to later find out that there's a bug hidden somewhere. I don't really want to waste your time. If you get roughly the same results with 73 as you got with 71 and 72 (when using the correct option combinations), then the build should be "good" for testing.



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.

*REALLY* curious how these will measure. I'm hoping for another improvement in "misses", on top of making cuts from black and high APL changes work. Maybe I'm too optimistic?



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?



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.



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.



http://madshi.net/madVRhdrMeasure68.zip (fix "high freq 32-4")
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.



http://madshi.net/madVRhdrMeasure66.zip

- added option to disable the FALL tweak for Metric2



http://madshi.net/madVRhdrMeasure65.zip

- added "adjust for brightness" option for metric1
- fixed a bug in the combined metric 10.0 threshold check



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.



http://madshi.net/madVRhdrMeasure63.zip

The numbers for "always ignore" are the same in builds 62 and 63, so no need to retest them. But the numbers for "always adjust" and "choose lowest diff" are different in builds 62 and 63.
Edit: Fer15 confirms build 63 seems to produce *much* better results for "always adjust" and "choose lowest diff" compared to build 62. So trash build 62, please.



http://madshi.net/madVRhdrMeasure62.zip (fixed a bug in the APL logic for metric2)
http://madshi.net/madVRhdrMeasure61.zip

1) Actual scene change detection should now be based on the 3rd number (combined metric1 & metric2) exceeding 10.0.
2) Metric2 uses 69:69 for now. I can still change this later, or maybe optimize speed.
3) There's a new "metric2 APL behaviour" option now, which defines how to handle the situation if the APL changes between 2 consecutive frames. Previous builds always tried to adjust to the new APL, to try to workaround things like lightning bolts etc. However, I'm not sure if that's actually the best idea for metric2. So you can choose to simply ignore APL changes instead, or to try both and use the lower difference for each compared *pixel*. Please note that these options can produce unpredictable changes in the numbers. So we need our usual large number of scenes to draw any real conclusions. The "choose lowest diff" will probably also lower the overall numbers, which might once again require you to adjust the metric2 threshold.



http://madshi.net/madVRhdrMeasure60.zip

This is now hard coded to "medium" size. There are now 5 options, with varying "wideness" and "complexness". "81:25" should be the same as "wildly complex, extra wide" in the previous build (maybe you can do a very quick double check, just to be safe). The other options have some more complexity vs wideness. The first number is the "wideness", the 2nd number is the "complexness". Also, the old build did everything in squares. The 4 new options in this build try to do things in a more circular way, which I hope (but am not sure) might improve the speed vs quality ratio.



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".

My suggestion would be to start testing with the default (same as previous builds) which is "simple, medium, normal". Then from there you could try changing one of the 3 option categories, and check which gives you better results, and you can also compare speed and whether the quality improvement is worth the speed hit. I wouldn't recommend to test all 27 variations. Just start with the default, and only change one of the 3 option categories at a time.

P.S: Forgot to say: Please activate the option "disable substraction of previous frame" while you're testing the new options. The reason for that is that although the "substraction of previous frame" feature seems to work great to avoid false positives, it makes it more difficult to test new metric2 algorithm variants, because it makes the numbers a bit unreliable. E.g. if a specific option combination creates a huge spike for frame X, then frame X + 1 will appear to have very low numbers. So the numbers for frame X + 1 may be misleading. Disabling "substraction of previous frame" allows you to check the metric2 for each frame on its own, without being affected by the detection numbers of the previous frame. That should help with testing...



http://madshi.net/madVRhdrMeasure58.zip (added Bicubic125 and Bicubic150)
http://madshi.net/madVRhdrMeasure57.zip (fixed a bug in the downscaling code that might have favored SoftCubic)
http://madshi.net/madVRhdrMeasure56.zip (added SoftCubic80 and SoftCubic100)
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).



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.



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.



http://madshi.net/madVRhdrMeasure52.zip

1) There are now 4 numbers written over the histogram. The first two are the same as in previous builds. The other two are: 3) average of both metrics, 4) scaled product of both metrics.

2) There's a new feature that builds a rolling average of the scene detection metrics. And this rolling average is then substracted from the scene detection metrics. The new option called "substract rolling average percent" defines how much of the rolling average is substracted. A value of 100 means 100%, a value of 0 means the rolling average is not substracted at all.

Are the 2 new numbers is the histogram useful? Maybe we could use one of those instead of using the two metrics separately? Having only one combined metric number could be useful, e.g. we could later try to scale the brightness adjustment speeds with the scene detection percentage somehow.

Substracting the rolling average of scene detection percentages has the purpose that it might help avoid false positives in heavy action scenes. Let me mention an example, to make things clearer. E.g. let's say we have defined a scene change detection threshold of 20%. Now if the scene detection for several consecutive frames looks like this:

0, 0, 0, 0, 0, 0, 0, 20

This is probably a scene change, right? But what about this situation?

10, 12, 14, 12, 16, 18, 17, 20

Is this still a scene change? That's why I thought substracting a rolling average should help. I'm not sure if we should substract 100% of the rolling average, though, that might be too much? I've set the default to 50% now. Another question is how long the rolling average should be? Atm it's hard coded to 0.5 seconds (= 12 frames for 24fps movies, 30 frames for 60fps videos).



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.



http://madshi.net/madVRhdrMeasure50.zip

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.



http://madshi.net/madVRhdrMeasure49.zip (fixed the accidental doubling of the first luminance change)
http://madshi.net/madVRhdrMeasure48.zip

There are 2 different scene detection metrics now. Both thresholds have to be met in order for a scene change to be detected. I've no idea if the 2nd (new) one is useful or not. Maybe it can help out in situations where the first metric detects a false positive? Both metrics are quite different in how they're calculated, so they could potentially show different behaviour in different scenes.



http://madshi.net/madVRhdrMeasure47.zip

1) Dynamic clipping etc is only done while playing videos, but not when creating measurement files.
2) There's a new option to enable histogram smoothing.

In my quick tests it seems that the histogram smoothing overall lowers the scene change percentage number, but more so for non-scene-changes compared to real scene changes. So I think it might be useful to increase the overall scene changes reliability. But I'll leave the decision up to you guys. What do you think?
P.S: I'd recommend that you trash measurement files made with builds 41 up to 46. But measurement files created with builds up to 40 should be fine.



http://madshi.net/madVRhdrMeasure46.zip (fixed an issue that caused by the black bar removal from the scene change detection)
http://madshi.net/madVRhdrMeasure45.zip

1) Removed some stuff to cleanup the number of options.
2) Scene detection can now optionally ignore pixels above 100nits. Does that help?
3) You can't any longer use different values for brightening vs darkening. Same speeds for both now, to make things simpler. There was no agreement on whether to use higher values for brightening vs darkening at all (e.g. Dexter and Fer15 had opposing views), so this removes one possible cause of disagreement.
4) Instead of "safe" vs "fast" speeds you can now define the speeds at various brightness differences (linear interpolation in between). This allows more control over which speed is applied in which situation exactly. The default values are probably quite "careful" / slow. Not sure, you might find them too slow?
5) I moved the "ignore measurement files" option to the "configuration -> files & folders" tab.

I'm usually looking at Passengers timecode 1.15.00 (exactly). I think I can see some dimming there if the speed is too high.



http://madshi.net/madVRhdrMeasure44.zip

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.



http://madshi.net/madVRhdrMeasure43.zip

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.)



http://madshi.net/madVRhdrMeasure42.zip

1) I've added an option that allows you to make madVR ignore all measurement files. Please note that you need to re-load the running video in the media player, if you change the option while video playback is running. The modified option won't become active until you re-load the video in the media player.
2) I've added a new option now that lets you define how long a scene must be to qualify as a "long scene". To be more exact: If there's a "long scene", and then a sudden scene change, madVR will switch the dynamic display target nits immediately. However, if there are multiple sudden scene changes, without a "long scene" in between, madVR will no longer suddenly switch the dynamic display target nits. This new behaviour should fix the Mad Max scene, and doesn't seem to introduce new problems, on a quick check. But of course I'll rely on you guys to test this.
3) Scene change detection tries to (approximately) ignore black bars now. @Neo-XP: Does that mean we should modify the "small scene change" threshold (currently 10%)?
4) Some small tweaks.



http://madshi.net/madVRhdrMeasure41.zip

I've implemented the very same algorithms that Anna & Flo implemented in their "optimization tool" for measurement files - but I've implemented them for the "live algo" (meaning when no measurement file is available). Due to not having a measurement file available for the "live algo", of course I couldn't implement the Anna & Flo "chapter" algorithm, so I implemented that part of the algorithm differently.

All the same settings/options that Anna & Flo offer are also available in this test build (except the "chapter" related settings). Please note that this build is *not* intended for fine tuning the Anna & Flo algorithms. Of course you can do that, if you like, but it's not really what I'm interested in hearing from you in this thread at this point. The main purpose of this build is to check if all the "dynamic" improvements introduced by Anna & Flo's tool can also be made to work with the "live algo".

What I'd like you to do:
1) Use the same settings you're currently using with the Anna & Flo tool. Or if you've not used that tool yet, just stick to the default settings.
2) Please start by unchecking the "detect scene changes" option and fine tune the "max brightening/darkening per second" options. What you want to achieve is a fast but completely invisible adjustment to dark vs bright scenes. Of course the goals "fast" and "completely invisible" contract each other, so please try to find the sweet spot. The sweet spot is probably the setting which is *just* slow enough to be invisible.
3) Once you've selected brightening/darkening settings that are invisible to you (but still reasonably fast), please enable scene change detection and try to find a scene change threshold which doesn't produce noticeable artifacts (e.g. flickering), but which still detects most scene changes properly. Please note that it's perfectly ok if some scene changes are "missed" by madVR, as long as the miss doesn't come with noticeable image quality deficits. So you should probably error on the side of missing some scene changes, instead of producing false positive scene change detections.
4) And of course I'd like to have your opinion on whether my current "dynamic live algo" implementation with scene change and brightening/darkening settings already works well enough, or if we need to find some more improvements to make it useable.



http://madshi.net/madVRhdrMeasure40.zip

- The main change is to fix a problem when using Anna & Flo's "optimizer" tool for the measurement files.
- There are a couple HDR unrelated changes in this build (nothing terribly important). I hope I didn't introduce new bugs, but can't guarantee that.



http://madshi.net/madVRhdrMeasure39.zip

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.



http://madshi.net/madVRhdrMeasure38.zip (fixed couple small bugs that affected measurements once more, trash all the measurements you made with build 37 once more)
http://madshi.net/madVRhdrMeasure37.zip

This time it's a test build for everyone, not just for users of the "live algo". I've done quite a lot of changes, here's a list, from the top of my head, maybe the list is even incomplete:

1) Cleaned up HDR settings a lot.
2) Moved some HDR settings to "trade quality" section.
3) Trade quality option "compromise on HDR tone & gamut mapping accuracy" is on by default and activates dumb tone mapping.
4) Trade quality option "compromise on HDR luminance channel quality" is on by default and activates "fast" luminance repair (plus "repair repair").
5) Trade quality option "don't measure HDR frame peak luminance" if off by default and disables measurements + dynamic tone mapping.
6) Moved measurement file folder setting to a separate settings page.
7) Renamed "user interface" settings folder to "configuration".
8) High quality luminance repair defaults to 300@0.010 for now, but I'm still listening to feedback, e.g. 1000@0.008 etc are still valid options.
9) Ported the "Atomic Blonde fix" to the measurement algo.
10) Fixed broken measurements, due to "Atomic Blonde fix".
11) Had to break/change measurement file format once more... :(
12) Added a header field to the measurement file format which allows you to optionally define a "target peak nits" value for each movie.
13) Added an optional measurement file format section which allows you to define a specific "target peak nits" value for each movie frame.
14) madMeasureHDR.exe now reports mastering display black level, too.
15) madMeasureHDR.exe now reports metadata even if measurements are incomplete.
16) madMeasureHDR.exe no longer reports MaxCLL 99.8% and 99.0%.
17) Live measurements are no longer taken, if a complete measurement file is available (to save performance).
18) Black bars are now excluded from Avg/MaxFALL measurements.

This is a release candidate build. Which means, no further feature changes are planned atm. Just bug fixes and minor tweaks (if at all). Would like to release a new official build very soon now.

As mentioned above, unfortunately I had to break the measurement file format once more. I'm sorry about that. The change was necessary to make the "Atomic Blonde fix" work with measurement files, too. Here's a description of the file format changes:

a) The file format version number is now 6 instead of 5.
b) The header size is now 10 DWORDs instead of 9.
c) The new header field is "TargetPeakNits" and is always set to 0 by madMeasureHDR. If you set this value to a specific number, madVR will use that number as the "target peak nits" setting for this one movie, instead of the "target peak nits" setting from your HDR settings page.
d) The old histogram section looked like this:
Code:
struct THistogram
{
  WORD PeakPq;
  WORD LumHistogram[256];
  WORD HueHistogram[31];
};

The new one now looks like this:
Code:
struct THistogram
{
  WORD PeakPq2020;
  WORD PeakPqDci;
  WORD PeakPq709;
  WORD LumHistogram[256];
  WORD HueHistogram[31];
};

As you can see, the peak of each frame is now available for BT.2020, DCI-P3 or BT.709 output. For calculations in your 3rd party tools I'd recommend to always use PeakPq2020, which is the same as in the old measurement file format. The "PeakPqDci" and "PeakPq709" fields are only needed by madVR to apply the "Atomic Blonde fix".

e) There's a new header flag "0x00000002" available. This flag is never set by madMeasureHDR.exe. But 3rd party tools can set this flag. If they do, they must add a new data section to the end of the file which has one WORD for each video frame. This WORD describes the "target peak nits" that madVR should use for each video frame. This way 3rd party tools are able to dynamically adjust madVR's "target peak nits" value during the runtime of the movie. Whether or not this is actually useful is not clear yet. But this should allow Soulnight to invent some new algos to test his ideas.



http://madshi.net/madVRhdrMeasure36.zip

I've added a new algo which tries once more to do selective repair. Or actually, it tries to repair the damage done by the repair luminance algo. So it's a "repair repair" algo, so to say.

The new algo (if it works) *may* eventually result in you slightly re-tweaking the repair luminance blur strength and ringing threshold, so I've kept those settings for this 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.

Let me know which of the options you prefer. Looking at Sony Camp 0:01:28 or Mad Max 0:28:29 or my preferred Phoenix frame, I think I prefer BT.709 overall (although it needs more repair), but I wanted to give you a chance to test this for yourself.



http://madshi.net/madVRhdrMeasure34.zip

based on feedback from Neo-XP and Fer15 (in another forum) I've decided to go back to the "old" repair luminance algo, but with the higher quality (and sadly slower) blur. There's still one thing to fine tune, which is the blur strength.

Please note that using a different blur strength will also require you to pick a matching ringing threshold. Meaning if you lower the blur strength, you should probably use a higher ringing threshold, and if you increase the blur strength, you should probably use a lower ringing threshold. FYI, the previous builds used a hard coded blur strength of 100. So it seems a blur strength of 100 is a good match to a ringing threshold of ca 0.010.

I've not fully tested which ringing thresholds should be used for the other blur strengths. Maybe 0.007 for 1000? I've no idea.

To make testing faster, I highly recommend that you only test 20 vs 100 vs 1000 first and ignore the other options. You can later check the other options to fine tune. Your first step in testing should be to pick a good ringing threshold for each of the 3 blur strengths. You can do that by using a test pattern which shows strong halos. Once you've picked a good ringing threshold for each of the 3 blur steps, you can compare 20 vs 100 vs 1000 with your preferred test scenes.



http://madshi.net/madVRhdrMeasure33.zip

I've got the "ok" to post screenshots from the NDA content, showing the "weird artifacts" which made me make the repair algo slower. So here goes, look for streaks in the sky above the mountain top:

As you can see, the "old" algo has the biggest artifacts, but the new and mixed algos still show the artifact, too (less strong). So I had to switch to a higher blur quality. Which mostly fixes the issue. I think I can still see a hint of the problem with the "old - higher blur quality" image, but it's nearly gone in the new/mixed algo, when using the higher blur quality. Of course I could choose an even higher blur quality, which would make things even slower, to make the problems completely invisible with any of the algos. But we probably don't want to lose even more speed, do we?

The "mixed" is a new option in this new test build.

This new test build now allows you to directly compare old vs new vs mixed. I've also auto adjusted the ringing thresholds. So a threshold of ca 0.010 should now work for all 3 variants, to make comparisons a bit easier for you.

So you can now pick which of the 3 algos to use, with the same improved (and slower) blur quality for all 3. Considering that the "old" algo still shows a hint of the artifact (although very faintly), maybe we should prefer new or mixed. But I'll leave that up to you. In any case, which of the 3 do you prefer overall?



http://madshi.net/madVRhdrMeasure32.zip

- fixed the hue histogram bug
- Found a scene which showed weird artifacts with the new "repair luminance" algo, so I had to modify it slightly

Looking at Phoenix and BvS, I think the new build shouldn't be worse, may even be a bit better. It's slightly slower, though. And you'll have to re-check the ringing-thresholds. On a quick check, maybe multiply the ones you like now by 1.5? So if you liked 0.10 with the previous build, maybe now 0.15? But I'll let you be the judge.



http://madshi.net/madVRhdrMeasure31.zip

This time there's a new option which applies the "repair luminance" algo only on image areas which seem to need it. It seems to work pretty well for the Phoenix and Mad Max scenes, but doesn't work as well for the Pan scenes. Also it's quite slow (although I might be able to optimize speed a bit more). I wonder if this new option is needed/beneficial? If we can get along without, that's probably better, because applying some processing only to selected image areas might eventually add artifacts on its own. But I wanted to give it a try, so let me know what you think...



http://madshi.net/madVRhdrMeasure30.zip

Changes mainly for live algo:
- fixed flicker risk calculation
- atomix blonde fix now always active
- lower values for the repair luminance feature
- a new "apply special highlight tweak" (effect seems fairly small, but it is positive or negative?)



http://madshi.net/madVRhdrMeasure29.zip

1) added option to apply possible fix for Atomic Blonde BT.709 detail loss (only for live algo atm)
2) added option to choose various "repair luminance" algorithm variants
3) modified reaction times for live algo
4) modified live algo measurements a bit to possibly fix highlight loss with Valerian
5) (de)activating "enable dynamic HDR" or changing calibration gamut will now clear and redo live algo measurements instantly

As you can see, almost all changes are only for the "live algo" (the one madVR is using when there's no measuremente file). If these changes prove "good", of course I'll port them to the measurement logic, too. So everyone who's using measurement files etc, you can probably mostly ignore this build. This build is mostly for users who use the live algo, especially Neo-XP and Fer15.
@Neo-XP:
- can you please check if the Atomic Blonde problem is improved?
- can you please check if the flickering issue with Starship Troopers is fixed?
- can you please check if the tone mapping halo problem is gone with the new "repair luminance" algorithm variants?
@Fer15:
- can you please check if the Atomic Blonde problem is improved?
- can you please check if the Valerian highlight loss problem is improved?
@Neo-XP, @Fer15, @Everyone else who's interested:
Which settings do you prefer for the new repair luminance options? A good test demo for this is Samsung Wonderland Two. E.g. frame 2250 shows very strong halos with the old ("fast") repair luminance algo. And frame 1550 shows detail differences between the various new repair luminance variants.

P.S: And how much performance does the new "repair luminance" algo cost?



http://madshi.net/madVRhdrMeasure28.zip

1) Changed measurement file format one more (last?) time. Changed described in detail below.
2) Optimized dynamic tone mapping adjustments when using the measurement file.
3) Live algo brightness reaction time is now automatically selected, based on the flicker risk.
4) Luminance histogram is now more detailed and shows pixels below 100nits in a different color than pixels above 100nits.
5) madMeasureHDR.exe now reports the original metadata and lots of measured numbers.
6) Added profile variables "maxCll90", "maxFall", "avgFall", "avgFmll", some are also shown in OSD.
7) Measured maxCll99.9 value is now used instead of maxCll100 for everything.
8) If maxCll99.9 is higher than the original maxCll metadata, the original maxCll metadata is used instead.

Please check both the live algo and the tone mapping when using the measurement file. Can you find any visible artifacts like flickering, brightness jumps or blown out highlight detail?

For profile switching, maybe "avgFall" could be helpful? It's practically the average brightness (in Nits) of every pixel in the whole movie combined. "avgFmll" is "avg frame max light level", which is the average of the peak measurements of every frame in the movie.

The file format header is the same as before, but version number is now 5, and there are 2 new DWORDs for "MaxFALL" and "AvgFALL", so the header size is now 9 DWORDs instead of 7. After the header we first have the scene information, which has the same format as before. After that we now have the following data (576 bytes) for every frame:

Code:
WORD PeakPq;
WORD LumHistogram[256];
WORD HueHistogram[ 31];
The luminance histogram is split into 2 sections: The indexes 0..63 describe the pixels from 0nits - 100nits. The indexes 64..255 describe the pixels from 100nits - 10000nits. You can calculate the "nits" value for each index like this:

Code:
nits0   = pq2linear(( 0 + 0.5) / 64 * 0.50807842151739901) * 10000.0;  // LumHistogram[ 0]
nits63  = pq2linear((63 + 0.5) / 64 * 0.50807842151739901) * 10000.0;  // LumHistogram[63]
nits64  = pq2linear(0.50807842151739901 + (  0 + 0.5) / 192 * (1.0 - 0.50807842151739901)) * 10000.0;  // LumHistogram[ 64]
nits255 = pq2linear(0.50807842151739901 + (191 + 0.5) / 192 * (1.0 - 0.50807842151739901)) * 10000.0;  // LumHistogram[255]

"0.50807842151739901" is the PQ value for 100nits.



http://madshi.net/madVRhdrMeasure27.zip

1) Added some workarounds/improvements for incomplete measurement files. Will not solve all problems! But maybe some.
2) Incomplete measurements files are still created, but now get the file name extension ".measurements.incomplete", and are ignored by madVR.
3) madVR no longer stores/remembers measurements during playback, because those were often incomplete, anyway.
4) Simplified settings dialog.
5) Dynamic intra-scene optimizations are now always active, if a (complete) measurement file is available.
6) Dynamic intra-scene optimizations now vary between min 4% and max 20%, depending on the situation.
7) Dynamic intra-scene optimizations are now carefully post processed / smoothed.
8) Dynamic intra-scene optimizations are now only done for 4+ second scenes. Shorter scenes are tone mapped to the scene's peak.
9) Fixed problem with histogram adding up to 106.67% instead of 100%.
10) Live algo: Added 3rd percentage value to histogram "flicker risk".

@Everyone, could you please double check that the dynamic intra-scene optimizations are working well? Basically, they should be relatively fast (up to 20%) for most scenes, but slow enough (4%) for flicker risky scenes like the Matrix 2 scene we tested with. Obviously we want full fast dynamic reaction, but there should be no luminance fluctuations/instabilities, and no visible brightness changes in the middle of a scene.

@Neo-XP, Fer15, and everyone interested in improving the Live algo: Could you please check if the 3rd/last percentage number in the histogram is useful to tune the brightness reaction time? FYI, the first number is the same as always. The 2nd number is the forth number from the previous build (the one Neo-XP found most useful).



http://madshi.net/madVRhdrMeasure26.zip

1) File names are truncated at the first "?" character.
2) Added some more debug output to find the cause of incomplete measurement files.
3) Added more histogram change percentage numbers to OSD.

All those of you who still have problems with getting incomplete measurement files, could you please create a debug log for me, using madMeasureHDR.exe to measure one of those movies where you get incomplete measurements? You will have to measure the full movie which will create a monster sized log file. Sorry about that. Please zip it, or even 7zip it, to get a reasonable file size for upload. (Please also include the resulting measurement file in the zip/7zip upload).

@Neo-XP, there are now 4 percentage change numbers in the luminance histogram instead of just 1. The top two show the histogram change of the current frame to the previous frame (same as in older builds), and the histogram change of the current frame to the frame which was shown 4 frames ago. The bottom two show the APL change of current frame to the previous frame, and to the frame 4 frames ago. For 60fps sources it's actually 10 frames instead of 4 frames. The "4 (or 10) frames ago" logic stops at a scene change border. So if you're 2 frames after a scene change, the 2nd number in both lines will be for 2 frames ago, not for 4 (or 10).

Maybe these new numbers will help find a better formula for dynamic brightness reaction logic? E.g. I hope the new numbers will show greater differences for the green Spear scene, but similarly low differences for the Matrix 2 scene?

(Just to avoid misunderstandings: I'm *not* planning to change scene detection. The new numbers are just for finding a suitable brightness reaction time, depending on histogram or APL change.)



http://madshi.net/madVRhdrMeasure25.zip

1) (Hopefully) fixed madMeasureHDR creating incomplete measurement files.
2) Modified file logic to replace invalid file name characters.
3) Fixed bug which resulted in weird behaviour when using "max dynamic scene adjustments" with incomplete measurements.



http://madshi.net/madVRhdrMeasure24.zip

Sorry, guys, due to the bugs, you have to redo all measurements. Because of that I've now also taken the "opportunity" to modify the file format once more. I'm now storing almost all information I measure, including the measured peak and histogram for every frame. I'm currently not making use of the histogram in madVR (other than for the OSD). But having all information in the measurement file means we hopefully may not have to re-measure in the future (unless the resolution of the histogram isn't high enough for some reason).

The new measurements files get much bigger now, because I'm storing the histograms. Is that a problem for anyone?

There's a new option called "max dynamic scene adjustments". If you disable it, madVR will use an optimized but constant tone mapping curve for each scene, similar to how HDR10+ will work, and exactly the same as the previous madVR test builds behaved. If you enable the "max dynamic scene adjustments" option, madVR will dynamically adjust the tone mapping parameters within each scene in such a way, that darker time periods in each scene will be compressed less than brigher time periods. This is done in such a way that there will never ever be clipped highlights. The only possible disadvantages of this new algorithm compared to disabling it is that you might be able to see the change in tone mapping parameters. However, if you choose a relatively low % number, it should be pretty much invisible, but provide a fair brightness and pop boost, for long scenes that vary a lot in peak brightness. This new algo is something that HDR10+ will (as far as I understand it) *not* be able to do. So we may actually have a solution now which is better than HDR10+.

Of course the new algo needs serious testing to make sure there are no unexpected bugs. And we need to decide which config for the new algo is the "best". Let me know what you think!

A good scene for a quick test would be the "Mother" scene (posted earlier in this thread, IIRC) where Jennifer turns on a lamp in a dark zoom. The same scene starts at 6nits, but then goes up to almost 1,000nits, *without* a scene change. With the new option disabled, madVR tone maps the whole scene to nearly 1,000nits. With the new algo enabled, the beginning of the scene is rendered without any compression, and tone mapping then ramps up slowly (depending on the config) and smoothly, and early enough so that when the lamp is turned on, the tone mapping is already at 1,000nits, so there's zero clipped highlights.



http://madshi.net/madVRhdrMeasure23.zip (fixed OSD glitch)
http://madshi.net/madVRhdrMeasure22.zip (fixed a measurement bug)
http://madshi.net/madVRhdrMeasure21.zip (fixed Toggling "enable dynamic HDR" option off had no effect, it was always forced on)



http://madshi.net/madVRhdrMeasure20.zip

1) madMeasureHDR now has optimized RAM usage.
2) madMeasureHDR now supports up to 4GB RAM instead of just 2GB.
3) madMeasureHDR now "hacks" DXVA Native into DXVA Copyback.
4) madMeasureHDR now reports the measured MaxCLL value.
5) Removed "limit" option, nobody liked it.
6) Added option to store (or not store) measurements during playback.
7) Added option to choose a measurement file storage folder/path.

If you don't specify a path, the measurement files are stored in the same path as the movie file itself.



http://madshi.net/madVRhdrMeasure19.zip

- fixed the previous build that still didn't always accept the measurement files, this one hopefully will.
- I did change the file format one more time, so you'll have to throw away your old measurement files and redo them



http://madshi.net/madVRhdrMeasure18.zip

1) Removed options for brightness delay, darkness delay and darkness reaction time.
2) Added 0.30s, 0.35s, 0.40s, 0.45s options for brightness reaction time.
3) Brightness reaction time defaults to 0.25s now.
4) OSD shows "frame % nits, scene % nits, movie % nits", if the measurement file is accepted as "complete".
5) Added option to limit the measurements to the mastering monitor peak luminance.



http://madshi.net/madVRhdrMeasure17.zip

1) Measurement file format has changed, madVR will ignore older files, you'll have to redo them all. But I think the format will probably stay fixed from now on.

2) If the measurement file is "complete" (not partial), the measured MaxCLL is now used to replace the MasteringMonitorPeakLuminance+MaxCLL metadata, both for rendering and profiles!

3) Kris suggested to ignore all measurements/pixels which exceed the master monitor peak, because the mastering monitor would have clipped those. So by ignoring those measurements, we should be able to get nearer to what the mastering monitor showed. As a result, madVR will now never exceed the mastering monitor peak luminance, for both MaxCLL metadata, measured MaxCLL and tone mapping target. This is open for discussion. If you don't like it, let me know.

4) If the measurement file is "complete" and the duration matches the movie duration (a difference of up to 10 video frames is accepted to account for splitter/decoder differences), madVR will use the measurement file as "law" and not overwrite it with real time measurements. If the duration doesn't match, madVR will still use the measurement file, but will also do measurements and overwrite the measurement file.

Question: If the measurement file is complete and matches the movie duration, should I even bother measuring, anymore? Or should I disable measurements and simply rely on the measurement file instead? It would save a bit of CPU and GPU performance. (But we'd also lose the histograms, of course.)



http://madshi.net/madVRhdrMeasure16.zip

- madMeasureHDR.exe should now work even if you set madVR to HDR passthrough.
- also it should hopefully now work properly with copyback and D3D11 native.



http://madshi.net/madVRhdrMeasure15.zip

Now with a command line utility ("madMeasureHDR.exe") to pre-parse a full movie file. The utility must be started from within the madVR folder and it requires 32bit LAV Splitter Source + LAV Video Decoder to be installed.



http://madshi.net/madVRhdrMeasure14.zip

It now collects and then stores (to disk) all measurements, which means any scene that you already played in the past, will be perfectly optimized the 2nd time you play it...



http://madshi.net/madVRhdrMeasure13.zip

I think I prefer blowing out highlights for 1-2 frames over visible (even if faint) brightness jumps. Can we try to find the fastest brightness reaction time setting which does not cause any visible brightness jumps? For that purpose I've uploaded build 13 here, with added 0.015 and 0.020 options.

Your argument for the "delay" setting does make sense. However, please also take into account that the peak measurements often jitter around quite a bit. So they may appear to go up for a short time, then they go down again for a short time, then up, then down. Without a delay, the tone mapping "target" will change all the time between higher and lower values, which may cause the image to appear slightly unstable. The delay helps stabilizing the overall image. I guess we can't use the delay if the image gets brighter, though, because that will cause too much problems with blown out highlights. But I think if the image gets darker, we should take our time to adjust, to make the image overall more stable.



http://madshi.net/madVRhdrMeasure12.zip

It just adds more choices for the brightness and darkness delays. @Neo-XP, maybe one of the new 0.25, 0.10 or 0.05 brightness reaction options works for Harry Potter without causing brightness jumps in that scene, or elsewhere?
And how slow would the brightness reaction time have to be to hide the Predator problem?
(As mentioned before, I think we should keep the darkness delay + slow reaction time, unless we can find scenes where it hurts.)



http://madshi.net/madVRhdrMeasure11.zip

So let's leave saturation tweaking behind us. But maybe Neo-XP and Fer15 could just do a very quick check to test if the new test build works as expected? It's supposed to do "100% scaled to 10,000nits" if you disable measurements, and "65% scaled to measured peak + 250nits" otherwise.

The new build has 4 options:
1) "brightness delay". This option defines how long madVR waits, when measurements gets higher/brighter, before madVR starts adjusting to the new measurements.
2) "brightness reaction time". This option defines how long madVR takes to smoothly increase the tone mapping "target" to the new measurements.
3) "darkness delay". Same as "brightness delay", but in case measurements get darker.
4) "darkness reaction time". Same as "brightness reaction time", but in case measurements get darker.

Basically during the "delay" phase, madVR doesn't modify tone mapping at all yet. Then during the "brightness reaction time", madVR slowly adjusts to the new measurements.

So now the big question is what the optimal values for these options are? I think the "brightness delay/reaction time" is probably a lot more important, because if that reacts too slowly, highlight detail will be clipped off. Of course "darkness delay/reaction time" is not unimportant, either. But if it adjusts slowly, there shouldn't be any image detail lost, the image will just look a bit darker/duller than necessary for a little bit.

You could try setting the brightness option to "no delay + immediately" and see if it works for you? It should improve some scenes. But it might also result in sudden brightness jumps in other situations/scenes, I'm not sure. So it might be safer to at least use a small "reaction time" (e.g. 0.5 seconds), while it is probably safe not to use any delay.

For the "darkness" options, I think probably higher/slower is generally better, to avoid unnecessary image pumping. But you can test what works well for you.



http://madshi.net/madVRhdrMeasure10.zip

1) Potential fix for the black & white image reported by chros73.
2) Scene change now when luminance histogram changes more than 10%, hue is ignored.
3) Saturation boost 2 gone (will stay the same as it was).
4) "Desat control" re-added, with "scaled to measured peak".
5) Desat control "limit" option added.

So the big question now is: Does desaturation "scaled to measured peak" work well now, thanks to scene detection? Or does it still produce artifacts? Also, of course, which is the best value to choose for "scaled to measured peak", and for the "limit" option? The limit option often has no effect, but sometimes it does, e.g. with the 1st Murder on the Orient Express scene, it has a quite noticable effect.



http://madshi.net/madVRhdrMeasure9.zip (fixed flickering issue)
http://madshi.net/madVRhdrMeasure8.zip

1) Fixed a potential cause for flickering.
2) Sped up reaction time to higher luminance peak measurements (because I didn't like the way the green spear scene looked with Measure7).



http://madshi.net/madVRhdrMeasure7.zip

Many thanks to fhoech @ DisplayCAL, who once more came around with a nice new formula. This time for adjusting the BT.2390 tone mapping curve to different measurement and target nits situations. Basically the new formula allowed me to get rid of the smooth blend between clipping and BT.2390. I can now immediately switch to clipping, if the measured nits is below the target, which gives us a bit of extra pop.

Also, I've managed to reduce the measurement performance cost, and further increased the "pop" in some situations.

Here's a little image comparison to wet your appetite (runtime ca 0:46:15), using 130nits target peak nits (to match the SDR Blu-Ray):

These 2 frames are the first frames of a new "scene". The first frame is rendered with simple clipping by the new test build, because the measured nits was below the target peak nits. The 2nd scene had a little bit of BT.2390 tone mapping applied, because the measured nits was a bit higher than the target peak nits.



http://madshi.net/madVRhdrMeasure6.zip (fixed the "measured" and "target" peak values not changing)
http://madshi.net/madVRhdrMeasure5.zip

- removed rolling average algo
- added luminance and hue histograms to OSD
- added new algo to adjust to changing peak measurements

The settings dialog still has the rolling average dropdown box, but it's useless in this build.

Please test this build with your favorite HDR stress test scenes. Key things to look at is if you can see any problems with scene changes, fade ins, or other difficult scenes where the measured peak luminance of the frames changes greatly.

FYI, the new algo reacts quite slowly to changes in measured luminance. However, it reacts immediately, without any delay, if the luminance and hue histograms add up to a 20% change (or more) from one frame to the next. These situations are usually scene changes, but they can also be heavy action scenes. So it's possible madVR will mis-detect heavy action scenes as scene changes. However, the only negative consequence is that madVR will then immediately react to the new measured peak luminance. Which is probably not something anybody would notice in a heavy action scene, if large parts of the image are changing, anyway. So I think it should work fine. Maybe you can check if the 20% value is good? Maybe I should lower or increase it a bit? (You will have to frame step through scene changes or action scenes to see the histogram percentage changes.)



http://madshi.net/madVRhdrMeasure4.zip

This time I re-implemented auto switching to "clipping" (instead of BT.2390). It works like this:
rolling average: 150nits; target peak nits: 200nits -> clipping
rolling average: 160nits; target peak nits: 200nits -> 80% clipping / 20% BT.2390
rolling average: 200nits; target peak nits: 200nits -> BT.2390

So basically the rolling average must measure 50nits below the target peak nits to fully switch to clipping.



http://madshi.net/madVRhdrMeasure3.zip

Still no scene detection. Here are the changes:
1) I'm now rounding up measurements to 100nits, which seems to help avoiding some artifacts.
2) There's a new option which lets you choose the rolling average reaction time.

Please let me know which reaction time works best for you. If you make it too fast, you'll get flickering with some content. The scene from Murder on the Orient Express is a *great* scene to test for flickering. If you turn the rolling average off, this scene flickers like crazy. FWIW, all previous builds used a hard coded reaction time of 3 seconds.



http://madshi.net/madVRhdrMeasure2.zip (fixed both 32bit and 64bit recompiled)
http://madshi.net/madVRhdrMeasure1.zip

1) If you activate "output video in HDR format", madVR now sends MaxCLL = target peak nits to the display. Maybe this will turn off tone mapping in good TVs?

2) I had the measurement feature dumbed down in such a way that all measurements were rounded up to 600 nits. Meaning, if a frame was measured as e.g. 150 nits, madVR actually pretended it was measured as 600 nits (the OSD showed the true measurement, though). I did this to reduce the danger of pumping and flickering artifacts. However, obviously this limited the positive benefits of the whole measurement logic, as well. So this new test build no longer rounds up the measurements. Practically, this means that the loss of highlight detail in content like GoT and Murder on the Orient Express (all the content which looked better when using "clipping" instead of "BT.3290") should mostly be gone now.

Please look out for any kind of artifacts (brightness pumping, flickering, whatever) which might be caused by the measurement functionality. If you find such problems, please report them here. I have *not* implemented scene change detection yet, so brightness pumping artifacts may occur at scene changes. I'm not sure if it's worth reporting those. However, I hope within each scene no artifacts occur? If you find artifacts within a scene, please let me know!

(FWIW, from the view point of video rendering, a "scene change" should be defined as a switch from one camera view to a completely different camera view. It could still be the same scene, from an movie script point of view. But that's not something a video renderer can detect. So if the video changes from one camera to a completely different camera, I would consider that a "scene change".)



http://madshi.net/madVRhdrSat5.zip (fixed formula for negative percentages)
http://madshi.net/madVRhdrSat4.zip

This build is based on the new v0.92.17, so it also has the "old" saturation boost algo hard coded to 35% now. I've selected 35% because the majority of users voted for 40%, while some users preferred 20%, and Soulnight probably preferred something higher than 40%. So the "weighted average" of feedback felt like 35% to me.

I've decided to put the "scale to static metadata" and "scale to measured peak" functionality on ice for now, because test results for "scale to static metadata" weren't enthusiastic, and "scale to measured peak" suffers from artifacts during scene changes. Maybe we can revisit "scale to measured peak" later, after I added stuff like scene change detection etc to the whole measurement functionality.

That leaves only one thing for us to do: The desaturation control didn't only offer different "scale to" variants, but also different desaturation percentages. So although we're now back to "scaled to 10,000nits" (same as v0.92.16), we can still try different saturation percentages. To make things easier to understand, I've renamed "desaturation control" to "saturation boost 2" now. And you can choose in a range from -50% up to +50%. A value of 0% is identical to what v0.92.16 and v0.92.17 do. I would not recommend going below -25%, because then the green spear sample shows a lot of banding artifacts. At -25% it still appears to be fine, though. Based on previous feedback, I suspect Neo-XP might like small negative numbers. Soulnight might like large positive numbers. Question is if we can find a compromise everybody can live with?



http://madshi.net/madVRhdrSat3.zip

- New "saturation vs luminance" related option

I've modified the "saturation boost" option selection from none/medium/high (0%, 50%, 100%) to now 0%, 20%, 40%, 60%. I think I would prefer not to go higher than 60%. I actually prefer 40%, I think. But I'll leave the final decision up to a majority vote. Of course I can do any funny percentage value you guys would favor, e.g. 41.843%, if need be.

The new option is called "desaturation control". Allow me to explain how these two saturation related options work, on a technical level:

1)
madVR applies some desaturation for every pixel which is compressed by tone mapping. This is necessary because if you reduce brightness of a pixel, you also need to reduce saturation a bit, otherwise the pixel will look/feel oversaturated/overcooked. However, the exact formula for how much desaturation we want to apply is not specified anywhere, so it's up to us to fine tune it. Anyway. This desaturation which is applied to *every* tone mapped pixel is affected by the new madVR option "desaturation control". v0.92.16 applies what I would call 100% desaturation, scaled to a peak of always 10,000nits.

Now the "desaturation control" option in madVR allows you to reduce the amount of desaturation in 10% steps from 100% down to 0%. Furthermore, you can choose how the desaturation is scaled: Should it always aim for 10,000nits (as v0.92.16 does)? Or should it aim for the metadata video peak? Or should it aim for the measured peak of each separate frame? I think ideally aiming for the peak of each separate frame might be a good thing. But does it work well?

So to sum it up in short: v0.92.16 currently always uses the same desaturation formula, regardless of the video peak. Maybe we can optimize that?

2)
After the above explained tone mapping + desaturation has been applied, there's another step which checks for pixels which are now still "out of gamut" (too bright and too saturated to fit into the display gamut). For these pixels, madVR has to decide how much luminance and how much saturation to reduce. This is what the "saturation boost" option is for.

So basically the "saturation boost" option only applies to pixels which (after tone mapping + desaturation) are out of gamut. As a result, the "saturation boost" option usually does not affect skin tones etc because those are rarely out of gamut. However, the "desaturation control" affects all pixels which are tone mapped, so skin tones could be affected, as well. Which means, fine tuning the "desaturation control" is kind of dangerous: We need to be careful not to overcook skin tones!
-------
If I may suggest: I'd recommend picking a "saturation boost" value first, and then stick to that. Afterwards try to find a good "desaturation control" setting. Ideally it would be great if we could scale this to the measured video peak. But you will need to test that with many different demos and movies to double check that the scaling to the measured video peak works well. Otherwise we can always stick to what v0.92.16 does, namely always scaling to 10,000nits.

Once you've decided on the best "desaturation control" setting, you could go back and re-evaluate if the "saturation boost" value you selected in the beginning is still the best option to go along with your preferred "desaturation control" setting. But I would strongly recommend that you don't modify both "desaturation control" and "saturation boost" at the same time during your testing, otherwise you'll get confused by the countless option combinations. So pick a "saturation boost" value you like (ideally not 0%, because that's unlikely the value we'll end up using) and then stick to that.



http://madshi.net/madVRhdrSat2.zip (improved "medium" setting)
http://madshi.net/madVRhdrSat1.zip

There's a new option called "saturation boost" which slightly boosts saturation in some specific situations (not generally, though). Thanks to the "repair luminance channel" algo which is always active in recent builds, I can slightly up saturation without losing too much luminance detail. Here are 2 comparison shots comparing a saturation boost of "none" (same as v0.92.16) to "high":

Mad Max "none" vs Mad Max "high"
Sony Camp "none" vs Sony Camp "high"

In these images a "high" saturation boost looks clearly better to my eyes than "none". However, I've also seen at least one situation where the saturation boost might have looked slightly worse. So I'll need you to double check with your preferred content & test scenes to verify which "saturation boost" gives the best results for the majority of content. Please note that there will *not* be an option for this in v0.92.17. We have to come to an agreement which saturation boost to always apply.

(FYI, it's not an artificial saturation boost, it's just a different parameter set for the saturation vs luminance reduction formula, but I thought the name "saturation boost" would be a more intuitive name, to help you quickly understand what the new test option does.)