2.5 A DICOM-szabvány .1 Összefoglalás (DICOM) .1 Összefoglalás (DICOM)
2.5.3.4 Bevezetés a játék-Dicom fájlformátumba III
Mielőtt belemerülhetnénk a DICOM sztenderd fájlformátumába, készítsünk egy egyszerűsített változatot csak úgy, saját szórakoztatásunkra. Az előző fejezetben (Bevezetés az alfanumerikus adatok reprezentációjába) megismerkedtünk az adatok bináris reprezentációjával. Felismertük, hogy ha egy hosszú bájtfolyamot kapunk, nem tudjuk értelmezni, mielőtt ismernénk az adatformátumokat. Ha megoldottuk a korábbi feladatokat (Bevezetés a játék-Dicom fájlformátumba I. (Feladatok az olvasónak)) a következő problémákat tudjuk felsorolni:
1. fontos, hogy ismerjük az adattípusokat
2. fontos, hogy ismerjük az adattípusok pontos szerkezetét. a) numerikus adatok esetén tudnunk kell, hogy hány bájt tartozik egy számhoz b)anélkül, hogy tudnánk, melyik irányban nőnek a helyiértékek, nem lehet numerikus értékeket dekódolni
3. ismernünk kell az adattípusok bevezetőkarakterét
4. hasznos lehet, ha tudjuk, hány adat következik egymás után ugyanabból a típusból
A legjobb az volna, ha a kezdő DICOM szakértő maga gondolná át a fenti gondokat, és próbálna egyedül megépíteni játék-Dicom fájlformátumát. Hogy könnyítsünk a feladványon, definiálom azokat az adattípusokat, melyeket ebben a bevezető szakaszban használni kell:
páciens neve
fájl azonosíó
numerikus értékek, melyek szürkeskála-értékeket takarnak, a számértékeket szavak tárolják
A kép (játék DICOM fájlunk egyetlen képet fog tartalmazni, 25 pixellel : 5 sor, 5 oszlop)
Ekkor négy különböző adattípusunk van: a szó, a kép, a páciensnév és a fájl azonosító.
Mielőtt bevezetnénk szimbólumokat a különböző adattípusokra, ne feledkezzünk el a szavak interpretációjáról, amikor numerikus értékeket írunk le, melyek a különböző szürkeskála-értékekhez tartoznak. Praktikus volna privát játék-DICOM fájlunkat egy olyan jellel kezdeni, hogy melyik numerikus interpretációt használjuk. Legyen a 00 bájt annak a jele, hogy jobbról balra növekednek a helyiértékek, és az FF bájt annak, hogy ellenkezőképpen. Megtehetjük, hogy ugyanezt valamilyen szimbolikus módon jelezzük, a 00 lenne a () és FF pedig <, hogy segítsük az emberi befogadást. Tovabbi szabályok előtt jelentsük ki, hogy csak a Latin-2 karakterkódolást használjuk. Felismertük tehát, hogy a DICOM fájlnak lesz egy ún. header (fejléc) része is, mely az egész fájlról tartalmaz információkat. Igen, a header a DICOM fájlnak nagyon fontos része.
Miután ezekben megállapodtunk, jelezzük a páciensnév kezdetét 01-gyel, melynek a humán olvasatra szánt változata a PN. Legyen a bevezető bájtja a fájl azonosítónak 02 és a képnek 03; az olvasható formája pedig UID illetve *. Még egy dologról kell megegyeznünk. Legyen a bevezető szimbólumot követő bájt jelentése az az adott típusú egységek darabszáma (egységek: bájtok a PN és UID esetében, szavak a pixeleknél).
Mielőtt egy mintafájlt adnánk, melyet dekódolni lehet, itt egy táblázat, melyben összefoglaltuk a fentieket.
65 hogy a név hány karakterből áll: 0B=11, a további 11 bájt bájttal (03) nem törődünk, mert tudjuk, hogy a név csak 10 meg. Még nem tudjuk, hogyan értelmezzük a szavakat, hiszen még nem ismerjük a fájl első bájtját
Válasszuk a szokásos módszert, azaz ahogy a decimális számoknál is szoktuk: növekedjenek a helyiértékek jobbról balra. Ennek eredményeképpen a fájl header 00 vagy LittleEndian lesz.
Ekkor a DICOM bájt szintű adatfolyam:
00 01 0B 41 65 65 65 65 65 65 6F 6F 6F 6F 02 02 02 03 03 A9 00 00 00 00 00 00 00 00 00 00 00 01 00 01 00 01 00 01 00 01 00 0A 00 0A 00 0A 00 0A
66
00 0A 00 0B 00 0B 00 0B 00 0B 00 0B 00 00 00 00 00 00
Először fordítsuk le ezt a folyamot olvasható formátumba. A fájl első fele információt szolgáltat a fájl egészéről, ezt "MetaHeader" (meta-fejléc)-nek hívjuk a továbbiakban.
Minden más információt a képen kívül hívjunk Header-nek.
Meta Header:
LittleEndian Header:
PN (páciens név 11 karakter): Aeeeeeeoooo UID (Fájl azonosító 2 karakter): 33
Kép: (Pixel értékek 25 szó, 5x4 pixel):
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
játék DICOM fájl vége
Ha a következő szürkeskála-képünk van:
Szürkeskála-definíció
Ekkor a 33-as azonosítójú DICOM fájlunk, mely Aeeeeeeoooo nevű betegünkhöz tartozik a következő képet tárolja:
31. ábra Szürkeskála-kép
Vegyük észre, hogy a játék-Dicom fájlunk semmilyen információt nem tartalmaz a felvételvalós fizikai mérétéről és orientációjáról.
67 2.5.3.5 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
tartalmazhat. Tartalmazhatja a Graphic Character karakterkódot és kontroll karaktereket, mégpedig:
CR,LF, FF, és ESC. 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
68 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.
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
69 10, 10, 10, 10, 10
11, 11, 11, 11, 11 0, 0, 0, 0, 0
End of the toy-DICOM file. ''