Luminance HDR 2.0.1, an improved, but still trying, photography tool

The term "high dynamic range photography" (HDR) encompasses a variety of techniques for working with specialized image formats that are capable of handling extremes of brightness and shadow beyond what can be stored in more pedestrian file formats like TIFF and JPEG, and beyond what can be displayed on CRT and LCD monitors. The leading HDR application for desktop Linux users is Luminance HDR, though that dominance is mostly by default: Linux-based HDR applications are quite scarce, and have, if anything, become more so since the Grumpy Editor's HDR with Linux article was published in 2007. Luminance recently released an update, which makes progress on the usability front, but still leaves considerable room for growth in the future.

Version 2.0.1 was unveiled on October 9, the first update to the 2.0-series released by the project's new maintainer Davide Anastasia. Anastasia inherited maintenance duties in September, making him the fourth project leader in two years. At that time he outlined a short list of goals on the project blog, beginning with fixing long-standing crashes, then working to undo feature regressions introduced in the 2.0 release, and finally improving on what many users and software reviewers have (accurately) described as a confusing user interface. 2.0.1 introduces a few cleanups, but primarily consists of bug-fixes.

Linux users can download source code packages from the project's SourceForge.net site (the URL comes from the application's original name, Qtpfsgui — arguably the most intimidating project moniker open source software has ever released). There are Mac OS X and Windows binaries provided as well. The code is simple to compile; it uses the Qmake build tool and depends on Qt4, the image processing libraries Exiv2, libTIFF, and OpenEXR, and the FFTW3 and GNU Scientific Library math libraries. The only hiccup that I encountered in the build process was that Qt4-specific versions of Qmake, the Qt user interface compiler UIC, and Qt meta-object compiler MOC are required; those who build Qt4 applications regularly should have no trouble whatsoever.

HDR workflow: image creation

Presumably, anyone with hardware capable of natively capturing and displaying HDR content also has special-purpose editing software provided by Skywalker Ranch, Weta Digital, or some other professional studio. Luminance is designed for the rest of us, with standard-issue digital cameras and displays. Thus, its workflow consists of two major tasks: importing a set of low dynamic range (LDR) images to blend into a single HDR image, and taking an HDR image and mapping it into an LDR format for distribution over the web or in print.

Most readers have seen HDR-based photos on Flickr or other online sites. The canonical example scenarios are city streets photographed late at night (where the buildings, the street lights, and the lit windows are all visible in one shot) and scenes in broad daylight, where both sun-lit and shaded subjects are properly exposed. In all of these situations, the key is taking multiple exposures at different settings: some exposed for the shadow areas, some exposed for the highlights. In software, we can blend them together, leaving neither washed-out bright spots nor murky, underexposed shadows.

Creating a new HDR image in Luminance consists of loading in the set of LDR originals, taken at bracketed exposure settings, lining them up, and blending the stack down into a single image. The image importer allegedly supports a wide variety of formats, including any camera raw file type supported by DCraw, JPEG, and TIFF. Once imported, Luminance reads the exposure setting from each file's EXIF tags, or allows you to input it manually if such a tag cannot be found. There are two automatic image-alignment algorithms available — an internal scheme labeled "Median threshold bitmap," and the align_image_stack function from the open source panorama tool Hugin. Alternately, you can choose to manually align the images using built-in editing tools. Finally, you must choose an HDR image "profile," consisting of a weighting function, response curve, and HDR creation algorithm. The settings you choose are applied to your stack of input images, and the result pops up in a preview window, where you can inspect it in all of its HDR glory.

In my tests, however, there were more than a few pitfalls to this process. First, selecting and loading the LDR images is more difficult than it needs to be, because you must select all of the images you want to use in the file selector, at the same time (i.e., there is no "add another" button). This means they must all be in the same directory, and on a practical level it means you must look them up in an image previewer first, because there is no thumbnail preview, and after a while the contents of IMG_4342.CR2 and IMG_4243.CR2 become harder to memorize. Luminance also cannot read Exif tags from TIFF files, and I was unable to successfully load JPEG conversions of my raw images, with Luminance complaining that they were an "invalid size," regardless of what size they were saved at.

The alignment step is also problematic; the Median threshold algorithm crashed every time I tried it, and align_image_stack tended to hang indefinitely. Eventually I decided to align my test images in Hugin directly, but this is also a very trying process. The wiki documentation is more than two releases out-of-date, and I could not decipher which combination of checkboxes needed to be set for Hugin to align the images geometrically without attempting to blend their exposure settings. That experiment ended up being a useless tangent anyway, however, because Luminance could not read any of the TIFF files Hugin produced. At the Hugin wiki's suggestion, I also attempted to use the Perl-based hdrprep for alignment, but it too failed to read the Exif data from the TIFFs.

The manual alignment tools offer some fine-grained control, including multiple ways to overlay two images on the canvas in order to eyeball their overlap and a masking function called Anti Ghosting. Sadly these tools also fall a bit short, primarily because there is no way to correct rotation problems, only vertical and horizontal pixel shifts. Even when I took test photos with a tripod, a small amount of rotation misalignment was part of the natural wind-and-camera-shake effects.

It is also difficult to make an informed choice about the HDR profiles, which are named "Profile 1" through "Profile 6." The weighting function, response curve, and HDR creation algorithm options are similarly opaque, and because installing 2.0.1 from source evidently does not include the user manual, looking up the HDR terminology online is the confused user's only recourse.

HDR workflow: image output

Luminance is capable of saving directly to several HDR image formats, including Logluv TIFF and OpenEXR. These formats use floating point numbers rather than integers for pixel data, allowing them to encode a much wider range of total values — potentially 38 f-stops, depending on the options.

This is orders of magnitude greater than a modern PC screen can display, so Luminance provides an HDR "visualizer" that allows you to explore an HDR image by adjusting the gamma and exposure with sliders. It might be confusing to new users at first, because it appears at first glance like the process of importing and blending the source images has produced nothing more than another LDR image, but in fact the visualizer only shows a portion of the image at a time, due to the physical limitations of the display.

If your goal is to save the image to OpenEXR or another format, you can do so as soon as the import process is complete. Most of the time, however, you will be interested in the second of Luminance's major tasks, compressing the HDR image back into a common LDR format — in such a way that it preserves as much detail as possible. You do this with the "Tonemap HDR image" menu entry, which brings up a workspace where you can select and test nine different tone-mapping algorithms, creating thumbnail-sized preview images before committing to a final choice.

Here again the user interface confronts the user with a formidable list of techno-speak options and little in the way of explanation. At some level, that is expected; the algorithms have scientific (rather than marketing-approved) names such as Mantiuk '06 and Reinhard '02 because they are named after their creators. But without reading the original papers, it is unreasonable to expect a user to decipher all of the individual settings. The Ashikhmin algorithm, for example, sports a checkbox labeled "Simple" and a radio button allowing you to choose between "Equation Number 2" and "Equation Number 4." Anyone who can guess what that means without looking is my personal hero.

Still, at least Luminance gets it right by allowing you to experiment with multiple test images and to compare them side-by-side. Other parts of the GUI (such as the image loader) have a frustrating lack of backup or undo operations. The final output, after all, is the end that justifies all of the means — so if a user can experiment with different algorithms and eventually stumble across a pleasant result, he or she will be happy even if the underlying formulas remain a mystery.

The upper-bound on usability

The tone-mapping algorithm "issue" raises an important question for Luminance and other niche graphics applications, namely: is it always possible to build a user interface with novice-level simplicity, or are some tasks inherently complicated? Do users really need all nine tone-mapping algorithms? Perhaps Luminance could be refactored to hide all of the mathematical details from the user, or dress them up in friendlier terms — but maybe that process would destroy too much of the application itself, turning it into a toy. The same question could probably be asked about Hugin or any of several complex GIMP plugins.

I tend to think that photographers (like everyone else) have a greater capacity for understanding the scary mathematical and theoretical tasks than they give themselves credit for. Most have gotten used to the arcane demosaicing and noise-removal algorithms found in raw image editors, after all. While Luminance 2.0.1 was frustrating to work with for many reasons, the bulk of the frustration came not from exposing too much scientific technobabble, but from the same sort of usability and interface problems that plague any understaffed project: the lack of thumbnail previews, vacant tooltips, missing "undo" buttons, unsupported file formats, and sudden crashes. My guess is that, absent those stumbling blocks, almost any user could get used to the peculiarities of HDR image creation and tone-mapping.

That having been said, Anastasia has his work cut out for him. Luminance has had many cooks in recent years, a fact that has undoubtedly contributed to its perplexing user interface and crash-proneness. Cleaning it up is high on Anastasia's to-do list as project maintainer; those of us who want to see a high-quality open source HDR tool can only hope he manages to build some momentum. Version 2.0.1, although it was only a bug-fix release, is a tantalizing first step because it came mere weeks after Anastasia took over the reins — the gap between the last 1.9.x release and 2.0.0 lasted well over a year. Today, Luminance has an active maintainer, a new release, and a TODO file included with the source code package. It isn't perfect, but it could be the beginning of something good.