Error in receiving CT studies only


There is something wrong with the DICOM files generated by your CT modality:

I1117 20:38:59.248891 main.cpp:298] Incoming Store request from AET REMOTEAE1 on IP, calling AET ORTHANC
W: Found element (0029,1140) with VR UN and undefined length, reading a sequence with transfer syntax LittleEndianImplicit (CP-246)
W: DcmItem: Length of element (0029,0010) is odd
W: DcmItem: Length of element (0204,fc04) is odd
W: DIMSE Warning: (REMOTEAE1,ORTHANC): DIMSE receiveDataSetInMemory: dset->read() Failed (Virtual Memory exhausted)
E1117 20:38:59.252270 StoreScp.cpp:305] Store SCP Failed: DIMSE Failed to receive message

The “0029” prefix indicates a private tag that is unknown to Orthanc, and consequently whose length cannot be determined by guess.

The solution is probably to add a declaration of this tag into the “Dictionary” configuration of Orthanc. This tag is probably a sequence (“SQ” value representation), as similar questions in other forums related to other software indicate, for instance:

If you need further help, you should provide us with a sample DICOM file, and carefully read the following FAQ about proprietary software:



Dear Sébastien ,

First, thank you for the prompt response and pointing me to the direction to correct the issue. I did add following private tags per your recommendation into the “Dictionary” configuration of Orthanc. However, it did not correct the issue. I’m sure I’m doing something not correct. Could you kindly look if I’m doing something incorrectly.

Please note I have uploaded updated Verbose file and sample Dicom files.

Sequence 1 has 10 sub items under 0029,1140. However, Sequence 2 have 5 sub items under 0029,1140.

“Dictionary” : {
“0029,0010” : [ “LO”, “SIEMENS CSA HEADER”, 1, 1, “SIEMENS Private Tag” ],

“0029,0011” : [ “LO”, “SIEMENS MEDCOM HEADER”, 1, 1, “SIEMENS Private Tag” ],
“0029,1008” : [ “CS”, “SOM 5”, 1, 1, “SIEMENS Private Tag” ],
“0029,1009” : [ “LO”, “VA 10A”, 1, 1, “SIEMENS Private Tag” ],
“0029,1010” : [ “OB”, “SOME NUMBER”, 1, 1, “SIEMENS Private Tag” ],
“0029,1131” : [ “LO”, “SOME NUMBER 1”, 1, 1, “SIEMENS Private Tag” ],
“0029,1132” : [ “UL”, “SOME NUMBER 2”, 1, 1, “SIEMENS Private Tag” ],
“0029,1133” : [ “UL”, “SOME NUMBER 3”, 1, 1, “SIEMENS Private Tag” ],
“0029,1134” : [ “CS”, “SOME NUMBER 4”, 1, 1, “SIEMENS Private Tag” ],
// I tried multiple variation on min and max multiplicity
“0029,1140” : [ “SQ”, “SOME NUMBER 5”, 1, 10, “SIEMENS Private Tag” ],
“0029,1141” : [ “CS”, “SOME NUMBER 6”, 1, 1, “SIEMENS Private Tag” ],
“0029,1142” : [ “LO”, “SOME NUMBER 7”, 1, 1, “SIEMENS Private Tag” ],
“0029,1143” : [ “LO”, “SOME NUMBER 8”, 1, 1, “SIEMENS Private Tag” ],
“0029,1144” : [ “OB”, “SOME NUMBER 9”, 1, 1, “SIEMENS Private Tag” ]

Truly appreciate your assistance!

Best regards,
Rick. (862 KB)

Verbose2.txt (158 KB)


The sample DICOM files you sent cannot be used to reproduce your issue, as they are already encoded using the “Little Endian Explicit” transfer encoding. This can be seen e.g. by running “dcm2xml” on your files, and inspecting the “data-set” header:

$ dcm2xml 100001.dcm | grep data-set

“Little Endian Explicit” means that the DICOM instances contain the value representation (VR) of each individual tag. For more information:

The original logs you provided indicate that your modality sent DICOM files under the “Little Endian Implicit” transfer syntax, which means that the VR was unknown, and it is in this case that Orthanc must use the “Dictionary” option. If the files are already sent under “Little Endian Explicit”, there is no used for Orthanc to check the “Dictionary” option for parsing the files, as the file already contains the value representations.

Summarizing, either you provide sample DICOM files encoded using “Little Endian Implicit” transfer syntax, or you configure your modality to avoid “Little Endian Implicit” (e.g. “Little Endian Explicit”, although this configuration might not be possible with your modality).