KDE and Colour Management

Posted on by

Colour Management has a long way to come to the Linux desktop. Like on other computing environments first came single applications like Scribus, CinePaint or Krita and proved colour management be useful and mature. Now the open source Desktop stacks are following. Most advanced and wide spread inside colour managed applications is colour correction for monitors.

For KDE exists the KolorManager systemsettings panel for configuring a ICC profile per monitor device. It´s Oyranos CMS cares as well about setup of standard Xorg _ICC_PROFILE(_xxx) root window atoms and video card graphics table (VCGT). The later is a one dimensional per channel colour correction feature. So expect no magic all included solution by this means.

The heart of today most wide spread colour management systems is the ICC file specification. And to get ICC style Colour Management working inside KDE, the framework has to handle several needs.

One is to provide a overall desktop colour correction, which applies to the whole monitor screen area. A Desktop Colour Server will improve the overall Desktop usability and appearance in heterogeneous environments like Linux. Obviously colour measurement devices and early colour correcting applications need native access to the monitor colour space. The currently only full featured and backward compatible implementation of that scheme for Linux is the CompICC plugin to Compiz. The CompICC colour server assumes sRGB for all input. Output target is the actual monitor profile set e.g. by KolorManager. More details can be read in a older blog post. Given that colour servers are still pretty rare, only osX and CompICC provide that, it might not be a good goal for the foreseeable future to let all applications rely solely on that feature for their colour corrections. But it has the potential to the most slick and flexible desktop colour experience.

On the Input side ICC profiles and according Exif meta data need to be detected from the input streams and get appropriately assigned as ICC meta data to graphics objects. That can be application specific but is a very common task, which will be better implemented on the toolkit or framework level. The display component should then make use of this ICC meta data and do on the fly colour correction. As well file output needs support of embedding the ICC profile data back into the data stream.

Alongside the ICC data handling come options and preference management, which is covered by the KolorManager GUI to the Oyranos API.

20 thoughts on “KDE and Colour Management”

  2. Oho. Colord is the “yet another implementation”, which refused to integrate its goals into preexisting CMS´es like ArgyllCMS or Oyranos. But that´s only about history, which you can followup here a bit: http://blogs.gnome.org/hughsie/2009/11/02/gnome-color-manager-progress/

    What counts today is a very different understanding about, what makes a good colour management system. The colord author has failed to meet many criteria and was so far not very cooperative to accept some very common demands from various people in the colour community. Given that it is very unlikely that changes we need would be accepted by colord´s author. I am very sorry about that, as I was initially very euphoric about a new Gnome colour management contributor.

    Beside that I believe, Oyranos is from a architectural level much better designed, because it relies as good as possible on existing standards, which colord does not care about.

    Oyranos is needed to keep different concepts and goals alive. And I think it fits way better to KDE´s flexibility and useability requirements.

  3. Some thoughts from an application developer’s point of view:
    Oyranos proposed as a/the solution to color management. As an application developer, I ask myself what it actually is - is it a libary? is it a configuration module? A system-level settings daemon? And apparently, it’s a bit of all of that.

    Now we have at least three different problems to solve
    1) I need the actual color management implementation. Finding profiles from pictures, having a defined workspace profile, conversion, and output to a specified display or output profile. Problem: I will not use oyranos for that, but keep my own implementation based directly in liblcms. Really. I want to design the UI myself, decide about sane defaults, decide how I want to design the config dialog and which options are presented to the user. For me, these are application-specific options and not system-wide ones. For the “simple” application which does not do color manipulation as core functionality, possibly based on QImage, oyranos may be a good fit, but then with an easy to use Qt style API. Should aim at kdegraphics-libs at least

    2) The system integration. For digikam, we scan all profile paths and ship the crucial profiles ourselves. We certainly need a system integration layer which
    a) keeps a repository of available color profiles
    b) ensures that crucial profiles - sRGB, AdobeRGB, WideGamut, ProPhoto - are available, absolutely and always.
    c) Manage display profile setting, and all involved graphics card interaction. Application can query the profile old-style (X atom) and new-style (C++ API)
    d) Manage output profile settings per-device. This should be integrated into the existing APIs to manage scanners and printers; on KDE, there’s libksane for scanning, and the Qt printing APIs for printing.
    e) For applications to access a) through d), there should be a C++ wrapper API to access these properties. Absolutely important: The mid-term goal should be to get this library into kdegraphics-libs at least, better kdelibs or even Qt itself.

    3) Setup: The systemsettings module to fine-tune 2) and default options for 1). For the normal user (display profile sRGB), no setup should be required, color management up and running per default for any user who does not know what color management is

    4) Advanced setup: Manage calibration devices to create color profiles. Plug-and-play, one-click, UI, no command line, no option to think of.

    • Correct Oyranos could theoretical be split further into each single component. But as I do now integration into one distribution, I find it time rather consuming.

      to 1) At first glance individual per application settings appear reasonable. At a second view, users love to share things in their workflow. Adobe Bridge is much appreciated because it allows to share settings. The need to change everything just because the applications have no way to share thing is for many users not so comfortable. And there is the popular Gimp example. It ships with display profile selection from the internal colour management dialog. The system one is ignored - bingo. By this setting Gimp breaks colour wise in some environments. The user has to find that out for the per application settings. More options more chances to fail combined with bad defaults. I can imagine using Oyranos setting as a default and allowing for overriding and resyncing with these system settings could work out as a good thing for your advanced users and much more for the many none advanced users. Why should digikam and inkscape or Krita use different editing space (workspace) settings?
      QImage integration would be cool to have. That´s a good way to go. If well integrated with system stuff that could help many users.

      to 2b) Oyranos relies as well on the sRGB one. The other ones, if quality and license wise appropriate, could be integrated into the icc-profiles-openicc package. Can you point me to the repository to take a look at them? I would like to discuss that on the OpenICC list.
      2c) A C++ API layer is in preparation for Oyranos.
      2d) This integration is a end goal, but still needs more work to do properly beforehand to work properly.
      2e) good hint

      to 3) agreed. Many users should have no need to fiddle with settings.

      to 4) We do not have so many open source profilers. The most advanced one is dispcalGUI. All of them except LProf are based on ArgyllCMS.

      • We ship a set of profiles in libkdcraw:
        http://quickgit.kde.org/?p=libkdcraw.git&a=tree&f=profiles
        srgb-d65.icm, compatibleWithAdobeRGB1998.icc, widegamut.icm, prophoto.icm. (the other files there are broken and should be ignored) License was once checked and seems ok.
        One of the reasons is obviously that distributions do not guarantee that profiles are installed, so we ship it with a library on which we depend…

        I agree with common/shared settings for the default workspace profile. Some other settings are more complex, behavior when profile is missing or profile differs.
        Example: Tab 1 of digikam’s color settings. These can be asked system-wide, but implementation details will make it pretty difficult to find a generic solution:
        http://wstaw.org/m/2011/11/14/plasma-desktopMM1796.jpg
        Tab 2 of the settings: I would like to get completely rid of this tab and be able to query all this from system settings (note the inadequacy of having only one input and one output profile):
        http://wstaw.org/m/2011/11/14/plasma-desktopTG1796.jpg

        • A sRGB and compatibleWithAdobeRGB1998.icc is as well in the icc-profiles-openicc package.
          It would be nice to have very reliable sources for such crucial profiles. I will ask the ICC about the other ones.

          The icc-profiles-openicc can be required by your package. They should be present as soon as Oyranos is packaged like in the new openSUSE.

        • Some of the libkdcraw profiles look non relyable. These from the Scarse project. There are different reviews on the net mentioning the Scarse profiles, which hint problems. In my eyes, it makes sense to replace these profiles. But that will need some time.

  4. What about CUPS and other system-wide daemon integration ? one of the things that I love from colord is that it is fully integrated in CUPS and even v4l nowdays.

    Why is oyranos architecture better than colord ? so far I like what colord has though I’m no expert in color management from the external-logical point of view it makes sense.

    Also, can you point me to what requests Richard wasn’t willing to implement? Some people within the Solid community have been working with him and so far all I heard is good feedback…

    Anyway, glad to know that somebody else is working on color management, something else I can remove from my ToDo list.

    Ah also, there are some guys from krita and other parts of KDE working on it, you may want to use our mailists (kde-devel, kde-hardware-devel) to talk about this great project.

    • CUPS is not a desktop daemon like the gnome-settings-daemon. It is a completely independent server, with a whole bunch of features, which can not easily be circumvented. I argued on the OpenICC list to take CUPS communication serious and communicate through well defined APIs. Colord has chosen to take the opposite route and concentrate on side hacking colord support into CUPS by following a misguiding CUPS API for osX example. I can not see how that will scale in the future. Oyranos goes the longer route to follow existing standards and communicate through these with CUPS. We had at OpenICC a GSoC project, which was called XCPD to explore that route and support that. Oyranos was adapted to the evolving needs by this project.

      Oyranos is modular and substitutable. Colord tries to be indispensable, with lots of implications into system design. E.g. it needs to run as root daemon. Btw. that hard requirement comes from the above mentioned CUPS hack. Oyranos does not need by default root privileges and still works. Colord is practical useless without all those hooks, it started to imply on other system components. That´s a monolithic approach in colord. That approach was not yet deployed in heterogeneous environments. Many systems care nowadays much more about interoperability, e.g. osX and CUPS itself do.

      Obviously I am not a fan of many of his designs in the colour management field. As I am not a user of his ideas and implementations, but a independent maintainer of a CMS, I had not so nice experience so far. One example are the crippled Oyranos profiles in the shared-color-profiles package. It took him half a year to fix that halfheartedly and only after a license bug in the Fedora tracker. The ICC profile review on OpenICC, which showed many issues, had no direct effect for his data I am aware of.

      If we can further discuss stuff and exchange insights, that would be great. E.g. one bug tracker entry, I´ve seen, is the integration of profile selection into the KDE monitor panel.

      Krita developers are really nice and helped already setting up KolorManager on SVN years ago. To kde-devel I am subscribed and discussed there KWin colour management signing my emails with Kai-Uwe Behrmann. Might subscribe as well with kde-hardware-devel later on.

  5. compicc is outdated unfortunately, cant be used since compiz 0.9……….

    according to the developer:

    >with Compiz 0.9.x we are out of luck as it features a C++ API. CompICC
    >only supports the elder C API up to Compiz 0.8.x.

  6. Pingback: Zero tolerance « Getting Things Done

  7. So, is CUPS or will CUPS work with Kolor Management?

    BTW, would be awesome if we can drop the K and call it just Color Management :p

    • Once XCPD is integrated into print dialogs, user configured ICC profiles from KolorManager can easily be passed through CUPS to the actual PDF renderer. Regardless of that, CUPS maintains a path to configure vendor side device profiles in PPDs. A independent colour managed print application is PhotoPrint.

      The K stands for KDE, which is KolorManager about. So far users see only Color Management in their system settings panel.

  9. Pingback: Links 20/11/2011: GNU/Linux in Tamil Nadu, Flex Donated to Apache | Techrights

Comments are closed.