Luminance HDR offers top-notch high dynamic range imaging
Processing images with a high dynamic range – that is, an image with a wide range of values between its bright and dark areas – is possible with open source Luminance HDR.
HDR (High Dynamic Range) image processing is a state-of-the-art technology that, in the right hands, qualifies as an art form. The images this method creates are characterized by a wide range of brightness, an amazing level of detail, and – sometimes – striking colors. Many methods, with many parameters, control the precise results. The open source program Luminance HDR  groups these methods in a front end; however, despite really good software, you still need a good deal of expertise to achieve impressive results. Luminance is the successor to QtPFSGui , a Qt4 user interface for creating HDR images.
The human eye can see many more, and in some cases finer, differences in brightness than a digital camera. HDR images can compensate for this partly, but the way we perceive these images is vastly different. A special problem arises when presenting HDR images. Both computer screens and printers have limited capability when it comes to portraying brightness differences naturally. For example, today's typical LCD monitors resolve around 256 levels of brightness for each channel (red, green, blue; 8 bit), and printers even fewer levels, which explains why many image formats – led by JPEG – only support 8 bits per color channel by default.
Digital images of this kind are known as Low Dynamic Range (LDR) images. Most image manipulation programs were developed for these images – GIMP can currently only process LDR images today. However, the KDE image manipulation program Krita  is an exception to the rule.
Modern digital cameras use sensors that capture brightness in the RGB channels with at least 10, but normally 12, bits per channel. More expensive cameras can also resolve brightness at 14 and 16 bits per channel. This causes an interesting problem: The 12 to 16 bits captured by the camera need to be converted to 8 bits by way of small, non-linear changes in brightnesses that avoid losing the information in these bits entirely. This process is known as "tone mapping" and is precisely where HDR photography enters the scene. It uses various algorithms known as "tone-mapping operators" to convert LDR images to an HDR image that better matches the human eye's visual capabilities; among other things, tone mapping can convey very special, exotic moods.
The methods used can be divided roughly into three groups: global tone-mapping methods, which take into account the overall contrast of the image; local tone-mapping methods, which look only at local contrasts; and other methods that use very different methods.
Luminance groups various tone-mapping operators and lets users apply them to an image (or a series of multiple-exposure images). The best results of tone-mapping operators are achieved if you use the RAW image as input; only RAW input provides the entire exposure information of the sensor. Alternatively, you can provide the extended brightness range by creating a series of exposures (bracketing). In bracketing, your camera takes three or more images in rapid succession with different exposures (typically: 0EV, +1EV, -1EV, etc.). If you have the option, you should set the bracketing so that the shutter speed varies, and not the aperture. Changing the aperture leads to different depths of field, which is seen as a blur when combining the images.
When launched, Luminance opens a plain main window (Figure 1). From here, you can load a single image (Open HDR image) or drop a RAW image from the file manager onto this window.
If you want to load multiple images from an exposure series, click New HDR image and a wizard automatically appears to guide you through three steps of preparation for combining the images. First, Luminance loads the (source) images and shows them to you as a list (Figure 2), where you can adjust image exposures separately if the automatic results are not what you need. Usually, the automatically determined exposures are more suitable for further processing than self-selected values. This is true even if Luminance shows you values other than those set on your camera.
Luminance uses the Hugin  approach of aligning multiple images so that they are perfectly superimposed. This means you can even combine photos that only match approximately because they were not taken using a tripod, for example. In this step, you can check, and possibly even improve, the alignment quality (Figure 3). In this dialog, you also can set an image area for further processing using Crop All Images. The last dialog internally converts the source images into an editable Luminance HDR image.
Clicking Apply generates the preview for the tone-mapping operator that appears at the top in the left pane (Figure 4). Depending on your computer and the selected options, this can take some time. At first, choose a small image size (Result Size), because initially, you will only be creating a preview; however, it should not be too small, because some effects are only visible at a certain size. Values around 1000x… pixels are suitable.
Unless you uncheck Update current LDR, Luminance will only produce one output image and update it over and over again. If you want to compare the results, disable this option. Luminance remembers the parameters with which an image was created and uses them as the file name when you save. Save as saves the current image shown in the preview. Before finally saving, remember to check the size again and adjust and recalculate the image if necessary.
After generating multiple versions of an image Save All is the right choice: Luminance then lets you create a directory for the images. In both cases, Luminance stores images with long file names of the form
<Filename>_pregamma_1_fattal_alpha_1_beta_0.9_saturation_1_noiseredux_0..., which Luminance then displays in tabs.
As simple as using Luminance is, you are still a long way off to creating a good HDR image. The first step is to determine the right tone-mapping operator (see the "HDR Algorithms" box). This is often not easy because the results of the operators differ significantly in most cases. Although Luminance shows you a small preview of the available operators on the right, these images are not good enough to let you select the "correct" method. Over time you will develop a sense of which operators are appropriate for an image and which you do not need to look at in any great detail.
The algorithms that Luminance provides can be roughly divided into four categories:
Local operators – The Ashikhmin operator attempts to integrate the relevant factors of visual perception into its dynamic compression. A variation of the filter radius attempts to keep the contrast in the image. Often, this operator requires a brightness adjustment.
Global operators – The Drago operator also tries to simulate the human eye with a logarithm. Lighter areas are compressed more than darker ones. Often, this operator requires a brightness adjustment using the Bias slider. Methods such as this published by Erik Reinhard and others are based on the zone system. Again, compression is stronger in lighter areas. Among the several variations of this process, some are local operators.
Gradient-based operators – The Fattal tone-mapping operator often has a very good effect because it keeps fine differences in brightness very well, while producing realistic, detailed images. Additionally, it lets you reduce noise. This parameter can significantly influence the overall impression of the image, including the colors. The Version 2.3 checkbox is important because only this version guarantees that the result remains the same for different image sizes.
Mantiuk '06 and '08 and the rest of the crop – The first tone-mapping operator that Luminance presents to the user in two variants is the operator developed by Mantiuk, which is very often used because of its prominent location. Mantiuk '06 is particularly problematic because it often creates dull or sometimes falsified colors, generating oversharpened images that are prone to artifacts (see "A Complete Workflow"). The newer version, Mantiuk '08, largely avoids these problems. However, these shortcomings can also be put to creative use or avoided by appropriate parameters. A Bash script exists for the Mantiuk (06) algorithm .
The other operators, such as Pattanaik, rarely produce really good results. The various algorithms are compared   and described in detail  on the web.
The tone-mapping operators differ in many details, which is apparent in the selection of operators in Luminance. The parameters that you can influence range from just one in Drago up to five for Reinhard '02. You should first try the respective defaults because they usually generate very good results.
The resulting effects of the operators are quite different; for example, Mantiuk '06 often generates very pale, rough (oversharpened) results, whereas the results of Mantiuk '08, Fattal, and Durand typically appear much finer. However, images generated with Durand, Reinhard '02, and Reinhard '05 are often quite bright. A comparison in a difficult lighting situation is shown in Figure 5.
However, you can still easily correct this shortcoming later. To do so, press the Adjust Levels button. This opens a simplified version of the GIMP Levels tool. With it, you define the upper range for the input values that are converted to output values. Luminance maps values to the left of the slider entirely in black; a similar thing happens to values to the right of the right slider, which are all white. The middle (Gamma) controller shifts mean brightnesses and thus affects the "mood" of the image; however, you will not want to do this until you are adding the finishing touches.
Before you adjust the brightness, you should look at the effects if the Pre-gamma slide control, which depend on the current image and in particular on the tone-mapping operator you are using. Sometimes, this setting has no effect on the brightness but rather on the "colorfulness" of the results. Therefore, it is often useful to compute three different versions of an image for the current operator with normal, reduced, and increased pre-gamma settings.
Only after deciding on an operator and the pre-gamma level should you tune the other parameters to create the final version. Unfortunately, there are no universal rules for this. The results vary widely for various images and tone-mapping operators.
You can save the parameter sets that are best suited to your images. The three buttons on the right let you do this. You can store these defaults in an internal database or an external file.
In batch mode (Tools | Batch Tone Mapping), the parameter sets are then available for later use. Figure 6 shows the corresponding dialog. First, you create HDR images from the source images with Tools | Batch HDR and store them in a directory. Then, you convert them to LDR images with the desired parameter set. This is somewhat simpler and more flexible directly in the shell (see the "pfstools" box).
The code for Luminance HDR tone-mapping operators came directly from pfstools  – a suite of shell programs used for HDR processing. When it comes to generating large numbers of HDR images automatically with varying parameters, it certainly makes sense to look at these programs. Pipes make the use of pfstools simple:
pfsin <source_image> | pfstmo <operator with parameters> \ --verbose | pfsout <output_image>
pfsin loads the images,
pfstmo <operator> processes them, and
pfsout finally creates the LDR image.
A Complete Workflow
The Mantiuk '06 tone-mapping operator is a special case. It often has problems with solid color blocks and the edges of these areas, such as building edges against a lackluster sky. In such cases, Mantiuk '06 should not be used. However, if this method achieves particularly good results in other areas, you can just combine the areas on several layers. This method works really well in GIMP. To do so, load two or more finished LDR images (as layers) into a GIMP image. Then, for example, remove the sky where the problems occur.
The easiest way to do this is add an alpha channel to the layer on which you want to remove the sky (Layer | Transparency | Add Alpha Channel) then place it on top of the layer that has the sky you want to use. With the eraser, you can "rub out" the sky; do not worry if you accidentally remove too much because you can unerase (Alt+eraser tool) to put anything back in that you want to keep in the picture. Alternatively, you can use a layer mask that lets you do the same thing. The first method has the advantage of allowing you to produce a selection from the layer menu (Layer | Transparency | Alpha to Selection), which can then be used on other layers (Figure 7).
It is also possible to dispense entirely with HDR tools and still get good exposures. GIMP, for example, offers the
exposure-blend script for this purpose, which can be used to mix three images from a series of bracketed exposures. You will probably resort to using GIMP anyway in a further processing step – for example, to align or crop the image, balance the perspective, adjust the edges, lighten or darken certain areas, or make similar adjustments, as shown in Figure 8.
Besides RAW files and HDR images, Luminance can also load the OpenEXR, Radiance RGBE, TIFF (16 bit, 32 bit, float, and LogLuv), PFS, and JPG image formats. The last may come as a surprise, in that it is typically an LDR format; however, the results are not bad, as Figure 9 shows.
Night shots are another special case. The biggest problem with these images is that noise from the sensors – which shows itself as a colored pattern, often even as very noticeable stripes or wavy lines – emerge in the dark background. With operators that roughen up the image appearance, like Mantiuk '06, you are likely to achieve completely unrealistic structures that are typically not what you would be looking for (Figure 5, top left). The Fattal algorithm is particularly interesting here because it supports noise reduction (with the Noise Reduction slider). Other operators can also achieve good results with the appropriate parameters. Unfortunately, no general rules guarantee very good results; too much depends on the images.
Buy this article as PDF
Competitors get in the game with RHEL without Red Hat
Security researchers have already notified Microsoft; some fixes are available
The company is collaborating with Google and Intel to use Kubernetes as an engine for Fuel
Customers can take a free test drive of SLES for HPC on the Azure Cloud
San Francisco-based chip company announces their first fully open source chip platform.
The whole distro gets rebuilt on glibc 2.3
Ubuntu Vendor tries to solve app packaging and distribution problem across distributions.
Founder of ownCloud launches the Nextcloud project.
Will The Machine change the way future programmers think about memory?