Agreed, its reproducible and after all conforming to the specification. I would have, as you, expected a colorimetric table inside the profile and by logic a A2B1 tag. But the spec says:
"8.3.2 N-component LUT-based input profilesIn addition to the tags listed in 8.2 an N-component LUT-based input profile shall contain the following tag:
AToB0Tag (see 9.2.1).AToB1Tag (see 9.2.2), AToB2Tag (see 9.2.3), BToA0Tag (see 9.2.6), BToA1Tag (see 9.2.7), BToA2Tag (see 9.2.8) may also be included in an N-component LUT-based input profile. If these are present, their usage shall be as defined in Table 21 (see 9.1). In addition a gamutTag (see 9.2.18) may be included. The usage of this tag is identical as in output profiles."
So a relative colorimetric tag is optional.Neverthless most input profiles in my collection follow the relative colorimetric bahaviour.
Judging from the deltaE of the table A2B0 against the CGATS it is relative colorimetric: (dE CIE*Lab) durchschnittlich: 2.35456 maximal: 9.90228 minimal: 0.160836 (dE CIE 2000) durchschnittlich: 1.12998 maximal: 4.08634 minimal: 0.0952519
So dont worry the profile is relative colorimetric despite the perceptual naming. This still complies with the spec and as pointed out with common pactise.
Regarding your options, I would omit the -u switch: " -u If Lut input profile, make it absolute (non-standard)"With D49 as white point it is not a huge difference, but is wrong for most cases.
Am 19.11.09, 12:38 +1300 schrieb Guy K. Kloss:
As I want to achieve a relative colourimetric transformation (and I *do not* want any gamut mapping to happen in the input -> PCS transformation), I was assuming that the A2B1 is the "proper" table to use. I want to use a CMS (in this case LCMS) to make use of the profile and give me that behaviour (that is no gamut mapping and the relative colourimetric intent).
kind regards Kai-Uwe Behrmann --developing for colour management www.behrmann.name + www.oyranos.org