robert@xxxxxxxxxxxxxxxxxx wrote: Hi, > - Why does Argyll provide the gamt tag? It's required. The resulting file wouldn't be ICC complaint if it was missing. > ... and I > assume that if it is used and the gamut mapping has already been done in the > cLUT (I assume that any XYZ value of 65535 indicates OOG?) that it won't do > any harm (or much harm for values close to but inside the gamut). I doubt any software looks at it. If one is interested in the gamut, then it's far safer to generate your own gamut boundary representation using the A2B data. A flaw in the ICC profile format though, is that it doesn't have any representation for ink limits, and the ink limit will partly determine the gamut extent. (Not applicable to CMY or RGB devices of course.) One can make some guesses from the B2A table contents, but this is not as accurate as knowing exactly how the ink limit was set. If one were drafting a modern color profile format, then I suspect a triangle surface representation of the gamut would be be more likely to be useful than the current tag type. > - Regarding the AtoB mapping: I've had another look at the i1Profiler > generated profiles and even though it has data in all three tags, the data > is the same - so it appears to be using the Colorimetric mapping for all > three, as in Argyll ... just wasting space. Note that tag types can be shared, so it may or may not be using more room. > - I'm not sure if I mentioned this, but Soft-Proofing with Simulate Paper in > Photoshop does the equivalent of: Convert to Profile with selected intent; > Convert back to working space with Absolute Colorimetric. Right, but exactly how does it convert from the printing device to display ? You say "with Absolute Colorimetric", but for the printer to PCS _and_ PCS to display, or just the first part ? Note that the ICC seem to think that people expect/want the "half absolute" conversion, where it becomes a relative colorimetric interpretation of the absolute appearance of the print (hence the forced use of the chromatic adaptation tag in V4). This is not strict soft proof. A strict soft proof is absolute for both, so that the XYZ values on the screen are the same as the XYZ of the (expected) print. > I read your note "About ICC Profiles and Gamut Mapping" and I would like to > clarify a couple of things: > - You say: "The colorimetric intent is meant to convey the exact device > color behaviour, without any gamut mapping". Clearly there is clipping that > occurs on output to a device like a printer. Yes, there will be clipping if you specify a color outside the device gamut in any colorimetric conversion from PCS to device space. > Are you saying that the > clipping is effectively left to the printer, so the CMM will just output > colors without caring if these colors can be printed or not? No, this scenario is virtually impossible, unless the printer itself had overrange capable device value input. In any case, no normal CMM would assume this, 99.99% of the time device values are assumed to be between 0 and 100%. On this basis, things like B2A tables only hold device values between 0 and 100%, therefore clipping has to happen in the PCS to device value table lookup. > - You say in relation to ICC V2 behaviour: "The main disadvantage is that > the gamut mapping will only operate exactly as intended when the profile is > linked with the source profile it was setup for". (This only relates to > Perceptual and Saturation as Colorimetric does not do a gamut mapping). I > take it that for a print profile, that the source profile should normally be > the working space? It is whatever space your source images are in. Typically the color space is used as a proxy for the gamut the images occupy. With limited gamut color spaces (i.e. sRGB) this is usually a good assumption, since images are typically optimized to occupy much of the available gamut. This assumption breaks down if images are stored in large/unlimited gamut spaces such as L*a*b*, scRGB, ProPhoto etc., and alternative strategies are needed to create an appropriate gamut mapping. > I had put the monitor profile in the -S flag in colprof, > but this would seem to be incorrect. Do I understand correctly that if the > profile is made with -S AdobeRGB1998.icc but the working space is ProPhoto > RGB that the Perceptual and Saturation gamut mappings will not operate as > intended (I was going to say 'wrong', but I'm sure you would tell me that > there is no 'right' or 'wrong' in these matters :)). ProPhoto is problematic, since it has a gamut much larger than typical images, hence is a poor choice as a proxy for the gamut of the images. Using it as the source gamut for gamut mapping will typically result in a dull, desaturated result. You can either use a small gamut, closer to the actual gamut the images occupy as the source for gamut mapping (although this then disregards much of the purpose of storing images in a large gamut space), or you should move to a more sophisticated workflow, where you create the gamut mapping for each individual image, or batch of images, where the source gamut is determined by the images themselves. > - You say in relation to ICC V4 behaviour: "The chief drawback, is that only > one (non colorimetric) intent can really be supported, that of saturation". > If I understand you correctly (that if you stretch and compress to and from > the RMG in Perceptual that some horrible things are likely to happen) Not horrible, it's just that you have less control, and certain intents are no longer available. > that > we then we use Perceptual to our peril in V4 LUT-based profiles. Is that > correct? If so, that's a very useful bit of information!! There is not universal agreement as to what behavour each intent has. I distinguish between ones that don't expand the gamut, and those that do. Other people don't seem to make this distinction. For many situations, the the distinction may not matter - if the source gamut is almost the same size or larger than the destination, then there is no room for expansion, so there will be little difference in the result. For casual use with typical sRGB sources and inkjet printer destinations, the PRMG approach appears to work well enough. The idea of a common intermediate gamut seems to be at the heart of some contributors vision for ICC profiles from the start (hence the provision of separate A2B tables for each intent), although I don't think I've ever seen this explicitly stated until the PRMG proposal - I guess this was kept as "secret sauce" for a very long time, to the determent of the ICC format as a standard, along with other details that would have assisted interoperability. I've chosen not to use this approach, because it is a much "less correct" approach to gamut mapping, and has notable limitations. If the ICC profile format at least maintains the basic capability of representing the devices measured behaviour (and sometimes some of the ICC members seem to loose sight of this, witness the V4 display profile changes), then other approaches are possible. Graeme Gill.