octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #46392] image package - regionprops(bw, 'Perim


From: Hartmut
Subject: [Octave-bug-tracker] [bug #46392] image package - regionprops(bw, 'Perimeter') gives incorrect result
Date: Fri, 06 Nov 2015 20:21:07 +0000
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:42.0) Gecko/20100101 Firefox/42.0

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

                 Summary: image package - regionprops(bw,'Perimeter') gives
incorrect result
                 Project: GNU Octave
            Submitted by: hardy
            Submitted on: Fr 06 Nov 2015 20:21:06 GMT
                Category: Octave Forge Package
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: 4.0.0
        Operating System: Any

    _______________________________________________________

Details:

This happens with Octave 4.0.0 and the current image package 2.4.1 (as well as
the current repo tip of the image package). Here is a little script to show
the behavior:


clear, close all;
pkg load image

% create test image (circle with diameter 201)
I = zeros(400);
disk = fspecial('disk',100);
disk = disk./max(disk(:));
I(100:300, 100:300) = disk;
bw = im2bw(I);
imshow(bw)

% calculate perimeter of circle:
props = regionprops(bw, 'Perimeter', 'Area');
area = props.Area
perim = props.Perimeter


The results of Octave are: area = 31397 and perim = 564 .
The results of Matlab R2013b are: area = 31397 and perim = 658.4407 .

The "correct" result of the perimeter of a circle of radius 100.5 is perim =
631.46 . This is much closer to the Matlab approximation value than to the
current Octave return value.

I think I understand the difference and will be able to fix it: Octave only
counts the plain number of pixels that form the boundary. This results in a
too small result at positions where two boundary pixels are only connected
diagonally. Octave will currently calculate the length at this position to be
1 (as for any other pixels as well). But a better approximation for the
distancy between to diagonally connected pixels is sqrt(2). 

I will try to soon prepare a patch for this.





    _______________________________________________________

Reply to this item at:

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

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]