[argyllcms] Re: gamut mapping
- From: Graeme Gill <graeme@xxxxxxxxxxxxx>
- To: argyllcms@xxxxxxxxxxxxx
- Date: Thu, 23 Jul 2009 13:14:58 +1000
nome cognome wrote:
I read I have to use appearance space in tiffgamut if I intend to use
the resulting gamut with collink. I can trigger it with the -pj
switch, but I cannot understand what's the intent transform (the -i
switch) in this step.
If you don't set -i, it will default to the right thing for -pj.
If you know what you're doing, you could choose something else
for the intent. [The underlying logic allows an orthogonal
choice of ICC table (colorimetric/perceptual/saturation),
absolute/relative conversion, and PCS space. "Absolute"
appearance (Jab) space doesn't have much meaning in
the context of a single profile, but in the context
of linking means that the source and destination space is forced
to have the same parameters. ]
Once I have extracted the gamut I'dd like to use
the perceptual intent with collink, but while extracting the gamut I
don't even know what's the aim of choosing an intent!
It determines the ICC table used, as well as the absolute/relative
white point treatment. When combining a gamut from tiffgamut
with collink, it's necessary to use consistent choices.
I read that with the aboslute intent (and the -pj switch of course) I
will have a white point mismatch between source ad destination
gamuts[1], so it should be better to use the relative intent (-ir)
instead of the absolute one[2] (-ia), but in another mail[3] is
suggested to use -ia. Why?
It all depends on context, so I can't really say.
Note that attempting to use "Absolute" appearance intent
in combination with a separate source gamut is likely
to be problematic, because there is no way of
conveying the source/destination common white point that will be
use for the "absolute" appearance conversion from collink to tiffgamut.
On the documentation I read: "Note that the CIECAM02 output space
selection by default uses the colorimetric transform of the profile
resulting in the appearance of the native device". So the default
intent is absolute or relaitive, but does not specify which one.
That's because it's not relevant. In practice it uses absolute
colorimetric from the underlying ICC transform, but an appearance transform
is equivalent to the relative colorimetric ICC one, since the viewer is
assumed to be adapted to the white point.
The "absolute" appearance transform is not really absolute, it just
forces a common set of appearance parameters between source and
destination colorspaces in collink, achieving a similar effect
to the use of absolute colorimetric linking.
Furthermore I found something very strange: "The default intent will
be absolute colorimetic for L*a*b* output, and CIECAM02 appearance for
Jab output." What? What's the "CIECAM02 appearance" intent? I never
heard about it and there isn't any "CIECAM02 appearance" option for
the intent switch (-i). I'm _really_ confused!
There are multiple possible ways of specifying and talking about
such things, depending on whether the options are treated orthogonally,
or combined into all possible combinations.
So it's possible in some cases to choose a combined treatment
(ie. choice of ICC table, appearance space transformation
and PCS of Jab) as an a single "intent" choice, or by
specifying all the bits separately.
I found this[4] message in the mailing list, you talk about Absolute,
Relative and CIECAM02 output color space.
From wikipedia[6]: "Absolute color space: a color space in which
colors are unambiguous, that is, where the interpretations of colors
in the space are colorimetrically defined without reference to
external factors. CIEXYZ and sRGB are examples of absolute color
space. The L*a*b* is sometimes referred to as absolute, though it also
needs a white point specification to make it so. A non-absolute color
space (like RGB) can be made absolute by defining its relationship to
absolute colorimetric quantities (ex. define an ICC profile).
Converting between two non-absolute color spaces or between absolute
and non-absolute color spaces is almost a meaningless concept."
You need to keep in mind that wikipedia is not particularly accurate
when it comes to specialized subjects, and that there is a difference
between the normal color science meaning of absolute and ICC meaning.
Loosely, the the normal color science meaning is absolute level vs. relative
level, while the ICC meaning is absolute white point vs. normalized to the white
point.
From xicclu documentation[5]: "Normally the native PCS (Profile
Connection Space) of a device or abstract profile is used, but the -p
flag allows this to be overridden."
So with the -p switch I can choose the output color space, but why an
output color space defined through the -p parameter becames "Relative"
if I use a particular intent? What do you mean with "Relative" output
color space?
Because CIECAM02/appearance space is a special case, in which
"absolute" doesn't have a meaning. There is no such thing
as a real absolute value in CIECAM02 space, since (by definition)
it always takes as a parameter the white point the observer is
assumed to be adapted to. I've used this unused combination
to add a useful option to collink, that of forcing a common
set of appearance parameters between source and destination,
to achieve an analogous intent to that of using absolute colorimetric,
and called it "absolute appearance".
I consider this topic very interesting, so I surfed the web searching
for informations about it and I found lots of interesting
books[7,...,12]. Can you suggest me an easy one to start from?
Not really, since you seem to be focussing on Argyll specific
implementation details.
The -c parameter allows choosing a set of viewing conditions (which
must be the same used with collink[2]), but which one should I choose?
pcd?
Whatever is appropriate for your viewing situation. The simplest
is to choose one of from the enumerated choices.
Last but not the least: noise. What's the best way to reduce the
impact of noise on the gamut size and so on the gamut mapping? I think
that the color popularity filter will help a bit, but I'm not sure if
it's the best way to achieve the goal. Do you suggest me to use the
color popularity switch, downsampling, noise reduction or a particular
filter? I don't care about processing time. I found an interesting
discussion about it[13] where someone suggested to use a median cut
quantization algorithm for gamut mapping purposes. Have been done
tests about it?
Some people reported that for real world images, the gamut
created was overly large, encompassing noisy or small pixel
count values. There are two views of this phenomena, one is that
it's a tiffgamut issue and that the resulting gamut should
reflect the visually dominant gamut not the low pixel count
low visibility colors. Another view is that it's a gamut representation
and gamut mapping issue, and that rather than being a solid hull,
a gamut should be a probability density plot, with the density
representing the importance of each color in the gamut, and
that the gamut mapping should deal with trading off the
mapping of high importance colors vs. low importance colors.
The latter would be a nice approach to take, but the pragmatic
solution was to put the important vs. unimportant color
cut-off threshold choice into tiffgamut. There are certainly
other possible ways of dealing with this than a popularity filter,
and you're welcome to experiment with them and report back.
I certainly don't claim that what tiffgamut provides is
the only or best way of doing this, since I've only used it
in a fairly limited fashion.
cheers,
Graeme Gill.
Other related posts:
