ESKÉ VYSOKÉ UENÍ TECHNICKÉ V PRAZE Fakulta jaderná a fyzikáln¥ inºenýrská
DIPLOMOVÁ PRÁCE
2010
Pavel Ne²kudla
ESKÉ VYSOKÉ UENÍ TECHNICKÉ V PRAZE Fakulta jaderná a fyzikáln¥ inºenýrská Katedra matematiky
DIPLOMOVÁ PRÁCE
Zpracování dat z MRI Processing of MRI data
Poslucha£:
Pavel Ne²kudla
kolitel:
Ing. Tomá² Oberhuber
Akademický rok:
2009/2010
Na toto místo p°ijde svázat
zadání diplomové práce! originál zadání, v ostatních kopie.
V jednom z výtisk· musí být
estné prohlá²ení Prohla²uji na tomto míst¥, ºe jsem p°edloºenou práci vypracoval samostatn¥ a ºe jsem uvedl ve²kerou pouºitou literaturu.
V Praze dne 2. kv¥tna 2010
............................. Pavel Ne²kudla
Název práce: Zpracování dat z MRI Autor: Pavel Ne²kudla Obor: Inºenýrská informatika / Tvorba softwaru Druh práce: Diplomová práce Vedoucí práce:
Ing. Tomá² Oberhuber. Katedra matematiky, Fakulta jaderná a fyzikáln¥
inºenýrská, eské vysoké u£ení technické v Praze
Abstrakt:
Cílem této práce je navrhnout a naprogramovat základ aplikace, která bude
slouºit pro prohlíºení medicínských dat a pro provád¥ní operací nad t¥mito daty jako jsou r·zné vizualizace, segmentace, apod. Vyvo°ená aplikace umí pracovat se standardním medicínským obrazovým formátem DICOM. Oproti b¥ºn¥ dostupným program·m, které se zam¥°ují zejména na vizualizaci a segmentaci dat, je tento navrºen v první °ad¥ za ú£elem snadné manipulace s na£tenými studiemi, moºnosti sestavovat obrázky studií do r·zných uspo°ádání (pro porovnávání snímk· a pro vytvá°ení prezentací) a moºnosti exportovat výsledky uspo°ádání do obvyklých gra ckých formát· PNG a AVI.
Klí£ová slova: MRI, DICOM, Qt, OpenGL.
Title: Processing of MRI data Author: Pavel Ne²kudla Abstract: The goal of this work is to develop an application framework which will be used to view medical data and to perform some operations on this data such as visualization, segmentation, etc. The created application can open standard medical image format DICOM. Compared to a common available software which is aimed especially at visualization and segmentation of data, this program is focused primarily on the easy manipulation with open medical studies, possibility of building the images of the studies into the various layouts suitable for comparing of images and for creating presentations. The created layouts can be exported to common graphical formats PNG and AVI.
Key words: MRI, DICOM, Qt, OpenGL.
Obsah 1 Úvod
8
2 Magnetická rezonance
10
2.1
Pouºití v medicín¥
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Stru£ná historie MRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.3
Princip MRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.4
Nukleární magnetická rezonance [4] . . . . . . . . . . . . . . . . . . . . . . .
11
2.5
Rekonstrukce obrazu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.6
Za°ízení MRI
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.7
Nevýhody MRI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3 DICOM
10
17
3.1
Souborový formát DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.2
Kontrast a jas obrazových dat . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4 Implementace programu
20
4.1
Srovnání s exitujícími programy . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2
Knihovny a technologie pouºité p°i vývoji aplikace
. . . . . . . . . . . . . .
22
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3
4.4
4.2.1
Qt
4.2.2
OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.3
DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2.4
Cg a Cg Toolkit
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
4.2.5
GLEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.2.6
PLIB
29
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Architektura programu a popis funk£nosti programu
. . . . . . . . . . . . .
29
4.3.1
Gra cké rozhraní . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.3.2
D·leºité komponenty, správci objekt·
. . . . . . . . . . . . . . . . .
31
4.3.3
Import dat
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
4.3.4
Reprezentace obrazových dat v GUI
. . . . . . . . . . . . . . . . . .
32
4.3.5
Animace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
4.3.6
Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
Dokumentace základních t°íd aplikace 4.4.1
Hierarchie t°íd
. . . . . . . . . . . . . . . . . . . . .
33
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6
5 Uºivatelská p°íru£ka programu DICOM Presenter
53
5.1
Instalace v MS Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
53
5.2
První spu²t¥ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
5.3
Na£tení medicínských dat
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
5.4
Pracovní plocha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
5.5
Ovládací panel
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.6
Image
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.7
Animace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
5.8
Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
6 Záv¥r
63
A Sestavení (build) projektu ve Windows
69
A.1
DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
70
A.2
Plib
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.3
Qt
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.4
Seznam staticky linkovaných knihoven projektu DICOM Presenter
. . . . .
73
A.5
Problémy vyskytujicí se p°i spou²t¥ní programu v MS Windows . . . . . . .
74
7
Kapitola 1 Úvod Úkolem této diplomové práce bylo naprogramovat základ aplikace umoº¬ující zobrazování a zpracování dat po°ízených za°ízeními magnetické rezonance. Pro dosaºení tohoto cíle byla stanovena následující osnova díl£ních úkon·:
·
Seznámení se s magnetickou rezonancí (MRI) v medicín¥.
·
Prostudování základ· formátu DICOM a vytipování vhodných knihoven pracujících s tímto formátem pro pouºití v na²em programu.
·
Seznámení se s programováním v prost°edí KDE.
·
Návrh a implementace základu aplikace pro prohlíºení a zpracování dat z MRI.
Podn¥tem pro vznik takové aplikace byla spolupráce katedry matematiky FJFI s pracovi²t¥m radiodiagnostiky a interven£ní radiologie institutu IKEM[1], zejména s tamn¥j²ím expertem v oblasti magnetické rezonance s panem Ing. Jaroslavem Tint¥rou, CSc.. Spole£n¥ s ním jsme postupn¥ navrhovali poºadavky na program, který by m¥l usnadnit prohlíºení snímk· z magnetické rezonance a jehoº základ m¥l být výsledkem mého usílí. Poºadavky byly sm¥rovány zejména na pohodlnost ovládání takového programu pro urychlení £asto vykonávaných £inností s medicínskými daty. V ideálním p°ípad¥ by m¥l na moji práci navázat vývoj p°ídavných modul· umoº¬ující následující funkcionalitu:
·
Import dat Vytvo°it modul, který dokáºe zpracovat soubory DICOM z adresá°e, nebo je i na£te ze sít¥, dále je pak p°euspo°ádá do nových adresá°·, které budou odpovídat jednotlivým pacient·m, modalitám (typ·m snímání) a zkoumanému objektu a soubory n¥jak logicky p°ejmenuje.
·
Zobrazování a Export Dal²í £ástí programu by m¥l být prohlíºe£ DICOM soubor·, který by umoºnil snadnou manipulaci s medicínskými snímky a jejich export do standardních gra ckých formát·, p°ípadn¥ umoºnil tvorbu jednoduchých prezentací.
·
Segmentace a dal²í metody zpracování obrazu Umoºnit tvorbu modul·, které dovedou pracovat s obrazovými daty a vykonávat nad nimi r·zné funkce. Nap°íklad detekci hran, segmentaci a dal²í.
8
Mým úkolem bylo implementovat základ funkcionality bod· 1 a 2. Import dat probíhá prozatím zjednodu²en¥ a neumoº¬uje v²echny varianty, které pan Ing. Tint¥ra v pr·b¥hu spolupráce postupn¥ navrhoval. Já jsem se zam¥°il zejména na druhý bod, který nejvíce vystihoval stanovené zadání práce a zárov¥¬ jsem se p°i návrhu a vývoji aplikace snaºil myslet i na budoucí integraci modul· umoº¬ujících funkcionalitu segmentace a zpracování dat.
9
Kapitola 2 Magnetická rezonance Magnetická rezonance je metoda zaloºené na kvantovém fyzikálním principu, kdy jádra atom· s jaderným spinem umíst¥ná v magnetickém poli dokáºí absorbovat elektromagnetické zá°ení o ur£ité (rezonan£ní) frekvenci a po n¥jakou dobu toto zá°ení vyza°ovat zp¥t do prostoru.
2.1
MRI
Pouºití v medicín¥ je zkratka pro anglický termín Magnetic Resonance Imaging, coº v p°ekladu zna-
mená Medicínské zobrazování magnetickou rezonancí (
MR ). Jedná se o zobrazovací tech-
niku pouºívanou v medicín¥ zejména v diagnóze. V dne²ní dob¥ je to jedna z nejp°esn¥j²ích metod pro zobrazení struktur v lidském t¥le. Bohuºel její pouºití je je²t¥ dnes spí²e okrajové a pouºívá se v¥t²inou aº jako up°es¬ující metoda a to hlavn¥ z d·vodu velkých po°izovacích náklad·. Na rozdíl od CT, které vyuºívá radioaktivní rentgenové zá°ení, MR vyuºívá elektromagnetického zá°ení, u kterého dosud nebyly prokázány ²kodlivé ú£inky. Spole£n¥ s detailností získaných snímk· pak tato vlastnost pasuje magnetickou rezonanci na ²pici dne²ních medicínských zobrazovacích metod. Jedná se v¥t²inou o nejcitliv¥j²í metodu pro diagnostiku patologie m¥kkých tkání - tedy sval·, ²lach, kloub·, mozku, míchy, srdce a cév [2]. MR je zaloºena na principu jaderné magnetické rezonance (NMR) a kv·li tomu se také ze za£átku tato zobrazovací technika nazývala jaderná magnetická rezonance. Slovo jaderná v²ak ve ve°ejnosti vyvolává pocit radioaktivního zá°ení, a tak bylo z názvu odstran¥no.
MR má mnoho r·zných specializací. Jmenujme nap°íklad:
·
fMRI (Functional MRI) Funk£ní magnetická rezonance m¥°í zm¥nu signálu v mozku zp·sobenou zm¥nami nervové aktivity. Tu je moºné detekovat díky zvý²ené pot°eb¥ po kyslíku zapojených mozkových center. Jedná se o takzvaný
level dependent)
·
BOLD (blood-oxygen-
efekt. Dokáºe zobrazovat aº 800 snímk· za vte°inu
MRA (Magnetic resonance angiography) MR angiogra e je technika zobrazující snímky cév pro diagnostikování abnormálního zúºení p°ípadn¥ aneurysma (výdu´
10
na tepn¥, která má v tomto míst¥ vysoké riziko prasknutí).
·
MRS(Magnetic resonance spectroscopy) MR spektroskopie m¥°í r·zné biochemické vlastnosti tkání v lidském t¥le bez nutnosti biopsie (fyzického odb¥ru vzorku). Díky ní je moºné získat informace o metabolismu nádor· (jak nebezpe£ný nádor je), zatímco pomocí MRI je moºné nádor pouze lokalizovat.
2.2
Stru£ná historie MRI
Historie MR sahá do roku 1946, kdy Felix Bloch a Edward Purcell objevili fenomén magneti-cké rezonance [3]. Aº do za£átku 70.tých let se pak NMR pouºívala pro chemickou a fyzikální analýzu molekul. V roce 1971 pak Raymond Damadian ukázal, ºe relaxa£ní doby rezonance v tkáních a nádorech se li²í, £ímº odstartoval my²lenku pomocí MR diagnostikovat nemoci. V roce 1973 byl pak p°edstaven první CT skener uºívající rentgenových paprsk· a tím se ukázalo, ºe nemocnice jsou ochotné utratit velké mnoºství nancí za zobrazovací za°ízení. Od té doby tedy do²lo k velkému rozvoji MRI. V roce 1975 Richard Ernt p°edvedl zobrazování pomocí kódování fáze a frekvence a p°evodu na obraz pomocí Fourierovy transformace. V roce 1977 Peter Mans eld navrhl EPI (Echo-planar) techniku, která se b¥hem dal²ích let vyvinula do podoby, kdy je pomocí ní moºné produkovat snímky s rychlostí aº 30ms na snímek. Lze tedy sledovat struktury v lidkém t¥le v reálném £ase. První snímky z MR se vytvá°ely n¥kolik minut. V roce 1986 se pak £as pro vytvo°ení kvalitního snímku zkrátil p°ibliºn¥ na 5 sekund.
2.3
Princip MRI
Zobrazování pomocí magnetické rezonance se d¥lí na dv¥ £ásti. První z nich je £ist¥ fyzikální (princip magnetické rezonance jaderných nuklid·) a druhá je matematická (získání prostorového obrazu a jeho zpracování). Za£n¥me p°iblíºením fyzikálního principu MR.
2.4
Nukleární magnetická rezonance [4]
Kaºdý proton, neutron a elektron má vlastnost, které se °íká jaderný spin. Spin m·ºe nabývat hodnot, které jsou celo£íselnými násobky hodnoty 1/2. M·ºe být kladný i záporný. Spin protonu si lze p°edstavit jako vektor magnetického momentu, který zp·sobuje, ºe se proton chová jako malý magnet s jiºním a severním pólem. Pokud je tento proton umíst¥n ve vn¥j²ím magnetickém poli, pak se spinový vektor zarovná do sm¥ru tohoto vn¥j²ího pole a to ve dvou moºných stavech. V nízkoenergetickém stavu je orientován ve sm¥ru a ve vysokoenergetickém stavu proti sm¥ru tohoto pole. Dv¥ £ástice s opa£ným spinem mají celkový magnetický moment rovný 0. V MR nás tedy zajímají nepárové jaderné spiny.
ν B
Ve vn¥j²ím magnetickém poli m·ºe £ástice se spinem p°ijmout foton o ur£ité frekvenci (rezonan£ní, Larmorova frekvence), která závisí na velikosti vn¥j²ího magnetického pole
11
a gyromagnetickém pom¥ru
42.58M Hz/T .
γ,
který je konstantní pro kaºdou látku. Pro vodík je
γ =
Vodík je také v¥t²inou prvkem, který nás p°i vy²et°ení magnetickou rezo-
nancí zajímá. Je totiº obsaºen ve vod¥ tvo°ící v¥t²inu hmoty lidského t¥la. P°íjmem energie fotonu p°echází £ástice mezi dv¥ma spinovými stavy. Pokud je £ástice ve stavu s niº²í energií a p°ijme foton, pak p°ejde do stavu s vy²²í energií. Pokud je ve stavu s vy²²í energií pak p°ejde do stavu s niº²í energií. Aby k tomuto efektu do²lo, tak energie fotonu E musí být rovna p°esn¥ energetickému rozdílu obou stav·.
E=h ¯ν = h ¯ γB , h ¯
kde
je Planckova konstanta. Z toho plyne, jak lze p°i konstantním magnetickém poli B
vypo£ítat frekvenci fotonu pro daný prvek. Typicky se tato frekvence v MR pohybuje mezi 15-80 MHz. Ze souboru spin· ve vn¥j²ím magnetickém poli se jedny zarovnají do stavu s niº²í energií (jejich po£et ozna£íme
N +)
a zbylé do stavu s vy²²í energií (N
+ lehce v¥t²í neº pokojové teplot¥ je po£et N
− ), p°i£emº p°i
N −.
Podle Boltzmannovy statistiky totiº platí:
N + /N − = exp(−E/kT ), E
kde
je energie mezi dv¥ma energetickými stavy,
k
je Boltzmannova konstanta a
T
je
teplota v Kelvinech. Výsledný vektor magnetizace ve spinovém souboru je pak úm¥rný rozdílu
(N + − N − ).
Tím pádem je tomuto rozdílu úm¥rná i síla signálu nam¥°ená za°ízením MR. Síla signálu je dále ovlivn¥na p°irozenou £etností izotopu a biologickou £etností m¥°eného prvku. P°irozená £etnost izotopu je pom¥r výskytu daného izotopu prvku v p°írod¥ v·£i ostatním izotop·m. Biologická £etnost je pom¥r výskytu daného prvku oproti zbývajícím prvk·m v lidském t¥le. Sou£et vektor· magnetizace v ur£itém souboru spin· se nazývá sí´ová magnetizace. Sm¥r sí´ové magnetizace a sm¥r externího magnetického pole v rovnováºném stavu je stejný
Z . Vektor magnetizace v rovnováºném M0 , tedy podélná magnetizace MZ = M0 . P°í£né sloºky MX a MY jsou
a to podle pouºívané konvence rovnob¥ºný s osou stavu je ozna£ován
v tuto chvíli nulové. Vystavením spinového systému elektromagnetickému vln¥ní o frekvenci p°íslu²né p°echodu mezi spinovými stavy je moºné m¥nit vektor sí´ové magnetizace. Pokud
MZ = 0. Toho lze docílit takzvaným 90◦ RF impulsem. sloºky MZ do p·vodního rovnováºného stavu MZ = M0 , je
je energie dostatek je moºné u£init Doba, kterou trvá návrat spjata s takzvanou
T 1 relaxa£ní dobou. To je doba, kterou trvá zm¥na podélné magnetizace e. Proces návratu je popsán následující
sm¥rem k jejímu rovnováºnému stavu o faktor rovnicí.
MZ = M0 /(1 − exp(−t/T 1)) Promítnutím vektoru magnetizace do roviny
XY
zjistíme, ºe se stá£í kolem osy
Z
rychlostí p°íslu²né Larmorov¥ frekvenci. Jedná se o takzvanou precesi. Doba popisující návrat p°í£né magnetizace
MXY
do rovnováºného stavu se nazývá
MXY = MXY0 exp(−t/T 2)) 12
T2
relaxa£ní doba.
T2
je vºdy men²í nebo rovna
T 1.
V principu jde tedy o to vybudit precesi vektor· magnetizace, £ehoº lze dosáhnout oscilujícím elektromagnetickým impulsem o frekvenci rovné Larmorov¥ frekvenci (rezonance). Precedující magnetické vektory se následn¥ stá£í po spirále do p·vodní podélné orientace po jistou dobu, po kterou vydávají signál detekovatelný v cívkách kolem zkoumaného objektu. Pro získání informace o struktu°e látky se m¥°í £asy T1 a T2.
2.5
Rekonstrukce obrazu
Pro obrazovou rekonstrukci je pot°eba prostorov¥ lokalizovat zdroj signálu. K tomu jsou pouºity takzvané gradientní cívky, které vytvá°ejí gradientní magnetické pole. Jedná se nap°íklad o lineární gradientní magnetické pole. To zp·sobí nehomogenitu p·vodního pole
B,
ale známými podn¥ty, díky £emuº lze pak ur£it prostorové sou°adnice zdroje signálu.
Díky tomuto poli mají totiº spiny v r·zných pozicích r·znou Larmorovu frekvenci danou roz²í°ením p·vodní Larmorovy rovnice o nový £len
G
p°íslu²ející gradientnímu poli.
E=h ¯ν = h ¯ γ(G + B) Nyní tedy sta£í zkoumaný soubor spin· vybudit elektromagnetickým impulsem o ur£itém spektru frekvencí a v anténních cívkách detekovat signál, který odpovídá rezonancím na ur£ité frekvenci. Signál detekovaný na anténách (chovající se podle rovnice pro T1) je p°eveden do frekven£ní domény, z které lze zjistit na jakých frekvencích zkoumaný vzorek rezonoval (kde se objevily ²pi£ky v amplitud¥). P°evod mezi doménami se provádí rychlou Fourierovou transformaci. V p°ípad¥ pouºití lineárního gradientního magnetického pole pak osa frekvencí p°esn¥ odpovídá prostorové ose a to díky lineárnímu vztahu v Larmorov¥ rovnici. Víme tedy s jakou silou v jaké vzdálenosti od antény zkoumaný vzorek reagoval. Tím dostáváme obrazovou informaci v jedné dimenzi.
Pro zjednodu²ení, zejména v p°ípadech více rozm¥r·, se zavádí takzvaný k-space formalismus. Jeho podstatu a význam si p°edvedeme na jednodimenzionálním p°íkladu, kdy je gradientní pole orientované ve sm¥ru osy
Z.
Nejprve se magnetickým polem
nají sm¥ry magnetických moment· spin· ve sm¥ru osy
Z,
B0
zarov-
poté jsou vybuzeny oscilujícím
elektromagnetickým impulsem a za£nou vykonávat precesní pohyb v rovin¥
XY
o Lar-
morov¥ frekvenci, která je r·zná v závislosti na pozici. Úhel, který svírá vektor v rovin¥ fáze
XY s osou X se nazývá fáze a exp(ıγ(B0 + Gz)t. Fázory jsou
ten lze také popsat takzvaným fázorem, vektorem zpo£átku pro v²echny magnetické momenty celého
spinového souboru stejné, ale s postupem £asu se jejich fáze v d·sledku r·zných frekvencí rozhodí a pozice fázoru v prostoru pak leºí na k°ivce zvané ²roubovice, p°i£emº vzdálenost mezi jejími závity se s £asem zmen²uje (zv¥t²ují se rozdíly ve fázích). Tato vzdálenost se
λ. Zde se práv¥ zavádí veli£ina prosk = γGt a platí k = 2π/λ s jednotkou m−1 , odkud plyne název prostorové
nazývá vlnovou délkou ²roubovice a je ozna£ována torové frekvence
frekvence. Signál, který je nam¥°en na cívkách je pak roven:
S(k) =
R
ρ(z) exp(ıkz)dz , 13
r(z)
kde
Z , které mají své fázové vektory exp(ıkz). ρ(z), které odpovídá obrazové informaci.
je rozloºení hustoty spin· podél osy
Fourierovou transformací signálu získáme
V p°ípad¥, ºe je pole ovlivn¥no více gradientními poli, pak je jejich sou£et vektorové pole
G,
prostorová frekvence je vektor
S(k) =
R
k = γGt
ρ(r) exp(ıkr)dr,
kde
a signál je roven:
r
je vektor pozice spinu.
Vícerozm¥rný obraz lze pak získat pomocí vícerozm¥rné Fourierovy transformace.
2.6
Za°ízení MRI
Jednotka MRI obsahuje °ídící po£íta£ a samotné skenovací za°ízení. Po£íta£ zpracovává data od skeneru a pomocí rychlé Fourierovy transformace rekonstruuje snímky v reálném £ase. Kaºdé snímací za°ízení obsahuje silný magnet, vytvá°ející homogenní pole. Ty se d¥lí na následující typy:
·
Odporové Jsou to b¥ºné elektromagnety tvo°ené mnoha vinutími cívky. Pr·chodem elektrického proudu pak vzniká magnetické pole. Tyto magnety mají men²í náklady na konstrukci oproti supravodivým, ale velké nároky na elektrickou energii pro jejich provoz kv·li odporu vodi£·. B¥ºn¥ se pouºívají jen pro slabá magnetická pole kolem 0.3 Tesla.
·
Permanentní Tyto magnety mají trvalé magnetické pole, takºe mají nízké náklady na provoz. Jejich problémem je hlavn¥ vysoká hmotnost. Pro sílu magnetického pole 0.4 Tesla váºí mnoho tun. Siln¥j²í pole by vyºadovalo magnety tak t¥ºké, ºe by byl problém je zkonstruovat.
·
Supravodivé Supravodivé magnety jsou nejpouºívan¥j²ími magnety v MR. Jsou podobné odporovým magnet·m, jen drátové vinutí je uchováváno v tekutém heliu p°i asi
−270◦
C. Tento obrovský chlad je v²ak dob°e izolován vakuem, takºe pacient
ho necítí. Takto nízká teplota drát· sníºí jejich odpor aº na nulu, coº dramaticky sníºí pot°ebu elektrické energie a tím i náklady na provoz. Konstrukce takových systém·, které dokáºou generovat pole v rozmezí 0.5-2.0 Tesla, je stále velmi drahá, ale s takto výkonými magnetyje moºné dosáhnout mnohem v¥t²í obrazové kvality. Dal²í £ástí MRI jednotky jsou radiofrekven£ní cívky, které vysílají nebo p°ijímají elektromagnetický signál. Slouºí jednak k vybuzení magnetické rezonance, dále jako antény p°ijímající signál a také jako modi kátory magnetického pole v cílovém prostoru. D¥lí se na objemové, gradientní, vyrovnávací a povrchové.
2.7
Nevýhody MRI
V okolí skeneru p·sobí silné magnetické pole (v p°ípad¥ supravodivých a permanentních magnet· neustále). Je tedy nebezpe£né mít v dosahu magnetické p°edm¥ty, protoºe by mohlo dojít k takzvanému projektilovému efektu, tedy vyst°elení p°edm¥t· sm¥rem
14
do magnetu. Pacient nesmí mít p°i vy²et°ení v t¥le ºádné kovové implantáty. Ty by zp·sobily nehomogenitu magnetického pole a tím i artefakty ve výsledném obraze. Dal²í nevýhodou jsou pak nep°íjemnosti, kterým musí pacienti b¥hem vy²et°ení £elit. Ty josu spojené s vysokým hlukem zp·sobeným vysíláním RF impuls·. Dále také nutnost být nehybn¥ v malém uzav°eném prostoru po dlouhou dobu, coº m·ºe být velice nep°íjemné a v p°ípad¥ n¥kterých úraz· i velmi bolestivé. Dále je pak nemoºné vy²et°it pacienty trpící klaustrofobií, pro které je v poslední dob¥ k dispozici takzvané otev°ené MRI.
Obrázek 2.1: Skenovací za°ízení MR.
15
Obrázek 2.2: Sagitální snímek mozku získaný magnetickou rezonancí.
16
Kapitola 3 DICOM DICOM je zkratka anglického termínu The Digital Imaging and Communications in Medicine. Jedná se o standard vytvo°ený asociací NEMA (National Electrical Manufacturers Association) v roce 1993 pro usnadn¥ní distribuce a zobrazování medicínských dat po°ízených snímacími metodami, jako jsou CT, MRI a ultrazvuk [5]. Jednotlivé typy snímacích metod se ozna£ují jako
modality. Standard je velmi rozsáhlý a d¥lí se na n¥kolik £ástí. Jsou v n¥m
de novány zp·soby skladování medicínských dat a zp·sob jejich správy, nap°íklad mazání, archivování a sdílení dat v síti. Medicínská za°ízení jasn¥ deklarují, které £ásti DICOM formátu podporují (takzvaný conformance statement).
Sluºby nabízené standardem DICOM [6]:
·
Skladování Skladovací sluºba je pouºívána k uloºení snímk· nebo dal²ích uchovatelných objekt· jako jsou r·zné záznamy a dokumenty do systému
PACS
nebo na
pracovní stanici. PACS je zkratka anglického termínu Picture Archiving And Communication System a jedná se o kombinaci hardwaru a softwaru umoº¬ující digitální uchování dat.
·
Potvrzení uskladn¥ní Tato sluºba je ur£ena k tomu, aby klientovi (SCU - Service Class User) potvrdila, ºe se na serveru (SCP - Service Class Provider) provedlo uskladn¥ní dat na n¥jaké trvalé záznamové médium (nap. CD), aby klient mohl u sebe data bezpe£n¥ smazat.
·
Dotaz/Vrácení Pomocí této sluºby se m·ºe klient dotázat PACS systému na seznam studií nebo jiných objekt· a ten je klientovi vrátí.
·
Modality Worklist
Sluºba usnad¬ující konkrétnímu zobrazovacímu za°ízení (modal-
it¥) získat informace o pacientov¥ provedených a plánovaných vy²et°ení v elektronické podob¥.
·
Tisk Tisková sluºba slouºí k posílání obrázk· na DICOM tiskárnu, která tiskne rentgenový snímek. Ve standardu DICOM £ást 14 je de nována standardní kalibrace tisku, která pomáhá zachovat konzistenci obrazu na r·zných zaºízeních.
17
·
O ine media - DICOM soubory Sluºba umoº¬ující skladování medicínských dat na r·zná vým¥nná úloºi²t¥ dat.
3.1
Souborový formát DICOM
ást 10 standardu DICOM popisuje souborový formát pouºívaný pro distribuci obrazových dat. Tento formát pochází z p·vodní speci kace formátu NEMA a je b¥ºn¥ ozna£ován jako souborový formát DICOM. V tomto souboru je obsaºena hlavi£ka s informacemi a obrazová data zárove¬. Tím je na rozdíl od jiných formát· zaru£eno, ºe se chybnou manipulací neodd¥lí informace od obrázku. V hlavi£ce jsou uloºeny informace o po°ízené studii jako jsou jméno pacienta, obrazové informace, typ snímacího za°ízení. Obrazová data v souboru mohou být uloºena bu¤ v b¥ºném formátu, nebo komprimovan¥ pro u²et°ení místa. Tato komprese m·ºe být bu¤ ztrátová pomocí JPEG nebo bezztrátová RLE (Run Length Encoding) jako je ve formátu TIFF. Prvních 128 byt· souboru je prázdných a následují za nimi písmena D, I, C, M. Poté následují informace hlavi£ky, které jsou rozd¥leny do takzvaných skupin. V kaºdé skupin¥ se pak vyskytuje n¥kolik prvk· p°íslu²ejících dané skupin¥. Dvojice skupina:prvek se identi kuje dvojicí hexadecimálních £ísel. Nap°íklad 0002:0010 je prvek
unique identification
Transfer syntax
a obsahuje popis uloºení obrazových dat v souboru, jako je
pouºitá komprese. Kódy hodnot pro tento prvek jsou de novány v £ásti 5 standardu DICOM. Krom¥ komprese ur£uje tato hodnota také po°adí byt· hodnoty pixelu v surových datech. azení byt· m·ºe být bu¤ Big Endian nebo Little Endian [7]. To je d·leºité v p°ípad¥, ºe pro jeden pixel obrazových dat je pouºito více neº jednoho bytu. M·ºe se stát, ºe pro danou architekturu bude pot°eba po°adí byt· p°ehodit. Dal²í informace o obrazu jsou ve skupin¥ 0028. Prvky této skupiny jsou nap°íklad po£et vzork· na pixel, po£et alokovaných bit·, fotometrická interpretace a dal²í. Fotometrická interpretace p°i°azuje hodnotám pixel· barevné hodnoty. Ve v¥t²in¥ p°ípad· bývá spojitá monochromatická, tzn. s mnoha stupni ²edi. Takový obrázek má jeden vzorek na pixel. V¥t²inou jsou hodnoty vzorku 12-ti bitové nebo 32-ti bitové. Dále mohou být pouºity i barevné interpretace (RGB, CMYK, paleta). Nap°íklad RGB interpretace pouºívá 3 vzorky na pixel. Barva pak m·ºe nabývat aº 16 milion· r·zných hodnot. Dále je také moºné de novat vlastní prvky pro uchování pot°ebných informací souvisejících s danou studií. V DICOM sv¥t¥ m·ºe mít kaºdý pacient n¥kolik DICOM studií, z nichº kaºdá m·ºe sestávat z n¥kolika sérií. Tyto série v¥t²inou korespondují s jedním typem dat (s jednou modalitou).
3.2
Kontrast a jas obrazových dat
V oblasti medicínského zobrazování se v p°ípad¥ kontrastu a jasu obrázku hovo°í o takzvaném st°edu a ²í°ce okna , z anglického Window Center:Width. A o zm¥n¥ kontrastu a jasu jako o okn¥ní . Hodnoty ²í°ky a st°edu okna lze v n¥kterých p°ípadech povaºovat za standardní, kalibrované. Nap°íklad, kdyº jsou snímky hlavy nasnímány s hodnotami pixel· v rozmezí 0-4096, tak okno nastavené na C:W = 50:530 zobrazuje dob°e m¥kké
18
tkán¥, zatímco C:W=400:2000 zobrazuje lebe£ní kosti. Problém u MRI dat je, ºe hodnoty pixel· bývají relativní pro dané m¥°ení, a tak hodnoty nastavení C:W nemusí pasovat na stejné tkán¥ mezi r·znými studiemi.
Obrázek 3.1: R·zná nastavení jasu a kontrastu
19
Kapitola 4 Implementace programu 4.1
Srovnání s exitujícími programy
V dne²ní dob¥ je dostupné mnoho program· pro zpracování medicínských snímk·. V¥t²ina z nich je komer£ních a velmi drahých. Dále existují i voln¥ dostupné aplikace. Jmenujme ty kvalitn¥j²í, nap°íklad:
·
OsiriX [8] Velmi dob°e propracovaný projekt. Bohuºel pouze pro platformu Mac OS, která není p°íli² vhodná k poºadovaným ú£el·m.
·
Medinria
[9] Také voln¥ dostupný software, který nabízí mnoho funkcí. Je dos-
tupný pro platformy Linux a Windows, coº jsou i cílové platformy tohoto projektu, av²ak nenabízí poºadovanou funkcionalitu. Poslední stabilní verze pochází ze zá°í 2008.
·
MRICron
[10] Program specializující se zejména na zobrazování snímk· mozku.
Jeho nativním formátem není DICOM. Dále existuje mnoho program·, které jsou na funkce pom¥rn¥ chudé, jejich uºivatelské prost°edí není p°íli² p°ív¥tivé a navíc se ve velké v¥t²in¥ jedná o jednoú£elov¥ zam¥°ené projekty, které nem¥ly dlouhou ºivotnost a pro poºadované ú£ely jsou op¥t nepouºitelné.
P°i návrhu a vývoji mého programu zpracovávajícího data z medicínských studií jsem postupoval p°edev²ím podle poºadavk· kladených pracovi²t¥m magnetické rezonance institutu IKEM. P°estoºe na trhu existuje celkem velký výb¥r program·, tak ºádná z komer£ních aplikací nasazených v institutu IKEM ani ºádná ze jmenovaných voln¥ dostupných aplikací nevyhovuje t¥mto poºadavk·m. T¥mi jsou zejména moºnost libovoln¥ rozloºit obrázky medicínských studií na pracovní plo²e, aby bylo moºné snímky mezi sebou snadno porovnávat a p°ípadn¥ vyexportovat. Ve v¥t²in¥ existujících program· jsou k dispozici pouze vzorová rozloºení snímk· na pracovní plo²e (nap°. 2x2 obrázky), p°i£emº obrázky reprezentují zpravidla 4 r·zné pohledy na stejnou medicínskou studii (viz. obr. 4.1). Hlavním cílem tohoto projektu bylo tedy
20
Obrázek 4.1: Rozloºení obrázk· typické pro v¥t²inu program·. Vlevo naho°e axiální °ez, vpravo naho°e sagitální °ez, vlevo dole koronální °ez a vpravo dole bývá trojrozm¥rné zobrazení. V tomto p°ípad¥ je zde op¥t sagitální °ez.
poloºit základ aplikace, která by umoº¬ovala uºivateli pln¥ kontrolovat rozmíst¥ní obrázk· libovolných studií na pracovní plo²e. Rozmís´ování snímk· na plo²e by m¥lo být jednodu²e ovladatelné a uºivatelsky p°ív¥tivé. Stejn¥ tak by m¥lo být snadné provád¥t základní transformace obrazových dat zp·sobem, který je standardní ve v¥t²in¥ existujících produkt· a to za pomoci my²i. Pohybem my²i p°i stisknutém levém tla£ítku se v¥t²inou posunuje obrázek, p°i stisknutém prost°edním tla£ítku se uskute£¬uje zm¥na m¥°ítka obrázku a podobn¥ probíhá i takzvané okn¥ní , tj. zm¥na kontrastu a jasu, p°i stla£eném pravém tla£ítku.
Poºadavky na aplikaci jsou shrnuty do následujících bod·: 1. Zvolit postupy a knihovny pro vývoj aplikace, aby b¥ºela v prost°edí KDE v OS Linux. Opera£ní systém Linux byl zvolen pro své vysoké moºnosti vyuºití výkonu po£íta£e a pro svou cenovou dostupnost. 2. Navrhnout framework umoº¬ující sestavovat obrázky do libovolných uspo°ádání na pra-
21
covní plo²e. 3. Implementovat základní transforma£ní funkce nad obrazovými daty medicínské studie. Jedná se o barevné transformace, posun a ²kálování obrazu. Umoºnit plynulý p°echod mezi jednotlivými snímky (nap°. po sob¥ jdoucími °ezy v prostoru) celé studie. 4. V aplikaci zobrazovat základní údaje o medicínské studii získané z DICOM hlavi£ky jako jsou velikost snímku, rozli²ení obrazových dat, sou°adnice °ezu, a dal²í. 5. Umoºnit vytvá°ení animací medicínských studií a jejich vzájemnou synchronizaci. Tato funkcionalita je vhodná nap°íklad pro porovnávání probíhajících svalových kontrakcí, nebo pozorování p°esunu tekutin v r·zných oblastech stejného orgánu. 6. Implementovat export výsledk· do standardních gra ckých formát· (PNG, AVI). Z vytvo°ených soubor· je pak nap°íklad moºné snadno vytvá°et prezentace.
4.2
Knihovny a technologie pouºité p°i vývoji aplikace
V této £ásti se seznámíme s knihovnami, které jsem se rozhodl p°i vývoji své aplikace pouºít, abych mohl docílit spln¥ní vý²e vytý£ených poºadavk·. Uvedu také alternativy, které p°ipadaly v úvahu a jaké byly jejich nevýhody oproti zvolenému °e²ení.
4.2.1
Qt
Qt [11] je multiplatformní framework pouºívaný mnoha programy zejména pro tvorbu uºivatelského rozhraní (GUI). Podporovanými platformami jsou GNU/Linux, MS Windows, Mac OS X, Symbian S60 (t°etí edice), Java nebo vestav¥né (embedded) systémy, coº jsou jednoú£elové systémy nap°íklad pro obsluhu bankomat·. Nejrozsáhleji je Qt pouºito v prost°edí KDE, coº je gra cké desktopové prost°edí pro Linux a dal²í unixové opera£ní systémy. Dal²ími známými aplikacemi vyuºívající Qt jsou Google Earth, Opera, Skype, VirtualBox, a dal²í. Knihovna Qt se za£ala vyvíjet v roce 1993. První dv¥ verze Qt byly dostupné pouze ve dvou variantách: Qt/X11 pro Unix a Qt/Windows pro Windows. Verze pro Windows byla vydána pouze v proprietární licenci, a tak volné/open source aplikace napsané v Qt pro X11 nemohly být p°eneseny na Windows bez zakoupení proprietární licence. Proprietární software je software, jehoº autor upravuje licenci k jeho pouºívání. Jeho zdrojové kódy nebývají dostupné a obvykle spadá do komer£ního softwaru. Úpravy funkcionality programu tak m·ºe provád¥t pouze autor. GPL licence Qt pro Windows byla vydána aº v £ervnu 2005 s vydáním Qt verze 4. Podpora pro Mac OS X v proprietární licenci byla p°idána v roce 2001 v Qt verzi 3.0 a v roce 2003 v Qt 3.2 se objevila i GPL licence. Do roku 2008 stála za vývojem Qt norská spole£nost Trolltech ASA. V lednu 2008 ji koupila nská rma NOKIA a p°ejmenovala Trolltech na Qt software. Po tomto odkoupení se NOKIA zam¥°ila na vývoj pro platformy jejích za°ízení. Qt se tak objevilo na platformách Symbian OS (t°etí edice) a Maemo.
22
Po celou dobu existence bylo Qt dostupné v komer£ních licencích, které umoº¬ovaly vývoj proprietárních aplikací bez omezení na licence. Zárove¬ k tomu se objevovalo stále nové mnoºství volných licencí. V sou£asnosti je Qt dostupné pod licencí GNU LGPL, která jej umoº¬uje pouºít jak v proprietárním, tak volném softwaru. Qt není jedinou multiplatformní knihovnou pro tvorbu uºivatelského rozhraní (GUI). Existují i dal²í knihovny jako jsou Universe £i GTK+, které vyuºívá druhé nejroz²í°en¥j²í gra cké prost°edí Linuxu GNOME. GTK+ bylo p·vodn¥ napsáno pro rastrový gra cký editor GIMP a je na rozdíl od Qt psáno v jazyku C. Qt je psáno v C++ a pouºívá vlastní
renderovací
(vizualiza£ní) jádro snaºící se na kaºdé platform¥
renderovat
(vykreslovat)
gra ku p°íslu²nou danému vzhledu platformy. Krom¥ snadného vytvá°ení GUI usnad¬uje toolkit Qt i práci s XML soubory, vlákny, SQL a sí´ovým rozhraním. Dále také obsahuje podporu kreslení SVG (kontrétn¥ ve verzi tiny) a podporu OpenGL.
GUI Gra cké rozhraní aplikací se tvo°í za pomocí takzvaných Qt
widget·
(Widget je anglický
termín pouºívaný pro prvek okna (zkratka pro anglický termín Windows gadget)). Jedná se o standardní objekty uºivatelského rozhraní, jako jsou okno aplikace, dialogové okno, edita£ní (textové) pole, tla£ítko a dal²í sloºit¥j²í objekty. Následuje p°íklad velmi jednoduché aplikace napsané pomocí Qt. Jedná se o typickou aplikaci Hello world! . Okno aplikace je v tomto p°ípad¥ tvo°eno jediným widgetem a to tla£ítkem t°ídy
QPushButton.
#include
#include int main(int argc, char *argv[]) { QApplication app(argc, argv); QPushButton hello("Hello world!"); hello.resize(100, 30);
}
hello.show(); return app.exec();
Výstup programu je na obrázku 4.2.
Podpora OpenGL Nezanedbatelnou dobu jsem strávil nad otázkou, jak umístit do hlavního okna aplikace Qt n¥jaký widget, jehoº gra cký obsah by byl vykreslován pomocí OpenGL. Uvaºoval jsem
23
Obrázek 4.2: Výstup ukázkové Qt aplikace.
i o moºnosti, ºe okno pro renderování OpenGL gra ky by bylo na zbývajícím rozhraní aplikace úpln¥ nezávislé. Pro sv·j program jsem pot°eboval najít zp·sob, jak co nejrychleji vykreslovat obrázky medicínských snímk·. OpenGL jsem byl nucen pouºít proto, ºe se jedná v podstat¥ o jedinou pouºitelnou multiplatformní knihovnu pracující s gra ckými akcelerátory. Propojení GUI tvo°eného v Qt s OpenGL jsem se nejprve snaºil dosáhnout za pomocí knihovny SDL (Simple DirectMedia Library). Tu jsem zvolil zejména proto, ºe jsem s ní jiº m¥l n¥jaké zku²enosti a v podstat¥ se jedná o nadstavbu nad OpenGL, pomocí které se snadno inicializuje subsystém OpenGL a ve které se snadno pouºívají textury. SDL také zahrnuje podporu renderování truetype font· (v modulu
SDL_ttf).
Gra cký výstup
OpenGL se mi poda°ilo umístit na poºadovanou pozici na obrazovce a byl jsem schopen do n¥j i renderovat textury pouºitím funkcí a procedur OpenGL API. asto se v²ak vyskytoval problém s blikáním obrazu a také s odchytáváním událostí generovaných my²í a klávesnicí, které byly odchytávány subsystémem SDL a ne Qt widgety. Za£al jsem tedy zji²´ovat, zda neexistuje jiná a také mén¥ komplikovaná moºnost, jak renderovat obsah OpenGL na Qt widgety. Pak jsem objevil v·bec tu nejjednodu²²í moºnost (coº se ukázalo pozd¥ji), jak toho docílit. Toho, ºe Qt obsahuje modul pro práci s OpenGL jsem si v¥dom byl, ale domníval jsem se, ºe jeho pouºití nebude tak snadné, jaké nakonec bylo. V Qt GUI totiº existuje widget, jehoº gra ka je p°ímo renderována pomocí
QGLWidget. Ten na rozdíl od ostatních widget· nepouºívá pro QPainter, ale nechává svoje vykreslení na uºivateli, který implementuje funkci painGL(), v níº lze pouºívat libovolné funkce OpenGL API a gra cký
OpenGL. Jedná se o widget
svoje vykreslení funkcí objektu
výstup je automaticky umíst¥n na plochu widgetu. Te¤ jiº jen zbývalo nau£it se základy OpenGL a mohl jsem renderovat obsah textur na poºadovaná místa okna aplikace. Ze za£átku jsem pouºíval standardní postup p°i práci s texturami, který je pom¥rn¥ komplikovaný, zejména proto, ºe je £ist¥ procedurální. Od verze 4.2 obsahuje Qt i objekt
QGLFramebufferObject zapouzd°ující funkcionalitu textury
OpenGL do objektu Qt knihovny. Pouºitím tohoto objektu se p·vodn¥ celkem náro£ná (zejména na mnoºství kódu) práce s texturami stala pom¥rn¥ snadnou a intuitivní. Zmizely také n¥které problémy, které se vyskytovaly p°i testování aplikace na r·zném hardwaru
QGLFramebufferObject CGLImage a CGLWorkspace. Mezi hlavní výhody tohoto objektu pat°í také
patrn¥ kv·li barevným formát·m textur. V programu pouºívám v objektech t°íd
implementovaný export textury do souboru.
Shr¬me si tedy d·vody, pro£ jsem se rozhodl knihovnu Qt pouºít. Prvním d·vodem je, ºe tato knihovna je podporována na cílových platformách opera£ních systém· Linux a
24
MS Windows. Na rozdíl od knihovny GTK+ je tato objektová a psána v C++. V sou£asné dob¥ navíc za jejím vývojem stojí silná rma NOKIA, která hodlá Qt pouºívat na svých za°ízeních, coº zaru£uje pokra£ování jejího dal²ího rozvoje. Pro Qt hovo°í také její stále se zlep²ující podpora pro OpenGL.
4.2.2
OpenGL
OpenGL (Open Graphics Library) je standardní speci kace pro multiplatformní API (zkratka pro Application programming interface) ur£eného pro psaní aplikací vyuºívajících 2D a zejména 3D po£íta£ovou gra ku [12][13]. Knihovna OpenGL byla vyvinuta rmou Silicon Graphics Inc. (SGI) v roce 1992 a pouºívá se na poli po£íta£ových her, virtuální reality, CAD systém·, vizualizace dat, atd.
OpenGL slouºí zejména k následujícím dv¥ma ú£el·m:
·
Prvním je usnadnit p°ístup k funkcím jednotlivých rozdílných 3D akcelerátor· pomocí jednotného rozhraní.
·
Druhým je zprost°edkovat uºivateli stejné sady funkcí na v²ech platformách dle ur£ité speci kace. V p°ípad¥, ºe daný 3D akcelerátor funkci nepodporuje p°ímo na úrovni hardwaru, pak je tato emulována softwarov¥.
Návrh OpenGL OpenGL pracuje jako stavový automat, který se v oblasti po£íta£ové gra ky ozna£uje jako
graphics pipeline
(zobrazovací °et¥zec). Jeho stav je ovliv¬ován pomocí sady proce-
dur, které ur£ují, jakým zp·sobem budou vstupní data (gra cká primitiva) zpracována, p°etransformována a nakonec zobrazena do výstupního za°ízení. Základními gra ckými primitivy jsou body, úse£ky, polygony a bitmapy (obdélníky s pixely).
Základní popis funkcionality v renderovacím °et¥zci (graphics pipeline): 1. Zpracování vstup· na gra cká primitiva. Roli zde hrají funkce vy£íslující r·zné polynomiální funkce, které de nují vstupní geometrii (NURBS povrchy, k°ivky, atd.). Výstupem jsou
vertexy
(body v 3D prostoru).
2. Operace na vertexech, tj. transformace a osv¥tlování v závislosti na materiálech, o°ezání oblastí mimo viditelnou £ást. Výstupem jsou tedy op¥t vertexy. 3. Rasterizace. Konverze vertex· na pixely (projekce na 2D m°íºku) pomocí interpola£ních algoritm·. Pixely se v OpenGL terminologii ozna£ují jako
fragmenty.
4. Operace na fragmentech, tj. úpravy barevných hodnot. Nap°íklad ztmavení, nebo mlºení na základ¥ hloubkového bueru. Buer je druh pam¥ti, která je pouºívána v¥t²inou k do£asným ú£el·m.
25
5. Nakonec se fragmenty uloºí do
framebueru.
Framebuer je obrazové výstupní za-
°ízení, které p°ená²í obrazovou informaci z vyrovnávací pam¥ti (
bueru ) a obsahuje
práv¥ jeden kompletní rámec dat (frame).
Extensions - roz²í°ení v OpenGL speci kaci Standard OpenGL umoº¬uje výrobc·m gra ckého hardwaru zprost°edkovat dal²í funkcional-
extensions ). V t¥chto roz²í°eních
itu mimo standard OpenGL pomocí takzvaných roz²í°ení (
mohou být zavedeny nové funkce £i konstanty. Kaºdý výrobce pro ozna£ení svých nových konstant a funkcí pouºívá zkratku uvedenou v jejich názvu a také v pojmenování vlastního roz²í°ení. Nap°íklad ATI pouºívá zkratku ATI a nVidia NV. asto se také stane, ºe se výrobci shodnou na stejném roz²í°ení. Takové roz²í°ení má pak zkratku EXT. Pokud pak toto roz²í°ení standardizuje Architecture Review Board (konsorcium spravující standard OpenGL), pak se pouºívá zkratka ARB. Prvním takovým roz²í°ením bylo GL_ARB_multitexture, uvedené ve verzi 1.2.1. Ve verzi 1.3 pak p°estalo být roz²í°ením a stalo se sou£ástí jádra OpenGL. P°ed pouºitím roz²í°ení je pot°eba zjistit, zda je podporováno na daném gra ckém akcelerátoru a následn¥ získat ukazatele na p°ípadné funkce de nované v tomto roz²í°ení. Tyto úkony jsou usnadn¥ny nap°íklad pouºitím toolkit· jako jsou GLEW a GLEE. Speci kace tém¥° v²ech roz²í°ení je k dispozici v o ciálním registru [14].
Historie Na za£átku 90.tých let byla rma Silicon Graphics (SGI) nejvlivn¥j²í na poli 3D gra ky pracovních stanic. Jejich IRIS GL API bylo povaºováno za v té dob¥ nejmodern¥j²í a snadno pouºitelné renderovací API. Konkurence SGI byla v té dob¥ postavena okolo PHIGS standardu, za kterým stály rmy Sun Microsystems, Hewlett-Packard a IBM. Aby si SGI upevnilo pozici na trhu s 3D hardwarem rozhodlo se p°em¥nit IrisGL API na otev°ený standard. Samotné IrisGL API nebylo podle SGI úpln¥ vhodné k t¥mto ú£el·m (obsahovalo i API netýkající se gra ky) a tak byl vydán nový standard a to OpenGL. Tímto krokem byl standardizován p°ístup k gra ckému hardwaru a bylo zodpov¥dností výrobc· hardwaru vyvinout ovlada£e za°ízení podporující tento standard. V roce 1992 inicializovalo SGI zaloºení OpenGL architectural review board (OpenGL ARB), skupiny rem, které se m¥ly starat o OpenGL speci kaci a roz²i°ovat ji. Jedinou sou£asnou konkurencí OpenGL je DirectX od Microsoftu, které je v²ak podporováno pouze na OS MS Windows. V letech 1997-1999 spolupracovali SGI, Microsoft a Hewlett-Packard na projektu, který m¥l sjednotit OpenGL a Direct3D, který byl ale z r·zných d·vod· ukon£en. Materiály vhodné pro za£ínající OpenGL vývojá°e jsou k dispozici na o ciálních webových stránkách OpenGL [15].
4.2.3
DCMTK
DICOM toolkit [16] je soubor nástroj· a knihoven implementujících velkou £ást standardu DICOM. Tuto knihovnu pouºívám pro na£ítání dat soubor· ve formátu DICOM.
26
V souboru jsou obsaºeny jak obrazová data tak hlavi£ka obsahující r·zné informace získané b¥hem vy²et°ení. Pomocí API DCMTK knihovny je moºno p°istupovat k ob¥ma druh·m informací. Co se tý£e hlavi£ky, tak je moºné dotazovat se na hodnoty parametr· jako jsou velikost a rozli²ení obrazových dat, informace o pacientovi, informace o snímacím za°ízení a dal²í (viz [5]). Pro obrazová data obsahuje knihovna podporu dekódování r·zných kompresních formát·, nap°íklad JPEG. Výhodou této knihovny je op¥t multiplatformnost, Open-source licence, obsáhlá dokumentace a asi nejrozsáhlej²í implementace standardu DICOM. Dal²í knihovnou pro práci s formátem DICOM je nap°íklad gdcm [17], která je ale více zam¥°ena zejména na souborový formát DICOM (£ást 10 standadu DICOM). Zejména první verze knihovny byla orientovaná pouze na obrazovou informaci DICOM soubor·. Od roku 2008 je ve vývoji nová verze gdcm 2.xx slibující ²ir²í podporu standardu a patrn¥ by stála za podrobn¥j²í prozkoumání. Dále také existují kompletní toolkity s podporou DICOM formátu jako jsou VTK a ITK. V dob¥, kdy jsem aplikaci za£ínal vyvíjet, byla knihovna gdcm ve verzi 2 teprve v po£átcích a tak jsem se rozhodl pro DCMTK. Sada DCMTK byla zvolena také pro to, ºe je napsána v C++ a obsahuje pouze API pro práci se standardem DICOM. Naproti tomu jiné knihovny obsahují mnoho modul· pro vizualizaci a segmentaci dat. Volba na tuto knihovnu padla jiº n¥kdy na podzim roku 2008 a je moºné, ºe od té doby doznaly ostatní knihovny zm¥n a byly by t°eba pro na²e pouºití nyní vhodn¥j²í. Otázkou nap°íklad z·stává, jak by ²lo urychlit na£ítání DICOM soubor·.
4.2.4
Cg a Cg Toolkit
Cg je programovací jazyk podobný jazyku C pro programování
shader·
gra ckých karet.
Shader je program ur£ený pro b¥h na procesoru gra cké karty. Cg Toolkit je API pro pouºití shader· v b¥ºných programech. Jeho implementace existuje op¥t pro opera£ní systémy Linux a Windows, dále také pro Solaris a Mac OS. Hlavním d·vodem pro pouºití shader· v na²em projektu byla pot°eba m¥nit kontrast a jas obrázk· ( okn¥ní ) medicínských snímk·. Ty se proti b¥ºným digitálním obrázk·m odli²ují v¥t²inou mnohem v¥t²í barevnou hloubkou. I kdyº se jedná jen o odstíny ²edi, tak zatímco b¥ºná bitmapa má jen 256 odstín· ²edi, v oblasti medicíny mají snímky b¥ºn¥ 4096 odstín· ²edi a mohou mít i více. Jak jsem jiº v sekci OpenGL nazna£il, tak obrazová data medicínských snímk· se nahrají do OpenGL textury. V úvahu pak p°ipadaly t°i zp·soby, jak u t¥chto obrazových dat m¥nit jas a kontrast, tedy transformovat barevné hodnoty. Pro reprezentaci barev bylo v texturách pouºito reálných £ísel o jednoduché p°esnosti (float) v rozsahu
<0.0-1.0>.
První moºností transformace barev by bylo data textury
exportovat do pam¥ti (pomocí funkce
glReadPixels),
tam provést p°epo£et hodnot a
výsledek zp¥t nahrát do textury. P°i testování a zji²´ování r·zných moºností, jak barevnou konverzi provést, jsem vyzkou²el i toto °e²ení, které v²ak bylo velmi pomalé. Nyní bylo jasné, ºe bude t°eba pouºít n¥jakou konverzi p°ímo na datech textury, která bývá v pam¥ti gra cké karty, pokud má dostate£nou pam¥´ovou kapacitu. K tomuto ú£elu se zdály být vhodné funkce
glBlendFunc, glBlendEquation
a
glBlendColor
[18], která
v p°ípad¥ správn¥ nastavených parametr· byla schopna ve dvou krocích poºadovanou
27
konverzi provést velmi rychle. Potíº se ov²em objevila v tom, ºe reprezentace barevných hodnot je pouze v rozmezí
<0.0-1.0>.
OpenGL totiº po kaºdé operaci nad texturami
tyto hodnoty o°ezává práv¥ na daný rozsah, coº vede ke ztrát¥ informace o barvách a tento postup se tedy ukázal jako nefunk£ní. V prvním kroku se totiº barevné hodnoty p°e²kálovaly (p°i zm¥n¥ kontrastu) a poté posunuly (jas), jenomºe jiº p°i p°e²kálování v¥t²inou do²lo k o°ezání hodnot a následný posun míval £asto jiº velmi omezený obor hodnot. P°edstavme si nap°íklad vstupní data, která jsou v rozsahu zv¥t²it 5x kontrast. Pak vyjdou hodnoty
<2.0-5.0>,
<0.4-1.0>
a chceme
které se ov²em o°eºou a nezbude
nic. Následný posun hodnot o -2 tak nemá ºádný vliv. V diskuzích na internetu jsem je²t¥ objevil moºnosti, které by za pomocí roz²í°ení OpenGL
glClampColorARB
m¥ly toto
prahování vypnout, av²ak neukázaly se jako spolehlivé. Pro pouºití OpenGL roz²í°ení bylo navíc nutné pouºít knihovnu GLEW (viz dále). Poslední moºností, která se nakonec ukázala jako nejlep²í, bylo práv¥ pouºití shader·. V p°ípad¥ operací nad barevnými hodnotami pixel· se hovo°í o takzvaných pixel shaderech, ozna£ovaných na poli OpenGL také jako fragment shadery. Shadery jsou podporovány na v¥t²in¥ moderních gra ckých karet a provádí se velmi rychle, protoºe jsou pro jejich prove-
streamprocesory ) schopné zpracov-
dení na gra cké kart¥ vyhrazeny samostatné jednotky (
ávat více fragment· paraleln¥ (v dne²ní dob¥ aº 3200 na ATI HD5970). Výhodou t¥chto program· je také to, ºe jsou kompilovány aº za b¥hu programu zavoláním funkcí API Cg toolkitu. Lze tedy zm¥nit funkci pixel shader bez pot°eby p°ekompilovat celý program. Následuje ukázka kódu pouºitá v programu práv¥ pro nastavení jasu (bias) a kontrastu (scale) barev:
struct output{ float3 color : COLOR; }; output main(float4 color: COLOR, float3 texCoord : TEXCOORD0, uniform sampler3D decal : TEX0, uniform float bias, uniform float scale) { output OUT; OUT.color = tex3D(decal, texCoord)*scale + bias; return OUT; } Inicializace shader·, tj. nahrání shader program· do prost°edí Cg, je provedeno ve funkci
CGLWidget::InitShaders(). CGLImage::DrawSliceFrom3DTextureToActualSliceTexture().
Pouºity jsou ve funkci
28
4.2.5
GLEW
The OpenGL Extension Wrangler Library [19] je knihovna umoº¬ující pouºívat roz²í°ení OpenGL (viz. 4.2.2). I tato knihovna je multiplatformní. V na²em programu ji pouºíváme kv·li pouºití 3D textur (roz²í°ení poru fragment shader· (roz²í°ení
4.2.6
GLEW_EXT_texture3D) a je²t¥ pomocí ní zji²´ujeme podGLEW_ARB_fragment_program).
PLIB
A Portable Game Library [20] je knihovna ur£ená k usnadn¥ní psaní po£íta£ových her nap°í£ r·znými platformami, v£etn¥ Windows a Linuxu. Osahuje krom¥ jiného i £ást renderovací fonty, kterou vyuºíváme v na²em programu p°i renderování text· v OpenGL kontejneru. OpenGL v základu renderování textu nepodporuje a renderování pomocí Qt
QGLWidgetu sice funguje, ale je velmi pomalé. Proto jsem se k t¥mto ú£el·m rozhodl pouºít práv¥ knihovnu PLIB. Renderování textu je pouºito ve funkci CGLWidget::RenderText(). Tímto vý£et pouºitých knihoven kon£í. P·vodn¥ jsem projekt vyvíjel v Linuxové distribuci Ubuntu ve vývojovém prost°edí
C++ Express Edition
Qt Creator,
ale nakonec jsem se rozhodl p°ejít k
Visual
v opera£ním systému Windows kv·li rychlosti kompilace a snad-
n¥j²ímu testování OpenGL funkcionality, nebo´ ovlada£e zejména pro integrované gra cké karty notebook· poºadovanou funkcionalitu nezvládaly. Návod na zprovozn¥ní projektu je v p°íloze (A).
4.3
Architektura programu a popis funk£nosti programu
V této kapitole si ukáºeme, jakým zp·sobem jsem se p°i programování vypo°ádal s poºadavky, které byly na výsledný program kladeny. Nastíním také základní architekturu a funkcionalitu programu.
Základní funkcionalitu programu lze shrnout do následujícího schématu: 1. Na£tení studií z datového zdroje. 2. Zpracování studií (gra cké úpravy). 3. Export výsledku zpracování. To v²e je vykonáváno na podn¥ty uºivatele programu, který toho dosahuje interakcí s uºivatelským rozhraním (GUI). Toto schéma je znázorn¥no na diagramu (4.3), kde je i na jednotlivých úrovních uvedeno, které z modul· do daných proces· zasahují.
4.3.1
Gra cké rozhraní
Pro snadnou obsluhu programu uºivatelem je ur£eno uºivatelské rozhraní (GUI), které je vytvo°eno ve frameworku Qt.
29
Obrázek 4.3: Schéma funkcionality programu
Základem uºivatelského rozhraní je Qt widget
MainWindow,
tedy hlavní okno aplikace.
To je pouze jedno a v²echny ostatní komponenty GUI jsou umíst¥ny v n¥m. V této verzi programu se jedná o dv¥ základní komponenty, které se d¥lí o místo v hlavním okn¥. První z nich je OpenGL
kontejner, objekt t°ídy CGLWidget, který slouºí ovládací panel, objekt t°ídy CControlPanel.
k vykreslování ve²keré gra ky. Druhou je
Ten p°edstavuje plovoucí okno, které je moºno uchytit po stranách hlavního okno, £i ho libovoln¥ umístit na obrazovce. V n¥m je pak umíst¥no mnoho widget·, které umoº¬ují uºivateli upravovat vzhled a chování objekt· v kontejneru a které zobrazují informace o nich.
Kontejner se dále gra cky d¥lí na t°i £ásti:
·
pracovní plochu (CGLWorkspace)
·
prohlíºe£ obrázk· (CGLImageExplorer) - tj. prohlíºe£ otev°ených medicínských studií
prohlíºe£ pracovních ploch (CGLWorkspaceExplorer) Uvnit° pracovní plochy mohou být r·zn¥ umís´ovány obrázky ·
DICOM studií (CGLImage).
V budoucnu by bylo dobré mít moºnost uloºit rozmíst¥ní obrázk· na pracovní plo²e
30
do souboru, aby uºivatel mohl pokra£ovat v práci i po novém spu²t¥ní programu. Prohlíºe£ obrázk· zobrazuje seznam otev°ených DICOM studií ve vertikálním seznamu a prohlíºe£ pracovních ploch zobrazuje náhledy otev°ených pracovních ploch v horizontálním seznamu. Je tedy moºné mít otev°eno více pracovních ploch i více DICOM studií najednou. Schéma gra ckého rozhraní je na následujícím diagramu (4.4).
Obrázek 4.4: Schéma gra ckého rozhraní
4.3.2
D·leºité komponenty, správci objekt·
V programu existuje n¥kolik objekt·, které mají sloºit¥j²í funkcionalitu a slouºí jako správci jednodu²²ích objekt·, umoº¬ují jejich tvorbu, odstra¬ování a mají nad nimi kontrolu. Jsou vytvo°eny jako unikátní instance (singletony) svých t°íd a je moºné se na n¥ kdekoliv v kódu
31
programu odvolat pomocí statické metody
GetInstance().
T¥mito správci jsou:
· CDicom3DTextureManager (Správce 3D textur ) Správce objekt· t°ídy CDicom3DTexture, které obalují OpenGL textury vytvo°ené na základ¥ dat z medicínských studií. Podrobn¥ji v kapitole 4.3.3.
· CGLImageExplorer Krom¥ prohlíºe£e otev°ených DICOM studií se jedná i o správce objekt· CGLImage t¥chto studií. Podrobn¥ji v kapitole 4.3.4. · CGLWorkspaceExplorer Krom¥ prohlíºe£e otev°ených pracovních ploch se jedná i o správce objekt· CGLWorkspace t¥chto pracovních ploch. Podrobn¥ji v kapitole 4.3.4. · CAnimationManager
Správce animací. Obrázky DICOM studií mohou být ani-
movány a tento správce se stará práv¥ o jednotlivé animace nad t¥mito studiemi. Podrobn¥ji v kapitole 4.3.5.
4.3.3
Import dat
Import dat probíhá tvorbou nového objektu obrázku
CGLImage
s parametrem cesty k
souboru DICOM studie, ze kterého se mají data na£íst. Konstruktor obrázku volá správce 3D textur, aby nahrál texturu de novanou tímto souborem. Správce pak vytvá°í nový objekt 3D textury
CDicom3DTexture,
která dále vytvo°í objekt t°ídy
CDicomSerieData
(4.4.1). Tato t°ída pak zjistí, zda jsou v adresá°i i jiné soubory ze stejné studie a na£te je postupn¥ do pam¥ti. Pro na£ítání je pouºito API knihovny DCMTK. Na£tená obrazová data pak zpracuje objekt t°ídy
CDicomSerieData 4.3.4
CDicom3DTexture,
který z obrazových dat objektu
vytvo°í OpenGL texturu.
Reprezentace obrazových dat v GUI
Obrazová data jsou v programu reprezentována pomocí OpenGL textur zabalených v objektech
CDicom3DTexture. V OpenGL kontejneru jsou pak tyto textury renderovány v obrázk· (CGLImage). Obrázky jsou zobrazovány v prohlíºe£i otev°ených DICOM
objektech
studií a také na pracovní plo²e. V té m·ºe být zobrazeno více obrázk· a uºivatel má moºnost tém¥° libovoln¥ m¥nit jejich pozici a rozm¥ry podle zvoleného správce rozmíst¥ní (layoutu). Kaºdý obrázek v sob¥ uchovává odkaz na 3D texturu a informace s jakými transformacemi se má textura promítnout na plochu obrázku. Lze nastavit sou°adnice °ezu 3D texturou. Z tohoto °ezu se pak vytvá°í 2D OpenGL textura. P°i projekci z 3D na 2D jsou aplikovány transformace barevných hodnot pomocí shader·. Znamená to, ºe projekce z 3D na 2D probíhá pouze p°i zm¥n¥ pozice °ezu v 3D textu°e a p°i zm¥n¥ nastavení jasu a kontrastu, tj. p°i okn¥ní .
QGLFramebufferObject. QGLFramebufferObject, a tak
Dvourozm¥rné OpenGL textury jsou obaleny Qt objektem Kaºdý objekt obrázku má svou vlastní instanci objektu
32
obrázky vytvo°ené ze stejné DICOM studie a tedy i stejné 3D textury mohou být naprosto nezávislé. Posun textury a ²kálování m¥°ítka je pak provád¥no za pomoci OpenGL API pouze na této 2D textu°e. Obrázky, stejn¥ jako ostatní objekty d¥d¥né z
CGLObject jsou pak vykreslovány voláním
kreslících metod svých nad°azených objekt·. V p°ípad¥ prohlíºe£e obrázk· se uvnit° metody
CGLImageExplorer::paintL() volají metody paintL() v²ech v seznamu viditelných obrázk·. Ty se tedy renderují p°ímo do gra ky kontejneru (do framebueru). V p°ípad¥ pracovní plochy se ale obrázky renderují do 2D textury pracovní plochy. Kaºdá pracovní plocha má totiº svou vlastní OpenGL texturu (QGLFramebufferObject). Teprve po té, co se v²echny obrázky pat°ící dané pracovní plo²e vyrenderují do textury pracovní plochy, je tato textura vykreslena do gra ky kontejneru. Textura má je²t¥ 2 dal²í pouºití. Prvním z nich je vykreslování náhled· pracovních ploch v prohlíºe£i pracovních ploch. Druhým je moºnost uloºit výslednou texturu jako bitmapu do souboru. To je velmi usnadn¥no práv¥ tím, ºe textura je obalena objektem
QGLFramebufferObject,
který ob-
sahuje implementovanou funkci provád¥jící export do standardních gra ckých formát·
4.3.5
Animace
Kaºdý obrázek má p°i°azenu animaci, objekt
CAnimation,
který se stará o animování
(automatickou zm¥nu parametr· v £ase) vlastností obrázku. V sou£asné chvíli lze animovat pouze hloubkovou sou°adnici 2D °ezu v 3D textu°e. Lze tedy nastavit automatické procházení v²emi snímky jedné studie. V p°ípad¥, kdy DICOM studie obsahuje v kaºdém souboru snímek stejného místa zachyceného pouze v jiném £ase, pak animace zobrazuje skute£ný pr·b¥h procesu na tomto míst¥.
4.3.6
Export
Jak jsem jiº v kapitole 4.3.4 zmínil, pouºitím objekt·
QGLFramebufferObject pro drºení 2D
OpenGL textury lze jednodu²e docílit exportu obrazu do bitmapového formátu. Pouºitím této výhody lze tedy snadno uloºit obraz aktuální pracovní plochy. Dále lze také exportovat animace probíhající na pracovní plo²e ve form¥ videa. Princip je jednoduchý a je zaloºen na postupném exportu jednotlivých pracovních ploch, zobrazených v r·zném anima£ním kroku, jako bitmap. Následn¥ je vzniklá série bitmap p°evedena pomocí externího programu na video soubor. V p°ípad¥ systému Windows byl pouºit program
EasyBMPtoAVI
[21]. Tento program je k dispozici jako Open-source a je
multiplatformní. Sou£asná implementace v²ak podporuje pouze MS Windows.
4.4
Dokumentace základních t°íd aplikace
4.4.1
Hierarchie t°íd
·
CAnimation
·
CAnimationManager
33
·
CControlPanel
·
CDicom3DTexture
·
CDicom3DTextureManager
·
CDicomHeader
·
CDicomHeaderGeneralEquipmentModule
·
CDicomHeaderImageModule
·
CDicomHeaderPatientModule
·
CDicomHeaderSeriesModule
·
CDicomSerieData
·
CDicomSerieLoadException
·
CGLObject
·
CGLImage
·
CGLImageExplorer
·
CGLWidget
·
CGLWorkspace
·
CGLWorkspaceExplorer
·
CGLWorkspaceSnapshot
·
CPoint3Df
·
CSettings
·
CTextureNotCreatedException
·
CVideoConverter
·
CWorkspaceLayout
·
CFreeLayout
·
CGrowingGridLayout
·
MainWindow
·
SaveSequenceDialog
·
SaveSnapshotDialog
34
CAnimation
CGLImage) je p°i jeho konstrukci CAnimation). Pomocí objektu animace je
Pro kaºdý obrázek zobrazující DICOM objekt t°ídy vytvo°en jeho vlastní objekt animace (této t°ídy
moºné dynamicky m¥nit gra cký obsah obrázku (a s ním související parametry). Správu animací a provád¥ní anima£ních krok· má na starosti objekt
CAnimationManager.
Proza-
tím je podporována pouze animace pozice v rozm¥ru hloubky 3D textury, která náleºí objektu CGLImage. Pokud nap°íklad obrázek obsahuje £asovou posloupnost snímk·, pak obrázek v základní poloze obsahuje v textu°e p°i posunu do hloubky snímky zachycené v r·zných £asech. M·ºe se jednat o snímky stahování srde£ního svalu zachycené v r·zném £asu a animace pak umoºní prohlíºet si celý proces jako video. Pomocí tohoto objektu lze nastavit rychlost animace, nastavit po£áte£ní a kone£ný snímek medicínské studie (indexy v hloubce textury), mezi kterými bude probíhat animace. Animaci je moºné restartovat, pozastavit a následn¥ pokra£ovat v animování a nastavit, zda se má animace provád¥t v nekone£ném cyklu, nebo provést pouze jednou. Následuje dokumentace vybraných funkcí této t°ídy:
CAnimation::CAnimation (CGLImage &image) Zkonstruuje anima£ní objekt pro konkrétní obrázek. Nastaví výchozí anima£ní hodnoty:
·
Rozsah animace p°es celou hloubku textury obrázku (tedy v²echny moºné snímky).
·
Rychlost animace na 25 snímk· za vte°inu.
·
Opakování ve smy£ce jako aktivní.
·
Animaci ponechá v pozastaveném stavu.
Parametry: image Objekt obrázku, kterému animace náleºí. bool CAnimation::Do ( oat ms) Provede jeden anima£ní krok. Funkce je zavolána £asova£em ze správce animací, pokud animace není pozastavená. Animace se posune na snímek, který odpovídá £asu daný parametrem
ms
uplynulého od posledního snímku.
Parametry: ms as v milisekundách, o který chceme animaci posunout. Návratová hodnota: true Pokud anima£ní krok prob¥hl. void CAnimation::SetLoop (bool loop) Nastaví, zda se má animace ve smy£ce opakovat.
Parametry: loop Pro nastavení nekone£ného opakování ve smy£ce true, pro jediný b¥h animace false. 35
void CAnimation::SetStartFrame (int startFrame) Nastaví index prvního snímku animace. Jedná se o index v rozm¥ru hloubky textury obrázku. Tento index se prahuje na hodnoty 1 aº celkový po£et snímk·.
void CAnimation::SetStopFrame (int stopFrame) Nastaví index posledního snímku animace. Jedná se o index v rozm¥ru hloubky textury obrázku. Tento index se prahuje na hodnoty 1 aº celkový po£et snímk·.
CAnimationManager T°ída spravující v²echny existující animace obrázk· - anima£ní správce. V první °ad¥ tato t°ída spravuje tabulku obrázk· a k nim p°íslu²ných animací. Kaºdý
GetAnimation() pro p°i°azení aniRemoveAnimation() pro odstran¥ní anima£ního
obrázek p°i své konstrukci volá funkci tohoto správce ma£ního objektu a p°i destrukci naopak objektu.
Dal²ími funkcemi anima£ního správce je hromadné ovládání v²ech spravovaných animací. Ty lze najednou pozastavit (PauseAll()), spustit (ResumeAll()), restartovat na
první snímek animace (RestartAll()) a lze jim nastavit velikost zrychlení, p°ípadn¥ zpo-
malení b¥hu (ChangeGlobalSpeedFactor()). Anima£ní správce také obsluhuje ukládání animace do souboru ve funkci
SaveSequence().
Následuje dokumentace vybraných funkcí této t°ídy:
CAnimationManager::CAnimationManager () [private] Konstrukce anima£ního správce. Nastaví základní anima£ní hodnoty spole£né v²em animacím a na jejich základ¥ vytvo°í anima£ní £asova£, který následn¥ v pravidelných £asových intervalech volá funkci
TimerTimeout().
void CAnimationManager::ChangeGlobalSpeedFactor (double speedFactor) Zm¥ní nastavení zrychlení b¥hu v²ech animací.
Parametry: speedFactor Násobící koe cient zrychlení b¥hu v²ech animací. Nap°.: ·
1 - rychlost beze zm¥ny = anima£ní £as koresponduje se skute£ným £asem;
·
0.5 - polovi£ní rychlost = anima£ní £as plyne 2x pomaleji neº skute£ný £as.
·
2 - dvojnásobná rychlost = anima£ní £as plyne 2x rychleji neº skute£ný £as.
36
void CAnimationManager::SaveSequence (const QString & leName, const QPoint &size, oat fps, bool keepFrames) Uloºí animaci probíhající na aktuální pracovní plo²e do video souboru.
Parametry: ·
leName Jméno souboru, do kterého se má video uloºit.
·
size Rozli²ení výstupního videa.
·
fps Po£et snímk· za vte°inu, které má obsahovat výsledné video.
·
keepFrames P°epína£, jestli se mají ponechat statické snímky animace vytvo°ené v pr·b¥hu ukládacího procesu.
Ukládání animace probíhá v následujících krocích: 1. Pozastaví probíhající animace a restartuje je. 2. Spo£te délku trvání nejdel²í animace na aktivní pracovní plo²e a tuto délku vezme jako délku výsledného videa. 3. Podle po£tu snímk· a délky trvání spo£te po£et snímk·, které se vyrenderují. 4. Uloºí první (resetovaný) snímek jako snímek s indexem 0. 5. Uloºí zbývající snímky aº do spo£teného po£tu. 6. Zkonvertuje statické snímky do video souboru.
CDicom3DTexture
Obrázek 4.5: Diagram t°íd pro CDicom3DTexture.
37
T°ída, která uchovává obrazová data DICOM medicínských snímk· v 3D textu°e OpenGL a informace z DICOM hlavi£ky. Kaºdému objektu obrázku pak p°íslu²í jeden objekt této t°ídy. Objekty této t°ídy jsou konstruovány správcem 3D textur (CDicom3dTextureManager). Následuje dokumentace vybraných funkcí této t°ídy:
CCDicom3DTexture::CDicom3DTexture (QString & leName ) Konstruktor, který z daného souboru na£te data snímk· do objektu t°ídy
CDicomSerieData
a z t¥chto dat poté vytvo°í OpenGL 3D texturu. Zárove¬ se zjistí a nastaví rozm¥ry tex-
GetWidth(), GetHeight(), GetDepth(). Nakonec CDicomSerieData odstraní (CDicomSerieData::FreeData()). V p°ípad¥ vyhodí výjimku CTextureNotCreatedException.
tury, které jsou pak p°ístupné metodami se data z objektu neúsp¥chu
CDicomHeader & CDicom3DTexture::GetDicomHeader(int frameNr) CDicomHeader p°íslu²nou DICOM studiu, z níº byl objekt vytvo°en. CDicomHeader obsahuje logicky £len¥né moduly osahující jednotlivé informace
Vrátí objekt t°ídy Objekt t°ídy
z hlavi£ky DICOM souboru.
Parametry: frameNr íslo snímku, jehoº hlavi£ku chceme vrátit.
CDicom3DTextureManager Správce 3D textur. T°ída je ur£ena pro správu objekt· t°ídy
CDicom3DTexture,
tedy tro-
jrozm¥rných OpenGL textur vytvo°ených z DICOM studií. Stará se o to, aby se v p°ípad¥ op¥tovného otev°ení stejné studie nevytvá°ela nová OpenGL 3D textura, ale pouºila se jiº stávající. Objekt si uchovává po£ítadlo pouºití textury, a kdyº tento po£et klesne na nulu, tak se daná OpenGL textura odstraní z pam¥ti, tj. smaºe se její obalující objekt. Následuje dokumentace vybraných funkcí této t°ídy:
CDicom3DTexture CDicom3DTextureManager::GetTexture (const QString &identi cationString ) Vrátí ukazatel na texturu, pokud je jiº nahraná v tomto manaºeru, jinak vrátí NULL. Kaºdý
CDicom3DTexture objekt má p°i°azený identi ka£ní °et¥zec získaný z ID parametru
hlavi£ky DICOM studie. Inkrementuje po£ítadlo pouºití dané textury.
CDicom3DTexture CDicom3DTextureManager::LoadTexture (QString &dicomFileName) Nahraje texturu z medicínské studie DICOM ur£ené jménem prvního souboru. Nejprve na£te DICOM hlavi£ku daného souboru a zjistí identi ka£ní °et¥zec studie. Podle tohoto
38
identi kátoru se pak hledá v seznamu textur, zda jiº není na£tená. Pokud identi ka£ní °et¥zec je²t¥ v seznamu není, tak se vytvo°í nový objekt textury (CDicom3DTexture). Nahrané textury jsou vlastn¥ny tímto správcem textur a ostatním objekt·m jsou pouze zap·j£ovány. Ty by m¥ly volat ReleaseTexture() ve svém destruktoru, p°ípadn¥ kdykoli d°íve, pokud jiº s texturou nebudou pracovat, aby mohla být pam¥´ OpenGL textury uvoln¥na hned, jak je to moºné.
Parametry: dicomFileName jméno souboru obsahující DICOM studii. void CDicom3DTextureManager::ReleaseTexture (CDicom3DTexture *texture) Dekrementuje po£ítadlo pouºití dané textury. V p°ípad¥, ºe toto po£ítadlo dosáhlo nuly, znamená to, ºe textura jiº není pot°eba, objekt textury je tedy smazán a uvolní se i pam¥´ p°íslu²né OpenGL textury.
CDicomHeader
Obrázek 4.6: Diagram spolupráce t°íd pro CDicomHeader.
P°es objekt této t°ídy lze p°istupovat k informacím hlavi£ky formátu DICOM. Informace v hlavi£ce jsou rozd¥leny do modul·: pacient, snímaná série, obraz a snímací za°ízení
39
(viz 4.6). Detailn¥j²í popis a informace o parametrech hlavi£ky jsou k nalezení v dokumentu DICOM standard 3.3 - £ást 3 pod ozna£ením header tags [17]. Lze se nap°íklad podívat na de nice tag· v hlavi£kovém souboru DCMTK knihovny
dcdeftag.h
a pak v
dokumentaci nalézt p°íslu²ný tag (dvojici hexadecimálních £ísel). Do budoucna je moºné snadno roz²í°it podporovaný seznam parametr·.
CDicomSerieData Objekty této t°ídy jsou ur£eny pro udrºení obrazových dat medicínských snímk·. T°ída je schopna na£íst DICOM sérii (medicínské snímky) ze soubor· ve formátu DICOM pomocí API DICOM toolkitu. Slouºí zejména jako p°ístup k obrazovým dat·m DICOM studie pro t°ídu
CDicom3DTexture.
Následuje dokumentace vybraných funkcí této t°ídy:
CDicomSerieData::CDicomSerieData (char lePath, int max3Dsize) Konstruktor objektu volající funkci LoadFrames(), která se pokusí na£íst data medicínských snímk· ur£ených souborem
Parametry:
filePath.
·
lePath Cesta k souboru, z kterého se vychází p°i pokusu o na£tení DICOM studie.
·
max3DSize Maximální rozm¥r na£tených dat ve v²ech t°ech sm¥rech. Je pouºit proto, ºe n¥které gra cké karty mají omezenu velikost 3D textury.
bool CDicomSerieData::LoadDicomImage (char lePath, bool isFirst = false, int frameCount = 0) [private] Na£te DICOM hlavi£ku daného souboru a dále pak obrazová data tohoto souboru. Obrazová data jsou nejprve analyzována a zjistí se zp·sob jejich komprese. Následn¥ se pak data dekomprimují a uloºí se do pam¥ti objektu.
Parametry: ·
lePath Cesta k souboru, který chceme na£íst.
·
isFirst Ur£uje, zda je tento snímek první v sérii. Pokud ano, pak se alokuje pam¥´ pro obrazová data snímk·.
·
frameCount Celkový po£et snímk· série DICOM, kterou na£ítáme. Pro výpo£et velikosti dat k alokaci. Parametr je nutný p°i zpracovávání prvního snímku.
bool CDicomSerieData::LoadFrames (char lePath) [private] Pokusí se na£íst data DICOM série ze zadaného souboru a z dal²ích soubor· ve stejném adresá°i p°íslu²ející stejné studii. Proces probíhá v následujících fázích:
40
1. Zkontroluje se, zda cesta k souboru kon£í p°íponou DCM nebo IMA. Pokud ne, pak funkce vrátí
false.
2. Pokusí se najít n¥jaký odd¥lova£ ('_',
'-')
mezi názvem souboru a indexem oz-
na£ujícím £íslo snímku série. Pokud nenalezne ºádný odd¥lova£, pak se pokusí na£íst pouze jeden soubor a funkce kon£í - prozatím není podporováno na£ítání DICOM soboru obsahujícího více snímk·. 3. V p°ípad¥, ºe odd¥lova£ byl nalezen, tak se cesta k souboru rozd¥lí na £ást p°ed a £ást po rozd¥lova£i. Pak se prochází adresá° vstupního souboru a v²echny názvy soubor·, které mají stejný pre x jako ná² soubor, se p°idají do vektoru. Poté se na kaºdý název z tohoto seznamu volá funkce
LoadDicomImage(),
která se pokusí o na£tení
dat souboru. 4. Provede zpracování na£tených dat funkcí
PerformImageInputDataProcessing().
Parametry: lePath Cesta k souboru, který chceme na£íst. CGLObject
Obrázek 4.7: Diagram t°íd pro CGLObject. P°edek pro v²echny objekty umíst¥né na hlavním OpenGL kontejneru, které jsou práv¥ pomocí OpenGL vykreslovány. Obsahuje základní funkce pro umíst¥ní a zm¥nu velikosti t¥chto objekt·, nastavení ²í°ky okraje a jeho barvy. Dále pak obsahuje funkci pro p°evod z Qt sou°adnic na OpenGL sou°adnice, jejichº osa y je orientována v opa£ném sm¥ru.
41
Kaºdému objektu lze nastavit, zda s ním jde pohybovat, zda lze m¥nit jeho velikost, zda ho lze zav°ít (odstranit) a tímto nastavením se ovlivní zobrazení p°íslu²ných manipula£ních ikon, pomocí kterých lze (po kliknutí my²í na n¥) tyto úkony vykonávat. Tato t°ída obsahuje také základní prototypy funkcí, které jsou spole£né v²em odvozeným t°ídám od tohoto objektu. T¥mi jsou kreslení ohrani£ujícího ráme£ku, vykreslení vnit°ku objektu ur£itou barvou a nastavení parametr· jako jsou velikosti okraj· a jejich barvy. Také obsahuje prototyp funkce pro vybarvení okraje p°i výb¥ru objektu. Nakonec tato t°ída obsahuje £ist¥ virtuální funkce pro OpenGL kreslení (paintGL) a zpracování uºivatelské interakce (prozatím pouze události spojené s my²í). Následuje dokumentace vybraných funkcí této t°ídy:
virtual void CGLObject::paintGL() [pure virtual] CGLWidgetu. Musí být volána uvnit° funkce CGLWidget::paintGL(), která je volána p°i pot°eb¥ p°ekreslit CGLWidget pomocí OpenGL. Implementováno v t°ídách CGLImageExplorer, CGLWorkspaceExplorer, CGLWorkspace, CGLWidget, CGLImage a CGLWorkspaceSnapshot. Funkce, která slouºí pro vykreslení objektu do
void CGLObject::TranslateOpenGLCoords () Provede posun aktuální modelové OpenGL matice na sou°adnice daného objektu. P°edpokládá, ºe aktuální projek£ní plocha OpenGL má velikost hlavního
CGLWidgetu
- tedy
objektu, do kterého se nej£ast¥ji vykresluje. Vzhledem k tomu, ºe ypsilonová sou°adnice je v OpenGL orientována od spodu obrazové pam¥ti (obrazu), zatímco ypsilonová sou°adnice v Qt je orientována od shora obrazovky dol·, tak tato funkce provádí práv¥ p°evod z Qt sou°adnic do OpenGL sou°adnic. Vyuºití má nap°íklad p°i kreslení ráme£ku kolem daného objektu.
CGLImage
Obrázek 4.8: Diagram d¥di£nosti t°íd pro CGLImage. Objekty této t°ídy reprezentují zobrazitelné DICOM studie (série medicínských snímk·). Jsou to
obrázky
(tj. viditelné gra cké prvky referované v OpenGL kontejneru
CGLWidget).
T°ída obsahuje odkaz na trojrozm¥rnou texturu s obrazovými daty (CDicom3DTexture)
42
Obrázek 4.9: Diagram spolupráce t°íd pro CGLImage.
a umoº¬uje zobrazovat 2D projekci °ez· této textury v r·zných rovinách (prozatím podporuje pouze °ezy v základních t°ech rovinách). Tuto 2D projekci lze zv¥t²ovat, upravovat jas a kontrast (Window
center:width)
jejích barev, dále pak lze provád¥t posun °ezu
sm¥rem do hloubky 3D textury a tento posun i animovat pomocí vlastn¥ného anima£ního objektu (CAnimation). Následuje dokumentace vybraných funkcí této t°ídy:
CGLImage::CGLImage (QString & le, QPointF &position, QPointF &size) Konstruktor objektu obrázku. Nejprve se ze správce 3D textur (CDicom3DTextureManager) získá trojrozm¥rná textura (CDicom3DTexture) z obrazových dat medicínských snímk· ur£ených daným souborem. Dal²í inicializace objektu prob¥hne ve funkcích
InitActualSliceOpenGLTexture().
Parametry: 43
Init()
a
·
lePath Cesta k souboru obsahujícímu medicínský snímek.
·
position Sou°adnice, na kterých má být objekt obrázku umíst¥n.
·
size Velikost (²í°ka a vý²ka) objektu obrázku.
CGLImage::CGLImage (CDicom3DTexture texture, QPointF &position, QPointF &size) Konstrukce objektu obrázku z jiº hotového objektu CDicom3DTexture. V podstat¥ se vytvo°í obrázek s obrazovými daty danými parametrem textury. Pouºívá se v p°ípad¥ vytvá°ení kopií obrázku.
Parametry: ·
texture Ukazatel na 3D texturu, na jejímº základ¥ chceme vytvo°it nový objekt obrázku. Vlastnictví se nep°edává - v²echny 3D textury jsou spravovány správcem (CDicom3DTextureManager).
·
position Sou°adnice, na kterých má být objekt obrázku umíst¥n.
·
size Velikost (²í°ka a vý²ka) objektu obrázku.
void CGLImage::Init (QPointF &position, QPointF &size) Inicializace prom¥nných. Nastavení základních pozic obrázku, výchozích hodnot pro orientaci snímk·, základního pojmenování obrázku, vzhled objektu, moºnosti manipulace a nastavení zobrazení informativních text· na obrázku. Poté se provede inicializace základních parametr· obrázku, jako jsou výchozí sou°adnice °ezu texturou, výchozí nastavení zv¥t²ení, konstrastu a jasu. Vytvo°í se textura obrázku (QGLFramebufferObject), na kterou se bude promítat aktuální °ez 3D texturou a provede se první vykreslení °ezu na tuto texturu.
Parametry: ·
position Sou°adnice, na kterých má být objekt obrázku umíst¥n.
·
size Velikost (²í°ka a vý²ka) objektu obrázku.
void SetOrientation(TImageAxisOrientation orientation) Nastaví orientaci °ezu v 3D textu°e. Prozatím jsou podporovány základní t°i typy orientace paraleln¥ s osami (axiální, koronální, sagitální). Po zm¥n¥ orientace °ezu se z pam¥ti nahrají poslední sou°adnice, které byly p°i této orientaci uloºeny a s t¥mito sou°adnicemi se 3D textura vykreslí na texturu obrázku.
44
Obrázek 4.10: Diagram spolupráce t°íd pro CGLImageExplorer.
CGLImageExplorer T°ída slouºící pro správu otev°ených obrázk· a zobrazení jejich náhled· pro moºnou vizuální správu uºivatelem. Uºivatel tak vidí v p°ehledném seznamu DICOM studie, s kterými pracuje a m·ºe je pouºívat na pracovní plo²e. Zav°ením obrázku v tomto správci dojde k zav°ení v²ech obrázk· odvozených od tohoto na v²ech otev°ených pracovních plochách. Následuje dokumentace vybraných funkcí této t°ídy:
void CGLImageExplorer::OpenImage (QString & leName) Pokusí se otev°ít DICOM studii ur£enou jménem souboru, ve které by m¥la být studie uloºena. Funkce vykonává následující kroky: 1. Pokus o otev°ení souboru s DICOM studií a vytvo°ení z ní objekt
CGLImage.
2. Zji²t¥ní pozice pro umíst¥ní dal²ího obrázku do prohlíºe£e. 3. Pokud byl obrázek úsp¥²n¥ na£ten, tak se nastaví jeho atributy, aby s ním uºivatel nemohl manipulovat. 4. Nastaví na£tený obrázek jako aktivní. 5. V ovládacím panelu nastaví jako aktivní pohled pro prohlíºe£ obrázk·. To spole£n¥ s p°edchozím krokem zp·sobí zobrazení informací o nové DICOM studii v panelu a zárove¬ umoºní s touto studií pracovat.
CGLWidget Hlavní gra cký kontejner pro gra cké prvky kreslené pomocí OpenGL. Je to jediný objekt t°ídy
QGLWidget. Jedná se o hlavní £ást programu DICOM Presenter a jsou v n¥m umíst¥ny
následující komponenty:
45
Obrázek 4.11: Diagram spolupráce t°íd pro CGLWidget.
·
Pracovní plocha se zobrazenými obrázky (CGLWorkspace).
·
Prohlíºe£ otev°ených obrázku (CGLImageExplorer).
·
Prohlíºe£ pracovních ploch (CGLWorkspaceExplore).
Tento objekt p°ijímá v²echny události my²i a podle polohy kurzoru nastaví aktivní objekt a tomu události p°eposílá. P°i pot°eb¥ p°ekreslit jeho obsah se volá funkce
paintGL(), která
se stará o vykreslení v²ech vlastn¥ných objekt·. Dal²í funkcí tohoto objektu je pak správa textur pro ikony ovládání objekt· (CGLObject) a správa OpenGL shader·, tj. program· provád¥ných gra ckou kartou. Následuje dokumentace vybraných funkcí této t°ídy:
void CGLWidget::initializeGL () [protected] Jde o funkci, která je zavolána po tom, co je inicializován subsystém OpenGL, aby mohly být inicializovány komponenty na tomto subsystému závislé. Od této chvíle je uº moºné volat libovolné funkce OpenGL API. Konkrétn¥ se ve funkci provedou následující úkony:
·
Nahrají se textury pro ikony ovládání OpenGL objekt· (InitIconTextures()).
·
Provede se inicializace OpenGL shader· pouºívaných v tomto programu.
·
Spustí se subsystém kreslení font·.
46
·
Vytvo°í se singleton instance t°íd prohlíºe£e obrázk· (CGLImageExplorer) a pracov-
ních ploch (CGLWorkspaceExplorer).
void CGLWidget::InitIconTextures () [protected] Nahraje textury ikon (zav°ít, posun, zm¥na velikosti), které slouºí uºivateli k manipulaci s objektem. Tyto ikony jsou pak dostupné ostatním t°ídám v programu p°es metody sigletonu
GetMoveIconTexture(), GetResizeIconTexture()
a
GetCloseIconTexture().
void CGLWidget::InitShaders () [protected] Nejprve inicializuje Cg subsystém. Poté nahraje shadery pouºívané v programu pro zm¥nu barevných vlastností textur. T¥mi jsou v na²em p°ípad¥ kontrast a jas (scale, bias). Tyto programy jsou pak provád¥ny p°ímo procesory gra cké karty (stream processor). Jedná se o fragment (pixel) shadery, tedy shadery pracující s barevnými sloºkami obrazových bod·.
void CGLWidget::ResetGLView () Nastaví zobrazovací pole (viewport ) a projek£ní
matici OpenGL na celou plochu tohoto
kontejneru. Rozm¥ry projek£ní plochy pak odpovídají p°esn¥ rozm¥r·m jeho plochy (v pixelech), díky £emuº je moºné jednodu²e renderovat objekty, které jsou v n¥m umíst¥né.
CGLWorkspace
Obrázek 4.12: Diagram spolupráce t°íd pro CGLWorkspace. T°ída reprezentující pracovní plochu v OpenGL kontejneru. Tento pracovní prostor je ur£en k tomu, aby do n¥j mohly být rozmís´ovány jednotlivé obrázky medicínských studií a aby je mohl uºivatel snadno porovnávat a manipulovat s nimi. Lze vytvo°it hned n¥kolik na sob¥ nezávislých pracovních ploch, které jsou vizuáln¥ i logicky (pam¥´ov¥)
CGLWorkspaceExplorer. Pracovní plocha má CWorkspaceLayout, takzvaný layout (správce rozmíst¥ní), pomocí kterého
spravovány pomocí správce pracovních ploch p°i°azen objekt
47
jsou obrázky na plochu rozmís´ovány. Tento objekt také vlastní v sob¥ umíst¥né objekty
CGLImage. Následuje dokumentace vybraných funkcí této t°ídy:
void CGLWorkspace::AddImage (CGLImage image) P°idá objekt obrázku do seznamu obrázk· spravovaných danou pracovní plochou. Správce rozmíst¥ní vybere vhodné místo a velikost pro umíst¥ní nového obrázku na pracovní oblasti a její gra ka se p°ekreslí.
void CGLWorkspace::RemoveImage (CGLImage image) Odebere objekt obrázku do seznamu obrázk· spravovaných danou pracovní plochou. Správce rozmíst¥ní zjistí, zda není moºné ud¥lat n¥jaké automatické zm¥ny pozic a velikostí zbývajících obrázk· a p°ípadn¥ je provede. Gra ka pracovní oblasti se p°ekreslí, aby re ektovala provedené zm¥ny.
void CGLWorkspace::SaveTexture (const QString & leName, const QPoint &size) Nejprve vykreslí texturu pracovní plochy, aby obsahovala nejaktuáln¥j²í stav obrázk· uvnit°. Pak tuto aktuální texturu zapí²e do souboru.
CGLWorkspaceExplorer T°ída slouºící pro správu pracovních ploch a pro zobrazování jejich náhled· zastoupených objektem (CGLWorkspaceSnapshot) v p°ehledném seznamu v dolní £ásti OpenGL kontejneru. Pro vykreslení náhled· v seznamu se pouºívají textury pracovních ploch, kterým tyto náhledy náleºí. Následuje dokumentace vybraných funkcí této t°ídy:
void CGLWorkspaceExplorer::AddWorkspace (CGLWorkspace *workspace) P°idá danou pracovní plochu do prohlíºe£e. Ten bude tuto plochu spravovat a zobrazovat její snímek. Vypo£te se také pozice za p°edchozími náhledy pracovních ploch a na této pozici se náhled vykreslí.
void CGLWorkspaceExplorer::paintGL () [virtual] Funkce, která slouºí pro vykreslení objektu prohlíºe£e do OpenGL kontejneru. Nejprve se nakreslí vlastní prohlíºe£ - tedy jeho výpl¬ a okraje. Dále se pak procházejí v²echny obsaºené pracovní plochy a vykreslují se jejich p°íslu²né náhledy v p°ípad¥, ºe jsou umíst¥ny ve viditelné oblasti seznamu. V této funkci se také p°epo£ítají hodnoty pro správnou
48
funkcionalitu posuvníku (
Scrollbaru ), pomocí kterého se lze pohybovat mezi náhledy pra-
covních ploch v p°ípad¥, ºe jejich celková velikost p°esahuje velikost prohlíºe£e. Snímek vybrané pracovní plochy se je²t¥ zvýrazní funkcí
DrawSelectedSnapshot().
void CGLWorkspaceExplorer::RemoveWorkspace (CGLWorkspace workspace) Odebere danou pracovní plochu z prohlíºe£e. Tím pádem se zni£í i v²echny objekty obrázk·, které této pracovní plo²e náleºely. Odstraní také náhled dané plochy z prohlíºe£e a p°esune náhledy zbývajících ploch, pokud po té odstran¥né zbylo v seznamu místo.
void CGLWorkspaceExplorer::SetActiveWorkspace (CGLWorkspace workspace) Nastaví danou pracovní plochu jako aktivní a její obsah se zobrazí v OpenGL kontejneru. Znovu se spustí animace, které náleºí obrázk·m této pracovní plochy a které nejsou zrovna pozastaveny.
CSettings Tato t°ída slouºí k ukládání a na£ítání nastavení parametr· programu z a do souboru. Vyuºívá Qt t°ídy
QSettings,
která je ur£ená k uchovávání parametr· aplikace mezi jejími
r·znými spu²t¥ními. V²echny metody této t°ídy jsou statické a ve°ejné. Parametry lze nastavit také p°ímo v souboru
DicomPresenter.ini,
který slouºí práv¥ jako trvalá pam¥´
parametr· programu. Následuje seznam parametr·, jejichº ukládání je podporováno:
·
Lze nastavit velikost OpenGL textury pro pracovní plochu. ím v¥t²í jsou rozm¥ry této textury, tím náro£n¥j²í jsou poºadavky na gra cký hardware.
·
Lze omezit po£et snímk·, které se nahrávají v rámci jedné DICOM série.
·
Velikosti okraj· a mezer mezi jednotlivými prvky v ovládacím panelu.
·
Velikosti okraj·, barvy výplní a barvy okraj· v²ech objekt· t°ídy
·
Pro prohlíºe£ otev°ených studií i pro prohlíºe£ pracovních ploch lze je²t¥ nastavit
CGLObject.
barvu textu, kterou se bude vykreslovat nápis v jejich titulku.
CWorkspaceLayout Základní t°ída pro v²echny typy správc· rozmíst¥ní komponent na pracovní plo²e. Takový správce rozmíst¥ní slouºí k tomu, aby uºivateli pomohl snadno rozmístit obrázky na pracovní plo²e, v p°ípad¥ p°idání nového £i odebrání stávajícího. M·ºe také pomoci s automatickým ukotvením obrázku ke stranám pracovní plochy, dále se zarovnáním jeho polohy vedle jiných obrázk· v pracovní plo²e, atd. Provedení rozmíst¥ní lze také libovoln¥ zavolat na poºádání (Do()). Následuje dokumentace vybraných funkcí této t°ídy:
49
virtual bool CWorkspaceLayout::AddImage (CGLImage image)[pure virtual] Poºadavek na umíst¥ní nového obrázku do stávajícího rozmíst¥ní. Funkce je volána p°i p°idání obrázku do pracovní plochy.
virtual void CWorkspaceLayout::Do () [pure virtual] Rozmístí objekty obrázku do základního postavení p°íslu²ného danému rozmíst¥ní. Funkce je volána v okamºiku nastavení daného rozmíst¥ní pracovní plo²e.
void CWorkspaceLayout::ImageMovedAlignToOtherImages(CGLImage image) [protected, virtual] Zarovná umíst¥ní obrázku vedle ostatních obrázk· v pracovní plo²e. Funkce zabezpe£uje, aby obrázek nep°esahoval hranice ostatních obrázk·.
void CWorkspaceLayout::ImageMovedAlignToWorkspace (CGLImage image) [protected, virtual] Zarovná umíst¥ní obrázku do pracovní plochy. Funkce zabezpe£uje, aby obrázek nep°esahoval hranice pracovní plochy, po tom, co se obrázek p°esunul.
void CWorkspaceLayout::ImageResizedAlignToOtherImages (CGLImage image) [protected, virtual] Zarovná velikost obrázku uvnit° pracovní plochy. Funkce zabezpe£uje, aby obrázek nep°esahoval hranice ostatních obrázk·.
void CWorkspaceLayout::ImageResizedAlignToWorkspace (CGLImage image) [protected, virtual] Zarovná velikost obrázku do rozm¥r· pracovní plochy. Funkce zabezpe£uje, aby obrázek nep°esahoval hranice pracovní plochy, po tom, co obrázek zm¥nil velikost.
virtual void CWorkspaceLayout::RemoveImage (CGLImage image) [pure virtual] Poºadavek na odebrání obrázku ze stávajícího rozmíst¥ní. Funkce je volána p°i odebrání obrázku z pracovní plochy.
CFreeLayout Správce rozmíst¥ní umoº¬ující libovolné rozloºení obrázk· na pracovní plo²e. Obrázk·m je moºno nastavit libovolnou pozici i velikost. Mohou být umíst¥ny i p°es sebe. Tento správce rozmíst¥ní pomáhá se zarovnáváním obrázk· vedle sebe a do pracovní plochy, pokud se o to uºivatel snaºí.
50
CGrowingGridLayout Správce rozmíst¥ní, který uspo°ádává objekty obrázk· do tabulky (m°íºky). Pokud je m°íºka p°íli² malá (nový objekt se do ní nevejde), pak se do m°íºky p°idá nový °ádek (p°ípadn¥ sloupec) a objekty se znovu rozmístí. Objekty v m°íºce se nep°ekrývají a navazují na sebe. Zm¥na velikosti jednoho objektu ovlivní ostatní ve stejném sloupci a °ádku. Objekty je moºno p°esunovat do volných pozic v m°íºce nebo si dva obrázky v m°íºce mohou prohodit své pozice navzájem. Následuje dokumentace vybraných funkcí této t°ídy:
bool CGrowingGridLayout::AddImage (CGLImage image) [virtual] Poºadavek na umíst¥ní nového obrázku do stávajícího rozmíst¥ní. Funkce je volána p°i p°idání obrázku do pracovní plochy. V tomto rozmíst¥ní jsou obrázky zarovnány do tabulky, která umí dynamicky m¥nit sv·j rozm¥r a podle následujícího algoritmem: 1. Za£íná se s tabulkou o 1 sloupci a bez °ádk·. 2. P°i vloºení obrázku do rozmíst¥ní se tabulka postupn¥ plní, dokud jsou v ní volná místa. 3. V p°ípad¥, ºe jiº v tabulce není místo, tak se do tabulky doplní: (a) Dal²í °ádek, pokud se naposledy p°idal sloupec. (b) Dal²í sloupec, pokud se naposledy p°idal °ádek.
void CGrowingGridLayout::Do () [virtual] Rozmístí objekty obrázku do základního postavení p°íslu²ného danému rozmíst¥ní. Smaºe tabulku pro obrázky a za£ne ji tvo°it znovu, jakoby postupn¥ p°idává obrázky pomocí funkce
AddImage.
void CGrowingGridLayout::ImageIsMoving (CGLImage image)[virtual] Funkce volaná po kaºdém posunu objektu obrázku po pracovní plo²e. Zarovná pozici objektu obrázku do tabulky (V p°ípad¥, ºe pozice m°íºky tabulky jsou poblíº pozice manipulovaného obrázku). Zjistí, zda daná manipulace s obrázkem je v rámci rozmíst¥ní povolena a podle toho upraví stav obrázku. Je dovoleno p°esouvat obrázek jen v rámci tabulky na p°esné pozice sloupc· a °ádk·. V p°ípad¥, ºe obrázek je p°esouván na pozici, na které je jiº umíst¥n jiný obrázek, pak se tyto dva prohodí.
void CGrowingGridLayout::ImageIsResizing(CGLImage image) [virtual] Funkce volaná po kaºdé zm¥n¥ velikosti objektu obrázku. Zajistí zarovnání velikosti na hranice pracovní plochy. Dále pak upraví velikosti v²ech obrázk· ve stejném sloupci, aby m¥ly stejnou ²í°ku, jako je nová ²í°ka manipulovaného obrázku. Stejn¥ tak upraví vý²ku v²ech obrázk· ze stejného °ádku.
51
void CGrowingGridLayout::ImageMoveFinished (CGLImage *image) [virtual] Funkce volaná v okamºiku, kdy uºivatel p°estal hýbat s objektem obrázku. Dokon£í se p°esun objektu podle toho, zda je £i, není moºný. Pokud do²lo k prohození obrázk·, tak se toto prohození provede a pozice obrázk· se zarovnají do tabulky.
void CGrowingGridLayout::RemoveImage(CGLImage *image) [virtual] Poºadavek na odebrání obrázku ze stávajícího rozmíst¥ní. Funkce je volána p°i odebrání obrázku z pracovní plochy. Pokud jsou odstran¥ny v²echny obrázky z jednoho sloupce, resp. °ádku, pak se tento sloupec, resp. °ádek odstraní a rozmíst¥ní se provede znovu.
MainWindow
Obrázek 4.13: Diagram spolupráce t°íd pro MainWindow.
Objekt této t°ídy je hlavním oknem aplikace. T°ída je odvozena od Qt objektu
QMainWindow.
Pouºitím Qt frameworku je pak inicializace aplikace velice jednoduchá a probíhá následovn¥:
int main(int argc, char *argv[]) { QApplication a(argc, argv); MainWindow w; w.show(); int res= a.exec(); return res; }
52
Kapitola 5 Uºivatelská p°íru£ka programu DICOM Presenter 5.1
Instalace v MS Windows
Microsoft Visual C++ ve verzi Express Edition, která je dostupná zdarma, neumoº¬uje vytvá°ení instala£ních balí£k· pro naprogramované aplikace. Nejkorektn¥j²í cestou k p°enosu programu na jiný po£íta£ je nainstalovat na tomto po£íta£i Visual C++ Express Edition a celý projekt na n¥m znovu zkompilovat. Seznam soubor· nutných pro správný b¥h aplikace:
· cg.dll, cgGL.dll · closeicon.bmp, resizeicon.bmp, moveicon.bmp
soubory textur pro manipu-
la£ní ikony
· DicomPresenter.exe · DicomPresenter.ini · EasyBMPtoAVI.exe
soubor s nastaveními programu
program konvertující sérii bitmap na video
· fragment_shader_bias_scale2D.cg, fragment_shader_bias_scale3D.cg Shadery pro úpravu barev OpenGL textur
· glew32.dll · QtCore4.dll/QtCored4.dll · QtGui4.dll/QtGuid4.dll · QtOpenGL4.dll/QtOpenGLd4.dll · Times-Roman.txf
font pro knihovnu PLib
53
5.2
První spu²t¥ní
Po spu²t¥ní programu se nám zobrazí obrazovka s rozloºením gra ckých prvk· jako na obrázku 5.1. Jednotlivé komponenty v²ak budou prázdné. Zde jsou v programu otev°eny dv¥ studie a rozpracovány 3 pracovní plochy pro lep²í p°edstavu vzhledu programu. Na obrázku
Obrázek 5.1: Snímek programu Dicom Presenter je vid¥t hlavní okno aplikace s titulkem. Toto okno se d¥lí na 2 £ásti. V pravé £asti je sloupcový ovládací panel (viz. 5.5). Levou a hlavní £ást okna pak vypl¬uje kontejner zobrazující medicínské snímky. Tento kontejner se d¥lí na 3 £ásti. Nejv¥t²í £ást vlevo naho°e zaujímá pracovní plocha (viz 5.4). Dole je umíst¥n prohlíºe£ pracovních ploch (viz 5.4) a vpravo je prohlíºe£ otev°ených DICOM studií (5.3).
54
5.3
Na£tení medicínských dat
Program podporuje na£ítání soubor· ve formátu DICOM (p°ípony IMA a DCM). Pro otev°ení studie lze pouºít jednu ze t°í následujících moºností: 1. Z
Menu
vybrat
File -> Open...
2. V ovládacím panelu stisknout tla£ítko
Open Dicom File.
3. Dvojklikem levým tla£ítkem my²i na plochu prohlíºe£e otev°ených studií. Poté se zobrazí dialogové okno umoº¬ující výb¥r souboru pro otev°ení. Dicom Presenter se pak pokusí na£íst v²echny soubory z adresá°e p°íslu²ející stejné studii. Probíhá to tak, ºe program prohledá adresá° tohoto souboru a zjistí, zda v n¥m jsou soubory se stejným jménem aº na £íselný index za n¥jakým odd¥lova£em, poml£kou, nebo podtrºítkem. Pokud ano, tak dále p°edpokládá, ºe tyto indexy budou postupn¥ r·st vºdy o 1. Následují p°íklady dvou struktur soubor·, s kterými si program poradí:
IM-0001-0001.dcm IM-0001-0002.dcm IM-0001-0003.dcm IM-0001-0004.dcm IM-0001-0005.dcm brain_001.dcm brain_002.dcm brain_003.dcm brain_004.dcm brain_005.dcm Pak se tyto soubory otev°ou a z jejich hlavi£ky se zji²´uje id studie, která musí být u v²ech studií stejná jako u první, zadané uºivatelem. Program v pr·b¥hu na£ítání zobrazuje malé okno s ukazatelem pr·b¥hu na£ítání a s tla£ítkem umoº¬ujícím na£ítání p°eru²it (viz obr. 5.2). Po p°eru²ení se p°estanou na£ítat dal²í snímky série, ale i p°esto se studie otev°e. Tady je pot°eba dát si pozor v p°ípad¥, ºe byste cht¥li otev°ít studii znovu, ale tentokrát na£íst více snímk· série. To se nepoda°í, dokud p·vodní studii nezav°ete z prohlíºe£e otev°ených studií. Pr·b¥h na£ítání je také zobrazován ve standardním výstupu, kde jsou uvedeny i podrobn¥j²í informace o pr·b¥hu na£ítání. Pokud se na£ítání studie nebo vytvo°ení 3D textury z této studie nezda°í, uºivateli se zobrazí modální okno s upozorn¥ním. Na£ítání se nemusí zda°it nap°íklad kv·li ²patnému formátu obrazových dat, nebo kv·li nedostatku gra cké pam¥ti pro uchování celé studie v 3D textu°e. První snímky v²ech úsp¥²n¥ na£tených studií se pak zobrazují v seznamu v prohlíºe£i otev°ených studií. Tady lze jednotlivé studie vybírat a pak s nimi dále pracovat. Pro zav°ení studie sta£í kliknout my²í na ikonku k°íºku v pravé horní £ásti obrázku.
55
Obrázek 5.2: Ukazatel pr·b¥hu na£ítaní studie
5.4
Pracovní plocha
Pracovní plocha slouºí uºivateli pro zobrazování r·zných pohled· na otev°ené medicínské studie a umoº¬uje je sestavovat do libovolných uspo°ádání. Pracovních ploch lze mít otev°eno více najednou. O jejich správu se stará prohlíºe£ pracovních ploch. V tom je zobrazen seznam otev°ených pracovních ploch. Po spu²t¥ní programu je p°ístupná pouze jedna plocha a dal²í lze p°idat dvojklikem na oblast prohlíºe£e pracovních ploch. Odebrání pracovní plochy se provadí kliknutím levým tla£ítkem my²i na ikonku k°íºku v pravé horní £ásti náhledu pracovní plochy. Kliknutím na náhled pracovní plochy ji vybereme. Obrázek lze na pracovní plochu p°idat následujícím postupem. Nejprve se v prohlíºe£i otev°ených studií vybere studie, s níº chceme pracovat. V ovládacím panelu je pak k dispozici tla£ítko
Create Copy, jehoº stisk zp·sobí vytvo°ení kopie obrázku studie na práv¥
vybranou pracovní plochu. Obrázky se na pracovní plochu umís´ují podle toho, jaký správce rozmíst¥ní má pracovní plocha nastavený. Ten je moºné vybrat v ovládacím panelu (viz. 5.5). Uºivatel m·ºe obrázky v pracovní plo²e p°esunovat a m¥nit jejich velikost uchycením za p°íslu²né ikony. V levém horním rohu se nachází ikonka pro posun objektu, vpravo dole poté pro zm¥nu velikosti. Posun a zm¥na velikostí objektu je ovlivn¥na zvoleným správcem rozmíst¥ní, který uºivateli pomáhá s p°izp·sobením se ostatních objekt· na plo²e. Na p°íkladech na obrázcích (5.3, 5.4 a 5.3) si ukáºeme, jak probíhá p°esunování a zm¥na velikosti objekt· v p°ípad¥ pouºití m°íºkového správce rozloºení. Ve v²ech p°ípadech je manipulováno s obrázkem v levém horním rohu a na obrázku je £ervenou elipsou vyzna£ena poloha ukazatele my²i. Na prvním obrázku (5.3) je ukázán nepodporovaný posun obrázku mimo m°íºku rozloºení. Proto je obrázek zbarven £ervenou barvou. V tuto chvíli by se obrázek po uvoln¥ní tla£ítka my²i vrátil zp¥t do své výchozí polohy v levém horním rohu. Na obrázku (5.4) je proveden posun obrázku aº na místo jiného obrázku v m°íºce, toho vpravo dole. V tuto chvíli se jedná o p°esun, který je správcem rozloºení podporován a proto se dané dva obrázky po uvoln¥ní tla£ítka prohodí. Znázorn¥nou zeleným zabarvením. Obrázek (5.5) ukazuje zm¥nu velikosti objekt· pomocí uchycení za ikonku dvojité ²ipky. P°ed zm¥nou velikosti m¥ly v²echny stejnou velikost a na obrázku je vid¥t, jak zm¥na velikosti jednoho objektu ovlivní i ostatní, kv·li zachování m°íºkového rozloºení.
56
Obrázek 5.3: Nedovolený p°esun obrázku.
Nakonec je je²t¥ na obrázku (5.6) ukázáno jakého rozloºení lze dosáhnout v p°ípad¥ pouºití volného rozmíst¥ní.
5.5
Ovládací panel
Ovládací panel v Dicom Presenteru má t°í r·zná rozloºení ovládacích prvk· a s ní spojenou i rozdílnou funkcionalitu. Ta se li²í podle toho, jaká £ást hlavního kontejneru je aktivní. Tedy zda pracovní plocha, prohlíºe£ otev°ených snímk·, nebo prohlíºe£ pracovních ploch. Vzhled panelu se vºdy poskládá z n¥kolika z následujících kontejner·:
· Workspace properties
Vlastnosti týkající se pracovní plochy. Obsahuje textové pole,
kam lze zadat pojmenování pro pracovní plochu. Defaultn¥ jsou jména tvaru WS:£íslo pracovní plochy. Obsahuje také rozbalovací seznam s výb¥rem správc· rozmíst¥ní.
· Dicom Header Jedná se o tabulku zobrazující dvojici parametr a jeho hodnota ur£itých tag· z hlavi£ky souboru DICOM.
· Global Animation Panel Panel slouºící k ovládání v²ech aktivních animací na aktuální
Pause All a restarto(Speed factor).
pracovní plo²e. Obsahuje moºnost v²echny animace pozastavit ( vat (
Restart All).
Lze také nastavit rychlost probíhání animací
· Image Info Vlastnosti týkající se ozna£eného obrázku. Obsahuje textové pole, kam lze zadat jeho pojmenování. Defaultn¥ jsou jména tvaru Im:£íslo pracovní plochy.
Dále obsahuje rozbalovací seznam s výb¥rem orientace °ezu 3D texturou (Axial,Sagittal, Coronal) a za²krtávací pole pro nastavení, zda zobrazovat textové informace p°ímo v obrázku. Jedná se o zobrazení orientace (Left, Right, Anterior, Posterior, Head, Feet), dále zobrazení m¥°ítka (zoom), kontrastu a jasu (window center/ width (C/W)), £ísla snímku série (Frame nr.). M¥°ítko, kontrast a jas a také £íslo snímku lze i v tomto kontejneru p°ímo nastavit.
57
Obrázek 5.4: Povolený p°esun obrázku.
· Animation Properties
Kontejner obsahující nastavení animace vybraného obrázku.
Animace je defaultn¥ vypnuta a povolit ji lze za²krtnutím
Animation properties. Tím
se animace spustí a aktivují se dal²í nastavení pro animaci jako jsou £ísla snímk·, mezi kterými animace pob¥ºí a £asový interval p°echodu mezi snímky.
· Opened Image properties V tomto panelu jsou zobrazeny informace o obrázcích odvozených z vybrané DICOM studie. V seznamu je zde uvedena vºdy dvojice jméno pracovní plochy a jméno obrázku. Dvojklikem na poºadovaný °ádek dojde k výb¥ru daného obrázku s p°ípadným p°esunem na jinou pracovní plochu. V následujícím seznamu uvedu, které z p°edcházejících kontejner· jsou zobrazeny v kterém ze t°í moºných vzhled· ovládacího panelu. Pro p°edstavu jsou tyto panely zobrazeny na obrázku (5.7) a jsou to zleva:
·
Create new workspace),
Workspace Tla£ítko pro vytvo°eni nové pracovní plochy (
Workspace Properties), globální anima£ní panel Global animation panel) a tabulku s informacemi z DICOM hlavi£ky (Dicom Header).
atributy vybrané pracovní plochy ( (
·
Workspace Properties), inforImage Info), anima£ní panel obrázku (Animation properties), globální anima£ní panel (Global animation panel) a tabulku s informacemi z DICOM hlavi£ky (Dicom Header). Workspace Explorer Atributy vybrané pracovní plochy, (
mace o obrázku (
·
Open Dicom Image), seznam odvozených obrázk· (Opened Image Properties), informace o obrázku (Image Info), anima£ní panel obrázku (Animation properties), globální anima£ní panel (Global animation panel) a tabulku s informacemi z DICOM hlavi£ky (Dicom Header). Image Explorer Tla£ítko pro otev°ení nové studie (
58
Obrázek 5.5: Zm¥na velikosti obrázku.
5.6
Image
V této £ásti jsou sepsány operace, které je moºné s obrázkem studie provád¥t a je také popsán zp·sob, jak toho docílit. V¥t²ina operací nad ur£itými hodnotami je dostupná jak pomocí my²i, tak z ovládacího panelu. Výhoda ovládacího panelu je v moºnosti nastavit hodnoty p°esn¥, takºe je moºné snadno nastavit více obrázk·m stejné hodnoty.
Posun obrázku Obrázek lze ve svém okn¥ posunovat tahem my²í za stisku levého tla£ítka.
Zm¥na m¥°ítka Obrázek lze p°ibliºovat nebo oddalovat pomocí tahu my²í sm¥rem dop°edu a dozadu za stisku prost°edního tla£ítka. St°ed ²kálování je pak na pozici kurzoru my²i. Zm¥nu m¥°ítka
zoom).
je také moºné nastavit v ovládacím panelu (
Okn¥ní obrázku Obrázku lze m¥nit jas a kontrast, £emuº se °íká okn¥ní (viz. 3.2. Hodnota ovliv¬uje jas a
width
center
pak
kontrast. Tyto hodnoty lze m¥nit bu¤ z ovládacího panelu, nebo
tahem my²í za stisku pravého tla£ítka. Posun zleva doprava sniºuje kontrast a posun shora dol· sniºuje jas.
Zm¥na orientace Obrázek je po na£tení zobrazen jako axiální °ez 3D texturou. Orientaci °ezu lze zm¥nit výb¥rem z ovládacího panelu.
59
Obrázek 5.6: Volné rozmíst¥ní obrázk· na plo²e.
Posun °ezu do hloubky Posun °ezu do hloubky 3D textury (podle orientace °ezu) lze provád¥t t°emi zp·soby. Prvním z nich je rolováním kole£ka my²i. Druhým je v ovládacím panelu nastavit poºadované
Frame nr.). Nebo lze v objektu obrázku zobrazit posuvník (za²krtnout k°íºek p°ed poloºkou (Frame nr.) a pak kliknutím na posuvník se nastaví snímek (°ez) odpovídající
£íslo snímku (
pozici na posuvníku (viz obrázek 5.8).
5.7
Animace
Obrázky medicínských studií lze animovat ve smyslu zm¥ny polohy °ezu v hloubkové sou°adnici 3D textury. Ovládání animace je uskute£¬ováno za pomocí ovládacího pan-
Animation properties. Animace je defaultn¥ vypnuta a povolit ji lze za²krtnutím polí£ka Animation properties. Tím se animace spustí a aktivují se dal²í naselu, konkrétn¥ kontejneru
tavení pro animaci jako jsou £ísla snímk·, mezi kterými animace pob¥ºí a £asový interval p°echodu mezi snímky. Lze spustit animace pro více obrázk· najednou a ty lze pak mezi sebou synchronizovat pomocí panelu
Global animation panel tla£ítkem pro restart v²ech animací. V tomto panelu
je také moºnost pozastavit v²echny probíhající animace.
5.8
Export
Program umoº¬uje 2 druhy exportu práce do souboru. Prvním z nich je export statického snímku pracovní plochy do souboru. V
Menu
vybereme
File
a
Save workspace as bitmap
a
zobrazí se dialog umoº¬ující nastavení exportu (viz obr. 5.9). V tomto dialogu je moºné nastavit cílové rozli²ení exportovaného obrázku. P°i£emº lze za²krtnutím nastavit, zda se má zachovat p·vodní pom¥r stran.
60
Obrázek 5.7: T°i typy rozmíst¥ní komponent na ovládacím panelu.
Druhou moºností je export animací probíhajících na pracovní plo²e. V
File
a
Save workspace animation
Menu vybereme
a zobrazí se dialog umoº¬ující nastavení exportu (viz obr.
5.10). V tomto dialogu je moºné nastavit cílové rozli²ení exportovaného videa a i zde je volba zachování pom¥ru stran. Navíc lze nastavit i po£et snímk· za vte°inu výsledného videa a zda se mají ponechat statické bitmapy vytvo°ené v pr·b¥hu operace.
61
Obrázek 5.8: Zm¥na snímku (°ezu) tahem my²í po posuvníku.
Obrázek 5.9: Dialog pro nastavení parametr· exportu snímku.
Obrázek 5.10: Dialog pro nastavení parametr· exportu animace.
62
Kapitola 6 Záv¥r V této diplomové práci byl naprogramován framework umoº¬ující zobrazovat medicínská data. V n¥m jsou obrázky studií reprezentovány objekty na pracovní plo²e, s kterými m·ºe uºivatel snadno manipulovat (m¥nit jejich polohu a velikost). Framework dokáºe provád¥t základní funkce nad obrazovými daty, jako je zm¥na konstrastu a jasu, zm¥na m¥°ítka obrazu a animování p°echodu mezi jednotlivými snímky série medicínských dat. Výsledky práce lze v gra cké podob¥ exportovat do soubor·. Pomocí tohoto frameworku byl vytvo°en program, který dokáºe na£íst série medicínských studií ze soubor· DICOM formátu. Práce spo£ívala nejen v programovací £ásti, ale p°ed tím také v prozkoumávání moºností, jaké technologie pro vývoj pouºít. Tento pr·zkum byl provedem za ú£elem vytvo°it framework tak, aby zobrazování a operace se snímky byly sviºné a vyuºívali dnes dostupné moºnosti gra ckého hardwaru. Toho jsem docílil vyuºítí knihovny OpenGL, která podporuje hardwarovou akceleraci pro práci z obrazovými daty a knihovny Cg, pomocí které lze psát programy p°ímo pro gra cké karty. Do budoucna se nabízí nap°íklad moºnost vyuºít zakomponování shader· pro r·zné ltry nad obrazovými daty. Pomocí shader· je moºné paraleln¥ vykonávat operace nad pixely a tím tyto operace urychlit. Bylo by dobré pro²et°it metody umoº¬ující segmentaci obrazových dat pomocí GPU (procesoru gra cké karty) a vyuºít tak paralelizace pro tyto a p°ípadn¥ dal²í ú£ely. Inspiraci lze nalézt na internetu a zdá se, ºe moºnosti takového zpracování obrazu jiº existují. Jist¥ by pomocí shader· ²ly naprogramovat barevné ltry pro odli²ení jednotlivých struktur lidských orgán·, takzvané barevné mapy. Sou£asný program postrádá moºnost uloºit rozpracovanou fázi práce s obrázky a pracovní plochou. Naskýtá se tak moºnost navrhnout a vytvo°it n¥jaký zp·sob ukládání práce na disk. Pro pot°eby institutu IKEM by bylo dobré v budoucnu vytvo°it klienta pro získávání dat z DICOM server· a moºnost získané studie t°ídit do logicky strukturovaných a pojmenovaných adresá°· s moºností p°idávat do soubor· vlastní tagy a podobn¥. Dále se nabízí prozkoumat jak zrychlit na£ítání studií z DICOM sobor·. Pro dosaºení tohoto cíle by se musely otestovat dal²í knihovny pracující s DICOM soubory, nebo by se musel naprogramovat úpln¥ vlastní modul, který by obrazová data ze soubor· rychle na£etl a následn¥ dekomprimoval pomocí existujících knihoven.
63
Bohuºel v rámci diplomové práce nebylo v mé moci stihnout v²echny p°edloºené návrhy, a tak nezbývá neº p°enechat dal²í vývoj aplikace n¥komu jinému. Práce na tomto programu je nejen velmi zajímavá a £asto i pom¥rn¥ zábavná, jako nap°íklad p°i práci s gra kou a zpracováním obrazu. Zárove¬ je pot°eba mít na pam¥ti, ºe program by m¥l být nasazen v pom¥rn¥ d·leºité oblasti medicíny a je tedy nutné k vývoji takového softwaru p°istupovat s velkou obez°etností a £asto detailn¥ studovat p°edepsané standardy. Implementace programu je na p°iloºeném CD.
64
Seznam obrázk· 2.1
Skenovací za°ízení MR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.2
Sagitální snímek mozku získaný magnetickou rezonancí.
. . . . . . . . . . .
16
3.1
R·zná nastavení jasu a kontrastu . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
Rozloºení obrázk· typické pro v¥t²inu program·. Vlevo naho°e axiální °ez, vpravo naho°e sagitální °ez, vlevo dole koronální °ez a vpravo dole bývá trojrozm¥rné zobrazení. V tomto p°ípad¥ je zde op¥t sagitální °ez. . . . . . .
21
4.2
Výstup ukázkové Qt aplikace. . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Schéma funkcionality programu . . . . . . . . . . . . . . . . . . . . . . . . .
30
4.4
Schéma gra ckého rozhraní
. . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.5
Diagram t°íd pro CDicom3DTexture. . . . . . . . . . . . . . . . . . . . . . .
37
4.6
Diagram spolupráce t°íd pro CDicomHeader.
. . . . . . . . . . . . . . . . .
39
4.7
Diagram t°íd pro CGLObject. . . . . . . . . . . . . . . . . . . . . . . . . . .
41
4.8
Diagram d¥di£nosti t°íd pro CGLImage.
42
4.9
Diagram spolupráce t°íd pro CGLImage. . . . . . . . . . . . . . . . . . . . .
43
4.10 Diagram spolupráce t°íd pro CGLImageExplorer. . . . . . . . . . . . . . . .
45
4.11 Diagram spolupráce t°íd pro CGLWidget.
46
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . .
4.12 Diagram spolupráce t°íd pro CGLWorkspace.
. . . . . . . . . . . . . . . . .
47
. . . . . . . . . . . . . . . . . .
52
5.1
Snímek programu Dicom Presenter . . . . . . . . . . . . . . . . . . . . . . .
54
5.2
Ukazatel pr·b¥hu na£ítaní studie
. . . . . . . . . . . . . . . . . . . . . . . .
56
5.3
Nedovolený p°esun obrázku. . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
5.4
Povolený p°esun obrázku.
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
5.5
Zm¥na velikosti obrázku. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
5.6
Volné rozmíst¥ní obrázk· na plo²e.
60
5.7
T°i typy rozmíst¥ní komponent na ovládacím panelu. . . . . . . . . . . . . .
61
5.8
Zm¥na snímku (°ezu) tahem my²í po posuvníku.
. . . . . . . . . . . . . . .
62
5.9
Dialog pro nastavení parametr· exportu snímku.
. . . . . . . . . . . . . . .
62
5.10 Dialog pro nastavení parametr· exportu animace. . . . . . . . . . . . . . . .
62
4.13 Diagram spolupráce t°íd pro MainWindow.
. . . . . . . . . . . . . . . . . . . . . . .
A.1
Cesty k hlavi£kovým soubor·m. . . . . . . . . . . . . . . . . . . . . . . . . .
70
A.2
Cesty ke knihovnám. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.3
Nastavení prom¥nných prost°edí.
72
. . . . . . . . . . . . . . . . . . . . . . . .
65
A.4
Nastavení kompila£ního pravidla. . . . . . . . . . . . . . . . . . . . . . . . .
66
73
Literatura [1]
Herout, P.: P°íprava text· po£íta£em II. Vydavatelství Západo£eské univerzity, Plze¬ 1998
[2] IKEM,
Institut Klinické a Experimentální Medicíny [online], dostupný z WWW:
[3] J. Bogaert, S. Dymarkowski, A.M. Taylor,
Clinical Cardiac MRI,
1st ed. 2005.
2nd printing, 2005, XII, 556 p. 1218 illus., 92 in color. With CD-ROM., Softcover, ISBN: 978-3-540-26217-6 [4] Magnetic resonance imaging. In
Wikipedia : the free encyclopedia [online]., St. Peters-
burg (Florida) : Wikimedia Foundation, 2001 -, last modif. on 12 April 2010. Anglická verze. Dostupný z WWW: [5] Joseph P. Hornak,
The Basics of NMR [online], dostupný z WWW:
[6] National Electrical Manufacturers' Association,
in Medicine (DICOM)
Digital Imaging and Communications
Rosslyn, Va: NEMA, 2004; PS 3.1-2004-3.13-2004., dostupný
online z WWW: [7] Digital Imaging and Communication in Medicine. In
Wikipedia : the free encyclopedia
[online]., St. Petersburg (Florida) : Wikimedia Foundation, 2001 -, last modif. on 6 April 2010. Anglická verze. Dostupný z WWW: [8] Endianness. In
Wikipedia : the free encyclopedia
[online]., St. Petersburg (Florida) :
Wikimedia Foundation, 2001 -, last modif. on 7 April 2010. Anglická verze. Dostupný z WWW: [9] OsiriX Imaging Software.
OsiriX Imaging Software. [online]. Dostupný z WWW:
[10] Asclepios MedINRIA.
MedINRIA. [online]. Dostupný z WWW:
67
[11] MRIcro.
MRIcro. [online]. Dostupný z WWW:
[12] Nokia Corporation and/or its subsidiaries.
Qt Online Reference Documentation
[on-
line]. Dostupný z WWW:
The OpenGL Graphics System: A Speci cation (Version 4.0 (Core Pro le) - March 11, 2010), The Khronos Group Inc., [online]. Dostupný z
[13] Mark Segal, Kurt Akeley. WWW:
[14] OpenGL. In
Wikipedia : the free encyclopedia
[online]., St. Petersburg (Florida) :
Wikimedia Foundation, 2001 -, last modif. on 12 April 2010. Anglická verze. Dostupný z WWW: [15] OpenGL Registry.
Extension Speci cations [online]. Dostupný z WWW:
[16] OpenGL wiki.
Getting started [online]. Dostupný z WWW:
[17] The OFFIS computer science institute.
DCMTK - DICOM Toolkit wiki [online]. Dos-
tupný z WWW: [18] SourceForge.
GDCM : Grassroots DICOM library
[online]. Dostupný z WWW:
[19] OpenGL specs.
glBlendFunc [online]. Dostupný z WWW:
cs3421/gl/glblendfunc.html>
The OpenGL Extension Wrangler Library [online]. Dostupný z WWW:
[21] SourceForge.
STEVE'S PORTABLE GAME LIBRARY [online]. Dostupný z WWW:
[22] SourceForge.
EasyBMPtoAVI Movie Creator [online]. Dostupný z WWW:
[23] Support DCMTK.
INSTALL le [online]. Dostupný z WWW:
DCMTK. FAQ #27: Compilation of DCMTK-based program fails with LNK2001 [MSVC] [online]. Dostupný z WWW:
[24] Forum
68
P°íloha A Sestavení (build) projektu ve Windows Pro opera£ní systém Windows jsem vytvo°il projekt ve vývojovém prost°edí Microsoft Visual Studio 2008 Express Edition, které je voln¥ p°ístupné ke staºení ze stránek Microsoftu. Po otev°ení projektu jsou v zobrazení Solution Explorer zobrazeny adresá°e inc a src, které projekt d¥lí na soubory deklarací a de nicí.
Jsou v nich obsaºeny 4 typy soubor·:
·
hlavi£kové (header les -.h)
·
zdrojové (source les - .cpp)
·
de ni£ní pro gra cké rozhraní (form les - .ui)
·
soubory vygenerované kompilátory knihovny Qt (GeneratedFiles moc .cpp, ui .h)
DicomPresenter je sestaven pomocí následujících knihoven (podrobn¥ji v kapitole 4):
·
Qt Multiplatformní framework slouºící p°edev²ím pro tvorbu gra ckého rozhraní.
·
DCMTK Soubor nástroj· implementující velkou £ást standardu DICOM.
·
OpenGL Knihovna pro renderování 3D objekt·.
·
GLEW Dynamická knihovna umoº¬ující práci s pokro£ilými funkcemi OpenGL.
·
Cg - Soubor nástroj· umoº¬ujících programování GPU pomocí shader·.
·
PLIB Knihovna usnad¬ující programování multimediálních aplikací.
69
Knihovny DCMTK a PLIB je nutno zkompilovat pro vytvo°ení staticky linkovatelných knihoven. Pomocí nástroje CMake jsem vytvo°il projekt pro Visual studio a ten jsem v n¥m poté zkompiloval. Návod v sekci
BUILDING (Win32)
v instala£ním dokumentu DCMTK
[22]. Výsledkem kompilace jsou pak staticky linkovatelné knihovny umíst¥né v r·zných adresá°ích p°íslu²ejících jednotlivým modul·m toolkitu DCMTK. Pro zjednodu²ení práce jsem si zkopíroval v²echny hlavi£kové soubory do jednoho adresá°e zkompilované statické knihovny do adresá°e
lib.
include
a v²echny
Pak sta£í v nastavení Visual studia od-
kazovat pouze do t¥chto adresá°·. V p°iloºeném souboru
dev.zip jsou v²echny pot°ebné knihovny jiº zkompilované a tak
sta£í tento soubor rozbalit do poºadovaného adresá°e a poté tuto cestu p°idat do nastavení Visual Studia v menu
Tools->Options->Projects And Solutions->VC++ Directories C:/Progs/Dev/, pak nas-
P°edpokládejme, ºe jsme soubor dev.zip rozbalili do adresá°e tavení cest k hlavi£kovým soubor·m bude jako na obrázku A.1.
Obrázek A.1: Cesty k hlavi£kovým soubor·m. A nastavení cest ke statickým knihovnám jako na obrázku A.2.
A.1
DCMTK
statické knihovny DICOM toolkitu musí být linkovány v ur£itém po°adí, jinak dochází k problém·m s referencemi [23].
Vnit°ní závislosti knihoven jsou následující:
·
dcmdata: ofstd.
·
dcmimage: dcmimgle, dcmdata, ofstd.
70
Obrázek A.2: Cesty ke knihovnám.
·
dcmimgle: dcmdata, ofstd.
·
dcmjpeg: ijg8, ijg12, ijg16, dcmimage, dcmimgle, dcmdata, ofstd.
·
dcmnet: dcmdata, ofstd.
·
dcmpstat: dcmimage, dcmimgle, dcmsign, dcmsr, imagectn, dcmtls, dcmnet, dcmdata, ofstd.
·
dcmsign: dcmdata, ofstd.
·
dcmsr: dcmdata, ofstd.
·
dcmtls: dcmnet, dcmdata, ofstd.
·
dcmwlm: dcmnet, dcmdata, ofstd.
·
imagectn/dcmqrdb: dcmnet, dcmdata, ofstd.
Dále pak v¥t²ina aplikací vyuºívajících DCMTK musí být linkována s
wsock32 A.2
netapi32
a
knihovnami, p°estoºe není vyuºívána ºádná sí´ová funkcionalita.
Plib
P°i pokusu o zkompilování Dicom Presenteru docházelo k chyb¥, kv·li nekompatibilit¥ znakových sad. Knihovna Plib si nerozumn¥la s pouºitím znakové sady UNICODE. e²ením bylo p°epnout nastavení znakové sady projektu
>Character Set (Not Set). 71
Properties->Con guration Properties-
A.3
Qt
Pro kompilátory knihovny Qt je pot°eba nastavit cestu ke knihovn¥ QT QTDIR do prom¥nných prost°edí
Ovládací panely->Systém->Up°esnit->Prom¥nné prost°edí
(viz obrázek A.3).
Obrázek A.3: Nastavení prom¥nných prost°edí.
Pro úsp¥²né zkompilování a pouºití t°íd odvozených od objekt· QObject je nutné deklara£ní soubory t¥chto t°íd nejprve zkompilovat QT
MOC kompilátorem (moc.exce).
Zkompilováním t¥chto soubor· MOC kompilátorem se vytvo°í meta-object kód pro tyto t°ídy. Poté je je²t¥ nutné zkompilovat výsledný meta kód standardním kompilátorem C++. Dále jsou v projektu soubory s p°íponou
ui.
Jsou to XML soubory de nující vzhled
Qt formulá°· a dialog·. Lze je editovat bu¤ ru£n¥, nebo pohodln¥ z gra ckého nástroje
Qt Designer,
který je sou£ástí balíku Qt. Otev°ení v Qt Designeru docílíme kliknutím
pravým tla£ítkem my²i na daný ui soubor. Dále vybereme
Open with..->Add.. a p°idáme do
designer.exe z adresá°e qt/bin. Tyto soubory se poté musí zkompilovat uic.exe, £ímº se vygenerují hlavi£kové soubory s tradi£ní C++ strukturou
seznamu program kompilátorem
de nující vzhled formulá°·. Aby se p°edchozí soubory kompilovali skute£n¥ poºadovanými kompilátory, je pot°eba nastavit jim takzvané
Custom build rule. Tato pravidla lze vytvo°it i v externím souboru a 72
qt_vc2008.rules) Project->Custom Build Rules->Find Existing. Nyní tedy sta£í na
následn¥ je pouze importovat do projektu. Kompila£ní pravidla (ze souboru importujeme pomoci menu
dané soubory, které chceme kompilovat t¥mito pravidly, kliknout pravým tla£ítkem my²i,
Properties->Con guration Properties->General->Tool a zde zvolit pat°i£ný nástroj. Qt User Interface File a pro soubory obsahující deklarace t°íd odvozených QObject (obsahujících makro Q_OBJECT) vybrat QT MOC rule. Ilustrace na obrázku
vybrat
Pro ui soubory od
A.4. /
1
Obrázek A.4: Nastavení kompila£ního pravidla.
qt_vc2008.rules). Tyto soubory je pot°eba importovat do projektu, pomocí menu Project->Add Existing Items Kompilací dojde k vytvo°ení soubor· v adresá°i GeneratedFiles (nastaveno v
a zkompilovat pomocí standardního kompilátoru.
Tady je pot°eba si dávat pozor, protoºe po zav°ení a znovu otev°ení projektu se nastavení t¥chto kompila£ních pravidel vºdy ztratí (alespo¬ ve Visual C++ 2008 Express Edition) a provedeme-li n¥jaké zm¥ny v rámci ui nebo v deklaraci QT objekt· (nap°íklad p°idání nových signál· a slot·), tak se tyto zm¥ny nezkompilují, dokud neprovedeme op¥tovné nastavení pravidel podle postupu popsaného v p°edcházejícím odstavci.
A.4
Seznam staticky linkovaných knihoven projektu DICOM Presenter
P°i linkování je dobré se drºet vypsaného po°adí knihoven:
·
cg.lib
73
·
cgGL.lib
·
wsock32.lib
·
netapi32.lib
·
ijg16.lib
·
ijg12.lib
·
ijg8.lib
·
dcmjpeg.lib
·
dcmimgle.lib
·
dcmimage.lib
·
dcmdata.lib
·
ofstd.lib
·
fnt.lib
·
sg.lib
·
ul.lib
·
glew32.lib
·
QtCore4.lib
·
QtGui4.lib
·
QtOpenGL4.lib
·
qtmain.lib
·
opengl32.lib
Pro úsp¥²nou funkci programu DICOM Presenter doporu£uji mít nainstalované nejnov¥j²í ovlada£e pro gra ckou kartu.
A.5
Problémy vyskytujicí se p°i spou²t¥ní programu v MS Windows
Po spu²t¥ní takzvané release verze programu z p°íkazové °ádky dochází k nep°edvídatelnému chování OpenGL textur. N¥které textury fungují normáln¥ a zobrazují medicínská data, ale jiné (v principu stejné) svá data nezobrazí. Pro toto chování jsem nenalezl ºádné vysv¥tlení a tak jsem se pokusil p°ejít na nov¥j²í verzi knihovny Qt s tím, ºe problémy snad zmizí. áste£n¥ se to p°echodem na verzi 4.7 povedlo, ale jen v debug verzi, která se zdá být funk£ní (ve verzi 4.5 m¥la i tato texturové problémy). Zajímavé je, ºe pokud program spustíme z prost°edí Visual studia tak k t¥mto problém·m s texturami v·bec nedochází.
74
