eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Modul zobrazování lidské pánve a chirurgických ²roub·
Michal mrha
Vedoucí práce:
Ing. Petr Felkel, Ph.D.
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Web a multimedia
24. kv¥tna 2012
iv
v
Pod¥kování D¥kuji Ing. Petru Felkelovi, Ph.D. za vedení práce, Ing. Michalu U°i£á°ovi za poskytnuté materiály a panu Ond°eji Kubánkovi za ochotu a jeho £as.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Jablonci nad Nisou dne 23. 5. 2012
.............................................................
viii
Abstract The aim of this project is to create a module for displaying volumetric data of human pelvis and polygonal models of surgical screws. This module will serve as an interactive simulator of surgery of the pelvis and will be a part of a larger educational application. It will let the tutors create simulations from actual data acquired from CT scans, into these simulations students will place screws and other surgical implants. This module will be put into real use as a tool for tuition and examining of medical students.
Abstrakt Cílem této práce je vytvo°it modul pro zobrazování objemových dat lidské pánve a geometrických dat chirurgických ²roub·. Tento modul bude fungovat jako interaktivní simulátor operace pánve a bude sou£ástí v¥t²ího výukového programu. Umoºní profesor·m vytvá°et zadání simulací z reálných dat získaných z CT sken·, do kterých pak budou studenti vkládat ²rouby a dal²í chirurgické implantáty. Tento modul bude vyuºíván v praxi pro výuku a zkou²ení medik·.
ix
x
Obsah 1 Úvod
1
2 Popis problému, speci kace cíle
3
2.1
Podrobnosti zadání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Funk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.3
Priority
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.4
Vyty£ený cíl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3 Teorie 3.1
3.2
7
Reprezentace objektu v po£íta£ové gra ce
. . . . . . . . . . . . . . . . . . . .
7
3.1.1
Geometrická data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.1.2
Objemová data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
3.1.3
Srovnání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Metoda zobrazení volumetrických dat
9
. . . . . . . . . . . . . . . . . . . . . .
9
3.2.1
Nep°ímo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2.2
P°ímo
9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Volba prost°edí, nástroj· a postup·
11
4.1
Pouºitý po£íta£ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.2
Jazyk programu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.3
Vývojové prost°edí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
4.4
Gra cká knihovna
12
4.5
Databáze a FTP
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.6
Zp·sob volumetrického zobrazení . . . . . . . . . . . . . . . . . . . . . . . . .
12
4.6.1
Algoritmus
12
4.6.2
Zobrazovací mód
4.6.3
Rozhodnutí
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
4.7
Reºim vykreslení geometrických dat
. . . . . . . . . . . . . . . . . . . . . . .
15
4.8
Projekce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.9
Pohyb kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
4.10 Pohyb ²roubu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.11 Architektonický vzor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
xi
xii
OBSAH
5 Realizace 5.1
Model
19 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.1.1
roub
5.1.2
CT obraz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.1.3
Generátor display list· . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
5.2
View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.3
Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.4
Dal²í £ásti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.4.1
CT obraz podrobn¥ji . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
5.4.2
rouby podrobn¥ji
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.4.3
Picking
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.4.4
Ukládání pozice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.4.5
P°evedení obrázk· na skalární pole . . . . . . . . . . . . . . . . . . . .
25
6 Testování
19
27
6.1
Výkonnostní test
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
6.2
Uºivatelský test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
7 Záv¥r
29
7.1
Zhodnocení projektu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
7.2
Moºnosti dal²ího vývoje
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
7.2.1
V¥t²í p°izp·sobitelnost zobrazovacího módu . . . . . . . . . . . . . . .
30
7.2.2
Vhodn¥j²í nastavení kvality
. . . . . . . . . . . . . . . . . . . . . . . .
30
7.2.3
tení DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
7.2.4
P°idání dal²ích chirurgických objekt· . . . . . . . . . . . . . . . . . . .
30
7.2.5
Zlep²ení ovládání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
7.2.6
Práce s vy²²ím výkonem . . . . . . . . . . . . . . . . . . . . . . . . . .
31
A Screenshoty
35
B Uºivatelská p°íru£ka
37
B.1
Instalace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.2
Studentská £ást . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.2.1
Spu²t¥ní simulace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.2.2
Ukládání a nahrávání . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
B.2.3
Úkoly
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
B.2.4
Pohyb kamery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
B.2.5
Správce objekt· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
B.2.6
Vlastnosti objekt·
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
B.2.7
Speci cké vlastnosti CT obrazu . . . . . . . . . . . . . . . . . . . . . .
39
B.2.8
Speci cké vlastnosti ²roubu
. . . . . . . . . . . . . . . . . . . . . . . .
40
B.2.9
Tla£ítka v zobrazovacím panelu . . . . . . . . . . . . . . . . . . . . . .
40
B.3
Administra£ní £ást
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
B.3.1
Vytvá°ení simulace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
B.3.2
CT obraz
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
B.3.3
Zdroje 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
xiii
OBSAH
B.3.4
Úkoly
B.3.5
Po£áte£ní stav
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
B.3.6
P°idání do kurzu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
B.3.7
Prohlíºení studenstkých simulací
42
. . . . . . . . . . . . . . . . . . . . .
42
C Seznam pouºitých zkratek
43
D Obsah p°iloºeného CD
45
xiv
OBSAH
Seznam obrázk· 5.1
Pouºití ltru pro odstran¥ní m¥kkých tkání
. . . . . . . . . . . . . . . . . . .
23
A.1
Screenshot 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
A.2
Screenshot 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
A.3
Screenshot 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
B.1
Základní rozloºení uºivatelského rozhraní . . . . . . . . . . . . . . . . . . . . .
38
xv
xvi
SEZNAM OBRÁZK
Kapitola 1
Úvod Tento projekt byl zadán léka°skou fakultou a má vést ke zkvalitn¥ní výuky medik· v oblasti chirurgických zákrok· na lidské pánvi. Úkolem je vylep²it výukovou aplikaci Pánev, která se na fakult¥ pouºívá jako interaktivní systém pro distribuci výukových materiál· a zkou²ení medik·. P°ísp¥vkem tohoto projektu bude simulátor, který umoºní trojrozm¥rné zobrazení reálných dat z tomogra ckých sken·. Do tohoto obrazu pak studenti budou vkládat implantáty a simulovat tak chirurgický zákrok, který by byl realizovatelný v praxi. Nutno zd·raznit, ºe se jedná o £ist¥ výukový projekt, který bude ur£en ke vzd¥lávání medik· a nebude vyuºíván v p°íprav¥ reálných operací.
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2
Popis problému, speci kace cíle 2.1 Podrobnosti zadání Ú£elem tohoto projektu je vylep²it simulátor v rozsáhlé výukové aplikaci Pánev pro studenty medicíny. Ta je zam¥°ena na studium lidské pánve, zejména pak na úrazy s ní spojené a následná chirurgická °e²ení. Úkolem není m¥nit samotnou výukovou aplikaci, proto je vhodné provád¥t co nejmen²í mnoºství zm¥n, které p°ímo nesouvisí se simulátorem. Aplikace má gra cké rozhraní ve stylu .NET Windows Forms a je primárn¥ instalována na po£íta£ích v u£ebn¥ léka°ské fakulty. Klientská aplikace neukládá ºádná uºivatelská data, v²e je drºeno v centrální databázi a v FTP úloºi²ti na serveru. P°i spu²t¥ní aplikace je uºivatel vyzván k p°ihlá²ení, jeho dal²í moºnosti jsou zásadn¥ ovlivn¥ny jeho uºivatelskou rolí a identitou. Aplikace má dv¥ základní uºivatelské role: profesor a student. Profesor vytvá°í materiály, prezentace, testy a simulace. Následn¥ má moºnost kontrolovat výsledky student· v testech a simulacích. Zárove¬ tyto výukové bloky za°azuje do kurz·, do kterých jsou studenti p°ihlá²eni. Student má p°ístup do blok· ve svých kurzech, m·ºe pracovat na zadaných simulacích a vypracovávat zadané testy. Konkrétním cílem projektu je nahrazení nepraktického 2D simulátoru novým, pouºiteln¥j²ím simulátorem, který bude operovat ve t°ech rozm¥rech. P·vodní simulátor sice vyuºíval 3D modely chirurgických ²roub·, vkládal je v²ak do plo²ného °ezu, nikoli do 3D obrazu. To neposkytovalo prakticky ºádnou prostorovou p°edstavu o umíst¥ní ²roubu. Hlavním úkolem simulátoru je trojrozm¥rné zobrazení snímk· lidské pánve a moºnost p°idávat do scény ²rouby a jiné chirurgické komponenty, které simulují výsledky chirurgického zákroku na konkrétních datech, tedy na konkrétním p°ípadu poran¥né pánve. Aby mohl být prostor v simulátoru zobrazen trojrozm¥rn¥, je nejprve pot°eba získat trojrozm¥rná data. V praxi se bude jednat o sérii °ez· z po£íta£ové tomogra e (CT), které budou nahrány do systému profesorem. Tato volumetrická data je nutno vhodným zp·sobem zobrazit tak, aby bylo moºné soust°edit se pouze na kosti, na které je tento simulátor zam¥°en. M¥kké tkán¥ nejsou v tomto projektu objektem zájmu. Klí£ovou £ástí simulátoru je interaktivní umis´ování ²roub· a dal²ích podobných objekt· do prostoru simulace. Student musí mít moºnost voln¥ ²roubem pohybovat tak, aby mohl dosáhnout vhodného uspo°ádání, tedy m¥nit polohu a nato£ení ²roubu vzhledem k obrazu pánve. rouby budou mít formu polygonálního modelu.
3
4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Aby program zapadal do celkového schematu aplikace, musí mít profesor moºnost vytvo°it zadání a za°adit ho do kurz·. Studenti daného kurzu pak mohou toto zadání nahrát a provád¥t samotnou simulaci, tedy umis´ovat ²rouby. Dále musí mít moºnost svou práci uloºit, jednak pro moºnost pokra£ování na rozd¥laném úkolu, ale také pro zp°ístupn¥ní studentské práce profesor·m. Aplikace Pánev je nejvíce vyuºívána v po£íta£ové u£ebn¥, jejíº stroje jsou jiº zna£n¥ zastaralé. Jedná se o stolní osobní po£íta£e s nep°íli² lichotivými parametry, mají nap°íklad pouze 512MB opera£ní pam¥ti. P°esto je nutné, aby simulátor pracoval dostate£n¥ rychle pro interakci, coº odpovídá vykreslovací frekvenci alespo¬ 10 FPS.
2.2 Poºadavky 2.2.1 Funk£ní poºadavky •
Simulátor musí vhodným zp·sobem zobrazovat objemová data získaná z tomogra ckých sken·.
•
Simulátor musí zajistit zobrazení pánevních kostí, m¥kké tkán¥ nejsou pro tento modul podstatné.
•
Simulátor musí vhodným zp·sobem zobrazovat geometrická data ²roub·, p°ípadn¥ dal²ích objekt·. Ze zobrazení musí být jasná vzájemná poloha kostí a ²roub·.
•
Uºivatel musí být schopen ²roubem v prostoru pohybovat, m¥nit jeho sm¥r a polohu.
•
U£itel musí mít moºnost vytvá°et zadání simulací a za°azovat je do kurz·. Student pak bude mít p°ístup k zadání ve svých kurzech.
•
Student bude mít moºnost svou práci uloºit a pozd¥ji nahrát. Také bude mít moºnost obnovit zadání simulace..
2.2.2 Nefunk£ní poºadavky •
Simula£ní modul by m¥l být sou£ástí stávající výukové aplikace Pánev verze 0.84, ve které nahradí sou£asnou nepraktickou 2D verzi simulátoru.
•
Do ostatních £ástí programu Pánev by pokud moºno nem¥l zasahovat.
•
Modul bude ukládat svá data ve spole£né databázi programu, své vstupní / výstupní soubory na FTP serveru. Lokáln¥ nebude uloºeno nic krom¥ samotné instalace.
•
Simulátor bude siln¥ interaktivní, £emuº musí odpovídat rychlost vykreslování.
•
Simulátor by nem¥l mít p°íli² vysoké £i speci cké nároky na hardware a opera£ní systém.
2.3.
PRIORITY
5
2.3 Priority Obávám se, ºe nebude moºné vytvo°it volumetrický zobrazova£, který zvládne vykreslit vnit°ek lidského t¥la v plném rozli²ení CT snímk· z°etelným a p°irozeným obrazem na zastaralém hardwaru a s takovou frekvencí, aby byla moºná pohodlná interakce. Zárove¬ si ned¥lám ºádné iluze o tom, ºe by se mi poda°ilo implementovat ve²kerou funk£nost, kterou lze od podobného simulátoru o£ekávat. Existují stovky men²ích £i v¥t²ích vylep²ení, které lze na podobný software aplikovat. Desítky uºite£ných funkcí, které by uºivateli daly více moºností. Je tedy nutné rozhodnout, co je pro tento projekt zcela zásadní a co je podruºné. Je naprosto jasné, ºe simulátor musí plnit svou základní funkci tedy zobrazovat lidskou pánev a umoºnit umíst¥ní ²roub·. Dále je velmi d·leºité, aby bylo moºné pracovat p°ímo s kostmi. Relevantní data se nesmí ztrácet v m¥kkých tkáních a jiných £ástech obrazu, které nejsou pro simulaci podstatné. Také povaºuji za d·leºité, ºe vzájemná poloha kostí a ²roub· bude jednozna£n¥ rozpoznatelná, jinak simulace ztrácí význam. Aby byl program pouºitelný v sou£asných podmínkách, musí dokázat zobrazovat data v interaktivních frekvencích i na starých strojích. Zmín¥né body povaºuji za naprosto klí£ové. Bez nich významným zp·sobem utrpí pouºitelnost simulátoru. Následují dal²í zásadní vlastnosti, které v²ak mohou být v p°ípad¥ nutnosti potla£eny ve prosp¥ch t¥ch vý²e zmín¥ných: Jedná se o analýzu medicínských dat, i kdyº jen b¥hem výuky. Povaºuji tedy za d·leºité zachovat p°esnost na co nejvy²²í úrovni. Dále je pot°eba minimalizovat £as pot°ebný ke zvládnutí základní práce se simulátorem, ovládání by m¥lo být jednoduché. Aplikace je ur£ena pro výuku, ne pro dlouhodobou práci specialist·, jednoduchost tedy m·ºe být d·leºit¥j²í neº efektivita. A nakonec vlastnosti velmi uºite£né, ne v²ak nepostradatelné: Simulátor by m¥l uºivateli poskytnout dostate£ný prostorový vjem bez nutnosti neustálého otá£ení pohledu, a£koli je zm¥na úhlu pohledu pro úplnou p°edstavu nutná. Obraz by m¥l také co nejlépe vystihovat realitu, tedy p·sobit p°irozen¥. Do tohoto odstavce také pat°í ve²keré funkce, které neovliv¬ují pouºitelnost simulátoru zcela zásadním zp·sobem a nejsou sou£ástí zadání.
2.4 Vyty£ený cíl Cílem tohoto projektu je vytvo°ení simulátoru, který bude spl¬ovat poºadavky zadání a bude pouºitelný p°i výuce. S ohledem na p°edpokládaný rozsah implementace a moºné problémy s výkonem na cílových po£íta£ích si v²ak nekladu za cíl vytvo°ení kone£né verze s maximální funkcionalitou a exibilitou. Spí²e se bude jednat o první funk£ní verzi, která bude v budoucnu p°edm¥tem dal²ího vývoje a roz²i°ování v závislosti na pot°ebách zadavatele.
6
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Teorie 3.1 Reprezentace objektu v po£íta£ové gra ce Objekty reálného sv¥ta existují ve t°ech prostorových rozm¥rech, jejich vlastností jsou v zásad¥ spojité, úrove¬ jejich detail· neuv¥°iteln¥ vysoká. Naproti tomu objekty zobrazované po£íta£em jsou vykresleny na dvourozm¥rnou obrazovku, jejich vlastnosti jsou diskrétní, úrove¬ detailu omezená mimo jiné výkonem stroje. Je tedy nutná °ada operací, neº m·ºeme reálný objekt zobrazit po£íta£ov¥. P°edtím, neº n¥jaký objekt m·ºeme zobrazit, je t°eba ho p°evést do digitální podoby. To znamená uloºit relevantní data do n¥jaké struktury, která bude objekt reprezentovat. Existují dv¥ základní reprezentace vizuálních vlastností objekt·: geometrická a objemová.
3.1.1 Geometrická data Geometrická reprezentace ve 3D zhruba odpovídá vektorové reprezentaci 2D dat. V tradi£ní polygonální geometrii je vn¥j²í plocha objektu aproximována mnohoúhelníky (polygony), které jsou zadány svými vrcholy a hranami mezi nimi. Polygon m·ºe být opat°en texturou (2D obrazem na jeho povrhu), jeho materiál m·ºe mít vlastní barvu, pr·hlednost nebo ur£itým zp·sobem odráºet sv¥tlo. Typickými p°íklady geometrických dat jsou modely pouºité v po£íta£ových hrách, virtuální model budovy £i dopravního prost°edku nebo sou£ástka navrºená v CAD systému. Výhodou tohoto p°ístupu je, ºe m·ºeme vrcholy umístit na libovolné sou°adnice, nikoli pouze na p°edem ur£enou m°íºku. Navíc jsou umoºn¥ny hladké ²ikmé hrany. Takovým p°ístupem lze navíc velmi jednodu²e reprezentovat hranaté objekty s jasn¥ ur£enými hranicemi nap°íklad krabici nebo £ást stroje. S pouºitím osv¥tlovacího modelu, textur a polopr·hledných materiál· lze vykreslovat velmi p°esv¥d£ivé modely. První slabinou polygonální reprezentace jsou zaoblené objekty zatímco na zobrazení krychle sta£í osm vrchol·, kouli nikdy p°esn¥ nepopí²eme. Dostate£ným mnoºstvím polygon· dosáhneme dobré aproximace (obzvlá²´ s pomocí plynulého stínování), ov²em za cenu velkého mnoºství dat pro relativn¥ jednoduchý tvar. Tuto slabinu v²ak z velké £ásti °e²í geometrická reprezentace pomocí k°ivek (nap°íklad NURBS), které jsou dnes b¥ºnou sou£ástí modelovacích nástroj· a CAD systém·.
7
8
KAPITOLA 3.
TEORIE
Nevy°e²eným problémem ov²em z·stavá geometrická reprezentace objekt·, jejichº hranice není jasn¥ ur£ena nebo není d·leºitá. Geometrická reprezentace pracuje s povrchem t¥les, který by se dal popsat jako jednozna£n¥ ur£ené rozhraní mezi materiály. N¥kdy nás v²ak nezajímá samotné binární rozhraní, ale úrove¬ ur£itých hodnot v prostoru. Povrchem m·ºeme jen t¥ºko realisticky reprezentovat plamen sví£ky, oblak páry nebo oblast vysokého tlaku v atmosfé°e.
3.1.2 Objemová data Objemová, neboli volumetrická reprezentace dat odpovídá bitmapové reprezentaci 2D dat. Místo dvourozm¥rných pixel· se skládá z trojrozm¥rných jednotek, voxel·. Fungují naprosto analogicky, na m°íºce v prostoru má kaºdý uzel svou hodnotu. M°íºka je nej£ast¥ni pravoúhlá s konstantními rozestupy v jednotlivých sm¥rech, není to v²ak pravidlem. Soubor voxelizovaných dat si lze p°edstavit jako °adu dvourozm¥rných obrázk· se°azených za sebou tak, ºe jejich pixely tvo°í trojrozm¥rnou m°íºku. Kaºdý voxel m·ºe mít jednu £i více hodnot, typicky skalárních. M·ºe se jednat nap°íklad o hustotu látky, vodivost £i propustnost pro ur£itý typ paprsku. Typickými p°íklady volumetrických dat jsou soubory medicínských dat z po£íta£ové tomogra e (CT) nebo magnetické rezonance (MRI), obrazy mikroskopických struktur nebo meteorologická data. Výhodou volumetrické reprezentace je, ºe dob°e popisuje vnit°ní strukturu objektu, nikoli jen jeho zevn¥j²ek. Zárove¬ nejsou ur£ena pouze binární rozhraní, ale hodnoty v kaºdém uzlu, coº umoº¬uje tém¥° plynule zobrazit zm¥ny v relevantních veli£inách. Vzorky jsou sice diskrétní, mohou v²ak nabývat celé °ady hodnot. Navíc se jedná o data nam¥°ená p°ímo v reálném sv¥t¥. Pokud geometrická reprezentace odpovídá ve 2D rýsovacímu prknu, volumetrická data odpovídají fotogra i. Nevýhod je ov²em také celá °ada. Velikost dat je tém¥° nezávislá na sloºitosti reálných struktur, zna£né mnoºství dat tedy m·ºe být irelevantní. Zatímco geometrická reprezentace oby£ejné krychle vyºaduje data o osmi bodech v prostoru, objemový obraz stejné krychle se skládá z hodnot v obrovském mnoºství uzl·. V rozli²ení b¥ºného CT skenu se jedná o desítky milion·. Nem¥nná vzorkovací frekvence s sebou p°iná²í i dal²í problém, kterým je minimální rozm¥r zobrazitelných dat. Pokud máme k dispozici jeden vzorek na milimetr, t¥ºko m·ºeme zobrazit mikroskopické anomálie v klí£ové oblasti snímku. Zvý²it kv·li tomu rozli²ení celého snímku je v²ak nevhodné, £i dokonce technicky nemoºné. áste£ným °e²ením t¥chto problém· je uchovávat objemová data jako octree, jehoº bu¬ky mají r·znou velikost v závislosti na d·leºitosti regionu a frekvenci zm¥n m¥°ených hodnot. Aby v²ak byl octree opravdu efektivní, je vhodné zanedbat nevýznamné zm¥ny v plochých regionech, £ímº se ztrácí £ást informací. Objemová data jsou na rozdíl od geometrické reprezentace vázána k pevn¥ daným uzl·m na m°íºce. Pokud by se v obraze vyskytovala výrazná ²ikmá linka, bude bu¤ tvo°it schody, nebo bude rozmazaná. Jakékoli jednozna£n¥ ur£ené rozhraní mezi povrchy bude lépe vyjád°eno geometricky.
3.2.
METODA ZOBRAZENÍ VOLUMETRICKÝCH DAT
9
3.1.3 Srovnání Kaºdá ze zmín¥ných reprezentací má své vyuºití, ºádná není univerzáln¥ lep²í. Geometrické zobrazování je v sou£asnoti mnohem roz²í°en¥j²í a má lep²í podporu. N¥kdy je vhodn¥j²í reálný objekt modelovat v geometrickém 3D editoru £i pouºít 3D skener, n¥kdy je vhodn¥j²í ho nasnímat jako objemová data. Tato data se n¥kdy vyplatí p°evést do geometrické podoby, jindy je lep²í pracovat s objemem p°ímo.
3.2 Metoda zobrazení volumetrických dat Objemová data lze zobrazovat bu¤to p°ímo ze skalárních hodnot uloºených ve m°íºce objemu, nebo nep°ímo p°evedením na polygonální model.
3.2.1 Nep°ímo Abychom mohli p°evést soubor volumetrických dat na geometrický model, musíme ob¥tovat mhoho základních výhod spojených s objemovou reprezentací. P°edev²ím jsme omezeni na povrchový model, p°ípadn¥ sadu takových model·. Tím ztrácíme velké mnoºství informací o vnit°ních strukturách objektu. Z ur£ení aplikace v²ak vyplývá, ºe uºivatele budou zajímat p°edev²ím kosti, jejichº rozhraní je jasn¥ ur£eno. Bylo by tedy p°e£asné geometrickou metodu zcela vylou£it.
Marching Cubes Nejb¥ºn¥j²ím postupem pro rekonstrukci polygonálního modelu z pole skalárních hodnot jsou Marching Cubes, tedy pochodující krychle, p°ípadn¥ analogický postup Marching Tetrahedrons. Jedná se o algoritmus z konce osmdesátých let, který je moºné voln¥ pouºít, jelikoº jeho patent vypr²el. Pro zvolenou hrani£ní hodnotu vytvo°í iso-surface, neboli povrch se stejnou hodnotou. Jinými slovy hladinu nebo 3D vrstevnici. Základní opera£ní jednotkou tohoto algoritmu je bu¬ka, tedy krychle se skalárními daty v kaºdém vrcholu. Kaºdá hodnota je porovnána se zvolenou hrani£ní hodnotou. Podle vrchol·, které leºí pod zadanou úrovní, je postaven index pro´atých hran 0-255, coº odpovídá po£tu v²ech moºných kombinací. Na míst¥ s tímto indexem je pak v p°edem vytvo°ené tabulce nalezen záznam o tom, které hrany bu¬ky budou pro´aty hladinou. Dále se na pro´até hrany umístí pr·se£íky, jejichº pozice je vypo£tena lineární interpolací hodnot v obou relevantních vrcholech. Nakonec se v dal²í p°edem vytvo°ené tabulce pomocí stejného indexu p°e£te informace o tom, jakým zp·sobem mají být z pr·se£ík· vytvo°eny trojúhelníky. Tímto postupem je zkontrolována kaºdá bu¬ka objemu. Pokud jsou její vrcholy na opa£ných stranách hladiny, vytvo°í se p°edepsané trojúhelníky. Výstupem je polygonální model souvislé hladiny, která prochází zadanou hrani£ní hodnotou. V na²em p°ípad¥ by se jednalo o hodnotu blízko pod úrovní hustoty kostí, takºe by hladina tvo°ila rozhraní mezi m¥kkými tkán¥mi a kostmi.
3.2.2 P°ímo P°ímým zobrazením objemu je my²lena metoda, která objemová data nep°evádí na geometrické útvary, ale ze skalárních hodnot v objemu p°ímo po£ítá barevné hodnoty výsledného
10
KAPITOLA 3.
TEORIE
obrazu. V p°ípad¥ CT skenu je hlavní výhodou zachování informací o vnit°ní struktu°e objekt·. Nevýhody vyplývají z jednotlivých metod.
Texture Slices N¥kdy se ozna£uje jako Texture Mapping nebo Cutting Planes. Tato metoda funguje na jednoduchém principu. Proloºí objemem sadu rovnob¥ºných °ez·, na které z objemových dat namapuje polopr·hledné textury. ezy se v interaktivních aplikacích umis´ují v zásad¥ dv¥ma zp·soby. První moºností je udrºovat °ezy kolmé na sm¥r pohledu, druhou pak ponechat °ezy statické vzhledem k objemu. U °ez· kolmých na pohled jsou n¥kdy viditelné artefakty, navíc se p°i pohybu musí p°epo£ítávat mapování textur. Statické °ezy je t°eba vytvo°it z n¥kolika stran a p°epínat mezi nimi v závislosti na úhlu pohledu, aby se nestalo, ºe uºivatel uvidí místo objemu jen sérii vertikálních £ar. Mohou vznikat viditelné skoky nap°íklad p°i p°echodu z p°edních °ez· na bo£ní. Dal²í reºii zobrazení a kombinování textur je moºné p°enechat gra ckému rozhraní, nap°íklad OpenGL. Výhodou této metody je mimo jiné to, ºe dokáºe pom¥rn¥ rychle pracovat i na star²ím hardwaru. Gra cká akcelerace této metody je moºná v zásad¥ na v²ech gra ckých kartách, coº umoº¬uje dostate£nou rychlost pro interaktivitu. Dal²í výhodou je velmi snadná kombinace z geometrickými objekty ve scén¥, protoºe a£koli jsou skalární hodnoty objemu zobrazeny p°ímo, texturované °ezy se chovají jako b¥ºné polygony. Nevýhodou této metody je pon¥kud slab²í interaktivita transforma£ní funkce. M·ºeme m¥nit hodnoty pixel· p°ímo v textu°e, ale u velkých objem· m·ºe být transformace textury £asov¥ náro£ná. Nicmén¥ m·ºeme v reálném £ase m¥nit funkci míchání barev (blending) a alpha ltr, coº je dostate£ný nástroj k odstran¥ní m¥kkých tkání z CT snímku.
Raycasting Tato metoda pro kaºdý zobrazovaný pixel protne objem paprskem, p°i£emº v pravidelných intervalech £te skalární hodnoty. Nam¥°ené hodnoty potom vyhodnocuje podle zvolené transforma£ní funkce v pevn¥ daném po°adí. Paprsek je moºno vyslat zep°edu (front-to-back), £i zezadu (back-to-front). Výhodou této metody je ohromná exibilita a velmi kvalitní obraz. Lze implementovat zobrazovací módy, které fungují jako rentgen, vybírají pouze maximální intenzitu £i zobrazují stínované povrchy. Na moderních gra ckých kartách s programovatelnými shadery lze dosáhnout dobrého pom¥ru kvality a rychlosti. Gra cky akcelerované verze dosahují po v²ech stránkách lep²ích výsledk· [1] neº algoritmus Shear Warp, který zde proto ani nerozebírám. Nevýhodou jsou vysoké nároky na hardware, p°ípadn¥ dlouhé renderovací £asy u v¥t²ího objemu dat. Existuje °ada metod pro zvý²ení efektivity, ov²em na star²ích strojích nelze o£ekávat rychlost umoº¬ující interaktivní ovládání.
Splatting Tato metoda pracuje tak, ºe z kaºdého uzlu objemu promítne na projek£ní plochu kruh gaussovského rozloºení, který ovliv¬uje hodnoty ve svém nejbliº²ím okolí. Tento postup je £asto p°irovnáván k házení sn¥hových koulí. Výsledky nejsou tak p°esné jako u ostatních metod. A£koli je splatting v literatu°e jako moºnost £asto zmi¬ován jako alternativa k raycastingu, není p°íli² oblíbený.
Kapitola 4
Volba prost°edí, nástroj· a postup· 4.1 Pouºitý po£íta£ Na vlastní vznikající kód nemá pouºitý stroj prakticky ºádný vliv. Cht¥l jsem se v²ak alespo¬ £áste£n¥ p°iblíºit parametr·m po£íta£·, na kterých by program mohl v praxi fungovat. Rozhodl jsem se program b¥hem vývoje netestovat na výkonném desktopu, který si snadno poradí i s velmi ne²ikovn¥ psaným kódem, ale na star²ím laptopu, na kterém se problémy s rychlostí algoritm· spí²e projeví. Jedná se o zhruba p¥t let starý laptop Asus F3Sv. Tento stroj je sice pom¥rn¥ vysoko nad p°edpokládanou kon gurací cílových po£íta£·, zejména v oblasti gra cké karty a RAM, stále je v²ak výrazn¥ blíºe neº m·j stolní po£íta£.
4.2 Jazyk programu Vzhledem k tomu, ºe je program Pánev psán v jazyce C# a modul má být jeho interní sou£ástí, je C# pom¥rn¥ jasnou volbou. Mohl bych sice vytvo°it knihovny v jiném .NET jazyce, k takovému postupu ov²em nemám ºádný objektivní d·vod. Zárove¬ jsem se rozhodl zachovat cílový framework p°edchozí verze. Ztratím sice n¥kolik uºite£ných nástroj· oproti nov¥j²ím verzím (nap°. LINQ), nejedná se v²ak o tak zásadní nástroje, aby ospravedlnily p°echod na jiný framework.
Modul tedy bude psán v jazyce C# pro .NET Framework 2.0.
4.3 Vývojové prost°edí Zdrojové kódy p°edchozí verze programu mi byly p°edány jako projekt Visual Studio 2005. K dispozici mám v²ak studentskou licenci Visual Studio 2008, proto jsem projekt p°evedl na nov¥j²í verzi. Neo£ekávám vyuºití nástroj· nedostupných ve star²í verzi, jediných d·vodem je má platná licence.
Program tedy bude editován jako projekt Microsoft Visual Studio 2008. 11
12
KAPITOLA 4.
VOLBA PROSTEDÍ, NÁSTROJ A POSTUP
4.4 Gra cká knihovna Pro zobrazení 3D dat hodlám pouºít jedno z b¥ºn¥ pouºívaných gra ckých rozhraní, OpenGL nebo DirectX. Zatímco OpenGL je opravdu pouze gra cké API, DirectX poskytuje i dal²í nástroje pro programování po£íta£ových her. Na druhou stranu OpenGL je multiplatformní a podle v²eho lépe dokumentované. OpenGL navíc za£alo podporovat 3D textury o £ty°i roky d°íve neº DirectX, coº by mohlo pozitivn¥ ovlivnit kompatibilitu se star²ími stroji. A£koli je tém¥° jisté, ºe simulátor bude spou²t¥n pod Windows, OpenGL se zdá být pro na²i aplikaci vhodn¥j²ím z obou kandidát·. Navíc jsem jiº v minulosti s OpenGL p°i²el do styku, zatímco rozhraní DirectX by pro mne bylo zcela nové. OpenGL nelze pouºít v C# p°ímo, je pot°eba n¥jaký framework nebo wrapper. Ve starém simula£ním modulu byla pro tento ú£el pouºita knihovna CsGL. Ve své dob¥ plnila sv·j ú£el, ov²em nyní je zna£n¥ zastaralá a nespolupracuje dob°e s nov¥j²ími systémy. V reºimu x64 nap°íklad nefunguje v·bec a zp·sobuje pád celé aplikace. Nástupcem této knihovny je Tao Framework, i ten jiº v²ak ustoupil svému dal²ímu pokra£ovateli, OpekTK. Po krátkých pokusech jsem do²el k záv¥ru, ºe OpenTK umí v²e, co od n¥j o£ekávám, a pracuje se s ním pohodln¥. Navíc má k dispozici °adu ukázkových aplikací a poskytuje kvalitní online dokumentaci.
V aplikaci bude pouºito gra cké API OpenGL [9] prost°ednictvím knihovny OpenTK [10].
4.5 Databáze a FTP V aplikaci bude pot°eba komunikovat s databází, která p°i spu²t¥ní ov¥°uje identitu uºivatele, drºí informace o uºivatelských skupinách, kurzech, uºivatelských datech atd. Navíc databáze poskytuje cesty k soubor·m na FTP serveru. Jedná se tedy o klí£ovou £ást celé aplikace, bez které není její funk£nost moºná. Tím, ºe simula£ní modul bude vyuºívat databázi celé výukové aplikace, je speci kace databáze p°edem ur£ena a není záhodno ji kv·li simula£nímu modulu m¥nit. Soubory jsou na server p°ená²eny protokolem FTP, stejným zp·sobem jsou op¥t nahrávány. To p°edstavuje jistá omezení, je nutno po£ítat s relativn¥ nízkou p°enosovou rychlostí. Není vhodné zp·sob ukládání dat na server m¥nit, ov²em musíme se snaºit minimalizovat velikost soubor· pro p°enos.
Databáze v sou£asnosti b¥ºi na Firebird Serveru verze 1.5 a tak to i z·stane. Stejn¥ tak p°ístup k soubor·m pomocí FTP z·stane nezm¥n¥n.
4.6 Zp·sob volumetrického zobrazení 4.6.1 Algoritmus B¥hem výb¥ru zobrazovací metody jsem bral v úvahu celou °adu informací z nejr·zn¥j²ích zdroj· nalezených na Internetu [5] £i v knihách [6] [4]. Z n¥kolika pr·zkum· [15] [14] [13] mimo jiné vyplývá, ºe velké mnoºství uºivatel· vlastní po£íta£e s velmi slabými pixel / vertex shadery. P°i vyuºití programovatelných shader· pro vykreslení objemu by u nich
4.6.
ZPSOB VOLUMETRICKÉHO ZOBRAZENÍ
13
vykreslovací £asy byly nep°ijateln¥ vysoké. P°i pouºití nov¥j²ích generací shader· by pak program nefungoval. Podle [15] navíc 5% sledovaných uºivatel· vlastní gra ckou kartu s pevnou pipeline, kde shadery nep°ichází v úvahu. Proto jsem se rozhodl varianty s vyuºitím programovatelných shader· vylou£it. Provedl jsem n¥kolik vlastních pokus· s implementací jednotlivých algoritm·: Sepsal jsem úplnou implementaci algoritmu Marching Cubes podle návodu [2]. Trojúhelníky jsem ukládal do vlastní datové struktury, která pro n¥ dopo£ítávala normály. Jakmile algoritmus úsp¥²n¥ zpracoval objemová data, vytvo°il z trojúhelník· display list a model byl p°ipraven k pouºití. Výsledky byly u men²ích testovacích dat velmi uspokojivé. Stínované plochy vypadaly hezky a jako reprezentace kostí mohly být dostate£né. Problémy se ov²em projevily u v¥t²ích objem·. Jednak výrazným zp·sobem vzrostl £as pot°ebný k vytvo°ení modelu, °ádov¥ na n¥kolik minut. Pokud v²ak místo objemových dat ukládáme hotový model, tento problém z v¥t²í £ásti odpadá. Je to sice nep°íjemné ve fázi, kdy u£itel odhaduje správnou hranici pro daný soubor dat tak, aby plocha reprezentovala v²echny kosti a ºádné m¥kké tkán¥. Toto je ov²em v¥c jednorázová a lze ji usnadnit nap°íklad histogramem dat. Naráºíme v²ak na dal²í problémy velkých objemových dat p°evedených na trojúhelníky, kterými jsou rychlost zobrazení a velikost generovaného modelu. Po£ty trojúhelník· se u objemových dat pouºitelné velikosti dostávaly °ádov¥ do milion·. Kaºdý trojúhelník je p°itom reprezentován £ty°mi trojrozm¥rnými vektory s p°esností oat, jedním pro kaºdý vrchol a jedním pro normálu. Nejprve jsem zkusil pouºít klasickou serializaci, výsledky v²ak byly odstra²ující. Poté jsem sadu trojúhelník· prost¥ namapoval na pole byt· a uloºil do binárního souboru. Poté jsem vyuºil je²t¥ GZip kompresi tohoto pole. Pro p°edstavu uvedu velikosti modelových soubor· pro sadu deseti snímk·, p°i£emº po£et snímk· v opravdových simulacích odhaduji na 100-200, tedy minimáln¥ desetkrát více neº p°i t¥chto testech. Serializovaný soubor m¥l velikost 47MB, trojúhelníky jako pole byt· 15MB, komprimované 7MB. Soubor realistického rozm¥ru by tedy m¥l °ádov¥ 100MB. Abychom se dostali na p°ijatelné hodnoty, °ekn¥me do 10MB, museli bychom ob¥tovat rozli²ení a vytvá°et v¥t²í trojúhelníky. Takto razantní sníºení kvality nepovaºuji v medicínské aplikaci, by´ jen výukové, za vhodné. Bylo by moºné pouºít takovou plochu jako alternativní nekvalitní zobrazení, p°ípadn¥ generovat plochu jen v men²í klí£ové £ásti objemu. Celkov¥ v²ak algoritmus Marching Cubes po vlastních pokusech hodnotím jako nevhodný primární zp·sob zobrazení. Dále jsem velmi zjednodu²en¥ implementoval Raycasting. Z d·vodu minimalizace nárok· na hardware jsem se vyhnul programovatelným shader·m a podobným vymoºenostem a výpo£ty jsem provád¥l na CPU. Testovací implementace fungovala opravdu triviáln¥, pouze s£ítala hodnoty na£tené v objemu p°i pr·chodu paprsku. Musím uznat, ºe má implementace nebyla v·bec optimalizovaná a jist¥ by se dala n¥kolikanásobn¥ zrychlit, ov²em renderovací £as se pohyboval v °ádech sekund. Vzhledem k naprosto triviální transforma£ní funkci, ºádné interpolaci a relativn¥ malému objemu jsem byl tímto výsledkem odrazen. Navíc jsem p°i svém p°edchozím pr·zkumu narazil na °adu názor· potvrzujících pomalé renderování raycastingem i p°es vyuºití nejr·zn¥j²ích optimaliza£ních metod. Odsoudil jsem tedy raycasting jako p°íli² pomalý vzhledem k velmi omezeným hardwarovým prost°edk·m, které bude mít aplikace v praxi k dispozici. Jako dal²í jsem implementoval metodu Texture Slices. Nejprve jsem vyzkou²el metodu s °ezy statickými v·£i objemu, p°i£emº se st°ídala orientace °ez· v závislosti na úhlu kamery. N¥které zdroje zmi¬ovali znatelné skoky p°i zm¥n¥ pohledu, nic takového jsem v²ak nepozo-
14
KAPITOLA 4.
VOLBA PROSTEDÍ, NÁSTROJ A POSTUP
roval. Jedinou dal²í nevýhodou oproti otá£ejícím se °ez·m je nutnost mít v pam¥ti t°i sady textur. To jsem obe²el tím, ºe jsem data nahrál jako 3D texturu, které jsou v OpenGL podporovány jiº 14 let, takºe snad mají dostate£nou podporu i na star²ích kartách. Vzhledem k tomu, ºe nevím o ºádných dal²ích výhodách oto£ných °ez· (naopak si n¥které zdroje st¥ºují na vznik artefakt·), ani jsem tuto druhou metodu nezkou²el implementovat. Nakonec jsem vhodn¥ nastavil míchání barev. P°i malých objemech fungovala implementovaná technika naprosto bez problém·, renderovací rychlost byla dostate£ná pro naprosto plynulé zobrazení. P°i souborech reálné velikosti, konkrétn¥ u souboru 150ti snímk·, klesla frekvence zhruba na 5-10 FPS. To sice není ideální hodnota, ov²em vysoce p°evy²uje v²echny ostatní dosud vyzkou²ené algoritmy. Pokud umoºním sníºení kvality p°i pohybu, mohu se dostat na velmi slu²né frekvence a zachovat maximální kvalitu obrazu b¥hem statických vykreslení. Alpha lter navíc umoº¬uje velmi snadno odstranit m¥kké tkán¥ a zobrazit pouze kosti. Pokud nám vyhovuje rentgenové zobrazení kostí, tato metoda se zdá být velmi vhodná.
4.6.2 Zobrazovací mód Základním zobrazovacím módem je pr·m¥rná intenzita. Celý objem p°ispívá k výsledné hodnot¥, obraz v²ak trpí tím, ºe slabá vrstva d·leºitého materiálu (v na²em p°ípad¥ kost) bude sama o sob¥ nevýrazná. Jinou moºností je maximální intenzita. K výsledné hodnot¥ nep°ispívá celý objem, ale jen nejvy²²í hodnota. Tento mód bohuºel neposkytuje p°íli² dobrou prostorovou p°edstavu a nep·sobí p°irozen¥. Vhodnou kombinací p°edchozích moºností je akumulace intenzity. Celý objem p°ispívá k obrazu, ale i slabá vrstva se m·ºe výrazn¥ projevit, pokud je dostaten¥ intenzivní. Výsledný obraz p°ipomíná rentgenový snímek. Také je moºné nastavit binární hranici skalárních hodnot a vytvo°it tak povrch neboli hladinu (iso-surface). Aby nebyl povrch vykreslen jednolitou barvou, je moºné pom¥rn¥ triviáln¥ m¥nit odstín v závislosti na vzdálenosti. Pokro£ilej²í metodou je výpo£et gradientu a pouºití osv¥tlovacího modelu, £emuº bych se v²ak rád vyhnul kv·li zvý²eným nárok·m na výpo£etní £as i vyuºitou pam¥´. Vý²e zmín¥né módy lze do ur£ité míry kombinovat.
4.6.3 Rozhodnutí Aby bylo z°ejmé, podle £eho metodu zobrazení objemu vybírám, zde je zjednodu²ený ºeb°í£ek priorit:
1. Moºnost zvýraznit kosti £i odstranit m¥kké tkán¥ 2. Obraz, který dokáºe b¥ºný uºivatel interpretovat 3. Dostate£ná renderovací rychlost pro interaktivitu 4. Funk£nost i na star²ím hardwaru 5. Zachování maximálního rozli²ení snímk·
4.7.
REIM VYKRESLENÍ GEOMETRICKÝCH DAT
15
6. Dobrá prostorová p°edstava uºivatele 7. P°irozený vzhled a estetika
Tento ºeb°í£ek jsem sestavil já, nikoli zadavatel. Jedná se o m·j odhad, v¥°ím v²ak, ºe rámcov¥ odpovídá poºadavk·m ze zadání. První bod spl¬ují v²echny zvaºované moºnosti. Druhý bod spl¬ují n¥které metody lépe neº jiné, v zásad¥ v²ak ºádná moºnost není vylou£ena. T°etí aº pátý bod jednozna£n¥ nejlépe spl¬uje metoda Texture Slices bez pouºití gradientu. A£koli nap°íklad kombinovaný mód zobrazení (gradientem stínované hladiny pro kosti a st°ední intenzita pro m¥kké tkán¥) generovaný raycastingem dokonale spl¬uje poslední dva body a ve druhém bod¥ je o n¥co málo úsp¥²n¥j²í, v ºádném p°ípad¥ neprojde p°es t°etí aº pátý bod. P°i výzkumu z roku 2001 [3] pouºití stínovaných ploch 4x sníºilo frekvenci metody raycasting (na tehdy moderních strojích na frekvenci 1 FPS). Moºné módy zobrazení bych dále zredukoval na akumulovanou intenzitu a vzdáleností stínovanou hladinu. Oba tyto módy jsou dostate£n¥ rychlé, hardwarov¥ nenáro£né a zárove¬ poskytují snadno interpretovatelný obraz. Intenzita poskytuje pon¥kud v¥t²í exibilitu, také tolik nezávisí na uºivatelsky nastavené hranici. Správn¥ nastavený povrch poskytuje o n¥co lep²í prostorovou orientaci. Domnívám se, ºe nejvhodn¥j²ím módem pro primární zobrazení je akumulovaná intenzita. Vzdáleností stínovaný povrch je vhodný jako potenciální dopl¬ující rozbrazení, pokud uºivatel vyºaduje naprosto nepr·hledné kosti a nemá problém s nasavením binární hranice.
Volumetrické zobrazení bude primárn¥ °e²eno algoritmem Texture Slices a bude zobrazovat v módu akumulované intenzity.
4.7 Reºim vykreslení geometrických dat Základním módem vykreslování geometrie v OpenGL je bezprost°ední reºim (immediate mode), kdy jsou vrcholy a jejich vlastnosti zadávány ru£n¥ p°ímo p°i vykreslování. Tento reºim je jednoduchý, ov²em pon¥kud neforemný a p°i v¥t²ím mnoºství geometrie také pomalý. Alternativou jsou pole vrchol· (vertex arrays), kdy se vlastnosti vrchol· £tou z p°edem p°ipravených polí. Výhodou m·ºe být sdílení vrchol·, niº²í po£et volání funkcí a zvý²ení výkonnosti p°i vykreslování. Do této kategorie pat°í také vyuºití VBO (vertex buer object), kdy se vrcholy ukládají do buer· na video pam¥ti, coº op¥t zrychluje zpracování geometrie. Dal²í alternativou je pouºití struktury zvané display list [7], coº lze p°eloºit jako zobrazovací seznam. P°i vytvá°ení display listu se zavolají v²echny GL p°íkazy pro vytvo°ení geometrie a nastavení jejich vlastností, stejn¥ jako bychom cht¥li geometrii vykreslit v bezprost°edním mód·. Místo vykreslení jsou v²ak tyto p°íkazy uloºeny do pam¥ti. Celou geometrii pak m·ºeme jednodu²e opakovan¥ vykreslit pouhým zavoláním konkrétního display listu. Navíc jsou na²e p°íkazy p°edzpracovány a pokud moºno uloºeny do gra cké pam¥ti. V závislosti na konkrétním uºití a na hardwaru pak mohou display listy poskytnout výrazné zvý²ení výkonu. Hlavní nevýhodou je, ºe hotový display list nelze editovat. Výkon pot°ebný k vykreslení geometrie je v simulátoru zanedbatelný ve srovnání s nároky na zpracování objemových dat. Rad¥ji neº podle výkonu budu tedy volit podle osobních
16
KAPITOLA 4.
VOLBA PROSTEDÍ, NÁSTROJ A POSTUP
sympatií: display listy povaºuji za praktické a elegantní °e²ení. Z pohledu programátora jsou velmi p°ehledné a usnad¬ují opakované vykreslování stejných model·. Jejich hlavní nevýhoda by se v aplikaci v·bec nem¥la projevit, není d·vod k editaci model· za b¥hu.
Geometrie bude renderována p°eváºn¥ za pouºití display list·.
4.8 Projekce Je moºné jednodu²e implementovat jak perspektivní, tak ortogra ckou projekci. U perspektivní projekce by bylo nutné kompenzovat zvý²enou hustotu objemových dat ve v¥t²ích vzdálenostech, coº je ov²em banalita. Otázkou je, co p°iná²í v dané aplikaci lep²í výsledky. Perspektiva obvykle poskytuje uºivateli lep²í prostorový vjem a p·sobí p°irozen¥. Naproti tomu ortogra cké zobrazení p·sobí um¥le a uºivatel si musí chvíli zvykat, ºe se vzdáleností z·stávají velikosti konstantní. Jakmile v²ak tato základní pravidla p°ijme, m·ºe lépe porovnávat velikosti útvar· v r·zných vzdálenostech a snáze rozpozná nap°íklad rovnob¥ºné linky. V praxi se ve 3D zpravidla modeluje v ortogra cké projekci, hotové scény se pak p°edvádí v perspektiv¥. Simulátor operace je svým ur£ením n¥kde na p·l cesty mezi modelováním a prohlíºením. Po odzkou²ení obou projekcí na reálných datech jsem v²ak perspektivu vylou£il. Zejména u výrazných hran rovnob¥ºných se sm¥rem pohledu p·sobila ortogra e jako ostrý a p°esný pr·m¥t, zatímco perspektiva vypadala jako laciný rozmazaný efekt.
Simulátor bude vyuºívat ortogra ckou projekci.
4.9 Pohyb kamery Je °ada zp·sob·, jak se kamera ve scén¥ m·ºe pohybovat. Z po£íta£ových her ve trojrozm¥rném prostoru známe zejména pohled první osoby, kdy se st°ed otá£ení nachází p°ímo v míst¥ kamery. Druhou obvyklou kamerou ve hrách je t°etí osoba, kdy se st°ed otá£ení zpravidla otá£í kolem st°edu v n¥jaké vzdálenosti p°ed sebou (v míst¥, kde stojí hlavní postava). Nicmén¥ ve v¥t²in¥ her je posun kamery v prostoru n¥jak limitován (postava chodí po zemi) a navíc je tento pohyb ovládán klávesnicí. Samoz°ejm¥ lze umoºnit i pohyb v²emi sm¥ry, metodou létající první osoby. Tento zp·sob je intuitivní ve hrách, kde je hrᣠna pohled první osoby zvyklý. V simulátoru operace by v²ak dle mého p·sobil dost neohraban¥. Rad¥ji neº ve hrách budu hledat inspiraci ve 3D modelovacích programech. V t¥ch je zpravidla kamera implementována jako druºice na kulové plo²e s pohledem xovaným na pevný st°ed otá£ení. Dále je umoºn¥no posunutí kolmé na sm¥r pohledu (na které je uºivatel zvyklý z 2D aplikací, nap°íklad z digitální mapy) a zoom, který m¥ní polom¥r koule, po které se kamera pohybuje. Na tento zp·sob pohybu jsem zvyklý z °ady 3D aplikací, zdá se mi být velmi intuitivní a vhodný. Mohu jen doufat, ºe uºivatel bez zku²eností s podobnými programy bude souhlasit.
Kamera bude mít t°i módy pohybu, rotaci po kulové plo²e se sm¥rem pohledu xovaným na st°ed otá£ení, posun rovnob¥ºný s projek£ní plochou a p°iblíºení, tedy zm¥nu polom¥ru kulové plochy.
4.10.
POHYB ROUBU
17
4.10 Pohyb ²roubu Pohyb p°edm¥tem ve 3D prostoru je vºdy svým zp·sobem zrádný. Uºivatel vídí prostor namapován na projek£í plochu, £asto se tedy stane, ºe nemá ºádnou p°edstavu o vzdálenosti objekt· od kamery, dokud nezm¥ní úhel pohledu. Perspektivní projekce poskytuje alespo¬ £áste£nou p°edstavu tím, ºe se se vzdáleností m¥ní velikost. Z d·vod· zmín¥ných vý²e je v²ak v simulátoru pouºita projekce ortogra cká. V minulosti jsem pracoval s n¥kolika 3D editory, pohyb objektem byl v¥t²inou provád¥n rovnob¥ºn¥ se sou°adnými osami systému, p°ípadn¥ rovnob¥ºn¥ s projek£ní plochou. Tento zp·sob je výhodný zejména v tom, ºe je naprosto jasné, jakým sm¥rem se objekt práv¥ pohybuje. Pokud v²ak víme, ºe je objektem ²roub, m·ºeme uºivateli nabídnout i p°irozen¥j²í pohyb. M·ºeme umoºnit pohyb ²roubu podél jeho vlastní osy, p°ípadn¥ kolmo na ni. Pokud student nap°íklad umístí ²roub na vhodné místo, ale cht¥l by ho hloub¥ji za²roubovat, tento mód jeho práci výrazn¥ zjednodu²í. P°i vytvá°ení model· v²ak bude d·leºitou roli hrát orientace ²roubu a jeho vyst°ed¥ní, coº je t°eba autor·m model· zd·raznit. Ob¥ moºnosti, pohyb podél os systému a pohyb podél os ²roubu, mají své výhody a nevýhody. Netroufám si odhadovat, který zp·sob ovládání by byl u uºivatel· oblíben¥j²í. Vzhledem k tomu, ºe se tyto dv¥ moºnosti vzájemn¥ nevylu£ují, bude nejlep²í umoºnit oba zp·soby ovládání.
Pohyb ²roubu bude moºný jak podél os systému, tak vzhledem k vlastní ose ²roubu.
4.11 Architektonický vzor Tento projekt není primárn¥ návrhový, ale implementa£ní. Vzniku t°íd nechám tedy volný pr·b¥h. Je v²ak dobré drºet se aleso¬ £ást¥£n¥ n¥jakého základního sm¥ru. Základní architektura simulátoru nebude nijak sloºitá. Vstupním bodem simulace bude panel gra ckého uºivatelského rozhraní, jehoº instance si vytvo°í zbytek objekt· nutných pro chod simulátoru. Zárove¬ tento panel bude poskytovat rozhraní pro zbytek aplikace, není nutné míchat výukovou aplikaci s vnit°ní strukturou simulátoru. Kaºdá instance GUI si vytvo°í instanci t°ídy, která bude drºet informace o konkrétní simulaci. Nazývejme ji pracovn¥ t°eba scéna. Tato t°ída se bude starat o p°eváºnou £ást logiky simulátoru, bude p°ipravovat rendering pro gra cký kontext GUI. Také si bude drºet kolekci objekt· umíst¥ných ve scén¥. Tyto 3D objekty, nap°íklad ²rouby a CT obraz, budou reprezentovány objekty vlastní t°ídy, pravd¥podobn¥ se spole£ným p°edkem £i rozhraním. Budou si drºet v²echny své vlastnosti. Dalo by se °íct, ºe z tohoto nástinu vyplývá architektura podobná MVC, p°i£emº Model (3D objekty) nemá jednu vlastní t°ídu, ale je drºen v Controlleru jako kolekce. Gra cké rozhraní pak samoz°ejm¥ odpovídá £ásti View. Nepochybn¥ budou b¥hem implementace vznikat i dal²í t°ídy, napadá m¥ nap°íklad nutnost zpracování vstupních a výstupních soubor· a komunikace s databází. To by mohla dostate£n¥ °e²it statická t°ída poskytující pot°ebné metody.
Základ modulu bude vycházet z architektury MVC.
18
KAPITOLA 4.
VOLBA PROSTEDÍ, NÁSTROJ A POSTUP
Kapitola 5
Realizace B¥hem implementace jsem mnohokrát vyuºil informací z Internetu, zejména se jednalo o dokumentaci [8] [9] [10], tutoriály [16] a diskuze [12]. Vzhledem k pom¥rn¥ zna£nému rozsahu aplikace (simulátor má s komentá°i p°es 4000 °ádek kódu) zde nebudu detailn¥ rozebírat kaºdou £ást a zam¥°ím se jen na základní strukturu implementace. Pro podrobn¥j²í informace o implementaci doporu£uji pro£íst vlastní zdrojový kód s komentá°i, který je p°iloºen na CD. Ve²kerý kód simulátoru se nachází ve vlastním jmenném prostoru (namespace)
Panev.Simulation,
£emuº odpovídá i umíst¥ní kódu ve stejnojmenné
sloºce. Základní strukturu simulátoru lze p°ibliºn¥ popsat jako architekturu Model View Controller, a£koli na dodrºení tohoto architektonického vzoru nebyl kladen p°íli² velký d·raz. Rozhraní mezi jednotlivými £ástmi je pon¥kud ²ir²í a mén¥ z°etelné, neº je zvykem.
5.1 Model Hlavní data simulace jsou uloºena v jednotlivých 3D objektech. Pomocná data jako úhel pohledu jsou ov²em drºena p°ímo ve t°íd¥
GLWorkspace,
která se stará o v¥t²inu vnit°ní
logiky a lze ji ozna£it jako Controller. V²echny 3D objekty mají spole£ného p°edka, abstraktní t°ídu
Object3D. T°ídy objekt· z
ní d¥dí vlastnosti spole£né v²em typ·m objekt· v simulaci, jako je jméno, barva, viditelnost nebo zda je objekt práv¥ ozna£en. Také potomk·m p°edepisuje abstraktní metodu
Draw(),
která by po implementaci m¥la objekt vykreslit do aktivního gra ckého kontextu OpenGL. Navíc drºí statickou prom¥nnou
IDGenerator,
která m·ºe být pouºita pro p°id¥lování uni-
kátních identi kátor· novým objekt·m.
5.1.1 roub rouby mají vlastního potomka abstraktní t°ídy
Object3D, t°ídu Screw3D. Mají celou °adu
vlastností, d·leºitá je zejména pozice, rotace a velikost. Konstruktoru ²roubu je p°edána instance t°ídy
ModelSource,
která obsahuje mimo jiné identi kátor display listu pouºitého
19
20
KAPITOLA 5.
REALIZACE
3D modelu. roub si pamatuje jak identi kátor svého display listu pro vykreslování, tak sv·j
ModelSource pro p°ípadné uloºení a nahrání celé simulace v novém GL kontextu. ModelSource je drobná t°ída, která ze záznamu v databázi získá soubor s modelem, ze kterého pak nechá statickou t°ídou DisplayListMaster generovat display list. Identi kátor
display listu a základní informace o modelu si pak drºí v prom¥nných, p°ípadn¥ je poskytuje dal²ím objekt·m.
5.1.2 CT obraz CT obraz je reprezentován t°ídou
TextureSlices3D,
která je rovn¥º potomkem
Object3D. Tex-
Jejími p°idanými vlastnostmi jsou intenzita, alpha lter a procenta o°ezu. Konstruktor
tureSlices3D
p°ijímá jako parametr pole byt·, ve kterém jsou uloºena volumetrická data. Na
rozdíl od ²roubu drºí v¥t²í mnoºství display list·, konkrétn¥ dv¥ sady po ²esti kusech, jednu v plné kvalit¥ a druhou ve sníºené. Display listy jsou generovány statickou t°ídou
DisplayListMaster
p°ímo z pole byt·. CT
je implementováno metodou Texture Slices s °ezy zarovnanými podle objemu, nikoli podle pohledu. Z objemových dat je postavena 3D textura, kterou jsou pak v pravidelných intervalech proloºeny obdélníky °ez·, na které je tato textura namapována. Aby nedocházelo k situaci, ºe jsou °ezy rovnob¥ºné se sm¥rem pohledu, je generováno ²est sad °ez·. Nesta£í pouze t°i, protoºe je pot°eba zachovat back-to-front vykreslovací po°adí pro míchání barev.
5.1.3 Generátor display list· Statická t°ída
DisplayListMaster
jednak poskytuje simulátoru jednorázov¥ vytvo°ené dis-
play listy opakovan¥ pouºitých objekt· jako jsou osy systému, k°íº zna£ící t¥ºi²t¥ ²roubu a dal²í primitivní 3D objekty. Také v²ak vytvá°í display listy pro 3D objekty podle zadaných parametr·. roub je rekonstruován ze souboru .obj. Pouºil jsem kostru p·vodní £te£ky, která byla pouºita pro parsování .obj soubor· v p°edchozí verzi simulátoru. Vstupní soubory p°edchozí verze dodrºovaly konvence formátu .obj, ov²em kaºdý záznam m¥l vlastní °ádek (coº £te£ka o£ekává) a nebyly nastaveny normály. Pro zachování jakési kompatibility po£ítám se stejným formátem souboru i pro novou verzi, také budou recyklovány staré modely. V rámci kompatibility tedy ne£tu normály ze souboru .obj, ale pro kaºdý polygon je dopo£ítávám. Na£tené polygony i s normálami jsou pak uloºeny do display listu, jehoº identi kátor je metodou vrácen. Texturové °ezy pro CT obraz jsou vytvá°eny p°ímo z pole byt· objemových dat. Nejprve jsou data nahrána do pam¥ti jako 3D textura ve formátu Alpha8, aby zabírala co nejmén¥ pam¥ti a zachovala p°itom plnou kvalitu. Dále je vytvo°eno ²est display list·, jeden pro kaºdou stranu. Objemovou texturou jsou v pravidelných intervalech prokládány obdélníky, na které je polopr·hledná textura namapována. Pro dosaºení správného míchání barev jsou obdélníky kresleny odzadu dop°edu. P°i plné kvalit¥ (zadáno parametrem) jsou °ezy proloºeny kaºdým voxelem, p°i sníºené kvalit¥ se pak frekvence °ez· sniºuje. Identi kátory v²ech ²esti display list· jsou metodou vráceny.
5.2.
21
VIEW
5.2 View Gra cké rozhraní se nalézá p°ímo ve t°íd¥
Simulator, která je potomkem t°ídy UserControl.
Jedná se tedy o komponentu Windows Forms, coº je d·leºité pro za£len¥ní do výukové aplikace jako celku. Umoº¬uje nám to vyplnit simulátorem prázný panel, který je v aplikace pro simulaci vyhrazen. Gra cké rozhraní obsahuje dv¥ základní £ásti: ovládací prvky zprost°edkované b¥ºnými
komponentami
Windows
Forms
a
zobrazovací
plochu,
která
je
instancí
t°ídy
OpenTK.GLControl. Tato t°ída nám oproti hotov¥j²ím polotovar·m jako je GameWindow dává v¥t²í svobodu za cenu pon¥kud sloºit¥j²í reºie. Pro za£len¥ní do komplexn¥j²ího uºivatelského rozhraní je to ta nejvhodn¥j²í volba. P°i zavolání konstruktoru si GUI postaví celý základ simulace. B¥hem inicializace si mimo jiné vytvá°í instanci t°ídy
GLWorkspace
a seznamy objekt· jsou p°ipojeny ke svým
datovým zdroj·m. Potom se v závislosti na parametru konstruktoru na£te bu¤ profesorská, nebo studentská verze a inicializují se komponenty Windows Forms. Jednotlivé panely jsou p°ipojeny ke svým rodi£·m a podle módu skryty £i zobrazeny. Nakonec je zavolána metoda
Rescale(), která rozmístí panely v závislosti na velikosti okna. Po nahrání komponenty GLControl se inicializuje gra cký kontext OpenGL, který je pak po dobu simulace vyuºíván pro vykreslování scény. Simulator poskytuje GLWorkspace p°ístup k metodám nezbytným pro práci s GLControl, konkrétn¥ SwapBuers() a Invalidate(). T°ída Simulator sama neprovádí nic, co p°ímo nesouvisí s uºivatelským vstupem a s výstupem na obrazovku. Jediným úkolem je zprost°edkovat komunikaci mezi uºivatelem a t°ídou
GLWorkspace, která zaji²´uje logiku aplikace.
Gra cké rozhraní poskytuje uºivateli °adu ovládacích prvk·, od textových polí p°es tla£ítka k posuvník·m. Naprostá v¥t²ina handler· pak pracuje tím stylem, ºe handler p°e£te hodnotu a p°edá ji odpovídající ve°ejné metod¥
GLWorkspace. Stejným zp·sobem pracují i
mouse event handlery. Komunikace s
GLWorkspace funguje oboustrann¥. Simulator nap°íklad poskytuje metody GLWorkspace volá s aktuálními
pro aktualizaci hodnot na svých ovládacích prvcích, které údaji práv¥ ozna£eného 3D objektu.
Krom¥ hlavního okna simulátor vyuºívá je²t¥ n¥kolik drobn¥j²ích formulá°· p°i vytvá°ení nového zadání. Aº na vypisování tabulky z databáze, coº jsem prakticky opsal z p°edchozí verze simulátoru, nejsou implementa£n¥ nijak zajímavé.
5.3 Controller Controller je reprezentován t°ídou
GLWorkspace, která drºí celou simulaci pohromad¥. Udr-
ºuje aktuální informace o pohledu kamery, má referenci na CT obraz i na v²echny dal²í objekty ve scén¥. Zprost°edkovává oboustrannou komunikaci mezi Modelem a View, zná práv¥ ozna£ený 3D objekt a p°edává informace mezi uºivatelským rozhraním a tímto objektem. Nejv¥t²í £ást kódu se zabývá zpracováním událostí vyvolaných uºivatelem, konkrétn¥ pohybem my²i a pouºitím ovládacích prvk·. Metody ur£ené pro tento ú£el volá p°es své handlery View.
22
KAPITOLA 5.
GLWorkspace
REALIZACE
také zodpovídá za inicializaci a vykreslování scény v GL kontextu, který
GUI poskytuje. 3D objekty poskytují Controlleru metody pro své vlastní vykreslení, ten je pak jen poskládá dohromady.
5.4 Dal²í £ásti 5.4.1 CT obraz podrobn¥ji CT obraz má dv¥ sady display list· po ²esti stranách. O tom, který display list se pouºije, rozhodují parametry p°i volání funkce
Draw(...) na instanci t°ídy TextureSlices3D. Metoda je
informována o sou£asném úhlu pohledu kamery, podle kterého rozhodne, ze které strany má být objem zobrazen. Pohled zhora a zdola se aktivuje p°i p°ekro£ení
± 45 ◦
vertikálního úhlu,
◦ zbylý prostor je rozd¥len na kvadranty po 90 . S tímto rozd¥l¥ním nedochází k viditelným skok·m p°i p°epínání jednotlivých obraz·, pokud je frekvence °ez· dostate£n¥ vysoká. Dal²í parametr kreslící funkce m·ºe aktivovat zobrazení v nízké kvalit¥. Tento mód je aktivován, pouze pokud je uºivatelem povolen a pokud dochází k pohybu kamery nebo objektu ve scén¥. Statický obraz bude vºdy v plné kvalit¥, protoºe nepot°ebujeme vysokou zobrazovací frekvenci pro interakci. V sou£asné implementaci je tento mód pojat jako nouzový reºim pro slabý hardware, není ur£en pro b¥ºné pouºívání. Tomu odpovídá i jeho pon¥kud nep°íjemný obraz, který je dosaºen výrazným sníºením frekvence °ez·. Pokud by m¥l být reºim sníºené kvality £aso vyuºíván, doporu£uji jinou implementaci. Nap°íklad sníºení rozli²ení textury. CT obraz je moºno ze v²ech stran o°íznout pro získání jakéhosi pseudo-°ezu. Tato funkcionalita byla implementována pomocí GL.ClipPlane. Kaºdá ze ²esti ClipPlane má uloºenou vlastní rovnici, která je modi kována v závislosti na uºivatelském vstupu. ClipPlanes jsou zapnuty pouze pro renderování objemu, ²rouby jsou tedy vºdy zobrazeny celé. D·leºitým bodem pro vykreslení objemových dat je transforma£ní funkce (transfer function). P·vodní my²lenka byla nechat tuto funkci pln¥ uºivatelsky nastavitelnou, od toho jsem v²ak upustil. Zaprvé si nejsem jistý, ºe by se mi poda°ilo zachovat vysokou kompatibilitu se star²ím hardwarem (pokud by m¥l obraz reagovat na zm¥nu interaktivn¥), zadruhé by to kladlo pom¥rn¥ vysoké nároky na uºivatele. Nakonec jsem uºivatelské nastavení zredukoval jen na ty nejpot°ebn¥j²í operace. Základem implementované transforma£ní funkce je vhodn¥ nastavená funkce pro míchání barev:
GL.BlendFunc(BlendingFactorSrc.SrcAlpha, BlendingFactorDest.OneMinusSrcAlpha); Toto nastavení se b¥ºn¥ pouºívá pro polopr·hledné materiály a i v na²em p°ípad¥ dob°e poslouºí, jelikoº nepr·hlednost °ez· odpovídá intenzit¥ CT snímk·. Obraz z této funkce by v²ak byl v¥t²inou výrazn¥ p°esv¥tlený, proto uºivateli dávám moºnost sníºit intenzitu. To je velmi jednodu²e implementováno jako zvý²ení pr·hlednosti °ez·, na kterých je 3D textura mapována. V závislosti na po£tu snímk· a jejich intenzit¥ se budou cílové hodnoty li²it, pr·m¥rn¥ v²ak kvalitní obraz odpovídá zhruba 95% pr·hlednosti (tedy 5% alpha). Jelikoº chci zachovat rozsah 0 100%, ale zárove¬ poskytnout zvý²enou citlivost v nízkých hodnotách
5.4.
23
DALÍ ÁSTI
alpha, rozhodl jsem je nep°evád¥t vstup lineárn¥. Hodnotu X z uºivatelova posuvníku nakonec p°evádím na hodnotu alpha jako
X 4.
Uºivatelská hodnota 50% tedy odpovídá zhruba
6% alpha, zatímco krajní hodnoty 0% a 100% z·stávají. I p°i vhodném nastavení intenzity se v²ak kosti ztrácí mezi m¥kkými tkán¥mi, coº je v simulátoru zásadní problém. Umoº¬uji tedy uºivateli nastavit aplha lter, horní hranici pr·hlednosti, nad kterou se pr·hledné objekty p°estávají úpln¥ zobrazovat. Výsledek je ten, ºe kdyº uºivatel tuto hodnotu vhodn¥ nastaví, m¥kké tkán¥ z obrazu úpln¥ zmizí a kosti z·stanou nedot£eny. Samotný ltr je implementován pomocí GL.AlphaTest, kde alphaTreshold je uºivatelsky nastavená hodnota:
GL.AlphaFunc(AlphaFunction.Greater, (float)alphaTreshold); GL.Enable(EnableCap.AlphaTest); Výsledkem je dostate£ný nástroj k odstran¥ní m¥kkých tkání a zvýrazn¥ní kostí:
Obrázek 5.1: Pouºití ltru pro odstran¥ní m¥kkých tkání
5.4.2 rouby podrobn¥ji rouby nabízí celou °adu metod pro transformace (pohyb, rotace, zv¥t²ení, posun t¥ºi²t¥), které volá Controller po zpracování uºivatelských vstup· z View. Pohyb je implementován jak podél sou°adných os systému, tak podél vlastních os ²roubu. Rotace je implementována ve t°ech sm¥rech: kolem sou°adné osy Y, kolem osy ²roubu a kolem osy kolmé na ob¥ p°edchozí osy. St°ed otá£ení je vºdy v takzvaném t¥ºi²ti ²roubu, které je posouváno po hlavní ose uºivatelem. P°esn¥ji t¥ºi²t¥ z·stává na nulových lokálních sou°adnicích a model je posouván v opa£ném sm¥ru, p°i£emº tento posun je kompenzován posunem celé lokální soustavy tak, aby se uºivateli model ²roubu jevil nehybný. Implementace transformací je vcelku triviální, pokud nalezneme správné po°adí GL transforma£ních p°íkaz·. I rotace je nakonec implementována sérií
GL.Rotate(...), a£koli jsem v ur£itých fázích vývoje pouºíval rota£ní kvaterniony, abych
obe²el gimbal lock. P°i implementaci transformací ²roubu vyvstala otázka, jak citlivé mají transformace být. P°íli² citlvivé ovládání bylo velmi nep°íjemné p°i dola¤ování detail·, nízká citlivost zase
24
KAPITOLA 5.
REALIZACE
neumoº¬ovala p°ibliºn¥ umístit ²roub jedním tahem. Nakonec jsem citlivost ovládacích prvk· implementoval tak, ºe je nep°ímo úm¥rná p°iblíºení. P°i pohledu zdálky lze tedy ²roubem posouvat p°es celou scénu, p°i velkém p°iblíºení v²ak reaguje decentn¥. Zcela zásadní je methoda
Draw(), která samotný ²roub vykreslí. Pokud není ²roub ozna-
£en, pr·b¥h je triviální: OpenGL se p°edá barva ²roubu, ve správném po°adí se provedou transformace a je zavolán uloºený display list. Pokud je ²roub ozna£en, ale není jím práv¥ manipulováno, zobrazuje se ºlutou barvou. Dále se znázorn¥na jeho hlavní osa a poloha jeho t¥ºi²t¥. Po odzkou²ení transformací v simulátoru jsem se rozhodl poskytnout uºivateli n¥kolik vizuálních pom·cek, které mu pomohou zorientovat se v probíhající transformaci. Pro tento ú£el má ²roub bool hodnoty zna£ící, zda probíhá n¥která z transformací s vizuální pom·ckou. Tyto hodnoty jsou pak kontrolovány p°i renderování a p°ípadn¥ je jedna z pom·cek zobrazena. První z nich je aktivována p°i posunu ²roubu kolmo na jeho vlastní osu. Je zobrazena m°íºka roviny, po které se t¥ºi²t¥ m·ºe pohybovat, a zelené £áry, které zna£í sou£asnou polohu t¥ºi²t¥ v této rovin¥. Zatímco m°íºka je b¥hem pohybu statická, £áry se hýbou s t¥ºi²t¥m. Zárove¬ tyto £áry dosahují práv¥ k okraj·m m°íºky, ani blíº, ani dál. Pro implementaci této pom·cky bylo zapot°ebí zapamatovat si zm¥ny pozice p°i práv¥ provád¥ném posunu, aby mohl být pohyb m°íºky kompenzován a ta z·stala statická. Dále se vyskytly drobné nep°íjemnosti s hledáním takového po°adí transformací, které by v²echny zmín¥né vizuální pom·cky zobrazilo dle mých p°edstav. Nakonec jsem v²e vy°e²il dlouhou °adou vno°ených transformací, která dosáhla poºadovaného výsledku, ov²em nep°íli² elegantní cestou. Druhou pom·ckou jsou barevné kruhy p°i rotaci kolem osy Y a p°i rotaci kolem horizontální osy. St°ed obou kruh· je v t¥ºi²ti, tedy ve st°edu otá£ení. Modrý kruh je horizontální a statický, £ervený je vertikální a otá£í se kolem osy Y tak, ºe osa ²roubu prochází jeho pr·m¥rem. Na modrém kruhu je vyzna£en úhel, který ve vodorovné rovin¥ svírá jedna z pevných sou°adných os systému a pr·m¥t osy ²roubu do horizontální roviny. Na £erveném kruhu je pak vyzna£en úhel, který ve svislé rovin¥ svírá osa ²roubu a horizontální rovina. Zní to komplikovan¥, ale tato pom·cka alespo¬ netrp¥la váºnými problémy p°i ur£ování po°adí transformací. Oba kruhy se sice vykreslují na odd¥lených místech b¥hem série rotací, ani jeden v²ak nevyºaduje ºádné zp¥tné kompenzace.
5.4.3 Picking P·vodn¥ byly ²rouby ovládány pouze p°es ovládací prvky vn¥ zobrazovacího panelu
Control.
GL-
Jediná interakce p°ímo v obraze byl pohyb kamerou. Tento zp·sob sice fungoval,
bylo by v²ak p°íjemn¥j²í, kdyby byla moºná alespo¬ £áste£ná interakce s objektem p°ímo ve scén¥. Toho jsem dosáhl pomocí techniky zvané picking [11], která vyuºívá alternativního renderovacího módu:
GL.RenderMode(RenderingMode.Select); Ten nic nevykresluje na obrazovku, ale zapisuje jména renderovaných objekt· do speciálního bueru. Vhodným nastavením projekce pak m·ºeme zajistit, ºe se renderuje pouze oblast kurzoru my²i. Jinými slovy získáme jména objekt·, na které ve scén¥ ukazujeme. Pro
5.4.
25
DALÍ ÁSTI
tento ú£el má kaºdý ²roub své unikátní ID, které p°ed vykreslením pouºije jako jméno pro
GL.LoadName(ID). Zvlá²tní ID má také t¥ºi²t¥ ²roubu.
Tímto zp·sobem je implementováno ozna£ení ²roubu p°ímo v obraze, posun t¥ºi²t¥ chycením jeho zna£ky a n¥kolik transforma£ních mód· p°i taºení ²roubem.
5.4.4 Ukládání pozice Kaºdá uloºená pozice má odpovídající záznam v databázi, který mimo jiné obsahuje cestu k souboru s uloºenou simulací. P°esn¥ji ID tohoto záznamu odpovídá názvu souboru ve sloºce s uloºenými pozicemi. Tento postup je hojn¥ vyuºíván v celé výukové aplikaci. Simulace je kompletn¥ uloºena do XML souboru s pevn¥ danou strukturou pomocí t°ídy
XmlTextWriter,
GLWorkspace. Následn¥ m·ºe být ze souboru XmlTextReader, jehoº data GLWorkspace zpracuje do nové si-
které diktuje data instance
op¥t rekonstruována pomocí mulace.
5.4.5 P°evedení obrázk· na skalární pole Profesor nahrává do systému obrázky v b¥ºných formátech jako .jpg a .bmp. Do budoucna by byla vhodná i podpora formátu DICOM. Z vloºených obrázk· program po jednom vytvá°í objekt
Bitmap, se kterým je moºno pracovat nezávisle na vnit°ním formátu vstupního
souboru. Z bitmapy jsou pak £teny hodnoty pixel· a zapisovány do pole byt·, které bude tvo°it volumetrická data. Hodnoty jsou £teny pomocí metody
GetPixel(x, y), coº je sice po-
n¥kud pomalé, ale nedá se to zkazit. Vytvá°ení objemových dat ze snímk· se bude provád¥t maximáln¥ jednou pro kaºdé zadání simulace, drobná £asová prodleva tedy není problém. Výstupní pole byt· má následující formát:
8B hlavi£ka: 2B ²í°ka dat, 2B vý²ka dat, 2B hloubka dat, 1B velikost rezestupu snímk·, 1B nepouºitý
T¥lo: 1B intenzity pro kaºdý voxel tak, ºe jdou za sebou nep°eru²ovan¥ po °ádcích, které jdou za sebou po snímcích, které jsou °azeny v zadaném po°adí Data v tomto formátu jsou p°ed uloºením na FTP server je²t¥ komprimována pomocí t°ídy
GZipStream. Tím je dosaºeno p°ijatelné velikosti souboru a zárove¬ jsou data uloºena
bezztrátov¥. Soubor £ítající 150 snímk· o rozli²ení 512x512, coº povaºuji za pom¥rn¥ velký objem, má na serveru zhruba 5MB.
26
KAPITOLA 5.
REALIZACE
Kapitola 6
Testování Mnoºství provedených test· nepovaºuji za dostate£né. Vzhledem k omezeným podmínkám a nedostatku £asu m¥lo testování mnohem men²í rozsah, neº bych si p°ál. Stále je v²ak lep²í testování £áste£né neº ºádné.
6.1 Výkonnostní test Výkon programu byl testován na dvou strojích: na dva roky starém stolním po£íta£i a na p¥t let starém herním laptopu. Krom¥ b¥hu samotné simulace je n¥kolik dal²ích krok·, které kv·li velkému objemu dat mohou být £asov¥ náro£né. Staºení simulace ze serveru a nahrání do simulátoru trvá u pom¥rn¥ velkého objemu (150 snímk· 512x512) °ádov¥ 10 15 sekund. To povaºuji za rozumný stav pouºitelný v praxi. Vytvá°ení objemových dat stejného rozli²ení pak trvá zhruba 2 minuty. To je nep°íjemné, ov²em vytvá°ení volumetrického pole bude profesorem spou²t¥no pouze pro vytvo°ení nového zadání na nových datech. Student nebude tímto v·bec zasaºen, proto povaºuji del²í prodlevu za p°ijatelnou.
Laptop
•
Men²í objemové soubory (do 30 snímk· 512x512) pracovaly naprosto plynule.
•
Na st°edn¥ velkém souboru (50 snímk· 512x512) bylo moºno pozorovat lehké trhaní a pokles FPS na 10 20, coº je stále dostate£né pro interakci.
•
Velký soubor (150 snímk· 512x512) jiº vykazoval jasn¥ viditelné známky zpomalení, nástup pohybu zhruba 0.3 sekundy a pokles FPS na 5 10.
•
Nejv¥t²í soubor (300 snímk· 512x512) m¥l pak nástup pohybu zpoºd¥n o 0.5 sekundy a frekvence klesla na 2 5.
P°i pouºití nouzového módu sníºené kvality p°i pohybu bohuºel z·stal zpomalený nástup pohybu, FPS se v²ak následn¥ dostalo zp¥t do normálu a pohyb byl plynulý. P°idání ²roub· na výkon simulátoru nem¥lo vliv. 50 model· ²roubu, coº je mnohonásobn¥ více, neº lze v simulaci p°edpokládat, nem¥lo ºádný m¥°itelný dopad na výkon simulátoru s libovoln¥ velkým objemovým souborem.
27
28
KAPITOLA 6.
TESTOVÁNÍ
Stolní po£íta£ I nejv¥t²í testovaný soubor (300 snímk· 512x512) byl zobrazován naprosto plynule a to i v plné kvalit¥.
6.2 Uºivatelský test V²echny funkce simulátoru jsem samoz°ejm¥ osobn¥ vyzkou²el. S ovládáním jsem nem¥l nejmen²í problém, jakoºto autor jsem v²ak p°esn¥ v¥d¥l, co od programu o£ekávat a jaké moºnosti mi nabízí. Simulátor byl testován jen jedním nezávislým uºivatelem, studentkou bez p°edchozích zku²eností s podobnými programy £i s 3D modelováním. S velmi stru£nou instruktáºí, která je mnohem podrobn¥ji dostupná v uºivatelské p°íru£ce, byl uºivatel schopen b¥hem n¥kolika minut zvládnout základní ovládání programu. N¥jv¥t²ím problémem bylo ovládání ²roubu v 3D prostoru simulace, ov²em po n¥kolika minutách experimentování byl uºivatel schopen umis´ovat ²rouby p°esn¥ podle svých p°edstav v °ádech desítek sekund aº jednotek minut. Podle uºivatele by po pár hodinách pouºívání aplikace dostával ²rouby na ur£ené pozice s naprostou jistotou a mnohem rychleji.
Kapitola 7
Záv¥r 7.1 Zhodnocení projektu Simulátor, který je výstupem tohoto projektu, není v ºádném p°ípad¥ dokonalý. I p°es °adu nedostatk· v²ak povaºuji projekt za úsp¥²ný. Byl vytvo°en simulátor pouºitelný p°i výuce medik·, který je moºno v budoucnu dále vylep²ovat. Zárove¬ jsem se nau£il mnoho o samostatné práci na st°edn¥ velkém projektu, o vyhledávání informací, o komunikaci s dal²í stranou, o vizualizaci dat i o jazyku C#, ve kterém jsem p°edtím nikdy nepracoval. Také jsem m¥l moºnost nahlédnout do práce najatých profesionál·, kte°í psali zbytek aplikace Pánev. Nov¥ nabytých znalostí a zku²eností si váºím a doufám, ºe je v budoucnu uplatním i v dal²ích projektech. Program byl ve Vinohradské nemocnici prezentován zadavateli, který je s výsledky spokojen. Základní funkce simulátoru p°esn¥ odpovídají zadání a jsou pouºitelné p°i výuce, i kdyº existuje prostor k vylep²ení (podrobn¥ji v dal²í kapitole). Objemová data jsou zobrazována v dostate£né kvalit¥ a s p°ijatelnými nároky na hardware. Simulátor umoº¬uje uºivateli velmi jednodu²e odstranit z obrazu m¥kké tkán¥ a ponechat pouze kosti. rouby jsou ovladatelné n¥kolika zp·soby a po krátkém experimentování není problém jejich umis´ování zvládnout. P°i vhodném nastavení obrazu je vzájemná poloha ²roub· a kostí dostate£n¥ z°etelná. Profesor m·ºe jednodu²e vytvo°it zadání na konkrétních CT datech, se slovním popisem úkol· a se seznamem model·, které jsou pro simulaci k dispozici. Student m·ºe snadno svou pozici uloºit £i nahrát, p°ípadn¥ obnovit zadání. Uloºené pozice student· si profesor m·ºe prohlíºet. Základní funk£nost je tedy zaji²t¥na, nedostatky v²ak z·stávají. Následující body povaºuji za nejv¥t²í slabiny simulátoru:
•
Reºim zobrazení je bohuºel nem¥nný, k dispozici je pouze akumulace intenzity, coº zhruba odpovídá rentgenovému snímku. Zobrazení sice poskytuje dostate£nou p°edstavu o vzájemné poloze kostí a ²roub· a je relativn¥ rychlé, není v²ak vizuáln¥ p°íli² efektní.
•
Transforma£ní funkce není pln¥ uºivatelsky nastavitelná. A£koli zm¥na intenzity a hranice pro odstran¥ní m¥kkých tkání poskytují dostate£né moºnosti pro provedení simulace, chybí úplná uºivatelská kontrola.
29
30
KAPITOLA 7.
•
ZÁV
R
Na starém a nevýkonném hardwaru mohou nastat problémy s rychlostí zobrazování objemu a v¥t²í objemy mohou být neúnosn¥ pomalé. Na st°edn¥ výkonném laptopu starém p¥t let lze se simulátorem úsp¥²n¥ pracovat, p°i v¥t²ích objemech dat (v reºimu plné kvality) v²ak aplikace ztrácí plynulost obrazu a je pot°eba kvalitu p°i pohybu sníºit.
•
Ovládání objekt· ve 3D není intuitivní.
7.2 Moºnosti dal²ího vývoje 7.2.1 V¥t²í p°izp·sobitelnost zobrazovacího módu Prvním vylep²ením, které bych p°idal, by byl n¥jaký alternativní nepr·hledný mód. Rentgenový pohled poskytuje dobrý p°ehled o vnit°ních strukturách, ale po umíst¥ní ²roubu je dobré mít moºnost zkontrolovat, kde ²roub protíná povrch kosti a zda n¥kde netr£í ven. To by bylo lépe vid¥t v módu, kde jsou kosti zcela nepr·hledné. Dal²í moºností je pln¥ nastavitelná transforma£ní funkce. Uºivatel by nastavoval její pr·b¥h nap°íklad k°ivkou v histogramu obrazu. Tím by se výrazn¥ zvý²il vliv uºivatele na zobrazení, zárove¬ by se v²ak od n¥j o£ekávala schopnost s histogramem pracovat. A pokud by m¥l obraz reagovat v reálném £ase, byla by pot°eba hlub²í zm¥na zobrazovací metody. Jednorázové nastavení by se dalo pom¥rn¥ snadno implementovat jako p°emapování volumetrických dat p°ed vytvo°ením textury.
7.2.2 Vhodn¥j²í nastavení kvality V sou£asnosti simulátor podporuje pouze dva reºimy kvality: plnou kvalitu a vynechání °ez· p°i pohybu. Vynechání °ez· sice výrazn¥ zvy²uje rychlost, nevypadá v²ak v·bec dob°e. Pokud bude reºim sníºené kvality z výkonnostních d·vod· £asto vyuºíván, doporu£uji n¥jakou vhodn¥j²í implementaci. Nabízí se nap°íklad vyuºít p°i pohybu 3D texturu s niº²ím rozli²ením ve stylu mipmaps.
7.2.3 tení DICOM Vstupní soubory pro objemová data nyní tvo°í obrázky ve formátech .jpeg, .bmp a .png. Naprostá v¥t²ina medicínských dat je v²ak k dispozici ve fomátu DICOM. Existuje °ada freeware nástroj· pro p°evod DICOM na .jpeg, ale samoz°ejm¥ by bylo vhodn¥j²í, kdyby simulátor um¥l DICOM soubory zpracovávat samostatn¥.
7.2.4 P°idání dal²ích chirurgických objekt· Sou£asný simulátor je schopen pracovat s libovolným modelem ve správném formátu, ale vºdy se k n¥mu bude chovat jako ke ²roubu. Pokud komponenta nemá jednozna£n¥ ur£enou hlavní osu (osa ²roubu je naprosto zjevná), m·ºe být ovládání nep°irozené. Komponenta bude fungovat a v²echny pozice budou dosaºitelné, ne vºdy v²ak pohodlnou cestou. P°idáním dal²ích typ· objekt· s vlastním reºimem ovládání lze tomuto p°edejít.
7.2.
MONOSTI DALÍHO VÝVOJE
31
7.2.5 Zlep²ení ovládání Ovládání ²roub· v prostoru je funk£ní, netroufám si v²ak odhadovat, zda je pro uºivatele snadno pochopitelné a intuitivní. Nepochybuji o tom, ºe je moºné tento systém n¥jak vylep²it. K tomu by v²ak bylo pot°eba více zku²eností nebo odezva v¥t²ího mnoºství uºivatel·. Dal²í moºností pro zvý²ení efektivity ovládání jsou hotkeys, klávesové zkratky pro nej£ast¥ji vyuºívané operace.
7.2.6 Práce s vy²²ím výkonem V simulátoru je kladen velký d·raz na kompatibilitu se star²ím hardware. Pokud v²ak tato pot°eba zmizí nebo budou fungovat odd¥lené verze v závislosti na hardware, otevírá se spousta moºností. Nabízí se vyuºití programovatelných shader·, vykreslování stínovaných ploch pomocí gradientu, zobrazování raycastingem namísto textur a °ada dal²ích inovací s vy²²ími hardwarovými nároky.
32
KAPITOLA 7.
ZÁV
R
Literatura [1] BENTOUMI, H. GAUTRON, P. BOUATOUCH, K. GPU-Based Volume Rendering for Medical Imagery.
http://www.waset.org/journals/ijeee/v4/v4-1-5.pdf,
stav z 27. 4. 2012.
[2] BOURKE, P. Polygonising a scalar eld.
http://local.wasp.uwa.edu.au/~pbourke/geometry/polygonise/index.html,
stav
z 5. 4. 2012. [3] ENGEL, K. KRAUS, M. ERTL, T. High-Quality Pre-Integrated Volume Rendering Using Hardware-Accelerated Pixel Shading.
http://www.vis.uni-stuttgart.de/~engel/pre-integrated/, [4] HANSEN, C. D. JOHNSON, C. R.
stav z 15. 4. 2012.
The Visualization Handbook.
Kitware, Inc., 1st
edition, 2005. [5] P°isp¥vatelé Wikipedie. Wikipedia: Volume Rendering.
http://en.wikipedia.org/wiki/Volume_rendering, [6] SCHROEDER, W. MARTIN, K. LORENSEN, B.
stav z 27. 4. 2012.
Visualization Toolkit.
Kitware,
Inc., 3rd edition, 2003. [7] web:dl. Display List Tutorial.
http://www.lighthouse3d.com/opengl/displaylists/,
stav z 25. 4. 2012.
[8] web:msdn. Microsoft Developer Network.
http://msdn.microsoft.com/library/,
stav z 27. 4. 2012.
[9] web:opengl. OpenGL.
http://www.opengl.org/,
stav z 27. 4. 2012.
[10] web:opentk. Open Toolkit.
http://www.opentk.com/,
stav z 27. 4. 2012.
[11] web:picking. OpenGL Tutorial: Picking.
http://content.gpwiki.org/index.php/OpenGL:Tutorials:Picking, 25. 4. 2012. [12] web:stackover ow. Stack Over ow.
http://stackoverflow.com/,
stav z 27. 4. 2012.
33
stav
z
34
LITERATURA
[13] web:stats1. Hardwarový a softwarový výzkum Steamu: April 2012.
http://store.steampowered.com/hwsurvey/,
stav z 22. 5. 2012.
[14] web:stats2. Minecraft Hardware Data.
http://stats.minecraft.net/,
stav z 22. 5. 2012.
[15] web:stats3. Web Player Hardware Statistics.
http://unity3d.com/webplayer/hwstats/,
stav z 22. 5. 2012.
[16] web:swift. Swiftless Tutorials: OpenGL.
http://www.swiftless.com/opengltuts.html,
stav z 27. 4. 2012.
P°íloha A
Screenshoty
Obrázek A.1: Screenshot 1
35
36
PÍLOHA A.
Obrázek A.2: Screenshot 2
Obrázek A.3: Screenshot 3
SCREENSHOTY
P°íloha B
Uºivatelská p°íru£ka B.1 Instalace Simulátor je sou£ástí výukového programu Pánev 0.85. Program se instaluje technologií ClickOnce, sta£í tedy v instala£ním balí£ku spustit setup.exe. Instalátor vytvo°í zástupce v nabídce Start. Instalovaný program je ur£en pro b¥h p°ímo v nemocni£ní lokální síti, jinde se aplikaci nepoda°í p°ipojit k serveru. P°i prvním spu²t¥ní simulátoru m·ºe program poºádat o povolení administrátora kv·li komunikaci se serverem, v takovém p°ípad¥ p°ipojení povolte a program restartujte. Program lze pozd¥ji odinstalovat prost°ednictvím ovládacích panel·. (P°idat nebo odebrat programy pro star²í Windows jako XP, Programy a funkce pro nov¥j²í systémy jako Win7)
B.2 Studentská £ást Pokud si nejste jisti, co který ovládací prvek v simulátoru d¥lá, ukaºte my²í na n¥j nebo jeho popisku. V¥t²ina d·leºitých prvk· vám vypí²e stru£ný popis své funkce.
B.2.1 Spu²t¥ní simulace Studenti mají do simulátoru p°ístup v modulu Výuka v sekci Simulace, pokud je v jejich kurzu n¥jaká simulace za°azena. Ze seznamu simulací v horní £ásti simulátoru zvolí student konkrétní zadání. Pokud jiº v minulosti na tomto zadání pracoval a svou pozici uloºil, bude tato pozice nahrána. V opa£ném p°ípad¥ bude nahráno £isté zadání. Otev°ení simulace m·ºe trvat aº n¥kolik desítek sekund, data se stahují ze serveru, bu¤te proto trp¥liví.
B.2.2 Ukládání a nahrávání Na horní li²t¥ má student moºnost uloºit svou pozici, tedy sou£asný stav otev°ené simulace v£etn¥ pohledu kamery, vloºených objekt· a v²ech jejich vlastností. Vedlej²í tla£ítko mu umoºní svou uloºenou pozici op¥t nahrát, pokud provede v simulaci neºádoucí zm¥ny. Poslední tla£ítko horní li²ty obnoví p·vodní zadání simulace, pokud chce student znovu za£ít z výchozí pozice.
37
38
PÍLOHA B.
UIVATELSKÁ PÍRUKA
Spr ávceobj ekt ů
Úkol ysi mul ace
Vl ast nost ioznačenéhoobj ekt u
Nahr áváníaukl ádánísi mul ace
Zobr azovacípr ost or
Obrázek B.1: Základní rozloºení uºivatelského rozhraní
B.2.3 Úkoly P°ímo nad hlavním zobrazovacím panelem simulátoru je °ádka s textem úkolu. Tla£ítka se ²ipkami po jejích stranách p°epínají mezi jednotlivými úkoly.
B.2.4 Pohyb kamery Ovládání kamery probíhá p°ímo v zobrazovacím prostoru. V²echny pohyby kamerou probíhají podobn¥, spou²tí se stiskem n¥kterého tla£ítka my²i v prázdné oblasti zobrazovacího prostoru. Tím rozum¥j oblast bez ²roub· a komponent, samotný CT obraz se chová jako prázdný prostor. Se stisknutým tla£ítkem pak pohybuj my²í. Kamera má t°i základní módy pohybu:
•
Posun, který se spou²tí levým tla£ítkem my²i.
•
Rotaci, která se spou²tí pravým tla£ítkem my²i.
•
P°iblíºení, které se spou²tí prost°edním tla£ítkem my²i. Alternativou je p°iblíºení kole£kem.
Doporu£uji s pohybem kamery chvíli experimentovat, je to mnohem ú£inn¥j²í neº jakýkoli slovní popis.
B.2.
STUDENTSKÁ ÁST
39
B.2.5 Správce objekt· Levý panel simulátoru reprezentuje správce objekt·. V simulaci se vyskytují dva zádladní typy objekt·: CT obraz a vloºené objekty (²rouby). CT obraz je pevn¥ svázán se zadáním simulace, student ho tedy nem·ºe nahradit. Seznam povolených typ· objektu pro vloºení je v horní £ásti panelu objekt· a je rovn¥º ur£en zadáním. Tla£ítko P°idat objekt vloºí do simulace jednu kopii typu, který jste v horním okénku zvolili. V²echny objekty pouºité v simulaci jsou vypsány v seznamu, který tvo°í nejv¥t²í £ást správce objekt·. Kliknutím na poloºku v seznamu je objekt ozna£en a je moºné modi kovat jeho vlastnosti, p°ípadn¥ ho smazat tla£ítkem Odstranit objekt. Alternativou k ozna£ení ²roubu ze seznamu je ozna£ení kliknutím na ²roub p°ímo v zobrazovacím panelu.
B.2.6 Vlastnosti objekt· V²echny zmi¬ované vlastnosti se vztahují k objektu, který je práv¥ ozna£en v seznamu objekt·. N¥které vlastnosti jsou pro v²echny typy objektu spole£né, jiné jsou pro daný typ speci cké. Pokud má jedna vlastnost více ovládacích prvk·, nap°íklad posuvník a £íselnou hodnotu, jsou vzájemn¥ provázané a není pot°eba nastavovat ob¥ hodnoty. V²echny objekty mají vlevo dole (pod správcem objekt·) své nejobecn¥j²í údaje: své jméno a stru£ný popis, pokud ho n¥kdo vyplnil. V této oblasti najdete také polí£ko Zobrazit objekt. Pokud je za²rtnuté, objekt se normáln¥ v simulaci zobrazuje. V opa£ném p°ípad¥ je objekt neviditelný, stále v²ak existuje a zachovává si v²echny ostatní vlastnosti. Za²krtnutím polí£ka se op¥t zobrazí. Dále mají v²echny objekty podrobn¥j²í panel vlastností na pravé stran¥ obrazovky. Úpln¥ naho°e je nastavení barvy objektu. Nenechte se zmást tím, ºe ozna£ený ²roub z·stává ºlutý, po odzna£ení bude mít zvolenou barvu.
B.2.7 Speci cké vlastnosti CT obrazu Pokud je ve správci objekt· ozna£en CT obraz, panel vlastností na pravé stran¥ bude krom¥ barvy umoº¬ovat dal²í speci cké nastavení. Velmi d·leºitým nástrojem je Dolní hranice. Je to hranice intenzity CT snímku, pod kterou se jeho obsah nezobrazí. Jelikoº m¥kké tkán¥ mají na snímku niº²í intenzitu neº kosti, je moºné tímto nástrojem z obrazu m¥kké tkán¥ odstranit a kosti zachovat. Dal²í vlastností CT obrazu je intenzita. Pokud je obraz p°esv¥tlený nebo naopak p°íli² tmavý, intenzitou lze toto korigovat. Pozor, p°edchozí nastavení Dolní hranice je p°ímo závislé na hodnot¥ intenzity! Pokud m¥níte intenzitu obrazu, m·ºe se stát, ºe bude pot°eba doladit hodnotu Dolní hranice. Poslední pom·ckou pro vhodn¥j²í zobrazení CT je O°ez. Skládá se ze ²esti posuvník·, kaºdý nastavuje úrove¬ o°ezu z jedné strany, p°i ukázání my²í vypí²e ze které. Pokud chcete nap°íklad zobrazit pouze levou £tvrtinu obrazu, nastavíte pátý posuvník (Pravá) zhruba na £tvrtinu p·vodní hodnoty. Pokud chcete získat horizontální °ez obrazem zhruba v polovin¥, nastavíte t°etí a £tvrtý posuvník (Horní, Dolní) oba na polovinu.
40
PÍLOHA B.
UIVATELSKÁ PÍRUKA
B.2.8 Speci cké vlastnosti ²roubu Pokud je ozna£en ²roub, jeho vlastnosti jsou k dispozici v pravém panelu. Pro ²roub je ur£ující jeho poloha, rotace, velikost a poloha t¥ºi²t¥. Pravým st°edem ²roubu není st°ed jeho modelu, ale práv¥ jeho teºi²t¥, kterým m·ºete po jeho ose pohybovat. To je t°eba mít na pam¥ti zejména p°i rotacích. Tla£ítka, která p°i najetí my²í zobrazují kurzor ²ipky nahoru-dol·, fungují tak, ºe na nich stisknete tla£ítko my²i a pak my²í, se stále stisknutým tla£ítkem, táhnete nahoru £i dol·. Ablosutní posun nabízí zp·sob, jak posouvat ²roubem nezávisle na jeho orientaci. Pokud chcete pusouvat ²roub podél sou°adných os celého systému, toto je nejlep²í zp·sob. Osy X, Y a Z budou vºdy statické v·£i CT obrazu. Krom¥ zadávání hodnot na £íselníku je také moºné táhnout pomocí my²i tla£ítkem po jeho pravé stran¥ nahoru £i dol·. Nap°íklad chcete-li posunout ozna£ený ²roub podél zelené osy sm¥rem nahoru, stisknete zelené tla£ítko Y a potáhnete nahoru my²í. Relativní posun umoº¬uje pohybovat ²roubem v závislosti na jeho orientaci. Kolmo horizontáln¥ vyjad°uje pohyb po ose, která je kolmá na osu ²roubu a zárove¬ je horizontální v·£i sou°adnému systému. Kolmo vertikáln¥ pak zna£í pohyb po ose kolmé jak na osu ²roubu, tak na horizontální osu zmín¥nou u p°edchozí funkce. Podél ²roubu znamená pohyb podél osy ²roubu. Alternativou k t¥mto tla£ítk·m je pak taºení ozna£eného ²roubu p°ímo v zobrazovacím panelu. Pohybu Podél ²roubu odpovídá tah prost°edním tla£ítkem my²i, horizontální a vertikální kolmý pohyb je pak kombinován tahem levým tla£ítkem my²i. T¥ºi²t¥ je u ozna£eného ²roubu reprezentováno r·ºovým zam¥°ova£em. T¥ºi²t¥ ur£uje st°ed otá£ení ²roubu, jeho posun je moºný pouze podél jeho osy. Krom¥ tla£ítka je také moºné t¥ºi²t¥ posouvat taºením r·ºového zam¥°ova£e p°ímo v zobrazovacím panelu. Rotace ²roubu probíhá ve t°ech sm¥rech, st°ed rotace je vºdy v t¥ºi²ti ²roubu. Horizontální rotace otá£í ²roubem kolem vertikální osy sou°adnicového systému, tedy zelené osy Y. Na kouli si ji lze p°edstavit jako zem¥pisnou délku. B¥hem rotace je znározn¥na modrým kruhem. Vertikální rotace otá£í ²roubem kolem osy, která je kolmá na osu ²roubu a zárove¬ horizontální v·£i sou°adnému systému. Lze si ji p°edstavit jako zem¥pisnou ²í°ku a b¥hem rotace je znázorn¥na £erveným kruhem. Rotace V ose otá£í ²roubem kolem jeho vlastní osy. Alternativním módem ovládání horizontální a vertikální rotace je taºení ²roubu pravým tla£ítkem my²i p°ímo v zobrazovacím panelu. Zm¥na velikosti probíhá uniformn¥ ve v²ech sm¥rech. Jednosm¥rná deformace ²roubu není moºná.
B.2.9 Tla£ítka v zobrazovacím panelu V levém horním rohu obrazu se nalézají dv¥ tla£ítka. Jedním se zapína zobrazení barevných os sou°adného systému. Druhé umoº¬uje simulátoru vynechávat ur£itý po£et °ez· a tím zvý²it rychlost reakce simulátoru na pohyb. P°i pohybu se tím výrazným zp·sobem sniºuje p°ehlednost a kvalita obrazu. Povaºujte tuto moºnost za nouzové °e²ení, pokud slab²í po£íta£ nestíhá obraz p°i pohybu zobrazovat.
B.3.
ADMINISTRANÍ ÁST
41
B.3 Administra£ní £ást Simulátor funguje velmi podobn¥ jako verze pro studenty, zmi¬uji zde pouze rozdíly. Pokud pot°ebujete p°íru£ku k simulátoru jako celku, prostudujte prosím ob¥ £ásti.
B.3.1 Vytvá°ení simulace Simulaci lze vytvo°it £i upravit v modulu Správa kurz· v sekci Simulace operace. Pro pouhou úpravu stávající simulace zvolte zadání z levého sloupce. Pro vytvo°ení nového zadání pouºijte tla£ítko Vytvo°it nový, vypl¬te jméno zadání a zvolte bu¤ moºnost vytvo°it prázdnou simulaci, nebo kopii jedné ze stávajících. Horní li²ta také nabízí tla£ítka Uloº a Odstra¬. Prvním z nich uloºíte ve²keré provedené zm¥ny v otev°ené simulaci. Tím druhým zadání kompletn¥ odstraníte. D·razn¥ doporu£uji p°ed odstran¥ním odebrat zadání ze v²ech kurz·, ve kterých se vyskytuje.
B.3.2 CT obraz Do simulace p°idejte CT obraz tla£ítkem Nahrát CT obraz. V kaºdé simulaci m·ºe být práv¥ jeden, nahráním nového nahradíte ten p°edchozí. V okn¥ se seznamem zvolte z databáze jeden z nahraných CT obraz· a klikn¥te na P°idat soubor do simulace. Pokud pot°ebujete vytvo°it nový soubor z obrázk· v po£íta£i, zvolte místo toho Vytvo°it nový soubor. Ve vyskakovacím okn¥ nahrajte do seznamu na pravé stran¥ obrázkové soubory s CT scany. V pr·zkumníku m·ºete vybrat více obrázk· najednou, zpravidla není nutné je p°idávat po jednom. Program p°ijímá obrázky ve formátu .jpg (.jpeg), .png a .bmp. Pro správné zobrazení musí být obrázky v seznamu se°azeny a musí mít v²echny stejné rozli²ení. M¥la by fungovat v²echna rozli²ení, optimální jsou v²ak soubory 256x256 a 512x512 pixel·, ideáln¥ £ernobílé. Po£et snímk· není aplikací omezen, p°íli² velký po£et v²ak m·ºe na star²ích po£íta£ích zp·sobit problémy s výkonem nebo pam¥tí. Za rozumný po£et i pro mén¥ výkonný stroj povaºujte 50 aº 200 snímk·. Po vloºení obrázkových soubor· zadejte vzdálenost mezi °ezy. Pokud vzdálenost mezi °ezy odpovídá velikosti jednoho pixelu v obrázku, zvolte hodnotu 1. Pokud vzdálenost °ez· neznáte, doporu£uji experimentovat. S nejv¥t²í pravd¥podobností se jedná o malé £íslo do hodnoty 5. Pokud je výsledný obraz v simulátoru protaºený £i zkrácený podle modré osy Z, byla ²patn¥ zadána práv¥ tato hodnota. Nakonec vypl¬te jméno, pod kterým se CT soubor uloºí do databáze a klikn¥te na Vytvo°it CT soubor. V²echny obrázky se nyní musí p°e£íst, zpracovat do speciálního formátu a uloºit na server, coº m·ºe dohromady trvat i n¥kolik minut. Pokud se neobjeví ºádná chybová hlá²ka, bu¤te prosím trp¥liví.
B.3.3 Zdroje 3D Zdroje 3D model· reprezentují seznam objekt·, které pak m·ºe student do simulace v libovolném po£tu vkládat. Zdroj p°idáte tla£ítkem P°idat zdroj 3D, poté vyberete jeden ze záznam· v databázi a zvolíte P°idat soubor do simulace. Pokud po°ebujete nahrát nový model z po£íta£e, zvolte místo toho Vytvo°it nový zdrojový soubor. Ve vyskakovacím okn¥ vypl¬te název pro databázi a pomocí Procházet nahrajte soubor s modelem. Model musí být ve formátu .obj. Pokud se má model v simulátoru
42
PÍLOHA B.
UIVATELSKÁ PÍRUKA
správn¥ chovat, je d·leºité, aby jiº v p·vodním formátu leºel na ose a m¥l správnou orientaci. Normály nejsou d·leºité, simulátor si je dopo£ítá. Ani barva není d·leºitá, simulátor ji zm¥ní. Textury a materiály nejsou podporovány a budou odebrány.
B.3.4 Úkoly Na rozdíl od studentské £ásti je zde umoºn¥na editace °ádky s úkolem. Na £íselníku vpravo od ní nastavte po£et úkol·. ipkami vedle °ádky p°epínejte úkoly a postupn¥ v²echny vypl¬te. Nakonec p°epn¥te na úkol, který se má zobrazit p°i spu²t¥ní zadání (pravd¥podobn¥ první). Simulátor totiº p°i spu²t¥ní nep°etá£í na první úkol, ale na ten, který byl p°i uloºení aktivní. Pro p°ehlednost se doporu£uje úkoly £íslovat, není to v²ak pravidlem.
B.3.5 Po£áte£ní stav Po vytvo°ení samotného zadání m·ºete provád¥t v²echny úpravy, které by mohl provád¥t student. M·ºete nap°íklad p°ednastavit vhodné vlastnosti pro zobrazení CT £i vloºit a nastavit ²rouby. Student·m se pak tato pozice nahraje jako výchozí, nebrání jim to v²ak v provád¥ní zm¥n této pozice v jejich vlastní simulaci.
B.3.6 P°idání do kurzu P°ed opu²t¥ním edita£ního módu nezapome¬te tla£ítkem Uloº potvrdit zadání! Hotová zadání m·ºete p°idávat do kurz· jako v²echny dal²í poloºky v modulu Správa kurz· v sekci Kurzy.
B.3.7 Prohlíºení studenstkých simulací V modulu Správa kurz· v sekci Statistiky simulací m·ºete prohlíºet uloºené pozice v²ech student· na v²ech zadáních. V horní £ásti obrazovky m·ºete výsledky ltrovat. Konkrétní uloºenou pozici snadno otev°ete v tabulce tla£ítkem Zobrazit simulaci. Máte moºnost simulaci prohlíºet i m¥nit její stav pro lep²í interpretaci, nem·ºete v²ak uloºit provedené zm¥ny.
P°íloha C
Seznam pouºitých zkratek 2D
Two-Dimensional
3D
Three-Dimensional
API
Application Programming Interface
CAD
Computer-Aided Design
CPU
Central Processing Unit
CT
Computer Tomography
DICOM
Digital Imaging and Communications in Medicine
FPS
Frames per Second
FTP
File Transfer Protocol
GUI
Graphical User Interface
GPU
Graphics Processing Unit
LINQ MRI MVC
Language Integrated Query
Magnetic Resonance Imaging Model - View - Controller
NURBS
Non-Uniform Rational B-Spline
43
44
PÍLOHA C.
SEZNAM POUITÝCH ZKRATEK
P°íloha D
Obsah p°iloºeného CD P°iloºené CD obsahuje t°i sloºky a jeden soubor:
•
Sloºka
local_simulator obsahuje v²e pot°ebné ke zprovozn¥ní testovací aplikace s lokální
databází. Je v ní p°iloºen také návod ve formátu PDF.
•
Sloºka
panev_85
obsahuje instala£ní balí£ek a zdrojový kód aplikace Pánev verze 0.85.
Je v ní p°iloºena také uºivatelská p°íru£ka k simulátoru ve formátu PDF.
•
Sloºka
text
obsahuje text této práce ve formátu PDF a soubory sázecího programu
TeX.
•
Soubor
readme.txt
obsahuje podrobn¥j²í informace o obsahu CD.
45
