After enabling multiframe (or, more accurately, turning off multiframe conversion) at the scanner (Siemens XA30), we are now getting errors - but only for multi slice reformatted data from the 3D T1 MPRAGE acquisition (a series created using the “parallel ranges” tool in MR view).
orthanc_1 | 2023-04-24T20:37:46.935746761Z E0424 20:37:46.935006 StoreScp.cpp:273] Store SCP Failed: DIMSE Failed to receive message
We get a more detailed dcmtk error message if we send to our Mercure router, which also uses dcmtk under the hood:
DcmItem: Parse error while parsing element (fffe,e000)
DIMSE Warning: (AWP1671091,mic-dicom-router): DIMSE receiveDataSetInMemory: dset->read() Failed (Invalid tag)
Store SCP Failed: 0006:020d DIMSE Failed to receive message
DIMSE failure (aborting association): 0006:020d DIMSE Failed to receive message
Osirix MD also throws a ‘DIMSE’ error. I think Osirix also uses dcmtk under the hood (Horos does, so Osirix probably still does).
Commercial dicom router “Compass” does not have a problem receiving these series.
We are facing the same problem and it is very unlikely that Siemens is willing or able to help. The problem is that this error aborts the complete transfer, meaning if you send a study and it contains one of the faulty series the entire transfer is aborted and the series coming later are not transferred. We could live with those faulty series being ignored and sent to the void but the aborting of the entire transfer is a problem.
Is there any way to instruct/configure Orthanc to ignore errors in the DCMTK parsing and just ignore those errors instead of aborting the entire transfer?
We could certainly consider adding some “tolerance” for ill-conditioned modalities, but we still need a way to reproduce the issue without having an access to a Siemens XA30.
Please provide sample DICOM files together with command-line instructions with free and open-source like dcm4che/DCMTK/GDCM/pynetdicom/… that would allow us to reproduce the behavior of the Siemens XA30.
I have further looked into this and there must be something going wrong during the online conversion of the DICOMs before sending. Siemens is basically modifying all DICOMs directly before the export (to adjust for various possible export settings, e.g. single frame vs. multi frame etc.). When I dump the DICOM to the hard drive (without the online conversion) I can happily import it to Orthanc using dcmtk from the command line, the same series fails when going through the Siemens Online Export. This of course makes it impossible to send you example DICOMs as the problem only occurs when the DICOMs are sent directly from the scanner.
The only next step I see is to add a lot more debug output to Orthanc, recompile and then try to pinpoint at which DICOM tag it is failing and what the cause might be. Will see if I can find some time for this next week.
We have the same problem, but not using Orthanc here; I would guess it is something between Siemens DICOM network transfer and the receiving storescp at the other end.
We have a VidaFit with syngo XA50, and the plain storescp from dcmtk (from Ubuntu 22.04 repository). And I agree, it is hard to produce example data if they are not “created”.
I will file a ticket at Siemens Teamplay platform, but am not very optimistic that this is solved in the near future.
Maybe discussing this with OFFIS DCMTK is more promising; maybe the Orthanc community/forum can help here?
The Orthanc core team doesn’t have a direct communication channel with the OFFIS DCMTK team. I would suggest to report the issue directly onto their official discussion forum: https://forum.dcmtk.org/
I’ve made another interesting experience.
I’m talking about two DICOM images (Scout and T1MPRAGE), both were successfully transferred from the MR device (Siemens VidaFit XA50) to our storescp DICOM receiver. Transfer was set to Enhanced/Multiframe so the transferred file is a single file per image volume with 128 frames (Scout) and 224 frames (T1MPRAGE).
If I try to import both images into an Orthanc PACS using the UI Upload function,
the Scout is imported successfully (single file, single instance, 128 frames),
the T1MPRAGE is failing.
The browser console gives the following error code, 413 Request Entity Too Large.
If I use an inhouse built DICOM Send Tool, I can push both files to the Orthanc PACS. But most probably our DICOM Send Tool splits the multiframe file into single frames/instances, and sending those to the Orthanc PACS. The Orthanc shows the T1MPRAGE as image with 224 instances (each frames=1).
But I would guess, Orthanc should be able to handle multiframe as multiframe, and this might be an issue here? I can offer the two example files, maybe via PM and owncloud link?
No, we have not! We have a couple workarounds when this occurs - it mostly occurs with “reconstructed” series - one of which is sending problematic series to one of our older (non-XA30) modalities and then re-sending it from there. It’s really annoying.