From a.janke at gmail.com Tue May 8 11:45:51 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 9 May 2007 01:45:51 +1000 Subject: [MINC-development] MINC and Subversion Message-ID: Hi all, After a bit more goading I think I may have finally come to some sort of agreement (with myself) regarding svn for use with MINC and the various packages that we distribute. I know that there are at least 2 of you who still like CVS (and I do too! :) but feel the change is warranted. So what is the plan? the plan is to finally use the placeholder on feeble: feeble/cvs.bic.mni.mcgill.ca:/public-cvsroot Of course the above needs to be renamed slighty! Any recomendations on how we should structure the new repository? I for one am all for a very simple flat structure something akin to this: prod/ minc/ mni-autoreg/ dev/ minc_dev/ ... Where prod = production == all the packages that we distribute and dev == just that. thoughts? -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From sylvain at bic.mni.mcgill.ca Tue May 8 16:41:24 2007 From: sylvain at bic.mni.mcgill.ca (Sylvain MILOT) Date: Tue, 8 May 2007 16:41:24 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: Message-ID: Sounds good to me Andrew. As for access, as you pointed out to me in our previous exchange, I vote in favor of a file based svn, as opposed to an http based - as I don't see the need to maintain a whole new set of usernames and passwords. S On Wed, 9 May 2007, Andrew Janke wrote: > Hi all, > > After a bit more goading I think I may have finally come to some sort > of agreement (with myself) regarding svn for use with MINC and the > various packages that we distribute. I know that there are at least 2 > of you who still like CVS (and I do too! :) but feel the change is > warranted. > > So what is the plan? the plan is to finally use the placeholder on feeble: > > feeble/cvs.bic.mni.mcgill.ca:/public-cvsroot > > Of course the above needs to be renamed slighty! > > Any recomendations on how we should structure the new repository? I > for one am all for a very simple flat structure something akin to > this: > > prod/ > minc/ > mni-autoreg/ > > dev/ > minc_dev/ > ... > > Where prod = production == all the packages that we distribute and dev > == just that. > > thoughts? > > > -- > Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > --- Sylvain Milot (sylvain at bic.mni.mcgill.ca) (bicadmin at bic.mni.mcgill.ca) Brain Imaging Centre Montreal Neurological Institute 3801 University Street Webster 2B, Room 208 Montreal, Qc., Canada, H3A 2B4 Phone : (514) 398-4965, Fax: 398-8948 Mobile : (514) 712-1768 Office : 527 Av Des Pins O., Room 204 Montreal, Qc., H2W 1S4 From jason at bic.mni.mcgill.ca Tue May 8 16:45:04 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Tue, 8 May 2007 16:45:04 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: Message-ID: <4640E150.6020704@bic.mni.mcgill.ca> Sylvain MILOT wrote: > Sounds good to me Andrew. As for access, as you pointed out to me in our > previous exchange, I vote in favor of a file based svn, as opposed to an > http based - as I don't see the need to maintain a whole new set of > usernames and passwords. > I'd argue for the opposite - there's an increasing number of MINC users/developers outside of Montreal, and it seems silly to have to give them local accounts for repository access when instead you could give them an account just for subversion (plus get much finer level access control in the process). Jason > S > > > On Wed, 9 May 2007, Andrew Janke wrote: > > >> Hi all, >> >> After a bit more goading I think I may have finally come to some sort >> of agreement (with myself) regarding svn for use with MINC and the >> various packages that we distribute. I know that there are at least 2 >> of you who still like CVS (and I do too! :) but feel the change is >> warranted. >> >> So what is the plan? the plan is to finally use the placeholder on feeble: >> >> feeble/cvs.bic.mni.mcgill.ca:/public-cvsroot >> >> Of course the above needs to be renamed slighty! >> >> Any recomendations on how we should structure the new repository? I >> for one am all for a very simple flat structure something akin to >> this: >> >> prod/ >> minc/ >> mni-autoreg/ >> >> dev/ >> minc_dev/ >> ... >> >> Where prod = production == all the packages that we distribute and dev >> == just that. >> >> thoughts? >> >> >> -- >> Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) >> Canberra->Australia +61 (402) 700 883 >> _______________________________________________ >> MINC-development mailing list >> MINC-development at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >> >> > > --- > Sylvain Milot (sylvain at bic.mni.mcgill.ca) > (bicadmin at bic.mni.mcgill.ca) > Brain Imaging Centre > Montreal Neurological Institute > 3801 University Street > Webster 2B, Room 208 > Montreal, Qc., Canada, H3A 2B4 > Phone : (514) 398-4965, Fax: 398-8948 > Mobile : (514) 712-1768 > Office : 527 Av Des Pins O., Room 204 > Montreal, Qc., H2W 1S4 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > From jharlap at bic.mni.mcgill.ca Tue May 8 17:00:05 2007 From: jharlap at bic.mni.mcgill.ca (Jon Harlap) Date: Tue, 08 May 2007 17:00:05 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: <4640E150.6020704@bic.mni.mcgill.ca> References: <4640E150.6020704@bic.mni.mcgill.ca> Message-ID: <4640E4D5.7020701@bic.mni.mcgill.ca> not to mention that file based doesn't work so well when you have multiple developers working on a respository, as jason and i saw when setting up the brain-view subversion repository... you have to set up silly hacks in order to allow all the developers to write to the repository directory and not create inaccessible files for the other developers... on the plus side, you can use any form of apache auth module you like, and you can even combine several - so if you used PAM with ldap on the systems, you could use the same LDAP for subversion over http as well... and for added security you can use ssl (https) - so if you wanted to allow collaborators who don't have bic accounts to access the subversion repos, you could actually create client certs for those users and accept equally the LDAP and SSL client cert credentials, so both internal and external users can access the repos. isn't apache fun? ;) j Jason Lerch wrote: > Sylvain MILOT wrote: >> Sounds good to me Andrew. As for access, as you pointed out to me in our >> previous exchange, I vote in favor of a file based svn, as opposed to an >> http based - as I don't see the need to maintain a whole new set of >> usernames and passwords. >> > I'd argue for the opposite - there's an increasing number of MINC > users/developers outside of Montreal, and it seems silly to have to give > them local accounts for repository access when instead you could give > them an account just for subversion (plus get much finer level access > control in the process). > > Jason >> S >> >> >> On Wed, 9 May 2007, Andrew Janke wrote: >> >> >>> Hi all, >>> >>> After a bit more goading I think I may have finally come to some sort >>> of agreement (with myself) regarding svn for use with MINC and the >>> various packages that we distribute. I know that there are at least 2 >>> of you who still like CVS (and I do too! :) but feel the change is >>> warranted. >>> >>> So what is the plan? the plan is to finally use the placeholder on feeble: >>> >>> feeble/cvs.bic.mni.mcgill.ca:/public-cvsroot >>> >>> Of course the above needs to be renamed slighty! >>> >>> Any recomendations on how we should structure the new repository? I >>> for one am all for a very simple flat structure something akin to >>> this: >>> >>> prod/ >>> minc/ >>> mni-autoreg/ >>> >>> dev/ >>> minc_dev/ >>> ... >>> >>> Where prod = production == all the packages that we distribute and dev >>> == just that. >>> >>> thoughts? >>> >>> >>> -- >>> Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) >>> Canberra->Australia +61 (402) 700 883 >>> _______________________________________________ >>> MINC-development mailing list >>> MINC-development at bic.mni.mcgill.ca >>> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >>> >>> >> --- >> Sylvain Milot (sylvain at bic.mni.mcgill.ca) >> (bicadmin at bic.mni.mcgill.ca) >> Brain Imaging Centre >> Montreal Neurological Institute >> 3801 University Street >> Webster 2B, Room 208 >> Montreal, Qc., Canada, H3A 2B4 >> Phone : (514) 398-4965, Fax: 398-8948 >> Mobile : (514) 712-1768 >> Office : 527 Av Des Pins O., Room 204 >> Montreal, Qc., H2W 1S4 >> _______________________________________________ >> MINC-development mailing list >> MINC-development at bic.mni.mcgill.ca >> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development >> > > _______________________________________________ > 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 Wed May 9 08:25:00 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 9 May 2007 22:25:00 +1000 Subject: [MINC-development] MINC and Subversion In-Reply-To: <4640E4D5.7020701@bic.mni.mcgill.ca> References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> Message-ID: On 5/9/07, Jon Harlap wrote: > not to mention that file based doesn't work so well when you have > multiple developers working on a respository, as jason and i saw when > setting up the brain-view subversion repository... you have to set up > silly hacks in order to allow all the developers to write to the > repository directory and not create inaccessible files for the other > developers... Aye, the more I read about file base SVN, the more I am tempted towards the dark side of webDAV. We could of course still stick with a file based version and for usernames just not use NIS on feeble. But this would seem counterproductive. > on the plus side, you can use any form of apache auth module you like, > and you can even combine several - so if you used PAM with ldap on the > systems, you could use the same LDAP for subversion over http as well... > and for added security you can use ssl (https) - so if you wanted to > allow collaborators who don't have bic accounts to access the subversion > repos, you could actually create client certs for those users and accept > equally the LDAP and SSL client cert credentials, so both internal and > external users can access the repos. isn't apache fun? ;) Now you're just trying to show off. Far far too many acronyms here... ;) Although I question the need for client certifcates, why is this really needed? Should not (at least) the core MINC repo be open for anonymous read access and have a few pumpkings who are allowed to comit? Out of interest, what do you happen to use in tronno? SVN as per the above setup? Or is there no real central thingo? All this is sounding increasingly annoying/amusing to the point that I am about ready to just migrate to sourceforge or some other SVN providor. You can dump the whole tree periodically for backup so what would be the problem? Any violent objections to using a third (free) party that allows access to dump the entire thing so that you could transfer it later? As I see it we have two choices. (or perhaps 3) 1. keep on burying our heads and leave it in CVS 2. install SVN and lots of acronyms on feeble. 3. Use a third party. Myself I am Oh so tempted by #3. Perhaps a review of the options for #3 are in order. a From jason at bic.mni.mcgill.ca Wed May 9 08:35:18 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 9 May 2007 08:35:18 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> Message-ID: > > Now you're just trying to show off. Far far too many acronyms > here... ;) > > Although I question the need for client certifcates, why is this > really needed? Should not (at least) the core MINC repo be open for > anonymous read access and have a few pumpkings who are allowed to > comit? Out of interest, what do you happen to use in tronno? SVN as > per the above setup? Or is there no real central thingo? We use a simple SVN with apache setup - no SSL, just plain apache authentication, and with a separately maintained set of accounts (htpasswd) for write access. Not the most secure solution, but hopefully enough for our purposes. > > 1. keep on burying our heads and leave it in CVS > > 2. install SVN and lots of acronyms on feeble. > > 3. Use a third party. > > Myself I am Oh so tempted by #3. Perhaps a review of the options for > #3 are in order. I've used google code for a different project and quite like it - but all repositories have to be world readable, which might not be what you want. I suspect that the desire to keep certain repositories private will mean that the do it yourself solution is still best. Cheers, Jason From a.janke at gmail.com Wed May 9 08:47:02 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 9 May 2007 22:47:02 +1000 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> Message-ID: > We use a simple SVN with apache setup - no SSL, just plain apache > authentication, and with a separately maintained set of accounts > (htpasswd) for write access. Not the most secure solution, but > hopefully enough for our purposes. Thanks for the info. So essentially you have two types of users, those who can see the svn repo and those who cant.. :) a .htpasswd method with svn doesn't allow for more fine-grained control does it? (the LDAP thing is out as the BIC still uses NIS from what I know. IRIX and GNU/Linux still won't hold hands and play nice) > > 1. keep on burying our heads and leave it in CVS > > 2. install SVN and lots of acronyms on feeble. > > 3. Use a third party. > > I've used google code for a different project and quite like it - but > all repositories have to be world readable, which might not be what you > want. I suspect that the desire to keep certain repositories private > will mean that the do it yourself solution is still best. Most interesting, care to hand out the address so that I can have a poke around to see what a small project would look like? I suspect however than an external site will not really ever be completely sanctioned if only for political reasons. ie: it would be nice if the SVN address of MINC still included bic.mni.mcgill.ca in it somewhere... The option that does present itself here though is to have a local webDAV repo at the BIC that is only open to those with passwords (ala .htpasswd) and then use a post-commit hook to synch it to an external "read for all" repo on google code or the likes. Might be messy though. I should also point out that the only code that will migrate to this new svn thing (if it comes into being) will be code that is on packages (ie: stuff that is to be released). if things are not to be released then either we make another separate local repo or continue to use CVS for these projects. This to my mind is a good way to separate what is and what isn't for publc consumption from the BIC. a From jason at bic.mni.mcgill.ca Wed May 9 09:08:23 2007 From: jason at bic.mni.mcgill.ca (Jason Lerch) Date: Wed, 9 May 2007 09:08:23 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> Message-ID: <2be7e490b4820c13c3b6b4d54bf11f0d@bic.mni.mcgill.ca> On May 9, 2007, at 8:47 AM, Andrew Janke wrote: >> We use a simple SVN with apache setup - no SSL, just plain apache >> authentication, and with a separately maintained set of accounts >> (htpasswd) for write access. Not the most secure solution, but >> hopefully enough for our purposes. > > Thanks for the info. So essentially you have two types of users, > those who can see the svn repo and those who cant.. :) a .htpasswd > method with svn doesn't allow for more fine-grained control does it? Actually it does. Here's a sample of what the control file looks like: [RMINC:/] * = r jason = rw jharlap = rw matthijs = rw [registration:/] jason = rw lau = rw matthijs = rw In this case there are two projects, one of them (RMINC) is world readable as well as being writeable by three authors, and the other is not world readable with read-write permissions for three people. Note that one can use user groups as well and not just individual users. The accounts are kept in a separate flat text file created/modified by htpasswd. > (the LDAP thing is out as the BIC still uses NIS from what I know. > IRIX and GNU/Linux still won't hold hands and play nice) > >>> 1. keep on burying our heads and leave it in CVS >>> 2. install SVN and lots of acronyms on feeble. >>> 3. Use a third party. >> >> I've used google code for a different project and quite like it - but >> all repositories have to be world readable, which might not be what >> you >> want. I suspect that the desire to keep certain repositories private >> will mean that the do it yourself solution is still best. > > Most interesting, care to hand out the address so that I can have a > poke around to see what a small project would look like? http://code.google.com/p/opcit/ (my very slowly being developed attempt to write a better Endnote - anyone on this list feel like helping out?). > > I suspect however than an external site will not really ever be > completely sanctioned if only for political reasons. ie: it would be > nice if the SVN address of MINC still included bic.mni.mcgill.ca in it > somewhere... > > The option that does present itself here though is to have a local > webDAV repo at the BIC that is only open to those with passwords (ala > .htpasswd) and then use a post-commit hook to synch it to an external > "read for all" repo on google code or the likes. Might be messy > though. I don't think that is necessary, as projects can be quite easily separated using the mechanism I describe above. Also note that access control can be even more fine-grained - i.e. the trunk of a project can be world readable with any of the branches limited to a set of users. > > I should also point out that the only code that will migrate to this > new svn thing (if it comes into being) will be code that is on > packages (ie: stuff that is to be released). if things are not to be > released then either we make another separate local repo or continue > to use CVS for these projects. Why? Won't it be easier to fully migrate everything if you are going to start migrating? Then use the access control file to separate what is and isn't for public consumption. Jason From jharlap at bic.mni.mcgill.ca Wed May 9 09:17:52 2007 From: jharlap at bic.mni.mcgill.ca (Jonathan HARLAP) Date: Wed, 09 May 2007 09:17:52 -0400 Subject: [MINC-development] MINC and Subversion In-Reply-To: References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> Message-ID: <4641CA00.3060202@bic.mni.mcgill.ca> Andrew Janke wrote: >> We use a simple SVN with apache setup - no SSL, just plain apache >> authentication, and with a separately maintained set of accounts >> (htpasswd) for write access. Not the most secure solution, but >> hopefully enough for our purposes. > > Thanks for the info. So essentially you have two types of users, > those who can see the svn repo and those who cant.. :) a .htpasswd > method with svn doesn't allow for more fine-grained control does it? > (the LDAP thing is out as the BIC still uses NIS from what I know. > IRIX and GNU/Linux still won't hold hands and play nice) Now that I look it up, LDAP isn't necessary: apache_auth_pam would be happy to use the NIS accounts. SSL server I said and meant it. SSL client certs I think is way overkill and was just pointing out that you can do whatever you want. Users logging in to SVN via http using their NIS accounts will be sending their BIC account info in plaintext across the internet. Not really a great idea, IMHO - thus SSL server to encrypt the communication channel such that the account info is sent securely. As to how to handle internal and external users together: BIC accounts (NIS) for internal users and a separate htpasswd-type file for the external users should be fine. You can load more than one auth module into apache, and if you use an auth block that's something like: AuthType Basic AuthName "secure area" AuthPAM_FallThrough on AuthUserFile /path/to/apache/passwd/passwords AuthGroupFile /path/to/apache/passwd/groups require group coders require valid-user Then it will try PAM (in our case, NIS) and if the user doesn't appear in NIS then it will fall through to the specified htpasswd-managed user and group files. > >>> 1. keep on burying our heads and leave it in CVS >>> 2. install SVN and lots of acronyms on feeble. >>> 3. Use a third party. >> I've used google code for a different project and quite like it - but >> all repositories have to be world readable, which might not be what you >> want. I suspect that the desire to keep certain repositories private >> will mean that the do it yourself solution is still best. > > Most interesting, care to hand out the address so that I can have a > poke around to see what a small project would look like? > > I suspect however than an external site will not really ever be > completely sanctioned if only for political reasons. ie: it would be > nice if the SVN address of MINC still included bic.mni.mcgill.ca in it > somewhere... > > The option that does present itself here though is to have a local > webDAV repo at the BIC that is only open to those with passwords (ala > .htpasswd) and then use a post-commit hook to synch it to an external > "read for all" repo on google code or the likes. Might be messy > though. > > I should also point out that the only code that will migrate to this > new svn thing (if it comes into being) will be code that is on > packages (ie: stuff that is to be released). if things are not to be > released then either we make another separate local repo or continue > to use CVS for these projects. > > This to my mind is a good way to separate what is and what isn't for > publc consumption from the BIC. > For private projects you could have a private repos and just don't allow the PAM fallthrough so only internals have access (or have a separate set of user/group files so internals and a different set of selected externals have access) J From a.janke at gmail.com Wed May 9 10:08:30 2007 From: a.janke at gmail.com (Andrew Janke) Date: Thu, 10 May 2007 00:08:30 +1000 Subject: [MINC-development] MINC and Subversion In-Reply-To: <4641CA00.3060202@bic.mni.mcgill.ca> References: <4640E150.6020704@bic.mni.mcgill.ca> <4640E4D5.7020701@bic.mni.mcgill.ca> <4641CA00.3060202@bic.mni.mcgill.ca> Message-ID: > Now that I look it up, LDAP isn't necessary: apache_auth_pam would be > happy to use the NIS accounts. > > SSL server I said and meant it. SSL client certs I think is way > overkill and was just pointing out that you can do whatever you want. > Users logging in to SVN via http using their NIS accounts will be > sending their BIC account info in plaintext across the internet. Not > really a great idea, IMHO - thus SSL server to encrypt the communication > channel such that the account info is sent securely. > > As to how to handle internal and external users together: BIC accounts > (NIS) for internal users and a separate htpasswd-type file for the > external users should be fine. You can load more than one auth module > into apache, and if you use an auth block that's something like: > > AuthType Basic > AuthName "secure area" > AuthPAM_FallThrough on > AuthUserFile /path/to/apache/passwd/passwords > AuthGroupFile /path/to/apache/passwd/groups > > require group coders > require valid-user > > Then it will try PAM (in our case, NIS) and if the user doesn't appear > in NIS then it will fall through to the specified htpasswd-managed user > and group files. Thanks for this, all good food for thought, however I doubt that certain individuals (JF! you aren't on MINC dev are you? :) would agree to mixing NIS with apache, call it paranoia, I know myself I am not keen on this. But there is like a good compromise, do you know if it is possible to limit module use to an subnet? What I am thinking of is the following: 1) we use svn + webDAV 2) Access is via .htpasswd first and failing that, NIS+PAM+SSL 3) BUT! restrinct NIS+PAM+SSL to the BIC subnet only as is NIS currently I also realise that .htpasswd is not all that secure (but quite secure enough). Is there a slightly better version of .htpasswd that works in this instance via SSL? Or is .htpasswd + SSL enough? ta a From vladimir.fonov at gmail.com Thu May 10 11:17:11 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 10 May 2007 11:17:11 -0400 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Hello All, I came across a minc file which breaks nu_correct 1.10.1 in a sense that it increases nonuniformity. See pictures at http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/ , or take a look at files in /data/scratch/scratch1/broken_nuc/ -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Thu May 10 11:23:06 2007 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 11 May 2007 01:23:06 +1000 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Looks like stratified background noise and/or poor slice normalization to me. Meaning the file conversion is probably off. a On 5/11/07, Vladimir FONOV wrote: > Hello All, > > I came across a minc file which breaks nu_correct 1.10.1 in a sense > that it increases nonuniformity. See pictures at > http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/ , or take a look at > files in /data/scratch/scratch1/broken_nuc/ > > -- > Best regards, > Vladimir S. Fonov ~ vladimir.fonov gmail.com > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From vladimir.fonov at gmail.com Thu May 10 11:30:03 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 10 May 2007 11:30:03 -0400 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Hello, On 5/10/07, Andrew Janke wrote: > Looks like stratified background noise and/or poor slice normalization to me. > > Meaning the file conversion is probably off. So, is there any way of automatically detecting this ? As you can imagine this is one of the scans of the young kids. This is how it looks after fitting to a model: http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/fitted.jpg -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Thu May 10 11:33:05 2007 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 11 May 2007 01:33:05 +1000 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: I seem to remember something about N3 having strife with some combinations of slice scaling... try this: mincreshape -float in.mnc out.mnc nu_correct out.mnc fred.mnc a On 5/11/07, Vladimir FONOV wrote: > Hello, > > On 5/10/07, Andrew Janke wrote: > > Looks like stratified background noise and/or poor slice normalization to me. > > > > Meaning the file conversion is probably off. > > So, is there any way of automatically detecting this ? As you can > imagine this is one of the scans of the young kids. This is how it > looks after fitting to a model: > http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/fitted.jpg > > > -- > Best regards, > Vladimir S. Fonov ~ vladimir.fonov gmail.com > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From vladimir.fonov at gmail.com Thu May 10 11:36:38 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 10 May 2007 11:36:38 -0400 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Hello, On 5/10/07, Andrew Janke wrote: > I seem to remember something about N3 having strife with some > combinations of slice scaling... > > try this: > > mincreshape -float in.mnc out.mnc > > nu_correct out.mnc fred.mnc Doesn't help (it's already been done for this example). -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From vladimir.fonov at gmail.com Thu May 10 11:51:53 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 10 May 2007 11:51:53 -0400 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Hello, > On 5/10/07, Andrew Janke wrote: > > I seem to remember something about N3 having strife with some > > combinations of slice scaling... > > > > try this: > > > > mincreshape -float in.mnc out.mnc > > > > nu_correct out.mnc fred.mnc > > Doesn't help (it's already been done for this example). > resampling to 1x1x1 without direction cosines does help, though. -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From vladimir.fonov at gmail.com Thu May 10 13:54:43 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 10 May 2007 13:54:43 -0400 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Problem solved (partially): > > > I seem to remember something about N3 having strife with some > > > combinations of slice scaling... > > > > > > try this: > > > > > > mincreshape -float in.mnc out.mnc > > > > > > nu_correct out.mnc fred.mnc > > Actually problem is not with nu_correct , but with mincreshape -float somehow makes things bad: http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/float.jpg - after mincreshape -float . And my nu_correct script was doing just that - converting to float and running nu_correct -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com From a.janke at gmail.com Thu May 10 18:16:53 2007 From: a.janke at gmail.com (Andrew Janke) Date: Fri, 11 May 2007 08:16:53 +1000 Subject: [MINC-development] nu-correct produces incorrect results, sometimes In-Reply-To: References: Message-ID: Sorry, I had meant: mncreshape -float mincreshape -short ... opps. :) a On 5/11/07, Vladimir FONOV wrote: > Problem solved (partially): > > > > > I seem to remember something about N3 having strife with some > > > > combinations of slice scaling... > > > > > > > > try this: > > > > > > > > mincreshape -float in.mnc out.mnc > > > > > > > > nu_correct out.mnc fred.mnc > > > > > Actually problem is not with nu_correct , but with mincreshape -float > somehow makes things bad: > http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/float.jpg - after > mincreshape -float . > > And my nu_correct script was doing just that - converting to float and > running nu_correct > > -- > Best regards, > Vladimir S. Fonov ~ vladimir.fonov gmail.com > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From a.janke at gmail.com Tue May 22 10:58:40 2007 From: a.janke at gmail.com (Andrew Janke) Date: Wed, 23 May 2007 00:58:40 +1000 Subject: [MINC-development] ITK and MINC. Message-ID: Hi all, For those who have an interest in ITK and MINC, have your say here. http://www.itk.org/Wiki/Proposals:Adding_MINC_File_Format I have been asked to help finish of what as to be done to get it included in the base ITK distribution, so now is the time to get your requests/coments/offers of help in. I have left a space at the bottom for those who wish to add things. -- Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) Canberra->Australia +61 (402) 700 883 From jgsled at sickkids.ca Thu May 24 12:56:11 2007 From: jgsled at sickkids.ca (John G. Sled) Date: Thu, 24 May 2007 12:56:11 -0400 Subject: [MINC-development] mincreshape In-Reply-To: References: Message-ID: <20070524165611.GG11680@sickkids.ca> Hi Andrew and Vladimir, What did you finally conclude was the cause of the stripes? Is there a bug in mincreshape? In my experience, short integers work fine with nu_correct whether there is slice scaling or not. On a slightly related note, I have run into a problem with mincreshape in which mincreshape +zdirection in.mnc out.mnc doesn't change the zstep to a positive number. The command mincreshape +direction in.mnc out.mnc created a file in which the ystep was flipped to be positive, but the zstep stayed negative. Is there some logic to this that I am overlooking? It seems like a bug. cheers, John On Fri, May 11, 2007 at 08:16:53AM +1000, Andrew Janke wrote: > Sorry, I had meant: > > mncreshape -float > mincreshape -short > > ... > > opps. :) > > > a > > On 5/11/07, Vladimir FONOV wrote: > > Problem solved (partially): > > > > > > > I seem to remember something about N3 having strife with some > > > > > combinations of slice scaling... > > > > > > > > > > try this: > > > > > > > > > > mincreshape -float in.mnc out.mnc > > > > > > > > > > nu_correct out.mnc fred.mnc > > > > > > > > Actually problem is not with nu_correct , but with mincreshape -float > > somehow makes things bad: > > http://www.bic.mni.mcgill.ca/~vfonov/broken_nuc/float.jpg - after > > mincreshape -float . > > > > And my nu_correct script was doing just that - converting to float and > > running nu_correct > > > > -- > > Best regards, > > Vladimir S. Fonov ~ vladimir.fonov gmail.com > > _______________________________________________ > > MINC-development mailing list > > MINC-development at bic.mni.mcgill.ca > > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development > > > > > -- > Andrew Janke (a.janke at gmail.com || http://a.janke.googlepages.com/) > Canberra->Australia +61 (402) 700 883 > _______________________________________________ > MINC-development mailing list > MINC-development at bic.mni.mcgill.ca > http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development From sean at rogue-research.com Thu May 24 13:43:00 2007 From: sean at rogue-research.com (Sean McBride) Date: Thu, 24 May 2007 13:43:00 -0400 Subject: [MINC-development] ITK and MINC. In-Reply-To: References: Message-ID: <20070524174300.649746231@smtp1.sympatico.ca> On 2007-05-23 00:58, Andrew Janke said: >For those who have an interest in ITK and MINC, have your say here. > > http://www.itk.org/Wiki/Proposals:Adding_MINC_File_Format > >I have been asked to help finish of what as to be done to get it >included in the base ITK distribution, so now is the time to get your >requests/coments/offers of help in. I have left a space at the bottom >for those who wish to add things. Andrew, Not sure what I could/should say on the wiki, but I just wanted to say that it would be great if MINC support was in the base ITK distribution! We would definitely be willing to help test any new builds you have. We are currently using Leila's stuff from the ITK journal, it seems to work fine, though we have not stress-tested it. Cheers, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From vladimir.fonov at gmail.com Thu May 24 14:32:24 2007 From: vladimir.fonov at gmail.com (Vladimir FONOV) Date: Thu, 24 May 2007 14:32:24 -0400 Subject: [MINC-development] mincreshape In-Reply-To: <20070524165611.GG11680@sickkids.ca> References: <20070524165611.GG11680@sickkids.ca> Message-ID: Hello, On 5/24/07, John G. Sled wrote: > > Hi Andrew and Vladimir, > > What did you finally conclude was the cause of the stripes? Is there > a bug in mincreshape? In my experience, short integers work fine with > nu_correct whether there is slice scaling or not. Strangely enough, if you do mincreshape -float -normalize stripes disappear. > On a slightly related note, I have run into a problem with mincreshape > in which > > mincreshape +zdirection in.mnc out.mnc > > doesn't change the zstep to a positive number. The command > > mincreshape +direction in.mnc out.mnc > > created a file in which the ystep was flipped to be positive, > but the zstep stayed negative. Is there some logic to this > that I am overlooking? It seems like a bug. > It is 'feature' from the man mincreshape: +direction: Flip images to give positive step value for spatial axes. Note that the flipping of spatial axes only applies to "image dimensions". These are the two fastest varying (non-vector) dimensions in the file. If you want to flip a non-image dimension, you can convert it to an image dimension with -dimsize =-1 (the -1 means don't really change the size). Check out the examples. So, use mincreshape +direction -dimsize zspace=-1 -- Best regards, Vladimir S. Fonov ~ vladimir.fonov gmail.com