[Digikam-devel] [Bug 144593] New High Dynamic Range (HDR) plugin

[Arnd Baecker]

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