Introduction to the a simplified 'toy-DICOM' file format IV (Further development: the Value Representation)

When defining our toy-DICOM format we used the following concepts:

• The meta header
• The header
• We had different data types
• Among the data files the image format had special importance as we are defining a standard for image communication.
• We introduced certain data types: In the meta header we had a data of two possible values called LittleEndian and BigEndian, we defined the PN, the UID.
• Every data type had a well defined format: either by definition or by means of a data descriptor giving the number or bytes or words.

 
The way we had to interpret our data was implicitly given: A certain data type with the data length descriptor seemed to be sufficient for the interpretation of the specific parts of the file. In the real DICOM the data types and the way of interpreting the different data types are two different concepts. To make this clear let us introduce for our toy DICOM format the following two “Value representations”. For instance one can imagine two different data types and two different Value representations in a way that all the four combinations make sense.
For instance in our DICOM file besides the PN we may introduce a PMN (patient maiden name) and RM (remark data type). We have many different data types now. Let us see two compatible VR’s (value representations):

LO Called: Long String	A character string that may be padded with leading and/or trailing spaces.	Default Character Repertoire	64 character maximum
LT Called: Long Text	A character string that may contain one or more paragraphs. It may contain the Graphic Character set and the Control Characters, CR,LF, FF, and ESC.	Default Character Repertoire	10240 character maximum
W	Double bytes to be interpreted as given in the Meta Header	Arbitrary pairs of bytes	No limitation

 
True: all the four combination will work. In the following toy-DICOM file we have all kind of data and VR so far introduced. Note that from now on we will not look at bytes but the corresponding values corresponding to the VR’s defined.

 

Meta Header:

LittleEndian

Header:

PN LO 11: Aeeeeeeoooo
PMN LT 48: Pacskurk Maria Olga Viola Henreitta von Comorra
RM LO 31: This a VIP patient of type 234.
UID LT 2: 33

Image W 25:

0, 0, 0, 0, 0
1, 1, 1, 1, 1
10, 10, 10, 10, 10
11, 11, 11, 11, 11
0, 0, 0, 0, 0

End of the toy-DICOM file.

Note that for the PN, PMN, RM, and the UID we could have chosen the VR another way too. Also, it must be clear that certain data types and certain VR’s may be incompatible. Also, note that in the case of our first example file the value representations were implicitly given. In theory the definition of the data type itself may include one practical VR. We have just learned that in DICOM the Data type and the actual way of the interpretation are separate concepts.

One final remark and another example: DICOM allows the implicit VR, that is the data types have their own default VR. The DICOM meta header should contain the information telling if in the file there will or will not be VR’s given.

I let the user interpret the following two versions of the toy-DICOM file given above:

First possibility (The only difference compared to the file above is that the information about the existence of the VR’s is given:

 
1.

Meta Header:

LittleEndian
Explicit

Header:

PN LO 11: Aeeeeeeoooo
PMN LT 48: Pacskurk Maria Olga Viola Henreitta von Comorra
RM LO 31: This a VIP patient of type 234.
UID LT 2: 33

Image W 25:

0, 0, 0, 0, 0
1, 1, 1, 1, 1
10, 10, 10, 10, 10
11, 11, 11, 11, 11
0, 0, 0, 0, 0

End of the toy-DICOM file.

2.
Meta Header:

LittleEndian
Implicit

Header:

PN 11: Aeeeeeeoooo
PMN 48: Pacskurk Maria Olga Viola Henreitta von Comorra
RM 31: This a VIP patient of type 234.
UID 2: 33

Image 25:

0, 0, 0, 0, 0
1, 1, 1, 1, 1
10, 10, 10, 10, 10
11, 11, 11, 11, 11
0, 0, 0, 0, 0

End of the toy-DICOM file.

 

---