CompCor contours misaligned with reference BOLD image

[effigies]

Unknown as yet whether this is just a visualization issue or if the misalignment shows bad masks that infect results.

DS000001 / sub-02

[oesteban]

This looks to me as a potential duplicate of #703. I've edited your initial post to clarify dataset and subject.

[oesteban]

Running 1.0.0-rc4 on this one. We'll see if it replicates.

[effigies]

@oesteban Did this finish?

[oesteban]

Ok, I can confirm this is still happening with 1.0.0-rc4. Same aCompCor plots.

[oesteban]

This is not a visualization issue. The overlay (aCompCor mask) is correct and the BOLD average is displaced.

[oesteban]

@effigies WDYT about the following hypothesis.

The command we use to convert from mat to itk is:

c3d_affine_tool \
    -ref work/fmriprep_wf/single_subject_02_wf/anat_preproc_wf/skullstrip_ants_wf/t1_skull_strip/highres001_N4Corrected0.nii.gz \
    -src work/fmriprep_wf/single_subject_02_wf/func_preproc_task_balloonanalogrisktask_run_03_wf/nonlinear_sdc_wf/skullstrip_bold_wf/apply_mask/ants_susceptibility_Warped_masked.nii.gz \
 work/fmriprep_wf/single_subject_02_wf/func_preproc_task_balloonanalogrisktask_run_03_wf/bold_reg_wf/bbreg_wf/transformer/transform.mat \
    -fsl2ras -oitk (...)/fsl2itk_fwd/affine.txt

While this is fine for the BBR path, the reference image here is in conformed FS' space right? Therefore, we would need first to use that as reference for convert3d and second, prepend the ras2tk transform with FSL before we apply it. Right?

[oesteban]

This might be helpful here: https://gist.github.com/satra/1096274

[effigies]

t1_skull_strip/highres001_N4Corrected0.nii.gz should be in T1w_preproc space, and work/fmriprep_wf/single_subject_02_wf/func_preproc_task_balloonanalogrisktask_run_03_wf/bold_reg_wf/bbreg_wf/transformer/transform.mat should already include the FreeSurfer transform.

[oesteban]

Right. I've also run the workflow with --no-freesurfer and we get the same result. So my hypothesis is incorrect, there's some source of translation elsewhere.

[effigies]

If you're seeing the displacement in fslview or freeview or similar, then you can just start looking at outputs and see when the misalignment happens or gets worse.

[oesteban]

Ok, the BBR transform applied alone but using the ITK version & antsApplyTransform seems to work fine.

[effigies]

Yeah, I've been wondering if #733 is going to end up fixing this. The weirdness of FSL's registration might mean we're getting double translation.

In #733, I'm staying in FreeSurfer's LTA affine space until it's time to convert to ITK.

[oesteban]

I think I've got it. The reference space for transforms from HMC and SDC are different than the reference for BOLD-T1w. I used antsApplyTransform to generate a pre-bbr version including both HMC and SDC and it also looks off by the same traslation.

We need to adjust the center of the image I guess. Will keep digging but I think this might be the problem.

[oesteban]

I may have identified the source of translation:

If I manually transform the first volume of the BOLD dataset with the SDC transform (seems like the first volume is the reference for head motion correction, so identity transform for that part), the resulting "SD corrected" image is:

Volume information for pre-bbr.nii.gz
          type: nii
    dimensions: 64 x 64 x 34
   voxel sizes: 3.1250, 3.1250, 4.0000
          type: FLOAT (3)
           fov: 200.000
           dof: 0
        xstart: -100.0, xend: 100.0
        ystart: -100.0, yend: 100.0
        zstart: -68.0, zend: 68.0
            TR: 0.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 degrees
       nframes: 1
       PhEncDir: UNKNOWN
ras xform present
    xform info: x_r =  -1.0000, y_r =  -0.0000, z_r =   0.0000, c_r =    -2.0685
              : x_a =  -0.0000, y_a =   1.0000, z_a =  -0.0000, c_a =    31.9808
              : x_s =   0.0000, y_s =   0.0000, z_s =   1.0000, c_s =   -38.6506
Orientation   : LAS
Primary Slice Direction: axial

voxel to ras transform:
               -3.1250  -0.0000   0.0000    97.9315
               -0.0000   3.1250  -0.0000   -68.0192
                0.0000   0.0000   4.0000  -106.6506
                0.0000   0.0000   0.0000     1.0000

voxel-to-ras determinant -39.0625

ras to voxel transform:
               -0.3200   0.0000   0.0000    31.3381
               -0.0000   0.3200  -0.0000    21.7661
               -0.0000  -0.0000   0.2500    26.6626
                0.0000   0.0000   0.0000     1.0000

While for the actual reference image used as input for BBR is:

Volume information for ants_susceptibility_Warped_masked.nii.gz
          type: nii
    dimensions: 64 x 64 x 34
   voxel sizes: 3.1250, 3.1250, 4.0000
          type: FLOAT (3)
           fov: 200.000
           dof: 0
        xstart: -100.0, xend: 100.0
        ystart: -100.0, yend: 100.0
        zstart: -68.0, zend: 68.0
            TR: 0.00 msec, TE: 0.00 msec, TI: 0.00 msec, flip angle: 0.00 degrees
       nframes: 1
       PhEncDir: UNKNOWN
ras xform present
    xform info: x_r =  -1.0000, y_r =  -0.0000, z_r =   0.0000, c_r =    -1.0902
              : x_a =  -0.0000, y_a =   1.0000, z_a =  -0.0000, c_a =    -8.8271
              : x_s =   0.0000, y_s =   0.0000, z_s =   1.0000, c_s =    16.1993
Orientation   : LAS
Primary Slice Direction: axial

voxel to ras transform:
               -3.1250  -0.0000   0.0000    98.9098
               -0.0000   3.1250  -0.0000  -108.8271
                0.0000   0.0000   4.0000   -51.8007
                0.0000   0.0000   0.0000     1.0000

voxel-to-ras determinant -39.0625

ras to voxel transform:
               -0.3200   0.0000   0.0000    31.6511
               -0.0000   0.3200  -0.0000    34.8247
               -0.0000  -0.0000   0.2500    12.9502
                0.0000   0.0000   0.0000     1.0000

So we are changing the center coordinates of the xform.

[effigies]

Is ants_susceptibility_Warped_masked.nii.gz not the result of the same process you did manually?

[oesteban]

Nope, I'll trace it back to the node where we mess up the xform.

[effigies]

Ugh. Sorry about this.

[oesteban]

Got it: antsApplyTransforms and its nasty habit of modifying s/qforms

[oesteban]

Working on the consistency of x-forms (I'm not blocked), but this PR will need to wait for #741 and #740 to get merged first.