Bildverlust bei avi über GIGe

Hey,

also hab mich an einen älteren Post gehalten und etwas zusammengeklickt. Scheint aber immer noch nicht recht zu laufen. Skipped frames werden zu null angezeigt, doch das bringt ja nix, wenn er die in den Buffer schreibt und ich bei beenden des Programms einen vollen Buffer, doch kein komplettes *.avi erhalte..

Hast Du eine Idee zu der Struktur, wie ich sie jetzt habe?

Vielen Dank

Hey Kasi,

vielen Dank für Deine und die Unterstützung aller.

Problem ist gelöst. Einfach LV nicht zwingen anzuzeigen was die Kamera sieht und schon klappts auch mit dem avi

Komme jetzt auf volle Bildrate. Bei der mitgelieferten Software geht das simulaten Anzeigen zwar auch noch, doch was solls. Wenn dazu noch wer eine Idee hat, dann bin ich dafür klar dankbar.

Bis zum nächsten Mal..

Du könntest einen zweiten Slave-Loop unten hinzufügen, dessen einzige Aufgabe es mit "Preview Queue Element" das aktuell zu prozessierende Bild anschaut, ohne es zu entfernen

Das probiere ich gleich. Hat es einen Vorteil das Bild nicht zu entfernen? Ich meine, wird die Belastung der Resourcen verlagert? Es scheint einfach hart an meiner Grafikeinheit zu hängen. Doof ist, dass ich schon ein Bild brauche um zu sehen, wann mein Versuch rum ist. Hab aber rausgefunden, dass wenn ich die Größe des Bildes auf dem Frontpanel reduziere, es mit der Aufnahmegeschwindigkeit passt. Ist nicht schick, doch wenigstens kann ich so arbeiten..

Ich bin mir da auch nicht ganz sicher, ob der Parallel-Loop wirklich den gewünschten Performance-Boost liefert.
Eine andere Möglichkeit ist es vielleicht, die Pixelzahl des Bilds vor der Anzeige mit "\vision\Image Manipulation.llb\IMAQ Resample" zu reskalieren, aber sehr wahrscheinlich braucht das mehr Zeit, als direkt das große Bild anzuzeigen
Also wie gesagt, dass das mit der zusätzlichen Parallelisierung klappt, kann ich ich nicht garantieren, aber einen Versuch ist es meiner Meinung nach wert. (Du kannst das dann relativ leicht überprüfen, indem du dir die Schleifendurchläufe der beiden Consumer anschaust, die sollten dann (mehr oder weniger stark) asynchron verlaufen, d.h. dann auch, dass die Schleife mit dem Preview ab und zu einen Frame verpasst, den der Avi-Consumer bearbeitet, aber das ist ja egal, dient ja nur der Live-Vorschau)

***edit*** achso, die Frage nach dem Vorteil, das Bild nicht zu entfernen - der parallele Previewer darf auf keinen Fall die Queue manipulieren, sonst nimmt der Preview-Consumer dieses Bild ja dem Avi-Consumer weg, und das soll nicht geschehen. Gucken, aber nicht anfassen!

Mal ne ganz blöde Frage:

Du arbeitest an dem Rechner nicht zufällig mit Remote Desktop oder ähnlichem? Habe nämlich vom Verhalten her exakt das gleiche Problem hier wenn ich darüber auf meinen Datenrechner gehe (Bildrate sackt ab von 25FPS auf ~8FPS wenn Bild in Anzeige). Das liegt dann allerdings nicht am Labview selbst sondern am Windows bzw. am 100MBit lokalen Netzwerk über das Windows nicht genug versenden kann und deswegen scheinbar auch die eigentliche Berechnung selbst ausbremst.

Im parrallen Loop (für die Anzeige) "entnimmst" du nicht sondern machst nur preview (letztes Element kopieren und anschauen ohne es aus der Queue zu löschen) damit der Consumer auch tatsächlich alle Bilder kriegt (da du im Anzeigeloop nicht alle Bilder entnehmen willst sondern nur genug um ohne zu starken Performance Verlust was zu sehen, kannst du deswegen nicht einfach entnehmen und in eine neue Loop werfen oder "zurücktun" - du wüsstest ja gar nicht wohin - stichwort Racing conditions).

Im Prinzip kannst du die Loop dann einfach mit einem einstellbaren Wait ausstatten (ka, kannst ja auf dem Frontpanel irgendwas machen wie "Bildrate Vorschau" und berechnest dir daraus das wait so dass du entsprechend viele Bilder aus der Queue auf die Anzeige packst. Je nachdem wie gut deine Hardware dann damit ausgelastet ist kannst dann entweder mehr oder weniger Vorschaubilder pro Sekunde anzeigen lassen. Denke mal spätestens bei nem wait von 1000ms aka 1FPS sollte das dann kein Problem sein das parrallel laufen zu lassen.

Anzeige

Mir ist aufgefallen, dass in die Preview-Schleife dann aber wahrscheinlich dringend ein Wait muss, damit der Rechner nicht lahmgelegt wird. Irgendwas zwischen 10 und 100ms delay? Mal rumprobieren.

Hi,

danke ihr zwei. Es reicht mir ja vollkommen jeden xten Frame anzuzeigen, hauptsache ich kann feststellen, wenn alles gelaufen ist.

@Kiesch: Ich verwende den Rechner tatsächlich remote, doch nicht, wenn ich aufnehme. Habe auch schnell gemerkt, dass das nicht zusammen läuft Es saß dann immer jemand vor dem Rechner und wenn ich ab und an kam um nach dem Rechten zu schauen und das zufällig im Versuch passiert ist, dann hatten wir enormen Verlust.

Vielen Dank euch. Ich gebe Rückmeldung, ob ich eure Vorschläge realisieren konnte.

Hallo Hummingbird,

bitte beachte dass du in diesem Fall mit Bildreferenzen arbeitest. Mit dem aktuell hier besprochenen Design handelst du dir eine richtig fette "Race-Condition" ein. Schau dir mal an was du in die Queue steckst und was du in der parallel laufenden Schleife von dieser erhältst. Du wirst feststellen, dass es sich immer um die gleiche Bildreferenz handelt. Das Problem dabei: Während du versuchst das Bild in deinen Film zu schreiben kann in der oberen Schleife dieses bereits schon wieder durch die Bildaufnahme überschrieben werden. Wie gesagt anders als sonst in LabVIEW üblich arbeitest du nur mit Referenzen (auf den Speicher)!!! Alles was du in die Queue steckst ist immer ein und dasselbe Bild, egal an welcher Stelle du letztlich darauf zugreifst. So wie ich das jetzt sehe kann es nur schief gehen und dein AVI wird wahrscheinlich nur bei sehr langsamer Bildaufnahme halbwegs stimmen.

Schöne Grüße
Falk

Ja genau. In Queues mit Bildern muss man aufpassen, entweder Du legst Dir einen Stack aus Bildreferenzen an (mit Haushaltung wer gerade frei ist) oder Du übergibst das ganze Bild (Image 2 Array) was aber viel Overhead macht.

Gottfried