Bug #554
closed
When OF/OD is mapped to OB, do we need to consider endianness?
100%
Description
When one of the two global flags dcmEnableOtherFloatStringVRGeneration or dcmEnableOtherDoubleStringVRGeneration are set to OFFalse and their corresponding VR is mapped to OB, do we need to consider endianness (i.e. conditionally swap bytes) because OF and OD consist of 4/8 bytes per value?
Currently, OF and OD are handled the same way as UN and UT.
See DcmVR::getValidEVR() for details.
Files
Updated by Marco Eichelberg over 8 years ago
We only map OF/OD to OB when reading a dataset in LittleEndianImplicit, i.e. in this case the OF/OD data will be kept in little endian byte order (just like we would do if we were mapping to UN). This could be an issue when we try to convert back to the real VR (dcmconv --convert-un) and byte order is big endian. In that case we need to handle the special case that the OB element - just like a UN element - is in little endian, not in big endian.
Updated by Marco Eichelberg over 8 years ago
My last comment was not correct. In fact the conversion of post-1993 VRs to OB happens while writing a dataset, not while reading. There was indeed a bug that can be reproduced by converting the attached DICOM sample file to explicit VR with dcmconv, using the --disable-new-vr option. When converting to explicit VR little endian (+te) the OB elements have the correct value, when converting to big endian (+tb), their value is wrong (OF/OD values swapped to big endian byte order).
Updated by Marco Eichelberg over 8 years ago
- Status changed from New to Closed
- Assignee set to Marco Eichelberg
- % Done changed from 0 to 100
Closed by commit 5ecea10.
Updated by