We want to make some bridging registrations that map one template brain onto another. Let's call them A and B. We want to transform image data and points both from A->B and from B->A. Everybody would be much happier if round trip mapping points or images from A->B->A returned points to their original location. 

1. Both streamxform/gregxform and reformatx have the option to specify --inverse registrations. So we could calculate one registration (say A->B) and then invert that to go in the opposite direction (B->A).  The problem here is that B->A will be very slow and not even guaranteed to behave.

2. Or we could calculate A->B and B->A. But the problem here is that they will not be identical.

So if we expect to map just about as much image data A->B as B->A what should we do? I have noticed the --ic-weight option to reformat

--ic-weight
Weight for inverse consistency constraint
[Default: 0]

I _think_ that this will at least try to ensure that a single registration A->B is invertible, but there is still no guarantee that if A->B and B->A is calculated one will be the inverse of the other.

Any recommendations?

Many thanks,

Greg.

Hi Greg:

I think you mean the "--ic-weight" option in warp and warpx, not reformat?

Anyway, I would advise against using that. It never really worked as well as I was hoping, and I vaguely recall it will disappear altogether in the upcoming CMTK 2.3 release (which, sadly, isn't really making much progress right now).

So for lack of better options, I would recommend computing one direction and then using the explicit (numerical) inversion for the other direction.

As for speed - if you need to apply the same inverse often, you can compute a deformation field using the xform2dfield tool, which also accepts the "--invert" option for each transformation you give it. This way, you invert the deformation once, sample it, and henceforth use the sampled version.

Another option, which isn't implemented yet unfortunately, would be to fit a B-spline to the inverse of whatever transformation you would like to invert. This was planned for the next CMTK release (did I mention it's not making much progress?)

Hope this helps.

Torsten

Originally posted by Torsten Rohlfing: yes - typo. This  Just to give an example a test image reformatted with A->B or with the inverse of B->A took 30s and 1h15 respectively. OK so I was starting to wonder about this. But what would i do to use the deformation field? Can it directly substitute for a standard parametric registration input for reformatx? I have also found the fit_spline_dfield. If I make a dfield (as above) can I then use this to fit a b-spline based parametric transform? Any tips for the whole procedure in this case?

Many thanks again,

Greg.

Greg -

Yes, you can use a deformation field created by xform2dfield just like any other transformation on the reformatx command line (you cxan even use "--invert" with it, but then again, why would you?))

As for fit_bspline_dfield - yes, you could use that, but it wouldn't make things any faster (applying a deformation field should be very fast) and you would loose some precision of the dfield due to fitting.

What I meant in my original elaboration was slightly different - you can fit a B-spline to a set of point correspondences. These point correspondences could be a set of pairs (x,T(x)) with T being any transformation you may have. Then if you fit a B-spline transformation to the set of pairs (T(x),x) you will get a fit of the inverse transformation without ever actually doing the inversion (either analytic or numerical).

So that would be what I would strongly encourage you to use, but alas, I have not been able to find the time to actually implement this particular fitting procedure. (It is obviously not very hard to implement, given that I already have the general fitting code running, but there is just too much other stuff that I need to get done first; sorry).

Torsten

Originally posted by Torsten Rohlfing: Cool. I'll try it. I guess my thinking was that the B spline representation might be more compact. Any good rule of thumb for the sampling to use for the deformation field given a given B spline control point spacing? I wouldn't want to use the original template image as the float deformation field would end up 3 (axes) * 8 (bytes) / 2 (bytes) = 12 x bigger than my original 200 Mb 16 bit template (gzip compression doesn't do much for this kind of data). With the b spline representation and control point spacing of about 10 voxels I can actually keep the transforms in a git repo. When you have the time this will be really useful as there are some non-CMTK registration procedures that we occasionally need to use that produce a set of point correspondences.

Thanks again,

Greg.

Hi Greg:

I don't have a rule of thumb to offer for fitting B-spline transformations to deformation fields, but I would certainly suggest to use a multi-level fitting (e.g., "fit_spline_dfield --levels 4") and fit an affine transformation first ("--fit-affine-first").

As for fitting landmark correspondences - the library actually supports this already, but it's not wrapped in a nice command line tool. The "unwarp_image_phantom" tool uses this type of fitting to compute a B-spline transformation based on a specific type of MR imaging phantom (the "ADNI Phantom"). Really, all that is missing here would be for someone to decide on a reasonable input file format for the landmark pairs and change the reader part of that tool. This will likely happen before the inverse transformation fitting, but still, don't hold your breath.

Torsten

Hi Torsten,
Originally posted by Torsten Rohlfing: Useful tips! I guess I already discovered the importance of fitting the affine first. But I was actually asking for the opposite, a rule of thumb for what voxel size to use in the deformation field volume given a particular control point grid spacing.  Well likewise, but you never know – sounds more or less within my competence! 

Best,

Greg.