[Openicc] Named color profiles

[Graeme Gill]

Richard Hughes wrote:
> I'm slightly confused about named color profiles. I've been asked to
> support NCP in the gnome-color-manager viewer tool, but I'm a little
> unsure of the basics.

They are not widely used. One of the limitations is that ICC
doesn't have a standard spectral PCS format, so there is no
obvious way of attaching a spectral reference to the named color.
A spectral definition for a spot color is much more meaningful
and flexible in the overall scheme of things.

> As I understand it, each named color in a profile has a title (with
> shared prefix and suffix) and two values, a PCS value and a device
> value. I'm struggling to work out what the device value should be, if
> the PCS is XYZ. Even if the PCS is Lab, surely for v4 profiles we
> assume D50, and we can trivially work out the LAB value from the XYZ
> value or vice versa. Basically I'm struggling to work out why you
> would ever want a NCP with a PCS of Lab.

I'm not sure what your trouble is here. XYZ and Lab are alternate PCS
spaces. The only difference is that Lab typically has more
gamut when encoded in an ICC profile. The device values only make
any sense if this NCP is intended for a particular printing
process, where the device values correspond to the origin of,
or best match to the PCS value.

If the profile is not meant to be tied to a particular device,
then you would set the number of device components to 0,
although it's not clear what one should but in the header
for the device space signature!

Complications I know about:

	NCP's retain the legacy (V2) Lab PCS encoding, irrespective
of the profile version.

	It's not entirely clear whether the PCS is absolute or relative. Typical
usage for spot colors demands an absolute color match, but most PCS values
in an ICC profile are relative colorimetric, which presumably is the case here.
If so, then in principle they can be transformed back to absolute colormetric
using the white point tag, but confusion may ensue for RGB colors from a monitor
space, given the contradictory handling of white point for print vs. display
devices in ICC V4, where the real absolute white point is hidden away in the
chromatic transform tag rather than being in the white point tag. Without
knowing whether the PCS values are for a display or not, it won't be clear
whether a chromatic adaptation tag should be used or not. Note that the device
attributes field doesn't have an emissive display bit.

[ I guess if I was to create an NCP from display PCS data, I'd ignore the
   V4 display profile recommendations of how to convert it to PCS, and put
   the chromatic transform into the white point. That way at least the NCP
   colors are consistent, and any absolute transformation back to device space values
   will involve a device profile where this ambiguity doesn't exist (at least for
   V4 profiles). ]

Graeme Gill.