[Openicc] Named color profiles

[Max Derhak]

I agree that there is a lot of confusion about Named Color Profiles
(NCPs).  When implementing the CMM's in SampleICC I found that NCPs have
significantly less clear rules about their usage and application.  
  
That said, IccProfLib in SampleICC actually has a CMM (CIccNamedCmm)
that has the ability to use and apply named color profiles in much the
same mannor as device profiles.  In fact NCP can be connected to other
profiles as well (IE you can go from a named color profile to a printer
profile.  Or visa-versa.  The SampleICC command line tool
iccApplyNamedCMM allows one to apply profiles using CIccNamedCmm by
using a text file containing colors to be applied to a chain of
profiles.  The text file can contain device values, PCS values, or named
color values with results being output to the console.  Individual
rendering intents can also be assigned to each of the profiles in the
chain.  Absolute colorimetric rendering vs relative colorimetric
rendering can also be chosen for named color profiles.

An interesting approach is to connect an RGB profile to a named color
profile followed by the same named color profile connected to a printer
profile. This "proofing" link of profiles uses the named color "space"
in the sequence of profiles to essentially map the colors to a color map
defined by the named colors. 

BTW - One thing that we are addressing in (ICC labs - aka ICC.2) is the
ability to encode spectral information in a revised form of Named Color
Profile.

Max Derhak
Senior Software Architect
max.derhak at onyxgfx.com


-----Original Message-----
From: openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org
[mailto:openicc-bounces+max.derhak=onyxgfx.com at lists.freedesktop.org] On
Behalf Of Graeme Gill
Sent: Monday, April 11, 2011 3:57 AM
To: Open ICC Color Managment
Subject: Re: [Openicc] Named color profiles

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.
_______________________________________________
openicc mailing list
openicc at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc