[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #45088] image package: rangefilt requires doma
From: |
Hartmut |
Subject: |
[Octave-bug-tracker] [bug #45088] image package: rangefilt requires domain and image to have equal number of dimensions |
Date: |
Wed, 29 Mar 2017 14:37:03 -0400 (EDT) |
User-agent: |
Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0 |
Follow-up Comment #21, bug #45088 (project octave):
The Matlab result for the rangefilt command in comment #19 is the following:
19 23 23 15 8
20 23 23 21 14
19 19 16 19 19
14 21 23 23 20
8 15 23 23 19
There are also a bunch of Matlab compatible tests for rangefilt in file #39544
(from patch #9235).
When I use the patch from comment #16 (file #39535) in rangefilt.m then I get
the following result for the rangefilt command in comment #19:
19 23 23 15 8
20 23 23 21 14
19 19 16 19 19
14 21 23 23 20
8 15 23 23 19
This is identical to the above Matlab result. So Avinoam's latest patch (file
#39535) seems to generate Matlab compatible results even in this new test
case. (It also passes all the Matlab compatible tests from the mentioned file
#39544.)
Conclusion: No, the (patched) rangefilt.m is not completly wrong. It gives
Matlab compatible results in all 14 testcases that we currently have. (The
current version in the repo IS completely wrong, though.)
I am very open to deal with the padding issue (in order to better deal with
different numbers of dimensions) differently. I might be a clever idea to let
_spatial_filtering_ do this padding job. (But I myself wasn't eager to
implement this padding in c code.) Now that we have so many test cases
available for all filtering functions that call _spatial_filtering_ (see patch
#9235) the risk is significantly lower to unintentionally damage something in
this code.
Using
imdilate (im, domain) - imerode (im, domain)
also produces the correct result of rangefilt for the new test case in comment
#19. (I haven't tested the results for the other 14 testcases though.) That
might be an even better way (faster?) to do a fully new implementation of
rangefilt.m. But in this case we still need to fix the calling of
_spatial_filtering_ (for entropyfilt and stdfilt) and the padding issue for
the remaining filter functions (probably entropyfilt, stdfilt, medfilt2,
ordfilt2, maybe more).
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?45088>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/