[Insight-users] ShapedNeighborhoodIterator problem

[wanlin]

For issue 5).  I ran cross it before and make some changes in
itkNeighborhoodAlgorithm.txx. Here is the patch, For 5x5 image with kernel
size 3x3, the output of regions list are

9
ImageRegion (0xb8b830)
  Dimension: 2
  Index: [1, 1]
  Size: [3, 3]

5
ImageRegion (0xb8b870)
  Dimension: 2
  Index: [0, 0]
  Size: [1, 5]

5
ImageRegion (0xb8b8b0)
  Dimension: 2
  Index: [4, 0]
  Size: [1, 5]

3
ImageRegion (0xb8b8f0)
  Dimension: 2
  Index: [1, 0]
  Size: [3, 1]

3
ImageRegion (0xb8b930)
  Dimension: 2
  Index: [1, 4]
  Size: [3, 1]




On Mon, Nov 15, 2010 at 11:37 AM, Dawood Masslawi <masslawi at gmail.com>wrote:

>
>    - 1) If I'm going to do this type of thing:
>    -
>    -   IteratorType::OffsetType top = {{0,-1}};
>    -   IteratorType::OffsetType bottom = {{0,1}};
>    -   IteratorType::OffsetType left = {{-1,0}};
>    -   IteratorType::OffsetType right = {{1,0}};
>    -
>    - Then get the pixels with:
>    - iterator[top][0]
>    -
>    - is there an advantage to using the ShapedNeighborhoodIterator over
>    just a NeighborhoodIterator?
>
> ------------------------------
>
> You can use offsets for both ShapedNeighborhoodIterator and regular
>
> NeighborhoodIterator, the difference is in performance. A regular
>
> NeighborhoodIterator would need more pixels to form a rectangular
>
> neighborhood (which artificially could be considered as a
>
> "ShapedNeighborhoodIterator" using offsets) but a
>
> ShapedNeighborhoodIterator would require less pixels in the neighborhood
>
> to form a shaped neighborhood, less pixels mean less memory allocation
>
> and less boundary checking which could remarkably improve the performance
>
> specially for large neighborhoods in large and multidimensional images
> plus,
>
> handling shaped neighborhoods is easier with
> the ShapedNeighborhoodIterator.
>
> ------------------------------
>
>
>    - 2) If I do want to use the ShapedNeighborhood style, is this correct:
>    -
>    - IteratorType::IndexListType::const_iterator indexIterator =
>    iterator.GetActiveIndexList().begin();
>    -     while (indexIterator != iterator.GetActiveIndexList().end())
>    -       {
>    -      std::cout << (int)iterator[*indexIterator][0] << " ";
>    -       ++indexIterator;
>    -       }
>
>
> ------------------------------
> Yes, the following is also a good practice:
>
> IteratorType::ConstIterator ci;
>
>   for (ci = iterator.Begin(); ci != iterator.End(); ci++)
>
>   {
>
>            std::cout <<  ci.get() << std::endl;
>
>           }
>
> ------------------------------
>
>
>    - 3) If I loop over the ActiveIndexList using the FaceCalculator, is
>    the idea that in all regions except the 0th region I need to do something
>    like:
>    -
>    - IteratorType::IndexListType::const_iterator indexIterator =
>    iterator.GetActiveIndexList().begin();
>    -     while (indexIterator != iterator.GetActiveIndexList().end())
>    -       {
>    -       bool valid;
>    -       iterator.GetPixel(*indexIterator,valid);
>    -       if(valid) { do something }
>    -       ++indexIterator;
>    -       }
>    -
>    - Alternatively, I could use 4 separate loops (one for each face
>    region) where I know which neighbor isn't valid. I would have to modify the
>    ActiveIndexList to reflect this missing pixel before each loop.
>
> ------------------------------
>
> Usually for neither of face calculator or neighborhood iterator you need to
> perform
>
> the boundary check yourself (notice that the iterator itself has to iterate
> over the
>
> boundary to check for its validity), the face calculator splits the image
> into boundary
>
> and non-boundary regions for the iterator to not to check for all of the
> pixels and
>
> only perform the boundary checking for pixels in the face region (pixels
> with distance
>
> from the image boundary equal or less than the neighborhood radius). This
> would also
>
>  improve the performance specially for large datasets.
>
> ------------------------------
>
>    - 4) I believe
>    - iterator[top][0]
>    - is equivalent to but faster than iterator.GetPixel(top). Is this
>    correct?
>
> ------------------------------
> I'm not sure about this since I haven't seen a significant performance
> difference.
>
>
>    -
>    ------------------------------
>    - 5) Am I correct that the face calculator returns overlapping regions?
>    If I use a 5x5 image with a 3x3 kernel, it returns regions of size
>    - 9
>    - 5
>    - 5
>    - 5
>    - 5
>    -
>    - totaling 29, when there are only 25 pixels. I don't see any functions
>    to turn on/off this overlap. How is this usually handled?
>
> ------------------------------
>
> To the best of my knowledge this is still an unsolved issue which was
> brought up
>
> by other users in the list as well. Usually the face calculator assumes
> that the
>
> face region is far smaller than the non-boundary region which could be an
> issue
>
> for small images or very large neighborhoods.
>
>
> Regards,
>
> Dawood
>
>
> _____________________________________
> 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/20101115/93d58843/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: itkNeighborhoodAlgorithm.txx.patch
Type: text/x-patch
Size: 2375 bytes
Desc: not available
URL: <http://www.itk.org/pipermail/insight-users/attachments/20101115/93d58843/attachment.bin>