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

[Marcel Wiesweg]

> Is it OK if I ask why particularly 3? Here's why I'm asking:
> 
> 
> 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. 

We want to support color management enabled by default, and we want it to 
"just work". There is some low-level code involved, like scanning hard coded 
file paths on Linux for profile files. This works quite ok but it feels 
"dirty", this falls into abstraction layers which IMO should be placed at a 
desktop wide layer.
The bonus we get is single configuration, and correct color management in 
multiple applications.

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

The initial support was written by F J Cruz, the code was mostly feature 
complete, but structurally not clean and contained a number of larger bugs.
Around 2009, I have looked into this area, structured it in clean C++ classes, 
and tried to make a config UI which allows it to just work.

> The X atom is still used, yes? It's the same as the _ICC_PROFILE atom?

Yes, exactly

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

Yes, sounds as if digikam should be able to read it. I have personally never 
tested with colord, though. I wouldn't say it's not a problem on digikam's 
side.

Marcel