Back in 2010, we looked at Luminance HDR, a
standalone application for creating and editing high dynamic range
(HDR) images on Linux systems. At that time, Luminance was a
technically capable tool with a byzantine user interface that often
got in the user's way. In the intervening two years, the program has
made strides, although it has yet to break through the easy-to-grok
barrier. But it still remains one of the best applications in a small
set of open source options.
In 2010, Luminance was at version 2.0.1. Today, the latest release
is 2.3.0, which was released in July 2012. The intervening releases
introduced cross-platform support (including Mac OS X, which is a
popular request among photographers), 64-bit processor support, and
significant speed improvements through harnessing multiple CPU cores.
The core of the application has been reworked as well, and it now uses
LibRaw for raw photo conversion, Lcms2 for color management, and has
separated the user interface out — which allows for a new
command line front-end.
The feature set is essentially the same as in earlier versions,
however. Users can import a stack of images taken at different
exposure levels and blend them into one; the combined image covers a
far wider range of light-to-dark than a camera sensor can grab in a
single shot. The "exposure-blended" output can be exported either
as an HDR image (in OpenEXR or TIFF format), or tone-mapped into
a more pedestrian low dynamic range (LDR) format. There is one new
tone-mapping algorithm in the latest builds, a size-independent
version of the Fattal method, and
there is an alignment tool which is supposed to support aligning raw
images. The other big news on the feature front is support for
batch processing, for those who create a significant number of HDR
Luminance put to the test
The most visible changes in Luminance 2.3.0 are in the user
interface, however. Most notably, the application confines itself to
a single window — the old interface popped-up multiple windows
and windows-embedded-within-windows, which quickly leads to clutter.
There is a "wizard" to guide the user through the process of importing
and aligning images. Once the image stack is aligned, the user can
click through previews of the output using all of the application's
available algorithms, and adjust the settings of each to gauge how
they affect the output. This is a big improvement over the old
interface, which required generating each output option separately,
then eyeballing them side-by-side in preview windows. Toggling
back-and-forth between the options brings out the often subtle
differences between the various effects.
On the other hand, the application has done little to de-math-nerd-ify
the settings and preferences. In 2010, I speculated that there may be
a limit to how much simplification can be done — the algorithms
are complex equations with a host of esoteric variables, after all.
But Luminance still fails to offer the user any real clues, presenting
instead a list of preset profiles with the utterly opaque names "Profile 1,
Profile 2, Profile 3, Profile 4," (and so on) on the last screen of
the project wizard. I could not even find an option to rename the
profiles. Being able to tweak each algorithm's settings is important,
and seeing the changes applied instantly is a boon, but the generic
names create a usability barrier.
For example, one of the algorithms always produces desaturated output,
and another produces a significant "black outline" effect. Renaming
the profiles "Desaturated" and "Outlined" might not be technically
correct, but it might help users learn to work with the available
options. Sure, user-assigned profile names will be non-standard, but
so are the generic "Profile N" monikers. Does anyone know which of
the numbered profiles represents the algorithms used in other
tone-mapping programs, like Enfuse?
2.3.0 is easier to navigate than the older releases, but it still
has is its share of bugs. In particular, the alignment tool failed
completely in all of my tests. The interface allows manual,
fine-grained adjustment of the imported images, but the adjustment is
immediately lost on the next step. Initially, I thought I had
forgotten to click "Apply" or some other such button, but that was not
the case. Even if one crops the images after the alignment is
perfected, the changes are lost immediately. There are other minor
irritations, such as the file-open dialog not remembering the last
directory, and Exif rotation not being picked up in the project
wizard, but a non-functional alignment tool means Luminance is
effectively useless without near-pixel-perfect aligned images.
There are two possibilities for getting there. The "correct"
thing to do is probably to take all of one's photos from a sturdy
tripod with a cable release, thus eliminating awkward misalignments
from the outset. But even then, wind and camera shake will frequently
cause small misalignments, which necessitates the other option:
aligning the images first using a separate application. Fortunately,
there is a good option available.
The panorama-generation toolkit Hugin has collected an
assortment of valuable accessories over the years, including
lens-calibration functions, cloud-detection routines, and more. One
of the handiest is the ability to automatically align multiple
photographs of the same scene. This is a critical step for stitching
multiple images into a panorama, but it can also be used to align a
stack of images. Hugin will also correct geometric distortion, which
is not mandatory for HDR work, but certainly does not hurt.
In fact, Luminance 2.3.0 can call out to Hugin's automatic image
alignment tool. In my own tests, however, working directly in Hugin
is far simpler. First, in the event that the alignment routine fails
to find where the images line up, you can manually fix problems in
Hugin itself. A failure in Luminance leaves you with only the
Luminance manual-alignment tool (which, in my tests, never worked).
Second, Hugin's ability to fix lens distortion is always applied
before the alignment step, which greatly increases the odds
of success with wide-angle shots (where there is more distortion).
Luminance's call to Hugin's alignment routine does not perform
But Hugin can also perform the exposure-blending step itself, too. It
uses the Enfuse utility, and it produces excellent results. The only
caveat is that Hugin offers no control over the tone-mapping used to
create LDR output. Whatever defaults Enfuse uses are applied to the
output when generating an LDR file. It attempts to create
sane-looking results: no weird color saturation, no "fringing" or
other artifacts one might find in the HDR sections of a photo-sharing
The real question is whether there is any reason to head back to
Luminance if the output from Hugin is good enough. One certainly
can: Hugin can export OpenEXR or HDR TIFF output too; these
files can then be opened in Luminance and tone-mapped with any of the
included algorithms. Whether that is worth it is a purely artistic
decision. For the most part, the output that Hugin gets from Enfuse
is straightforward: balanced color, the full range of contrast. If
the point of blending multiple images is simply to capture a scene
that does not fit into a normal exposure in the camera's viewfinder,
Enfuse will likely suffice. Only if the special-effects look is
desirable does Luminance offer much extra functionality.
Comparing the two user interfaces is a bit of a toss-up. Both fall
well short of making the task at hand simple to understand.
Technically, the best results from Hugin are probably found by making
as few adjustments to the tools and options as possible — but
that fact is far from discoverable. The Optimizer tab,
for instance, offers tantalizing options like "Optimize high dynamic
range," but they rarely do what the user expects and are difficult to
revert. Luminance may throw a screenful of esoteric research-paper
terms at the user, but at least it is easy to click between the
Nevertheless, there are still other options to weigh. The Digikam photo-management suite can
also blend multiple pictures into an HDR image. It, too, uses Enfuse
for this functionality, so its results will be similar, but it is
simpler to use. Hugin's UI is an array of potentially-confusing tabs
— most of which hold tools and buttons that have no bearing on
blending a stack of images together into an HDR format. Avoiding them
entirely may be the best way to get started in HDR images on
On the other hand, Digikam is extremely anxious to take over one's
photo collection and manage it, whether one wants it to or not.
Running it for the first time launches an import wizard that wants to
index the user's entire home folder; the only way to prevent this is
to point it at an empty directory instead.
Another approach might be to use Enfuse directly. Enfuse was
designed to be executed from another application (namely Hugin, which
the Enfuse manual
recommends in its workflow section), but it can be called from the
command line as well. The caveats are that Enfuse needs pre-aligned
images, and it expects certain things from the input image formats.
For instance, it expects input images to have an alpha channel —
which they do when they are generated by Hugin — and throws
warnings when no alpha channel is found.
The final option to consider is exporting an OpenEXR or HDR TIFF file
and using one of the various open source raw converters to make
adjustments to it. Darktable, RawTherapee, and Rawstudio each support
OpenEXR, and they offer the usual slate of adjustment tools. In
short, there is not any reason that an HDR photo needs to be filtered
through one of Luminance's tone-mapping algorithms. Those techniques
can produce intriguing results, but it would be wrong to regard them
as the only "HDR" option.
In that sense, perhaps Luminance deserves a pass for keeping its
algorithm-adjustment options complex. Ultimately, the majority of
users just want a photo that looks good to the eye. The
surreal-looking tone-mapping that first captured the public's
attention with the term HDR has its place, but it does not have to be
the final word, and it probably will not be. The expanding support
for OpenEXR and other natively-HDR formats within the usual
photo-editing applications probably means we will see other uses for
HDR gaining in popularity.
For that matter, the digital camera market is beginning to see
hardware that natively blends together stacks of exposures; HDR is one
of the main selling points of replacement camera firmware projects
like CHDK and Magic Lantern. Add to that
mix the high-bit-depth support coming in GIMP 2.10, and two years from
now, the HDR editing scene on Linux — and other platforms
— could look drastically different.
to post comments)