Guter Umgang mit großen Datensätzen (mehrere ~20Megapixel-Fotos)

Hallo zusammen,

ich mache mir gerade Gedanken über eine LabVIEW-Ansteuerung von einer DSLR-Kamera mit einer Auflösung von ~20MP. Die Datengröße liegt damit bei etwa 60MB pro Bild, wenn ich mich nicht grob verrechnet habe, was gewisse... Herausforderungen an die Programmierung bzw. das Speichermanagement stellt. LabVIEW Vision steht nicht zur Verfügung.
Was wäre Eure Herangehensweise, mit solchen Datenklumpen umzugehen?

In der späteren Software sollten bestenfalls beliebig viele Bilder aufnehmbar, anseh- und bearbeitbar und speicherbar sein.
Mein erster Gedanke geht in die Richtung temporäre Dateien, so dass ich immer nur ein Bild im Speicher habe und der Rest auf der Festplatte gehalten wird. Beim Beenden des Programms würden diese temporären Dateien dann gelöscht werden. Sieht jemand mit diesem Vorgehen Probleme oder Optimierungspotential?

Danke für's Feedback,
Grüße,
Kasi

Anzeige

1x 60 MB im Speicher, das finde ich bei der typischen Ausstattung eines heutigen Computers nicht sooo schlimm.
Bei LabVIEW muss man aber aufpassen mit den Datenkopien, die gerne mal angelegt werden.
Also heißt es hier aufpassen! Verzweigungen im Blockdiagramm vermeiden. Arbeiten mit Shift-Registern. Wenn die Daten in einem SubVI verarbeitet werden sollen, dann die Daten an das SubVI übergeben, dort verarbeiten (auch hier auf effiziente Datenverarbeitung achten - nach Möglichkeit keine Kopien, ReplaceArraySubset ist sein bester Freund), und die geänderten Daten dann wieder an den Aufrufer übergeben. etc. etc. etc.

Gruß, Jens

(15.01.2013 22:23 )jg schrieb:  1x 60 MB im Speicher, das finde ich bei der typischen Ausstattung eines heutigen Computers nicht sooo schlimm.
Bei LabVIEW muss man aber aufpassen mit den Datenkopien, die gerne mal angelegt werden.
Also heißt es hier aufpassen! Verzweigungen im Blockdiagramm vermeiden. Arbeiten mit Shift-Registern. Wenn die Daten in einem SubVI verarbeitet werden sollen, dann die Daten an das SubVI übergeben, dort verarbeiten (auch hier auf effiziente Datenverarbeitung achten - nach Möglichkeit keine Kopien, ReplaceArraySubset ist sein bester Freund), und die geänderten Daten dann wieder an den Aufrufer übergeben. etc. etc. etc.

Gruß, Jens

Hallo Kasi,
Als Ergänzung zu Jens, passt meiner Meinung nach die „Data Value Reference“ am besten für Dein Vorhaben.
Im Anhang mal grob dargestellt.

Gruß
Ralf

Heieiei... in diese Memory-Palette habe ich mich noch nie rangewagt, getreu dem "LabVIEW macht das schon gut alleine"-Motto.
Der Vorteil von den Referenzen ist einzig und allein, dass ich mir keine Gedanken darüber machen muss, wenn diese mal kopiert werden, weil sie kaum Speicher nutzen, egal, auf welche Daten sie zeigen, richtig?
Könnte man dann auch brutal sagen, dass, wenn man "alles richtig macht", d.h. keine Kopien erzeugt, auf diese Referenzierung auch verzichten kann?
Die In Place Element Structure fand ich schon immer sehr elegant (oder zumindest interessant), allerdings finde ich selten Möglichkeiten, diese sinnvoll einzusetzen. Vielleicht hilft diese trotzdem bei den anstehenden Bildbearbeitungsfeatures weiter.

Danke Euch zweien auf jeden Fall für eure Gedanken.

Frage @Ralf:

Warum da ein "Request for Deallocation" ? Was macht das? Potentielle kopien beseitigen? Ich dachte dafür nimmt man extra die In Place struktur damit am Ende nur noch da wo die Daten vorher die wieder hingespeichert werden (mehr oder weniger). Die also "vor Ort" bearbeitet werden statt erst kopiert und dann irgendwann das original vernichtet. Was also dealloziert man da?

Gruß Kiesch

P.S: Gibt es eigentlich irgendwo eine Referenz von NI zum Thema, speziell wann genau jetzt wirklich kopien angelegt werden. Grade beim OO Programmieren schleift man ja oft seine Objekte überall mit und deswegen steht man dann oft vor der Wahl entweder potentiell kopien anzulegen oder nur sequentiell damit arbeiten zu können.

Hab jetzt nur das gefunden, aber das ist nicht wirklich klar:
http://zone.ni.com/reference/en-XX/help/...data_sets/

(Tenor: Bei wire splitting wird "villeicht" (konkret steht da "im Zweifel") eine Kopie erzeugt )

(21.01.2013 15:04 )Kiesch schrieb:  Frage @Ralf:

Warum da ein "Request for Deallocation" ? Was macht das? Potentielle kopien beseitigen? Ich dachte dafür nimmt man extra die In Place struktur damit am Ende nur noch da wo die Daten vorher die wieder hingespeichert werden (mehr oder weniger). Die also "vor Ort" bearbeitet werden statt erst kopiert und dann irgendwann das original vernichtet. Was also dealloziert man da?

Gruß Kiesch

Hallo Kiesch,
im Normalfall ist dieses Request Deallocation wirkungslos.
Ich habe festgestellt das in einigen Fällen dieser Baustein doch die erhoffte Wirkung zeigt.
Im Anhang mal ein Beispiel mit Verwendung von DVR und Sub-Vi.
In diesem Beispiel muss der Request Deallocation im Sub-vi verwendet werden, auf Main-Ebene passiert nichts.
Warum weiß ich nicht, vielleicht haben die anderen ja eine Idee.

Gruß
Ralf

Anzeige