Klaus Karcher wrote:
Graeme: what do you think about setting the -p switch for cctiff as default?
No, that's not really the idea of it. It's strictly for comparing the behavior. The whole point of cctiff is to do the transformation at high speed. I'm not at all surprised that there are issues with blacks if you are using profiles with a gamma of 1.0. The way cctiff/icclink are setup at the moment, is that they make certain assumptions about the per channel curves shape, in making use of them for the per channel curves for the overall transform. One of the assumptions is that the curves transform from the device space to a roughly perceptual space (Argyll CLUT base profiles aim for exactly this). The multi-dimensional transform that then does all the work is defined by a grid, and a roughly perceptual space will mean that the grid points are located roughly evenly in perceptual space. Gerhard noticed an issues caused by this some time ago, and that is why there is a "hack" to treat XYZ PCS profiles differently - their per channel curves are not used as per channel curves for the overall transform, since they would cause the input space to the 3D Lut to be evenly spaced in linear light space, causing poor grid resolution at the black end. The assumption then though, is that the basic encoding of the device space is roughly perceptually linear, i.e.. that it has a gamma of somewhere between 1.8 and 2.4. When you use a device space that is linear light encoded with an XYZ PCS profile, it breaks this assumption and the grid spacing is not good at the black end. Using the -p switch uses the defining floating point transform for each pixel, so it avoids this issue at great cost to speed. My plan is to correct these issues at some stage by applying a similar approach to the per channel curve creation of profile (or perhaps a simpler heuristic in the case of icclink) to create per channel input and output curves, and so ensure that the 3D lookup grid points are well placed. In the mean time it's probably a good idea to stick to color spaces that encode the linear light space with a gamma somewhere between 1.8 and 2.4, so that the encoding is efficient, doesn't suffer problems in the black if truncated to 8 bits per component, and doesn't suffer from issues when transformed through 3D CLUTs without the use of optimized per channel curves. Graeme Gill.