The blurring, the extracting of pixels "greater than [arbitrary number]", and the mixing of the blurring image back over the original... isn't HDR, that's bloom.

HDR makes bloom better, so most HDR demos will also implement bloom. But this concept you're describing is not HDR. It's bloom. You're describing bloom, which can be implemented in either HDR or LDR. You don't need HDR to implement this concept.


If you ignore all this blurring/mixing stuff for a moment ---
HDR is high-dynamic-range, it's the concept of storing real luminance/irradiance data in your frame buffer, instead of "colours". In the real world, the sky is 10,000 times brighter than an object in a day-time shadow... so in a HDR renderer, we might write the number 10000.0f into the frame-buffer when drawing the sky, and write the number 1.0f for an object in shadow.

HDR is a term that comes from photography, where they've been capturing images with very large differences in brightness for a long time.

This raw HDR data can't be directly displayed though, because your monitor only supports values in the range of 0 to 1. So by using another concept called 'tone-mapping', you can convert this high-range (usually floating point) image, into a regular 8-bit-per-channel image that you can display. These tone-mapping algorithms mimic the human eye, which can easily look at objects that are thousands of times brighter than each other at the same time -- usually some kind of exponential-looking curve is involved in the mapping process.

Notice blurring, or extracting bright pixels, etc, doesn't come into it. HDR is simply the concept of storing a large range of brightness values, and it's paired with the concept of tone-mapping, which lets you convert that large range into an LDR image.


Now, coming back to bloom... it goes hand in hand with HDR, because this "blurring of bright pixels" concept is a trick that fools your brain into thinking a pixel is brighter than it really is. We can't display the value of 10,000 to the monitor, but if we map it to 1.0f instead, and also blur it, the brain will perceive it to be brighter than a 1.0f pixel that doesn't also have blur. Meaning, bloom lets us better convey these really bright pixels, even though we can't display them properly.

[quote name='way2lazy2care' timestamp='1312901321' post='4846709']To my understanding basically HDR is just brightening and darkening parts of your image based off an average brightness level for the whole picture so you can enhance the range of brightness/darkness that you can experience beyond what you can display on screen.

My question is, why use the CS? Couldn't you just have the hardware generate the mipmap levels, and the last mipmap level, 1 pixel will contain the average illuminance?
[/

Also does anyone agree the HDRToneMappingCS11 looks kind of weird when you move the camera around? The color intensity changes unnaturally in my opinion.

In theory, a parallel reduction implemented with shared memory in a compute shader should have significantly less memory reads and writes compared to generating a mip chain. In practice it depends on how well the compute shader is implemented since there are all kinds of subtle performance pitfalls.
[/quote]

I see. I guess I sort of assumed that since graphics hardware has had auto mipmap chain support for a while it would be quite good at it, and perhaps optimized for it. I'll have to do some comparisons if I get time.

In theory, a parallel reduction implemented with shared memory in a compute shader should have significantly less memory reads and writes compared to generating a mip chain. In practice it depends on how well the compute shader is implemented since there are all kinds of subtle performance pitfalls.

I see. I guess I sort of assumed that since graphics hardware has had auto mipmap chain support for a while it would be quite good at it, and perhaps optimized for it. I'll have to do some comparisons if I get time.
[/quote]

The whole luminace mip-map thing is the most obvious thing and what I first thought of, I'd be interested to see your results. I'm particularly lazy when it comes down to it I, too looked at the demo when I first started looking at HDR but found the code needed to utilise compute shaders not hard to understand particularly, but certainly more complex.

I made a quick sample for my blog that calculates the average luminance using a compute shader reduction, and on my hardware (AMD 6950) it's about twice as fast as GenerateMips for a 1024x1024 luminance map. I'd be interested to see what the results are on other hardware, if you want to try it out. At the very least it's a better starting point than the SDK sample if you're targeting FEATURE_LEVEL_11 hardware.