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 <[email protected]> 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 >
