Re: [darktable-dev] what happens with linux color management ?

[Alexander Rabtchevich]

Hello

It seems Mate doesn't have any.

With respect,
Alexander Rabtchevich


johannes hanika wrote:

re: colord: is there the more minimalistic xiccd maybe?

cheers,
  jo
On Sat, Nov 24, 2018 at 11:48 AM Alexander Rabtchevich
 wrote:

Hello

And there is no colord in Mate desktop, at least on Linux Mint. So I have to 
select correct profile from the list manually each time I load Darktable. Could 
the last selection be saved and restored? Or could the settings include 
preferred monitor profile to be loaded if darktable failed to find system one?

With respect,
Alexander Rabtchevich



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

Re: Aw: [darktable-dev] what happens with linux color management ?

[philippe . weyland]

Re: So I have to select correct profile from the list manually each time I load 
Darktable.

Same on windows 10, the last selection is not saved (Bug #12328). The system 
profile is used instead.

- Mail original -
De: "Alexander Rabtchevich" 
À: "darktable" 
Envoyé: Samedi 24 Novembre 2018 11:47:55
Objet: Aw: [darktable-dev] what happens with linux color management ?

Hello

And there is no colord in Mate desktop, at least on Linux Mint. So I have to 
select correct profile from the list manually each time I load Darktable. Could 
the last selection be saved and restored? Or could the settings include 
preferred monitor profile to be loaded if darktable failed to find system one?

With respect,
Alexander Rabtchevich
___
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 happens with linux color management ?

[johannes hanika]

heya,
On Fri, Nov 23, 2018 at 5:24 PM Aurélien Pierre
 wrote:
>
> Hi everyone,
>
> my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it was the 
> same when I used Gnome Shell.  I have a custom screen ICC profile installed 
> in gnome-color-manager, and loaded in darktable through colord.
>
> When I change the ICC profile on Gnome with darktable open, the colors of the 
> darkroom preview change too (no matter if darktable uses the system display 
> profile or one built-in profile, like Adobe RGB). That is the contrast and 
> white point of the picture, plus the color of the UI.

what do you mean "if darktable uses"? in which setting? if you set the
output colour profile in the darkroom module, it'll change the export
output, not the display profile for darkroom mode.

the display profile we get from the system, via interaction with
colord/xiccd or by querying the xatom variable.

> So that means that the OS is stacking another color transformation on top of 
> darktable's one.

yes, but what you observe above is that we query the icc profile from
the system and apply it as display profile. the os is stacking the
video luts (VCGT as you noted below). these are loaded to the GPU as
part of your system's colour management setup.

> From this article (2011), I get that gnome expects apps to take care of 
> themselves :
>
> One of the things I tried to deliberately ignore designing colord was 
> actually flipping pixel values. Colord is a very high level daemon that can 
> say to apps like Krita or GIMP “Use this profile for this device” rather than 
> them supplying a 140Mb memory buffer and an operation list. This means we can 
> do the conversion on the CPU using lcms2 for some programs and using the GPU 
> using a shader in things that use 3D. By not trying to wrap lcms we can let 
> the application do the pixel conversion in the right layer in the right way.

yes, that is correct.


> Of course, the downside of this is that you have to patch applications to 
> actually do the right thing. We can make this easier by doing some framework 
> code for Clutter and Cairo, but sooner or later the application has to know 
> about color management in one form or another. This is going to be my main 
> focus for GNOME 3.4; now we have all the framework installed and working and 
> we can say to application authors “It's already installed, so don't worry 
> about the additional dependency, just commit my patch and it'll just work”.
>
> But gnome-color-manager has no documentation, and even the Gnome color dev 
> documentation is pretty useless (a lot of "how to", no "what's going on", but 
> they found time to design a cheesy kindergarten theme).
>
> Looking at GDK pixbuf doc, they don't have tags to explicitely say "hey 
> that's already color-corrected so bug off". The Wikipedia entry of Linux 
> color management is as helpful and factual as a marketing director 
> motivational speech (let's increase the leverage of color management by 
> ensuring the quality of good devices, with a pro-active method to supervise 
> critical elements in a proficent way — sure !).
>
> As of now, I have seen no block diagram to describe the full color pipe in 
> Linux, nor any way to ensure the quality of the transform.
>
> From the info I have gathered, the pipe I have put together is as follow:
>
> || darktable pipe -> LCMS/(Internal cmatrix color correction + TRC) -> Cairo 
> surface -> GDK pixbuff -> || -> Mutter compositor -> (OS color correction ? 
> TRC ?) -> Xorg -> Nvidia/Intel GPU driver -> (Color correction ? VCGT ?) -> 
> || -> HDMI DAC (gamma 2.2) -> Screen
>
> So my question is : does anyone have any idea of what's going on with color 
> on Linux, or are we stacking ICC on top of shit just to pretend it's 
> color-managed magically, somehow ?

that graph seems to make sense to me. we do apply our custom cmatrix +
TRC in our own code because traditionally it was some faster than
using lcms2. also there was the issue of clipping at [0,1] (which was
resolved in lcms2 as well at some point). in addition to that there's
the VCGT which has to be setup. also note that we don't make up the
cmatrix ourselves but it is supplied to us by the desktop. i'd like to
stress that icc is really just a storage format: it's some blob
encoding from which we grab a matrix and shaper curve.

HDMI still uses a hardcoded gamma of 2.2? i didn't know that.

and yes, it takes some diligence to setup all the components that are
involved in the pipeline. we have "darktable-cmstest" to perform a few
high level sanity checks because of that. also be aware that some
monitors supply edid profiles which might make it into colord but are
in fact completely bogus. gnome colour manager is maintaining a list
of such profiles if i remember correctly.

cheers,
 jo


>
> Thanks,
>
> Aurélien.
>
>
> ___ 
> darktable developer mailing list to unsubscribe send a mail to 
> 

Re: [darktable-dev] what happens with linux color management ?

[johannes hanika]

re: colord: is there the more minimalistic xiccd maybe?

cheers,
 jo
On Sat, Nov 24, 2018 at 11:48 AM Alexander Rabtchevich
 wrote:
>
> Hello
>
> And there is no colord in Mate desktop, at least on Linux Mint. So I have to 
> select correct profile from the list manually each time I load Darktable. 
> Could the last selection be saved and restored? Or could the settings include 
> preferred monitor profile to be loaded if darktable failed to find system one?
>
> With respect,
> Alexander Rabtchevich
> ___
> 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 happens with linux color management ?

[David Houlder]

On 25/11/18 12:57 pm, Aurélien Pierre wrote:

Le 24/11/2018 à 04:51, David Houlder a écrit :

On 24/11/18 3:22 am, Aurélien Pierre wrote:


Hi everyone,

my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it 
was the same when I used Gnome Shell.  I have a custom screen ICC 
profile installed in gnome-color-manager, and loaded in darktable 
through colord.


When I change the ICC profile on Gnome with darktable open, the 
colors of the darkroom preview change too (no matter if darktable 
uses the system display profile or one built-in profile, like Adobe 
RGB). That is the contrast and white point of the picture, plus the 
color of the UI.


So that means that the OS is stacking another color transformation 
on top of darktable's one.


Is it possible that you're just seeing the effects of the gamma ramps 
changing when they're loaded from the VCGT of the profile that you 
switch to?


When changing between D65 and D55 profiles, the colors take an amber 
shift, so it's not just a problem of VCGT.


The VCGT has curves for each colour channel, so it's possible for 
colours to shift if those curves are changed.


If you can change the profile without loading the VCGT (or restore 
the gamma ramps manually after the change) and the supposedly 
non-colour-managed parts of the UI change, then I'd say that there's 
some kind of double-correction happening, otherwise it's probably 
working as intended.




I don't know if messing directly with the VCGT is even possible.



You don't have to mess with the profile itself, you just have to prevent 
the gamma ramps being set from the VCGT in order to perform the 
experiment.  See


https://wiki.archlinux.org/index.php/ICC_profiles#Loading_ICC_profiles
https://packages.ubuntu.com/search?keywords=xcalib

e.g. after you switch profiles you could use xcalib to set the gamma 
ramps from the original profile, while leaving the _ICC_PROFILE atom(s) 
and colord pointing to to the new profile.


In fact, an even simpler experiment has just occurred to me: just run 
xcalib with each profile in turn and watch the display. That should give 
you a rough visual idea of how much of the profile's colour space 
transformation is being handled by the gamma ramps (VCGT).



Fromthis article 
 
(2011), I get that gnome expects apps to take care of themselves :


One of the things I tried to deliberately ignore designing
colord was actually flipping pixel values. Colord is a very high
level daemon that can say to apps like Krita or GIMP “Use this
profile for this device” rather than them supplying a 140Mb
memory buffer and an operation list. This means we can do the
conversion on the CPU using lcms2 for some programs and using
the GPU using a shader in things that use 3D. By not trying to
wrap lcms we can let the application do the pixel conversion in
the right layer in the right way.

Of course, the downside of this is that you have to patch
applications to actually do the right thing. We can make this
easier by doing some framework code for Clutter and Cairo, but
sooner or later the application has to know about color
management in one form or another. This is going to be my main
focus for GNOME 3.4; now we have all the framework installed and
working and we can say to application authors “It's already
installed, so don't worry about the additional dependency, just
commit my patch and it'll just work”.

But gnome-color-manager has no documentation, and even the Gnome 
color dev documentation is pretty useless (a lot of "how to", no 
"what's going on", but they found time to design a cheesy 
kindergarten theme).


Looking at GDK pixbuf doc, they don't have tags to explicitely say 
"hey that's already color-corrected so bug off". The Wikipedia entry 
ofLinux color management 
 is as helpful 
and factual as a marketing director motivational speech (let's 
increase the leverage of color management by ensuring the quality of 
good devices, with a pro-active method to supervise critical 
elements in a proficent way — sure !).


As of now, I have seen no block diagram to describe the full color 
pipe in Linux, nor any way to ensure the quality of the transform.


From the info I have gathered, the pipe I have put together is as 
follow:


|| darktable pipe -> LCMS/(Internal cmatrix color correction + TRC) 
-> Cairo surface -> GDK pixbuff -> || -> Mutter compositor -> (OS 
color correction ? TRC ?) -> Xorg -> Nvidia/Intel GPU driver -> 
(Color correction ? VCGT ?) -> || -> HDMI DAC (gamma 2.2) -> Screen


So my question is : does anyone have any idea of what's going on 
with color on Linux, or are we stacking ICC on top of shit just to 
pretend it's color-managed magically, somehow ?


Thanks,

Aurélien.

Re: [darktable-dev] what happens with linux color management ?

[Aurélien Pierre]

Le 24/11/2018 à 04:51, David Houlder a écrit :
> On 24/11/18 3:22 am, Aurélien Pierre wrote:
>>
>> Hi everyone,
>>
>> my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it
>> was the same when I used Gnome Shell.  I have a custom screen ICC
>> profile installed in gnome-color-manager, and loaded in darktable
>> through colord.
>>
>> When I change the ICC profile on Gnome with darktable open, the
>> colors of the darkroom preview change too (no matter if darktable
>> uses the system display profile or one built-in profile, like Adobe
>> RGB). That is the contrast and white point of the picture, plus the
>> color of the UI.
>>
>> So that means that the OS is stacking another color transformation on
>> top of darktable's one.
>>
> Is it possible that you're just seeing the effects of the gamma ramps
> changing when they're loaded from the VCGT of the profile that you
> switch to?
>
When changing between D65 and D55 profiles, the colors take an amber
shift, so it's not just a problem of VCGT.
>
> If you can change the profile without loading the VCGT (or restore the
> gamma ramps manually after the change) and the supposedly
> non-colour-managed parts of the UI change, then I'd say that there's
> some kind of double-correction happening, otherwise it's probably
> working as intended.
>
>
I don't know if messing directly with the VCGT is even possible.
>>
>> Fromthis article
>> 
>> (2011), I get that gnome expects apps to take care of themselves :
>>
>> One of the things I tried to deliberately ignore designing colord
>> was actually flipping pixel values. Colord is a very high level
>> daemon that can say to apps like Krita or GIMP “Use this profile
>> for this device” rather than them supplying a 140Mb memory buffer
>> and an operation list. This means we can do the conversion on the
>> CPU using lcms2 for some programs and using the GPU using a
>> shader in things that use 3D. By not trying to wrap lcms we can
>> let the application do the pixel conversion in the right layer in
>> the right way.
>>
>> Of course, the downside of this is that you have to patch
>> applications to actually do the right thing. We can make this
>> easier by doing some framework code for Clutter and Cairo, but
>> sooner or later the application has to know about color
>> management in one form or another. This is going to be my main
>> focus for GNOME 3.4; now we have all the framework installed and
>> working and we can say to application authors “It's already
>> installed, so don't worry about the additional dependency, just
>> commit my patch and it'll just work”.
>>
>> But gnome-color-manager has no documentation, and even the Gnome
>> color dev documentation is pretty useless (a lot of "how to", no
>> "what's going on", but they found time to design a cheesy
>> kindergarten theme).
>>
>> Looking at GDK pixbuf doc, they don't have tags to explicitely say
>> "hey that's already color-corrected so bug off". The Wikipedia entry
>> ofLinux color management
>>  is as helpful
>> and factual as a marketing director motivational speech (let's
>> increase the leverage of color management by ensuring the quality of
>> good devices, with a pro-active method to supervise critical elements
>> in a proficent way — sure !).
>>
>> As of now, I have seen no block diagram to describe the full color
>> pipe in Linux, nor any way to ensure the quality of the transform.
>>
>> From the info I have gathered, the pipe I have put together is as follow:
>>
>> || darktable pipe -> LCMS/(Internal cmatrix color correction + TRC)
>> -> Cairo surface -> GDK pixbuff -> || -> Mutter compositor -> (OS
>> color correction ? TRC ?) -> Xorg -> Nvidia/Intel GPU driver ->
>> (Color correction ? VCGT ?) -> || -> HDMI DAC (gamma 2.2) -> Screen
>>
>> So my question is : does anyone have any idea of what's going on with
>> color on Linux, or are we stacking ICC on top of shit just to pretend
>> it's color-managed magically, somehow ?
>>
>> Thanks,
>>
>> Aurélien.
>>
>>
>> ___
>> darktable developer mailing list to unsubscribe send a mail to
>> darktable-dev+unsubscr...@lists.darktable.org
>
>
> -- 
> David Houlder
> +61 2 6248 7463
> da...@davidhoulder.com
> https://davidhoulder.com
>
> ___
> 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

Aw: [darktable-dev] what happens with linux color management ?

[Alexander Rabtchevich]

Hello

And there is no colord in Mate desktop, at least on Linux Mint. So I have to 
select correct profile from the list manually each time I load Darktable. Could 
the last selection be saved and restored? Or could the settings include 
preferred monitor profile to be loaded if darktable failed to find system one?

With respect,
Alexander Rabtchevich
___
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org

Re: [darktable-dev] what happens with linux color management ?

[David Houlder]

On 24/11/18 3:22 am, Aurélien Pierre wrote:


Hi everyone,

my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it 
was the same when I used Gnome Shell.  I have a custom screen ICC 
profile installed in gnome-color-manager, and loaded in darktable 
through colord.


When I change the ICC profile on Gnome with darktable open, the colors 
of the darkroom preview change too (no matter if darktable uses the 
system display profile or one built-in profile, like Adobe RGB). That 
is the contrast and white point of the picture, plus the color of the UI.


So that means that the OS is stacking another color transformation on 
top of darktable's one.


Is it possible that you're just seeing the effects of the gamma ramps 
changing when they're loaded from the VCGT of the profile that you 
switch to?


If you can change the profile without loading the VCGT (or restore the 
gamma ramps manually after the change) and the supposedly 
non-colour-managed parts of the UI change, then I'd say that there's 
some kind of double-correction happening, otherwise it's probably 
working as intended.



Fromthis article 
 
(2011), I get that gnome expects apps to take care of themselves :


One of the things I tried to deliberately ignore designing colord
was actually flipping pixel values. Colord is a very high level
daemon that can say to apps like Krita or GIMP “Use this profile
for this device” rather than them supplying a 140Mb memory buffer
and an operation list. This means we can do the conversion on the
CPU using lcms2 for some programs and using the GPU using a shader
in things that use 3D. By not trying to wrap lcms we can let the
application do the pixel conversion in the right layer in the
right way.

Of course, the downside of this is that you have to patch
applications to actually do the right thing. We can make this
easier by doing some framework code for Clutter and Cairo, but
sooner or later the application has to know about color management
in one form or another. This is going to be my main focus for
GNOME 3.4; now we have all the framework installed and working and
we can say to application authors “It's already installed, so
don't worry about the additional dependency, just commit my patch
and it'll just work”.

But gnome-color-manager has no documentation, and even the Gnome color 
dev documentation is pretty useless (a lot of "how to", no "what's 
going on", but they found time to design a cheesy kindergarten theme).


Looking at GDK pixbuf doc, they don't have tags to explicitely say 
"hey that's already color-corrected so bug off". The Wikipedia entry 
ofLinux color management 
 is as helpful 
and factual as a marketing director motivational speech (let's 
increase the leverage of color management by ensuring the quality of 
good devices, with a pro-active method to supervise critical elements 
in a proficent way — sure !).


As of now, I have seen no block diagram to describe the full color 
pipe in Linux, nor any way to ensure the quality of the transform.


From the info I have gathered, the pipe I have put together is as follow:

|| darktable pipe -> LCMS/(Internal cmatrix color correction + TRC) -> 
Cairo surface -> GDK pixbuff -> || -> Mutter compositor -> (OS color 
correction ? TRC ?) -> Xorg -> Nvidia/Intel GPU driver -> (Color 
correction ? VCGT ?) -> || -> HDMI DAC (gamma 2.2) -> Screen


So my question is : does anyone have any idea of what's going on with 
color on Linux, or are we stacking ICC on top of shit just to pretend 
it's color-managed magically, somehow ?


Thanks,

Aurélien.


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



--
David Houlder
+61 2 6248 7463
da...@davidhoulder.com
https://davidhoulder.com


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

[darktable-dev] what happens with linux color management ?

[Aurélien Pierre]

Hi everyone,

my darktable is installed on Ubuntu Budgie (fork of Gnome 3), but it was
the same when I used Gnome Shell.  I have a custom screen ICC profile
installed in gnome-color-manager, and loaded in darktable through colord.

When I change the ICC profile on Gnome with darktable open, the colors
of the darkroom preview change too (no matter if darktable uses the
system display profile or one built-in profile, like Adobe RGB). That is
the contrast and white point of the picture, plus the color of the UI.

So that means that the OS is stacking another color transformation on
top of darktable's one.

Fromthis article

(2011), I get that gnome expects apps to take care of themselves :

One of the things I tried to deliberately ignore designing colord
was actually flipping pixel values. Colord is a very high level
daemon that can say to apps like Krita or GIMP “Use this profile for
this device” rather than them supplying a 140Mb memory buffer and an
operation list. This means we can do the conversion on the CPU using
lcms2 for some programs and using the GPU using a shader in things
that use 3D. By not trying to wrap lcms we can let the application
do the pixel conversion in the right layer in the right way.

Of course, the downside of this is that you have to patch
applications to actually do the right thing. We can make this easier
by doing some framework code for Clutter and Cairo, but sooner or
later the application has to know about color management in one form
or another. This is going to be my main focus for GNOME 3.4; now we
have all the framework installed and working and we can say to
application authors “It's already installed, so don't worry about
the additional dependency, just commit my patch and it'll just work”.

But gnome-color-manager has no documentation, and even the Gnome color
dev documentation is pretty useless (a lot of "how to", no "what's going
on", but they found time to design a cheesy kindergarten theme).

Looking at GDK pixbuf doc, they don't have tags to explicitely say "hey
that's already color-corrected so bug off". The Wikipedia entry ofLinux
color management 
is as helpful and factual as a marketing director motivational speech
(let's increase the leverage of color management by ensuring the quality
of good devices, with a pro-active method to supervise critical elements
in a proficent way — sure !).

As of now, I have seen no block diagram to describe the full color pipe
in Linux, nor any way to ensure the quality of the transform.

>From the info I have gathered, the pipe I have put together is as follow:

|| darktable pipe -> LCMS/(Internal cmatrix color correction + TRC) ->
Cairo surface -> GDK pixbuff -> || -> Mutter compositor -> (OS color
correction ? TRC ?) -> Xorg -> Nvidia/Intel GPU driver -> (Color
correction ? VCGT ?) -> || -> HDMI DAC (gamma 2.2) -> Screen

So my question is : does anyone have any idea of what's going on with
color on Linux, or are we stacking ICC on top of shit just to pretend
it's color-managed magically, somehow ?

Thanks,

Aurélien.


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