Problem beim Verwenden von 2D Arrays

' schrieb:Informationsgehalt 8Bit? Nungut, für ein Bild zur Konturenerkennung etc. ist das ausreichend. Sind es tatsächlich nur 8Bit?
Nun, man wird natürlich U32/U32 verwenden. Aber hier mit double zu rechnen ist wahrlich mit Kanonen auf Spatzen geschossen! Hast du die Möglichkeit, die Daten von woher auch immer als I32 zu bekommen anstelle von double?

Ja, es wird noch daran gearbeitet, es einmal zumindest auf 12Bit zu bekommen aber da fehlt mir gerade noch der passende Treiber.
Naja also im Grunde werden sie als unsigned char wohl übergeben, oder auch nicht, diese Änderung in Double kommt ja durch:
[code]typedef struct {

Anzeige

' schrieb:Naja also im Grunde werden sie als unsigned char wohl übergeben

Tatsächlich. Jetzt seh' ich's wieder.

Im Header steht doch tatsächlich unsigned char für die Bild[]-Daten! Dann musst du in der DLL aber nicht mit double-Arrays arbeiten. Stell' das mal alles auf long (i32) um. Muss denn das Kontraste-Array in double sein? Reicht da nicht auch I32?

Zitat:Dann musst du in der DLL aber nicht mit double-Arrays arbeiten. Stell' das mal alles auf long (i32) um. Muss denn das Kontraste-Array in double sein? Reicht da nicht auch I32?

Ich habe mir mal die Daten etwas angesehen und schätze, dass gerade durch das Rauschen wirklich long gut reichen dürfte und habe es darauf umgestellt, das dürfte der Geschwindigkeit wohl wieder Vorteile finden aber am Zustand ändert sich auch nichts. LabVIEW hängt sich immernoch auf, also entweder stimmen tatsächlich die Indizes in den Schleifen nicht oder diese Übergabe funktioniert doch noch nicht so wirklich.
Beim ersten Fall werde ich das wohl später nochmals durchdenken, bisher kam ich immer zum Ergebnis, dass es so gehen müßte aber wenn man mal so etwas nach seinem Denkmuster erstellt hat ist es auch schwierig den Fehler zu finden da man letztlich oftmals einfach wieder auf dem gleichen falschen Pfad geht.
Bei der Übergabe wundert mich immernoch, dass ind en Beispielen dieses Übergabearray "array" in der Funktionsdeklarationszeile blau hinterlegt wurde, was nun aber mit Bild bzw Kontrast nicht geschieht.

Hast du denn überhaupt schon mal die Links verfolgt, die dc6xs in seinem Posting (#14) erwähnt hat? Da ist doch bestimmt was dabei, das optimiert einen Kontrast ausrechnen kann.

' schrieb:Hast du denn überhaupt schon mal die Links verfolgt, die dc6xs in seinem Posting (#14) erwähnt hat? Da ist doch bestimmt was dabei, das optimiert einen Kontrast ausrechnen kann.

Ja, habe dort allerdings noch nicht einen Codezugang gefunden, allerdings habe ich mich auch noch nicht wirklich längere Zeit damit beschäftigt, da ich auch eine andere Qulle fand, die ein paar Möglichkeite gab den Kontrast zu berechnen, allerdings stellten sich diese dann auch als eher suboptimal heraus da sie entweder auf Fourier Transformationen basierten oder aber ein histogramm derart verwendeten, dass man es programmtechnisch recht viel umsortieren hätte müssen, was ja wiederum neue Schleifen aufgeworfen hätte.

Oh, mein Gott schwere Not...

Code:

for (m=0;m<numrow;i++)

i++ ..wenig verwunderlich, dass das wohl nicht gesund ist.

Code:

double** Mittelwert = callocmatrix(*Brows,*Bcols);

Auch Unsinn, denn ich errechne ja eine neue Größe für die neuen Arrays und auch Mittelwert muß ja nur so groß sein wie Kontrast also doch eher:

Code:

double** Mittelwert;
numrow=floor(numrow / *Lrows);
numcol=floor(numcol / *Lcols);
Mittelwert = callocmatrix(numrow,numcol);

Also damit wären schonmal wieder zwei Dinge draußen, von denen eines mehr als gravierend ist.
Das hat allerdings auch nur zur Folge, dass LV nun nicht mehr abstürzt sondern der Knoten einen Fehler 1097 liefert, folglivh wird wohl, wie schon gedacht, immernoch etwas mit der Übergabe der Arrays nicht stimmen.
Ich wundere mich auch imemrnoch, dass in allen Beispielen die ich sah die Übergebenen arrays mit "array" benannt wurden und hinter diesem TD1Hdl blau wurden wie man es von Variablentypen dem for der Schleifen etc. gewohnt ist, bei anderer Benennung geschieht dies jedoch nicht. Ich vermute, dass es daher wirklich wohl irgendwie damit zusammenhängen könnte.

Ich hab mir mal Gedanken gemacht.

Das Ergebnis ist der Delphicode - siehe unten. Er entspricht (im ersten Schritt) dem, was ich oben geschrieben habe: Bild = 1000*1000; Quadrat=11*11 (5*2+1=11); Mittelwert=1000*1000; Demnach wäre der Kontrast auch 1000*1000. Dabei ist mir ein Problem aufgefallen: Wie sieht das Mittelwertfenster (= das Quadrat) am Rande des Bildes aus. Am Punkt (0,0) kann man kein Mittelwertfenster der Größe 11x11 machen. Der Punkt (0,0) kann in keinem Fenster in der Mitte liegen. Demnach kann das Fenster um den Punkt (0,0) nur die Breite 1 haben, also den Punkt selbst. Diese Überlegung gilt für alle Punkte, die näher als 5 am Rand liegen. Durch diesen Sachverhalt erschwert sich die Berechung (respektive der Algorithmus) erheblich. Diese Überlegung hab ich in meinen Code mal außen vor gelassen. Verstehst du meine Überlegung?

Ein weiterer Punkt ist mir aufgefallen. Dein geposteter VI-Code bewirkt doch folgendes: Bild=1000x1000; Fenster=10x10; Kontrast=100x100 wegen Schleifenzähler = Länge div Fenster = 1000 div 10. Demnach ergibt dein LV nicht für jeden Bildpunkt einen Kontrastpunkt, sondern für jedes Bildfenster ergibt sich ein Kontrastpunkt. Ist das so gewollt respektive so richtig?

Hier mal der Code in Delphi. Den kann man - also du - mit etwas Überlegung nach C++ wandeln. Dieser Code, der erheblich mehr macht als dein LV-Code, braucht circa 600ms. Das liegt am beschriebenen "Gleitenden Mittelwert". Bild[] und Mittelwert[] sind dabei 2D-Arrays. Das sieht man daran, dass eben mittels zweier Schleifen über den Pointer zugegriffen wird. Es ist also ausreichend, einen "Datenzeiger" an die DLL zu übergeben.

[code]const BRows: cardinal = 1000;

' schrieb:Auch Unsinn, denn ich errechne ja eine neue Größe für die neuen Arrays und auch Mittelwert muß ja nur so groß sein wie Kontrast also doch eher:

Ja, das hab ich jetzt auch gesehen. Siehe obiges Posting.

Soll es also so sein: Pro Fenster ein Kontrastpunkt? Das wäre natürlich erheblich einfacher (aber langweiliger).

Zitat:Soll es also so sein: Pro Fenster ein Kontrastpunkt? Das wäre natürlich erheblich einfacher (aber langweiliger).

Ja genau, wobei das Fenester am ende so 5 oder 7 groß sein wird, das mit dem gleitenden Mittelwert ist jedoch auch eine interessante Idee, allerdings würde ich zu Gunsten der Geschwindigkeit doch lieber beim alten Verfahren bleiben um das zu beschleunigen. Erkenne ich am Ende, dass doch noch etwas "Platz" ist werde ich aber sicher nochnmal versuchen, wie es anders aussieht. Die Ränder sind bei diesen Sachen immer ein Problem, ich würde dann wohl dazu tendieren sie einfach "abzuscheniden" das wäre dann eine Verkleinerung um 10 bzw 14 Pixel, ich denke, dass das nicht allzu viel ausmachen würde.

Nun aber zurück zum momentanen Stand, inzwischen läuft die Übergabe der Parameter, was mich immerhin dazu brachte, nun einmal zu sehen, dass in meiner Berechnung wohl wirklich die Indizes etwas durcheinander laufen aber das sehe ich dann doch eher als Motivation an, es wirklich noch einmala uf eine andere Art zu versuchen, dazu werde ich auch gleich nochmal deinen code etwas genauer ansehen. Da sah ich gestern abend bereits kurz drüber, habe aber festgestellt, dass diese Delphi Crashkurs vor Jahren nun aich schon sehr in Vergessenheit geraten ist. Die Geschwindigkeit ist für mich gerade auch noch nicht so wirklich zufriedenstellend, ich habe das Ganze mal in LV in eine Ablaufstruktur gesteckt, die Zeit davor, danach gemessen, voneinander abgezogen, das gleiche in LV auch nochmal und da kommen recht ähnliche Werte raus. Aber wie gesagt, dadurch, dass nun wwenigstens diese Übergaben gehen kann ich mich nun wenigsten ganz der Codeoptimierung widmen. Mich fasziniert ja doch, dass dein Code, trotz der wohl aufwendigeren Berechnung noch immer schneller zu sein scheint -aber ich bin auch guter Hoffnung, dass mit diesen selbstinkrem,entierenden Zeigern einmal zu verstehen. Ich schätze, dass ihatte ich da nicht ganz verstanden weil ich zu dem Zeitpunkt noch nicht wirklich gesehen hatte, dass man im Grunde ja nur noch 1D Arrays verwendet und ich dann ständig nach der zweiten Dimension suchte.

Oh übrigens bedauerlicherweise muß man doch double Variablen benutzen, wobei ich es mir aber auch noch in float ansehen wollte.

So dann werde ich nun mal etwas schmökern, herumprobieren und mich dann sicherlich wieder melden.

' schrieb:Die Ränder sind bei diesen Sachen immer ein Problem, ich würde dann wohl dazu tendieren sie einfach "abzuscheniden".

Sollte das Projekt sowas zulassen, würde ich das auf jeden Fall abschneiden.

Zitat:Oh übrigens bedauerlicherweise muß man doch double Variablen benutzen, wobei ich es mir aber auch noch in float ansehen wollte.

In der DLL würde ich aber trotzdem mit integer rechnen - auch bei einer Division. Da findet sich bestimmt ein geeigneter Algorithmus mit Integer, der noch genug "Nachkommastellen" hat. Umrechnen auf benötigte double Werte kann man außerhalb ein einer entsprechenden Schleife. Das geht schneller als in der DLL mit double zu rechnen.

Ich hab mal zu dem "reduzierenden Verfahren" was geschrieben - Dauer: 15ms (in Worten: fünfzehn) bei Bildgröße 1000*1000 und Fenstergröße 5*5.

[code]const XLenF = 5; // Breite des Fensters in X Richtung