[Insight-users] Spline smoothing distance and N4ITK parameters

[Andriy Fedorov]

Nick,

This is a great clarification, thanks! Without having any experience
with using N3MNI, I can now appreciate the value of this contribution!
I had enough issues from the little I have done putting FSL tools as
part of a workflow for evaluation. It's really great that I don't need
to go down the same path with N3MNI.

Now that I have more confidence that I understand the impact of
parameter selection, I will continue using your tool hopefully in a
more educated way. I will update the IJ page if I have any results
that deserve wider attention.

Andriy Fedorov


On Fri, Sep 4, 2009 at 11:19, Nicholas Tustison<ntustison at gmail.com> wrote:
>> I do have a couple of hopefully quick clarification questions. Can you
>> elaborate on these?
>
> Yeah, no problem.
>
>> 1) in the paper, you describe the default settings to have [4,4,4]
>> control points (for 3d image) and 4 fitting levels. So, as I
>> understand, you will have 4x4x4 -> 16x16x16 -> 64x64x64 -> 256x256x256
>> spline mesh elements!!! Can this be right, or I did not get your
>> explanation right?
>
> No, there's a difference between the B-spline mesh and the control point
> grid but they're related by the simple relationship
>
> number of b-spline elements = number of control points - spline order
>
> So, when we start with 4 control points in every parametric dimension and
> cubic basis functions, the number of elements = 4x4x4 - 3 = 1x1x1.  The
> resolution level doubling for every level refers to the the b-spline mesh
> grid and not the control point grid although, as you can see, there's a
> simple relationship between the two.
>
>> 2) is this correct to think that by choosing just one fitting level,
>> and selecting the number of control points to be something like
>> [imageSize*imageSpacing/splineDistanceFromN3MNI,...] one might expect
>> to get somewhere close to replicating the behaviour of N3MNI with the
>> given "splineDistance" value?
>
> Yeah, sort of.  I imagine that this would be an approach that would get
> closest to mimicking the behavior of N3MNI although not having performed any
> relevant experiments, I can't say how close the performance would be.   So
> one of the thoughts I had was to actually accommodate a SetSplineDistance()
> function by changing the parametric domain to not be identical with the
> spatial domain of the input image.  However, in trying to do something like
> this the code quickly degrades in terms of its elegancy and there's added
> computational costs.
>
>> I understand your motivation for using the improved version of spline
>> fitting.
>>
>> But I also think that it will be essential for wider adoption of this
>> tool to be able to provide mapping, or precise instructions on how to
>> select the parameters to reproduce the behaviour of N3MNI with given
>> settings. N3MNI is already part of established workflows, and it has
>> been studied in a number of publications. It would be wonderful to be
>> able to learn and benefit from all these great publications...
>
> The problem is that there is no precise mapping between the choice of
> smoothing strategies (an additional complication is the explicit
> regularization term modulated by omega which is nonlinearly related to the
> spline distance).  Additional motivation for foregoing a SetSplineDistance()
> option is that I didn't want to give people the illusion that somehow they
> should be getting identical behavior when using N3MNI and comparing it with
> N4ITK.
>
> The publications are important but what is it the take-home message of these
> publications with respect to the spline distance---is it that there is a
> single spline distance or set of spline distances which works "best" for all
> scenarios or a set of scenarios or is it the more general observation that
> locality affects the solution?  Since there is no direct mapping between
> smoothing strategies, it would seem that only the latter observation would
> be relevant for users of N4ITK which is what I remember from reading the
> publications.  However, it's been awhile since I've looked at those
> publications so I could be wrong.
>
> As regards wider adoption---you're absolutely right in that N3MNI is already
> part of established workflows and for such groups it might be easiest to
> continue to use N3MNI.  Interestingly enough the entire motivation for
> developing N4ITK was exactly because some of my colleagues were trying to
> integrate N3MNI into our lab's brain image processing pipeline.
>  Unfortunately, my colleagues encountered two major difficulties while
> trying to do this:  1) N3MNI, as a set of perl scripts, was particularly
> difficult to set up in terms of its dependencies and 2) the mnc file format
> gave us all kinds of problems.     N3 is such a beautiful algorithm in terms
> of its performance that we either had to push on to get N3MNI to work or try
> to create our own implementation.  Granted these are all difficulties due
> to, most likely, deficiencies on our part but when you actually try to look
> at the N4ITK code to understand what's going on with the N3 algorithm as
> well as the support and portability that accompanies ITK classes, I think
> those reasons alone are sufficient motivation for wider adoption.
>
> Also, just so you know, I thought about doing a comprehensive comparison
> between N3MNI and N4ITK using something like the Brainweb data for the
> technical document but the trouble we had setting up N3MNI and the mnc file
> format ruined all desire to perform such a comparative analysis.
>
>> In any case, thank you for this valuable contribution to the open
>> source community, and for replying to my question.
>
> I'm glad you like it.  Hopefully it will get introduced into the ITK library
> in one of the future release.  For that, I thank you for your review.  Let
> me know if you have any other questions.
>
> Nick
>
>