The problem of contrast in SIHDR

How many images do we require for effective HDR in any given situation? I'm going to break away from the purpose of this blog for a moment and consider multiple-image HDR. So let's do a thought experiment. Let's say that, for a 32-bit target space, we take 32 pictures and each one is one f-stop apart. And let's say that we're using a conceptual camera which takes them all simultaneously on, oh, 32 different sensors. Now we dump these 32 pictures into Photomatix or similar and process them onto a 32-bit space. Nirvana, yes? Of course. We guarantee that we have all brightness ranges covered multiple times. Photomatix churns and produces the desired mapping of which, as usual, we can see about 8 or 9 bits worth at any one time.
Oh. Problem.
The range which we really desired to see only covered about 16 bits and now that 16-bits will be tone mapped into about half of the 8 or 9 available tone-mapping target bits. To sum up; the part we were interested in is now occupying about 4.5 bits. Can you say 'low contrast'?
It's exactly this tonal compression that lies at the heart of the 'low-contrast HDR problem'. Is it possible to have too many images for HDR processing? It certainly IS possible.
I call the following 'Consoli's Conjecture'. The optimal number of exposures for multiple-image HDR is approximately equal to (B - 6) / 2. I justify this in the following way. B is the number of brightness ranges over which we desire visible exposure. To make the math easy let's say that we desire 16 brightness ranges. So B is 16. I say that we only need exposures two stops apart. Therefore we don't need 16 exposures for B = 16. But neither do we need them on either end. Let's say that the tail of the lightest and darkest exposures extends to the edges of what's desired and that the lowest three zones of the darkest exposure and the upper three zones of the brightest exposure will give adequate rendering of the dark and light edges of the range. That accounts for the 'minus 6' part of the expression. Therefore, for 16 brightness ranges we have (16 - 6) / 2 or 5 exposures. And these are exposures 2 f-stops apart with the middle exposure centered right in the center of the range of interest. Other people have certainly worked this out; if my readers know more I wish that they would enlighten me.
Of course, all of this assumes a smooth global compressor tone-mapping function. This would be one which would take 16 brightness ranges and smoothly map them on to an 8 bit space. That is, half what we would normally expect 16 exposure zones to require.
It is exactly this that leads to the low-contrast problem in HDR. Here's an example.

 

 

This is a picture of the Badia Tower in Florence and it's much as it came from the camera.  See the disgustingly underexposed expanses on left and right.

I processed this through Photomatix (which I obviously don't own) and that rendered this amazing result:

The right and left sides have opened up amazingly but notice the dramatically lowered contrast in the center; in the tower itself.  It's as though a veil of gauze had been drawn over the scene.  Let's detour a moment and look at the following version which started with the original and just used Photoshop Levels control to bring the right side up to about where it was in the HDR version:

 

Here the right side is about the same as the HDR version but, of course, the center of interest is completely washed out.

    But, in the end for Squinchpix, I didn't use the HDR version.  I used the following version because it was easier using traditional Photoshop techniques to overcome the problem by dividing up the picture space:

 

    

This is it.   I created a brightness map in Photoshop CS3 and used that to select the various areas for brightness adjustments.  It never lost contrast.  Compare it to the others.  A brightness mask is a kind of local tone mapper of the kind you find in HDR software.   One way to overcome the severe contrast problem in HDR is not to use it at all.