[Insight-developers] RE: ExtractImageFilter : Regions : what should they be ?

[Miller, James V (Research)]

You could argue whether the ExtractImageRegion should set the
LargestPossibleRegion or not.  The reason it sets the LargestPossibleRegion
is that the ExtractImageRegion will never produce anything larger than the
region specified.  So its LargestPossibleRegion IS the region prescribed.

You could also argue whether the LargestPossibleRegion should have an
index or not.  But there are a few reasons to allow it: Consider the 
case the where you have two readers that each read a single slice of series,
each as a volume with one slice.  You may want to keep track of the slice 
number in the index of the LargestPossibleRegion.  Another case is if you 
need to pad an image with a border.  You may want to keep the indices
aligned 
so that pixel (5,7) is the same pixel before and after the pad. Finally,
it just simplifies the code that the LargestPossibleRegion, RequestedRegion,
and BufferedRegion are all the same datatype.

As for the readers, I hit upon this problem a few weeks ago. I checked 
in changes to ImageFileReader (version 1.33) on February 18th.  Do you have
these changes?

As for the other filters, if they cannot handle a LargestPossibleRegion that
doesn't start with a zero index, I would consider this a bug. The only
places
most filters should worry about LargestPossibleRegion is in 
GenerateInputRequestedRegion(), GenerateOutputInformation(), 
EnlargeOutputRequestedRegion(), and GenerateOutputRequestedRegion().  The
GenerateData(), ThreadedGenerateData(), AllocateOutputs(),
BeforeThreadedGenerateData(), AfterThreadedGenerateData(), should only
operate on the RequestedRegions. If a filter needs the LargestPossibleRegion
as the BufferedRegion, then it should provided the appropriate
implementations of GenerateInputRequestedRegion(),
GenerateOutputRequestedRegion, GenerateOutputInformation(), and/or
EnlargeOutputRequestedRegion such that the RequestedRegion for the filter is
the LargestPossibleRegion.

IO is a concern.  But I combed through this code and I think the fix I put
in
in February should handle the issues.  As the IO code stands there is plenty
of 
opportunity for the regions of the ImageFileReader to mismatch the regions
of the ImageIO object.  This was the problem I was having.  The
ImageFileReader
was given a region from the ExtractImageRegionFilter and allocated memory
to fit the region.  The ImageIO, tried to write the entire image into that
space.
Boom.  So I added an EnlargeOutputRequestedRegion() method to the
ImageFileReader
so that the ImageFileReader and ImageIO objects are in sync. When ITK gets 
around to supporting streaming readers, we'll need to readdress the issue
that
the ImageFileReader may request only a portion of an image (and hence need
to communicate this information down to the ImageIO object).


For the ExtractImageRegion, you could add a mode to reset the output index
and origin.  I wouldn't remove the standard behavior because if you wanted
to extract a region, operate on it, and then realign it with the original
(uncropped) image, then it is easier to do this if the Index of the
extracted
region is not reset. I think you can use ChangeInformationImageFilter to
move the origin and index if you need to.





> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez@kitware.com]
> Sent: Wednesday, March 26, 2003 5:13 PM
> To: Miller, James V (Research); Insight Developers List
> Subject: ExtractImageFilter : Regions : what should they be ?
> 
> 
> 
> Hi Jim,
> 
> There is an open issue regarding how the ExtractImageFilter
> should behave regarding the values of the regions for the
> output image.
> 
> Right now, the output image have its three regions set
> to the exact values of the user-provided region passed
> in the SetExtractionRegion() method.
> 
> That is, if we have an input image of size 200x200.
> 
> and we ask for extracting the region:
> 
>    Index =  10,  15
>    Size  = 145, 135
> 
> the output image reports to have:
> 
> LargestPossibleRegion = BufferedRegion = RequestedRegion
> 
> with
> 
>    Index {  10, 15  }
>    Size  { 145, 135 }
> 
> 
> This confuses downstream filters. In fact it seems that
> few filters are prepared to deal with a non-zero index
> for the LargestPossibleRegion.
> 
> ---
> 
> In some way it looks like the Largest possible region shouldn't
> have an index at all, since it is redundant with the notion of
> origin.  The largest possible region should probably be just
> "size".
> 
> The buffered region and Requested region chould be defined in
> the reference frame of the largest possible region.
> 
> If you test the example in Insight/Examples/IO,
> 
> 
>         ImageReadExtractWrite.cxx
> 
> 
> With parameters:
> 
> 
>   ImageReadExtractWrite
>     BrainProtonDensitySlice.png output.png 15 17 110 120
> 
> 
> You will see that the PNG reader gets confused with the regions.
> 
> 
> I would suggest that the ExtractImageFilter should report
> an image with the corrected origin
> 
> 
>     = Input image origin + ExtractRegionStartIndex * spacing
> 
> 
> and all its regions set to
> 
>     Index={0,0} and
>     Size=ExtractRegionSize
> 
> 
> Or, if there are good reasons for the current behavior of the
> ExtractImageFilter, we could consider
> 
> 
> 1) Adding booleans allowing to commute the
>     behavior of this filter
> 
> 2) Creating a new filter with the second behavior.
> 
> 
> I'll be happy to write (2) if you find (1) to be undesirable,
> 
> 
> Please let me know what you think,
> 
> 
> Thanks
> 
> 
> 
>      Luis
> 
> 
>