[RESOLVED] Import_dicom: Dropped fMRI volumes

denizvat · November 13, 2025, 4:11am

Hey Jure,

I believe I am encountering a similar issue reported here: [RESOLVED] Import_dicom not reading all the diffusion data but for fMRI volumes.

Description:

When importing fMRI data random volumes are being dropped. Interestingly, this only occurs for releases >1.0.0 and only for some fMRI runs and not others and in some instances even for T1w images. My workaround at the moment is to use 0.99 or below. I was wondering if it is possible to fix this in the new releases >1.4.0. Below is the specific call that I am using with 1.4.0 and the log DICOM-Report.txt. Thanks again!

Best wishes,

Deniz

Call:

qunex import_dicom \
  --masterinbox="${DATA}/sessions/inbox/MR/" \
  --sessionsfolder="${DATA}/sessions/" \
  --nameformat="(?P<subject_id>.*?)_(?P<session_name>.*)" \
  --check="no" \ # also tried "any"
  --add_json_info="all" \
  --parelements="all"

Logs:

# Generated by QuNex 1.4.0 [QIO] on 2025-11-13_11.21.26.420923
Report for R9999_3TSESS1 (R9999) scanned on 2025-03-24 14:51:52

MR device: SIEMENS|Prisma

  20     2                                 AAHScout      1   [TR    3.15, TE   1.37]   R0011   2025-03-24 14:51:52 
  30     3                         AAHScout_MPR_sag      1   [TR    3.15, TE   1.37]   R0011   2025-03-24 14:51:53 
  70     7                gre_field_mapping_aligned      1   [TR  731.00, TE   7.38]   R0011   2025-03-24 14:56:04 
  80     8                gre_field_mapping_aligned      1   [TR  731.00, TE   7.38]   R0011   2025-03-24 14:56:04 
  90     9                gre_field_mapping_aligned      1   [TR  731.00, TE   7.38]   R0011   2025-03-24 14:56:05 
 130    13                            rfMRI_REST_AP    488   [TR  800.00, TE  37.00]   R0011   2025-03-24 15:01:51 
     WARNING: number of frames in nii does not match dicom information: 271 vs. 488 frames
     WARNING: not enough slices (72) to make a complete volume.
 160    16                            rfMRI_REST_PA    488   [TR  800.00, TE  37.00]   R0011   2025-03-24 15:12:26 
     WARNING: number of frames in nii does not match dicom information: 232 vs. 488 frames
     WARNING: not enough slices (72) to make a complete volume.
 180    18                                  T1w_MPR      1   [TR 2400.00, TE   2.02]   R0011   2025-03-24 15:22:39 
 210    21                                  T2w_SPC      1   [TR 3200.00, TE 564.00]   R0011   2025-03-24 15:31:20 
 280    28                        tfMRI_PVT_RUN1_AP    211   [TR 1000.00, TE  37.00]   R0011   2025-03-24 15:41:25 
 310    31                        tfMRI_PVT_RUN2_AP     44   [TR 1000.00, TE  37.00]   R0011   2025-03-24 15:45:11 
 340    34                        tfMRI_PVT_RUN3_AP    323   [TR 1000.00, TE  37.00]   R0011   2025-03-24 15:53:23 
     WARNING: number of frames in nii does not match dicom information: 284 vs. 323 frames
     WARNING: not enough slices (72) to make a complete volume.
 370    37                        tfMRI_PVT_RUN4_AP    323   [TR 1000.00, TE  37.00]   R0011   2025-03-24 16:00:45 
     WARNING: number of frames in nii does not match dicom information: 112 vs. 323 frames
     WARNING: not enough slices (72) to make a complete volume.

demsarjure · November 13, 2025, 9:51am

Hi Deniz,

This is not really a direct QuNex issue, the warnings are coming from dcm2niix one of the external tools that we use for dicom to nifti conversion.

We currently use dcm2niix from February 2024, I plan to update to the latest (May 2025) with the next release (1.4.1), which is supposed to happen by the end of November. As you can see in the post you linked, the issues in that case were the opposite of yours. In your case importing seems to work with an older version and not with a more recent one, in his case it did not work with an older version of dcm2niix but worked with a newer one. Maybe that will resolve your issues.

Can you perhaps try to convert one of the images by hand with the latest dcm2niix. Or maybe you can upload this session or the problematic image somewhere where I can download it and get to the bottom of this myself.

What you could also try is to set the tool option to a different value (dcm2nii or dicm2nii). Not sure if the latter will work with Octave that is in the container, but it is worth a try.

        --tool (str, default 'auto'):
            What tool to use for the conversion. It can be one of:

            - 'auto' (determine best tool based on heuristics)
            - 'dcm2niix'
            - 'dcm2nii'
            - 'dicm2nii'.

            If set to 'auto', for dicom files the conversion is done using
            dcm2niix, and for PAR/REC files, dicm2nii is used if QuNex is set
            to use Matlab, otherwise also PAR/REC files are converted using
            dcm2niix.

So auto in your case equals dcm2niix.

If you check the data onboarded with an older version, is it actually OK? If it is OK, a workaround would be to onboard with older version and then process with never.

Thanks for reporting this and helping us out with its resolution.

Best, Jure

denizvat · November 15, 2025, 3:13am

Hey Jure,

Thanks a lot for these suggestions! I did some more testing and wanted to share a quick update on what I found.

First, I confirmed that both dcm2niix versions work fine outside of Qunex, so the dcm2niix and DICOMs themselves seem to be fine.

After comparing the import_dicom code between Qunex 0.95.2 (which works for me) and 1.4.0, I suspect the new series-grouping logic in sort_dicom might be the source of the missing sequences/volumes. The updated series_key uses multiple DICOM fields (SeriesNumber, AcquisitionNumber, SeriesInstanceUID, ImageOrientation, etc.), and if any of these are missing or match across runs (which happens with some DICOM data), some sequences get merged or skipped. There are also stricter InstanceNumber checks that could explain the dropped fMRI volumes.

I realised that in the 1.4.0 version there is --existing_structure=False. When I set this to True, then everything imports correctly again, which solves the problem, but also suggests that the issue might be in the new grouping code.

Hope this helps! Thanks again for all your support — Qunex has been great for our workflows.

Best,
Deniz

demsarjure · November 15, 2025, 8:52am

Uf, I forgot about existing_structure, sorry about this . It was me who coded this… This was added for this exact use case.

We found out that it is hard (or impossible) to code a perfect merging logic for DICOMs. The upgrade in grouping logic was coded because the old, more relaxed grouping was not working in some other cases. For backwards compatibility purposes and also becuase the merging logic works fine most of the time, we decided to keep that as the default but allow users to disable it and group DICOMs manually through folders.

Glad this worked!

Best, Jure

denizvat · November 18, 2025, 3:44am

Hey Jure,

Not a problem at all! Thanks for letting me know about the functionality of existing_structure, which I can confirm is working perfectly fine, and will allow us to migrate all calls to =>1.4.0.

Best wishes,

Deniz