Closed ghost closed 8 years ago
Color management, our favorite topic here :smile:
First of all, I think it's easier if you post the output of mpv -v
directly into a comment here.
What happens if you load your 3DLUT file in mpv via icc-cache-dir=<dirname>
?
And maybe post a full log of mpv with the opened file, i.e. --log-file=<path> <file>
Edit: Oh, and for the record. The difference in the sample images is clearly visible, even on crappy laptop screen ;)
First of all, I think it's easier if you post the output of mpv -v directly into a comment here.
Done.
What happens if you load your 3DLUT file in mpv via icc-cache-dir=
?
I don't think I can load the MadVR 3DLUT using that command. Or at least I don't know how to make it work. It creates a new folder in the source path with a random-name generated file.
And maybe post a full log of mpv with the opened file, i.e. --log-file=
Here you are (I'm afraid it's too long to put it on a post): a.txt
Please use three symbols, break a line, post your stuff and then do another set of three
symbols on a final line. That would be much more readable for such type of content (the preview should show you how much better it looks). Thank you.
(and since it wasn't obvious, I meant the quoted content)
edit: or actually you might just not be finishing the quoted part of the message you're replying to.
What happens if you load your 3DLUT file in mpv via icc-cache-dir=
?
That won't work, it requires some sort of header which you can't easily make up.
That won't work, it requires some sort of header which you can't easily make up.
It also requires a specific format and the right filename.
As for the OP issue, I can't reproduce it on my end. Using the latest master (f99e48a), I am running this:
mpv --fullscreen=no --geometry 1920x1200 -vo opengl-hq:dither-depth=8:icc-profile=/mem/btujkb.icm:3dlut-size=256x256x256 /mem/46418e00-1538-11e6-91b2-ce802f3b8ae4.jpg
Taking a raw screendump of this using import -depth 8 filename.png
gives me the following PNG output:
Inspecting the color values using a color picker (in krita, specifically); any deviations from the original neutral tones seems to be due to a combination of rounding error and dithering, both which are unavoidable. (Your reference image also has these off-by-ones)
Edit: I did not tag the result of this image, so the gamma will look wrong in browsers like firefox that do color management. When comparing, remember to either inspect pixel values directly or view them with CMS turned off.
Also, for some reason your “reference” result seems to have the black levels boosted by an insane degree. I can't tell you why that's the case, but it doesn't seem to be a part of the original image.
But either way, this was about the white balance specifically.
Edit 2: Just to be sure, I re-uploaded a stripped, tagged version of the image.
This version should now look similar to the original in browsers and other programs that do color management.
Also, your log indicates you are using mpv version 190578b which does not seem to be a valid commit I can locate anywhere. What's going on there?
Also, your log indicates you are using mpv version 190578b which does not seem to be a valid commit I can locate anywhere. What's going on there?
I'm using the latest 64-bit build from here: https://mpv.srsfckn.biz/
Edit 1: I've just tried running exactly the same as you (I renamed the picture and the profile to "a" and put them in the same folder):
mpv --fullscreen=no --geometry 1920x1200 -vo opengl-hq:dither-depth=8:icc-profile=a.icm:3dlut-size=256x256x256 a.jpg
And I'm still having the same blue tint.
Edit 2: And yes, the second image that you have posted is very similar to the one that I see when I open the source on a color-managed application.
Okay. For the reference, the only relevant difference since then in current master is the enabling of black point compensation, which doesn't seem to have made any effect here either way.
I'd like to add that the gamma differences between the source image and the expected result might be caused because XnViewMP is configured to treat images without embedded profile as sRGB.
I'd like to add that the gamma differences between the source image and the expected result might be caused because XnViewMP is configured to treat images without embedded profile as sRGB.
mpv is configured to treat all RGB images as sRGB regardless of any embedded profiles or not. (Unless you override it manually or FFmpeg somehow inexplicably provides colorspace tags for these images)
Edit 1: I've fixed some black crush and yellow tint problems by using icc-intent=0
, but other images still look bluish.
Edit 2: If I open a bluish image in Photoshop and save it to png, it looks good on MPV. But if I save it to jpg again, it still looks bad. MP4 video files have the same problem, but I didn't see any png with the bluish tint. PNG and GIF files look exactly as expected.
So it only happens with YUV files and not RGB files?
What if you add `--vf=format=gamma=srgb
?
I'm not sure about which files use YUV.
What if you add `--vf=format=gamma=srgb?
Using this works on both JPG and MP4 files, it fixes the problem This is the result:
@TallsFalls What if you use --vf=format=gamma=bt.1886
on the RGB files?
@haasn If I use bt.1886 the blue tint strikes again. I'd like to add that the blue tint problem also happens in my laptop, which is also calibrated with DisplayCAL.
Well, I can't reproduce it even with that option. Are we using different versions of LittleCMS and mpv, perhaps?
Can you try building the latest version of both and testing again?
I'm afraid I'm too dumb to do that. I'm trying to follow the "Native compilation with MSYS2" guide, but I'm having the error "Program ['gcc.exe'] is not executable"
Did you use a fresh installation of MSYS2?
Yes.
Um, okay. At which step does this error appear? Installing all the dependencies did finish successfully?
All the dependencies finished successfully.
This happens at ./waf configure CC=gcc.exe --check-c-compiler=gcc --prefix=/mingw64
Well, I've never used waf personally, but Windows itself should not be the problem.
The syntax with ./
is a bit unusual..
I mean this should still work, theoretically.
What happens when you just run waf
from the /mpv
directory?
Edit: My bad, I was skipping this step: Start a MinGW-w64 shell (mingw64_shell.bat). Note that this is different from the MSYS2 shell that is started from the final installation dialog.
@haasn On my built MPV I don't have any problem with color management. There are still small differences between MPV and Photoshop / XnViewMP, but now they are almost imperceptible.
cc @lachs0r
Still a problem? My builds use LCMS git master.
@lachs0r I don't have this problem since a long time ago.
MPV doesn't seem to like my display profile. I have a blue tint when using color management (icc-profile-auto). It's apparent on dark colors and grays. I've already tried changing the size to 256x256x256 and the four color rendering intents.
My ICC profile was made using DisplayCAL. It's a XYZ Lut + Matrix profile. The settings that were used when making the profile are whitepoint: 6500K and tone curve: gamma 2.2 (The default "Office & Web" preset).
The image looks neutral on my monitor in Photoshop, XnViewMP and MPC-HC + MadVR (using a 3DLUT calibration file made on DisplayCAL). But it's completely blue in MPV.
Here I'm attaching the following files:
Github won't let me upload the icc profile, so here it is: https://my.mixtape.moe/btujkb.icm