Lens correction before or after HDR

[spotmeter]

I recently shot some church interiors with the new Canon 25mm TS_E II and imported the photos into Lightroom.

Because the dynamic range is so great inside the churches, I shot 3 or 4 exposures to capture data in the highlights and shadows.

My question is:  Should I use the lens correction module in LR to correct the exposures before combining them in Photomatix, or should I correct for lens distortion after combining them?

Thanks.

[dreed]

I recently shot some church interiors with the new Canon 25mm TS_E II and imported the photos into Lightroom.

Because the dynamic range is so great inside the churches, I shot 3 or 4 exposures to capture data in the highlights and shadows.

My question is:  Should I use the lens correction module in LR to correct the exposures before combining them in Photomatix, or should I correct for lens distortion after combining them?

If I'm going to HDR images then the HDR step is done after I've reset various LR adjustments and before I make any tweaks (such as lens correction) so that the probability of everything being correctly aligned is greatest.

It's a pity that currently HDR cannot be done on raw images.

[RFPhotography]

Since all the corrections can be synced in LR and given that for a specific set of images the corrections should all be the same, doing the lens corrections in LR (or ACR) should be fine.  I'd also suggest doing any CA correction, WB adjustment and dust spotting before sending the images into the HDR cooker.

If you're using the LR plugin for PM, any changes you make to the raw file will be incorporated on the conversion to TIFF before merging in PM.  If you're loading into PM directly from PM then you're best to convert the raw files to TIFF and load those TIFFs into PM.  The raw converter in PM doesn't do the best job.

It's a pity that currently HDR cannot be done on raw images.

You can send RAW images into most every HDR applications.  HDR applications have a built in raw converter.  If you mean being able to send the images into HDR-land without any conversion, that's just not possible.  Raw isn't an image file format.  There has to be some form of conversion done into an image format at some point.

[hjulenissen]

You can send RAW images into most every HDR applications.  HDR applications have a built in raw converter.  If you mean being able to send the images into HDR-land without any conversion, that's just not possible.  Raw isn't an image file format.  There has to be some form of conversion done into an image format at some point.

I believe that one could synthesize a HDR raw file from several bracketed raw exposures. Problem is, you would only gain some DR/noise advantage until you hit the ceiling on inherent 12/14/16-bit file format limitations. Now, if there are any raw converters out there that accepts 32-bit int or 32-bit float for each sensel (dcraw?), I believe that you could make a simple front-end for assembling bracketed exposures without ever doing debayer etc.

It would be kind of neat to continue using Lightroom at its best (direct internal edits of "raw" files), but have those raw files contain a stop or more DR than what my camera is able to do in a single shot. That would probably only be a nasty band-aid until Lightroom (hopefully) comes with bare-bones HDR and stitching really soon.

Now, if you need any spatial realignement or anything else that operate on 2 or more (sub)-pixels (spatially or color-wise) this approach becomes unrealistic.

-h

[dreed]

You can send RAW images into most every HDR applications.  HDR applications have a built in raw converter.  If you mean being able to send the images into HDR-land without any conversion, that's just not possible.  Raw isn't an image file format.  There has to be some form of conversion done into an image format at some point.

Why shouldn't it be possible to HDR the data that comes of the sensor, before it is converted into an image?

After all, isn't HDR really just about replacing parts of the data set that is not useful with data that is useful?

Why should it matter if the data comes from a JPEG file, a TIFF file or a raw file?

Each file is just a different way of representing a particular color value for a pixel.

When it comes to raw files, it shouldn't be necessary to demosaic the image in order to know that a 20x20 square in one picture that is all black can be replaced by the very same square in another picture that has values that are non-zero.

The real question is, would HDR render a different image if it used raw data instead of data from an image that had been converted from raw?

The answer to that might be that the difference is insignificant and that it boils down to rounding in the image conversion/HDR process and thus there's nothing of value to gain by doing HDR on raw data vs TIFF.

[kwalsh]

If the shots were tripod mounted then it shouldn't matter much which order you do it in.

If they were hand-held definitely do lens correction before HDR merge.

Check out the software package PhotoAcute if interested in HDR straight from RAW back to RAW.

Ken

[RFPhotography]

It might be possible but I'd think there'd be some complications.  The HDR software could probably do the merge just on the basis of non-demosaiced brightness values.  HDR software already reverses out the tone curve of an embedded colour profile to get back to linear data so there's not much benefit from that standpoint.  But then what does the output become?  How does it get tonemapped?  When does it get turned into an actual image file with the colour information included? 

h, I don't believe dcraw can handle 32 bit images.  As far as I'm aware, it only reads raw files.

Ken, is there any more information available on that raw in/raw out claim?  There's, unsurprisingly, not much detail on their website that I can find.  To say I'm skeptical would be an understatement.  My guess is that what the software does is convert to some type of image format, do the processing then out put to DNG.  If I'm right, then it really isn't raw in/raw out.

[kwalsh]

Ken, is there any more information available on that raw in/raw out claim?  There's, unsurprisingly, not much detail on their website that I can find.  To say I'm skeptical would be an understatement.  My guess is that what the software does is convert to some type of image format, do the processing then out put to DNG.  If I'm right, then it really isn't raw in/raw out.

Their software operates in a lot of different modes so it is hard to say exactly what is applied for each feature. 

In some modes, such as averaging, it clearly isn't doing anything beyond averaging multiple exposures which would be true RAW in and RAW out.  In tripod mounted HDR mode where it doesn't have to interpolate it similarly only operates on RAW channels - here it isn't performing a tone map, just expanding the dynamic range by choosing and averaging optimal exposures.

In aligning modes and super-resolution modes I'm not sure.  Are they interpolating the RAW channels independently?  That certainly could work but I don't know for sure what they actually do.  I don't use those modes so I haven't experimented.

What I do know is that in many modes it is true RAW in RAW out.  Only the noise profile changes between a single input file and a processed multiple exposure.  Color processing and detail are identical so clearly they've done no demosaicing in those modes to produce a "pseudo-raw" file - it is true RAW near as I can tell from experiments.

They have a free watermark trial so you can experiment yourself.

[RFPhotography]

It's unusably slow.  8 minutes to process 5 D700 raw images.  It's not raw in/raw out.  It appears to be as I suspected.  Raw in, images rendered, dng out.  And the result is butt ugly.

[NikoJorj]

I believe that one could synthesize a HDR raw file from several bracketed raw exposures. Problem is, you would only gain some DR/noise advantage until you hit the ceiling on inherent 12/14/16-bit file format limitations.

Zero Noise does that and produces 16bits DNG files : http://www.guillermoluijk.com/article/virtualraw/index_en.htm
And I'd say the limit of a 16bits file is rather far away, ie you shoudn't hit it with 4EV or 6EV-spaced captures (warning : wild uneducated guess inside).