[Insight-users] multi-modality with FEM or with Demons ? : BSplineTransform
Luis Ibanez
luis.ibanez@kitware.com
Sat May 15 17:19:14 EDT 2004
Hi Hari,
Thanks for letting us know that you found the problem.
You could have avoided of this trouble by using the
itk::Vector and itk::Point classes in the right way.
Instead of
displacement[0] = movingPoint[0] - fixedPoint[0];
displacement[1] = movingPoint[1] - fixedPoint[1];
displacement[2] = movingPoint[2] - fixedPoint[2];
You simply should do:
displacement = movingPoint - fixedPoint;
The "operator-()" is defined in the itk::Point class and
returns an itk::Vector of the appropriate dimension.
That's, after all, the advantage of using C++ classes for
representing Points, Vectors and CovariantVectors instead
of using plain C arrays.
The expression above will work for any arbitrary Dimension.
You may find useful to read the Doxygen documentation
of the itk::Point
http://www.itk.org/Insight/Doxygen/html/classitk_1_1Point.html
as well as the itk::Vector
http://www.itk.org/Insight/Doxygen/html/classitk_1_1Vector.html
Regards,
Luis
-------------------
Hari Sundar wrote:
> Hi,
>
> Thanks for all the input. I figured out the problem, and it was my
> fault. I guess we were all looking at the wrong place. The problem
> comes from the fact that we calculate the explicit displacement field
> .... see code ...
>
> Thanks for all the help.
> -Hari
>
> // CODE
>
> while( ! fi.IsAtEnd() )
> {
> index = fi.GetIndex();
> field->TransformIndexToPhysicalPoint( index, fixedPoint );
> movingPoint = transform->TransformPoint( fixedPoint );
> displacement[0] = movingPoint[0] - fixedPoint[0];
> displacement[1] = movingPoint[1] - fixedPoint[1];
> // displacement[2] = movingPoint[2] - fixedPoint[2]; // Need to add ...
> fi.Set( displacement );
> ++fi;
> }
>
> // END-CODE
>
> On Fri, 14 May 2004 23:05:40 -0400, Luis Ibanez <luis.ibanez@kitware.com> wrote:
>
>>
>>Hi Hari,
>>
>>Your test certainly demonstrates that the
>>third component is being computed as zero... :-/
>>
>>Please send me the code that you used for generating
>>this vector field, and if you are using FEM, please
>>send me the parameters file too.
>>
>>
>>
>> Thanks
>>
>> Luis
>>
>>------------------
>>
>>Hari Sundar wrote:
>>----------
>>
>>>Hi Luis,
>>>
>>>Yes the Glyph orient mode is set to vector. I used the calculator and
>>>used the resulting image to drive the glyphs. The Image_0 and Image_1
>>>components are all right. The Image_2 component is Zero as expected.
>>>
>>>I also extracted the Z components from the file and checked that it
>>>was indeed zero.
>>>
>>>Is it possible that the grid is being fashioned as a large tiled 2D
>>>image instead of a 3D image ?
>>>
>>>Is there anything I can do to verify this ?
>>>
>>>thanks,
>>>-Hari
>>>
>>>On Fri, 14 May 2004 19:59:39 -0400, Luis Ibanez <luis.ibanez@kitware.com> wrote:
>>>
>>>
>>>>Hi Hari,
>>>>
>>>>Thanks for the details on ParaView.
>>>>
>>>>Yeap 1.2 is fine, that's the release version.
>>>>
>>>>Did you check if the Glyph filter had the option
>>>>"Orient/Scale"
>>>>
>>>> Orient Mode = Vector
>>>>
>>>>You can check also the content of the third component
>>>>of your deformation field by selecting ImageFile_2 in
>>>>the calculator, and clicking in the red "Accept" button.
>>>>
>>>>This will create an image whose pixels have the values
>>>>of the third component in the input image.
>>>>
>>>>If the image comes out with an uniform color... then
>>>>we will have to conclude that the third component is
>>>>actually null....
>>>>
>>>>Please let us know what you find,
>>>>
>>>> Thanks
>>>>
>>>>
>>>>
>>>> Luis
>>>>
>>>>-------------------
>>>>
>>>>Hari Sundar wrote:
>>>>
>>>>
>>>>
>>>>>Hi Luis,
>>>>>
>>>>>I am using Paraview 1.2 on linux.
>>>>>Yes, it shows three scalar components, ImageFile_0, ImageFile_1 and ImageFile_2
>>>>>
>>>>>thanks,
>>>>>-Hari
>>>>>
>>>>>On Thu, 13 May 2004 14:23:04 -0400, Luis Ibanez <luis.ibanez@kitware.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Hi Hari,
>>>>>>
>>>>>>What version of ParaView are you using ?
>>>>>>
>>>>>>Could you please do the following test:
>>>>>>
>>>>>>1) Load in ParaView the MetaImage containing
>>>>>> the Deformation field.
>>>>>>
>>>>>>2) Then click on the icon that has Calculator,
>>>>>> (or select Filter -- > Calculator).
>>>>>>
>>>>>> When it appears, the GUI of the calculator
>>>>>> will have a menu-choice on the bottom left
>>>>>> that says "Scalars". Please click on it
>>>>>> and let us know what it shows.
>>>>>>
>>>>>> If the loaded dataset has three components,
>>>>>> this menu-choice will display:
>>>>>>
>>>>>> ImageFile_0
>>>>>> ImageFile_1
>>>>>> ImageFile_2
>>>>>>
>>>>>> if the field only has two components, you
>>>>>> will only see
>>>>>>
>>>>>> ImageFile_0
>>>>>> ImageFile_1
>>>>>>
>>>>>> Please let us know what you find.
>>>>>>
>>>>>>--
>>>>>>
>>>>>>About your question:
>>>>>>
>>>>>>The physical extent of the deformation is
>>>>>>defined by the BSpline grid. If you are
>>>>>>observing that it is limited to a restricted
>>>>>>region of the image, that means that your
>>>>>>configuration of the BSpline grid need some
>>>>>>adjustment. Note that the BSpline grid also
>>>>>>has an spacing. For example if you want the
>>>>>>BSpline grid to be such that there are N
>>>>>>image pixels between two BSpline grid points,
>>>>>>then you must set the spacing of the BSpline
>>>>>>grid to be N * image_pixel_spacing.
>>>>>>
>>>>>>Note also that this flexibility of the BSpline
>>>>>>is sometimes desirable, since it lets you
>>>>>>focus on a small region of the image that
>>>>>>is the only place where you expect deformations
>>>>>>to occur. However this is not an efficient
>>>>>>way of working, given that you still compute
>>>>>>the registration over *all* the pixels of the
>>>>>>fixed image, not just those over the BSpline
>>>>>>grid. For this reduction to make sense, you
>>>>>>should sync the extent of the FixedImageRegion
>>>>>>with the physical extent of the Bspline grid.
>>>>>>
>>>>>>To put it short: please check the physical
>>>>>>extent of the BSpline grid and compare it to
>>>>>>the physical extent of your fixed image.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Luis
>>>>>>
>>>>>>--------------------
>>>>>>Hari Sundar wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi Luis,
>>>>>>>
>>>>>>>The deformation field has 3 components per pixel. The glyphis set to
>>>>>>>use the vector for orientation. I have attached 2 images to show you
>>>>>>>what I mean.
>>>>>>>
>>>>>>>Also another small question. Why is the deformation field limited to a
>>>>>>>smaller section of the actual volume dimensions (Bounding box vs.
>>>>>>>where the deformation field != 0 ).
>>>>>>>
>>>>>>>The parameters are obtained from the fixedImage, so shouldn't it cover
>>>>>>>the whole volume ?
>>>>>>>
>>>>>>>thanks,
>>>>>>>-Hari
>>>>>>>
>>>>>>>On Thu, 13 May 2004 10:05:26 -0400, Luis Ibanez <luis.ibanez@kitware.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>Hi Hari,
>>>>>>>>
>>>>>>>>Please check the content of the MetaImage header to
>>>>>>>>see if the deformable registration program is actually
>>>>>>>>writing 3 components per pixel.
>>>>>>>>
>>>>>>>>Note that in Paraview you have to make sure that the
>>>>>>>>Glyph filter, on its Orient/Scale frame has the
>>>>>>>>Orientation option is set to "Vector".
>>>>>>>>
>>>>>>>>--
>>>>>>>>
>>>>>>>>Multi-res will imply to subsample your original image.
>>>>>>>>The evaluations of the metric are still done over *all*
>>>>>>>>the pixels of the original image. The BSpline transform
>>>>>>>>is used here as any other basic transform.
>>>>>>>>
>>>>>>>>Please read the Chapter on image registration in the
>>>>>>>>SoftwareGuide, There is a full section on how to setup
>>>>>>>>the Multi-Resolution framwork.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>Regards,
>>>>>>>>
>>>>>>>> Luis
>>>>>>>>
>>>>>>>>---------------------
>>>>>>>>Hari Sundar wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>Hi Luis,
>>>>>>>>>
>>>>>>>>>I ran it for 50 iterations. It did not converge, but should have
>>>>>>>>>reached somewhere. I'll try and run it till convergence anyway. I
>>>>>>>>>visualized the resulting deformation field in paraview and all the
>>>>>>>>>vectors seem to be parallel to the XY plane. That's why I am saying
>>>>>>>>>that there is no Z component.
>>>>>>>>>
>>>>>>>>>Multi res in this case would be the number of nodes in the bSpline
>>>>>>>>>grid, right ? But then even the 5x5x5 grid seems to take forever. How
>>>>>>>>>do I structure the multi-res approach ?
>>>>>>>>>
>>>>>>>>>thanks,
>>>>>>>>>-Hari
>>>>>>>>>
>>>>>>
>>>>>>
>>
>
More information about the Insight-users
mailing list