[Digikam-users] DK 3.3.0 Editor: Color Effects not functional

[Gilles Caulier]

2013/8/8 Robert Zeller <robert.zeller at robert-zeller.org>:
> On 08/08/2013 01:18 PM, Gilles Caulier wrote:
>> 2013/8/8 Robert Zeller <robert.zeller at robert-zeller.org>:
>>> Gilles,
>>>
>>> thanks for the instructions. I downloaded the source from git as of this
>>> morning and compiled it. First test shows that the dysfunction has
>>> disappeared. But this version is announced as 3.4.0 . Is it ok to use it
>>> already? I mean is it stable enough?
>> yes, it's fine. 3.4.0 is just 3.3.0 plus few improvements and
>> bugfixes. No problem to use it in production.
> Sounds good. Then I will use 3.4.0 for production.
>>
>> We have few branched version developed by GSoc 2013 students. master
>> branch is stable.
>>
>>> You were talking about race conditions: Does that mean that DK runs
>>> already on multiple cores in parallel for compute intensive tasks?
>> yes it is, but it's not a multi-core problem here. It's a race
>> conditions with signal/slots from Qt that we use in image editor tools
>> interface.
>>
>>> And
>>> if so, what about the version that I just downloaded from git: runs it
>>> parallel or single tasked? I would be very interested to have a parallel
>>> version that runs on the six cores of my CPU, because I am converting
>>> Nikon D800 raw files which have 36 Mpix, and this takes some time.
>> In BQM, since 3.0.0, we use multi-core to process items in parallele.
>> In 3.3.0 i add an option to disable it (look queue settings for
>> details), because some people have a bad experience with it (target
>> files corrupted). Look this bugzilla entry :
>>
>> https://bugs.kde.org/show_bug.cgi?id=318577
>>
>>
>> I never reproduce this on my computer (i process a lots of files here
>> everyday, including Sony RAW files)
> Ok I understand, that means you are starting multiple conversion tasks
> on a number of images in parallel, and the single tasks are assigned to
> the individual cores of the CPU by the BQM. One  step further would be
> to run the conversion of a single image on multiple cores in parallel.
> That should in principle be possible, if you divide the area of an image
> in a number of subareas and run the conversions in parallel on every
> subarea. Is this already possible or are there plans to implement such a
> scheme of parallelism?

For RAW Files, it's already done by libraw (used by digiKam of
course), through OpenMP, especillay for demosaicing task. a 24Mpx on
my i7 computer (8 core), take 2 seconds in editor, in 16bits colors
depth and AMaze demosaicing mode.

For Image Editor tools, it's different. We already use separated
thread to run algorithms, but not yet multi-core. This require to
analyse code and rewrite all with a decomposition of task when image
are processed. It's typically a good subject for a student in the
future.

There are also others tools that use multi-core support in
kipi-plugins, as Panorama (16 JPGS of 24Mpx is compiled on my computer
in less than 5 minutes).

ExpoBlending kipi tool will be parallelized through HDR support
project from GSoC 2013...

> I am normally not using BQM, because I am working on single images one
> by one. Most of my photos don't need any improvement, but if one needs
> editing the steps to be taken are quite individual for each image. So I
> can't use BQM very effectively. Parallelization on a single photo would
> be of great help.
>>
>> So i would to know your feedback here.
> Sure, I will inform you if I find something.
> Thanks for your great responsiveness.

ok thanks

Gilles Caulier