date:20160704

Also when I run mir_convert on the DICOMs I get the same error as the one I got
when I used DICOMs :
WARNING: file
/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/3T2/MR.1.3.12.2.1107.5.2.19.45306.2014091812330393354083931
does not contain a Siemens ASCII header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header

Any idea what this could be ?

Thanks,

Ismail

On Jul 4, 2016, at 3:15 PM, Koubiyr, Ismail
> wrote:

It says 1 … I don’t understand why I get that knowing that when I open the
nifti I can go through the frames …

Ismail

On Jul 4, 2016, at 3:11 PM, Anastasia Yendiki
> wrote:

I do not know why the dicoms do not work. When you run mri_info on your nifti,
what is the number of frames that shows up?

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:

Hi Anastasia,

This is what’s weird, my nifti volume contains 64 frames as my bvecs/bvals. So
this shouldn’t be the reason.
Also why the DICOMs wouldn’t work at the beginning ?

Thanks,
Ismail

On Jul 4, 2016, at 2:41 PM, Anastasia Yendiki
> wrote:

Hi Ismail - You can see from the log file that the command that causes the
error is this:

mri_convert --frame 31
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi.nii.gz
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi_frame31.nii.gz

It's trying to extract the 32nd frame of your nifti file, but from the error
message it looks like your nifti file doesn't have a 32nd frame. So either the
nifti file has too few volumes, or the bvecs/bvals have too many lines. You'll
have to figure that out.

a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:

Hi Anastasia,
Here it is.
But how could the problem be related to the nifti volume since I have errors
when using the DICOMs too ?
Thanks again,
Ismail
On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki
> wrote:

Hi Ismail - It sounds like the error has to do with the nifti volume, not
the bvecs/bvals. Can you send the log file from scripts/trac-all.log?

Thanks,
a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:

Hi Anastasia,
Thank you for getting back to me.
Here are more details about my problem, I think it should help you
understand more.
I run trac-all -prep -c on some DICOM files but I had the following error
:
WARNING:file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.368
0043
.6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header
I also tried to de-mosiac the DICOMs, it gave me the same error.
Then I converted the DICOMs into NIFTI, which allowed me not to get the
previous error but something else weird happened. Now I get :
ERROR: fMRIframe: frame >= nframes
I checked the bvecs and bvals files, they seem normal, no additional
space,
but when the new bvecs and bvals are created, they seem messed up. I
will
attach you all the bvecs and bvals I used and the ones I get too.
Ideally, the DICOMs should work fine but I have no idea why I get these
errors.
The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
any additional space.
Thank you in advance for your help.
Best,
Ismail
P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.

On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
> wrote:
Hi Ismail - Are you passing the nifti volume as input to trac-all?
It's
hard to tell without looking at your configuration file.
Best,
a.y
On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:

Hi everyone,

I have some problems trying to run TRACULA on some DWI
data. It is a mosaic Siemens DWI. I first converted the
DICOM files with dcm2nii to get the bvec and bval files.
Then I run the trac-all -prep -c command and I get the
following error :

WARNING: file /My/path/to/dicom does not contain a Siemens
ASCII header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header

I tried to unpack the mosaics with gdcmtar, but I got the
same error.

Thank you in advance for your help,

Ismail
___
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
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

Re: [Freesurfer] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header

It says 1 … I don’t understand why I get that knowing that when I open the 
nifti I can go through the frames …

Ismail

> On Jul 4, 2016, at 3:11 PM, Anastasia Yendiki  
> wrote:
> 
> 
> I do not know why the dicoms do not work. When you run mri_info on your 
> nifti, what is the number of frames that shows up?
> 
> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
> 
>> Hi Anastasia,
>> 
>> This is what’s weird, my nifti volume contains 64 frames as my bvecs/bvals. 
>> So this shouldn’t be the reason.
>> Also why the DICOMs wouldn’t work at the beginning ?
>> 
>> Thanks,
>> Ismail
>> 
>>> On Jul 4, 2016, at 2:41 PM, Anastasia Yendiki 
>>>  wrote:
>>> 
>>> 
>>> Hi Ismail - You can see from the log file that the command that causes the 
>>> error is this:
>>> 
>>> mri_convert --frame 31 
>>> /Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi.nii.gz 
>>> /Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi_frame31.nii.gz
>>> 
>>> It's trying to extract the 32nd frame of your nifti file, but from the 
>>> error message it looks like your nifti file doesn't have a 32nd frame. So 
>>> either the nifti file has too few volumes, or the bvecs/bvals have too many 
>>> lines. You'll have to figure that out.
>>> 
>>> a.y
>>> 
>>> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
>>> 
 Hi Anastasia,
 Here it is.
 But how could the problem be related to the nifti volume since I have 
 errors
 when using the DICOMs too ?
 Thanks again,
 Ismail
> On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki
  wrote:
> 
> 
> Hi Ismail - It sounds like the error has to do with the nifti volume, not
 the bvecs/bvals. Can you send the log file from scripts/trac-all.log?
> 
> Thanks,
> a.y
> 
> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
> 
>> Hi Anastasia,
>> Thank you for getting back to me.
>> Here are more details about my problem, I think it should help you
>> understand more.
>> I run trac-all -prep -c on some DICOM files but I had the following error
 :
>> WARNING:file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.368
 0043
>> .6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
>> header
>> has this file been anonymized?
>> ERROR: cannot unpack mosiacs without ASCII header
>> I also tried to de-mosiac the DICOMs, it gave me the same error.
>> Then I converted the DICOMs into NIFTI, which allowed me not to get the
>> previous error but something else weird happened. Now I get :
>> ERROR: fMRIframe: frame >= nframes
>> I checked the bvecs and bvals files, they seem normal, no additional
 space,
>> but when the new bvecs  and bvals are created, they seem messed up. I
 will
>> attach you all the bvecs and bvals I used and the ones I get too.
>> Ideally, the DICOMs should work fine but I have no idea why I get these
>> errors.
>> The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
>> any additional space.
>> Thank you in advance for your help.
>> Best,
>> Ismail
>> P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.
>> 
>> On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
>>  wrote:
>> Hi Ismail - Are you passing the nifti volume as input to trac-all?
>> It's
>> hard to tell without looking at your configuration file.
>> Best,
>> a.y
>> On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:
>> 
>> Hi everyone,
>> 
>> I have some problems trying to run TRACULA on some DWI
>> data. It is a mosaic Siemens DWI. I first converted the
>> DICOM files with dcm2nii to get the bvec and bval files.
>> Then I run the trac-all -prep -c command and I get the
>> following error :
>> 
>> WARNING: file /My/path/to/dicom does not contain a Siemens
>> ASCII header
>> has this file been anonymized?
>> ERROR: cannot unpack mosiacs without ASCII header
>> 
>> I tried to unpack the mosaics with gdcmtar, but I got the
>> same error.
>> 
>> Thank you in advance for your help,
>> 
>> Ismail
>> ___
>> 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
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>> ___

Re: [Freesurfer] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header



I do not know why the dicoms do not work. When you run mri_info on your 
nifti, what is the number of frames that shows up?


On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:


Hi Anastasia,

This is what’s weird, my nifti volume contains 64 frames as my bvecs/bvals. So 
this shouldn’t be the reason.
Also why the DICOMs wouldn’t work at the beginning ?

Thanks,
Ismail


On Jul 4, 2016, at 2:41 PM, Anastasia Yendiki  
wrote:


Hi Ismail - You can see from the log file that the command that causes the 
error is this:

mri_convert --frame 31 
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi.nii.gz 
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi_frame31.nii.gz

It's trying to extract the 32nd frame of your nifti file, but from the error 
message it looks like your nifti file doesn't have a 32nd frame. So either the 
nifti file has too few volumes, or the bvecs/bvals have too many lines. You'll 
have to figure that out.

a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:


Hi Anastasia,
Here it is.
But how could the problem be related to the nifti volume since I have errors
when using the DICOMs too ?
Thanks again,
Ismail

On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki

 wrote:



Hi Ismail - It sounds like the error has to do with the nifti volume, not

the bvecs/bvals. Can you send the log file from scripts/trac-all.log?


Thanks,
a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:


Hi Anastasia,
Thank you for getting back to me.
Here are more details about my problem, I think it should help you
understand more.
I run trac-all -prep -c on some DICOM files but I had the following error

:

WARNING:file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.368

0043

.6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header
I also tried to de-mosiac the DICOMs, it gave me the same error.
Then I converted the DICOMs into NIFTI, which allowed me not to get the
previous error but something else weird happened. Now I get :
ERROR: fMRIframe: frame >= nframes
I checked the bvecs and bvals files, they seem normal, no additional

space,

but when the new bvecs  and bvals are created, they seem messed up. I

will

attach you all the bvecs and bvals I used and the ones I get too.
Ideally, the DICOMs should work fine but I have no idea why I get these
errors.
The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
any additional space.
Thank you in advance for your help.
Best,
Ismail
P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.

 On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
  wrote:
Hi Ismail - Are you passing the nifti volume as input to trac-all?
It's
hard to tell without looking at your configuration file.
Best,
a.y
On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:

 Hi everyone,

 I have some problems trying to run TRACULA on some DWI
 data. It is a mosaic Siemens DWI. I first converted the
 DICOM files with dcm2nii to get the bvec and bval files.
 Then I run the trac-all -prep -c command and I get the
 following error :

 WARNING: file /My/path/to/dicom does not contain a Siemens
 ASCII header
 has this file been anonymized?
 ERROR: cannot unpack mosiacs without ASCII header

 I tried to unpack the mosaics with gdcmtar, but I got the
 same error.

 Thank you in advance for your help,

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

___
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




___
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] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header

Hi Anastasia,

This is what’s weird, my nifti volume contains 64 frames as my bvecs/bvals. So 
this shouldn’t be the reason.
Also why the DICOMs wouldn’t work at the beginning ?

Thanks,
Ismail

> On Jul 4, 2016, at 2:41 PM, Anastasia Yendiki  
> wrote:
> 
> 
> Hi Ismail - You can see from the log file that the command that causes the 
> error is this:
> 
> mri_convert --frame 31 
> /Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi.nii.gz 
> /Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi_frame31.nii.gz
> 
> It's trying to extract the 32nd frame of your nifti file, but from the error 
> message it looks like your nifti file doesn't have a 32nd frame. So either 
> the nifti file has too few volumes, or the bvecs/bvals have too many lines. 
> You'll have to figure that out.
> 
> a.y
> 
> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
> 
>> Hi Anastasia,
>> Here it is.
>> But how could the problem be related to the nifti volume since I have errors
>> when using the DICOMs too ?
>> Thanks again,
>> Ismail
>> > On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki
>>  wrote:
>> >
>> >
>> > Hi Ismail - It sounds like the error has to do with the nifti volume, not
>> the bvecs/bvals. Can you send the log file from scripts/trac-all.log?
>> >
>> > Thanks,
>> > a.y
>> >
>> > On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
>> >
>> >> Hi Anastasia,
>> >> Thank you for getting back to me.
>> >> Here are more details about my problem, I think it should help you
>> >> understand more.
>> >> I run trac-all -prep -c on some DICOM files but I had the following error
>> :
>> >> WARNING:file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.368
>> 0043
>> >> .6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
>> >> header
>> >> has this file been anonymized?
>> >> ERROR: cannot unpack mosiacs without ASCII header
>> >> I also tried to de-mosiac the DICOMs, it gave me the same error.
>> >> Then I converted the DICOMs into NIFTI, which allowed me not to get the
>> >> previous error but something else weird happened. Now I get :
>> >> ERROR: fMRIframe: frame >= nframes
>> >> I checked the bvecs and bvals files, they seem normal, no additional
>> space,
>> >> but when the new bvecs  and bvals are created, they seem messed up. I
>> will
>> >> attach you all the bvecs and bvals I used and the ones I get too.
>> >> Ideally, the DICOMs should work fine but I have no idea why I get these
>> >> errors.
>> >> The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
>> >> any additional space.
>> >> Thank you in advance for your help.
>> >> Best,
>> >> Ismail
>> >> P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.
>> >>
>> >>  On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
>> >>   wrote:
>> >> Hi Ismail - Are you passing the nifti volume as input to trac-all?
>> >> It's
>> >> hard to tell without looking at your configuration file.
>> >> Best,
>> >> a.y
>> >> On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:
>> >>
>> >>  Hi everyone,
>> >>
>> >>  I have some problems trying to run TRACULA on some DWI
>> >>  data. It is a mosaic Siemens DWI. I first converted the
>> >>  DICOM files with dcm2nii to get the bvec and bval files.
>> >>  Then I run the trac-all -prep -c command and I get the
>> >>  following error :
>> >>
>> >>  WARNING: file /My/path/to/dicom does not contain a Siemens
>> >>  ASCII header
>> >>  has this file been anonymized?
>> >>  ERROR: cannot unpack mosiacs without ASCII header
>> >>
>> >>  I tried to unpack the mosaics with gdcmtar, but I got the
>> >>  same error.
>> >>
>> >>  Thank you in advance for your help,
>> >>
>> >>  Ismail
>> >>  ___
>> >>  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
>> > ___
>> > 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


___
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

Re: [Freesurfer] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header



Hi Ismail - You can see from the log file that the command that causes the 
error is this:


mri_convert --frame 31 
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi.nii.gz 
/Users/ismailkoubiyr/Documents/PFE/Tracula/out/3T5/dmri/dwi_frame31.nii.gz

It's trying to extract the 32nd frame of your nifti file, but from the 
error message it looks like your nifti file doesn't have a 32nd frame. So 
either the nifti file has too few volumes, or the bvecs/bvals have too 
many lines. You'll have to figure that out.


a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:


Hi Anastasia,

Here it is.
But how could the problem be related to the nifti volume since I have errors
when using the DICOMs too ?
Thanks again,

Ismail



> On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki
 wrote:
>
>
> Hi Ismail - It sounds like the error has to do with the nifti volume, not
the bvecs/bvals. Can you send the log file from scripts/trac-all.log?
>
> Thanks,
> a.y
>
> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
>
>> Hi Anastasia,
>> Thank you for getting back to me.
>> Here are more details about my problem, I think it should help you
>> understand more.
>> I run trac-all -prep -c on some DICOM files but I had the following error
:
>> 
WARNING:file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.368
0043
>> .6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
>> header
>> has this file been anonymized?
>> ERROR: cannot unpack mosiacs without ASCII header
>> I also tried to de-mosiac the DICOMs, it gave me the same error.
>> Then I converted the DICOMs into NIFTI, which allowed me not to get the
>> previous error but something else weird happened. Now I get :
>> ERROR: fMRIframe: frame >= nframes
>> I checked the bvecs and bvals files, they seem normal, no additional
space,
>> but when the new bvecs  and bvals are created, they seem messed up. I
will
>> attach you all the bvecs and bvals I used and the ones I get too.
>> Ideally, the DICOMs should work fine but I have no idea why I get these
>> errors.
>> The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
>> any additional space.
>> Thank you in advance for your help.
>> Best,
>> Ismail
>> P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.
>>
>>  On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
>>   wrote:
>> Hi Ismail - Are you passing the nifti volume as input to trac-all?
>> It's
>> hard to tell without looking at your configuration file.
>> Best,
>> a.y
>> On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:
>>
>>  Hi everyone,
>>
>>  I have some problems trying to run TRACULA on some DWI
>>  data. It is a mosaic Siemens DWI. I first converted the
>>  DICOM files with dcm2nii to get the bvec and bval files.
>>  Then I run the trac-all -prep -c command and I get the
>>  following error :
>>
>>  WARNING: file /My/path/to/dicom does not contain a Siemens
>>  ASCII header
>>  has this file been anonymized?
>>  ERROR: cannot unpack mosiacs without ASCII header
>>
>>  I tried to unpack the mosaics with gdcmtar, but I got the
>>  same error.
>>
>>  Thank you in advance for your help,
>>
>>  Ismail
>>  ___
>>  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
> ___
> 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] Failure to use yeo-7/17 networks maps as templates in MRIcron

2016-07-04 Thread Hsiang-Yuan Lin

Hi Thomas,

Thanks for swift instruction. It works well. However, I have further
question: could I write the color lut into header? Because I used your
suggested Colorlut information to create a new .lut file and put them into
MRIcron templates folder with the correctely oriented Yeo2011_7network
template. But it failed to present the designated color in MRIcron.

Thank you!

Best,
Hsiang-Yuan

On Mon, Jul 4, 2016 at 4:37 PM, Thomas Yeo  wrote:

> Hi Hsiang-Yuan,
>
> That's because the header information is different. You can do the
> following:
>
> >> mri_vol2vol --mov Yeo2011Parcellation.nii.gz --targ
> FSL_MNI2mm_template.nii.gz --regheader --nearest --o Yeo2011_FSL2mm.nii.gz
>
> The output file "Yeo2011_FSL2mm.nii.gz" should have an orientation
> compatible with mricron. Can you let me know if this works.
>
> Thanks,
> Thomas
>
> On Mon, Jul 4, 2016 at 12:58 AM, Hsiang-Yuan Lin 
> wrote:
> > Hi Prof. Yeo,
> >
> > I have problems utilizing yeo 7/17 cortical network parcellation maps as
> > templates in MRIcron (I aim to use your cortical parcellation maps to
> > underlay my findings in order to derive the implications based on iFC
> > networks). To be specific, there is an orientation problem in the current
> > version of parcellation maps in MNI space.
> >
> > Thank you for your help in advance.
> >
> > Best,
> > Hsiang-Yuan
> >
> > --
> > Hsiang-Yuan Lin, M.D.
> > Attending Psychiatrist & Adjunct Lecturer
> > Department of Psychiatry & Child Mental Health Center
> > National Taiwan University Hospital and College of Medicine
> > email: louisli...@gmail.com
> > CV:
> >
> https://drive.google.com/file/d/0B3jQGSXih2aeY2o1QnJwUVJjU1U/view?usp=sharing
> > https://www.researchgate.net/profile/Hsiang_Yuan_Lin2
> >
> >
> >
> > --
> > Hsiang-Yuan Lin, M.D.
> > Attending Psychiatrist & Adjunct Lecturer
> > Department of Psychiatry & Child Mental Health Center
> > National Taiwan University Hospital and College of Medicine
> > email: louisli...@gmail.com
> > CV:
> >
> https://drive.google.com/file/d/0B3jQGSXih2aeY2o1QnJwUVJjU1U/view?usp=sharing
> > https://www.researchgate.net/profile/Hsiang_Yuan_Lin2
>



-- 
*Hsiang-Yuan Lin, M.D.*


*Attending Psychiatrist & Adjunct LecturerDepartment of Psychiatry & Child
Mental Health CenterNational Taiwan University Hospital and College of
Medicine*
email: louisli...@gmail.com
CV:
https://drive.google.com/file/d/0B3jQGSXih2aeY2o1QnJwUVJjU1U/view?usp=sharing

https://www.researchgate.net/profile/Hsiang_Yuan_Lin2
___
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] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header

Hi Anastasia,

Here it is.
But how could the problem be related to the nifti volume since I have errors 
when using the DICOMs too ?
Thanks again,

Ismail



> On Jul 4, 2016, at 1:44 PM, Anastasia Yendiki  
> wrote:
>
>
> Hi Ismail - It sounds like the error has to do with the nifti volume, not the 
> bvecs/bvals. Can you send the log file from scripts/trac-all.log?
>
> Thanks,
> a.y
>
> On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:
>
>> Hi Anastasia,
>> Thank you for getting back to me.
>> Here are more details about my problem, I think it should help you
>> understand more.
>> I run trac-all -prep -c on some DICOM files but I had the following error :
>> WARNING: 
>> file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.3680043
>> .6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
>> header
>> has this file been anonymized?
>> ERROR: cannot unpack mosiacs without ASCII header
>> I also tried to de-mosiac the DICOMs, it gave me the same error.
>> Then I converted the DICOMs into NIFTI, which allowed me not to get the
>> previous error but something else weird happened. Now I get :
>> ERROR: fMRIframe: frame >= nframes
>> I checked the bvecs and bvals files, they seem normal, no additional space,
>> but when the new bvecs  and bvals are created, they seem messed up. I will
>> attach you all the bvecs and bvals I used and the ones I get too.
>> Ideally, the DICOMs should work fine but I have no idea why I get these
>> errors.
>> The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
>> any additional space.
>> Thank you in advance for your help.
>> Best,
>> Ismail
>> P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.
>>
>>  On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
>>   wrote:
>> Hi Ismail - Are you passing the nifti volume as input to trac-all?
>> It's
>> hard to tell without looking at your configuration file.
>> Best,
>> a.y
>> On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:
>>
>>  Hi everyone,
>>
>>  I have some problems trying to run TRACULA on some DWI
>>  data. It is a mosaic Siemens DWI. I first converted the
>>  DICOM files with dcm2nii to get the bvec and bval files.
>>  Then I run the trac-all -prep -c command and I get the
>>  following error :
>>
>>  WARNING: file /My/path/to/dicom does not contain a Siemens
>>  ASCII header
>>  has this file been anonymized?
>>  ERROR: cannot unpack mosiacs without ASCII header
>>
>>  I tried to unpack the mosaics with gdcmtar, but I got the
>>  same error.
>>
>>  Thank you in advance for your help,
>>
>>  Ismail
>>  ___
>>  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
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer



trac-all.log
Description: trac-all.log
___
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] controlling for total gray matter volume (Clara K?hn)

yes, just note that they are somewhat different hypothoses that you are 
testing as noted by Mike in the past. If you use average surface 
area/thickness you are testing the hypothesis that part of the brain is not 
changing/different relative to the average. If you control for TIV (or the 
2/3 root of it I guess for surface area) you are looking for any change 
while removing head size as a nuisance variable. I think Mike's is probably 
the more interesting approach, but they are somewhat distinct.

cheers
Bruce

On Mon, 4 Jul 2016, Arkadiy Maksimovskiy wrote:

> Hi Clara,
> Yes- my apologies. I misunderstood your initial analyses description. Sounds
> right to me as well.
> 
> - Arkadiy
> 
>
___
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] controlling for total gray matter volume (Clara K?hn)

2016-07-04 Thread Arkadiy Maksimovskiy

Hi Clara,

Yes- my apologies. I misunderstood your initial analyses description.
Sounds right to me as well.

- Arkadiy
___
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] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header



Hi Ismail - It sounds like the error has to do with the nifti volume, not 
the bvecs/bvals. Can you send the log file from scripts/trac-all.log?


Thanks,
a.y

On Mon, 4 Jul 2016, Koubiyr, Ismail wrote:


Hi Anastasia,

Thank you for getting back to me.
Here are more details about my problem, I think it should help you
understand more.

I run trac-all -prep -c on some DICOM files but I had the following error :
WARNING: 
file/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.3680043
.6.8878.22551.20150806120704.648.1017 does not contain a Siemens ASCII
header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header
I also tried to de-mosiac the DICOMs, it gave me the same error.

Then I converted the DICOMs into NIFTI, which allowed me not to get the
previous error but something else weird happened. Now I get :
ERROR: fMRIframe: frame >= nframes
I checked the bvecs and bvals files, they seem normal, no additional space,
but when the new bvecs  and bvals are created, they seem messed up. I will
attach you all the bvecs and bvals I used and the ones I get too.

Ideally, the DICOMs should work fine but I have no idea why I get these
errors.
The bvecs and bvals are obtained from dcm2nii and then corrected to avoid
any additional space.

Thank you in advance for your help.

Best,

Ismail

P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.


  On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki
   wrote:


Hi Ismail - Are you passing the nifti volume as input to trac-all?
It's
hard to tell without looking at your configuration file.

Best,
a.y

On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:

  Hi everyone,

  I have some problems trying to run TRACULA on some DWI
  data. It is a mosaic Siemens DWI. I first converted the
  DICOM files with dcm2nii to get the bvec and bval files.
  Then I run the trac-all -prep -c command and I get the
  following error :

  WARNING: file /My/path/to/dicom does not contain a Siemens
  ASCII header
  has this file been anonymized?
  ERROR: cannot unpack mosiacs without ASCII header

  I tried to unpack the mosaics with gdcmtar, but I got the
  same error.

  Thank you in advance for your help,

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



___
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] longitudinal tracula



Hi Michael - There is no bvec file associated with the base template. The 
base template is a structural (the median of a subject's structural time 
points) and not a diffusion scan.


The way you'd want to account for different amounts of motion across 
subjects in a cross-sectional analysis, you'd probably want to account for 
different changes in motion in a longitudinal study. Whether you'd also 
want to discard data is an open question.


a.y

On Mon, 4 Jul 2016, Harms, Michael wrote:



So, what bvec/bvec file should be associated with the BASE scan?  It isn’t
clear to me how the bvec/bval in the BASE scan get used in trac-paths.

I see the point of your note of caution, but unless someone moved the same
amount (and for the same frames) for their sessions in a longitudinal
study, the same issue applies, even if you use all frames “as is”.  In
that case, the potential bias would be due to using data of differing
quality across sessions.  In a sense, we are just making the issue
explicit by discarding bad frames as part of a QC step.

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 7/4/16, 2:41 AM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Anastasia Yendiki"  wrote:


Hi Michael - Indeed it should not be too difficult to add the feature of
specifying the b-value table for each scan and I can add this in the next
version.

However, I would be a bit careful with removing different DWI volumes for
different time points. The acquisition should be as consistent as possible
across time points. If you find that there's a longitudinal change, would
this be because there were different directions/b-values in each time
point or because of an actual change in the brain? I suppose that, unless
there's a systematic bias, you might expect that these changes will be in
different directions for different subjects and would then average out.
But it's a tricky issue.

Best,
a.y

On Fri, 1 Jul 2016, Harms, Michael wrote:



Hi Anastasia,
Looking through the trac-preproc and trac-paths scripts, it is now clear
to me that all the time points for a given subject have to be
contained/specified
within the same dmrirc configuration file in order to implement a
longitudinal TRACULA analysis.  So, I've answered my previous question in
that regard.

The challenge in our case is that we have separately pre-processed the
dMRI data for each subject and time point, removing bad frames/volumes
(using the
DTIPrep QA tool).  Thus, the bvecs/bvals are not identical for all the
time points of a given subject.  We can specify the bvec file for each
subject/time
point using the bveclist configuration parameter.  But there is no
analog available for bvals, since only a single bvalfile can be
specified.

I see that this issue has been raised in a couple other posts relatively
recently (2015):
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41737.html
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg40007.html
but no working solution was provided at that time.

I’m wondering if there is perhaps now a development version of TRACULA
that supports a “bvallist” capability?  If not, it doesn’t look like it
would be too
difficult to modify trac-all  to include that capability (modeling after
what is already in trac-all for the bveclist/bvecfile stuff).  But, in
that case,
it isn’t immediately clear to me if there are other downstream “gotchas”
in the preproc, paths, or stats stage specific scripts/binaries that
would need
modifications as well.  [I don’t see anything in the sections related to
the BASE-specific processing in trac-preproc involving bvals/bvecs, so
think we are
fine there.  But it is harder for me to tell what is going on in
trac-paths].

thanks,
-MH

--
Michael Harms, Ph.D.
---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: mha...@wustl.edu

From:  on behalf of "Harms,
Michael" 
Reply-To: Freesurfer support list 
Date: Wednesday, June 29, 2016 at 5:00 PM
To: Freesurfer support list 
Subject: [Freesurfer] longitudinal tracula


Hi,
When running TRACULA with longitudinal data, is it necessary for all
scan waves of a given subject to be included in a single dmrirc file?  My
initial
thought was “no”, that it would be fine to run one scan wave per subject
per dmrirc file (as long as the “baselist” variable is set appropriately

[Freesurfer] Question

2016-07-04 Thread Dulce Maria Magdaleno Arroyo

Hi,


I am doing a research about the uterus, in this research I am trying to
define the geometry of this organ, so I want to use freesurfer to mapping
the uterus into a sphere; as far as I understand I don't need all the brain
image processing. I have already a FEM model of the uterus in matlab, and I
was wondering if just the command mris_inflate could be used to this task
or if I have to consider some other commands?

Other question I have is, Do I need to convert my matlab data to .mgh to
use the freesurfer commands? If yes, Could you give me some directions to
do this task?


In advance, thank you so much for your help.


Best,

DM
___
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] controlling for total gray matter volume


yup, that is a reasonable approach
Bruce

On Mon, 4 Jul 2016, Harms, Michael 
wrote:




Hi,
Why not use total surface area to control for analyses involving area, and
mean cortical thickness to control for thickness?  I’ve posted to the list
before regarding this, so you should be able to find those posts.

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 7/4/16, 9:12 AM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Clara Kühn"  wrote:

Do you know, if there are any publications concerning this matter? So far
I've found only this
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0148852
that controls for tGM only for area and not CT.

Cheers Clara

- Ursprüngliche Mail -
Von: "Bruce Fischl" 
An: "Freesurfer support list" 
Gesendet: Montag, 4. Juli 2016 15:37:57
Betreff: Re: [Freesurfer] controlling for total gray matter volume

sounds right to me
Bruce
On Mon, 4 Jul 2016, Clara Kühn wrote:


I have decided now to not control for ICV or total gray matter volume
when looking at cortical thickness but to control for total gray matter
volume when looking at surface area. Does that sound about right?

Cheers, Clara

- Ursprüngliche Mail -
Von: "Arkadiy Maksimovskiy" 
An: freesurfer@nmr.mgh.harvard.edu
Gesendet: Samstag, 2. Juli 2016 18:36:51
Betreff: Re: [Freesurfer] controlling for total gray matter volume

Hi Clara,

If I am understanding your question correctly, you don't need to control
for brain volume when looking at thickness analyses.

See quote below from this link:

http://www.freesurfer.net/fswiki/eTIV

"Note that this correction is only useful in situations where the
structure scales with head size. Outside of this, correction just adds
noise, or provides inaccurate data. In the case of the measures from
Freesurfer, one would apply correction to the volume measures and not
thickness measures. This is because volume scales with head size which is
mostly due to changes in surface area, whereas thickness alone scales to
a much less degree."

Best,
Arkadiy

On Sat, Jul 2, 2016 at 12:00 PM, <
freesurfer-requ...@nmr.mgh.harvard.edu > wrote:


Send Freesurfer mailing list submissions to
freesurfer@nmr.mgh.harvard.edu

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
or, via email, send a message with subject or body 'help' to
freesurfer-requ...@nmr.mgh.harvard.edu

You can reach the person managing the list at
freesurfer-ow...@nmr.mgh.harvard.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Freesurfer digest..."


Today's Topics:

1. controlling for total gray matter volume (Clara K?hn)
2. cotrolling for total gray matter volume (Clara K?hn)


--

Message: 1
Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST)
From: Clara K?hn < cku...@cbs.mpg.de >
Subject: [Freesurfer] controlling for total gray matter volume
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
Message-ID:
< 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de >
Content-Type: text/plain; charset=utf-8

Dear FreeSurfer experts,

I would like to look at longitudinal thickness data and want to control
for total gray matter volume. Should I use that information from the
CROSS before anything has been registered and smoothed or from the LONG
after they have been registered to the BASE?
Also I was wondering if it is useful to control for total gray matter
volume when looking at surface area?

Thanks for your help!
Clara


--

Message: 2
Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST)
From: Clara K?hn < cku...@cbs.mpg.de >
Subject: [Freesurfer] cotrolling for total gray matter volume
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
Message-ID:
< 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de >
Content-Type: text/plain; charset=utf-8

Dear FreeSurfer experts,

I would like to look at longitudinal thickness data and want to control
for total gray matter volume. Should I use that information from the
CROSS before anything has been registered and smoothed or from the LONG
after they have been registered to the BASE?
Also I was wondering if it is useful to control for total gray matter
volume when looking at surface area?

Thanks for your help!
Clara



___
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

Re: [Freesurfer] controlling for total gray matter volume

2016-07-04 Thread Harms, Michael


Hi,
Why not use total surface area to control for analyses involving area, and
mean cortical thickness to control for thickness?  I’ve posted to the list
before regarding this, so you should be able to find those posts.

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 7/4/16, 9:12 AM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Clara Kühn"  wrote:

Do you know, if there are any publications concerning this matter? So far
I've found only this
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0148852
that controls for tGM only for area and not CT.

Cheers Clara

- Ursprüngliche Mail -
Von: "Bruce Fischl" 
An: "Freesurfer support list" 
Gesendet: Montag, 4. Juli 2016 15:37:57
Betreff: Re: [Freesurfer] controlling for total gray matter volume

sounds right to me
Bruce
On Mon, 4 Jul 2016, Clara Kühn wrote:

> I have decided now to not control for ICV or total gray matter volume
>when looking at cortical thickness but to control for total gray matter
>volume when looking at surface area. Does that sound about right?
>
> Cheers, Clara
>
> - Ursprüngliche Mail -
> Von: "Arkadiy Maksimovskiy" 
> An: freesurfer@nmr.mgh.harvard.edu
> Gesendet: Samstag, 2. Juli 2016 18:36:51
> Betreff: Re: [Freesurfer] controlling for total gray matter volume
>
> Hi Clara,
>
> If I am understanding your question correctly, you don't need to control
>for brain volume when looking at thickness analyses.
>
> See quote below from this link:
>
> http://www.freesurfer.net/fswiki/eTIV
>
> "Note that this correction is only useful in situations where the
>structure scales with head size. Outside of this, correction just adds
>noise, or provides inaccurate data. In the case of the measures from
>Freesurfer, one would apply correction to the volume measures and not
>thickness measures. This is because volume scales with head size which is
>mostly due to changes in surface area, whereas thickness alone scales to
>a much less degree."
>
> Best,
> Arkadiy
>
> On Sat, Jul 2, 2016 at 12:00 PM, <
>freesurfer-requ...@nmr.mgh.harvard.edu > wrote:
>
>
> Send Freesurfer mailing list submissions to
> freesurfer@nmr.mgh.harvard.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> or, via email, send a message with subject or body 'help' to
> freesurfer-requ...@nmr.mgh.harvard.edu
>
> You can reach the person managing the list at
> freesurfer-ow...@nmr.mgh.harvard.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freesurfer digest..."
>
>
> Today's Topics:
>
> 1. controlling for total gray matter volume (Clara K?hn)
> 2. cotrolling for total gray matter volume (Clara K?hn)
>
>
> --
>
> Message: 1
> Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] controlling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control
>for total gray matter volume. Should I use that information from the
>CROSS before anything has been registered and smoothed or from the LONG
>after they have been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter
>volume when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
> --
>
> Message: 2
> Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] cotrolling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control
>for total gray matter volume. Should I use that information from the
>CROSS before anything has been registered and smoothed or from the LONG
>after they have been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter
>volume when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu

Re: [Freesurfer] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header

Hi Anastasia,

Thank you for getting back to me.
Here are more details about my problem, I think it should help you understand 
more.

I run trac-all -prep -c on some DICOM files but I had the following error :
WARNING: file 
/Users/ismailkoubiyr/Documents/PFE/Tracula/dti/SER_5/MR.1.2.826.0.1.3680043.6.8878.22551.20150806120704.648.1017
 does not contain a Siemens ASCII header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header
I also tried to de-mosiac the DICOMs, it gave me the same error.

Then I converted the DICOMs into NIFTI, which allowed me not to get the 
previous error but something else weird happened. Now I get :
ERROR: fMRIframe: frame >= nframes
I checked the bvecs and bvals files, they seem normal, no additional space, but 
when the new bvecs  and bvals are created, they seem messed up. I will attach 
you all the bvecs and bvals I used and the ones I get too.

Ideally, the DICOMs should work fine but I have no idea why I get these errors.
The bvecs and bvals are obtained from dcm2nii and then corrected to avoid any 
additional space.

Thank you in advance for your help.

Best,

Ismail

P.S : 3T2_bvecs.txt and 3T2_bvals.txt are the original files used.


On Jul 4, 2016, at 3:32 AM, Anastasia Yendiki 
> wrote:


Hi Ismail - Are you passing the nifti volume as input to trac-all? It's
hard to tell without looking at your configuration file.

Best,
a.y

On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:

Hi everyone,

I have some problems trying to run TRACULA on some DWI data. It is a mosaic 
Siemens DWI. I first converted the DICOM files with dcm2nii to get the bvec and 
bval files.
Then I run the trac-all -prep -c command and I get the following error :

WARNING: file /My/path/to/dicom does not contain a Siemens ASCII header
has this file been anonymized?
ERROR: cannot unpack mosiacs without ASCII header

I tried to unpack the mosaics with gdcmtar, but I got the same error.

Thank you in advance for your help,

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



bvals
Description: bvals


bvecs
Description: bvecs


bvecs.norot
Description: bvecs.norot


dwi_orig.mghdti.bvecs
Description: dwi_orig.mghdti.bvecs


dwi_orig.mghdti.bvals
Description: dwi_orig.mghdti.bvals
0
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
0
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
1000
0
00 0 0
-0.203086 0.51882 -0.83041
0.19699 0.519109 -0.831697
0.400451 0.175928 -0.899271
-0.402681 0.730255 -0.551883
-0.201801 0.940841 -0.272204
-0.852534 0.518969 -0.0621066
-0.729693 0.519789 -0.444259
-0.406 0.176399 -0.896687
-0.730687 0.176545 -0.659491
-0.650821 0.731986 0.201565
-0.321998 0.941721 0.0973547
-0.325885 0.523495 0.787243
-0.652464 0.522204 0.549176
-0.979115 0.177805 0.0985869
-0.857087 0.178312 0.48333
0.00074441 0.735199 0.677851
0.00317198 0.943882 0.330266
0.656176 0.522342 0.544602
0.331016 0.523908 0.784824
0.197021 -0.176144 -0.964446
0.20548 0.177881 0.96236
0.651496 0.731864 0.199821
0.324279 0.941458 0.0921958
0.200221 0.939774 -0.277014
0.402681 0.730255 -0.551883
0.730024 0.176561 -0.66022
0.726896 0.519093 -0.449628
0.851743 0.519522 -0.0680449
0.859934 0.178306 0.478247
0.979641 0.177715 0.0933861
0 0 0
-0.203086 0.51882 -0.83041
0.19699 0.519109 -0.831697
0.400451 0.175928 -0.899271
-0.402681 0.730255 -0.551883
-0.201801 0.940841 -0.272204
-0.852534 0.518969 -0.0621066
-0.729693 0.519789 -0.444259
-0.406 0.176399 -0.896687
-0.730687 0.176545 -0.659491
-0.650821 0.731986 0.201565
-0.321998 0.941721 0.0973547
-0.325885 0.523495 0.787243
-0.652464 0.522204 0.549176
-0.979115 0.177805 0.0985869
-0.857087 0.178312 0.48333
0.00074441 0.735199 0.677851
0.00317198 0.943882 0.330266
0.656176 0.522342 0.544602
0.331016 0.523908 0.784824
0.197021 -0.176144 -0.964446
0.20548 0.177881 0.96236
0.651496 0.731864 0.199821
0.324279 0.941458 0.0921958
0.200221 0.939774 -0.277014
0.402681 0.730255 -0.551883
0.730024 0.176561 -0.66022
0.726896 0.519093 -0.449628
0.851743 0.519522 -0.0680449
0.859934 0.178306 0.478247
0.979641 0.177715 0.0933861
0 0 0
0 0 0___
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

[Freesurfer] mapping a surface from fsaverage_sym to the subject's native surface

2016-07-04 Thread Ali-Reza Mohammadi-Nejad

Dear Freesurfer experts,
Based on the FS wiki, I calculated the cortical thickness difference between 
the lh and rh of a subject.Now, I want to use the “mris_apply_reg” command to 
map the “left-right  difference” from fsaverage_sym back to the subject's 
native surface.Unfortunately, I did not find the appropriate options of this 
command to do this work.Thanks for any help. Best regards,Ali-Reza Ali-Reza 
Mohammadi-Nejad
Pre-doctoral research fellow
Radiology and Neurology Research
Henry Ford Health System 
Detroit, MI 48202, USA___
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] controlling for total gray matter volume

2016-07-04 Thread Clara Kühn

Do you know, if there are any publications concerning this matter? So far I've 
found only this 
http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0148852 that 
controls for tGM only for area and not CT.

Cheers Clara

- Ursprüngliche Mail -
Von: "Bruce Fischl" 
An: "Freesurfer support list" 
Gesendet: Montag, 4. Juli 2016 15:37:57
Betreff: Re: [Freesurfer] controlling for total gray matter volume

sounds right to me
Bruce
On Mon, 4 Jul 2016, Clara Kühn wrote:

> I have decided now to not control for ICV or total gray matter volume when 
> looking at cortical thickness but to control for total gray matter volume 
> when looking at surface area. Does that sound about right?
>
> Cheers, Clara
>
> - Ursprüngliche Mail -
> Von: "Arkadiy Maksimovskiy" 
> An: freesurfer@nmr.mgh.harvard.edu
> Gesendet: Samstag, 2. Juli 2016 18:36:51
> Betreff: Re: [Freesurfer] controlling for total gray matter volume
>
> Hi Clara,
>
> If I am understanding your question correctly, you don't need to control for 
> brain volume when looking at thickness analyses.
>
> See quote below from this link:
>
> http://www.freesurfer.net/fswiki/eTIV
>
> "Note that this correction is only useful in situations where the structure 
> scales with head size. Outside of this, correction just adds noise, or 
> provides inaccurate data. In the case of the measures from Freesurfer, one 
> would apply correction to the volume measures and not thickness measures. 
> This is because volume scales with head size which is mostly due to changes 
> in surface area, whereas thickness alone scales to a much less degree."
>
> Best,
> Arkadiy
>
> On Sat, Jul 2, 2016 at 12:00 PM, < freesurfer-requ...@nmr.mgh.harvard.edu > 
> wrote:
>
>
> Send Freesurfer mailing list submissions to
> freesurfer@nmr.mgh.harvard.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> or, via email, send a message with subject or body 'help' to
> freesurfer-requ...@nmr.mgh.harvard.edu
>
> You can reach the person managing the list at
> freesurfer-ow...@nmr.mgh.harvard.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freesurfer digest..."
>
>
> Today's Topics:
>
> 1. controlling for total gray matter volume (Clara K?hn)
> 2. cotrolling for total gray matter volume (Clara K?hn)
>
>
> --
>
> Message: 1
> Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] controlling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control for 
> total gray matter volume. Should I use that information from the CROSS before 
> anything has been registered and smoothed or from the LONG after they have 
> been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter volume 
> when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
> --
>
> Message: 2
> Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] cotrolling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control for 
> total gray matter volume. Should I use that information from the CROSS before 
> anything has been registered and smoothed or from the LONG after they have 
> been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter volume 
> when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
___
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] controlling for total gray matter volume

2016-07-04 Thread Clara Kühn

Ok, thanks!

- Ursprüngliche Mail -
Von: "Bruce Fischl" 
An: "Freesurfer support list" 
Gesendet: Montag, 4. Juli 2016 15:37:57
Betreff: Re: [Freesurfer] controlling for total gray matter volume

sounds right to me
Bruce
On Mon, 4 Jul 2016, Clara Kühn wrote:

> I have decided now to not control for ICV or total gray matter volume when 
> looking at cotrical thickness but to control for total gray matter volume 
> when looking at surface area. Does that sound about right?
>
> Cheers, Clara
>
> - Ursprüngliche Mail -
> Von: "Arkadiy Maksimovskiy" 
> An: freesurfer@nmr.mgh.harvard.edu
> Gesendet: Samstag, 2. Juli 2016 18:36:51
> Betreff: Re: [Freesurfer] controlling for total gray matter volume
>
> Hi Clara,
>
> If I am understanding your question correctly, you don't need to control for 
> brain volume when looking at thickness analyses.
>
> See quote below from this link:
>
> http://www.freesurfer.net/fswiki/eTIV
>
> "Note that this correction is only useful in situations where the structure 
> scales with head size. Outside of this, correction just adds noise, or 
> provides inaccurate data. In the case of the measures from Freesurfer, one 
> would apply correction to the volume measures and not thickness measures. 
> This is because volume scales with head size which is mostly due to changes 
> in surface area, whereas thickness alone scales to a much less degree."
>
> Best,
> Arkadiy
>
> On Sat, Jul 2, 2016 at 12:00 PM, < freesurfer-requ...@nmr.mgh.harvard.edu > 
> wrote:
>
>
> Send Freesurfer mailing list submissions to
> freesurfer@nmr.mgh.harvard.edu
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
> or, via email, send a message with subject or body 'help' to
> freesurfer-requ...@nmr.mgh.harvard.edu
>
> You can reach the person managing the list at
> freesurfer-ow...@nmr.mgh.harvard.edu
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Freesurfer digest..."
>
>
> Today's Topics:
>
> 1. controlling for total gray matter volume (Clara K?hn)
> 2. cotrolling for total gray matter volume (Clara K?hn)
>
>
> --
>
> Message: 1
> Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] controlling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control for 
> total gray matter volume. Should I use that information from the CROSS before 
> anything has been registered and smoothed or from the LONG after they have 
> been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter volume 
> when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
> --
>
> Message: 2
> Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST)
> From: Clara K?hn < cku...@cbs.mpg.de >
> Subject: [Freesurfer] cotrolling for total gray matter volume
> To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
> Message-ID:
> < 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de >
> Content-Type: text/plain; charset=utf-8
>
> Dear FreeSurfer experts,
>
> I would like to look at longitudinal thickness data and want to control for 
> total gray matter volume. Should I use that information from the CROSS before 
> anything has been registered and smoothed or from the LONG after they have 
> been registered to the BASE?
> Also I was wondering if it is useful to control for total gray matter volume 
> when looking at surface area?
>
> Thanks for your help!
> Clara
>
>
___
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] controlling for total gray matter volume


sounds right to me
Bruce
On Mon, 4 Jul 2016, Clara Kühn wrote:


I have decided now to not control for ICV or total gray matter volume when 
looking at cotrical thickness but to control for total gray matter volume when 
looking at surface area. Does that sound about right?

Cheers, Clara

- Ursprüngliche Mail -
Von: "Arkadiy Maksimovskiy" 
An: freesurfer@nmr.mgh.harvard.edu
Gesendet: Samstag, 2. Juli 2016 18:36:51
Betreff: Re: [Freesurfer] controlling for total gray matter volume

Hi Clara,

If I am understanding your question correctly, you don't need to control for 
brain volume when looking at thickness analyses.

See quote below from this link:

http://www.freesurfer.net/fswiki/eTIV

"Note that this correction is only useful in situations where the structure scales 
with head size. Outside of this, correction just adds noise, or provides inaccurate data. 
In the case of the measures from Freesurfer, one would apply correction to the volume 
measures and not thickness measures. This is because volume scales with head size which 
is mostly due to changes in surface area, whereas thickness alone scales to a much less 
degree."

Best,
Arkadiy

On Sat, Jul 2, 2016 at 12:00 PM, < freesurfer-requ...@nmr.mgh.harvard.edu > 
wrote:


Send Freesurfer mailing list submissions to
freesurfer@nmr.mgh.harvard.edu

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
or, via email, send a message with subject or body 'help' to
freesurfer-requ...@nmr.mgh.harvard.edu

You can reach the person managing the list at
freesurfer-ow...@nmr.mgh.harvard.edu

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Freesurfer digest..."


Today's Topics:

1. controlling for total gray matter volume (Clara K?hn)
2. cotrolling for total gray matter volume (Clara K?hn)


--

Message: 1
Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST)
From: Clara K?hn < cku...@cbs.mpg.de >
Subject: [Freesurfer] controlling for total gray matter volume
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
Message-ID:
< 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de >
Content-Type: text/plain; charset=utf-8

Dear FreeSurfer experts,

I would like to look at longitudinal thickness data and want to control for 
total gray matter volume. Should I use that information from the CROSS before 
anything has been registered and smoothed or from the LONG after they have been 
registered to the BASE?
Also I was wondering if it is useful to control for total gray matter volume 
when looking at surface area?

Thanks for your help!
Clara


--

Message: 2
Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST)
From: Clara K?hn < cku...@cbs.mpg.de >
Subject: [Freesurfer] cotrolling for total gray matter volume
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu >
Message-ID:
< 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de >
Content-Type: text/plain; charset=utf-8

Dear FreeSurfer experts,

I would like to look at longitudinal thickness data and want to control for 
total gray matter volume. Should I use that information from the CROSS before 
anything has been registered and smoothed or from the LONG after they have been 
registered to the BASE?
Also I was wondering if it is useful to control for total gray matter volume 
when looking at surface area?

Thanks for your help!
Clara

___
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] Tissue probability maps from aseg.mgz

Hi Lee

that is the correct option, I just haven't gotten around to putting it in 
the help text yet.
Bruce

On Mon, 4 Jul 2016, Lee Subin Kristine wrote:

> 
> Dear FreeSurfers,
> 
> 
> Is it possible to get tissue probability maps (for the purpose of using them
> in spm DARTEL, PVElab, etc) out of aseg.mgz?
> 
> 
> I did read in a previous 
> post(https://mail.nmr.mgh.harvard.edu/pipermail/freesurfer/2007-October/006384.
> html) that you can use mri_ca_label with the option -write_probs, but I
> could not find a -write_probs option.
> 
> 
> If not, I'm wondering is there is any other possible way to get tissue
> probability maps from FreeSurfer?
> 
> 
> Any help would be much appreciated.
> 
> 
> Regards,
> 
> Subin
> 
> 
>
___
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] controlling for total gray matter volume

2016-07-04 Thread Clara Kühn

I have decided now to not control for ICV or total gray matter volume when 
looking at cotrical thickness but to control for total gray matter volume when 
looking at surface area. Does that sound about right?

Cheers, Clara

- Ursprüngliche Mail -
Von: "Arkadiy Maksimovskiy" 
An: freesurfer@nmr.mgh.harvard.edu
Gesendet: Samstag, 2. Juli 2016 18:36:51
Betreff: Re: [Freesurfer] controlling for total gray matter volume

Hi Clara, 

If I am understanding your question correctly, you don't need to control for 
brain volume when looking at thickness analyses. 

See quote below from this link: 

http://www.freesurfer.net/fswiki/eTIV 

"Note that this correction is only useful in situations where the structure 
scales with head size. Outside of this, correction just adds noise, or provides 
inaccurate data. In the case of the measures from Freesurfer, one would apply 
correction to the volume measures and not thickness measures. This is because 
volume scales with head size which is mostly due to changes in surface area, 
whereas thickness alone scales to a much less degree." 

Best, 
Arkadiy 

On Sat, Jul 2, 2016 at 12:00 PM, < freesurfer-requ...@nmr.mgh.harvard.edu > 
wrote: 


Send Freesurfer mailing list submissions to 
freesurfer@nmr.mgh.harvard.edu 

To subscribe or unsubscribe via the World Wide Web, visit 
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 
or, via email, send a message with subject or body 'help' to 
freesurfer-requ...@nmr.mgh.harvard.edu 

You can reach the person managing the list at 
freesurfer-ow...@nmr.mgh.harvard.edu 

When replying, please edit your Subject line so it is more specific 
than "Re: Contents of Freesurfer digest..." 


Today's Topics: 

1. controlling for total gray matter volume (Clara K?hn) 
2. cotrolling for total gray matter volume (Clara K?hn) 


-- 

Message: 1 
Date: Thu, 30 Jun 2016 15:19:43 +0200 (CEST) 
From: Clara K?hn < cku...@cbs.mpg.de > 
Subject: [Freesurfer] controlling for total gray matter volume 
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu > 
Message-ID: 
< 600644700.119350.1467292783757.javamail.zim...@cbs.mpg.de > 
Content-Type: text/plain; charset=utf-8 

Dear FreeSurfer experts, 

I would like to look at longitudinal thickness data and want to control for 
total gray matter volume. Should I use that information from the CROSS before 
anything has been registered and smoothed or from the LONG after they have been 
registered to the BASE? 
Also I was wondering if it is useful to control for total gray matter volume 
when looking at surface area? 

Thanks for your help! 
Clara 


-- 

Message: 2 
Date: Thu, 30 Jun 2016 15:01:06 +0200 (CEST) 
From: Clara K?hn < cku...@cbs.mpg.de > 
Subject: [Freesurfer] cotrolling for total gray matter volume 
To: Freesurfer support list < freesurfer@nmr.mgh.harvard.edu > 
Message-ID: 
< 1473114832.117985.1467291666701.javamail.zim...@cbs.mpg.de > 
Content-Type: text/plain; charset=utf-8 

Dear FreeSurfer experts, 

I would like to look at longitudinal thickness data and want to control for 
total gray matter volume. Should I use that information from the CROSS before 
anything has been registered and smoothed or from the LONG after they have been 
registered to the BASE? 
Also I was wondering if it is useful to control for total gray matter volume 
when looking at surface area? 

Thanks for your help! 
Clara 

-- 
Clara K?hn, Phd Student 

Max-Planck-Institute for Human Cognitive and Brain Science 
Department of Neuropsychology 
Stephanstrasse 1A 
04103 Leipzig, Germany 

Phone: +49 341 - 9940 2271 
Fax: +49 341 - 9940 2260 
Web: www.cbs.mpg.de 
E-Mail: cku...@cbs.mpg.de 



-- 

___ 
Freesurfer mailing list 
Freesurfer@nmr.mgh.harvard.edu 
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer 

End of Freesurfer Digest, Vol 149, Issue 6 
** 


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

Re: [Freesurfer] longitudinal tracula

2016-07-04 Thread Harms, Michael


So, what bvec/bvec file should be associated with the BASE scan?  It isn’t
clear to me how the bvec/bval in the BASE scan get used in trac-paths.

I see the point of your note of caution, but unless someone moved the same
amount (and for the same frames) for their sessions in a longitudinal
study, the same issue applies, even if you use all frames “as is”.  In
that case, the potential bias would be due to using data of differing
quality across sessions.  In a sense, we are just making the issue
explicit by discarding bad frames as part of a QC step.

cheers,
-MH

--
Michael Harms, Ph.D.

---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave.Tel: 314-747-6173
St. Louis, MO  63110Email: mha...@wustl.edu




On 7/4/16, 2:41 AM, "freesurfer-boun...@nmr.mgh.harvard.edu on behalf of
Anastasia Yendiki"  wrote:


Hi Michael - Indeed it should not be too difficult to add the feature of
specifying the b-value table for each scan and I can add this in the next
version.

However, I would be a bit careful with removing different DWI volumes for
different time points. The acquisition should be as consistent as possible
across time points. If you find that there's a longitudinal change, would
this be because there were different directions/b-values in each time
point or because of an actual change in the brain? I suppose that, unless
there's a systematic bias, you might expect that these changes will be in
different directions for different subjects and would then average out.
But it's a tricky issue.

Best,
a.y

On Fri, 1 Jul 2016, Harms, Michael wrote:

>
> Hi Anastasia,
> Looking through the trac-preproc and trac-paths scripts, it is now clear
>to me that all the time points for a given subject have to be
>contained/specified
> within the same dmrirc configuration file in order to implement a
>longitudinal TRACULA analysis.  So, I've answered my previous question in
>that regard.
>
> The challenge in our case is that we have separately pre-processed the
>dMRI data for each subject and time point, removing bad frames/volumes
>(using the
> DTIPrep QA tool).  Thus, the bvecs/bvals are not identical for all the
>time points of a given subject.  We can specify the bvec file for each
>subject/time
> point using the bveclist configuration parameter.  But there is no
>analog available for bvals, since only a single bvalfile can be
>specified.
>
> I see that this issue has been raised in a couple other posts relatively
>recently (2015):
> https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41737.html
> https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg40007.html
> but no working solution was provided at that time.
>
> I’m wondering if there is perhaps now a development version of TRACULA
>that supports a “bvallist” capability?  If not, it doesn’t look like it
>would be too
> difficult to modify trac-all  to include that capability (modeling after
>what is already in trac-all for the bveclist/bvecfile stuff).  But, in
>that case,
> it isn’t immediately clear to me if there are other downstream “gotchas”
>in the preproc, paths, or stats stage specific scripts/binaries that
>would need
> modifications as well.  [I don’t see anything in the sections related to
>the BASE-specific processing in trac-preproc involving bvals/bvecs, so
>think we are
> fine there.  But it is harder for me to tell what is going on in
>trac-paths].
>
> thanks,
> -MH
>
> --
> Michael Harms, Ph.D.
> ---
> Conte Center for the Neuroscience of Mental Disorders
> Washington University School of Medicine
> Department of Psychiatry, Box 8134
> 660 South Euclid Ave. Tel: 314-747-6173
> St. Louis, MO  63110 Email: mha...@wustl.edu
>
> From:  on behalf of "Harms,
>Michael" 
> Reply-To: Freesurfer support list 
> Date: Wednesday, June 29, 2016 at 5:00 PM
> To: Freesurfer support list 
> Subject: [Freesurfer] longitudinal tracula
>
>
> Hi,
> When running TRACULA with longitudinal data, is it necessary for all
>scan waves of a given subject to be included in a single dmrirc file?  My
>initial
> thought was “no”, that it would be fine to run one scan wave per subject
>per dmrirc file (as long as the “baselist” variable is set appropriately
>for each
> scan wave and subject).
>
> But looking at the ‘trac-all’ script, I see
>
> if ($#baselist == 0) then#--->>> A single time point for each subject
> …
> else#--->>> Multiple time points for each subject
> …
>
> So, I’m wondering why different sections in the code would be necessary
>if in fact it is ok to process a single scan wave per dmrirc file.
>
> thanks,
> -MH
>
> --
> Michael

Re: [Freesurfer] Failure to use yeo-7/17 networks maps as templates in MRIcron

2016-07-04 Thread Thomas Yeo

Hi Hsiang-Yuan,

That's because the header information is different. You can do the following:

>> mri_vol2vol --mov Yeo2011Parcellation.nii.gz --targ 
>> FSL_MNI2mm_template.nii.gz --regheader --nearest --o Yeo2011_FSL2mm.nii.gz

The output file "Yeo2011_FSL2mm.nii.gz" should have an orientation
compatible with mricron. Can you let me know if this works.

Thanks,
Thomas

On Mon, Jul 4, 2016 at 12:58 AM, Hsiang-Yuan Lin  wrote:
> Hi Prof. Yeo,
>
> I have problems utilizing yeo 7/17 cortical network parcellation maps as
> templates in MRIcron (I aim to use your cortical parcellation maps to
> underlay my findings in order to derive the implications based on iFC
> networks). To be specific, there is an orientation problem in the current
> version of parcellation maps in MNI space.
>
> Thank you for your help in advance.
>
> Best,
> Hsiang-Yuan
>
> --
> Hsiang-Yuan Lin, M.D.
> Attending Psychiatrist & Adjunct Lecturer
> Department of Psychiatry & Child Mental Health Center
> National Taiwan University Hospital and College of Medicine
> email: louisli...@gmail.com
> CV:
> https://drive.google.com/file/d/0B3jQGSXih2aeY2o1QnJwUVJjU1U/view?usp=sharing
> https://www.researchgate.net/profile/Hsiang_Yuan_Lin2
>
>
>
> --
> Hsiang-Yuan Lin, M.D.
> Attending Psychiatrist & Adjunct Lecturer
> Department of Psychiatry & Child Mental Health Center
> National Taiwan University Hospital and College of Medicine
> email: louisli...@gmail.com
> CV:
> https://drive.google.com/file/d/0B3jQGSXih2aeY2o1QnJwUVJjU1U/view?usp=sharing
> https://www.researchgate.net/profile/Hsiang_Yuan_Lin2
___
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] trac-all error (bvecs and bvals don't have same number of entries)



Hi Lars - At first glance, these files look fine to me. Do the dmri/bvals 
and dmri/bvecs files that get generated look fine too?


a.y

On Sat, 2 Jul 2016, Lars M. Rimol wrote:


Hi,

Trying to run trac-all -c dmric_file -prep,  I get an error message stating 
that there are different numbers of entries in the bval and bvec files. I don't
understand why, since both have the same number of rows (64).

OS = Ubuntu 14.04.4
Software: freesurfer-Linux-centos6_x86_64-stable-pub-v5.3.0; I have updated 
Tracula and FSL (v 5.0.9).


Error message:

#@# Tensor fit fr. 01. juli 19:20:29 +0200 2016
dtifit -k /media/lmr2/subjects/DTI/tracula_2016/4_FS/dmri/dwi.nii.gz -m 
/media/lmr2/subjects/DTI/tracula_2016/4_FS/dlabel/diff/aparc+aseg_mask.bbr.nii.gz
 -r
/media/lmr2/subjects/DTI/tracula_2016/4_FS/dmri/bvecs -b 
/media/lmr2/subjects/DTI/tracula_2016/4_FS/dmri/bvals -o
/media/lmr2/subjects/DTI/tracula_2016/4_FS/dmri/dtifit
Error: bvecs and bvals don't have the same number of entries
Linux dmed4870 3.19.0-31-generic #36~14.04.1-Ubuntu SMP Thu Oct 8 10:21:08 UTC 
2015 x86_64 x86_64 x86_64 GNU/Linux

trac-preproc exited with ERRORS at fr. 01. juli 19:20:30 +0200 2016

--
I also tried flipping the bvec/bval files, but got the same error.
I don't know if there's anything wrong with the bval/bvec files, or if this 
error message is indicative of some other problem. Is the updated Tracula
version only compatible with the dev version of FS?

I have attached the bval/bvec files and the trac-all.log.

---
The contents of the dmric file is:

setenv SUBJECTS_DIR  /media/lmr2/subjects/DTI
set dtroot =  /media/lmr2/subjects/DTI/tracula_2016_nativerows
set subjlist = (4_FS)
set dcmroot =  /media/lmr2/subjects/DTI
set dcmlist =   ( 4/5/1.dcm )
set bvalfile = /media/lmr2/subjects/DTI/bvals_rows.csv
set bvecfile = /media/lmr2/subjects/DTI/bvec_rows.csv



Thank you!


yours,

Lars M. Rimol, PhD
Senior researcher,
Norwegian Advisory Unit for functional MRI
Department of Radiology,
St. Olav's University hospital,
7006 Trondheim,
Norway




___
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] TRACULA group stats visualization



Hi Derek - Are you by any chance using the dev version of freeview?

a.y

On Fri, 1 Jul 2016, Derek Pisner wrote:


Dear Anastasia,
I am running into an issue with the trac-all -stat option on our longitudinal 
TRACULA data. 

Everything runs smoothly through all earlier stages, and I checked individual 
subjects' merged outputs in freeview with -tv mode. Everything looks fine.

Also, then when I run trac-all -c dmric_config -stat, everything finishes 
without error.
 
But then when I open the results with the command:
freeview -v $FSLDIR/data/standard/MNI152_T1_1mm_brain.nii.gz -w 
/data/blt/TRACULA/tractography_output/stats.long/*.path.mean.txt

I get the image seen in the attached .png file. Any idea what might be causing 
this?

Many thanks in advance for you help.

Best,
Derek



___
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] longitudinal tracula



Hi Michael - Indeed it should not be too difficult to add the feature of 
specifying the b-value table for each scan and I can add this in the next 
version.


However, I would be a bit careful with removing different DWI volumes for 
different time points. The acquisition should be as consistent as possible 
across time points. If you find that there's a longitudinal change, would 
this be because there were different directions/b-values in each time 
point or because of an actual change in the brain? I suppose that, unless 
there's a systematic bias, you might expect that these changes will be in 
different directions for different subjects and would then average out. 
But it's a tricky issue.


Best,
a.y

On Fri, 1 Jul 2016, Harms, Michael wrote:



Hi Anastasia,
Looking through the trac-preproc and trac-paths scripts, it is now clear to me 
that all the time points for a given subject have to be contained/specified
within the same dmrirc configuration file in order to implement a longitudinal 
TRACULA analysis.  So, I've answered my previous question in that regard.

The challenge in our case is that we have separately pre-processed the dMRI 
data for each subject and time point, removing bad frames/volumes (using the
DTIPrep QA tool).  Thus, the bvecs/bvals are not identical for all the time 
points of a given subject.  We can specify the bvec file for each subject/time
point using the bveclist configuration parameter.  But there is no analog 
available for bvals, since only a single bvalfile can be specified.  

I see that this issue has been raised in a couple other posts relatively 
recently (2015):
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg41737.html
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg40007.html
but no working solution was provided at that time.

I’m wondering if there is perhaps now a development version of TRACULA that 
supports a “bvallist” capability?  If not, it doesn’t look like it would be too
difficult to modify trac-all  to include that capability (modeling after what 
is already in trac-all for the bveclist/bvecfile stuff).  But, in that case,
it isn’t immediately clear to me if there are other downstream “gotchas” in the 
preproc, paths, or stats stage specific scripts/binaries that would need
modifications as well.  [I don’t see anything in the sections related to the 
BASE-specific processing in trac-preproc involving bvals/bvecs, so think we are
fine there.  But it is harder for me to tell what is going on in trac-paths].

thanks,
-MH

-- 
Michael Harms, Ph.D.
---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: mha...@wustl.edu

From:  on behalf of "Harms, Michael" 

Reply-To: Freesurfer support list 
Date: Wednesday, June 29, 2016 at 5:00 PM
To: Freesurfer support list 
Subject: [Freesurfer] longitudinal tracula


Hi,
When running TRACULA with longitudinal data, is it necessary for all scan waves 
of a given subject to be included in a single dmrirc file?  My initial
thought was “no”, that it would be fine to run one scan wave per subject per 
dmrirc file (as long as the “baselist” variable is set appropriately for each
scan wave and subject).

But looking at the ‘trac-all’ script, I see

if ($#baselist == 0) then#--->>> A single time point for each subject
…
else#--->>> Multiple time points for each subject
…

So, I’m wondering why different sections in the code would be necessary if in 
fact it is ok to process a single scan wave per dmrirc file.

thanks,
-MH

-- 
Michael Harms, Ph.D.
---
Conte Center for the Neuroscience of Mental Disorders
Washington University School of Medicine
Department of Psychiatry, Box 8134
660 South Euclid Ave. Tel: 314-747-6173
St. Louis, MO  63110 Email: mha...@wustl.edu

 





The materials in this message are private and may contain Protected Healthcare 
Information or other information of a sensitive nature. If you are not the
intended recipient, be advised that any unauthorized use, disclosure, copying 
or the taking of any action in reliance on the contents of this information is
strictly prohibited. If you have received this email in error, please 
immediately notify the sender via telephone or return mail.

 





The materials in this message are private and may contain Protected Healthcare 
Information or

Re: [Freesurfer] [TRACULA] ERROR: cannot unpack mosiacs without ASCII header

Hi Ismail - Are you passing the nifti volume as input to trac-all? It's 
hard to tell without looking at your configuration file.

Best,
a.y

On Tue, 28 Jun 2016, Koubiyr, Ismail wrote:

> Hi everyone,
>
> I have some problems trying to run TRACULA on some DWI data. It is a mosaic 
> Siemens DWI. I first converted the DICOM files with dcm2nii to get the bvec 
> and bval files.
> Then I run the trac-all -prep -c command and I get the following error :
>
> WARNING: file /My/path/to/dicom does not contain a Siemens ASCII header
> has this file been anonymized?
> ERROR: cannot unpack mosiacs without ASCII header
>
> I tried to unpack the mosaics with gdcmtar, but I got the same error.
>
> Thank you in advance for your help,
>
> Ismail
> ___
> 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] tracula not work



Hi Yang - Have you followed the instructions on how to set up the 
freesurfer environment?


https://surfer.nmr.mgh.harvard.edu/fswiki/DownloadAndInstall#Setup.26Configuration

Best,
a.y

On Mon, 13 Jun 2016, yangfuxing wrote:


Hi professor??   When I finished setting up the configuration file "dmrirc", type 
"trac-all -c dmrirc"in the terminal ,it return "FSLDIR: Undefined
variable", how can I solve it?Thank you.
Best,
yang

___
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] Fwd: TRACULA stat extraction issue