From zijdenbos at gmail.com Tue May 28 19:09:08 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Tue, 28 May 2013 19:09:08 -0400 Subject: [MINC-development] reversedef? Message-ID: Hi all, I was wondering what is happening with reversedef. I noticed it still exists in the minctracc/Extra_progs dir, but seems to be somewhat dangling. I recall from sometime in the 1990s that it could speed up mincresample a fair bit by reorganizing the deformation field somehow. At the moment it's not clear to me how this actually worked (Louis explained it to me at the time but that memory has somewhat faded). I have mincresample calls that can run up to an hour or so, so if there would be any way to speed these up that would actually be quite helpful. Thanks, -- A From a.janke at gmail.com Tue May 28 20:17:06 2013 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 29 May 2013 10:17:06 +1000 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: Hi Alex, > I was wondering what is happening with reversedef. I noticed it still > exists in the minctracc/Extra_progs dir, but seems to be somewhat > dangling. Not much, it's still there and still works. > I recall from sometime in the 1990s that it could speed up > mincresample a fair bit by reorganizing the deformation field somehow. mincresample is faster if you do this: mincresample -transformation xfm_inv.xfm -invert_transformation ... than if you use the forward transformation. This is due to how the code works in mincresample, it blits through the output volume finding data that goes to the current point and then resamples this. > I have mincresample calls that can run up to an hour or so, so if > there would be any way to speed these up that would actually be quite > helpful. So, reversedef can help you here, the only problem is that this will then introduce in effect another resampling as when you invert a transformation you have to resample/regrid the vectors. As I recall the code in reversedef to do this is NR code. Perhaps a better approach and the approach that both Vlad and myself use in our model building scripts is to generate an inverse transformation in the first instance. ie: # fit model to the source and resample minctracc .... model.mnc source.mnc xfm_inv.xfm mincresample -like model.mnc -transformation xfm_inv.xfm \ -invert_transformation source.mnc res.mnc There are other advantages to this approach, the principal being that this makes averaging xfms a whole lot easier. I have two other tools that are probably worth mentioning here: xfm2def - takes a complex xfm (could have multiple grids + linear, etc) and turns it into a single nonlinear xfm. This can also speed up mincresample. https://github.com/BIC-MNI/minc/blob/master/progs/xfm/xfm2def.c gennlxfm http://packages.bic.mni.mcgill.ca/scripts/gennlxfm One of the problems of fitting multiple volumes to a model if you want to average them is that the grids often don't align with each other due to the bit of jiggery-pokery that minctracc does when intialising grids. You can use this to generate an identity nonlinear grid that you then feed to minctracc. # gennlxfm -ident -like model.xfm ident.xfm # minctracc -transformation ident.xfm model.mnc source1.mnc output1.xfm # minctracc -transformation ident.xfm model.mnc source2.mnc output2.xfm # minctracc -transformation ident.xfm model.mnc source3.mnc output3.xfm You are now guaranteed that output{1,2,3}.xfm are all identically sampled and thus can be averaged. a From zijdenbos at gmail.com Tue May 28 20:47:42 2013 From: zijdenbos at gmail.com (Alex Zijdenbos) Date: Tue, 28 May 2013 20:47:42 -0400 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: Hi Andrew, Thanks! various bits of useful info here. My deformations are in fact already collapsed to a single grid using xfm2def, that indeed made a big difference. I'm always a bit reluctant to invert deformations unnecessarily, as minctracc's deformation fields are often not invertible. Then on the other hand, the registration scripts that I have written are able to do bidirectional registrations (source to target, target to source, invert, average) so in effect I'm already doing this a lot; I suppose it would make sense to actually generate the inverse xfm as the 'primary' for efficiency purposes. So also, to understand things correctly; is reversedef(xfm) basically equivalent to xfm2def( xfminvert( xfm ) ) ? -- A On Tue, May 28, 2013 at 8:17 PM, Andrew Janke wrote: > Hi Alex, > >> I was wondering what is happening with reversedef. I noticed it still >> exists in the minctracc/Extra_progs dir, but seems to be somewhat >> dangling. > > Not much, it's still there and still works. > >> I recall from sometime in the 1990s that it could speed up >> mincresample a fair bit by reorganizing the deformation field somehow. > > mincresample is faster if you do this: > > mincresample -transformation xfm_inv.xfm -invert_transformation ... > > than if you use the forward transformation. This is due to how the > code works in mincresample, it blits through the output volume finding > data that goes to the current point and then resamples this. > >> I have mincresample calls that can run up to an hour or so, so if >> there would be any way to speed these up that would actually be quite >> helpful. > > So, reversedef can help you here, the only problem is that this will > then introduce in effect another resampling as when you invert a > transformation you have to resample/regrid the vectors. As I recall > the code in reversedef to do this is NR code. Perhaps a better > approach and the approach that both Vlad and myself use in our model > building scripts is to generate an inverse transformation in the first > instance. > > ie: > > # fit model to the source and resample > minctracc .... model.mnc source.mnc xfm_inv.xfm > > mincresample -like model.mnc -transformation xfm_inv.xfm \ > -invert_transformation source.mnc res.mnc > > There are other advantages to this approach, the principal being that > this makes averaging xfms a whole lot easier. I have two other tools > that are probably worth mentioning here: > > xfm2def - takes a complex xfm (could have multiple grids + linear, > etc) and turns it into a single nonlinear xfm. This can also speed up > mincresample. > > https://github.com/BIC-MNI/minc/blob/master/progs/xfm/xfm2def.c > > gennlxfm > > http://packages.bic.mni.mcgill.ca/scripts/gennlxfm > > One of the problems of fitting multiple volumes to a model if you want > to average them is that the grids often don't align with each other > due to the bit of jiggery-pokery that minctracc does when intialising > grids. You can use this to generate an identity nonlinear grid that > you then feed to minctracc. > > # gennlxfm -ident -like model.xfm ident.xfm > > # minctracc -transformation ident.xfm model.mnc source1.mnc output1.xfm > # minctracc -transformation ident.xfm model.mnc source2.mnc output2.xfm > # minctracc -transformation ident.xfm model.mnc source3.mnc output3.xfm > > You are now guaranteed that output{1,2,3}.xfm are all identically > sampled and thus can be averaged. > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From a.janke at gmail.com Tue May 28 20:57:03 2013 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 29 May 2013 10:57:03 +1000 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: > Then on the other hand, the registration scripts that I > have written are able to do bidirectional registrations (source to > target, target to source, invert, average) so in effect I'm already > doing this a lot; I suppose it would make sense to actually generate > the inverse xfm as the 'primary' for efficiency purposes. Indeed it would. Also if you are using xfmavg to do this be very sure that you linear components of the xfm's you are averaging are identical. There is some info in the -help about this. If you are using xfm2def for both then things are good. > So also, to understand things correctly; is reversedef(xfm) basically > equivalent to xfm2def( xfminvert( xfm ) ) ? Yes. The results of this will be numerically equal but not identical. One uses some internal NR code, the other uses volume_io to do the hard work. a From andrew at biospective.com Wed May 29 09:49:08 2013 From: andrew at biospective.com (Andrew Wood) Date: Wed, 29 May 2013 09:49:08 -0400 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: Hi Andrew, I haven't been able to find everything needed to build reversedef at release-0.99.60 in the git repository. It's not built by default, so I added it to minctracc/Extra_progs/Makefile.am. I get an error that it's missing minc_def.h (which was remove in Feb-2000), and a handful of other compile errors. Must I go back to a release from the 90s to get this, or am I missing something obvious? Thanks, Andrew On Tue, May 28, 2013 at 8:57 PM, Andrew Janke wrote: > > Then on the other hand, the registration scripts that I > > have written are able to do bidirectional registrations (source to > > target, target to source, invert, average) so in effect I'm already > > doing this a lot; I suppose it would make sense to actually generate > > the inverse xfm as the 'primary' for efficiency purposes. > > Indeed it would. Also if you are using xfmavg to do this be very sure > that you linear components of the xfm's you are averaging are > identical. There is some info in the -help about this. If you are > using xfm2def for both then things are good. > > > So also, to understand things correctly; is reversedef(xfm) basically > > equivalent to xfm2def( xfminvert( xfm ) ) ? > > Yes. The results of this will be numerically equal but not identical. > One uses some internal NR code, the other uses volume_io to do the > hard work. > > > a > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladimir.fonov at gmail.com Wed May 29 10:48:12 2013 From: vladimir.fonov at gmail.com (Vladimir S. FONOV) Date: Wed, 29 May 2013 10:48:12 -0400 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: <51A6152C.9020708@gmail.com> Hello, I suppose these days one can achieve this by doing 1. xfm_normalize.pl xfm.xfm temp.xfm --invert --exact --like template.mnc 2. mincresample -transform temp.xfm -invert_transformation input.mnc output.mnc -like template.mnc however, I didn't make experiments to see how much faster it will be On 13-05-28 07:09 PM, Alex Zijdenbos wrote: > Hi all, > > I was wondering what is happening with reversedef. I noticed it still > exists in the minctracc/Extra_progs dir, but seems to be somewhat > dangling. I recall from sometime in the 1990s that it could speed up > mincresample a fair bit by reorganizing the deformation field somehow. > At the moment it's not clear to me how this actually worked (Louis > explained it to me at the time but that memory has somewhat faded). > > I have mincresample calls that can run up to an hour or so, so if > there would be any way to speed these up that would actually be quite > helpful. -- Best regards, Vladimir S. FONOV ~ vladimir.fonov gmail.com From a.janke at gmail.com Wed May 29 21:09:48 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 30 May 2013 11:09:48 +1000 Subject: [MINC-development] reversedef? In-Reply-To: <51A6152C.9020708@gmail.com> References: <51A6152C.9020708@gmail.com> Message-ID: Wh{at,ere}'s this? a On 30 May 2013 00:48, Vladimir S. FONOV wrote: > xfm_normalize.pl From a.janke at gmail.com Wed May 29 21:52:14 2013 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 30 May 2013 11:52:14 +1000 Subject: [MINC-development] reversedef? In-Reply-To: References: Message-ID: Hi Andrew, > I haven't been able to find everything needed to build reversedef at > release-0.99.60 in the git repository. It's not built by default, so I added > it to minctracc/Extra_progs/Makefile.am. I get an error that it's missing > minc_def.h (which was remove in Feb-2000), and a handful of other compile > errors. > > Must I go back to a release from the 90s to get this, or am I missing > something obvious? While going back to the 90's is something that I highly recommend (and my wife reckons I am stuck in) it just that reversedef.c has been missing some attention as of late. See this: https://github.com/BIC-MNI/mni_autoreg/commit/3da6bbcd60d4eb537de1b474980d2c9a9c120671 On this note the develop branch of mni_autoreg won't build for me currently (whinges about VIO_OK and other things). I take it Vlad is trying to update the VIO namespace ugliness. a