[Insight-developers] RE: ExtractImageFilter : Regions : what
should they be ? : RegionOfInterestImageFilter added.
Luis Ibanez
luis.ibanez@kitware.com
Fri, 28 Mar 2003 07:38:41 -0500
Hi Jim,
In order to avoid disturbing the ExtractImageFilter
I added a RegionOfInterestImageFilter.
http://www.itk.org/Insight/Doxygen/html/classitk_1_1RegionOfInterestImageFilter.html
This filters extract a user-specified region.
The output image has a LargestPossibleRegion with Index=0
and size = to the size of the user-specified region.
The origin is corrected so it matches the physical
position of the extracted image on top of the input
image. The spacing is passed untouched.
Luis
--------------------------------------
Miller, James V (Research) wrote:
> 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
>>
>>
>>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers
>