Marcus Blomenkamp wrote: > Assuming that the native primaries of the display combined with the primaries > of sRGB > form a near-zero vector product in CIE xy (same angle from white), would the > per > channel LUT still be wrong? Wrong in such a way that it could not be > corrected/approximated by the appropriate combination of > (brightness,contrast,gamma) as > LUT ramp? It simply doesn't work that way. If you change the intensity of one or two channels, you are simply shifting the white point and those channels. If you change all three channels by the same amount, you are changing the brightness but not the gamut. To change the chromaticities of the channels requires a matrix. > I will have a look at it, but success stories seemed sparse when googling the > respective terms. Before digging into that i will use the displays PiP > side-by-side > mode displaying profiled/managed content on one side and the non-managed > LUT-calibrated > content on the other side, trying to find the above mentioned sufficiently > correct > combination. Mathematically it's pretty straight forward to apply a 3x3 matrix to each RGB value independently. Example of the more complex but flexible 3D cLUT that I know of are the exrdisplay utility in the OpenEXR library that uses a fragment shader, and the GPU Gems 2 article "Using Lookup Tables to Accelerate Color Transformations" by Jeremy Selan. There is a plugin for the Compiz X11 compositor that supports 3D cLUT transforms using a shader - see CompICC at http://www.oyranos.org, but it should be simple to substitute a 3x3 matrix for the texture lookups in the example code. Graeme Gill.