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

[Elle Stone]

On 3/22/13, Erik Felthauser <efelthauser at gmail.com> wrote:
> On Fri, Mar 22, 2013 at 4:25 PM, Marcel Wiesweg
> <marcel.wiesweg at gmx.de>wrote:
>
>>
>> Digikam's color management was written when there was no KDE-wide
>> support, no support in KWin or the graphics stack.

Is digiKam 3.1 still using lcms v1? or has it switched entirely to lcms2?

>> It reads the monitor profile from the
>> old-style XAtom, but then the internal configuration option will be
>> greyed out.
>>
> Not sure what you mean by "internal config option will be greyed out"...No
> option in digiKam is greyed out for me...

In digiKam 3.1 (on openSUSE 12.2), the option to change the Monitor
profile (Settings/Color Management/Profiles/Monito profile) isn't
*literally* grayed out when a system monitor profile is being used.
But it says "Monitor Profile from System Settings" and it's not
possible to choose a different monitor profile.

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.

>
>> I suspect double correction if you set the profile in both places.
>>

How would "double correction" be accomplished?

It is easy enough to set ProfileA, with vcgt-tagA, as the system
profile (which means vcgt-tagA values should be loaded into the
videocard LUT), and then use ProfileB with a color-managed application
that is capable of ignoring the system profile (eg Krita 2.6, Gimp,
UFRaw, Cinepaint). In this case the resulting colors/tonality would be
wrong unless both monitor profiles use the same vcgt tag values.

But digiKam doesn't allow choosing a monitor profile if a system
monitor profile is installed, unless somehow the kde stuff sets the
system monitor profile in a way that digiKam doesn't understand. I
also don't think digiKam is capable of loading the monitor profile
vcgt tag values (if any) into the video card LUT, but if it *were*
capable of doing so, wouldn't it just be reloading the same values
that had already been loaded?

>
> Then, do you know: If I turn off CM in digiKam, does digiKam show pics with
> corrected colors for monitor, thanks to KDE color manager?

The only way digiKam can show the correct colors when color management
is disabled is if your monitor is *calibrated* to match the sRGB color
space and you only work with sRGB images. Whether your monitor is
calibrated to sRGB depends on the settings you use to create your
monitor profile. Some degree of calibration is almost always a part of
the monitor profiling process, unless you deliberately make a "native"
monitor profile. But typically with LCDs calibration is limited to
setting brightness (usually 75-100cd/m2 for image editing), a white
point (often D65), and a gamma/tone-response curve (usually something
close to the sRGB TRC).

If your monitor is sufficiently closely calibrated to match sRGB then
you can disable color management (if you only work with sRGB images)
or else just use sRGB as your monitor profile. Unfortunately most LCD
monitors actually can't be calibrated to *exactly* match sRGB; and
depending on the monitor, the resulting "after calibration" monitor
profile often has a smaller color gamut than sRGB and also smaller
than what the monitor can achieve "natively" (that is, with no
calibration prior to profiling, other than setting the brightness).

"Disable Color Management" ought to mean that the RGB values from your
image are sent directly to the monitor screen, with no intervening ICC
profile transforms. The same thing ought to happen when you *do* use
color management, IF two things are true: (1)your image profile is
sRGB and (2)you set your monitor profile to sRGB. In other words, if
the image and monitor profiles exactly match, there should be no ICC
profile transform being done when sending the image to the screen.
(However, as already noted, the image colors will display incorrectly
unless you also have already calibrated your monitor to match sRGB.)

> Also, I shoot in sRGB, so I guess it is not a worry about the working
> space?? But for someone shooting AdobeRGB, then they DO need to use digiKam
> internal CM, right, to ensure conversion for working space?

Yes, you need color management and a good monitor profile to work with
AdobeRGB images, otherwise many colors will look more saturated than
they are in reality (assuming you don't have a wide-gamut monitor).
And to work with sRGB images you also need color management and a good
monitor profile, OR a monitor that is calibrated to the sRGB color
space; otherwise you can't trust what your monitor shows you.

>>
>> digikam uses lcms and computes color correction on the CPU. I have a weaker
>> machine and experience only very short delays if I set a monitor profile other
>> the sRGB. It probably scales linearly with image size. I do not know if your
>
> own monitor profile is very cost intensive to use, you could try another
> for testing.
>>

>
> Is your "other profile" a custom one? I noticed that the non-custom
> profiles that appear in my /home/erik/.local/share/icc/ are about 1KB only.
> However, the one I created with ColorHug is 24KB. Perhaps it is TOO "High
> Quality". Maybe I can make a lesser-quality one, that requires less CPU?

> I do know that if I use the default manufacturer one (don't know where it
> came from -- maybe ColorHug live CD or digiKam downloaded it?), which is
> only about 1KB, it is less slow, but still not great. Takes maybe half as
> long compared to custom profile.

The "default manufacturer one" possibly was pulled from the monitor
hardware EDID information. Oyranos can do that (and does, if it
doesn't find an installed monitor profile). I'm not sure if colord
can/does pull the EDID monitor profile and write it to disk.

Regarding profile size, my own custom monitor profile is an Argyllcms
matrix+shaper-curves ("-as") profile. It's about 42kb. Most of that
size is from the targ, DevD, and CIED tags; these tags could be
entirely removed from the profile without affecting how the profile
works - they are just information tags. I don't see how the presence
or absence of these tags could make color-managed editing slower.

If your monitor profile is a LUT profile (doubtful), then I could see
how it might slow things down, depending on how digiKam uses lcms
and/or lcms2. However, a high quality LUT profile would be quite a bit
bigger than 24KB.

Probably the extra size of your monitor profile compared to say, the
standard sRGB profile, is from the monitor profile "vcgt" tag which
"calibrates" by altering the video card LUTs (but only if the vcgt
information is actually loaded into the videocard LUT, which is part
of what happens when a profile is installed as the system monitor
profile).

If you have wine installed, you can use the ICC Profile Inspector
(available from color.org) to examine your monitor profile tags to see
where the extra size comes from. Or use IccXml, which is probably
available from your repositories (and also from sourceforge).

Or if you have icc_examin installed, then icc_examin will show you the
contents of the vcgt, DevD, targ, and CIED tags (but only if these
tags exist in the profile - if they aren't listed, they don't exist).
Installing icc_examin will bring along oyranos, and I don't know how
well oyranos and colord work together when it comes to actually
managing your system monitor profiles - I have both installed but
don't use either one to set my system monitor profile.

> I guess I may try to run ColorHug again, but it sounds like I am not the
> only one with the problem...

>> Just to be sure, you turn and off CM in digikam and experience the
>> differences, while system CM is constantly turned on?
>>
>
> That is correct.
>

Have you tried the opposite approach? *Not* using the kde/system CM to
set the system monitor profile? and telling digiKam directly to use
your monitor profile?

I'm not sure how one would go about doing this using the kde color
settings dialogs, because even though I'm running a lot of kde apps,
and have all the core kde desktop stuff installed, I can't get the kde
system-color-management stuff to acknowledge that I actually have a
monitor or any monitor profiles. Which doesn't bother me because
usually I log into an IceWM session (less CPU power going to the
desktop itself), and I install my monitor profile as the system
monitor profile using the .xinitrc file in my home folder.

You can install a system monitor profile from the command line using
these argyllcms commands:

#clear the existing vcgt information
dispwin -c
#install the monitor profile
dispwin -I /path/to/your-chosen-monitor-profile.icc

The above command assumes the vcgt information is already inside the
ICC monitor profile (which is probably the case); else it uses a
linear vcgt file. FWIW, I don't need to be root to run these commands
on my system.

If what you are already doing is working for you, proceed with caution
with experimenting to disable the kde color management unless you know
how to re-enable it (maybe just restarting the computer?); I don't
know how to re-enable kde's color management, not being able to enable
it in the first place.

As an aside, my website home page, http://ninedegreesbelow.com, has
links to three articles that you might find helpful in understanding
color management and monitor profiles (none of the articles discuss
the problem of image editing slowing down from using color
management):

*Color Management Experiment Kit (starter kit): If seeing is
believing, does your monitor profile matter?
* sRGB, the universal monitor profile, not so good for LCD monitors
* Profiling Your Monitor — popular confusions, hopefully cleared

My apologies for being so long-winded!

Elle


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