User: Password:
Subscribe / Log in / New account

Open source High Dynamic Range photography in 2012

Benefits for LWN subscribers

The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

By Nathan Willis
November 28, 2012

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 images.

[underexposed photo] [correctly exposed photo] [overexposed photo]

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.

[Luminance HDR project wizard]

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.

[Luminance tone-mapping]

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.

[Luminance alignment fail]

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 distortion correction.

[Hugin UI]

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 web site.

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 alternatives.

The rest

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 Linux.

[Digikam HDR plugin]

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.

Luminance HDRHuginDigikam
[Luminance HDR photo] [Hugin photo] [Digikam photo]

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.

(Log in to post comments)

Open source High Dynamic Range photography in 2012

Posted Nov 28, 2012 19:43 UTC (Wed) by mikemol (subscriber, #83507) [Link]

For HDR, I usually low my raws into Hugin, do my stitching and stacking there, export to OpenEXR, load *that* into Luminance-HDR, and proceed.

No need to depend on Luminance-HDR for stacking when Hugin does such a terrific job of it.

Open source High Dynamic Range photography in 2012

Posted Nov 28, 2012 22:33 UTC (Wed) by s0f4r (guest, #52284) [Link]

It's unfortunate that in the final results the three images are completely different:

- the luminance result is unwhitebalanced, it looks nice but people may complain it's too yellow
- the hugin result needs to be cropped, and is projected, vs. plainly mapped. That's OK for stitching a panorama, but something you wouldn't do if you used a tripod and do not need aligning.

I use hugin and luminance myself, but often prefer to whitebalance manually before stacking and tonemapping, etc.. Luminance does an excellent job for me as part of the processing flow, emphasis "part".

Open source High Dynamic Range photography in 2012

Posted Nov 28, 2012 23:55 UTC (Wed) by n8willis (subscriber, #43041) [Link]

But the trick is that there is no one, "correct" way to render. The Luminance output, like you say, is a different temperature, but that's a frequent occurrence -- in this case, I think I ended up picking the output example I did just to demonstrate a little bit of the variety possible, without resorting to the goofy-lookind haloed effects you'll find on Flickr. And this Luminance algorithm (whichever one it was...) did a better job of reproducing the color of the backlit tree leaves than did either of the Enfuse results -- which blued-up the sky enough to affect the tree. Guess you can't have it all.

The Hugin output probably needs some FOV adjustment, but that's just because it didn't have the zoom lens on my camera in its database, so I had to settle for an approximation. It was actually a pretty wide angle, and you can see some distortion in the post on the RHS in both of the non-Hugin output images.


Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 2:08 UTC (Thu) by sdumitriu (subscriber, #56869) [Link]

There's also Darktable, which in its most recent version gained more HDR features that at least for me made any other tool obsolete.

Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 10:51 UTC (Thu) by simosx (subscriber, #24338) [Link]

That's in Darktable 1.1, released just last week.
It may take some time for packages to appear.

Among others, there is support for OpenCL.

Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 10:54 UTC (Thu) by simosx (subscriber, #24338) [Link]

There is a gtk+ GUI for Enfuse, MacroFusion at

Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 11:23 UTC (Thu) by gb (subscriber, #58328) [Link]

Why compare images with obviously different white balance?

I'd recommend to article author read few chapters of this:

Through it is named after Photoshop, it is very general and smart book about colors and should be readable for any technically skilled person.

Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 14:15 UTC (Thu) by pboddie (guest, #50784) [Link]

I haven't looked in detail at the "temperature" of the original images, but it looks like the results have different colour casts precisely because of various processing steps employed by the different toolchains. In any case, controlling the white balance precisely (or even at all) is likely to be awkward for some kinds of camera, so it can be informative to see how the tools manage if the settings vary across images.

Making HDR images is a difficult business. Most of the images one sees typically compress the widened range into such a narrow distribution that the result looks like a screenshot from some kind of primitively shaded first-person shooter. Even though the human visual system is able to handle bright and dark subjects much better than the average digital camera, people seem to overlook the fact that it generally doesn't do so all at once: you may be able to distinguish shadow detail in a bright scene by shifting your attention to that detail, but you aren't also having to resolve the details of bright clouds at the same time, and yet a HDR image is expected to do both and still look "natural".

Open source High Dynamic Range photography in 2012

Posted Nov 29, 2012 19:21 UTC (Thu) by n8willis (subscriber, #43041) [Link]

It's not a comparison of the images; it's a comparison of the applications. Specifically their usability, since they are all capable of producing OpenEXR images (in which the white balance is scene-referred...).


Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds