[Insight-developers] [Insight-users] LevelsetMotionRegistrationImageFilter

[Luis Ibanez]

Hi Kishore,

I think we have found a fix for the problem that your
reported:

   http://public.kitware.com/Bug/view.php?id=9709

In summary:

The tkFiniteDifferenceImageFilter now uses the Output
image, instead of the Input image, as the source for
the Spacing parameters.

In this way, the process should work even for the uses
of this filter in which a NULL input has been passed
to the filter.

The fix has been committed, and the new test is now
passing in my local build.


If you have a chance,
could you please update your ITK CVS checkout
and  try again a build of your application ?

and...

Please let us know how it goes



    Thanks


         Luis



-----------------------------------------------------------
On Sat, Oct 17, 2009 at 5:43 PM, Luis Ibanez <luis.ibanez at kitware.com> wrote:
> Hi Kishore,
>
> Thanks for pointing this out,
> and for filing the bug report.
>
> Unfortunately this class don't even have a test.
> So, we have started by adding a test for it,
> (mostly based on the test of the Demons filter).
>
> You will find this new test under:
>
> Insight/Testing/Code/Algorithms/
>               itkLevelSetMotionRegistrationFilterTest.cxx
>
>
> This test is running the filter with the method
>
>           UseImageSpacingOn()
>
> and we don't observe a segmentation fault as a
> consequence.
>
> .....
>
> In your email you say that the member variable
>
>                    this->m_Input,
>
>>> is a vector of 3 image pointers.
>
>
> For what I can see in this filter, the Input variable
> is actually of the same type as the InputImage
> type used for instantiating the filter.
>
>
> Could you provide a minimal example illustrating
> the situation in which you see that the m_Input
> variable is an array of images  ?
>
>
>     Thanks
>
>
>           Luis
>
>
> -----------------------------------------------------------
> On Tue, Oct 13, 2009 at 7:36 PM, Kishore Mosaliganti
> <kishoreraom at gmail.com> wrote:
>> To add to the below problem, I initialized the filter with a 0 vector
>> deformation field. Now, the filter executes with ImageSpacingOn().
>> However, the metric values with iterations are not influenced by the
>> ImageSpacingOn option.
>>
>> This makes me believe the underlying implementation is not using the
>> image spacings.
>>
>> Kishore
>>
>> On Tue, Oct 13, 2009 at 7:13 PM, Kishore Mosaliganti
>> <kishoreraom at gmail.com> wrote:
>>> Hi all,
>>>
>>> I was using the LevelsetMotionRegistrationImageFilter to register two
>>> 3D image datasets whose voxels have anisotropic spacing:
>>>
>>>  RegistrationFilterType::Pointer filter = RegistrationFilterType::New();
>>>  CommandIterationUpdate::Pointer observer = CommandIterationUpdate::New();
>>>  filter->AddObserver( itk::IterationEvent(), observer );
>>>  filter->SetFixedImage( fixedImage );
>>>  filter->SetMovingImage( movingImage );
>>>  filter->SetNumberOfIterations( 50 );
>>>  filter->SetGradientSmoothingStandardDeviations( 0.1 );
>>>  filter->UseImageSpacingOn();
>>>  filter->Update();
>>>
>>> The problem is I get a Segmentation fault when I turn on
>>> UseImageSpacingOn(). Otherwise, the filter executes normally.
>>>
>>> I used the debugger and went into the code.
>>> LevelsetMotionRegistrationImageFilter is a sub-class of
>>> PDEDeformableRegistrationImageFilter which is a subclass of
>>> FiniteDifferenceImageFilter. The code failed in the
>>> FiniteDifferenceImageFilter::GenerateData() method in the following
>>> lines:
>>>
>>> ....
>>>
>>> if (this->GetState() == UNINITIALIZED)
>>>    {
>>>    // Set the coefficients for the deriviatives
>>>    double coeffs[TInputImage::ImageDimension];
>>>    if (m_UseImageSpacing)
>>>      {
>>>      for (unsigned int i = 0; i < TInputImage::ImageDimension; i++)
>>>        {
>>>        coeffs[i] = 1.0 / this->GetInput()->GetSpacing()[i];
>>>        }
>>>      }
>>>    else
>>>      {
>>>      for (unsigned int i = 0; i < TInputImage::ImageDimension; i++)
>>>        {
>>>        coeffs[i] = 1.0;
>>>        }
>>>      }
>>>
>>> .....
>>>
>>> When I went to see the state of the input pointer, this->m_Input, it
>>> is a vector of 3 image pointers. Basically, this->m_Input[1] refers to
>>> the fixed image and this->m_Input[2] refers to the moving image.
>>> this->m_Input[0] is NULL. this->m_Input[0] is supposed to contain the
>>> initial deformation field which is not a prerequisite for running the
>>> code.
>>>
>>> The code in itkPDEDeformableRegistrationImageFilter::SetFixedImage()
>>> and itkPDEDeformableRegistrationImageFilter::SetMovingImage() call
>>> this->ProcessObject::SetNthInput( 1, const_cast< FixedImageType * >(
>>> ptr ) ) and this->ProcessObject::SetNthInput( 2, const_cast<
>>> FixedImageType * >( ptr ) ) respectively.
>>>
>>> This filter derives from
>>> ImageToImageFilter<TDeformationField,TDeformationField> but the vector
>>> of inputs have been set as scalar-valued fixed and moving image
>>> pointers. Also, for the case when the initial deformation field is
>>> unknown, the FiniteDifferenceFilter is checking for the first input
>>> which doesn't exist.
>>>
>>> I have filed a bug report:
>>> http://public.kitware.com/Bug/view.php?id=9709
>>>
>>>
>>>
>>> Thanks,
>>> Kishore
>>>
>> _____________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the ITK FAQ at: http://www.itk.org/Wiki/ITK_FAQ
>>
>> Follow this link to subscribe/unsubscribe:
>> http://www.itk.org/mailman/listinfo/insight-users
>>
>