External Email - Use Caution
Hi All,
I'm running FS v. 5.3 on Gentoo Linux.
I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results.
Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none.
The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold
I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55.
My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem?
Best regards, Patrycja
External Email - Use Caution
Hi All,
I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results.
I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)?
I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution?
The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used.
Best regards, Patrycja
2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk patrycja.naumczyk@gmail.com:
Hi All,
I'm running FS v. 5.3 on Gentoo Linux.
I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results.
Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none.
The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold
I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55.
My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem?
Best regards, Patrycja
External Email - Use Caution
Hi All,
a little update. I tried running fslreorient2std before preprroc-sess. It didn't help either...
Best regards, Patrycja
pon., 14.05.2018, 10:05 użytkownik Patrycja Naumczyk < patrycja.naumczyk@gmail.com> napisał:
Hi All,
I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results.
I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)?
I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution?
The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used.
Best regards, Patrycja
2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk patrycja.naumczyk@gmail.com :
Hi All,
I'm running FS v. 5.3 on Gentoo Linux.
I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results.
Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none.
The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold
I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55.
My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem?
Best regards, Patrycja
It might be the initialization with FLIRT. Do you have access to FS6.0? If so, can you try running 6.0 instead to see if it fixes the problem?
On 5/14/18 4:05 AM, Patrycja Naumczyk wrote:
Hi All,
I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results.
I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)?
I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution?
The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used.
Best regards, Patrycja
2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk <patrycja.naumczyk@gmail.com mailto:patrycja.naumczyk@gmail.com>:
Hi All, I'm running FS v. 5.3 on Gentoo Linux. I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results. Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none. The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55. My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem? Best regards, Patrycja
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
External Email - Use Caution
Hi Doug,
we have v.6.0 on a cluster, so I quickly run one subject there (the one, whose files and pictures I attached previously). This time the BBR-sum was 0.9476, so slightly better but still bad :(
Best regards, Patrycja
2018-05-14 16:56 GMT+02:00 Douglas Greve dgreve@mgh.harvard.edu:
It might be the initialization with FLIRT. Do you have access to FS6.0? If so, can you try running 6.0 instead to see if it fixes the problem?
On 5/14/18 4:05 AM, Patrycja Naumczyk wrote:
Hi All,
I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results.
I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)?
I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution?
The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used.
Best regards, Patrycja
2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk patrycja.naumczyk@gmail.com :
Hi All,
I'm running FS v. 5.3 on Gentoo Linux.
I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results.
Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none.
The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold
I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55.
My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem?
Best regards, Patrycja
Freesurfer mailing listFreesurfer@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 to you in error but does not contain patient information, please contact the sender and properly dispose of the e-mail.
Can you tar up one of your subjects (fmri and FS analysis) and send it to me on our file drop below?
On 05/14/2018 01:58 PM, Patrycja Naumczyk wrote:
Hi Doug,
we have v.6.0 on a cluster, so I quickly run one subject there (the one, whose files and pictures I attached previously). This time the BBR-sum was 0.9476, so slightly better but still bad :(
Best regards, Patrycja
2018-05-14 16:56 GMT+02:00 Douglas Greve <dgreve@mgh.harvard.edu mailto:dgreve@mgh.harvard.edu>:
It might be the initialization with FLIRT. Do you have access to FS6.0? If so, can you try running 6.0 instead to see if it fixes the problem? On 5/14/18 4:05 AM, Patrycja Naumczyk wrote:Hi All, I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results. I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)? I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution? The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used. Best regards, Patrycja 2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk <patrycja.naumczyk@gmail.com <mailto:patrycja.naumczyk@gmail.com>>: Hi All, I'm running FS v. 5.3 on Gentoo Linux. I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results. Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none. The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55. My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem? Best regards, Patrycja _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer <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 <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 <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
External Email - Use Caution
OK - the 5.3 or the 6.0 version?
2018-05-14 20:00 GMT+02:00 Douglas N. Greve dgreve@mgh.harvard.edu:
Can you tar up one of your subjects (fmri and FS analysis) and send it to me on our file drop below?
On 05/14/2018 01:58 PM, Patrycja Naumczyk wrote:
Hi Doug,
we have v.6.0 on a cluster, so I quickly run one subject there (the one, whose files and pictures I attached previously). This time the BBR-sum was 0.9476, so slightly better but still bad :(
Best regards, Patrycja
2018-05-14 16:56 GMT+02:00 Douglas Greve <dgreve@mgh.harvard.edu mailto:dgreve@mgh.harvard.edu>:
It might be the initialization with FLIRT. Do you have access to FS6.0? If so, can you try running 6.0 instead to see if it fixes the problem? On 5/14/18 4:05 AM, Patrycja Naumczyk wrote:Hi All, I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results. I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)? I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution? The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used. Best regards, Patrycja 2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk <patrycja.naumczyk@gmail.com <mailto:patrycja.naumczyk@gmail.com>>: Hi All, I'm running FS v. 5.3 on Gentoo Linux. I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results. Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none. The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55. My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem? Best regards, Patrycja _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer <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 <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 <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
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
External Email - Use Caution
Hi Doug,
could please confirm receiving the files I sent the other day? By any chance, maybe You had a time to look into them?
Best regards, Patrycja
2018-05-14 20:01 GMT+02:00 Patrycja Naumczyk patrycja.naumczyk@gmail.com:
OK - the 5.3 or the 6.0 version?
2018-05-14 20:00 GMT+02:00 Douglas N. Greve dgreve@mgh.harvard.edu:
Can you tar up one of your subjects (fmri and FS analysis) and send it to me on our file drop below?
On 05/14/2018 01:58 PM, Patrycja Naumczyk wrote:
Hi Doug,
we have v.6.0 on a cluster, so I quickly run one subject there (the one, whose files and pictures I attached previously). This time the BBR-sum was 0.9476, so slightly better but still bad :(
Best regards, Patrycja
2018-05-14 16:56 GMT+02:00 Douglas Greve <dgreve@mgh.harvard.edu mailto:dgreve@mgh.harvard.edu>:
It might be the initialization with FLIRT. Do you have access to FS6.0? If so, can you try running 6.0 instead to see if it fixes the problem? On 5/14/18 4:05 AM, Patrycja Naumczyk wrote:Hi All, I'm still struggling with the registration - so far I tried performing slice-timing and/or motion correction in SPM instead of FS, but that did not changed the results. I came up with a new idea, but don't know how to verify it. I used GE scanner for data acquisition, which meant I had to convert the fMRI data and make the directory tree myself (as the dcm-unpack did not work well). I used MRIconvert for converting to nifti, which does not preserve some of the FS-Fast crucial data (i.e. the TR, which I had to update with mri_convert in all files). Is it possible that this is the reason of bbregister's misalignment? Like, the script needs some additional information that should be embedded in the data and is not (due to outside conversion)? I was thinking of maybe working around the problem by manually registering the rs-fMRI template to task-based template and then merging the two registration files (rs-fMRI_to_taskBased and taskBased_to_anatomical) and feeding that to the preproc-sess with "-regfile" flag. Potentially it could work, but maybe there is a simpler solution? The only difference between the properly aligned task-based fMRI and faulty rs-fMRI is that the latter has lower resolution (task based: 2.5x2.5x3.2mm, rs-fMRI: 3.4x3.4x3.3mm) and was longer (task-based: 160 volumes, rs-fMRI: 400 volumes). I attach screenshot of the problem in tkregister. Left - task-based fMRI, middle - rs-fMRI, right - rs-fMRI with task-based registration file used. Best regards, Patrycja 2018-05-12 15:20 GMT+02:00 Patrycja Naumczyk <patrycja.naumczyk@gmail.com <mailto:patrycja.naumczyk@gmail.com:
Hi All, I'm running FS v. 5.3 on Gentoo Linux. I made a study, where all subjects during one session had T1, resting-state and task-based fMRI. I processed all anatomical data through standard recon-all (it worked well), and the task-based fMRI through FS-FAST - which also generated fine results. Now I wanted to look into the rs-fMRI with functional connectivity. I made a separate directory tree for this purpose (in order not to mess task and rest data), and unfortunately the bbregister doesn't handle the registration during preproc-sess properly. Misalignment is big and covers all runs. BBR-sums of all of participants (N=39) exceed 0.8 (some of them exceed 1.0). What's interesting is that bbregister previously managed the task-based fMRI data well (with no BBR-sum exceeding 0.8). I double checked the data for any i.e. conversion/orientation faults, but found none. The command for preprocessing was identical in rs-fMRI and task-based fMRI: preproc-sess -sf <sessid> -d <ProjectDirectory> -surface fsaverage lhrh -mni305 -fwhm 5 -per-run -fsd bold I attach exemplary register log file from rs-fMRI subject registration (BBRsum=0.9704). This subject's task-based fMRI BBR-sum was 0.55. My question is - what may be the cause of such a discrepancy between registration of two functional runs taken one by one (the rs-fMRI preceded the task based)? Does anyone have an idea how to fix the problem? Best regards, Patrycja _______________________________________________ Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu <mailto:Freesurfer@nmr.mgh.harvard.edu> https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer <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 <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 <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
Freesurfer mailing list Freesurfer@nmr.mgh.harvard.edu https://mail.nmr.mgh.harvard.edu/mailman/listinfo/freesurfer
freesurfer@nmr.mgh.harvard.edu
-
Douglas Greve -
Douglas N. Greve
-
Patrycja Naumczyk