{"action":"created","issue":{"url":"https://api.github.com/repos/mpv-player/mpv/issues/534","labels_url":"https://api.github.com/repos/mpv-player/mpv/issues/534/labels{/name}","comments_url":"https://api.github.com/repos/mpv-player/mpv/issues/534/comments","events_url":"https://api.github.com/repos/mpv-player/mpv/issues/534/events","html_url":"https://github.com/mpv-player/mpv/issues/534","id":27214481,"number":534,"title":"Color Management (OS X): Image is too dark","user":{"login":"UliZappe","id":6627065,"avatar_url":"https://avatars.githubusercontent.com/u/6627065?v=3","gravatar_id":"","url":"https://api.github.com/users/UliZappe","html_url":"https://github.com/UliZappe","followers_url":"https://api.github.com/users/UliZappe/followers","following_url":"https://api.github.com/users/UliZappe/following{/other_user}","gists_url":"https://api.github.com/users/UliZappe/gists{/gist_id}","starred_url":"https://api.github.com/users/UliZappe/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/UliZappe/subscriptions","organizations_url":"https://api.github.com/users/UliZappe/orgs","repos_url":"https://api.github.com/users/UliZappe/repos","events_url":"https://api.github.com/users/UliZappe/events{/privacy}","received_events_url":"https://api.github.com/users/UliZappe/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":216,"created_at":"2014-02-09T02:17:33Z","updated_at":"2016-01-17T22:23:48Z","closed_at":"2014-02-25T01:13:39Z","body":"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.\r\n\r\nThe following images are from a scene from Lars von Trier’s *Melancholia*. The first image is from **QuickTime Player X**:\r\n\r\n![quicktime](https://f.cloud.github.com/assets/6627065/2118922/4eae0370-912d-11e3-950e-9398ce2b8fbb.jpg)\r\n\r\nThis image is from a **h.264** file (in an **mp4** container) extracted from the BluRay version of the movie. 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.\r\n\r\nSo this image is arguably the reference and shows how the colors *should* look like.\r\n\r\nThe next image is from the same **mp4** file, played in **mpv** *without color management*:\r\n\r\n![mpvnoprofile](https://f.cloud.github.com/assets/6627065/2118938/ca1667ae-912e-11e3-9796-6e0f8bd430f5.jpg)\r\n\r\nThis 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).\r\n\r\nThe 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):\r\n\r\n![mpvprofile](https://f.cloud.github.com/assets/6627065/2118945/421cdbfc-912f-11e3-9a99-d9e95131352b.jpg)\r\n\r\nAs 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.\r\n\r\nNow 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?\r\n\r\nCould somebody familiar with this part of the **mpv** code base comment?"},"comment":{"url":"https://api.github.com/repos/mpv-player/mpv/issues/comments/172390793","html_url":"https://github.com/mpv-player/mpv/issues/534#issuecomment-172390793","issue_url":"https://api.github.com/repos/mpv-player/mpv/issues/534","id":172390793,"user":{"login":"haasn","id":1149047,"avatar_url":"https://avatars.githubusercontent.com/u/1149047?v=3","gravatar_id":"","url":"https://api.github.com/users/haasn","html_url":"https://github.com/haasn","followers_url":"https://api.github.com/users/haasn/followers","following_url":"https://api.github.com/users/haasn/following{/other_user}","gists_url":"https://api.github.com/users/haasn/gists{/gist_id}","starred_url":"https://api.github.com/users/haasn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/haasn/subscriptions","organizations_url":"https://api.github.com/users/haasn/orgs","repos_url":"https://api.github.com/users/haasn/repos","events_url":"https://api.github.com/users/haasn/events{/privacy}","received_events_url":"https://api.github.com/users/haasn/received_events","type":"User","site_admin":false},"created_at":"2016-01-17T22:23:48Z","updated_at":"2016-01-17T22:23:48Z","body":"^ ITU-R offers another realization of why it works so well in practice to have cameras tuned for Rec. 709, and display devices tuned for Rec. 1886:\r\n\r\nSince LCD displays don't go down to a true zero black, but instead have a minimum “black point”, you need to include this consideration in round-trip calculations. And when you do, that is, multiply a BT.709 input curve by a BT.1886-with-constant-offset output curve, you get a total end-end response that is very approximately linear: In other words, the ‘error’ of BT.709 almost perfectly cancels out the ‘error’ of a non-true black.\r\n\r\nThis is described in ITU-R Report BT.2246 “The present state of ultra-high definition television”, which outlines their design process for Rec. 2020 - in particular, why they decided to keep around the same EOTF and OETF for Rec. 2020."}}