Handling of EVR_xs

All other questions regarding DCMTK

Moderator: Moderator Team

Post Reply
Message
Author
bkuemmer
Posts: 21
Joined: Wed, 2005-05-04, 12:49
Location: Bremen, Germany

Handling of EVR_xs

#1 Post by 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
OFFIS DICOM Team
OFFIS DICOM Team
Posts: 1493
Joined: Tue, 2004-11-02, 17:22
Location: Oldenburg, Germany
Contact:

#2 Post by 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
Posts: 21
Joined: Wed, 2005-05-04, 12:49
Location: Bremen, Germany

#3 Post by bkuemmer »

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

Cheers
Bernd

Post Reply

Who is online

Users browsing this forum: Bing [Bot] and 1 guest