<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Dirk,<br><div><br></div><div>As a counterpoint, I do not agree that there is a bug but rather just an ambiguity in the way we have defined whether or not a pixel is to be included.</div><div><br></div><div>If you take a protractor and plotted a unit circle, then superimpose a grid on it (this this case, 3x3), and then shaded in the nearest pixels to the circle, it would look like the “original” example. The same applies to the radius 5 circle.</div><div><br></div><div>Technically, if you look at the parametric definition of a circle, then yes, those pixels would not be included, as their physical space points fall outside the circle. </div><div><br></div><div>However, I believe (anecdotal) in graphics rendering, it is common practice to include those pixels which are nearest to the actual physical space point.</div><div><br></div><div><div apple-content-edited="true"><div style="orphans: 2; text-align: -webkit-auto; widows: 2; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="text-align: -webkit-auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div style="text-align: -webkit-auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div>Regards,</div><div><br></div></div></div></div></div></div><div>
<div style="color: rgb(0, 0, 0); font-family: Helvetica;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div style="color: rgb(0, 0, 0); font-family: Helvetica;  font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Ho Cheung</div><div>(775) 388-2368</div></div></div></div>
</div>
<br><div><div>On Oct 16, 2013, at 1:05 PM, Padfield, Dirk R (GE Global Research) <<a href="mailto:padfield@research.ge.com">padfield@research.ge.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">Hi All,<br><br>I am writing to ask your advice about a bug I found in BinaryBallStructuringElement.<br><br>For a while, I have been bothered by the fact that the BinaryBallStructuringElement return balls that are larger than the specified radius.  For example, when given a radius of 1, it returns the structuring element:<br>1    1    1<br>1    1    1<br>1    1    1<br><br>But this structuring element has a radius that is more than 1!  If it truly had a radius of 1, it would be a cross shape in this case.<br><br>When choosing a larger radius, the problem is more obvious.  Setting radius = 5 (leading to a structuring element size of 11x11) results in:<br>0    0    0    1    1    1    1    1    0    0    0<br>0    0    1    1    1    1    1    1    1    0    0<br>0    1    1    1    1    1    1    1    1    1    0<br>1    1    1    1    1    1    1    1    1    1    1<br>1    1    1    1    1    1    1    1    1    1    1<br>1    1    1    1    1    1    1    1    1    1    1<br>1    1    1    1    1    1    1    1    1    1    1<br>1    1    1    1    1    1    1    1    1    1    1<br>0    1    1    1    1    1    1    1    1    1    0<br>0    0    1    1    1    1    1    1    1    0    0<br>0    0    0    1    1    1    1    1    0    0    0<br><br>This is clearly not an ellipse/circle with radius 5 because the interior ellipse/circle is touching each image border at five points rather than just one.  As it turns out, the code is actually defining a radius that is "X + 0.5", where X is the radius that is requested!<br><br>The problem is in the specification of the ellipse axes on lines 70-76 of itkBinaryBallStructuringElement.hxx:<br>  // Define and set the axes lengths for the ellipsoid<br>  typename EllipsoidType::InputType axes;<br>  for ( i = 0; i < VDimension; i++ )<br>    {<br>    axes[i] = this->GetSize(i);<br>    }<br>  spatialFunction->SetAxes(axes);<br><br>In this case, "this->GetSize()" is equal to radius*2+1.  But, an ellipse/circle with radius X should have axes length 2X, not 2X+1!  In the implementation, the center of the ellipse is properly accounted for by setting it to "this->GetRadius+1", but the size of the ellipse is not correct!<br><br>To correct this, we can make a simple change either<br>    axes[i] = this->GetSize(i) - 1;<br>or<br>    axes[i] = this->GetRadius(i) * 2;<br><br>The second is probably more intuitive.<br><br>With this fix, we get for radius=1:<br>0    1    0<br>1    1    1<br>0    1    0<br><br>and for radius=5:<br>0    0    0    0    0    1    0    0    0    0    0<br>0    0    1    1    1    1    1    1    1    0    0<br>0    1    1    1    1    1    1    1    1    1    0<br>0    1    1    1    1    1    1    1    1    1    0<br>0    1    1    1    1    1    1    1    1    1    0<br>1    1    1    1    1    1    1    1    1    1    1<br>0    1    1    1    1    1    1    1    1    1    0<br>0    1    1    1    1    1    1    1    1    1    0<br>0    1    1    1    1    1    1    1    1    1    0<br>0    0    1    1    1    1    1    1    1    0    0<br>0    0    0    0    0    1    0    0    0    0    0<br><br>This is a true circle with radius 5!<br><br>My questions are:<br>1) Is anyone else bothered by this bug?  I imagine that many users expect the corrected version and don't realize they are getting the incorrect one.<br>2) Do others agree with this fix?<br>3) Can we make this fix given the number of filters/applications that will change slightly as a result of this fix?<br><br>Many thanks,<br>Dirk<br><br><br><br>_______________________________________________<br>Powered by <a href="http://www.kitware.com">www.kitware.com</a><br><br>Visit other Kitware open-source projects at<br><a href="http://www.kitware.com/opensource/opensource.html">http://www.kitware.com/opensource/opensource.html</a><br><br>Kitware offers ITK Training Courses, for more information visit:<br>http://kitware.com/products/protraining.php<br><br>Please keep messages on-topic and check the ITK FAQ at:<br>http://www.itk.org/Wiki/ITK_FAQ<br><br>Follow this link to subscribe/unsubscribe:<br>http://www.itk.org/mailman/listinfo/insight-developers<br></blockquote></div><br></body></html>