[Freesurfer] scp issue??
Hi! All, I download and install freesurfer-Darwin-leopard-i686-stable-pub-v5.0.0 on my macbook pro yesterday. After that, scp command from terminal is not working anymore. Below is an example: gnc...@mbp:tmp]$ scp -i ~/.ssh/id_dsa.pub sdg.zip macpro:~/tmp freesurfer-Darwin-leopard-i686-stable-pub-v5.0.0 It shows freesurfer's version and did not copy file at all. I have no idea why scp command will have something to do with freesurfer. Does anyone know anything about this?? Gen ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Re: [Freesurfer] scp issue??
Sorry. I figure it out what went wrong. It has nothing to do with freesurfer installed. The problem is the machine I tried to scp to also has freesurfer's settings in .bashrc. Somehow source those .sh create a problem. Anyway, nothing to do with freesurfer. Gen On Thu, Aug 26, 2010 at 8:11 AM, Gennan Chen gnc...@gmail.com wrote: Hi! All, I download and install freesurfer-Darwin-leopard-i686-stable-pub-v5.0.0 on my macbook pro yesterday. After that, scp command from terminal is not working anymore. Below is an example: gnc...@mbp:tmp]$ scp -i ~/.ssh/id_dsa.pub sdg.zip macpro:~/tmp freesurfer-Darwin-leopard-i686-stable-pub-v5.0.0 It shows freesurfer's version and did not copy file at all. I have no idea why scp command will have something to do with freesurfer. Does anyone know anything about this?? Gen ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Re: [Freesurfer] initial G-W contrast is negative
Aha. OK, omitting -no-resample, as below, outputs a well registered, but
downsampled, anatomical file. What should I change to output a well registered
anatomical file with the same dimension and voxel size as the original
anatomical? If this was in the mri_vol2vol help, it was not clear to me.
mri_vol2vol --reg register_{$S}.dat --mov epi.template_{$S}.nii --fstarg --inv
--o {$S}_Anat_in_Func_noresamp.nii
Thanks!
-Kathleen
On 8/23/10 11:44 AM, Douglas N Greve gr...@nmr.mgh.harvard.edu wrote:
Why are you using --no-resample? This will keep the anatomical in the
256^3 space (it just changes the header).
doug
Hansen, Kathleen (NIH/NIMH) [F] wrote:
Thanks. The tkregister2 check gives some new information. The initial
registration is not very bad when checked in tkregister2. Also, the final
registration is perfectly acceptable when checked in tkregister2, so my
original question needs clarification.
What I want to do is to use the register.dat file to create an anatomical
registered to a functional. I want the actual registered anatomical data as
a saved file. In the past, I applied these lines to a dataset that didn't
produce the G-W contrast warning. Also, this fmri dataset was collected in
the same scan session as the anatomical.
bbregister --mov epi.template_{$S}.nii --bold --s {$S} --init-fsl --reg
register_{$S}.dat
mri_vol2vol --reg register_{$S}.dat --mov epi.template_{$S}.nii --fstarg
--inv --no-resample --o {$S}_Anat_in_Func_noresamp.nii
The output, {$S}_Anat_in_Func_noresamp.nii, aligned well with the fmri volume
epi.template_{$S}.nii with no other registration needed.
Now I am applying these lines to several different datasets. All of them do
produce the G-W contrast warning, and they were not collected in the same
scan sessions as their surface anatomicals. In each case, the output,
{$S}_Anat_in_Func_noresamp.nii, is very far from the fmri volume
epi.template_{$S}.nii. This is strange, since in these same datasets the
register_{$S}.dat produces a good alignment between epi.template_{$S}.nii and
{$S}/mri/orig.mgz when viewed in tkregister2.
Thanks very much for your help on this,
Kathleen
On 8/20/10 11:32 AM, Douglas N Greve gr...@nmr.mgh.harvard.edu wrote:
That warning in and of itself is not critical, but it does suggest that
the initial registration failed. I assume the registration still looks
bad? Does this happen on a bunch of data sets or just this one? There
are a couple of more steps. First, you can run with --init-fsl and check
the initial registration to verify that it is way off. To do this, run
with --init-reg-out and check that registration with tkregister2. If
that is bad, you can can try two things. First, if you have spm and
matlab, you can use --init-spm. Second, you can tweak the initial
registration by hand to get it close (ie, within 5mm and 5deg), then
use --init-reg
doug
Hansen, Kathleen (NIH/NIMH) [F] wrote:
Thanks for the suggestions. It is whole-brain epi data. Unfortunately, it
was not acquired at the same time as the anatomical. Just for the heck of
it I tried substituting --init-header for --init-fsl anyway, and got the
same warning about negative G-W contrast.
-Kathleen
On 8/19/10 2:39 PM, Douglas Greve gr...@nmr.mgh.harvard.edu wrote:
It may have been the initialization that failed. Was the epi acquired
at the same time as the anatomical? If so, you might be able to run it
with --init-header. Also, is this whole brain or partial field of view?
doug
On 8/19/10 1:50 PM, Hansen, Kathleen (NIH/NIMH) [F] wrote:
Hello,
The following command has produced a very wrong registration and a warning:
bbregister --mov epi.template.strange_G-W_contrast.nii --bold --s D06
--init-fsl --reg register.strange_G-W_contrast.dat
WARNING: initial G-W contrast is negative, but expecting positive.
If the mov data has a T1 contrast, re-run with --T1
The file epi.template.strange_G-W_contrast.nii is BOLD fmri data, not
T1-weighted data. As far as I can tell, it is a typical BOLD fmri volume.
Any ideas?
Thank you,
Kathleen
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance
HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in
error
but does not contain patient information, please contact the sender and
properly
dispose of the e-mail.
--
Douglas N. Greve, Ph.D.
MGH-NMR Center
gr...@nmr.mgh.harvard.edu
Re: [Freesurfer] Notes on CUDA Acceleration
On Tue, 2010-08-24 at 09:37 -0400, Richard G. Edgar wrote: One final thing: Nick and I found last week that the accelerated mri_em_register_cuda doesn't seem to work prior to skull stripping. I'm going to work on this this week, but if you want to continue using the GPU accelerated binary, you'll have to turn off the FAST_TRANSLATION and FAST_TRANSFORM flags in mri_em_register.c, and recompile. This will increase the runtime to around 4 minutes on ernie, but will give results identical to the CPU code. Actually, the problems with mri_em_register_cuda appear to be a little more widespread. I'm working on testing this with more brains now (the perils of having only one test case...), and hope to have an update soon. Regards, Richard ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
[Freesurfer] do I have to reprocess my subjects if I install new version of Freesurfer?
Do I have to reprocess my data if I install the new (v5.0.0) version of Freesurfer? If I don't, and process more subjects in the study with v5.0.0 will that be problematic? ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Re: [Freesurfer] do I have to reprocess my subjects if I install new version of Freesurfer?
yes, you should reprocess them all, but it shouldn't require any manual interventions as we preserve the manual edits. cheers Bruce On Thu, 26 Aug 2010, Kevin Head wrote: Do I have to reprocess my data if I install the new (v5.0.0) version of Freesurfer? If I don't, and process more subjects in the study with v5.0.0 will that be problematic? ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Re: [Freesurfer] MRI Files Doubts
the reason, as i understand it, is that the analyze format does not store orientation information. this means there is no way to tell left from right, which can lead to problems in both atlas alignment, and during multimodal (fmri) registration. n. On Thu, 2010-08-26 at 13:32 -0500, Dr. Luis Guillermo Almeida Montes wrote: Dear Nick: Some colleagues asked me some doubts about pre-processing in FreeSurfer for MRI files. I remember you told me once that MRI files in analyze format would be inappropiate to pre-process in FreeSurfer suite. They work with this analyze format since their DICOM files can ´t be processed because their files are compressed.Can you give technicals details about the reasons about why analyze files cannot be used in FreeSurfer for pre-processing? Thank you. Best Regards. Dr. Luis G. Almeida ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Re: [Freesurfer] Notes on CUDA Acceleration
Hi Richard and others, allow me one additional remark that may be crucial for those considering to invest in new cards. Although the Fermi class cards make use of the same architecture (Geforce GTX 480 and Tesla C2050 for example), for consumer products (GTX 400 series), double precision performance has been limited to a quarter of that of the full Fermi architecture (Tesla C20xx). Error checking and correcting memory (ECC) is also disabled on consumer cards. I don't really know how important double precision is for the CUDA enabled Freesurfer tools, but this could mean you have to buy four GTX cards to catch up with the performance of one Tesla card. Cheers, Georg -Ursprüngliche Nachricht- Von: freesurfer-boun...@nmr.mgh.harvard.edu [mailto:freesurfer-boun...@nmr.mgh.harvard.edu] Im Auftrag von Richard G. Edgar Gesendet: Dienstag, 24. August 2010 15:38 An: freesurfer@nmr.mgh.harvard.edu Betreff: [Freesurfer] Notes on CUDA Acceleration Greetings, I've been asked to provide some extra information about GPU support in Freesurfer (being the one guilty of mri_em_register_cuda...). Firstly, there are no immediate plans for OpenCL support. It would be very nice to have - with ATI, NVIDIA _and_ x86 multicore backends. However, it's far less mature than CUDA. The good news is that the really 'hard' bit is restructuring the algorithms to fit well on a GPU. The syntax of CUDA and OpenCL is very similar (strange that), but OpenCL is more verbose. As for cards. for what is in the current release, any GeForce GTX-200 series or Tesla 10 series (i.e. C1060 and S1070) card should work (I don't know the Quadro model numbers - CUDA architecture 1.3 is the key feature). I think that everything should actually work on somewhat older cards, but the compile flags will have to be tweaked. So long as that threshold is reached, the only issue is the amount of RAM needed. Currently, I expect that any card with at least 1 GiB of RAM will have plenty, and the threshold for mri_em_register_cuda will be much lower than that. Going forward, I would strongly recommend purchasing 'Fermi' class cards. These are the GTX 400 series, and Tesla 20 series. The new architecture lifts some hardware limits on GPU kernels which are crippling for portions of mri_ca_register. With a more accelerated mri_ca_register, RAM limits may also come into play, until I can come up with a suitably cunning GPU implementation of the Gaussian Classifier Array (right now, I'm going to burn around 2 GiB on a single GCA, to make implementation simple). However, I have bigger fish to fry first. One final thing: Nick and I found last week that the accelerated mri_em_register_cuda doesn't seem to work prior to skull stripping. I'm going to work on this this week, but if you want to continue using the GPU accelerated binary, you'll have to turn off the FAST_TRANSLATION and FAST_TRANSFORM flags in mri_em_register.c, and recompile. This will increase the runtime to around 4 minutes on ernie, but will give results identical to the CPU code. I hope this is helpful, Richard ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer The information in this e-mail is intended only for the person to whom it is addressed. If you believe this e-mail was sent to you in error and the e-mail contains patient information, please contact the Partners Compliance HelpLine at http://www.partners.org/complianceline . If the e-mail was sent to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail. ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
