Re: [darktable-dev] What is the gamma.c IOP ?

[Aurélien Pierre]

hello,

I have partially solved the issue with the wrong readings of the color
picker : there is actually a function
dt_dev_pixelpipe_process_no_gamma() in src/dev/pixelpipe_hb.c that
temporarily disables the gamma IOP to get the reading. I have modified
it to disable the colorout IOP instead. That fixes the problem when
LittleCMS is not used.

I think the color management needs a cleaning. Looking at the code in
pixelpipe_hb.c, a lot of bad things happen :

  * the histogram and color picker are computed after the display
profile is applied. So, in a multi-screen setup, you don't get the
same histogram depending on the screen you are using. So much for
consistency and reproductibility…
  * the Lab values of the color picker are computed by reverting the
display profile (which means creating a new inverse virtual profile,
and applying it each time the pixelpipe is run). So much for
performance…

I think these parts would be better moved in the colorout IOP, to take
real Lab readings before any RGB conversion and to use the (proper)
output color profile instead of the display one to perform RGB conversions.

Also, continuing with the display color profile… The color management
pipe in dt seems to be as follow :

camera RGB/CFA -> [ input profile ] -> Lab -> [ output profile ] ->
display RGB -> [ OS color management / display ICC profile ] ->
video output.

When darktable is set to use the system display profile, aren't we
correcting twice the picture for the display (one in dt, one before the
GPU output) ? I'm kind of lost here.

Moreover, the internal display correction applies the gamma tonecurve of
the display profile, so the actual 50 % Lab grey is always displayed at
75 % on the screen, which shouldn't happen. It doesn't make sense to
have linear REC 709 and 2020 profiles built-in, and never ever be able
to see actual linear data.

I'm currently adding an option in colorout to bypass the gamma and
enable a linear workflow. It works with the internal dt color
management, but LittleCMS doesn't seem to allow to remove the TRC and
keep only the RGB primaries. Any help welcome.

Thanks,

Aurélien.

Le 03/11/2018 à 09:15, johannes hanika a écrit :
> Hey,
>
> One more reason for gamma.c: legacy. In 2009 when the pipeline was the
> one of ufraw, this was actually used. So in case someone opens 10yo
> shots now they depend on the iop.
>
> Re: colorpicker. that's a known issue, we don't run multiple pipelines
> so the colorpicker reads whatever there is at the end.
>
> No clue about your logspace issue. Maybe you picked in lab after
> display profile transform? that'll have gamma and cbrt().
>
> Cheers
> Jo
>
> On Sat, 3 Nov 2018, 10:05 Andreas Schneider,  > wrote:
>
> On Saturday, 3 November 2018 09:59:23 CET Andreas Schneider wrote:
> > On Friday, 2 November 2018 21:10:33 CET Aurélien Pierre wrote:
> > > Hi Jo !
> > >
> > > Thanks for your answer.
> > >
> > > So this doesn't explain why the global colorpicker readings change
> > > depending on the display ICC profile, nor why using a log encoding
> > > between -2.5 and 2.5 EV, the grey gets remapped to L = 77
> instead of 50.
> > >
> > > I believe there is a gamma correction where it doesn't belong.
> Where is
> > > the code for the colorpicker ?
> >
> > Aurélien,
> >
> > you broke image export with the latest change:
> >
> > See:
> >
> > https://xor.cryptomilk.org/darktable/broken.jpg
>
> Oh, I get the same if I open it in the darkroom!
>
> -- 
> Andreas Schneider                 a...@cryptomilk.org
> 
> GPG-ID:     8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>
>
> 
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
> 
>
>
> ___
> darktable developer mailing list to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] What is the gamma.c IOP ?

[johannes hanika]

Hey,

One more reason for gamma.c: legacy. In 2009 when the pipeline was the one
of ufraw, this was actually used. So in case someone opens 10yo shots now
they depend on the iop.

Re: colorpicker. that's a known issue, we don't run multiple pipelines so
the colorpicker reads whatever there is at the end.

No clue about your logspace issue. Maybe you picked in lab after display
profile transform? that'll have gamma and cbrt().

Cheers
Jo

On Sat, 3 Nov 2018, 10:05 Andreas Schneider,  wrote:

> On Saturday, 3 November 2018 09:59:23 CET Andreas Schneider wrote:
> > On Friday, 2 November 2018 21:10:33 CET Aurélien Pierre wrote:
> > > Hi Jo !
> > >
> > > Thanks for your answer.
> > >
> > > So this doesn't explain why the global colorpicker readings change
> > > depending on the display ICC profile, nor why using a log encoding
> > > between -2.5 and 2.5 EV, the grey gets remapped to L = 77 instead of
> 50.
> > >
> > > I believe there is a gamma correction where it doesn't belong. Where is
> > > the code for the colorpicker ?
> >
> > Aurélien,
> >
> > you broke image export with the latest change:
> >
> > See:
> >
> > https://xor.cryptomilk.org/darktable/broken.jpg
>
> Oh, I get the same if I open it in the darkroom!
>
> --
> Andreas Schneider a...@cryptomilk.org
> GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D
>
>
> ___
> darktable developer mailing list
> to unsubscribe send a mail to
> darktable-dev+unsubscr...@lists.darktable.org
>
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] What is the gamma.c IOP ?

[Andreas Schneider]

On Saturday, 3 November 2018 09:59:23 CET Andreas Schneider wrote:
> On Friday, 2 November 2018 21:10:33 CET Aurélien Pierre wrote:
> > Hi Jo !
> > 
> > Thanks for your answer.
> > 
> > So this doesn't explain why the global colorpicker readings change
> > depending on the display ICC profile, nor why using a log encoding
> > between -2.5 and 2.5 EV, the grey gets remapped to L = 77 instead of 50.
> > 
> > I believe there is a gamma correction where it doesn't belong. Where is
> > the code for the colorpicker ?
> 
> Aurélien,
> 
> you broke image export with the latest change:
> 
> See:
> 
> https://xor.cryptomilk.org/darktable/broken.jpg

Oh, I get the same if I open it in the darkroom!

-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] What is the gamma.c IOP ?

[Andreas Schneider]

On Friday, 2 November 2018 21:10:33 CET Aurélien Pierre wrote:
> Hi Jo !
> 
> Thanks for your answer.
> 
> So this doesn't explain why the global colorpicker readings change
> depending on the display ICC profile, nor why using a log encoding
> between -2.5 and 2.5 EV, the grey gets remapped to L = 77 instead of 50.
> 
> I believe there is a gamma correction where it doesn't belong. Where is
> the code for the colorpicker ?

Aurélien,

you broke image export with the latest change:

See:

https://xor.cryptomilk.org/darktable/broken.jpg



Andreas

-- 
Andreas Schneider a...@cryptomilk.org
GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

[darktable-dev] What is the gamma.c IOP ?

[Aurélien Pierre]

Hi Jo !

Thanks for your answer.

So this doesn't explain why the global colorpicker readings change
depending on the display ICC profile, nor why using a log encoding
between -2.5 and 2.5 EV, the grey gets remapped to L = 77 instead of 50.

I believe there is a gamma correction where it doesn't belong. Where is
the code for the colorpicker ?

Regards,

Aurélien.

Le 02/11/2018 à 06:17, johannes hanika a écrit :
> heya,
>
> it used to do the gamma in the olden days. now it just does what you
> observed: convert to uint8 for display and any marshalling of data at
> the end of the pipeline in gui mode can take place here. it's
> certainly not applying gamma. i suppose we could delete these old
> gamma lut table lines of code and just round directly in process().
>
> cheers,
>  jo
> On Thu, Nov 1, 2018 at 3:52 PM Aurélien Pierre
>  wrote:
>> Hi,
>>
>> there is in dt an hidden IOP named gamma.c that is the last one in the 
>> pixelpipe. Looking at the code, it is useful to display the masks and 
>> convert the pixels to uint8 values.
>>
>> However, it does a gamma conversion too, with a linear and gamma parameters. 
>> First of all, this conversion seems damaging in a calibrated and linear 
>> workflow because it (seems to) prevents the color picker to get accurate 
>> pixel values readings.
>>
>> Then, I don't see where the gamma and linear parameters are grabbed. Could 
>> anyone tell me what it does and how ? Having an arbitrary gamma conversion 
>> there could be redundant with the display gamma and is a serious matter for 
>> color management.
>>
>> Thanks,
>>
>> Aurélien.
>>
>>
>> ___ 
>> darktable developer mailing list to unsubscribe send a mail to 
>> darktable-dev+unsubscr...@lists.darktable.org
> ___
> darktable developer mailing list
> to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
>

___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] What is the gamma.c IOP ?

[johannes hanika]

heya,

it used to do the gamma in the olden days. now it just does what you
observed: convert to uint8 for display and any marshalling of data at
the end of the pipeline in gui mode can take place here. it's
certainly not applying gamma. i suppose we could delete these old
gamma lut table lines of code and just round directly in process().

cheers,
 jo
On Thu, Nov 1, 2018 at 3:52 PM Aurélien Pierre
 wrote:
>
> Hi,
>
> there is in dt an hidden IOP named gamma.c that is the last one in the 
> pixelpipe. Looking at the code, it is useful to display the masks and convert 
> the pixels to uint8 values.
>
> However, it does a gamma conversion too, with a linear and gamma parameters. 
> First of all, this conversion seems damaging in a calibrated and linear 
> workflow because it (seems to) prevents the color picker to get accurate 
> pixel values readings.
>
> Then, I don't see where the gamma and linear parameters are grabbed. Could 
> anyone tell me what it does and how ? Having an arbitrary gamma conversion 
> there could be redundant with the display gamma and is a serious matter for 
> color management.
>
> Thanks,
>
> Aurélien.
>
>
> ___ 
> darktable developer mailing list to unsubscribe send a mail to 
> darktable-dev+unsubscr...@lists.darktable.org
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

[darktable-dev] What is the gamma.c IOP ?

[Aurélien Pierre]

Hi,

there is in dt an hidden IOP named gamma.c that is the last one in the
pixelpipe. Looking at the code, it is useful to display the masks and
convert the pixels to uint8 values.

However, it does a gamma conversion too, with a linear and gamma
parameters. First of all, this conversion seems damaging in a calibrated
and linear workflow because it (seems to) prevents the color picker to
get accurate pixel values readings.

Then, I don't see where the gamma and linear parameters are grabbed.
Could anyone tell me what it does and how ? Having an arbitrary gamma
conversion there could be redundant with the display gamma and is a
serious matter for color management.

Thanks,

Aurélien.


___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org