[Openicc] L* ... (please move topic to ECI-EN mailinglist)

[Lars Borg]

Scott,

L* is great if you're making copies. However, in most other 
scenarios, L* out is vastly different from L* in. (This is sometimes 
known as rendering.) And when L* out is different from L* in, an L* 
encoding is very inappropriate as illustrated below.

Although it's sometimes meaningless to use L* for colors on set, let 
me provide an example for video. Let's say you have a Macbeth chart 
in the studio and it's lit perfectly for this case, so L* measures 96 
for the whitest patch. On set, the six gray patches would measure 
around  L* 96, 81, 66, 51, 36, 21. (Note that I didn't tell you the 
color temperature of the studio lights.)

Assuming the camera is Rec.709 compliant, using a 16-235 digital 
encoding, and the camera is set for the exposure of the Macbeth 
chart, the video RGB values would be 224,183,145,109,76,46.

Displaying this video on a calibrated $30,000 reference HD TV monitor 
should reproduce these patches at L* 95.5, 78.7, 62.2, 45.8, 29.6, 
13.6.
If say 2% flare is present on the monitor (for example at home), the 
projected values would be different, here: 96.3, 79.9, 63.8, 48.4, 
34.1, 22.5.

As you can see, L* out is clearly not the same as L* in.
This is sometimes called the system gamma, and this is a required 
feature of the video reproduction pipeline, and follows international 
standards from  ITU and IEC.
Except for copiers, a system gamma greater than 1 is a required 
feature (for user acceptance) for all image reproduction systems 
aiming to please human eyes. For example, film still photography has 
a much higher system gamma than video.

Now, if you prescribe an L* encoding for the video, which set of 
values would you use:
96, 81, 66, 51, 36, 21 or
95.5, 78.7, 62.2, 45.8, 29.6, 13.6 or maybe
96.3, 79.9, 63.8, 48.4, 34.1, 22.5?
Either is wrong, when used in the wrong context.
If I need to restore the scene colorimetry for visual effects work, I 
need 96, 81, 66, 51, 36, 21.
If I need to re-encode the HD TV monitor image for another device, 
say a DVD, I need 95.5, 78.7, 62.2, 45.8, 29.6, 13.6.

In this context, using an L* encoding would be utterly confusing due 
to the lack of common values for the same patches. Video solves this 
by not encoding in L*. (Admittedly, video encoding is still somewhat 
confusing. Ask Charles Poynton.)
Similar examples can be made for print.

When cameras, video encoders, DVDs, computer displays, TV monitors, 
DLPs, printers, etc., are not used for making exact copies, but 
rather for the more common purpose of pleasing rendering, the L* 
encoding is inappropriate. And as noted above, this is reflected in 
current international standards.
Further, as most combinations of displays and printers (regardless of 
TRC) make for very poor copying systems (they mismatch in gamut, 
dynamic range, viewing conditions, etc.), the L* encoding remains 
equally inappropriate here.

Maybe you are constructing a copying system?

Lars Borg

-- 
Lars Borg
Principal Scientist

Adobe Systems Inc.
345 Park Avenue
San Jose, CA 95110-2704
Phone 408 536.2723
Fax: 408 537.4068
borg at adobe.com
http://www.adobe.com