Fegyvári András:
Videó-EEG felvevő és lejátszórendszer tervezése elektrofiziológiai vizsgálatokra
PPKE ITK műszaki informatikus szak konzulens: Ulbert István 2010
1
BEJELENTŐ LAP HELYE
2
BEJELENTŐ LAP HELYE
3
Nyilatkozat:
Alulírott Fegyvári András, a Pázmány Péter Katolikus Egyetem Információs Technológiai Karának hallgatója kijelentem, hogy ezt a diplomatervet meg nem engedett segítség nélkül, saját magam készítettem, és a diplomamunkában csak a megadott forrásokat használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen a forrás megadásával megjelöltem. Ezt a Diplomamunkát más szakon még nem nyújtottam be.
…............................................... Fegyvári András
4
1. TARTALOMJEGYZÉK 1.Tartalomjegyzék.......................................................................................5. 2.Tartalmi összefoglaló...............................................................................7. 3.Abstract....................................................................................................9. 4.Bevezető...................................................................................................11. 5.A feladat ismertetése, célkitűzés..............................................................12. 6.Előzmények 6.1 A sokcsatornás extracelluláris elvezetés mint elektrofiziológiai eszköz..........................................................13. 6.1.1 A kísérlet bemutatása............................................................13. 6.1.2 Elektródok.............................................................................15. 6.1.3 Beültetés................................................................................17. 6.1.4 Elektronikai részegységek, szoftverek...................................19. 7.Tervezés részletes leírása 7.1 A Video-EEG Lejátszó...................................................................21. 7.1.1 Célja......................................................................................21. 7.1.2 Kritériumok...........................................................................21. 7.1.3 A felhasználói felület bemutatása.........................................22. 7.1.4 Funkciók és használatuk.......................................................23. 7.1.5 A program felépítése.............................................................24. 7.1.5.1 A cnt bináris fájlok olvasása........................................25. 7.1.5.2 A GUI szerkezete, ActiveX, Media Player...................25. 7.1.5.3 global paraméterek......................................................27. 7.1.5.4 A főciklus működése.....................................................28. 7.1.5.5 Data cursor..................................................................29. 7.1.5.6 Eseménykezelés............................................................30. 7.1.6 Felmerült problémák és megoldásuk....................................31. 7.1.7 Hardver és szoftverkövetelmények........................................33. 7.1.8 Értékelés, további fejlesztési lehetőségek.............................34. 7.2 A Video-EEG Felvevő....................................................................36. 7.2.1 Célja......................................................................................36. 7.2.2 Kritériumok...........................................................................36. 5
7.2.3 Hardver.................................................................................37. 7.2.3.1 Feltárt megoldási lehetőségek és elemzésük................37. 7.2.3.2 Komponensek leírása...................................................39. 7.2.3.2.1 A frame grabber..................................................39. 7.2.3.2.2 A kamera.............................................................40. 7.2.3.3 Hardver installáció......................................................41. 7.2.4 Szoftver.................................................................................42. 7.2.4.1 Funkciók és használatuk, a GUI bemutatása..............42. 7.2.4.2 A program felépítése....................................................43. 7.2.4.3 Felvetődött problémák és megoldásuk.........................48. 7.2.5 Hardver és szoftverkövetelmények........................................49. 7.2.6 Értékelés, további fejlesztési lehetőségek.............................49. 7.3 Rendszer demonstráció, alvásvizsgálat 7.3.1 Bevezető................................................................................51. 7.3.2 A 224-es macska...................................................................52. 7.3.3 példák a mérésből.................................................................54. 8.Összefoglalás...........................................................................................56. 9.Köszönetnyilvánítás.................................................................................57. 10.Irodalomjegyzék.....................................................................................58. 11.Mellékletek.............................................................................................59.
6
2. TARTALMI ÖSSZEFOGLALÓ Szakdolgozatom témája egy az extracelluláris elvezetéseket továbbfejlesztő, videó és EEG jeleket szinkron mód felvevő/lejátszó rendszer kidolgozása. Munkámat egyetemünk Elektrofiziológiai Laborjában, ill. az MTA Pszichológiai Kutatóintézetében végeztem. Bár a fejlesztések sokszor párhuzamos zajlottak és nehezen szétválaszthatóak, munkámat mégis három részre osztanám: (1) A sokcsatornás extracelluláris elvezetés technikájának megismerése (2) Felvevőrendszer fejlesztése (3) Lejátszórendszer fejlesztése Az extracelluláris elvezetés az elektrofiziológia egyik legelterjedtebb kutatási a technikája. Célja, hogy az idegsejtek által generált elektromos jeleket elvezessük és rögzítsük. Ez mondhatni az EEG egy invazív formája, mivel itt a skalp felszíne helyett közvetlenül az idegszövetbe helyezzük el az elektródokat. Az elektródok műtét során kerülnek az agyba, és krónikus esetben bent is maradnak a kísérleti alany agyában (a dolgozatba patkány és macska példák kerültek). A felvett adatokból következtetéseket szeretnénk levonni, az agyi elektromos jelek élettani, pszichikai és viselkedéses kapcsolatait, korrelációit szeretnénk feltárni, ezért magától értetődően hasznos lenne, ha a kísérletről videofelvétel is készülne. Az elektromos jelek a videóval kiegészülve új lehetőségeket nyitnak, teljesen újfajta kísérletek végrehajtását teszik lehetővé. Ez a fejlesztés volt a feladatom a félévek során. Az új felvevőrendszer LabView környezetben készült és együttesen kellett szoftver ill. hardverfejlesztéssel foglalkoznom. A legfontosabb kritérium a videó és EEG jel felvétel szinkronitásának betartása volt. A két felvételnek ugyanabban az időpontban kell kezdődnie és folyamatosan azonos sebességgel kell futnia. Ebből fakadóan az elkészült videó és EEG jel hosszának egyeznie kell. Ha ezek nem teljesülnek, hibás adatokkal dolgoznánk tovább. A tervezés a hardver kiválasztásával kezdődött. Előzetesen több kamerarendszert is összehasonlítottunk, míg végül a szigorú szinkronitási kritériumokat figyelembe véve a CameraLink szabvány mellett döntöttünk. Az agyi elektromos jelek a korábban megszokott NeuroScan .cnt fájlformátumban kerülnek rögzítésre a LabView Data Acquisition (DAQ) szoftvercsomagjával, míg a videofelvételek DivX-es tömörítéssel .avi fájlokban az Image Aquisition (IMAQ) csomag felhasználásával. A felvevő a felhasználó által megadott .cnt fájlnévvel egyező .avi fájlt készít. A lejátszórendszer MatLab keretrendszerben készült, és itt is a legfontosabb elvárás a garantált szinkronitás volt. Az elvezetett elektrofiziológiai jelek aktuális pozíciójának egyeznie kellett a videó aktuális időpontjával. A videó megjelenítésére egy ActiveX control-t használok, mely a MatLab által megjelenített
7
grafikus felhasználói felületbe épül be. A lejátszó használata olyan, mint bármely más médialejátszóé. Elég csak a .cnt fájlt megnyitni, és a videó automatikusan megnyílik hozzá. Az időzítést a videólejátszó szolgáltatja. Lejátszás közben egy főciklus folyamatosan lekérdezi a videó aktuális időpontját és aszerint olvassa ki a fájlból, illetve jeleníti meg az agyi elektromos jeleket. A szinkronitás így biztosított. Fejlesztése során a legtöbb problémát a nagymennyiségű adat kezelése és megjelenítése volt, melyre több megoldást próbáltam ki. A szoftver kezdeti verziója animáltan jelenítette meg az elektromos jeleket, azonban a nagy hardverigény miatt a végleges verzióban egy mozgó kurzor ('slider') szimbolizálja az aktuális időpontot. A lejátszó egy adott hosszúságú ablakban jeleníti meg a jeleket és lejátszás közben két 'slider' szimbolizálja az aktuális időpontot. Az egyik az ablakon lévő időt, míg a másik a teljes időtartamra vonatkozó időt jeleníti meg. Amikor az aktuális időpont eléri az ablak végét, az ablak ellapozódik és a 'slider' is az intervallum elejére ugrik. A program képes ún. esemény (event, .ev2) fájlok készítésére is. Az esemény fájlok egyszerű text fájlok melyekben adott időpontokhoz tartozó eseményeket tárolhatunk egy megadott szabvány szerint. Ehhez egy külön kis kezelőfelület áll rendelkezésre, melynél minden gomb egy eseményt reprezentál. Lejátszás közben ezekre kattintva menthetjük el eseményeket, majd a save gombbal elmenthetjük őket .ev2 formátumba, melyeket más szoftverekhez használhatunk fel. A felvevőrendszer felhasználói felülete LabView környezetben. Bal oldalon a kísérlet élőképe látható mely rögzítésre kerül, jobb oldalon pedig az elvezetett agyi bioelektromos jelek melyek cnt fájlformátumban mentődnek el A lejátszórendszer felhasználói felülete MatLab környezetben. Bal oldalon az elektromos jelek láthatóak, alatta pedig az időt reprezentáló kurzorok. A jobb oldali kis ablakban a videó, alatta pedig a lejátszó kezelőfelülete található.
8
3. ABSTRACT The aim of my thesis is to develop a synchronous EEG-video recorder and player system to improve the multichannel extracellular recording method. I performed my project at the Electrophysiology Lab of the Péter Pázmány Catholic University and at the Institute for Psychology of Hungarian Academy of Science. Although my work can not be easily divide, and the developing went parallel, I try to split it into three parts. (1) Examine and learn the multichannel extracellular recording methods (2) Develop the recording system (3) Develop the player system The extracellular recording is one of the most important methods of electrophysiology. Its goal is to record the bioelectric signals generated by neuronal cells. It is an invasive form of EEG, because instead of placing the electrode on the scalp, we place them inside the brain, directly into the tissue. In chronic case we leave the electrodes it in the brain of the experimental subject (the thesis contains rat and cat results). We want to draw conclusions from the recorded data, and try to understand and expose the correlations between the electric signals and the anatomical, physiological, psychological and behavioral properties. That's why, it is extremely useful to make videos from the experiments. The supplementary videos together with the simultaneously recorded electric signals generate new possibilities and we are able to create new kind of experiments. This development was my task during the semesters. The new recording system was created in LabView environment and I had to do software and hardware development in parallel. The main criterion was the synchrony between the video and electrophysiology signals. The two recording modalities have to start at the same time, and have to be recorded with same speed. On this score, the video and EEG recordings must have equal length. If these criteria are not fulfilled, we are going to work with faulty data, even if the player is works well. The design process was started with choose of the hardware. Previously we compared diverse camera systems, and finally (considering the synchrony criteria) we chose the CameraLink standard. The neuronal electric signals are still recorded in the usual Neuroscan .cnt file format with the LabView Data Acquisition software (DAQ), and the videos in .avi format encoded with DivX codec with the help of LabView Image Acquisition software (IMAQ). The recorder creates the .avi file with the same name as the .cnt file given by the user. The player system was created in MatLab developer environment. The main criterion was still the synchrony between electrophysiology and video data. The recorded signal's current
9
position has to be exactly the same with the video's current frame. To display the video, I use an ActiveX control, which was embedded in the MatLab generated graphical user interface. The usage of the player is very similar to many classical media players. It is capable to open the .cnt file, and the video will open automatically. The timing is guaranteed by the embedded media player. During the play a loop is running, and continuously read the timestamp from the video. After, it reads the .cnt file following the time data and display the content of the .cnt file (the actual interval). That is how the synchrony is guaranteed. During the development the biggest challenge was to handle (read and display) the huge amount of data, which I implemented via several methods. The early versions of the player worked with animated visualization of the electric signals, but because of the high hardware demand, in the final version I have to use animated cursors which represent the current position in the recording. The window has two sliders (cursor). One is representing the current position on the plotting window, and the second is representing the time in the full time range. When the actual time reaches the end of the window, it turns it to the next interval and the cursor goes back tot the start position. The player software is able to create event files (.ev2 extension). Event files are simple text files, which contain time positions and types of an event. For this function a small user interface is available, where every button stands for a special kind of event. On playing, pressing a button cause an event position to be saved into the .ev2 file. With the 'save' button, we can save all of the events in the standard .ev2 file format, and we can use them in other softwares. The graphical user interface of the Recorder System in LabView environment. The recorded live video signal shown on the left and the recorded bioelectric signals on the right window
The graphical user interface of the Player System in MatLab environment. The bioelectric signals shown on the left window and under are the position represent sliders. On the right is the video window under with the user controls.
10
4. BEVEZETŐ
A szakdolgozathoz egy több féléven át tartó munka vezetett, és összefoglalja a félévek során szerzett tudást, tevékenységeket. A szemeszterek során egyetemünk Elektrofiziológiai Laborjában, illetve az MTA Pszichológia Kutatóintézetében dolgoztam. Feladatom az elektrofiziológiai eljárások, szűkebben a sokcsatornás extracelluláris elvezetés technikájának megismerése és egy ezen kísérleteket támogató, ill. kiegészítő rendszer fejlesztése volt. A szakirány választás óta lehetőségem volt megismerni a laboratórium felszereléseit, a különböző elektrofiziológiai eljárásokat, az állatkísérleteket és a kísérletekhez szükséges műtéteket. Témám eredeti címe az „Agykérgi kiváltott potenciál és az elektromos háttértevékenység kapcsolatának vizsgálata” volt. Ez egy tágabb, globálisabb cím volt és leginkább az extracelluláris elvezetés technikáját és felhasználását takarta. Jelentkezésem után konzulensemtől végül azt a feladatot kaptam, hogy készítsek el egy szinkron videó-EEG felvevő és lejátszórendszert. Erre a rendszerre már rég óta szüksége volt a labornak, így remélem munkám sok segítség nyújt majd. Szakdolgozatomat három fő részre bontanám: 1. Az extracelluláris elvezetési technika ismertetése 2. A lejátszórendszer fejlesztése 3. A felvevőrendszer fejlesztése 4. A rendszer használhatóságának rövid demonstrálása A szakdolgozatban a logikus sorrend a felvevő majd a lejátszórendszer tárgyalása lenne, de mivel kronológiailag a lejátszórendszer fejlesztése történt meg előbb, ezért inkább itt is ezt a sorrendet követem.
Pázmány Péter Katolikus Egyetem Elektrofiziológiai Labor
11
5. A FELADAT ISMERTETÉSE, CÉLKITŰZÉS Mint említettem fő feladatom egy Videó-EEG felvevő és lejátszórendszer fejlesztése volt. Irodalomkutatásról elég nehéz beszámolni hiszen egy olyan rendszert kellett létrehoznom amihez nem igazán sikerült hasonló megvalósításokat találnom. Ha egy ilyen felvevő-lejátszó rendszert készít valaki, akkor általában saját célra (labor számára) teszi. Mivel minden labornak így a miénknek is egyéni elvárásai voltak, ezért egy akár létező megoldást is csak nehezen lehetett volna felhasználni. A laborban régóta zajlanak extracelluláris és egyéb elvezetések. Munkámmal ezt a technikát fejlesztettem tovább egy új képességgel rendelkező formába, mely később láthatóan sok új kísérleti lehetőségre ad módot. Segítségével teljesen új típusú kísérleteket lehet majd megvalósítani. Első lépésként magával az extracelluláris elvezetés technikájával ismerkedtem meg, hisz enélkül nem lehet egy erre épülő fejlesztéssel foglalkozni. Eddig az elvezetések során agyi az elektromos jeleket (ill. kiegészítésképpen izomműködést is) vettünk fel és elemezhettünk ki. Mivel az elvezetésekkel az agyi elektromos jelek pszichikai és egyéb kapcsolatát, korrelációit szeretnénk feltárni, kézenfekvő hogy a digitálisan tárolt és grafikusan megjelenített hullámok mellé a kísérletről videofelvételt is készítsünk. A videofelvételnek köszönhetően lehetőség van a kísérletet úgymond visszajátszani, és a videón történt eseményeket összehasonlítani a velük összefüggésben levő agyi aktivitással. A felvétel és lejátszás legfontosabb kritériuma a szinkronitás, melyre munkám során a legtöbb hangsúlyt fektettem.
12
6. ELŐZMÉNYEK 6.1. A sokcsatornás extracelluláris elvezetés mint elektrofiziológia eszköz 6.1.1. Kísérlet bemutatása Az általam fejlesztett rendszer alapja a sokcsatornás extracelluláris elvezetés. Mivel ezt a technikát fejlesztem tovább, ill. egészítem ki, elengedhetetlen volt ennek alapos megismerése. Szakirányomon kötelező tantárgy volt az „Elektrofiziológiai mérések és protézisek I-II”, így az ott megszerzett friss tudásnak köszönhetően könnyebben láthattam át a dolgokat. Első szakirányú félévemben (Önálló laboratórium I.) ezzel a technikával ismerkedtem meg közelebbről, és amennyire csak lehetett folyamatosan részt vettem az aktuális kísérletekben is. Elektrofiziológiában a sokcsatornás extracelluláris elvezetés egy mérési technika. Az eredmények felhasználása sokféle lehet és a név is csak összefoglaló, több formája, megvalósítása is létezik. Minden esetben neuronok és neuronpopulációk által generált elektromos potenciálokat szeretnénk mérni. Ezek az elektromos tevékenységek közvetlen kapcsolatban állnak pszichikai és élettani állapotunkkal, és mi ezeket a kapcsolatokat szeretnénk feltárni. Ugyanezen potenciálokat mérjük a széles körben használt EEG-nél is, azonban a skalp felszínén lévő jelek a jelterjedés tulajdonságai miatt már nagyon gyengék és csak nagy populációk összjelét „halljuk” (értelemszerűen ettől még az EEG nem lebecsülendő eszköz), ugyanakkor megvan az az előnye, hogy viszonylag könnyen kivitelezhető és non-invazív. Meglepő hogy az EEG jel keletkezésének pontos mechanizmusát a mai napig nem
1. ábra: Az agyi elektromos jelek mérésére használt elektródok típusai, mérési stratégiák
sikerült egyértelműen leírni, de a jelterjedés tulajdonságaiból kiindulva a keletkezésükért koponya közelében lévő sejtek működése a felelős. Megemlítendő, hogy ezekkel a paraméterekkel általában ellentétesek az orvosi képalkotó technikák mint például az fMRI, amivel ugyancsak agyi aktivitást mérünk, és pontos információt kapunk a jel forrásának helyéről, viszont időbeli felbontása másodperces nagyságrendű. Az extracelluláris elvezetés részben az EEG eddigi hátrányait küzdi le. Ebben az esetben a mérőelektródákat közvetlenül az idegszövetbe helyezzük el. Ezzel sokkal jobb minőségű
13
jeleket kapunk (részletgazdagabb, „sejt-közeli”), és a jel forrása is könnyebben meghatározható, hiszen közvetlenül a forrás mellől mérünk (természetesen gyakorlatban ez korántsem ilyen egyszerű). A módszer előnyéből származik legnagyobb hátránya is, mégpedig hogy az eljárás erősen invazív. Az elektródok egy műtéti eljárással kerülnek az agyba, ami nyilvánvalóan kockázatos és nehéz feladat, ezért a kísérletek többsége állatokon zajlanak, és csak erősen indikált esetben alkalmazzák humán gyakorlatban. Ilyenek lehetnek például a súlyos epilepsziás gócpontok feltérképezése. Az elvezetések során megkülönböztetünk akut és krónikus(an) beültetett elektródokat. Az elektródok mindkét esetben egy műtét során kerülnek a szövetbe, de míg akut esetben a mérés csak alvó, a beavatkozás alatt álló alanyon történik, addig krónikus esetben egy hosszútávra beültetett elektródot helyezünk el. A krónikusan beültetett elektród hatalmas előnye, hogy a beavatkozás után is végezhetünk elvezetéseket az éber, szabadon mozgó alanyokon, ezzel sokkal összetettebb kísérletekre van lehetőség, és az én munkám hasznossága is itt nyilvánul meg. Vegyünk például egy olyan kísérlet ahol a patkány egy labirintusban mozog és hippokampuszának helysejtjeihez ültettünk be elektródot (a helysejtek különlegessége leegyszerűsítve az hogy csak a labirintus bizonyos területein tüzelnek, egyfajta topografikus leképzésként térképként működnek). A munkám segítségével így a cselekmény (patkány mozgása) és az elektromos jel (tüzelő sejtek) egyszerre válik megfigyelhetővé. Egy másik felhasználási terület lehet az alvásvizsgálat. A videón pontosan nyomon követhető, hogy az állat alszik-e ill. ha igen akkor az alvás milyen fázisában van (pl. REM fázisnál a szem és bajuszmozgás). Ezek a kísérletek videó nélkül nehezen lennének kivitelezhetőek.
Laborunkban a sokcsatornás extracelluláris elvezetések az alábbiakból állnak össze:
•
Kísérleti állat a beültetett elektróddal (általában ingerlés alatt áll).
•
Közvetlenül az elektród után csatlakoztatott előerősítő.
•
Közbenső főerősítő.
•
A megfigyelőszobától az AD kártyáig tartó csatorna (szalagkábel).
•
Az AD kártya számára a jeleket rendező/elosztó kapcsolódoboz (National Instruments, NI SCC-68).
•
Analóg-digitál konverter (NI PCI-6259 A/D kártyák).
•
Az NI kártya által beolvasott adatok rögzítését végző (nagy teljesítményű) számítógép, egy LabVIEW virtual instruments programmal vezérelve.
14
Az elektródokon általában több mérési pont, kontaktus található. Bizonyos esetekben előfordulnak egycsatornás, drótként működő elektródok is, de ezekből is többet helyezünk el. Minden kontaktus egy-egy csatorna az adatfolyamban, és innen származik a „sokcsatornás” elnevezés is. Az agyi elektromos jelek nagyon gyengék. Maga az akciós potenciál is max. 70 mV. Mivel az extracelluláris tér kiváló vezető, az amúgy is kis amplitúdójú jelek gyorsan szétfolynak és keverednek más neuronok által generált jelekkel. A jelenlegi standard mintavételezési frekvencia 20kHz. Ez azt jelenti, hogy minden egyes csatornán másodpercenként 20 000-szer mér az A/D kártya. Erre a nagy mintavételezési rátára azért van szükség, hogy később ki tudjuk válogatni belőle az „egysejt” aktivitást (unit activity), továbbá hogy részletesebben tudjuk statisztikailag elemezni. Egyetlen sejt jele a nagy amplitúdójával (és nagy frekvenciájával) különíthető el a háttéraktivitástól. Az egyes sejtekhez tartozó aktivitást szűréssel tudjuk kinyerni. A hozzájuk tartozó akciós potenciálok nagy frekvenciájúak, így egy megfelelő sáváteresztő szűrővel kinyerhetjük őket. A megkapott akciós potenciálokat ezek után paramétereik alapján klaszterezni szokták (csoportokba rendezés) egy-egy sejtnek megfelelően, de ez a téma már nagyon eltávolodik dolgozatom tárgyától. A jeleket felvevő számítógépen egy LabView virtual instruments program fut, mely kezeli az A/D kártyákat és rögzíti az adatokat neuroscan formátumú, cnt kiterjesztésű bináris fájlokba. Erről a szoftverről később még részletesen írni fogok.
6.1.2. Elektródok Az egész eljárás kulcsfontosságú eleme. Ez az elem helyezkedik el közvetlenül a szövetben. Anyaguk, formájuk és gyártási technológiájuk nagyon változatosak, csak egy adott típusú elektródról is külön szakdolgozatot lehetne írni, így itt most csak röviden bemutatnám pár főleg a laborban használt extracelluláris elvezetéshez használható típust. Az extracelluláris szó sejten-kívülit jelent. Az ilyen típusú elvezetéseknél a sejteken kívüli térben mérünk, ellentétben az intracellulárissal ahol behatolunk magába a sejtbe. Az intracelluláris mérésekhez üvegkapillárisokat használnak, mivel jelenleg csak üvegből lehetséges üreges, a sejtméret nagyságrendjének megfelelő méretű tűt készíteni. Ezzel ellentétben az extracelluláris elvezetéshez rengetegféle elektróda közül választhatunk. Az extracelluláris elektródok kialakítása főleg attól függ, hogy mire szeretnénk használni. Anyaguk szerint lehetnek például fém (platina, ezüst, acél), szénszál, üveg és szilícium, formájuk szerint legegyszerűbben csoportosítva 1, 2 és3 dimenziójúak. A legegyszerűbb kialakítású az egyszerű szigetelt drót, melynek lecsupaszított vége a
15
kontaktus. A drót maga ~0,23 mm átmérőjű és lakkszigetelt acélszálból készült. Egyszerűsége ellenére igen praktikus és olcsó. A több kontaktussal rendelkezők közül először a „linear array”-t avagy a rétegelektródát említhetnénk meg, melynél a kontaktusok sorban egy vektorban helyezkednek el. Az alapul szolgáló ~0,4 mm-es acélcsőben 24 kontaktus található, melyek ~50μm átmérőjű ugyancsak lakksziget 2. ábra: A rétegelektróda felépítése
acélszálból készültek. A köztük lévő
teret szigetelő anyag tölti ki, a végső felületet pedig polírozással készítik el. A több dimenzióban elhelyezkedő kontaktusok kialakítása már többféle is lehet. Léteznek egész agyterületeket beborító mátrixok vagy villaszerűen kialakított mikroelektródok is. Az elektróda gyártás ezen ága sokat átvett a félvezetőiparból. Ma már a legtöbb extracelluláris elektróda szilíciumból, MEMS és VLSI technikákat alkalmazva készül. A 3-as ábrán látható a Neuronexus cég egy elektródja. Ez a félvezetőgyártó cég kifejezetten szilícium alapú extracelluláris elektródok gyártására szakosodott, és nagyon széles termékpalettával rendelkezik. Egyéni kialakítás igénylő elektródokat is legyártanak. Talán a legextrémebb kialakítású elektród mátrixban elrendezett kontaktusokkal elrendelkező elektróda, melynek előállítása már nagyon bonyolult rétegtechnológiát kíván. Bizonyos esetekben az elektróda pár csatornáján nem elvezetni szoktak, hanem trigger csatornákként működnek, melyek általában ingerlésre használhatosak. Ezenkívül elektródokkal nem csak agyi elektromos jeleket vezethetünk el, hanem a később látható az izommozgások regisztrálására is használhatóak. Ez a rövid kis összefoglaló csak tájékoztató jellegű volt, természetesen az elektródokról még rengeteg mindent el lehetne mondani, azonban ez már nagyon elkanyarodna a dolgozatom témájától.
16
3. ábra: Egy krónikus beültetéshez kialakított szilícium alapú többcsatornás elektród
6.1.3. Beültetés Az elektromos jeleket elvezető elektródok egy műtéti eljárással kerülnek az agyszövetbe. Ez kísérlettől függően rövidebb és hosszabb ideig is eltarthat és a műtét bonyolultsága is változó. A nehézség függ a beültetés helyétől, a kísérleti állattól és az elektród paramétereitől, illetve hogy akut vagy krónikus beültetést végzünk. Az elektród beültetési helye természetesen attól függ, hogy milyen területet szeretnénk vizsgálni. A teljes beavatkozás egy ún. sztereotaxiás célzókészülékben történik. Ez egy precíziós, három tengellyel és skálával rendelkező eszköz, amely egy háromdimenziós Descartes koordinátarendszert definiál az alany koponyája köré. A koponya rögzítése a keretbe meghatározott anatómiai pontokon történik. Ezek egyezményesek, és az egyén tulajdonságaitól a lehető leginkább függetlenek. Patkánynál a tipikus két ilyen rögzítési pont a hallójárat és a felső állkapocs.
4. ábra: A sztereotaxiás keretbe befogott patkány a beavatkozás közben. A képen jól látható az eszköz három tengelye. A feltárt skalp felett a fúrás ill. az elektród helyét bejelölő tű látható A kiválasztott funkcionális terület megtalálásához ún. sztereotaxiás atlaszokat használunk. Ezen atlaszok tizedmilliméteres felbontásban tartalmaznak agyi metszetek ábráit, és az adott metszeten található funkcionális és anatómiai területek megnevezéseit. Ezért volt szükség az egyezményes koordinátarendszerre és rögzítési pontokra, mivel így a meglévő atlaszok
17
alapján tudunk navigálni (az atlaszokon kívül természetesen sokat számít az anatómiai tudás és tapasztalat). A koordináták kiválasztása egy külön tervezési fázis. A pozícióba való eljutás néha nehézségeket okozhat, például ha mélyagyi területeket szeretnénk vizsgálni (pl. hippokampusz), vagy ha a koponyán nehezen feltárható a terület (pl. látókéreg).
5. ábra: Részlet a patkány sztereotaxiás atlaszából. Az origónak a Bregma-t szokták kijelölni, mely a koponya tetején található a koszorúvarrat és sagittális varrat találkozásánál, ezért könnyen megtalálható és egyértelmű A műtét első lépése a craniotomia, mely a skalp eltávolításával és a koponya felületének megtisztításával kezdődik. Az előkészítés után a sztereotaxiás keret mozgatható fejét a kívánt területre állítjuk és bejelöljük a koponyán a feltárásra kijelölt területet. Ez után következik az egyik legnehezebb feladat a koponya kifúrása, mely nagy koncentrációt és tapasztalatot kíván. Innentől kezdve minden művelet már mikroszkóp alatt zajlik. A fúrás helyett jobb szó a marás. A koponyán való átjutás rétegről-rétegre történik, míg az el nem vékonyodik annyira hogy egy kis csipesszel ki lehessen „pattintani” azt. A koponyán ejtett lyuk (ablak) mérete nem szokta meghaladni a pár négyzetmillimétert. A feladat ezen része azért nehéz, mert el kell kerülnünk az idegszövet sérülését. Az ablak elkészülte után következik a fő lépés, az elektróda beszúrása. Talán ez a legnehezebb művelet, mivel az elektródok többsége igen sérülékeny. A behatolás során a dura mater-en való áthaladás terheli meg leginkább az elektródát, mivel ez a három agyhártyaréteg közül (neve is mutatja) a legvastagabb. Miután ezen átjutottunk, a nehezén már túl vagyunk. A behelyezés közben az elektródot rákapcsoljuk a rendszere, hogy nyomon követhessük működését. Az ilyenkor látható jelalakból több következtetést is le lehet vonni. A kontaktusok szabad szemmel nem láthatóak, így csak akkor lehetünk bizonyosak arról hogy a helyükre kerültek amikor a megfelelő jeleket kezdjük látni a képernyőn. A még kint lévő kontaktusok a
18
mikroszkópban láthatóak, de a fiziológiás oldat és szövetből eredő folyadék a kontaktusokra kerülve jelet vezetnek át, így a képernyőn akár úgy tűnhet, hogy az a helyén van. A jelalakból arra is következtethetünk, hogy az adott kontaktus épp milyen területen helyezkedik el (például más jelalakok figyelhetőek meg a kéregben és thalamuszban). Az elektródot addig toljuk lefelé a keret mozgatómechanizmusával, amíg az utolsó kontaktus is eltűnik, és el nem érjük a legideálisabb pozíciót. Akut és krónikusan esetben itt kettéválik a metódus. Akut esetben nincs már más teendőnk mint elkezdeni a tényleges mérést, szükség szerint állítani a pozíciót és ingerelni (hang, bajusz, gyógyszeres stb. ingerlések). Krónikus esetben még sok teendő maradt hátra. Az elektróda működésének tesztje után, a koponyát vissza kell zárnunk és az elektróda kivezetéseit, csatlakozófelületeit ki kell alakítani. Az elektródokhoz, az erősítő és a mérőeszköz működéséhez szükséges földelési, ill. referenciapontokat, vezetékeket is ki kell kialakítani (hiszen potenciált mindig csak két pont között tudunk mérni). A koponyába kis csontcsavarokat helyezünk el melyek egyrészt az előbb említett pontoknak felelnek meg, másrészt a következőkben felépített vázat kapcsolják össze a koponyacsonttal. A csatlakozófelület, a hozzátartozó kis szalagkábel és a referencia csatlakozók egy csontcementből készült koronába kerülnek rögzítésre. Az idegszövetnek pár nap regenerálódásra van szüksége. Miután az állat megszokta a fején levő csatlakozókat és szervezete is hozzászokott az implantátumhoz, élheti tovább megszokott életét és folyamatosan lehetőséget biztosít a mérésekhez, és ami számunka fontos, éber állapotban és természetes alvás közben is. A beavatkozások természetesen altatott állatokon történnek, és a műtét során folyamatosan nyomon követjük életjeleiket, ill. altatásban tartjuk őket. Az eljárások során szigorúan betartjuk a hatályos törvényeket és etikai szabályokat.
6.1.4. Elektronikai részegységek, szoftverek Az elektróda és a felvevő számítógép közti elektronikának két fő szerepe van: erősítés és analóg-digitál konvertálás. Mint szó volt róla, a forrásnál lévő elektromos jelek amplitúdója nagyon kicsi. A kísérlet és a felvevő számítógép külön-külön szobában van, így a jelnek több méteres utat kell megtennie. Ez okból már közvetlenül az elektróda után be van iktatva egy előerősítő továbbá a számítógépig tartó úton egy főerősítő. Az erősített jelek szalagkábeleken futnak be a számítógépbe. Mivel a számítógép csak digitális formában képes az adatot tárolni, mintavételezéssel konvertálnunk kell az analóg jelet. Az analóg digitál konvertálást egy National Instruments A/D kártya végzi, melyet egy LabView szoftver vezérel. A mintavételi
19
frekvencia állítható, de a 20kHz a sztenderd. A felvett jeleket többek közt a Neuroscan cég SCAN nevű szoftverével elemezzük ill. saját készítésű MatLab programokkal. A jelek nagyon érzékenyek a zajra. A legtöbb gondot az elektromos hálózat okozza. Ha a kísérlet közelében bármilyen „háztartási” (tipikusan lámpák) eszköz áram alatt van, akkor az elvezetett jeleken egyértelműen látható lesz a hálózat 50 Hz-es mintázata. A zaj megelőzésére felvételkor a lehető legtöbb elektromos eszközt ezért kikapcsoljuk, ezenkívül ha lehetséges, ún. Faraday kalitkába végezzük a mérést. Utólagos szűréssel még csökkenthető a zaj, de a legjobb elkerülni.
20
7.1 A VIDEÓ-EEG LEJÁTSZÓ Konzulensemhez kerülve első feladatom a lejátszórendszer fejlesztése volt. Nem volt könnyű dolgom, hiszen nem találtam kiindulási pontot vagy hasonló megoldást amiből kiindulhattam volna. A szoftver MatLab környezetben készült és bár tanulmányaim során gyakran kellett használnom, mégis sokszor teljesen új területekkel kellett megismerkednem. Emiatt a munka elején csak lassan haladtam, viszont most már elég biztosan mozgok e környezetben és megismerhettem eddig nem tanult funkciókat, megoldásokat is. Részben emiatt és részben a hasonló megoldások hiányában a fejlesztés korai szakaszában több zsákutcába is futottam, míg el nem készült a mostani használható verzió, mely a SyncPlayer nevet kapta.
7.1.1.Célja A Videó-EEG lejátszó szoftver alapvető funkciója, hogy a kísérletek során készült videót és az agyi elektromos jeleket szinkron mód lejátssza. Ez a kettős lejátszás az egész rendszer lényege, hiszen így párhuzamos figyelhetjük meg a kísérleti állat viselkedését és a viselkedéshez tartozó neurális tevékenységeket.
7.1.2. Kritériumok A lejátszás során a legfontosabb kritérium a szinkronitás. A videón látható frameket ezredmásodperces pontossággal kell szinkronizálni az agyi elektromos jel aktuális időpontjával. E kritérium nélkül szoftver mit sem ér, ezért a fejlesztés során ezt tartottam leginkább szem előtt. Ezen kívül fontos szempont volt a könnyű használhatóság és átláthatóság, mely a később látható grafikus felhasználói felületen (GUI) nyilvánul meg. Amennyire csak lehetett megpróbáltam modulárisan fejleszteni, hogy az adott funkciók könnyen kicserélhetőek legyenek. Az agyi elektromos jeleknek átláthatóan, megfelelő arányú (idő/amplitúdó) módon kell megjelenniük. A MatLab keretrendszer választására azért került sor, mert a laborban már több más szoftver is ebben készült, gyorsan lehet benne fejleszteni és többen is segítségemre tudtak lenni ha kérdés merült fel.
21
7.1.3. A felhasználói felület bemutatása
6. ábra: A SyncPlayer elnevezésű program felhasználói felülete használat közben
1. Főablak, a cnt fájlokból kiolvasott adatok megjelenítésére. A rácsozat egy másodpercenkénti, az ablak időtartománya állítható. 2. Videomegjelenítő ablak, továbbá alatta látható az aktuális pozíciót jelző „óra” 3. Aktuális pozíció az 1-es ablak által megjelenített intervallumban (animált) 4. Aktuális pozíció a videó/cnt fájl teljes hosszát tekintve (animált) (A két csúszka mozgatásával bele lehet tekerni a felvételbe) 5. Fő kezelőfelület a lejátszáshoz: Play, Pause, Stop, Open, Fast Forward, stb. 6. Az 1-es ablak méretét beállító felület 7. A csatornák egymáshoz képest való eltolása az 1-es ablakban 8. A cnt fájl és a videó fő paraméterei: mintavételezési ráta, csatornaszám, hossz, fájl név, aktuális pozíció, stb. 9. Aktuális pozíció beállításának másik, numerikus módja (így a lehető legpontosabban ugorhatunk adott időponthoz) 10. Event kezelés (lásd később) 11. A lejátszó üzenetei a felhasználóhoz (hibaüzenetek, tanácsok, jelentések) 12. 'checkbox' (pipa) oszlop, mellyel a jobb átláthatóság kedvéért beállítható, hogy melyik csatornákat szeretnénk megjeleníteni
22
7.1.4. Funkciók és használatuk A program indításához nincs más dolgunk mint MatLab parancssorba beírni a SyncPlayer parancsot. A lejátszó felhasználói szempontból úgy működik mint egy szokványos médialejátszó. A gombokkal navigálhatunk a felvételen és több megjelenési tulajdonságot is beállíthatunk. Indításkor egy üres felület jelenik meg. A „vezérlőpulton” lévő megnyitás gombbal választhatjuk ki a kívánt cnt fájlt. Ekkor a program automatikusan megnyitja az e fájlhoz tartozó videót. Egyezmény szerint a program a cnt fájl mellé az azonos nevű, de más kiterjesztésű videót nyitja meg. Fontos hogy a cnt és videó fájl egy mappában legyen, különben hibaüzenetet kapunk. Megnyitás után megjelenik a kezdeti időponttól az ablak méretéig terjedő jel. Az „infobox”-ba betöltődnek a mérés fontosabb paraméterei mint a fájl neve, hossza, csatornák száma, stb. Az ablak bal oldalára kirajzolódnak a csatornákat szimbolizáló „checkbox”-ok, ezeket ki/be pipálva válogathatunk a megjelenítendő csatornák közt (sok csatorna esetén ez igen hasznos funkció). A lejátszás kezelése magától értetődő, csak megnyomjuk a 'play' gombot és elindul a lejátszás. Korábbi verzióknál az elektromos jel megjelenítése animált volt, de a később említett okok miatt végül statikus lett, és az aktuális pozíciót egy kurzor szimbolizálja, mely egyszerűen végigrohan a jelen. A kijelzőn lévő jelre bárhol rá lehet kattintani és kiválasztani egy adott időpontot. Ekkor a videó is az adott időpontra ugrik, továbbá megjelenik a kijelölt ponthoz tartozó pontos idő. Ez is egy nagyon hasznos funkció, mert milliszekundum pontosan ki lehet választani adott időpontot és a hozzátartozó framet. Ez a lehetőség csak leállított (paused) állapotban érhető el az épp megjelenített időintervallumon, hiszen a jel elugorhat miközben kattintunk és a videó is folyamatosan változik. A grafikon megjelenésén több paramétert is állítani lehet. A baloldalon lévő pipákkal kiválaszthatóak a megfelelő csatornák, de ugyanezt egy felugró ablakban szövegesen is meg lehet adni (felsorolva a számokat). A megjelenítendő intervallum (ablak mérete) is állítható. A grafikon minden esetben az egész másodperceknél szaggatott függőleges tengelyt húz be a jobb átláthatóságért. A grafikon alján lévő bal/jobb nyilakkal lapozni lehet. Ekkor egy ablaknyit arrébb ugrunk az időben. Természetesen ez a funkció is csak leállított állapotban működik. A grafikon legalján két fontos „csúszka” (slider) található. Ezek szimbolizálják az aktuális pozíciót. A felső slider az ablakon belüli időpontot mutatja, míg az alsó a teljes időtartományon belüli pozíciót. Mivel az ablak folyamatosan lapozódik, a lokális slider körbekörbe fut. Ahogy egy hétköznapi lejátszón, úgy itt lehetséges ezekkel a sliderekkel navigálni (seeking). Az „infobox” legalsó sora a lejátszó üzeneteit írja ki, mint például ha lejátszás
23
közben kattintunk a grafikonra, figyelmeztet hogy ezt csak leállított módban lehet. Egy különálló funkció az ún. event (esemény) kezelés. Több EEG jeleket elemző és feldolgozó szoftver használja az ún event fájlokat. Ezek nagyon egyszerű text fájlok, melyek időpontokat és a hozzájuk tartozó eseményeket tárolnak. Segítségükkel egy ezt használó szoftverrel meg lehet adni például hogy: „átlagolj ki minden X esemény utáni állapotot”. A lejátszószoftverrel lehetséges az ilyen event fájlok készítése. Az eventkezelő ablakot bekapcsolva lejátszás közben a megfelelő gombok megnyomásával eventeket menthetünk el. Az események a 'save' gomb megnyomásával szabványos .ev2 kiterjesztésű fájlokba mentődnek. Nagy csatornaszám esetén a jelek már nehezen férnek el a kijelzőn, és a jelenlegi felbontásban már így is túlzsúfolt a felület, a videónak is csak egy kis ablak jutott. Ezért egyrészt növelni szeretném későbbiekben a felbontást, másrészt felmerült a többképernyős megjelenítés ötlete is. Kísérlet képpen a felhasználói felületet kettébontottam két ablakra, és az új ablak csak a videó megjelenítésére szolgál. A notebookhoz csatlakoztatott második monitort csak be kell állítani az operációs rendszerben és már használatra is készen állt (kiterjesztett desktop mód). A szoftver elindításakor a videoablakot áthúzzuk az egérrel a másik monitorra, vagy csak lejátszás közben duplán kattintantunk rá és a videót teljes képernyőn nézhetjük a második monitoron. Így az elektromos jelek megjelenítésére is több hely jut. Ezt a kétképernyős verziót csak próbaképp készítettem, még nincs teljesen letesztelve, de igény szerint lehetőség van e mód használatára is. Ami problémát jelenthet azaz erős operációsrendszer-függés, továbbá a későbbiekben említett Media Player verziókülönbségek is okozhatnak anomáliákat.
7.1.5. A program felépítése A MatLab keretrendszer sok hasznos és kész funkciót szolgáltat, kifejezetten tudományos, kutatási célokra. Részben ezeket felhasználva fejlesztettem, de segítséget kaptam a laborból is, illetve rengeteget segített a MatLab súgója mely sok hasznos példát tartalmaz. Ezen kívül érdemes volt alaposabban is utánaolvasni pár dolognak az e témákkal foglalkozó internetes fórumokban. A fejlesztés elején három fontos problémával kellett foglalkoznom. Elsőként megoldást kellett találnom a cnt fájlok beolvasásárára és megjelenítésére, másodszor kellett valamilyen videomegjelenítési eszközt találnom, és harmadszorra az egyik legfontosabb hogy ezeket összeszinkronizáljam.
24
7.1.5.1 A cnt bináris fájlok olvasása A Neuroscan cnt fájlok bináris olvasásához való függvény megírása, a megfelelő források hiányában számomra nem volt lehetséges. Ezért már meglévő függvényeket ajánlottak fel a laborban. Az első ilyen egy zsákutca volt, mivel az a cnt fájl teljes tartalmát beolvasta a memóriába, ami míg kisebb próbafájlokon működött, a gyakorlatban használt nagy fájlokon (akár 2 GB) már használhatatlanná vált. Végül nagy segítségemre volt a labor egy doktorandusza Csercsa Richárd, aki felajánlotta saját készítésű fájlolvasó függvényét, melyet egy ugyancsak MatLab-ban készült cnt elemző szoftveréhez készített. Ezt a függvényt alakítottam át a saját problémámnak megfelelően. Erre a függvényre leginkább azért volt szükségem, hogy megismerjem a cnt fájlok felépítését, konkrétan hogy megtudjam milyen adatok milyen byte-okon helyezkednek el. Az adatkiolvasó függvény paraméterként megkap egy csatornaindexet, ill. egy kezdő és végpontot, majd egy vektorban visszaadja a megfelelő értékeket. Mivel nekem lejátszás közben folyamatosan kellett olvasnom fájlt, több optimalizációs változtatást is eszközölnöm kellett (lásd később). Funkcionálisan több részre osztottam a függvényt és csak az a része maradt meg, ami a folyamatosan változó időindexekhez tartozó adatokat olvassa ki. Az egyéb kiolvasásokat és beállításokat átettem a program inicializációs részébe. 7.1.5.4. A GUI szerkezete, ActiveX, Media Player Az egyik legnagyobb kihívást a videó kezelése jelentette. Itt futottam bele a legtöbb zsákutcába. MatLab-ban léteznek beépített videókezelők, de egyik sem arra a célra amire nekem szükségem volt. A beépített lejátszókat (pl. 'mmread', 'implay', 'mplay') nem tudtam darabokra bontani, hogy beilleszthessem a saját felhasználói felületbe továbbá sokkal bonyolultabbak voltak a kelleténél. Sok másfajta lehetőség pedig inkább a videók elemzésére, morfológiájára volt használatos, és a framek kezelésén volt a hangsúly, így nehezen lehetett időzíteni továbbá a hardver igényük is sokkal nagyobb mivel a videóban minden framet átkonvertálnak egy MatLab által támogatott formába, sőt néha az egész videót be kellett tölteni a memóriába. A megoldást végül egy fórumban találtam meg.
25
A MatLab 6.5-ös verziótól támogatja az ún. ActiveX control-okat. Az ActiveX (eredetileg Component Object Model, COM) egy technológia, szabvány, mely a komponens alapú fejlesztés támogatását szolgálja. A COM programozók a szoftvereiket a COM feltételeinek megfelelő komponensekből építik fel. Minden COM komponens egy vagy több interfészen keresztül szolgáltat funkciókat. Az interfészeknek több programozási nyelvhez van ún. kötése, például C, C++, D, Visual Basic, valamint több Windows platformon implementált script nyelvhez (pl. MatLab!). Mint ahogy az később látható, a komponensekhez való hozzáférés az interfészek metódusain keresztül történik. Esetünkben az ActiveX támogatás azt jelenti, hogy a MatLab-ban készült grafikus felhasználói felületekbe ActiveX controlokat helyezhetünk el. Rengeteg féle control létezik a világhálón, kezdve a pdf olvasótól a táblázatkezelőn át a különböző médialejátszókig. A szoftverembe végül egy Windows Media Player ActiveX control-t helyeztem el. Az objektum referenciáit, metódusait, egyszóval leírását az MSDN-en
7. ábra: Az MSDN online elérhető dokumentációja a Media Player-hez
(Microsoft Developer Network) találtam
meg. Mivel a Media Player olyan kiterjesztésű és kódolású fájlokat tud lejátszani, mint amilyen codec-ek telepítve vannak, így ez a lejátszó is szinte bármilyen formátumot támogat. Ha későbbiekben a felvevőrendszert megváltoztatjuk, attól még a lejátszórendszer ugyanúgy használható marad. A program a már említett grafikus felhasználói felülettel rendelkezik. Ennek törzsét a MatLab 'guide' nevű GUI szerkesztőjével készítettem. Azonban itt csak az általánosabb elemeket helyeztem el. Lehetséges a GUI-kat teljesen manuálisan is elkészíteni, csak nagyon időigényes a sok paraméter beállítása miatt. A 'guide'-ban, mint egy szerkesztőben csak le kell pakolni az ablakba a grafikai elemeket (gombok, kijelzők, menük, stb.) és ha elkészültünk, a szerkesztő legenerálja nekünk a hozzátartozó MatLab forráskódot (amit manuálisan kellett volna megírni). A dolgokat csak az bonyolítja, hogy a 'guide' két fájlt generál, az egyik egy .fig kiterjesztésű, és a felületet reprezentálja. Tulajdonképpen csak egy lista a komponensekről. A másik fájl amit kapunk egy .m kiterjesztésű, amiben csak ki kell töltenünk a megfelelő függvények törzsét és azok végrehajtódnak például egy gomb megnyomásakor (callbackeknek hívják ezen függvényeket). Mint említettem a 'guide'-ot csak az általános elemek generálásához használtam. Több komponenst inkább manuálisan helyeztem el, hiszen például a csatornákat reprezentáló pipák száma változó, a cnt fájl függvénye. Lehetőség lett volna az ActiveX controlt is a
26
szerkesztőben elhelyezni, de ezt is inkább manuálisan tettem, mert ha így nehezebben is, de szabadabban tudom kezelni. Minden 'guide' által generált elem elérhető az .m fájlban az ún. handles konténeren keresztűl, és így elérve úgy használhatóak a metódusaik mintha manuálisan hoztuk volna létre. 7.1.5.3. global paraméterek A program modularitását megfelelő függvények használatával próbáltam elérni. Mivel sok változót több függvény is használ, ezért ezeket nem egyenként adom át nekik, hanem globalként deklaráltam őket. MatLab-ban ez kicsit olyan mintha osztályszintű változók lennének. A global-ként deklarált változókat bárhol, bármikor elérhetjük. A cnt fájlokra vonatkozó ill. a belőlük kiolvasott fontos adatok változói: global global global global global global global global
fid; Srate; Length; Ch_num; CNT_FILE_NAME; baseline; sensitivity; calib;
% % % % % % % %
maga a cnt fájl mint bináris fájl mintavételezési ráta cnt fájl hossza (pontokban) cnt csatornák száma file neve kalibrálási változók
A megjelenésre vonatkozó változók: global global global global global global global
Win_size_sec; Win_size; Act_ch_num; Act_chs; Ch_boxes; Plot_shift; dec_fact;
% % % % % % %
az ablak hossza amibe kirajzolunk (sec) az ablak hossza amibe kirajzolunk (pontokban) az aktuálisan megjelenített csatornák száma pipákat reprezentálja (0/1) a pipa grafikai objecteket tárolja csatornák közti eltolás a megjelenítéshez megjelenítendő adat csökkentésének mértéke
lejátszáshoz szükséges változók: global global global global global global global
MovieControl % Act_signal; % Buffered; % Current_position;% P_start_time; % Run; % Opened; %
A mediaplayer Ez az aktuális, épp a kijelzőn látható jel be van-e töltve a következő ablaknyi adat aktuális pozíció/idő (pontban) Plottolási ablak kezdete (pontokban) fut-e a lejátszás meg van-e nyitva fájl
A program inditásakor egy inicializációs rész fut le. A gui kirajzolása előtt pont ilyen lehetőségre ad módot az OpeningFcn függvény, mely minden 'guide' által generált felhasználói felületben megtalálható. A megnyitás gombra kattintva a felhasználót egy szokványos user interface segíti a fájl kiválasztásában. Miután a program megkapta a fájl nevet, elkezdi a mérés alapadatait
27
betölteni, majd az adatoknak megfelelően beállítani a megjelenítő felületet, míg végül „kiplottolja” az első ablaknyi jelet. Innen már nincs más dolgunk mit a „play”-re kattintani. 7.1.5.4. A főciklus működése A lejátszás maga tulajdonképpen egy nagy ciklus, melyet a lejátszógomb megnyomásakor lefutó függvény indít el. Ahogy fent említettem, az ActiveX control-os mediaplayer objektumot el lehet érni a megadott metódusaival. A ciklus indulása előtt egyszerűen csak meghívjuk a lejátszó lejátszást elindító metódusát azaz a Player.controls.play-t. A lejátszó objektum számomra legfontosabb írható és olvasható változója a Player.controls.currentPosition. Ez a változó tárolja lejátszás közben a videó aktuális időpontját. A változó írása pedig megfelel a videóba való „beletekerésnek”. Ezt a változót olvasom ki a ciklus minden iterációjában és ez alapján frissítem a számlálókat és a slidereket is. Ez kicsit leegyszerűsítve így néz ki:
Run=true; mp.controls.play; while (Run) || (Current_position+Win_size>=Length) hold on; Current_position=(mp.controls.currentPosition)*Srate; if ~Buffered && Current_position>P_start_time+Win_size-3*Srate PreLoad(P_start_time + Win_size, P_start_time+2*Win_size); end if Current_position>=P_start_time+Win_size P_start_time=P_start_time+Win_size; Plot_it(handles); end set(handles.S_time,'string', Current_position/Srate); set(handles.TEXT_act_pos,'string', Current_position); set(handles.Act_locpos_slider, 'Value', Current_position-P_start_time); set(handles.Act_pos_slider,'Value', Current_position); set(handles.TEXT_currentPositionString, 'String', mp.controls.currentPositionString);
end
pause(0.001) hold off;
28
8. ábra: A kirajzoláshoz (plot) és lejátszáshoz használt változók, illetve a lejátszóciklus működése A Plot_it függvény felelős az adatok kirajzolásáért. Mivel a kirajzolás kissé összetett és több helyen is szükség van rá, logikus volt hogy egy külön függvény feleljen érte. Egy korábbi verzióban ebben a függvényben volt a cnt fájlból való olvasás is, de a később leírtak miatt végül kivettem belőle és csakis a kirajzolásért felelős. A PreLoad függvény tölti be a Buffered_signal-ba a soronkövetkező adatokat, és ha elkészült vele, a Buffered változót true-ra állítja. A Plot_it mindig a Buffered_signalban lévő adatokat rajzolja ki. Amennyiben nincs pufferelve adat ( vagyis Buffered == false) akkor meghívja a PreLoad függvényt. A 8-as ábrán látható PreLoad után azért tettem kérdőjelet, mert az adatok betöltésére két stratégiát is használhatunk, ennek magyarázatára később térek rá. 7.1.5.5. Data cursor A lejátszó egy praktikus funkciója az ún. 'data cursor'. Ez MatLab-ban egy alapból használható funkció, amit csak engedélyezni kell egy adott axes-re (ez az a felület amire a plot függvény a jeleket kirajzolja). Ha ezt engedélyezzük és a kirajzolt jelalak egy pontjára kattintunk, akkor egy kis ablakban megjelenik az adott pont x és y értéke. Azonban a data cursor lehet tetszőleges működésű is, csak meg kell adni annak a függvénynek a nevét amit futtatni akarunk egy kattintáskor. Az alap data cursort ezért 9. ábra: A Data cursor működése
kicseréltem egy saját verzióra. Célom az volt hogy adott pontra kattintva
29
megkapjuk a pont precíz időpontját, és hogy a videó a ponthoz tartozó frame-hez ugorjon. Az általunk megírt data cursor függvényhez csak annyi kikötése van, hogy egy stringet kell visszaadnia. Ez lesz az a string amit kattintáskor megjelenik. A függvény bemenő paraméterként megkapja a grafikai objektum hierarchiából az ún. event_obj-et, melynek 'Position' értékét kiolvasva kaphatjuk meg a ponthoz tartozó x és y értéket. Mivel nekem szükségtelen volt az y koordináta, ezért azt elhagytam és csak az x-et használtam (az x tengely az idő). Ez az x koordináta azonban csak az abalokon belüli koordináta és nem az egész jel hosszára vonatkozó érték (mivel az ablak egy adott időtartomány jelenít meg), ezért ehhez az értékhez még hozzá kell adni plottolás kezdetéig eltelt időt (P_start_time), és végül már csak formázni kell a kimeneti stringet. A másik fontos feladat, hogy a videót is beállítsuk a ponthoz tartozó framre. Ezt könnyen megtehetjük, csak a Player.controls.currentPosition-t kell az előbb kiszámolt értékre állítani (és ezen kívül a slidereket és számlálókat is frissíteni kell). 7.1.5.6 Eseménykezelés Az eseményrögzítés egy külön modul a szoftverben. Fent említett lényege, hogy .ev2 kiterjesztésű fájlok szabványának megfelelően eseményeket rögzítsen. Az event fájlok felépítése igen egyszerű. Egy esemény egy sor a txt-ként kódolt fájlban. Egy esemény legfontosabb paraméterei: az azonosítója (egész szám), a bekövetkezés időpontja (pontként definiálva, idő kiszámítása az Srate segítségével) és az esemény típusa (egy egész szám). Az eseménykezeléshez egy külön kis kezelőfelület áll rendelkezésre. Ez egy gombokból álló kis ablak ahol minden gomb egy beprogramozott esemény rögzítésére szolgál. Megnyomásakor mindig a gombhoz tartozó azonosító és az aktuális időpont rögzül egy global vectorba. Ha fájlba szeretnénk menteni az eseményeket, azt a 'Save' gombra kattintva tehetjük meg. Mivel a vektorba egymás után kerülnek be az adatok, és 10. ábra: Az eseménykezeléshez lejátszás közben vissza is tekerhettük a felvételben, kiírás előtt először tartozó kis rendezi kell a vektort egy kis algoritmus segítségével. A rendezés felhasználói felület végeztével egy ciklus újra végigfut a vektoron és minden tagjára meghívja a 'new_event_line' függvényt, mely az ev2 fájl szabványa szerint generálja le a fájl sorait és betölti azt az újonnan létrehozott cnt fájlnévvel egyező fájlba.
ID event type time(points) ------------------------------------7 2 0 0 0.0000 25291 8 3 0 0 0.0000 27416 9 1 0 0 0.0000 29165 10 4 0 0 0.0000 32547 11 1 0 0 0.0000 33539 12 3 0 0 0.0000 34667 13 2 0 0 0.0000 42920
11. ábra: Részlet egy .ev2 fájlból
30
7.1.6. Felmerült problémák és megoldásuk A szoftver első verziója az elektromos jeleket animálva jelenítette meg. Itt futottam bele a legnagyobb problémába. Sehogy se sikerült folytonos (ami pl. minimum 20 fps) mozgású animációt elérni. Az ok a nagy adatmennyiség kezelése volt. A példa kedvéért vegyünk egy 24 csatornás jelet (ami nem is sok csatorna) a standard 20 kHzes mintavételezéssel. A megjelenítő ablak pedig legyen 7 másodperc hosszú, és tegyük fel hogy 25 fps-es animáció a cél. Ez másodpercenkénti 84 000 000 pont fájlból való kiolvasását és képernyőre való kirajzolását jelenti. Ilyen sok adat kezelése és a pontok megmozgatás elvileg nem olyan nagy feladat egy mai hardverrel. Elméletileg egy modernebb játékszoftver is sokkal bonyolultabb ennél. A nagy mennyiségű adattömegen kívül a probléma leginkább abból adódik, hogy a MatLab nem ilyen mértékű grafikára van optimalizálva, ellenben egy játékkal amit direkt úgy fejlesztettek. Ne feledkezzünk meg arról, hogy mindezen adatokat folyamatosan olvasni kell a lassú háttértárból, és arról sem, hogy mindemellett egy DivX-es videó is fut. A probléma megoldását két irányból közelítettem meg. Egyrészt redukálni kellett az adatmennyiséget, másrészt kihasználni a MatLab ritkábban használt, de jelen esetben annál hasznosabb funkcióit. Végül pedig le kellett mondanom az animált megjelenítésről, mely helyett az eddig látott mozgó kurzor és lapozás maradt. Az animált megjelenés igazából csak látványosság, a mozgó kurzor ugyanúgy megfelelő sőt gyakorlatban talán jobb is. Mivel 20 kHz-en mintavételeztünk, nyilvánvaló hogy rengeteg pontot fölöslegesen olvasunk ki, és jelenítünk meg. Egy átlagos monitor max. 1600 pixel széles és ebből megjelenítésre is csak egy része a grafikon területe. Egy csatornán 7 másodperc ezen a mintavételezésen 140 000 pontot jelent. Ez azt eredményezi, hogy a MatLab rengeteg pixelt subpixelként kezel és nem jelenít meg. Kicsit megdöbbentően hangzik, de most mindössze minden ötvenedik pontot olvasok ki és jelenítek meg, és még így több a pont mint ami elfér. Joggal merül fel a kérdés, hogy ekkora arányú adatvesztés megengedhető-e. A tapasztalat szerint igen. A 20 kHz-es mintavételezés a statisztikai elemzésekhez és az egysejt aktivitás miatt szükséges. Bár százalékosan sok adatot hagyunk el, emberi szemmel még így is nehezen vehető észre a különbség a monitoron. Mivel a lejátszónál a szinkronitás a legszigorúbb kritérium, ez az az ár bőven megengedhető volt. Ettől az adatmennyiség csökkenéstől a jelen látható jelenségek ugyanúgy megfigyelhetőek. Az adatvesztés problémára még megoldás lehet a pontok kiátlagolása is, azonban ez megint csak nagy számítást igényelne. Ha csökkentjük az adatmennyiséget, az olyan mintha a mintavételezést is csökkentenénk. Erre kritikusan oda kellett figyelnem, hisz az időt mindig a pontok számát, a mintavételezési frekvenciával megszorozva kapjuk meg (pl. Current_position*Srate). A programban
31
bevezettem egy dec_fact nevű változót mely az adatmennyiség csökkentés mértékét tárolja. Tapasztalat szerint az 50-szeres csökkentés a legideálisabb (más érték nem elég, vagy a jel csúnyán jelenik meg). A változóval szinte minden Srate használatkor szorozni/osztani kell (pl. Current_position*Srate/dec_fact). Az adatcsökkentés a fájlolvasáskor történik meg. Fontos hogy eleve kevesebb adatot olvassunk be, hisz a háttértárból való olvasás is nagy időt vesz igénybe. A cnt fájlokban a mérési pontok csatornák szerint váltakozva vannak felsorolva. Egy adott csatorna beolvasása egy adott időintervallumról így néz ki: [signal] = fread(fid, time/dec_fact, 'int', jump*dec_fact);
Ahol: signal: kimemő adat (felhasználás előtt egyéb adatokkal még kalibrálva) fid: fájl azonosító, maga a cnt fájl dec_fact: adatcsökkentés mértéke time: az intervallum hossza amit be szeretnénk olvasva (ezt előző sorokban ezt pontosan ki kell számolni a fájl felépítése alapján) int: jelző, hogy a binárisan beolvasott adatot milyen típusként kezelje jump: a csatornák szerint váltakozó adatok miatt csak minden 'jump'-adik adat ami az adott csatornához tartozik. Itt látható legjobban a dec_fact használata. Mivel a time határozza meg a kiolvasott adat mennyiségét, így azt osztani kell, míg a jump-ot szorozni hiszen csak minden ötvenedik (dec_fact) adatot olvasunk ki. Az intervallum határa nem, csak a számossága változik. Ezzel a technikával sikerült mind a háttértárból való olvasás idejét, mind a kirajzolás idejét drasztikusan csökkenteni. Azonban a lapozásnál még így van egy kis megakadás. A 8-as ábrán látható PreLoad felirat után a kérdőjelet azért tettem ki, mert ahogy említettem az adatok kiolvasására két stratégiát is használhatunk. Mivel a grafikát sikerült hatékonyra állítani (lásd később), a késleltetést már csak a háttértárból való kiolvasás okozza. Ez volt az egyik ok amiért a Plot_it függvényből kivettem a fájlolvasást és külön funkcióba tettem (PreLoad). A PreLoad vagyis az adatok beolvasása történhet lejátszás közben (egyfajta pufferelés) ill. közvetlenül a lapozás előtt. A probléma az, hogy a háttértárból való kiolvasás megakasztja a kurzor mozgását fél-egy másodpercre, ami funkcionálisan nem nagy gond, viszont bántó a szemnek. Ha a PreLoad a lapozás végénél történik, akkor a kurzoron nem látszik az akadás viszont a lapozásra kell félegy másodpercet várni.
32
A gyorsítására azonban még pár más trükköt is bevetettem. A MatLab által generált ablaknak rengeteg beállítható tulajdonsága van, köztük egy ilyen a 'Renderer', mely három-féle beállítást enged meg: painters, zbuffer, OpenGL. Mindháromnak megvan a maga előnye és hátránya. Én az OpenGL-t választottam, mert nagyobb grafikákhoz ez praktikusabb, de ami még fontosabb hogy ez a mód hardveresen is támogatott, megefelelő videókártya esetén. A harmadik teljesítmény javító lehetőség a párhuzamos programozási lehetőségek kihasználása. Ma már a legtöbb PC többmagos processzorral rendelkezik és az ezeket támogató technikák is rohamosan fejlődnek. Ez a lehetőség már MatLab-nál is adott. A jelenlegi legtöbb fejlesztést e téren teszik a MatLab fejlesztői. Mivel ezek elég friss fejlesztések, még korántsem sikerült ezeket a lehetőségeket kihasználnom. Az egyik ilyen amit most használok az a for ciklusok párhuzamosítása. Erre már viszonylag rég óta van lehetőség az ún. parfor ciklus használatával, de az újabb verzió már a drange funkciót kínálja. Az eredeti tervek szerint az eseménykezelést nem egy gombokkal teli kis ablak vezérelte volna, hanem a felhasználó a billentyűzet segítségével adhatott volna utasítást az esemény elmentésére (pl. numerikus billentyűzet 1-9 számai). Itt azonban végül abba a megoldatlan problémába ütköztem, hogy a GUI-ba beépülő Media Player egy ablak az ablakban és ez káoszt okozott a billentyűzet figyelésben. Az ún focus (vagyis hogy melyik ablak az aktív amire figyelnie kell a rendszernek) hol a nagy ablakra, hol a Media Player-re vándorol. Ebből az a hiba fakad, hogy mind a MatLab által kezelt ablak, mind a Media Player is rendelkezik egy külön-külön billentyűzet figyeléssel. Emiatt a billentyűzetfigyelés attól függ, hogy melyik ablak az aktív. Ezt elvileg egy kis odafigyeléssel lehetett volna úgy használni úgy, hogy a felhasználóra bízzuk az ablakaktivitás kezelését, de ez szinte lehetetlen mivel a lejátszó minden egyes vezérlőutasításnál aktívvá teszi magát, ezen felül ha aktivizálom az egyik ablakhoz tartozó billentyűzetfigyelést, akkor a másik hibaüzenetekkel kezd dobni. Így végül maradt a mostani kezelőfelületes megoldás.
7.1.7. Hardver és szoftverkövetelmények Hardver szempontjából sajnos a minél jobb teljesítményű gép használata az ajánlott. Jelen dolgozat írásakor egy kétmagos 64 bites AMD processzort, 2 giga RAM-ot és 512 MB dedikált memóriás ATI videokártyát használok, egy ilyen paraméterekkel rendelkező számítógép ma már általánosnak mondható. A folyamatos javítások és optimalizálásoknak köszönhetően ezen a gépen ha (még) nem is kifogástalanul, de kielégítő minőségben fut a lejátszás. A későbbi javításokkal ez csak javulni fog.
33
Mivel a renderelés OpenGL-re van állítva, ajánlott az olyan videokártya használata amely hardveresen támogatja az OpenGL-t. Persze legrosszabb esetben az OpenGL szoftveres implementációja minden számítógépen adott. A szoftvert notebookon fejlesztettem, ezért a képernyőfelbontás (1366x768) jelenleg ehhez van igazítva. Tesztelés közben azonban kiderült, hogy nagyobb csatornaszám esetén ez a felbontás már nem elegendő, így jelenleg egy asztali számítógép monitorjához kezdtem el igazítani a felbontást (1600x1200). Ebben a felbontásban a csatornák már szépen eloszlanak vertikálisan is. Magától értetődően a program használatához a MatLab keretrendszer szükséges. Az utolsó verziót MatLab R2009b alatt fejlesztettem és teszteltem. Lehetőség szerint érdemes mindig a legfrissebb keretrendszert használni, mivel azt folyamatosan optimalizálják. Ez kiváltképp igaz a grafikára és a rohamosan fejlődő párhuzamos programozásra és a többprocesszoros hardverek kihasználására. A szoftver egy fontos komponense a Windows Media Player. A jelenleg 12-es verziónál tartó szoftverből nem mindegy hogy melyik van telepítve. Egy fontos funkciót valamiért nem minden verzió kezel ugyanúgy. Amikor a kijelzőn a data cursort használjuk, és rákattintunk egy pontra, akkor szándékom szerint a videónak az adott framre kell ugrania. Ilyenkor minden lejátszó az időben valóban arra a pontra teker, de pár verzió nem jeleníti meg az adott framet csak a play-re kattintás után. Ez kellemetlen hisz ez a program egy hasznos funkciója lenne. Érdekes hogy a 10-es verziónál ez nem működik, a 11-esnél igen és 12-esnál megint csak nem. Ezek alapján a 11-es verzió használata szükséges. Operációsrendszerként jelenleg Windows7-et használok és minden tökéletesen működik. Korábban XP-t használtam és az is problémamentes volt. Ellenben Vista alatt a Media Player nem működött, teljesen kifagyott. Lehetséges hogy a Windows MediaCenter volt a hiba forrása, de én mindenképp az XP-t vagy 7-et ajánlok és a MediaPlayer 11-es verzióját. Végül még a DivX codec meglétére is szükség van, mivel a videofelvételek ezzel vannak tömörítve.
7.1.8. Értékelés, további fejlesztési lehetőségek A lejátszó program a kezdeti (mondhatni használhatatlan) verziókhoz képest nagyon sokat fejlődött, jelenleg használhatónak tartom. Azonban úgy érzem még nagyon sokat lehetne javítani rajta (és több hétköznapi használatot nehezítő bug vár kijavításra). Nekem nagyon nem tetszik a magas hardverigény, mely leginkább a MatLab interpretált/script nyelv mivoltából fakad. Rég óta tervezem, hogy az egész programot átültetem C++ (esetleg java) nyelvre, hiszen azokkal sokkal optimálisabb programokat lehet fejleszteni. Az eddig
34
összegyült tapasztalatok alapján ez nem lenne olyan nehéz, azonban idő hiányában a diplomáig erre már nem kerül sor. Jelenleg azon dolgozom hogy a szoftver egy nagyobb képernyő felbontáson fusson, ezzel javítva a csatornák átláthatóságát. Attól függetlenül hogy több további javítani való akad még a szoftveren, úgy érzem kihoztam a maximumot a MatLab által nyújtott keretekből és ha nem is tökéletes, de használható eszközt sikerült elkészítenem.
35
7.2 A VIDEÓ-EEG FELVEVŐ 7.2.1. Célja Az eddig tárgyalt lejátszórendszer mit sem ér a szükséges felvételeket előállító felvevőrendszer hiányában. Célja az eddig látott cnt fájlok és a hozzá tartozó videofájlok szinkron rögzítése. A lejátszórendszerrel ellenben itt nem csak szoftveres hanem hardveres megvalósítás is szükséges volt. A szoftveres részhez már volt egy létező cnt felvevő eszköz, mely konzulensem munkája, így volt egy kiindulási alapom. A hardveres részhez viszont ugyancsak az alapoktól kellett építkeznem és megtalálnom egy megvalósítási módot.
7.2.2 Kritériumok Az feladat megoldására többféle megoldás is felmerült. Fontos kritériumokat kellett figyelembe vennem, hogy dönthessünk a végleges megoldásról. A rendszer hardveres részét tulajdonképpen teljesen a nulláról kellett kezdeni, a tervezéstől a vásárláson át az implementálásig. A tervezés során több olyan kritériumot kellett teljesíteni ami meghatározta a végül megvásárolt komponenseket.
•
A rendszer ellenőrizhetően szinkronban vegyen fel videó és EEG jelet. A videón eltelt időnek tökéletesen egyeznie kell az elvezetésen eltelt idővel, különben a párhuzamos vizsgálat/lejátszás lehetetlenné válik.
•
Integrálható legyen a most használatban levő rendszerbe, ne kelljen egy teljesen új rendszert kiépíteni és megvásárolni.
•
A rendszer később bővíthető legyen egyéb funkciókkal (lásd később)
•
A kor technikai fejlettségének megfelelő legyen, elemzésre alkalmas minőségű felvételeink készüljenek, évek múlva is megfeleljen a minőségi elvárásoknak.
36
7.2.3. Hardver 7.2.3.1. Feltárt megoldási lehetőségek és elemzésük A tudományos ill. ipari videófelvevő és képbeolvasó rendszerek hardver szempontjából általában két komponensből állnak össze. Egy kamerából, (melyből igen sokféle szabvány létezik) és egy ún. frame grabber-ből mely a kamera jelét digitalizálja és olvassa be az őt használó szoftver protokolljának megfelelően. Tervezés során a két legfontosabb szempont a szinkronitás biztosítása és a már létező rendszerbe való integrálhatóság volt. A második szempontot figyelembe véve már az elején egyértelmű volt, hogy csak valamilyen National Instrument (NI) támogatta megoldás jöhet szóba. Frame grabberek terén a fent említett cég széles skálán kínálja termékeit. Más gyártók is kínálnak hasonló eszközöket, de mivel fontos hogy a kártyát LabVIEW-ban kezelni tudjuk, a legegyszerűbb megoldás mindenképp egy NI kártya volt. A gyártó honlapján különböző megoldások és rendszerek közül kellett válogatni és dönteni egy adott szabvány mellett. A frame grabberek és kamerák legtöbb esetben elválaszthatatlanak egymástól. Csoportosítani többféle képen lehet őket, főleg a ki és bemenő jelük alapján. A számítógépbe való csatlakozás szempontjából pl. PCI, PCIexpress, USB és FireWire megoldások léteznek. A kamera kimenő videojele alapján még több szabvány közül kellett választanunk. Ezek a lehetőségek: analóg (hagyományos coax kábeles), IEEE 1394 (ismertebb nevén: FireWire), GigE Vision (Gigabit Ethernet), Camera Link és USB. Az analóg jel mellett leginkább az szólhat, hogy könnyű hozzá kamerát szerezni, sőt a laborban rég óta van is egy, megfigyelés céljából. Bár egyszerűbb feladatokhoz megfelelő, ez a technika már nem nevezhető 21. századinak. Nem lehet vele nagy fps értéket elérni (vagy ha igen, akkor az speciális kamera) és sokkal kevesebb opciót kínál (belső memória, ROI stb). Az IEEE 1394 avagy FireWire technológia már sokkal modernebb. A FireWire csatlakozóval ellátott számítógépekhez nem is szükséges frame grabber. De pont ez az egyik legnagyobb hátránya, hogy frame grabber hiányában nehéz más adatbeolvasó eszközzel szinkronizálni. A GigE Vision egy eléggé új ethernet alapú rendszer, hatalmas elméleti sávszélességgel (125MB/s) és akár 100m-es kábelhosszal. Mivel új technológia, még kevés kamera létezik hozzá és azok is drágák, és nincs is szükségünk ekkora teljesítményre, sávszélességre és kábelhosszra. Az USB rendszerű kamerák is szóba jöttek a tervezés során, azonban ezeket már a legelején elvetettük, és más laboratóriumok is óvtak használatától. Mindazonáltal nagyon jó tulajdonsága hogy olcsó. Az egyik legnagyobb hátránya, hogy egészen 2009-ig nem támogatta a LabVIEW, ezenkívül nagyon rossz a képminősége és szinkronizációja is nehézkes, egyszóval komolyabb tudományos alkalmazásokhoz jelenleg elégtelen. Arra viszont kiválóan megfelelt, hogy elsajátítsam a képbeolvasási és videórögzítési technikák alapjait saját
37
számítógépemen is. Az utolsó lehetőség (melyet mi is választottunk) az ún. Camara Link-es rendszer. Ez a kifejezetten tudományos és ipari megoldásokhoz fejlesztett technológia rendkívül rugalmas, és a legnagyobb sávszélességet nyújtja (bár ez számunkra lényegtelen). Frame grabber szükséges hozzá, viszont ha a frame grabber rendelkezik ún. RTSI busszal, akkor azon keresztül szinkronizálható is. A rendszer paramétereit természetesen később még részletesen kifejtem. A megvizsgált kamerarendszerek számosított összehasonlítása:
(forrás: http://zone.ni.com/devzone/cda/tut/p/id/5386)
•
Throughput – Képátviteli sebesség
•
Effective cost – A teljes rendszer ára (kamera, framgrabber, kábelek, szoftver)
•
Cable length – Erősítő (ismétlők) nélkül használható maximális kábelhossz
•
Standardized interface – a használt interfész minősége összevetve jövőbeli használhatóságával és a használat egyszerűségével (pl. 'plug and play')
•
Power over cable – A kamera buszán keresztül táplálható-e az eszköz, azaz szükséges-e külön tápegység
•
Camera availability – A kamerarendszer elérhetősége, a gyártott típusának mennyisége (pl. több rendszer már évtizedek óta jelen van, míg van ami csak pár éves így nehezebben elérhető)
•
CPU usage – A CPU használatának mértéke a képbeolvasás alatt
•
I/O synchronization – más eszközökkel való szinkronizálhatóság mértéke
38
7.2.3.2. Komponensek leírása 7.2.3.2.1 A frame grabber Hosszú mérlegelés után választásunk végül az NI-PCIe 1427-es számú Camera Link-es frame grabber kártyára esett. A legfontosabb mellette szóló érvek: •
az egyik legolcsóbb ilyen típusú (nincs szükségünk nagy extrákra),
•
rendelkezik RTSI busszal,
•
Camera Link szabványú,
•
új termék, a kor igényeinek megfelelő.
Az RTSI a „Real-Time System Integration” rövidítése és egy szabvány kommunikációs csatorna a National
12. ábra: NI-PCIe 1427
Instruments kártyák között. Ha a kártyákat összekötjük ezen az RTSI buszon keresztül, akkor azok képesek egy eszközként működni. A kártyák így valós időben képesek adatokat cserélni és ez kifejezetten arra használatos, hogy összeszinkronizálja az eszközök működését, alapvetően közös órajelet használva. Ezen kívül lehetőség van például arra is hogy az egyik adatakvizíciót egy másik adatakvizícióval triggereljük.
13. ábra: A PC-be behelyezett frame grabber. Alul a két darab azonos A/D kártya találhat az RTSI busszal összekötve, felette a frame grabber ugyancsak RTSI busz kapcsolódási lehetőséggel. Mivel az EEG jelek beolvasására is egy olyan NI A/D kártyát használunk ami rendelkezik RTSI busszal, ezért az EEG és képbeolvasást szükség esetén tökéletesen egymáshoz tudjuk időzíteni. Sok esetben már két A/D kártyát használunk egyszerre az EEG-hez a nagy csatornaszám miatt, és ezeket is már RTSI buszon keresztül szinkronizáljuk.
39
7.2.3.2.2. A kamera A kártya kiválasztása közben párhuzamosan az ehhez való kamera keresését is megkezdtük. A választásnál leginkább arra kellett figyelnünk hogy 'Camera Link' szabványú legyen, a következő paraméter szinte már csak az ár volt. Az ilyen típusú kamerákat sokszor extrém feladatokhoz készítik, de mivel nekünk nincs szükségünk nagy felbontásra és extra magas fps-re se, ezért a legolcsóbb kategória is bőven megfelelt célunkra. Hosszas keresgélés és árajánlatkérések
14. ábra: A megfigyelőszobára irányított kamera. Maga a vásárolt hardver a mozgatható állványon található rózsaszín doboz, melyre az optika rá van szerelve
után a választás végül a svájci Photonfocus cég MV-D640C-66-os típusú kamerájára esett. A kamera színes CMOS szenzorral rendelkezik és a képeket ún. „Area scan” módon olvassa be. Ez azt jelenti, hogy az összes pixelt egyszerre olvassa ki, ellentétben a „line scan”-nel, ami soronként. Az area scan azért lehet hasznos mert, ha valami nagyon gyorsan mozgó dolgot szeretnénk felvenni, akkor előfordulhat, hogy a pixelsorok olvasása közben is jelentősen elmozdul az objektum (persze nekünk erre valószínűleg nem lesz szükségünk). Maximális felbontása 640x480 pixel, ami nem sok, de a célnak tökéletesen megfelel, ezenkívül maximálisan 200 kép/másodperces (fps) felvételre képes. A viszonylagos nagy fps érték tulajdonképpen túlzó számunkra, de ha már rendelkezésünkre áll, később egyéb ezt kihasználó kísérleteket is végrehajthatunk majd. Ez a kamera nem csak kimenő jelekkel rendelkezik. A Camera Link szabványnak köszönhetően a kábelen keresztül kommunikálhatunk is az eszközzel, akár felvétel közben is állíthatunk paramétereket. Ehhez a gyártó honlapjáról letölthető egy kis program mellyel hardver szinten bele tudunk nyúlni a kamerába. A PFRemote névre hallgató kis programmal nem csak az akvizíciós paramétereket állíthatjuk, hanem meggyőződhetünk a kamera állapotáról is. Az egyik legfontosabb állítható paraméter az 'exposure time' avagy exponálási idő. Ez az az időmennyiség ami rendelkezésre áll a szenzornak ahhoz hogy fényt gyűjtsön össze és állítson össze belőle egy framet. Ez két dolgot is befolyásol. Egyrészt minél több ideje van fényt begyüjteni, annál világosabb és részletgazdagabb lesz a kép, másrészt minél több időbe telik egy képkocka előállítása, annál kevesebb lesz a videó fps értéke. Ha például 25 fps értékű videót akarunk készíteni ez az érték nem mehet 40 ms alá.
40
Mivel ezek a kamerák főképp ipari alkalmazásokra lettek fejlesztve, nagymértékű megvilágítást igényelnek. Esetünkben ez a kísérleti állatok nyugalma érdekében nehezen kivitelezhető, így erősíteni kell a jelet ami viszont nagyobb zajt eredményez (lásd később).
15. ábra: A PFRemote kezelőprogram felületének részlete, melyen például az expozíciós idót lehet állítani
16. ábra: A kezelőfelület egy másik része ahol pl. a színek erősítése állítható
7.2.3.3. Hardver installáció A hardver telepítése többé-kevésbé egyszerű volt. A frame grabbert behelyeztük az alaplap PCIe foglalatába majd telepítettük a Vision Acquisition szoftvert, végül a Measurement and Automation (MAX) eszközkezelővel ellenőriztük működését. A kamerát csatlakoztattuk a Camera Link kábel segítségével a kártyához majd a gyártó honlapján lévő speciális driver-rel (camera config fájl) beregisztráltuk a kamerát az NI rendszerbe. Így most már a kamera és a frame grabber is használatra kész állapotba került, és megkezdődhetett a szoftveres fejlesztés. A laborban eredetileg is volt egy analóg megfigyelő kamera, mely a kísérleti szobára irányult. Az új kamera ennek a helyére került. Bár optikát is vettünk a kamerához, az intézetben rábukkantunk pár jó minőségű kompatibilis teleobjektívre is. Az objektív zoom funkciója nagyon hasznosnak bizonyult, például alvásvizsgálatkor ráközelíthetünk a REM fázisban alvó alanyra, hogy közelről is megfigyelhessük a fázis jeleit mint bajusz, szem vagy farok mozgást.
41
7.2.4. A Szoftver A frame grabber és kamera önmagukban használhatatlanok, kell hozzájuk egy szoftver ami vezérli őket és kiolvassa, feldolgozza az adatfolyamot. Ezt a szoftvert LabVIEW környezetben valósítottam meg, hiszen pont ezért vettünk National Instruments terméket. Mint fent említettem a végleges szoftver feladata, hogy szinkron mód vegyen fel EEG jeleket a már meglévő A/D kártyákról, és rögzítsen videót az új frame grabberen keresztül. Az egész fejlesztéshez előbb alaposan át kellett néznem és megértenem a már meglévő adatbeolvasó szoftvert. Ez a program konzulensem munkája és ezt vettem alapul saját szoftveremnek is, ami nagy segítséget nyújtott mert a feladat szoftveres oldalát nem kellett teljesen a nulláról kezdenem, és rengeteget tanultam belőle. 7.2.4.1. Funkciók és használatuk, a GUI bemutatása
17. ábra: A felvevőrendszer felhasználói felülete LabView környezetben. Bal oldalon a kísérleti szoba élőképe látható ami a felvételre is kerül. Jobbra pedig az eddig is megszokott agyi elektromos jeleket megjelenítő felület található (itt éppen nem éles kísérlet zajlik, így csak az 50Hz-es hálózati zaj látható) Az egyszerűség kedvéért a gui kezelőfelülete nagyon hasonlít az eredeti videó-nélküli felületre. A szoftvert pont ugyanúgy kell használni mint az eredeti verziót is, a videofelvétel automatikusan és párhuzamosan kerül rögzítésre. Mivel a lejátszó fájlnév egyezés alapján nyitja meg a videofájlt, itt is elég csak a cnt fájl nevét kiválasztani és a videó automatikusan ezen a néven mentődik el. A kijelző leginkább abban különbözik, hogy az agyi elektromos jeleket megjelenítő ablak mellé egy videomegjelenítő ablak is került. Felvétel közben így
42
élőben láthatjuk a kísérleti szobában zajló eseményeket, és hogy mi kerül rögzítésre. A kezelőfelületen még megtalálható pár tesztelést segítő kezelőfelület is, melyek a végleges verzióban már nem láthatóak (pl. Bayer-szűrő minta, színerősítések, lásd később).
7.2.4.2. A program felépítése Az EEG felvevőrendszer a LabVIEW adatbeolvasó szoftvermodulját, a Data Acquisition-t (DAQ) használja mely teljes hozzáférést és támogatást nyújt az A/D kártyákhoz. Az felvevő működésének lényege itt is egy „végtelen” ciklus, ami minden iterációban egy fix méretű ('samples to read') adatcsomagokat olvas be a kártyára bemenő csatornákról, ahova befutnak a felerősített agyi elektromos jelek az elektródról. A mintavételezési frekvenciát a szoftveren belül be lehet állítani, melynek sztenderd értéke 20 kHz. Az EEG felvevőrendszer működésének lényegi része viszonylag egyszerű. Ami az egészet bonyolulttá teszi az a sok megírt egyéb funkció és inicializáló beállítás, mint a beolvasott jelek animált kirajzolása vagy a jel hangkimenetre küldése. A fent említett cnt file-ok legenerálása is, aminek „header”-jének és „footer”-ének legenerálása aprólékos feladat, továbbá a beolvasott adatokon több típusátalakítást is eszközölni kellett mielőtt azokat fájlba írjuk. Fontos kritérium az adatfolyam folytonossága. Mivel az adatok egy ciklusban olvasódnak be, elméletileg előfordulhat, hogy két iteráció között „hézag” jelenik meg az adatfolyamban arra az időre amíg a ciklus a végrehajtása az elejére ugrik. Ez régen problémát is jelentett, de az újabb DAQ szoftververzióknál már nem, és garantált az adatolvasás folytonossága. Ezt a tulajdonságot később ki is használom a szinkronizációhoz. Mivel a hardver beszerzése sok időbe telt, volt időm könyveket, fórumokat olvasni a témával kapcsolatban, így amikor az alkatrészek végre megérkeztek viszonylag rövid idő alatt sikerült összeállítanom a rendszert. A frame grabber mellé megkaptuk a LabVIEW Vision Acquisition programcsomagját mely kifejezetten az ilyen típusú kártyák használatához szükséges komponenseket tartalmazza és felépítésében nagyon hasonlít a Data Aquisition-höz. LabVIEW-ban általában minden adatakvizíció hasonlóan működik. Először is egy új folyamatot kell inicializálni és megadni az akvizíciós paramétereket. Ha ez kész, a beolvasás folyamatosan futhat (ez a rész szerepel a ciklusban). Végül a folyamatot le kell zárni és kezelni az esetleges hibákat.
43
A már meglévő EEG felvevő szoftver első ránézésre számomra kicsit bonyolultnak tűnt, ezért nem fogtam bele azonnal a videofelvételi funkció beépítésébe, hanem egy teljesen új vi-on kezdetem el lépésről lépésre kipróbálni a szükséges funkciókat. Először csak inicializáltam a kamarát és kitettem egy kijelzőt amin a videojelet lehetett megtekinteni. Ezek után elkezdetem a fájlba való mentést próbálgatni. LabVIEW-ban alapvetően az avi fájlba való mentés a támogatott. Az avi fájl létrehozásakor az egyik legfontosabb paraméter a videó fps értéke, azaz hogy lejátszás közben hány kép jelenik meg egy másodperc alatt. Ez az információ a lejátszó számára fontos, hiszen annak tudnia kell, hogy milyen sebességgel kell lejátszania a videót. Ebből következőleg a legfontosabb kritérium, hogy ha egy avi fájl definiálásakor megadunk egy fps értéket, akkor azt „kötelességünk” is olyan sebességgel felvenni. Ugyanis például ha megadtuk, hogy 25 fps-es az avi fájl akkor ha valamely okból kifolyólag (pl. lassú hardver) csak 20 fps-el veszünk fel, egy felgyorsult, nem real-time videót kapunk eredményül, mert a lejátszó azt olvassa ki hogy neki ezt a videót 25 fps-el kell lejátszania. A lejátszó csak teszi a dolgát nem tudhatja, hogy mennyi volt a tényleges felvételi sebesség. Természetesen a változó sebességű felvétel se megengedett. Ezt a pontos időzítést elérni nem olyan könnyű feladat, mindenképp szükséges valamilyen garantáltan és megbízható órajel vagy trigger jel. A videofelvétel is (mint az adatakvizíció) egy nagy ciklusban történik. Ebben a ciklusban minden iterációban beolvasunk a kamerából egy képet és hozzáírjuk a létrehozott avi fájlhoz mint következő framet. Ha semmilyen kontrollt nem teszünk a ciklusba akkor elméletileg a 18. ábra: Az adatakvizíció paraméterit beállító felület (pl. mintavételezési ráta, el, ami a kameránkban megközelítőleg 200 fps. samples to read, fizikai csatorna neve, stb.) hardver határainak megfelelő sebességet érünk
A gyakorlat meg is közelítette ezt az értéket, és csak azért nem lett pontosan ennyi mert más hardvertényezők is befolyásolják a felvétel sebességét, de átlagban kijött a várt 200 fps. Miután ezeket a dolgokat kitapasztaltam, betettem egy késleltetést a ciklusba, hogy egy körülbelüli 25 fps értéket érjek el. Időzítés szempontjából kulcsfontosságú a beolvasó ciklus egy iterációjához szükséges idő. Mint ahogy várható volt, az előbb említett késleltetés nem is működött tökéletesen hiszen a ciklus „sebességét” nem csak a beépített késleltetés befolyásolja, hanem egyéb folyamatok is. Mindenesetre arra jó volt hogy tesztelhessem az avi fájlba való mentést. Az első felvételek készítése közben egy újabb probléma merült fel. Az elkészült videofájlok hatalmasak lettek. Mindössze egy percnyi kb. 25 fps-es videó 270 megabyte-os lett.
44
Bár laborunk amúgy is nagyméretű mérési eredményeket tartalmazó fájlokkal dolgozik (a 20 kHz-en mintavételezett cnt fájlok gigás méretűek is lehetnek) mindenképp szerettem volna valahogy redukálni a fájlméretet. Szerencsémre ez LabVIEW-ban igen egyszerűen megoldható volt. Egy kis kutatás után kiderült, hogy az avi fájl definiálásakor meg lehet adni paraméterként egy szöveges konstanst, konkrétan egy videótömörítő codecet nevét. Természetesen csak olyan codeceket lehet megadni amik be van regisztrálva (telepítve vannak) az operációs rendszerbe. Elterjedtsége és ingyenes volta miatt a DivX codec mellett döntöttem, ami hatalmas mértékben redukálta a videók méretét. Kicsit féltem, hogy vajon ez a tömörítés mennyire veszi igénybe az amúgy leterhelt memóriát és CPU-t, de szerencsére ez nem okozott gondot. A codec az előbb említett 270 megás fájlt mindössze 7 megabyte-ra tömítette össze (!). A DivX tömörítés algoritmusából adódóan a tömörítés mértéke nem állandó, függ a videó részletgazdagságától, de legrosszabb esetben is nagyságrendileg kisebb fájlméreteket eredményezett. A kis méretű videónak köszönhetően ma már a legtöbb kísérletről videofelvétel is készül, hiszen mérete eltörpül a cnt fájlokhoz képest, és semmilyen plusz feladatot nem ró a felvételt végrehajtó személyre. Ezek a videók akkor is hasznosnak lehetnek ha épp nem olyan kísérletről van szó amihez videó szükséges, hiszen segítségével esetleges egyéb hasznos információk mentődik el a kísérletről ill. lefolyásáról. Az elemi funkciók kipróbálása után kezdtem el a videofelvételt összeépíteni az EEG felvevővel. Kicsit izgalmas volt a dolog, hiszen egyszerre kellett használni a két különböző NI kártyát, és ez néha gondot tud okozni. Egy esetleges anomália, hiba csak akkor fog kiderülni ha már a teljes rendszer kész lesz. Mint említettem a legfontosabb követelmény a szinkronitás betartása volt. Mivel mindkét adatbeolvasás alapvetően egy ciklusra épül, ezért a két funkciót egy nagy ciklusba olvasztottam össze. DAQ-nál garantált a szünetmentes adatbeolvasás a megadott mintavételezési frekvencián, így könnyen kiszámolható a ciklus „sebessége”. A DAQ adatbeolvasás egyik fontos paramétere, az egy beolvasás alatt beolvasott pontok száma ('samples to read'). Itt az alapérték 200 mintapont csatornánkként. Ha a mintavételezés 20 kHz-en zajlik és a ciklus egy iterációban 200 pontot olvas be, az azt jelenti, hogy a ciklus úgymond 100 Hz-el fut. Más szóval egy másodperc alatt százszor olvas be 200 pont hosszúságú adatcsomagokat. Ami ebből a legfontosabb hogy ez az érték garantáltan ennyi és nem változik a mérés során (ha mégis, akkor „timeout” hibaüzenetet kapunk). Ezek a beállítások pont szerencsések számomra hiszen ha 25 fps-es videót szeretnék készíteni akkor nincs más dolgom minthogy minden negyedik iterációban olvasok be egy képet. Ez az egyszerű megoldás azért jó mert garantált a konstans sebességű felvétel és mindez megfelelően szinkronban is történik. Igaz hogy a minden negyedik iteráción belül nem tudjuk pontosan, hogy a beolvasott 200 pont közül pontosan melyikekre esik a kép beolvasása, de mivel a két mintavételezés között nagyságrendi különbség van (20 kHz vs. 25 Hz), ez olyan
45
kis mértékű esetleges eltérés ami nem okoz gondot. Az avi fájl fps paraméterének egésznek kell lennie és emberi szem számára folytonosnak (25 körüli), ha például más mintavételezési frekvenciát szeretnénk használni, találni kell egy olyan másik számot amivel leosztva a mintavételezési frekvenciát egy egész számot kapunk.
19. ábra: A felvevőrendszer lelke, az adatbeolvasást végző ciklus. A belső kis feltétel azt vizsgálja hogy az adott iterációs lépés indexe osztható-e néggyel. Ha igen, akkor végrehajtja a frame beolvasást és beleírja azt az avi fájlba. Ez az egész azt jelenti hogy képet csak minden negyedik iterációban olvasunk be (részletes magyarázat a szövegben) Ez a módszer egyszerű és tökéletesen funkcionál. Mindazonáltal nem tartom végleges megoldásnak. Egyrészt mert nem használja ki a frame grabber adta lehetőségeket, ugyanis az igazi megoldás az lenne a későbbiekben ha az RTSI buszon keresztül közös órajellel működne a mintavételezés, vagy például az adatakvizíció triggereli a képbeolvasást. Másrészt az a probléma is adódhat ezzel a megoldással, hogy találni kell egy megfelelő számhármas beállítást. Gyakorlatban ez eddig nem jelentett problémát, a mostani fix beállítások tökéletesen megfelelnek. Ebben a számhármasban a mintavételezési ráta ami változhat, de szerencsére a 20 kHz-es mintavételezés a sztenderd és nem valószínű hogy ezen változtatni kell a jövőben. Az így adódó 25 fps pedig ugyancsak tökéletesen megfelelő érték.
46
20. ábra: A valósidejűség tesztelése. A felvétel alanyául szolgáló óra és a róla készült felvétel. A vártnak megfelelően a két másodpercmutató tíz percen át szinkronban mozgott Mindattól függetlenül hogy a DAQ időzítése garantálja a videó időzítését is, muszáj volt valahogy kipróbálnom a dolgot, és a gyakorlatban is bizonyítani helyességét. Ehhez egy analóg zsebórát hívtam segítségül. Egyszerűen készítettem egy 10 perces felvételt magáról az óráról. Ezek után az órát felakasztottam a monitorra, és amikor annak másodpercmutatója elérte az egészet elindítottam a videót is. Eredményként a 10 perces felvétel alatt a monitoron lévő és a videón lévő másodpercmutatók mindvégig szinkronban mozogtak. Úgy érzem ezzel a kísérlettel sikerült bizonyítanom, hogy valóban real-time sikerült felvenni a videót. A felvétel valósidejűségét és szinkron tulajdonságát az is kiválóan bizonyítja, hogy a videó hossza tökéletesen megegyezik a cnt fájl hosszával. Az előző ábrán is látható volt, hogy az első videók szürkeárnyalatosak és kicsit rácsozottak voltak (lásd 20-as ábra). Ezzel sokáig nem foglalkoztam, azt gondoltam, hogy csak valami egyszerű beállítás miatt ilyen a kép, és idő híján nem foglalkoztam a vele. Egy véletlen beszélgetés közben azonban kiderült, hogy korántsem erről van szó. A kamera egy ún. Bayer szűrőt használ. Ez a technika nagyon elterjedt, azonban nem vesszük észre, mivel ennek kezelését általában helyettünk megoldják. A technika lényege, hogy a szenzor minden egyes pixelje 21. ábra: A Bayer-szűrő egyik fajta elrendezése elé meghatározott mintában egy színszűrőt helyeznek el, ami csak adott színtartományban engedi át a fényt.
47
Az adott pixelhez tartozó RGB értéket a környező pixelek segítségével számíthatjuk ki a következőképpen. Adott a Bayer szűrő mintája kilenc pixelre és ezeknek a pixeleknek az RGB értéke, a középen lévő pixel RGB értékét így számolhatjuk ki: RGR GBG RGR
->
200 50 220 60 100 62 196 58 198
R=(200+220+196+198)/4=203 G=(50+60+62+58)/4=58 B=100
vagyis (203,58,100) Ezzel a kódolással egy pixel értékét így 8 bittel is kódolni tudjuk (24 helyett) így kisebb sávszélesség szükséges, ellenben számolást igényel a megjelenítésnél ami terhelheti a CPU-t. Mikor kiderült, hogy megjelenítésnél ezzel a problémával is foglalkoznom kell és hogy még további erőforrásokat igényelhet, kicsit megijedtem. Szerencsémre a LabVIEW erre is nyújtott megoldást. A Vision Acquisition szoftvercsomag tartalmaz kifejezetten a kamera jeléből származó jel dekódolására alkalmas Bayer szűrőt ('debayering'), így azt csak el kellett helyeznem és megadnom a paramétereket. Ez a szűrő nem helyben számolja ki az értékeket, hanem inicializáláskor felépít egy ún. lookup table-t. Ennek lényege, hogy ha véges értékkészletű (pl. fix bites RGB) és gyakran ismétlődő adatokkal dolgozunk, akkor nem kell minden műveletet újra kiszámolni, hanem az adott értékhez tartozó megoldást csak ki kell keresni a táblázatból. Ez a műveleti időt nagyságrendekkel csökkenti. A táblázat felépítéséhez szükséges paraméterek: bayer mintázat, a színek erősítése, egy pixel értékéhez szükséges bitek száma (Bit Depth). Így igen egyszerűen és hatékonyan sikerült végre színes képet is kihozni a kamerából.
7.2.4.3. Felvetődött problémák és megoldásuk A felvevőrendszerben egyetlen egy, de annál idegesítőbb problémával kellett megküzdeni. Felvétel közben néha minden előjel nélkül lefagyott a rendszer és egy olyan nehezen megfejthető hibaüzenetet kaptunk, hogy növeljük meg a kártyák pufferméretét. A hiba attól volt nagyon kellemetlen hogy csak a teljes számítógép újraindításával sikerült újra használhatóvá tenni a rendszert. A hiba se a LabVIEW, se a kártyák resetelésével és 'selftest”jével nem volt orvosolható. Ez a probléma akkor következett be garantáltan, ha valamilyen más szoftvert is el kezdtünk futtatni a számítógépen (szövegszerkesztő, Neuroscan, stb), azonban spontán is jelentkezett. A hiba valószínűleg valóban abból adódhatott, hogy a rendszernek nem volt elég ideje arra, hogy az átmeneti tárolóból (puffer) kiolvassa az adatokat, mert nagyon le volt terhelve, mivel itt is mint a lejátszónál sok erőforrást használ a rendszer. A megoldást végül az akvizíciós paraméterek „próbálgatásos” átállítgatásával értük
48
el. A fent említett számhármasban (mintavételezés, adatcsomag hossz, osztó) az egy olvasás alatti csomaghossz megváltoztatása hozta a legjobb eredményt. Az eddigi 200 mintapont/secet 400 mintapont/sec-re változtattuk. Ez persze azt jelenti, hogy a cikluson belüli osztót felére kell venni, azaz kettőre-re (mivel úgymond a ciklus 'sebessége' felére csökkent). Egy másik kisebb probléma a kép minőségének gyengesége. Mint fent említettem a kamerának nagy fényerő van szüksége, ez viszonyt az állatok nyugalma érdekében nem lehetséges. Erre egy megoldás a színcsatornák erősítése, azonban ezek a gyakorlatban sok zajt eredményeztek. Ezenfelül a videót az teszi még rosszabb minőségűvé, hogy a DivX-es tömörítés mértéke túl nagy, és tömörítésnél a zajok még jobban kiemelődnek. Ebben az esetben dönteni kell, hogy inkább egy sötétebb videót választunk vagy egy zajosabbat, természetesen a paraméterek állítgatásával még lehet finomítgatni az eredményen, és még szeretnék a javítani a minőségen a továbbiakban.
7.2.5. Hardver és szoftverkövetelmények Sajnos itt is az erősebb hardver megléte az ajánlott. Az eredeti felvevőprogramhoz is erős számítógépekre volt szükség. A felvétek közben a számítógépnek nagyon sok feladata van: •
elektromos jelek beolvasás és fájlba írása nagy mintavételezési frekvencián
•
videojel olvasása, kijelzése és
•
valós idejű DivX tömörítése
•
Bayer szűrő alkalmazása
A fejlesztésnél a LabVIEW 8.6-os verzióját használtam. Mivel ez a környezet igen érzékeny a verziók közti különbségekre, a szoftvert csak ezen a verzión való futtatását javaslom (természetesen könnyen átmenthető más verziókhoz is). Fontos hogy telepítve legyen a legfrissebb DivX codec a tömörítés végett. Mivel a codec más-más operációs rendszeren és más-más verziókban szerepel, a felvevő első futtatása elött pontosan meg kell adni a codec aktuális nevét az avi inicializációs részben, majd elmenteni a vi-t (erre segítséget ad az IMAQ AVI Get Filter Names VI). Mivel mind az A/D kártyához, mind a frame grabberhez mellékelték a drivereket és akvizíciós modulokat (DAQ, IMAQ), ezért azok meglétével valószínűleg nem kell foglalkozni.
49
7.2.6. Értékelés, további fejlesztési lehetőségek A felvevőrendszer fejlesztése a vártnál gyorsabban és jól sikerült. Az hardver beszerzése közben volt időm tervezni ill. leírásokat tanulmányozni, így az eszközök kézhezvétele után pár hét alatt sikerült használható verziót elkészítenem. A rendszerben nincs semmilyen komolyabb hiba vagy javítanivaló, már hétköznapi használatban alkalmazzák a Pszichológiai Kutatóintézetben és az intézeten belül más kutatócsoport is érdeklődik iránta. Bár említettem hogy az USB kamerás rendszert az elején több okból is elvetettük, azonban olcsósága mégis arra sarkal, hogy foglalkozzak vele. Jelenleg azzal próbálkozom, hogy a drága kamerarendszert sikerüljön olcsóbb USB kamerás alternatívával kiváltani. A dolog nem tűnik reménytelennek, mivel sok fejlesztő szeretné ha a LabVIEW támogatná ezen kamerákat, ezenkívül sikerült jó minőségű kamerákat is fellelnem. Ezen kívül egy másik fejleszthető dolog, a DivX-es tömörítés minőségének javítása lenne. Ennél a tömörítésnél elméletileg megadható lenne a tömörítés mértéke, ami sokat javítana a képminőségen (persze kissé növelné a fájlméretet). Erre azonban még nem sikerült rájönnöm miként lehetséges, de attól félek hogy csak a codec fizetős verziójában elérhető. Végül még egy hasznos funkció igénye is felmerült, a hang felvétele. A kísérleti állatoknak küldött hangokhoz külön csatornák tartoznak, melyek ugyanúgy mentésre kerülnek. Ugyanakkor hasznos lenne ha a kísérleteket szóban kommentálni is lehetne. Mivel a videó hangsávja jelenleg üres így oda valószínűleg el tudjuk későbbiekben menteni, a lejátszó pedig eredendően képes a videó hangsávját is lejátszani.
50
7.3 RENDSZERDEMONSTRÁCIÓ, ALVÁSVIZSGÁLAT 7.3.1. Bevezető Az alvás miértjét és működését a mai napig sok rejtély és kérdés öleli körül. Alvás közben több pszichológiai, fiziológiai változás megy végbe idegrendszerünkben és testünkben. Ezek megismerése, kutatása egyik kiemelkedő területe a pszichofiziológiának. A Pszichológiai Kutatóintézetben is rég óta folynak kutatások e területen, szerteágazó témában. Mint korábban említettem, a munkám nagyon praktikus és hasznos lehet az ilyen kutatásokban, és emiatt volt már rég óta szükség egy ilyen rendszerre. Az alvást a ciklikusság jellemzi és ezek a ciklusok több elkülöníthető fázisra bonthatóak. A fázisok tulajdonságai mind az elektromos jeleken, mind az alany alvás közbeni viselkedésében megfigyelhetőek. Fontos megemlíteni, hogy ezen fázisok és tulajdonságaik humán és kísérleti állatokban másmás mértékben eltérhetnek, továbbá hogy a mesterséges altatás mennyire hozható párhuzamba a természetesen alvással, ezek önmagukban is külön kutatási témáknak tekinthetőek. A humán alvásnak 4+1 féle fázisát különböztethetjük meg. A négy fázis egyre mélyülő alvásnak felel meg. Az első rövid fázist inkább csak szendergésnek nevezhetjük mintsem alvásnak, és erre a fázisra az alvást megelőző alfa hullámok (8-12 Hz) csökkenése ill. rövid théta hullámok (4-7 Hz) megjelenése a jellemző. Mivel itt még felszínes az alvás, az alany könnyen felébreszthető. A második fázisban megjelennek az ún. alvási orsók, továbbá az EEG a théta ill. delta (0,5-3,5 Hz) tartományba kezd eltolódni. A harmadik fázis már közép-mély alvásnak tekinthető, az EEG egyre inkább egy nagyobb amplitúdójú és lassabb delta tartományba esik. A negyedik stádium a mélyalvás (a hármas is annak tekinthető, de a négyes a mélyebb). Ebben a fázisban a nagy amplitúdójú delta hullámok a jellemzőek, továbbá itt figyelhetőek meg a leglassúbb (0,2-1 Hz) potenciálváltozások, melyet lassú oszcillációnak hívunk (lassú hullámú alvás, slow wave sleep, SWS). Az egyik terminológia szerint a lassú hullámok depolarizációs fázisát „up-state”-nek, míg a hiperpolarizációs fázist „down-state”nek hívjuk. A négy fázis során az izomtónus fokozatosan csökken és végül a szemmozgások is megszűnnek. A harmadik és negyedik fázisból az alany csak erős ingerre ébreszthető fel. A negyedik fázis után a sorozat újra, de visszafelé megint lejátszódik. Az ez után következő fázis gyökeresen eltér az eddigiektől. Az EEG deszinkronizálódik (eltűnnek a jól definiálható hullámok) és egy éber állapothoz hasonlítható EEG jel lesz látható. A gyors szemmozgásról elnevezett REM (Rapid Eye Movements) fázist, izom, különösen végtag rángások jellemzik. Ez a fázis köthető álmodáshoz, mely összefüggésben lehet a szem és végtag mozgásokkal.
51
22. ábra: Egy a tipikus EEG jeleket jól ábrázoló grafikon (hipnogram), melyen jól látható a négy fázisok egymásutánisága ill. az azokat megszakító REM fázisok. (A kép forrása: http://www.soundersleep.com/uploads/EEG%20hypnogram.gif)
7.3.2. A kísérlet, setup ismertetése A demonstrációhoz egy krónikus elektródákkal beültetett macska állt rendelkezésemre, melyet több más kísérlethez is használnak. Ilyen krónikus macskákat viszonylag ritkán implantálnak, mert a beültetés után hónapokig, sőt évekig képesek rendelkezésre állni. Az állatok az elektródákat és hozzájuk kapcsolódó alkatrészeket meglepően gyorsan megszokják, és teljesen természetesen viselkednek, ezzel kiváló alanyként szolgálnak a kísérletekhez.
7.3.3. A '224'-es macska A '224'-es macska elektródjainak elrendezését úgy tervezték meg, hogy a hallókéreg alvás alatti működését vizsgálják, mint például azt hogy alvás közben a hallás mint szenzoros input miként dolgozódik fel, ill. milyen hatásai vannak a szenzoros inputnak az alvásra. Természetesen ez a kérdéskör ennél sokkal bonyolultabb és én csak tesztelés illetve demonstrációs célból használtam fel a belőle származó mérési eredményeket. A macskával kapcsolatos kísérletekhez a felvételek már az új rendszerrel készültek. Ez volt első alkalom, hogy élesben is használatba került a munkám. Persze értelemszerűen számos olyan kísérlet is zajlik amihez szükségtelen a videó funkció (pl. akut kísérletek), így az eredeti felvevőrendszer is használatban van.
52
A 224-es macskából 48 csatorna jelét dolgozzuk fel, melyekből több csatorna nem agyi elektromos jelenségeket, hanem például izom és szemmozgás regisztrál. Ezekre azért van szükség, hogy valamilyen módon a viselkedés is rögzítve legyen a cnt fájlban (a videó részben ezt válthatja ki). Ezen kívül még két trigger csatornát is kapott, melyeken keresztül hangingereket kap. Az elektródák egyik fele lakkszigetelt acéldrót, melyek helyeit egy mátrixban elrendezett megvezető csőrendszer jelöli ki. A csatornák másik fele egy fent említett 24 csatornás rétegelektród jeleit vezetik el. Az csatornák kiosztása a következő: 1-8: bal oldali hallókéreg 9-15: jobb oldali hallókéreg 16: jobb motoros kéreg 17: bal oldali látókéreg 18: vertex 19-20: jobb hippokampusz 21-22: szemmozgás regisztráció 23: nyakizom mozgás regisztráció 24: 1-es trigger 25-47: hallókérgi rétegelektróda 48: 2-es trigger
7.3.4. Példák a mérésből Az következőkben felsorolt példák pár jellemző alvási és ébrenléti fázist mutatnak be. Mivel itt macskáról van szó, a négy alvási fázis nehezebben elkülöníthető ill. nincs meg hozzá a megfelelő tapasztalatom hogy megkülönböztessem őket. Továbbá a macska alvási szokásai is eltérnek az emberétől, a fázisok gyakran keverednek. Az alvás három fázisát különböztettem meg ill. egy éber állapotot. A képek alatt a mérési eredményt tartalmazó cnt fájl neve olvasható ill. a kép időpontja. Az itt felsorolt cnt fájlok megtalálhatóak a mellékelt adathordozón.
53
Éber:
224_2010_03_18_07.cnt @00:29, A macska épp tisztálkodik, megfigyelhető az elvezetett szem és izommozgás. Felszínes alvás:
224_2010_03_04_01.cnt @ 02:33, alvási orsók láthatóak ~2:33-2:40
54
Mély alvás, SWS:
224_2010_03_18_07.cnt @ 07:39, SWS: ~7:37-40, 9:04-10, 9:47-50, 12:58-13:15 lassú hullámok, up-down state-ek REM:
224_2010_03_04_14.cnt @ 02:13, A képen sajnos nem, de a videón gyönyörűen láthatóak a bajusz, fül ill. farokvég mozgások ill. a szemhéj mozgása is.
55
8. ÖSSZEFOGLALÁS
A szemeszterek során fokozatosan jutottam el ehhez a végső szakdolgozathoz. A dolgozat tartalma felöleli és összegzi az eddigi munkásságomat. A diplomaterv témabejelentőben felsorolt feladatokat amennyire lehet véghez vittem. Feladatom a sokcsatornás extracelluláris elvezetés megismerése és az eddig tárgyalt videó-EEG felvevő és lejátszórendszer elkészítése volt Miután megismerkedtem a kísérlettekkel és az eszközökkel, elsőként a lejátszó szoftvert kezdtem el fejleszteni. Amikor ez kezdett alakot ölteni, konzulensemmel nekiláttunk a felvevőrendszer megtervezéshez, mely az elején leginkább a kritériumok megfogalmazásáról szólt. Úgy érzem hogy a felvevőrendszer jól sikerült, mi több aktív használatba is került. A lejátszórendszerrel igazság szerint sok problémám volt és bár a mostani verzió használhatónak mondható, még korántsem tökéletes. Jelenleg a maradék időmet az államvizsgára és lejátszórendszer véglegesítésének szentelem. A félévek során sok új elméleti és gyakorlati ismeretre tettem szert. A laboratóriumokban megismerhettem az előadásokon hallott kísérleteket a gyakorlatban is, és programozási ismereteimet is kibővíthettem. Ezen kívül a felhasznált hardverkomponensek kiválasztásából és a beüzemeléséből is sokat tanultam. A felvevőrendszer hardvere még több kiaknázatlan lehetőséget tartogathat.
56
9. KÖSZÖNETNYÍLVÁNÍTÁS Ezúton szeretném megköszönni az egyetem és a labor több oktatójának illetve munkatársának a munkámhoz nyújtott segítségét. Tihanyi Attila tanár úrnak, aki kapcsolatai révén segített megvásárolni az eszközöket és ajánlott egy magyar kamerákkal foglalkozó céget. Feldhoffer Gergelynek aki felvilágosított a Bayer szűrőkkel kapcsolatban. Csercsa Richárdnak a cnt fájlokhoz nyújtott segítségéért, és az utolsó fejezethez nyújtott segítségét. Természetesen konzulensemnek Ulbert Istvánnak és Karmos Györgynek, továbbá az Elektrofiziológia Laboratórium minden munkatársának akik segítségemre voltak.
57
10. IRODALOMJEGYZÉK Cristopher G. Relf [2004]: „Image Acquisition and Processing with LabVIEW”, CRC PRESS, ISBN 0-8493-1480-1 Rick Bitter, Taqi Mohiuddin, Matt Nawrocki [2007]: „LabVIEW Advanced Programming Techniques”, CRC PRESS, ISBN 0-8493-3325-3 Dr. Karmos György [2001]: „Kognitív folyamatokat tükröző eseményhez-kötött potenciálok agykérgi mechanizmusai”, Magyar Pszichológiai Szemle, 2001, LVI. 2. 239-262 Stoyan Gisbert [2005]: „MATLAB”, TypoTEX, ISBN 963 9548 49 9 Photonfocus MV-D640 Series (CMOS Area Scan Camera) User Manual National Instruments PCIe-1427 User Manual George Paxinos, Charles Watson [1998]: „The Rat Brain”, Academic Press Ltd, ISBN 0-12547617-5 Vladyslav V. Vyazovskiy, Umberto Olcese, Yaniv M. Lazimy, Ugo Faraguna, Steve K. Esser, Justin C. Williams, Chiara Cirelli, Giulio Tononi [2009]: „Cortical Firing and Sleep Homeostasis”, Cell Press/Neuron 63, 865-878 Photonfocus AG. [2005]: PFRemote Documentation Mérési jegyzőkönyvek (cat_224) http://www.mathworks.com (részletes help szolgáltatás, MatLab példaprogramok, tutorial-ok) http://msdn.microsoft.com/ (Dokumentációk a Windows Media Player AxtiveX control-hoz) http://zone.ni.com/dzhp/app/main (LabVIEW és National Instruments eszközdokumentációk, segédletek) http://hu.wikipedia.org/wiki/ActiveX http://elektrofiz.itk.ppke.hu/ (Az Elektrofiziológia Labor honlapja) Elektrofiziológia mérések és protézisek I. előadásjegyzetek
58
11. MELLÉKLETEK A mellékelt DVD tartalma: •
a szakdolgozat elektromos példánya
•
a felvevőrendszer szoftvere, ACQ_Dual_6259_VIDEO mappa
•
a lejátszórendszer szoftvere, SyncPlayer mappa
•
demonstrációs felvételek, melyek a felvevőrendszer készültek és megtekinthetőek a lejátszó szoftverrel, Cat_224 mappa
59
