Re[2]: LStar
Re[2]: LStar
- Subject: Re[2]: LStar
- From: Peter Karp <email@hidden>
- Date: Thu, 19 May 2005 15:06:41 +0200
> http://homepage.mac.com/hanspeterharpf/pictures/PhotoAlbum52.html
> As you can see, with any gamma over 1.8 there is an uneven
> distribution of tone values in the shadows.
> L* is the simples curve you can draw - it´s a straight line.
The wording L* is not a curve is irritating IMO. L* is a function
which is defined like most of us know:
http://www.brucelindbloom.com/Eqn_XYZ_to_Lab.html
It's a modifed cubic root (except for the shadows). If you specify L*
as the input (as shown in the graph), of course L* output will be a
straight line with a slope of 1 ;-)
But you could specify gamma 2.2 as input values and then L* will be
a "curve" ;-) You can "play" with different input/outputs in Bruce
Lindbloom's java applet on his homepage:
http://www.brucelindbloom.com/CompandCalculator.html
> L* can be described in a very simple equation: L*=(RGB)/2.55
This is only true, when you calibrate the display to a transfer
function which follows L*.
> And, L* is the visually equidistant like in L*a*b*.
Yes. We have to keep in mind that L* was defined for specific viewing
conditions. If the surround changes, L* no longer will describe a
visually equally spaced gradient. Sometimes we tend to forget that
colorimetry was never intended to describe the appearance, but "only"
to say wether two color samples look similar under a specified viewing
condition!
The idea to calibrate a display to a non-gamma transfer function can
be interesting. With appropriate color spaces this might be a good way
to go (with gamma based color spaces you'll loose what you have won in
the first place). But it's nonsense to state that then "everything
will be fine (straight ;-), because changing viewing conditons
(luminance of the display, illuminance of the proof and the surround
and ambient light) are not taken into account. Right now we're dealing
with very simple models. CIELAB can be seen as a very simple color
appearance model and works suprisingly well for many cases, but can
not describe our appearance perfect.
> Since TFT monitors do nat have a native hardware gamma, it is
> nonsense to force them into a (artificial) gamma behavior that does
> not represent the human perception of brighness steps at all. Gamma
> can always be only an approximation, as you can see in the graph. So,
> why not go for the real thing?
L* is surely _one_ possible way to calibrate a flat panel. Why choose
a gamma instead? One reason is that you're working with a CRT (or
mixed with CRT's and TFT's) and you want one calbration/working_space
for all of your desktops or you simply want to be compatible with the
"history". In the long run L* (or another transfer function) can be
interesting. But what many seem to forget is that Photoshop (or any
other CM-aware application) honors the monitor profile and adjusts the
output which is sent to the display, so that the specified (via the
profile embedded in the picture) color values are shown similar on
different displays, regardless of the used transfer function of a
specific display. Lighter grays for 1.8 gamma vs. 2.2 (or L*) are
outside a colormanaged workflow, but most of us will be interested to
see what's visible _insdide_ a colormanaged workflow. So I'm not
saying that it's totally unimportant to which transfer function you
calibrate a flat panel display (or a CRT, where you only can
"calibrate" the transfer function with the means of the graphics card
LUT), but I think that other choices influence your CM-experience much
more then that (proof light, spectra of the proof inks...)
Best regards
Peter
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
| References: | |
| | >Re: LStar (From: Karl Koch <email@hidden>) |