[Digikam-users] editing with Color Management enabled is very slow?

[Elle Stone]

On 3/25/13, Marcel Wiesweg <marcel.wiesweg at gmx.de> wrote:
>
>
>> > There is a configuration switch to use lcms2, I have not yet tested
>> > this. Default is lcms1.
>>
>> Thanks! Marcel. Is this a compile time switch? I don't see any options
>> that mention lcms in the digiKam settings.
>
> Yes, this is a CMake option
> OPTION(ENABLE_LCMS2            "Link digiKam to LCMS2 instead LCMS1
> (experimental) (default=OFF)"      OFF)

Thanks! I'll give it whirl and see what happens. I wonder if the
Kubuntu digiKam 3 binary was compiled with lcms1 or lcms2.

>> 1. Specify a default "system" monitor profile.
>> 2. Load the default "system" monitor profile "vcgt" information (if
>> there is any) to the video LUTS.
>> 3. Assist the user in managing all their monitor, printer, scanner,
>> camera, working space, and etc, profiles. "Managing profiles" means
>> knowing *which profile*, located *where* on your system, is available
>> for *what purpose*. "Managing" doesn't include actually doing any ICC
>> profile conversions.
>> 4. Assist the user in creating device profiles (colorhug/colord; not
>> sure if KDE Desktop color management has anything equivalent).
>
> All these, particularly 3), having reliably implemented on our target
> systems is something I am looking forward to.
>

Is it OK if I ask why particularly 3? Here's why I'm asking:

I switched to Linux only after making sure that Linux color management
really works, meaning I could supply a monitor profile, open an image
in a color-managed application, and see the right colors. I consider
Linux color management to be one of the crown jewels of open source
photography, and it's always worked perfectly for me. "How to color
manage under Linux" (my "how", not necessarily someone else's) is
pretty simple:

1. Use argyllcms to create a monitor profile and a camera profile.

2a. Use argyllcms to install the monitor profile (which also loads the
vcgt tag if needed) AND/OR
2b. Directly tell the color managed application which monitor profile to use.

3. Make the appropriate other color management options settings in the
color-managed application (always ask, don't automatically convert,
etc).

I'm guessing that most people only use a handful of ICC profiles (a
couple of monitor profiles, a couple of camera profiles, sRGB, and a
couple of larger working space such as ProPhoto; maybe  some printer
or scanner profiles). So I'm puzzled as to what Desktop ICC color
management, and especially ICC profile management, brings to the
already bountiful table that is Linux color management. I've been
puzzling over this question of "why Desktop CM" for quite a while now
and any insight/points of view from people who are using KDE and/or
Gnome CM would be very most gratefully accepted.

>> As Remco says, conceptually speaking there is a profound difference
>> between an artificial working space profile such as ProPhoto or
>> BetaRGB, and a device profile such as a monitor profile or a printer
>> profile (device profiles "characterize" whereas working space profiles
>> "define how to code the color" as Remco says). But practically
>> speaking, whether converting from one working space profile to
>> another, or from a working space profile to a device profile, an ICC
>> profile conversion is used.
>
> I have developed a (probably simplistic) understanding which leads me when
> coding CM support:
> Whenever I have pixel data, I need a color profile which tells me how to
> interpret the numbers.
> When I have a file in sRGB and the user wants to edit images in AdobeRGB, I
>
> tell lcms to convert the pixel numbers. When the AdobeRGB pixels from the
> image editor are displayed on the monitor which has a profile, I tell lcms
> to
> convert the pixel numbers. When the user wants to save the file, I add the
> AdbobeRGB profile to the metadata.
>

 I'm very far from being an expert on LCMS, but I've wrestled with the
code and your understanding sounds perfect to me - feed LCMS the
starting and ending profiles, image types, and conversion flags (use
or not use black point compensation, which conversion intent, whether
to use slower/higher quality routines or faster routines, etc). Did
you write the LCMS code for digiKam?

>> That is interesting. As you say, it appears that digiKam (a KDE/qt
>> app) isn't aware that colord assigned a system monitor profile.
>
> At the moment, we only support the ancient XAtom solution. If there is any
> modern solution, via DBus or whatever, we dont read it.

The X atom is still used, yes? It's the same as the _ICC_PROFILE atom?
For anyone who is curious, these two pages explain (not very well
imho) what the _ICC_PROFILE atom is:

http://www.burtonini.com/computing/x-icc-profiles-spec-0.2.html
 "Currently there is only one atom base name defined.
_ICC_PROFILE The _ICC_PROFILE atom is set on the root window of the
default (first) screen . . . The value of the atom should be a literal
ICC profile, that applications can read and parse directly."
http://www.oyranos.org/wiki/index.php?title=ICC_Profiles_in_X_Specification_0.4

Quoting from the colord documentation
(http://www.freedesktop.org/software/colord/intro.html):

* Integration X11 by setting the per-screen and per-output
_ICC_PROFILE atom, which makes applications such as the GIMP use a
color managed output.
* Easy to use D-Bus interface for applications to query what ICC
profiles should be used for a specific device or device type.

I interpreted the first bullet above to mean that colord can set the
_ICC_PROFILE (same as X?) atom, and the second bullet to mean that
other applications can (but don't have to) use dbus to query colord
about what profiles are available to use for what purposes.

If I understand the colord documentation, and if colord really did set
the _ICC_PROFILE atom, then digiKam should be able to read it. So if
digikam can't read it, then either it wasn't really set (even if the
user went through the motions), or it was set improperly (not sure if
that's even possible). Which is why I asked Erik or Gus whether any of
the GTK/Gnome applications were picking up the installed monitor
profile.

Elle


-- 
http://ninedegreesbelow.com - articles on open source digital photography