Re: "Proper Gamut Mapping"
Re: "Proper Gamut Mapping"
- Subject: Re: "Proper Gamut Mapping"
- From: Graeme Gill <email@hidden>
- Date: Sat, 15 Dec 2007 11:45:54 +1100
Todd Shirley wrote:
I'm interested in this thread, but I'm getting confused, so hopefully
you can clarify. It seems like you didn't respond to Marco's question
because he used the word "convert" instead of "mapped".
As far as I'm aware I responded to Marco's question. The words "mapped"
and "convert" have overlapping meanings in general. Any sort of transformation
is a conversion, and a mapping is a conversion. But it's also possible to
use these words in ways to make distinctions between different
processing steps too.
If you break down the linking of two device profiles into logical
steps, then a necessary steps is to be able to deal with the two
device color spaces in a common color space, for instance PCS.
Device colors are "converted" to and from the PCS using the information
in the profiles. Having got your colorpaces in a common space, then
for perceptual or saturation mappings, it's desirable to do something
about the range of colors (gamut) that each device space covers,
as well as details like white points, grey axes, etc. The process
of transforming (or converting) from one gamut extent to another
is by convention called gamut mapping.
In your post
(below) you say "mapped from an unspecified non-specific source gamut
to a specific destination gamut" which to me implies a conversion, and
if it doesn't, what do you mean?
I'm not sure I understand what you're reading into this. The overall
process of converting from one device colorspace to another with perceptual
gamut mapping involves a conversion of color values.
> Are you referring to the fact that a
conversion using standard ICC profiles requires 2 profiles because each
profile can only describe one device, and therefore the destination
profile is converting from a because it, by
itself, does not "know" the source?
Yes.
> How is this a problem, considering
you must use a source and destination profile for any conversion?
Because in typical ICC profiles, the gamut mapping transform is
encoded in the destination profiles B2A table, yet the B2A table
is typically created without any information about what gamut
is being mapped from. So the source gamut used to create such
a table can only be a "non-specific source gamut".
My (limited) understanding of device-links is that they more-or-less
just roll two device profiles into one, thus fulfilling your
requirement that proper gamut mapping is "mapped from a specific source
gamut to a specific destination gamut". How is this gamut mapping
better than using two discrete profiles?
It needn't be better, but it offers the scope to be better if gamut
mapping is postponed to the point at which the profiles are linked.
99.9% of applications and systems that take ICC profiles to define
their color spaces will use a traditional CMM, which makes use of
the pre-canned B2A tables with their cooked in gamut mapping.
A traditional CMM simply links the appropriate A2B and B2A tables,
so the gamut mapping cannot have been chosen specifically for
the source gamut involved. This approach was chosen because it's
very fast.
Having an explicit, off line linking step offers the scope to
do other, slower things, such as creating a gamut mapping that maps
from the actual source gamut to the destination gamut, and having
a device link profile gives you somewhere to store it.
I get confused when you say "how can the source profile have any affect
on the gamut mapping ?" Perhaps I don't understand exactly how all this
works, but doesn't the source profile convert the color information
into LAB using the source gamut, thus resulting in a set of LAB numbers
that are limited to the source gamut?
The gamut of a colorspace is essentially independent of the nature
of the mapping between the device values and their corresponding CIE
value. So it doesn't make sense to say "convert the color information
into LAB using the source gamut". The source gamut is not "used" to make
a conversion, it just comes along for the ride when colors are transformed
from device space to CIE. The gamut itself doesn't change in such a process,
it stays the same, just the colorspace has changed, hence the representation
of the gamut has changed. Gamut mapping is logically a different transformation
than changing colors from device space to/from CIE.
> Then when this information is
passed to the destination profile, isn't the source gamut implied
because all the LAB numbers fall within the source gamut?
Yes, but the source gamut doesn't necessarily fall within the destination
gamut, which is what gamut mapping is meant to do.
> So it seems
to me that even though the "gamut mapping has already been hard coded
into the destination profiles B2A table", because the LAB numbers are
limited to the source gamut the destination gamut is "informed" by the
source gamut?
How can that be ? The B2A table can't possibly know what source
gamut it will be presented with, so it can't know what range
of colors to allow for in the gamut mapping. In general
it will be presented with multiple source gamuts (one
for every possible source colorspace), how can one
transform cope with that range of gamuts, unless it
is generalized, rather than being specific ?
> When I write it out like this, I see that maybe there
could be a problem with this transform, but I can't quite get my head
around it. Clearly you have a better idea, so I'd appreciate if you
could clarify why a device profile transform is better!
OK, there are three basic steps in linking two device profiles with
a perceptual or saturation intent:
InDevice -> PCS
PCS -gamut-map-> PCS
PCS->OutDevice
The first is encoded in the input profile. The last is encoded in
the output profile. Where does the middle transform, that depends on both the
input space and output space gamuts live ? The answer is it
can't properly live anywhere, and presents an M x N combinatorial
explosion if you want to store it into a file, the very problem that
ICC profiles were intended to solve. So the middle transform has
to be shoved into one or the other or both of the other two
transforms. Somehow.
As a profile creator, how do you cope with this ? You've got
to cope with it in some way. All you can really do is to use
some simplifying assumptions, and hope for the best.
You might assume that input color spaces are all like sRGB.
You might survey typical color gamuts of your user base,
and use that as the mapping source. You might try and create
a graduated compression that does minimal extra compression
on typical color gamuts, and uses the reserve to cope with
larger than usual gamuts by compressing them severely.
You might try and make linking between your profiles work
together better by using the A2B table to map the input gamut
to a chosen intermediate gamut, and the B2A table to convert
from your intermediate gamut to the output gamut (but
note this can have the effect of converting the intent
to saturation rather than perceptual). Lots of choices for
the tool creator, but nothing is optimal, and nothing is
guaranteed to work well with profiles created by other tools.
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