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

[Elle Stone]

On 3/24/13, Marcel Wiesweg <marcel.wiesweg at gmx.de> wrote:
>
>>
>> Is digiKam 3.1 still using lcms v1? or has it switched entirely to lcms2?
>
> 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.

>>  I also don't think digiKam is capable of loading the monitor profile
>
> it cannot access the LUT

Good to know - reading and handling the vcgt tag should be left up to
the Desktop color management module or whatever other application the
user chooses for loading the vcgt information (if any, it depends on
the monitor profile).

>
> If digikam converts from the working color space to the monitor profile, and
> KDE thinks it is sRGB and converts again to the monitor profile, that would
> be double correction, isnt it?

That would be a case of double correction. But that doesn't and can't
happen at present because the KDE and Gnome Desktop color management
"frameworks" (to use the colord preferred terminology) don't do ICC
profile conversions.

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

"Does colord or GNOME Color Manager convert my image? No. You need to
use a pixel conversion library, for instance lcms2."

At present Desktop color management enables the user to accomplish (at
least) these tasks:

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

The command line can be used for tasks 1, 2, and 4; and not everyone
needs sophisticated profile management (I know where all my ICC
profiles are located and what they are used for). But some people find
KDE/Gnome Desktop color management more convenient and user-friendly
than command line tools, and that's the whole point of KDE/Gnome color
management: making color management a little easier to use.

> I really did not look into the new KDE CM stuff.
> In my dreams, I assign a profile to a region on screen, and the window
> manager knows the monitor profile, and handles the color conversion.

Letting KDE or Gnome Desktop color management handle all ICC profile
conversions from the image window to the display screen would require
a rewrite of all the color-managed applications to remove or at least
make optional the relevant color-conversion code (to avoid
double-conversions), and a rewrite of the Gnome AND the KDE Desktop
code to add ICC profile conversion code, plus the ability to detect
which color-managed application window wants which ICC profile.

It seems to me that having the Desktop do all ICC profile conversions
from the image window to the display screen would limit the user's and
also the editing application's creative choices: What if the user
wanted to use relative colorimetric intent for one open application,
perceptual for another? Or use a LUT monitor profile for one
application and a matrix monitor profile for another? Or use
highest-quality ICC profile conversion for one open application and a
lower-quality profile conversion for another?

What if you are trying to softproof to the screen in one open
application, while in another you are merely looking at images? What
if one application wants to use cairo and another doesn't? I've looked
at the ICC profile conversion code in digiKam (older version), Krita,
Cinepaint, and Gimp. All of these color-managed applications use LCMS
(1 or 2, depending). But each of them uses LCMS ***very***
differently, even for such a "simple" thing as sending information to
the display screen.

On 3/24/13, Remco Viëtor <remco.vietor at wanadoo.fr> wrote:
> On Sunday 24 March 2013 19:39:37 Marcel Wiesweg wrote:
>>
> Don't mix up colour space and correction profile:
> colour space defines how to code a given colour, for an ideal system
> correction profile says how to correct that ideal colour so that it
> looks correct on /your/ screen.
>
> You don't assign a colour space to a monitor, and you don't assign a
> correction profile to an image...

I'm not sure what you mean by "ideal" but it sounds interesting - the
ideal monitor "sees" just what the human eye sees? So the transform
from the Profile Connection Space to the monitor space is an identity
transform?

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.

On 3/24/13, Erik Felthauser <efelthauser at gmail.com> wrote:
> On Sun, Mar 24, 2013 at 12:12 PM, Elle Stone <l.elle.stone at gmail.com>
> wrote:
>> When you look at "Settings/Color Management/Profiles/Monitor profile",
>> what does it say? Can you choose a different profile than the one that
>> is pre-selected? If the answer is yes, then probably digiKam isn't
>> picking up the system-set profile, or else there really isn't a
>> system-set profile.
>>
>
> Yes, I am able to select a different monitor profile even when system
> monitor device correction profile is set via colord, actually, I have to,
> because I do not even have such an option as "Monitor Profile from System
> Settings" in my DK CM monitor profile list... It appears digiKam (i'm
> running 3.0.0.) is not aware of colord or something. Maybe it is an issue
> with KDE not announcing properly, maybe digiKam not listening, or maybe my
> setup in particular...

That is interesting. As you say, it appears that digiKam (a KDE/qt
app) isn't aware that colord assigned a system monitor profile. Do you
have Gimp (a Gnome/gtk app) on your computer? Is Gimp aware that you
have a system monitor profile?

Elle


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