Thumbnails not color-managed + severely distorted shadow tonality for thumbs, previews

Elle Stone ellestone at
Fri Nov 17 12:51:16 GMT 2017

On 11/16/2017 03:27 PM, Marcel Wiesweg wrote:
> Regarding the optimization flag, I find Marti Maria's definitive answer to
> this issue raised by you here
> asserting that we should not change the flag per default for very convincing
> performance reasons, but a specialized option for 16bit -> 16bit conversions
> appears acceptable

Are you suggesting some sort of internal switch - not accessible by the 
user - that detects the color space and/or bit depth and then switches 
between using and not using the LCMS optimizations, without the user 
having any say in the matter?

If so, then I would ask you to consider instead putting in a user 
preference to allow the *user* to enable or disable the LCMS 
optimizations per their own choice. Krita has a very nice example of 
such an option.

Regarding the "performance reasons" that you mention, this is something 
*users* should experiment with and make their own informed decisions 
instead of relying on generalities that might not even apply to their 
own particular use cases.

Currently I'm using a relatively fast machine with a lot of RAM. But my 
last computer was ten years old before it finally stopped working around 
three years ago. That machine only had a one core processor, and by 
today's standards it was a slow processor, though the machine did have 
8GB RAM. That's my "benchmark" machine.

Linear gamma RGB profiles are matrix profiles. My monitor profile is a 
matrix profile made using ArgyllCMS. I'm fairly sure that the majority 
of users have matrix monitor profiles.

For matrix-to-matrix ICC profile conversions, even on my old machine I 
never noticed any slow-down at all, regardless of whether the LCMS 
optimizations were being used or not being used.

At least on Linux (I am not willing to make statements about what 
happens on Windows or Mac), I'm fairly sure the only time disabling the 
LCMS optimizations is likely to slow down performance to the point of 
being noticeable by the user, is when the source and/or destination 
profile is a LUT profile, such as a printer profile. And even then, "how 
slow is too slow" is surely machine-dependent and also a matter of user 

If a user does normally use a LUT monitor profile, well, that person 
would probably want to make some experiments and decide whether or not 
to enable or disable the LCMS optimizations.

Soft proofing using LCMS does slow down the display of the image, with 
or without the optimizations, and I'm sure this has to do with the 
double profile conversion going on, as well as with the fact that 
printer profiles are LUT profiles.

Personally I don't use LCMS for soft proofing because the LCMS 
soft-proofing gamut checks fail rather badly when the source profile is 
a linear gamma matrix profile. So I use PhotoFlow for soft-proofing. 
PhotoFlow has internal soft proofing code that very nicely works around 
the current limitations in LCMS soft proofing. AFAIK this code is still 
only in the linear gamma branch of PhotoFlow, but will be merged with 
the main branch at least by the 0.30 release 


More information about the Digikam-users mailing list