VASTAGBÉL DAGANATOK DIAGNOSZTIKÁJÁNAK AUTOMATIZÁLÁSA

Átírás

1 Budapesti Műszaki Főiskola Neumann János Informatikai Kar Szoftvertechnológia Intézet TUDOMÁNYOS DIÁKKÖRI DOLGOZAT VASTAGBÉL DAGANATOK DIAGNOSZTIKÁJÁNAK AUTOMATIZÁLÁSA Szerzők: Bándi István mérnők informatikus szak, IV. évf. Reményi Attila mérnők informatikus szak, IV. évf. Konzulensek: Kozlovszky Miklós ügyvivő szakértő Vámossy Zoltán főiskolai docens Budapest, 2009.

2 1 Tartalomjegyzék 1 Tartalomjegyzék Bevezetés Problémaleírás Célkitűzés Biológia háttér A vastagbél A vastagbél nyálkahártya A vastagbél betegségei [5] Gyulladásos betegségek A diszplázia Informatikai háttér Hasonló programok Képfeldolgozó keretrendszerek Intel IPP OpenCv Masszívan párhuzamos programozás alternatívái CUDA (Compute Unifed Device Architecture) [7] CUDA alapjai Programozási modell Kernelek és szálak Memória hierarchia CUDA API Probléma megoldásának megközelítése Program architektúrája Digitális metszet kezelés A digitális metszetek kezelése a gyakorlatban Cuda használata.net-ben Sejtmagdetektálás A probléma ismertetése Konvertálás HSV modellbe [23] Az algoritmus Oldal 1

3 7.4 Ultimate Erode Sejtmagok paramétereinek mérése Kitöltő algoritmus Körvonal detektáló Átmérők megállapítása [21] Mirigydetektálás A probléma megismerése: Az algoritmus Háló készítése [21] Hámdetektálás A probléma megismerése A detektáló algoritmus Sejtmagok differenciálása Képfeldolgozás gyorsítása GPGPU segítségével Alapok, használat Futásidejű API Meghajtó API A szegmentáló kernel A teljesítménymérő alkalmazás A zajszűrő kernel Globális memória Beépített struktúra használata Négy bájt olvasása, három bájt írása Textúra alkalmazása bájt Osztott memória Redundancia megszüntetése Adatlehívás sorrendjének megváltoztatása Optimalizálás számításra Egyéb algoritmusok Paraméterek mérése Megvalósított paraméterek ismertetetése Tesztelés Oldal 2

4 Sejtmagok detektálása Mirigy detektálása Értékelés GPGPU Kernelek összehasonlítása GPU CPU összehasonlítása G80 GT200 összehasonlítás Továbbfejlesztési lehetőségek GPGPU Ábrajegyzék Irodalomjegyzék Oldal 3

5 2 Bevezetés 2.1 Problémaleírás Napjainkban a szövetminták mikroszkopikus vizsgálata túlnyomórészt manuálisan történik. A kutatónak, vagy orvosnak a mikroszkóp fölé kell hajolnia, egy kényelmetlen testhelyzetben, szemével a mikroszkópban végtelenbe kell fókuszálnia, majd a jegyzeteire tekintve közelre, ez a szemnek és az agynak egyaránt megterhelő. Egy minta manuális kielemzése, akár több 10 percet is igénybe vehet, így egy teljes mintasor elemzése fárasztó, valamint sok időt és energiát emészt fel. Arról nem is beszélve, hogy az orvos is ember, így pár órás munka után, a fáradtsági faktor miatt megnő a valószínűsége, hogy a mintából hibás diagnózist állít fel. A probléma egy másik olvasata a gazdaságosság. A költségek csökkentése érdekében a kórházak, kutatóintézetek sok esetben csökkentik a laboratóriumok, ill. a kutatók, orvosok számát. Ez a módszer a költségeket látszólagosan csökkenti, mert a túlterheltség miatt megnő a hibaarány. Egy laboratóriumban sokféle mintát elemeznek, ezek vizsgálata különböző módszert igényel, mi a vastagbél daganatok diagnosztikájára koncentrálunk. Ezúton szeretnénk köszönetet nyilvánítani a SOTE Sejtanalitika Laborjának, és a 3DHistech Kft-nek, különösen Molnár Bélának, Ficsor Leventének, Valcz Gábornak, Szabó Dánielnek és Jónás Viktornak a dolgozat és a szoftver létrejöttében nyújtott segítségükért. 2.2 Célkitűzés A problémára megoldást nyújt egy szövettani immundiagnosztikai kiértékelő és speciálisan a vastagbél daganatok differenciáldiagnosztikáját, prognosztikáját támogató szoftver. A program feladata a HE (Haematoxylin and Eosin) festést kapott digitalizált minták számítógépes feldolgozása a 3DHistech Kft. által több év óta fejlesztett MIRAX szoftver termékcsaláddal együttműködve. A feldolgozás során a szoftver a morfológiai paraméterek alapján azonosítja az egyes szövetkomponenseket: felszíni hámot, mirigyeket, sejtmagokat. A szöveti képek feldolgozását követően diagnosztikai elemzés készül a szegmentált szövettípusokra a diagnosztikai paraméterek alapján, célzottan az ép, gyulladásos, hyperplasztikus és daganatos elváltozások azonosítására. Célunk: a szövetkomponensek felismerését és szegmentációját támogató algoritmusok implementálása, a szoftver használatát segítő grafikus felhasználói felület tervezése, az indikátorként alkalmazható paraméterek definiálása, és kvantitatív értékeik meghatározása, melyek segítségével a szoftver a későbbiekben döntéstámogatást biztosíthatna az orvos felhasználók számára, az egyes paraméterek mérését megvalósító algoritmusok implementálása, a mért paraméterek kiértékelését végző eljárások kidolgozása, Oldal 4

6 az ép, gyulladásos, daganatos szöveti struktúrák megkülönböztetésére. A szoftver képfeldolgozó algoritmusait, a gyorsabb futás érdekében, az nvidia által megalkotott CUDA technológiát felhasználva implementáljuk. Ez a technológia kiválóan alkalmas a számítás intenzív, jól párhuzamosítható feladatok, így a képfeldolgozás felgyorsítására. A CUDA-val kihasználható a számítógépekben lévő, eddig leginkább megjelenítésre használt GPU-k számítási kapacitása. Ezzel a program futása gyorsabb, és (a CPU tehermentesítése miatt) használata kényelmesebb lesz. A szoftver kevésbé időkritikus részeit és a grafikus felületet C#-ban, a.net keretrendszert felhasználva valósítjuk meg. Oldal 5

7 3 Biológia háttér 3.1 A vastagbél A vastagbél az emésztőrendszer utolsó szakasza, átmérője átlagosan 5-6 cm, hossza cm [14]. Bélrendszer feladatai a táplálék emésztése, felvétele, felszívása és az emészthetetlen salakanyag külvilágra juttatása. A vastagbélrák az egyik leggyakoribb daganatfajta, Magyarországon évente új megbetegedést diagnosztizálna, amivel a 2. leggyakoribb daganat a tüdőrák után. A vastagbél szöveti szerkezetét az alábbi ábra szemlélteti. 1. ábra Vastagbél szöveti szerkezete [18] Mivel a vastagbél daganat a nyálkahártyából mucosa fejlődik ki, ennek a felépítését részletesebben is megvizsgáljuk. 3.2 A vastagbél nyálkahártya A vastagbél nyálkahártyája az alábbi rétegekből épül fel [18]: hámsejt réteg propria réteg: a nyálkahártya kötőszöveti rétege [16] lamina muscolaris mucosae: nyálkahártya izomrétege Oldal 6

8 2. ábra Vastagbél nyálkahártyájának szerkezete [18] A hámréteg jellemzője, hogy a sejtek közötti távolság kicsi, szorosan egymás mellet helyezkednek el, megnyúlt hasáb alakúak, és sejtmagjaik egyvonalban vannak [5]. A nyálkahártyába betüremkedő képződmények mirigyek, melyek feladata, hogy nyák termelésével síkosítsák a vastagbél falát. A mirigyek alsó részén egy osztódó sejtréteg, a germinatív vagy generatív réteg található. 3. ábra Hámréteg, és egy mirigy ** Az egészséges nyálkahártya tulajdonságai [18]: a nyálkahártya felszíne sima Oldal 7

9 a mirigyek sűrűsége 6-8 db / mm a mirigyek mérete normális, a nyálkahártyáig érnek, irányultságuk párhuzamos, és nem ágaznak el csak a mirigy alsó részén található osztódó sejtréteg sejtjeik száma és felépítése normális a kötőszövetben és az izomrétegben nincs elváltozás 3.3 A vastagbél betegségei [5] Egy egészséges vastagbél nyálkahártya sejt daganatos elváltozását több ok is előidézheti. Az elváltozás hatására a sejt bizonyos tulajdonságai megváltoznak, így képes lesz magát kivonni a saját, és a környező sejtek növekedési kontrolja alól. Ezek a sejtek új populációt hoznak létre, és a túlnövik a környezetüket, ún. polip vagy hiperplázia jön létre. A hiperplázia azt jelenti, hogy a sejtek normálisnál ugyan gyorsabban szaporodnak, de felépítésük nem változik. Ha a folyamat itt nem áll meg, diszplázia alakul ki, amikor már a sejtek szerkezetében is változások történnek. Később ebből alakulhat ki a rák Gyulladásos betegségek A vastagbél gyulladásos betegségei a rák kialakulásának szempontjából fontosak, hosszabb ideig tartó gyulladás esetén megnő a rák kockázata. A gyulladás a hámsejtek szerkezetének megváltozásával jár, ami elősegíti a mutációt, és így áttételesen a rák kialakulását. A gyulladt nyálkahártya az alábbiakban különbözik az egészségestől: a nyálkahártya felszíne megváltozik a mirigyek sűrűsége csökken a mirigyek párhuzamos, egyenes lefutása megváltozik A nyálkahártya felületének simasága megszűnik, bizonyos helyeken kitüremkedések, máshol hámsejthiány, bemaródás alakul ki. A mirigyek sűrűsége az 7-8 db / mm-ről 4-5 db / mm-re csökken, a távolság közöttük megnő. Nemcsak a mirigyek helyzete, de a szerkezetük is drasztikusan megváltozik: a mirigyek párhuzamossága megszűnik, átmérőjük megváltozik (4. ábra), a mirigyek egyenes lefutása megszűnik, elágazások jönnek létre (5. ábra A mirigyekben elágazások jelennek meg), az izomréteg és a mirigy alapja közötti távolság megnő, és mirigyenként különbözik (6. ábra Az izomréteg és a mirigyek alapja közti távolság megnő, és mirigyenként különbözik). A gyulladás során a kötőszövetben propira réteg is elváltozások jelennek meg, a sejtek száma megnő, egészséges egyenletes eloszlásuk megváltozik. Ez minden vastagbél gyulladás esetén megjelenik, a fent felsorolt morfológiaváltozások nem feltétlenül! Oldal 8

10 4. ábra A mirigyek párhuzamossága megszűnik 5. ábra A mirigyekben elágazások jelennek meg Oldal 9

11 6. ábra Az izomréteg és a mirigyek alapja közti távolság megnő, és mirigyenként különbözik A diszplázia A diszplázia által okozott elváltozások túlnyomórészt megegyeznek a gyulladás által okozottakkal, de a diszplázia a gyulladástól függetlenül is kialakulhat. A diszpláziából közvetlenül is kialakulhat rákos daganat. A diszplázia az alábbi elváltozásokat okozza (a gyulladásnál már megismerteken kívül): a hámréteg sejtmagjai megnyúlnak, sűrűn helyezkednek el nincsenek egy vonalban, a sejtmagok megnagyobbodnak, alakjuk megváltozik, a sejtmagok jobban festődnek, a mirigyek generatív sejtrétege megvastagszik, és a sejt felsőbb részein is megjelenhet (7. ábra A generatív réteg a sejt felső részén is megjelenik). Oldal 10

12 7. ábra A generatív réteg a sejt felső részén is megjelenik Oldal 11

13 4 Informatikai háttér 4.1 Hasonló programok Mivel a feladat napjaink egyik megoldatlan problémája, így nehéz hasonló programokat találni. A HistoQuant nevű program célja részben megegyezik a mi feladatunkkal. Ez a program is tud sejtmagokat detektálni és ezek bizonyos jellemzőit is meg tudják mérni. A program azonban nincs ingyenes vagy próba verziója, így nem tudtam pontos információt szerezni milyen hatásfokkal képes detektálni. 4.2 Képfeldolgozó keretrendszerek Napjainkban már nagyon sok képfeldolgozással foglalkozó nyílt és zárt forráskódú keretrendszer elérhető. Ezek újraimplementálása fölösleges és nagyon időigényes. A feladat megoldásához felhasználjuk az OpenCv-t és az Intel IPP-t Intel IPP Integrated Performance Primitives az Intel egy többplatformos zárt forráskódú szoftverkönyvtár, amely kiemelten optimalizált funkciói fejlett alkalmazások kidolgozását teszik lehetővé. Az Intel Signal Processing Library (SPL), Image Processing Library (IPL), Intel JPEG Library (IJL) és az Intel Recognition Primitives Library (RPL) ezek funkcióit egybevonva született meg az IPP. Az IPP sok területhez ad fejlesztési eszközt. Ilyen területet a képfeldolgozás, gépilátás, hangfelismerés, adat tömörítés, kriptográfia, hangfeldolgozás, video kódolás stb. Mi azonban csak az első kettőt fogjuk használni. Az IPP kihasználja a legújabb processzorok nyújtotta technológiákat, mint a MMX, Streaming SIMD Extensions (SSE), Streaming SIMD Extensions 2 (SSE2), Streaming SIMD Extensions 3 (SSE3) technológia. Ajánlott az Intel architektúra használata, de a fent említetett technológiák nagy része megtalálható már az AMD processzorokban is OpenCv Az OpenCV (Open Source Computer Vision) egy nyílt forráskódú keretrendszer ben kezdte el fejleszteni az Intel C, C++ nyelvben és 2006-ban adták ki az első verziót. Az OpenCV több platformon fut Windows, Linux, Mac OS X. Az Intel IPP-vel szoros kapcsolatban áll. Az OpenCV önmagában is ki tudja használni a többprocesszoros gépeket, de amennyiben az IPP telepítve van a számítógépre, ki tudja használni az IPP további előnyeit is. Az OpenCV több fő részből áll. CXCore tartalmazza az alapvető struktúrákat és ezeken értelmezett alapvető műveleteket. CVCam tartalmazza a kamerával kapcsolatos függvényeket. HighGUI modul az grafikus felülethez az eszközöket. Machine Learning modulban találhatók meg a neurális hálók és hasonló főleg osztályozással foglalkozó függvények. CV modul pedig a képfeldolgozás, képelemzéssel mozgásdetektálással foglalkozó függvényeket gyűjti össze. Mi főleg a CV előnyeit fogjuk kihasználni. Oldal 12

14 4.3 Masszívan párhuzamos programozás alternatívái A masszívan párhuzamos architektúrák az asztali számítógépekben napjainkban olcsón elérhetőek. Három cég foglalkozik ilyen processzorok fejlesztésével: az nvidia, az Intel és az AMD. Ezen sorok írásakor azonban az Intel megoldása még nem elérhető, és kevés információ jelent meg róla. Az AMD és az nvidia is árul játékosoknak szánt videokártyák mellett professzionális felhasználásra szánt adatpárhuzamos gyorsítókat is, melyek jellemzője, hogy a központi egység teljesen ugyanaz, mint a játékosoknak szánt kártyákon, azonban általában több memóriával kaphatóak és nem található rajtuk video kimenet. A fejlesztőkörnyezeteket tekintve tágabb a választék, hiszen az egyes gyártók specifikus rendszerei mellett számos gyártófüggetlen megoldás is létezik. Az AMD megoldásai Az AMD első, asztali számítógépekben is elérhető, egységes árnyalókkal rendelkező architektúrája a 2007-ben piacra dobott R600-as volt. A cég a professzionális felhasználásra szánt kártyáknak a FireStrem nevet adta. Az R600-ra építve a következő években sorra jelentek meg a továbbfejlesztések: 2007-ben az RV670, 2008-ban pedig az RV770. [19] Az R600 mellé kiadott fejlesztőkörnyezet a Stanford Egyetemen kifejlesztett BrookGPU fordító és futtatókörnyezet egy (az AMD hardverekre optimalizált) változatát, a Brook+-t használja. A fejlesztőkörnyezet biztosít egy alacsonyabb szintű hozzáférést is a GPU erőforrásaihoz a CTM (Close To Metal) révén. [20] Az nvidia megoldásai [8] Az nvidia első kereskedelmi forgalomban kapható architektúrája mely programozható árnyalókkal rendelkezett, a 2006-ban bejelentett G80-as volt, és ezzel indult útnak a professzionális felhasználásra szánt Tesla termékvonal is. A következő lépés a 2008 elején forgalomba került G90-es volt, melyet a GT200 követett 2008 júniusában. A G80-nal egy időben jelent meg a hozzá tartozó fejlesztő környezet a CUDA (Compute Unified Device Architecture), melynek célja, hogy a hagyományos C nyelvet a lehető legkevesebb kiegészítéssel tegye használhatóvá az nvidia architektúrák programozására. Gyártófüggetlen megoldások A BrookGPU-t, ahogy már említettem, a Stanford Egyetemen fejlesztették ki, azzal a céllal, hogy hatékonyabbá és egyszerűbbé tegyék a GPU-ra történő fejlesztést. Ahogy a neve is mutatja, az ANSI C nyelv egy változatát, a Brook-ot használja, melyet kifejezetten adatpárhuzamos problémák egyszerűbb megközelítésére fejlesztettek ki. A fordító a Brook-ban írt kódot OpenGl, DirectX vagy az ATI féle CTM utasításokká fordítja, és azt futtatja az aktuálisan használt GPU-n. Tartalmaz emulátort is, mely a hibakeresést egyszerűsíti. Nagy előnye, hogy nyílt forráskódú, ingyenesen elérhető. [2] A RapidMind nem használ külön nyelvet, hanem a hagyományos C++ kódot elemezve próbálja a kódot párhuzamos architektúrákra optimalizálni. Képes kihasználni a sokmagos processzorokat, adatpárhuzamos gyorsítókat, sőt a Sony, Toshiba és az IBM által kifejlesztett Cell processzort is. Kutatási célokra ingyenesen elérhető. [4] A DirectCompute API-t a Microsoft fejleszti a DirectX11 részeként, mely ezen sorok írásakor még nem elérhető. Támogatni fogja a DirectX10 kompatibilis GPU-kat is. [10] Az OpenCL specifikációját 2008 végén hozta nyilvánosságra a Khronos Group. Céljai között szerepel, hogy hasonlóan a RapidMind-hoz, sokmagos processzorokra, GPU-kra és a Cell-re egy nyelvet és fejlesztőkörnyezetet használva lehessen hatékonyan fejleszteni. Az Oldal 13

15 OpenCL teljesen nyílt platform, bármelyik gyártó implementálhatja a saját architektúrájára, így az egész iparágnak jelenthet egységes megoldást. [17] Megemlítendő még a PeakStream, mely a RapidMind-hoz hasonló rendszert hozott létre [3]. Érdekességképpen megjegyezném, hogy sem a PeakStream, sem a RapidMind nem önálló, előbbit a Google vásárolta fel június 5.-én [1], utóbbit az Intel augusztus 19.-én [4]. Véleményem szerint az ideális választás az OpenCL lenne, hiszen teljesen ingyenes és független, a Khronos Group-on keresztül mégis szinte minden jelentős informatikai cég, kivétel a Microsoft, támogatja. Azonban ez egy nagyon új szabvány, a projekt indulásakor még csak a specifikáció volt elérhető, ezért más alternatíva után kellett néznem. Választásom végül a CUDA-ra esett, ennek legfontosabb okai, hogy teljesen ingyen elérhető és programozási modelljének alapjai megegyeznek az OpenCL specifikációjában leírtakkal, így később egyszerűbb lesz az átállás. Oldal 14

16 4.4 CUDA (Compute Unifed Device Architecture) [7] CUDA alapjai Az nvidia által fejlesztett CUDA egy fejlesztőkörnyezet, melynek segítségével kizárólag a cég saját architektúráit lehet programozni, a már elterjedt C nyelv kicsit módosított változatával. Egy CUDA kompatibilis GPU-nak több száz magja van, és ezek több ezer párhuzamos szálat képesek futtatni. A fejlesztés során az elsődleges szempont volt, hogy a C nyelvet a lehető legkevesebb módosítással alkalmassá tegyék a GPGPU-k programozására. Első verziója 2006 novemberében jelent meg, az első végleges, 1.0-ás verzió pedig 2007 júniusában került a fejlesztőkhöz. A programozás szempontjából a legfontosabb része a fordító. A fordítási folyamat kicsit különbözik a már megszokottól, hiszen a.cu kiterjesztésű forráskódot tartalmazó állomány két féle kódot is tartalmaz: a központi processzoron futtatandó ún. hoszt kódot, és a grafikai egységen végrehajtandó ún. eszköz (device) kódot. A fordító első lépésként szétválasztja a két féle kódot, és a CPU kódot átadja egy hagyományos C fordítónak, míg a GPU-n végrehajtandó kóddal maga foglalkozik. A fordítás során a forrás először egy köztes kódra fordul, ez a PTX, melynek szerepe hasonló a.net által használt MSIL-hez: elfedi a tényleges használt architektúrák közötti különbséget, és garantálja, hogy ugyanaz a kód az összes architektúrán futtatható lesz. Fontos megjegyezni, hogy bár a PTX-ről natív kódra történő fordítás során a fordító optimalizálja a kódot, az egyes architektúrák valamelyest más követelményeket támasztanak a hatékony kóddal szemben. Egy CUDA kompatibilis processzor alapegysége a feldolgozás szempontjából a Streaming Processor, a továbbiakban SP. Nyolc darab SP van egy Streaming Multiprocessor -ba szervezve, erre a későbbiekben mint multiprocesszor vagy MP fogok hivatkozni. A hardver részletes ismertetése ennek a dolgozatnak nem célja, ezért csak a programozás szempontjából lényeges fogalmakat és tulajdonságok magyarázatára térek ki. Minden multiprocesszor tartalmaz egy ún. SIMT egységet, melynek feladata a szálak létrehozása, ütemezése és futtatása. Ez az egység a szálakat ún. warp -okba csoportosítja, egy warp 32 szálat tartalmaz. Egy warp az aktuálisan a multiprocesszor által futtatott szálakat jelenti. Az egy MP egy SIMT egység felépítésből következik, hogy adott időpillanatban az SP-k, azonos utasítást tudnak csak végrehajtani, nincs minden SP-nek külön PC-je (Program Counter: a következő végrehajtandó utasításra mutat). Emiatt előfordulhat, hogy az amúgy párhuzamosan, függetlenül végrehajtható szálak között az elágazások miatt soros függőség alakul ki, ez lassítja a program futását Programozási modell Programozási modell vagy paradigma alatt egy módszertant értünk, mely alkalmazásával az egyes problémákat képesek vagyunk számítógéppel leírni, ill. megoldani. A C nyelv a strukturált programozási paradigmát valósítja meg, mely Neumann féle soros feldolgozásra épít. Ezzel szemben a CUDA a párhuzamos programozási modellt implementálja. A két paradigma jelentősen különbözik, de a C nyelv néhány kiegészítéssel alkalmassá tehető a párhuzamos programozásra. A CUDA a C nyelvet az alábbi elemekkel egészíti ki: függvény típusokkal, amikkel meghatározhatjuk, hogy egy függvény hol fusson, és honnan legyen hívható (CPU vagy GPU) Oldal 15

17 változó típusokkal, amikkel meghatározhatjuk egy változó helyét a GPU memóriájában a kernel hívási direktívájával négy beépített változóval, amikkel meghatározhatók a grid és a blokk dimenziói, valamint a blokkok és a szálak indexei. Ezzel elérhetjük, hogy a párhuzamosság csak a kernelek hívásakor jelenjen meg, a kernelhívások között, és a kerneleken belül is strukturált kódot írhatunk. A CUDA által alkalmazott párhuzamos programozási modell lényege, hogy egy szál a feldolgozni kívánt adatstruktúra egy vagy néhány elemét dolgozza fel, pl. egy kép esetében egy vagy néhány pixelt. A CUDA kódot futtatni képes GPU-k jellemzően több tucat, vagy akár több száz szálat képesek párhuzamosan futtatni. Az nvidia által használt terminológiában a hoszt a központi vezérlő egységet, míg a device továbbiakban eszköz a videokártyát vagy adatpárhuzamos gyorsítót jelenti. A kettő között a kapcsolatot a mai rendszerekben a PCI-Express 2.0 szabványú csatoló biztosítja, melynek elméleti sávszélessége 8 GB/s. A hoszt és az eszköz aszinkron működésű, egy kernelhívás után a vezérlés azonnal visszakerül a CPU-hoz, ezért nem blokkolja a program futását. 8. ábra Kernelhívás Kernelek és szálak A kernel egy olyan függvény, amit a CPU hív, de a GPU hajt végre, hívásakor meg kell adnunk, hogy hány párhuzamos szálon szeretnénk egyszerre futtatni. A kernelre az alábbi megszorítások érvényesek: csak a GPU memóriáját érheti el nem lehet visszatérési értéke (void) Oldal 16

18 nem lehet rekurzív a statikus változók használata nem megengedett A GPU szálak ún. könnyű szálak, létrehozásukhoz, és a szálak közti váltásokhoz szükséges idő jóval kevesebb, mint a CPU-n futatott szálak esetén, és kevésbé erőforrás igényesek. Egy kernel hívása az alábbi módon történik: kernelnnév<<<griddim, blockdim, memsize,>>>(paraméterek). A griddim-mel és a blockdim-mel a szálak hierarchiáját határozhatjuk meg, a memsize-zal pedig az osztott memória méretét; ez opcionális. A szálak hierarchiáját az alábbi ábra szemlélteti: 9. ábra Szálhierarchia [6] A szálakat ún. blokkokba rendezzük. Minden blokk ugyanannyi szálat tartalmaz, ezek számát és dimenzióit adjuk meg a blockdim-mel a kernel hívásakor. Egy blokkban a szálakat egy, kettő vagy három dimenzióba rendezhetjük, egy blokk a mai GPU-k esetén maximum 512 szálat tartalmazhat. Minden blokknak külön osztott memóriája van, így csak az azonos blokkban lévő szálak képesek ezen keresztül együttműködni. A kernelek egy gridben futnak, és egy GPU egy időben csak egy kernelt futtathat. Egy MP egy időben egy blokkot futtat, de tartozhat hozzá több blokk is, ilyenkor sorban futtatja őket. A blokkok és a blokkon belüli szálak száma kritikus a futási idő szempontjából, de számukat mindig az aktuálisan feldolgozni kívánt adat struktúrájához kell igazítani, és nem a hardverhez. A hardver osztja be, hogy melyik blokkot, melyik maghoz rendeli. 10. ábra Blokkok kiosztása a magokhoz különböző GPU-knál [6] Oldal 17

19 4.4.4 Memória hierarchia A CUDA-ban hat különböző memória területet különböztetünk meg, melyek elhelyezkedését és egymáshoz való kapcsolatukat az alábbi ábra szemlélteti. 11. ábra Az egyes memória fajták kapcsolata, elhelyezkedése [12] A szálak által leggyorsabban a végrehajtó egységekkel közös félvezetőlapkán található regiszterek, és osztott memória érhető el, ezek késleltetése mindössze néhány ciklus. A regiszterek használata triviális, minden kernelben definiált változó az aktuális szál privát használatú regisztereibe kerül. Az osztott memória már sokkal nehezebben megfogható, hiszen a központi processzora írt programok esetében ezzel a fogalommal nem találkozhatunk. Ha mégis analógiát szeretnénk keresni, akkor a működése és használhatósága miatt a CPU-ban található gyorsító tárakhoz hasonlíthatjuk, azzal a lényeges különbséggel, hogy a GPU-ban a használata nem automatikus, a programozó dolga, hogy kihasználja az előnyeit. Logikailag az osztott memória a blokkokhoz tartozik, fizikailag viszont multiprocesszoronként van egy. Hatékony kihasználásának módjára a későbbiekben még visszatérek. A többi négy memóriafajta közös tulajdonsága, hogy fizikailag a GPU-val egy NYÁK-ra szerelt DRAM-ban találhatóak, emiatt a késleltetés nagyjából százszor akkora, mint a regiszterek és az osztott memória esetében. Ne feledjük azonban, hogy a videokártyák által biztosított sávszélesség többszöröse a központi egységnél megszokottnak. Memória órajel Szélesség Sávszélesség nvidia GT200 [9] 1100 MHz 512 bit 141 GB / s Intel Nehalem [15] 1066 MHz 192 bit 25,6 GB /s 1. táblázat GPU - CPU sávszélesség A négy memória típus közül egyedül a lokális szálszintű, a többit az összes szál kezelheti. A lokális memória a regisztertér kiterjesztésének tekinthető, tipikusan akkor kerül alkalmazásra, amikor a kernelben egy tömböt definiálunk, amit aztán dinamikusan címzünk. Ennek oka az, hogy a szálakhoz tartozó privát regiszterek nem indexelhetőek. Oldal 18

20 Emiatt csak az olyan tömbök kerülhetnek közvetlenül a regiszterekbe, amelyek indexei már a fordítási időben eldönthetőek. A globális memóriát az összes szál írhatja és olvashatja, de gyorsító tár nem tartozik hozzá, emiatt a kezelésénél különösen ügyelni kell hatékonyságra. A konstans és a textúra memóriához ugyan tartozik egy gyorsító tár a GPU-ban, amin keresztül sokkal hatékonyabban elérhetők, de alkalmazhatóságukat behatárolja, hogy csak olvashatóak. Az utóbbi három memória típus kezelése allokálás, felszabadítás a hoszt kódon keresztül történik. Az egyes memóriák tulajdonságait az alábbi táblázat foglalja össze. Elhelyezkedés Gyorsító tár Elérhetőség Láthatóság Élettartam Regiszter integrált nem értelmezett olvasható / írható Lokális külső nincs olvasható / írható Osztott integrált nem értelmezett olvasható / írható Globális külső nincs olvasható / írható Konstans külső van csak olvasható Textúra külső van csak olvasható 1 szál szál 1 szál szál 1 blokk blokk összes szál + CPU összes szál + CPU összes szál + CPU lefoglalástól felszabadításig lefoglalástól felszabadításig lefoglalástól felszabadításig 2. táblázat Memória fajták összefoglalása [12] CUDA API A CUDA kétféle API-t biztosít a GPU programozására: a runtime, azaz futásidejű API-t, és a driver, azaz meghajtó API-t. A futásidejű API-t használva az eszköz kód egy állományba kerül a hoszt kóddal, míg a meghajtó API-t használva a kernelek egy külön fájlba kerülnek, majd a fordítás után ezeket be lehet tölteni a programba, és a paraméterek átadása után futtatni. Az utóbbit használva a kód jóval bonyolultabb lesz, de nagyobb programok esetén a használata elkerülhetetlen. Mindkettő működését és használatát a későbbiekben részletesen tárgyalom. Oldal 19

21 5 Probléma megoldásának megközelítése Képfeldolgozó algoritmusokkal szeretnénk kinyerni az információt. A szöveti minta hatékony detektálása és kielemzése napjaink egyik megoldatlan problémája. Mivel a teljese probléma megoldása több éves kutatást igényel érdemes a programot úgy tervezni, hogy az később kis munka befektetésével módosítható, továbbfejleszthető legyen. A teljes problémát megpróbáljuk kisebb feladatokra osztani melyek minimálisan kapcsolódnak egymáshoz. Minden egyes feladathoz megfeleltetünk a programban egy modult. Mivel a minták sok szempontból (méret, vágási sík, festődés erősége, festődés szín stb.) nagyon eltérőek lehetnek, minden algoritmust úgy kell fejleszteni, hogy minél több típusú mintát tudjon detektálni, valamint az egyes kulcsfontosságú problémák (sejtmagdetektálás, mirigydetektálás, hámdetektálás, egyes bonyolultabb paraméterek mérése) esetén több algoritmust implementálunk. Amennyiben egy mintán nem megfelelő eredményt produkál az alapérdemezett algoritmus lehetőség van egy másik a mintához jobban alkalmazkodó algoritmus használatára. A digitalizált szöveteket úgynevezett digitális slide-okon tároljuk, ezek képezik a programunk bementét. Problémát okozhat a program fejlesztése során, hogy ezek a digitális slide-ok igen nagyméretűek lehetnek. Ezt a problémát több síkon kezeljük. A digitális slide betöltése után lehetőséget adunk a felhasználónak hogy kijelölje azt a területet, ami fontos az vizsgálat szempontjából, így redukálódik a vizsgálat terület. Az összes algoritmust fel kell készíteni, hogy végrehajtás előtt megvizsgálja a bemeneti adat méretét és amennyiben az túl nagy, képes legyen azt felbontani kisebb, a végrehajtás szempontjából hatékonyabb méretűekre bontani és ezeket egymás után végre tudja hajtani. A digitális slide-ok nagy mérete nagy futási időt igényel. A probléma nagy adatpárhuzamosságot tartalmaz, így ha kihasználjuk az adatpárhuzamosságot GPU segítségével a futási időt az eredeti töredékére csökkenthetjük. Oldal 20

22 6 Program architektúrája A program architektúrájának megtervezéséhez tudni kell, hogyan végzik el ezt a feladatot az orvosok napjainkban. A minta elkészítése után az orvos behelyezi a mintát egy mikroszkópba. Minta festés során sérülhet, bizonyos esetekben ez lehetetlené teszi az minta pontos kiértékelését. Az első feladta ennek megállapítása. Meg kell vizsgálni a festődési szintjét. Amennyiben nem festődik kellőképpen áttetsző lesz a minta, ha túlságosan megfestődik az egész minta egyszínű lesz, így nem lehet elkülöníteni az egyes szöveti komponenseket. Amennyiben megfelelő a festődés szintje, meg kell vizsgálni a minta kimetszése során mennyire sérült a minta. Kisebb vágási hibák nagyon gyakran előfordulnak, így ezeket tudni kell kezelni későbbiekben a programnak is. A festődésen és a vágási hibákon kívül néha előfordulhat, hogy az igen vékony minta gyűrődik. A kisebb gyűrődést tartalmazó mintákat ki lehet értékelni, csupán a gyűrődési területet ki kell hagyni. Amennyiben az orvos meggyőződött arról, hogy megfelelő a minta megvizsgálja a szövetkomponenseket. Megvizsgálja a sejtmagok, mirigyek és a hám elhelyezkedését, mennyiségét, és alakjukat. Ezek az adatok orvos számára kellő adatot jelentenek, hogy meg tudja határozni a szövet állapotát. A program a hagyományos kiértékelési munkafolyamatra épül. A program első feladata a digitális minta betöltése. A programnak tudnia kell kezelni az alapvető kép kiterjesztéseket és a digitális slide-okat. Ezen feladatok elvégzésére valamint annak megvizsgálása, hogy a minta megfelelően ki lehet értékelni létrehozunk egy LOAD nevű modult. Megnyitás után a programnak meg kell vizsgálnia, hogy a minta megfelelően kiértékelhető, amennyiben lehetséges fel kell ismernie és meg kell találni az egyes szöveti komponenseket (sejtmag, mirigy, hám) a későbbi kiértékeléshez. A szöveti komponensek pontos detektálása egy nagyon bonyolult probléma így ez újabb önálló modult igényel (DETECTION). Feltéve hogy sikeresen detektáltuk a szöveti komponenseket meg kell határozni azok tulajdonságait. Ezt a feladatot az PARAMETER MEASUREMENT nevű modul fogja ellátni. Mint azt a hagyományos módszer tette, a kiszámolt paraméterek és ezekből készített statisztikai adatok alapján döntést kell hozni a minta állapotát illetően. A döntéshozó modul neve PARAMETER EVALUATION. 12. ábra Rendszerterv fejlődése I Oldal 21

23 Ahhoz, hogy ez egy használható program legyen, létre kell hozni a GUI-t és a kimenetet kezelő modult (SAVE). A modulok végrehajtása soros mivel minden modul támaszkodik az azt megelőző modul eredményeire, de bizonyos esetekben nem csupán azokra. A paraméter mérésre szükségünk lesz a bementi képre is, így a LOAD és a PARAMETER MEASUEMENT modulok között direkt kommunikáció van. 13. ábra Rendszerterv fejlődése II A program gyorsításához használni fogunk képfeldolgozó keretrendszereket, valamit Cuda nyelvben megírt GPU függvényeket. Mivel a program C#-nyelvben készül és a képfeldolgozó keretrendszerek és GPU kód nem C#-ban íródott ezért ezekhez szükségünk lesz wrapperekre. A program legvégső állapotában teljesen automatizált módon fog működni, ez lehetővé teszi, hogy nagy adatmennyiséget önállóan fel tudjon dolgozni. A nagy adatmennyiség maga után vonja, hogy a programnak tudnia kell kezelni adatbázisokat. Oldal 22

24 14. ábra Rendszerterv fejlődése III 6.1 Digitális metszet kezelés A célkitűzéseink között magas prioritással szerepelt, hogy a programunk képes legyen a 3DHistech Kft. által fejlesztett digitális metszet formátumot kezelni. Ezzel elérhetjük, hogy a felhasználó külön program használata nélkül, közvetlenül a metszeten jelölje ki azt a területet, amin aztán szeretné a vizsgálatot lefuttatni. A cégtől kaptunk egy függvénygyűjteményt, az ún. SlideAC-t, mely segítségével a digitális metszetek egyszerűen kezelhetőek. A digitális metszet működési elve a képpiramisra épül: a szkennelés során a digitális mikroszkóp végigpásztázza a metszetet, majd ez elkészült képekből, az átfedések kezelése után elkészül a képpiramis legalsó, azaz legnagyobb felbontású szintje. Oldal 23

25 15. ábra Képpiramis [13] Annak érdekében, hogy az alacsonyabb nagyításon ne kelljen túl nagy képeket kezelni, a legnagyobb felbontású kép fölé még további kilenc készül, és mindegyik szint fele akkora nagyításban készül el, mint alatta lévő. Az így elkészült képpiramis összesen 33%-kal foglal több helyet, mint ha csak a legnagyobb felbontású kép kerülne eltárolásra, de az alacsonyabb felbontású képek jelentősen gyorsítják mind a feldolgozást, mind a megjelenítést. 1. egyenlet A képpiramis által maximálisan felhasznált tárterület A képpiramis minden egyes szintje kisebb képekből áll össze, és mindegyik ilyen kis képelem 256 x 256 pixel méretű a nagyítástól függetlenül. A SlideAC nem enged képpont szintű hozzáférést a metszethez, hanem a kép pixel koordináta rendszere fölé definiál egy újat, amelynek alapegysége egy képelem. Ennek következménye, hogy a lekérdezett kép szélessége és magassága is 256 többszöröse lehet csak A digitális metszetek kezelése a gyakorlatban A digitális metszetek kezelését az alábbi szempontokat figyelembe véve terveztem meg: a navigálás a metszet legkisebb nagyítású képén történjen a használható nagyítási szintek egyezzenek meg a képpiramis szintjeivel a navigálás képelemenként történjen, és a megjelenített képen lehessen kijelölni azt a területet, amin később a feldolgozást szeretnénk lefuttatni a megjelenített kép mérete 512 x 512 pixel legyen a navigálás során a távlati képen jelenjen meg az aktuálisan mutatott kép befoglaló négyzete. Így a feladat két részre bontható. Egyrészt a navigáláskor kell az aktuális nagyításnak, és az egér mozgásának megfelelő képet megjeleníteni, másrészt a megjelenített képen a kijelölt területet a feldolgozáshoz szükséges nagyítási szinten lekérdezni. A SlideAC-hez Oldal 24

26 kapott dokumentáció alapján a digitális metszetről az alábbi függvény segítségével lehet képet lekérdezni: HRESULT GetImage([in] long x1, [in] long y1, [in] long x2, [in] long y2, [in] long Magnification, [in] long edchn, [in] long GreenChn, [in] long BlueChn, [in, out] IMrxBitmapImage* ppicture). A navigáció szempontjából a legfontosabb paraméterek az (x1, y1), (x2, y2) koordináták és a Magnification, azaz a nagyítási szint. Az (x1, y1) számokkal lehet megadni a lekérdezendő kép bal felső, míg az (x2, y2) számokkal a jobb alsó képelem koordinátáit. A nullás nagyítási szint felel meg az szkennelés során felvett képek nagyítási szintjének, a kilences pedig a piramis legfelső szintjét jelenti. 16. ábra Navigáció A távlati képen egy pixel megfelel a legnagyobb nagyításon 2 x 2 képelemnek. Így a befoglaló négyzet mérete az alábbi képlet segítségével számítható: 2. egyenlet Slide kezelés: befoglaló négyzet mérete A felső egyenletben az m a nagyítási szintet, az a a négyzet oldalainak hosszát jelöli pixelben. A következő lépésként a lekérdezendő kép bal felső képelemének koordinátáit kell kiszámolni, ezt az alábbi képlettel lehet megtenni: 3. egyenlet Bal felső képelem koordinátáinak számítása Az egyenletben (tx, ty) a képelem koordinátáit, (X, Y) az egér pozícióját, az m pedig a nagyítási szintet jelöli. Tehát már megvan a bal felső képelem koordinátája és Oldal 25

27 természetesen a nagyítási szint, azaz már csak a jobb alsó képelem hiányzik. Ennek értéke (tx + 1, ty + 1), mivel a feltételek között az szerepelt, hogy a megjelenítendő kép 512 x 512 pixel méretű legyen. A következő lépésként a megjelenített képen a felhasználó által kijelölt területet kell a SlideAC segítségével lekérdezni. 17. ábra Képrészlet kijelölése feldolgozásra Ehhez szükség van a megjelenített kép nagyítási szintjére, a bal felső képelemének koordinátáira, melyet az előző lépésben meghatároztunk, illetve az új nagyítási szintre valamint a kijelölt téglalap bal felső és jobb alsó sarokpontjának koordinátáira. Első lépésként meg kell határozni a megjelenített kép bal felső képelemének koordinátáit az új nagyítási szinten: 4. egyenlet Bal felső képelem koordinátáinak kiszámítása az új nagyítási szinten A fenti egyenletben a diff a régi és az új nagyítási szint különbségének abszolút értéke, a (bx, by) koordináták pedig a bal felső képelem koordinátái az új nagyítási szinten, a továbbiakban erre báziskoordinátákként hivatkozok. A következő lépésként a megjelenített kép koordináta rendszerében kell kiszámolni az új nagyítási szintnek megfelelő képelem szélességet. Például azonos nagyítási szinten ez az érték 256, hiszen a lekérdezett kép két képelemből épült fel, eggyel kisebb nagyítási szinten 128 és így tovább, általánosan: 5. egyenlet Képelem szélessége az új nagyítási szinten Az utolsó lépésként meg kell határozni azoknak a képelemeknek a koordinátái, melyek tartalmazzák a felrajzolt téglalap bal felső, és jobb alsó sarokpontjait, a következő módon: Oldal 26

28 6. egyenlet Befoglaló téglalap sarkainak koordinátái Az egyenletben (px, py) koordináták rendre a téglalapot meghatározó sarokpontok. Az így megkapott értékek azonban csak a bázishoz képest jelölik ki a lekérdezendő képet, ezért még el kell tolni őket a báziskoordinátákkal. 6.2 Cuda használata.net-ben Ahogy azt már leírtam a CUDA alapvetően a C nyelvet támogatja, a projekt fő nyelve viszont a C#, ezért valamilyen módon meg kell oldani, hogy a menedzselt.net kódból is meg lehessen hívni a GPU-ra írt függvényeket. Triviális megoldásként adódik, hogy a külön C-ben írt alkalmazásokban letesztelt kerneleket, a hoszt kóddal együtt egy közös gyűjteménybe pakoljuk, majd egy dll-t fordítsunk belőle, és ezt importáljuk a fő programba. A nem menedzselt kódban írt függvények hívása a menedzselt C#-ból ugyan megoldható, de tapasztalataim alapján bonyolult, nehézkes és a hibakeresés így sem a kernelekben, sem a hoszt kódban nem megoldható. Előnyösebb a GASS CUDA.Net keretrendszer használata, mely a meghajtó API-t valósítja meg.net alatt, így legalább a hoszt kód C#-ba kerül, ami leegyszerűsíti a hibakeresést. Továbbra is szükség van egy külön fájlra, de ez már csak a kerneleket tartalmazza, vagy a köztes PTX nyelvre fordítva, vagy bináris formában. A PTX azért előnyösebb, mert így garantált, hogy bármelyik architektúrán lefut a kód. A CUDA.Net használata ugyan jóval egyszerűbb mint ha a C-ben írt dll függvényeit használnánk, de még így is több lépcsőfokot kell végigjárni. Először is meg kell írni, és le kell tesztelni magát a kernelt, mivel a kernelben hibát keresni csak a futásidejű API-t használva lehet, ezért célszerű minden kernelhez egy külön kis alkalmazást írni. Ha a kernel készen van, akkor át kell másolni egy külön állományba, amit aztán a megfelelően felparaméterezett CUDA fordítóval le kell fordítani. Az eredmény egy csak PTX, vagy GPU bináris kódot tartalmazó fájl, amit aztán már fel lehet használni a meghajtó API segítségével a.net-ben. Ezt a folyamatot a későbbiekben még részteltesen tárgyalom. Oldal 27

29 18. ábra CUDA használata.net-ben Oldal 28

30 7 Sejtmagdetektálás 7.1 A probléma ismertetése Első lépésként meg kell ismerni magát a sejtmagot. A sejtmagok területe egy ép vastagbélszövetről készült mintán átlagosan um 2, alakjuk rendkívül változatos lehet, de általánosságban elmondhatjuk, hogy lekerekített, alig szegmentált. Számunkra fontosabb tulajdonság, hogy a sejtmagok a minta festése során jobban festődnek, mint a környezetük, sötétebbek lesznek. 19. ábra Sejtmagok Célunk, hogy a binarizálás során, egy olyan maszkot készítsünk, ami lefedi a sejtmagok teljes területét. Ezt megkönnyíti, ha szokásos RGB szintér helyett a képet HSV modellbe konvertáljuk. 7.2 Konvertálás HSV modellbe [23] A HSV az RGB színtér gyakori reprezentációja, amely sokkal precízebben írja le a színkapcsolatokat, mit az RGB. A HSV és az RGB egyaránt három dimenzióval rendelkeznek, de egészen eltérő módon határoznak meg egy-egy színt. Oldal 29

31 20. ábra Az RGB modell ábrázolása [22] Az RGB rendszert a három alapszín illetve ezek angol megfelelői alkotják (Red, Green, Blue). Ezen három színből bármilyen szín kikeverhető. A három dimenzió - x, y, z tengelyek - mindegyikéhez hozzárendelve a három alapszín egyikét megkapjuk az RGB színteret, melyben az origó megfelel a szín (fény) hiánynak, az x, y, z koordinátája pedig az adott szín piros zöld, kék összetevőinek. Az RGB modell mondható a legelterjedtebb színábrázolási módszernek az informatikában. HSV a színeket egy cilinderen értelmezi. RGB térnek megfelelően itt is minden egyes szín egy pontot jelöl meg a cilinder terében. A szín árnyalata meghatározza a cilinder körlapján a szöget, a telítettség a centrális ponttól való távolságot, a világosság pedig a cilinderen belüli magasságot határozza meg. 21. ábra HSV modell két ábrázolása [22] Mivel a HSV egy egyszerű transzformációja az RGB színkódolási rendszernek, ezért létezik egy egyértelmű leképzés a két rendszer között. Oldal 30

32 Kihasználva ezt az egyértelmű leképzést felépíthetünk egy LUT (Look Up Table) t, mely nagymértékben gyorsítani fogja az átkódolást. HSV rendszer alkalmazása nagymértékben megkönnyíti azon paraméterek meghatározását, amelyekkel maszkolhatjuk a sejtmagokat, hiszen mint azt a mintán láthatjuk, a sejtmagok főként lilás színnel rendelkeznek, színtelítettségük viszonylag magas, világosságuk alacsonyabb a környezeténél. 7.3 Az algoritmus Sajnos a képek, amiken az egyes sejtmagokat, ill. később a mirigyeket, hámréteget, detektálni szeretnénk, zajosak. A mi esetünkben a zajok forrása elég sokrétű lehet, zaj keletkezik az egyes minták szkennelése folyamán, és a jpg tömörítés során is. Szkennelés során előfordulhat, hogy a lencse vagy a tárgylemez szennyeződéseket tartalmaz, sőt, az egyes mikroszkópok fénytörési tulajdonságai is eltérhetnek. Ez utóbbi nem pontszerű, pixel szintű zajokat eredményez, hanem az egész minta színtelítettségét eltolja. Ez a későbbiek folyamán nehezíteni fogja a binarizálásnál egy általános küszöb érték meghatározását. A zajok miatt az első lépésként egy zajszűrést kell elvégeznünk. Zajszűrés esetén fennállhat annak a veszélye, hogy képen számunkra hasznos információkat is elmosunk. A mi esetünkben azonban ilyen káros mellékhatásról nem beszélhetünk, hiszen célunk nem egy éles határra rendelkező objektum éleinek detektálása, hanem egy maszk készítése. A zajszűréssel elérhetjük, hogy ez a maszk kevésbé lesz szegmentált, és reményeink szerint jobban lefedi a valódi sejtmagokat. A zajszűrés után következhet magának a maszknak az elkészítése. A maszk alatt az alábbi tulajdonságokkal rendelkező képet értjük: mérete ugyanakkora, mint az eredeti kép mérete, ahol az eredeti képen sejtmagot valószínűsítünk, fehér színű, egyéb helyeken fekete. Ahhoz, hogy a képet a szegmentálni tudjuk, meg kell határozni a fentebb ismertetett HSV modell egyes csatornáinak küszöbértékeit. Ha a küszöbértékek megvannak, már el tudjuk készíteni a maszkot. Zajszűrés ellenére az elkészített maszk nem független a zajtól ezért végső lépéként a maszkot is kezelnünk kell. A maszk utólagos kezelésére a legjobb módszer az Open. Ezzel a lépéssel szétválaszthatjuk az esetlegesen összetapadt sejtmagokat és eltüntethetjük a maszkon található kisebb zajokat is. 7.4 Ultimate Erode Gyakran előfordul, hogy a sejtmagok egymáshoz közel helyezkednek el. Ilyen helyek például a mirigy fala valamint a hámréteg. Ezeken a helyeken a sejtmagok szorosan egymás mellett helyezkednek el. Oldal 31

33 22. ábra Összetapadt sejtmagok Ilyen esetben ezek több sejtmag maszkja összeérhet. Ezeket külön kell választani a pontos detektáláshoz. 23. ábra Összetapadt sejtmagok binarizálása Fentebb már említettem, hogy az összeragadt sejtmagokat Open algoritmussal kezeljük. Azonban a fenti képen jól látható, hogy egyetlen Open algoritmus nem nyújt megoldást a problémára. Ezt a feladatot az Ultimate Erode nevű algoritmust fejlesztettem ki. Az algoritmus a binárizált képet vár bemenetként. Jelen esetben feketével jelöltem a két sejtmag összetapadt maszkját (24. ábra/a). Oldal 32

34 24. ábra Ultimate Erode Az algoritmus megvizsgálja és feljegyzik a maszk külső pixeleit. Azt a pixelt nevezzük külső pixelnek, amelynek legalább egy nem a maszkhoz tartozó pixellel szomszédos nyolcas szomszédságot alkalmazása esetén.(24. ábra/b) Ez a lépés megegyezik egy Eróziós lépéssel [24], azzal a kivétellel, hogy jelen esetben el kell tárolni a külső pixeleket. A külső pixeleket eltávolítjuk a maszkon, majd újra végrehajtjuk az előző lépést mindaddig, amíg a maszk teljesen feldolgozásra kerül. Amennyiben több sejtmag maszkja összeér. A csatlakozási szakasz valamennyivel keskenyebb lesz, mint maga a sejtmag átmérője. Ezt használja ki az algoritmus. Mint az a képen is látszik a folytonos méret csökkentés során a maszk egy idő után kettészakad. Így amennyiben tovább folytatjuk az összetapadt sejtmagmaszkok centrumát kapjuk meg. Mivel a minta csupán egy igen vékony metszet az eredeti szövetből a sejtmagok területe igen eltérő lehet. Attól függ, hogy a gömbszerű sejtmagot épp hol metszették el. Ennek tudatában nem elegendő csupán a legutolsó pillanatban megnézni a megmaradt centrumokat, hiszen így a kisebb sejtmagok maszkjai már eltűntek. Az eredményen maximumkeresést kell végezni. A fenti képen két maximum gócot fogunk találni. Ezek a gócok megfelelnek egy-egy sejtmag centrumának. A baloldalon elhelyezkedő maximumgóc egy darab pixelből áll így a centrumpont megegyezik ennek koordinátájával. A jobboldalon elhelyezkedő maximumgóc 3 pixelből áll ebben az esetben a centrumpontot ezek koordinátáinak átlagolásával határozzuk meg. A minta bonyolultsága miatt a binarizálása során előfordul, hogy olyan részeket is lefed a maszk, amik nem sejtmagot jelölnek. Az algoritmus végén ezért végigjárjuk a centrumpontokat és megvizsgáljuk, hogy azok hányadik ciklusban kerültek végleges feldolgozásra. A ciklusszámból következni lehet az eredeti maszk méretére. Amennyiben a ciklusszám nagy nem lehet egyetlen sejtmag, vagy több összetapadt sejtmag vagy valamilyen binarizálási hiba. Minkét esetben ezeket a programnak fel kell ismernie és közölnie kell a felhasználóval. Amennyiben a ciklusszám túl kicsi nem jelölhet sejtmagot így ezeket el kell dobni. Oldal 33

35 7.5 Sejtmagok paramétereinek mérése A sejtmagokat lefedő maszk elkészült, a következő feladatunk, hogy ezt felhasználva a sejtmaghoz tartozó paramétereket meghatározzuk. A meghatározandó paraméterek közé tarozik a terület, kerület, ill. a sejt morfológiai jellemzői Kitöltő algoritmus A kitöltő algoritmust használjuk a sejtmag terültének megmérésére, valamint a sejteket befoglaló téglalap meghatározására. Az algoritmus működése egyszerű. Megvizsgáljuk az adott pontot, és ha az egy megadott színtartományba esik akkor átfestjük, valamint minden még nem átfestett szomszédjára végrehajtjuk ezen lépéseket. Forráskódba könnyen átírható rekurzió használatával azonban nem a legszerencsésebb megoldás mivel a rekurziós módon megírt algoritmusok nagy mennyiségű adatok esetén sokkal lassabb futási időt eredményeznek, mint az iteratív megvalósítás és sok esetben veremtúlcsordulást is okozhatnak. Az iteratív megvalósításhoz két tárolóra van szükség. Az első a vizsgálatra várakozó elemeket, a második a már megvizsgált elemeket tartalmazza. A gyors futás érdekében ezen tárolóknak a következő funkciókat kell megvalósítaniuk: o gyors elemhozzáadás o gyors elem eltávolítás o gyors tartalmazás lekérdezés. Célunk egy ponthalmaz beazonosítása, amelyhez első megközelítésben FIFO (First In First Out) puffert alkalmaznánk az első halmaz esetén, de jobban átgondolva a problémát rájöhetünk, hogy a beazonosítás sorrendje nem hordoz számunkra hasznos információt. Egyszerűség kedvéért nevezzük el az elsőt in, a másodikat out tárolónak. 25. ábra A kitöltő algoritmus működési elve Kezdetben az in tároló csak a kiindulási pontot tartalmazza, az out tároló üres. Az algoritmus első lépésben vesz az in-ből egy elemet. Megvizsgálja, hogy annak a pontnak a színe az adott tartományon belűre esik. Amennyiben teljesült a feltétel, a szomszédos pontok közül azokat, amelyek sem az in, sem az out tárolóban nem szerepelnek betesszük az in halmazba. Utolsó lépésben a megvizsgált elemet minden esetben áthelyezzük az out halmazba, itt végezzük a paraméterek mérését. A területmérést úgy végezzük, hogy megszámoljuk az áthelyezett pixeleket, befoglaló téglalaphoz eltároljuk a legkisebb és Oldal 34

36 legnagyobb x és y koordinátákat, és meghatározzuk a súlypontot. Az algoritmus addig fut ameddig az in halmaz üressé nem válik. 26. ábra A nyolcas és négyes szomszédság Szomszédos pontoknak tekinthetjük a nyolcas vagy a négyes szomszédságot. Négyes szomszédság használata ajánlott, hiszen ez is teljesen bejárja a kétdimenziós teret és maximálisan 4 szer vizsgál meg minden egyes pontot ellenben a nyolcas szomszédság használata esetén Körvonal detektáló Szeretnénk a sejtmagok kerületét is megmérni. Erre a legjobb módszer, ha egyszerűen körbejárjuk a maszkon a sejtet határoló pixeleket és megszámoljuk őket. Ehhez egy körvonal detektáló algoritmust használunk. Az algoritmus kiinduló pontja a megmérendő objektum bal felső pontja, azaz a legkisebb y koordinátájú sor legkisebb x koordinátájú oszlopában lévő pixel. A körbejárás iránya megegyezik az óramutató járásának irányával. Első lépésként definiálunk egy 3x3-as maszkot, melynek a középpontja az aktuális pont, továbbá a maszkon egy kitüntetett pontot, a forráspontot. A forráspont jelöli azt a pontot ahonnan érkeztünk, azaz az algoritmus előző iterációjában megtalált határpixelt. 27. ábra A körvonal detektáló maszk ** Az első lépésben forráspontunk még nincs, az algoritmus az első lehetséges következő kontúrpontból indul, azaz az első vizsgált pont az (1, 0) lesz. Azért ez az első lehetséges pont, mert a kezdőpont meghatározásánál kizártuk, hogy a kezdőpont fölött, ill. tőle balra objektum pontja helyezkedjen el. Az algoritmus lényege, hogy a forráspontból kiindulva az aktuális vizsgálandó pixelről eldönti, hogy az objektumhoz tartozik-e vagy nem. Ha igen, akkor feljegyzi a talált pontot, és a következő iteráció középpontja az aktuálisan megtalált pont lesz, forráspontja pedig az aktuális középpont. Ha nem, akkor folytatja a vizsgálatot a Oldal 35