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

[Peter Karp]

Chris,

> "The focus of the eciRGB_v2 profile still is on the print and  
> publishing industry"

> That's predominately an 8bpc workflow, and a TRC that's closer to  
> gamma 1.8 function than L*. So I don't see the compatibility or  
> usefulness of L* here.

[...]

> So I'm all ears if someone has a compelling explanation about L* and  
> ECI-RGBv2.0.

I live in germany and many people here promote L* if that would be the
holy grail and using L* will bring you to color heaven ;-)

I myself think the genereal idea behind L* is a good one and is close
to the general idea of the DICOM transfer function you've mentioned
too. But so far no one of the supporters could prove a real advantage
in daily usage to me. I'm pretty sure that you can create test
scenarios where you show that L* has some advantage over another TRC,
but so for other TRCs as well ;-)

I agree with Jan-Peter that an important match is the working space to
the monitor TRC. You stated that almost all device TRCs will not match
L*. That's right. So when I have a device which is limited to 8
bits/channel (like all current LCDs are maximum 8 bits + 2 bits FRC)
it's a good idea to calibrate the device to a TRC which uses the same
'gamma' like the working space, thus minimising conversion errors
(lost tone values). I must add that I speak of hardware calibrated
displays. For software calibrated displays the situation might differ,
because some/many tone levels will already be lost when adjusting the
TRC by the means of the video graphics card LUT!

My understanding equals with your words that the best way is to
minimize conversions -- especially in 8bit-spaces.

To summarize: I think that L* is a general good idea but needs closer
examination in which scenarios it's benefical or non-productive. L* is
often promoted in relation to a "good softproof". From my tests so far
I'm pretty sure that other parameters are _far_ more important to
achieve a good softproof and the choice of the TRC is most of the time
not that important, assuming we'll make intelligent choices in general
-- resulting in few conversions, many possible matches of device and
working space TRC.

You've mentioned the output and I have the impression that by many
advocates  of L* this final, but often most important step is not
taken into account and a printer nor offset press will have a L* TRC.

What annoys me with L* (and ECI-RGB2 for that matter) is that often
it's stated that this would be superior, _without_ mentioning the pre
conditions. Don't let us (I'm not talking about you, but many others)
forget that in color nearly everything is relative and L* was created
for specific conditions too. In the report of the ECI meeting (from
Nov. 2006 if I'm correct from the top of my head ) where ECI-RGB2 was
agreed you even find the note that L* brings only marginally
advtanges and that no problems with gamma 1.8 coded pictures are
known. So the 20 ECI members who voted for L* (100% btw) made a
decision which was known not to bring real advantages...? :-o

So I'm with you and I also don't understand all the hype about L* (I
think I posted a message to the colorsync list quite some time ago
with the subject "L* hype" or something like that... ;-) ) and still
wonder who, how, where and when someone made a deeper evaluation of
the pros and cons of L* TRC and to which conclusion he/they came. It
boils down to determine and test how many levels real world systems
can discriminate and then to make sure that the weakest link in the
chain will loose as few as possible levels. This should bring the best
results. It might be that L* could be needed there, but it could also
be that a better TRC for working space/monitor could be a TRC close
to the output device TRC?

Best regards
Peter Karp