Hi Francois,<br><br>Thanks for pointing this out.<br><br>You may have found a bug indeed.<br><br>The assumption of the boundary face <br>calculator is that the radius of the <br>neighborhood is smaller than half<br>of the image size.<br>
<br>Let me attempt to illustrate this in a<br>diagram:<br><br><font style="font-family: courier new,monospace;" size="2">XXXXXXXXXXXXXXXXXXXX<br>XXXXXXXXXXXXXXXXXXXX<br>HHHOOOOOOOOOOOOOOHHH<br></font><font style="font-family: courier new,monospace;" size="2">HHHOOOOOOOOOOOOOOHHH<br>
</font><font style="font-family: courier new,monospace;" size="2">HHHOOOOOOOOOOOOOOHHH<br></font><font style="font-family: courier new,monospace;" size="2">HHHOOOOOOOOOOOOOOHHH</font><br><font style="font-family: courier new,monospace;" size="2">XXXXXXXXXXXXXXXXXXXX<br>
XXXXXXXXXXXXXXXXXXXX<br></font><br>Here we have the top and <br>bottom faces for a neighborhood<br>whose radius is (3,2) (3 in the<br>horizontal direction, and 2 in the<br>vertical direction).<br><br>Therefore, the "H" colums <br>
form faces of width=3<br><br>while the "X" rows form faces <br>of height=2<br><br>Leaving ample room for the <br>central "face" marked by the<br>"O" symbols.<br><br>If we start increasing the values<br>
of the radius, the "H" and "X"<br>regions will increase in size, <br>at the same time that the "O"<br>(the inside face) will decrease <br>in size.<br><br>Therefore, it is possible to get<br>to a point where the "O" region<br>
is empty, or even further, where<br>the left and right "H" regions <br>start overlapping.<br><br>In your particular case, <br><br>A) You have an image of 4x4 pixels.<br><br>B) You set the radius to 1,1<br> therefore to a neighborhood<br>
size of 3x3<br><br>C) You ask the calculator to partition<br> a subregion of the image, defined<br> by <br><br> Index = (1,0)<br> Size = (1,2)<br><br><br>So, in practice, you "image of interest''<br>
is only of size 1x2.<br><br><br>Should you have used the full size of <br>the 4x4 image, you should have found<br>faces as in the diagram below:<br><br><font size="2"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">BBBB</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">CAAD</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">CAAD</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">EEEE</span></font><br>
<br>Where "A" is the inside face, <br>and "B","C","D","E", are the lateral <br>faces<br><br>Since in (3) you limited the region <br>to only the "O"s in the diagram below:<br>
<font size="2"><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">XOOX</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">XXXX</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">XXXX</span><br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">XXXX</span></font><br><br>Then the partition of the "OO" region<br>
into faces becomes quite challenging.<br><br>The resulting "inside" region is certainly<br>correct in retuning an empty size.<br><br>As for the other regions, I agree with<br>you in that they are not consistent...<br>
<br>However, <br>I'm having trouble figuring out what<br>the "correct" answer should have been...<br><br><br>I would be tempted to say that the <br>request is not solvable, and that the<br>calculator should have simply thrown<br>
and exception here.<br><br><br>Would you consider that a reasonable<br>behavior for the face calculator ?<br><br><br><br> Regards,<br><br><br> Luis<br><br><br>-----------------------------------------------------<br>
<div class="gmail_quote">On Fri, Oct 1, 2010 at 12:20 PM, <span dir="ltr"><<a href="mailto:devieill@irit.fr">devieill@irit.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hello all,<br>
the itk documentation state that the boundary face calculator should output<br>
2N+1 region where N is considered to be the region/image dimension.<br>
However when creating a itk::Image<double,2> containing 4 pixels and<br>
running the following simple code :<br>
____________________________________<br>
<br>
typedef itk::NeighborhoodAlgorithm::ImageBoundaryFacesCalculator<<br>
Image2D > FaceCalculatorType;<br>
itk::NeighborhoodAlgorithm::ImageBoundaryFacesCalculator< Image2D><br>
faceCalculator;<br>
FaceCalculatorType::FaceListType faceList;<br>
itk::NeighborhoodAlgorithm::ImageBoundaryFacesCalculator<<br>
Image2D>::FaceListType::iterator fit;<br>
<br>
Image2D::RegionType region;<br>
Image2D::IndexType index;<br>
Image2D::SizeType size;<br>
itk::Size<2> radius;<br>
index[0] = 1;<br>
index[1] = 0;<br>
size[0] = 1;<br>
size[1] = 2;<br>
region.SetIndex(index);<br>
region.SetSize(size);<br>
radius[0]=1;<br>
radius[1]=1;<br>
faceList = faceCalculator(img1, region, radius);<br>
std::cout << " face list number " << faceList.size() << std::endl ;<br>
for (fit = faceList.begin(); fit!= faceList.end(); ++fit) {<br>
std::cout << " current face is " << *fit << std::endl ;<br>
}<br>
_______________________________<br>
<br>
<br>
I have the following output :<br>
<br>
______________________________<br>
face list number 4<br>
current face is ImageRegion (0x25c0f10)<br>
Dimension: 2<br>
Index: [1, 1]<br>
Size: [0, 0]<br>
<br>
current face is ImageRegion (0x25c0f50)<br>
Dimension: 2<br>
Index: [1, 0]<br>
Size: [1, 2]<br>
<br>
current face is ImageRegion (0x25c0f90)<br>
Dimension: 2<br>
Index: [1, 0]<br>
Size: [1, 1]<br>
<br>
current face is ImageRegion (0x25c0fd0)<br>
Dimension: 2<br>
Index: [1, 1]<br>
Size: [1, 1]<br>
____________________________________<br>
<br>
<br>
Despite the fact that there is NOT the right number of regions,<br>
what bothers me the most is that one gets duplicated pixels, or to put it<br>
simply the regions given by the algorithm are overlapping.<br>
Assuming that one build a filter using neighboorhood filters this<br>
become troublesome (imagine with multithreading...).<br>
My question are :<br>
1) is the boundary calculator broken ?<br>
2) what should be used instead to design fast filters requiring a radius ?<br>
3) Can one have neuman boundary conditions with it ?<br>
<br>
Regards,<br>
de Vieilleville François<br>
<br>
<br>
_____________________________________<br>
Powered by <a href="http://www.kitware.com" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at<br>
<a href="http://www.kitware.com/opensource/opensource.html" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Kitware offers ITK Training Courses, for more information visit:<br>
<a href="http://www.kitware.com/products/protraining.html" target="_blank">http://www.kitware.com/products/protraining.html</a><br>
<br>
Please keep messages on-topic and check the ITK FAQ at:<br>
<a href="http://www.itk.org/Wiki/ITK_FAQ" target="_blank">http://www.itk.org/Wiki/ITK_FAQ</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://www.itk.org/mailman/listinfo/insight-users" target="_blank">http://www.itk.org/mailman/listinfo/insight-users</a><br>
</blockquote></div><br>