Acum as dori sa fac o aplicatia care sa poata reda traiectoria sub forma de film. Am gasit ca pentru Linux ar fi Qt pe baza de C++, dar e mult de munca cu instalarea. Ma gandesc si la un applet Java. Va voi tine la curent.
Ai putea sa desenezi direct datele in imagini, folosind de exemplu LibTIFF, pe care apoi le pui impreuna intr-un film. Cred ca exista deja biblioteci de functii pentru asta, sau poti folosi mplayer/mencoder care s-ar poate lansa dintr-o aplicatie C/C++.
Intr-adevar, rolul actual al masinii e acela de a automatiza, daca ai folosit masina pentru a calcula coordonatele, trebuie sa elimini partea manuala in care trimiti coordonatele spre procesare ulterioara, cu alte cuvinte sa faci un singur program care se ocupa de intregul proces: - tu introduci parametrii , el iti furnizeaza filmul dorit.
Sugestia de mai sus e bine aleasa, LibTiff, impreuna cu alte librarii pentru formate grafice libpng sau libjpg iti vor permite sa renunti la GnuPlot: programul tau va calcula coordonatele si va produce imagini statice pentru fiecare set de coordonate.
Fara a folosi librarii, unde un minim de experienta in programare e de dorit, poti reprezenta coordonatele grafic si produce imagini BMP, care au o alcatuire asa de simpla, incat nu ai nevoie de librarii externe.
Idea ar fi urmatoarea:
- iti propui o rezolutie maxima de lucru, sa spunem 800x600, pentru a nu ingreuna procesorul
- vizualizezi aceasta suprafata ca un sistem cartezian
- desenezi punctele corespunzatoare traiectoriei planetei
- desenezi alte informatii , cum ar fi: pozitie, timp, parametrii folositi, intr-un colt al suprafetei
- salvezi suprafata intr-un format grafic
BMP, nu este altceva decat un header (BM...) + o colectie de puncte reprezentate prin culoare. Pentru a reprezenta punctul, intram in mai multe detalii, si anume adancimea de culoare:
Formatul cel mai des utilizat e RGB24, in care se folosesc 8 biti pentru rosu, 8 pentru verde si 8 pentru albastru. Astfel avem 2^8 nuante de rosu, 2^8 nuante de verde si 2^8 nunte de albastru.
00000000 va fi cel mai inchis rosu, in timp ce 11111111 va fi cel mai puternic/viu/colorat rosu. Pentru un punct reprezentat in RGB24 vom avea asadar 2^24 culori posibile.
000000000000000000000000 reprezinta negru
111111111111111111111111 reprezinta alb
Revenind la BMP, dupa headerul initial, BMP-ul contine multimea de 800x600 puncte, un total de informatie de 800x600x24biti. Daca imaginea ta este complet neagra, fisierul BMP va contine dupa haeder doar zero-uri.
Din total commander se poate verifica acest lucru deschizand cu F3 imagini BMP, eventual negre
Adancinmea de culaore poate fi si de 16 biti, de 8 biti, sigur calitatea culorii este redusa, 8 biti insemnand un numar de 256 de culori posibile.
Daca aceste informatii sunt necesare pentru scriereaa unui BMP, celelalte formate sunt mai complicate. Sa privim putin formatul JPG . A fost introdus pentru a oferi o mai buna compresie a informatiei reprezentate. Problema se pune in felul urmator: daca Adi reprezinta un sistem solar intr-o imagine de 800x600, dar nu deseneaza nici o planeta sau soare, va avea o imagine neagra, care va necesita spatiu de stocare in format BMP: header (neglijabil) + 800x600x3Bytes, si tot ce vom stoca vor fi zero-uri. E o risipa.
Nu ar fi mai eficient sa stocam informatia in felul urmator:
dreptunghi de la 0,0 la 800,600 , de culoare negra?
Cam asa functionaza JPG, aproximeaza zone de nuante apropiate la o singura culoare, si nu mai retine o multime de puncte ci o definitie a unei zone. Ca un exercitiu salvati o imagine cu detalii (o poza din vacanta) in format JPG la calitate minima (0) . Veti vedea ca zonele patratoase sunt evidente: practic calitatea JPG se refera la pragrul de aproximare al nuantelor apropiate: calitate mica inseamna ca tot mai multe nunte sunt sudate intr-o singura culoare.
Pentru reprezentari video, lucrurile devin si mai complicate. Un fisier Video are ca si fisierele imagine o anumita structura, si un fel de a reprezenta informatia. Facem abstractie de sunet, in cazul de fata, si ne usuram situatia.
Un film pentru a da impresia de naturalete animatiei trebuie sa ruleze 25 de cadre pe secunda. Daca cadrele noastre sunt sistemul planetar al lui Adi, ar inseamna 25 de cadre la rezolutie de 800x600. Daca informatia nu este comprimata in nici un fel inseamna ca fiecare secunda necesita un spatiu de 25x800x600x3 bytes = 36MB . O ora de film ar ocupa 129600MB, adica 129GB . Si asta fara sunet. Cat are hardul vostru?
Si aici se folosesc tehnici de compresie asemanatoare celei descrisa pt JPG. Cel mai bun lucru, Adi, ar fi sa creezi un format [GIF animat], care nu e altceva decat un format grafic cu un header in care se defineste rezolutia si un numar de cadre, si un delay dupa fiecare cadru, dupa care imaginile sunt concatenate intr-un singur fisier. Nu foloseste sunet nenecesar pentru scopul tau , si e abordabil din punct de vedere al programarii.
