Re: [Freesurfer] Changing wstresh and removing wsg-atlas - consequences?
Hi Silas, Changing the wsthresh and wsgatlas parameters only affect the brainmask (which is, among other things, used to limit how far the pial surface is allowed to grow). This shouldn't affect the white matter. if your data contrast is good, you generally wont see much affect from adjusting these parameters. However, if the contrast is bad you need to inspect your brainmasks carefully, to make sure they improved (without removing actual brain from the image). Furthermore, in this case it is likely you'll also need to edit the brainmasks manually. To answer your question: Whenever you modify the parameters, and in particular if you need to edit brainmasks, you introduce a bias in your study (your qualitative evaluation of how good the brainmasks / pial surfaces are). You need to consider if adjusting brainmasks is better than letting the pipeline do its job - which boils down to the number of subjects you have. The more you have, the more robust your statistics will be, and the more likely it is that you can leave everything as it is. However, If you have few subjects, bad data quality (and in turn, brainmask quality) can really impact your pial surface, and then it may be best to adjust the masks. We can talk more at the hospital if you need further discussion, and also look at your data ;-) Best, Christian On 02/16/2015 01:54 PM, Silas wrote: Hi Freesurfer team, I'm currently making an structural analysis using freesurfer. In the analysis i'm comparing 3 groups; 2 patient groups with different reactions to a certain type of medication and a healthy control group. In the freesurfer pipeline i'm changing the parameters wsthresh and wsgatlas in order to obtain a better fitted pial surface and white matter surface - and i was wondering if changing these parameters affect the comparability of the 3 groups (if e.g. i would like to investigate the inferior frontal gyrus)? Best, Silas ___ 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 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] recon-all normalization: bias field output
Hi Barbara, Hang on, this will be slightly hairy. Right now, if you're not using the -3T flag when you run recon-all, you're essentially invoking N3 four times (the N3 wrapper, mri_nu_correct.mni). Every time you invoke N3, the output files are stored in separate directories (the once you located yourself). If you use the -3T flag, things simplifies greatly. I presume you're not using the -3T flag, since you mentioned several N3 output directories. Now generally, in terms of the bias field correction model (bias is assumed to be multiplicative), there's no difference in running N3 once or four times. However, N3 does a couple of things that will yield a small difference. N3 first computes a threshold mask, which it uses to limit the voxels it estimates the bias from. Then it estimates the bias. Then it performs a final smoothing of the bias, and then it divides the uncorrected data with the bias to obtain a corrected estimate. So to summarize, when you do not use the -3T parameter, you: 1. threshold a mask 2. estimate a bias 3. do a final smoothing of the bias 4. correct (divide uncorrected with bias) 5. repeat from 1. The effect of the above might or might not be negligible, depending on your data. Practically though, the big chunk of the correction is done in the first mri_nu_correct.mni iteration. And if you're using -3T, you can disregard step 5. What kind of data do you work on (field strength)? To answer your question: If you want the 'bias' that is corrected for with Freesurfer, you want to divide the volume prior to feeding mri_nu_correct.mni, with the corrected volume after running mri_nu_correct.mni the fourth time. You could also try to run nu_correct yourself with the proper arguments - this gives you a much better understanding of the method - and internal output that you can log and analyse (-verbose flag). If you need to work with the tmp files, The thresholded mask you're interested in, is called nuc_auto_mask.mnc. The field estimate that N3 uses to divide the uncorrected data, is called corrected_field.mnc. Note that I'm working directly with the N3 binary, so there's a chance that the names differ (but I do not think so, since these names seem to be hardcoded). There should not be any differences in volume dimensions, if you're using the right volumes. Best, Christian On 08/29/2014 10:34 AM, Barbara Kreilkamp wrote: Dear Freesurfers, The recon-all.log does not give info about the intermediate outputs (like nu2_est and nu2_field mnc-files), could you please confirm that the nu2_field.mnc is the bias field volume? It is the biggest file of all and is one of the last files generated by the script, but I would like to be sure. Thank you very much, Barbara On Thu, Aug 28, 2014 at 3:27 PM, Barbara Kreilkamp bakk@googlemail.com mailto:bakk@googlemail.com wrote: Dear Bruce and Christian, I found the easy way of simply writing 'set cleanup = 0' at the beginning of mri_nu_correct.mni and then I run this command mri_nu_correct.mni --i T2-scic/mri/orig/001.mgz --o nu.mgz --n 2 This way I get all the masks and iterations that were computed. Now I also see that it generates as many folders as there are iterations, ending with nu2_field and nu2_est if there are two iterations. I see more files now and now I am thinking that the last output is nu2_field, which would be the bias field. So this is why I did not divide anything by hand (also because my 001.mgz and the nu.mgz do not have the same image dimensions) and the info about masked-out voxel would be missing in that case. All the best and thanks. Barbara On 28/08/2014 14:46, Bruce Fischl wrote: Hi Barbara what exactly did you divide? If you look at the recon-all.log it will show the exact inputs and outputs of nu_correct. cheers Bruce On Thu, 28 Aug 2014, Barbara Kreilkamp wrote: Dear Christian, Thanks a bunch for this answer. I ran all the steps you mentioned (except for the one where I simply do uncorrected/corrected, as these images have different dimensions, it seems nu3 does more than just normalization of intensities, but also image cropping). Do you know anything about the image cropping? I ended up with the output nu1_mask and nu1_est and I think the last one is the bias field, at least it looks very much like one :). Am I right? Thanks for your help, Barbara On 27/08/2014 22:53, Christian Thode Larsen wrote: Hi Barbara, I'm not aware of any way that you can do it directly by passing arguments to recon-all (some might correct me
Re: [Freesurfer] recon-all normalization: bias field output
Hi Barbara, I'm not aware of any way that you can do it directly by passing arguments to recon-all (some might correct me on that), but it is possible: 1) As N3 models the bias as a multiplicative effect uncorrected = corrected * bias, the simplest way is to divide each voxel of the volume before and after correction, in order to obtain a volume containing the bias. Note that N3 (by default) works within a mask where low-intensity voxels have been thresholded away. These voxels will contain garbage if you divide all voxels in the volume. 2) Somewhat more complicated: you can specify the -keeptmp flag combined with -tmp SOMEDIR/ (remember the trailing slash) to N3, in order to preserve its working files. This requires you to modify the N3 binary call in the mri_nu_correct.mni script. You also need to convert the mnc files from the tmp dir, so that you can work with the volumes. 3) if you do 2), you also get hold of the low-intensity voxel mask that N3 operates within. You can use this to constrain the division mentioned in 1). Best, Christian On 8/27/2014 11:18 PM, Barbara Kreilkamp wrote: Dear all, Is there a way to output the N3's (non-parametric normalization step) output? I am interested in the bias field that was computed to correct the image intensities. Thank you for your help, Barbara ___ 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
Re: [Freesurfer] DEPRECATED warning in Freesurfers
Hi, While you're on the subject, there's a version 1.12 available from http://packages.bic.mni.mcgill.ca/tgz/ (dated January 2011, Freesurfer wraps and uses 1.10). I'm running tests with this version, and it also produces the errors mentioned. Best Regards, Christian On 06/03/2013 02:56 PM, Bruce Fischl wrote: Hi Peter I would try this: http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-users Bruce On Mon, 3 Jun 2013, Peter Wendorff wrote: Hi Brucel yes, sure - sorry. I followed your advice (your response to my first mail here), and found http://www.bic.mni.mcgill.ca/Research/Homepage which - if I'm not mistaken - is the MNI institute you pointed me to. As there's no John Sled listed on their website I wrote to Jennifer Chew, who is mentioned as general admnistrative questions or assistance, but I did not get an answer yet. I'll wait for a response further, but if there's any more direct contact, I would be happy to get an additional pointer ;) regards Peter Am 03.06.2013 14:29, schrieb Bruce Fischl: Hi Peter, did you mean MNI when you said MRI? I think that they are still maintaining it - I would be surprised otherwise Bruce On Mon, 3 Jun 2013, Peter Wendorff wrote: Hi again. So: is the MRI stuff dead code? I wrote an email to Jennifer Chew asking for the right contact for bugs/issues regarding that code. That mail has been sent on May 22nd and I didn't get any response, yet. Is that code ever updated by the freesurfer team? Or only if there's anybody from MRI joining in by some kind of a pull request (in git terms)? If the latter: Are pull requests accepted even by other people than MRI stuff (e.g. by me, if I'm working out my patch, which I haven't done yet)? How to apply that patch then? regards Peter Am 15.05.2013 16:18, schrieb Peter Wendorff: Hi Bruce. Thanks - kind of... Can you point me to anybody working on that stuff there currently? The cprresponding code is from 1996, and according to the MNI website, it's author John Sled isn't there any more. Who's the maintainer of these code parts in the freesurfer project? (Or isn't there anybody responsible?) Is there some kind of master repository/project for their code in Freesurfer (if the freesurfer project I hoped to address here isn't responsible for it)? If I were a pearl guru and know exactly what could and could not happen by this patch, I would probably ask for repository access, but I'm not, so any contact being responsible would be great. regards Peter Am 15.05.2013 15:04, schrieb Bruce Fischl: thanks Peter, that's actually MNI code, so you might want to report it to them. Bruce On Wed, 15 May 2013, Peter Wendorff wrote: Hi. I'm working with freesurfer as a software developer in a cloud project. My task is to enable control of freesurfer via network (e.g. REST interfaces). That works fine so far, but I stumbled over the following pearl deprecated warning: Use of ?PATTERN? without explicit operator is deprecated at /usr/local/freesurfer//mni/bin/sharpen_volume line 153. Which has been printed to the log files repeatingly. I'm not a pearl expert, but I think, it's due to a more up to date pearl version used here, that deprecated the usage of ? delimiters for patterns without explicit operator. Using / as a delimiter works fine. I changed that locally to (new line 153): ($output_volume =~ /^([\S]+).mnc/) ($base_name = $1) || die sharpen_volume failed: output volume does not appear to be . a minc volume.\n; (the original code here was): ($output_volume =~ ?^([\S]+).mnc?) ($base_name = $1) || die sharpen_volume failed: output volume does not appear to be . a minc volume.\n; I'm not sure this is the best solution. It's even not strictly necessary to change this - it's only a warning that's thrown; but I think, it's useful. How can I submit this as a patch? Is it enough to report here? What to do? regards Peter Wendorff P.S.: For referene the header parameters of my sharpen_volume for revision comparison: # #$RCSfile: sharpen_volume.in,v $ #$Revision: 1.1 $ #$Author: bert $ #$Date: 2003/04/16 14:29:34 $ #$State: Exp $ #--- # -- MNI Header -- #@NAME : sharpen_volume #@INPUT : #@OUTPUT : #@RETURNS: #@DESCRIPTION: modifies intensities so as to produce a sharper histogram #@METHOD : #@GLOBALS: #@CALLS : #@CREATED: February 28, 1996 #@MODIFIED : #- ___ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu
[Freesurfer] Gradient unwarp software / Siemens Verio scanner
Hi, I'm currently exploring gradient unwarping of data on a Siemens Trio scanner (sonata coils) and a Siemens Verio scanner. I have got lists with coil coefficients for both scanners. According to the FS mail archives, you provide a binary for gradient unwarping, but not any scanner tables (due to licensing), or the conversion scripts mentioned here:https://surfer.nmr.mgh.harvard.edu/fswiki/GradientUnwarping https://surfer.nmr.mgh.harvard.edu/fswiki/GradientUnwarping. With some googling, I have found this version:https://code.google.com/p/gradunwarp/ https://code.google.com/p/gradunwarp/https://code.google.com/p/gradunwarp/ which seems to be the latest available version of the software (originally written by Czanner). This package also provides the table conversion scripts. The development appears to be stalled, however. I have used this version for (what seems to be) successful gradient unwarping of Siemens Trio data. A couple of questions: 1) Can you enlighten me as to the latest and 'most proper' version of the software to use for gradient unwarping (bug fixes, scanner support)? Is the binary in FS further developed than the google docs version, and if so, have I somehow missed the table conversion scripts? 2) At DRCMR (see below), we have a Siemens Verio scanner, as well as a list with the associated gradient coil coefficients. As of now, it seems like the correction software (public FS + google doc version) does not support this scanner type. Is this something that could possibly be included? Or is a newer (possibly non-public) version available that supports it already? We're aware that the scanner can perform correction by itself, but as far as I know this is only in 3D, and also requires you to do it immediately after the sequence. Best Regards, Christian Thode Larsen PhD Student Technical University of Denmark (DTU) / Danish Research Centre for Magnetic Resonance (DRCMR) Supervisor: Koen Van Leemput ___ 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.
