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

[Jan-Peter Homann]

Hello Chris and all,
I think it is better to move this topic to the english ECI mailinglist 
at http://www.eci.org
As ECI has invented and pushed eciRGBv2 with L* encoding, it is better 
to discuss Chris points there.
For me, this will be the last e-mail to discuss L* at OpenICC, but I 
will monitoring and answering on the ECI-EN mailinglist.

Regards
Jan-Peter

PS: details about ink-limits and inkjet linearization with Gutenprint 
should be discussed on the Gutenprint mailinglist...

Chris Murphy wrote:
>
> 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
>


-- 
***********   Neue Adresse / new adress   ************

homann colormanagement ------ fon/fax +49 30 611 075 18
Jan-Peter Homann ------------- mobile +49 171 54 70 358
Christinenstr. 21 ------ http://www.colormanagement.de
10119 Berlin -------- mailto:homann at colormanagement.de

***********   Neue Adresse / new adress   ************