Re: [Lcms-user] Profile linearization and softproofing

[Graeme G. <gr...@ar...>]

Aurélien Pierre wrote:

Hi,

> I'm working on the software darktable to enable a linear workflow (no gamma correction
> from the display, this is done by a log2 function internally), in order to visualize the
> data in the scene-referred space.

> I'm looking for a way to keep the RGB primaries but remove the TCR/tonecurve from that
> xform in order to suppress the gamma correction. So far, I'm clueless. Is that possible ?

it's not really clear what you are attempting to do.

Note that all conventional displays have a gamma reproduction characteristic - the
display light levels are non-linearly related to the frame buffer control values.
This is because it makes the control values more perceptually uniform,
and therefore there is less visual quantization with limited frame buffer depth
or video signal encoding depth.

Typically the term "gamma correction" means the image processing
system applying the anti-gamma of the display, in order to cancel
out the effects of the gamma response, so that the code can
deal with linear light levels in computation.

In an ICC profile color managed system though, the display profile provides
a mapping between PCS (i.e. CIE standard observer, device independent) values
and the display control (i.e. device) values. (i.e. it provides the
inversion of the display behavior.)

PCS can be either CIE XYZ or CIE L*a*b* D50 white point values.
These are effectively interchangeable, since the conversion
is fixed. CIE XYZ values are linear light.

So you don't really need a proofing transform to send linear light
values to the display, you just need the inverse (i.e. B2A direction)
ICC device profile. Note though that the range of values is limited
by the display gamut.

A soft proofing transform is typically quite complex, involving
three device profiles i.e.:

Source color space -> input profile -> proofing profile -> Proofing colorspace ->
proofing profile -> output profile -> Output colorspace.

i.e. the transform does a color conversion from the source color space
to the proofing space, and then converts that to the output (typically
display) color space. The purpose is typically to be able to
see the gamut mapping characteristics of the proofing device (i.e. printer),
while viewing on a different device (i.e. display). Note that within
the gamut and the accuracy of the profiles, the color fidelity
will be maintained by the color management system.

If that's really what you want to do (i.e. you really want to do
a soft proof, because you are targeting (say) a printer), then you
control the source color space by your choice of source ICC profile.
i.e. if you want the source to be a linear light RGB type space,
then you need to create or use such a profile as the source profile.

This is because the whole point of a color management system
is to manage the color. Its purpose is to be closed loop control.
So you provide a color, define what that color means by providing
a color profile (the source profile) or use a device independent
color encoding like XYZ or L*a*b*, and then the color management
system takes care of faithfully conveying that color to the output
device as much as is possible, without you having to know
much about how that device behaves.

Note that if you don't really wish to use a proofing transform,
you would use the simpler cmsCreateTransform(), which converts
between your source colorspace and your display.

Hope this helps,

	Graeme Gill.