Hi all, I think I found the culprit thanks to the file Karsten provided in the bug report:
The offending tag is (7fe0,0010) OW i.e. the pixel data is encoded in big endian, and in gdcm the code is commented with gdcm-2.6.1/Source/DataStructureAndEncodingDefinition/gdcmVR.cxx:290 // Optimized version for transforming a read VR from DICOM file // into a VRType (does not support OB_OW for instance) so it seems that gdcm doesn't support big endian data, or only sometimes: * I tried dicomtonifti from vtk-dicom, and here the file is read. * I tried gdcmdump and here the file is rejected: "Failed to read: 2.dcm" What also surprises me bit is that neither ITK nor ginkodadx fall back to the dcmtk module, when reading fails with gdcm. AFAIK Aeskulap uses only dcmtk, so no surprise that it accepts the file. Amide via (x)medcon also doesn't read the file, but via dcmtk it works (obviously). Now the question is, does ginkgocadx change the endianess when it is uploading files to it's cloud? Best, Gert
