[Octave-bug-tracker] [bug #46390] image package - im2bw interprets threshold slightly different than Matlab

[Hartmut]

URL:
  <http://savannah.gnu.org/bugs/?46390>

                 Summary: image package - im2bw interprets threshold slightly
different than Matlab
                 Project: GNU Octave
            Submitted by: hardy
            Submitted on: Fr 06 Nov 2015 20:00:11 GMT
                Category: Octave Forge Package
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Matlab Compatibility
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.0.0
        Operating System: Any

    _______________________________________________________

Details:

I observed this behavior with Octave 4.0.0 release and the image package
release 2.4.1 (under Linux). Here is a little skript to show the behavior:


I = uint8([0:255]);
bw = im2bw(I, 0.9);
sum(bw)


If you let this skript run in Octave, the result is 25. This means the Octave
version of im2bw decides that the values between 231 and 255 are above a
threshold of 90%.

If you let this script run in Matlab (R2013b), the result is 26. This means
the Matlab version of im2bw decides that the values between 230 and 255 are
above a threshold of 90%.

This is (only) an incompatibility. The results of the Octave version of im2bw
are also well usable. But they ARE different to the Matlab results, you always
get a few less foreground pixels with Octave.

In my naive understanding, the Matlab result is "more correct". When I would
be asked to divide the set [0 ... 255] into a chunk with 90% and another chunk
with 10% of the numbers, then I would calculate 256*0.9 = 230.4. And then I
would start to count 230 elements of this set, and end up with 0 ... 229. So
the value 230 would be the first one of the remaining 10%, those values being
230...255. This is the Matlab result.

So I guess this issue is probably either about 
* how to round a float percentage to the next integer value, or about 
* starting to count at 0 or at 1, or about 
* taking 255 or 256 as maximum value of the uint8 numbers.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?46390>

_______________________________________________
  Nachricht gesendet von/durch Savannah
  http://savannah.gnu.org/