[Insight-developers] ImageRegion utility functions

[Miller, James V (Research)]

Here are a few ideas:

1) Instead of drawing a single random variable, draw N random numbers
where N is the dimension of the index.

2) In a loop, draw a random variable and see if that offset converts
to an index that is inside the region (slow).

3) Draw a random variable and convert that offset to an index. Take 
the modulus of this index with the size of the desired region to force
an index in the desired region.

4) A random iterator (like Luis suggests) but NOT using drand48

5) As you suggested put in ComputeIndex and ComputeOffset routines in 
ImageRegion. Now here is the question: Should these indices and offsets
be relative to the current region? Then the routines in ImageBase would
call these methods and make adjustments for being in the buffered region.
Maybe that is not necessary....



-----Original Message-----
From: Lydia Ng [mailto:lng@insightful.com]
Sent: Tuesday, April 16, 2002 12:43 PM
To: Miller, James V (Research); insight-developers@public.kitware.com
Subject: RE: [Insight-developers] ImageRegion utility functions


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
>