Closing as fixed.

Looks good.
pushed http://hg.code.sf.net/p/octave/image/rev/c90b489def49
If there are no further comments, I will close this bug report.
Thanks :)

I've enlarged the information about this change in the NEWS file, because the output values of this function are now always different than before. See attached patch (V5).
(file #45428)

Here is a new proposal for a patch (file V4):
 I tried to adjust all issues from Carne's comment #9. (Sorry if I missed a whitespace somewhere...)
 I changed the input checking of I, to allow for logical input images.
 I added some tests for logical input images.
Please review this and let me know if something is still wrong before pushing.
@Avinoam: After finishing this, I will proceed with patch #9235, because I would like to use this corrected entropy function in the BISTs there.
(file #45425)

Hartmut  could please update also patch #9235?

Looks fine to me, if it fixes the issue. Just:
1) the patch adds trailing whitespace. Please remove
2) can you add a test case for logical input as well
3) list entropy in the NEWS file (if we keep the NEWS file up to date, then it's easier to make the release  alternative to check history when making the release)

Here is a new version of my patch (V3) with additional (Matlab compatible) tests using uint8 inputs.
Please review if this one is now ready for pushing.
(file #45416)

Could you add some 8 bit tests like
assert (entropy (uint8(C)), ...., eps)

This was a good idea to imcast float images to uint8, it made our function Matlab compatible for all the float images I tested :)
Here is a new patch file (V2). It:
 uses im2uint8 on all input images except for logicals (as Matlab claims to do)
 uses imhist instead of hist, because Matlab does it (according to its help page)
 it removes the zero elements in the histogram p properly. (I double checked the previous code line "P += (P == 0);". It puts a 1 at all 0 positions, which excludes those histogram bins from the entropy calculation because log2(1)=0. But the resulting histogram p cannot easily be normalized to a sum of 1 afterwards, because there are all those surplus 1s in it.)
 it normalizes the histogram p to a sum of 1 (this is how I understand the word "normalized histogram counts" in the Matlab help page. And it works fine.)
 it adds a bunch of Matlab compatible tests with float images.
Any comments on this new patch? Do you any objections to push this patch?
(file #45388)

Yes, it seems so.
Maybe imcast to uint8 can help?

Is it really true that the current Octave implementation is (quite) compatible for uint8 intputs, but nor for float inputs? In this case I would also like to conclude that we still do something wrong in the first "conversion to uint8" step.

Reading Matlab documentation:
"entropyfilt converts any class other than logical to uint8 for the histogram count calculation so that the pixel values are discrete and directly correspond to a bin value",
So if you use in the examples:
You will see that Octave results are similar to Matlab results, on uint8 matrices.

(properly adding Carne to cc)

Here is my first proposal how to fix this (see patch file V1):
 Use imhist instead of hist.
**This is what the Matlab help on entropy claims to do. I'm not sure this is necessary.
 Normalize the resulting histogramm to have a sum of 1.
 This normalization is also mentioned on the Matlab help page. And when I use this my results becomse compatible.
 Ignore the zero elements in the histogramm.
 This was also done before (as the code comment sais), but I do not understand what entropy.m did before, the code was P += (P == 0);
 I added the example from comment #0 as new test case.
Please have a look and review this test. Any comments on the above mentioned changes are appreciated.
I would espacially appreciate of someone could check of the new test case is Matlab compatible (as I am currently only assuming this). And one or two more Matlab compatible test cases with real numbers (e.g. 5 to 10 element matrices) could also be useful.
(file #45372)

The results of entropy.m in the image package don't seem to be very Matlab compatible.
Here is a small example:
From another bug report (on entropyfilt, see patch #9235) I assume that the Matlab result on this will be 0.9183. But the current (image 2.8.0 release) Octave output is 2.9477.
