Thanks for the information Graeme, I was not aware of the internals of monitor profiling - that it involves it's calibration and later it's characterization. Makes perfect sense to me now.
About the need of another ICC profile for creation of LUT: I'm still digesting this.
I thought that one of the beauties of ICC profiles is that each profile characterizes one device. So for N devices we need just N profiles, all combinations of them are "calculated" at run time (notable exception being device link profiles). But using information in profile X to create a LUT of device Y seems to break this rule - would I then have to create as many display profiles as I have output devices? Maybe I got something fundamentally wrong about CM.
Mark
OK, I just did all steps and have the ICC now. Compared to another profile I created a while ago with the Spyder2 software, I like the one Argyll created more - both have quite different white points.I'm not sure you should notice this unless you are running absolute colorimetric intent.I just want to understand better why so many steps are needed to get the ICC: dispcal took lots of readings, and as the name says calibrates the display. Couldn't the .cal file directly be used to create the ICC file? Or am I missing something.The .cal primarily contains calibration information - how to set the device LUT's to conform to a particular behaviour. It doesn't contain information on how the device behaves with that calibration (ie. it doesn't contain characterization information for the device in a calibrated state). So gathering this information is a separate couple of steps. It might be possible to create a lower accuracy matrix profile during the calibration process, but I haven't looked into exactly what's needed to do this yet. You wouldn't have the option of creating a CLUT based profile though, you would forgo choices about how many patches to use for the calibration, and I'm unsure of the accuracy compared to doing a separate profile since I'm trying to minimize the number of measurements during calibration, but none the less I may add this as an option at some stage.I created a matrix profile, I do not understand why I have to specify another icc profile in order to create a LUT based profile.A LUT profile allows for the possibility of gamut mapping for theperceptual and saturation intents, by use of either of two of the B2A tables.Gamut mapping entails mapping gamuts between a source gamut and a destination gamut. While the device you are profiling defines thedestination gamut, there is no defined source gamut unless you specify one,ie. by providing another ICC profile to define it.Any (ICCV2) profile creation process that is creating perceptual and/orsaturation intent tables, and does not require a source gamut to be defined, is merely fudging the gamut mapping. ICCV4 profile creation takes a slightly different approach to avoid this issues, but the consequence is that you end up locked into saturation intent using anything other than the colorimetric table with ICCV4. (ICCV4 isn't currently supported by Argyll).For a LUT based profile, where gamut mapping is desired, then a source profile will need to be provided to define the source gamut. For instance, if the display profile was likely to be linked to a CMYK printing source profile, say "swop.icm", then the following would suffice:Could you please explain me what this does.The gamut mapping maps specifically from one gamut (the source) to the destination (the device). It will be tailored specificallyfor that source gamut. This means that ideally a new destination profileshould be created every time a new source is chosen to link with that profile (Don't blame me for this, this is how ICC2 is defined!). This can be a bit impractical, so one general approach to setting up the gamut mapping, is the one I explain in "Typical usage scenarios and examples": Gamut mapping has the most dramatic influence when the source and destination are different fundamental device types, ie. Additive RGB vs. Subtractive CMYK. So it can work quite well if the colorimetric table is used when linking with sources of the same type, and perceptual if linking with devices of the opposite type. To work this way, a source profile of the opposite type should be specified as the source gamut during profile creation, since it is what's used to create the perceptual and saturation intent tables. So to work things this way, when creating an RGB profile, one would provide a typical CMYK profile as the source gamut. When creating a CMYK profile, provide a typical RGB profile as the source. Then when linking with the same type, use colorimetric, and when linking with the opposite type, use perceptual. Of course this may not work for you if you have little control over the intents, want some different sort of reproduction (ie. saturation) etc. You may want simply to use a source gamut/profile that is representative of typical source spaces you will be linking to. For those really after the best quality results and best control, then I'd really recommend a device link workflow. You get to exactly define your gamut mapping (including black preservation etc.), and the device link avoids double conversion, particularly though the lower precision B2A tables. Graeme Gill.
