heya, On Fri, Nov 23, 2018 at 5:24 PM Aurélien Pierre <rese...@aurelienpierre.com> 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 > darktable-dev+unsubscr...@lists.darktable.org ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
