DICOM series with instances?

[ogenos]

I have a series of 256 slices that I want all grouped into a single dicom output that should have "Number of Frames = 256". For some reason, the slices are grouped consecutively and automatically (from the scanner) into three subseries (or instances) of 100, 100, and 56 slices as if some modulo 100 on the "Number of Frames" is in effect. My guess is that a dicom attribute is not set properly and I would appreciate any help with figuring the responsible attribute(s). The highlights in the attached images may clarify the situation. The first image is from the scanner reconstruction. Other images are from loading the dicom enhanced file (output from the scanner) onto MicroDicom (free dicom viewer) and show three subseries' attributes.

[David Clunie]

Can you share the object(s)? That way we can look at the Attribute Values.

[ogenos]

https://drive.google.com/file/d/14tBFrE_KsUkUJDWoQH8XJjltjFMTCRSp/view?usp=drive_link

[Jouke.Numan]

Hi Ogenos,

I've looked at the files you shared, the zip file contains 4 files in two series.

First series has 3 images containing 100, 100 and 56 frames as you indicated. 

Second series has 1 image containing 256 frames.

Notable differences between two series:

Tag                             3 images series                                       1 image series                                       Name

(0008,0008) CS [ORIGINAL\PRIMARY\OTHER\NONE]       [ORIGINAL\PRIMARY\M\NONE]     #  28, 4 ImageType
(0008,103e) LO [zte_ak]                                                            [petra_ak]                               #   8, 1 SeriesDescription

(0008,9206) CS [DISTORTED]                                                  [MAGNITUDE]                              #  10, 1 ComplexImageComponent

(0018,1030) LO [zte_ak]                                                            [petra_ak]                               #   8, 1 ProtocolName

(0018,9005) SH [zte33d1_8000]                                              [Petra3d1]                               #   8, 1 PulseSequenceName

(0020,0011) IS [2]                                                                       [3]                                      #   2, 1 SeriesNumber

(0020,0012)      (Absent)                                                            [1]                                      #   2, 1 AcquisitionNumber

(0020,0013) IS [1],[2], [3] (across images)                              [1]                                      #   2, 1 InstanceNumber

(0020,0105) IS [0]                                                                        [1]                                      #   2, 1 NumberOfTemporalPositions

(0028,0008) IS [100], [100], [56]  (across images)                 [256]                                    #   4, 1 NumberOfFrames

There are more changes, but these seem in line with the differences in frame count.

I suggest you look into the differences in Protocol used on acquisition.

Regards, Jouke

Op donderdag 19 maart 2026 om 20:01:10 UTC+1 schreef ogenos:

[David Clunie]

Of note, the three multi-frame instances in the first series do not seem to have any "Concatenation" attributes within them, to indicate that this is a single reconstruction split into multiple images but constituting one "Concatenation Source" - see "https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.7.6.16.html#sect_C.7.6.16.1.3"

[Wim Corbijn]

No access to the dataset but expect that the instances share same dimension information.

With that it becomes one set of 256 images, just for size split in 3 instances. 

[Peter Chripunow]

Could you elaborate your involvement in the mentioned scanner and reiterate on your scenario, please?

When you say you have 1 series of 256 slices, are you importing those into that scanner, or are you looking at the patient browser at this scanner after a scan?
At which point does the scanner produce the output?
Do you know how the conversion at this scanner works?

How sure are you that the sw in the scanner works as intended?

For potential other reasons than the arbitrary modulo 100 split you can try comparing the 2 100 multi-frame objects.
Apart from any expected differences, like Image Position (Patient) which I hope is indeed different every time, you might find your culprit.

Then again, maybe the modulo 100 is just how it works at this scanner, like to avoid mega-sized objects, and it's either a matter of concatenation or understanding them as "new" ranges from the volume.

[ogenos]

The scanner has a modularized pipe for reconstruction of images from the data measured. The user is given the possibility to modify modules of the reconstruction pipe on a remote computer using a provided (from the manufacturer of the scanner) compiler. The modified modules are compiled as a .dll library which is then copied into the appropriate directory on the scanner and read by the reconstruction engine while data are collected and when acquisition finishes the reconstruction is output as DICOM files on the scanner.  

Now, when modifying the modules the user is provided a limited number of DICOM parameters or attributes that he can modify to let the reconstruction engine know how to organize the output. This limited set of DICOM attributes is called MiniHeader parameters (see attached).  

In my case, the object created by the modified reconstruction is the same in size as the object created by the unmodified reconstruction, therefore size is not the reason for spitting the series into instances. There must be a DICOM parameter, which I am missing/not setting properly that is responsible. I was hoping to get it figured by someone with more knowledge on the organization of DICOM outputs. 

The strange thing is that this splitting of the series into instances came with the new version of the scanner's OS (XA60). I was using the same set of DICOM attributes on the of scanner's OS (VE11B) and it produced one series (no multiple instances) of 256 slices. Maybe there is something new with DICOMs now?  

[Peter Chripunow]

Alright, I guess we found some issue, at least - Your concern ain't with DICOM, as in DICOM the standard.

Please ignore the keyword "DICOM" in MiniHeader spec, or replace it with "bob".

It appears that a data element encoding style is used - some pseudo-DICOM if you will. And term 'DICOM' is being mis-used, or at least in local context.

This is a pure application concern in the scanner, or any ICE programming.

Therefore, you would have to reach out to the vendor of the scanner or search for any support regarding the MiniHeader or ICE applications.

Maybe, someone here has experience or some opinion on what might be the right tweak in the MiniHeader.

[ogenos]

Vendor doesn't offer direct support to users. I have put this question in the forum of users of this type of scanner but gotten no reply.

  

@ Jouke.Numan:  

miniHeader->set("ComplexImageComponent", "MAGNITUDE");   // made no difference
miniHeader->set("NumberOfFrames", 256); // Still NumberOfFrames reverts to =100 (or 100, or 56) depending on the instance (1,2,3) in the dicom file.

Anyone any idea on the DimensionIndexValues dependency? They are different in the modified versus original versions of dicom files (see attached). 

[ogenos]

I have narrowed down the problem to the Dicom attribute "In Stack Position Number" (see attached). Isn't this number automatically derived from "Slice Position" and "Temporal Ordering" so to say (Dimension Index Pointer Attribute)?

Any direction on what needs to be done is very much appreciated.   

[Wim Corbijn]

Hi Ogenos,

Was able to look into the data, the 3 images span a single volume of 256 slices.

You are correct that the Multiframe information is not correct.

The In Stack Position Number should be running from 1 to 256 and should be a reflection of the Image Position which you can see is nicely increasing per image.

The Dimension Index Values are now incorrectly populated as they are all 1\1\1, which should not be the case.

Frame comments (0020,9158) is giving the actual slice number.

Will see that I trigger the manufacturer.

Regards,

Wim