Professional Photo Management with the Power of Open Source

digiKam has a new friend: LibRaw…

by digiKam

3 weeks ago, i have received a mail from a contributor named Holger Berger. He send me a patch against dcraw implementation included in libkdcraw, to parallelize demosaicing operations using OpenMP library. After some tests on my dual core computer i have immediately felt the power of parallelized code: it's faster.

We have tried to contact Dave Coffin to include this patch officially in dcraw... without success (no response). Why ? He don't like OpenMp certainly... So we have looked for another way to use this patch.

On LGM 2008, Alexander Prokoudine dropped a few words about a new library named LibRaw. This library re-uses dcraw implementation and wraps code around a C++ interface.

I have contacted Alex Tutubalin, the Libraw author, and a crazy thread have been started to port libkdcraw to libraw and improve API. After 2 weeks, KDE3 and KDE4 libkdcraw code leave dcraw.c and work fine with LibRaw as well.


With the last LibRaw release 0.6.0, Alex and Holger have started to patch code using OpenMp. It's not yet complete, but work is in progress.

Using Libraw instead dcraw.c brings huge improvements for digiKam: less memory allocation, no pipe to stream raw data generated by a separated process, pure multi-threading, more meta-data and settings to play with RAW files. To resume: Libraw become a new friend for digiKam...

Nice, and good to know for everything else...

because Digikam (or is it kipi-plugins?) could much improve the batch operations (recompress /resize /etc.) if it detects automaticaly the numbers of CPUs (and even better, also detect system load to launch parallel batching.

Example : on a 2 Core system, if load is > 1, just launch one thread, because there is probably too much activity on the system to take benefit of 2 threads. This auto-detection is what misses the most to end users...

.. and it's so easy with Solid

in libplasma we have a RunnerManager, used by apps like KRunner, which manages the threading of Runners (which answer user requests, such as "4+57=" or "google maps" or "word processor" or "/bin/ls" or whatever =) and the threadpool is scaled to match the processor count:

const int numProcs = qMax(Solid::Device::listFromType(Solid::DeviceInterface::Processor).count(), 1);

that one line gives us the number of processors (2 in my dual core laptop).. then we calculate a number, allowing for user config:

const int maxThreads = config.readEntry("maxThreads", 16);
const int numThreads = qMin(maxThreads, 2 + ((numProcs - 1) * 2));

and then set the thread pool count accordingly:


four lines of code ... transparent (to the user) thread scaling according to hardware.

i'd love to see something like this centralized in kdelibs at some point so we can coordinate even between applications, so one MT app doesn't CPU starve another one because they are both doing something like the above =)

Thanks Aaron for this

Thanks Aaron for this tip...

I have search in a pass a way to set threads for computation accordingly with number of cpu available, especially with CImg component into digiKam core.


in Digikam 0.10?

Will it be used in the final 0.10 version? Damn, it's becoming harder and harder not to migrate to a beta version of a distrib to use version 0.10! :)

0.10.0 and 0.9.5...

Yes 0.10.0 (KDE4) and 0.9.5 (KDE3) will use LibRaw. Both branches of libkdcraw implementation are already patched and ready to test...


A fork ?

Is libRaw a fork of dcraw or is it just a wrapper around dcraw (and in this case, regular synchronization between the both codes will be necessary) ?

I know that there are many problems with the dcraw's developper but recently, dcraw was the most complete opensource library for RAW treatment (and RAW treament seems to be a really complex task).

both fork and wrapper

For now, libraw is based on dcraw sources with some our additions:
* Library interface (C and C++).
dcraw is not a library. Many implementations makes library from dcraw by its own (as UFRaw does), and
need to re-sync on every dcraw release. LibRaw team does this job for you (in most cases it takes several hours of work or less).

* thread safety (and OpenMP for AHD and wavelet denoise)
* code and data isolation, it is possible to run several instances in parallel.
* ability to extract image data to memory (faster than dcraw in background)
* ability to extract image data, thumbnail and ICC profile (if exists) in single pass

Minor enchancements:
* gamma-corrected 16-bit output
* (planned to near future) extraction of rgb->xyz coefficients

We plan to implement dark frame data extraction (for use in banding supression algorithms).

Also, we're not happy with dcraw postprocessing stage, but accurate postprocessing is separate
big job (and will be implemented in separate library)

What about using the GPU to

What about using the GPU to speed up calculations?

It's a natural thought to use the processor specialized for displaying things to process the data it has to show... IIRC it should be able to handle floating point and HDR data natively since a few years...

GPU acceleration (to be

GPU acceleration (to be precise, NVidia CUDA acceleration) is planned for the far future.

There is no need for acceleration on RAW parsing phase. On postprocessing phase we (libraw team)
is not happy with dcraw quality (so 'dcraw processing emulation' added only for compatibility).
So, we need to write our own postprocessing modules, than port it to GPU :)

Hi, just a offtopic


just a offtopic thing:

You only have the introduction of your blog posts in your feed syndicated to planetkde. I am not sure if there is a policy thing for this (and I don't think we really need it ), but it seem as all (or nearly all) others have configured it to push full posts in the feeds.

As I do not like to go on every single website just to overread the planet feed, I would really appreciate if you could change this.

Great news!

I just wanted to upgrade my AMD3200+ to a new CPU and was hesitating between dual and quad core, I guess you made my decision easy, it will be quad core! :)
Thanks again for the great work!

External libraw

Could we please have an option to use an external libraw installed on the system instead of the copy in libkdcraw? Or even just always use a separate library (i.e. remove the copy in libkdcraw)?

it's planed...

It's planed.

I have already discuted about this problem with Alex and LibRaw is not yet fully ready to be used as an external shared lib by libkdcraw. For ex, there is no package config settings in LibRaw. Also, Makefiles are hardcoded: no automake/autoconf or CMake environnement. This will be fixed in the future, so for the moment including LibRaw in libkdcraw is the better way.


libraw package

LibRaw 'package' (RPMs/SRPMs, debs, Cmake files and so on) is planned on 1.0 release.
We (libraw team) think, that it is better to focus on functionality, not on bells and whistles

Also, any help is very welcome. SVN repository can be prepared in several days (we use internal CVS now),
so just ask...

OpenMP and gcc

We have been experimenting with OpenMP in "that other raw converter" too - it's quite powerful!

But please note that GCC version < 4.4 can result in some exciting deadlocks with OpenMP in a threaded environment:

Stephane Chauveau has written highly optimized versions of the PPG-interpolation and wavelet-denoise functions in dcraw.

Thanks for the note. We have

Thanks for the note.

We have not see any problems with gcc 4.3 on Mac and FreeBSD (main development platforms),
but will check.

Anyway, OpenMP is experimental feature and not considered stable or ever 'usable' :)

Only when mixing OpenMP and pthreads

According to that GCC bug report, problems can only happen when you mix OpenMP with regular POSIX threads, more specifically if you use OpenMP primitives from more than one POSIX thread at the same time. If you have only one (non-OpenMP) thread doing RAW decoding at any given time and if nothing else in the program is using OpenMP, then that thread is free to use OpenMP without causing this problem.


I was just pointing out that it was something to look out for. If libraw uses OpenMP, it's not thread-safe on older gcc.


Is libraw going to be optional? I'm asking because the more and better libraw becomes, the less reason of existence libkdcraw has...
Wouldn't it then at the end of the day make a lot more sense to use libraw directly in digikam and abandon libkdcraw? I think this wrapper-wrapper-wrapper thing is unneeded here...

libkdcraw still here...

No. code from libkdcraw group a lots of functions used in digiKam kipi-plugins and others KDE program.

It make a coherent call to libraw library everywhere.


Is libraw going to be

Is libraw going to be optional? I'm asking because the more and better libraw becomes, the less reason of existence libkdcraw has...
Wouldn't it then at the end of the day make a lot more sense to use libraw directly in digikam and abandon libkdcraw? I think this wrapper-wrapper-wrapper thing is unneeded here...