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.

a bájt	speciális szimbólum	olvasható formátum	példa egy egységre hexa formában	a jelentés
00	LittleEndian	a szavakat jobbról balra kell olvasni, a “LittleEndian” szó erre utal	10 2a	16*256+42=4096+42= 4138
FF	BigEndian	a szavakat balról jobbra kell olvasni	10 2a	16+256*42=10752
01	PN	A páciensnév kezdete, a következő bájt, a páciens nevében szereplő karakterek számát adja meg	010B 41656565656565 6F6F6F6F0300010001	01 megmondja, hogy a páciensnév következik, 0B azt, hogy a név hány karakterből áll: 0B=11, a további 11 bájt interpretációja a Latin-2 karaktertáblázat szerint nyer értelmet. Mivel a Latin-2 41=A, 65=e, 6F=o, páciens 11 karakteres neve „Aeeeeeeoooo”. A következő bájttal (03) nem törődünk, mert tudjuk, hogy a név csak 10 karaktert tartalmaz.
02	UID	A fájl azonosítója. Ne feledjük, hogy a következő bájt az UID karaktereinek számát írja le.	02020303	02: UID jön, 02: két bájtos lesz: 0303. Azaz: 33.
03	Kép	Itt kezdődik a fájl azon része, mely a képet tartalmazza.A következő szám A9=25 a képeink mindig is 5x5 pixelt tartalmaznak	03A9 0000 0000 0000 0000 0000 0001 0001 0010 0010 0010 000A 000A 000A 000A 000A 000B 000B 000B 000B 000B	03: a kép következik A9 jelentése 25, azaz a kép 25 pixelt tartalmaz, melyek pixelértékeit szavakban adjuk 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
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:

Ekkor a 33-as azonosítójú DICOM fájlunk, mely Aeeeeeeoooo nevű betegünkhöz tartozik a következő képet tárolja:

 
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.

 

---