[MINC-users] N3 - Changes since v 1.10.1

Claude LEPAGE claude at bic.mni.mcgill.ca
Tue Jun 1 17:23:17 EDT 2010


Hi Burt,

These are my changes. Of course, you will not obtain the same results as before,
because the previous code had a major bug.

If I can summarize somehow briefly:

N3 tries to minimize:

         E/N + Lambda*J

where E is the fitting term (cubic spline to image),
      N is the number of sampling points
      Lambda is a damping coefficient
      J is a stabilization term (matrix of derivatives)
You can read the original paper by Sled for my details.

In implementations prior to 1.11.0, the normalization by N was missing.
So instead of the average error per sampling point E/N, it was the total
error E. Another way of viewing the problem is that the effective damping
coefficient was Lambda*N instead of Lambda. So the amount of effective
damping would vary with number of sampling points (voxel sizes), thus the
old N3 was NOT voxel size invariant. For example, running old N3 on the
same image at 1mm or 0.5mm voxels would give totally different answers.
Fortunately, the old N3 scripts were calibrated to have a reasonable
damping Lambda in stereotaxic MNI space at 1mm voxels. Aside from that,
results would be unpredictable. Still, there was too much damping in 
the old N3. Lambda=1.0e-7 might be a little be too small. Perhaps 1.0e-6
would be better. The damping corresponding to the behaviour of the old
N3 would be approximately Lambda=5*1.0e-5.

In a second round of improvements, I modified the way in which the correction
field was evaluated outside the mask. Before, it would extrapolate the cubic
splines, which would cause problem at small spline distances like 25mm. Why?
Another complicated story. N3 computes a correction field in volume space 
inside the mask only. To extrapolate outside the mask, old N3 would set the
correction field to 1 everywhere outside the mask, with the real correction
inside the mask, then respline the extended correction field in/out the mask
and save the spline coefficients in compact form (.imp file). The drawback
with this approach is the lack of continuity in the correction field at the 
mask border. The end result is that the extended correction field is erroneous
around the perimeter of the mask, which happens to be in the cortex. This 
problem is amplified for 3-Tesla scans. In the new N3, I extend the correction 
field outside the mask by solving a Laplacian field, without modifying the 
correction field inside the mask.

Overall, the new N3 will make a substantial difference for 3T scans and
scans not at 1mm voxels (animal scans, for example).

I think this is it for the changes. Quite complicated indeed. I hope this
description helps you. If you have specific questions, don't hesitate to 
post them here.

Claude

> Our lab recently upgraded N3 from 1.10.1 to 1.11.0. Applying nu_correct to
> same images yields different results and we are trying to assess the extent
> and meaning of those changes.
>
> The 1.11.0 changelog says:
>
> 2009-06-15  Claude Lepage  <claude at bic.mni.mcgill.ca>
>     * Remove downsampling in evaluation of field (computers are fast
>           now, so be more accurate by sampling at full resolution)
>     * Correct the field in the region outside the mask to make
>           sure the mask varies smoothly away from the brain (important
>           with the previous changes)
>     * New program for the far-field correction
>
> 2009-05-08  Claude Lepage  <claude at bic.mni.mcgill.ca>
>     * Make nu_estimate_np_and_em.in invariant to voxel steps (via
>           spline_smooth in EBTKS - must use EBTKS 1.6.2 or above)
>     * Free memory after usage
>
> 2008-06-10  Andrew L Janke <a.janke at gmail.com>
>     * updated README, merged CHANGES and WHATSNEW into NEWS
>     * src/NUcorrect/nu_estimate_np_and_EM: added code to check on
>       (deprecated) use of the EM section and thus spit a warning
>     * epm-header.in: removed netcdf dependency
>
>
> Also, the help output from both version has one additional option in version
> 1.11.0:
>
> -lambda <value>   regularization coefficient for splines [default: 1.0e-7]
>
> I suppose these changes have been tried, tested and documented somewhere.
> Can someone point me in the right direction so I can have a better idea of
> what we are dealing with?
>
>
> Burt.


More information about the MINC-users mailing list