"Adjusting for negative MosaicRefAcqTimes (issue 271)" warning but with normal slice times

Hello, I’m new to the fMRI preprocessing community so hopefully this post has sufficient detail to be answered. I’m attempting to run some resting state BOLD fMRI DICOMs through dcm2niix. These data were acquired either on a Siemens Prisma or Siemens TrioTim scanner. For every single one of my subjects, I get the following warning:

Warning: Adjusting for negative MosaicRefAcqTimes (issue 271).

However, when I looked at my slice times in all of the dicom headers, they are positive. In the dcm2niix -v 1 output, each image series says something like:

Slice timing range appears reasonable (range 0…715, TR=800 ms)

My output images look normal to me, and the JSON files have the correct TR/TE listed. My understanding is that this warning results from motion correction on the scanner generating negative slice time values, but this does not seem to exist, so I’m puzzled as to why I’m getting this warning and if it’s anything to worry about.

Would appreciate any thoughts! thanks.

I suspect this is resolved by this commit in the development branch of dcm2niix.

Assuming you are using a Unix (Linux, macOS) computer, you should be able to build the developmental branch with these commands:

git clone --branch development https://github.com/rordenlab/dcm2niix.git
cd dcm2niix/console

Hi Chris,

Thanks for your quick reply! Unfortunately I’m getting the error below trying to install the development branch. Either way, will there be any issues using nifti files generated via the most recent version (v1.0.20210317)?

elicorn@borel:/gdrive/public/USERS/elicorn/tools> git clone --branch development https://github.com/rordenlab/dcm2niix.git Cloning into 'dcm2niix'... remote: Enumerating objects: 5683, done. remote: Counting objects: 100% (614/614), done. remote: Compressing objects: 100% (280/280), done. remote: Total 5683 (delta 395), reused 454 (delta 293), pack-reused 5069 Receiving objects: 100% (5683/5683), 26.33 MiB | 34.09 MiB/s, done. Resolving deltas: 100% (4073/4073), done. elicorn@borel:/gdrive/public/USERS/elicorn/tools> cd dcm2niix/console elicorn@borel:/gdrive/public/USERS/elicorn/tools/dcm2niix/console> make g++ -s -O3 -I. main_console.cpp nii_foreign.cpp nii_dicom.cpp jpg_0XC3.cpp ujpeg.cpp nifti1_io_core.cpp nii_ortho.cpp nii_dicom_batch.cpp -o dcm2niix -DmyDisableOpenJPEG In file included from nifti1_io_core.h:12:0, from nii_dicom_batch.cpp:29: nifti1.h:489:36: error: expected identifier before numeric constant #define DT_UNKNOWN 0 /* what it says, dude */ ^ nifti1.h:489:36: error: expected ‘}’ before numeric constant nifti1.h:489:36: error: expected unqualified-id before numeric constant In file included from /usr/include/features.h:423:0, from /usr/include/unistd.h:25, from nii_dicom_batch.cpp:10: /usr/include/dirent.h:402:1: error: expected declaration before ‘}’ token __END_DECLS ^ make: *** [makefile:34: all] Error 1

Hmm, can you try once more to see if this commit resolves your issue. If it does not help, it would be interesting to see the output of the following commands. It is curious, as the nifti1.h file is used in many projects so there must be something unusual about your setup to generate a naming conflict.

g++ -v
uname -a

My best guess is this is a false alarm. But without seeing the images and without using the branch that resolves the false alarms, it is hard to be sure. You could also use a different tool like dicm2nii to see if it provides the same values. Unfortunately, Siemens hides slice timing in their proprietary CSA header, and inserts negative values for their motion correction, so we really needed to reverse engineer the format.

Working on dicm2nii, but that commit didn’t work either. I am able to install v1.0.20210317 though. Here’s the output:

elicorn@borel:/gdrive/public/USERS/elicorn/tools/dcm2niix> g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper OFFLOAD_TARGET_NAMES=hsa:nvptx-none Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go --enable-offload-targets=hsa,nvptx-none, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp --disable-libvtv --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 7.5.0 (SUSE Linux)

elicorn@borel:/gdrive/public/USERS/elicorn/tools/dcm2niix> uname -a Linux borel 5.3.18-lp152.78-default #1 SMP Tue Jun 1 14:53:21 UTC 2021 (556d823) x86_64 x86_64 x86_64 GNU/Linux

I can compile the latest dev branch on my local machine, so must be an issue on my end. Will let you know what I find. Any suggestions on what might need to be fixed about the compiler would be helpful though!

Did one image locally with the dev branch of dcm2niix, and with dicm2nii. Slice times in json file are identical to the stable version of dcm2niix.

Great. This resolves your issue. For completeness, the development branch of dcm2niix should now compile on your system. Kudos to Ningfei Li for fixing that issue.

That worked for me!! Thank you all very much.