Thomas Baumann wrote:
looking into some profiles, I noticed that 'profile' generates only one A2B (printer to PCS) LUT linked to all rendering intents, while profiles made with commercial software (Bill Atkinson's) either contain all three, or at least two A2B tables with saturation mapped to perceptual. While proofing works well the way it is, the option to remap printer output data perceptually could be useful - if I got it right (still CM newbie). Is there a way to generate the missing A2Bx table(s), without or with small changes to the source code?
Other profile creation software may do such things, but do you have any idea what they are doing, or why they are doing it ? I certainly don't know what they are doing or the purpose of such mappings in the A2B tables when applied to ICCV2 files. I can imagine using such an approach to improve perceptual rendering intechanegebility amongst profiles all generated by the same package, but it may actually work against intechanegebility with profiles from other packages. The ICCV4 format does articulate a practice that involves having different A2B tables for different intents, although the overall theory is not really explained. I had a number of discussion with the people from H.P. who are working on applying the ICCV4 reference gamut to the sRGB colorspace profile, in order to try and understand how it was meant to work, and this is the best I came up with: The idea for ICCV4 is to use the PCS as a reference medium with a gamut, and to have the A2B transform the device gamut into the reference gamut, and the B2A transform the reference gamut back into the device gamut. This is an idea that seemed to be the only logical purpose of having separate intent A2B tables, and something that addresses (to some degree) the issues of trying to do gamut mapping at a point when the source and destination gamuts are never known at the same time. It seems like this approach will improve things quite a bit amongst non-critical users of color (ie. "home user", "office") type users. For more serious uses, I have a number of doubts at the moment. My concerns are: The two gamut mappings that get applied in an overall device to device conversion add extra inaccuracy in the color rendering. It's hard to accurately hit a destination gamut surface and provide a smooth mapping. Doing two mappings doubles this inaccuracy. There is no guarantee that gamut mappings from two different vendors will complement each other - ie. say the source and destination gamuts were almost the same, that the transformation into the reference space and then out of the reference space will be done in a way that won't lead to color overall distortions. There are quite a few different gamut mapping algorithms out there, and they don't do the same mapping. Mixing different vendors profiles will almost certainly mean mixing gamut algorithms, and they won't therefore undo each other accurately. Not all useful mappings can be inverted. For some purposes, it may be that the gamut mapping has to severely compress, and should clip once beyond the reference gamut surface. The A2B and B2A mappings within a single profile are meant to be inverses, but you can't invert a clipping. My main concern is that this scheme imposes certain behaviour on the gamut mapping that, (in my view) force it to be more of a saturation intent mapping than what I've viewed a perceptual mapping should be. Here's my definition of some intents: Perceptual: Source surface gamut colors that are out of the destination gamut are compresses, while keeping proportionality between within gamut colors. Source surface gamut colors that are within the gamut of the destination gamut are not changed. Saturation: Source surface gamut colors that are out of the destination gamut are compresses. Source surface gamut colors that are within the gamut of the destination gamut are expanded. In both cases proportionality is maintained in the overall response. Enhanced saturation: Same as saturation, but with an added "enhance saturation" rendering. The ICCV4 reference medium gamut scheme forces the perceptual rendering intent to be what I've called here saturation intent. There's no reasonable way that I can figure, of not expanding the source gamut to meet the destination gamut, because there's still no way of knowing what the two gamuts are at the same time. For some purposes this expansion will be fine, and in fact will be seen as good (popular users of color often respond well to bright, saturated images, even if they aren't accurate), but for more serious use, the loss of this distinction between perceptual and saturation may be more of an issue. If you expect your saturation intent to significantly enhance saturation, then there can still be a distinction between the two gamuts, but it's one of degree rather than kind I think with ICCV4. Anyway, to come back to where we started, doing an ICCV4 scheme is not the basis on which the Argyll ICCV2 profiles are based. They are based on doing the gamut mapping once, in the B2A table, or at link time. Within this scheme, there is no reason for the A2B tables to do anything other than describe the color response of the device, hence only one table. Since ICCV2 doesn't pin down how such things are to be done, intechanegebility with other profiles using A2B and B2A tables is crap shoot. If you don't wish to take such chances, then it's best to only use the colorimetric tables, which are reasonably well defined. Doing specific gamut mappings using just the colorimetric tables is what icclink -g or -G are all about. Klaus Karcher wrote: > Confusing, since http://www.argyllcms.com/doc/profile.html says: "If a > source gamut is specified, then an ICC Version 2.4.0 profile will be > created with a full complement of A2B and B2A tags to support all intents." Sorry, at the time I wrote that, I wasn't aware anyone created ICCV2 profiles with other than one A2B table. I'll amend the sentence. Graeme Gill.