[Debian-med-packaging] Bug#753809: ginkgocadx and certain dicom files

[Gert Wollny]

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