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:

Weaver::instance()->setMaximumNumberOfThreads(numThreads);

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 =)

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...

digiKam

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)

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 :)

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.

digiKam

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...

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' :)

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.

digiKam