Summary of what happened:
I recently encountered a bug in fmriprep where boldref registration ends in antsAI seg fault. It appears that the DerivativesDataSink node caused data corruption when copying bold_average as hmc_boldref. I believe the root cause is that the NIfTI file it’s trying to copy is in big-endian int16 format. DerivativesDataSink tries to coerce the data volume to float32 and writes the data volume in machine native little-endian format. However, it reuses the original header, only updating the datatype field in the header. In this case, it results in a big-endian header with a little-endian data volume, causing the alignment to fail.
I have already filed a bug in niworkflow DerivativesDataSink inconsistent byte order · Issue #1029 · nipreps/niworkflows · GitHub. I’m also happy to contribute a patch if the maintainer let me if we should keep the byte-order of the header or make the header follow native byte order.
Command used (and if a helper script was used, a link to the helper script or the command generated):
Running standard fmriprep without fs recon-all
Version:
fmriprep 25.2.3 container
Environment (Docker, Singularity / Apptainer, custom installation):
Singularity built from docker image.
Data formatted according to a validatable standard? Please provide the output of the validator:
The dataset is valid and from OpenNeuro
https://openneuro.org/datasets/ds000258/versions/1.0.1