FreeLists / argyllcms / [argyllcms] Re: B2A mapping of out-of-gamut colors

[Graeme Gill <graeme@xxxxxxxxxxxxx>]

Klaus Karcher wrote:

> Thomas Baumann wrote:
>
> > according to the command line help the meaning has changed since the last
> > official release - I am using Beta 7 because it supports the DTP20. The
> > former -b switch is now -m (merge).
> You are right. Seems like the documentation does not reflect the latest 
> changes yet.
Yes, it doesn't reflect the current xicclu.

> BTW: there's another difference I'm excited to discover:
>
> doc7:
> -S    Use internal optimized separation for inverse 4d [NOT IMPLEMENTED]
>
> usage:
> -S    Use internal optimised separation for inverse 4d
Sorry, this remains unimplemented.

> To figure out the influence of the Helmholtz-Kohlrausch-Effect in this 
> case I compiled a xicclu version with XICC_USE_HK set to 0 (xicc.h line 
> 49), but it didn't change a lot:
> xicclu -fif -ir -a -b SP3800_PSPP_2880_ARG2.icc
> 9.000000 0.000000 80.000000 [Lab] -> Lut -> 0.982441 1.000000 0.000000 
> [RGB] (clip)
> [Actual 90.854331 -3.834409 115.588589, deltaE 89.338580]
>
> xicclu_wo_hk -fif -ir -a -b SP3800_PSPP_2880_ARG2.icc
> 9.000000 0.000000 80.000000 [Lab] -> Lut -> 0.963003 1.000000 0.000000 
> [RGB] (clip)
> [Actual 89.124108 -6.217807 113.343536, deltaE 87.007616]
The magnitude of the effect depends on the hue angle. You may find
it's greater with some other colors.

> > As to unreal colour, I know that Lab 9/0/80 is not a "real" colour. But
> > you get there easily if you change the brightness of a real photograph in
> > Lab mode.
> That's one of the reasons why I think Lab is a bad editing space (at 
> least in Photoshop).
It's quite difficult dealing with such non-real colors. Certain
colorspaces behave certain ways, but that doesn't make any
particular treatment "correct". CIECAM02 is somewhat different
to L*a*b*, and has a series of extra difficulties with regard
to some areas of the non-real space as well. If compiled
with L*a*b* as the gamut mapping space you may get a result
closer to what comes out of other packages, but this doesn't make
it right or wrong. The basic problem is how to you evaluate
0 divided by 0 ? Is it very big, 1.0 or very small ?
To translate to colorspace, is a very saturated color
with L* of 0, black (because L* is 0), or lighter than
that and saturated because of the Helmholtz-Kohlrausch-Effect ?

Basically you are operating outside the valid range
of the colorspace (even though it's representable), and
observing it's mathematical nature which at that point
has no correlation with anything that can be observed.

> I'm not sure if I would prefer that, but I think you can tweak profile's 
> clipping behavior when you change line 49 of profout.c:
> #define USE_CAM_CLIP_OPT        /* Clip out of gamut in CAM space rather 
> than XYZ or L*a*b* */
> and use the -ax flag for profile
My current code has a #define at the top of xicc.c that allows switching
between L*a*b* and CIECAM02 for clipping and gamut mapping. I suppose
such a thing could be made a run time option, although it would
complicate documentation and understanding of how things works a great deal.

Graeme Gill.