[Elastix] (no subject)

Tom Knoop t.h.knoop at student.utwente.nl
Thu May 8 08:50:25 CEST 2014

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:


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.



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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bigr.nl/pipermail/elastix/attachments/20140508/8f3556ea/attachment.html>

More information about the Elastix mailing list