ICC Colour Profile Inspector

Because the colorant tags are not the device’s primaries. Every XYZ value in a v4 display profile is expressed relative to the D50 illuminant of the profile connection space, even though almost every real display is built around D65. The conversion between the two is stored in the chromatic-adaptation tag, chad, as a 3x3 Bradford matrix. To recover the chromaticities the display actually has, you invert that matrix and apply it to each colorant, which is what this tool does when a chad tag is present. Without one there is nothing to un-adapt with, so the values shown are the stored D50-relative numbers and are labelled as such — for an sRGB profile that is the difference between seeing x = 0.6484 and the 0.6400 you were expecting.

No — "gamma 2.2" was never what sRGB specified. The sRGB transfer function is piecewise: a linear segment below 0.04045 and a power function with an exponent of 2.4 applied to a scaled and offset input above it. Written as an ICC parametric curve that is function type 3 with five parameters, and this tool prints all five. The curve happens to sit close to a pure 2.2 gamma across the midtones, which is where the shorthand came from, but it diverges near black, and that is exactly where banding shows up. When a profile stores a sampled table instead, no exact gamma exists at all, so the number shown is an estimate taken at mid-grey and is labelled as one.

A matrix/shaper profile describes the device with three colorant tags and three tone curves: convert each channel through its curve, multiply by the 3x3 matrix built from the colorants, and you are in the connection space. It is small, fast, invertible and can only describe a device whose behaviour really is that simple — which displays mostly are. A LUT profile instead stores sampled multi-dimensional tables in A2B0/B2A0 and their siblings, one set per rendering intent, and is what printers need because ink on paper is not a linear system. Some profiles carry both; the colour management module then picks by intent, which is why a printer profile can behave differently in perceptual and colorimetric mode.

No. The profile ID field is a 16-byte MD5 of the whole profile with the flags field, the rendering intent field and the ID field itself temporarily set to zero, and the specification never made computing it mandatory. Plenty of profilers leave it blank, so all zeros simply means nobody wrote one. What is worth noticing is the other case: an ID that is present but no longer matches, which means the file was edited after the ID was calculated. This tool recomputes the hash when an ID is stored and says which of the two you have.

It is deliberate and completely legal. The tag table maps signatures to positions, and nothing stops two signatures naming the same position. The common case is rTRC, gTRC and bTRC on a display profile: the three channels share one tone curve, so the writer stores the curve once and points all three entries at it, saving a few hundred bytes. Reporting the bytes three times would suggest three independent curves that could drift apart, which is why they are shown as sharing instead. Editing such a profile by hand is where it bites — changing "one" curve changes all three.

The profile connection space is the common ground every conversion passes through: source device to PCS, PCS to destination device. The specification allows only XYZ or Lab there, so a profile claiming anything else cannot be composed with another one. The exception is the device link class, which is not a device description at all but a frozen source-to-destination conversion — its "PCS" field holds the output device space, so CMYK or RGB is correct there and this tool does not flag it. Device links are fast and exact for the pair they were built for and useless for anything else, which is why an application that hands you one cannot also tell you what your printer would do with a different paper.