✨Feature/update pixdim4 for the final *bold outputs

[birajstha]

Fixes

Fixes/Related to #2139 by @sgiavasis

Description

Added a node at the very end just before data-sink to compare and update/match the pixdim4 of the CPAC processed output with the native raw source bold image, as in figure below.

Technical details

Tests

Run this branch and check the final CPAC outputs with following command
for file in *preproc_bold.nii.gz; do echo $file; fslinfo "$file"| grep pixdim4; done

For the outputs below, the value should be 0.8
sub-PA001_ses-V1W1_task-facesmatching_run-1_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-facesmatching_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-poke_run-1_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-poke_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-poke_run-2_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-poke_run-2_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-REST_run-1_desc-preproc_bold.nii.gz
pixdim4 0.800000
sub-PA001_ses-V1W1_task-REST_run-1_space-MNI152NLin2009cAsym_desc-preproc_bold.nii.gz
pixdim4 0.800000

Screenshots

Checklist

• My pull request has a descriptive title (not a vague title like Update index.md).
• My pull request targets the develop branch of the repository.
• My commit messages follow best practices.
• My code follows the established code style of the repository.
• I added tests for the changes I made (if applicable).
• I updated the changelog.
• I added or updated documentation (if applicable).
• I tried running the project locally and verified that there are no visible errors.

Developer Certificate of Origin

Developer Certificate of Origin

Developer Certificate of Origin
Version 1.1

Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
1 Letterman Drive
Suite D4700
San Francisco, CA, 94129

Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.


Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
    have the right to submit it under the open source license
    indicated in the file; or

(b) The contribution is based upon previous work that, to the best
    of my knowledge, is covered under an appropriate open source
    license and I have the right under that license to submit that
    work with modifications, whether created in whole or in part
    by me, under the same open source license (unless I am
    permitted to submit under a different license), as indicated
    in the file; or

(c) The contribution was provided directly to me by some other
    person who certified (a), (b) or (c) and I have not modified
    it.

(d) I understand and agree that this project and the contribution
    are public and that a record of the contribution (including all
    personal information I submit with it, including my sign-off) is
    maintained indefinitely and may be redistributed consistent with
    this project or the open source license(s) involved.

[shnizzedy]

Do we have to worry about

If the dataset has slice time offsets, these will be scaled by the factor newTR/oldTR. This scaling does not apply if you use '-Tslices' in the same 3drefit run.

?

[birajstha]

I am not sure about this one. May be @sgiavasis could advise on this.

[birajstha]

The reason to use AFNI 3drefit instead of nibabel is to change the Time step in 3dinfo as well along with pixdim4

[sgiavasis]

I looked into this further. It seems that it only refers to, and impacts, an AFNI-specific slice-timing setting in the header, which can be checked using 3dinfo -slice_timing.

I ran this on several different datasets and found all of them to be unset:
0.000000|0.000000|0.000000|0.000000|0.000000|0.000000|... etc.

This was both raw data and final outputs, just to make sure C-PAC wasn't clearing this setting as well.

I am pretty sure this is an esoteric and rarely-used setting. As we know, slice-timing offsets and sequences are now contained in BIDS sidecars. But in the interest in keeping up with the theme of this issue and PR, where we maintain the old header information in case a user wants to run post-processing using some non-BIDS-enabled tools, I would still want to avoid inadvertently changing an AFNI header slice-timing offset to something wrong.

So the question remains, how often is this setting actually populated? Again, I think rarely. But if it is, when a tool invoked by C-PAC clobbers the TR value in the pixdim4 header field, is it also clobbering this field? I doubt it, and if we run 3drefit -TR and it scales newTR/oldTR like the 3drefit docs say, it might scale by, let's say, 0.8/1.0 as it would in our recent specific case.

Also curious about -Tslices - can this be used blankly with no parameter, to keep it the same, but prevent the scaling? May be worth manually setting this AFNI header field with the offsets from the sidecar, then trying a few of these permutations out.