Open source High Dynamic Range photography in 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	Exposed	Overexposed

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.

Hugin

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.

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.

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 HDR	Hugin	Digikam

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.