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