[Freesurfer] Possible bug: recon-all -i $T1 -T2 $T2 -autorecon1 attempts to run -T2pial

2023-07-24 Thread Christopher Markiewicz 
External Email - Use Caution

Hi all,

This is a reproduction of GitHub issue 1010. There is a section of recon-all 
(L5927-5930 in current dev) that states:

  # MOD: turn on T2/FLAIR pial editing when FLAIR specified
  # This can backfire, eg, if not all the preceeding steps
  # are included
  set DoT2pial = 1;

This seems an intentional decision to make -T2 activate -T2pial (and similar 
for -FLAIR), which I suppose is a response to people running `recon-all -i $T1 
-T2 $T2 -all` without `-T2pial`. However, it also activates with -autorecon1 
and -autorecon2, which will not run -pial before -T2pial. Would you all 
consider this a bug or a caveat emptor kind of situation?

Would it make sense to add the following to -autorecon1 and -autorecon2 
(hopefully this formats okay)?

diff --git a/scripts/recon-all b/scripts/recon-all
index 4b98118264..0655097ab9 100755
--- a/scripts/recon-all
+++ b/scripts/recon-all
@@ -6869,6 +6869,7 @@ while( $#argv != 0 )
   breaksw
 
 case "-autorecon1":
+  set DoT2pial = 0;
   set DoCreateBaseInput = 1;
   set DoMotionCor  = 1;
   set DoTalairach  = 1;
@@ -6911,6 +6912,7 @@ while( $#argv != 0 )
   set DoRemoveNeck = 0;
   set DoSkullLTA   = 0;
   set DoSegStats   = 0;
+  set DoT2pial = 0;
   set DoCANormalize= 1;
   set DoGCAReg = 1;
   set DoCALabel= 1;

In any case, I am now adding -noT2pial and -noFLAIRpial to -T2 calls that 
aren't -all as well, which seems safe for writing commands that will work for 
both FreeSurfer 6 and 7.

Thanks,
Chris

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail.

Re: [Freesurfer] -gcareg dropped from -autorecon2-volonly

2023-04-04 Thread Christopher Markiewicz 
External Email - Use Caution

Hi Doug,

Sorry for the delay. CAReg shows up, but not GCAReg:

$ grep -A6 "case .-autorecon2-volonly" $FREESURFER_HOME/bin/recon-all
case "-autorecon2-volonly":
  set DoRemoveNeck = 0;
  set DoSkullLTA   = 0;
  set DoSegStats   = 0;
  set DoCANormalize= 1;
  set DoCAReg  = 1;
  set DoCALabel= 1;

Best,
Chris


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Douglas N. Greve 

Sent: Thursday, March 30, 2023 09:29
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] -gcareg dropped from -autorecon2-volonly

In my version, it appears just after DoCANormalize. Can you have grep
print out one more line?

On 3/28/2023 9:05 AM, Christopher Markiewicz wrote:
>  External Email - Use Caution
>
> Hi Doug,
>
> $ cat $FREESURFER_HOME/build-stamp.txt
> freesurfer-linux-ubuntu22_x86_64-7.3.2-20220804-6354275
> $ grep -A4 "case .-autorecon2-volonly" $FREESURFER_HOME/bin/recon-all
>  case "-autorecon2-volonly":
>set DoRemoveNeck = 0;
>set DoSkullLTA   = 0;
>set DoSegStats   = 0;
>set DoCANormalize= 1;
>
> I'm also not seeing it in `dev` on GitHub: 
> https://secure-web.cisco.com/19BPC0I5kosNy_-RSRAWv0WGSAh5adNjGaAo84dO6_vclc0xTDdaWDhzjw4v7ppIcDpDNswchLRbpmE36ysQBkiSWjw92p1HKyrkhU-0zbtFv4PraKshl7lT1z-a16c9dB0tN4yZo_820XxuOeTrje-GYr8LsSd--qY_M5HRd1G6fSraiGRRAops64STReDvpoi0BXA-zlhMdnAhELxhrvob5NlWaNnWqeDe6wSEbT-hxMaP2uo-Bt_piurh13j7769MK9sNR0k-7Y9JyehZM_3gicUwLa4OuBnJ0Y_Ciig6EqP4woHYnsEIVljYRyK8kXmAy_9umFAvwvA9MpVIJmg/https%3A%2F%2Fgithub.com%2Ffreesurfer%2Ffreesurfer%2Fblob%2Fdev%2Fscripts%2Frecon-all%23L7020-L7031
>
> Best,
> Chris
>
> 
> From: freesurfer-boun...@nmr.mgh.harvard.edu 
>  on behalf of Douglas N. Greve 
> 
> Sent: Monday, March 27, 2023 11:16
> To: freesurfer@nmr.mgh.harvard.edu
> Subject: Re: [Freesurfer] -gcareg dropped from -autorecon2-volonly
>
> In 7.2 it appears to be there (and in 7.3 and in dev and in 7.0 and 7.1)
>
>   case "-autorecon2-volonly":
> set DoGCAReg = 1;
> set DoRemoveNeck = 0;
> set DoSkullLTA   = 0;
> set DoCANormalize= 1;
> set DoCAReg  = 1;
> set DoCALabel= 1;
> set DoSegStats   = 0;
> set DoNormalization2 = 1;
> set DoMaskBFS= 1;
> set DoSegmentation   = 1;
> set DoFill   = 1;
> breaksw
>
>
> On 3/24/2023 9:57 AM, Christopher Markiewicz wrote:
>>   External Email - Use Caution
>>
>> Hi all,
>>
>> This is a duplicate of a bug report on GitHub 
>> (https://secure-web.cisco.com/1C5EnDIMtZh6wk0SJMqe8l166ycKmSdnL5atT3CIHDPAY15Ixtf93Rif0FmPFCZaftXbqlhK5AbXT22OXXCJq9JgIiSOyglr8IF1n3lOAzrtCIHcr8C2aLwqsXcMciJwp9Mz2DV4vmcWjm2v_xTUmw6hoea4u37a4hkUyIkSRKIBbOEC9mKcGdJ41Nbz86rmDYbEm3v5pV6zuR3zISglz0_aPe4hJhmj_y7BHipJWdwr3J3pwKPc5BT5WbnmtOEJ6hBkSswM8xHN-3ZfID-bPa2VEltISdFH8ITDhpQJKlPlhEYwtkSxcoWugX9kNCGiWbWsbTqR4PbpJPvp4qp4e5w/https%3A%2F%2Fgithub.com%2Ffreesurfer%2Ffreesurfer%2Fissues%2F1081):
>>
>> `DoGCAReg` was removed from `-autorecon2-volonly` in commit 
>> 4b9af5fc8c559e944400b885ef89f3682f94e0da, but this seems unrelated to the 
>> commit message. It's still in `-autorecon2`. Is there a reason it shouldn't 
>> be present, or was this a mistake?
>>
>> This issue affects versions 7.3.0+. Apologies for doubling up if you saw it; 
>> my impression is the mailing list is more actively monitored.
>>
>> Best,
>> Chris
>>
>> ___
>> Freesurfer mailing list
>> Freesurfer@nmr.mgh.harvard.edu
>> https://secure-web.cisco.com/1iz623RDpG7jX-8vTchfFOWMqWMqqANGChsGlp8WXSurTf7Cz8elbzrjKirHbvATP_qaqv_KoLTkXONA83ZcZSCEC3AC8F9tXylylG1U5rojlEiuJ2cquf910LkQmkwZO91NGSzZIT6ZdjjGVoyppmiAWQWVX2LzZH5_DZevRY6KpGwQQAGftGMcIA5ZvdtpRJMrG41XL6ZS6tTW6O9o21zA0DFo_U4_EPRZqXvowfGGMDYtO79ZAM8zStmKz3FgYaf5r-_KiiGtKSLm_AIznuNafWcT-3lDXNYu13CyoeypNUqVGOpbbpCaMkAkBkoXlNvhwV9Oo1v9AosVjUEtXQw/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://secure-web.cisco.com/1iz623RDpG7jX-8vTchfFOWMqWMqqANGChsGlp8WXSurTf7Cz8elbzrjKirHbvATP_qaqv_KoLTkXONA83ZcZSCEC3AC8F9tXylylG1U5rojlEiuJ2cquf910LkQmkwZO91NGSzZIT6ZdjjGVoyppmiAWQWVX2LzZH5_DZevRY6KpGwQQAGftGMcIA5ZvdtpRJMrG41XL6ZS6tTW6O9o21zA0DFo_U4_EPRZqXvowfGGMDYtO79ZAM8zStmKz3FgYaf5r-_KiiGtKSLm_AIznuNafWcT-3lDXNYu13CyoeypNUqVGOpbbpCaMkAkBkoXlNvhwV9Oo1v9AosVjUEtXQw/

Re: [Freesurfer] -gcareg dropped from -autorecon2-volonly

2023-03-28 Thread Christopher Markiewicz 
External Email - Use Caution

Hi Doug,

$ cat $FREESURFER_HOME/build-stamp.txt
freesurfer-linux-ubuntu22_x86_64-7.3.2-20220804-6354275
$ grep -A4 "case .-autorecon2-volonly" $FREESURFER_HOME/bin/recon-all
case "-autorecon2-volonly":
  set DoRemoveNeck = 0;
  set DoSkullLTA   = 0;
  set DoSegStats   = 0;
  set DoCANormalize= 1;

I'm also not seeing it in `dev` on GitHub: 
https://secure-web.cisco.com/19BPC0I5kosNy_-RSRAWv0WGSAh5adNjGaAo84dO6_vclc0xTDdaWDhzjw4v7ppIcDpDNswchLRbpmE36ysQBkiSWjw92p1HKyrkhU-0zbtFv4PraKshl7lT1z-a16c9dB0tN4yZo_820XxuOeTrje-GYr8LsSd--qY_M5HRd1G6fSraiGRRAops64STReDvpoi0BXA-zlhMdnAhELxhrvob5NlWaNnWqeDe6wSEbT-hxMaP2uo-Bt_piurh13j7769MK9sNR0k-7Y9JyehZM_3gicUwLa4OuBnJ0Y_Ciig6EqP4woHYnsEIVljYRyK8kXmAy_9umFAvwvA9MpVIJmg/https%3A%2F%2Fgithub.com%2Ffreesurfer%2Ffreesurfer%2Fblob%2Fdev%2Fscripts%2Frecon-all%23L7020-L7031

Best,
Chris


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Douglas N. Greve 

Sent: Monday, March 27, 2023 11:16
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] -gcareg dropped from -autorecon2-volonly

In 7.2 it appears to be there (and in 7.3 and in dev and in 7.0 and 7.1)

 case "-autorecon2-volonly":
   set DoGCAReg = 1;
   set DoRemoveNeck = 0;
   set DoSkullLTA   = 0;
   set DoCANormalize= 1;
   set DoCAReg  = 1;
   set DoCALabel= 1;
   set DoSegStats   = 0;
   set DoNormalization2 = 1;
   set DoMaskBFS= 1;
   set DoSegmentation   = 1;
   set DoFill   = 1;
   breaksw


On 3/24/2023 9:57 AM, Christopher Markiewicz wrote:
>  External Email - Use Caution
>
> Hi all,
>
> This is a duplicate of a bug report on GitHub 
> (https://secure-web.cisco.com/1C5EnDIMtZh6wk0SJMqe8l166ycKmSdnL5atT3CIHDPAY15Ixtf93Rif0FmPFCZaftXbqlhK5AbXT22OXXCJq9JgIiSOyglr8IF1n3lOAzrtCIHcr8C2aLwqsXcMciJwp9Mz2DV4vmcWjm2v_xTUmw6hoea4u37a4hkUyIkSRKIBbOEC9mKcGdJ41Nbz86rmDYbEm3v5pV6zuR3zISglz0_aPe4hJhmj_y7BHipJWdwr3J3pwKPc5BT5WbnmtOEJ6hBkSswM8xHN-3ZfID-bPa2VEltISdFH8ITDhpQJKlPlhEYwtkSxcoWugX9kNCGiWbWsbTqR4PbpJPvp4qp4e5w/https%3A%2F%2Fgithub.com%2Ffreesurfer%2Ffreesurfer%2Fissues%2F1081):
>
> `DoGCAReg` was removed from `-autorecon2-volonly` in commit 
> 4b9af5fc8c559e944400b885ef89f3682f94e0da, but this seems unrelated to the 
> commit message. It's still in `-autorecon2`. Is there a reason it shouldn't 
> be present, or was this a mistake?
>
> This issue affects versions 7.3.0+. Apologies for doubling up if you saw it; 
> my impression is the mailing list is more actively monitored.
>
> Best,
> Chris
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://secure-web.cisco.com/1iz623RDpG7jX-8vTchfFOWMqWMqqANGChsGlp8WXSurTf7Cz8elbzrjKirHbvATP_qaqv_KoLTkXONA83ZcZSCEC3AC8F9tXylylG1U5rojlEiuJ2cquf910LkQmkwZO91NGSzZIT6ZdjjGVoyppmiAWQWVX2LzZH5_DZevRY6KpGwQQAGftGMcIA5ZvdtpRJMrG41XL6ZS6tTW6O9o21zA0DFo_U4_EPRZqXvowfGGMDYtO79ZAM8zStmKz3FgYaf5r-_KiiGtKSLm_AIznuNafWcT-3lDXNYu13CyoeypNUqVGOpbbpCaMkAkBkoXlNvhwV9Oo1v9AosVjUEtXQw/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer

___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://secure-web.cisco.com/1iz623RDpG7jX-8vTchfFOWMqWMqqANGChsGlp8WXSurTf7Cz8elbzrjKirHbvATP_qaqv_KoLTkXONA83ZcZSCEC3AC8F9tXylylG1U5rojlEiuJ2cquf910LkQmkwZO91NGSzZIT6ZdjjGVoyppmiAWQWVX2LzZH5_DZevRY6KpGwQQAGftGMcIA5ZvdtpRJMrG41XL6ZS6tTW6O9o21zA0DFo_U4_EPRZqXvowfGGMDYtO79ZAM8zStmKz3FgYaf5r-_KiiGtKSLm_AIznuNafWcT-3lDXNYu13CyoeypNUqVGOpbbpCaMkAkBkoXlNvhwV9Oo1v9AosVjUEtXQw/https%3A%2F%2Fmail.nmr.mgh.harvard.edu%2Fmailman%2Flistinfo%2Ffreesurfer
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 Mass General Brigham 
Compliance HelpLine at 
https://secure-web.cisco.com/1POG2n7wGXIhbgOgyia5pGK1aSOOR0Gvvs206k_qbLIkthjbMEc9Ak5oKsL4Sj8tH7yoFh-mc0mINYXgnjqmZmEOvvm3P_qzIXKmrVxwvyqVzv6jb031xmi3u2N3CyxTIAnXokiGQrPruVoWh6odUESTBtsKOnq-GM_iBO52eP6xLbCXs7dvSgKGmpGscwQJdjD2-xoT6RK4MuH7T0T1cV8RqsK7SuiEb7UPe6uNf5yCQFF6Mhwdx_SYl6XM8PRANtHPJcLsJDvBZqvvrB_7k_6j_3j5X1uXrYnR1nOUxgeGZ6nN8ocj2CtVx45LtpGdn5WQ7k0M-RXzxI0eV3ZLwvQ/https%3A%2F%2Fwww.massgeneralbrigham.org%2Fcomplianceline
 
<https://secure-web.cisco.com/1POG2n7wGXIhbgOgyia5pGK1aSOOR0Gvvs206k_qbLIkthjbMEc9Ak5oKsL4Sj8tH7yoFh-mc0mINYXgnjqmZmEOvvm3P_qzIXKmrVxwvyqVzv6jb031xmi3u2N3CyxTIAnXokiGQrPruVoWh6odUESTBtsKOnq-GM_iBO52eP6xLbCXs7dvSgKGmpGscwQJdjD2-xoT6RK4MuH7T0T1cV8RqsK7SuiEb7UPe6uNf5yCQFF6Mhwdx_SYl6XM8PRANtHPJcLsJDvBZqvvrB_7k_6j_3j5X1uX
 
rYnR1nOUxgeGZ6nN8ocj2CtVx45LtpGdn5WQ7k0M-RXzxI0eV3ZLwvQ/https%3A%2F%2Fwww.massgeneralbrigham.o

[Freesurfer] -gcareg dropped from -autorecon2-volonly

2023-03-24 Thread Christopher Markiewicz 
External Email - Use Caution

Hi all,

This is a duplicate of a bug report on GitHub 
(https://secure-web.cisco.com/1C5EnDIMtZh6wk0SJMqe8l166ycKmSdnL5atT3CIHDPAY15Ixtf93Rif0FmPFCZaftXbqlhK5AbXT22OXXCJq9JgIiSOyglr8IF1n3lOAzrtCIHcr8C2aLwqsXcMciJwp9Mz2DV4vmcWjm2v_xTUmw6hoea4u37a4hkUyIkSRKIBbOEC9mKcGdJ41Nbz86rmDYbEm3v5pV6zuR3zISglz0_aPe4hJhmj_y7BHipJWdwr3J3pwKPc5BT5WbnmtOEJ6hBkSswM8xHN-3ZfID-bPa2VEltISdFH8ITDhpQJKlPlhEYwtkSxcoWugX9kNCGiWbWsbTqR4PbpJPvp4qp4e5w/https%3A%2F%2Fgithub.com%2Ffreesurfer%2Ffreesurfer%2Fissues%2F1081):

`DoGCAReg` was removed from `-autorecon2-volonly` in commit 
4b9af5fc8c559e944400b885ef89f3682f94e0da, but this seems unrelated to the 
commit message. It's still in `-autorecon2`. Is there a reason it shouldn't be 
present, or was this a mistake?

This issue affects versions 7.3.0+. Apologies for doubling up if you saw it; my 
impression is the mailing list is more actively monitored.

Best,
Chris

___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
 .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail.

[Freesurfer] Data formats review - Surface and surface-sampled data

2022-04-18 Thread Christopher Markiewicz 
External Email - Use Caution

Hi all,

This Friday, April 22, we at Nipy will be hosting a journal club on surface and 
surface-sampled data formats. We are focused on current interchange formats and 
possible future directions, which seems like it might be of interest to the 
FreeSurfer community.

The presenters will include Tim Coalson (GIFTI and CIFTI-2), Eric Larson (MNE 
STC) and Qianqian Fang (JData and BMesh).

The time will be 1pm EDT on Friday, Apr 22. Here's an 
AreWeMeetingYet
 link that will resolve in your time zone. I've also posted the event to the 
Nipy meetings 
calendar,
 where we will also post future meetings of this sort. Both include a Zoom link 
for the call.

For further discussion, we have a discourse: 
https://secure-web.cisco.com/1zfKDCpus1rwQRLZbhGF2mjBZQNW0AJ6rTWAwMjov1a7V9SlbXN9wscRCXGIH_b3c5WV_VBj6LFoe2oNnrwOf4SYpnFBEX9W53Nqmh__ryLU9LkJ3eA02cDW8m5lUEEKNoFssrcarKgwLX1C0CdpGMk6JcgZRvERcRlDGVjN3ikgIDyPUwokoq5pghE7qfCrdJTLAEJ1Q2WTABawEPqiVve3Tl0Tgs3k2t09NIuty2bDo7DFZP4ErkSw2lQEVY9dCkWo0SnXwJ3Ayln6DXRVYyl8BChR6T3Jaqle5rSDFJ5C2RwcgCaeDsQAgfbXzPKtjHkTBDqeLTqyBnAG7sKqxuQ/https%3A%2F%2Fnipy.discourse.group%2Ft%2Fdata-formats-review-surface-and-surface-sampled-data%2F123%2F11

Best,
--

Christopher J. Markiewicz, PhD

Center for Reproducible Neuroscience

Stanford University
___
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 Mass General Brigham 
Compliance HelpLine at https://www.massgeneralbrigham.org/complianceline 
 .
Please note that this e-mail is not secure (encrypted).  If you do not wish to 
continue communication over unencrypted e-mail, please notify the sender of 
this message immediately.  Continuing to send or respond to e-mail after 
receiving this message means you understand and accept this risk and wish to 
continue to communicate over unencrypted e-mail.

[Freesurfer] Python Surface API discussion

2021-09-03 Thread Christopher Markiewicz 
External Email - Use Caution

Hi FreeSurfers,

I wanted to reach out to this group about plans to create a new Python API for 
working with surface data in Nibabel. As you are all undoubtedly aware, surface 
meshes are too large and cumbersome to pack with data sampled on the surface, 
necessitating something like FreeSurfer's directory structure. We're looking to 
create a common API that would work with FreeSurfer directories, collections of 
GIFTI files, CIFTI-2 + WBspec, etc., to allow efficient access to the topology, 
geometry and sampled data as needed.

We need input from users and developers of downstream tools who would like to 
work with these data. Non-Python developers are also welcome to share their 
experience and advice!

I'd like to plan a meeting in the next couple weeks. I'm (slowly) trying to 
start discussions over at 
https://secure-web.cisco.com/18kV2cNFE9uq84UPL5TGr7HSq3wVmYRpi0JhnQnLHwSQ5xNJPy6TP1vZWCiSLLout2WbAa-lfg6Mq6C7NTVzjgDBhLhQWGXj6_ZjRZNzpKzsO_TNviODj0ehZ9m3HmV1VtCauzjBIRkCNFinWCTsLoF2flLPpqnCGbXBWHYhwQtsi3GZGbpVLVeEqQI8wm94xk4rPSomgazhEjWVNQVmJwzIldlbKfbYtj-1hOUMzhIlDYmxyTOiaO6B2qh2sB7fBZLoxtJ_anLUX4vEz3FIoKg/https%3A%2F%2Fnipy.discourse.group%2Fc%2Fsurface-api%2F10.
 Please reach out over there or email me directly if you're interested in 
taking part in these discussions.

On behalf of the Nibabel developers,
--
Christopher J. Markiewicz, PhD
Center for Reproducible Neuroscience
Stanford University


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

Re: [Freesurfer] Clarification about .annot file format

2018-09-28 Thread Christopher Markiewicz 
External Email - Use Caution

Doug,


I think that's the only one.


Chris


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Greve, Douglas N.,Ph.D. 

Sent: Friday, September 28, 2018 1:09:50 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Clarification about .annot file format

Is this the offending line? or is there more?
value = (A * 2563) + (B * 2562) + (G * 256) + (R)


On 9/28/18 1:03 PM, Christopher Markiewicz wrote:

External Email - Use Caution

Hi Doug,


The relevant wiki page is: 
https://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles#Annotation


Chris


From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 on behalf of Greve, Douglas N.,Ph.D. 
<mailto:dgr...@mgh.harvard.edu>
Sent: Friday, September 28, 2018 12:47:36 PM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: Re: [Freesurfer] Clarification about .annot file format

Thanks Chris, can you point us to the offending wiki page?
doug

On 9/28/18 12:44 PM, Christopher Markiewicz wrote:

External Email - Use Caution

Hi all,


I believe I've gotten to the bottom of this, and the problem is incorrect 
documentation, both in the read/write_annotation.m files and in the wiki.


Taking the FreeSurfer C source as the de facto specification, we can refer to 
the colortab.c file. Here, the labels are not constructed or decoded using the 
transparency (255 - alpha) information at all, but are simply (R + G << 8 + B 
<< 16).


For more complete discussion, see:


https://github.com/nipy/nibabel/issues/649#issuecomment-424755969


I think the most parsimonious resolution of this confusion is simply to update 
the documentation on the wiki page (I cannot; someone with permissions will 
need to), and to patch the MATLAB code to build its labels from RGB values 
alone. I will submit a patch to the GitHub branch.

Please let me know if I've gotten something wrong.

Best,
Chris Markiewicz


From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 on behalf of paul mccarthy 
<mailto:pauldmccar...@gmail.com>
Sent: Thursday, September 20, 2018 11:39:53 AM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: [Freesurfer] Clarification about .annot file format


External Email - Use Caution

Howdy,

There is a discussion regarding the .annot file format over at the nibabel 
github repository, regarding the interpretation of the flag/alpha value:

https://github.com/nipy/nibabel/issues/649

If one wishes to create an .annot file with colours that have a transparency 
value, how should it be stored in the file? By piecing together the information 
from the freesurfer code [1,2], and Graham Wideman's helpful notes [3], I came 
to the conclusion that alpha values should be stored as 1-the actual value. But 
it would be great to get some clarification on this from somebody who knows 
more than me

Thanks very much,

Paul McCarthy

[1] https://github.com/freesurfer/freesurfer/blob/dev/matlab/read_annotation.m
[2] https://github.com/freesurfer/freesurfer/blob/dev/matlab/write_annotation.m
[3] 
https://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles#Annotation



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




___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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] Clarification about .annot file format

2018-09-28 Thread Christopher Markiewicz 
External Email - Use Caution

Hi Doug,


The relevant wiki page is: 
https://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles#Annotation


Chris


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Greve, Douglas N.,Ph.D. 

Sent: Friday, September 28, 2018 12:47:36 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] Clarification about .annot file format

Thanks Chris, can you point us to the offending wiki page?
doug

On 9/28/18 12:44 PM, Christopher Markiewicz wrote:

External Email - Use Caution

Hi all,


I believe I've gotten to the bottom of this, and the problem is incorrect 
documentation, both in the read/write_annotation.m files and in the wiki.


Taking the FreeSurfer C source as the de facto specification, we can refer to 
the colortab.c file. Here, the labels are not constructed or decoded using the 
transparency (255 - alpha) information at all, but are simply (R + G << 8 + B 
<< 16).


For more complete discussion, see:


https://github.com/nipy/nibabel/issues/649#issuecomment-424755969


I think the most parsimonious resolution of this confusion is simply to update 
the documentation on the wiki page (I cannot; someone with permissions will 
need to), and to patch the MATLAB code to build its labels from RGB values 
alone. I will submit a patch to the GitHub branch.

Please let me know if I've gotten something wrong.

Best,
Chris Markiewicz


From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 on behalf of paul mccarthy 
<mailto:pauldmccar...@gmail.com>
Sent: Thursday, September 20, 2018 11:39:53 AM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: [Freesurfer] Clarification about .annot file format


External Email - Use Caution

Howdy,

There is a discussion regarding the .annot file format over at the nibabel 
github repository, regarding the interpretation of the flag/alpha value:

https://github.com/nipy/nibabel/issues/649

If one wishes to create an .annot file with colours that have a transparency 
value, how should it be stored in the file? By piecing together the information 
from the freesurfer code [1,2], and Graham Wideman's helpful notes [3], I came 
to the conclusion that alpha values should be stored as 1-the actual value. But 
it would be great to get some clarification on this from somebody who knows 
more than me

Thanks very much,

Paul McCarthy

[1] https://github.com/freesurfer/freesurfer/blob/dev/matlab/read_annotation.m
[2] https://github.com/freesurfer/freesurfer/blob/dev/matlab/write_annotation.m
[3] 
https://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles#Annotation



___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu<mailto: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] Clarification about .annot file format

2018-09-28 Thread Christopher Markiewicz 
External Email - Use Caution

Hi all,


I believe I've gotten to the bottom of this, and the problem is incorrect 
documentation, both in the read/write_annotation.m files and in the wiki.


Taking the FreeSurfer C source as the de facto specification, we can refer to 
the colortab.c file. Here, the labels are not constructed or decoded using the 
transparency (255 - alpha) information at all, but are simply (R + G << 8 + B 
<< 16).


For more complete discussion, see:


https://github.com/nipy/nibabel/issues/649#issuecomment-424755969


I think the most parsimonious resolution of this confusion is simply to update 
the documentation on the wiki page (I cannot; someone with permissions will 
need to), and to patch the MATLAB code to build its labels from RGB values 
alone. I will submit a patch to the GitHub branch.

Please let me know if I've gotten something wrong.

Best,
Chris Markiewicz


From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of paul mccarthy 

Sent: Thursday, September 20, 2018 11:39:53 AM
To: freesurfer@nmr.mgh.harvard.edu
Subject: [Freesurfer] Clarification about .annot file format


External Email - Use Caution

Howdy,

There is a discussion regarding the .annot file format over at the nibabel 
github repository, regarding the interpretation of the flag/alpha value:

https://github.com/nipy/nibabel/issues/649

If one wishes to create an .annot file with colours that have a transparency 
value, how should it be stored in the file? By piecing together the information 
from the freesurfer code [1,2], and Graham Wideman's helpful notes [3], I came 
to the conclusion that alpha values should be stored as 1-the actual value. But 
it would be great to get some clarification on this from somebody who knows 
more than me

Thanks very much,

Paul McCarthy

[1] https://github.com/freesurfer/freesurfer/blob/dev/matlab/read_annotation.m
[2] https://github.com/freesurfer/freesurfer/blob/dev/matlab/write_annotation.m
[3] 
https://surfer.nmr.mgh.harvard.edu/fswiki/LabelsClutsAnnotationFiles#Annotation
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer

[Freesurfer] Resolution limits of FLAIR/T2w for effective pial refinement

2018-02-28 Thread Christopher Markiewicz 
Hi all,

I wonder if people have any data (or anecdotes - I'm not picky) with regard to 
how high of resolution T2w or FLAIR images need to be in order to be useful for 
FreeSurfer's pial refinement. I've seen a couple threads suggesting the optimal 
is ~1mm isotropic, and that thick slice (1x1x5 mm^3) FLAIR images could be 
tried, but might hurt more than help, and I'm wondering if there's a 
suboptimal-but-still-useful range somewhere in between.

For the record, this isn't a question of what scan parameters are recommended, 
but rather is in the context of data that's already been collected, which I 
would like to preprocess as well as possible.

So, at what resolutions would you recommend (a) completely ignoring T2w/FLAIR 
images; (b) including T2w/FLAIR images that pass QC; (c) trying and seeing? Do 
these answers change at all with T1w resolution?

--
Chris Markiewicz
Center for Reproducible Neuroscience
Stanford University


___
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] RFC: Changes to nibabel API for .mgh/.mgz files

2017-10-31 Thread Christopher Markiewicz 
Hi all,

I'd like to solicit input for the Python interface to .mgh/.mgz files in 
nibabel[0].

I've recently had cause to dig into this interface (MGHImage[1]), and found 
that the naming of header fields[2] (analogous to variable names in C structs) 
is inconsistent with all of my experience with how FreeSurfer refers to these 
fields in the code (MRI_IMAGE[3]) as well as in the outputs of many programs, 
such as mri_info. (In fact, the current names seem to reflect the intermediate 
variables used in load/save_mgh.m and the description of the affine transforms 
in the FS Coordinates powerpoints[4].)

I'm proposing (https://github.com/nipy/nibabel/pull/569) an API change in 
nibabel, with field names[5] that more closely reflect what I deem to be common 
FreeSurfer usage (although it does not adhere precisely to the C structure 
fields). Given that, it was felt that the FreeSurfer community more broadly 
should have some say in the final API. To put a few specific questions: Do you 
depend on the current MGHHeader field names? Would you be averse to updating 
the field names? If not, are there alternatives to my proposal you would find 
preferable?

While I would be willing to discuss in more detail on this list, I don't want 
to needlessly pollute a support list with discussions of a third party API. If 
it's convenient, I would prefer responses on the pull request linked above.

Thanks,
Chris Markiewicz

[0] http://nipy.org/nibabel/
[1] https://github.com/nipy/nibabel/blob/master/nibabel/freesurfer/mghformat.py
[2] 
https://github.com/nipy/nibabel/blob/2139ce0d24e65a83295bb6b3eaaf005eaeaebb5f/nibabel/freesurfer/mghformat.py#L28-L35
[3] https://github.com/freesurfer/freesurfer/blob/master/include/mri.h#L157-L252
[4] https://surfer.nmr.mgh.harvard.edu/fswiki/CoordinateSystems
[5] 
https://github.com/effigies/nibabel/blob/55c9bf905ec8785617755f900635fc31bae43232/nibabel/freesurfer/mghformat.py#L30-L49

___
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] lta_convert does not produce ITK transforms that are correctly applied by antsApplyTransforms

2017-10-20 Thread Christopher Markiewicz 
Hi Martin,

I've tracked down the issue. It turns out that the difference is that the 
VolGeoms are determined by the sform, while ANTs uses the qform. Syncing the 
qform to the sform resolves the issue.

Chris

From: freesurfer-boun...@nmr.mgh.harvard.edu 
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Christopher Markiewicz 
<markiew...@stanford.edu>
Sent: Tuesday, October 17, 2017 12:11:52 PM
To: Freesurfer support list
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Hi Martin,

I've uploaded a .tgz file with a T1w volume, BOLD volume, and a valid LTA file.

https://gate.nmr.mgh.harvard.edu/filedrop2/?g=7f71pykmv7p

Chris

From: freesurfer-boun...@nmr.mgh.harvard.edu 
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Martin Reuter 
<mreu...@nmr.mgh.harvard.edu>
Sent: Tuesday, October 17, 2017 9:32:54 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Hi Chris,

thanks, can you send the images and the exact commands. We have had success in 
the past, could be that you have a special case (e.g. maybe we never tested 
registration across different resolutions or whatever?).

Thanks, Martin

https://gate.nmr.mgh.harvard.edu/filedrop2/


On 16. Oct 2017, at 19:37, Christopher Markiewicz 
<markiew...@stanford.edu<mailto:markiew...@stanford.edu>> wrote:

Doug,

Sorry if I muddied things by going into the significant digits - accurate to 5 
seems reasonable. I was simply meaning to say that the rotation and scaling 
parameters are not the issue, to save the reader time inspecting them.

The translations (final three parameters) are off by anywhere 3 to 54mm, though.

LTA-FSL-ITK: 1.3066136395454464 -45.60342165876236 -43.10584860730749
LTA-ITK: -2.2848172187805176 -2.9065067768096924 11.744022369384766

I'm guessing lta_convert has the wrong model of the origin in ITK style 
affines, at least as applied by antsApplyTransforms.

Chris

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
<freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 on behalf of Douglas Greve 
<gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu>>
Sent: Monday, October 16, 2017 12:39:28 PM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Not sure I understand. If the two transforms are only off by less than
the 5th decimal, then why are the registrations off so much. As for why
it would be off at the 5ht dec, it probably has to do with the way we
store the matrix. When a volume is read in, the matrix is decomposed
into translation, scale, and direction cosine, and then the matrix is
thrown away. When a volume with the same geometry is written out, the
matrix is recomputed. Some resolution is lost during the
decomposition/recomposition, and we don't end up with the exact same matrix.


On 10/14/17 1:30 PM, Christopher Markiewicz wrote:
Hi,

I've used `bbregister` to generate a transform `bold2T1.lta` from `bold.nii` to 
`T1.mgz` (assume we have a `T1.nii` as well for the sake of ANTs).

The following produces a well-aligned output:

mri_convert --apply_transform bold2T1.lta bold.nii bold_space-T1.nii

As does the following:

lta_convert --inlta bold2T1.lta --outfsl bold2T1.mat
c3d_affine_tool -ref T1.nii -src bold.nii bold2T1.mat -fsl2ras -oitk 
bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

However, if one skips the FSL step, the registration is quite far off:

lta_convert --inlta bold2T1.lta --outitk bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

Comparing the ITK transform files:

LTA-FSL-ITK

#Insight Transform File V1.0
#Transform 0
Transform: MatrixOffsetTransformBase_double_3_3
Parameters: 0.9895096215486424 0.011126830936108464 -0.00042204653562094823 
-0.01079971161879626 0.872329255299452 -0.42602926756857834 
-0.004755964529051335 0.42420535065804454 0.8878552541301569 
-1.3066136395454464 -45.60342165876236 -43.10584860730749
FixedParameters: 0 0 0


LTA-ITK

#Insight Transform File V1.0
#Transform 0
Transform: AffineTransform_double_3_3
Parameters: 0.98950976133346558 0.011126830242574215 
-0.00042204943019896746 -0.010799713432788849 0.87232941389083862 
-0.42602935433387756 -0.0047559700906276703 0.42420542240142822 
0.88785547018051147 -2.2848172187805176 -2.9065067768096924 11.744022369384766
FixedParameters: 0 0 0


To 5 significant dig

[Freesurfer] readVolGeom corner case leads to lta_convert failures

2017-10-18 Thread Christopher Markiewicz 
Hi all,

We've run into an issue where lta_convert is failing if the filename line in a 
volume geometry is of a specific length. We've identified the source of the 
problem, and made a pull request on GitHub that at least partially fixes the 
issue (https://github.com/freesurfer/freesurfer/pull/180). Doug's requested 
that all bugs be posted to the mailing list, so I excerpt the pull request 
below.

-

It is currently possible to create a valid VolGeom string that will break 
readVolGeom, by setting the length of the line beginning "filename = " to be 
255 characters (+ `'\n'`).

The filename is defined to be a 1024 byte string, and so up to 1023 characters:

https://github.com/freesurfer/freesurfer/blob/9b79bf0eef76710a70a5b73142a8f6e2bab1a6b6/include/transform.h#L54

So, in writeVolGeom, a line may be written that is up to 1035 characters long 
(`"filename = "` + 1023 + `'\n'`):

https://github.com/freesurfer/freesurfer/blob/9b79bf0eef76710a70a5b73142a8f6e2bab1a6b6/utils/transform.c#L365

If the line is exactly 255 characters long (excluding newline), then the 
`fgets` call will retrieve the entire contents of the line (256 characters - 
terminating `'\NUL'`) without retrieving a newline. The next call to `fgets` 
will then get a line of length 0, resulting in a premature termination of the 
loop.


To observe an effect of this issue, consider the following LTA file:


type  = 0 # LINEAR_VOX_TO_VOX
nxforms   = 1
mean  = 0. 0. 0.
sigma = 1.
1 4 4
2.327464342117310e+00 4.245608299970627e-02 3.455499932169914e-02 
-1.319661331176758e+01 
-7.824462652206421e-02 3.904805898666382e+00 2.233271896839142e-01 
-5.291442871093750e-01 
-4.939173907041550e-02 -1.728723645210266e-01 4.818737983703613e+00 
7.657078552246094e+01 
0.000e+00 0.000e+00 0.000e+00 
1.000e+00 
src volume info
valid = 1  # volume info valid
filename = 
/scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/func_preproc_task_IncidentalencodingtaskusingPosnercueingparadigmwithobjectvgreeblejudgment_run_05_wf/bold_reg_wf/bbreg_wf/bbregister/ants_susceptibility_War
volume = 64 64 30
voxelsize = 3.4375000e+00 3.4375000e+00 4.000e+00
xras   = 1.000e+00 0.000e+00 0.000e+00
yras   = 0.000e+00 9.979115724563599e-01 -6.459446996450424e-02
zras   = 0.000e+00 6.459447741508484e-02 9.979115724563599e-01
cras   = 3.4375000e+00 8.357086181640625e-01 4.582891845703125e+01
dst volume info
valid = 1  # volume info valid
filename = 
/scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/anat_preproc_wf/t1_merge/sub-07_T1w_ras_template.nii.gz
volume = 124 256 256
voxelsize = 1.500e+00 8.593999743461609e-01 8.593999743461609e-01
xras   = 9.998608827590942e-01 1.065783575177193e-02 -1.283265277743340e-02
yras   = -9.511843323707581e-03 9.962262511253357e-01 8.627174794673920e-02
zras   = 1.370369549840689e-02 -8.613768219947815e-02 9.961889982223511e-01
cras   = -3.533935546875000e-01 5.862289428710938e+00 -1.128549194335938e+01
subject sub-07
fscale 0.10


If you save this as `test.lta`, the following command fails in an unexpected 
way:


$ lta_convert --inlta truncated.lta --outlta out.lta
$Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $

--inlta: truncated.lta input LTA transform.
--outlta: out.lta output LTA.
LTAchangeType: dst geometry must be valid


The offending line is:


filename = 
/scratch/03763/oesteban/fmriprep-phase1/work/ds000110/fmriprep_wf/single_subject_07_wf/func_preproc_task_IncidentalencodingtaskusingPosnercueingparadigmwithobjectvgreeblejudgment_run_05_wf/bold_reg_wf/bbreg_wf/bbregister/ants_susceptibility_War


Add or remove a character and the command proceeds without error. However, 
supposing you add a character (and, critically, convert between `RAS_TO_RAS` 
and `VOX_TO_VOX`):


$ lta_convert --inlta extended.lta --outlta out1.lta 
$Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $

--inlta: extended.lta input LTA transform.
--outlta: out1.lta output LTA.
 LTA read, type : 1
 1.01550   0.01035   0.02607  -3.12509;
-0.00760   0.97176  -0.10423   6.51772;
-0.02702   0.10772   1.03053  -46.97261;
 0.0   0.0   0.0   1.0;
Writing  LTA to file out1.lta...
lta_convert successful.
$ lta_convert --inlta out1.lta --outlta out2.lta --ltavox2vox
$Id: lta_convert.cpp,v 1.9.2.1 2016/08/09 02:33:22 zkaufman Exp $

--inlta: out1.lta input LTA transform.
--outlta: out2.lta output LTA.
--ltavox2vox: output LTA as VOX_TO_VOX transform.
 LTA read, type : 1
 1.01550   0.01035   0.02607  -3.12509;
-0.00760   0.97176  -0.10423   6.51772;
-0.02702   0.10772   1.03053  -46.97261;
 0.0   0.0   0.0   1.0;
LTAchangeType: dst geometry must be valid


This is a result of the truncation that occurs during the read.

Thanks for your time,

Re: [Freesurfer] lta_convert does not produce ITK transforms that are correctly applied by antsApplyTransforms

2017-10-17 Thread Christopher Markiewicz 
Hi Martin,

I've uploaded a .tgz file with a T1w volume, BOLD volume, and a valid LTA file.

https://gate.nmr.mgh.harvard.edu/filedrop2/?g=7f71pykmv7p

Chris

From: freesurfer-boun...@nmr.mgh.harvard.edu 
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Martin Reuter 
<mreu...@nmr.mgh.harvard.edu>
Sent: Tuesday, October 17, 2017 9:32:54 AM
To: Freesurfer support list
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Hi Chris,

thanks, can you send the images and the exact commands. We have had success in 
the past, could be that you have a special case (e.g. maybe we never tested 
registration across different resolutions or whatever?).

Thanks, Martin

https://gate.nmr.mgh.harvard.edu/filedrop2/


On 16. Oct 2017, at 19:37, Christopher Markiewicz 
<markiew...@stanford.edu<mailto:markiew...@stanford.edu>> wrote:

Doug,

Sorry if I muddied things by going into the significant digits - accurate to 5 
seems reasonable. I was simply meaning to say that the rotation and scaling 
parameters are not the issue, to save the reader time inspecting them.

The translations (final three parameters) are off by anywhere 3 to 54mm, though.

LTA-FSL-ITK: 1.3066136395454464 -45.60342165876236 -43.10584860730749
LTA-ITK: -2.2848172187805176 -2.9065067768096924 11.744022369384766

I'm guessing lta_convert has the wrong model of the origin in ITK style 
affines, at least as applied by antsApplyTransforms.

Chris

From: 
freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>
 
<freesurfer-boun...@nmr.mgh.harvard.edu<mailto:freesurfer-boun...@nmr.mgh.harvard.edu>>
 on behalf of Douglas Greve 
<gr...@nmr.mgh.harvard.edu<mailto:gr...@nmr.mgh.harvard.edu>>
Sent: Monday, October 16, 2017 12:39:28 PM
To: freesurfer@nmr.mgh.harvard.edu<mailto:freesurfer@nmr.mgh.harvard.edu>
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Not sure I understand. If the two transforms are only off by less than
the 5th decimal, then why are the registrations off so much. As for why
it would be off at the 5ht dec, it probably has to do with the way we
store the matrix. When a volume is read in, the matrix is decomposed
into translation, scale, and direction cosine, and then the matrix is
thrown away. When a volume with the same geometry is written out, the
matrix is recomputed. Some resolution is lost during the
decomposition/recomposition, and we don't end up with the exact same matrix.


On 10/14/17 1:30 PM, Christopher Markiewicz wrote:
Hi,

I've used `bbregister` to generate a transform `bold2T1.lta` from `bold.nii` to 
`T1.mgz` (assume we have a `T1.nii` as well for the sake of ANTs).

The following produces a well-aligned output:

mri_convert --apply_transform bold2T1.lta bold.nii bold_space-T1.nii

As does the following:

lta_convert --inlta bold2T1.lta --outfsl bold2T1.mat
c3d_affine_tool -ref T1.nii -src bold.nii bold2T1.mat -fsl2ras -oitk 
bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

However, if one skips the FSL step, the registration is quite far off:

lta_convert --inlta bold2T1.lta --outitk bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

Comparing the ITK transform files:

LTA-FSL-ITK

#Insight Transform File V1.0
#Transform 0
Transform: MatrixOffsetTransformBase_double_3_3
Parameters: 0.9895096215486424 0.011126830936108464 -0.00042204653562094823 
-0.01079971161879626 0.872329255299452 -0.42602926756857834 
-0.004755964529051335 0.42420535065804454 0.8878552541301569 
-1.3066136395454464 -45.60342165876236 -43.10584860730749
FixedParameters: 0 0 0


LTA-ITK

#Insight Transform File V1.0
#Transform 0
Transform: AffineTransform_double_3_3
Parameters: 0.98950976133346558 0.011126830242574215 
-0.00042204943019896746 -0.010799713432788849 0.87232941389083862 
-0.42602935433387756 -0.0047559700906276703 0.42420542240142822 
0.88785547018051147 -2.2848172187805176 -2.9065067768096924 11.744022369384766
FixedParameters: 0 0 0


To 5 significant digits, these are the same, except the last three 
(translation) parameters. And the `AffineTransform_double_3_3` is different 
from `MatrixOffsetTransformBase_double_3_3`, though I'm not sure whether this 
has any effect.

Here is the original LTA:

type  = 1 # LINEAR_RAS_TO_RAS
nxforms   = 1
mean  = 0. 0. 0.
sigma = 1.
1 4 4
1.010462999343872e+00 -1.063966564834118e-02 4.625014495104551e-03 
-2.332115173339844e+00
1.228639855980873e-02 9.293417930603027e-01 -4.459420144557953e-01 
2.507942199707031e+00
4.575361963361502e-04 4.440840482711792e-01 9.132194519042969e-01 
-1.2016

Re: [Freesurfer] lta_convert does not produce ITK transforms that are correctly applied by antsApplyTransforms

2017-10-16 Thread Christopher Markiewicz 
Doug,

Sorry if I muddied things by going into the significant digits - accurate to 5 
seems reasonable. I was simply meaning to say that the rotation and scaling 
parameters are not the issue, to save the reader time inspecting them.

The translations (final three parameters) are off by anywhere 3 to 54mm, though.

LTA-FSL-ITK: 1.3066136395454464 -45.60342165876236 -43.10584860730749
LTA-ITK: -2.2848172187805176 -2.9065067768096924 11.744022369384766

I'm guessing lta_convert has the wrong model of the origin in ITK style 
affines, at least as applied by antsApplyTransforms.

Chris

From: freesurfer-boun...@nmr.mgh.harvard.edu 
<freesurfer-boun...@nmr.mgh.harvard.edu> on behalf of Douglas Greve 
<gr...@nmr.mgh.harvard.edu>
Sent: Monday, October 16, 2017 12:39:28 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] lta_convert does not produce ITK transforms that are 
correctly applied by antsApplyTransforms

Not sure I understand. If the two transforms are only off by less than
the 5th decimal, then why are the registrations off so much. As for why
it would be off at the 5ht dec, it probably has to do with the way we
store the matrix. When a volume is read in, the matrix is decomposed
into translation, scale, and direction cosine, and then the matrix is
thrown away. When a volume with the same geometry is written out, the
matrix is recomputed. Some resolution is lost during the
decomposition/recomposition, and we don't end up with the exact same matrix.


On 10/14/17 1:30 PM, Christopher Markiewicz wrote:
> Hi,
>
> I've used `bbregister` to generate a transform `bold2T1.lta` from `bold.nii` 
> to `T1.mgz` (assume we have a `T1.nii` as well for the sake of ANTs).
>
> The following produces a well-aligned output:
>
>  mri_convert --apply_transform bold2T1.lta bold.nii bold_space-T1.nii
>
> As does the following:
>
>  lta_convert --inlta bold2T1.lta --outfsl bold2T1.mat
>  c3d_affine_tool -ref T1.nii -src bold.nii bold2T1.mat -fsl2ras -oitk 
> bold2T1.txt
>  antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
> bold2T1.txt
>
> However, if one skips the FSL step, the registration is quite far off:
>
>  lta_convert --inlta bold2T1.lta --outitk bold2T1.txt
>  antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
> bold2T1.txt
>
> Comparing the ITK transform files:
>
> LTA-FSL-ITK
>
>  #Insight Transform File V1.0
>  #Transform 0
>  Transform: MatrixOffsetTransformBase_double_3_3
>  Parameters: 0.9895096215486424 0.011126830936108464 
> -0.00042204653562094823 -0.01079971161879626 0.872329255299452 
> -0.42602926756857834 -0.004755964529051335 0.42420535065804454 
> 0.8878552541301569 -1.3066136395454464 -45.60342165876236 -43.10584860730749
>  FixedParameters: 0 0 0
>
>
> LTA-ITK
>
>  #Insight Transform File V1.0
>  #Transform 0
>  Transform: AffineTransform_double_3_3
>  Parameters: 0.98950976133346558 0.011126830242574215 
> -0.00042204943019896746 -0.010799713432788849 0.87232941389083862 
> -0.42602935433387756 -0.0047559700906276703 0.42420542240142822 
> 0.88785547018051147 -2.2848172187805176 -2.9065067768096924 11.744022369384766
>  FixedParameters: 0 0 0
>
>
> To 5 significant digits, these are the same, except the last three 
> (translation) parameters. And the `AffineTransform_double_3_3` is different 
> from `MatrixOffsetTransformBase_double_3_3`, though I'm not sure whether this 
> has any effect.
>
> Here is the original LTA:
>
>  type  = 1 # LINEAR_RAS_TO_RAS
>  nxforms   = 1
>  mean  = 0. 0. 0.
>  sigma = 1.
>  1 4 4
>  1.010462999343872e+00 -1.063966564834118e-02 4.625014495104551e-03 
> -2.332115173339844e+00
>  1.228639855980873e-02 9.293417930603027e-01 -4.459420144557953e-01 
> 2.507942199707031e+00
>  4.575361963361502e-04 4.440840482711792e-01 9.132194519042969e-01 
> -1.201664733886719e+01
>  0.000e+00 0.000e+00 0.000e+00 
> 9.98807907104e-01
>  src volume info
>  valid = 1  # volume info valid
>  filename = 
> /scratch/fmriprep_wf/single_subject_02_wf/func_preproc_task_short_wf/bold_reg_wf/bbreg_wf/bbregister/uni_masked_xform.nii.gz
>  volume = 64 64 34
>  voxelsize = 3.125e+00 3.125e+00 
> 4.000e+00
>  xras   = -1.000e+00 0.000e+00 
> 0.000e+00
>  yras   = 0.000e+00 1.000e+00 
> 0.000e+00
>  zras   = 0.000e+00 0.000e+00 
> 1.000e+00
>  cras   = -1.090248107910156e+00 -1.071614074707031e+01 
> 1.

[Freesurfer] lta_convert does not produce ITK transforms that are correctly applied by antsApplyTransforms

2017-10-14 Thread Christopher Markiewicz 
Hi,

I've used `bbregister` to generate a transform `bold2T1.lta` from `bold.nii` to 
`T1.mgz` (assume we have a `T1.nii` as well for the sake of ANTs). 

The following produces a well-aligned output:

mri_convert --apply_transform bold2T1.lta bold.nii bold_space-T1.nii

As does the following:

lta_convert --inlta bold2T1.lta --outfsl bold2T1.mat
c3d_affine_tool -ref T1.nii -src bold.nii bold2T1.mat -fsl2ras -oitk 
bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

However, if one skips the FSL step, the registration is quite far off:

lta_convert --inlta bold2T1.lta --outitk bold2T1.txt
antsApplyTransforms -i bold.nii -r T1.nii -o bold_space-T1.nii -t 
bold2T1.txt

Comparing the ITK transform files:

LTA-FSL-ITK

#Insight Transform File V1.0
#Transform 0
Transform: MatrixOffsetTransformBase_double_3_3
Parameters: 0.9895096215486424 0.011126830936108464 -0.00042204653562094823 
-0.01079971161879626 0.872329255299452 -0.42602926756857834 
-0.004755964529051335 0.42420535065804454 0.8878552541301569 
-1.3066136395454464 -45.60342165876236 -43.10584860730749
FixedParameters: 0 0 0


LTA-ITK

#Insight Transform File V1.0
#Transform 0
Transform: AffineTransform_double_3_3
Parameters: 0.98950976133346558 0.011126830242574215 
-0.00042204943019896746 -0.010799713432788849 0.87232941389083862 
-0.42602935433387756 -0.0047559700906276703 0.42420542240142822 
0.88785547018051147 -2.2848172187805176 -2.9065067768096924 11.744022369384766
FixedParameters: 0 0 0


To 5 significant digits, these are the same, except the last three 
(translation) parameters. And the `AffineTransform_double_3_3` is different 
from `MatrixOffsetTransformBase_double_3_3`, though I'm not sure whether this 
has any effect.

Here is the original LTA:

type  = 1 # LINEAR_RAS_TO_RAS
nxforms   = 1
mean  = 0. 0. 0.
sigma = 1.
1 4 4
1.010462999343872e+00 -1.063966564834118e-02 4.625014495104551e-03 
-2.332115173339844e+00 
1.228639855980873e-02 9.293417930603027e-01 -4.459420144557953e-01 
2.507942199707031e+00 
4.575361963361502e-04 4.440840482711792e-01 9.132194519042969e-01 
-1.201664733886719e+01 
0.000e+00 0.000e+00 0.000e+00 
9.98807907104e-01 
src volume info
valid = 1  # volume info valid
filename = 
/scratch/fmriprep_wf/single_subject_02_wf/func_preproc_task_short_wf/bold_reg_wf/bbreg_wf/bbregister/uni_masked_xform.nii.gz
volume = 64 64 34
voxelsize = 3.125e+00 3.125e+00 
4.000e+00
xras   = -1.000e+00 0.000e+00 0.000e+00
yras   = 0.000e+00 1.000e+00 0.000e+00
zras   = 0.000e+00 0.000e+00 1.000e+00
cras   = -1.090248107910156e+00 -1.071614074707031e+01 1.619928741455078e+01
dst volume info
valid = 1  # volume info valid
filename = 
/scratch/fmriprep_wf/single_subject_02_wf/anat_preproc_wf/t1_merge/sub-02_T1w_template.nii.gz
volume = 160 192 192
voxelsize = 1.000e+00 1.33015441895e+00 
1.33015441895e+00
xras   = 1.000e+00 0.000e+00 0.000e+00
yras   = 0.000e+00 1.000e+00 0.000e+00
zras   = 0.000e+00 0.000e+00 1.000e+00
cras   = -3.000e+00 2.69482421875e+00 -8.30517578125e+00
subject sub-02
fscale 0.10


If it would be useful, I can provide any relevant images for testing.

--
Chris Markiewicz
Center for Reproducible Neuroscience
Stanford University


___
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] negative header after preproc-sess

2017-07-27 Thread Christopher Markiewicz 
Hi Doug,

I wonder if there's a plan to move to NIfTI-2 as the default encoding for 
.nii(.gz) images that would can't be encoded in a standard-conforming NIfTI-1? 
I believe all of the major packages support NIfTI-2 in their latest releases 
(with the possible exception of ANTs, which I don't believe handles surface 
data in any event).

Chris Markiewwicz

From: freesurfer-boun...@nmr.mgh.harvard.edu 
 on behalf of Douglas Greve 

Sent: Wednesday, July 5, 2017 7:07:50 PM
To: freesurfer@nmr.mgh.harvard.edu
Subject: Re: [Freesurfer] negative header after preproc-sess

When the nifti standard was adopted, they used a short int to represent the 
dimensions. Unfortunately, this only allows for a maximum dimension of 32k, 
which is not big enough for surfaces. So I hacked the FS nifti format to put a 
-1 as the first dim at which point the FS code will go to another place in the 
header to get the spatial dimensions. It is possible to reshape the spatial 
dimensions as long as the largest prime factor is less than 32k (see 
mri_surf2surf with --reshape option). Other than that, you might ask the 
nibabel people to program the same hack.

On 6/25/17 6:48 AM, Bai Haohao wrote:
Hello Freesurfer experts,

I am running my data with preproc-sess to project my func data to individual 
anatomy file, and the command shows as below:

preproc-sess -sf ${Sesslist} -fsd "bold" -surface self lhrh -fwhm 0 -per-run 
-force

And the subjectname point to the subject dir that created after recon-all.

After the running completed, I try to load data from fmcpr.sm0.self.lh.nii.gz 
with nibabel, and I get this error info:

>>> f.get_data()
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/pymodules/python2.7/nibabel/spatialimages.py", line 341, in 
get_data
return np.asanyarray(self._data)
  File "/usr/lib/python2.7/dist-packages/numpy/core/numeric.py", line 512, in 
asanyarray
return array(a, dtype, copy=False, order=order, subok=True)
  File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 55, in 
__array__
self._data = self._read_data()
  File "/usr/lib/pymodules/python2.7/nibabel/arrayproxy.py", line 60, in 
_read_data
data = self.header.data_from_fileobj(fileobj)
  File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 486, in 
data_from_fileobj
data = self.raw_data_from_fileobj(fileobj)
  File "/usr/lib/pymodules/python2.7/nibabel/analyze.py", line 458, in 
raw_data_from_fileobj
return array_from_file(shape, dtype, fileobj, offset)
  File "/usr/lib/pymodules/python2.7/nibabel/volumeutils.py", line 493, in 
array_from_file
raise IOError(msg)
IOError: Expected -1804 bytes, got 264809160 bytes from file 
"fmcpr.vol2surf.lh.nii.gz"
 - could the file be damaged?

Then I check the file header by nibabel, and I get this:

>>> print(f.get_header())
 object, endian='<'
sizeof_hdr  : 348
data_type   :
db_name :
extents : 0
session_error   : 0
regular :
dim_info: 0
dim : [  4  -1   1   1 451   1   1   1]
intent_p1   : 0.0
intent_p2   : 0.0
intent_p3   : 0.0
intent_code : none
datatype: float32
bitpix  : 32
slice_start : 0
pixdim  : [-1.  1.  1.  1.  2.0072  
1.  1.
  1.]
vox_offset  : 352.0
scl_slope   : 0.0
scl_inter   : 0.0
slice_end   : 0
slice_code  : unknown
xyzt_units  : 10
cal_max : 0.0
cal_min : 0.0
slice_duration  : 0.0
toffset : 0.0
glmax   : 0
glmin   : 146790
descrip : FreeSurfer May 13 2013
aux_file:
qform_code  : scanner
sform_code  : scanner
quatern_b   : -0.0115927606821
quatern_c   : -0.996071338654
quatern_d   : -0.0864994972944
qoffset_x   : 73344.5546875
qoffset_y   : -1492.14978027
qoffset_z   : -2311.28955078
srow_x  : [ -9.99280393e-01   2.56918129e-02   2.79041883e-02   
7.33445547e+04]
srow_y  : [  2.04970520e-02   9.84766901e-01  -1.72667429e-01  
-1.49214978e+03]
srow_z  : [  3.19152586e-02   1.71971247e-01   9.84584868e-01  
-2.31128955e+03]
intent_name :
magic   : n+1



Note that the dim has value -1, but when I use -surface fsaverage, the dim is 
correct(show as below):

dim : [4 27307 1 6   451 1 1 1]

And I read the source code, the difference between self and fsaverage is 
appeared when running rawfunc2surf-sess, and log files are attached.

I have tried many commands to load data from fmcpr.sm0.self.lh.nii.gz, such as 
fslview, freeview, mri_convert, mri_surf2surf, ...

and only tksurfer could read this file by -timecourse fmcpr.sm0.self.lh.nii.gz.

I want to figure out how could I fix it, and any suggestion would be helpful.

Thanks in advance,

Bai Haohao


Version info:
System:

[Freesurfer] Survey on inputs for surface-based analysis pipelines

2017-04-12 Thread Christopher Markiewicz 
Hi list,

We're working on FMRIPREP , a 
pipeline aimed at performing baseline preprocessing, and producing cleaned 
structural and functional data which can be fed into any of a number of 
analysis pipelines.

We've recently begun incorporating surface reconstruction and surface-mapped 
functionals, and we'd like to get feedback on what outputs would be most 
valuable to people, in terms of formats, spaces and sampling strategies.

1) What surfaces do you use for sampling functional data and visualization? If 
you use down-sampled surfaces, do you have a preferred down-sampling strategy 
or target mesh?

2) What statistical analyses and model-fitting tools do you use for 
surface-based analyses? And are there any particular considerations you have 
for preparing your data for use by these tools?

I appreciate your time and any input you may have to help us build a tool that 
fits the needs of the community.

Thanks,
-- 
Chris Markiewicz
Center for Reproducible Neuroscience
Stanford University


___
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] First-level GLM on externally-preprocessed functionals

2017-04-06 Thread Christopher Markiewicz 
Hi list,

We're working on making a preprocessing stream that will be generally
accessible to different analysis streams, including FreeSurfer. One
component of this is sampling functional volumes to FreeSurfer meshes, and
I want to test this component by running a simple first-level GLM in
FreeSurfer.

I've always done this through the FSFAST pipeline, but that may be a bit
much, given that I'm starting from surface time series (the equivalent of
`$FUNCTIONALS_DIR/$SESS_ID/bold/$RUN/fmcpr.sm0.fsaverage.lh.nii.gz`, but as
a GIFTI file).

Supposing I have a paradigm file and the files described above, what's the
best way to do a basic GLM? Would it be to `mri_surf2surf` our GIFTI
surfaces into `fmcpr.sm0.fsaverage.lh.nii.gz` files in a FSFAST directory
structure, and pick up at `mkanalysis-sess`? Or is there a more
straightforward way to just get a simple set of contrasts to compare with a
volumetric analysis?

Thanks in advance,
Chris Markiewicz
___
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] Adjust bbregister affine to target raw T1

2017-03-14 Thread Christopher Markiewicz 
Hi Doug,

As an update, --init-coreg produced essentially the same result as
--init-fsl; however, that was on EPIs we've discovered were LR flipped
during reconstruction, so I've switched to a different test subject for now.

Now, for --init-fsl and --init-coreg, respectively, we get:

MinCost: 0.552768 531.638763 549.553173 0.397916
MinCost: 0.552773 531.586204 549.501644 0.394639

Again, very little difference between the two cases, so that's good. I'm
not really sure how to judge what a reasonable min cost is. What criteria
do you use, and is there more detailed documentation somewhere?

Thanks,
Chris


On Fri, Mar 10, 2017 at 10:41 AM, Douglas Greve <gr...@nmr.mgh.harvard.edu>
wrote:

> That min cost (.86) is too high for sure. My guess is that it is the fsl
> init. In general, bbregister is pretty insensitive to the initialization
> method (as long as the init does not fail), so I would not worry about some
> being done with coreg and some with flirt
>
> On 3/9/17 3:40 PM, Christopher Markiewicz wrote:
>
> Hi Doug,
>
> This is the final line with "cost" in it:
>
> MinCost: 0.862331 7440.183178 7411.264107 -1.819400
>
> We're switching from FLIRT BBR (two-pass) to bbregister when there's a
> reconstructed subject available, so I'm using `--init-fsl` to try to
> minimize the differences in the pipeline in the two cases, but I can try
> `--init-coreg` if there's something wrong with the initialization.
>
> Thanks,
> Chris
>
>
> On Thu, Mar 9, 2017 at 3:29 PM, Douglas N Greve <gr...@nmr.mgh.harvard.edu
> > wrote:
>
>> that should have worked. what was the bbregister final cost function? It
>> could have been that fsl did not provide a good initial registration. If
>> you have v6, you can leave off --init-fsl and it will use mri_coreg
>> (which is more robust).
>>
>>
>> On 03/09/2017 03:24 PM, Christopher Markiewicz wrote:
>> > Hi all,
>> >
>> > Suppose you have a sub-pipeline:
>> >
>> > $ recon-all -s $SUBJ -i $T1 -all
>> > $ bbregister --s $SUBJ --mov $EPI --init-fsl --t2 --reg bbreg.dat
>> > --fslmat fsl.mat
>> >
>> > Now `bbreg.dat`/`fsl.mat` is registered to
>> > `$SUBJECTS_DIR/$SUBJ/mri/T1.mgz`; what's the best way to register to
>> $T1?
>> >
>> > I've tried:
>> >
>> > $ tkregister2 --no-edit --mov $EPI --reg bbreg.dat --targ $T1
>> > --fslregout adjusted.mat
>> >
>> > And that's clearly wrong, but I'm kind of stuck on where to go from
>> > here. Anybody see where I'm going wrong?
>> >
>> > Thanks,
>> > Chris
>> >
>> >
>> > ___
>> > Freesurfer mailing list
>> > Freesurfer@nmr.mgh.harvard.edu
>> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>>
>> --
>> Douglas N. Greve, Ph.D.
>> MGH-NMR Center
>> gr...@nmr.mgh.harvard.edu
>> Phone Number: 617-724-2358
>> Fax: 617-726-7422
>>
>> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
>> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
>> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
>> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>>
>> ___
>> 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 
> listfreesur...@nmr.mgh.harvard.eduhttps://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

[Freesurfer] BUG: bbregister --init-best needs to unset InitCoreg

2017-03-13 Thread Christopher Markiewicz 
Hi all,

bbregister --init-best always produces "ERROR: cannot spec an init method
with --init-best", because InitCoreg is defined as 1 by default, and never
set to 0 by --init-best. (Setting something else that unsets InitCoreg will
trigger the same error.)

Example, given SUBJ and EPI:

$ bbregister --init-best --s $SUBJ --mov $EPI --o ${EPI%.nii.gz}_bbr.nii.gz
--reg ${EPI%.nii.gz}_bbr.dat
ERROR: cannot spec an init method with --init-best

Using FreeSurfer 6.0 release installed on an Ubuntu 16.04 machine.

Thanks,
Chris
___
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] Adjust bbregister affine to target raw T1

2017-03-09 Thread Christopher Markiewicz 
Hi Doug,

This is the final line with "cost" in it:

MinCost: 0.862331 7440.183178 7411.264107 -1.819400

We're switching from FLIRT BBR (two-pass) to bbregister when there's a
reconstructed subject available, so I'm using `--init-fsl` to try to
minimize the differences in the pipeline in the two cases, but I can try
`--init-coreg` if there's something wrong with the initialization.

Thanks,
Chris


On Thu, Mar 9, 2017 at 3:29 PM, Douglas N Greve <gr...@nmr.mgh.harvard.edu>
wrote:

> that should have worked. what was the bbregister final cost function? It
> could have been that fsl did not provide a good initial registration. If
> you have v6, you can leave off --init-fsl and it will use mri_coreg
> (which is more robust).
>
>
> On 03/09/2017 03:24 PM, Christopher Markiewicz wrote:
> > Hi all,
> >
> > Suppose you have a sub-pipeline:
> >
> > $ recon-all -s $SUBJ -i $T1 -all
> > $ bbregister --s $SUBJ --mov $EPI --init-fsl --t2 --reg bbreg.dat
> > --fslmat fsl.mat
> >
> > Now `bbreg.dat`/`fsl.mat` is registered to
> > `$SUBJECTS_DIR/$SUBJ/mri/T1.mgz`; what's the best way to register to
> $T1?
> >
> > I've tried:
> >
> > $ tkregister2 --no-edit --mov $EPI --reg bbreg.dat --targ $T1
> > --fslregout adjusted.mat
> >
> > And that's clearly wrong, but I'm kind of stuck on where to go from
> > here. Anybody see where I'm going wrong?
> >
> > Thanks,
> > Chris
> >
> >
> > ___
> > Freesurfer mailing list
> > Freesurfer@nmr.mgh.harvard.edu
> > https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
> --
> Douglas N. Greve, Ph.D.
> MGH-NMR Center
> gr...@nmr.mgh.harvard.edu
> Phone Number: 617-724-2358
> Fax: 617-726-7422
>
> Bugs: surfer.nmr.mgh.harvard.edu/fswiki/BugReporting
> FileDrop: https://gate.nmr.mgh.harvard.edu/filedrop2
> www.nmr.mgh.harvard.edu/facility/filedrop/index.html
> Outgoing: ftp://surfer.nmr.mgh.harvard.edu/transfer/outgoing/flat/greve/
>
> ___
> Freesurfer mailing list
> Freesurfer@nmr.mgh.harvard.edu
> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
>
>
> The information in this e-mail is intended only for the person to whom it
> is
> addressed. If you believe this e-mail was sent to you in error and the
> e-mail
> contains patient information, please contact the Partners Compliance
> HelpLine at
> http://www.partners.org/complianceline . If the e-mail was sent to you in
> error
> but does not contain patient information, please contact the sender and
> properly
> dispose of the e-mail.
>
>
___
Freesurfer mailing list
Freesurfer@nmr.mgh.harvard.edu
https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine at
http://www.partners.org/complianceline . If the e-mail was sent to you in error
but does not contain patient information, please contact the sender and properly
dispose of the e-mail.

[Freesurfer] Adjust bbregister affine to target raw T1

2017-03-09 Thread Christopher Markiewicz 
Hi all,

Suppose you have a sub-pipeline:

$ recon-all -s $SUBJ -i $T1 -all
$ bbregister --s $SUBJ --mov $EPI --init-fsl --t2 --reg bbreg.dat --fslmat
fsl.mat

Now `bbreg.dat`/`fsl.mat` is registered to
`$SUBJECTS_DIR/$SUBJ/mri/T1.mgz`; what's the best way to register to $T1?

I've tried:

$ tkregister2 --no-edit --mov $EPI --reg bbreg.dat --targ $T1 --fslregout
adjusted.mat

And that's clearly wrong, but I'm kind of stuck on where to go from here.
Anybody see where I'm going wrong?

Thanks,
Chris
___
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] bbregister surfaces

2017-01-12 Thread Christopher Markiewicz 
Hi all,

According to
https://www.mail-archive.com/freesurfer@nmr.mgh.harvard.edu/msg25476.html,
bbregister uses the white matter surface and cortical thickness measures to
perform its registrations, though there was some possibility of using the
pial surface in further releases. I just want to verify that this is still
the case, and the pial surface is not currently being used.

Thanks,
Chris Markiewicz
___
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.