[Insight-developers] readers and regions

[Miller, James V (Research)]

Filters should always traverse the RequestedRegion.  The BufferedRegion
should be at least as big as the RequestedRegion.

Converting indexes into memory addresses is based off of the BufferedRegion's
StartIndex and Size.  So if a filter (or iterator) is manipulating indices
to form memory addresses or memory addresses to form indices, these operations
should be relative to the BufferedRegion.





-----Original Message-----
From: Damion Shelton [mailto:dmshelto@andrew.cmu.edu]
Sent: Monday, April 22, 2002 1:59 PM
To: Miller, James V (Research); insight-developers@public.kitware.com
Subject: RE: [Insight-developers] readers and regions


Ok...

> inputImage->SetRequestedRegionToLargestPossibleRegion() before
> the reader->Update() call, then you have the data you wanted.
> You may still have an indexing problem, however, because it sounds
> like something is indexing off of the LargestPossibleRegion when it
> should be indexing off of the BufferedRegion.

Yup. We changed the code to this and it worked - thanks. We haven't tracked 
down where the region weirdness was coming from.

Re. the filters - here's a code snippet from GradientImageFilter:

  typename TInputImage::RegionType inputRequestedRegion;
  inputRequestedRegion = inputPtr->GetRequestedRegion();

Looking through the rest of the code, it appears that this filter - 
presuming it's a "typical" filter - worries about the requested region 
rather than the buffered region. I.e., the iterators traverse the requested 
regions, and not the buffered regions, if I'm understanding things 
correctly.

So, should filters traverse the requested or buffered regions? Or are they 
the same thing, if the filter is implemented correctly?

Right now we're leaning towards a problem in the blox code propogating 
backward and messing up the regions earlier on, but we're not positive yet.

-Damion-