madVR - high quality video renderer (GPU assisted)

[Sunspark]

I don't have a HDR screen, so all I can do is just ask questions.. for example, I've seen it said that you need a 1000 nit display to get good results.. do you get blinded when it's a snow scene or desert or something with light tones? Another is, photographs.. I can see photos taken in HDR expose more detail, but they don't look natural. I don't see the world via exposing everything in sight differently then overlaying. So, when it comes to video, do they have unnatural levels of detail?

[huhn]

why would you go blind from 1000 nits.
a full moon can reach a couple 1k nits.
a day light lit street is many k of nits.
HDR has just a higher difference between black and white that's it everything else can be done with SDR even that can be done with SDR but it is very stupid.

how can something have unnatural level of detail you are still using your eyes.

[ryrynz]

He means sharpness and contrast and I agree HDR can look pretty tacky. Dolby Vision looks more natural, not sure if that's how it's mastered or just how my TV presents it compared to HDR10. Don't let whatever gamma your screen is "meant" to be at rule your viewing enjoyment. Sometimes you got to fiddle with it to get it looking natural, always seems to be a bit of a problem on OLEDs.

[tp4tissue]

GoT: The Long Night was totally awesome in HDR... It's actually my go to for testing banding. But as for being watchable, it was absolutely amazing in HDR. It's actually a perfect example of why HDR is really needed in film and TV.

QB

They already reported that the color grading for that scene was a mistake.

It was not intentional, some one dropped the ball. :D

[huhn]

He means sharpness and contrast and I agree HDR can look pretty tacky. Dolby Vision looks more natural, not sure if that's how it's mastered or just how my TV presents it compared to HDR10. Don't let whatever gamma your screen is "meant" to be at rule your viewing enjoyment. Sometimes you got to fiddle with it to get it looking natural, always seems to be a bit of a problem on OLEDs.

of cause that's how it's mastered.
hdr or SDR are just a different target.

[tp4tissue]

I don't have a HDR screen, so all I can do is just ask questions.. for example, I've seen it said that you need a 1000 nit display to get good results.. do you get blinded when it's a snow scene or desert or something with light tones? Another is, photographs.. I can see photos taken in HDR expose more detail, but they don't look natural. I don't see the world via exposing everything in sight differently then overlaying. So, when it comes to video, do they have unnatural levels of detail?

The pipeline to your eye is entirely artificial. What you see is a creative human choice ontop, of, an approximation (image capture).

HDR at this point is only a slight increase in the dynamic range to render highlights and visual flair. It's like a speaker that can play a bit louder.

1000nits isn't very much. Even on an overcast/cloudy day, outdoor ground elements are well over 500 nits. The human iris and electrochemical receptors dynamically alter perceived light.

10,000 nits is where we achieve near reality. In an indoor room, you will never need more than that to express intent.

1000nits snow scenes are also only about 200-300 nits on OLED. So it's not nearly enough to represent real life. LCD light cannons that do 800nits full field are still the more accurate technology in the peak use-cases. :D

The reason I got an oled is because I realized HDR peak highlights are not used to great effect in the current crop of movie material. So absolute peak brightness is not as useful as off-axis uniformity.

My move away from LCDs is primarily driven by viewing distance. The big films are all coming in on 2.39:1 aspect ratio, a 77 inch is only really as big as a 58 inch in height when fitted. So really you're watching a wider 58 inch screen. That isn't very big. So you have to watch it pretty close around 6 feet.

The closeness to screen makes LCD suffer tramendously because the right eye is receiving a very different image from the left eye. You only have about 10 degrees of gamma / chroma stability on VA-LCD. Then there's the drift at the edges, which is just grey.

Sony's new bravia is aiming to change the status quo back towards LCDs, by combining light cannon + minileds + x-wide angle filter + VA. On previous x-wide LCDs, my opinion is that upclose viewing still has that shimmering 3d glasses look, and off axis contrast ratio still takes a dive.

I honestly still prefer TCL's brute force method. That 20,000 zone thing can't be beat, but it's not like I can afford it.

[tp4tissue]

of cause that's how it's mastered.
hdr or SDR are just a different target.

The problem with hdr is the same as in sdr really. We don't really know with any certainty the conditions it was mastered in.

If they had used a bias light, things could look really different.:eek:

[Drybonz]

I'm consistently getting presentation glitches, but not dropped frames, in the info display. Is it possible that these are actually caused by the info overlay being open in full screen? I've tried the different queue settings (1-3 etc) to try to eliminate this but can't seem to get playback without these glitches.

[Siso]

I'm consistently getting presentation glitches, but not dropped frames, in the info display. Is it possible that these are actually caused by the info overlay being open in full screen? I've tried the different queue settings (1-3 etc) to try to eliminate this but can't seem to get playback without these glitches.

Which OS, what card? What settings do you use?

[Drybonz]

Which OS, what card? What settings do you use?

Windows 11, 4060, i9, 32gb... but my main question was about the overlay. This happens whether I drop my settings down to the ultra low end or with maxed out settings.

[Emulgator]

I would try to up/downdate nVidia drivers, move to Studio drivers, etc.

[Drybonz]

I would try to up/downdate nVidia drivers, move to Studio drivers, etc.

I'm on the 552.22 drivers. I generally just download the new ones when they come out and almost never see anything about changes to video in the release notes. What are the most recommended driver versions?

*edit* Just switched to the studio drivers. No change.

*edit* I got it sorted. I had to increase the queues and advance frames a lot more than people are generally recommending. After that I can increase my settings and still don't have drops/glitches.

[bcec]

I have been using d3d11 (hardware encoding turned on) with lav and madvr on my 1080ti and things have been working. I recently swapped 1080ti for 3080ti and same configuration d3d11 + hardware decoding is now freezing after 5 or so min of playback. Switching to dxva2 copy back with hardware encoding doesn't freeze. Any ideas?

[huhn]

know issue don't use d3d11 native with madVR.

btw. that's decoding your GPU can also encode.

[bcec]

know issue don't use d3d11 native with madVR.

btw. that's decoding your GPU can also encode.

Thank you!

EDIT: follow up question: is there another mode of d3d11 I can use with madVR (i.e. is there a way to select native vs non-native)? Or should I only use dxva2? I need GPU hardware decoding since my cpu is very old

[Sunspark]

Use dxva2 copy-back yeah, it will not be worse picture quality than the d3d11 mode.

[Siso]

I'm on the 552.22 drivers. I generally just download the new ones when they come out and almost never see anything about changes to video in the release notes. What are the most recommended driver versions?

*edit* Just switched to the studio drivers. No change.

*edit* I got it sorted. I had to increase the queues and advance frames a lot more than people are generally recommending. After that I can increase my settings and still don't have drops/glitches.

Share your queues settings and frames in advance, it may help others.;)

[strumf666]

Thank you!

EDIT: follow up question: is there another mode of d3d11 I can use with madVR (i.e. is there a way to select native vs non-native)? Or should I only use dxva2? I need GPU hardware decoding since my cpu is very old
In lav filters you need to change the output device from "Automatic (Native)" and it should use d3d11 copy-back iirc.

[Drybonz]

Share your queues settings and frames in advance, it may help others.;)

32-16 for the queue and 8 for frames. That was the sweet spot for me, but I don't think there's any magic in those numbers. I think 1-3 is the number that has been suggested so many times (not just here) that we don't really consider using other settings. I had stayed within that 1-3 zone and couldn't solve my problem, so my main takeaway is don't be afraid to bump those up more if it's not working for you.

[huhn]

the low queue setting are to avoid unreported frame drop/repeats. 4 is the maximum nvidia supports these days.

[Siso]

On beta 112 I had to use 12 cpu, 8 gpu, frames in advance 3, to get stable playback.

[tp4tissue]

the low queue setting are to avoid unreported frame drop/repeats. 4 is the maximum nvidia supports these days.

How is the madvr hdr support on the newer nvidia cards huhn. On my latest AMDs it switches so fast, and doesn't black out the screen.

On my old 1060, it goes black, then pops back when nvhdr kicks up. :o

[huhn]

1-5 black frames close to instant but the issue it the TV on my old sony TV is was instant with no frame delay.
madVR often breaks something forcing me to restart the PC so you should ask user where it works.

mpv works flawless.

[Klaus1189]

What do I need for mpv to get HDR working?

Can you post your mpv config and list of additional stuff I need?
Do I need Vulkan?

[huhn]

vo=gpu-next
gpu-api=vulkan
target-colorspace-hint

the 3rd line is maybe all you need.
i gave up on mpv after i figured out that it can't do an YCbCr-> RGB conversation correctly and ignores interlaced flags because the flag could be wrong...

[Klaus1189]

Too Bad. What do you use now?

[huhn]

this is don't care about HDR.
if you care about HDR try mpcVR it at least places the chroma correctly unlike madVR but has nothing worth calling a really good chroma scaler and so on.

[Drybonz]

Do any of the new HDR settings on the test builds have a significant impact on performance to be aware of? Thanks for the help.

[kasper93]

figured out that it can't do an YCbCr-> RGB conversation correctly really? 🤯
ignores interlaced flags because the flag could be wrong... deinterlace=auto

[huhn]

and did you get it in as default?

and yes mpv is doing conversation wrong haasn could not find out why but he is looking.

try ire 30.

edit: i actually wanted to check the new release if it got fixed but i forgot that limited range is also broken making this a pain to check...
https://i.ibb.co/VNxxCGN/limited-range-bug.png

and because i'm a bitter idiot of man child :-)
mpv let's write and usely and objectively wrong meta data that is not supposed to be used according to the spec:
https://ibb.co/j3brRK9
mpv ladies and gentle man defiantly the same image. this is not the ycbcr RGB bug.

i do the conversation bug test later if you care i need to remember how to work around bug/limitations to do that easily.

[ashlar42]

They already reported that the color grading for that scene was a mistake.

It was not intentional, some one dropped the ball. :D
Don't think so... https://www.ign.com/articles/2019/06/20/got-the-long-night-director-reveals-why-the-battle-of-winterfell-was-so-dark

[oneonefive]

and did you get it in as default?

and yes mpv is doing conversation wrong haasn could not find out why but he is looking.

try ire 30.

edit: i actually wanted to check the new release if it got fixed but i forgot that limited range is also broken making this a pain to check...
https://i.ibb.co/VNxxCGN/limited-range-bug.png

and because i'm a bitter idiot of man child :-)
mpv let's write and usely and objectively wrong meta data that is not supposed to be used according to the spec:
https://ibb.co/j3brRK9
mpv ladies and gentle man defiantly the same image. this is not the ycbcr RGB bug.

i do the conversation bug test later if you care i need to remember how to work around bug/limitations to do that easily.

You were told many times over why mpv's behavior is actually correct. Quit speaking in bad faith and spreading misinformation.

[huhn]

yes yes misinformation what else.
that why GPU does it correctly... (it doesn't but is much better)

it's the windows photo app that got it wrong, the bt 709 spec and GPU does it wrong right?
and clipping btb and wtw when a pixel is scaled is also not an issue but showing it when no scaling is done is also correct.

[kasper93]

Try reporting one issue and don't mix unrelated topics. It will be a lot easier to follow up on that. Screenshots are broken. It depends what you expect of them, but depending on your target options you will get different result, need to configure correctly. It is quite low priority as it really doesn't affect playback, which is what you should care about. If you want raw screenshot of video, use ffmpeg.

[huhn]

the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...

like telling me with screenshot-tag-colorspace=no that it converts to sRGB it doesn't... the tone curve is untouched.

with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does.

BTW. any other calibrator in this thread that can "confirm" to me that BT 1886 is approximated 1.961?

[kasper93]

with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does. So you want rendered image dumped as-is to png without tagging or tagged as sRGB without conversion? Screenshot function is designed to produce tagged file which can be used to reproduce the image as it were intended to be viewed on different setups. It does not save image that is correct only on your display as some sort of "calibration tool", it is screenshot of video, not your display.

Imagine this simplified example:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with target-csp) -(load)> image-csp -(renderer)> target-csp-b

Note that video-csp and image-csp may not be the same. But they both will correctly be converted to target-csp to produce the same image. If target-csp-a == target-csp-b, it would be the same output. Note that this is simplified and the round-trip is not always perfect, but this is how it suppose to work. And of course need a image viewer to correctly converts image-csp to your target display.

What you seem to want is mistagged screenshot as sRGB to view the difference between target-csp-a rendering:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with sRGB) -(load)> sRGB -(renderer)> target-csp-b

Note that this is not valid way to do screenshot and if you want that, just use Print Screen key.

the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...

I have limited time to invent bugs and reports myself. If you want me to work on something, I need exact steps to reproduce invalid result and valid results, with command line, images... If the limited knowledge of mpv developers is the problem, try not to argue the details, just argue the results and if you proof that the result image is wrong it will be easier to deep dive to dissect the issue, even with limited knowledge about the basic calibration.

[huhn]

So you want rendered image dumped as-is to png without tagging or tagged as sRGB without conversion? Screenshot function is designed to produce tagged file which can be used to reproduce the image as it were intended to be viewed on different setups. It does not save image that is correct only on your display as some sort of "calibration tool", it is screenshot of video, not your display.

Imagine this simplified example:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with target-csp) -(load)> image-csp -(renderer)> target-csp-b

Note that video-csp and image-csp may not be the same. But they both will correctly be converted to target-csp to produce the same image. If target-csp-a == target-csp-b, it would be the same output. Note that this is simplified and the round-trip is not always perfect, but this is how it suppose to work. And of course need a image viewer to correctly converts image-csp to your target display.

What you seem to want is mistagged screenshot as sRGB to view the difference between target-csp-a rendering:

video-csp -(renderer)> target-csp-a -(save)> png (tagged with sRGB) -(load)> sRGB -(renderer)> target-csp-b

Note that this is not valid way to do screenshot and if you want that, just use Print Screen key.



I have limited time to invent bugs and reports myself. If you want me to work on something, I need exact steps to reproduce invalid result and valid results, with command line, images... If the limited knowledge of mpv developers is the problem, try not to argue the details, just argue the results and if you proof that the result image is wrong it will be easier to deep dive to dissect the issue, even with limited knowledge about the basic calibration.
don't waste your time on this.
actually in the example case the current gamma would be blank because you have no clue what it is.

--target-trc= is provided and you add that that's ok. you will get wrong results but mpv did nothing technically wrong.
but for bt 1886 mpv writes a total none sense number the bt 709 spec tells you is not used in production it is not an eotf and on top of that it writes the absolute correct advanced meta data that it is bt 1886 meaning it could be everything. but you also have to stop added bt 1886 if it is not the --target-trc= and no black is defined (i get to that later).

bt1886 is not 1.961 the only gamma curve it has is 2.4 and the rest is a mess between 1.0 and 2.4 at the same time. ignoring HDR SDR conversation... which is total mess. ok not really because if the black was not 0 then the output is not bt 1886 it is s specific curve of bt 1886 which need the black point to be reversible but that doesn't mean the image is bt 1886.

the next issue is windows only. Microsoft is sRGB it thinks every thing is sRGB and that is in theory changeable but not in practice yet.
if you let windows convert SDR to HDR it will think the SDR is sRGB.
i'm not here to make that your problem.

so yes if you don't know don't write something in that will definitely create a wrong result. to calibrate to bt 709 gamma i have do quite some insane stuff. because why would a calibration software like displaycal even provide me with a preset of something that isn't even used and is not bt 1886.

and that was now exactly what you don't want me to do.
i never learn.

TDLR;
this is what you want me to do?:
https://i.ibb.co/R61V8Zh/child-way.png
mpv.exe --no-config --vo=gpu-next
(not really what i used but close enough)

the gamma value is a fallback with bt 1886 advanced meta data you can write nothing which will work just fine with modern image viewer or something around ~2.2 is technically not correct because bt 1886 does have a gamma fixed gamma it is different on displays if the CR is different but the send image is 100% the same it's 2.4.

well i forgot the logs. which i'm supposed to provide even with a meta question where mpv isn't been used yet.

well have a nice day.
i actually don't want you to do anything i just don't want to argue that bt 1886 is 1.961. that's all.

[kasper93]

don't waste your time on this.
actually in the example case the current gamma would be blank because you have no clue what it is.

I'll be honest I was your last hope. I haven't look at the issue yet. I know there were some previous discussion, but I haven't followed it. And generally I like digging into some "weird" problems. I also know that screenshots have some limitations, I wanted to look at eventually. But if you say no need to work on this. I won't bother.

[tp4tissue]

the report is very short and have no unrelated information. it's just getting derailed after that by what's the words limited knowledge about the basic of calibration. just check it yourself...

like telling me with screenshot-tag-colorspace=no that it converts to sRGB it doesn't... the tone curve is untouched.

with madVR no matter what i do the screenshoot will give me the image i see at the time i took the screen shoot. well every renderer does.

BTW. any other calibrator in this thread that can "confirm" to me that BT 1886 is approximated 1.961?

I'm confused by the back and forth huhn, :eek:

What exactly is being done wrong? Is it the color space or the gamma tracking?

My colorimeter measurements and gamma test slides seems to check out fine for SDR and HDR. I am under windows 10, tested with both nvidia and amd gpus using madvr+mpchc.

[huhn]

I'm confused by the back and forth huhn, :eek:

What exactly is being done wrong? Is it the color space or the gamma tracking?

My colorimeter measurements and gamma test slides seems to check out fine for SDR and HDR. I am under windows 10, tested with both nvidia and amd gpus using madvr+mpchc.

that's about mpv GPU-next. if you play a bt 709 file and make a screenshoot it will write at least to types of meta data for gamma.
a gamma number where they choice 1.961 for bt 1886. and a newer information that just says bt 1886. every image viewer that takes the new bt 1886 meta data will be fine it pretty much means do nothing. programs like windows photo app will use the old meta data and screws the image up.

what is any program supposed to do with that gamma... except mess the image up?

reason for that is mpv uses the encode function of bt 709 for bt 1886 as a decode function. don't ask me why bt 709-6 is clear that is it not used in production and it has nothing to do with bt 1886.

move on.
about color issue mpv gpu-next adds a green tint to a gray scale the brightness is also wrong.
this has not been retested by me in month.

[kasper93]

I'm confused by the back and forth huhn, :eek: It is mpv off-topic, not related to madVR.

@huhn: You are barking (cackling?) at the wrong tree. As I understand your issue is with 1.961 value and that's fair, but you have to go to FFmpeg devs to change/fix that.
The value is not made by mpv or libplacebo it is in ffmpeg image writer / png encoder.

See:
https://github.com/FFmpeg/FFmpeg/blob/86e418ffd7bbdc0530e1e4d5bd7534b6e03b5b05/libavcodec/pngenc.c#L320
https://github.com/FFmpeg/FFmpeg/blob/86e418ffd7bbdc0530e1e4d5bd7534b6e03b5b05/libavutil/csp.c#L135-L147

The only place where libplacebo get approximate value for gamma is here and it is 2.2.
https://github.com/haasn/libplacebo/blob/47ea18ef47875aafe611d47e07a6314ccc92a916/src/shaders/dithering.c#L90-L93

So it is out of my hands, I don't maintain FFmpeg. Ask others. Also since it is in ffmpeg, all the images that are saved to png in ffmpeg would produce the same issue you are having.

EDIT: https://trac.ffmpeg.org/ticket/10000

[huhn]

i was expecting this anyway.
in ffmpeg it makes sense to have this "gamma" it is not a video player it's everything and if you have a high end camera which will follow bt 709 and you want to process this it should follow that "gamma" because that's what the spec is made for the file is not mastered yet.

the thing mpv are doing here are also "wrong" but this is for dithering the error will be very very small.
for bt 1886 it should use 2.4 and if you are very very bored you can get --icc-force-contrast= or an icc file and calculate the real "gamma" which is then used for dithering.

for sRGB well it should be sRGB. cheap man's sRGB is 2.22 so 2.20 is basically the same very very close.

total waste of time. bt 1886 could be changed to return 2.4; so OLED user get it accurate.

if i read this code correctly anyway i'm not a programmer this is outside my expertise.

EDIT: https://trac.ffmpeg.org/ticket/10000
well he is not wrong but just adding 2.4 is also not going to work wonders.
the point is with bt 1886 we don't know the gamma.

[Sunspark]

I did some research. The reason the gamma of BT.1886 isn't a known value is because it's multiple dynamic values and takes into account the characteristics of the display itself.

The display needs to communicate back what the actual black level is, (it isn't zero in BT.1886 like the others).

"However, if you don't want to bother with a precise BT.1886 calculation, white/black values of 120/0.03 cd/m2 serve as a good rule of thumb. This results in a gamma response between 2.3-2.4 at the top end and 2.2-2.1 on the low end."

So Huhn is right when he says 1.961 is not the correct number to be using and ffmpeg is using the wrong value.

Links:

Official specification full of formulas: https://www.itu.int/rec/R-REC-BT.1886-0-201103-I/en
Charts (srgb is quite different from bt1886 and 2.22) and text: https://www.burosch.de/understanding-gamma.html
Text and charts: https://www.chromapure.com/colorscience-gamma-new.asp
Misc: https://www.portrait.com/resource-center/bt-1886-10-questions-10-answers/

[Amuat]

I've been trying to follow this recent very technical discussion, and you have made me wiser in a Socratic sense, as in making me understand how little I know. Nevertheless, I'm gonna inject something in a peasant terminology at this juncture.

Like in this conversation, people often talk about crushed blacks. What bothers me far above anything else is that horrendous greyish, visibly pixelated near-black. It's by far the ugliest thing I've seen in generally quite high quality videos, and surprisingly common. I'm personally willing to make half the f*****g image "black-crushed" if that's what it takes to get rid of it. Not that such drastic measures are ever needed, but the truth is that I do have to make the image slightly darker than I would otherwise like to.

I'm wondering if my Philips OLED806 is just not good enough. It's hard to believe that most supposedly good quality videos are just "supposed to" look like that. If I use the Filmmaker Mode, which as I understand is an attempt to make the image as close as possible without professional calibration to what it's "supposed to" look like, it's just insane how much uniform brightness and hence that ugly greyness there is. I've maxed out all the contrast settings, including gamma, and still have had to turn brightness down from the default 50 to 40, which is a more drastic difference than it maybe sounds. As I said, the image is only slightly darker than I would like it to be, and I'm quite happy with it, but I just don't understand how that horrendous greyness is such a problem. Could it be that the default NVidia brightness and gamma settings are at fault here, that Filmmaker Mode would look good if I would play a high quality video through a Blu-ray player or such?

And finally, do people complain about crushed blacks precisely because they are forced to go darker to avoid those greys, or again, is this more of a personal problem of mine?

[huhn]

I did some research. The reason the gamma of BT.1886 isn't a known value is because it's multiple dynamic values and takes into account the characteristics of the display itself.

The display needs to communicate back what the actual black level is, (it isn't zero in BT.1886 like the others).

"However, if you don't want to bother with a precise BT.1886 calculation, white/black values of 120/0.03 cd/m2 serve as a good rule of thumb. This results in a gamma response between 2.3-2.4 at the top end and 2.2-2.1 on the low end."

So Huhn is right when he says 1.961 is not the correct number to be using and ffmpeg is using the wrong value.

Links:

Official specification full of formulas: https://www.itu.int/rec/R-REC-BT.1886-0-201103-I/en
Charts (srgb is quite different from bt1886 and 2.22) and text: https://www.burosch.de/understanding-gamma.html
Text and charts: https://www.chromapure.com/colorscience-gamma-new.asp
Misc: https://www.portrait.com/resource-center/bt-1886-10-questions-10-answers/
it get's worse.
bt 1886 is 2.4. this is a mathematical fact this is a screenshoot we are talking about or the image that is thrown at the display.

while your display calibrated to bt 1886 will be different from my OLED both get the same image as input and if that image would be changed it is not bt 1886 at that point.

and it get's better let write 2.4 in for bt 1886 source and the result will be wrong. because microsoft doesn't care it is sRGB so it is going to make the image darker by turning the 2.4 to 2.22.

so we write 2.22 the fake sRGB?
what about linux or apple.
apple was 1.8 in the past i heard they changed that and yes i don't know that. so if we now throw 2.4 at that damn ma boy...

and it get's even worse with HDR to SDR tone mapping...
mpv can tone map to bt 1886 and if the result is not gamma 2.4 making the image not bt 1886 as odd as that sounds and it is doing the correct thing because HDR is absolute. but what do you write as meta data in the screenshoot... well my best recommendation at this point it leave it blank test it on apple and the most popular linux image viewer and see if they are kinda sane.

welcome to hell.
I've been trying to follow this recent very technical discussion, and you have made me wiser in a Socratic sense, as in making me understand how little I know. Nevertheless, I'm gonna inject something in a peasant terminology at this juncture.

Like in this conversation, people often talk about crushed blacks. What bothers me far above anything else is that horrendous greyish, visibly pixelated near-black. It's by far the ugliest thing I've seen in generally quite high quality videos, and surprisingly common. I'm personally willing to make half the f*****g image "black-crushed" if that's what it takes to get rid of it. Not that such drastic measures are ever needed, but the truth is that I do have to make the image slightly darker than I would otherwise like to.

I'm wondering if my Philips OLED806 is just not good enough. It's hard to believe that most supposedly good quality videos are just "supposed to" look like that. If I use the Filmmaker Mode, which as I understand is an attempt to make the image as close as possible without professional calibration to what it's "supposed to" look like, it's just insane how much uniform brightness and hence that ugly greyness there is. I've maxed out all the contrast settings, including gamma, and still have had to turn brightness down from the default 50 to 40, which is a more drastic difference than it maybe sounds. As I said, the image is only slightly darker than I would like it to be, and I'm quite happy with it, but I just don't understand how that horrendous greyness is such a problem. Could it be that the default NVidia brightness and gamma settings are at fault here, that Filmmaker Mode would look good if I would play a high quality video through a Blu-ray player or such?

And finally, do people complain about crushed blacks precisely because they are forced to go darker to avoid those greys, or again, is this more of a personal problem of mine?

everything is a mess anyway but without a calibration you don't know what it is supposed to look.

ask tp4tissue just because we finally have a gamma for bt 709 doesn't mean everything before that is mastered at that gamma or even today. i don't have a solution obviously...

[QBhd]

... What bothers me far above anything else is that horrendous greyish, visibly pixelated near-black. It's by far the ugliest thing I've seen in generally quite high quality videos, and surprisingly common. ....

This sounds to me like you have the black levels set wrong at some point in your playback chain.

QB

[mclingo]

Hi I've been thinking for a while to move back to Windows 10 because I hate the way that Windows 11 deals with audio implementation stereo versus surround etc it's just absolute trash, I find mine randomly reverting to stereo and the settings menus in general are just an absolute mess.

Have they broken windows 10 any further with madvr that is not actually worth moving back to Windows 10 oh and are there any new good reasons to come back?

[Amuat]

This sounds to me like you have the black levels set wrong at some point in your playback chain.

QB

Any suggestions how I would go about diagnosing and hopefully correcting the problem?

[Sunspark]

@mclingo set up another partition, 64 gigs minimum and run an install. You will have a boot menu and you will be able to boot into however many versions of Windows you have installed. Each in their own partition. MS is going to be introducing 12 in a year or two anyway.

[mclingo]

Yeah I thought about that but I dip in and out of watching movies and doing stuff on the web quite a lot so it would be a massive pain to have to do a full reboot every time. I just remembered that if I do this I'll have to go through the rigmarole of setting up steam and my quest 3 and side quest and all that gubbins, I'll probably just stick with it for now and just hope it all gets fixed in 12