Conceptual motivation for the difference between imhist() and histcounts()

In trying to divorce my toolbox from the IPT, I reimplemented imhist() using histc()/histcounts().

While histc()/histcounts() describes bin locations by their edges, imhist() describes bin locations by their centers. As a consequence, when using imhist(), the first and last bins straddle the extreme values of the data range, effectively making them uniquely half-width bins.

Why this is the preferred behavior? Is this something that is particularly of importance for images? It seems rather contrary to my intuition. I would expect an image with a uniform intensity distribution to have a flat histogram, which isn't what imhist() produces.

Answer 1

[Steven Lord]

I haven't used imhist very much if at all, but I suspect using histcounts with the 'integers' BinMethod is likely to be close in functionality to it.

[DGM]

Well, it sort of is, though imhist() behaves that way even for FP images. I don't know that it really answers the "what's the motivation" question unless the answer is simply that the behavior is an artifact of presuming everything should match some legacy behavior with integer images.