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

[Mathieu Malaterre]

GDCM does handle big endian transfer syntax correctly. The input file
is bogus. A hack has been added in GDCM to handle this:

[release 7e32e2d] Add a fallback for some dataset with invalid group 2 element
 1 file changed, 26 insertions(+)

Using gdcm from current git/release make it possible to cleanup this file:

$ gdcmconv -X 2.dcm 2_explicit.dcm
$ gdcmconv -M 2_explicit.dcm 2_corrected.dcm

The first step is required, since group 2 element are required to be
written using explicit transfer syntax, this allow merging of all
group 2 elements within the header. The second step is required to
return to the original implicit transfer syntax.


Anything written below this is line is totally wrong:


On Thu, Jan 28, 2016 at 10:45 PM, Gert Wollny <gw.fossdev at gmail.com> wrote:
> 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
>