[Insight-developers] [Fwd: on segmentation & connectedness]

[Luis Ibanez]

This is a multi-part message in MIME format.
--------------000108020108010900060301
Content-Type: message/rfc822;
 name="Re: on segmentation & connectedness"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="Re: on segmentation & connectedness"

>From - Mon Oct 14 14:40:42 2002
X-Mozilla-Status2: 00000000
Message-ID: <3DAB0FA4.9010300@kitware.com>
Date: Mon, 14 Oct 2002 14:40:36 -0400
From: Luis Ibanez <luis.ibanez@kitware.com>
Organization: Kitware Inc.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2.1) Gecko/20010901
X-Accept-Language: en-us
MIME-Version: 1.0
To: Joshua Cates <cates@sci.utah.edu>
CC: cspl <affable@hd2.dot.net.in>,
	insight-users-request@public.kitware.com,
	Damion Shelton <dmshelto@andrew.cmu.edu>
Subject: Re: on segmentation & connectedness
References: <Pine.LNX.4.44.0210141135290.1362-100000@poblano.sci.utah.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit


Hi Josh,

I like the third option you propose, where the Neighborhood
Iterator manage a set of indices to the neighbor pixels.


Just to double-check:

When you mention "offset" do you mean the "unsigned long"
value from the start of the buffer to the position of the
pixel ? or do you mean the itk::Offset<> class which is
the N-D set of differences between two indices.

It looks like the later (itk::Offset<> as a difference of
itk::Index<>) may be the more explicit way of representing
a neighborhood.


   my two cents,


      Luis


===============================================================


Joshua Cates wrote:

> There are several options for expanding the neighborhood iterators to
> handle arbitrary connectedness.  
> 
> One way is to slice the neighborhood iterator array using a container
> that holds array offsets (which has the advantage of being fully
> customizable to non-traditionally-shaped neighborhoods).  I do this sort 
> of thing in the watersheds code:
> 
> class ConnectednessObjectBase {
>   std::size_t GetSize() {return m_Offsets.size();}
>   
>   unsigned GetOffset(unsigned i) { return m_Offsets(i); }
> 
>   std::vector<unsigned> m_Offsets;
> };
> 
> class CityBlockConnectedness {
>   CityBlockConnectedness(dimensionality) {
>   for (i = 0; i < 2*dimensionality; i++)
>      m_Offsets.push_back(this->CalculateIthOffset(i, dimensionality));
>   }
>   CalculateIthOffset(unsigned i, unsigned dimensionality) {
>    ....
>   }
> 
> };
> 
> 
> - or drop the container -
> 
> class ConnectedObjectBase {
>   virtual std::size_t GetSize() = 0;
>   virtual unsigned CalculateIthOffset(unsigned, unsigned) = 0;
>   virtual unsigned GetOffset(unsigned i, dimensionality) 
>     { return this->CalculateIthOffset(i, dimensionality)} ;
> }
> 
> To iterate over the connected pixels in a neighborhood becomes:
> 
> CityBlockConnectedNess c(3);
> SmartNeighborhoodIterator(neighborhoodRadius, image, imageRegion) it;
> 
> //Print the connected pixels in a neighborhood
> for (unsigned i = 0; i < c->GetSize(); ++i)
> {
>   std::cout << it->GetPixel(c->GetOffset(i));
> }
> 
> 
> Another option is to use an actual slice iterator directly on the 
> neighborhood container itself.  Examples of doing this can be found by 
> looking through the code which does inner products on neighborhoods.  
> There is a mechanism to take an inner product with a slice of a 
> neighborhood, for example.
> 
> A third option is to create special NeighborhoodIterators which only keep
> track of the requested neighbor pixels.  You then iterate through the
> indicies directly.  This is the most efficient way.  I plan to backfill
> this functionality into the neighborhood iterators sometime in the coming
> months.  Any design ideas or API suggestions would be helpful.
> 
> Josh.
> 
> 
> 
> 
> 
>



--------------000108020108010900060301--