[argyllcms] Re: ArgyllCMS V0.70 Beta 7 test now available.

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sun, 21 Oct 2007 11:47:46 +1000

Mark wrote:
OK, I just did all steps and have the ICC now. Compared to another profile I created a while ago with the Spyder2 software, I like the one Argyll created more - both have quite different white points.

I'm not sure you should notice this unless you are running absolute
colorimetric intent.

I just want to understand better why so many steps are needed to get the ICC: dispcal took lots of readings, and as the name says calibrates the display. Couldn't the .cal file directly be used to create the ICC file? Or am I missing something.

The .cal primarily contains calibration information - how to
set the device LUT's to conform to a particular behaviour.
It doesn't contain information on how the device behaves
with that calibration (ie. it doesn't contain characterization
information for the device in a calibrated state).

So gathering this information is a separate couple of steps.

It might be possible to create a lower accuracy matrix profile
during the calibration process, but I haven't looked into exactly
what's needed to do this yet. You wouldn't have the option of
creating a CLUT based profile though, you would forgo choices
about how many patches to use for the calibration, and I'm
unsure of the accuracy compared to doing a separate profile
since I'm trying to minimize the number of measurements during
calibration, but none the less I may add this as an option at
some stage.

I created a matrix profile, I do not understand why I have to specify another icc profile in order to create a LUT based profile.

A LUT profile allows for the possibility of gamut mapping for the
perceptual and saturation intents, by use of either of two of the B2A tables.
Gamut mapping entails mapping gamuts between a source gamut and a
destination gamut. While the device you are profiling defines the
destination gamut, there is no defined source gamut unless you specify one,
ie. by providing another ICC profile to define it.

Any (ICCV2) profile creation process that is creating perceptual and/or
saturation intent tables, and does not require a source
gamut to be defined, is merely fudging the gamut mapping.

ICCV4 profile creation takes a slightly different approach to
avoid this issues, but the consequence is that you end up
locked into saturation intent using anything other than
the colorimetric table with ICCV4. (ICCV4 isn't currently
supported by Argyll).

For a LUT based profile, where gamut mapping is desired, then a source profile will need to be provided to define the source gamut. For instance, if the display profile was likely to be linked to a CMYK printing source profile, say "swop.icm", then the following would suffice:

Could you please explain me what this does.

The gamut mapping maps specifically from one gamut (the source)
to the destination (the device). It will be tailored specifically
for that source gamut. This means that ideally a new destination profile
should be created every time a new source is chosen to link with that
profile (Don't blame me for this, this is how ICC2 is defined!).
This can be a bit impractical, so one general approach to
setting up the gamut mapping, is the one I explain in
"Typical usage scenarios and examples":

 Gamut mapping has the most dramatic influence when the source
 and destination are different fundamental device types,
 ie. Additive RGB vs. Subtractive CMYK. So it can work quite
 well if the colorimetric table is used when linking with sources
 of the same type, and perceptual if linking with devices of
 the opposite type. To work this way, a source profile of the
 opposite type should be specified as the source gamut during
 profile creation, since it is what's used to create the
 perceptual and saturation intent tables.

 So to work things this way, when creating an RGB profile, one would
 provide a typical CMYK profile as the source gamut.
 When creating a CMYK profile, provide a typical RGB profile as
 the source.

 Then when linking with the same type, use colorimetric,
 and when linking with the opposite type, use perceptual.

Of course this may not work for you if you have little control
over the intents, want some different sort of reproduction
(ie. saturation) etc. You may want simply to use a source
gamut/profile that is representative of typical source spaces
you will be linking to.

For those really after the best quality results and best control,
then I'd really recommend a device link workflow. You get to
exactly define your gamut mapping (including black preservation
etc.), and the device link avoids double conversion, particularly
though the lower precision B2A tables.

Graeme Gill.

Other related posts: