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
<http://libregraphicsworld.org/blog/entry/richard-hughes-on-color-management-in-linux-and-gnome>
(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
<https://en.wikipedia.org/wiki/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 ?
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
--
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
