Re: some thoughts on CIELAB, part 1
Re: some thoughts on CIELAB, part 1
- Subject: Re: some thoughts on CIELAB, part 1
- From: Robin Myers <email@hidden>
- Date: Fri, 07 Feb 2003 08:29:07 -0800
I have split my response into two separate messages.
Part 1.
Graeme Gill wrote:
>
>
Robin Myers wrote:
>
> You can easily discover this "hooking" encoding effect by taking values
>
> for constant hue and lightness (I used Munsell values) and plot them on
>
> an a*b* diagram.
>
>
What difference does it make if they "hook" when projected
>
into the a*b* plane ? Any 3D curve can be made to look like a hook if you
>
project it in the right direction into 2D. There's only a problem if
>
the 3D space folds back on itself, and since the mapping from XYZ
>
to/from L*a*b* is monotonic, the L*a*b* itself doesn't cause this
>
problem.
The hooking makes a difference if the programmer writing the profile
generation code uses simple extrapolation code for taking the target
measurements and extending them for creating a larger sampling than the
target provides. By not understanding the "hooking" and the curvature of
constant hue lines the resulting profile creates purple skies instead of
blue ones. I have experienced this problem with many clients and several
different profile generation packages.
>
> As for XYZ being a worse choice I disagree. It is linear in color
>
> mixing,
>
>
Only true when mixing light. Most colorant mixing models
>
are based on XYZ or spectral reflectance values, but the
>
useful ones aren't linear. L*a*b* isn't used in
>
profiles that assume an underlying mixing model, they
>
are used in formats that are general purpose, and
>
make no assumptions about the devices behaviour (ie. CLUT
>
based profiles).
I'm not sure what you mean by "useful" here. I have used XYZ mixing
algorithms with all manner of color production devices quite
successfully. By successful I mean that within the gamut of the device I
have achieved colorimetric reproduction to within the error of
production of the device. The technologies I have successfully profiled
this way include CRT, LCD, thermal transer, dye diffusion thermal
transfer, printing press, ink jet, hot wax ink jet, electrostatic liquid
toning and electrostatic solid toning. The algorithms used are
documented in a US patent 5,909,291.
The output device ignorance in the current ICC model means that often
gamut mapping is performed when it is totally unnecessary (i.e. when the
source color is within the gamut of the destination device) or that
intelligent gamut mapping (using the source and destination gamuts to
adjust the amount of mapping) is extremely difficult, if not impossible.
>
> all the coordinate values are positive, when projected onto xy
>
> diagrams, lines of constant hue exhibit much less curvature.
>
>
Constant hue in what terms ? Perceptual ?
Perceptual as defined by the published Munsell values from Wyczecki and Stiles.
>
I didn't think there were any "golden" standards on what
>
defines a perceptually constant hue. Munsell values are
>
often used as a guide, but there are several other test
>
sets being used in Color Appearance Model development.
>
L*a*b* is bad in the blue region, which is why it's
>
not a good choice for large scale color modifications needed
>
for things like Gamut mapping, but this isn't relevant
>
as a means of representing color. Because L*a*b* is more
>
nearly perceptual than XYZ, it is a much better choice
>
when quantization is taking place. There is a reason you
>
can't use 8 bit XYZ Lut ICC representation !
There are at least two sets of perceptual "standards" that I know of,
Munsell and OSA. Unfortunately, I do not have a set of XYZ values for
the OSA standard and so I have used Munsell for basing my analysis of
L*a*b* space.
<end of Part 1>
Robin Myers
_______________________________________________
colorsync-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/colorsync-users
Do not post admin requests to the list. They will be ignored.