[argyllcms] Re: Custom Illuminant

  • From: Graeme Gill <graeme@xxxxxxxxxxxxx>
  • To: argyllcms@xxxxxxxxxxxxx
  • Date: Sun, 06 Jul 2014 14:20:43 +1000

robert@xxxxxxxxxxxxxxxxxx wrote:

Hi,

> - Why does Argyll provide the gamt tag?

It's required. The resulting file wouldn't be ICC complaint if it was missing.

> ... and I
> assume that if it is used and the gamut mapping has already been done in the
> cLUT (I assume that any XYZ value of 65535 indicates OOG?) that it won't do
> any harm (or much harm for values close to but inside the gamut).

I doubt any software looks at it. If one is interested in the gamut,
then it's far safer to generate your own gamut boundary representation
using the A2B data. A flaw in the ICC profile format though, is that it doesn't
have any representation for ink limits, and the ink limit will partly
determine the gamut extent. (Not applicable to CMY or RGB devices of course.)
One can make some guesses from the B2A table contents, but this is not as
accurate as knowing exactly how the ink limit was set.

If one were drafting a modern color profile format, then I suspect a
triangle surface representation of the gamut would be be more likely
to be useful than the current tag type.

> - Regarding the AtoB mapping: I've had another look at the i1Profiler
> generated profiles and even though it has data in all three tags, the data
> is the same - so it appears to be using the Colorimetric mapping for all
> three, as in Argyll ... just wasting space.

Note that tag types can be shared, so it may or may not be using more room.

> - I'm not sure if I mentioned this, but Soft-Proofing with Simulate Paper in
> Photoshop does the equivalent of: Convert to Profile with selected intent;
> Convert back to working space with Absolute Colorimetric.

Right, but exactly how does it convert from the printing device to display ?
You say "with Absolute Colorimetric", but for the printer to PCS _and_ PCS to 
display, or
just the first part ?

Note that the ICC seem to think that people expect/want the "half absolute" 
conversion,
where it becomes a relative colorimetric interpretation of the absolute 
appearance
of the print (hence the forced use of the chromatic adaptation tag in V4). This 
is not
 strict soft proof. A strict soft proof is absolute for both, so that the XYZ 
values on
the screen are the same as the XYZ of the (expected) print.

> I read your note "About ICC Profiles and Gamut Mapping" and I would like to
> clarify a couple of things:
> - You say: "The colorimetric intent is meant to convey the exact device
> color behaviour, without any gamut mapping". Clearly there is clipping that
> occurs on output to a device like a printer.

Yes, there will be clipping if you specify a color outside the device
gamut in any colorimetric conversion from PCS to device space.

> Are you saying that the
> clipping is effectively left to the printer, so the CMM will just output
> colors without caring if these colors can be printed or not?

No, this scenario is virtually impossible, unless the printer itself
had overrange capable device value input. In any case, no normal
CMM would assume this, 99.99% of the time device values are
assumed to be between 0 and 100%. On this basis, things like
B2A tables only hold device values between 0 and 100%, therefore
clipping has to happen in the PCS to device value table lookup.

> - You say in relation to ICC V2 behaviour: "The main disadvantage is that
> the gamut mapping will only operate exactly as intended when the profile is
> linked with the source profile it was setup for". (This only relates to
> Perceptual and Saturation as Colorimetric does not do a gamut mapping). I
> take it that for a print profile, that the source profile should normally be
> the working space?

It is whatever space your source images are in. Typically the color space
is used as a proxy for the gamut the images occupy. With limited gamut
color spaces (i.e. sRGB) this is usually a good assumption, since images
are typically optimized to occupy much of the available gamut.

This assumption breaks down if images are stored in large/unlimited gamut
spaces such as L*a*b*, scRGB, ProPhoto etc., and alternative strategies
are needed to create an appropriate gamut mapping.

>  I had put the monitor profile in the -S flag in colprof,
> but this would seem to be incorrect.  Do I understand correctly that if the
> profile is made with -S AdobeRGB1998.icc but the working space is ProPhoto
> RGB that the Perceptual and Saturation gamut mappings will not operate as
> intended (I was going to say 'wrong', but I'm sure you would tell me that
> there is no 'right' or 'wrong' in these matters :)).

ProPhoto is problematic, since it has a gamut much larger than
typical images, hence is a poor choice as a proxy for the gamut
of the images. Using it as the source gamut for gamut mapping
will typically result in a dull, desaturated result.

You can either use a small gamut, closer to the actual
gamut the images occupy as the source for gamut mapping
(although this then disregards much of the purpose of
storing images in a large gamut space), or you should
move to a more sophisticated workflow, where you
create the gamut mapping for each individual image,
or batch of images, where the source gamut is determined
by the images themselves.

> - You say in relation to ICC V4 behaviour: "The chief drawback, is that only
> one (non colorimetric) intent can really be supported, that of saturation".
> If I understand you correctly (that if you stretch and compress to and from
> the RMG in Perceptual that some horrible things are likely to happen)

Not horrible, it's just that you have less control, and certain
intents are no longer available.

> that
> we then we use Perceptual to our peril in V4 LUT-based profiles.  Is that
> correct?  If so, that's a very useful bit of information!!

There is not universal agreement as to what behavour each intent has.

I distinguish between ones that don't expand the gamut, and those that do.
Other people don't seem to make this distinction. For many
situations, the the distinction may not matter - if the source gamut
is almost the same size or larger than the destination, then there
is no room for expansion, so there will be little difference in
the result. For casual use with typical sRGB sources and inkjet
printer destinations, the PRMG approach appears to work well enough.

The idea of a common intermediate gamut seems to be at the heart
of some contributors vision for ICC profiles from the start (hence
the provision of separate A2B tables for each intent),
although I don't think I've ever seen this explicitly stated
until the PRMG proposal - I guess this was kept as "secret sauce"
for a very long time, to the determent of the ICC format as a standard,
along with other details that would have assisted interoperability.

I've chosen not to use this approach, because it is a much
"less correct" approach to gamut mapping, and has notable limitations.
If the ICC profile format at least maintains the basic capability
of representing the devices measured behaviour (and sometimes
some of the ICC members seem to loose sight of this, witness the V4
display profile changes), then other approaches are possible.

Graeme Gill.


Other related posts: