[Digikam-devel] [Bug 144593] New: New High Dynamic Range (HDR) plugin
Gerhard Kulzer
gerhard at kulzer.net
Tue Apr 24 08:28:56 BST 2007
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.kde.org/show_bug.cgi?id=144593
Summary: New High Dynamic Range (HDR) plugin
Product: digikamimageplugins
Version: unspecified
Platform: Debian testing
OS/Version: Linux
Status: NEW
Severity: wishlist
Priority: NOR
Component: Wish for new plugin
AssignedTo: digikam-devel kde org
ReportedBy: gerhard kulzer net
Version: (using KDE KDE 3.5.6)
Installed from: Debian testing/unstable Packages
OS: Linux
This is to start a discussion on a new HDR plugin. A HDR tool will mix two or more (nearly) identical images having different exposure into a new image representing a wider dynamic range, which is closer to human perception of a photographic scene. So far so simple.
The two main tasks to be accomplished are:
1. the mixture algorithm
2. realignment of composing layers
Gimp-like applications allow for manual combination of layers through gradients and mask painting. This is not trivial, and with mask painting one can easily spend a couple of concentrated hours in front of the screen, the mouse arm ending seized in its socket.
digiKam must accomplish some intelligent __automatic__ layer combination, as it doesn't want to compete in the Gimp arena and remain easy to use. Task 2 arises from the fact that bracketing often produces slightly shifted and rotated image series, which will blur the end result if combined without registering between the layers. But it is questionable in its priority compared to task 1, the HDR tool itself.
I've dug out an article on the relative merits of various known combination algorithms (see this link: http://www.gerhard.fr/files/HDR-tone-mapping.pdf, look at pages 641 and 645 in particular). The "Icam model" and "Photographic reproduction" algorithm seem to win the price. For the Icam model I found another article with all mathematical details required to define an algorithm (see http://www.gerhard.fr/files/MFairchildArticle01-2004.pdf).
Question: does anybody know a coded implementation of this model?
Task 2 I haven't analyzed yet, but some simplified "minimum entropy " algorithm should be able do find the best match between layers. For example, one could sample 3 small areas widely separated and run entropy minimization, say LL, LR and center (because the upper half tends to be occupied by the sky which shows no exploitable details), or the 3 areas could be manually chosen.
What do you think?
More information about the Digikam-devel
mailing list