Hi Mark,

Sorry this is a little lengthy again - I'm trying to be as clear as possible.

Everything you say makes sense and squares with what I thought but my experience differs a little. With your help, I think my problem boils down to how the cost function is evaluated. Couple of clarifications first.

Just to be clear. I know the init matrix is added to everything - I want to see whether FLIRT improves matters starting from the init. So when I talked about doing "nothing" or an identity transform I meant this in addition to the init.

My optimise command with 0 max iterations was just an attempt to measure the cost associated with the init matrix (by not allowing optimise to perform any iterations). I now do this directly by using setrow and measurecost and get the same results.

I concede some confusion on my part over cost versus similarity in FLIRT. I agree that sort functions as advertised and that from a cost-function perspective it does the right thing. I think my problem actually stems from *how* the cost function is computed.

If you have any further advice much appreciated.

Here's my FLIRT command:
-----------------------
flirt -v -dof 9 -bins 64 -cost normmi -schedule ../test.sch -init test_proc_TYPHOON_213213-to-1.mat -refweight proc_NIMROD_1616-mask-norm.nii.gz -ref proc_NIMROD_1616.nii.gz -in proc_TYPHOON_213213.nii.gz -omat test-reg-213213.mat -out test-reg-213213.nii.gz

Here's part of the FLIRT output - the result of optimise is in the first row of UF and the identity is in the second row:
----------------------------------
>> measurecost MAXDOF UF:1-2  0.0   0.0    0.0    0.0    0.0    0.0  0.0  0.0  0.0  rel
 >> print U
-0.008305 0.945402 0.305760 0.100657 0.000000 -0.306213 0.854226 0.281214 0.000000 0.000000 -0.312695 0.949854 0.000000 55.184867 18.229680 -22.503618 1.000000
-0.004685 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 0.000000 1.000000

Which from what you say means that the first row (result from optimise) has the lowest cost and is therefore output. The confusion is that if I compute NMI outside FLIRT using the same number of bins, same mask and same images I get the following:

UNreg
(cnscompare.py)  cnscompare:    ssd 665.736004758 ma 3.0332 mb 3.1016 je 6.0847 mi 0.0501 nmi 1.0082
With init only
(cnscompare.py)  cnscompare:    ssd 444.313641584 ma 3.0332 mb 3.2428 je 5.7635 mi 0.5126 nmi 1.0889
FLIRT
(cnscompare.py)  cnscompare:    ssd 683.167758922 ma 3.0332 mb 3.0764 je 6.0440 mi 0.0656 nmi 1.0109

The exact values of NMI aren't important - I guess there's some transformation to the cost-function. However the ranking is different between the different transformation cases inside and outside FLIRT - hence the confusion. Visually the init-only case is an excellent result and has the highest NMI outside FLIRT. But the FLIRT result is catastrophically wrong and has a much lower NMI computed outside FLIRT but also a lower cost function computed inside FLIRT. I also tried running with different numbers of bins and allowing optimise to run more iterations but get the same results. Any ideas?

Thanks for ploughing through this.

Best Wishes

-Bill

---
Dr Bill Crum, Senior Lecturer,
King's College London,
Centre for NeuroImaging Sciences (PO89)
Institute of Psychiatry, De Crespigny Park, London, SE5 8AF
tel: +44 (0)20 3228 3043, fax: +44 (0)20 3228 2116

> -----Original Message-----
> From: FSL - FMRIB's Software Library [mailto:[log in to unmask]] On
> Behalf Of Mark Jenkinson
> Sent: 14 May 2010 00:41
> To: [log in to unmask]
> Subject: Re: [FSL] flirt schedule file problems
> 
> Hi Bill,
> 
> The -init matrix is added to everything, so that this becomes
> the new point of reference.  Hence an "identity" matrix in
> the schedule file would actually be the same transformation
> as the -init matrix.  I hope that makes sense.  Effectively,
> any matrix inside the schedule file will have the init matrix
> post-multiplied with it at the beginning of the optimisation.
> 
> I'm a bit puzzled about your problem with sort.  All values
> used by FLIRT (and this is also true of the documentation
> for schedule files and the terminology in general) is *cost*
> function value - not similarity values.  So ascending order
> means that the lowest values ends up in row 1.  However,
> lowest cost is the best value, so this is what should be
> used by FLIRT later on.
> 
> As for your optimisation problem - is it related to the
> *cost* vs *similiarity* function issue?  It is certainly
> possible that starting with a different transformation
> can lead to a better solution (especially when bypassing
> the search/perturbation phases) but your identity
> matrix will be the same as just using the -init matrix,
> so I don't see how you currently have two different
> starting points anyway.  I'm also not sure what the code
> does when you specify 0 as the last value in the optimise
> call, as this is the maximum number of iterations, and
> zero doesn't make much sense.  So maybe this is a
> problem?
> 
> Anyway, I hope this is enough info to help you solve
> the problem.
> 
> All the best,
> 	Mark
> 
> 
> 
> On 13 May 2010, at 10:29, Crum, Bill wrote:
> 
> > Hi,
> >
> > I'm having some problems with a custom FLIRT schedule file and need
> > a sanity check.
> >
> > Essentially I want to run with a very good initialisation matrix and
> > just do a fine-scale (1mm) adjustment. My initialisation matrix
> > seems to load OK.
> >
> > Problem 1:
> > The optimise command can result in a worse result than doing
> > nothing. It doesn't seem to start from the identity transform even
> > with zero perturbation. Not sure if this is a consequence of using
> > an init matrix, a bug, a feature or a misunderstanding on my part?
> >
> > Fudge 1:
> > So I explicitly measure the cost for the identity transform and use
> > sort to see whether this gives a better result than optimise.
> >
> > Problem 2:
> > The sort command behaves as advertised by sorting in ascending order
> > of similarity. However the first row (least similar) of the matrix
> > gets passed back to flirt rather than the last row (most similar).
> > So in my case it discards the best result.
> >
> > Unfortunately I can't figure out a Fudge for 2. I need to either
> > change the sort order or selectively delete matrix rows. Of course
> > even better if optimise behaved better in the first place ...
> >
> > Below is my schedule file and flirt command. I've tried it a number
> > of different ways but always get the same result.
> > I tested this by commenting/uncommenting out the sort command below
> > and varying the order of the optimise commands.
> >
> > Are these real problems or have I just broken the schedule handler
> > by doing something non-standard further up?
> >
> > Any help greatfully received - this is driving me nuts!
> >
> > Many Thanks
> >
> > -Bill Crum
> >
> > test.sch
> > ---------------------------------------------------------------------
> > # 8mm scale
> > setscale 8
> > clear S
> > clear P
> >
> > # 4mm scale
> > setscale 4
> >
> > # 2mm scale
> > setscale 2
> >
> > # 1mm scale
> > setscale 1
> > setoption smoothing 1
> > setoption boundguess 1
> >
> > # Optimise from this position
> > clear UF
> > setrow UF  1 0 0 0  0 1 0 0  0 0 1 0  0 0 0 1
> >
> > clear U
> > # Dummy optimise with 0 iterations
> > # I also tried just adding an identity row to UF directly but get
> > the same result
> > optimise MAXDOF UF:1  0.0   0.0   0.0   0.0   0.0   0.0   0.0  0.0
> > 0.0  rel 0
> > # Optimise from this position
> > optimise MAXDOF UF:1  0.0   0.0   0.0   0.0   0.0   0.0   0.0  0.0
> > 0.0  rel 1
> >
> > clear UF
> > copy U UF
> > clear U
> > measurecost MAXDOF UF:1-2  0.0   0.0    0.0    0.0    0.0    0.0
> > 0.0  0.0  0.0  rel
> > print U
> > sort U
> > print  U
> > ---------------------------------------------------------------------
> >
> > flirt -cost normcorr -schedule ../test.sch -nosearch -v -dof 9 -
> > refweight proc_NIMROD_1616-mask-norm-d2.nii.gz -ref
> > proc_NIMROD_1616.nii.gz -in proc_TYPHOON_212212.nii.gz -init
> > test_proc_TYPHOON_213213-to-1.mat -omat test-reg-213213.mat -out
> > test-reg-213213.nii.gz
> >
> > ---
> > Dr Bill Crum, Senior Lecturer,
> > King's College London,
> > Centre for NeuroImaging Sciences (PO89)
> > Institute of Psychiatry, De Crespigny Park, London, SE5 8AF
> >