Re: [Rapp-dev] Padding for binary morphing: (SIZE + 1) / 2 or SIZE / 2?

[Johan Almbladh]

That should be SIZE / 2. Let's say we have a structuring element (SE) with 3x3 pixels. When we place this patch in the corner of the image, i.e. with the SE center pixel aligned exactly on the image corner pixel, then the structuring element reaches 1 pixel outside the image. These pixel values will be read and needs to be valid. 

For odd SE sizes we can get away with different padding sizes. For the sake of simplicity the functions require the same (maximum) padding size in these cases. i.e. SIZE / 2. For a 2x2 SE we then get 1 pixel padding for all edges even though two edges can be unpadded.

Also note that x and y padding sizes can be different if the SE is asymmetric (3x7, 2x1), i.e. SIZE is width or height of the SE.

Best regards,
/Johan

On Fri, Nov 26, 2010 at 4:37 PM, Hans-Peter Nilsson <address@hidden> wrote:

In commit
<http://git.savannah.gnu.org/cgit/rapp.git/commit/?id=5c545b7c8b476f2ee7984d51e5648d1a2a1d9f2d>
I fixed what was seen as an inconsistency in the documentation.
I haven't regenerated the one at
<http://www.nongnu.org/rapp/doc/rapp/group__grp__binmorph.html>
yet.  The documentation there defines the radius as the width
rounded up, yet the padding is SIZE / 2, where SIZE is the
maximum size of the structuring element in the horizontal and
vertical directions in width and height of the structural
element, i.e. the "truncated" radius.

It has been argued by local users that the padding should indeed
be SIZE / 2, not (SIZE + 1) / 2, as the former is the
theoretical lower limit.  I.e. the truncated value is correct.
Thus, that the documentation should be changed back (and
clarified), and all overlap-detections correspondingly adjusted.

I'm slightly inclined to do the suggested change, as the code
seems to use the "lower" padding.  Beware, I'm frequently
mistaken, please double-check. ;-)

Since there's no release just yet, this is the best time to
speak up.  Is there any win for the "upper" padding, now or some
conceivable future improvement?

Speaking of the release, I hope to get to that as soon as this
issue is resolved.  I'm also going to add a few pointers to the
project home in the documentation and README, and a rapp.spec
file.

brgds, H-P