[Elastix] (no subject)

Tom Knoop t.h.knoop at student.utwente.nl
Mon May 12 13:45:04 CEST 2014


Hi Stefan,

You where right, there was a problem with the voxel spacing. Once again, I
made a mistake assuming the aquisition of the data had gone according to
the protocol. In this case, the voxel size was a bit off (1.17 instead of
0.93 mm in-plane), which messed up the euler based registration. After I
made this parameter dynamic as well, the registration went as expected,
with acceptable SSD.

Thanks for your feedback, and for the time and effort you guys put into
this great program!

Best,

Tom


On Fri, May 9, 2014 at 1:18 PM, S. Klein <s.klein at erasmusmc.nl> wrote:

>  Hi Tom,
> Interesting. Are some of your CT scans perhaps made with gantry angle? If
> it is not taken into account in the direction cosines, it could explain a
> shearing transformation. Or perhaps a mistake is made somewhere with the
> voxel spacing in one of the images? That could explain why you need a
> global scaling.
>
> To investigate why affine gives so much better results than rigid, it
> could be good to inspect the parameters of the resulting affine
> transformation. Does the resulting affine transform matrix induce
> scaling/shearing? Or is it equivalent to a rigid transformation?
>
> Best,
> Stefan
>
>
> On 08/05/2014 08:50, Tom Knoop wrote:
>
> Dear Kasper, all,
>
>  Thank you for your suggestion. I am a bit hesitant to use affine
> transformations since I try to do intra-patient registrations, which should
> work with rigid transformations only. In the end (after I cleared another
> problem which had to do with me assuming the patient position was alwas
> feet first, thus messing up the dicom import into matlab I made), I build a
> workflow that performs a rigid transformation first, and if the final
> result is higher than a certain threshold, continues with a affine
> transformation. I am quite happy with the results, so thank you! I have
> included a visualisation for the registration process for both a failed and
> working rigid transformation, and the consecutive working affine
> transformation. I included the affine parameterfile I used as well. The
> files can be found here:
>
>  https://filesender.surfnet.nl/?vid=14ca4c6e-3339-6728-72d1-000055597207
>
>  This leaves me with the question why the rigid transformation does not
> work in all intra-patient cases. By the way, I tried to manually register
> some points, and do a multi metric transformation as well, this had no
> succes (although my makeshift landmark selection might have been a bit off
> as wel) If anyone has additional insights in this, I am very interested.
>
>  Best,
>
>  Tom
>
>
> On Sat, May 3, 2014 at 2:08 PM, Kasper Marstal <kaspermarstal at gmail.com>wrote:
>
>> Dear Tom,
>>
>>  I had the same problem when initializing registration of MRIs of heads
>> using a rigid transformation (I can see you have specified "EulerTransform"
>> in your parameter file). In my case, some heads would align nicely and
>> other would seem to get stuck in random places yet close to the solution.
>> This typically happens when you apply rigid transformations (scaling,
>> rotation, translation) to registrations where they cannot account for
>> anatomical differences between scans that violates this rigid body
>> assumption (fx in inter-patient registrations).
>>
>>  I solved my problem using an affine transform which also allows for
>> stretching and shearing of the deformation field. This typically works well
>> for bones. Use this transform by changing the line in your parameter file
>> from (Transform "EulerTransform") to (Transform "AffineTransform").
>>
>>  If you are feeling adventurous you might even consider subsequent
>> application of a non-rigid transform, such as the  (Transform
>> "BSplineTransform"), to capture the remaining differences near bone
>> edges that the affine transformation is unable to recover. This really
>> depends on the assumptions about your problem that you are willing to make
>> and/or sacrifice, however.
>>
>>  Let us know how it goes!
>>
>>  Cheers,
>> Kasper
>>
>>
>>  On 30 April 2014 12:10, Tom Knoop <t.h.knoop at student.utwente.nl> wrote:
>>
>>>  Dear All,
>>>
>>>  I am trying to register the long bones in the leg (femur) in multiple
>>> CT scans of the same patients. There are a number of reasons to do this,
>>> but one of them is that I would like to get a segmentation of the
>>> consecutive femurs by transforming the femur segmentation I made for the
>>> first image to the other images in the series. Because the rotation of the
>>> legs are different in every image, I do this per femur
>>>
>>>  To do this, I use the segmentation of the first image as a fixed mask,
>>> and mask out the controlateral side of the body in my moving mask. I have
>>> build a parameter file that uses AdvancedMeanSquares metric and five
>>> smoothing steps with a high number of iterations to make the process more
>>> robust. See also parameterfile rigid_bone_forward.txt in the zip-file which
>>> you can find at the download-link here:
>>> https://filesender.surfnet.nl/?vid=1dbe6839-ef04-b228-03e8-00001a643b33
>>>
>>>  This works fine for most of my images, with final SSD of around 5000.
>>> However, on some images, the registration just doesn't seem to work. It
>>> does get in the right direction (the femurs definitely have more overlap
>>> after the registration than before) but the voxel-accuracy I normally get
>>> is never reached. I have tried fooling around with the sp_A parameters and
>>> the resolution steps and maximum stepsizes, but to no avail. Also in the
>>> zip file are the logfiles of a successfull and failed registration.
>>>
>>>  Unfortunately, I cannot share the scans themselves. However, it are CT
>>> scans of the lower body (containing complete femurs, and part of the knee
>>> joint and pelvis) made on an philips brilliance big bore scanner, with a
>>> resolution of 512x512x±210 voxels with a voxel size of .9375x.9375x3mm. The
>>> images are saved as mhd double datafiles, with their anatomical position
>>> taken from the original dicom data. masks are saved as binary mhd files.
>>>
>>>  Has anyone have any idea about where this goes wrong? Visually, I do
>>> not see a difference between the failed and succesfull scans. It is
>>> possible that a single scan fails, while another scan for the same patient
>>> does register succesfully. What can I do to make this more robust?
>>>
>>>  Many thanks for your help!
>>>
>>>  Best,
>>>
>>>  Tom
>>>
>>>  _______________________________________________
>>> Elastix mailing list
>>> Elastix at bigr.nl
>>> http://lists.bigr.nl/cgi-bin/mailman/listinfo/elastix
>>>
>>>
>>
>> _______________________________________________
>> Elastix mailing list
>> Elastix at bigr.nl
>> http://lists.bigr.nl/cgi-bin/mailman/listinfo/elastix
>>
>>
>
>
> _______________________________________________
> Elastix mailing listElastix at bigr.nlhttp://lists.bigr.nl/cgi-bin/mailman/listinfo/elastix
>
>
> --
> Stefan Klein+31 10 7043442http://www.bigr.nl/people/StefanKlein
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bigr.nl/pipermail/elastix/attachments/20140512/3495d8fb/attachment.html>


More information about the Elastix mailing list