 |
 |
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 >