Dear developers,
I recently encountered an issue that disrupted processing in one of my batches. I followed the commonly recommended workflow: DICOM import → denoising → hMRI maps creation. The data were acquired on a Terra.X system running software version XA60.
Issue
When using the hMRI toolbox DICOM-import with the hierarchy option , the toolbox generates one NIfTI file per echo within each sequence. However, all these NIfTIs receive identical filenames across the sequence directories. (see below)
The only way to obtain unique NIfTI filenames is to use the option No directory hierarchy, which then includes the sequence number in the filename. Unfortunately, other identifiers—such as study date/time or subject ID—are not unique, so they do not resolve the problem.
As a result, the Denoising module (for T1w, PDw, MTw images) reuses the original filenames with only a prefix added. Since all modalities share identical base filenames, their denoised outputs also share identical names. When the outputs are saved in the same directory, they overwrite each other.
In batch mode with dependencies (denoising → map creation), this leads to missing denoised files and, consequently, failure of the map creation step. This possibly wastes quite a long time of processing, even though it is obvious from the very start of the batch that the execution will fail due to this issue.
This problem may also affect other modules that reuse input filenames when saving outputs to a shared directory.
.
├── kp_afib1_v1g_0032
│ ├── MF12345ab-000140-00001-00001-0.json
│ ├── MF12345ab-000140-00001-00001-0.nii
│ ├── MF12345ab-000140-00001-00002-0.json
│ └── MF12345ab-000140-00001-00002-0.nii
...
├── mtw_kp_mtflash3d_v1s_0p5_0043
│ ├── MF12345ab-000140-00001-00001-0.json
│ ├── MF12345ab-000140-00001-00001-0.nii
│ ├── MF12345ab-000140-00001-00002-0.json
│ ├── MF12345ab-000140-00001-00002-0.nii
...
├── t1w_kp_mtflash3d_v1s_0p5_0035
│ ├── MF12345ab-000140-00001-00001-0.json
│ ├── MF12345ab-000140-00001-00001-0.nii
│ ├── MF12345ab-000140-00001-00002-0.json
│ ├── MF12345ab-000140-00001-00002-0.nii
Hint
The issue did not occur with older datasets. It might be related to software version XA60 or the introduction of enhanced DICOM support.
Suggested solution
Reusing original filenames makes sense for consistency, but a sanity check should be implemented before the denoising step:
If filenames are identical across multiple modalities, the module should either automatically adjust output filenames to prevent overwriting or, at least, raise an error to not stop processing right away and avoid wasting the time of the user.
If filenames are distinct across modalities, no adjustment is needed (input filenames can be re-used)
Implementing such a check would prevent silent overwriting and broken batch dependencies.
Best regards,
Niklas
Dear developers,
I recently encountered an issue that disrupted processing in one of my batches. I followed the commonly recommended workflow: DICOM import → denoising → hMRI maps creation. The data were acquired on a Terra.X system running software version XA60.
Issue
When using the hMRI toolbox DICOM-import with the hierarchy option , the toolbox generates one NIfTI file per echo within each sequence. However, all these NIfTIs receive identical filenames across the sequence directories. (see below)
The only way to obtain unique NIfTI filenames is to use the option
No directory hierarchy, which then includes the sequence number in the filename. Unfortunately, other identifiers—such as study date/time or subject ID—are not unique, so they do not resolve the problem.As a result, the Denoising module (for T1w, PDw, MTw images) reuses the original filenames with only a prefix added. Since all modalities share identical base filenames, their denoised outputs also share identical names. When the outputs are saved in the same directory, they overwrite each other.
In batch mode with dependencies (denoising → map creation), this leads to missing denoised files and, consequently, failure of the map creation step. This possibly wastes quite a long time of processing, even though it is obvious from the very start of the batch that the execution will fail due to this issue.
This problem may also affect other modules that reuse input filenames when saving outputs to a shared directory.
Hint
The issue did not occur with older datasets. It might be related to software version XA60 or the introduction of enhanced DICOM support.
Suggested solution
Reusing original filenames makes sense for consistency, but a sanity check should be implemented before the denoising step:
If filenames are identical across multiple modalities, the module should either automatically adjust output filenames to prevent overwriting or, at least, raise an error to not stop processing right away and avoid wasting the time of the user.
If filenames are distinct across modalities, no adjustment is needed (input filenames can be re-used)
Implementing such a check would prevent silent overwriting and broken batch dependencies.
Best regards,
Niklas