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 >> <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
