[argyllcms] Re: icclink -G and source gamuts /-profiles

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sun, 11 May 2008 15:51:52 +1000

Klaus Karcher wrote:

Graeme: what do you think about setting the -p switch for cctiff as default?

No, that's not really the idea of it. It's strictly for comparing the
behavior. The whole point of cctiff is to do the transformation
at high speed.

I'm not at all surprised that there are issues with blacks if
you are using profiles with a gamma of 1.0.

The way cctiff/icclink are setup at the moment, is that they
make certain assumptions about the per channel curves shape,
in making use of them for the per channel curves for
the overall transform.
One of the assumptions is that the curves transform from
the device space to a roughly perceptual space (Argyll CLUT
base profiles aim for exactly this). The multi-dimensional
transform that then does all the work is defined by a grid,
and a roughly perceptual space will mean that the grid points
are located roughly evenly in perceptual space.

Gerhard noticed an issues caused by this some time ago,
and that is why there is a "hack" to treat XYZ PCS
profiles differently - their per channel curves are
not used as per channel curves for the overall transform,
since they would cause the input space to the 3D Lut
to be evenly spaced in linear light space, causing
poor grid resolution at the black end.

The assumption then though, is that the basic encoding of the
device space is roughly perceptually linear, i.e.. that
it has a gamma of somewhere between 1.8 and 2.4.

When you use a device space that is linear light encoded
with an XYZ PCS profile, it breaks this assumption and
the grid spacing is not good at the black end.

Using the -p switch uses the defining floating
point transform for each pixel, so it avoids this
issue at great cost to speed.

My plan is to correct these issues at some stage by
applying a similar approach to the per channel
curve creation of profile (or perhaps a simpler
heuristic in the case of icclink) to create
per channel input and output curves, and so
ensure that the 3D lookup grid points are well placed.

In the mean time it's probably a good idea to stick
to color spaces that encode the linear light
space with a gamma somewhere between 1.8 and 2.4,
so that the encoding is efficient, doesn't
suffer problems in the black if truncated to 8 bits
per component, and doesn't suffer from issues
when transformed through 3D CLUTs without
the use of optimized per channel curves.

Graeme Gill.

Other related posts: