[Openicc] L* was: MS on HDR CMS :)

Chris Murphy lists at colorremedies.com
Fri Feb 15 09:27:25 PST 2008


On Feb 15, 2008, at 11:15 AM, Kai-Uwe Behrmann wrote:
>
> Devices behave like drivers and firmware wish.
> Times of CRT's with a certain gamma are fading out.

Everyone who is building LCD panels are at least trying to target the  
sRGB TRC (not merely gamma 2.2). No one is targeting L*. Few displays  
are sophisticated enough that this can be achieved using highbit  
internal LUTs. Changing display TRC in the video card isn't ideal as  
it is, let alone radically changing it.

> For inkjets at least it is all about the algorythm a driver uses  
> and of
> course its tweaking. I am not shure about offset, but would expect
> similiar relation of drivers and physical behaviour.

All of those are by design in approximately like a gamma 1.8 to 2.2  
defined TRC. Not L*. L* is how *we* work, not how *devices* work.


>
> Why should ECI use one certain gamma, when there are better means to
> match human perception.

First, it's a compromise between capture, display and output TRCs.  
None of those now or predicted in the near future have a TRC like L*.

Second, you don't get to say that L* is better without proof. I hear  
a lot of talk. Words being thrown around that are not at all related  
to the issue making it sound good. This is called "cherry picking"  
and it is not compatible with the scientific method. So far I'm not  
hearing what the problem is, and exactly why L* is a solution. Saying  
L* is perceptually uniform or better matches human perception is  
stating the obvious. I already know what L* is. The question is WHY  
IS THAT RELEVANT to devices that do not have such a tone response?  
Why does it matter at all in a 16bpc workflow let alone 32bpc? No one  
seems able to answer these questions.

Who cares if it matches human perception? That's not a requirement  
for image encoding. Image encoding - RGB values are *device values*.  
They are *device dependent*. They are merely a means of communicating  
signals to *devices*. Who cares what the necessary tone  mapping is  
to get them to do what we want? So long as they are consistent and  
predictable and correlate through a correctly built ICC profile those  
values are referenced back to LAB and to L* already.

>
> sRGB has not a gamma but a custom curve instead, and was long time
> considered the ideal to build LCD monitors for.

CRTs. Not LCDs.

> Now ECI came to the
> conclusion that L* is even better. Why go backward?

Except, it's not always better. And it has been shown to be better.  
Guess what? Saying things does not make it true. I find nothing on  
the ECI web site demonstrating premise and conclusion and testing of  
how ECI arrived at L* being "better" or even they even tested it  
against the sRGB curve.

Chris Murphy


More information about the openicc mailing list