[HDR-photo] Real-World example (Was: Alignment)

[Bernhard Vogl]

Hello Ferrell,

> When you wrote about the Fuji in extended mode, are you saying both RAW
> and Jpeg are converted with the camera respose curve.

For JPEG, there are basically 4 different "response curves" available:
1- slide film simulation (looks like Fujichrome)
2- negative film simulation
3- auto dynamic range
4- full dynamic range (that's what i almost exclusively use)

RAW is basically the same as on every other camera with the slight but important difference, that the 2 photosites are still separated. So you can build your own response curve and DR - but you are still bound to the sRGB output space with (all) the RAW converter(s).

> In general, jpeg is 
> converted using a camera response curve. You can create a camera response 
> curve using Ward's HDRshop although I don't think you can bring it into 
> photomatix.  

I actually thought of that, but as you said, i don't know a method to import a response curve into Photomatix, and HDRShop's HDR creation is very basic with no smooting of per-pixel misalignment of the bracketed images. Actually you can use HDRShop well to find mis-alignments because of the enormous artefacts...  ;-)

> Regarding RAW>jpeg we all know there is a response curve 
> involved but there is a little discussed response curve that takes place 
> >from real world>pixel value. Doesn't HDR have to unravel that also?

I'm not sure what you mean.
In the first place i expected that camera curve calibration won't touch the "medium brightness" but in fact it does. Maybe Geraldine listens and can explain some basics about response curve calibration?
That's the point where i think, that the "real world brightness" EXIF information could help to smooth out such things a little.

> 
> Also AutoPano Pro (APP) allows you to stitch the exposures and sections in
> sort of a two dimensional array. The exposures are stacked vertically and 
> the sections horizontally. It uses SIFT technology for the contol points 
> which is very reputable. Also you can save the stitched exposures as 16-bit
> tiff's for merging and TM'ing in another program or you can merge and Tm
> in APP. The TM operator is however, a global operator.
> You may be able to get the "cripsyness" that your earlier work didn't 
> have with STITCH>hdr>Tonemap using APP and SIFT technology.

I personally haven't worked much with APP. If you have good knowledge in APP stitching, i'd like to ask you to process the "real world examples" with APP and show the resulting HDR! 

> 
> The three methods for HDR pano varies when the stitching is done. It can
> be first, second or third:
> 
> STITCH>hdr>Tonemap
> hdr>STITCH>Tonemap
> hdr>Tonemap>STITCH
> 
> Each stage, stitching, merging and tone mapping involves blending and thus
> creates a potential for error in subsequent stages. A logical argument
> could 
> be made that the process that involves the smallest amount of blending 
> should take place first, followed by the second amount of blending and 
> ending with the most drastic blending of the three. Stitching the
> individual 
> exposures -2EV 0 +2EV has the lowest impact on the tonal distribution of
> the 
> image set. The next would be 32-bit HDR stitching followed by stitching of
> the single tone mapped images.

You could also argue the other way round: The brackets are parts of a whole and it should be your primary aim to put the pieces together (switch to HDR). This is the most capable and versatile image format and you should stay there as long as you could, to keep quality up.
If you replace the word HDR with RAW, you may understand what i mean  :-)

If you (en-/smart-)blend the LDR images, you are touching the response curve of your images even more drastically than the Fuji camera would ever dare to. Besides that, every blending software tries to smooth out ghosts and artifacts which is valid for a single LDR panorama, but definitely not what you want to happen in an image set for HDR creation.

The reason why i think that the other methods are also valid, is, because they need less computational power.

So I'd sort the methods like this:

HDR -> Stich -> tonemap
HDR -> tonemap -> Stitch
Stitch -> HDR -> Tonemap

Best regards
Bernhard