[argyllcms] Re: xicclu -g predictability issue
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Mon, 31 Jan 2011 14:57:18 +1100
Gerhard Fuernkranz wrote:
I was furthermore curious about the "kh" and "kz" locus in this small region
(see
attached plot).
While the "kz" locus is indeed smooth, the "kx" locus is discontinuous at two
points.
So any other black locus derived from the "kx" locus is supposed to be
discontinuous
too. But I'm curious where this "jump" is coming from. Is this just the result
of
inverting an almost flat, but still noisy/wavy region of the A2B table [i.e. a
region
which would be monotonically increasing or decreasing, if there weren't some
ripples
which break the monotonicity]?
The way I would explain it (assuming it's not a bug), is that there are several
possible solutions for at that point, and so the maximum K solution "jumps"
as a folded edge comes into range. A way of investigating in more detail whether
this is the case, is to go into xicc/xlut.c about line 940 in the
icxLuLut_inv_clut_aux()
function, and enable the "#ifdef NEVER" code. This will then report the possible
solution K locus segments for each lookup.
Should I conclude that the given L*a*b* color can be represented with CMYK
combinations
with K levels of 0.23...0.38 and 0.83, but not with any K levels in between? If
so,
then this would be quite strange as well.
I've certainly seem bifurcated black regions in some profiles.
Furthermore I noticed that "xicclu -fif -kz" and "xicclu -fif -kx" reported
different
subsets of my region as "clipped". Actually I had expected that both would
report the
_same_ sets of colors as "clipped". Either a given color can be represented
with at
least one CMYK combination, or it cannot (and my understanding is that
preserving
colorimetry takes precedence over the black generation rule, so if an ambiguous
CMYK
representation of a given color is not possible, then kx and kz should simply
return
the same CMYK numbers, shouldn't they?).
Hmm. yes, they should be the same.
Graeme.
Other related posts:
