A demó változó sebességgel halad. Két hete még úgy láttam, hogy nem lesz különösebb akadálya annak, hogy befejezzem az alkotást, de valami közbeszólt. Úgy hívják valóság. Rengeteg olyasmit kellett csinálnom, aminek semmi köze számítógépekhez, ettől a demóra fordítható idő nagyon lecsökkent. Még továbbra is úgy gondolom, hogy el fogok készülni, de szűkös a határidő.

A másik probléma, hogy úgy tűnik nem Linuxon fog futni. Az egész úgy kezdődött, hogy biztosítottak egy gépet, amiben egy Ati Radeon HD4850 teljesít szolgálatot. A hivatalos papír szerint a kártya ismeri az OpenGL 3.2-t. Már jó ideje 4-es verzióval foglalkozom csak, ezért nagy morogva átírtam a shadereket és a kódot 3.2-re. Igazából a nagy munka a layout-ok kiszedése volt, amivel meghatároztam, melyik vertex buffer tartalmazza a poligonok csúcsait, melyek a normálokat, illetve a textúrát. Én ugyanis szeretek minél több irányítást átadni a shadereknek, hogy a kód egyszerűbb legyen.

Ráadásul 32 bites Debiánt akarnak használni, ezért az egyszerűség kedvéért én is telepítettem egyet és azon fordítottam. Küldtem is egy félig kész mintadarabot a szervezőknek, hogy lássák, megy-e a compó gépen. Természetesen nem ment. Újabb levélváltások után a program hibaüzeneteit is megkaptam: nincs renderbuffer, nincs geometry shader, nincs semmi, ami egy kicsit is emlékeztetne arra, hogy már 2.1-nél magasabb OpenGL verziószámmal van dolgunk. A lehetőségek: odaadom nekik az én videokártyámat, de akkor azt party végéig nem látom. Elviszem az egész gépet, vagy fordítok Windowsra. Nincs kedvem cipelni semmi feleslegeset, ezért fordítok Windowsra.

A másik meglepetés az volt, hogy Grass készített egy pár modellt, de a textúrák egyes helyeken rosszul álltak. Mivel OBJ formátumot használunk (szöveges állomány), egy grep segítségével azonnal láttam, hogy a gond az, hogy több textúra koordináta van, mint csúcspont. Az OBJ betöltőm viszont úgy működött, hogy betöltötte a csúcspontokat, ezeket tekintette alapnak, és a textúra koordináták számát úgy állította be, hogy megegyezzen a csúcspontok számával. Itt viszont pont ellentétes volt a helyzet. A csúcspontok számát kellett megnövelni. A kód kijavítása után minden szépen jelent meg.

Még egy fontos adalék: a demóban lesz fraktál is.

A munka halad, még rengeteg tennivaló van és a valóság minden mesterkedése ellenére be fogom fejezni. (Vagy nem)

Bármennyire is jó egy alternatív platform, a rá való fejlesztés gyakran könnyebb egy PC-n, amit az ember gyakran használ. Ha a PC teljesítménye esetleg sokszorosa a másik gépnek, akkor érdemes elgondolkodni a keresztplatformos fejlesztésen.

Az Efika nem egy teljesítmény bajnok, de nem is ezért szeretjük. A rajta futó MorphOS fejlesztőkörnyezete GCC-t tartalmaz, amit hibái ellenére azért is szeretünk, mert szabadon elérhető a forrása és így ideális eszköz egy keresztplatformos fejlesztéshez.

Sajnos a helyzet nem ilyen egyszerű, ezt mindenki megmondhatja, aki próbált már kézzel fordítani GCC-t, binutils-t és a többi hozzá tartozó eszközt. Szerencsére a MorphOS fejlesztőcsapat adott ki egy szkriptet, amivel ezek a lépések nagyban leegyszerűsíthetőek. Sajnos dokumentáció nincs hozzá, ezért leírom, mit kell tenni, hogy ez a szkript lefusson. A teszteket Debian Wheezy 32 bites verzióján végeztem.

Valószínű 64 bites Linuxon is meg lehet oldani a feladatot, de sokkal bonyolultabban, ezért én 32 bites rendszert javaslok. Lássuk a hozzávalókat:

1db szkript: http://bigfoot.morphos-team.net/files/setup-cross-sdk.sh

4db utility: flex, bison, texinfo, lhasa

1db fordító: gcc 4.6

1db könyvtár a PATHban: /gg/bin (a könyvtárat nem kell létrehozni, csak a bejegyzést)

1db könyvtár: /gg

1 db MorphOS SDK és annak forrása: http://morphos-team.net/files/sdk-20130129.lha és http://morphos-team.net/files/src/sdk/sdk-source-20130129.tar.xz

Hozzunk létre egy tetszőleges könyvtárat, másoljuk bele a setup-cross-sdk.sh szkriptet, az sdk-t és az sdk forrását. Készítsünk egy gg könyvtárat a gyökérben, a chmod-al legyünk mi a tulajdonosai. Ne felejtsünk el írási jogot adni a könyvtárra.

Adjunk futási jogokat a setup-cross-sdk.sh szkriptnek, és indítsuk el. Hagyjuk fordítani negyed órán keresztül és végül elkészül a friss, ropogós keresztplatformos fordító. Tálaljuk a saját kényelmünket megkönnyítő symlinkekkel.

Idén is összegyűltek a számítógépek szerelmese, hogy összemérjék erejüket különböző viadalokon. Volt robot párbaj, számítógépes játékok és természetesen demoparti is. Jelen poszt erről az utolsó mérkőzésről fog szólni.

Nekem a legnagyobb öröm, hogy látom visszatérni Maxont a HBC-ből, aki korábbi tevékenységéhez képest csak egy képpel jelentkezett, de nem kell elégedetlennek lenni. Most egy kép, később egy egész wild. Az erős mezőny miatt 13-ik lett. Nem csoda, hiszen igen komoly ellenfelekkel kellett megkűzdenie.

A zenék eddig nagyon tetszettek. A lejátszási listámban is túlnyomó többségében Assemblyről származó zenék vannak. Idén gyengébb volt a felhozatal, nem is fog bővülni a gyűjteményem. Számítottam valami kellemesre Aikapallotól, de csalódnom kellett. Maga a zene nem volt rossz, de hiányzott belőle a tűz.

A Tekotuotanto csapatról két dolgot kell tudni. Ez az egyetlen csapat, akinek csak másolni tudom a nevét, leírni nem. Kimondani pedig soha nem is próbáltam. A másik, hogy szinte csak wildot készítenek. Idén megpróbáltak egy 4k-t is, ami olyan jól sikerült, hogy elvitték vele az első helyet. Filmük ismét poénos volt, még ha nem is nevettem magam könnyesre. A robotos film is érdekes volt, talán lehetett volna ez az első.

Demók terén már nem láttuk azt a színvonalat, amit az előző években megtapasztalhattunk. Néhány demó annyira gyenge volt, hogy akár én is programozhattam volna. A nyertes Return nem volt rossz alkotás, de hiányzott belőle az összhang. A jelenetek valahogy nem alkottak egészet számomra. Fórumokon kifogásolták a nagy fájlméretet, mások az árnyékok hiányát. Szerintem ezeken az apróságokon túl lehet jutni, ha a bemutatott történet egészet alkot.

Természetesen agyatlan hardverekre tervezett demókból sem volt hiány. Az Androidra írt releasek szóra sem érdemesek, hiszen van rá SDK, fejlesztőkörnyezet, meg oktatási anyagok netszerte. Egy metró kijelzőn viszont még nem láttunk demót. Eddig.

Összességében az idei Assembly nem volt eget rengető. Volt néhány érdekes produkció, de nem tartom valószínűnek, hogy bármelyiket is megnézem másodszor.

Az alkotások megtekinthetőek itt és itt.

Mi, férfiak nem sírunk. Legfeljebb akkor engedhetünk meg magunknak könnyeket, ha a szellemchilis szendvicsünket véletlenül wasabival öblítjük le, de ilyenkor is inkább azt mondjuk, hogy homok ment a szemünkbe. Nők esetében ez teljesen másképp van.

Nemrég három síró nőt is vígasztalhattam egy nap. Az első a kislányom volt, ennek megfelelően ez ment a legkönnyebben. Felvettem, simiztem egy kicsit és már meg is nyugodott. A második a feleségem volt, aki azért sírt, mert a gyerek sírt. Ölelés, simizés. Megmutattam, hogy már nem sír a gyerek, nincs semmi problémája. Nem, én sem tudom, mi volt a baja, de most már jól van.

Bár szabadságon voltam, azért bementem a melóhelyre, nehogy újabb 10000x10000-es képeket hozzanak létre, vagy más módon omlasszák össze az infrastruktúrát. Észrevettem, hogy az asszisztens nagyon szótlan. Mikor végeztem az adminisztrációval, megkérdezte, tudnék-e neki segíteni. Azt válaszoltam: igen.

Megbízták egy egyszerű feladattal, az UEA Small RNA Workbench különböző táblázatos eredményeit kellett volna összefésülnie. A feladat annyiból nem volt triviális, hogy a két táblázat közös metszete a kisRNS-ek szekvenciái voltak.

Mondtam neki, hogy vannak patman futásból eredményeim, amiket felhasználhat. A patman produkálja a legprimitívebb illesztési eredményt, amit valaha láttam: kereső szekvencia azonosíója, találat, orientáció, illesztés kezdete, illesztés vége, eltérések száma. Mindezt tabulátorral elválasztva.

- Azokat nem tudom használni. Hogyan dolgozzam fel a fájlokat? - itt kezdtek folyni a könnyei.

- Írsz egy Perl szkriptet. A split paranccsal kinyered az oszlopokat...

- Én nem tudok Perl-ben programozni, csak Bash-ban.

- Semmi gond, awk-al kinyered az oszlopokat és grep-el megkeresed a másik táblázatban a hozzá tartozó értéket. Kicsit lassabb lesz, mintha Perl-ben csinálnád, de működni fog.

Ezután nagy sírás közepette elmondta, hogy úgysem lesz jó, mert őt mindig csak bántják, mert elront dolgokat. Ráadásul ideje sincs rá, mert még két másik dolgot kellene csinálnia.

Amennyire tőlem telt, elmondtam, hogy a hibák felderítése az akadémia világában nem személyes ügy, hanem a megismerést szolgálja. Mindannyian hibázunk, de ha mások rámutatnak erre, akkor igyekezzünk tanulni belőle, és ne személyeskedésnek vegyük.

Úgy tűnik, a mondandóm nem segített. Másnap írt a főnökének, hogy a feladatot nem tudja megcsinálni, és csinálja meg vagy ő, vagy valaki más.

Gondos tervezés, precíz időbeosztás, megfeszített munka. Ezek szükségesek, hogy időben elkészüljön egy demo a kitűzött partira. Amennyiben bármelyik is hiányzik, jön a tartalék terv. Esetleg a tartalék terv B változata. Az ütemtervet figyelve és Grassal beszélve úgy láttuk, hogy nem fog Function-re elkészülni a várva várt produkció. Üres kézzel mégsem mehetünk, ezért nekiláttunk ötletelni, mi az, amit meg is tudunk valósítani és nem is tűnik összecsapottnak.

Első lépésben kiválasztottam a zenét Shamen DVD-jéről. Már korábban összeírtam azokat a zenéket, amelyek elindítottak bennem valamilyen képzettársítást, most csak meg kellett keresnem, mert a címére nem emlékeztem. Egyhuzamban meghallgattam 4-5 ször, hogy teljesen átérezzem és kialakuljanak valami homályos képek arról, mit is akarok látni.

Az új produkcióhoz az Antagonism motorját fogom felhasználni, mert jelenleg ez a legfejlettebb kódom. Továbbra is hiányzik belőle egy csomó funkció, de mi nem is vagyunk főállású játékengine fejlesztők. A kódból kipucoltam az ottmaradt teszt kódokat, majd áttekinthető formára hoztam. A GTK és egyéb könyvtárak fejlődtek egy keveset az elmúlt időszakban, ezért eltűntettem a sok fordítás során keletkező figyelmeztetést. Beépítettem a zenét, és élveztem, hogy a fekete képernyő ellenére van "valami".

Cinema4D-vel modelleztem egy hangyát, amit Grass feltextúrázott. Ő további modelleket is készített. A demómotor OBJ formátumot használ, így ebbe exportáltam a modelleket. Itt jött az első hidegzuhany. A teljes jelenet egyetlen modellbe került, a modelleket összemosta. Sajnos ez nem jó nekem, mert az egyes modellekre különböző effekteket akarok pakolni.

A kísérleti állapotban lévő és a nagyratörő Cybernetic Export Plugin nevet viselő bővítményt elkezdtem kiegészíteni egy olyan funcióval, hogy minden modellt külön fájlba írjon ki. Ez részben sikerült is, de egy számomra ismeretlen erő hatására bináris szutykot ír minden string elejére. Ezt majd meg kell oldani.

Közben rájöttem valamire. A demoscene 30-on túl már elsősorban nem is arról szól, hogy csináljunk valami eget rengetőt. Inkább arról, hogyan tudjuk úgy szervezni az életünket, hogy jusson idő erre a hobbira. Talán ez sokkal nagyobb művészet, mint megírni a világ legjobb demomotorját.

Ajánlottak nekünk egy egyetemi hallgatót, akinek a "második nyelve a programozás", hogy a nyári gyakorlatát nálunk töltse. Segítene nekünk a mindennapi feladatok megoldásában. A beszélgetések során értelmes ember benyomását keltette, aki dolgozott többek között a Mol-nál is. Volt néhány megvalósítandó ötletem, ezért elvállaltam a felügyeletét és azt, hogy készítek neki egy munkatervet, de a mindennapi ügyek mellett ennek jó része elmaradt.

Még két hét volt vissza az érkezéséig, amikor szóltak nekem, hogy vegyem fel vele a kapcsolatot, mert ha mi nem csapunk le erre a zsenire, akkor máshova megy dolgozni és akkor mi egész életünkre sajnálhatjuk az elszalasztott lehetőséget. Ráaásul a bérezését is meg kell beszélni. Állj! Pénzt kap? Javasoltam, hogy ez esetben teszteljük le, mire is képes. Természetesen a napi robot mellett a tesztelés elmaradt. (Woops)

Levélben megkérdeztem tőle, hogy milyen programozási nyelven szeretne dolgozni, milyen statisztikákat és algoritmusokat ismer. Azt írta, hogy C-ben szeretne kódolni, statisztikát alig ismer és például a hashekről még nem is hallott. Ez már kicsit gyanús volt, de gondoltam, majd itt megtanulja, amit kell.

Mivel eddig Windows alatt ügyködött, kapott egy gyorstalpalót Linux fejlesztésből. Mikor láttam, hogy ez nehéz lesz neki, kapott Midnight Commandert, KDevelopot, hogy ne érezze annyira egyedül magát a "Déli Sarkon", a pingvinek között.

Az első meglepetés akkor ért, amikor nem tudta, micsodák azok az include részek a C program elején.

- De megkérdeztem tőled, miben akarsz programozni? Azt mondtad, hogy C-ben.

- Én azt úgy értettem, milyen programozási nyelvekről hallottam. Pascalban programoztam (Woops), meg PLC-ben.

- Mi az a PLC? Még nem hallottam róla.

- Folyamatábrákon keresztül lehet programot írni. Össze kell kötni négyzeteket és abból lesz a program.

- Mint a Lego Mindstore-ban?

Végül is gyorsan belerázódott, a végén már a pointereket is értette, de valami megmagyarázhatatlan okból kifolyólag csak és kizárólag hátul tesztelős ciklusokat írt. Azt gondoltam, talán nem ismeri a for ciklust, de nem erről volt szó. Tulajdonképpen a maga nyakatekert, függvények nélküli, beégetett sztingekkel operáló kódjaival minden rá bízott feladatot megoldott, csak rossz volt nézni (meg debuggolni, mert azt többnyire én csináltam).

Nyár lévén én is szabadságra akartam menni, és sokat gondolkodtam azon, milyen feladatot adjak neki, amit a jelenlétem nélkül is tud végezni. Vagy legalábbis meg tudja keresni a választ a felmerülő kérdésekre. Ekkor gondoltam először a Java-ra. Nincsenek furcsa pointerek, nem kell a memóriaszivárgás miatt aggódni, ráadásul a net tele van a legtipikusabb Java hibák megoldásával. Az Eclipse pedig olyan, mint egy pelenka. Bármi kerül bele, megbírkózik vele. És itt nem csak a kék tintára gondolok.

A másik ok, ami miatt a Java mellett döntöttem, hogy egy olyan alkalmazásra volt szükség, ami képet generál, lehetőleg keresztplatformos módon. Már volt Java kódom, ami png-t generált, ezért azt is odaadtam, amolyan súgónak.

Fél nap elteltével szólt, hogy nem jelenik meg semmi, pedig ő mindent leírt, amit a kódomban talált. A rutin ránézésre tényleg jól volt megírva.

- Meghívod ezt a metódust? - mutattam a az egész program lelkét képező rajzoló rutinra.

- Persze, itt van. - ott viszont egy másik osztály metódusa volt, ugyan ilyen névvel. Kiderült, mikor valami hibát talált az Eclipse, az első javítási opcióra klikkelt annak elolvasása nélkül, ami a hiányzó metódus elkészítése volt. Nemsokára üres metódusokkal volt tele minden osztálya. Miután kigyomláltam a szemetet, már futott a program, készített png fájlt. De mikor meg akartuk nézni a végeredményt, a gép váratlanul lelassult, nekiállt swappelni. A halálán volt.

- Mekkora ez a kép? - kérdeztem, miután az egérmutató ismét mozgott a képernyőn.

- 10000 x 10000. Az nagynak számít?

- Nem szoktál letölteni képeket a netről? A nyolc megapixeles képek 3264 x 2448 felbontásúak. A képernyő, amin dolgozol, 1024 x 768-as.

Rámnézett, mint akinek ezek a számok továbbra sem mondanak semmit és csak ennyit mondott:

- Woops.

Az egyik nagy előnye, hogy az ember akadémiai kutatócsoport tagja, hogy hozzáférhet a NIIF szuperszámítógépeihez. A papíron leírt impozáns teljesítmény mutatók azonnal megdobogtatják egy magamfajta felhasználó szívét. Sajnos az örömbe sok üröm is keveredik, ha a tényleges felhasználásra kerül sor.

Regisztráció

A regisztrációs procedúra sokat egyszerűsödött, de márciusban, mikor a saját kérvényemet intéztem, ez kétfordulós meccs volt. Először projektszámot kellett igényelnem. Kitöltöttem egy papírt, aláírattam minden főnökömmel, akik igazolták, hogy én tényleg létezem, és tényleg kutató vagyok. Ezután még egyszer kitöltöttem egy nagyon hasonló papírt, ahol témaszámot igényeltem. A procedura nagyon hasonló volt. Kellett generálni egy ssh kulcsot és már kész is voltam.

Programok

A szuperszámítógépek használata hasonlít egy batyus lakodalomra: Étel-ital lesz elég, ha hoztok magatokkal. Szoftver lesz elég, ha fordítasz magadnak. Ez nem olyan problémás, egészen addig, amíg nem a függőségek függőségeit kell fordítani. Utána kicsit unalmassá válik. Én a Mira-t akartam futtatni, ezert felmásoltam egy statikusan linkelt binárist és azt használtam. Illetve próbáltam használni.

Üzemidő

Memória gondjaim voltak, ezért akartam a pécsi szuperszámítógépen dolgozni, de csak a kínlódás volt vele, ugyanis lépten-nyomon elérhetetlen volt a gép és a futó programok pedig elszálltak. Visszanéztem az ezzel kapcsolatos e-mailjeimet és az alapján készítettem ezt a grafikont:

Egy hetet nem tudott folyamatosan menni a pécsi gép. Szerintem annak idején a Windows 95 jobban teljesített, nem? Áttértem a szegedire, ahol viszont nem jutottam sorra. (Illetve az egyik kiesés alkalmával csak a futó jobok szálltak el, a várakozási sor nem ürült, amitől az élre tudtam törni). A másik igencsak frusztráló dolog a jobütemező, ahol az idő folyamán egyre több korlátozást vezettek be. Egyik alkalommal nem voltam elég figyelmes és a job futásának hosszabb időt adtam meg, mint amennyi a felső határ volt. Nem kaptam hibaüzenetet, nem kaptam figyelmeztetést, semmit. Annyi tűnt fel, hogy van üres node, de én továbbra is a várakozási sorban dekkolok.

Mikor végre sorra kerültem, gyanúsan lassan futott a Mira. Rövid nyomozás után kiderítettem, hogy a félelmetes memória, CPU és sávszélesség mellett az IO műveletek röhejesen lassúak. (Emlékeztetőül: A bioinformatikai programok nagy fájlokat olvasnak és írnak). Álljon itt egy cseppet sem mélyreható, gyors tesz, mire is képesek a szuperszámítógépek:

A tesztet a jó öreg dd-vel csináltam:

dd if=/dev/urandom of=fajl # iras teszt
dd if=/dev/sda of=/dev/null # olvasas teszt


A teszt nem túl szofisztikált, de a célnak megfelel (meg nem ártott volna néhány ismétlés, de annyit nem ér az egész). A deb egy nagyteljesítményű számítógép, ami nem a NIIF tulajdonában van.

Végszó

Sajnos semmi hasznosat nem tudtam kezdeni a hazai szuperszámítógépekkel. Végül úgy végeztem el a munkát, hogy lecsökkentettem a readek számát, hogy beleférjen 70GB memóriába, majd lefuttattam egy erre alkalmas gépen.

Amigát régen nem csak játékra használták, hanem munkára is. Annak ellenére, hogy mára ez a gép főleg hobbi célokat szolgál, akadnak fanatikusok, akik munkájukhoz is valamilyen Amigát, vagy újgenerációs leszármazottjainak egyikét használják.

Ilyen például LaySoft, aki PHP programozóként dolgozik, de a kódot MorphOS-en gépeli be, vagy Lázi, aki OS4 alatt Hollywooddal állít elő multimédiás tartalmakat. Ha nem is napi szinten, de nemrég én is munkára fogtam az Efikát.

Beszámolót kellett tartanom és a nagy nyári szabadságolás miatt nem tudtam szerezni laptopot. (Az igazsághoz hozzátartozik, hogy ha nagyon akartam volna, tudtam volna szerezni, de abból nem születik blogposzt.) Végül úgy döntöttem, az Efikára átmásolom az anyagot (néhány R-ben készült két volt az egész), majd bemutatom.

Az adatátvitel gond nélkül ment, mert MorphOS alatt van OpenSSH kliens, és bár van grafikus program hozzá, közönséges parancssorból is megy. A rendszergazda, aki a projektorért is felel, hitetlenkedve nézte, amint a VGA kábelt egy kis, fekete dobozhoz kötöm.

- Mi ez? - kérdezte. Csak egyet felelhettem rá.

- Számítógép.

A csoportvezető belépett a gyéren megvilágított irodába. A bútoroknak pont olyan áporodott szaga volt, mint hallgató korában. El gondolkodott rajta, bizonyára az az anyag, ami ilyen szagot bocsát ki, egyben tartósítja Don Emeritust is. Ez teszi lehetővé, hogy míg lediplomázott, elvégezte a PhD-t, csoportvezető lett az intézetben, addig Don Emeritus ugyan úgy ül itt, túl a nyugdíj korhatáron és kíméletlenül ontja a cikkeket, dönt pályázatok és kutatócsoportok sorsáról.

- Beszélni szerettél volna velem! - kezdte Don Emeritus. Kevés ideje volt, nem vesztegette udvarias fecsegésre.

- Igen, Don Emeritus - kezdte a csoportvezető, olyan hangon, mintha kollokviumra készülne. Maga is észrevette ezt. Megköszörülte a torkát, és sokkal magabiztosabban folytatta. - Kihagytak a bíráló bizottságból, amelyik dönt az új szuperszámítógép beszerzéséről. Csupa matematikus és agrármérnök alkotja, akik nem tudják, mire van szüksége egy bioinformatikusnak.

- Agrármérnökök? Ismered őket? - Don Emeritus lenézte más tudományterületek képviselőit, de az agrármérnökök számára nem is voltak tudósok.

- Gáspár Tamás, Hornay Béla...

- Hallottam róluk. Gyalázatos, alacsony impaktfaktorú cikkeket közölnek genetika címen. Egyetlen modern metódust sem ismernek. Számukra a genetika kimerül a szatelliták elemzésében.

- Ahogy mondod! Ugyanígy le akarják zülleszteni a bioinformatikát is.

- Mit akarsz, mit tegyek?

- Nyomást kellene gyakorolni rájuk.

- Hmm, Gáspár Tamás közös pályázatban van az egyik volt tanítványommal, aki azóta volt kint Németországban. Béla intézetének meg Toldai Zsolt a vezetője. Ő szinte már családtag, a lányom sógorának az unokatestvére. De ha beszélek velük, tisztában kell lenniük minden részlettel. Tudsz valakit még rajtad kívül, aki ért annyira a témához, hogy a bizottság tagja lehetne?

- Senki más! - gondolta a csoportvezető, de idejében visszafogta magát. - Vannak még egy páran...

- Értem - jegyeztem meg sokat sejtetően Don Emeritus. - Kérlek írd össze pár szóban a javaslataidat. Tudod, sok hasonló szívességnek kell eleget tennem. Van egy külön mappám rá.

Elérkeztünk OpenCV-t bemutató sorozatunk utolsó részéhez. Itt csak példákat szeretnék mutatni, mire is lehet használni ezt a programozói felületet. Sajnálatos módon az OpenCV C és C++-os felületei között jelentős különbségek vannak, ami abban is  megnyilvánul, hogy ha C++-ban programozunk, több algoritmust használhatunk. Ebben a fejezetben ezért csak C++-os példaprogramok lesznek.

Kontúr keresés

Első példánkban igyekszünk meghatározni egy képen a kontúrokat. A kontúr kereséshez a Canny metódust használjuk. Bemenetnek egycsatornás, 8 bites képet kell adnunk. A példaprogramban nem csak a képet jelenítjük meg, hanem két GUI elemet is, amivel az algoritmus paramétereit állítgatjuk. Az élkeresés hatékonyságát Gauss elmosással növeljük.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, gray;
  VideoCapture capture(0);
  bool run = true;
  int tb1 = 129, tb2 = 233;

  namedWindow("Edge", 0);
  createTrackbar("Tb1", "Edge", &tb1, 1000,0);
  createTrackbar("Tb2", "Edge", &tb2, 1000,0);

  while(run){
     capture >> raw;
     cvtColor(raw, gray, CV_BGR2GRAY);
     GaussianBlur(gray, gray, Size(7,7), 15, 15);
     Canny(gray, gray, tb1, tb2, 5, true);
     imshow("Edge", gray);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}


A GUI készítésénél vegyük észre, hogy minden elemet stringekkel azonosítunk és ugyancsak stringek segítségével határozzuk meg, melyik ablakon jelenjen meg. Ebben a példában csak egy ablakot hozunk létre "Edge" néven.

Háttér eltávolítás

Míg az előző példát akár C-ben is megírhattuk volna, ez a példa már olyan elemeket használ, amit csak C++-ban érhetünk el. A program megpróbálja a nyers képen elkülöníteni a hátteret az előtértől. Az előteret ezután elmentjük egy maszkba, amit felhasználunk arra, hogy a nyers képből az előteret átmásoljuk egy másik háttér elé. Ez a másik háttér egy időjárás térkép lesz. (Figyeljünk rá, hogy a webkamera képe és az új háttér ugyanolyan méretű legyen, mert a programban nincs méret korrekció.)

A háttér elválasztása nem működik teljesen pontosan, ez a program nem fog olyan minőséget produkálni, mint amit a TV csatornáknál megszokhattunk. Javaslom, hogy miután elindítottuk a programot, várjunk 5-10 másodpercet, mielőtt a kamera elé sétálunk, ennyi kell ugyanis, hogy "megtanulja", mi a háttér. A backgroundRatio mező segítségével állíthatjuk be, mennyire legyen az algoritmus precíz és gyors. Az árnyékok ugyancsak zavarhatják az algoritmust. Elméletileg az árnyékokat is felismeri, gyakorlatban nálam nem működött rendesen. A példaprogram paramétereivel játszunk nyugodtan.

#include <opencv2/opencv.hpp>

using namespace cv;

int main(int argc, char **argv){
  Mat raw, mask, background;
  VideoCapture capture(0);
  bool run = true;
  BackgroundSubtractorMOG2 subtract;

  subtract.nmixtures = 3;
  subtract.backgroundRatio = 0.01;
  namedWindow("Forecast", 0);
  // the image should be the same size as the cam image
  background = imread("magyarorszag.jpeg", CV_LOAD_IMAGE_COLOR);

  while(run){
     capture >> raw;

     // Create mask
     subtract.operator ()(raw, mask);
     erode(mask, mask, Mat());
     dilate(mask, mask, Mat());
     threshold(mask, mask, 40, 255, THRESH_BINARY);
     // use mask to substract foreground
     Mat tmp = background.clone();
     raw.copyTo(tmp, mask);
     imshow("Forecast", tmp);

     if(waitKey(30) > 0) run = 0;
  }

  return(0);
}




A példaprogramhoz felhasznált hátteret ide töltöttem:Objektum követés

Legvégére hagytam azt a programot, ami elindította ezt a sorozatot: Aha kiváltását. A feladat tehát az, hogy több képkockán keresztül követni kell két elemet, jelen esetünkben két kezet. Azért, hogy megkönnyítsük a dolgunkat, feltűnő színekkel jelöljük a követendő objektumokat. Ezután kiszűrjük csak ezt a színt és egy k-közép klaszterezéssel megállapítjuk a ponthalmaz közepét. Ha minden feltétel megfelelő, a klaszterek közepe a követni kívánt objektumokkal meg fog egyezni.

Mi ez a k-közép klaszterezés? Ez, mint a neve is mutatja, az adathalmazok csoportosítására használható. Az adathalmazoknak számszerű tulajdonságokkal kell rendelkezniük, ami a mi esetünkben a koordináták lesznek. Hátránya, hogy előre meg kell mondanunk, hány csoportra akarjuk bontani az adatainkat. A mi esetünkben ez nem probléma, mert tudjuk, hogy jó esetben két keze van az embernek. Az algoritmus ezután véletlenszerűen valamelyik csoportba osztja az adatokat, majd a kiszámolja a csoport középpontját (veszi a koordináták átlagát, innen a neve), majd megnézi, hogy más csoportból van-e közelebbi pont. Ha van, ez a pont is része lesz a csoportnak, és kezdődik egy új ciklus. Ha minden jól megy, ciklusról ciklusra egyre közelebbi pontok lesznek egy csoportban. Ha viszont zajos az adatunk, vagy rosszul választjuk meg a klaszterek számát, furcsa eredményeket kaphatunk. (Ahogy a bemutató videón is látni lehet majd)

Az algoritmus része az OpenCV-nek, ezért nem kell leprogramoznunk. Lássuk a kódot:

#include <opencv2/opencv.hpp>

#define CLUSTERNUM 8

using namespace cv;

int main(int argc, char **argv){
  Mat raw;
  Mat labels, centers(CLUSTERNUM, 2, CV_32FC2);
  VideoCapture capture(argv[1]);
  bool run = true;
  int lb1 = 0, lb2 = 100, lb3 = 100;
  int hb1 = 64, hb2 = 255, hb3 = 255;

  // Create windows
  namedWindow("Param", 0);
  namedWindow("Aha", 0);
  namedWindow("Filt", 0);
  createTrackbar("lb1", "Param", &lb1, 255, 0);
  createTrackbar("lb2", "Param", &lb2, 255, 0);
  createTrackbar("lb3", "Param", &lb3, 255, 0);

  createTrackbar("hb1", "Param", &hb1, 255, 0);
  createTrackbar("hb2", "Param", &hb2, 255, 0);
  createTrackbar("hb3", "Param", &hb3, 255, 0);

  while(run){
     capture >> raw;
     Mat filtered(raw.size(),CV_8U);
     inRange(raw, Scalar(lb1, lb2, lb3), Scalar(hb1, hb2, hb3), filtered);
     Mat dummy(filtered.rows * filtered.cols,2,CV_32F);
     int z = 0;
     for(int x = 0; x < filtered.rows; x++){
        for(int y = 0; y < filtered.cols; y++){
           if(filtered.at<uchar>(y,x) == 255){
              dummy.at<float>(z,0) = x;
              dummy.at<float>(z,1) = y;
              z++;
           }
        }
     }

     Mat points = dummy(Rect(0,0,2,z)); /* Reduce the image */

     // If the picture do not contains enough points, we can not make kmeans clustering
     if(z > CLUSTERNUM){
        kmeans(points, CLUSTERNUM, labels, TermCriteria(CV_TERMCRIT_EPS + CV_TERMCRIT_ITER, 10, 1.0), 3, KMEANS_PP_CENTERS, centers);
        for(int i = 0; i < CLUSTERNUM; i++){
           Point ipt = centers.at<Point2f>(i);
           circle(raw, ipt, 20, Scalar(0,0,255), CV_FILLED, CV_AA);
        }
     }

     imshow("Aha", raw);
     imshow("Filt", filtered);
     if(waitKey(30) >= 0) run = 0;
  }

  return(0);
}


A videóról beolvassuk a képkockákat, majd az inRange segítségével kiszűrjük azt a színtartományt, amire szükségünk van. A tartományok beállításához (minden színcsatornához egy tartományt lehet beállítani) a createTrackbar segítségével grafikus elemeket hozunk létre.

A kmeans parancs egy speciális mátrixot vár bemenetnek, ezért a szűrt képünket (filtered) ezekkel az ocsmány egymásba ágyazott ciklusokkal kell átalakítani. Ha erre valaki tud egy szebb módszert, az ne fogja vissza magát. De hogyan is néz ki ez a speciálist mátrix? Mindenképp CV_32F típusúnak kell lennie, és minden egyes sorban az adathalmaz egy elemének kell szerepelnie. (Tehát annyi sorunk lesz, ahány adatunk) Mivel a mi esetünkben két tulajdonsága van az adatoknak (X és Y koordináta), ezért a mátrixnak két oszlopa van.

A kmeans eredménye a centers változóban lesz. Utolsó lépésként megjelenítjük ezeket piros pöttyökkel. A lefordított program működés közben:

Remélem sok szép demó fog születni OpenCV felhasználásával.

Szerettem a tanulmányi versenyeket. A legtöbb meghírdetett versenyre elmentem, bár soha nem jutottam túl az iskolai fordulón. Nemrég megkért az egyik prof, hogy segítsek egy gimis srácnak felkészülni az IBO országos fordulójára.

Én csak az OKTV-ről hallottam, az IBO-ról soha, ezért elkezdtem némi információt gyűjteni róla. El is jutottam a régi feladatlapokhoz, és kíváncsian belelapoztam. A harmadik feladat után rá kellett jönnöm, hogy diploma, doktori ide vagy oda, ezen a versenyen bizony elvéreznék.

A gyakorlati résznél (mert ilyen is van) már határozottan ideges lettem. A versenyzőknek adnak mikroszkópot, tűt, szikét és egyéb kínzóeszközöket, felboncoltatnak velük valami bogarakat, majd papíron rajzolják fel a dögök törzsfáját UPGMA módszerrel. Ez még nem tűnik annyira vészesnek, de nem ártana némi ismétlés. Utána ugyan ezt el kell játszani néhány növénnyel, de a változatosság kedvéért Neighbor-joining módszerrel rajzoljanak törzsfát. Menjetek a fenébe - gondoltam. Mikor a végén valami koevolúciót kellett nézni a dögök és a gazok között, akkor döntöttem úgy, hogy ebből elég.

A felkészítés során a statisztikáról kellett beszélnem, amihez felhasználtam néhány Coursera-s kurzuson hallott példát, mert ott néha nagyon jól megvilágítják az okokat, míg a hazai oktatásban csak rálöncsölik a hallgatókra a képleteket, fogalmakat. Mint kiderült, ez jó ötlet volt.

Gondoltam faggatom kicsit a versenyről. Mint kiderült, ez egy elitista verseny, aki nem jutott tovább az OKTV második fordulóján, azt meghívást sem kap. A srác elmondta, hogy az a stratégiája, hogy olyan gyorsan végigmenni a teszteken, amennyire csak lehet, és csak arra válaszolni, amit gerincvelőből is tud. A gondolkodást a végére hagyja. Ha marad ideje, akkor alszik egy kicsit, de fél, hogy nem jut rá ideje, mert nagyon sok feladatot kapnak.

Kérdeztem tőle, miért kell aludni? Azt mondta, hogy a teszt után (ami három órás), este nyolc órakor lesz a gyakorlati rész, újabb két, két és fél óra hosszan. Este? Miért? Azért, hogy az állóképességet is igénybe vegyék.

Összegezzük: Van egy kegyetlenül nehéz feladatsor, amire egy átlagos középiskolásnak esélye sincs felkészülni. Ennek a srácnak is a fél kutatóintézet segített a felkészülésben. Ezekből a feladatokból adnak sokat, de azért nem kapnak annyi időt, hogy minden beleférjen. Az időpontot pedig úgy állítják be, hogy lehetőleg baromi fáradtak legyenek. Kérdem én, ennek mi értelme?

Az Olimpián sem látunk olyat, hogy az úszókat lovagpáncélba öltöztetik, mert ők már annyira profik. Kíváncsi lennék mit szólnának a 100 méteres síkfutás döntősei, ha rekortán helyett mondjuk folyós homokban küzdhetnének az aranyért.

De az is lehet, hogy én gondolom rosszul és ez a verseny kicsit másmilyen, ehhez hozzátartozik a "megperzselt föld".

Itt az ideje, hogy kicsit jobban nekiugorjunk és létrehozzuk első saját bővítményünket. Először egy kis elméleti tudnivaló következik, majd kódolhatunk is.

Könyvtárszerkezet

A bővítményünknek a Cinema 4D plugins könyvtárában kell lennie egy új alkönyvtárban. Itt fog majd elhelyezkedni a lefordított bővítmény. Rajta kívül egy res könyvtárra van még szükség, ami nevéből következően az erőforrásokat tartalmazza. Mik is ezek az erőforrások? Ikonok, többnyelvű szövegek, dialógus ablakok. Az ikonok, mint ahogy a példa kódnál is megfigyelhető, egyszerűen a res könyvtárban vannak. A fejléc állományok a descriptions alkönyvtárban vannak. A dialógus ablakok megjelenítéséhez a dialogs könyvtárba kell elhelyezni az erőforrásokat. A többnyelvű szövegek a strings_nyelv-ben kapnak helyet, ahol a nyelv a következő lehet: us, de, jp, fr, it, es.

Bővítmény típusok

A Cinema 4D bővítményei hurok típusúak, ami annyit tesz, hogy a kódunk a program futásának bizonyos eseményei során futnak le. Ilyen esemény lehet egy menüelem kiválasztása, egy jelenet renderelése vagy az exportálás. Lássuk, mik lehetnek ezek:

• Parancs plugin: Egy menüelem kiválasztásakor aktiválódik.
• Jelenet export: Új formátumba menthetjük a jelenetet
• Jelenet import: Eddig ismeretlen fájlt építhetünk a jelenetbe
• Kép export: Bitkép mentése
• Két import: Bitkép betöltő
• Tulajdonság plugin: Az objektumok új tulajdonságot kaphatnak segítségével
• Eszköz plugin: Új eszközt adthatunk a Cinema 4D-hez
• Modellező plugin: Új objektum módosító eszközt hozhatunk létre vele
• Animációs plugin: Egyedi idősávot hozhatunk létre
• Shader plugin: A megjelenítést módosíthatjuk vele
• Jelenet plugin: A jelenet újrarajzolásánál aktiválódik
• Video render plugin: A renderelésnél hozhatunk létre különböző effekteket
• Üzenet plugin: Más bővítmények üzeneteit dolgozhatjuk fel vele
• Csomópont plugin: Új csomópontot vehetünk fel vele
• Egyedi GUI elem: Új grafikus elemet hozhatunk létre
• Egyedi adattípus: A beépített adattípusokat egészíthetjük ki

Regisztráció

Minden bővítmény egy egyedi számmal rendelkezik. Egyedi számunkat a Maxontól kell igényelni. Az itt bemutatott bővítmények csak egy hasraütött számot tartalmaznak, tehát előfordulhat, hogy már regisztrálva vannak. Ha nem használunk más bővítményeket, akkor nem kell aggódnunk, hogy esetleg konfliktusba kerülünk más bővítményekkel, de ha az a tervünk, hogy kereskedelmi forgalomba értékesítjük, mindenképp egyedi azonosítóra lesz szükségünk.

Forráskód

Bizonyára ez a rész érdekel mindenkit. Minden bővítmény három függvényt tartalmaz: PluginStart, PluginEnd, PluginMessage.

#include "c4d.h"

Bool RegisterCGMenu();

Bool PluginStart(void){
        if(RegisterCGMenu() == FALSE) return FALSE;
        return TRUE;
}

void PluginEnd(){
}

Bool PluginMessage(LONG id, void *data){
        return FALSE;
}


A regisztrációt a PluginStart függvényben végezzük. Ha a regisztrációs sikeres, a bővítmény működni fog, ellenkező esetben kilép.

#include "c4d.h"

class CGMenu : public CommandData{
public:
        virtual Bool Execute(BaseDocument *doc);
};

Bool CGMenu::Execute(BaseDocument *doc){
        MessageDialog("My First Plugin");
        return true;
}

Bool RegisterCGMenu(){
        return RegisterCommandPlugin(1001999,"Hello World",0,AutoBitmap("cg.tiff"),String("hello"),gNew CGMenu);
}



Ez egy parancs plugin, amit a szülő osztály típusából állapíthatunk meg (CommandData). Egyetlen virtuális metódust tartalmaz, a parancs végrehatjását. Jelen pillanatban csupán egy üzenet ablakot jelenítünk meg egy egyszerű szöveggel. Végezetül a regisztráció mechanizmusát látjuk. Megadjuk az azonosítót, a menüben látható nevet, a bővítmény néhány tulajdonságát,  az ikont, a tooltip nevet, legvégül az osztályt, amit regisztrálni kívánunk.

Ha elkészítettük első bővítményünket, kísérletezzünk bátran a paraméterekkel. Nézzük meg a dokumentációban, mit jelentenek, majd tapasztaljuk ki hatásukat.

Bármilyen gondosan is fejlesztenek egy eszközt, mindig lesznek olyan funkciók, amelyeket a program nem fog támogatni. Halmozottan igaz ez olyan igények esetén, amire csak kevés embernek van szüksége. A demoscene pont ilyen. Kevés ember mozog benne, és nagyon speciális igényeik vannak.

Szerencsére a komolyabb alkalmazások támogatják, hogy a programozástól nem idegenkedő emberek az igényeiknek megfelelő bővítményekkel lássák el azt. Mai célunk a Cinema 4D demofejlesztő eszközzé alakítása lesz. (Folytatásos teleregény formájában). Az itt leírtak a 13-as verzióval való ismerkedésem folyamán születtek.

A program telepítése során a plugins könyvtárban van egy példa könyvtár (cinema4dsdk). Ha nem akarunk órák hosszat konfigurálni, akkor ezt a könyvtárat használjuk alapnak és más néven hozzuk létre a másolatát ugyan ide. (Tehát a CINEMA 4D R13\plugins könyvtárba.) Ha nem így teszünk, akkor a számtalan relatív elérési út miatt órákon át konfigurálhatjuk a projektet. (És jó eséllyel kudarcot is vallunk. Én megpróbáltam)

A cinema4dsdk könyvtárban van egy Visual Studio (továbbiakban VS) solution fájl, 2005-ös verzióhoz. Valószínűleg nekünk újabb verziójú lesz (nekem 2010 van). Ha el akarjuk kerülni, hogy a fejlesztőeszközünk működését szabotálja a Windows jogosultságok címén, akkor indítsuk adminisztrátorként. A Visual Studio ezek után szépen át is konvertálja nekünk.

A neten olyan információkkal találkozni, hogy a 2008-as VS nem végzi tökéletesen a konvertálást. Ha valaki ilyet tapasztal, kövesse ezt a forrást.

A konvertált solution fájlt ezután szépen le tudjuk fordítani, eredményül kapunk egy dll-t. Ahhoz, hogy ezt a Cinema 4D elfogadja, .cdl vagy .cdl64 kiterjesztésre kell változtatni, attól függően, hogy 32 vagy 64 bites bővítményt készítünk-e. Ebben a leírásban a 32 bites rendszerrel foglalkozom csak. Ha idegenkedünk az átnevezéstől, akkor a projektünk Properties->Confoguration Properties->General->Target Extension résznél beállíthatjuk ezt a kiterjesztést.

Amint ezzel megvagyunk, a program Plugins->könyvtárnév alatt megtaláljuk a bővítményeket, amelyek most még csak a lefordított példákat tartalmazzák. Nézegessük őket!

Elkészült a textura beolvasó osztály is. Azt gondoltam, hogy ezt egyszerűen átmásolom és használom, de a rendszerek közötti különbség ismét közbeszólt. ( Egy életre megjegyeztem, hogy Windows alatt fopen(file, "rb")-vel olvasunk be bináris fájlokat. )

Először is le kellett fordítani a libpng-t Windows alá. Szerencsére csak a zlib az egyetlen függősége, és olyan jó minőségű Visual Studio projekt fájlt sikerült készíteniük, hogy a folyamat teljesen fájdalom mentes volt. Már így is eléggé elszaporodtak a release-hez csatolt DLL-ek, ezért statikusan linkeltem mindkettőt.

Ezzel a lépéssel a régi Linuxos keretrendszer teljes funkcionalitása rendelkezésemre áll C++-ban és Windows alatt. A teszteléshez a Biopunk című demónkból kivettem a patkányt és megjelenítettem. A textúra szépen feszült, a mátrixok megfelelő módon forgatták be a modellt.

Amiről nem írtam, hogy Grass is dolgozik. Elkészített két modellt. Az egyik egy környezeti elem lesz, a másik egy karakter. Nem közlök róluk képet, de higgyétek el, nagyon vagányan néznek ki. Most egy nagyobb jelenet környezetén dolgozik. Ez kicsit olyan, mintha valami mese díszlete lenne. Kiforratlan, de nekem jó lesz, hogy a következő projekten, a Cinema 4D exporteren dolgozzak vele.

Pihenni nincs idő, még rengeteg munka vár és az idő fogy.

Egyik korábbi posztom kicsit félrevezető lehet. Ott azt sugalltam, hogy de-novo szekvencia összeszerelés esetén elég egyetlen programnak megadni a szekvencia darabokat, és az megcsinál mindent, végezetül megkapjuk az összes kromoszóma teljes nukleotid sorrendjét.

A helyzet az, hogy ilyen a legritkább esetben fordul elő. Úgy is mondhatnám, én még nem találkoztam ilyennel. A legtöbb esetben több ezer hosszabb-rövidebb szekvenciát kapunk, nem ritkán N-ekkel tarkítva. Szerencsére vannak programok, melyek segítenek a további feldolgozásban.

GAPFiller

A GAPFiller, mint neve is mutatja, nem csinál mást, mint a scaffoldokban található N-eket tünteti el. A program több lépésben readeket pakol a szekvenciákra és próbálja befoltozni a lyukakat. A párosított readek távolság információit felhasználva olyan lyukakat is be tud foltozni, amelyek a readeknél hosszabbak. Megadhatjuk neki, mennyi read illesztése esetén fogadjuk el a foltozást. A scaffoldok sorrendjét nem próbálja meg meghatározni.

SSPACE

A GAPFiller alkotóinak másik programja, ami a párosított readeket használja fel arra, hogy összekösse a scaffoldokat. Segítségével kevesebb szétdarabolt szekvenciánk lesz.

Mauve

Ha van egy rokon szekvenciánk, a Mauve segítségével megnézhetjük, a scaffoldok milyen sorrendben követik egymást. Arra is kiválóan alkalmas, hogy ellenőrizzük, mennyire jó az eddigi összeszerelés. Ha ugyanis azt tapasztaljuk, hogy a scaffoldok nagy része a genom különböző pontjairól származik, jó eséllyel valamit elszúrt a de-novo program. A Mauve Java-s fejlesztés, fut minden platformon.

 Blast

Ne feledkezzünk meg a jó öreg Blastról sem. Ha csak ellenőrizni kívánunjuk egy genomi struktúra jelenlétét nincs jobb és megbízhatóbb ennél a programnál.

Bambus 2

Ezt a programot nem tudtam használni. Már a telepítése is elég bonyolult volt. Az AMOS programcsomag része. A feladata elméletileg az SSPACE-ra hasonlít. Ha csak tehetjük használjuk inkább azt. És ha csak tehetjük, ne használjuk az AMOS-t sem.

Startup cégeknél, mikor befektetőkre vadásznak, előfordul, hogy nagyobbat mondanak az emberek, mint amit kellene. Ez egyeseknek be is jön. De a művész világról nem gondoltam volna, hogy ilyen kicsinyes módszereket használna. (Bár, mint látni fogjuk, a művész megnevezése nem is állja meg a helyét.)

Miről is van szó? Adva van egy művész, aki összeszedi az utcáról az eldobott rágógumit és egyéb szemetet, amin feltételezhetően emberi DNS van, megszekvenálja, megállapítja a fenotípust, megalkotja az illető arcát, majd egy 3D nyomtatóval kinyomtatja azt. A nyomtatott maszkokból pedig kiállítást szervez.

Első olvasatra - mondjuk ki - baromság az egész. Már csak abból a tényből kiindulva, hogy nem tudjuk senki arcszerkezetét megállapítani a DNS-ének birtokában. Amire képesek vagyunk, néhány kitüntetett távolság meghatározása, vagy ha tudjuk, hogy egy genetikai betegség arcdeformációval is jár, akkor a betegségre utaló jelek esetén feltételezhetjük, hogy rendelkezik a rá jellemző arcszerkezettel.

Sajnos vagy nem, a DNS önmagában kevés a fenotípus kialakításához. Van valami, amit nagy általánosságban úgy hívnak, környezet, és ez hatással van ránk. Ha Einsteinnek pálinkás kenyeret adnak gyerekkorában minden vacsorára és mákos teával altatják, hogy ne kérdezzen annyit, akkor hülye lesz, függetlenül a génjeitől.

Azért, hogy ne legyek igazságtalan a "művésszel" szemben, elolvastam a blogján található információtöredékeket. Ezek alapján a következő kép alakult ki bennem:

1. Összeszedi a mintákat. Megjegyzem a DNS nem egy darab műanyag pohár, az bizony bomlik. Laboratóriumi munkám során volt olyan, hogy "elvesztettem" a DNS-t. (A témavezetőm nagyon örült ilyenkor.) Az történt, hogy a DNS lebomlott vagy széttöredezett.

2. Valami labormunkát végez a mintákkal. Erről nem sok mindent sikerült megtudnom. Vagy SNP chipet használ, mert egy posztban linkel egy SNP Wikit. Vagy satellitákat néz (utal rá, hogy úgy érzi magát, mint a CSI-ben). Mivel kevés a minta, a második eset a valószínűbb. Amit biztosan nem csinál: teljes genom szekvenálás. Tehát eddig nem sok értelme van a labormunkájának.

3. Futtat egy csodaprogramot. Azt állítja, hogy írt valami tanuló algoritmust MATLAB-ban (bár a program nevét következetesen kisbetűvel írja) és BioPythonban (ha nem használna valami bio vackot, el sem hinném, hogy szekvenciákkal dolgozik).

4. Kinyomtat egy arcot az ingyenesen elérhető arc adatbázisból. Persze azt állítja, hogy az adatbázist csak tréning adatnak használja, de miféle tréning adat az, ahol hiányzik a genotípus?

Már csak azt nem értem, hol a művészet? A BioPython kódban? A szabvány kitekkel végzett laboratóriumi munkában? Talán abban, hogy ezt a sok hülyeséget el tudja adni.

Sajnos nem úgy haladok a produkcióval, mint terveztem. Elkészült a mátrix kezelő osztály és az OBJ betöltő. Nem hangzik soknak? Azért nem nem sok.

Mivel nem csak átmásoltam a C kódot, hanem felül is vizsgáltam, érdekes jelenségekre lettem figyelmes:

1. A Windows nem programozó barát

Gyakran hallani, hogy egyes alkalmazások felhasználó barátok, mások nem. De létezik a számítógép felhasználóknak egy másik faja, akik programokat alkotnak. Azt gondoltam, egy programozónak nem kell igényeket támasztania az operációs rendszer felé, csak adni neki egy szövegszerkesztőt, egy fordítót, és időt, hogy dolgozzon. De most, hogy Windows alatt szerencsétlenkedem, rájöttem, hogy igen is van igényem az operációs rendszer felé. Először is, legyenek a fejléc állományok egy helyen. Ahány SDK-t telepítek, az annyi helyre szórja szét a fejléc állományokat és könyvtárakat. Az elérési utak hosszúak, hülye karakterek vannak bennük, amiket más hülye karakterekkel semlegesítek. Hiányoznak a szkriptek és egyéb automatizáló eljárások.

Vicces, mert míg Linux alatt dolgoztam, soha nem gondoltam arra, hogy nekem szükségem lenne egy nagy IDE-re. Windows alatt Visual Studio nélkül halott lennék. Ennek a hatalmas böszme koloncnak nincs más dolga, minthogy az ellenséges operációs rendszer elé egy függönyt húzzon és megadjon nekem mindent, amire szükségem van.

2. A GNU lustává tesz

Ez az igazság. Annyi kóder nyalóka függvény van a glibc-ben, hogy teljesen a hatásuk alá kerültem. Azokra a függvényekre gondolok, amelyek egyáltalán nem bonyolultak, de valami unalmas, rutinjellegű feladatot megoldanak. Például getline, strsep. Windows alatt ezeknek írmagjuk sincs, mert nem részei semmilyen standardnak. De ahelyett, hogy fél óra alatt leprogramoznám őket, két órán keresztül a guglit nyúzom és olvasom a többi, hozzám hasonló lusta ember nyavajgását, hogy miért nincs ilyen Windows alatt.

3. A változatosság jótékony hatású

Itt arra gondolok, hogy akár mennyi szenvedéssel is jár most még a kódolás Windows alatt, jó, hogy látok mást is a parancssor mellett. Tágítja a látóteremet. Ez persze igaz az egész demoscenére. Hiszen egy cégnél a főnök megmondja, mit kell csinálni, a projekt vezető előírja, mikorra legyen kész. A vezető fejlesztő meghatározza, milyen eszközöket kell használni, végül a tesztelő rámutat, hogy mit kell kijavítani. Egy demó készítésénél viszont senki nem ír elő semmit. A cégnél akkor jó az ember, ha minél gyorsabban, minél kevesebb időráfordítással old meg valamit. A partikon ellenben értékelik, ha valaki egy nehéz kihívást vállal. (Ezzel nem akarom azt sugallni, hogy a Visual Studio kihívás. Egyáltalán nem az.)

4. Platform függetlenség nem létezik

A math.h-ból akartam az M_PI konstanst. Windows alatt még be kell írni, hogy #define _USE_MATH_DEFINES. Több szót nem is érdemes fecsérelni erre.

Baráti beszélgetések alkalmával gyakran terelődik a filmekre a szó. Ilyenkor megkérdezik, hogy láttam-e X filmet.

- Nem láttam - felelem a legtöbbször.

- Pedig az nagyon jó, neked is biztosan tetszene. Nézd meg feltétlenül.

Nem fogom megnézni a filmet. Egyrészt sajnálom rá azt a két órát, az utazásról nem is beszélve, amíg eljutok a moziig. Még a DVD kölcsönző felkeresése is plusz idő, amit akár demók kódolásával, cikkek olvasásával is tölthetek, ráadásul utóbbiak sokkal szórakoztatóbbak.

De nem volt ez mindig így. Régen én is faltam a filmeket, olvastam a fórumokat és listát vezettem a várható premierekről. Azután azt vettem észre, hogy egyre kevesebb feljegyzést készítek, alig olvasom a fórumokat, ha meg megnézek egy filmet, azt is unom. Mi történhetett?

Végül is mit kapunk egy tipikus hollywoodi filmtől? A valóság egy szűkített, eltúlzott képét. Képtelen történeteket, végleteket, az események sarkosítását. De ugyan ezt kapom, ha a rokonaimmal/ismerőseimmel beszélgetek! Annyi furcsa, szürreális történetet mesélnek, hogy néha nem tudom, én vagyok nagyon naív a világgal kapcsolatban, vagy tényleg a káosz uralkodik az életünkön.

Ezeket a történeteket is kategóriákba lehet sorolni, akár csak a filmeket:

Akció: "Ezek már az egész IV. kerületet megvásárolták. A géppisztolyos őrök nem engednek be senkit, aki nem közéjük tartozik."

Krimi: "A kínai áruházban elaltatták a nőt. Már majdnem kivették a veséjét, de az volt a szerencséje, hogy a férje bement az áruházba." (úgy tűnik, ezt mások is ismerik)

Sci-fi: "Ha egy terhes nőnek csúcsos hasa van, fiút fog szülni."

Horror: "Az anyuka egyszer megkívánta a szőlőt és az arcához kapott. Mikor megszületett a lánya, az arcán szőlőfürt-szerű anyajegy volt. Mi mind tudtuk, hogy miért."

Fantasy: "Én megálmodtam a halálát. Azt álmodtam, hogy egy tóban fürdött és integetett nekem. Azonnal felébredtem és rögtön tudtam, hogy meghalt."

De a legdurvább történeteket egy olyan volt munkatársam mesélte, aki szerintem skizofrén volt. Az első két története még érdekes volt. A második kettő meghökkentő, de mivel mindig készségesen meghallgattam, rámszabadította a fél Alkonyzónát. Élettörténete röviden:

Tíz évesen segített az apjának házakat tervezni, némelyik olyan jól sikerült, hogy tényleg megépítették. Tizenkét éves korába freskókat festett, mert olyan jól rajzolt, hogy a helyi lelkész megkérte, fessen a templom falára. Harmadikos szakközépiskolás korában a negyedikeseket tanította elektrotechnikából, mert a tanár épp nem ért rá. Még egyetem előtt ipari robotokat programozott, amivel az üzem hatékonyságát sikerült 20%-al növelnie. Annyi pénzt kapott, hogy egy földet vett, de ezzel kivívta a helyi maffia-kapcsolatokkal rendelkező ügyvéd haragját, aki be is perelte. Egyetlen ügyvéd sem vállalta el az ügyét, ezért úgy döntött, majd ő védi magát a tárgyaláson. Természetesen megnyerte a pert. Az egyetemen orosz fegyverfejlesztési kutatók oktatták, és hívták őt is csillagháborús projektekbe, de pacifizmusa nem engedte, hogy ilyen tevékenységbe vegyen részt.

Egyetem után besorozták, de megtagadta a szolgálatot és szökevény lett. Később a New York-i metró irányítórendszerét programozta egy kis csapatban, majd bankokban dolgozott, mint programozó. Szabadidejében pénzügyi könyveket olvasott, aminek hatására két hónappal előre tudta jelezni a gazdasági válságot és meghozta a szükséges óvintézkedéseket.

Elmondta, hogyan tehetünk szert paramépességekre és azt is elmagyarázta nekem, mi az epigenetika, mert én biztos nem hallottam róla, annyira új felfedezés ( a New York Times tudományos mellékletében olvasta, az sokkal megbízhatóbb forrás, mint a Nature vagy Science).

Ezek után kinek kellenek filmek?

A minap ismét a Trinityvel dolgoztam, és egy olyan szkriptnevet kellett beírnom, aminek a neve 54 karakterből állt. Rövid keresgélés után kiderült, hogy ez még nem is a csúcstartó. A gmap_gff3_to_percent_length_stats.count_mapped_transcripts.pl (61 karakter) volt a leghosszabb. Ha bárki tud olyan széles körben elterjedt alkalmazásról, ahol ennél hosszabb a szkript neve, azonnal tudassa a hozzászólások között.

A megmérettetésben csak olyan alkalmazások szerepelhetnek, amelyeket publikáltak vagy kereskedelmi forgalomba hoztak. Ha egy olvasó suttyomban készít valamit és felrakja a GitHubra, az nem számít.

Nemrég egy olyan fajjal dolgoztam, ahol még nincs referencia genom. Az eredmények érdekében több de-novo metódussal dolgoztunk, többek között a Trinityvel, hogy összeállíthassuk a faj transzkriptómját. Eredményül kaptunk is egy csomó szekvenciát, ami önmagában nem sok segítség a kísérletes biológusoknak. Ezért elkezdtem dolgozni a szekvenciák annotálásán.

Mikor végeztem, furcsa érzés fogott el. Én már tudtam, mi a szerepük az egyes szekvenciáknak, de rajtam kívül még senki. Legjobb tudásom szerint senki a világon. Kicsit hazug elképzelés, mert bizonyára több kutatócsoport is dolgozik ezen a témán, talán már épp a cikket gépelik, vagy arra várnak, hogy elfogadják azt. De erre akkor nem gondoltam. Örömömben elmondtam ezt az egyik asszisztensnek, aki megvonta a vállát és csak annyit mondott:

- Lefuttattál egy programot? Ezt bárki meg tudja csinálni.

Ez elég kijózanítóan hatott. Nézzük is meg, mi az, amit bárki meg tud csinálni.

A Trinityhez tartozik egy annotációs rendszer, a Trinotate. A program futásához további programok kellenek: Blast, HMMER, signalIP, tmHMM. Adatbázisok: SwissProt, PFam.

A gondot a signalIP és tmHMM okozta. Elvileg ingyen megkaphatja őket minden akadémiai kutató, de ennek a kutatóintézet domain nevének szerepelnie kell egy listán. Ha nincs fent, nem tudja letölteni. (GMail, Hotmail nem használható). Mondanom sem kell, mi nem voltunk a listán. Írtam nekik, hogy vegyenek fel, de nem válaszoltak semmit. Öt nap múlva újra írtam nekik, de most sem válaszoltak. Szerencsére felsorolták, hogy mely domainek vannak náluk bejegyezve. Elkezdtem nyomozni, hogy kinek az ismerősének az ismerőse dolgozik az adott helyeken. Kb. fél óra múlva megvolt a kapcsolat, aki letöltötte és elküldte nekem. Közben, hogy legyen tartalék terv is, összeszedtem az oldalról az összes e-mail címet, amit csak találtam. Webmestertől kezdve a portásig mindent és mindenkinek elküldtem a levelem, hogy bocs, de kell a program.

Erre már felfigyeltek. Végül két forrásból is meglettek a programok. De sajnos nem úgy működtek, mint a dokumentációban. Pontosabban sehogy nem működtek. Ekkor megnéztem a forráskódot. Kiderült, hogy a két program nem más, mint Perl szkriptek. (Na jó, a tmHMM-ben van valami C kód is). Belemásztam a kódba, hogy mégis miért nem futnak. A programokba beépített elérési útvonalak voltak kódolva, amitől kizárt dolog, hogy azonnal működjenek.

A doksi ugyancsak nem említette, hogy a signalIP-ből melyik eredményt kell felhasználni, a tmHMM eredményéből pedig el kell távolítani a fejlécet. Mikor ezekkel megvoltam, már kaptam is eredményt.

Ez még csak az én részem volt a folyamatból. Arról se feledkezzünk meg, hogy a szekvenciákhoz is rengeteg munka kellett. Fel kellett nevelni az élőlényeket, mintát kellett venni és meg kellett azokat szekvenálni. Talán nem árulok el nagy titkot, ha azt mondom, hogy ehhez az intézetben négy csoport adta a pénzt. Talán joggal gondolom azt, hogy ezt nem tudja bárki megcsinálni. (Az említett asszisztens eddigi hőstettei alapján biztosan nem képes rá.)

Bevallom, van valami hipnotikus a körbe rendezett genomi adatok látványában. A genomi átrendeződések kivételével nem hordoznak plusz információt, mégis, ha körbe rendezett kromoszómákat nézek, úgy érzem, sokkal tudományosabb munkát látok.

A program, amivel mindezt elő lehet állítani, a Circos. Ez a Perl nyelven írt program olyan naggyá nőtte ki magát, hogy a Nature talán nem is fogad el olyan cikket, amiben nem ezzel készültek az ábrák.

A program beolvas egy konfigurációs állományt és az ott található paraméterek alapján elkészíti az ábrát. Ha úgy döntünk, hogy magunk írjuk meg ezt az állományt, akkor nem árt, ha odatesszük magunk mellé a dokumentációt, mert szinte nincsenek benne alapértelmezett értékek. Ha egy tulajdonság csoportot létrehozunk, akkor az osszes paramétert be kell állítani, különben nem az jelenik meg, amit mi szeretnénk. Lássuk, hogyan is kezdjük.

A konfigurációs állományban alapvetően kulcs-érték párokat kell beállítani. Ha a tulajdonságokat több, azonos grafikai objektumon is be kell állítani, akkor XML szerű elválasztó tageket használunk.

Az első és legfontosabb paraméter a kariotípus (karyotype) beállítására szolgál. Mivel elsősorban genomi információk megjelentítésére szolgál, ez nem meglepő. Az, hogy mit tekinthetünk kariotípusnak, annál inkább. A programot ugyanis előszeretettel használják nem-genomi adatok megjelenítésére is. (Bizonyára másokat is hipnotizál, ha körbe rendezik adataikat)

A kariotípus egy szóközzel elválasztott táblázat. Első két oszlopa chr és '-'. Utána következik egy egyedi azonsító, majd a szöveg, ami megjelenik a képünkön. A kromoszóma méretét két koordinátával adhatjuk meg., végül egy szín azonosító.

A kariotípus megadása után következik az ideogram (<ideogram>) tulajdonságainak megadása. Ez kromoszómák megjelenítésének egyfajta globális beállítása. Megadhatjuk, mekkora kört képezzünk kromoszómáinkból, mekkora távolság legyen közöttük, legyenek-e kitöltve, stb.

A másik lényeges tulajdonságcsoport a kép (<image>). Itt a fájllal kapcsolatos tulajdonságokat állíthatjuk be. Például mekkora legyen a kész kép és mi legyen a fájl neve.

Sajnos a nagy számú paraméter miatt kezdeti lelkesedésünk a körbe rendezett kromoszómák iránt gyorsan lelankad. Ezt a program szerzője is felismerte, ezért a <<include >> paranccsal ajándékozott meg minket (valamint rengeteg konfigurációs állománnyal, hogy mégis legyen valami segítség, hamár alapértelmezett beállítások nincsenek.)

A színeket, betűtípusokat és egyéb apróságokat ezért egyszerűen csak beillesztjük. Ha a programot Ubuntu csomagkezelőjével telepítjük, az /etc/circos könyvtárban találjuk a segítséget.

Természetesen azok számára is van segítség, akik nem akarnak konfigurációs fájlokkal bajlódni. A program rengeteg szkripttel érkezik, amelyek gyorsan és fájdalommentesen készítik a köröket.

A cufflinks egy remek program, hogy a szekvenálásokból megállapítsuk, melyek lehetnek a kódoló régiók. Sajnos a program több, egymással összefüggő táblázatot generál, aminek a feldolgozása nem egyszerű feladat. Szerencsére az R programcsomag ismét a segítségünkre siet.

A cummeRbund csomag segítségével könnyen felderíthetjük a hatalmas adat mögött megbúvó összefüggéseket. Első lépésként töltsük be az adatokat:

library(cummeRbund)
adat = readCufflinks(dir="directory", genome="genom.fasta", gtfFile="annotacio", rebuild=T)


A parancs hatására adatainkat az adat változóval érhetjük el. A directory a cufflinks eredményeink kimeneti könyvtára. A genome.fasta az elemzéshez felhasznált genom, míg a gtfFile paraméterrel adhatjuk meg azt ismert transzkriptek annotációját. Amit nem látunk, az egy adatbázis generálás a háttérben. A szöveges állományok a gyorsabb kereshetőség érdekében egy SQLite adatbázisba lesznek elmentve. Ennek helye a directory-ban lesz.

Használata annyira egyszerű, hogy nem is kell érteni az R-hez, ha szép képeket és táblázatokat akarunk készíteni. Például ha normalizált expressziós értékek eloszlására vagyunk kíváncsiak, nem kell mást tenni, csak kiadni a

dens <- csDenstity(genes(adat))
dens


parancsot. A legtöbb parancs egyből rajzolja is az ábrákat. Annyira egyszerű használni, hogy csak a dokumentációt tudom ismételni. De hogy valami olyasmit is mutassak, ami nincs leírva a dokumentációba, nézzük, hogyan lehet az unalmas cufflinks azonosítókat gén szimbólumokra cserélni.

Az eredményül kapott szignifikáns gének neve ilyen furcsa karakterekkel kezdődik: XLOC_. Ha ezt egy biológus kezébe nyomjuk, az sikítani fog. Az annotáció segítségével viszont kicserélhetjük gén nevekre.

annot <- annotation(genes(adat))
sig.data <- as.data.frame(getSigTable(adat, alpha=0.05, level="genes"))
sig.data$gene_id <- row.names(sig.data)
sig.with.annot <- merge(annot, sig.data, all.y=T)


Mit csinál ez a kód? Először is létrehoz két data.frame típusú változót. Az egyik neve annot, a másiké sig.data. Az annot-nak van egy gene_id nevű oszlopa, ezt létrehozzuk a sig.data-ban is. Ezután a merge paranccsal összefűzzük őket. Az all.y segít, hogy ne veszítsünk adatot a sig.data-ból. Alapértelmezetten ugyanis a merge a két halmaz metszetét adja vissza.

Egy másik trükkel azt mutatom be, miként lehet GO analízist végezni. Ha olyan fajjal dolgozunk, amelynek megtalálható az annotációja a Bioconductorban, nincs nehéz dolgunk (ha nem található meg, az gáz):

go <- toTable(org.Hs.egGO)           # get GO ids
go$term <- Term(go$go_id)            # get GO terms
lipid <- go[grep("lipid", go$term),] # get GO ids by keyword
sym <- toTable(org.Hs.egSYMBOL)      # get all the gene symbols
lipidsym <- merge(lipid, sym)        # now the table contains
                                       genesymbols, GO terms and GO IDs
x <- merge(lipidsym, annot, by.x = "symbol", by.y = "gene_short_name") #
                                       put XLOC names into the mess
lipidgenes <- x$gene_id.y
lipidgenes <- getGenes(adat, lipidgenes) # select genes from
                                           expression data
x <- expressionPlot(lipidgenes)


A kód működéséhez be kell tölteni a GO.db és az org.Hs.eg könyvtárakat. Ha más fajjal dolgozunk, akkor természetesen az adott fajnak megfelelő annotációs könyvtárra van szükségünk. Először táblázattá alakítjuk a GO annotációt, és hozzáfűzzük a táblázathoz a leírásokat. A grep parancs segítségével kiválasztjuk a minket érdeklő GO kategóriákat. Az annotációból kiszedjük a gén szimbólumokat. Erre a lépésre azért van szükség, mert ez az adat képez kapcsolatot a cummeRbund-os eredmények és a GO annotáció között. A két merge segítségével összefűzűnk minden adatot, kiválasztjuk a cummeRbund-os azonosítókat és máris van egy génlistánk GO alapján. Végül megnézzük az expressziós profilját a listánknak.

Remélem mindenki kedvet kapott a cummeRbundhoz.

Ha Húsvét, akkor Revision. Ez nem is lehet kérdés. Jelen összeállításomban kiragadok néhány számomra kedves példát a release-k közül és röviden leírom, miért is tetszettek.

Amiga

Mivel is lehetne kezdeni, mint az Amigás releasekkel? Számomra az Elude vitte a pálmát. Ez a csapat ugyanis mindig olyan effektet hoz létre, ami megdöbbentő. Most például depth-of-field-el és karakter animációval örvendeztettek meg minket. Sokat kritizálják őket, hogy demóik nem koherensek, de szerencsére ez nem tántorítja el őket attól, hogy továbbra is fantasztikus demókkal árasszanak el minket. Bevallom, tavaly a Kakao után megijedtem, hogy beszüntetik tevékenységüket, de szerencsére a félelmem alaptalan volt. Akinek nincs szénné tuningolt 1200-ese vagy MorphOS-e, annak álljon itt a videó:

A másik kedvenc Moods Plateau Stealth Ranger-e. Nem sűrűn fordul elő, hogy egy egész demót dedikálnak valakinek, pláne olyan embernek, akit személyesen is ismerek. Charlie a Skoda és az Amigák nagy fanatikusa, (sorrendet nehezen tudnék megállapítani) aki minden évben komoly munkát végez azért, hogy az Amigás releasek zökkenőmentesen lemenjenek. Rójuk le mi is tiszteletünket azzal, hogy megnézzük ezt a demót:

Animációk

Az animációk közül csak egyet emelnék ki, a "Turtles all the way down"-t. Csak annyit mondok, fraktálokból soha nem elég:

64k

Az introk közül szintén a "Turtles all the way down" című tetszett, de ezt a Brain Control követte el. Mint biológiához közeli embernek, csak két kifogásom van: a vörösvértesteknek nincs DNS-ük, a fejlábúaknak pedig vörösvérteste.

Demók

Azt kell, hogy mondjam, Smash idén állva hagyta a mezőnyt, már ami a kódot illeti. Valós idejű raytracing, törésmodell és fénytörés szerepel a Fairlight demójában. Raytracing? Nagy cucc, már több, mint 10 éve láttunk ilyet demókban. Szeretném felhívni a figyelmet, hogy itt a fény színekre bomlik, mint a prizmáknál. A fénytörést nem gömbökre számolták, hanem egy összetett modellre. Engem nagyon zavart, hogy várost nehezen láttam, mert minden tükröződött. Néha nem értettem, a piramis olvad, vagy üreg képződik benne, de a látvány bőven kárpótol minket minden ilyen furcsa jelenségért.

Cocoon ismét egy futurisztikus gyárba kalauzol minket, de most embereket raknak össze furcsa forgó golyók. Tetszik a demó dinamizmusa. Ez egyébként a csapatra jellemző. Ami hiányzott, Willbe fantasztikus zenéje. Nem mintha H0ffman kompozíciója rossz lenne, de mintha már hallottam volna a SceneSat-on.

Nuance mindig az élmezőnyben végez, de nyerni szinte csak az Ultimate Meetingen tudnak. Figyelni szoktam az alkotásaikat, mert bár az egész demójuk nem szokott teljesen magával ragadni, mindig akad egy momentum, egy jelenet, amit élvezettel nézek. Itt például az tetszett, mikor a rovarfejű ember démonná alakul.

Panda Cube híres a monumentális alkotásokról, ami hasonló a Cocoon demókban látottakhoz, de kevesebb dinamika van bennük. Meg is kapják érte a magukét a fórumokon, ahol azzal vádolják őket, hogy csak flyby demókat készítenek. Én szeretem ezt a stílust is, de idén elég vérszegényre sikeredett mindez. Büntetésül nem kapnak linket :-)

Előadások

A demók csak egy részét képezik a partinak. A másik fontos rész az előadások. Ha az ember figyel, még talán tanul is valamit. Mivel én elég gyatra szépérzékkel vagyok megáldva, érdeklődöm minden olyan iránt, amit segít a vizuális tartalom összeállításában. Ezért is érdekes ez a kameráról és színösszeállításról is szóló előadás:

A másik témakör, amiben fejlesztenem kell magam, a kódolás. Ezért is érdekes ez az OpenGL fényeivel foglalkozó előadás:

Egy bébi-projektemről szeretném lerántani a leplet. Észrevételeim alapján a biológusok még mindig a Microsoft Word programot használják a szekvenciák feldolgozásra. Sajnos a programnak van pár olyan hiányossága, ami megnehezíti a bioinformatikai munkát, ezért pár hónapja elkezdtem írni egy makrót, ami megpróbálja növelni a munka hatékonyságát.

Az első probléma, hogy a szöveg keresés nem működik sortörés esetén. Miután ezt kiküszöböltem, gondoltam jó ötlet lenne Perl kompatibilis reguláris kifejezéseket is használni. Ezt elég nehéz volt implementálni, de nagyrészt sikerült. Ebben sokat támaszkodtam a következő VBScriptre.

A fehérjére fordítás és restrikciós enzim térképezés könnyed ujjgyakorlat volt. BAM beolvasás kicsit bonyolultabb, azt későbbre halasztom, de SAM importot építettem bele. Amit szeretnék még, egy Burrows-Wheeler illesztő. Az egyik dokumentumban lenne a referencia, a másikban a readek. Performanciában nyilván elmaradna a BWA-tól, de kisebb adatszettekre, gyors ellenőrzésre szerintem használható lenne.

Még sok fejleszteni való van vissza, hibák is akadnak szép számmal. Például ha az oldalbeállítás nem megfelelő, és emiatt a Fasta fejléc két sorba kerül, akkor lefagy a makró, és magával rántja a Wordöt is. Ezért a biztonság kedvéért fekvő A4 oldalt használjunk. Aki kíváncsi, letöltheti a sablont innen.

Ezt a képet az intézet ablakából készítettem. A nyúl megpróbál bekommandózni.