For an arbitrary floting-point image, it is unlikely that two pixels have the same value. (Sure, if you convert an 8-bit image to float there will be many pixels with the same values, but apply a Gaussian filter and you’ll see few counts in your histogram with a value above 1.) This is because you cannot, generally, do equality comparisons with floating-point numbers. Comparisons have to be approximate, they need a tolerance. And your map does equality comparison on the pixel value. Computing a histogram where most counts are 1 doesn’t really provide any new insight into the image data, it just sorts the pixel values.

A histogram usually is defined by bins. You divide the range of values into some number of bins, each bin will then span a section of that range. A pixel with a value of 0.145 and one with a value of 0.138 might fall in the same bin, one with a value of 0.137 might fall in another bin.

So, for example, say your data falls in the range [0,1], and you use 200 bins. The bin width will be 1/200 = 0.005. For each pixel you then compute:

std::size_t bin = std::floor(value / 0.005);

(obviously with bounds checking if necessary), and increment that histogram bin:

++histogram[bin];

Yes, this is more expensive, but it is the only way to compute a meaningful, useful histogram from floating-point data.

For 32-bit or 64-bit data the same applies: you can do equality comparisons, but you will be likely to have most counts be 1, because an image typically has many fewer pixels than you can address with 32 bits. You need to group intervals of values together to get a useful histogram.

It is good that you have a separate implementation for 8 and 16-bit unsigned integers. That code still uses std::numeric_limits<ElementT>::lowest(), which is always 0.

The biggest issue with your code for me would be that the value returned by the histogram function has a different type (with different member functions) depending on the data type of the input image. This makes it harder to write generic code. But that is something that is likely not as important for other people.

For an arbitrary floating-point image, it is unlikely that two pixels have the same value. (Sure, if you convert an 8-bit image to float there will be many pixels with the same values, but apply a Gaussian filter and you’ll see few counts in your histogram with a value above 1.) This is because you cannot, generally, do equality comparisons with floating-point numbers. Comparisons have to be approximate, they need a tolerance. And your map does equality comparison on the pixel value. Computing a histogram where most counts are 1 doesn’t really provide any new insight into the image data, it just sorts the pixel values.

A histogram usually is defined by bins. You divide the range of values into some number of bins, each bin will then span a section of that range. A pixel with a value of 0.145 and one with a value of 0.138 might fall in the same bin, one with a value of 0.137 might fall in another bin.

So, for example, say your data falls in the range [0,1], and you use 200 bins. The bin width will be 1/200 = 0.005. For each pixel you then compute:

std::size_t bin = std::floor(value / 0.005);

(obviously with bounds checking if necessary), and increment that histogram bin:

++histogram[bin];

Yes, this is more expensive, but it is the only way to compute a meaningful, useful histogram from floating-point data.

For 32-bit or 64-bit data the same applies: you can do equality comparisons, but you will be likely to have most counts be 1, because an image typically has many fewer pixels than you can address with 32 bits. You need to group intervals of values together to get a useful histogram.

It is good that you have a separate implementation for 8 and 16-bit unsigned integers. That code still uses std::numeric_limits<ElementT>::lowest(), which is always 0.

The biggest issue with your code for me would be that the value returned by the histogram function has a different type (with different member functions) depending on the data type of the input image. This makes it harder to write generic code. But that is something that is likely not as important for other people.