Bug 144593

Concerning task 2: I think it is quite complicated, but Digikam could use Hugin (http://hugin.sourceforge.net/).

Here is a tutorial:

http://www.panotools.info/mediawiki/index.php?title=HDR_workflow_with_hugin

There is an interesting article on HDR with linux
  http://lwn.net/Articles/225652/
Another good overview  of the techniques
http://www.mpi-inf.mpg.de/resources/pfstools/papers/mantiuk07hdr_pipeline.pdf


Concerning the software side:
- http://www.mpi-inf.mpg.de/resources/pfstools/
- A step by guide using pfstools:
  http://www.flickr.com/groups/technique/discuss/72157594155731025/
- examples of tone-mapping algorithms (follow the links):
  http://www.mpi-inf.mpg.de/resources/tmo/
- Comparison of different tone-mapping algorithms:
  http://dativ.at/logmap/index.html
- on qpfstmo, tone-mapping
  http://theplaceofdeadroads.blogspot.com/2006/07/qpfstmo-hdr-tone-mapping-gui-for-linux_04.html
- Maybe this is presently the best all-in-one solution:
  http://qtpfsgui.sourceforge.net/

For images taken without a tripod one can use hugin
to get them aligned:
http://chris.quietlife.net/2006/09/06/hdr-and-tonemapping-in-linux/

Concerning integration in digikam:
I am not sure whether this is really a good idea;
the main strength, in my opinion, of digikam is
the administration of images + some simple manipulations.
For other tasks specialized tools should be used, i.e.:
- for image manipulation: gimp, krita, ...
- for building panoramae: hugin
- for HDR images: the above tools

For example for constructing panorama pictures from
single shots, I wrote a small script (showing up as a menue
on right-click in the album view), which copies
all selected images into a separate folder in /tmp
where I then start hugin, create the pano,
and then finally copy (using an automatically generated script)
them back into the corresponding digikam folder.

What about making the integration of external tools/scripts (even into
digikams menus + association of short-cuts) possible?

Of course, adding support for viewing HDR images
(e.g. OpenEXR format etc.) might be nice.

I agree that stitching and tonemapping should be done by external apps. 
Digikam could just ease the communication with these apps and manage the generated pictures.

On my old Canon S40 the files taken in stitching mode are all called st_*. I don't if other camera do the same. When picture are taken using bracketing, I think the info is also in the exif.

This could be an hint for Digikam to group the picture (later when the 'group of pictures' is implemented) and add actions such "Stitch using Hugin." "Stitch using "qtpfsgui".  

One more link concerning the comparison of tone-mappers:
http://osp.wikidot.com/parameters-for-photographers

> ------- Additional Comments From Julien.Narboux inria fr  2007-04-24 10:33 -------

[...]
> On my old Canon S40 the files taken in stitching mode are all called st_*.
> I don't if other camera do the same.


For most DSLRs there won't be such stitching mode
because there is no live-preview (apart from those who
already have  a 1D Mark III ;-)

Usually takes such pictures in manual mode
(after selecting exposure for one direction) and with a fixed
white-balance. So this, together with specifying a time-interval
(i.e. shots taking in a range < 1 min.), should allow
automatic grouping.

> When picture are taken using bracketing,
> I think the info is also in the exif.


Yes, for the to-be HDRs (which I still have to process ;-),
my Canon 350D records:
  Exposure Mode: Autobracket
  Exposure Bias: 0, -2, 2       (in that order)

So it is straight-forward to sort them into a group.

> This could be an hint for Digikam to group the picture (later when the 'group of pictures' is implemented) and add actions such "Stitch using Hugin." "Stitch using "qtpfsgui".


Yes, grouping of pictures would definitively help a lot for such
of tasks (including the possibility to select more than one
representative image of such a group to be visible in the album view etc.)

But for this, a change in the database would be necessary +
adding quite a bit of code ...

Hmm, all this is more related to
http://bugs.kde.org/show_bug.cgi?id=121310

For integration of pfstools, QtPFSGui is the place to look, it seems they have integrated the PFS tools in their source code, may be as we include dcraw. (not looked at the source).

A blog entry from a Krita developer about the aligning problem:
http://cyrilleberger.blogspot.com/2007/04/aligning-images.html

As to creating a HDR, it can be a job for a KIPI plugin, if the process is mostly automatic. As Gerhard said, we dont want to mimic full-blown image editor capabilities.

Viewing HDR images can be integrated in the image viewer. Question is: Is loading+tonemapping a fast process? Or like loading a raw image? Or does it really take time? Furthermore, before opening such an image, a dialog might be needed asking for the preferred algorithm or settings, I dont know.

@Arnd: Yes there will be changes in the database, and there will be grouping of pictures, but dont expect it in the next months.

Thinking about this, it might _not_ be a task for a kipi plugin. If we need access to the pixel data of the full images, for aligning or for combining, an implementation using the image editor core will be better suited.

As I am a lazy guy by principle (lion) I don't like to switch applications during my workflow. As much as I want digiKam to remain easy to use, as much I thrive on sophisticated features like restauration or refocus. For example this morning i did 50 shots of commercial products to be integrated into a web site. I use digiKam's cropping, automatic correction, whitebalance, resizing and renaming tools. For the non-rectangulars I have to open another application to select and delete the background. So for me digiKam should have some selection tool, a stamp-copy and an eraser to be complete, all tools that don't employ layers. That's why I think that if we can integrate HDR into digiKam I would always prefer that. Looking at the dynamics of development, I also feel that digiKam is fast and might have to wait for another application to improve on a feature. I also feel that HDR is becoming popular.

Remark: the "Photographic reproduction" algorithm that i mentioned in #1 seems to be the Richard algorithm of the mpg site. So that one we can get a hold of.

I don't think matching layers needs a difficult algorithm as panorama tools do. HDR deals with minute in-plane shifts and even smaller rotations in a group of images, distortion don't need to be corrected.

Ad #5

> As to creating a HDR, it can be a job for a KIPI plugin, if the
> process is mostly automatic. As Gerhard said, we dont want to mimic
> full-blown image editor capabilities.


It seems it can be done automatic, but
in qtpfsgui there are also several default settings + the custom
mode in which one specify things like `confidence functions`,
`response curves` (or even use calibration to determine the
response curve of the camera) and different HDR creation models.

> Viewing HDR images can be integrated in the image viewer. Question
> is: Is loading+tonemapping a fast process?


This depends on the actual tonemapping procedure.
Some of them work pretty fast (on reduced size images),
but others can take much longer.
Tonemapping seems to be really the "art" part of the whole
procedure. For each algorithm there are several
parameters to tune ...

According to http://osp.wikidot.com/qtpfsgui-manual
for the quick display of the generated HDR a
``luminosity compression'' algorithm is used.
This might be something which could be incorporated
to display an HDR image as a thumbnail in the album-view.
Clicking on such a hdr could either bring up
an external tool (such as Qtpfsgui) or some additional
HDR editor (like the image editor itself).

The workflow could be
a) select a sequence of bracketed images (within digikam)
b) use Qtpfsgui to generate a HDR
  (optionally: save the hdr)
c) use Qtpfsgui to do the tone-mapping
d) save the resulting image as .png/.jpg etc.

One approach would be to make this sequence of steps
as simple as possible from within digikam:
a) - selecting images: no problem.
   - associating a program with right-mouse click: also no problem.
   - better option: have a menu entry (with definable shortcut)
   - problem: Qtpfsgui presently does not take parameters (=images)
     from the command line to directly generate a HDR.
b) minor detail for Qtpfsgui:
   for saving the hdr a reasonable name, composed of the input images could
   be suggested
   (no idea about exif info for HDR file formats)
d) For saving it might be nice if some of the exif information
   of the original images would be kept?

So for this to work it would be mostly a few small changes
on the Qtpfsgui side...

Of course, I can understand the wish to have everything
integrated within one application.
However, personally I am not in favour of re-doing a
HDR tool such as Qtpfsgui within digikam (or kipi-plugins, etc.).
It seems like a waste of resources, better needed at
other places of digikam and being against the unix philosophy
to "write programs that do one thing and do it well.
Write programs to work together."
but hey - I am not doing the coding ;-)

HDR was and is hot, but tonemapping HDR images often does not render realistic results, even when care is taken to preserv the real-look. 

A new tool has recently been released called tufuse.
Tufuse is capable of exposure blending and FOCUS BLENDING.
Tufuse generates REALISTIC scenes without needing to go into HDR mode!

Check it out here:
http://www.tawbaware.com/tufuse.htm

I spoke with the author and unfortunately a cross-platform version isn't planned, so that would mean that in order to implement something as great as this in digikam, you (the programmers) would need to write a tool the works the same way as tufuse from scratch.

I, honstely, would prefer to see something realistic like tufuse in digikam, than hdr which renders less realistic tonemapped results.

A friend and I wrote a script to use tufuse.exe through wine and batch process whole directories of bracketed shots. 
See it here:
http://www.autopano.net/wiki/action/view/Bashfuse

I wrote a new script to use Enfuse in digiKam, you can read about it and get it here:
http://www.panopixel.org/bashenfuse.php

I prefer it over tufuse because it does the same job but is open source, much faster, and allows me to process bigger files.

I voted for this feature.

I found qt-based application (http://qtpfsgui.sourceforge.net/) which performs HDR-imaging.

Maybe it is possible to refactor their code to some kind of new kipi plugin?

Everyone can test the new Kipi plugin in preparation by Gilles Caulier based on qtpfsgui :
http://websvn.kde.org/branches/work/~cgilles/hdrcreator

Nice work Gilles ! 

To simplify interface:
Maybe one could delete some of the algorithms. I managed to get decent result with only three algorithms : Reinhard02, Reinhard05 and Fattal the others gives result which are not realistic.

Julien

Julien, for me playing with HDR is not only about getting realistic results, but about surprising and unrealistic but stunning results.
When changing the parameters for the individual tone-mapping modes, you can get a wide range of realistic to completely unrealistic results.

http://osp.wikidot.com/parameters-for-photographers

SVN commit 1064720 by cgilles:

New tool to create pseudo HDR image using align_images_stack (Hugin project) and Enfuse (Enblend project).
It use a set of bracketed image, aligned automatically and fused
BUGS: 144593


 M  +2 -1      CMakeLists.txt  
 A             expoblending (directory)  
 AM            expoblending/CMakeLists.txt  
 AM            expoblending/Messages.sh  
 A             expoblending/TODO  
 AM            expoblending/aboutdata.h   [License: GPL (v2+)]
 A             expoblending/blendingdlg (directory)  
 AM            expoblending/blendingdlg/enfusesettings.cpp   [License: GPL (v2+)]
 AM            expoblending/blendingdlg/enfusesettings.h   [License: GPL (v2+)]
 AM            expoblending/blendingdlg/expoblendingdlg.cpp   [License: GPL (v2+)]
 AM            expoblending/blendingdlg/expoblendingdlg.h   [License: GPL (v2+)]
 AM            expoblending/expoblending.cpp   [License: GPL (v2+)]
 A             expoblending/expoblending.desktop  
 A             expoblending/icons (directory)  
 AM            expoblending/icons/CMakeLists.txt  
 AM            expoblending/icons/hi16-action-expoblending.png  
 AM            expoblending/icons/hi22-action-expoblending.png  
 AM            expoblending/icons/hi32-action-expoblending.png  
 AM            expoblending/icons/hi48-action-expoblending.png  
 A             expoblending/importwizard (directory)  
 AM            expoblending/importwizard/alignpage.cpp   [License: GPL (v2+)]
 AM            expoblending/importwizard/alignpage.h   [License: GPL (v2+)]
 AM            expoblending/importwizard/importwizarddlg.cpp   [License: GPL (v2+)]
 AM            expoblending/importwizard/importwizarddlg.h   [License: GPL (v2+)]
 AM            expoblending/importwizard/intropage.cpp   [License: GPL (v2+)]
 AM            expoblending/importwizard/intropage.h   [License: GPL (v2+)]
 AM            expoblending/importwizard/itemspage.cpp   [License: GPL (v2+)]
 AM            expoblending/importwizard/itemspage.h   [License: GPL (v2+)]
 AM            expoblending/importwizard/lastpage.cpp   [License: GPL (v2+)]
 AM            expoblending/importwizard/lastpage.h   [License: GPL (v2+)]
 A             expoblending/kipiplugin_expoblending.desktop  
 A             expoblending/manager (directory)  
 AM            expoblending/manager/actions.h   [License: GPL (v2+)]
 AM            expoblending/manager/actionthread.cpp   [License: GPL (v2+)]
 AM            expoblending/manager/actionthread.h   [License: GPL (v2+)]
 AM            expoblending/manager/manager.cpp   [License: GPL (v2+)]
 AM            expoblending/manager/manager.h   [License: GPL (v2+)]
 A             expoblending/pics (directory)  
 AM            expoblending/pics/assistant-align.png  
 AM            expoblending/pics/assistant-enfuse.png  
 AM            expoblending/pics/assistant-stack.png  
 AM            expoblending/plugin_expoblending.cpp   [License: GPL (v2+)]
 AM            expoblending/plugin_expoblending.h   [License: GPL (v2+)]


WebSVN link: http://websvn.kde.org/?view=rev&revision=1064720