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

[Elle Stone-2]

I made some screenshots to show two separate problems in digiKam when
displaying thumbnails and previews:

https://ninedegreesbelow.com/files/digikam-zoom-and-color-management-problem.jpg

This is for digiKam 5.7.0 on Gentoo Linux.

First problem:

DigiKam is not color-managing the thumbnails, even though in
Settings/Configure/Color Management I did select to "Use color managed
view for previews and thumbnails" as well as "Use color managed view in
editor".

Is anyone else seeing thumbnails that aren't color-managed (not a
relevant question unless your monitor profile isn't sRGB).

Second problem:

For both thumbnails and previews, and for both high bit depth pngs and
high bit depth tiffs, for images in linear gamma RGB color spaces, the
shadow tonality is severel distorted. The smaller the zoom, the greater
the distortion, but even at 50% and 100% zoom, the shadow tonality is
distorted. This is true for both pngs and tiffs.

The corresponding images when displayed in GIMP do not show distorted
shadow tonality even when the zoom is as small as 9%.

Colors do not blend correctly when edited in non-linear RGB color
spaces. As more and more image editors allow for high bit depth image
editing, more people are editing in linear gamma RGB color spaces.

Almost all of my own processed image files are in linear gamma color
spaces. This means digiKam is fairly much useless for allowing me to
examine and rate my processed image files, as image tonality is a key
part of judging the differences between images.

As a possibly relevant additional observation, I opened a test image in
a linear gamma RGB working space from digiKam, using ShowFoto. ShowFoto
also shows the same distortion in the shadow tonality, though not as
extreme as in the digiKam thumbnails.

Is digiKam perhaps using LCMS "low quality" conversions for conversions
from the image color space to the user's monitor profile? In Krita there
is an option under "Settings/Configure Krita/Color Management" to "Allow
Little CMS optimizations" with the warning to "uncheck when using linear
light RGB or XYZ". And indeed having this option in Krita checked
produces similar shadow tonality distortion as digiKam/showFoto is
showing, though not as extreme for zooming eg to 8% or 10%.

Is is possible that the zoom algorithm in digiKam is not properly set up
to handle linear gamma images? For example PhotoShop CS2 (version
current back around 2004) performed very badly with linear gamma image
shadow tonality until the zoom factor was at least 67%, at which point
everything was fine.

Best,
Elle

[Maik Qualmann]

The thumbnails are color managed. But the color depth of the thumbnails is
only 8 bit, that's probably the cause. The image preview can be activated in
the settings to display image with 16 bit, but the thumbnails are not.

Maik

Am Mittwoch, 15. November 2017, 16:16:35 CET schrieb Elle Stone:

> I made some screenshots to show two separate problems in digiKam when
> displaying thumbnails and previews:
>
> https://ninedegreesbelow.com/files/digikam-zoom-and-color-management-problem
> .jpg
>
> This is for digiKam 5.7.0 on Gentoo Linux.
>
> First problem:
>
> DigiKam is not color-managing the thumbnails, even though in
> Settings/Configure/Color Management I did select to "Use color managed
> view for previews and thumbnails" as well as "Use color managed view in
> editor".
>
> Is anyone else seeing thumbnails that aren't color-managed (not a
> relevant question unless your monitor profile isn't sRGB).
>
> Second problem:
>
> For both thumbnails and previews, and for both high bit depth pngs and
> high bit depth tiffs, for images in linear gamma RGB color spaces, the
> shadow tonality is severel distorted. The smaller the zoom, the greater
> the distortion, but even at 50% and 100% zoom, the shadow tonality is
> distorted. This is true for both pngs and tiffs.
>
> The corresponding images when displayed in GIMP do not show distorted
> shadow tonality even when the zoom is as small as 9%.
>
> Colors do not blend correctly when edited in non-linear RGB color
> spaces. As more and more image editors allow for high bit depth image
> editing, more people are editing in linear gamma RGB color spaces.
>
> Almost all of my own processed image files are in linear gamma color
> spaces. This means digiKam is fairly much useless for allowing me to
> examine and rate my processed image files, as image tonality is a key
> part of judging the differences between images.
>
> As a possibly relevant additional observation, I opened a test image in
> a linear gamma RGB working space from digiKam, using ShowFoto. ShowFoto
> also shows the same distortion in the shadow tonality, though not as
> extreme as in the digiKam thumbnails.
>
> Is digiKam perhaps using LCMS "low quality" conversions for conversions
> from the image color space to the user's monitor profile? In Krita there
> is an option under "Settings/Configure Krita/Color Management" to "Allow
> Little CMS optimizations" with the warning to "uncheck when using linear
> light RGB or XYZ". And indeed having this option in Krita checked
> produces similar shadow tonality distortion as digiKam/showFoto is
> showing, though not as extreme for zooming eg to 8% or 10%.
>
> Is is possible that the zoom algorithm in digiKam is not properly set up
> to handle linear gamma images? For example PhotoShop CS2 (version
> current back around 2004) performed very badly with linear gamma image
> shadow tonality until the zoom factor was at least 67%, at which point
> everything was fine.
>
> Best,
> Elle

[Elle Stone-2]

On 11/15/2017 02:08 PM, Maik Qualmann wrote:
> The thumbnails are color managed. But the color depth of the thumbnails is
> only 8 bit, that's probably the cause.

Hmm, no, on my monitor, if color management isn't being used, the image
has a slight magenta color cast. All the digiKam thumbnails have a
slight magenta color cast that for example changes the color of blue
skies to make them slightly more purple, and also gives grayscale images
a slight magenta color cast. This is completely separate from and
independent of the crushed/posterized shadows in the thumbnails. The
previews don't have the magenta color cast, but the thumbnails do.

But yes, the fact that the thumbnails are 8-bits accounts for the
crushed/posterized shadows for the thumbnails, but hopefully not also
for the previews. Are the previews 8-bits also? Because the tonality in
the previews doesn't have the type of posterized shadows I'd expect from
a linear gamma 8-bit image. Rather the shadows are crushed with fairly
abrupt transitions but not completely posterized tonal shifts.

Now that you've explained why the shadows are posterized for the
thumbnails, I should have realized that was the issue - I suspect
thumbnails are only 8-bits fairly universally. But magenta color cast
for the thumbnails is another issue altogether.

If you are saying the thumbnails *should* be color-managed (and the
settings would indicate that yes, they should be), how do I troubleshoot
why they are showing the typical (for my monitor, no doubt not for all
monitors) magenta color cast that results when I view images in
non-color-managed applications?

[AndriusWild]

Try to play with settings in the following tabs:

Settings - Configure digiKam - Image - RAW Behavior
Settings - Configure digiKam - Views - Preview

On Wednesday, November 15, 2017 1:08:59 PM MST, Elle Stone wrote:

> On 11/15/2017 02:08 PM, Maik Qualmann wrote:
>> The thumbnails are color managed. But the color depth of the thumbnails is
>> only 8 bit, that's probably the cause.
>
> Hmm, no, on my monitor, if color management isn't being used,
> the image has a slight magenta color cast. All the digiKam
> thumbnails have a slight magenta color cast that for example
> changes the color of blue skies to make them slightly more
> purple, and also gives grayscale images a slight magenta color
> cast. This is completely separate from and independent of the
> crushed/posterized shadows in the thumbnails. The previews don't
> have the magenta color cast, but the thumbnails do.
>
> But yes, the fact that the thumbnails are 8-bits accounts for
> the crushed/posterized shadows for the thumbnails, but hopefully
> not also for the previews. Are the previews 8-bits also? Because
> the tonality in the previews doesn't have the type of posterized
> shadows I'd expect from a linear gamma 8-bit image. Rather the
> shadows are crushed with fairly abrupt transitions but not
> completely posterized tonal shifts.
>
> Now that you've explained why the shadows are posterized for
> the thumbnails, I should have realized that was the issue - I
> suspect thumbnails are only 8-bits fairly universally. But
> magenta color cast for the thumbnails is another issue
> altogether.
>
> If you are saying the thumbnails *should* be color-managed (and
> the settings would indicate that yes, they should be), how do I
> troubleshoot why they are showing the typical (for my monitor,
> no doubt not for all monitors) magenta color cast that results
> when I view images in non-color-managed applications?
>
>
>
>

--
Thanks,
Andrey

[Elle Stone-2]

On 11/15/2017 03:16 PM, Andrey Goreev wrote:
> Try to play with settings in the following tabs:
>
> Settings - Configure digiKam - Image - RAW Behavior
> Settings - Configure digiKam - Views - Preview

I set Views/Preview to "Preview shows the full image", and Views/Preview
Raw Images to "Raw data in half size". Though right now I'm not actually
looking at raw files, but rather at tiffs and pngs.

Under Image Editor - RAW Behavior, that's set to "Always open the Raw
Import Tool to customize settings", but again right now I'm not looking
at raw files.

Right now the issue is viewing linear gamma tiffs and pngs:

The previews are color-managed but have crushed shadow tonality, and the
smaller the displayed image, the worse the shadow tonality.

The thumbnails do not look color-managed - instead have a slight magenta
color cast. The posterized shadows are explained by the fact that the
thumbnails are 8-bit images.

> On Wednesday, November 15, 2017 1:08:59 PM MST, Elle Stone wrote:
>> On 11/15/2017 02:08 PM, Maik Qualmann wrote:
>>> The thumbnails are color managed. But the color depth of the
>>> thumbnails is
>>> only 8 bit, that's probably the cause.
>>
>> Hmm, no, on my monitor, if color management isn't being used, the
>> image has a slight magenta color cast. All the digiKam thumbnails have
>> a slight magenta color cast that for example changes the color of blue
>> skies to make them slightly more purple, and also gives grayscale
>> images a slight magenta color cast. This is completely separate from
>> and independent of the crushed/posterized shadows in the thumbnails.
>> The previews don't have the magenta color cast, but the thumbnails do.
>>
>> But yes, the fact that the thumbnails are 8-bits accounts for the
>> crushed/posterized shadows for the thumbnails, but hopefully not also
>> for the previews. Are the previews 8-bits also? Because the tonality
>> in the previews doesn't have the type of posterized shadows I'd expect
>> from a linear gamma 8-bit image. Rather the shadows are crushed with
>> fairly abrupt transitions but not completely posterized tonal shifts.
>>
>> Now that you've explained why the shadows are posterized for the
>> thumbnails, I should have realized that was the issue - I suspect
>> thumbnails are only 8-bits fairly universally. But magenta color cast
>> for the thumbnails is another issue altogether.
>>
>> If you are saying the thumbnails *should* be color-managed (and the
>> settings would indicate that yes, they should be), how do I
>> troubleshoot why they are showing the typical (for my monitor, no
>> doubt not for all monitors) magenta color cast that results when I
>> view images in non-color-managed applications?
>>
>>
>>
>>
>

--
http://ninedegreesbelow.com
Color management and free/libre photography

[Maik Qualmann]

For the preview to have clean transitions, the option "Preview image is
converted to 8 bits for a faster viewing" must be disabled.
Can you provide a image to test the color management?

Maik

Am Mittwoch, 15. November 2017, 21:36:38 CET schrieb Elle Stone:

> On 11/15/2017 03:16 PM, Andrey Goreev wrote:
> > Try to play with settings in the following tabs:
> >
> > Settings - Configure digiKam - Image - RAW Behavior
> > Settings - Configure digiKam - Views - Preview
>
> I set Views/Preview to "Preview shows the full image", and Views/Preview
> Raw Images to "Raw data in half size". Though right now I'm not actually
> looking at raw files, but rather at tiffs and pngs.
>
> Under Image Editor - RAW Behavior, that's set to "Always open the Raw
> Import Tool to customize settings", but again right now I'm not looking
> at raw files.
>
> Right now the issue is viewing linear gamma tiffs and pngs:
>
> The previews are color-managed but have crushed shadow tonality, and the
> smaller the displayed image, the worse the shadow tonality.
>
> The thumbnails do not look color-managed - instead have a slight magenta
> color cast. The posterized shadows are explained by the fact that the
> thumbnails are 8-bit images.
>
> > On Wednesday, November 15, 2017 1:08:59 PM MST, Elle Stone wrote:
> >> On 11/15/2017 02:08 PM, Maik Qualmann wrote:
> >>> The thumbnails are color managed. But the color depth of the
> >>> thumbnails is
> >>> only 8 bit, that's probably the cause.
> >>
> >> Hmm, no, on my monitor, if color management isn't being used, the
> >> image has a slight magenta color cast. All the digiKam thumbnails have
> >> a slight magenta color cast that for example changes the color of blue
> >> skies to make them slightly more purple, and also gives grayscale
> >> images a slight magenta color cast. This is completely separate from
> >> and independent of the crushed/posterized shadows in the thumbnails.
> >> The previews don't have the magenta color cast, but the thumbnails do.
> >>
> >> But yes, the fact that the thumbnails are 8-bits accounts for the
> >> crushed/posterized shadows for the thumbnails, but hopefully not also
> >> for the previews. Are the previews 8-bits also? Because the tonality
> >> in the previews doesn't have the type of posterized shadows I'd expect
> >> from a linear gamma 8-bit image. Rather the shadows are crushed with
> >> fairly abrupt transitions but not completely posterized tonal shifts.
> >>
> >> Now that you've explained why the shadows are posterized for the
> >> thumbnails, I should have realized that was the issue - I suspect
> >> thumbnails are only 8-bits fairly universally. But magenta color cast
> >> for the thumbnails is another issue altogether.
> >>
> >> If you are saying the thumbnails *should* be color-managed (and the
> >> settings would indicate that yes, they should be), how do I
> >> troubleshoot why they are showing the typical (for my monitor, no
> >> doubt not for all monitors) magenta color cast that results when I
> >> view images in non-color-managed applications?

[Elle Stone-2]

On 11/15/2017 03:48 PM, Maik Qualmann wrote:
> For the preview to have clean transitions, the option "Preview image is
> converted to 8 bits for a faster viewing" must be disabled.

That is already unchecked. Unchecking is the same as disabling, yes?

 > Can you provide a image to test the color management?

Yes. I probably won't be able to provide the image until tomorrow morning.

In the meantime, I downloaded the digiKam source code from
https://anongit.kde.org/digikam-software-compilation.git

and modified core/libs/dimg/filters/icc/icctransform.cpp line 58 from

transformFlags = 0;

to

transformFlags = cmsFLAGS_NOOPTIMIZE;

I'm following the compile instructions here:
https://www.digikam.org/download/git/

Should those instructions say to uninstall digiKam from whatever
repository it might already be installed from, such as Gentoo Portage in
my case? Anyway, I just uninstalled digiKam from Gentoo Portage and
digiKam from git is building.

Hmm, sadly the build errored out at 95%, with this message:

[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/thumbbar/showfototooltipfiller.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/thumbbar/showfotocategorizedview.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/thumbbar/showfotothumbnailbar.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/main/showfotoinfoiface.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/main/showfotosettings.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/main/main.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/main/showfoto.cpp.o
[ 95%] Building CXX object
core/showfoto/CMakeFiles/showfoto.dir/showfoto_autogen/moc_compilation.cpp.o
[ 95%] Linking CXX executable showfoto
[ 95%] Built target showfoto
make: *** [Makefile:141: all] Error 2

I never use showfoto - can digiKam be build without showfoto? If yes,
what do I modify to make this happen? If no, any idea why the build
stopped at building showfoto? I'd like to build digiKam with the right
lcms flags to disable all partial and full lcms "optimizations".

Best,
Elle

[Elle Stone-2]

Hmm, forgot to add, here are the options in bootstrap.sh that I used for
building digiKam. I tried to disable as much as possible - I don't
actually use any of the stuff I disabled:


$CMAKE_BINARY -G "$MAKEFILES_TYPE" . \
       -DCMAKE_BUILD_TYPE=debug \
       -DCMAKE_INSTALL_PREFIX=$DIGIKAM_INSTALL_PREFIX/ \
       -DKDE_INSTALL_QTPLUGINDIR=$QT_PLUGIN_INSTALL_DIR/ \
       $ADDITIONAL_CMAKE_FLAGS \
       -DBUILD_TESTING=ON \
       -DDIGIKAMSC_CHECKOUT_PO=OFF \
       -DDIGIKAMSC_CHECKOUT_DOC=OFF \
       -DDIGIKAMSC_COMPILE_PO=OFF \
       -DDIGIKAMSC_COMPILE_DOC=OFF \
       -DDIGIKAMSC_COMPILE_DIGIKAM=ON \
       -DDIGIKAMSC_COMPILE_KIPIPLUGINS=OFF \
       -DDIGIKAMSC_COMPILE_LIBKIPI=OFF \
       -DDIGIKAMSC_COMPILE_LIBKSANE=OFF \
       -DDIGIKAMSC_COMPILE_LIBMEDIAWIKI=OFF \
       -DDIGIKAMSC_COMPILE_LIBKVKONTAKTE=OFF \
       -DENABLE_OPENCV3=OFF \
       -DENABLE_KFILEMETADATASUPPORT=OFF \
       -DENABLE_AKONADICONTACTSUPPORT=OFF \
       -DENABLE_MYSQLSUPPORT=OFF \
       -DENABLE_INTERNALMYSQL=OFF \
       -DENABLE_MEDIAPLAYER=OFF \
       -DENABLE_DBUS=ON \
       -DENABLE_APPSTYLES=ON \
       -Wno-dev \
       $SOURCEDIR && echo "$MESSAGE"

if [ -d ./extra/libkvkontakte/src ]; then
     ln -sf src ./extra/libkvkontakte/Vkontakte
fi

if [ -d ./extra/libmediawiki/src ]; then
     ln -sf src ./extra/libmediawiki/MediaWiki
fi

Do I need to change anything for the last two sets of "if . . . . fi" ?

[Elle Stone-2]

On 11/15/2017 04:38 PM, Elle Stone wrote:
> [ 95%] Built target showfoto
> make: *** [Makefile:141: all] Error 2
>
> I never use showfoto - can digiKam be build without showfoto? If yes,
> what do I modify to make this happen? If no, any idea why the build
> stopped at building showfoto? I'd like to build digiKam with the right
> lcms flags to disable all partial and full lcms "optimizations".

Hmm, sorry, it looks like showfoto did build. I'm rerunning the build
this time using -j1.

[Elle Stone-2]

On 11/15/2017 05:22 PM, Elle Stone wrote:
>
> Hmm, sorry, it looks like showfoto did build. I'm rerunning the build
> this time using -j1.

Here's the thing first problem:

/usr/include/boost/graph/graph_concepts.hpp:114:5:   required from
'static void
boost::concepts::requirement<boost::concepts::failed************
Model::************>::failed() [with Model =

Hopefully someone will know what I should do next to get digiKam to build.

Best,
Elle

Here's the full terminal output for the part that actually didn't build:

Scanning dependencies of target dimghistorygraphtest
[ 88%] Building CXX object
core/tests/dimg/CMakeFiles/dimghistorygraphtest.dir/dimgabstracthistorytest.cpp.o
[ 88%] Building CXX object
core/tests/dimg/CMakeFiles/dimghistorygraphtest.dir/dimghistorygraphtest.cpp.o
In file included from /usr/include/boost/graph/depth_first_search.hpp:18:0,
                  from /usr/include/boost/graph/strong_components.hpp:17,
                  from /usr/include/boost/graph/transitive_closure.hpp:17,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:51,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraphdata.h:35,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:47:
/usr/include/boost/graph/graph_concepts.hpp: In instantiation of
'boost::concepts::BidirectionalGraph<G>::~BidirectionalGraph() [with G =
boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>]':
/usr/include/boost/graph/graph_concepts.hpp:114:5:   required from
'static void
boost::concepts::requirement<boost::concepts::failed************
Model::************>::failed() [with Model =
boost::concepts::BidirectionalGraphConcept<boost::reverse_graph<boost::adjacency_list<boost::vecS,
boost::vecS, boost::bidirectionalS,
boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&> >]'
/usr/include/boost/graph/dominator_tree.hpp:250:5:   required from 'void
boost::lengauer_tarjan_dominator_tree(const Graph&, const typename
boost::graph_traits<Graph>::vertex_descriptor&, const IndexMap&,
TimeMap, PredMap, VertexVector&, DomTreePredMap) [with Graph =
boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>; IndexMap =
boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_index_t,
int, boost::property<vertex_properties_t,
Digikam::HistoryVertexProperties, boost::no_property> >, long unsigned
int>; TimeMap =
boost::iterator_property_map<__gnu_cxx::__normal_iterator<long unsigned
int*, std::vector<long unsigned int> >,
boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_index_t,
int, boost::property<vertex_properties_t,
Digikam::HistoryVertexProperties, boost::no_property> >, long unsigned
int>, long unsigned int, long unsigned int&>; PredMap =
boost::iterator_property_map<__gnu_cxx::__normal_iterator<long unsigned
int*, std::vector<long unsigned int> >,
boost::vec_adj_list_vertex_id_map<boost::property<boost::vertex_index_t,
int, boost::property<vertex_properties_t,
Digikam::HistoryVertexProperties, boost::no_property> >, long unsigned
int>, long unsigned int, long unsigned int&>; VertexVector =
std::vector<long unsigned int>; DomTreePredMap =
boost::associative_property_map<Digikam::QMapForAdaptors<Digikam::Graph<Digikam::HistoryVertexProperties,
Digikam::HistoryEdgeProperties>::Vertex,
Digikam::Graph<Digikam::HistoryVertexProperties,
Digikam::HistoryEdgeProperties>::Vertex> >; typename
boost::graph_traits<Graph>::vertex_descriptor = long unsigned int]'
/usr/include/boost/graph/dominator_tree.hpp:369:35:   required from
'void boost::lengauer_tarjan_dominator_tree(const Graph&, const typename
boost::graph_traits<Graph>::vertex_descriptor&, DomTreePredMap) [with
Graph = boost::reverse_graph<boost::adjacency_list<boost::vecS,
boost::vecS, boost::bidirectionalS,
boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>; DomTreePredMap =
boost::associative_property_map<Digikam::QMapForAdaptors<Digikam::Graph<Digikam::HistoryVertexProperties,
Digikam::HistoryEdgeProperties>::Vertex,
Digikam::Graph<Digikam::HistoryVertexProperties,
Digikam::HistoryEdgeProperties>::Vertex> >; typename
boost::graph_traits<Graph>::vertex_descriptor = long unsigned int]'
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:1290:58:
   required from 'void Digikam::Graph<VertexProperties,
EdgeProperties>::DominatorTree::enter(const GraphType&, const
Digikam::Graph<VertexProperties, EdgeProperties>::Vertex&,
Digikam::MeaningOfDirection) [with GraphType =
boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS,
boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>; VertexProperties = Digikam::HistoryVertexProperties;
EdgeProperties = Digikam::HistoryEdgeProperties]'
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:897:9:
   required from 'QList<Digikam::Graph<VertexProperties,
EdgeProperties>::Vertex> Digikam::Graph<VertexProperties,
EdgeProperties>::verticesDominatedBy(const
Digikam::Graph<VertexProperties, EdgeProperties>::Vertex&, const
Digikam::Graph<VertexProperties, EdgeProperties>::Vertex&,
QList<Digikam::Graph<VertexProperties, EdgeProperties>::Vertex>) const
[with VertexProperties = Digikam::HistoryVertexProperties;
EdgeProperties = Digikam::HistoryEdgeProperties]'
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:868:35:
   required from 'QList<Digikam::Graph<VertexProperties,
EdgeProperties>::Vertex> Digikam::Graph<VertexProperties,
EdgeProperties>::verticesDominatedBy(const
Digikam::Graph<VertexProperties, EdgeProperties>::Vertex&, const
Digikam::Graph<VertexProperties, EdgeProperties>::Vertex&,
Digikam::Graph<VertexProperties, EdgeProperties>::ReturnOrder) const
[with VertexProperties = Digikam::HistoryVertexProperties;
EdgeProperties = Digikam::HistoryEdgeProperties]'
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:446:73:
   required from here
/usr/include/boost/graph/graph_concepts.hpp:131:19: error: no matching
function for call to
'degree(boost::graph_traits<boost::reverse_graph<boost::adjacency_list<boost::vecS,
boost::vecS, boost::bidirectionalS,
boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&> >::vertex_descriptor&,
boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>&)'
          n = degree(v, g);
                    ^
In file included from /usr/include/boost/graph/adjacency_list.hpp:246:0,
                  from /usr/include/boost/graph/transitive_closure.hpp:21,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:51,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraphdata.h:35,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:47:
/usr/include/boost/graph/detail/adjacency_list.hpp:1514:5: note:
candidate: template<class Config> typename Config::degree_size_type
boost::degree(typename Config::vertex_descriptor, const
boost::bidirectional_graph_helper_with_property<Config>&)
      degree(typename Config::vertex_descriptor u,
      ^
/usr/include/boost/graph/detail/adjacency_list.hpp:1514:5: note:
template argument deduction/substitution failed:
In file included from /usr/include/boost/graph/depth_first_search.hpp:18:0,
                  from /usr/include/boost/graph/strong_components.hpp:17,
                  from /usr/include/boost/graph/transitive_closure.hpp:17,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:51,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraphdata.h:35,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:47:
/usr/include/boost/graph/graph_concepts.hpp:131:19: note:
'boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>' is not derived from 'const
boost::bidirectional_graph_helper_with_property<Config>'
          n = degree(v, g);
                    ^
In file included from /usr/include/boost/graph/adjacency_list.hpp:246:0,
                  from /usr/include/boost/graph/transitive_closure.hpp:21,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:51,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraphdata.h:35,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:47:
/usr/include/boost/graph/detail/adjacency_list.hpp:1087:5: note:
candidate: template<class Config> typename Config::degree_size_type
boost::degree(typename Config::vertex_descriptor, const
boost::undirected_graph_helper<C>&)
      degree(typename Config::vertex_descriptor u,
      ^
/usr/include/boost/graph/detail/adjacency_list.hpp:1087:5: note:
template argument deduction/substitution failed:
In file included from /usr/include/boost/graph/depth_first_search.hpp:18:0,
                  from /usr/include/boost/graph/strong_components.hpp:17,
                  from /usr/include/boost/graph/transitive_closure.hpp:17,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraph_boost.h:51,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/libs/database/imagehistory/imagehistorygraphdata.h:35,
                  from
/hdd/data1/code-build/digikam-software-compilation/core/tests/dimg/dimghistorygraphtest.cpp:47:
/usr/include/boost/graph/graph_concepts.hpp:131:19: note:
'boost::reverse_graph<boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>, const boost::adjacency_list<boost::vecS, boost::vecS,
boost::bidirectionalS, boost::property<boost::vertex_index_t, int,
boost::property<vertex_properties_t, Digikam::HistoryVertexProperties,
boost::no_property> >, boost::property<edge_properties_t,
Digikam::HistoryEdgeProperties, boost::no_property>, boost::no_property,
boost::listS>&>' is not derived from 'const
boost::undirected_graph_helper<C>'
          n = degree(v, g);
                    ^
make[2]: ***
[core/tests/dimg/CMakeFiles/dimghistorygraphtest.dir/build.make:87:
core/tests/dimg/CMakeFiles/dimghistorygraphtest.dir/dimghistorygraphtest.cpp.o]
Error 1
make[1]: *** [CMakeFiles/Makefile2:9676:
core/tests/dimg/CMakeFiles/dimghistorygraphtest.dir/all] Error 2
make: *** [Makefile:141: all] Error 2

[Elle Stone-2]

On 11/15/2017 05:51 PM, Elle Stone wrote:
>
> /usr/include/boost/graph/graph_concepts.hpp:114:5:   required from
> 'static void
> boost::concepts::requirement<boost::concepts::failed************
> Model::************>::failed() [with Model =
>
> Hopefully someone will know what I should do next to get digiKam to build.

Here are the boost libraries I have installed from Gentoo Portage:

dev-libs/boost-1.62.0-r1:0/1.62.0
dev-util/boost-build-1.62.0-r1:0

 From these threads, it looks like there has been a fairly recent (well,
a year ago) issue with boost libraries in digiKam:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834175
http://digikam.1695700.n4.nabble.com/Build-error-with-boost-1-62-patch-td4690576.html

Anyone have any idea what's the next step in building digiKam from
source? How do I get past the boost errors?

Do I need to install a more recent version of boost? 1.63 and 1.65 are
both available from Gentoo Portage.

[Andrew Goodbody]

On 15/11/17 23:03, Elle Stone wrote:

> On 11/15/2017 05:51 PM, Elle Stone wrote:
>>
>> /usr/include/boost/graph/graph_concepts.hpp:114:5:   required from
>> 'static void
>> boost::concepts::requirement<boost::concepts::failed************
>> Model::************>::failed() [with Model =
>>
>> Hopefully someone will know what I should do next to get digiKam to
>> build.
>
> Here are the boost libraries I have installed from Gentoo Portage:
>
> dev-libs/boost-1.62.0-r1:0/1.62.0
> dev-util/boost-build-1.62.0-r1:0
>
>  From these threads, it looks like there has been a fairly recent (well,
> a year ago) issue with boost libraries in digiKam:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=834175
> http://digikam.1695700.n4.nabble.com/Build-error-with-boost-1-62-patch-td4690576.html 
>
>
> Anyone have any idea what's the next step in building digiKam from
> source? How do I get past the boost errors?
>
> Do I need to install a more recent version of boost? 1.63 and 1.65 are
> both available from Gentoo Portage.

I have boost 1.62 installed and just built the latest source with no issues.

I would restore your bootstrap to the defaults (the opencv setting needs
to match the version installed on your system, V2 or V3) so that you are
using the most (or indeed only?) tested combination and try a clean build.

Andrew

[Elle Stone-2]

On 11/15/2017 07:13 PM, Andrew Goodbody wrote:
>
> I have boost 1.62 installed and just built the latest source with no
> issues.
>
> I would restore your bootstrap to the defaults (the opencv setting needs
> to match the version installed on your system, V2 or V3) so that you are
> using the most (or indeed only?) tested combination and try a clean build.

Well, I can't do that. The configuration wouldn't complete, failed on
one of the build options that could be set to "OFF", so I changed that
one and all the other options that were listed from ON to OFF. If these
"OFF" options don't work, what is the point of providing them?

The version of opencv on my system is V2.

Elle

[Elle Stone-2]

On 11/15/2017 06:03 PM, Elle Stone wrote:
>
> Do I need to install a more recent version of boost? 1.63 and 1.65 are
> both available from Gentoo Portage.

Installing boost 1.63 allowed digiKam from git to compile without any
problems.

On 11/15/2017 04:38 PM, Elle Stone wrote:

> I downloaded the digiKam source code from
> https://anongit.kde.org/digikam-software-compilation.git
>
> and modified core/libs/dimg/filters/icc/icctransform.cpp line 58 from
>
> transformFlags = 0;
>
> to
>
> transformFlags = cmsFLAGS_NOOPTIMIZE;

Yes, changing the transformFlags to always include cmsFLAGS_NOOPTIMIZE
makes the shadow tonality for previews match GIMP-2.9's shadow tonality.

For actual use in digiKam, if the decision is made to allow not using
the optimizations - which really does seem necessary for proper display
of linear gamma images - there would probably also need to be a user
option in the digiKam color management settings - perhaps similar to
what Krita has - to use or not use the optimizations. Apparently not
using the optimizations can lead to slower display and conversion of
images, depending on the type of conversion and the type of monitor
profile and etc.

Also in the version of digiKam that I installed from git, the thumbnails
are color-managed. Of course the shadows are still posterized from being
linear gamma 8-bit thumbnails, but that is to be expected.

There is one more variable (setting or not setting the system monitor
profile) that I want to double-check, that might affect the display of
the thumbnails: When using the version of digiKam from Gentoo Portage, I
had set the system monitor profile upon starting X. But this morning,
testing my modified "git" version of digiKam, I also unset the system
monitor profile and set the digiKam monitor profile from disk, so that
the digiKam color management settings and GIMP/Krita color management
settings would match as closely as possible. I can't imagine how this
would affect display of thumbnails but not the previews, but maybe it
somehow does.

Unfortunately (a small and basically irrelevant aside), my compiled
version of digiKam doesn't show an icon in the task bar, so when
minimized to the task bar tray it almost seems like digiKam isn't
running any more, but it really is.


On 11/15/2017 03:48 PM, Maik Qualmann wrote:
> Can you provide a image to test the color management?

I made a 16-bit integer png test image. At 1200x1200, the file is
2.8MiB, resized to 1024x1024, it's 1.9MiB - I can resize the image to be
smaller, if that would be better. Let me know what size you want and
I'll upload the image.

Best,
Elle

[Elle Stone-2]

On 11/16/2017 08:00 AM, Elle Stone wrote:

> Also in the version of digiKam that I installed from git, the thumbnails
> are color-managed. Of course the shadows are still posterized from being
> linear gamma 8-bit thumbnails, but that is to be expected.
>
> There is one more variable (setting or not setting the system monitor
> profile) that I want to double-check, that might affect the display of
> the thumbnails: When using the version of digiKam from Gentoo Portage, I
> had set the system monitor profile upon starting X. But this morning,
> testing my modified "git" version of digiKam, I also unset the system
> monitor profile and set the digiKam monitor profile from disk, so that
> the digiKam color management settings and GIMP/Krita color management
> settings would match as closely as possible. I can't imagine how this
> would affect display of thumbnails but not the previews, but maybe it
> somehow does.

Hmm, experimenting, I can deliberately produce not-color-managed
thumbnails by setting/unsetting the system monitor profile while digiKam
is running, and then changing the digiKam color management monitor
profile setting. Restarting digiKam makes the thumbnails be color-managed.

So I'm guessing that there was something in how my system monitor
profile was being set when I was running digikam 5.7.0 from Gentoo
Portage, that somehow resulted in the thumbnails not being
color-managed. So my apologies! for saying the thumbnails aren't
color-managed. They weren't on my system, but I think this was strictly
a function of when/how the system monitor profile was being set.

As already noted, the problem with the preview image shadow tonality is
completely eliminated by changing
"core/libs/dimg/filters/icc/icctransform.cpp" line 58 from
"transformFlags = 0;" to "transformFlags = cmsFLAGS_NOOPTIMIZE;" before
compiling and installing digiKam.

Best,
Elle

[Marcel Wiesweg]

If my memory is not too wrong, thumbnails are stored in sRGB on disk, and are
color managed on load, and then cached. This order is mandatory for
performance reasons. Given that profile loading via X atoms is like a
technology from the 1980s or 90s and there is no change notification, things
like you observe can happen.
(multi monitor setups with different profiles another issue)

Regarding the optimization flag, I find Marti Maria's definitive answer to
this issue raised by you here

https://sourceforge.net/p/lcms/mailman/message/29602585/

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

Marcel

> On 11/16/2017 08:00 AM, Elle Stone wrote:
> > Also in the version of digiKam that I installed from git, the thumbnails
> > are color-managed. Of course the shadows are still posterized from being
> > linear gamma 8-bit thumbnails, but that is to be expected.
> >
> > There is one more variable (setting or not setting the system monitor
> > profile) that I want to double-check, that might affect the display of
> > the thumbnails: When using the version of digiKam from Gentoo Portage, I
> > had set the system monitor profile upon starting X. But this morning,
> > testing my modified "git" version of digiKam, I also unset the system
> > monitor profile and set the digiKam monitor profile from disk, so that
> > the digiKam color management settings and GIMP/Krita color management
> > settings would match as closely as possible. I can't imagine how this
> > would affect display of thumbnails but not the previews, but maybe it
> > somehow does.
>
> Hmm, experimenting, I can deliberately produce not-color-managed
> thumbnails by setting/unsetting the system monitor profile while digiKam
> is running, and then changing the digiKam color management monitor
> profile setting. Restarting digiKam makes the thumbnails be color-managed.
>
> So I'm guessing that there was something in how my system monitor
> profile was being set when I was running digikam 5.7.0 from Gentoo
> Portage, that somehow resulted in the thumbnails not being
> color-managed. So my apologies! for saying the thumbnails aren't
> color-managed. They weren't on my system, but I think this was strictly
> a function of when/how the system monitor profile was being set.
>
> As already noted, the problem with the preview image shadow tonality is
> completely eliminated by changing
> "core/libs/dimg/filters/icc/icctransform.cpp" line 58 from
> "transformFlags = 0;" to "transformFlags = cmsFLAGS_NOOPTIMIZE;" before
> compiling and installing digiKam.
>
> Best,
> Elle

[Elle Stone-2]

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
>
> https://sourceforge.net/p/lcms/mailman/message/29602585/
>
> 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

In terms of the digiKam code going forward, does this mean there will be
a user option to disable the optimizations, such as Krita and GIMP provide?

In other words, what do you mean in practical terms by "specialized
option for 16bit -> 16bit conversions"? What about 32-bit floating point
images? Could there be 16-bit thumbnails as an option?

Marti Maria has made it clear that he doesn't think that linear gamma
RGB image editing makes sense except for raw processing. But he does
allow that there are "strong opinions" on this topic.

Except that this isn't really a matter of opinion, but a matter of how
colors actually do mix in linear gamma RGB vs perceptually uniform RGB:

* If you like darkening between mixed colors, hue shifts in Curves, and
other such gamma artifacts, editing in perceptually uniform RGB is
exactly the right thing to do.

* If you want colors in the digital darkroom to blend more like color
blend out there in the real world, then use linear gamma RGB for editing.

It's as simple as that.

Krita documentation encourages people to use linear gamma RGB precisely
because of the color-mixing benefits (there are nice pictures
illustrating the various points):

https://docs.krita.org/Gamma_and_Linear

Quite a few image editing softwares now make it possible to edit at 32f
in linear gamma color spaces and output high bit depth linear gamma
images, so it's to be expected that users will be outputting images in
linear gamma color spaces.

I think it would be nice if digiKam made it possible for users to view
their linear gamma images without seeing the tonal distortion in the
shadows produced by the LCMS optimizations.

Best,
Elle

[Elle Stone-2]

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
>
> https://sourceforge.net/p/lcms/mailman/message/29602585/
>
> 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
preference.

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
(http://photoflowblog.blogspot.com/,
https://discuss.pixls.us/t/how-soft-proofing-is-implemented-in-photoflow/3546/3).

Best,
Elle

[Marcel Wiesweg]

I have no precise opinion, but essentially thought of a user accessible switch
in the setup.

Performance must be optimized for the >>90% of users with the limited use
cases images in sRGB or Adobe RGB or RAWs -> no monitor profile or one created
with argyll cms / dispcal.

Feedback from people like you with expertise on CM is certainly appreciated.

> 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
> >
> > https://sourceforge.net/p/lcms/mailman/message/29602585/
> >
> > 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
> preference.
>
> 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
> (http://photoflowblog.blogspot.com/,
> https://discuss.pixls.us/t/how-soft-proofing-is-implemented-in-photoflow/354
> 6/3).
>
> Best,
> Elle

[Elle Stone-2]

On 11/17/2017 03:51 PM, Marcel Wiesweg wrote:
> I have no precise opinion, but essentially thought of a user accessible switch
> in the setup.

That would be wonderful!

> Performance must be optimized for the >>90% of users with the limited use
> cases images in sRGB or Adobe RGB or RAWs -> no monitor profile or one created
> with argyll cms / dispcal.

Yes, absolutely the default settings should reflect whatever seems to be
the most common use case.

Having a user option to disable the LCMS optimizations will make digiKam
useable for people who want to see proper tonality for linear gamma
images. I suppose a similar option could be in showFoto? Or would the
one switch cover both softwares?

Through no fault of digiKam's, there is currently no support in digiKam
for GIMP-2.9 XCF files - see GIMP bug report
https://bugzilla.gnome.org/show_bug.cgi?id=782244 - the time to compress
and save an embedded png is not inconsirable, which is a factor not
currently discussed in the bug report.

So to work around the lack of support for 2.9 XCF files, I made png
"sidecar files" for all my XCF files. This required also modifying the
kimageformats source code to not recognize XCF files, and then compiling
and installing the modified code, to keep digiKam from trying to read
the XCF files and then crashing.

Modifying the digiKam source code to not use the LCMS optimazations and
then compiling and installing the modified code turned out to be very
easy to do - the last time I tried to compile digiKam was several years
ago and it wasn't easy, so thank you! to whoever has made compiling
digiKam so much easier than it used to be.

GIMP-2.9 has been my main image editor for painting and photography for
the last five years, so I've accumulated a lot of GIMP 2.9 XCF files.
DigiKam has been my DAM software since around 2007. It's a huge relief
to finally be able to use digiKam for sorting/selecting/viewing the XCF
"sidecar files" and for opening the actual XCF files. I'll probably keep
using this "sidecar" approach even after there is digiKam support for
2.9 (or more likely 2.10) XCF files.

Best,

and thank you for digiKam

Elle