I think there are 2 issues with your image:

• First the gamma seems off, due to the shift in colors (e.g. the tan colored rocks turn more orange in your image). I'd check that you are using the right texture format for the image (a linear one probably, e.g. 16F), and also are doing the correct gamma conversion to sRGB on the final output after sampling the texture. It looks like you are getting an unwanted sRGB→linear conversion on sampling the texture, which is wrong because HDR is already linear.
• The other issue is the lack of tone mapping, which results in the bright white clipped areas in the sky. In the other thread I posted some shader code to do the mapping from HDR→LDR.

Tone mapping curves have a shape similar to this, which maps an input in [0,infinity] to [0,1]. This is the exponential tone mapping operator I posed in the other thread:

There are other possibilities (e.g. Reinhard, ACES), but this is the one I think looks the best. It's important to note that these tone mapping operators all have different slopes, which can confuse comparisons. To avoid this, I try to normalize the operator so that an input of 1.0 produces an output of 0.8. This makes it look about the same as a LDR rendering, and makes comparisons more meaningful.

Josh Klint said:
It's RGBA 32 float, so 1.0,1.0,1.0 equals 255,255,255

That doesn't make sense. 32-bit float shouldn't have a maximum of 255, and is probably calibrated so that 1.0== white, not 255==white like in 8-bit images.

To show how it is indeed a gamma issue, I took your screenshot and applied linear→sRGB gamma (approximately sqrt()) to the image. I get something close to the NVIDIA tool:

So you probably have an issue on the import side which causes incorrect gamma. For example, maybe the image import library does a sRGB→linear gamma conversion for you automatically that shouldn't be done.