Sziasztok,
1-2 éve olvastam egy egyetemi - talán holland vagy svéd- projectről, a lényege, hogy videókártyákkal számoltak ki viszonylag gyorsan ct vagy mri képeket 3d-be megjelenítve. Kezdetben csak Vista-n ment nekik, de később tervezték/megcsinálták Linux-ra is, és szándék volt rá, hogy nyílt forrásúvá teszik a fejlesztéseket. Próbáltam rákeresni, de sajna nem találtam őket, pedig Youtube film is volt a projectről. Ha valakinek beugrik, hogy kik lehettek ők, annak előre is köszönöm a linket. Esetleg tipp, hogy van-e használható nyílt project GPU alapú orvosi képalkotásra.
- 5608 megtekintés
Hozzászólások
Anders Ynnerman? Egyébként sokan csinálják: elég kézenfekvő GPU alkalmazás, de utube-os MS Surface marketinges változat:
http://www.ted.com/talks/anders_ynnerman_visualizing_the_medical_data_e…
Nem nagyon van szabad projekt, mert az alapszoftverek még ma sem igazán GPU-sak, mert nagyon fragmentált célgépek még mindig (nincsen intel opencl, es a cuda/fusion is csak custom binaryval megy, ami eleve gátolja az implementációt. De gyártó-PR projektek vannak, mint fent - de akár AAPL GC, pl http://www.apple.com/science/insidetheimage/breiman/)
rövden: nincsen.
- A hozzászóláshoz be kell jelentkezni
Meg nem nevetett hazai cég is ezt csinálja, de abszolúte proprietary és closed source ... C'est la vie. Hatalmas pénzt hajlandóak ilyen dolgokért kifizetni a "vásárlók".
A nyílt projektek közül a Wikipedia-n nézz szét; hogy mennyire használható az más kérdés. Én még nem hallottam olyan Mo.-i intézményről, ahol ezek közül használnának valamit. Általában az eszköz mellé jár a szoftver is, aminek az ára töredéke az eszközének.
- A hozzászóláshoz be kell jelentkezni
A Mediso-ra gondolsz?
/sza2
- A hozzászóláshoz be kell jelentkezni
Nyílt forrást nem nagyon találsz, ezt igen súlyos fejlesztői emberévekkel kell kifejleszteni.
Ami érdekes, és kevesen tudják, Magyarországon nagyon komoly piaci alapú fejlesztések folynak ezen a téren: a tisztán magyar tulajdonú cégnek komoly gamma kamera, CT, PET készülékfejlesztése is van, emellett szoftver oldalról komoly nukleáris medicinai, 3D-s CT és PET szoftvereket is fejlesztenek.
A teljesítmény igény miatt (elég brutális számolásigénye van) az utóbbi időben minden komolyabb számolást igyekeznek GPU-ra áttenni, és igen szép eredményeik vannak.
Ha valakit komolyabban érdekel a GPU alapú szoftverfejlesztés CUDA-ban, C++-ban, érdemes esetleg őket megkeresni, szinte mindig keresnek szoftverfejlesztőket. A munka nagyon inspiráló, bár talán kicsit kevesebbet fizetnek, mint az ember szeretné :) GPGPU-ra ismerkedni viszont nagyon jó lehet.
(érdekem nem fűződik a fentiekhez, már eljöttem innen személyes okok miatt)
- A hozzászóláshoz be kell jelentkezni
Ilyesmivel foglalkozom.
Én személy szerint a VTK-t szeretem nagyon: http://www.vtk.org
VTK-ra és Qt-ra épülő GUI: http://www.paraview.org (csak, hogy szerepeljen: ParaView-ra épített CFD program: http://www.openfoam.org)
VTK GPU alapú módosítása: http://www.vtkedge.org
A teljes rendszer: ITK (ezt sosem használtam, csak amiket fentebb is írtam): http://www.itk.org/
Bármelyikben tudok segíteni is.
--
http://www.naszta.hu
- A hozzászóláshoz be kell jelentkezni
No, akkor már ketten vagyunk - én a Slicer-t portoltam Solaris-ra, bár csak kotnyeles biológusként... :)
Amúgy a VTK-t használják az SZTE Számítógépes grafika tanszékén is páran.
(Amúgy a KitWare éppen a Slicer közeli projektekből nőtte ki magát. KitWare = Cmake, ITK, VTK, meg a többi... :)
<-------
You can't grep on dead trees.
- A hozzászóláshoz be kell jelentkezni
Hogy a topic indítónak is válaszoljak:
A Slicer GPU-t használ azokon a platformokon, ahol van rá lehetőség.
Elképzelhető, hogy kézzel kell lefordítani (nem emlékszek, hogy lenne letölhető GPGPU-s verzió), de van/volt ilyen branch egy időben.
Slicerben amúgy is tudok segíteni, szólj, ha kell!
szerk: Ja igen, visszaolvastam a topicot... :) - szóval a Slicer FREE!!!!!! - és nagyon sokat tud; 1998 óta fejlesztik, és - mostmár :) - 4 platformra is elérhető.
szerk2 (bocs, most ekezet nelkul) - Meg egy dolog:
a Harvardon + nagy amerikai egyetemeken fejlesztik, nem sz*rral gurigaznak!! :)
<-------
You can't grep on dead trees.
- A hozzászóláshoz be kell jelentkezni
Mire lenne szukseged? Ha bohockodni es erdekel a szoftverfejlesztes akkor eleg olcson lehet ilyesmit lekodolni ha mar kesz CT/MRI adatbazisod van. Akkor csak egy DICOM loader es marching cubes implementacio kell, plusz irgalmatlan sok turelem mire mindent megfeleloen osszepasszintasz. Ha nem, akkor keszpenz a megfelelo szoftverert. :) Mivel ezek retegszoftverek es irgalmatlan sok munkaba kerulnek, plusz a minosegukon akar embereletek is mulnak, ez ennyibe kerul.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Nehany dolgot szeretnek hozzafuzni, nem feltetlenul a te hozzaszolasodra valaszolva, de az eleje ide illik :)
En is szorakoztam olyannal anno, hogy dcmtk segitsegevel DICOM kepeket olvastam, benyomtam egy 3D texturaba es kulonbozo algoritmusok alapjan vizualizaltam, pl. DRR, kulonbozo transfer fuggvenyek alapjan volume rendering, ilyesmi. Ez meg az shaderek elotti idoben volt, szoval nem ma :)
GLSL-lel jol programozhatoak az orvosi kepfeldolgozashoz szukseges, kernel alapu szurok, itt pl. jarhato ut.
A 3D vizualizaciohoz azonban limitaltan hasznalhato csak, megpedig a kartyakon levo relativ keves memoria miatt. Egy mai csucskartyan levo 4GB RAM keves. tapasztalataim szerint a RAM -> GPU es GPU -> RAM adatmozgatas megoli a tejlesitmenyt, tehat akkor hatekony, ha minden muveletet a GPU-n tudunk elvegezni.
A jelenlegi tipikus DICOM kep meretek:
- CT: 512*512*16 bit = 512kB
- MR: 256*256*16 bit = 128kB
- PET: 128*128*? bit
- Cardiac XRAY: 1024*1024*8 bit = 1MB / frame, 30FPS
Egy mai felso kategorias CT gep kepes 2 metert scannelni 5 masodperc alatt es mindekozben 0.3mm-enkent kesziteni egy slice-ot. Ez egy teljes testes scan-nel (1.5m-el szamolva) legalabb 4500 kep, ami 2.25GB.
Egyre inkabb terjednek a CT/PET, CT/MR, CT/MR/PET kepalkotasok, azaz egy paciensrol tobb eljarassal keszitenek kepet, mert mindegyiken mas latszik -> tobb adat
Itt mar a "4D" a meno, ami azt jelenti, hogy tobb sorozat keszul kulonbozo idopontokban ugyanarrol a teruletrol, 5 ill. 10 sorozat sem ritka -> meg tobb adat. Ezzel kuszobolik ki a legzeskor lathato hullamzast, a mozgo szivrol sok felvetel keszul, stb.
A kozeljovoben varhato az 1024*1024 CT-k elterjedese -> 4* tobb adat
A kezelesekhez altalaban szukseg van kontrollra is, ami tobb kulonbozo kepsorozat osszeveteset jelenti, nott/csokkent/stagnalt/hogyan valtozott a tumor / egyeb elvaltozas -> tobb adat
Es ez csak az orvosi adat egy peldanyban, meg nem szamoltunk rajta semmit...
Olvastam cikkeket / lattam videokat 3D textura tomoritesi eljarasokrol, de ezek - enyhen szolva - nem trivialisak, a shadereknek tomoritett adatokon kell dolgozni. Allitolag 8-ad annyi terulet eleg altalaban az adatok tarolasara.
A jogi hatterrol:
Ha egy termekkel embereket diagnosztizalnak / kezelnek, akkor arra nagyon durva jogi szabalyozasok vonatkoznak, altalaban foldrajzi teruletenkent / orszagonkent elteroek, hogy egyszeru legyen!
Mac-re elerheto az Osirix nevu orvosi alkalmazas ingyenesen, tartalmaz patient browsert, DICOM kommunikaciot, media kezelest es alap szintu 2D es 3D viewereket. Szeretik az orvosok, intuitiv a UI-a es allitolag kenyelmes.
Viszont jogilag CSAK kutatasra hasznalhato, mert nincsenek meg szukseges szervek jovahagyasai.
Elerheto belole egy validalt termek, amit bizonyos teruleteken jovahagyattak. De az kemenyen fizetos!
- A hozzászóláshoz be kell jelentkezni
GLSL-lel jol programozhatoak az orvosi kepfeldolgozashoz szukseges, kernel alapu szurok, itt pl. jarhato ut.
Plusz OpenCL v. CUDA. Teljesen jol parhuzamosithatoak ezek a feladatok.
Olvastam cikkeket / lattam videokat 3D textura tomoritesi eljarasokrol, de ezek - enyhen szolva - nem trivialisak, a shadereknek tomoritett adatokon kell dolgozni. Allitolag 8-ad annyi terulet eleg altalaban az adatok tarolasara.
Nem igazan hasznalnam erre, valoban kb. 2-10-szeres a tomoritesi arany, de cserebe elegge vesztesegesek. Ha finom reszleteket akarsz megjeleniteni akkor nagyon rondan szet tudja kenni a kepet.
A tobbivel egyetertek. Ezen eljarasok egyike sem az igenyelt szamitasi kapacitas miatt necces, ezek szinte mindegyike leirhato nehany sorban, hanem a mindenfele memoria es egyeb busz lassu hozza.
Jelenleg a rekordom 64^3-as racson sse-vel 2.5-os C2D-n 3.09ms a poligonizacio. De ez az ertek 96-os racson mar 15ms, 128-on 83. Ahogy no a racs merete (es mint a fentebb szolo is megemlitette mar, a hazai putter CT-k is 512x512-es kepet adnak nagyjabol 1mm-es szeletre) ugy no exponencialisan a mozgatando adat mennyisege. A fenti ertekek i7-en nagyon szepen leesnek kb. a harmadara amig az adatok elfernek a processzorban, amint nagyobb ennel a racs alomszepen latszik, h a memoriara var. GPU-n is ez lesz a szuk keresztmetszet, az on-board ram es a pcie busz sebessege a kritikus.
Bar ez mar nagyon off-topic a tema indito hozzaszolashoz kepest. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
GLSL-lel jol programozhatoak az orvosi kepfeldolgozashoz szukseges, kernel alapu szurok, itt pl. jarhato ut.
Plusz OpenCL v. CUDA. Teljesen jol parhuzamosithatoak ezek a feladatok.
Egy kollega csinalt raytrace alapu volume renderinget GLSL-ben es CUDA-ban is, az altala hasznalt kornyezetben (Linux, uj NVidia driver, Geforce GTX 280) a GLSL renderer 2* gyorsabb volt, mint a CUDA.
Olvastam cikkeket / lattam videokat 3D textura tomoritesi eljarasokrol, de ezek - enyhen szolva - nem trivialisak, a shadereknek tomoritett adatokon kell dolgozni. Allitolag 8-ad annyi terulet eleg altalaban az adatok tarolasara.
Nem igazan hasznalnam erre, valoban kb. 2-10-szeres a tomoritesi arany, de cserebe elegge vesztesegesek. Ha finom reszleteket akarsz megjeleniteni akkor nagyon rondan szet tudja kenni a kepet.
Orvosi adatokra vannak specialis, lossless tomoritesek, tehat ez nem problema. A tomorites miatti kisebb adatforgalom talan ellensulyozni kepes a nagyobb szamolasi igenyt.
Jelenleg a rekordom 64^3-as racson sse-vel 2.5-os C2D-n 3.09ms a poligonizacio. De ez az ertek 96-os racson mar 15ms, 128-on 83. Ahogy no a racs merete (es mint a fentebb szolo is megemlitette mar, a hazai putter CT-k is 512x512-es kepet adnak nagyjabol 1mm-es szeletre) ugy no exponencialisan a mozgatando adat mennyisege. A fenti ertekek i7-en nagyon szepen leesnek kb. a harmadara amig az adatok elfernek a processzorban, amint nagyobb ennel a racs alomszepen latszik, h a memoriara var. GPU-n is ez lesz a szuk keresztmetszet, az on-board ram es a pcie busz sebessege a kritikus.
A tapasztalataink szerint magaban a vizualizacio edeskeves. A dokik olyan alkalmazasokat varnak el, amik a diagnosztikat segitik: automatikusan/felautomatikusan felismernek szerveket (maj, vesek, hugyholyag, ...), verereket keresnek, elvaltozas-gyanus objektumokat talalnak, stb.; azaz jelentosen csokkentik szamukra a munkat.
Ezeknel nem jarhato ut a poligonizacio, mert altalaban nem a surface-re van szukseg (annak csak egy alkalmazasi teruletet ismerem), hanem magukon a suruseg-ertekeken kell egy rakat algoritmust vegrehajtani.
Ettol eltekintve itt is problema a kezelendo adatok novekedese.
Apropo: a poligonizaciot gondolom marching cubes-al vegzed. A "kockakat" hogy bontod fel? Nekunk a 6 db tetraederre bontas gyors volt.
- A hozzászóláshoz be kell jelentkezni
Én írtam saját kódot. 40 tetraéderre bont egy voxelt és elhelyez köztes pontokat is, amelyeknek a helyeit változtathatja. Ezek után a felületet kiegyengetem átlagoló algoritmusokkal is. Egész normális szokott lenni a vége.
Ilyesmi: videó
--
http://www.naszta.hu
- A hozzászóláshoz be kell jelentkezni
Egy kollega csinalt raytrace alapu volume renderinget GLSL-ben es CUDA-ban is, az altala hasznalt kornyezetben (Linux, uj NVidia driver, Geforce GTX 280) a GLSL renderer 2* gyorsabb volt, mint a CUDA
Ezt jo tudni. :)
Orvosi adatokra vannak specialis, lossless tomoritesek, tehat ez nem problema
Erro merre lehet infot talalni? Mert az altalam ismert kartyak csak veszteseget textura tomoritest ismernek hardverbol.
A tapasztalataink szerint magaban a vizualizacio edeskeves. A dokik olyan alkalmazasokat varnak el, amik a diagnosztikat segitik: automatikusan/felautomatikusan felismernek szerveket (maj, vesek, hugyholyag, ...), verereket keresnek, elvaltozas-gyanus objektumokat talalnak, stb.; azaz jelentosen csokkentik szamukra a munkat
Ez evidens. Anno nezegettem ilyeneket (persze csak azokat amik ingyen elerhetoek voltak), mar azok is boven funkciogazdagabbak voltak, mint egy sima rendering.
Apropo: a poligonizaciot gondolom marching cubes-al vegzed. A "kockakat" hogy bontod fel? Nekunk a 6 db tetraederre bontas gyors volt.
Ez van erobol lekodolva, egyelore ez is megfelel az en igenyeimnek, mert nem orvosi meresi eredmenyek megjelenitesere hasznalom.
Ettol eltekintve itt is problema a kezelendo adatok novekedese.
Valoban, e teren minden megoldasnak ez a rakfeneje.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Bevett tömörítési eljárás, hogy úgy tárolnunk adatok, hogy:
- volume egy tömbben van,
- [értékek száma][érték]-ből építjük fel a tömböt. Orvosi képeknél ez hatékony. Pl. (egy bite-os minta): 00001111 az 4041. általában az értékek száma is és az érték is unsigned short nálunk.
--
http://www.naszta.hu
- A hozzászóláshoz be kell jelentkezni
Tulajdonkeppen nalam is hasonloan epul fel most, annyi diffel, h floattal szamolok egyelore, de gondolkodom az unsigned int-en csokkentendo a mozgatando adatok meretet. Csak sse-vel egyszerubb floattal szamolni es a kerekitesi hibak sem akkumulalodnak.
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Bizonyos kepeknel (CT pl.) az emberi testen kivuli regiot el lehet dobni, ott csak levego van. RLE-t hasznalva maris csokkentettuk nehanyszor 10%-al a volume meretet. A subvolume-okat pl. nagyon hatekonyan lehet RLE-vel kodolni (a bitmask-ot, egy 512-es sorhoz altalaban 4 szam eleg.
Az altalad irt kodolasnak tobb dolog is be tud tenni, legalabbis CT esetben mindenkepp:
- ritkak az azonos surusegu szomszedos voxelek
- zajos kep (technoligiabol eredo) eseten ez meg tovabb nonek a kulonbsegek
- egy kis femnek (piercing pl.) durva hatasa lehet a CT-re, lattam olyan kepet, hogy tobb centivel arrebb levo voxelre is volt hatasa.
- A hozzászóláshoz be kell jelentkezni
Orvosi adatokra vannak specialis, lossless tomoritesek, tehat ez nem problema
Erro merre lehet infot talalni? Mert az altalam ismert kartyak csak veszteseget textura tomoritest ismernek hardverbol.
Megprobalok elokeresni valamit. Regen volt es jo ideje nem vagyok kepben.
A tomoritest a shedernek kellett direktben kezelni, ezert is irtam, hogy korant sem trivialis. :)
A tapasztalataink szerint magaban a vizualizacio edeskeves. A dokik olyan alkalmazasokat varnak el, amik a diagnosztikat segitik: automatikusan/felautomatikusan felismernek szerveket (maj, vesek, hugyholyag, ...), verereket keresnek, elvaltozas-gyanus objektumokat talalnak, stb.; azaz jelentosen csokkentik szamukra a munkat
Ez evidens. Anno nezegettem ilyeneket (persze csak azokat amik ingyen elerhetoek voltak), mar azok is boven funkciogazdagabbak voltak, mint egy sima rendering.
Altalaban transfer fuggveny (kulonbozo szervekhez + modalitasokhoz kulonbozo presetek), tresholding illetve clipping a tudasuk nagy resze.
Te talalkoztal egyebbel, pl. komplex algoritmussal szerv kijelolese vagy hasonlo? Ezek joval tobb kutatast + programozast altalaban.
Apropo: a poligonizaciot gondolom marching cubes-al vegzed. A "kockakat" hogy bontod fel? Nekunk a 6 db tetraederre bontas gyors volt.
Ez van erobol lekodolva, egyelore ez is megfelel az en igenyeimnek, mert nem orvosi meresi eredmenyek megjelenitesere hasznalom.
Egy kollegaval anno azt talaltuk ki, hogy egy kockat 6 db tetraederre bontunk fel es minden tetraedert megvizsgalunk, 0, 1, 2 illetve 4 (mind a 4 csucs epp a keresett erteku) haromszog lesz az eredmeny. Az algoritmus egyszeru es gyors, az eredmeny elfogadhato volt.
Ha ugyanezeket a tetraedereket alkalmaztuk mindig, akkor nem volt szep az eredmeny, de koordinatankent paratlan esetben tukrozve a tetraedereket szep haromszog-halot kaptunk.
- A hozzászóláshoz be kell jelentkezni
Megprobalok elokeresni valamit. Regen volt es jo ideje nem vagyok kepben.
Koszonom szepen.
A tomoritest a shedernek kellett direktben kezelni, ezert is irtam, hogy korant sem trivialis. :)
Volt egy ilyen sanda gyanum mikor este atgondoltam azt a postot. :)
Te talalkoztal egyebbel, pl. komplex algoritmussal szerv kijelolese vagy hasonlo?
Nem. Azok a szoftverek mar irgalmatlan sokba kerultek volna ahhoz, h a kivancsisagom kielegitsem. Sajnos meg a VHP adatbazisa is tul draga jatszani.
Egy kollegaval anno azt talaltuk ki, hogy egy kockat 6 db tetraederre bontunk fel es minden tetraedert megvizsgalunk, 0, 1, 2 illetve 4 (mind a 4 csucs epp a keresett erteku) haromszog lesz az eredmeny. Az algoritmus egyszeru es gyors, az eredmeny elfogadhato volt.
Ez eleg jol hangzik, sot, eleg jol parhuzamosithatonak tunik igy elsore. :)
---
pontscho / fresh!mindworkz
- A hozzászóláshoz be kell jelentkezni
Nemcsak a megjelenítésbe, hanem a nyersadatok rekonstrukciójába is betört a GPU. Korábban a cégek proprietary célhardware-t használtak vektorprocesszorokkal. Ezeknél 100x gyorsabb a GPU és 100x olcsóbb. Ezzel elértek a rekonstruktorok abba a sebességtartományba, hogy számítás igényesebb, kifinomultabb rekonstrukciós algoritmusokkal (iteratív rekonstrukció) tudjunk számolni.
Ezúton is köszönetet szeretnék mondani minden hardcore gamer-nek, hogy indirekt módon hozzájárultak az orvosi diagnosztikához - a betegek nevében is.
Persze a cégek nem adják olcsón. A nagy gyártók már most átültették a proprietary alkalmazásaik egy részét GPU alapokra. De a fejlesztésnek megkérik az árát, sok emberóra fekszik benne.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
- A hozzászóláshoz be kell jelentkezni
Nemcsak a megjelenítésbe, hanem a nyersadatok rekonstrukciójába is betört a GPU. Korábban a cégek proprietary célhardware-t használtak vektorprocesszorokkal. Ezeknél 100x gyorsabb a GPU és 100x olcsóbb. Ezzel elértek a rekonstruktorok abba a sebességtartományba, hogy számítás igényesebb, kifinomultabb rekonstrukciós algoritmusokkal (iteratív rekonstrukció) tudjunk számolni.
Anno a Mitsubishi gyartott volume rendering-re kartyat, pl Volume Pro, ajanlottak nekunk is. Az akkori szinten jo es gyors VR-t tudott eloallitani. A marketingeseik boszen halgattak a "mi van, ha az 512^3-nel nagyobb volume-unk van?" kerdesre. :)
Egy rovid ismerteto: http://www.merl.com/papers/docs/TR99-18.pdf
Ezúton is köszönetet szeretnék mondani minden hardcore gamer-nek, hogy indirekt módon hozzájárultak az orvosi diagnosztikához - a betegek nevében is.
Szerintem azert ehhez koze lehet a SGI-tol a NVidia-hoz atment mernokoknek is :)
Jo iranyba (GPGPU) terelgettek a fejlodest, ok ugyanis nem a gamer market felol erkeztek.
Anno a CT/MR/PET rekonstrukciohoz tenyleg sajat tervezesu / kis peldanyszamban eloallitott hw (DSP) kellett, ennek megfeleloen jo draga volt, tizezer dollaros nagysagrendrol beszelek.
Par evvel ezelott mar az "altalanos celu" rendszerekre is lehetett alapozni, hallottam pl. Cell-el vegzett rekonstrukciorol. Ezeken meg gondolom meglehetosen sokat kellett faragni, a Cell programozasa allitolag nem trivialis.
A GPU a kovetkezo lepcso, ezek az eszkozok olcsok - professzionalis eszkozok szintjen es nem a gamer kartyaken -, jol ismert fejlesztoi eszkozokkel: C/C++, GLSL/CUDA/OpenCL.
Lattam adatokat ilyen, prototipus szintjen allo rendszerrol, az elso verzio 3* akkora FPS-t tudott, mint az elozo generacio, talan valami nem high-end Quadro board-on.
Annak ellenere, hogy egyszerubb a fejlesztes, nagyon sokba kerul, ahogy te is irtad: a rekonstrukciok eredmenye alapjan kezelnek embereket, igy nem a 'ha nem stimmel a pixel erteke, a gamer ugy sem latja 50FPS mellett' kategoria.
- A hozzászóláshoz be kell jelentkezni