Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

normalizing/conforming input data #260

Closed
chrisgorgo opened this issue Dec 9, 2016 · 3 comments
Closed

normalizing/conforming input data #260

chrisgorgo opened this issue Dec 9, 2016 · 3 comments
Milestone

Comments

@chrisgorgo
Copy link
Contributor

To make sure data fed to FMRIPREP from different datasets is looking as similar as possible we are currently reorienting anatomical images to RAS. However, there is more that can be done:

  • make sure that the information in the header concerning data type and affine transformation (sform, qform) are correct; fix if possible
  • apply the same procedure to all input data (_bold, _sbref, fieldmaps etc.)

Problems:

  • If we change the orientation of input files we need to adjust the phase encoding direction as well.
  • Applying those fixes to big 4D _bold files will create an (almost) identical copy and waste a lot of disk space
@oesteban
Copy link
Member

Possible duplicate of #581, #388, #433 ?

@oesteban oesteban marked this as a duplicate of #581 Jul 17, 2017
@oesteban oesteban modified the milestone: 1.0.0 Jul 17, 2017
@effigies
Copy link
Member

Copying in part of #573 (comment):

To address further issues raised in #260:

  • If we change the orientation of input files we need to adjust the phase encoding direction as well.

NIfTI does have a phase_dim header entry. We could update the header, and use that later.

  • Applying those fixes to big 4D _bold files will create an (almost) identical copy and waste a lot of disk space

True, and adding the PE direction header entry will cause the same issue, if we don't already need to create a new file.

I haven't tried this out yet, but we could consider creating a filename.hdr.gz with a data offset matching the original header, and symlink to the original file with filename.img.gz. Assuming this works, we couldn't reorient, but we could update the headers without copying the data.

@oesteban
Copy link
Member

Superseded by new issue (link above)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants