[Insight-users] grid spacing with BSplineDeformableRegistration

Luis Ibanez luis.ibanez at kitware.com
Tue Nov 30 22:46:30 EST 2004


Hi Kristina,

Thanks a lot for your detailed analysis.

I see your point now.

You are right, we certainly want to have the BSpline
grid extent to exceeds the image extent in the borders.
In that regard, the solution (a) is the correct one.

Keep in mind however that if we were using a BSpline
grid where the spacing is an integer multiple of the
image spacing, we will have the possibility of precomputing
the BSpline coefficients for the entire image, since the
first BSpline cell will be geometrically replicated over
the rest of the grid.  Currently we are not taking
advantage of this optimization possibility, but it is
something that some groups have been looking into.


Note also that there is an option (C), which is not to
apply floor() at all.  This option is needed in the case
the pixel spacing is so small that the truncation may cut
the value to zero.  For example:


    Pixel spacing = 0.001
    Number pixels = 44
    Grid nodes on the image = 10
    Total grid nodes = 13

        floor(  0.001 * (44-1)/(10-1) )
      = floor(  0.001 * 4.777 )
      = floor(  0.004.777 )
      = 0


After all,...
there is no need for the pixel spacing to be an integer.

Please let us know if you find option (C) to be reasonable.


Regarding your second question:

The number of BSpline nodes that you need outside of the image
increases in direct relationship with the order of the BSpline.
This is because this excess number is related to the size of
the BSpline support.

Therefore if you were using BSplines of order 4 you will need the
grid to exceed the image by 4 grid pixels.

You may want to look at this analysis in the Image Registration
course presented at RPI:

     http://www.cs.rpi.edu/courses/spring04/imagereg/

In particular to Lecture 26:

http://www.cs.rpi.edu/courses/spring04/imagereg/lectureBSplines.ppt


This lecture describes some of the principles of BSplines as
a transform in the registration framework.



   Regards,


       Luis



------------------------
Kristina Grunewald wrote:

> Hi Luis,
> 
> thanks for your reply.
> 
> I thought the first solution was better because when doing it the other
> way, the grid image doesn't overlap the fixed image.
> 
> If we consider the following case:
> fixed image size = 44
> fixed image spacing = 4
> fixed image origin = 0
> 
> number of grid nodes within the image support = 10
> number of grid nodes
>   = 13 (after having added the 3 due to spline order 3)
> 
> Then the first solution leads to
> a)
> grid spacing = 19
> grid origin = -19
> The grid image then ranges from its origin to
> (-19 + (numberOfGridNodes -1) * spacing) = 209
> 
> and the second to:
> b)
> grid spacing = 16
> grid origin = -16
> The grid image then ranges from its origin to
> (-16 + (numberOfGridNodes -1) * spacing) = 176
> 
> The fixed image ranges from 0 to 44*4 = 176
> 
> So in b) the spatial extent of the grid image doesn't exceed the spatial
> extent of the fixed image, as we intended it to.
> 
> 
> This leads me to another question:
> what number is to be added to the number of grid nodes within the image
> support when using a bspline order different from 3?
> 
> 
> Thanks a lot,
> Kristina
> 
> 
> 
> 
> Luis Ibanez wrote:
> 
>>
>> Hi Kristina,
>>
>>
>> Thanks for pointing this out.
>>
>> I would rather suggest you to use the second solution,
>> since the purpose of the spacing computation is not
>> to end up with an integer spacing in the BSpline grid,
>> but to make sure that the spacing of the BSpline grid
>> is an integer multiple of the image spacing.
>>
>> We should fix the computation in the BSplineWarping1.cxx
>> example, since it will work badly if somebody uses an
>> input image with pixel spacing = 0.001, and a BSpline
>> grid that has 1 image pixels per grid square. (e.g. the
>> grid spacing in that case will be wrongly computed
>> as == zero ).
>>
>>
>> Please let us know if you have further questions,
>>
>>
>>
>>    Thanks
>>
>>
>>       Luis
>>
>>
>>
>> --------------------------
>> Kristina Grunewald wrote:
>>
>>> Hello,
>>>
>>> I found two different ways how to compute the spacing of a bspline 
>>> grid transform in the existing code.
>>> In Examples/Registration/BSplineWarping1.cxx it is done like that:
>>>
>>> spacing[x] = floor( fixedSpacing[x] * (fixedImageSize[x] - 1) / 
>>> (gridSizeOnImage[x] - 1) );
>>>
>>> Whereas in Examples/Registration/DeformableRegistration4.cxx like:
>>>
>>> spacing[x] = fixedSpacing[x];
>>> spacing[x] *= floor( static_cast<double>(fixedImageSize[x] - 1)  /
>>>      static_cast<double>(gridSizeOnImage[x] - 1) );
>>>
>>> The rounding in the first case is done after having multiplied with 
>>> the fixed image spacing, in the latter before.
>>> This may result in different values, set fixedImageSize[x] = 44, 
>>> fixedSpacing[x] = 4, and gridSizeOnImage[x] = 10.
>>>
>>> I prefer the first solution but I am not quite sure whether this is 
>>> correct.
>>>
>>> Thanks,
>>> Kristina
>>> _______________________________________________
>>> Insight-users mailing list
>>> Insight-users at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-users
>>>
>>>
>>
>>
>>
>>
> 
> 
> _______________________________________________
> Insight-users mailing list
> Insight-users at itk.org
> http://www.itk.org/mailman/listinfo/insight-users
> 
> 





More information about the Insight-users mailing list