[argyllcms] Re: RGB printer profiling, A2B tables

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Fri, 12 Jan 2007 13:00:23 +1100

Thomas Baumann wrote:
looking into some profiles, I noticed that 'profile' generates only one
A2B (printer to PCS) LUT linked to all rendering intents, while profiles
made with commercial software (Bill Atkinson's) either contain all three,
or at least two A2B tables with saturation mapped to perceptual.

While proofing works well the way it is, the option to remap printer
output data perceptually could be useful - if I got it right (still CM
newbie). Is there a way to generate the missing A2Bx table(s), without or
with small changes to the source code?

Other profile creation software may do such things, but do you
have any idea what they are doing, or why they are doing it ?

I certainly don't know what they are doing or the purpose of such
mappings in the A2B tables when applied to ICCV2 files. I can
imagine using such an approach to improve perceptual rendering
intechanegebility amongst profiles all generated by the same package,
but it may actually work against intechanegebility with profiles
from other packages.

The ICCV4 format does articulate a practice that involves having
different A2B tables for different intents, although the overall theory
is not really explained. I had a number of discussion with the people
from H.P. who are working on applying the ICCV4 reference gamut to
the sRGB colorspace profile, in order to try and understand how it
was meant to work, and this is the best I came up with:

The idea for ICCV4 is to use the PCS as a reference medium with
a gamut, and to have the A2B transform the device gamut into the
reference gamut, and the B2A transform the reference gamut back into
the device gamut. This is an idea that seemed to be the only logical
purpose of having separate intent A2B tables, and something that
addresses (to some degree) the issues of trying to do gamut mapping
at a point when the source and destination gamuts are never known
at the same time.

It seems like this approach will improve things quite a bit amongst
non-critical users of color (ie. "home user", "office") type users.
For more serious uses, I have a number of doubts at the moment. My
concerns are:

 The two gamut mappings that get applied in an overall device to device
 conversion add extra inaccuracy in the color rendering. It's hard
 to accurately hit a destination gamut surface and provide a smooth
 mapping. Doing two mappings doubles this inaccuracy.

 There is no guarantee that gamut mappings from two different vendors
 will complement each other - ie. say the source and destination gamuts
 were almost the same, that the transformation into the reference space
 and then out of the reference space will be done in a way that won't
 lead to color overall distortions. There are quite a few different
 gamut mapping algorithms out there, and they don't do the same mapping.
 Mixing different vendors profiles will almost certainly mean mixing
 gamut algorithms, and they won't therefore undo each other accurately.

 Not all useful mappings can be inverted. For some purposes, it may
 be that the gamut mapping has to severely compress, and should
 clip once beyond the reference gamut surface. The A2B and B2A mappings
 within a single profile are meant to be inverses, but you can't invert
 a clipping.

My main concern is that this scheme imposes certain behaviour on the
gamut mapping that, (in my view) force it to be more of a saturation
intent mapping than what I've viewed a perceptual mapping should be.

Here's my definition of some intents:

Perceptual:
        Source surface gamut colors that are out of the destination
        gamut are compresses, while keeping proportionality between
        within gamut colors. Source surface gamut colors that are
        within the gamut of the destination gamut are not changed.

Saturation:
        Source surface gamut colors that are out of the destination
        gamut are compresses. Source surface gamut colors that are
        within the gamut of the destination gamut are expanded. In
        both cases proportionality is maintained in the overall
        response.

Enhanced saturation:
        Same as saturation, but with an added "enhance saturation"
        rendering.

The ICCV4 reference medium gamut scheme forces the perceptual rendering
intent to be what I've called here saturation intent. There's no reasonable
way that I can figure, of not expanding the source gamut to meet the
destination gamut, because there's still no way of knowing what the
two gamuts are at the same time. For some purposes this expansion
will be fine, and in fact will be seen as good (popular users of
color often respond well to bright, saturated images, even if they
aren't accurate), but for more serious use, the loss of this
distinction between perceptual and saturation may be more of an issue.

If you expect your saturation intent to significantly enhance saturation,
then there can still be a distinction between the two gamuts, but it's
one of degree rather than kind I think with ICCV4.

Anyway, to come back to where we started, doing an ICCV4 scheme
is not the basis on which the Argyll ICCV2 profiles are based. They
are based on doing the gamut mapping once, in the B2A table,
or at link time. Within this scheme, there is no reason for the
A2B tables to do anything other than describe the color response
of the device, hence only one table. Since ICCV2 doesn't pin down
how such things are to be done, intechanegebility with other profiles
using A2B and B2A tables is crap shoot. If you don't wish to take
such chances, then it's best to only use the colorimetric tables,
which are reasonably well defined. Doing specific gamut mappings
using just the colorimetric tables is what icclink -g or -G
are all about.

Klaus Karcher wrote:
> Confusing, since http://www.argyllcms.com/doc/profile.html says: "If a
> source gamut is specified, then an ICC Version 2.4.0 profile will be
> created with a full complement of A2B and B2A tags to support all intents."

Sorry, at the time I wrote that, I wasn't aware anyone created ICCV2 profiles
with other than one A2B table. I'll amend the sentence.

Graeme Gill.







Other related posts: