HDRMerge - an open-source tool for merging exposures in RAW

[assaft]

This is a tool that I have been using for a week or so and I'm quite happy with the results. It's an open-source project developed by Javier Celaya and can be downloaded from here. I didn't find it being mentioned on this forum so I thought I would post this. It is not specific to micro four thirds in any way but I assume that some of the posters here will find this interesting.

Description (copied)

HDRMerge combines two or more raw images into a single raw with an extended dynamic range. It can import any raw image supported by LibRaw, and outputs a DNG 1.4 image with floating point data. The output raw is built from the less noisy pixels of the input, so that shadows maintain as much detail as possible. This tool also offers a GUI to remove 'ghosts' from the resulting image. Discover more about HDRMerge

Wait... Another HDR program??

Not exactly... Common HDR programs, like Luminance HDR or Photomatix, actually perform two tasks:

• Exposure merging.
• Tone mapping.

Exposure merging consists in taking the best pixels of a set of images with different exposures and obtain an output image with a higher dynamic range than any of the inputs. This is what HDRMerge does. Tone mapping consists in squeezing an HDR image to present it with all its detail in low dynamic range devices, like screens or paper. Usually, as a result, shadows are pulled up and local contrast is enhanced.

Something that many people do not realize is that these two tasks are totally independent from each other. For instance, Luminance allows you to save the HDR image that results from the merging task. Then, you can load it (or any other HDR image) later to apply any tone mapping operator that Luminance implements. Likewise, HDRMerge generates an HDR image that can be later tone-mapped with another program.

Some additional notes

1. The tool can also be executed from a command line and allows to generate 16/24/32bit DNG files extremely fast. As long as ghosting is not a problem, this is the easiest way to go.

2. Photoshop/LR as well as RawTherapee 4.1 support DNG 1.4 files. Therefore all of these tools can be used for the tone-mapping.

3. When opening the generated DNG with LR it doesn't correct the lens distortion. I suspect that HDRMerge doesn't copy the camera profile embedded in the original RAW files. PhotoAcute acts similarly. This is problematic. Regarding RawTherapee, some work on integrating lensfun into it has been started recently. Hopefully soon the distortion of most m4/3 lenses will be auto corrected when developed with RT (I assume that even from DNGs without a lens profile).

4. I don't know how well it deals with alignment issues (as a result of hand shake) and how easy it is to deal with ghosting. I checked the alignment of several hand-held bursts and it looked pretty good.

Example

This is a sunset from yesterday. Three exposures were merged in HDRMerge and then the tone-mapping was done in LR. A noise comparison between the merged file and a development of an ETTR shot is given below.


Final image after merging and tone-mapping


Noise Comparison between the merged file and an ettr shot

 

[Hen3ry]

It uses the enfuse technology which I believe HDRMerge uses.

My first few experiments are very promising.

So easy to use too -- throw in your TIF files (I haven't explored alternatives), click, and it happens.

Cheers, geoff

--
Geoffrey Heard
Down and out in Rabaul in the South Pacific
http://rabaulpng.com/we-are-all-traveling-throug/i-waited-51-years-for-tavur.html

 

[kenw]

Thanks for this! I've been looking for software exactly like this for awhile and have more than once almost started writing a crappy version myself. PhotoAcute already does something very close to this, along with a lot of other features, but something open source I could tweak as needed that was specifically focused on RAW HDR generation is even better.

Way too busy for the rest of the year to play with this or start contributing any code But I've definitely bookmarked!

FYI, I saw you submitted a ticket on github for copying the lens profiles to the output DNG. One possible work around, or at least something easier for the developer to implement... Convert your RW2 or ORF files to DNG before passing them to HDRMerge. That way the lens profiles are already just DNG TIFF tags that can be byte for byte copied to the output DNG without having to deal with the proprietary encoding of the native RAW files. Essentially you just leverage Adobe's already implemented lens profile translator.

In fact, now that I think about it, you could probably even kludge this by copying the correct tag from one input DNG to the output DNG using software that handles modifying tags (I think exiftool can do this but there are probably others). Sounds like the developer is pretty busy right now and this is something you might be able to try on your own as a proof of concept.

Again - thanks for the link!

 

[assaft]

Thanks for this! I've been looking for software exactly like this for awhile and have more than once almost started writing a crappy version myself. PhotoAcute already does something very close to this, along with a lot of other features, but something open source I could tweak as needed that was specifically focused on RAW HDR generation is even better.

Way too busy for the rest of the year to play with this or start contributing any code But I've definitely bookmarked!

FYI, I saw you submitted a ticket on github for copying the lens profiles to the output DNG. One possible work around, or at least something easier for the developer to implement... Convert your RW2 or ORF files to DNG before passing them to HDRMerge. That way the lens profiles are already just DNG TIFF tags that can be byte for byte copied to the output DNG without having to deal with the proprietary encoding of the native RAW files. Essentially you just leverage Adobe's already implemented lens profile translator.

In fact, now that I think about it, you could probably even kludge this by copying the correct tag from one input DNG to the output DNG using software that handles modifying tags (I think exiftool can do this but there are probably others). Sounds like the developer is pretty busy right now and this is something you might be able to try on your own as a proof of concept.

Again - thanks for the link!

 

[Sergei Golikov]

Nice find, thanks for sharing, I have quite a few HDR apps, Oloneo being one, this looks interesting.

Sergei

 

[Timur Born]

Olympus cameras can merge raw images in-camera and you can even combine it with exposure bracketing for easier shooting. There is no auto alignment, though, so you really need to use a tripod. I also assume that it still only uses 12 bit raw files, so the software solution likely offers better result on top of more flexibility.

--

Red flash eyes save lives and eye-sight!

Retinoblastoma - Wikipedia

en.wikipedia.org

 

[assaft]

Olympus cameras can merge raw images in-camera and you can even combine it with exposure bracketing for easier shooting. There is no auto alignment, though, so you really need to use a tripod. I also assume that it still only uses 12 bit raw files, so the software solution likely offers better result on top of more flexibility.

--

Red flash eyes save lives and eye-sight!
http://en.wikipedia.org/wiki/Retinoblastoma

Yes, it is more flexible than Oly's f/w in dealing with alignment issues and ghosting (i.e. subject movement). But for me its main advantage is that it has a raw-to-raw merging that allows me to do the tone-mapping separately in RT/LR. PhotoAcute also supports that but it costs.

 

[kenw]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

 

[assaft]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

I just checked this workflow of converting some ORFs to DNGs using the free converter first and then merging them in HDRMerge; the result is the same - HDRMerge strips the lens corrections information. I added a note about this in the issue tracker. Hopefully the author will find an easy way to support this.

The alternative, as you mentioned in the beginning, is to write a small executable that copies the opcodes from a DNG that has been converted with Adobe's tool. I guess that it's not too much work using Adobe's DNG SDK, but I'm not sure if these opcodes are indeed the right information to copy and whether the correction values are not supposed to be influenced by the merging itself. Does it make sense to assume that as long as the aperture is kept constant and only the shutter speed changes while bracketing - the correction values should stay the same?

By the way, I've seen some posts about running Adobe DNG converter in Linux using Wine, but only when executed without the UI (i.e. in its command-line mode).

 

[Anders W]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

I just checked this workflow of converting some ORFs to DNGs using the free converter first and then merging them in HDRMerge; the result is the same - HDRMerge strips the lens corrections information. I added a note about this in the issue tracker. Hopefully the author will find an easy way to support this.

The alternative, as you mentioned in the beginning, is to write a small executable that copies the opcodes from a DNG that has been converted with Adobe's tool. I guess that it's not too much work using Adobe's DNG SDK, but I'm not sure if these opcodes are indeed the right information to copy and whether the correction values are not supposed to be influenced by the merging itself. Does it make sense to assume that as long as the aperture is kept constant and only the shutter speed changes while bracketing - the correction values should stay the same?

Yes, that assumption makes sense. I wouldn't think that either of the two types of corrections implemented by code embedded in the RAWs (distortion and lateral CA) changes even when you vary the f-stop. Both surely change with the FL for zooms but that might well be it.

I would be interested in knowing how well doing the corrections manually in LR after merging with HDRMerge works out in your experience. I would think that correcting the distortion manually can be accomplished pretty easily with good results since MFT lenses have rather simple distortion patterns (not moustache or other forms of second-order problems). Hopefully the LR checkbox for "remove chromatic aberration" should take care of the lateral CA without trouble too. When merging images that are already tone-mapped (as I currently do using LR/Enfuse) it is, IIRC, better to do the lateral CA correction before than after merging. But since the input as well as output of HDRMerge consists of RAW files, everything hopefully works out well although CA correction can only be performed after merging.

By the way, I've seen some posts about running Adobe DNG converter in Linux using Wine, but only when executed without the UI (i.e. in its command-line mode).

 

[assaft]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

I just checked this workflow of converting some ORFs to DNGs using the free converter first and then merging them in HDRMerge; the result is the same - HDRMerge strips the lens corrections information. I added a note about this in the issue tracker. Hopefully the author will find an easy way to support this.

The alternative, as you mentioned in the beginning, is to write a small executable that copies the opcodes from a DNG that has been converted with Adobe's tool. I guess that it's not too much work using Adobe's DNG SDK, but I'm not sure if these opcodes are indeed the right information to copy and whether the correction values are not supposed to be influenced by the merging itself. Does it make sense to assume that as long as the aperture is kept constant and only the shutter speed changes while bracketing - the correction values should stay the same?

Yes, that assumption makes sense. I wouldn't think that either of the two types of corrections implemented by code embedded in the RAWs (distortion and lateral CA) changes even when you vary the f-stop. Both surely change with the FL for zooms but that might well be it.

Thanks. By the way, I didn't find a way to use exiftool to copy the opcodes. They are not associated with a specific exif tag that I can specify for exiftool to copy. So I think that Adobe's DNG SDK is the best way to copy the correction data.

I would be interested in knowing how well doing the corrections manually in LR after merging with HDRMerge works out in your experience. I would think that correcting the distortion manually can be accomplished pretty easily with good results since MFT lenses have rather simple distortion patterns (not moustache or other forms of second-order problems).

So far I wasn't bothered by the distortion so much and didn't try to correct it in LR. I'll update later if/when I have more experience with the correction.

I took several bracketed sequences using the 45/1.8, 20/1.7, 14/2.5 and 9FE, merged them in HDRMerge and then imported to LR for the tone-mapping. Distortion-wise, I didn't even notice that the images from the 14mm and 20mm are uncorrected until I compared 1:1 crops to see the noise advantage of the merged file. I remember that I noticed that the 14mm shows severe vignetting but didn't realize that it's because the image is uncorrected and therefore it's not cropped. The landscape I posted in the OP is uncorrected and I don't find it disturbing enough to try to correct it. The 45mm and 9mm are not meant to be corrected by design so they are out of the game.

About the tone-mapping, I found it pretty straightforward. Pretty much the same effort I used to spend when processing Enfuse's output.

Hopefully the LR checkbox for "remove chromatic aberration" should take care of the lateral CA without trouble too. When merging images that are already tone-mapped (as I currently do using LR/Enfuse) it is, IIRC, better to do the lateral CA correction before than after merging. But since the input as well as output of HDRMerge consists of RAW files, everything hopefully works out well although CA correction can only be performed after merging.

I have the LaCA correction enabled as part of the import preset so that wasn't a problem. I did notice the familiar strong purple fringe of the 14mm/20mm on Oly bodies and I desaturated it using the defringe tool. Things seem to be straightforward here.

By the way, I've seen some posts about running Adobe DNG converter in Linux using Wine, but only when executed without the UI (i.e. in its command-line mode).

 

[Anders W]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

I just checked this workflow of converting some ORFs to DNGs using the free converter first and then merging them in HDRMerge; the result is the same - HDRMerge strips the lens corrections information. I added a note about this in the issue tracker. Hopefully the author will find an easy way to support this.

The alternative, as you mentioned in the beginning, is to write a small executable that copies the opcodes from a DNG that has been converted with Adobe's tool. I guess that it's not too much work using Adobe's DNG SDK, but I'm not sure if these opcodes are indeed the right information to copy and whether the correction values are not supposed to be influenced by the merging itself. Does it make sense to assume that as long as the aperture is kept constant and only the shutter speed changes while bracketing - the correction values should stay the same?

Yes, that assumption makes sense. I wouldn't think that either of the two types of corrections implemented by code embedded in the RAWs (distortion and lateral CA) changes even when you vary the f-stop. Both surely change with the FL for zooms but that might well be it.

Thanks. By the way, I didn't find a way to use exiftool to copy the opcodes. They are not associated with a specific exif tag that I can specify for exiftool to copy. So I think that Adobe's DNG SDK is the best way to copy the correction data.

So what you said here about half a year ago is not enough to have exiftool copy it?

E-M1 + Panasonic lenses : CA removal works great!

Anders W wrote: Perhaps this is unlikely given that the distortion and LaCa correction parameters are intertwined (distortion correction done differently for different colors). But who knows. indeed - it will be highly unlikely to write such a code that will try to figure out how do pure...

www.dpreview.com

I would be interested in knowing how well doing the corrections manually in LR after merging with HDRMerge works out in your experience. I would think that correcting the distortion manually can be accomplished pretty easily with good results since MFT lenses have rather simple distortion patterns (not moustache or other forms of second-order problems).

So far I wasn't bothered by the distortion so much and didn't try to correct it in LR. I'll update later if/when I have more experience with the correction.

OK. Would appreciate if you checked it out when you find the time. Of course, I can check this myself too by running DCRAW (which doesn't do any distortion correction), importing the results into LR and then check how difficult it is to get it right manually. But I haven't tried doing it yet.

I took several bracketed sequences using the 45/1.8, 20/1.7, 14/2.5 and 9FE, merged them in HDRMerge and then imported to LR for the tone-mapping. Distortion-wise, I didn't even notice that the images from the 14mm and 20mm are uncorrected until I compared 1:1 crops to see the noise advantage of the merged file. I remember that I noticed that the 14mm shows severe vignetting but didn't realize that it's because the image is uncorrected and therefore it's not cropped.

Yes, the distortion correction includes some cropping for reasons that are not yet entirely clear to me. But perhaps it is easier to accomplish decent results that way than by expanding the optical image circle that is sufficiently good to be used.

The landscape I posted in the OP is uncorrected and I don't find it disturbing enough to try to correct it. The 45mm and 9mm are not meant to be corrected by design so they are out of the game.

No, it's not disturbing in that image. On the other hand, the image isn't such that the distortion is easily seen. When it is, then you'd have to correct. As you know, many MFT WA lenses (including zooms at the WA end) have distortion levels of 5% or more and that would show up pretty badly for some subjects.

About the tone-mapping, I found it pretty straightforward. Pretty much the same effort I used to spend when processing Enfuse's output.

If I understand what HDRMerge does correctly, it should be about as straightforward as "developing" a single ETTRd shot in LR. The RAW file you get as a result of the merging should be pretty much the same as that you get from a single ETTRd shot with respect to the RAW ADU levels (or their ratios to one another if the scale is transformed). The only difference should be that the less saturated pixels have much better SNR (better precision, less noise) than in the single ETTRd shot.

Hopefully the LR checkbox for "remove chromatic aberration" should take care of the lateral CA without trouble too. When merging images that are already tone-mapped (as I currently do using LR/Enfuse) it is, IIRC, better to do the lateral CA correction before than after merging. But since the input as well as output of HDRMerge consists of RAW files, everything hopefully works out well although CA correction can only be performed after merging.

I have the LaCA correction enabled as part of the import preset so that wasn't a problem. I did notice the familiar strong purple fringe of the 14mm/20mm on Oly bodies and I desaturated it using the defringe tool. Things seem to be straightforward here.

Sounds good.

By the way, I've seen some posts about running Adobe DNG converter in Linux using Wine, but only when executed without the UI (i.e. in its command-line mode).

 

[assaft]

assaft wrote:
HDRMerge uses LibRaw to open the ORF and exiv2 to copy metadata information (the author replied on github). It sounds like neither LibRaw nor exiv2 can extract the lens profile, so the information cannot be stored in the DNG.

Adobe has a DNG SDK (from which I ran dng_validate to find the opcodes), and I need to see whether it can be used for converting an ORF to a DNG. If so, then as you say - it would be possible to silently convert the ORF to DNG before running HDRMerge and then, I assume, the correction tags will be preserved. Alternatively, the tags can be copied from the DNG created by the SDK to the DNG created by HDRMerge.

It is less sexy than incorporating SDK code but you could also just use the Adobe DNG converter directly. That's usually what I use when I want to look at RAW data and metadata in a non-proprietary format. It's free and has Windows and OSX binaries so it handles most people's needs. But of course HDRMerge is developing on Linux right now and there aren't DNG converter binaries for that!
--
Ken W
See profile for equipment list

I just checked this workflow of converting some ORFs to DNGs using the free converter first and then merging them in HDRMerge; the result is the same - HDRMerge strips the lens corrections information. I added a note about this in the issue tracker. Hopefully the author will find an easy way to support this.

The alternative, as you mentioned in the beginning, is to write a small executable that copies the opcodes from a DNG that has been converted with Adobe's tool. I guess that it's not too much work using Adobe's DNG SDK, but I'm not sure if these opcodes are indeed the right information to copy and whether the correction values are not supposed to be influenced by the merging itself. Does it make sense to assume that as long as the aperture is kept constant and only the shutter speed changes while bracketing - the correction values should stay the same?

Yes, that assumption makes sense. I wouldn't think that either of the two types of corrections implemented by code embedded in the RAWs (distortion and lateral CA) changes even when you vary the f-stop. Both surely change with the FL for zooms but that might well be it.

Thanks. By the way, I didn't find a way to use exiftool to copy the opcodes. They are not associated with a specific exif tag that I can specify for exiftool to copy. So I think that Adobe's DNG SDK is the best way to copy the correction data.

So what you said here about half a year ago is not enough to have exiftool copy it?

http://www.dpreview.com/forums/post/53581159

Exactly. This print of the opcode lists (in the post that you linked to) is from dng_validate - a tool provided by Adobe as part of the DNG SDK. I didn't find a way to copy these opcode lists from one DNG to another using exiftool.

I would be interested in knowing how well doing the corrections manually in LR after merging with HDRMerge works out in your experience. I would think that correcting the distortion manually can be accomplished pretty easily with good results since MFT lenses have rather simple distortion patterns (not moustache or other forms of second-order problems).

So far I wasn't bothered by the distortion so much and didn't try to correct it in LR. I'll update later if/when I have more experience with the correction.

OK. Would appreciate if you checked it out when you find the time. Of course, I can check this myself too by running DCRAW (which doesn't do any distortion correction), importing the results into LR and then check how difficult it is to get it right manually. But I haven't tried doing it yet.

I took several bracketed sequences using the 45/1.8, 20/1.7, 14/2.5 and 9FE, merged them in HDRMerge and then imported to LR for the tone-mapping. Distortion-wise, I didn't even notice that the images from the 14mm and 20mm are uncorrected until I compared 1:1 crops to see the noise advantage of the merged file. I remember that I noticed that the 14mm shows severe vignetting but didn't realize that it's because the image is uncorrected and therefore it's not cropped.

Yes, the distortion correction includes some cropping for reasons that are not yet entirely clear to me. But perhaps it is easier to accomplish decent results that way than by expanding the optical image circle that is sufficiently good to be used.

The landscape I posted in the OP is uncorrected and I don't find it disturbing enough to try to correct it. The 45mm and 9mm are not meant to be corrected by design so they are out of the game.

No, it's not disturbing in that image. On the other hand, the image isn't such that the distortion is easily seen. When it is, then you'd have to correct. As you know, many MFT WA lenses (including zooms at the WA end) have distortion levels of 5% or more and that would show up pretty badly for some subjects.

About the tone-mapping, I found it pretty straightforward. Pretty much the same effort I used to spend when processing Enfuse's output.

If I understand what HDRMerge does correctly, it should be about as straightforward as "developing" a single ETTRd shot in LR. The RAW file you get as a result of the merging should be pretty much the same as that you get from a single ETTRd shot with respect to the RAW ADU levels (or their ratios to one another if the scale is transformed). The only difference should be that the less saturated pixels have much better SNR (better precision, less noise) than in the single ETTRd shot.

Yes, that's how it feels. The files look somewhat dark when imported but I can easily boost the exposure with almost no penalty of noise. I compared several merges to an ETTRd shot and things look as expected. I also compared to PhotoAcute's 32bit exposure merge and the results look the same in terms of noise levels. Alignment and ghosting are treated differently but I haven't noticed a problem with HDRMerge so far..

Hopefully the LR checkbox for "remove chromatic aberration" should take care of the lateral CA without trouble too. When merging images that are already tone-mapped (as I currently do using LR/Enfuse) it is, IIRC, better to do the lateral CA correction before than after merging. But since the input as well as output of HDRMerge consists of RAW files, everything hopefully works out well although CA correction can only be performed after merging.

I have the LaCA correction enabled as part of the import preset so that wasn't a problem. I did notice the familiar strong purple fringe of the 14mm/20mm on Oly bodies and I desaturated it using the defringe tool. Things seem to be straightforward here.

Sounds good.

By the way, I've seen some posts about running Adobe DNG converter in Linux using Wine, but only when executed without the UI (i.e. in its command-line mode).

 

[Hen3ry]

Bracketeer uses the same merge technology as HDRMerge, I believe -- enfuse.

When I merge TIFF files, the EXIF is retained, so I can apply PTLens to the resultant image and make distortion and CA corrections as normal.

Cheers, geoff

 

[kenw]

assaft wrote:
Thanks. By the way, I didn't find a way to use exiftool to copy the opcodes. They are not associated with a specific exif tag that I can specify for exiftool to copy. So I think that Adobe's DNG SDK is the best way to copy the correction data.

So what you said here about half a year ago is not enough to have exiftool copy it?

http://www.dpreview.com/forums/post/53581159

Exactly. This print of the opcode lists (in the post that you linked to) is from dng_validate - a tool provided by Adobe as part of the DNG SDK. I didn't find a way to copy these opcode lists from one DNG to another using exiftool.

Yeah so now that you say it I recall having no luck getting exiftool to modify fields it didn't know about - even if you could get it to display them. For my IR converted G1 ideally I need to delete/disable the camera provided Lat CA corrections since they of course make no sense for IR and actually add CA to image. I couldn't get exiftool to modify or remove those tags even though I could get it to display them. Had to write a short program to do it myself.

By the way the -htmldump option on exiftool is super useful if you haven't used it before.

Oh, and as Anders said I recall the various distortion/CA profiles do not change with aperture. Certainly they shouldn't need to change based on second order aberration theory! I think they might change with focus if I remember testing them correctly, but of course that isn't an issue for HDR merging. You can of course run a quick test yourself using exiftool or the SDK to examine the files.
--
Ken W
See profile for equipment list

 

[kenw]

Bracketeer uses the same merge technology as HDRMerge, I believe -- enfuse.

When I merge TIFF files, the EXIF is retained, so I can apply PTLens to the resultant image and make distortion and CA corrections as normal.

HDRMerge is different actually. Enfuse/Bracketeer actually do a form of tone mapping - their output is an LDR file. It just uses a nice and subtle form of tone mapping that doesn't look like the overprocessed tone mapping people often get out of things like Photomatix. HDRMerge on the other hand never applies any sort of tone mapping, its output is a floating point HDR file.

Photoshop's "Merge to HDR" can be used to produce a HDR TIFF file from brackets because it gives you the option to skip tone mapping. Photomatix actually has a LR plugin that does this as well leaving off their tone mapper and producing a HDR file rather than the typical Photomatix tone mapped LDR file. PhotoAcute and HDRMerge do the same thing except they create a HDR RAW file rather than TIFF.
--
Ken W
See profile for equipment list

 

[Hen3ry]

Cheers, geoff

 

[assaft]

This is an update about the usability of HDRMerge for m4/3 shooters.

Background

HDRMerge is a tool that I found very useful and easy to integrate into my workflow. This is mainly because it supports RAW->RAW exposure merging without tone mapping, and because it has very good automatic alignment for hand-held work.

In a way, this is a pretty powerful combination of features: by merging exposures the user benefits from files with a wider dynamic range compared to what his/her camera can capture, and by staying in the RAW domain and skipping tone mapping (s)he still has the full control over the development process. As a result, the merged file is a high dynamic range file, as if it was captured by a camera with a wider dynamic range, and it can be processed in the same that a regular camera raw file is processed. This prevents the merged file from acquiring any kind of ‘HDR look’, not to mention the surreal look that is sometimes associated with HDR processing.

The main downside of exposure merging is the risk of ghosting. HDRMerge provides a graphical user interface for manually selecting the source layer in areas of moving objects.

Problem

However, the current version of HDRMerge (0.45) suffers from a major limitation: it does not copy the lens profile that is embedded in camera RAW files (ORF/RW2) to a merged DNG file. Therefore the merged file is not corrected for distortion when it is opened in a RAW converter (e.g. Photoshop/Lightroom). Since many m4/3 lenses are designed to be software corrected, it is particularly important to preserve the lens profile when merging files that were captured with such lenses.

My goal was to find a method to preserve the lens profile when merging. In addition, I looked for a way to integrate the merging process into Lightroom.

Solution

The main problem is solved by using a patch for exiv2. The patch copies the lens correction data from an input file to the merged file. Note, however, that the input files (ORF/RW2) have to be converted to DNG first, and therefore a script was prepared to automate this process.

As for the integration with Lightroom, the plugin Run Any Command by Jeffrey Friedl was found suitable for the job. It can be configured to run the merging scripts with the files selected in LR’s Develop module.

Photoshop users can run the merging script directly from the command line and then open the merged file for processing.

Package

The solutions described above are included in this package. A PDF explains how to use the scripts and how to configure the plugin for Lightroom.

It is currently supported only on Windows-based machines but can be ported to Linux/Mac in the future. The PDF explains this.

I will use this thread to post updates.

Thanks to Anders W. for reviewing the PDF and for experimenting with the scripts and plugin.

 

[assaft]

Package

The solutions described above are included in this package. A PDF explains how to use the scripts and how to configure the plugin for Lightroom.

It is currently supported only on Windows-based machines but can be ported to Linux/Mac in the future. The PDF explains this.

I will use this thread to post updates.

Thanks to Anders W. for reviewing the PDF and for experimenting with the scripts and plugin.

PhotoAcute, just like HDRMerge, does not preserve the lens profile embedded in the RAW files that it processes.

I noticed that it has an option to correct image geometry but it seems to rely on an internal profile system targeting specific body + lens combinations. I didn't manage to use it for sets taken with the E-M10 + 20/1.7.

An alternative approach is to use the scripts from the package attached above. Using it, a lens profile can be copied to the DNG file that PhotoAcute produces. As a result, the DNG will be corrected by the RAW converter that opens it.

The workflow is this:

1. Use convert.bat to convert a list of RAW files (ORF/RW2) to temporary DNG counterparts.

2. Run PhotoAcute on the DNG files and produce a new one.

3. User sync.bat to copy the lens profile from an input DNG file to the one produced by PhotoAcute.

4. Delete the temporary DNG files.

5. Open the new DNG file in a RAW converter for development.

This workflow can also be adapted to software other than PhotoAcute.

 

[Anders W]

This is an update about the usability of HDRMerge for m4/3 shooters.

Background

HDRMerge is a tool that I found very useful and easy to integrate into my workflow. This is mainly because it supports RAW->RAW exposure merging without tone mapping, and because it has very good automatic alignment for hand-held work.

In a way, this is a pretty powerful combination of features: by merging exposures the user benefits from files with a wider dynamic range compared to what his/her camera can capture, and by staying in the RAW domain and skipping tone mapping (s)he still has the full control over the development process. As a result, the merged file is a high dynamic range file, as if it was captured by a camera with a wider dynamic range, and it can be processed in the same that a regular camera raw file is processed. This prevents the merged file from acquiring any kind of ‘HDR look’, not to mention the surreal look that is sometimes associated with HDR processing.

The main downside of exposure merging is the risk of ghosting. HDRMerge provides a graphical user interface for manually selecting the source layer in areas of moving objects.

Problem

However, the current version of HDRMerge (0.45) suffers from a major limitation: it does not copy the lens profile that is embedded in camera RAW files (ORF/RW2) to a merged DNG file. Therefore the merged file is not corrected for distortion when it is opened in a RAW converter (e.g. Photoshop/Lightroom). Since many m4/3 lenses are designed to be software corrected, it is particularly important to preserve the lens profile when merging files that were captured with such lenses.

My goal was to find a method to preserve the lens profile when merging. In addition, I looked for a way to integrate the merging process into Lightroom.

Solution

The main problem is solved by using a patch for exiv2. The patch copies the lens correction data from an input file to the merged file. Note, however, that the input files (ORF/RW2) have to be converted to DNG first, and therefore a script was prepared to automate this process.

As for the integration with Lightroom, the plugin Run Any Command by Jeffrey Friedl was found suitable for the job. It can be configured to run the merging scripts with the files selected in LR’s Develop module.

Photoshop users can run the merging script directly from the command line and then open the merged file for processing.

Package

The solutions described above are included in this package. A PDF explains how to use the scripts and how to configure the plugin for Lightroom.

It is currently supported only on Windows-based machines but can be ported to Linux/Mac in the future. The PDF explains this.

I will use this thread to post updates.

Thanks to Anders W. for reviewing the PDF and for experimenting with the scripts and plugin.

You are welcome! But above all, I think we should all thank you very much for your programming efforts, the associated documentation and for making it all available to the rest us. That's what I call community service.