Bevezetés a játék-Dicom fájlformátumba IV (további bonyolítás: az értékmegjelenítés)

Játék-DICOM fájlunkban a következő fogalmakat használtuk:

1. Meta header
2. header
3. különböző adattípusok
4. a képformátumnak külön jelentősége van, hiszen kép-kommunikációs szabványt dolgozunk ki
5. minden adattípusnak jól definiált formátuma van: vagy definíció, vagy adatleírók (deszkriptorok) alapján, mely a számot, bájtot vagy szót adja meg

 
A fájl értelmezése implicit módon volt megadva: egy bizonyos adattípus az adathossz leírásával elég volt arra, hogy a fájl különböző részeit értelmezzük. Egy valós DICOM fájlban az adattípusok és az adattípusok értelmezése két egészen külön dolog. Hogy ezt tisztázzuk, játék-DICOM formátumunkat bővítsük két újabb "érték-reprezentációval". Például elképzelhetünk két különböző adattípust és két különböző "érték-reprezentációt", melynél mind a négy kombinációnak érelme van. Például a DICOM fájlunkban a PN szimbólum mellett bevezethetjük a PMN (Patient Maiden Name - leánykori név) és az RM (Remark Data - megjegyzés). Most többfajta adattípusunk van, nézzünk két kompatibilis érték-reprezentációt (VR).

LO neve: Long String	karaktersztring, mely előtt/mögött szóköz karakterek lehetnek	alapbeállítás karakterkészlet	64 karakter maximum
LT neve: Long Text	karaktersztring, mely több bekezdést tartalmazhat. Tartalmazhatja a Graphic Character karakterkódot és kontroll karaktereket, mégpedig: CR,LF, FF, és ESC.	alapbeállítás karakterkészlet	10240 karakter maximum
W	dupla bájt, mely metaheaderként értelmezendő	Arbitrary pairs of bytes	Nincs megkötés

 
Igaz, hogy mind a négy kombináció működhet. A következő játék-DICOM fájlban mindenféle VR és adat megtalálható, amit eddig definiáltunk. Innentől nem bájtokat hanem a definiált VR-ek szerinti értékeket nézzük.

''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.''

Vegyük észre, hogy a PN, PMN? RM és UID esetében megválaszthattuk volna a VR rendszert másképpen is. Az is egyértelmű, hogy néhány adattípus és VR nem kompatibilis. Az is igaz,hogy első példánkban a VR definíciókat explicit megadtuk. Elméletben az adattípus definíciója maga tartalmazhat egy VR-t. Megtanultuk, hogy a DICOM adattípus és az értelmezés módja külön-külön fogalmak.

Egy végső megjegyzés és még egy példa: a DICOM formátum megengedi az implicit VR-t azaz bizonyos adattípusokra van alapértelmezett VR. A DICOM metaheadernek tartalmaznia kell az információt, hogy lesznek-e VR-ek a fájlban.

Értelmezzük az alábbit két játék-DICOM fájl verziót. Az első lehetőség: (a különbség a fentihez képest csak annyi, hogy meg van adva, hogy a VR-ek léteznek-e )

''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. ''

 

---