[Insight-developers] ImageRegion utility functions

[Luis Ibanez]

Lydia, Jim,

Wouldn't that funcitonality be solved by the RandomImageIterator ?

We talked about it at last meeting...

It is an Image iterator that each time you call   (++it)    it will
do a random jump on the offset.   it Begin() and End() methods
will be controled by a:      SetNumberOfSamples().....


itk::ImageRandomIterator< ImageType > IteratorType;
IteratorType it (  image, region );

it.SetNumberOfSamples( 100 );

it.GoToBegin() ;  // will set up an internal counter to 0
while( !it.IsAtEnd() )
{
    it.Get()
    ++it;  // increment the internal counter and make a random jump
}


A great advantage of implementing this in the iterator is that we
could have variants of the method used for the random jump.
For example instead of using a random linear offset, use
random choices for each one of the components of the index
that will ensure a better uniform sampling of the volume. A different
iterator could do sampling using a particular distribution.
(probably taking advantage of the classes in Numerics/Statistics)


By doing this in an special iterator, we don't have to modify
the Regions because Iterators already have acccess to the
OffsetTable in the image.

We also have the idea of a Peano path iterator on the
wish list....

Of course with is "const" version included....


Luis



Lydia Ng wrote:

>Jim:
>
>>Why can't you use the methods is ImageBase? 
>>
>
>Okay what I really need is a quick and efficient way to uniformly
>sample one index out of an arbitrary region (typically less than
>the buffered region).
>
>Currently MI samples the whole buffered region. What I did
>was to uniformly pick a number between 0 and numberOfPixels - 1.
>Then used ImageBase::ComputeIndex( number ) to get the index.
>
>Brian had made request the the metric have the ability to
>support a smaller abitrary region. So for an arbitrary region
>I can still pick a number between 0 and the (number of pixels
>in the smaller region - 1 ). Then I need to translate this
>to an index - I can't use ImageBase::ComputeIndex( number )
>because the metric region is smaller than the buffered region.
>
>So I was thinking that was a good functionality for the ImageRegion
>to have. 
>
>I can do a version that doesn't have the extra storage for the
>offset table - but then it would be slower.
>
>All suggestions welcome!
>
>- Lydia
>
>
>>-----Original Message-----
>>From: Miller, James V (Research) [mailto:millerjv@crd.ge.com]
>>Sent: Tuesday, April 16, 2002 5:49 AM
>>To: Lydia Ng; insight-developers@public.kitware.com
>>Subject: RE: [Insight-developers] ImageRegion utility functions
>>
>>
>>Lydia,
>>
>>The problem here is that you cannot correctly compute
>>the offset from a single region. The calculations in ImageBase 
>>are based off of the BufferedRegion parameters. So you would need
>>to know the buffered region in order to determine the index
>>and offset.
>>
>>Also, I would try to avoid the extra storage in the iterators
>>(and hence Regions).  Regions get copied a lot. The iterators
>>(at least the ImageRegionIterator) does not copy the offset table
>>but rather asks the image to compute the index and offset.
>>
>>Why can't you use the methods is ImageBase?  I am assuming that
>>if you are calculating an index and an offset you plan to access
>>an Image.  So you probably have access to the image and can make
>>the calls to Image to convert between offsets and indices.
>>
>>
>>
>>-----Original Message-----
>>From: Lydia Ng [mailto:lng@insightful.com]
>>Sent: Monday, April 15, 2002 6:52 PM
>>To: insight-developers@public.kitware.com
>>Subject: [Insight-developers] ImageRegion utility functions
>>
>>
>>
>>At the UNC meeting I had agree to change
>>MutualInformationImageToImageMetric
>>so that one can limit the fixed image region for which the metric is
>>computed.
>>
>>To do this I need some ImageRegion utility functions in particular:
>>
>>  OffsetValueType ComputeOffset(const IndexType &ind) const;
>>    IndexType ComputeIndex(OffsetValueType offset) const;
>>
>>
>>They will behave similar to those in ImageBase.
>>Does anyone have problem with me doing the following?
>>
>>[1] Add the above function to the ImageRegion class?
>>
>>[2] The most efficient way of computing offset and index is
>>to keep a offset table? This requires extra storage space of
>>
>>OffsetValueType  m_OffsetTable[VImageDimension+1];
>>
>>Is adding an OffsetTable to ImageRegion acceptable to everyone?
>>
>>[3] Once this functionality is inside region one can possibly remove
>>them from ImageBase itself and defer the calculation to the 
>>BufferedRegion? Do people want me to change ImageBase or do they
>>want it left the way it is?
>>
>>- Lydia 
>>_______________________________________________
>>Insight-developers mailing list
>>Insight-developers@public.kitware.com
>>http://public.kitware.com/mailman/listinfo/insight-developers
>>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-developers
>