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:
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:
The next step is to adjust the levels (like in any image manipulation program) – this step makes quite a difference in the final output:
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):
Drago algorithm:
Durand algorithm (no level adjusted version)
Fattal (sic!) algorithm
Mantiuk algorithm
Pattanaik algorithm
Reinhard 2002 algorithm
Reinhard 2004 algorithm
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:
For comparison’s sake, here is the same image processed classically (with RawStudio) from a RAW file:
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 🙂
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 🙂
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
enfuse is also available from the hugin repositories (for fedora: http://bugbear.blackfish.org.uk/~bruno/apt/fedora/linux/) for the current testing versions.
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
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.
Hey,
such a great job, you made me realy curious!
It isn’t realistic, but over-realistic!
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!
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
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