Re: "Proper Gamut Mapping"
Re: "Proper Gamut Mapping"
- Subject: Re: "Proper Gamut Mapping"
- From: MATT LARMOUR <email@hidden>
- Date: Sat, 15 Dec 2007 22:08:34 -0800
- Priority: normal
This has been a very interesting thread for me as well, and I thank Graeme and Harold for taking the time to provide such detailed explanations. This is what I understand, if I understand correctly...
When the B2A0 tag (PCS to Device, Perceptual intent) of an output profile is built by the profile making application, the application needs to decide upon the gamut mapping scheme.
Because the profile making application can't know the range of PCS values (the degree of saturation and brightness of the source colours) that will be presented to it, it has to make an assumption about what this range is. It would be a poor decision to assume that this range would actually be the bounds of the PCS (usually CIELAB) itself, because this would result in drastic compression and would be true only in unusual cases. So, the profile making app assumes that the range of PCS values will correspond to, for example, the gamut of sRGB or AdobeRGB (1998).
This assumption leads to a "one size fits all" gamut mapping scheme which will perform a certain amount of compression from the (assumed) source gamut to the (known) destination gamut.
The reason this is a problem is that the degree of compression that has been built into the B2A0 table is optimal only if the gamut of the source colourspace of the image (or other objects) that we are converting is the same as the assumed source gamut when the B2A0 table was built. So if the profile building app assumed sRGB as source colourspace when building the B2A0 table, and the colourspace that our colours are in that are undergoing conversion, are, in fact, sRGB, then we are happy. But if the profile building app assumed something like AdobeRGB (1998) or Wide Gamut RGB when building the B2A0 table, but the actual colourspace that our colours are in that we are converting from is sRGB, then we have a problem because an unnecessary degree of gamut compression will occur.
So gamut mapping would be improved by building a device link for the specific source gamut-destination gamut combination. Or, if the profile making applications would let us, by specifing the expected source gamut before building the B2A0 table in a conventional ICC profile, and then the user ensuring that the colour data to be converted are in that expected colourspace.
The v4 ICC spec improves this situation by specifying the source gamut explicity.
To improve further, because, say, the gamut of the colour values comprising an _image_ would rarely fill the entire gamut of the colourspace to which the image belongs, the ideal scenario would be image-specific gamut mapping calculated at the time of conversion to a destination profile. This is the very idea of a "smart" CMM, if my understanding is correct.
Matthew Larmour
> > 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
> informationinto 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
> transformedfrom 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
> representationof 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
> destinationgamut, 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