madVR - high quality video renderer (GPU assisted)

[flossy_cake]

I'm finding the [blacklevel] tag to be quite useful. Had a couple of films now where the colourist decided to sit the whole movie on a "black pedestal" in what I suspect was a misguided attempt at increasing shadow detail.

A bit confused why Madshi didn't include this important control in the MadVR settings GUI, but at least you can bind a hotkey to it, eg. ctrl+shift+up/down arrows to preview on a low APL scene, then once you've got it dialed in tag the file

eg. for Korean Bluray of Snowpiercer I'm using [blacklevel=-8]. Although it doesn't work perfectly for this film as there are some early scenes which don't have the black pedestal and will suffer crush as a result. Still, the vast majority of the film is pedestaled so I feel like it's an overall improvement. Although I still worry if I'm meddling with the artistic intent here. The US Bluray of it has less pedestal so they obviously picked up on it in mastering and tried to correct it. Overall I get the impression the shadow detail was botched at the camera level so there is no "perfect" presentation of this film (35mm).

US Bluray (https://i3.lensdump.com/i/1QTH7q.png)
Korean Bluray (https://i.lensdump.com/i/1QTlUA.png)

[SirMaster]

by reading the issue and reproduce it.
saying there is no issue without even testing is just insulting.

We do test it....

He uses it to watch movies tone-mapped.

When I set it up I tested to make sure it was working as it should.

There were no problems for his normal use case and setup.

[el Filou]

I'm finding the [blacklevel] tag to be quite useful. [...] A bit confused why Madshi didn't include this important control in the MadVR settings GUIIt's in the settings under "color & gamma": "brightness" is the black level. Edit: for some reason, those settings don't work when doing GPU deinterlacing. No idea if it's a bug or some other weird GPU driver behaviour, black level is best set on the display itself anyway.Although I still worry if I'm meddling with the artistic intent here.
US Bluray (https://i3.lensdump.com/i/1QTH7q.png)
Korean Bluray (https://i.lensdump.com/i/1QTlUA.png)If you're worried, maybe it's best not to do anything? I know I'd rather watch a whole movie with slightly raised black than risking having crushed shadow detail in some scenes.
There are films where the raised black level is artistic intent, e.g. Buried (2010). On HD it's easy to spot if the error was in authoring of the media as you can see it on the black bars (even 1.85:1 movies have thin black bars normally). If the error was in mastering there is no way to know.For completeness here is somewhat of a torture test for deinterlacing 1080i. Some of you may have seen this file already as it's quite old. [...]Just for technical precision, this particular sample is a test of inverse telecine/reverse pulldown/film cadence detection/<insert synonym here>. "Deinterlacing" suggests producing progressive output from actually interlaced source, which isn't the case with this sample, and actually implies harder processing than just detecting "film frame to fields" cadence. We still call something that can do both a deinterlacer, but in this case it's a bit of a misnomer.
My old Radeon is incapable of detecting the cadence in that sample, probably because it's voluntarily badly authored as you said (ftr I can count on the fingers of one hand the number of PAL media where I needed to do more than just set it to weave in order to get back the original film frames, and I watch a *lot* of it :)).
The Cheese Slices tests were pretty bad overall as they're not very realistic. If my ivtc or deinterlacer works OK on all real content I don't care much about a synthetic torture test (the F1 sample you linked to is a more realistic one for example).

[flossy_cake]

It's in the settings under "color & gamma": "brightness" is the black level.

There are separate brightness and black level controls

https://i.ibb.co/9t5sB7s/mvrs.png

The black level one seems to be correctly labeled as it appears to function the same as Brightness control does on TV's. Looking at test patterns it seems MadVR's brightness control is perhaps gamma as it doesn't seem to raise the black floor or clip white?

If you're worried, maybe it's best not to do anything?

Yeah I really don't want to meddle with artistic intent, it's just that the US Bluray of it has the pedestal correction so that kind of suggests something is not quite right that they identified and corrected for the US release. If both US and Korean versions were the same then I probably wouldn't touch it. But a lot of the scenes on Korean version look quite washed out and ugly imo. As in pulling me out of suspension of disbelief and grabbing my attention "oh wow that looks bad". Probably on an OLED the blacks would be so much darker so the pedestal would be a lot lower too. Weirdly the TV broadcast version of it has no pedestal and looks a bit crushed.

Then I have a sitcom where for some reason a handful of episodes are on a black pedestal and I know for sure they look out of place and whoever did the mastering must have had their BVM set up wrong or too much ambient light to notice it.

[el Filou]

There are separate brightness and black level controlsYes, my bad.
From madshi's post for v0.85.2:There are now (a) per-display color controls available in the madVR "device manager", which allows you to maybe optimize display setup/calibration. Then there are (b) "source" color controls available which you can only modify by assigning keyboard shortcuts to them. These "source" color control settings are not stored, so they reset themselves to neutral values when you close the media player or load a new video. You can change these source color controls to correct badly encoded videos without having to worry about resetting the color controls afterwards again.
[...]
(2) The "brightness" and "contrast" color controls now do not change the black and white levels, anymore. Instead they modify the look of the image to appear brighter/darker or more/less contrasty, while still keeping peak black and white identical. If you want to modify black and white output levels, you can now use the new custom output levels option in the madVR device manager. Or you can fix bad movie encodings by using the new "source black level" and "source white level" controls, which you can only modify by assigning a keyboard shortcut, and which auto reset themselves.So it makes sense that your source black level is not in the settings, as it's not supposed to be a global setting, only a per-movie tweak for badly authored/encoded material.

[huhn]

go to mpc-hc miscellaneous.
these settings are supposed to be used.

i'm not going to test it.
We do test it....

He uses it to watch movies tone-mapped.

When I set it up I tested to make sure it was working as it should.

There were no problems for his normal use case and setup.

so you tested a version of 22h2.
you would be the first one to report that.
if you didn't use that version you didn't read the reported bug and didn't test it.

[flossy_cake]

So it makes sense that your source black level is not in the settings, as it's not supposed to be a global setting, only a per-movie tweak for badly authored/encoded material.

Yeah I suppose. Although I had a cheap LED once that had black crush which could have been resolved globally with MadVRs black level control if it was in the settings GUI. I recall some of the early OLEDs had black crush issues too. These are edge cases, but so are displays without saturation & hue controls so maybe those don't need to be in settings GUI either.

"Deinterlacing" suggests producing progressive output from actually interlaced source

By "actually interlaced source" you mean 1:1 cadence. But interlaced video comes in lots of cadences, and Madshi puts ivtc under deinterlacing category in the GUI and tag name [deint]. Although I saw Madshi and blaubart arguing quite fiercely about this in cheese slices thread so yeah there's gonna be some disagreement. Like I said to huhn, I don't really care what words are used as they're just pointers to ideas. Everyone agrees what the ideas are. The transgender debate comes to mind — they are claiming to be women, but in this case the word woman is just a pointer to gender, not biological sex, so there isn't any actual disagreement. The disagreement is about the names of pointers, which needn't upset anyone.

[Siso]

Can somebody help me about hdr to sdr settings, with the default settings+dynamic target nits - on bright scenes the picture is getting dark, without dynamic target nits it is fine. I'll attach some pics. I compared it to the blu-ray and it seems it macthes best with dynamic target nits unchecked.
https://thumbs2.imgbox.com/a5/dc/fCv5dpIr_t.png (https://imgbox.com/fCv5dpIr) https://thumbs2.imgbox.com/fe/c3/O40NMX1l_t.png (https://imgbox.com/O40NMX1l) https://thumbs2.imgbox.com/f5/96/E7o6Xjkd_t.png (https://imgbox.com/E7o6Xjkd)
Here are my settings https://thumbs2.imgbox.com/99/90/Fj9OMgo1_t.png (https://imgbox.com/Fj9OMgo1)

[flossy_cake]

Can somebody help me about hdr to sdr settings, with the default settings+dynamic target nits - on bright scenes the picture is getting dark, without dynamic target nits it is fine.

So you are trying to take a HDR version of the film and visually match it to the SDR Bluray version?

imo this is going to be problematic because you have no way of knowing what the colourists of the SDR Bluray did on a per-scene basis compared to the HDR version. There could be many scenes where they adjusted it by hand to suit SDR and there would be no single conversion setting from HDR to SDR that reproduces that look on all scenes. You would have to look at many many scenes and try to pick a "mid point" or something that best represents the Bluray version. It's going to be very messy, time consuming and stressful, and by the time you're finished you've probably watched all the scenes and don't want to watch the movie again :)

Or maybe you get lucky and the HDR version only uses the bright tones for highlights and the rest is pretty much in line with the Bluray SDR so you only have to choose how much highlight rolloff you want.

The point is, it's an unknown and you're always guessing. Just give up on the idea of some magical settings. You would eventually encounter some other film which needs different settings anyway and then you'd need per-movie profiles.

I can see you have set "real display peak nits" to 100. This seems a little low and will give a much brighter midtones as it has to compress the whole dynamic range into a smaller space. It's like using a very low gamma and will give less contrasty image. Madshi chose 200 nits as the default value and this value seems to just work well on most SDR TV and I don't really understand why cause mine is only 140 nits and 200 nits looks like the "correct" setting to my eyes. Maybe try 200 nits and untick all the autism controls to see if it's a close match to the Bluray?

[Siso]

My monitor is calibrated for 100 nits, if I choose 200 nits the movies look too dim. I don't like dim movies at all.

[Alexkral]

I'd try these from some posts before:

https://forum.doom9.org/showthread.php?p=1971114#post1971114
https://forum.doom9.org/showthread.php?p=1971137#post1971137

I don't know how the algorithm work in this case, but it seems to use a better roll-off.

[flossy_cake]

My monitor is calibrated for 100 nits, if I choose 200 nits the movies look too dim. I don't like dim movies at all.

Fair enough.

btw if you use the regular non-beta version of MadVR (the one without the autism controls) and select "tone mapping curve BT.2390" you'll get what ITU thinks is the best way to convert HDR to SDR for your given 100 nits (see "5.4.1 Mapping to display with limited brightness range (https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2390-8-2020-PDF-E.pdf#%5B%7B%22num%22%3A79%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C217%2C0%5D)").

[Alexkral]

The official madVR versions don't use the ITU roll-off. They use an alternative roll-off implemented by DisplayCAL, which better avoids the loss of details in the highlights, to the detriment of the maximum luminance.

[el Filou]

@flossy_cake What do you mean by "the autism controls" expression you keep using?

[flossy_cake]

@flossy_cake What do you mean by "the autism controls" expression you keep using?

Circled in red

https://i.ibb.co/VYLNKkZ/Fj9-OMgo1-o.png

Normal, sensible version:

https://i.ibb.co/4fJNstV/1.png


The official madVR versions don't use the ITU roll-off. They use an alternative roll-off implemented by DisplayCAL, which better avoids the loss of details in the highlights, to the detriment of the maximum luminance.

I have no idea if that's true or not -- got a source? Seems strange he would label it BT.2390 (ITU) if it's using some other DisplayCAL curve AND he already gives us "highlight recovery strength" as an option to tweak.

[quietvoid]

I have no idea if that's true or not -- got a source? Seems strange he would label it BT.2390 (ITU) if it's using some other DisplayCAL curve AND he already gives us "highlight recovery strength" as an option to tweak.

https://github.com/eoyilmaz/displaycal-py3/blob/main/DisplayCAL/colormath.py#L3425
madVR does use a different roll-off.

[flossy_cake]

https://github.com/eoyilmaz/displaycal-py3/blob/main/DisplayCAL/colormath.py#L3425
madVR does use a different roll-off.

Looks like someone's fork of DisplayCAL. Did Madshi say he uses this code in his pixel shader?

[quietvoid]

Looks like someone's fork of DisplayCAL. Did Madshi say he uses this code?

The math is the same as the original.
I just know the roll-off implemented in madVR is different from ITU's, I don't know if madshi specifically said that's what he uses.

[Alexkral]

I made an hlsl shader with the DisplayCAL BT.2390 implementation (which offers both roll off options) quite a while ago, and in fact that's what I've been using ever since in MPC-HC. I did a bunch of comparisons then, and the results using the alternative roll off were virtually identical to the madVR implementation. You can check this by creating a DisplayCAL LUT for HDR to SDR. With the "Adjust roll off" checkbox ticked, it uses the ITU roll off, and unticked, the alternative roll off.

For my use case (400 nits TV), I much prefer the ITU roll off, and it's the one I always use, but I don't know if I would say the same with other screens with different dynamic ranges.

The highlight recovery feature simply sharpens highlight details, it has nothing to do with BT.2390.

As a side note, I've read a lot of madhi's posts saying that the important thing for him was to respect the scientific approach, but in the end, at least for some things, he does what "he thinks" is best. So for detail recovery, there's probably nothing better (apart from the Envy), but if that's not that important to you, better look elsewhere.

[Siso]

I'd try these from some posts before:

https://forum.doom9.org/showthread.php?p=1971114#post1971114
https://forum.doom9.org/showthread.php?p=1971137#post1971137

I don't know how the algorithm work in this case, but it seems to use a better roll-off.

Very good posts, thank you.

[Balling]

My monitor is calibrated for 100 nits, if I choose 200 nits the movies look too dim. I don't like dim movies at all.

But HDR media SDR level is 203 nits, not 100.

[huhn]

and what has this todo with tone mapping?

[flossy_cake]

But HDR media SDR level is 203 nits, not 100.

What do you mean by this exactly -- something to do with Hybid Log Gamma?

edit: ok saw this


The PQ based ST2084 HDR specification originally defined expected reference white (nominal diffuse white) as being around 100 nits, which is basically the same as for SDR (Standard Dynamic Range) displays, as specified for mastering (grading) grade-1 applications. With PQ HDR, brightness above 100 nits was expected to be used for spectral highlight detail only. This meant that the Average Picture Level (APL) of a PQ HDR display would not be significantly different to a SDR display for most imagery.

However, subsequent evaluation of PQ based HDR imagery showed a better relative image was attained with a diffuse white around 200 nits. This has since been adopted by the ITU's BT.2408 specification (actually 203 nits), which is 58% of the full PQ signal (input) level.
https://www.lightillusion.com/what_is_hdr.html



2.1 HDR Reference White
The reference level, HDR Reference White, is defined in this Report as the nominal signal level
obtained from an HDR camera and a 100% reflectance white card resulting in a nominal luminance
of 203 cd/m2 on a PQ display or on an HLG display that has a nominal peak luminance capability of
1 000 cd/m2. That is the signal level that would result from a 100% Lambertian reflector placed at the
centre of interest within a scene under controlled lighting, commonly referred to as diffuse white1.
There may be brighter whites captured by the camera that are not at the centre of interest, and may
therefore be brighter than the HDR Reference White.
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.2408-4-2021-PDF-E.pdf#%5B%7B%22num%22%3A43%2C%22gen%22%3A0%7D%2C%7B%22name%22%3A%22XYZ%22%7D%2C54%2C743%2C0%5D



https://i.ibb.co/s5hQdqK/Untitled-2.png

[huhn]

again what has this todo with tone mapping in madVR.
for accurate results it needs your true nits.

[Alexkral]

for accurate results it needs your true nits.

Yes, but depending on several factors, you can get the white level to the value recommended by ITU by setting display peak nits to a lower value than the real one.

[huhn]

not in madVR you will get no value correct if you don't match the nit option with your correct nits.

if your display nits is accurate than the 203 nits will also be correct as long as it is over the knee point.

[Alexkral]

The point is that by setting accurate display nits, diffuse white will be at 100 nits, and...

However, subsequent evaluation of PQ based HDR imagery showed a better relative image was attained with a diffuse white around 200 nits.

Supposedly this has been changed on some masterings since then, but I'm not sure I've seen any.

EDIT: If anyone knows of any of these, please let me know.

[Sunspark]

If it helps someone, there is a way to set the display nits without changing the backlight setting. PWM displays usually need to run at 100% brightness to avoid PWM flickering, but one workable way you can lower the nits without introducing PWM flicker is to adjust the R G B levels in the monitor's custom preset downward evenly from 100% (e.g. 50%). It will look slightly different because the lcd crystals are rotated instead of being wide open, so you will need to do a new colour calibration for this preset.

[SirMaster]

If it helps someone, there is a way to set the display nits without changing the backlight setting. PWM displays usually need to run at 100% brightness to avoid PWM flickering, but one workable way you can lower the nits without introducing PWM flicker is to adjust the R G B levels in the monitor's custom preset downward evenly from 100% (e.g. 50%). It will look slightly different because the lcd crystals are rotated instead of being wide open, so you will need to do a new colour calibration for this preset.

You are losing contrast this way though.

[huhn]

The point is that by setting accurate display nits, diffuse white will be at 100 nits, and...



Supposedly this has been changed on some masterings since then, but I'm not sure I've seen any.

EDIT: If anyone knows of any of these, please let me know.

it will not be there it is different based on the number typed in if you set it to 10000 it is where every it was mastered because nothing is changed.
if you type the wrong number in "no" nit will be where it should be.
if you want to move the white diffuse to 203 try a dynamic target nits of 203 combined with the correct target peak nit.

[Alexkral]

It's actually even worse.

Assuming the roll off used in madVR, for any screen below 475 nits, if you set target peak nits to the true value, diffuse white begins to be compressed, i.e. the PQ value of 100 nits begins to be tonemapped below 100 nits. For any higher value, the 0 - 100 range remains untouched and should look the same as the SDR.

For example:

madVR target peak nits = 200
true target peak nits = 200
diffuse white (PQ = 100) tonemapped and viewed at 75.06 nits

madVR target peak nits = 700
true target peak nits = 700
diffuse white (PQ = 100) tonemapped and viewed at 100 nits

So with true target peak nits, diffuse white is always seen at 100 nits or below.

Dynamic target nits are as their name suggests, dynamic, so you can't fix them to any level. Also, the math behind all of that is unknown, and the very fact that there are two parameters for fixed and dynamic, is contradictory.

[Alexkral]

I've been reading a bit about all these "new" madVR settings that have nothing to do with BT.2390. These are my impressions so far:

- The math is never explained, so it's impossible to really know what's going on and what is the relation of these algos to the main tone mapping algo. It's a real mess.

- These are algos developed by collaborators of madshi, and mixed in some way with the main tone mapping algo, to the point that there will probably be very little left of the original BT.2390, and its behavior will be very different.

- When any of these developers are asked about the behavior of their algos, the answer is of the type "setting it higher, the image will be more dim, and lower, brighter, you have to set it to your taste".

So to use your own words, chances are that using the beta versions, "no" nit will be where it should be.

[huhn]

no it will be.
there is a knee point under which no nit is touched simple as that. if this can be higher depending on the scene doesn't change that. this only work when the peak nits are the same as the actual nits or everything will be compressed or decompressed.

[SirMaster]

Yeah, when you set a peak nit in madVR, even for the latest beta version, all pixels that are that nit or less are untouched. Only pixels that are brighter are tone-mapped.

And the modification algorithms to the tone-mapping are developed to make the image look as perceptually close to how it looks on a reference 1000 nit display. With variables to allow users to tune the image to their own taste.

[Alexkral]

This has been well known for a long time, and a matter of simple logic. If you have a video that peaks at 1000 nits, and you set target peak nits = 100, that means that 1000 nits are tonemapped to 100 nits. So where are 100 nits tonemapped? at 100 nits? That's clipping, not tonemapping.

I even remember reading posts from madhi, and Florian from DisplayCAL, giving a slightly different value than the 475 nits that I have indicated about the limit to avoid white level compression.

I'm always talking about BT.2390, this may be different in the beta versions, but don't expect a magical white level preservation, because the logic is the same.

[flossy_cake]

Does anyone have a HDR 1000nits test pattern with grey stepped ramp with each step labelled with nits value? I'd like to take a screenshot of it with MadVR set to 200nits BT.2390 rolloff and inspect the RGB values in photoshop to see what I'm actually getting.

[Sunspark]

You are losing contrast this way though.

Is there that much of a difference though? If I turn down the backlight, contrast is also lost no?

[SirMaster]

Is there that much of a difference though? If I turn down the backlight, contrast is also lost no?

No, turning down the backlight reduces both black and white equally. So contrast remains the same.

Reducing the gain controls lowers white only while leaving black the same.

That's how an LCD panel works. Black is determined by the pixels blocking as much light as they possibly can, and how much of the backlight comes through. If you are not lowering the backlight, the black cannot be darker.

But lowering the gain makes white and everything else lower, so there is now a smaller dynamic range between black and white. Everything is scaled between the black and white, so all content is going to have a smaller dynamic range.

The amount of contrast reduction is equal to how much you lower white by with the gain control.

[SirMaster]

This has been well known for a long time, and a matter of simple logic. If you have a video that peaks at 1000 nits, and you set target peak nits = 100, that means that 1000 nits are tonemapped to 100 nits. So where are 100 nits tonemapped? at 100 nits? That's clipping, not tonemapping.


Yeah, you are right.

I guess what I meant is that in a dynamic tone-mapping system like madVR, if a frame comes that fits entirely within the defined peak nits, then the frame is kept as-is.

Even for 1000 nit HDR, there are plenty of scenes and frames that are all within 100 nits, and so could be displayed natively without tone-mapping on many SDR range displays.

[huhn]

This has been well known for a long time, and a matter of simple logic. If you have a video that peaks at 1000 nits, and you set target peak nits = 100, that means that 1000 nits are tonemapped to 100 nits. So where are 100 nits tonemapped? at 100 nits? That's clipping, not tonemapping.

I even remember reading posts from madhi, and Florian from DisplayCAL, giving a slightly different value than the 475 nits that I have indicated about the limit to avoid white level compression.

I'm always talking about BT.2390, this may be different in the beta versions, but don't expect a magical white level preservation, because the logic is the same.
while accurate it's dated now.
back in the days diosplaycal didn't like it when you typed in true but accurate nit number like 80 for a PJ it gave a warning by calculating the knee point and telling that it is to low and important image part are compressed.

the problem with typing in a wrong number like 475 is that it may stop compressing whites but it is still compressing them globally if you don't have 475. that's where dynamic nits come in you can not set the accurate nit making is possible to get white level compression out of the way and you get accurate results for everything in that range too.

if you want accurate results you need to type the real number in no matter what.

[Alexkral]

I guess what I meant is that in a dynamic tone-mapping system like madVR, if a frame comes that fits entirely within the defined peak nits, then the frame is kept as-is.

That's what dynamic target nits does. The only problem with that is the fluctuation that occurs with the white level. I'm sure madVR is able to do it without it being very noticeable, and in the end what people want is that all the images are appealing, but still you're messing with the director's intent, because some scenes are just intended to be seen darker than others.

the problem with typing in a wrong number like 475 is that it may stop compressing whites but it is still compressing them globally if you don't have 475.

Of course, I was talking about setting the real value, there is no point in setting it to 475 nits if your screen peaks at 200 nits.

if you want accurate results you need to type the real number in no matter what.

Well for me the accurate result for diffuse white in HDR is 203 nits as recommended by ITU, and the only way to achieve it is by setting a value for target peak nits lower than the real one. Dynamic target nits could help with this, if it weren't for the problems I just pointed out and because the only way to set them is by pure intuition.

[huhn]

when you are over it why would you even care about this problem.

the spec talks about mastering to 203 as long as you have a peak nit that does not compress that point there is nothing going to happen to it only high lights are compressed.
but if you set a to low number then all values will be to bright including 203 and below.

[Alexkral]

This is about mastering, and it's a bit dated, but it sums up the problem pretty well. Unfortunately, the video is no longer available.

https://www.liftgammagain.com/forum/index.php?threads/grading-a-bright-sunny-day-in-hdr.10305/

[flossy_cake]

Controversial opinion but I feel like the creators of HDR had great intentions and ambition, but the implementation has ended up in a place where I feel like it's become so convoluted and complex with so many problematic scenarios, each needing their own custom fixes and metadata (some of them implemented in the mastering process, others implemented at the display) that it's starting to feel like a failed experiment like 3D. The MadVR beta tonemapping screen exemplifies this perfectly. Anyone who looks at that screen and thinks it's an acceptable state of affairs has completely missed the purpose of standardistion.

[huhn]

like you?
they are not meant to stay there are there to test nothing else.
they will be gone soon.

[flossy_cake]

they are not meant to stay there are there to test nothing else.
they will be gone soon.

I've seen a number of posts now where people are asking what MadVR tonemapping settings to use, with screenshot of those controls, as if to imply the goal is to somehow twiddle the knobs in just the right way to make it look good on their TV.

I don't criticise Madshi at all -- it's a beta version so it makes sense that experimental controls could exist in a beta version.

[brazen1]

HDR an ambitious failed convoluted experiment like 3D? LoL! My controversial opined reply: Sorry. HDR was and is a step forward from what 3D was - coming from a former 3D embracer.

The only failure is that all High Dynamic Range video causes problematic scenarios requiring custom fixes (if you can call it that) for some displays (projectors mainly) incapable of utilizing that ambitious failed convoluted experiment as intended.

So you compress high nit HDR mapped WAAAAY down to something in the realm of a flashlight trying to illuminate screens the size of barns losing most high definition of blacks, whites, everything in-between, contrast, clarity, resolution, etc. and point the finger at non-standard HDR content mastering? Not to mention specular highlights dubbed light cannon ammo the enemy because flashlights are too dim to produce the high nits required so you dim them and call it perfect? Ha!

Let's not fault HDR content for the shortcomings of some specific hardware. The way forward is not going back to SDR to accommodate old and new expensive equipment that doesn't cut the mustard anymore. Massaging HDR back to the future we know as SDR won't last forever. It will succumb as did 3D to the last hold-out stragglers. All you're doing is buying time while complaining about the latest mainstream state-of-the-art tech hard to massage into something watchable. Perhaps think about leaning towards large modern panels. They'll be barn sized soon enough. All your problems will be solved... all of them.

That said, it's great madVR exists to enhance older low mastered video that hasn't been AI upscaled mastered yet (I rely on madVR real-time for this and am VERY appreciative) as well as providing an avenue to partially accommodate insufficient displays rendering HDR video by altering and tone mapping it first, for those that require it, although it's time sensitive feedback software which is where ENVY finalizes the niche. Top Gun Maverick 11-1-2022 4k Blu-Ray. Be there or be square...

[SirMaster]

There's nothing wrong with the HDR format. It's just that it's made for 10,000 nits and BT.2020 gamut.

So it's natural for people to want to play it back on displays that cannot reach those specs and so the image needs to be compromised in various ways in order to have it look good.

But it will never look "correct" unless the display can reach the actual peak nits and peak color gamut saturations that the video uses.

[flossy_cake]

HDR an ambitious failed convoluted experiment like 3D? LoL!

I only said it's "starting to feel" like that, which is different than actually being a failure.

[Alexkral]

3D is (almost) dead simply because of marketing, and because companies have decided to invest exclusively in HDR development, but it still looks absolutely stunning on my LG. I'm sure that if glasses were not needed, right now it would be the standard of reference.

There's no way that SDR will succumb to HDR in the next few hundred years, simply because it is the format in which the vast majority of available content is and continues to be made.

As for HDR, really the only problem I see is this white level nonsense to make it compatible with SDR, and of course, not everyone has the necessary equipment. If not for that, I would rely on passthrough and forget about tone mapping. It seems pointless to me to want to see it on a projector anyway, but it's also true that most 4K content is also HDR, so if you want one, you need the other.