Essential HDR support missing

I'm currently testing some of the new HDR features with different HDR sample images.
It would be really useful if you could add HDR support to the following components:

Average Color
Minimum Level
Maximum Level
Hue / Saturation (possibly via HSY model)
Levels (if possible)

I understand why it might not be possible to add HDR support in Brightness / Contrast as you cannot assume 0.5 as midpoint / greypoint.

Another less essential thing is the lack of .hdr format support. A lot of HDR images are distributed in this format.

Quote
These will be difficult, because these are histogram-based. We'd have to remove the Cutoff input to ditch the histograms and support HDR.

Ok, yeah I can see why that might be a problem. Perhaps adding a slightly different set of components could be solution (Minimum Value, Maximum Value)?

So you're actually building a full histogram - interesting (how about putting that into a fixed gradient in the external category).
While the range is not fixed with HDR in general, it is fixed for a given HDR image (i.e. there is a minimum and a maximum), so it should still be possible to build a histogram (via temporary range normalization)?

Quote
(...) the main issue of histogram-based image filters is how to choose number of historgram "bins" (i.e. levels of discretization). It's incorrect to use the same number of bins for images with different RGB value ranges, isn't it?

With 8 bpc images there is not much doubt, here you can represent all values with direct correlation btwn value and index - but how did you handle histogram building with floating point images earlier? I guess by clamping and mapping to 8 bit range.

The question is if the direct correlation btwn value and index is really needed: i.e. the bin at e.g. index 255 could represent another value than 255, say image maximum value, and the value at index 0 could hold the image minimum.

Since floating point images are likely to contain lots of almost, but not equal values, some sort of weighted approach is needed for all intermediate values, as they probably will not match the index value for a given bin. When adding intermediate values that are not in direct correlation with an index, the values could be added with a weight to the two nearest entries.

Anyways - its just an idea, I haven't tested it in a real implementation yet. I'm also curious about another approach: sort each channel in the image and consider the result as a 1D array, resample that array down to the wished final table size. This should represent some sort of histogram, but I'm not sure about the actual mapping here..

Quote
BTW you question about Levels has given me an idea how to implement fully-hdr Levels

That is great news! Specially if you also figure out how to HDRize Min./Max. Level

About HDR version of HSL adjustment:
I did some tests yesterday - this is indeed a tough problem, mainly regarding increase in saturation because "full saturation" is range dependent. Shifting hue: no problem, decreasing saturation: no problem, lightness: no problem, but increasing saturation.. can't figure out that one..