Kamerafahrt über ein Bild realisieren

[flipdascript]

Hallo zusammen!

Ich weiß nicht ob ich den richtigen Titel gewählt habe.
Ich möchte ein Programm schreiben, das in einem Fenster Bilder anzeigt die viel größer als das Fenster selbst sind.
Das ganze soll animiert werden, so dass der tatsächlich angezeigte Bereich sich ändert, quasi als würde man durch eine Kamera auf das Bild schauen und die Kamera würde sich bewegen. Es sollte auch möglich sein, den aktuellen Zoom anzupassen, so dass ein größerer Bereich des Bildes im Fenster dargestellt wird.

Mein Problem ist nun, dass ich mich mit dem Thema Animationen quasi gar nicht auskenne. Ich habe sehr gute Kenntnisse von Delphi allgemein und kenne mich einigermassen mit GDI+ aus. Meine GDI+-Erfahrung beschränkt sich aber auf statische Bilder.
Ich habe es schon ganz billig mit Timer und selbstzeichnen auf ein Control ausprobiert, das ist aber leider zu langsam. Meine Frage ist nun ob mir jemand sagen kann wie ich das am Besten realisiere oder ob es alternative Suchbegriffe nach denen ich suchen könnte. Ich finde nämlich keine brauchbare Übersetzung von Kamerafahrt und bekomme Myriaden an Tutorials wie man eine Kamera im 3D-Raum bewegt.
Vermutlich ist das der Wink mit dem Zaun und ich komme an DirectX nicht vorbei?

Die Bilder können übrigens bis zu 70 MP groß sein...

[Perlsau]

Was du realisieren möchtest, benötigt keine speziellen Animationskenntnisse, sondern eine Scrollbox, in die du dein TImage legst, selbiges auf AutoSize stellst, Left und Top des TImage auf 0 stellst und ein Bild hineinlädst. Durch das Property AusoSize paßt sich das TImage der Bildgröße automatisch an. Ist das TImage nun größer als der Clientbereich der Scrollbox, erscheinen in selbiger Scrollbalken, mit denen du Ausschnitte des Bildes anzeigen kannst – wie in jedem Mal- und Grafikprogramm üblich.

[himitsu]

Zitat:

70 MP

Was du hier erstmal optimieren kannst, ist das Bild aufzuteilen ... dann sind keine Operationen auf "große Datenmengen" nötig und es kann schneller ablaufen.

Warum jedesmal all 70 MP verarbeiten, wenn man doch nur maximal 2 MP davon braucht? Je menr Daten man verarbeiten muß, um so langsamer wird es. :zwinker:
Auch hängt es von den Zoommechianissmen an, denn es gibt Langsamere und Schnellere, aber dank vorberechnerer Zwischenbilder kann man auch da schneller arbeiten.

Sieh dir mal Google-Maps und Dergleichen an.
Dort gibt es das Bild in kleineren Stücken und vorallem schon fertig in verschiedenen Größen/Zoomstufen.
So brauch man nicht mehr all zu stark zoomen, da man bei großen Zoomstufen bereits auf ein kleineres Bild zugreifen kann.
und man braucht auch nur die Bildausschnitte zu behandeln, welche überhaupt sichtbar sind.

[Namenloser]

Zitat:

Zitat von flipdascript (Beitrag 1284914)

Die Bilder können übrigens bis zu 70 MP groß sein...

Das ist wohl der Knackpunkt. Vorschlag: Zerhacke das Bild in viele kleine Kacheln in einer handlicheren Größe wie 512×512 Pixel und zeichne nur die Kacheln, die gerade im sichtbaren Bereich liegen. Um unterschiedliche Zoomstufen zu unterstützen, halte Kacheln in verschiedenen Detailstufen vor (vgl. https://de.wikipedia.org/wiki/Mip_Mapping)

Die Technik kennst du von Google Maps.

[Mavarik]

Die eigentliche Frage ist doch:

Woher kommen die Bewegungs- und Zoomdaten?
Willst Du das "OnTheFly" berechnen oder einen Film davon erzeugen?

Mavarik

[Bjoerk]

Die 70 MP machen einen ja fertig? Wenn du nur Delphi Werkzeuge verwenden willst: z.B. das Bild in eine Metafile erträglicher Größe umwandeln und dann ganz klassisch zoomen. Scrollbox, Paintbox rein, Paintboxabmessungen aus dem Zoom setzen und ein Strechdraw der Metafile in Paintboxpaint. Die Scrollbox ggf. doublebuffered setzen. Um einen Punkt zommen ist etwas tricky, geht aber. Ich hab hier zum Teil DIN A0 Pläne (ca. 15 MP), da geht's so sehr gut.

[flipdascript]

Zitat:

Zitat von Perlsau (Beitrag 1284916)

Was du realisieren möchtest, benötigt keine speziellen Animationskenntnisse, sondern eine Scrollbox, in die du dein TImage legst, selbiges auf AutoSize stellst, Left und Top des TImage auf 0 stellst und ein Bild hineinlädst. Durch das Property AusoSize paßt sich das TImage der Bildgröße automatisch an. Ist das TImage nun größer als der Clientbereich der Scrollbox, erscheinen in selbiger Scrollbalken, mit denen du Ausschnitte des Bildes anzeigen kannst – wie in jedem Mal- und Grafikprogramm üblich.

Das wäre natürlich eine Option. Ich befürchte nur, dass das noch langsamer wäre als das was ich bisher habe.

Zitat:

Zitat von himitsu (Beitrag 1284917)

Was du hier erstmal optimieren kannst, ist das Bild aufzuteilen ... dann sind keine Operationen auf "große Datenmengen" nötig und es kann schneller ablaufen.
Warum jedesmal all 70 MP verarbeiten, wenn man doch nur maximal 2 MP davon braucht? Je menr Daten man verarbeiten muß, um so langsamer wird es. :zwinker:

Das ist richtig. In meinen bisherigen Tests habe ich auch nur 6MP Bilder verwendet, und auch das ist alles andere als flüssig.

Zitat:

Zitat von himitsu (Beitrag 1284917)

Auch hängt es von den Zoommechianissmen an, denn es gibt Langsamere und Schnellere, aber dank vorberechnerer Zwischenbilder kann man auch da schneller arbeiten.
Sieh dir mal Google-Maps und Dergleichen an.
Dort gibt es das Bild in kleineren Stücken und vorallem schon fertig in verschiedenen Größen/Zoomstufen.
So brauch man nicht mehr all zu stark zoomen, da man bei großen Zoomstufen bereits auf ein kleineres Bild zugreifen kann.
und man braucht auch nur die Bildausschnitte zu behandeln, welche überhaupt sichtbar sind.

Die verschiedenen Interpolations-Modi kenne ich. Das mit dem Aufteilen in Kacheln ist eine gute Idee. Bevor ich mir darüber Gedanken machen kann, muß ich es aber erstmal halbwegs performant für kleinere Bilder hinbekommen.

Zitat:

Zitat von Namenloser (Beitrag 1284918)

Zitat:

Zitat von flipdascript (Beitrag 1284914)

Die Bilder können übrigens bis zu 70 MP groß sein...

Das ist wohl der Knackpunkt. Vorschlag: Zerhacke das Bild in viele kleine Kacheln in einer handlicheren Größe wie 512×512 Pixel und zeichne nur die Kacheln, die gerade im sichtbaren Bereich liegen. Um unterschiedliche Zoomstufen zu unterstützen, halte Kacheln in verschiedenen Detailstufen vor (vgl. https://de.wikipedia.org/wiki/Mip_Mapping)
Die Technik kennst du von Google Maps.

Jep. Werde ich, wenn ich die Performance für kleinere Bilder hinbekommen, mal ausprobieren.

Zitat:

Zitat von Mavarik (Beitrag 1284919)

Die eigentliche Frage ist doch:
Woher kommen die Bewegungs- und Zoomdaten?
Willst Du das "OnTheFly" berechnen oder einen Film davon erzeugen?
Mavarik

Das ist eigentlich weniger das Problem. Die Bewegungen sind relativ simpel und ich würde die on-the-fly berechnen.

Zitat:

Zitat von Bjoerk (Beitrag 1284925)

Die 70 MP machen einen ja fertig? Wenn du nur Delphi Werkzeuge verwenden willst: z.B. das Bild in eine Metafile erträglicher Größe umwandeln und dann ganz klassisch zoomen. Scrollbox, Paintbox rein, Paintboxabmessungen aus dem Zoom setzen und ein Strechdraw der Metafile in Paintboxpaint. Die Scrollbox ggf. doublebuffered setzen. Um einen Punkt zommen ist etwas tricky, geht aber. Ich hab hier zum Teil DIN A0 Pläne (ca. 15 MP), da geht's so sehr gut.

Das ist vermutlich nicht performant genug. Ich werds aber einfach mal ausprobieren.

Im Grunde soll das sowas ähnliches werden wie die Lockscreen-Slideshow von Windows 8, falls die jemand kennt.

Was ich bisher versucht habe:
- Timergesteuert auf die Zeichenfläche des Formulars zeichnen. Das flackert und ist träge.
- Zeichnen in OnPaint des Formulars und timergesteuert das Formular invalidieren. Das flackert nicht, ist aber sehr träge.
- Zeichnen in OnPaint des Formulars und in OnPaint das Formular invaldiieren. Das flackert nicht, ist aber sehr träge und ist vermutlich generell keine so gute Idee ;P

Mein eigentliches Problem ist also primär, dass ich nicht weiß wie ich es hinbekomme, ein Control so upzudaten, dass die "Animation" flüssig aussieht.

[Jens01]

OpenGL

[Namenloser]

Was auch noch zu berücksichtigen ist: TTimer hat keine besonders feine Auflösung. Je nach dem, was für dich flüssig bedeutet, kann auch das schon der Knackpunkt sein. 60 FPS und mehr sind mit TTimer eher problematisch. Google mal nach "Game Loop" für Alternativen.

[Popov]

@flipdascript

Ich hab zwar nicht ganz verstanden was du brauchst, aber da ich in der letzten Zeit wenig geprogt habe und vor Ende des Jahren nochmal Delphi anwerfen wollte, habe ich etwas geschrieben. Vielleicht ist es das was du brauchst (vielleicht auch was anderes).

Das Programm ist selbsterklärend, zuerst aber ein Bild laden.

[flipdascript]

Hallo Popov!

Das kommt dem was ich mir vorgestellt habe sehr nahe. Danke!

Muß heut abend mal schauen was Du da groß anders machst. Habe das grad nur kurz kompiliert und ausprobiert.

[Garfield]

Du meinst Pan & Scan?

Wenn es nicht alles in Delphi sein muss kann man auch Avisynth zu Hilfe nehmen. Da kann man zum Beispiel Slideshows erstellen.

[Popov]

@flipdascript

Das "Problem" ist, dass der Timer das Problem ist. Dass eine Prozeduren in 1/1000 Sekunde aufgerufen werden können, ist eher ein urbaner Mythos. Erfahrungsgemäß (ob gefühlt oder tatsächlich) sind es eher 10/1000, womit das Bild pro Sekunde nur um die 100 Pixel verschoben werden kann.

--Schnipp--

Um mein Gefühl zu überprüfen habe ich gerade einen Counter geprogt. Wenn ich da keinen Gedankenfehler habe, dann zählt der Timer wie oft er in der Sekunde aufgerufen wird (benötigt wird ein Timer und ListBox):

Delphi-Quellcode:

uses
  DateUtils;

var
  S1, S2, T: Word;

procedure TForm1.Timer1Timer(Sender: TObject);
begin
  S1 := SecondOfTheHour(Now);
  if S1 <> S2 then
  begin
    ListBox1.Items.Add(IntToStr(T));
    T := 0;
  end;
  Inc(T);
  S2 := S1;
end;

procedure TForm1.FormCreate(Sender: TObject);
begin
  Timer1.Interval := 1;
end;

Bei mir sind es 64 mal (ist ja auch ein alter Rechner).

Die "Lösung": pro Takt nicht ein Pixel verschieben, sondern mehrere Pixel.

[pelzig]

(Application.)OnIdle wird völlig überschätzt :thumb:

Deshalb sollte es hier auch nicht erwähnt werden!

MfG

[Garfield]

Zitat:

Zitat von Popov (Beitrag 1285195)

Dass eine Prozeduren in 1/1000 Sekunde aufgerufen werden können, ist eher ein urbaner Mythos. Erfahrungsgemäß (ob gefühlt oder tatsächlich) sind es eher 10/1000, womit das Bild pro Sekunde nur um die 100 Pixel verschoben werden kann.

Was willst Du mit 1000 Bildern je Sekunde? Schafft das Dein Bildschirm überhaupt?

Soweit ich das sehe wird SDTV mit 25 und HDTV mit 50 Bilder je Sekunde ausgestrahlt. Ein guter analoger Videorecorder hat ebenfalls 50 Bilder je Sekunde. Normal sollten 50 bis 60 Bilder je Sekunde vollkommen ausreichen.

[Popov]

Mein Fernseher läuft mit 400Hz, das mag mein Kanarienvogel. Der guckt schneller als ich ;)

Zum Thema...

Ich denke 1000 Bilder pro Sekunde sind nicht das Begehren des TE, sondern eher 1000 Schritte in der Sekunde, so dass ein Bild zur Not 1000 Pixel pro Sekunde gescrollt werden kann. Das kann man aber auch anders erreichen - einfach paar Pixel überspringen.

[Garfield]

Schön, dass Dein Fernseher 400 Hz hat. Meiner hat nur 100 Hz und zeigt damit nicht weniger Bilder in der Sekunde an als Deiner. 8-)

Wozu 1000 Schritte tun, wenn nur jeder 20. wahrgenommen wird? Dann reichen 50. Also nicht 1000 * 1 sondern dann 50 * 20.

[Sir Rufo]

Wer glaubt bei 400Hz auch 400 Bilder/s zu bekommen, der liest sich einmal dieses hier durch
http://www.hifi-forum.de/viewthread-133-7149.html

Es geht dabei nicht ums schlecht reden oder machen, sondern nur um die Klarstellung, was es mit diesen 100/200/400Hz auf sich hat.

[cbspeda]

Hi schau dir mal diese Komponente an:

http://www.imageen.com/info/index.html

lg Peter

[flipdascript]

Zitat:

Zitat von Garfield (Beitrag 1285159)

Du meinst Pan & Scan?

So ähnlich ja. Die Bewegung soll halt nur automatisch geschehen und es soll auch möglich sein zu zoomen.

Zitat:

Zitat von Garfield (Beitrag 1285159)

Wenn es nicht alles in Delphi sein muss kann man auch Avisynth zu Hilfe nehmen. Da kann man zum Beispiel Slideshows erstellen.

Ich würde das lieber in Delphi umsetzen. Wäre aber evtl. als Prästentationsworkaround denkbar ;P

Zitat:

Zitat von Popov (Beitrag 1285195)

@flipdascript
Das "Problem" ist, dass der Timer das Problem ist. Dass eine Prozeduren in 1/1000 Sekunde aufgerufen werden können, ist eher ein urbaner Mythos. Erfahrungsgemäß (ob gefühlt oder tatsächlich) sind es eher 10/1000, womit das Bild pro Sekunde nur um die 100 Pixel verschoben werden kann.

--Schnipp--

Die "Lösung": pro Takt nicht ein Pixel verschieben, sondern mehrere Pixel.

Das hakt leider ab und an, egal ob ich nur um einen, oder gleich um mehrere, Pixel verschiebe.

Zitat:

Zitat von Popov (Beitrag 1285212)

Ich denke 1000 Bilder pro Sekunde sind nicht das Begehren des TE, sondern eher 1000 Schritte in der Sekunde, so dass ein Bild zur Not 1000 Pixel pro Sekunde gescrollt werden kann. Das kann man aber auch anders erreichen - einfach paar Pixel überspringen.

Mein primäres Ziel ist es, dass die Bewegung flüssig dargestellt wird. Ich brauche keine 1000 Bilder die Sekunde. Die Windows 8 Locksceen Slideshow kommt dem was ich gern hätte noch am nähsten.

Hier ein Video in dem man sich das anschauen kann:
https://www.youtube.com/watch?v=lHoPCy1an8w

Zitat:

Zitat von cbspeda (Beitrag 1285342)

Hi schau dir mal diese Komponente an:

http://www.imageen.com/info/index.html

lg Peter

Werd ich machen. Danke für den Tip!

[Popov]

@flipdascript

Also die Flüssigkeit in anderen Programmen kommt ja nicht davon, weil da mehr Zwischenschritte sind. Ich weiß das, weil ich im Grunde einen alten PC habe und wenn ich ein aktuelles Game drauf ausführe, z. B. bei einem 3D Shooter, dann sehe ich die Bewegungen auch (sozusagen) in Zeitraffer. Da springt das Bild auch alle paar Meter weiter.

Du solltest die Bewegung nicht unbedingt Schritt für Schritt zeigen, sondern Zeitabhängig. Damit meine ich, dass immer nur das Bild gezeigt wird, das zu dieser bestimmten Zeit auch gezeigt werden sollte, und nicht jedes Frame nach und nach. Das Auge kompensiert das und alles wird flüssig.

Mal etwas verständlicher: nehmen wir an du hast eine Animation mit 24 Bildern pro Sekunde. Nach einer 1/2 Sekunde hackt es für eine 1/4 Sekunde, weil ein anderes Programm kurz etwas mehr Leistung brauchte. Nun gibt es das Problem, dass nach der 1/2 Sekunde einen Aussetzer für 1/4 Sekunde gibt. Wie soll der behandelt werden? Sollen die fehlenden 6 Frames gezeigt werden? Das ist die Menge Frames die in einer 1/4 Sekunde gezeigt werden. Werden die 6 Frames nachgeschoben, merkt man den 1/4 Sekunde Aussetzer. Werden sie verworfen, eher nicht.

Ich hab mal an einer Animation gearbeitet und ein ähnliches Problem wie du gehabt. Das Hacken sieht man nur wenn man unbedingt jeden Schritt zeigt. Stattdessen sollte man an der Zeit orientieren.

[Sir Rufo]

@Popov :thumb:

Es ist viel wichtiger, dass sich ein Objekt nach dem Neuzeichnen an der erwarteten Stelle befindet, als alle Zwischenschritte auch wirklich anzuzeigen.