Bug 226799 - RawEngine should use all CPU cores when converting images
Summary: RawEngine should use all CPU cores when converting images
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-DImg-RAW (show other bugs)
Version: unspecified
Platform: openSUSE Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-14 13:04 UTC by Roman Fietze
Modified: 2018-04-01 09:46 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 1.2.0


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Fietze 2010-02-14 13:04:08 UTC
Version:            (using KDE 4.4.0)
Installed from:    openSUSE RPMs

There already exist converters based on dcraw (ufraw) and even patches to dcraw (using OMP) to use multiple CPU cores when converting images.

This is esp. interesting e.g. inside digikam or other viewers or editors when the user wants to scan through the shot images and needs quick responses waiting for single images.

Batch conversion is a different question, here I could easiliy parallelize by calling multiple instances of dcraw/libkdcraw, but not when I just convert a single image.
Comment 1 Johannes Wienke 2010-02-14 13:50:35 UTC
Can you have a look in digikam under help -> component information whether parallelized demosaicing is active?
Comment 2 Roman Fietze 2010-02-14 14:57:22 UTC
(In reply to comment #1)

> ... whether parallelized demosaicing is active?

It tells me "Yes"

Some more info, just in case it might be useful:

digikam-1.1.0-29.8.x86_64
libkdcraw8-4.4.0-150.9.x86_64

I also checked the source files of kdegraphics4 and could see some code using OMP, and the libs using ldd and I could see libgomp.

Hmmm? It seems the most CPU cycles are used to convert to the displayed image format. See my small benchmarks below.

I tested it with a RAW-> 8 Bit PNG/PPM conversion from a Nikon 3s and 70s and a Canon 350D on a Quad Core Phenom II 905e:

- digikam batch: 25-35s (PNG), 10-12s (PPM)
- ufraw-batch: 25-30s (PNG), 11-12s (JPG), 7.5-11s (PPM)
- my own dcraw OMP patch: 12-18s (PNG), 6.5-8.5 (JPG), 6.5-7.5s (PPM)

I can provide my own patches if you are interested. They are based on the older 8.89 of dcraw, the results do not differ in any bit from the results created by the original dcraw version (test script) using Nikon 70s and Canon 350D images.
Comment 3 caulier.gilles 2010-02-14 17:23:10 UTC
Roman,

Due to a bug fixed by me in libkdcraw just before KDE 4.4, openMp api is only used properly in libraw with libkdcraw 1.0. With older version Help/Components Info said Yes with parallelized demosaicing, but it's wrong in fact.

Checkout libkdcraw form trunk, compile it (no need KDE 4.4 in fact), and recompile and install digiKam/kipi-plugins

Gilles Caulier
Comment 4 Roman Fietze 2010-02-15 18:36:49 UTC
Works much better with manually compiled libkdcraw8.

Now I get comparable times, somewhere between my implementationd and ufraw-batch.