Panorama-Video mit SDL

MG80S

Hallo zusammen, wollte eigentlich fragen, ob ich ein Problem mit SDL realisieren kann, aber wenn ich mir die Themen hier anschaue.....ja, das sollte wohl gehen.

Dennoch die Geschichte:
Ich brauche eine Anwendung, in der ich mich in einem Panoramavideo frei drehen kann. Habe also ein hübsches rechteckiges Video mit allen Bildinformationen und möchte dieses als Panorama wiedergeben.
Ich dachte mir, ich könnte jeden Frame des Videos auf die Inneseite eines Zylinders mappen und dann eine Kamera in die Mitte sellen. Ist das möglich?

Sollte vielleicht dazu sagen: Habe bis jetzt noch nicht wirklich viel Ahnung von SDL, habe mal angafangen mit DirectX und aufgrund meines jetzigen Problems mit SDL. Allerdings bis jetzt nur 2D-Scrolling-Tutorials
Aber wenn mir jemand sagen könnte, dass die Sache prinzipiell lösbar ist, fang ich wohl mal richtig an.

Vielen Dank schonmal...M

rapso

für diesen einfachen effekt mußt du nichts in 3d machen, spiele wie myst usw machen das auch nur mit 2d (was nicht heiß, dass ich dir von SDL abrate!)
aber mal ne frage aus neugierde, wie nimmst du ein panorama video auf? oder ist es ein rendering?, kannste mal ein screen posten?

rapso->greets();

MG80S

Das PanormaVideo kann man aufnehmen, indem man mit einer Fisheye-Linse etwas filmt. Damit hat man (fast) 360°-Aufnahmen, jedoch stark verzerrt. Die kann man dann entzerren et voila, Panorma. Darf leider nicht zuviel über Techniken verraten, da unsere Idee recht neu ist, aber das sind die Grundzüge.
Aber um nochmal auf Deinen Post zurückzukommen:
Du meinst, ich kann also das 3D-Bild auf 2D umrechnen und dann einfach so darstellen. Meinst Du das? Das klingt prinzipiell auch sehr gut.
Habe heute gehört, SDL ist wohl nicht so geeignet, da es 100% Rechenpower braucht, egal wie simpel die Anwendung ist(wegens aktivem Warten). Ist das so?

rapso

1. naja, wenn es für ein spiel ist, ist es normal dass es 100% braucht.
2. es gibt ja noch immer noch Sleep(10) damit weniger last erzeugt wird.
3. wenn du weißt, wie du das bild entzerrst, dann weißt du wohl auch wie du es auf z.b. 90° wieder verzerrst, wobei man das unabhängig von irgendeiner api machen kann, also bloss c++ und cpu

naja, und das mit den 180° finde ich beeindruckend für filme, ich kenne das bisher nur für photos.

rapso->greets();

LiquidAcid

Kann mir nicht vorstellen wie man mit Fisheye "fast 360 Grad" hinbekommen soll, für mich geht das allein theoretisch schon nicht, da die Cam ja irgendwo steht. Wärens wirklich 360 Grad dann würde die Cam ja auch immer auf dem Bild drauf sein, oder sehe ich das jetzt falsch? Da könnte ich mir höchstens vorstellen, dass die Cam nach beiden Seiten hin "offen" ist und jeweils 2 180 Grad Aufnahmen reinbekommt. Aber so...

geloescht

eine "fast-360°-fisheye-linse" wäre ja praktisch eine kugel, ich kann mir auch nicht vorstellen, wie das gehn soll. aber das ist gottseidank nicht mein problem.
zum 100%-prozessoerauslastungsproblem: da du in echtzeit das video verzerren musst (damit die panorama-ansicht auch schön 3d-ähnlich aussieht) wirst du sowieso praktisch immer 100% prozessorauslastung haben (kommt natürlich auch auf die auflösung und qualität an) Aber auch mit SDL kommt eine weitgehend plattformunabhängige warte-funktion, ich weiß grad nur den Namen nicht mehr Falls du also mal Zeit übrig haben solltest, kannst du sie einfach verwarten. Allerdings sollte man der Funktion immer ein paar Millisekunden weniger übergeben, als man braucht, da Multitaskingbetriebssysteme öfters die Angewohnheit haben, zu lange zu warten.
geloescht

Sgt. Nukem

LiquidAcid schrieb:

Kann mir nicht vorstellen wie man mit Fisheye "fast 360 Grad" hinbekommen soll, für mich geht das allein theoretisch schon nicht, da die Cam ja irgendwo steht.

Yo, aber 320 könnte man ja schaffen... und das sind doch schon "FAST" 360°

Oder er meint Neugrad.

durito

Hm, versteh ich das richtig?..

OpenGL -> Skybox -> Video auf Skybox ?

rapso

durito schrieb:

Hm, versteh ich das richtig?..

OpenGL -> Skybox -> Video auf Skybox ?

fast
-SkyBox + SkyCylinder

rapso->greets();

durito

yep, das dürfte ja dann nicht zu schwierig sein.

Solang keiner auf die Idee kommt nach oben zu schauen

MG80S

Woah, ein reges Treiben hier. Erstmal vielen Dank für Eure Aufmerksamkeit und Tipps. Und hier ein paar mehr Infos wegens dem regen Interesse.
Also, erstmal sorry, die 360° waren (natürlich) übertrieben. Aber man bekommt immerhin ein 2D-Abbild mit 360°x340° hin, immerhin....
Wer mal Bilder sehen will:

http://mitglied.lycos.de/mg80s
Da die pics.zip isses.

test1.jpg ist die Originalaufnahme, musste nur die oberen und unteren Ränder abschneiden, da mein Algorithmus noch recht unflexibel arbeitet....
test3.jpg ist das Gleiche mit ein paar Hilfsmarkierungen.
test3_entzerrt.jpg ist dann das entzerrte Bild, jedoch mit nem gaaanz schlechten Algorithmus. Wird (bzw. ist) schon verbessert, aber das war erstaml so zum Rumtesten, wies überhaupt aussehen kann.

Die Performance brauche ich, weil das ganze eigentlich als Plugin gedacht ist und somit der Alg nicht der einzige ist. Aber umsomehr ich darüber nachdenke, um so besser gefällt mir die "3D-Emulations-Idee". Das hat was und ist in diesem Fall wahrscheinlich auch das beste. Vielen Dank dafür.

Dann wünsch ich Euch ertsmal eine geruhsame Nacht (eher mir?)...M

rapso

emm 360°x340° wären da wohl schon zwei bilder ;), ist aber ne schöne cam die euch da die parabolidfotos/videos macht

rapso->greets();

MG80S

MG80S schrieb:

Aber man bekommt immerhin ein 2D-Abbild mit 360°x340° hin, immerhin....

Damit meinte ich auch, wenn man das Ding entzerrt, kann man "sozusagen" horizontal 360° sehen, vertikal 340°.

illuminator

So wie ich das seh müsstest du dein Bild als Textur auf die Innenseite einer (unten ein bisschen offenen) Kugel projezieren und die Kamera in die Mitte hinein stellen.
Man müsste sich halt über die Texturkoordinaten ein wenig Gedanken machen, je nachdem von welchen Bildformat man ausgeht ...

rapso

Quick&Dirty würde es so aussehen. wobei das natürlich besser geht. ich benutze hier nur das Nehe tutorial (also oGL) um das berechnete bitmap (256*256) in eine texture zu stecken und dann als quad darzustellen (geht fixer als DIB oder DD).

wobei das noch nicht performance optimiert ist, optimiert würde das sicherlich auch auf meinem gba laufen, die qualität des jpg ist scheisse und ich hab nirgens filtering an.. quick&dirty eben.
mit der linken maustaste kann man rotieren,
mit dem mausrad ne art FOV einstellen (FISCHAUGE*alarm* )

und wie gesagt, alles nur 2d operationen.

rapso->greets();

MG80S

Woah, krasse Sache! Vielleicht "Quick&Dirty", darür aber sehr zweckmäßig.
Jetzt also doch OpenGL? War eingentlich gerade dabei die 3D-Geschichte in 2D-Koordinaten umzurechnen? Oder hast Du das vorher auch gemacht?
Wenn ja: Ich hab da irgendwie noch nen Logik-Fehler drin:
Wenn ich von vorn auf einen Cylinder schauen, habe ich ja theoretisch in den Aussenbereichen meines "Blickwinkels" mehr Bildinformationen, da ich hier mehrere Pixel der Krümmung auf eine 2D-Ebene projeziere. Wie man ja an Deinem Prog auch sehr gut sieht, sind in den Aussenbereichen ja viel weniger Infos, was die Pixel ordentlich auseinanderzieht.
WHY?!?
Hängt das mit dem "menschlichen Auge" bzw. Linsen im Allgemeinen zusammen?
Habe dann aufgrund der Beobachtung versucht, eine Funktion der neuen Pixel auf alte (Originalbild) zu schreiben. Habe es per Tangens und x³ versucht um in den Aussenbereichen weniger Infos zu haben als innen, aber irgendwie stellt mich das noch nicht zufrieden.
Mal nebenbei: Hast Du mal die fps Deines Progrs gemessen? Für den Fall, dass ich mich z.B. immer drehe oder ähnliches. Würde mich mal interessieren (auch ohne perfekte Perfomance). Meine ist nämlich (noch) ziemlich grottig.

Tiefsten Respekt ... M

MG80S

Und nochmal @rapso:

Du suchst nicht ganz zufällig einen mäßig gut bezahlten, dafür aber sehr interessanten Nebenjob?

Die o.genannte Sache ist nämlich gerade im Aufbau.

Nunja, ich meld mich wieder, wenn ich auch mal n Ansatz fertig habe....... M

rapso

das programm hat zur zeit ca 50fps, wobei es zum einen langsammer werden würde wenn man für das bild lineare filterung einbauen würde, auf der anderen seite kann man einiges vorberechnen (was ich mir wegen Quick&Dirty ersparrt habe ) und das würde das programm wiederrum viel fixer machen.

wie ich schon gesagt habe, benutze ich openGL nur zur darstellung der textur in die ich das fertigberechnete bild reinstecke, das ist vom programmieraufwand am fixesten.

das mappen muss eigentlich auf eine sphere und nicht auf einen cylinder. normalerweise würdest du ja so projezeiren für euer parabolidbild

laenge = sqrt(x*x+y*y+z*z);
x'=x/laenge;
y'=y/laenge;

nun mußt du die projektion umkehren damit das photo auf den bildschirm 'reprojeziert' wird, dabei hast du natürlich das problem dass du kein z hast, das mußt du dir ausdenken (darüber wird dann die stärke des fischaugeneffekts gesteuert ).
es bietet sich an von -1.f bis +1.f für x und y zu gehen, dann kann man fürs erste ein z von ca 1.f wählen. (die schritweite ist natürlich 2.f/SizeX bzw 2.f/SizeY).

emm.. ja, hab ich was vergessen?

rapso->greets();

rapso

MG80S schrieb:

Und nochmal @rapso:

Du suchst nicht ganz zufällig einen mäßig gut bezahlten, dafür aber sehr interessanten Nebenjob?

just drop me a mail

rapso->greets();