I believe it applies to any codec, as will be demonstrated below. My apologies, saying it's related to H.264 may have been confusing matters. I use a prebuilt version of mpv as I didn't want to deal with all the dependencies of the code base, but if I can help by checking modified binary versions, I’d be glad to do so. (The other, more remote possibility that comes to my mind would be some incorrect blackpoint compensation setting.) So basically, Little CMS must gamma match the video source gamma as specified in the video profile to the display gamma as specified in the display profile.įrom what it looks like, the issue might well be gamma related. (My display is calibrated to gamma 2.2, which is the OS X default since Snow Leopard (and has always been the Windows default)). The gamma of the targeted display is included in its monitor profile, it will most probably (but not necessarily) be either 1.8 or 2.2. Hm, unfortunately, I have little knowledge about the video side of things, but I would have guessed that the BT.709 and BT.601 profiles define the gamma of the video source (just as ICC profiles embedded in images document the gamma of the image’s color space). It might also be possible that mpv is making an incorrect assumption about what the expected input gamma of the movie is. That’s why personally, I prefer either computer displays or projectors to watch movies. You have a point in that usually there are no factory monitor profiles for TV sets available, and it’s very hard to create them by yourself (almost no suitable measurement devices available). That some devices are "brighter" than others is pre color management thinking, so to say this shouldn't matter. The task of the monitor profile is exactly to convert the colors such that they look exactly the same on any output device with a corresponding monitor profile. Hm, yes, but the very idea of color management is to abstract from any hardware. The first thing that came to mind is the difference between television sets and computer monitors (which tend to be brighter) I also used this monitor when cross-checking with Apple’s DVD Player and the iTunes version. Yes, these are all screenshots from the very same monitor (a 30" Apple Cinema Display in my case). Now I wonder if this is a deficiency of the liblcms2.2.dylib library that mpv uses, or if it's just that mpv uses liblcms2.2.dylib with incorrect or suboptimal parameters?Ĭould somebody familiar with this part of the mpv code base comment? The third image is again from the same mp4 file, played in mpv with color management (using the default rendering intent, which is absolute – choosing another intent does not fix the problem discussed here):Īs you can see, compared to the QuickTime version, the colors seem to be more or less correct now, but the image is obviously too dark. This image makes it very obvious why color management is a must aesthetically, it’s basically another image (technically, it’s too red and too saturated). The next image is from the same mp4 file, played in mpv without color management: So this image is arguably the reference and shows how the colors should look like. I have compared it to the DVD version (played in Apple’s DVD Player) and to the version from the iTunes store, and the colors are exactly the same in these three versions and also match high quality still images I have from this movie. This image is from a h.264 file (in an mp4 container) extracted from the BluRay version of the movie. The first image is from QuickTime Player X: The following images are from a scene from Lars von Trier’s Melancholia. I have compared the icc-profile= setting of mpv to Apple’s native QuickTime Player X on OS X 10.9.1 and found that the resulting colors are basically correct, but the image is too dark.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |