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

[Hans-Peter Nilsson]

(I'm forwarding my copies of three messages missing from the
archives due to the recent backup restore: 1/3)

------- Start of forwarded message -------
Date: Sun, 28 Nov 2010 20:29:15 +0100
From: Johan Almbladh <address@hidden>
To: Hans-Peter Nilsson <address@hidden>
Cc: address@hidden

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