Falschfarbenbild erstellen mit DLL und NiVision (Grau->Farbe)

Hallo,

ich mache gerade ein Praktikum in einer Firma und soll ein Graubild farbig einfärben.
Mit LabVIEW wird das bisher schon gemacht, es dauert aber einfach zu lange!
Da ich (noch) informatik studiere und mit LabVIEW bisher noch nie gearbeitet habe, habe ich kurzerhand eine DLL in C
geschrieben, die von einem IMAQ (Bild) einen Speicherbereich bekommt und dann dort die Werte hineinschreibt.

Für einfaches Rot-Färben sieht dass dann so aus:
(Format des Bildes ist -RBG)
"niImage" ist dabei der besagte Speicherbereich

DLL_API void getSketchyRedImage(const float *const floatArray) {
uint32_t pixelIndex=0;
uint32_t value;
//für alle Pixel des Bildes
for (pixelIndex=0; pixelIndex<(image_height*image_width); pixelIndex++) {
//schiebe 'Wert einfach in Blauwert (RGB)
niImage[pixelIndex] = ((uint32_t) floatArray[pixelIndex])<<16;
}
}

[COMPILER ist Intel 10.2 mit allen Optimierungen, auch unpräzise floats erlaubt]

Soweit sehr einfacher Code, der auch nur für Werte des floatArrays zwischen 0 und 255 funktioniert (was auch gegeben ist).
Das Bild wird mit einem 'Image Display' dargestellt.

In der Hauptschleife des LabVIEW-Programms steht NUR der obige Code als DLL (     ),
bzw. der Intensitätsgraph (     )
(Anschlüsse davor irrelevant und der Übersichtlichkeit halber entfernt.
Andere Elemente dienen der Zeitmessung und dem Terminieren nach 10000 Durchläufen).
Will ich 10.000 Bilder mit 128kB einfärben, so dauert das 12 Sekunden.
Nehme ich einfach einen Intensitätsgraph, so dauert das nur ca. 2 Sekunden.

Woher kommt also die schlechte Leistung?
Dauert die Anzeige mit dem Image-Display so viel länger?
Ist die Anbindung an C so schlecht?
(Beide Anzeigen sind asynchron, Fehlererkennung ist bei der DLL unterdrückt)

Wenn wer ne Idee hat, oder spekulieren will, 'bescheid' sagen!

Bitte Forenregeln durchlesen (s. Link oben in der Titelzeile). Screenshots werden bei uns hier im Forum hochgeladen und nicht auf externe Links wie Imageshack o.ä.!

Gruß, Jens

' schrieb:

Bitte Forenregeln durchlesen (s. Link oben in der Titelzeile). Screenshots werden bei uns hier im Forum hochgeladen und nicht auf externe Links wie Imageshack o.ä.!

Gruß, Jens

Tut mir leid, wird in Zukunft nicht wieder vorkommen.

' schrieb:Tut mir leid, wird in Zukunft nicht wieder vorkommen.

Akzeptiert, Bild-Links geändert.

Mach' mal eine Verzögerung von 1 ms in Deine Whileschleife. Ohne Verzögerung läuft Deine CPU am Maximum. Vielleicht bringt's was.
Mit C und DLLs kenne ich micht nicht so toll aus, als dass ich da einen Fehler finden würde. Ehrlich gesagt: .

Gruß Markus

' schrieb:In der Hauptschleife des LabVIEW-Programms steht NUR der obige Code als DLL ( [attachment=41639:v2dllniimagene0.png] ),

In diesem Bild steht ein DLL-Knoten - den kannst du weglassen. Solange da kein Ausgang angeschlossen ist, ist die Arbeit im DLL-Knoten umsonst. Der Pointer, der in der Funktion übergeben wird, zeigt auf den Datenfluss, der in den DLL-Knoten hinein/heraus geht - nicht dorthin, wo der Wire herkommt.

Zitat:Will ich 10.000 Bilder mit 128kB einfärben, so dauert das 12 Sekunden.

Naja, 1.2ms pro 128kB, die 2mal kopiert werden müssen (Speichermanager!) - was bei der anderen Methode entfällt.

Zitat:Nehme ich einfach einen Intensitätsgraph, so dauert das nur ca. 2 Sekunden.

Ich kenn mich in den Tiefen von LV nicht aus. Aber es besteht die Möglichkeit, dass in der gezeigten Schleife der Graph die Daten nur ein einziges Mal neu berechnet. Der könnte nämlich so schlau sein, sich die alten Daten zu merken und nur zu arbeiten, wenn neues gekommen ist.

Zitat:Dauert die Anzeige mit dem Image-Display so viel länger?

Kann ich nicht beurteilen.

Zitat:Ist die Anbindung an C so schlecht?

Bestimmt nicht.
Wenn dann hält das Sicherungskonzept um den DLL-Knoten (bedenke: bei AV in der DLL sollte LV selbst nicht abstürzen) herum etwas auf.

Anzeige

' schrieb:In diesem Bild steht ein DLL-Knoten - den kannst du weglassen. Solange da kein Ausgang angeschlossen ist, ist die Arbeit im DLL-Knoten umsonst. Der Pointer, der in der Funktion übergeben wird, zeigt auf den Datenfluss, der in den DLL-Knoten hinein/heraus geht - nicht dorthin, wo der Wire herkommt.

Naja, 1.2ms pro 128kB, die 2mal kopiert werden müssen (Speichermanager!) - was bei der anderen Methode entfällt.

Ich kenn mich in den Tiefen von LV nicht aus. Aber es besteht die Möglichkeit, dass in der gezeigten Schleife der Graph die Daten nur ein einziges Mal neu berechnet. Der könnte nämlich so schlau sein, sich die alten Daten zu merken und nur zu arbeiten, wenn neues gekommen ist.

Kann ich nicht beurteilen.

Bestimmt nicht.
Wenn dann hält das Sicherungskonzept um den DLL-Knoten (bedenke: bei AV in der DLL sollte LV selbst nicht abstürzen) herum etwas auf.

Ich habe in ein paar Variationen herumgespielt. Dabei habe ich die Anzeige 'synchron' laufen lassen und nicht synchron.
Daten beziehen sich wieder auf das Färben von 10.000 Bildern:
ASYNCHRON:DLL=0:12 / Intensitätsgraph=0:02
SYNCHRON: DLL=0:27 / Intensitätsgraph=3:50

Um auszuschließen, dass das Bild nur einmal neu gezeichnet wird, habe ich einen Pixel zufällig belegt.
Das ganze dauert dann je Version circa eine Sekunde länger
(Man sieht den Pixel auch flackern)

@'IchSelbst':
-Speichermanager?
Wo wird denn zwei mal kopiert?
Wie kann man das verändern?

-DLL-Knoten
Hab ich nicht ganz verstanden. Ne, ehrlich gesagt garnicht :-)
Der doppelt grüne Draht sind die Daten, die in die DLL gehen, also das 'floatArray'.
Die werden in der DLL von diesem Float-Array in eine Darstellung gebracht, die NI-Vision-Konform ist und an der reservierten Speicherstelle geschrieben.
Das Funktioniert auch, in den DLL-Einstellungen ist der Parameter als 'Array-Datenzeiger' angegeben.

@Jens:
Vielen Dank für das Einstellen der Bilder, es werde Licht :-)

@Y-P:
Die CPU SOLL doch gerade am Maximum laufen ;-)
Naja, probiert ohne (positives) Ergebnis.
Der C-Code nimmt einfach nur die float-Werte (Fließkommawerte),
schneidet die Nachkommastellen ab und bringt die Zahl in das Ni-Vision Format eines RGB-Bildes
(--------/ROTWERT/GRÜNWERT/BLAUWERT), schiebt also den Ganzzahlenwert um 16-Stellen nach links.

' schrieb:Wo wird denn zwei mal kopiert?

Einmal zum Knoten rein, einmal zum Knoten raus. Jeder Wire ist eine Kopie.

Zitat:Wie kann man das verändern?

Bestimmt nicht. Hintergrund: LV kennt keine von außen manipulierbare Pointer.

Zitat:Der doppelt grüne Draht sind die Daten, die in die DLL gehen, also das 'floatArray'.
Die werden in der DLL von diesem Float-Array in eine Darstellung gebracht, die NI-Vision-Konform ist und an der reservierten Speicherstelle geschrieben.
Das Funktioniert auch, in den DLL-Einstellungen ist der Parameter als 'Array-Datenzeiger' angegeben.

Du meinst, der DLL-Knoten ohne Ausgangsbeschaltung funktioniert? Das wäre mir neu!
Ein Wire ist immer eine Kopie. Und zwar ab dem Anfang und ab jeder Verzweigung. Laut NI etc. D.h. ein Schreiben auf eine Verbindung kann keine Auswirkungen haben auf eine Verbindung, die aus einer Verzweigung entsteht. Wäre dem so, was passierte, wenn zwei VIs/DLLs gleichzeitig auf den "gleichen/selben" Wire schrieben?
Wenn du aber sagst, dass es funktioniert, glaub ich dir das gerne. Nur: Ich kann das nicht verifizieren. Da fehlen mir die Möglichkeiten und ab morgen auch die Zeit.

' schrieb:Einmal zum Knoten rein, einmal zum Knoten raus. Jeder Wire ist eine Kopie.
Bestimmt nicht. Hintergrund: LV kennt keine von außen manipulierbare Pointer.

Du meinst, der DLL-Knoten ohne Ausgangsbeschaltung funktioniert? Das wäre mir neu!
Ein Wire ist immer eine Kopie. Und zwar ab dem Anfang und ab jeder Verzweigung. Laut NI etc. D.h. ein Schreiben auf eine Verbindung kann keine Auswirkungen haben auf eine Verbindung, die aus einer Verzweigung entsteht. Wäre dem so, was passierte, wenn zwei VIs/DLLs gleichzeitig auf den "gleichen/selben" Wire schrieben?
Wenn du aber sagst, dass es funktioniert, glaub ich dir das gerne. Nur: Ich kann das nicht verifizieren. Da fehlen mir die Möglichkeiten und ab morgen auch die Zeit.

Ich habe keinen blassen Schimmer, wie LabVIEW intern das grafische Programm kompiliert,
aber optimierungen der Art, dass wenn bestimmte Operationen nur lesen, dass dann keine Kopie erstellt wird,
sind offensichtlich.
Da ich alles andere als ein LabVIEW experte bin, lehne ich mich weit aus dem Fester, wenn ich sage, dass
das sicher gemacht wird. Außerdem sind DLLs ein besonderes Konstrukt.
Was mit den Daten geschieht, kann LabVIEW nicht sagen, daher die Kopie, eingesehen.
Aber aus eben jenem Grund wird doch ein Ausgang garnicht benötigt.

Kann mich jetzt gerne einer noch schubsen oder aber eben festhalten, des Fensters halber.
Auf jeden Fall flackert mein lieber Pixel (oder auch mehr).

Die Erklärung mit den Kopien, die bei einem Intensitätsgraph nicht benötigt werden, da nur lesend, finde ich aber logisch in meinem LabVIEW-Weltbild :-)

Also ich sehe da nicht ganz durch, gebe aber trotzdem mal meinen Senf dazu

Verstehe ich richtig, dass die DLL eine Ersatzfunktion ist?
Warum rufst du diese dann 10'000 mal auf und nicht nur 1mal.
Die Daten (der orange Doppeldrath) hat ja immer denselben Wert.