Re: PRMG gamut
Re: PRMG gamut
- Subject: Re: PRMG gamut
- From: Graeme Gill <email@hidden>
- Date: Fri, 29 Feb 2008 15:49:45 +1100
email@hidden wrote:
Hmmmm.... you're going to have to elaborate on this statement, Graeme. Its
not at all apparent to me why this would of necessity be the case.
OK, here's the reasoning in some detail.
In general when we're mapping from one device to another, the
gamuts overlap. There are regions which are in and out of
gamut of the other device.
A perceptual rendering is usually regarded as one in which out
of gamut colors are brought in gamut, but colors that are already
in gamut are left alone. A saturation rendering is usually regarded as
one in which the colors are expanded and contracted so as to make the
gamut boundaries co-incide.
(Note in the following discussion I'm using the gamut boundary as an
indication of what's happening to colors within the gamut. For perceptual
rendering it's assumed that colors within the gamut are altered proportionally,
rather than being clipped.)
See <http://www.argyllcms.com/doc8/gamutmapping1.jpg>.
The PRMG is intended to operate as a intermediate common
gamut, where the incoming device gamut is transformed
to be the PRMG, and the PRMG is then transformed to
be within the outgoing device gamut. The idea is to
then be able to do specific gamut mappings, while still
being able to use a passive CMM, where the gamut mappings
are pre-computed.
For the following discussion, I'm referring to the
illustration in <http://www.argyllcms.com/doc8/gamutmapping2.jpg>
The V4 ICC specification state that the A2Bx and B2Ax tables must
be complements (ie. they must round trip). Lets assume that we
have a device who's gamut is greater than the PRMG. In figure 1 we
show a 2 dimensional slice through the two gamuts. For
the following figures we illustrate a 1 dimensional slice along
the red dotted line of the 2 dimensional slice.
In Figure 2 we show a cross section along the red dotted
line of an attempt to create perceptual rendering
A2B and B2A tables using the PRMG and following the ICC specifications,
for a device called "device 1".
In the B2A table the regions of the PRMG boundary that are out of
gamut are compressed to fit within the device gamut (bottom
line). The area of the PRMG that are within the device gamut
are left unchanged (perceptual rendering). The implication
of this is that the device gamut boundary in this area
is going to correspond with colors outside the PRMG
(top solid line marked '???').
Following the ICC spec., the A2B table must be the reverse
of this (they must round trip). This means that device 1
colors that are outside of the PRMG, map to colors outside the
PRMG (Figure 2 A2B top solid line marked '???').
We'll accept this for the moment, and see what happen when we
link a device 1 profile with a device 2 profile, the device 2
having a gamut that is smaller than the PRMG in all directions.
[Figure 3].
In the A2B transformation colors within the device 1 gamut are
transformed to colors outside the PRMG (top solid line).
Other colors within the device 1 gamut are transformed to the
PRMG boundary (bottom solid line marked 'expand').
In the B2A transformation, the colors that are outside
the PRMG end up being clipped (top solid line marked 'clip'),
while colors within the PRMG are mapped to be within the
device 2 gamut (bottom solid line marked 'compress').
Clearly this is not good. We're not getting a perceptual
rendering, since device 1 colors are being clipped.
Lets move on to figure 4, where we attempt to address this issue.
If we alter the device 1 A2B table so that device 1 colors
are NOT mapped to colors outside the PRMG (top line marked 'compress'),
then when we apply the device 2 B2A mapping, then we no longer
get clipping. Problem solved ??
Well, yes, but note the implication. [Figure 5]
If we've compressing in the device 1 A2B, that means we have
to implement the opposite in the device 1 B2A (because
the A2B and B2A mappings have to round trip), i.e. we have to
expand PRMG colors that are within the device 1 gamut,
out to the device boundary. This is NOT a perceptual
rendering, this is a saturation rendering. We are unable
to do a perceptual rendering.
[Note that no simple changes to the ICC specifications,
or mixing and matching different input and output device
intent tables will repair this problem since it is fundamental.
To do a true perceptual rendering, the gamut mapping
needs to know the relationship between the source
and destination device gamuts (should it leave unchanged,
or should it compress ?), while a passive profile
linking system such as the ICC profile is specified
for, must assume that gamut mapping can be done
without reference to more than a single actual device
gamut when the profile is constructed. This is the
problem that the PRMG was introduced specifically to
solve, but it only fixes saturation rendering, not perceptual,
and can never do so. Even if you remove the A2B and B2A round
trip rule, you still have the same fundamental problem. I won't
go through these here, as they involve going through several
scenarios similar to the discussion above. (I leave these as
an exercise for the reader :-)]
Graeme Gill.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Colorsync-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden