Handling of EVR_xs

[bkuemmer]

Hello there,

we recently stumbled upon implicit little endian files where the value for SmallestImagePixelValue was decoded "wrong" when reading the file with dcmtk: The file has a PixelRepresentation of 1, so the SmallestImagePixelValue should be read as signed short, but dcmtk (3.5.2) seems to always read EVR_xs values as unsigned short.

Wouldn't it be nice if dcmtk handled these EVR_xs tags "correctly" when possible?

Thanks
Bernd

[Marco Eichelberg]

EVR_xs is indeed handled as EVR_US inside the toolkit. While in theory it would be possible to add a special class to the toolkit that would manage such context-dependent value representations, we don't think that it is worthwhile for a number of reasons:

• With EVR_xs, the interpretation (value representation) of the attribute depends on the value of another attribute. What happens if you are constructing or modifying a dataset in memory, and somebody changes the value of Pixel Representation?
• Smallest Image Pixel Value and Largest Image Pixel Value are of little use - the attributes are optional, often absent, and when present, their value is often incorrect. So you cannot rely on these values anyway.
• There are a number of other xs (US/SS) attributes where it is not always easy to determine what the correct VR should be.

[bkuemmer]

OK, thanks for your comments. We are now handling this case ourselves.

Cheers
Bernd