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.naumc...@gmail.com <mailto:patrycja.naumc...@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

_______________________________________________
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.

Reply via email to