[ITK-users] Smallest region containing the physical space covered by another image's region

[Cyril Mory]

Hi Matt,

I had already done the push when I sent you the mail. Running "git 
gerrit-push" now fails with the error "No new changes", so I suppose the 
push went fine.
Let me know if something didn't go as expected.

Thanks a lot for your help,
Cyril

On 04/16/2015 05:18 PM, Matt McCormick wrote:
> Hi Cyril,
>
> Excellent, thanks for the update!
>
> Yes, avoiding the circular dependency between ImageBase and
> ImageRegion could be tricky.  Please push what you have.  I may take a
> shot at getting around the circular dependency.
>
> Thanks,
> Matt
>
> On Thu, Apr 16, 2015 at 5:03 AM, Cyril Mory
> <cyril.mory at creatis.insa-lyon.fr> wrote:
>> Hi Matt,
>>
>> Thank you for your detailed comments. I fixed most of the issues you spotted
>> and amended the patch. Unfortunately, I was unable to move the method to
>> itkImageRegion: from there I could not use the itkImageBase methods
>> TransformIndexToPhysicalPoint and TransformPhysicalPointToIndex.
>>
>> I am note familiar with forward declarations, friend classes and how they
>> are meant to be used, so maybe it was possible indeed and I just did it
>> wrong.
>>
>> Cyril
>>
>>
>> On 04/15/2015 07:22 PM, Matt McCormick wrote:
>>> Hi Cyril,
>>>
>>> Thanks for contributing the patch!
>>>
>>> I added a comments for some minor things on Gerrit.  If it is more
>>> convenient to do the computations manually than use BoundingBox, that
>>> is fine. In terms of where to put it, the ImageRegion class may be a
>>> better spot than ImageBase since there already are the PadByRadius,
>>> ShrinkByRadius, and Crop methods. In terms of the name, perhaps
>>> EnlargeOverBox or similar may be better. This is not a Get method like
>>> other Get'ers, we avoid the passive 'ing verb, and Box or something
>>> similar indicates we have done the computation in physical space
>>> instead of index space, which "Region" may imply.
>>>
>>> Thanks,
>>> Matt
>>>
>>> On Wed, Apr 15, 2015 at 7:23 AM, Cyril Mory
>>> <cyril.mory at creatis.insa-lyon.fr> wrote:
>>>> Hi Matt,
>>>>
>>>> I have added such a method to itkImageBase, it is called
>>>> GetSmallestRegionContainingRegion. The patch is submitted on a branch
>>>> with
>>>> the same name. I made my best, but I think it will require more
>>>> improvements
>>>> than the previous one before it can get merged.
>>>>
>>>> In particular, I haven't used the itk::BoundingBox class, because from
>>>> its
>>>> description it seems to handle only itk::Point. Should I convert indexes
>>>> to
>>>> points, run the BoundingBox calculation, and convert back ?
>>>>
>>>> I'll wait for the comments
>>>> Cyril
>>>>
>>>>
>>>> On 04/13/2015 09:12 PM, Matt McCormick wrote:
>>>>> Hi Cyril,
>>>>>
>>>>>> I am preparing a patch for the itkWarpImageFilter, and I came to
>>>>>> realize
>>>>>> that computing the requestedRegion of the inputs from the output's
>>>>>> requested
>>>>>> region is non trivial.
>>>>> Great job on the patch submission! :-)
>>>>>
>>>>>
>>>>>> - the displacement in the deformation field can be very large, in any
>>>>>> direction, ... therefore there is no choice but to load the full input
>>>>>> image
>>>>>> into memory (unless we want to go through the whole deformation field
>>>>>> to
>>>>>> evaluate the maximum displacement, but in a method like
>>>>>> GenerateInputRequestedRegion we do not want such heavy processing)
>>>>>> => Input image's requested region should be the largest possible region
>>>>> Yes, this is a good assessment.
>>>>>
>>>>>
>>>>>> - the requested region in the deformation field, on the other hand, can
>>>>>> be
>>>>>> computed. But it is not trivial. If the output and the DF have
>>>>>> identical
>>>>>> information (spacing, origin, direction), then the requested region in
>>>>>> the
>>>>>> DF should be copied from the output. If their information differs,
>>>>>> computing
>>>>>> the requested region would require a method to compute the smallest
>>>>>> rectangular region that contains the physical space covered by an other
>>>>>> image's region, the other image having (potentially) a different
>>>>>> spacing,
>>>>>> origin and/or direction. Does such a method exist somewhere in ITK ?
>>>>> A possible approach here could transform all corner indexes of the
>>>>> output to physical space points, transform physical points to index
>>>>> space of the DF, and compute a bounding box of these index points.
>>>>>
>>>>> The methods to apply could be
>>>>>
>>>>>      TransformIndexToPhysicalPoint
>>>>>      TransformPhysicalPointToIndex
>>>>>
>>>>> on the ImageBase class and the itk::BoundingBox class.
>>>>>
>>>>>
>>>>> HTH,
>>>>> Matt
>>>>