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

[Matt McCormick]

Hi Cyril,

Yes, thank you -- the new patch set looked good.  It got a few more
reviews here:

  http://review.source.kitware.com/#/c/19614/

including the suggestion to move the function to itk::ImageAlgorithm,
which is a good location that will also not run into any other
circular dependency conflicts.  Please see if the additional comments
can be addressed and if there is any trouble uploading the next patch
set.

Thanks,
Matt

On Tue, Apr 21, 2015 at 3:36 AM, Cyril Mory
<cyril.mory at creatis.insa-lyon.fr> wrote:
> 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
>>>>>
>>>>>
>