[Long time user, big fan - thanks for all your efforts]

Ok .. so before you say "I've told you to watch out for anonymous export from Siemens scanners - it messes up the headers and CSA" ... 

I have 20 years of expertise doing this stuff and I know my way around dicom headers, but this one has me stumped. I can't see anything obvious in the dicom headers (or CSAs) that has changed between the "before" and "after" scans but hopefully I am missing something obvious.

(1) ccording to Siemens they have not changed anything on my Prisma in the last 3 weeks but overnight the output behaviour of dcm2niix changed

(2) I am using the same version of dcm2niix before and after the change in behaviour -- "Chris Rorden's dcm2niiX version v1.0.20220720  (JP2:OpenJPEG) (JP-LS:CharLS) GCC5.5.0 x86-64 (64-bit Linux) v1.0.20220720"

Here's what used to work: I export a participant's data from the siemens (VE11C, Prisma) with the transfer - export to offline -tick the anonymous - give an output name (e.g. S20043 or S20063 on the examples attached). This results in a single folder of dicoms with no subdirs (including for example diffusion IMAs and whole brain t1/t2 scans) - this used to be correctly combined into 3D and 4D volumes using dcm2niix v1.0.20220720. 

command used is usually >> dcm2niix -f %s_%p -z y -o outDir inDir

Slice 9 and 57 from a T1 MPRAGE sequence are attached for S20063 so the dicom headers can be inspected (I can upload a full session if needed - let me know) - hopefully this will allow you to interrogate the headers. THIS IS A DATASET THAT WORKS and is correctly recombined.

Slice 9 and 57 from a T1 MPRAGE sequence are attached for S20043, acquired a few days later and with (to the best of my knowledge) no software changes. THIS DATASET DOES NOT WORK - after a few seconds it starts and evidently is processing individual dicoms as separate files e.g. for this diffusion IMA

Convert 1 DICOM as /tmp/S20043a/S20043a_cmrr_mb4_MS_DSI_128_20240521155811_7p (120x120x64x1)

and soon after errors with the likes of:

Convert 1 DICOM as /tmp/S20043a/S20043a_cmrr_mb4_MS_DSI_128_20240521155811_7u (120x120x64x1)
Error: Too many NIFTI images with the name /tmp/S20043a/S20043a_cmrr_mb4_MS_DSI_128_20240521155811_9

I do get a warning at the start that say "Warning: Empty protocol name(s) (0018,1030)" but that is the same for the S20063 data which works.

What I've tried: 

(1) diff'ing the headers and CSAs for obivious differences in working (S20063) and non working (S20043) datasets
(2) running dcm2niix -r to rename incoming dicoms into separate folders first, then running each folder separately - no luck - still eventually get "Error: Too many NIFTI images ..."
(3) other versions of dmc2niix - no luck
(4) ironically, Chris Rorden's dcm2nii :: 4AUGUST2014 (Debian) 64bit BSD License  -- this works (albeit the named outputs obviously differ)
(5) export data from scanner WITHOUT anon setting - works [but I won't upload that here] - this is not an ideal solution for this one side-case at our centre; 99.9 percent of our data are handled using dcmodify to do the anonymisation in a controlled way but just one of our users "needs" it this way .. grrr ]

.. still doesn't explain why it used to work ..

Long message sorry - and hopefully one with an easy answer because I have been dumb - hopefully it shows I've tried to solve this myself and hopefully will help others down the line. 

Thanks for any guidance.

I can not replicate your issue on my computer. I would first ensure you are using the latest stable version:

 https://github.com/rordenlab/dcm2niix/releases/tag/v1.0.20240202

If you are using a Unix computer, you can build your own copy of the development version:

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

cd dcm2niix/console

make

./dcm2niix ....

If all esle fails, send an example of a full dataset that fails to my email

https://sc.edu/study/colleges_schools/artsandsciences/psychology/our_people/directory/rorden_chris.php

I get the same errors with v1.0.20240202  .. both with the download and a locally built version.

Could be some quirk with my debian build I guess. 

I'll move back to manually anonymising the dicom headers with dcmodify before processing - we both have bigger fish to fry.

Thanks for taking a look anyway

Andre'

Happy to provide details if you can share a set where I can replicate the issue. Otherwise, I am glad you found a kludge to deal with this issue. Feel free to contact the Siemens Research Collaboration manager associated with your center - they often have insights into these sorts of issues.