[MPlayer-dev-eng] [RFC] Color management filter

[Yue Shi Lai]

Hi,

I apologize for the huge patch and the likely even longer message.

Attached is a video filter that enables MPlayer to display video with 
color management, and I wonder about your take on it. It depends on 
Little CMS (see: http://www.littlecms.com/), and implements the 
following features:

- On the fly generation of profiles for typical video signals (PAL, 
NTSC, SECAM, BT.709 HDTV)
- Basic color matching based on ICC profiles for all 4 ICC intents
- Black point compensation using either a modified version of the Adobe 
algorithm (see: http://www.color.org/AdobeBPC.pdf) the Little CMS 
internal algorithm
- Proofing transform (which allows e.g. simulation of CMYK printing) and 
gamut warning

There are still some comment gaps which I will fix for the final patch, 
but since the code is feature complete, I would glad for any tests feedback.

Usage:

1. You will need at least some form of an profile for your screen (the 
filter defaults to sRGB, but that is a last resort and not particularly 
fulfilling the purpose). Typically, an ICC profile is by the display 
manufacturer either on the driver CD or somewhere on the Web. This is 
sufficient to get a "better than nothing" result, but for the best 
result, you would need to directly calibrate your screen (because the 
phosphorus of the mercury lamp ages and the color characteristics drifts 
with time).

I tested this filter using a Colorvision Spyder 2 and calibrating with 
Argyll CMS (see: http://www.argyllcms.com/) and on both the Thinkpad T61 
LCD and a rater old LG Flatron L1715S. For both display, the 
manufacturer profile removes the grossly inaccuracy in color, while the 
measured profile tends to give an uniform and "CRT-like" look.

2. The basic syntax is

cm=variable1=value1:variable2=value2:...,next_filter

The filter accepts input from YUV source and transforms it either in YUV 
or RGB output. RGB should be preferred if you would like a precise 
result. The YUV output usually exhibit a slight posterization effect 
(color bands), because the color management is hitting the quantization 
limit. If this is an issue, use a RGB output (e.g. -vo gl2).

I usually use cm=thinkpad_t61_lcd:intent=a:bpc=1 (which assumes the 
profile thinkpad_t61_lcd.icc to exist)

src=... - source ICC profile
dpy=... - display (or for mencoder, target) ICC profile
proof=... - proofing profile (the output device to simulate)

The three profiles follows the paths proposed by Oyranos (see: 
http://oyranos.com/wiki/index.php?title=OpenIccDirectoryProposal), with 
an MPlayer specific directory added, are expected to lie in either (in 
the search order)

~/.local/share/color/icc
~/color/icc
~/.color/icc
MPLAYER_DATADIR/icc
/usr/share/color/icc
/usr/local/share/color/icc

Profiles are specified (to avoid issues with MPlayer command line 
parsing) without the leading path the .icc or (for profiles from 
Windows) .icm suffix.

src_prim=... - (on the fly generation of source profile) primaries type 
of the source
src_trc=... - (on the fly generation of source profile) the tonal 
reproduction curve ("gamma curve") of the source
dpy_prim=... - same as src_prim, for the display
dpy_trc=... - same as src_trc, for the display
intent=... - The 4 ICC intents, and ignores everything beyond the first 
character

intent=perceptual - is the default, and gives the color management 
module (CMM) maximum flexibility in adjusting the contrast and 
saturation to accommodate the dynamic range.

intent=saturation - extremely arbitrary behavior depending on the CMM, 
supposedly maximizes the saturation for "business graphics", and likely 
not what you want. If you want to preserve the saturation, the two 
remaining intents below tends to be what you are looking for.

intent=relative - color accurate matching _without_ compensating the 
white color (i.e. the light spectrum of your CRT or LCD lamp phosphorus 
layer, or if you have those, the back light LED). This means the color 
is corrected, but the 6500 K white of video signal is mapped to whatever 
RGB = (255,255,255) your screen gives you

intent=absolute - color accurate matching with compensation of the white 
color.

see also: http://www.color.org/iccprofile.xalter

warn=0..255:0..255:0..255 - only works with proofing profile set. It 
sets the gamut warn color, which labels color lies outside the proofing 
profile, if not all r, g, b are specified, use the default gray level (153)

bpc=n - black point compensation (BPC), which might be useful if you are 
using a hardware calibrated screen and the resulting image is too dark. 
n = 0 means no black point compensation, n = 1 uses _a modified form_ of 
the Adobe BPC, I will explain the modifications below, n = 2 uses the 
internal algorithm of Little CMS (which tends to overshoot).

black=0..255 sets the gray level that is considered "black" for the 
modified Adobe BPC, which is not necessarily 0 for typical video signals 
(defaults to 5)

exact=0/1 if nonzero, generate an exact and not interpolated color LUT 
(which can take on the order of 10 seconds, if your CPU is slow)

3. Some other notes

The lookup should be fast enough on most current, beyond Pentium III 
CPUs, but it can easily get the CPU load to ~ 60% on older Pentium M and 
Pentium 4 with a NTSC signal.

The algorithm uses internally a 256^3 color LUT (which occupies ~ 50 MB 
RAM), and by default does not calculate the entire LUT using Little CMS. 
Instead, a Catmull-Rom spline interpolation is applied on the LUT, which 
for HAVE_SSE2=1 is implemented using SSE2 assembly to speed up the 
calculation and reduce the latency it causes during MPlayer startup.

Black point compensation (BPC) is normally not needed if you are using a 
ICC profile supplied by the monitor manufacturer. These profiles 
typically characterize the screen by a ideal gamma value (usually = 
2.2), and thus black = (0, 0, 0). Measured profiles expecially for 
laptop LCD can have a non-zero black, simply because there is light 
leakage. Without BPC, everything below the light leakage is considered 
(0, 0, 0), thus removing dark details.

Little CMS does not implement the Adobe BPC, but rather its own. This 
filter implements a BPC algorithm that is _modified_ from the Adobe BPC 
by the following ways:

(a) A nonzero local black is used, because otherwise the Adobe BPC will 
overcompensate, like Little CMS, and resulting in black becoming gray.

(b) Instead of finding only the minimum of the parabolic least square 
function (which is typically wrong for screen profiles), find either the 
2nd root or if no real root exist, the minimum. This also removes the 
need for the ad hoc handling of "nearly straight mid range" cases in the 
original algorithm. I believe this and not the original version is the 
correct way to implement it.

(c) bpc=1 is implemented for the absolute colorimetric intent (as 
opposed to Little CMS and if you try bpc=2), which makes the algorithm 
not "absolute", but still fixes well the color temperature for old displays.

I implemented the proofing transform for completeness sake, though 
likely there are little practical use. You can test its effect e.g. 
using USWebUncoated.icc from 
http://www.adobe.com/support/downloads/product.jsp?product=62&platform=Windows 
or by using the same profile as the display, and use warn= to see what 
colors your screen cannot display natively.

Best,

Yue Shi Lai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-svn-vf_cm-20080825.patch
Type: text/x-patch
Size: 98204 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080825/aaa3804a/attachment.bin>