[Insight-users] Spline smoothing distance and N4ITK parameters

[Nicholas Tustison]

> 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