editing with Color Management enabled is very slow?
Locked
12
12
editing with Color Management enabled is very slow?
 
|
OS and software: Kubuntu 12.10 with kubuntu-backports ppa (digiKam 3.0.0)
processor: Core 2 Duo T6400 2.0 GHz 800 MHz FSB 2 MB L2 (35 W) memory: 4 GB - DDR2 800 MHz - 2 DIMMs
monitor colorimeter: ColorHug hardware, with ICC monitor profile set to "High Quality" I have applied the monitor profile created with ColorHug in two places: in the KDE system color settings option, and also in digiKam color management settings.
My photos are mostly 12MP, JPG or PNG. When I do not have color management enabled, editing photos is quite fast. When I turn on color management, editing photos is so slow. Just opening the editing window takes fully 5 to 8 seconds. Even just selecting an area for cropping, takes 5 second for the system to catch up, and CPU goes up very high, 50% just for making selection, 100% for other things. Resize the selection area takes 5 sec or more.
Turn off color management again, and everything is fast again. Opening edit window is immediate, selection is immediate, etc. My questions:
1. Since I have set monitor ICC profile in KDE system settings already, can I turn off digiKam's own color management, and digiKam will still be showing the correct colors for my monitor / profile? 2. If yes to question #1, what working color space is digiKam using when its color management option is turned off? sRGB? sRGB-D65? 3. If yes to question #1, then, I think I only need to turn on color management in digiKam when I want to do soft-proofing for printer, is that right? (Since I have applied ICC in system settings?)
4. Is it bad to have monitor profile set in both system and in digiKam? Does this apply corrections twice, causing over-correction? Or maybe this is why so slow?
5. Why is it so slow to set color management in digiKam? Is my computer hardware just too old and slow? If I buy a new computer with Intel i7 processor and 16GB DDR3 memory, will it be fast then? Or is the problem that digiKam is not yet optimized to be fast with color management editing?
Thank you very much, Erik _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
Hello Erik,
thanks for asking. That's what I'm also thinking about quite a while.
More out of a bunch questions after having fixed my update disaster on my notbook.
H. Jürgen Karbach
Am 22. März 2013, 09:48:39 schrieb Erik Felthauser: OS and software: Kubuntu 12.10 with kubuntu-backports ppa (digiKam 3.0.0) processor: Core 2 Duo T6400 2.0 GHz 800 MHz FSB 2 MB L2 (35 W) memory: 4 GB - DDR2 800 MHz - 2 DIMMs monitor colorimeter: ColorHug hardware, with ICC monitor profile set to "High Quality" I have applied the monitor profile created with ColorHug in two places: in the KDE system color settings option, and also in digiKam color management settings. My photos are mostly 12MP, JPG or PNG. When I do not have color management enabled, editing photos is quite fast. When I turn on color management, editing photos is so slow. Just opening the editing window takes fully 5 to 8 seconds. Even just selecting an area for cropping, takes 5 second for the system to catch up, and CPU goes up very high, 50% just for making selection, 100% for other things. Resize the selection area takes 5 sec or more. Turn off color management again, and everything is fast again. Opening edit window is immediate, selection is immediate, etc. My questions: 1. Since I have set monitor ICC profile in KDE system settings already, can I turn off digiKam's own color management, and digiKam will still be showing the correct colors for my monitor / profile? 2. If yes to question #1, what working color space is digiKam using when its color management option is turned off? sRGB? sRGB-D65? 3. If yes to question #1, then, I think I only need to turn on color management in digiKam when I want to do soft-proofing for printer, is that right? (Since I have applied ICC in system settings?) 4. Is it bad to have monitor profile set in both system and in digiKam? Does this apply corrections twice, causing over-correction? Or maybe this is why so slow? 5. Why is it so slow to set color management in digiKam? Is my computer hardware just too old and slow? If I buy a new computer with Intel i7 processor and 16GB DDR3 memory, will it be fast then? Or is the problem that digiKam is not yet optimized to be fast with color management editing? Thank you very much, Erik _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
In reply to this post by Gus Gustafson
Digikam's color management was written when there was no KDE-wide support, no support in KWin or the graphics stack. It reads the monitor profile from the old-style XAtom, but then the internal configuration option will be greyed out. I suspect double correction if you set the profile in both places. 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. Just to be sure, you turn and off CM in digikam and experience the differences, while system CM is constantly turned on? Marcel _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
Hi Marcel,
Thanks for your response. See my comments interspersed: On Fri, Mar 22, 2013 at 4:25 PM, Marcel Wiesweg <[hidden email]> wrote:
Not sure what you mean by "internal config option will be greyed out"...No option in digiKam is greyed out for me... I suspect double correction if you set the profile in both places. 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?
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?
own monitor profile is very cost intensive to use, you could try another for 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.
I guess I may try to run ColorHug again, but it sounds like I am not the only one with the problem...
That is correct.
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
On 3/22/13, Erik Felthauser <[hidden email]> wrote:
> On Fri, Mar 22, 2013 at 4:25 PM, Marcel Wiesweg > <[hidden email]>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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
> > 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. > 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 it cannot access the LUT > 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? 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. The assumed default profile for "all" windows would be sRGB if I'm not too wrong. 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? If the KDE stuff works, I would hope digikam does not need to care at all about the workspace -> monitor conversion. Marcel _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
On Sunday 24 March 2013 19:39:37 Marcel Wiesweg wrote:
> ... > 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. > The assumed default profile for "all" windows would be sRGB if I'm not too > wrong. > > 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? 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... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
In reply to this post by Elle Stone
On Sun, Mar 24, 2013 at 12:12 PM, Elle Stone <[hidden email]> wrote:
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... Any idea anyone? Perhaps I'll have to see if it appears once DK 3.1.0 comes to me via distro upgrade or backports ppa...
Well, I do not have your problem with colord, and I think for now I will not try removing it. But thanks for the cl commands for setting profile directly. I'll keep note in case I ever need.
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
On 3/24/13, Marcel Wiesweg <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: > On Sun, Mar 24, 2013 at 12:12 PM, Elle Stone <[hidden email]> > 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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
> > 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) > 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. > 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. > 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. Marcel _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
On 3/25/13, Marcel Wiesweg <[hidden email]> 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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
In reply to this post by Elle Stone
On Mon, Mar 25, 2013 at 12:38 PM, Elle Stone <[hidden email]> wrote:
Of course, I agree that many aspects of color management should be at the application level for greatest control by the user. I just wish it isn't (and don't know why it seems to be) so slow using it in digiKam. (I still need to try making a new profile w/ my colorimeter, maybe trying new settings.) Not sure if there is indeed a mis-connect going on somewhere, or maybe digiKam's CM can be changed, if not already, to leverage multiple CPU cores and/or GPU.
In any case, I think I am seeing correct colors without it for now, since my monitor profile (created with RBG option) that's set in system is correcting my monitor, and my images are (s)RGB.
I have not had access to my production machine. I'll check and report this evening.
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
In reply to this post by Elle Stone
> 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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
In reply to this post by Gus Gustafson
Looking at GIMP, I see my system monitor profile in the list, and above this there is a checkbox 'Try to use the system monitor profile', which it allows me to check / enable. Looking at krita, I do NOT find my system monitor profile in the list to choose from (there appears no way to add any not in the list), and the checkbox above "Use system monitor profile" is greyed out and unchecked... Any ideas? I wonder if this is related: https://bugs.kde.org/show_bug.cgi?id=312153 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
> On 3/26/13, Marcel Wiesweg <[hidden email]> wrote:
> >> 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. > Hmm, what you say is the first thing I've read about Desktop CM profile management that makes sense. The digiKam/Krita way of scanning for all the available profiles means I've moved most of my profiles to where digiKam *can't* find them. The list of folders where digiKam and Krita look is long, many of the folders are hidden, and many of these profiles are duplicates of profiles that are in /usr/share/color/icc. If I don't move all the profiles that I'm not currently using out of all the folders where digiKam and Krita look, then there are too many profiles to comfortably wade through to find the ones I want. As an aside, Gimp justs asks the user which folder to look in whenever you want to choose a profile for whatever purpose. It doesn't scan for "all" profiles upon startup. The Gimp way is much simpler from my own point of view, but probably not from everyone's point of view. > >> 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. On 3/26/13, Erik Felthauser <[hidden email]> wrote: > >>> 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? >> > > Looking at GIMP, I see my system monitor profile in the list, and above > this there is a checkbox 'Try to use the system monitor profile', which it > allows me to check / enable. The Gimp checkbox is there even if there isn't any installed system monitor profile. The way to tell if Gimp is really picking up the installed system monitor profile is to open an image with a distribution of familiar colors, preferably with an expanse of white somewhere. Then choose a blatantly wrong profile (try ProPhoto or WideGamut) as the Gimp/Edit/Preferences/Color Management/Monitor profile" and alternately check and uncheck the box that says "Try to use the system monitor profile". If the "Try to use the system monitor profile" box is checked AND the correct system monitor profile is really installed, then the picture will look right even if you've chosen a blatantly wrong profile for the Gimp Monitor profile. And unchecking the box will then show the wrong colors. But if there *isn't* an installed system monitor profile (or there is one and Gimp isn't finding it), then the colors will look wrong regardless of whether "Try to use the system monitor profile" is checked or unchecked. > Looking at krita, I do NOT find my system monitor profile in the list to > choose from (there appears no way to add any not in the list), and the > checkbox above "Use system monitor profile" is greyed out and unchecked... > > Any ideas? > > I wonder if this is related: https://bugs.kde.org/show_bug.cgi?id=312153 > That's a very suggestive bug report, but there are a lot of moving parts. Your digiKam package might use LCMS1 or 2, depending on how it was compiled, and Krita uses LCMS2. Compared to Krita 2.5, Krita 2.6 has new (and very nice) ICC profile conversion code. There's also "slowness if color management is enabled or not enabled" plus "using or not using colord" plus using Ubuntu (the bug report) vs using Kubuntu (your system)". I'm interested in testing this new CM Desktop stuff and none of it works on my main computer. So I will try installing Kubuntu 12.10/digiKam/colord on my laptop and see if I can replicate the "slow color management/system monitor profile not recognized" problem. Can you tell me which specific kde/colord color management packages you are using? Are any of the oyranos packages also installed? Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
I installed kubuntu 12.10 on my laptop. colord, colord-kde and
libcolord1 were installed by default. There are no oyranos packages. In the KDE system settings, under "Color - Manage color corrections of devices" there was an entry for the laptop display (this didn't happen on my main computer). Under the entry for the laptop display was a monitor profile pulled from EDID, so obviously colord can pull the EDID monitor profile. I clicked on the EDID display profile and then clicked "Install System Wide". Is this the correct procedure for installing the system monitor profile using colord under KDE system settings? Then I installed Gimp 2.8, and also krita 2.6.1 and digiKam/showFoto 3.0 from the backports ppa. None of them detect a system-installed monitor profile, and only digiKam/showFoto actually listed the colord-EDID monitor profile (which is located in the home folder in ./local/share/icc). htop shows that colord is running. But for whatever reason, it looks like the KDE colord isn't actually installing the monitor profile. As an aside, changing the monitor profile in digiKam/showFoto doesn't take effect until you restart the program. The same is true of earlier versions of Krita, but in Krita 2.6, and also in Gimp, the change is immediate. I haven't checked yet for "slow if color management is enabled". Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
I hadn't bothered installing system wide for other user accounts. > Then I installed Gimp 2.8, and also krita 2.6.1 and digiKam/showFoto For me, I know that KDE is utilizing the monitor I select, because the screen colors immediately change if I choose a different one (maybe I have to hit Apply, but I think not)... _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
Regarding the question of how colord-kde works and what it does,
Daniel Nicoletti (the colord-kde developer) looked into the problem and found that: >colord-kde was indeed not properly setting the XAtom >required by Gimp & friends, you can grab git master as the fix >is there. . . . >https://projects.kde.org/projects/playground/graphics/colord-kde/repository No doubt the fix will rapidly pfind its way to the Kubuntu/openSUSE "playground/experimental" repositories. Daniel confirmed that colord-kde doesn't do color correction, that's up to digiKam, Gimp, etc: >Indeed the color correction is a thing the app itself does > . . . we just provide which ICC the monitor is using. Also a correction/addendum to a statement that I made: If you resort to the command line, xicc can be used to set the x-atom and xcalib can be used to load the vcgt tag (I've tried xicc, it works; I've never used xcalib myself). The Argyllcms utility "dispwin" does both; it sets the X atom and loads the vcgt tag, but probably dispwin can't handle V4 profiles such as are created with colord (I couldn't get it to load the colord "edid" monitor profile). In case anyone is using Gnome desktop, colord does already properly set the system monitor profile upon startup. Elle -- http://ninedegreesbelow.com - articles on open source digital photography _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: editing with Color Management enabled is very slow?
|
|
> but probably dispwin can't > handle V4 profiles such as are created with colord (I couldn't get it > to load the colord "edid" monitor profile). V4 profiles require lcms2, doesn't it? Did you successfully compile and test digikam with lcms2? If it works, I would like to make it the default if available, I guess it's better and faster. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Is there a way to configure DigiKam to remove the JPEG thumbnail from
the EXIF metadata when it gets rewritten to the file? I am dealing with a poorly implemented third party streaming reader client (DirecTV settop) that wants to display the thumbnail rather than the full image. _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |