Steve, assigning to you since no one was assigned automatically - you would know better who is the right person to look into this.

Alex - please have a look at this. I recall that we looked at the poly data transform code in vtk and I believe it was doing the correct thing with the normals so perhaps there is something else going on here.

Indeed, the computation of normals in vtkPolyDataTransform returns NAN's for Bspline.

I traced it to Jacobian computation returning all 0 matrix in ITK class:

BSplineDeformableTransform<TScalar, NDimensions, VSplineOrder>
::ComputeJacobianWithRespectToParameters( const InputPointType & point,
JacobianType & jacobian ) const

called from Slicer's vtkITKBSplineTransform class:

void
InverseTransformDerivativeHelper( vtkITKBSplineTransformHelperImpl<O>* helper,
const T in[3], T out[3], T derivative[3][3] )

May need help from an itk BSpline guru (Jim?)

Yes, or as Andras suggested maybe we should switch to the vtk bspline class.

I'll use the 'send a reminder' feature to send this to Jim and Hans in case they have suggestions on Alex's note 11610.

We'll need to take a look at this. I think the BSpline code change in ITKv4. I doubt the vtkITK BSpline was updated.

I don't recall a vtkBSpline class. Perhaps it is new. I would hesitate to use the vtkBSpline as it is not the one used in the registration methods. We'd have to convert between ITK BSplines and VTK BSplines. I anticipate that not being straightforward as the ITK BSplines are built for doing registration.

I think it is wrong in itkv3 and was corrected in v4.

Slicer4 uses BSplineDeformableTransform::ComputeJacobianWithRespectToParameters() which I believe is ITK4

I think your approach is good. Evenatually, we will be moving to the BSplineTransform to provide better support for ITKv4.

BSplineDeformableTransform is for backwards compatibility to ITKv3

BSplineTransform is a revised and improved version for ITKv4.

Fixed in rev 23148.

Problem:
vtkITKBSplineTransform incorrectly computed the 1. forward derivatives, 2. inverse displacement when there was a bulk transform component and rotated bspline grid, 3. the inverse displacement.

Analysis:
In the ITK bspline transform no inverse computation is available and in the current ITK bspline version no additive bulk transform is supported (therefore it is not backward-compatible with the old ITK bspline transform), ITK's transform support is very limited (compared to the powerful transform pipelines in VTK), and Slicer already uses VTK transforms (vtkGridTransform), therefore the ITK bspline is not usable in Slicer as is.
A bspline transform implementation is available in VTK, which is is efficient and well-tested (and equivalence with ITK's bspline implementation can be proven by testing).

Solution:
Replaced vtkITKBSplineTransform it with a vtkBSplineTransform-based transform, vtkOrientedBSplineTransform, which extends the original VTK class to handle arbitrarily oriented b-spline grids and supports an additive bulk transform.
Added test that verifies the vtkOrientedBSplineTransform's equivalence with the ITK BSpline transform implementation in the whole bspline grid (the differences are less than 1e-10).
Added test that verifies the correctness of the inverse and derivative computation.

Fixes:
http://www.na-mic.org/Bug/view.php?id=3664
http://www.na-mic.org/Bug/view.php?id=3659
http://www.na-mic.org/Bug/view.php?id=3614

Will CLI's written in ITK be able to read and write the bspline transforms that are understood by the new implementation?

ITK is still used for file IO, nothing is changed in the transform file format. The only difference is that ITK is not used for computation.

Now the implementation is consistent for all the transform types (linear, grid, and bspline) and image data: ITK IO is used for initializing VTK objects.