[argyllcms] Re: Custom Illuminant

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Wed, 16 Jul 2014 12:05:29 +1000

robert@xxxxxxxxxxxxxxxxxx wrote:

Hi,

> -g uses a gamut file which is produced either from tiffgamut (from a set of
> images), or iccgamut (from an icc profile). <<There is no advantage to using
> an icc profile gamut with -g as this can be better specified with the -s
> flag and no -g flag.>> 

This isn't accurate. You can get away with it in colprof, but not for collink,
so it's worth keeping it straight.
The source ICC profile specifies the source colorspace that the images
are encoded in. By default, it also implies a source gamut, that of
the colorspace itself. The -g flag allows overriding that assumption
and specifying a different source gamut, encoded in the ICC's colorspace.

Summary:
   Source Profile = ProPhoto.icm, Image gamut = sRGB is quite
   different to Source Profile = sRGB, since you are specifying
   different encoding spaces.

> I'll refer to this gamut as the Custom Gamut, or CG.

I'd prefer to stick to the Argyll nomenclature, and call it image gamut.

> <<If there are image colors outside SG, they will be clipped to
> the DG boundary.>>

That should be impossible, because by definition an image gamut of an
image encoded in a particular colorspace, can't be outside the colorspaces 
gamut.

Yes, I think my code will cope if this does happen, but the only way it can
happen is if you create an image gamut of an image in a different color space
to the source color space. Once again, you might get away with configuring
a workflow that is OK in this situation with colprof, but not with collink,
and the chances of getting it all wrong are quite high.

> <<The -g flag effectively replaces SG by CG (with the white and black points
> coming from SG), so that the mapping now effectively 'squeezes' CG into
> DG.>>

Close enough.

> <<The effect is a Perceptual mapping that is less drastic than the full SG
> to DG mapping (which can result in desaturation of the more saturated
> colors, for example, because they are shifted to inside the DG gamut if SG
> is larger than the image gamut).

That depends strictly on how the image gamut compares with the source colorspace
gamut, and how that compares with the destination gamut. The most dramatic
difference is when the source gamut is much larger than the destination, but
the image gamut is not.

> The problem with it is that if the image
> contains colors that are outside CG, these colors will be clipped to DG, and
> so the perceptual relationship will no longer be fully maintained.

That can be a good thing - that's why tiffgamut has the ability to filter
the colors. You probably don't want to compress the gamut just to accommodate
a couple of percent of the image that are highly saturated colors - compressing
the bulk of the images gamut less and clipping those few pixels may well give
you a better visual result. (This is why sometimes people prefer relative
colorimetric when the bulk of the image gamut is within the destination
gamut, even if small parts are outside.)

> For this
> reason, profiles using -g should only be used when the image gamut is known
> to be inside of CG: this can only be guaranteed if the image is part of the
> set of images used in tiffgamut to make CG.  With caution, the profile could
> be used for an image that was not used to created CG, IF it is known, within
> reason, that its gamut is approximately within CG.>>

There are no hard rules there. When you have images stored in a wide gamut
space, then it's a matter of judgement in relation to the images themselves
as to how to define their gamut for the purposes of rendering them
into a restricted colorspace. Critical cases may involve manual adjustment,
just like they always have.

Images already rendered into a more restricted space (ie. sRGB)
can usually be dealt with much more straightforwardly.

(Cue discussions of "early binding" vs. "late binding",
 "image referred" vs. "output referred" etc.)

> The reason for this sort of approach is to attempt to reduce the
> desaturation that can be the result of a Perceptual mapping from a large
> color space to a smaller one.  (It is also applicable to Saturation
> mappings).

That's one way of putting it. Another way is that it's simply
nonsense to use a wide gamut color space encoding as the source
gamut for gamut mapping, and you get what you deserve if you
try it.

> <<If the image gamut is not known to be within CG and we do not wish to
> produce a new profile . but we wish to soften the full SG to DG squeeze, an
> alternative strategy to using the -g flag is to do a Relative Colorimetric
> mapping to an intermediate-sized gamut (for example from ProPhoto to Adobe
> RGB), followed by a Perceptual mapping to DG.>>

Maybe. Normally using the right options with tiffgamut + collink + cctiff
is all that's needed.

> As a slight aside, how are profiles which have no source profile specified
> usually made, do you know (for example by i1Profiler)?  Must they assume
> some intermediate gamut like Beta RGB (smaller than ProPhoto but larger than
> AdobeRGB), or is there some alternative algorithm that doesn't require the
> source profile?

I don't know - it's always been a mystery, and is one of the fundamental
puzzles around the ICC profile format. My guess would be that they use an
unspecified source gamut (a little like the PRMG) and/or they use a more general
non-linear compression curve which starts to compress within (say) 20%
of the gamut boundary and then asymptotes to a flat line (ie. a "soft clipping"
type curve). The results are unlikely to be optimal.

Graeme Gill.


Other related posts: