Hi Martin,

I've put a bunch of MATLAB m-files here:
  http://www.cs.ucl.ac.uk/staff/g.ridgway/dof2mat
(you can get them all in one zip if you'd rather -- just add .zip to above)

They're reasonably well documented, but get in touch if anything is
unclear. The naming is probably not clear... IRTK is variously known
as itk++ or occasionally itk within our lab (not to be confused with
the Insight Toolkit, which is also ITK).

> 1. If I have existing FSL affine transform, which maps input image to
> reference using FLIRT, how can I compose an equivalent affine transform with
> the origin of rotation in the center of the image

Essentially, you just need matrices which recentre the coordinates
before the rotation and undo this afterwards. So in
itk_affine_dof2flirtmat.m you'll see we simply have:
  Aflirt = inv(Ctrg) * Aitk * Csrc;

Now, actually getting Aitk from the parameters in the .dof is not
completely trivial. You didn't mention this in your post, so I'm not
sure how much you knew (the documentation is fairly non-existent,
unless you have access to the code). The .dof is actually
parametrised, in terms of e.g. rotations as degrees roll-pitch-yaw,
rather than elements of a homogeneous matrix. Hopefully the comments
in itk_affine_dof2mat.m are reasonably clear...

Similarly, getting the Csrc and Ctrg recentering matrices can trip you
up, as it depends on silly things like analyze flipping options.
Hopefully get_fsl2itk_mat.m will do the trick for your data, but if
not, you might need to play around with negative dimensions, etc...

The file flirt_irtk_test_simple.m is probably the best place to start
to see the general sequence. The most confusing thing is probably the
choice between so-called old and new dof format. I think FSL 3.3 and 4
still ships with what I've called the old format -- there are actually
15 numbers in the .dof for this. Shout if that doesn't make sense with
the files you're seeing! (don't ask if it just doesn't seem to make
sense mathematically -- it doesn't!)

> 2. if I finally have the transform, and I use avscale to decompose it to
> rotations, scales, skews, and translations, if the translations will be
> affected by the rotations?

Hmm... I think this depends on your point of view... avscale will (I
think -- MJ please correct me if I'm wrong) decompose so that rotation
is around FSL's origin. My conversion from fslmat to itkdof will have
the rotation around IRTK's centre-of-volume origin. In both cases the
translations will be correct, within their convention, but they will
obviously differ.

There is no "correct" centre of rotation which could be chosen to
remove the ambiguity in the translations. For brains, centre-of-mass
(mass as voxel intensity) could be used, but would be messed up by how
much neck was included. NIfTI format images with correct q- or s-forms
define their own origin -- SPM's rotations are around this origin,
which is nice, but sadly neither FSL nor (old) IRTK currently do that.
I think Daniel Rueckert and Julia Schnabel's in-house (new) IRTK uses
the NIfTI origin on single-file .nii (which my code probably doesn't
handle correctly) and the Analyze-style centre of volume on .hdr/.img
pairs (even if they are actually NIfTI pairs, which can make things
really messy). I seem to recall Mark or Steve saying flirt might move
to use the NIfTI origin, but I might just have dreamt that... ;-)

Phew, I hope at least some of that makes sense. Feel free to ask
further questions (probably best to address/CC them to me as my
mailing-lists account has got rather full lately, but I can search for
things addressed directly to me).

Best,
Ged