Pekka Paalanen wrote: > My failing is that I haven't read about what ICC v4 definition actually > describes, does it characterise content or a device, or is it more > about defining a transformation from something to something without > saying what something is.
The ICC format encompasses several related forms. The one that is pertinent to this discussion is ICC device profiles. At a minimum an ICC device profile characterizes a devices color response by encoding a model of device values (i.e. RGB value combinations) to device independent color values (i.e. values related to device independent CIE XYZ, called Profile Connection Space values in ICC terms). A simple model such as color primary values, white point and per channel responses is easily invertible to allow transformation both directions. For less additive devices there are more general models (cLut - multi-dimensional color Lookup Table), and they are non-trivial to invert, so a profile contains both forward tables (device -> PCS AKA A2B tables) and reverse tables (PCS -> device AKA B2A tables). Then there is intents. The most basic is Absolute Colorimetric and Relative Colorimetric. The former relates the measured values, while the latter one assumes that the observer is adapted to the white point of the devices. Typically the difference is assumed to be a simple chromatic adaptation transform that can be encoded as the absolute white point or a 3x3 matrix. The default intent is Relative Colorimetric because this is the transform of least surprise. cLUT based profiles allow for two additional intents, Perceptual where out of gamut colors are mapped to be within gamut while retaining proportionality, and Saturation where colors are expanded if possible to maximize colorfulness. These two intents allow the profile creator considerable latitude in how they achieve these aims, and they can only be encoded using a cLUT model. So in summary an ICC profile provides device characterization, as well as facilitating fast and efficient transformation between different devices, as well as a choice of intent handling that cannot typically be computed on the fly. Naturally to do a device to device space transform you need two device profiles, one for the source space and one for the destination. > What is the use for a device link profile? Device link profile use was a suggestion to overcome the previously stated impossibility of a client knowing which output a surface was mapped to. Since this no longer appears to be impossible (due to wl_surface.enter/leave events being available), device link profiles should be dropped from the extension. It is sufficient that a client can do its own color transformation to the primary output if it chooses, while leaving the compositor to perform a fallback color transform for any portion that is mapped to a secondary output, or for any client that is color management unaware, or does not wish to implement its own color transforms. This greatly reduces the implementation burden on the compositor. > If there is only the fd, you can fstat() it to get a size, but that > may not be the exact size of the payload. Does the ICC data header or > such indicate the exact size of the payload? Yes, the size of an ICC profile is stored in its header. Cheers, Graeme Gill. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel