Re: [Lcms-user] Profile linearization and softproofing

[Aurélien P. <re...@au...>]

Hi Graeme,

thank you for your answer.

The problem I have is that, in darktable, it seems the image is
gamma-corrected twice :

  * output Lab values are off, too bright : data 50 % Lab (measured on a
    RAW photo of a ColorChecker grey patch with white patch properly
    exposed) is shown as 75 % screen Lab. Given that 0.5^(1/2.4) = 0.75,
    that sounds like a gamma issue.
  * masks featherings show some sort of quantization artifacts on the edges,
  * linear grey ramps in an image (PNG synthesized grey gradient) looks
    washed away for the most part (again, too bright).

It is solved by removing the tonecurves from the output color conversion
or by using Elle Stones Identity ICC profile (gamma 1.0) as a display
profile in the software (but, of course, colors are desaturated then).
For usual RGB output spaces, this is done with darktable internal
functions (easy to hack), but for exotic RGB output spaces, LittleCMS
handles that with black boxes.

Or maybe I'm wrong and there is some place elsewhere in the code where
arbitrary gamma 2.4 conversions happen.

I understand the theory of profiling and error reverting with LUT or
TRC, it's on the actual implementation that I'm lost, and what actually
happens in the pixelpipe.

Thank you,

Aurélien.

Le 04/11/2018 à 18:56, Graeme Gill a écrit :
> 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.
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> https://lists.sourceforge.net/lists/listinfo/lcms-user