[Insight-users] Re: Registration Validation using Thin Plate Spline
Warp
Luis Ibanez
luis.ibanez at kitware.com
Mon Oct 16 20:12:29 EDT 2006
Hi Kevin,
Thanks for sending your recent findings on this problem.
I think that we have to abandon the notion that there is
a "perfect registration". There is no reason to expect
that a deformable registration should actually have a
solution, much less a perfect one.
I would rather see this in a more pragmatic way:
Find a deformation fields (or a transform) that optimizes
some property, given some constrains. That is, get the
best you can, at a price you are willing to pay.
The concept that there is a "right solution" is to
"Journal-Paper"-minded and lacks realism. It is only
useful for vanity claims.
The rule of thumb that a good registration must be completed
in less than 50 iterations, seems too arbitrary. It all depends
on how long you makes the steps of your iterations, and how
stable the conditions are.
What I would suggest is to get away from the notion of
the "correct answer" and rather move into an engineering
approach, where you are looking for trade-offs in costs
versus quality of solutions.
Regards,
Luis
------------------
Kevin Ming wrote:
> Hi again Luis,
>
> Here's what I've found recently regarding my previous question: After
> trying out 3 types of warping on 3 different synthetic data, it seems to
> me that the success of the registration deformation is largely dependent
> on the "completeness" of registration. By completeness I mean if
> near-perfect registration can be completed within 50 iterations or less,
> than the resultant deformation looks similar to the original warp (eg.
> warping in +y direction results in registration deformation field with
> mostly +y components and some +/-x components), otherwise the resultant
> deformation just doesn't make sense at all. In retropect, I suppose,
> this seems to be common sense.
>
> What are your thoughts, suggestions?
>
>
> Thank you,
> Ming
>
>
> On 10/2/06, *Kevin Ming* <ming.kevin at gmail.com
> <mailto:ming.kevin at gmail.com>> wrote:
>
> Hi Luis,
>
> So you think the problem lies in the deformation field generation
> and visualization, and not in the registration? I tend to agree
> with you as the registration output came out near-perfectly.
> However, is it also possible that the deformable registration
> algorithm has deformed the input image so much that, while the
> output looks like the way it should, the actual deformation itself
> is physically unfeasible; and as a result, the deformation field
> came out to be incorrect?
>
> Actually, I've recently discovered an obscurity with visualizing
> deformation fields in ParaView: I could simply tell ParaView to
> generate the glyphs with the original .mhd file as input, without
> having to go through the Calculator function. In fact, as you've
> suggested, I tried to look at the different components of the
> deformation field using the Calculator, but the glyphs generation
> all came out to be the same - the supposed final deformation field
> with all components incorporated.
>
> I'm uploading to you the following files relevant to the problem,
> with the title "Kevin Ming - Registration Validation Problem".
> This'll hopefully make your life easier than if I were to simply
> describe everything to you:
>
> MyDefReg3D_LevelSet.cxx - my version of the level set deformable
> registration algorithm, which includes the orginal/default version
> of the code for deformation field generation
>
> synth_warp_field.mhd / synth_warp_field.raw - the deformation field
> resulting from the the Thin Plate Spline Warp algorithm, the one
> corresponding to the landmark specifications I've provided last on
> my last email
>
> synth_warp_field_reg.mhd / synth_warp_field_reg.raw - the
> deformation field resulting from the level set registration
> algorithm, the input moving image being the deformed image resulting
> from the Thin Plate Spline Warp algorithm
>
>
> Thank you,
> Kevin
>
>
> On 10/1/06, *Luis Ibanez* < luis.ibanez at kitware.com
> <mailto:luis.ibanez at kitware.com>> wrote:
>
>
> Hi Kevin,
>
> There are two independent problems in your email:
>
> 1 - Does the registration Work ?
> 2 - Does the visualization of the Deformation Field Work ?
>
>
>
> About 1:
>
> It is normal that a LevelSet deformable registration algorithm
> cannot replicate the deformation induced by the KernelTransform.
>
> There is no reason to expect that the LevelSet propagation can
> be equivalent to the set of kernels that the KernetlTransform
> used. You can expect, however, that a good approximation may be
> achieved.
>
>
> About 2:
>
> Something is wrong on the way the deformation field is being
> passed to Paraview. You should check the content of the different
> components of the deformation field. For this purpose you could
> use the "Calculator" in Paraview, for extracting each one of
> the components and verifying they range of values.
>
> If the deformation of the original image was corrected, then
> your deformation fields was probably correct, and there is
> only a problem in the process of saving the deformation field
> to a file, and then loading it in ParaView.
>
> What code are you using for writing the deformation field to a
> file ?
>
>
>
> Please let us know,
>
>
> Thanks
>
>
> Luis
>
>
> ----------------
> Kevin Ming wrote:
>> Hi,
>>
>> I've created a synthetic image, deformed in the y direction
> according to
>> the following landmarks:
>>
>> Source Target
>> x y z x y z
>> 55 43 01 55 43 01
>> 30 35 01 30 35 01
>> 33 56 01 33 56 01
>>
>> 55 43 08 55 43 08
>> 30 35 08 30 35 08
>> 33 56 08 33 56 08
>>
>> 55 43 30 55 44 30
>> 30 35 30 30 36 30
>> 33 56 30 33 57 30
>>
>> But when I applied the level set deformable registration, even
> though
>> the output came out near-perfectly, the deformation field does
> not match
>> that produced from the warping at all; all the vectors/glyphs
> point in
>> the +/- z direction, none in the y direction. I've not made any
>> modifications to the warping algorithm than was originally
> provided by
>> ITK, and I use ParaView to visualize the deformation field as per
>> described in the software guide, what could have happened?
>>
>>
>> Thank you,
>> Kevin
>
>
>
>
More information about the Insight-users
mailing list