Love it or hate it, HDR is here… and it’s on Linux, too

These days, it is hard to avoid HDR when you are interested in photography. Just for the record, High Dynamic Range is a way to combine different exposures of the same image: you end up with an image that has a wider range of shadow and highlight that what you normally see on printed paper or on your monitor. You then rearrange this extra dynamic to fit into a file that you can see on your monitor or print.

The result is an image that has a lot of details in both shadows and highlights – in my opinion, most of these images look very unnatural (not to say ugly) and very rarely do I come across “good taste HDR”. Like every post-processing, it is only when you don’t notice it that it is done right. Other people, of course, will disagree and process every single one of their pictures in HDR.

To know more about HDR, have a looks at the wikipedia article as well as the HDR Flickr gallery.

Although I won’t cover HDR in all details, I decided to give it a go out of curiosity, especially since Linux does it – via Qtpfsgui, that’s right GUI means: “no command line” 🙂

Getting the images

You need to start with 3 (or more) bracketed version of the same view. You need to use a tripod and vary the shutter speed since bracketing a hand-hold picture will probably produce misaligned images. Although you can realign them in software, it doesn’t work too well in practice often resulting in a blurry final result.

An (easier) way is to process a RAW file with -1, 0 and +1 exposure compensation. I decided to go that way and had a RAW file processed into JPEG 3 times from UFraw in the command line – that avoids alignment issues as well. Although there is a way to manually enter this information, Qtpfsgui will process your files more easily if they include exifs.

Creating an HDR file

Once you have these files, you can fire Qtpfsgui – there is a detailed documentation in their sourceforge wiki.

Creating an HDR file is dead easy, just click on (surprise, surprise) create HDR and go through a few steps; if your files have proper exif datas and are aligned, this is straightforward – it basically boils down to choosing the files you want to use to produce your HDR image. You can also manually align your files if needed. I left all the settings to default and clicked next a few times. This is the result:

qtpfsgui_hdr_image.jpg

Save your image as test.exr (an open source HDR format).

ToneMapping

Now this is where the good fun starts. Tone Mapping is about squeezing back the HDR image to a “standard” dynamic range, ie one you can show on your monitor or print on paper. When clicking the ToneMap button, you are presented with a new window including the Tone mapping Panel where you to chose the image size you want (start with small sizes, since tonemapping is CPU intensive), the pregamma setting as well as your tonemapping algorithm and its settings. Once you have made your choice, click apply and you get a window with your image:

qtpfsgui_tone_mapping.jpg

The next step is to adjust the levels (like in any image manipulation program) – this step makes quite a difference in the final output:

qtpfsgui_levels_adjust.jpg

I created an image with each of the different tonemapping algorithms (settings as defaults) and then saved another version with the levels adjusted – if I could get a usable output from the previous step. This may look a bit tedious, but it shows how much difference there can be in the final result of an HDR image. In adjusting the levels, I just tried to get a pleasing output: saturated and without burning the whites (too much). By the way, Open Source Photography has a page describing the different algorithm in more detail.

Ashikhmin algorithm (no level adjusted version):

neige_pregamma_1_ashikhmin_-eq2_local_05.jpg

 Drago algorithm:

neige_pregamma_1_drago_bias_085.jpg
neige_pregamma_1_drago_bias_085_adjusted.jpg

Durand algorithm (no level adjusted version)

neige_pregamma_1_durand_spatial_8_range_04_base_5.jpg

Fattal (sic!) algorithm

neige_pregamma_1_fattal_alpha_01_beta_08_saturation_1_noiseredux_0.jpg
neige_pregamma_1_fattal_alpha_01_beta_08_saturation_1_noiseredux_0_adjusted.jpg

Mantiuk algorithm

neige_pregamma_1_mantiuk_contrast_mapping_03_saturation_factor_08.jpg
 neige_pregamma_1_mantiuk_contrast_mapping_03_saturation_factor_08_adjusted.jpg

Pattanaik algorithm

neige_pregamma_1_pattanaik00_mul_1_autolum.jpg
neige_pregamma_1_pattanaik00_mul_1_autolum_adjusted.jpg

Reinhard 2002 algorithm

neige_pregamma_1_reinhard02_key_018_phi_1.jpg
neige_pregamma_1_reinhard02_key_018_phi_1_adjusted.jpg

Reinhard 2004 algorithm

neige_pregamma_1_reinhard04_brightness_-10_chromatic_adaptation_1_light_adaptation_0.jpg
neige_pregamma_1_reinhard04_brightness_-10_chromatic_adaptation_1_light_adaptation_0_adjusted.jpg

Conclusion HDR or Not?

My favorite output is Reinhard04 – I think it keeps the white unburnt while allowing a high saturation of the image and maintaining a relatively natural overall look. So I had a more careful processing of my image using this algorithm, and here is the HDR result which I like most for this image:

neige_hdr.jpg

For comparison’s sake, here is the same image processed classically (with RawStudio) from a RAW file:

neige_raw.jpg

I thought this image would be a good candidate for HDR since it has snow that needs to be very white without burning (I didn’t burn it when shooting, yeah!) with a lot of color nuances up to pitch dark (for the trees).

And indeed, when comparing the classical version to the HDR one side by side my great certainty from the beginning of this entry starts to fade: I have this feeling that the “truth” is somewhere between the two versions…

Let’s go back to trying more things, different algorithms 🙂

9 Responses to Love it or hate it, HDR is here… and it’s on Linux, too

  1. greywulf says:

    Good post.

    I became very hooked on HDR photography a few years ago, as a quick search on my blog shows. Most of those shots were created using Photomatix Pro for Windows. In the end though, I wrote a short script (info here) how to automate it all in Linux the easy way. That’s what I use now when the HDR bug bites again.

    I found HDR works best if you’ve got lots of blue sky and photogenic clouds in the shot. That gives the biggest “wow” for your buck 🙂

  2. Felix Hagemann says:

    Interesing comparison of the different algorithms. I also never liked the artificial looking results from tonemapping. If you are just interested in combining several exposures into a pleasing, natural looking LDR, then you should definitely have a look at enfuse:
    http://wiki.panotools.org/Enfuse

    Unfortunately there is no official release yet, so you have to compile your own cvs checkout, but I promise: It’ s worth the trouble.

    Felix

  3. jan says:

    enfuse is also available from the hugin repositories (for fedora: http://bugbear.blackfish.org.uk/~bruno/apt/fedora/linux/) for the current testing versions.

  4. jcornuz says:

    Hi there,

    Now that you mention it, I remember reading about Enfuse… somewhere. I’ll look into it when I get a chance. This looks really interesting – thanks for the tip.

    Take care,

    Joel

  5. beka says:

    From http://www.hdrsoft.com/resources/dri.html:

    Can’t I just create the exposures from one RAW file?

    Not really. Your RAW file contains data captured by the sensors for only
    one exposure. The total dynamic range you can reconstruct from one photo
    converted with different exposure settings can never be more than the
    dynamic range captured by your camera, and this is rather limited (see
    above).

    When you are using only one exposure to capture the scene, your RAW file
    is already your HDR image. Converting the RAW file to images with
    different exposure levels is a bit like slicing the dynamic range of the
    RAW into several parts. Combining the parts back into an HDR image will
    at best re-produce the dynamic range of the initial RAW file.

    That said, if you are using a good RAW converter to derive fake
    exposures from a single RAW file, you will probably notice that the HDR
    image created from the fake exposures shows more dynamic range than the
    pseudo-HDR image obtained by converting the single RAW file directly.
    This is because your RAW converter includes a good noise reduction
    function, and this has an important effect on the dynamic range. You RAW
    converter may also include the ability to continue to retrieve
    highlights details when one or two of the color channels have already
    reached saturation.

    So, a good RAW converter includes functions designed to optimize the
    dynamic range retrieved from the raw sensor data, but this does not
    change the fact that the dynamic range of a RAW file is limited to one
    exposure only. Unless the dynamic range of your scene is low, you will
    need to take more than one exposure to create an HDR image of the scene.

  6. NewMikey says:

    Thanks! I use QTPFSGUI sometimes but I found the results unsatisfactory and unrealistic until now. It seems I can only blame myself for that as I neglected to adjust the levels as per your example.

    Never too old to learn a new trick!

  7. jcornuz says:

    Hi there,

    @Beka: Thanks for you input. I thought HDR was a chance to exploit the extra dynamic range that a RAW file offers (vs JPEG). Apparently, this modus operandi is accepted in the Flickr HDR group but it is not the “proper thing”. Good to know – let’s go back to tripod.

    @Mike: I can only agree with your last words (see the above post 🙂 )

    Take care,

    Joel

  8. Paul says:

    Hi.
    I would to write here about an open-source program written by me. This software is a LDR tonemapper. Unlike HDR tonemapping, this requires a single jpeg file, and of course, it cannot reproduce the wide range of the HDR pictures. But many pictures processed by this program looks much better.

    You can download it from here:
    http://zynaddsubfx.sourceforge.net/other/tonemapping/

    Here is are some screenshots and example images (original and processed).

    Here is a time-lapse video with images processed with this program:

    (and you can see on that page the video with original images).

    Paul

Leave a comment