mpv
mpv copied to clipboard
mpv-player
What black level is assumed with uncalibrated displays?
If display is not calibrated, there surely must be an assumed black level what value is assumed 0.0 or something else?
In --vo=gpu-next, it defaults to 1000:1 contrast. No way to change it, currently. (Patches welcome to add an option)
It's worth noting that I'm currently (once again) rewriting this code, to work differently in the presence of ICC profiles
A contrast of 1000:1 I'm not sure how to calculate the black level from it. There needs to be a lowest level of black that mpv sends to the screen, is it 0.0001, 0.0175?
I'm starting to understand why there is a lot of confusion about calibration in mpv.
Internally mpv uses gamma 1886, if someone calibrates screen to that standard by the book, using icc-profile-auto=yes only results in colors looking more accurate no noticable contrast change vs. icc-profile-auto=no because desktop is also calibrated to 1886 (assuming monitor is close to 1000:1 contrast). The confusion comes when using something like gamma 2.2, in that case icc-profile-auto=yes the video will be manipulated to look like 1886, like mpv compensates against the gamma ramp of 2.2 to make it 1886 (no idea how to call it). So turning ICC on off shows a huge difference in contrast, but the ICC auto version looks like 1886 regardless of what gamma you use. For a gamma 2.2 the video gets lightened so that adding a gamma ramp from GPU still results in 1886. But with more manipulation color accuracy degrades mostly visible on skin tones. This is my take from experimenting with different settings. Taking screenshots is totally useless what you see on screen is different than what ends up in the screen capture, hence all the bugs with inconclusive endings.
I tried davinci resolve calibrated to 1886 results are very similar to mpv very close so mpv is accurate but only when using 1886.
Also noticed that changing black level offset from 100% or setting black level manually to 0.0001 does not really help and I'm not sure why.
What could help you decide some better more contrasty look that might be better for more people would be gimp with color management turned on, intent relative colorimetric, no black point compensation. Think it looks the best as a standard.
I don't know why 1886 is considered like the industry standard, it just looks terrible on low end displays and only partially acceptable on high end displays can't even hit a gamma of 2.4
Another observation is that the further away from 1886 you calibrate the worst the result in mpv with ICC auto. But 1886 while technically well reproduced by mpv looks so washed out that I prefer calibrating to gamma 2.2 and using ICC off, gamma ramp is still applied only colors are a bit off.
A partial workaround for gamma 2.2 that looks best for desktop calibration is to add icc-force-contrast=inf aka. pure gamma 2.4 and add a gamma-factor=1.1 this makes it ~gamma 2.2, but colors near black look a bit bluish on my monitor for whatever reason.
A contrast of 1000:1 I'm not sure how to calculate the black level from it. There needs to be a lowest level of black that mpv sends to the screen, is it 0.0001, 0.0175?
It's 0. The values mpv sends to the screen are relative to the screen's black point. It does not matter whether your screen has a contrast of 1000:1 or 5000:1, a value of 0 sent to the screen is always 'whatever the screen's black point happens to be'.
Regarding the rest of your comments, are you testing with --vo=gpu or --vo=gpu-next?
Sorry for not mentioning the version of mpv:
- mpv version: mpv 0.34.0 Copyright © 2000-2021 mpv/MPlayer/mplayer2 projects built on Sun Nov 7 20:16:38 +08 2021 FFmpeg library versions: libavutil 57.7.100 libavcodec 59.12.100 libavformat 59.8.100 libswscale 6.1.100 libavfilter 8.16.101 libswresample 4.0.100 FFmpeg version: git-2021-11-06-1728127e
- Windows 11
- https://sourceforge.net/projects/mpv-player-windows/files/release/mpv-0.34.0-x86_64.7z/download
I use stable windows version, also I do experiment with --vo=gpu-next latest nightly from: https://sourceforge.net/projects/mpv-player-windows/files/64bit/
As far as contrast goes both --vo=gpu or --vo=gpu-next act the same almost down to the last detail, the only improvement I see with --vo=gpu-next is way less chroma noise:
gpu:
gpu-next:
Think I finally found a fix for my contrast issues. Given that mpv internally uses a gamma of 1886 as standard, I let it use an icm calibrated for that standard with icc-profile="1886.icm" option, and I leave the monitor calibrated to gamma 2.2 or anything else that looks ok, this results in color correction in mpv respecting the 1886 standard and because the gamma 2.2 is applied to the display it will be applied on top of the color corrected video. In case I want 1886 gamma I set the display to also use 1886 gamma profile same as the one manually set in mpv.
But I have a question, in order to test I would need to clear the icc-profile and this does not work in input.conf:
F1 cycle-values icc-profile "" "d:\ROG PG279Q Resolve-v001 #1 2022-04-27 16-43 0.3127x 0.329y Rec. 1886 M-S XYZLUT+MTX.icm"
But I have a question, in order to test I would need to clear the icc-profile and this does not work in input.conf:
F1 cycle-values icc-profile "" "d:\ROG PG279Q Resolve-v001 #1 2022-04-27 16-43 0.3127x 0.329y Rec. 1886 M-S XYZLUT+MTX.icm"
That should work, I use the same (on Linux):
c cycle-values icc-profile "" "~~/S2721DGF.icm"
Maybe make sure the path is correctly found?
But I have a question, in order to test I would need to clear the icc-profile and this does not work in input.conf:
F1 cycle-values icc-profile "" "d:\ROG PG279Q Resolve-v001 #1 2022-04-27 16-43 0.3127x 0.329y Rec. 1886 M-S XYZLUT+MTX.icm"That should work, I use the same (on Linux):
c cycle-values icc-profile "" "~~/S2721DGF.icm"
Maybe make sure the path is correctly found?
Nope setting it to "" does not work
I would make sure there's no other auto loading enabled. It works for me.
mpv.conf:
icc-profile="~~/S2721DGF.icm" icc-cache-dir="~/.cache/mpv" icc-profile-auto=no use-embedded-icc-profile=no
input.conf:
c cycle-values icc-profile "" "~~/S2721DGF.icm"
The problem with cycle-values icc-profile was some path length problem or a bad character in the path on windows, this works now:
F2 cycle-values icc-profile "" "~~/color-management/ROG PG279Q Video Rec1886.icm"
Coming back to the color management contrast issue I noticed something in the logs even if I use option icc-profile=<file> I end up with this in the log:
[ 0.146][v][vo/gpu] Opening ICC profile 'D:/OneDrive/Documents/PortableOD/MediaPlayers/mpv/portable_config/color-management/ROG PG279Q Video Rec1886.icm'
...
[ 0.152][v][vo/gpu/win32] color-profile: C:\Windows\system32\spool\drivers\color\ROG PG279Q Gamma_2_2-v001 #1 2022-02-05 15-34 0.3127x 0.329y 2.2 S XYZLUT+MTX.icm
Is the second icm used for anything or is it just an extra information for debugging porpoises?
Think I finally found a fix for my contrast issues. Given that mpv internally uses a gamma of 1886 as standard, I let it use an icm calibrated for that standard with icc-profile="1886.icm" option, and I leave the monitor calibrated to gamma 2.2 or anything else that looks ok, this results in color correction in mpv respecting the 1886 standard and because the gamma 2.2 is applied to the display it will be applied on top of the color corrected video. In case I want 1886 gamma I set the display to also use 1886 gamma profile same as the one manually set in mpv.
Obviously I was wrong, made same settings on a laptop and black crush is terrible with icc-profile="1886.icm" and display gamma 2.2. I have no clue how to calibrate my monitor for mpv so that I get accurate colors and preserved contrast. I give up.. I invested a lot of time in this and the only conclusion so far is that no matter what I do the results on screen are from acceptable to outright terrible.
Uncalibrated - terrible - colors inaccurate -contrast acceptable - black crush
Calibrated gamma 2.2 - terrible - washed out colors and skin tone issue - terrible contrast - no black crush
Calibrated rec1886 - terrible - washed out colors - terrible contrast - no black crush
Mpv forced rec1886 display profile gamma 2.2 - monitor dependent from terrible to acceptable - colors are ok on both PC and laptop - contrast good on PC too much on laptop - black crush acceptable on PC and terrible on the laptop - my take is that this config is only ok regarding black crush if using icc-profile-auto results in a contrast decreasing vs uncalibrated.
Note that there is no guarantee for any gamma setting to be correct for a given content example. My impression is that some content is produced in such a way that it should be viewed in regular pure power gamma ~2.4 curve, as TVs otherwise would need to be able to be aware of their actual black point for BT.1886, which, apart from OLED, probably is wishful thinking.
BT.1886 will still be much brighter than pure power gamma 2.2 with any LCD device, that's to be expected. With an ICC profile, mpv displays SDR content in BT.1886 and it takes display gamma into account for this. So if the display is gamma 2.4 and ICC profile says so (or sets the display to gamma into gamma 2.4 via VCGT), BT.1886 will brighten it up stronger than with display gamma 2.2 to achieve the same result.
With gpu-next, you can also feed it 3D LUTs generated via DisplayCal and see what mpv's gamma adjustment does in comparison. Ideally, there should be zero difference with the same parameters.
As for the ICC profile gamma rework, I think it would be great if we could cycle through some gamma settings (e.g. BT.1886, pure power 2.2 and 2.4 and perhaps also gamma 2.2 with black output offset 0% for some weird files) via a toggle hotkey by default, as real-world content is so greatly unreliable in that regard.
BT.1886 will still be much brighter than pure power gamma 2.2 with any LCD device, that's
Darker, not brighter. WTF?
as TVs otherwise would need to be able to be aware of their actual black point
Any normal TV is aware of it and changes the picture. Dolby IQ works like that too, but it can also change if the illuminant is not on a Plankian locus, so not "white".
So if the display is gamma 2.4 and ICC profile says so (or sets the display to gamma into gamma 2.4 via VCGT), BT.1886 will brighten it up stronger than with display gamma 2.2 to achieve the same result.
No, the opposite. If the display is 2.4 gamma it will not touch anything. If it is 2.2 gamma it will have to darken the picture to stay the same. The reference is how it looks with 2.4 gamma if untouched.
as real-world content is so greatly unreliable in that regard.
All that content is supposed to be BT.1886, so in dark room 2.4 gamma, in light room 2.2
value of 0 sent to the screen is always 'whatever the screen's black point happens to be'.
That is how it is supposed to work when you color manage SDR to HDR. Since BT.709 does not have a black point, 64 Y' is what is used for it (limited range 10 bit PQ).
If display is not calibrated, there surely must be an assumed black level what value is assumed 0.0 or something else?
No, only for sRGB/Adobe RGB, since those have a black point. Scene referred do not have a black point, so who knows what their 0 RGB (16, 64 YCbCr) is. Though I still do not know whether PQ 64 is 0 nits or 0.0001 nits :)
Darker, not brighter. WTF?
No, not with LCD black levels. I perhaps could just reconfirm this with a SpyderX that I got at hand and which can measure LCD black levels perfectly well, but I'm not really feeling inclined to that with reactions like "WTF".
Darker, not brighter. WTF?
No, not with LCD black levels. I perhaps could just reconfirm this with a SpyderX that I got at hand and which can measure LCD black levels perfectly well, but I'm not really feeling inclined to that with reactions like "WTF".
Yes I agree that on any display that has a non perfect black level standard 1886 will have less contrast and will be way brighter than pure gamma 2.2 any time of day. 1886 has a very slow progression from display black to display white and on anything less than an OLED it will be visibly brighter and washed out.
I experimented a lot with every setting that exists in DisplayCAL I created about 36 profiles with black output offset going from 0% to 100%, absolute vs relative tone curve, black point compensation baked in, gamma 2.2 gamma 2.4, 1886, I even tried white level and black level drift compensation (just in case). 3dlut Resolve calibration to check if mpv and Resolve show the same image and white in Resolve was just a bit whiter and colors were a bit more accurate, but not a noticeable difference while playing the video.
And here comes the conclusion, I ditched DisplayCAL. I don't believe the statement on the net that with same settings in DisplayCAL you end up with same results as using the software for your hardware. Even with importing colorimeter corrections from the original software is not enough. Uninstalled DisplayCAL and installed ccProfiler and everything went from bad to totally fine, whites are white (not green like with DisplayCAL), and contrast is spot on, colors are as expected and even more accurate. ccProfiler large patch set is only 461 and I used like 2000-3000 and more in DisplayCAL and got way worse results.
So anyone coming to this thread having same problem like me don't blame mpv its a profile issue:
- Install software that came with your hardware
- Calibrate to Gamma 2.2 or whatever you feel looks best to you.
- Optionally uninstall ccProfiler and similar and reinstall DisplayCAL to use it's profile loader instead of utility included in ccProfiler that loads gamma only once at boot.
With DisplayCAL, tried my best to find the reason but I couldn't find a single option in DisplayCAL that would solve my contrast issue. ATM I'm thinking there is a bug in DisplayCAL or ArgyllCMS just can't prove it. All I know is no option changed the behavior for me not even a 3dlut with vcgt on and off.
If DisplayCAL would give same results as the standard software it would be amazing, but it doesn't, unfortunately.
So far I managed to mess up how colors appear in mpv in 2 ways:
- By using an old Spyder colorimeter that can't measure contrast (black point)
- By buying one of the most expensive colorimeters i1Display Pro Plus and using it with DisplayCAL
If you reached this point your my hero.
EDIT: Corrected some recommendations after further testing, banding as an example.
Why did you turn "Use Windows display calibration" in the OS? Shouldn't one ideally remove that and let MPV deal with the calibration? Isn't every single relevant data about your screen already in the profile?
VCGT is only loaded on GPU if a utility loads it like DisplayCAL profile loader, a gamma loader from ccProfiler (i1Profiler) or similar. To get the correct look you need to load the VCGT. Alternative is to create a 3DLUT with VCGT baked in and load no other calibration at all at OS level, this would make all apps using the LUT display colors accurately but nothing else on your display would be color corrected.
Recently tested banding on Windows and I now recommend not using the " Use Windows display calibration" option. Best is to let the calibration software utility load the gamma at boot, and even better use DisplayCAL profile loader even if you don't use DisplayCAL to calibrate the display.
On Thu, May 12, 2022, 05:19 OrangeColaJuice @.***> wrote:
Why did you turn "Use Windows display calibration" in the OS? Shouldn't one ideally remove that and let MPV deal with the calibration? Isn't every single relevant data about your screen already in the profile?
— Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/10143#issuecomment-1124462403, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGLXVW7QLKWXS6GET6LWDTVJRTELANCNFSM5URZGTCA . You are receiving this because you authored the thread.Message ID: @.***>
https://github.com/ledoge/dwm_lut general color management with dithering on, alternative to the loader
https://github.com/ledoge/dwm_lut general color management with dithering on, alternative to the loader
Missed this comment for some reason, would this help mpv display colors accurately with all internal color management options turned off? @haasn Wouldn't mpv still assume display characteristics if not reading them from a profile? In a sense mpv not knowing the global lut would send the best guess of what should appear on screen and the global lut would be applied on top, not very accurate right?
It's applied globally and thus completely replaces applications' own calibration. So it's not really related to mpv, unless for comparison purposes. If you want to use both at the same time, you need to re-run calibration with it active and use that ICC profile in mpv, but this is getting off-topic.
It's applied globally and thus completely replaces applications' own calibration. So it's not really related to mpv, unless for comparison purposes. If you want to use both at the same time, you need to re-run calibration with it active and use that ICC profile in mpv, but this is getting off-topic.
I tried dwm_lut and indeed if all other color managers are turned off vcgt burned into the 3dlut it looks fabulous applied to every single pixel on the screen, nothing really compares to it.
For mpv to still get some information about the display would it help if I set the lut parameter to the globally applied 3dlut but without vcgt (to avoid applying vcgt twice). I think mpv not guessing what the display can handle + a global 3dlut would be most accurate. What are your thoughts?
It's applied globally and thus completely replaces applications' own calibration. So it's not really related to mpv, unless for comparison purposes. If you want to use both at the same time, you need to re-run calibration with it active and use that ICC profile in mpv, but this is getting off-topic.
It's not off topic it's about color management and figuring out how to do it correctly so we finally solve this once and for all, to the benefit of everyone. I don't even have much time to watch movies, but I do care to understand how all this works and want to make it work, and just maybe help others who have same problems once I figure it out ;). So far there are a lot of blank spots and bugs and quirks that make color management a headache in and outside mpv. Not to mention with latest mpv even my previous workaround with using ccProfiler to create the profile stopped working (mpv now shows an even brighter image with the profile created with ccProfiler than the one created with DisplayCAL)
There is a missing piece, why applying ICC that was created while not using dwm_lut active is not recommended to be used in color managed applications like mpv? The way I tried to do it is creating an "sRGB" profile with tone curve set as measured (to avoid gamma correction) then creating a 3dlut with vcgt baked in (gamma 2.2), applying both with mpv results in black crush to some extent, and it's not clear to me why this happens.
My expectation with using icc profile created before 3dlut was applied is that mpv gets the profile tries to output the best sRGB image it can and 3dlut maps those colors as it usually does expecting the source to be srgb (source was selected to be srgb), in an ideal situation this should not show any color changes inside mpv window just color correction applied 2 times, but it's not the case for some reason. Help me understand the reason to fill in this gap in my understanding about color management.
If you want to use both at the same time, you need to re-run calibration with it active and use that ICC profile in mpv, but this is getting off-topic.
Tried just that and mpv brightens the video a lot. Best I can do is load only the lut with dwm_lut and add these to mpv options: target-prim=bt.709 (3dlut expects this) target-trc=bt.1886 (not sure about this, my assumption is that I can have a video with bt.1886 and 3dlut to have gamma 2.2, maybe I'm wrong)
I have created the 3dlut with a gamma 2.2 not sure if that matters, but I just can't tolerate bt1886 as my desktop calibration.
Made it like this:
Oddly enough gimp does not show the same behavior it looks ok with both profile and dwm_lut enabled at the same time when the profile was created with dwm_lut active when profiling.
In
--vo=gpu-next, it defaults to 1000:1 contrast. No way to change it, currently. (Patches welcome to add an option)
Forgot to ask what implications does it have to assume 1000 as the top not knowing the display?
VCGT is included in the ICM profile just not loaded unless the OS or a utility is told to load it. And it's very important what loads the VCGT if windows loads it it loads it in 8bit, if ccProfiler utility or DisplayCAL loads it loads it in 16bit.
The LUT option is fine just be careful when including the VCGT into the LUT to not use any at OS level.
lut-type=conversion - no idea what this is can't comment
On Thu, May 12, 2022, 09:27 OrangeColaJuice @.***> wrote:
So the icc profile can't hold the 1DLUT, had no idea. I was aware that you could bake the VCGT in the .cube file and I recommend this for that and general color management: https://github.com/ledoge/dwm_lut general color It does dithering on its own so you won't get banding on non AMD gpus but it introduces some lag in mpv (I'm on an ancient iGpu) while using the .cube file or icc work smoothly. I also want to rely on mpv for color management because I can control the dithering process as well.
Is this the correct way to load the .cube btw? lut="C:/apps/Unnamed.cube" lut-type=conversion
— Reply to this email directly, view it on GitHub https://github.com/mpv-player/mpv/issues/10143#issuecomment-1124579120, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAGLXVSJGEW77AB6EXFWYXTVJSQFZANCNFSM5URZGTCA . You are receiving this because you authored the thread.Message ID: @.***>