DICOM file OK on Intel but not PPC (Missing byte swapping)
Cross-platform DICOM implementation
Brought to you by:
malat
We have a DICOM file that does not work with our app (via GDCM) but does with other DICOM viewers.
On Intel, the image appears correctly; on PowerPC the voxel colours are all wrong. I ran gdcmdump on both machines and compared the output. Some values are swapped, ex:
(0019,1012) ?? (SL) 0\0\217841663 # 12,3 TablePositionOrigin
(0019,1013) ?? (SL) 0\0\217841663 # 12,3 ImaAbsTablePosition
(0019,1012) ?? (SL) 0\0\-1268 # 12,3 TablePositionOrigin
(0019,1013) ?? (SL) 0\0\-1268 # 12,3 ImaAbsTablePosition
217841663 is the byte swapped representation of -1268.
I cannot share the DICOM file in this public bug. Contact me privately.
I have a 2nd DICOM file that is probably the same problem. gdcmdump again reveals byte swapped values. But not for the same fields...
$ svn ci -m"BUG: 3043115 Implement VRToTag function require on PPC architecture and implicit file." ~/Perso/gdcm/trunk/Source
Sending Source/DataStructureAndEncodingDefinition/gdcmImplicitDataElement.txx
Sending Source/DataStructureAndEncodingDefinition/gdcmTagToVR.cxx
Sending Source/DataStructureAndEncodingDefinition/gdcmTagToVR.h
Transmitting file data ...
Committed revision 7115.
According to Sean the issue is still present:
...
We finally had a chance to test your fix for bug 3043115 and it's an
improvement but the issue is still there. I could not figure out how to
reopen the bug at sourceforge.
Can you reopen the bug, or tell me how?
Again we used gdcmdump, and can see that the value for "2,1 Largest
Image Pixel Value" is byte swapped. Other values may be swapped too,
but this technique won't reveal this if the value is 0 (as is the case
for "2,1 Smallest Image Pixel Value").
...
$ gdcmdump gdcmData/MR_SIEMENS_forceLoad29-1010_29-1020.dcm| grep Lar
(0028,0107) ?? (US or SS => US) 63239 #
2,1 Largest Image Pixel Value
[master b3fbfbb] Adding support for dual VR
2 files changed, 27 insertions(+), 7 deletions(-)
Change it too big for this release. I'll have to delay for now.
GDCM 2.0.17 needs to be delivered this week.
Mathieu, no problem if it waits for the next release. Is the code in some branch that we could test?
I just retested in 2.2.1, and this is not fixed.