Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
Also die Idee dahinter ist, dass man ein Bild hat, dieses Bild wird in Teilarrays zerlegt, deren Größe von Lcols bzw. Lrows angegeben wird.
In jedem dieser Teilarrays wird zuallererstz der Mittelwert berechnet, anschließend die Standardabweichung. Wenn man nun die Standardabweichung durch den mittelwert dividiert erhält man daraus den Kontrast. diese Zeile fehlte übrigens bisher noch, wie ich gerade sah, daher habe ich das Programm nochmals mitgeschickt.
Diese Werte werden dann also in einem neuen Array gespeichert, dass eben entsprechend der Teilarraygrößen kleiner ist, floor(numrow/ *Lrows).
Die jeweils vier Schleifen dienen also nun dazu, das gesamte Bils zu durchwandern, was die äußeren Beiden besorgen, die inneren beiden durchlaufen dann eben diese kleinen Teilarrays.
Wenn wir annehmen, dass Lcols 2 wäre und die Indexformel j+(n*Lcols) haben wäre das also j+ (n*2)
n=0 0+0 =0
1+0=1
n=1 0+2=2
1+2=3
usw
Also ich meine, dass das so funktionieren müßte.
Ich habe nun übrigens mal die funktionszeile, so geändert, dass gar keine Sterne mehr vorhanden sind.
long KontrastC(long *Brows, long *Bcols, long *Lcols, long *Lrows, TD1Hdl Bild, TD1Hdl Kontrast,long *test)
Tatsächlich scheint somit auch alles zu laufen. Nun zeigt sich allerdings ein viel größeres Problem. Urspünglich sollte das ja aus LV ausgelagert werden um diese Kontrastberechnung zu verschnellern. Nun da ich die Berechnung in LV und die in C parallel laufen habe ist es jedoch so, dass das ganze Programm wahnsinnig verlangsamt wurde, das geht so weit, dass LV schon gar keine Rückmeldung mehr gibt.
Das ist nun doch sehr frustrierend wie ich sagen muß, ist mein Code nun wirklich so viel schlechter als das was ich in LV machte (siehe Bild), das wiederspricht nun wirklich sehr allen aussagen die ich so hörte, dass man hohe Geschwindigkeitsgewinne zu erwarten hat wenn man etwas in einer DLL auslagert.
Läuft das nun scheinbar und es sind immernoch große Fehler enthalten, ist der code nur unglaublich schlecht aber die LV eigenen DLLs werden es doch kaum anders lösen, wie ist das nun zu erklären udn wie bekomme ich es damit nun wirklich verschnellert und nicht verlangsamt?
[code]/*Programm zur Kontrastberechnung und Bildarrayzerlegung
Wenn der C-Compiler das genau so macht, wie du das hier programmiert hast, ist das um Potenzen langsamer als du denkst. Es findet hier z.B. eine Operation "(m* *LRows)" statt, die für drei Schleifen immer den selben Wert liefert. Die Frage ist, optimiert der C-Kompiler diese Operation oder nicht. Jeder Programmierer wird diese Berechnung also herausziehen. Überlege mal: Die drei inneren Schleifen wenn zusammen 100.000 Durchläufe sind, wird diese Operation sooft umsonst gemacht. Die Operation selbst ist natürlich nur extrem kurz - aber ganz viel mal wenig gibt auch viel (Zeit). Jetzt bleibt es natürlich nicht bei dieser einen Operation. Selbst das, was links vom = steht, stellt eine Operation dar - die möglicherweise nicht zu vernachlässigen ist! Da wird nämlich u.U. multipliziert. Das kann etwas länger dauern als inkrementieren.
Wenn du den Code tatsächlich in C auslagern wolltest wegen Zeitersparnis, müsstest du dir eigentlich den C-Code in ASM ansehen und überlegen, ab das noch zu toppen ist. Wenn in der innersten Schleife nichts weiter steht als ein paar FPU-Befehle und nur wenige INC 's - dann glaube ich, ist das schneller als LV.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
03.03.2008, 19:50 (Dieser Beitrag wurde zuletzt bearbeitet: 03.03.2008 19:53 von dc6xs.)
' schrieb:Wenn du den Code tatsächlich in C auslagern wolltest wegen Zeitersparnis, müsstest du dir eigentlich den C-Code in ASM ansehen und überlegen, ab das noch zu toppen ist. Wenn in der innersten Schleife nichts weiter steht als ein paar FPU-Befehle und nur wenige INC 's - dann glaube ich, ist das schneller als LV.
Wieso eigentlich FPU-Operationen, bzw warum sich den Aufwandmachen das mit Flotingpoint-Zahlen zurechnen?
Mit etwas klugen Nachdenken und einer Fixedpoint-Arithmetik sollte es schneller gehen.
Ansonsten vielleicht mal über den Tellerrand schaun, bei Projekten wie imlib,ImageMagick, GIMP etc.
Eventuell ist es auch sinnvoll sich mal die Parameter für die CPU-Optimierung beim compilieren anzuschaun.
Was nutzte denn als Compiler? den Compiler vom MS Studio, Intel CC oder GCC?
Gruß,
Robert
Bitte Beachten:
Die obenstehenden Texteile können unter Umständen Sarkasmus und Ironie enthalten, für nicht erkannten Sarkasmus oder nicht erkannte Ironie wird keine Haftung übernommen.
N.B.: "Multiple exclamation marks, " he went on, shaking his head, "are a sure sign of a deseased mind." - Terry Pratchett
04.03.2008, 09:59 (Dieser Beitrag wurde zuletzt bearbeitet: 04.03.2008 10:05 von grey.)
Gut, ich habe nun einmal die Parameter die öfters gebracht werden etwas aus den inneren Schleifen herausgezogen, genau wie dieses 1.0/(*Lrows * *Lcols) was man ja nun auch nur einmal berechnen muß.
Das Bild bzw die Bilder haben eine Größe von 658x492, ich verwende den Visual C++ 9.0 (2008) Express Edition, ganz einfach weil es zu dem dieses Tutorial gab, wie man diese DLLs damit einbindet.
Allerdings scheint sich LV auch noch aufzuhänmgen wenn ich nur die Mittelwertsberechnung durchführe, das läßt mich ja dann doch noch ein wenig an einen Fehler glauben, da ich doch davon ausgehe, dass zumindest das in einer angemessenen Zeit möglich sein sollte. Allerdings liefert sowohl LV (besonders der Knoten) und auch der Compiler keine Fehlermeldungen.
' schrieb:Das Bild bzw die Bilder haben eine Größe von 658x492,
So wenig? Das darf selbst ohne alle Optimierungen und bei schlechtester Programmierung nicht länger als eine Sekunde Dauern (höchstens anderthalb).
Zitat:Allerdings scheint sich LV auch noch aufzuhänmgen wenn ich nur die Mittelwertsberechnung durchführe, das läßt mich ja dann doch noch ein wenig an einen Fehler glauben
Ich bin bei den verschiedenen Werten von BCols/LCols und BRows/LRows, die ja für die Array-Indices verantwortlich sind, immernoch skeptisch.
Zitat:Allerdings liefert sowohl LV (besonders der Knoten) und auch der Compiler keine Fehlermeldungen.
Das kann ich mir ohne weiteres vorstellen. Das kann die Folge eines fehlerhaftes Indexes sein.
[*nachkuck*]
Ich sehe gerade, wie du das Mittelwertarray erstellst. Mittels callocmatrix(). Das bedeutet, das du 492 Pointer machen lässt! Das ist aufwändig.
[*überleg*]
Ich fasse mal zusammen, was du machen willst.
Du hast ein Bild der Größe 658x492, der Einfachheit halber 1000x1000. Jetzt macht du eine Mittelwertbildung, die wie folgt geschehen soll. Um jeden Punkt dieses Bilder herum soll der Mittelwert einer Fläche der Größe z.B. 10x10 gebildet werden. Es entsteht also ein neues Feld der Größe 1000x1000 mit gemittelten Punkten (das müsste also sowas wie eine "Verschleierung" sein). Zusätzlich berechnest du noch ein Kontrastbild, das dann auch die Größe 1000x1000 hat.
Liege ich mit meiner Überlegung richtig?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
Ja, also LV braucht dafür ca 1,2 Sekunden was aber einfach noch zu lange ist, schließlich möchte ich danach noch ein paar Berechnungen anstellen, was einfach nicht möglich ist da es wohl jetzt schon zu langsam wäre.. daher ist das für mich auch wirklich eine sehr kritische Sache.
Zitat:Ich fasse mal zusammen, was du machen willst.
Du hast ein Bild der Größe 658x492, der Einfachheit halber 1000x1000. Jetzt macht du eine Mittelwertbildung, die wie folgt geschehen soll. Um jeden Punkt dieses Bilder herum soll der Mittelwert einer Fläche der Größe z.B. 10x10 gebildet werden. Es entsteht also ein neues Feld der Größe 1000x1000 mit gemittelten Punkten (das müsste also sowas wie eine "Verschleierung" sein). Zusätzlich berechnest du noch ein Kontrastbild, das dann auch die Größe 1000x1000 hat.
Liege ich mit meiner Überlegung richtig?
Ja, genau. Nur, dass ich dieses Mittewertfeld eben auch nur für die Kontrastberechnung benötige (Kontrast=Standardabweichung/Mittelwert) , letztlich mag ich einfach nur dieses 1000x1000 (in deinem Beispiel) Kontrastbild haben.
Wo ich mir auch nicht ganz sicher bin, sind diese Teile:
(*Bild)->elt[((i+ZWm)* numcol) dieses mal numcol, ob es nun das oder doch eher mal *Lcols sein muß, das erkenne ich aus dem Beispiel nicht wirklich gut.
Momentan sieht der Code übrigens so aus:
[code]/* Call Library source file */
' schrieb:Ja, also LV braucht dafür ca 1,2 Sekunden was aber einfach noch zu lange ist,
Ja, ok. Das sollte durch eine DLL zu toppen sein. Ich tippe auf 100ms.
Zitat:Ja, genau.
Na, da hab ich jetzt doch eine gedankliche Grundlage, heute abend mal wieder einen interessantes Algorithmus auszutüfteln.
Zitat:Wo ich mir auch nicht ganz sicher bin, sind diese Teile:
(*Bild)->elt[((i+ZWm)* numcol) dieses mal numcol, ob es nun das oder doch eher mal *Lcols sein muß, das erkenne ich aus dem Beispiel nicht wirklich gut.
Ich programmiere nicht in C, sondern in Delphi. Und dort auch mit eben diesen selbstgemachten Pointern. Wie die C-Syntax für einen Zugriff per Arrayhandle genau heißen muss, weiß ich nicht. Ich weiß nur: Wenn er falsch ist, hat das fatale folgen - bis hin zu Absturz ohne jedwede Meldung.
Noch ein paar Fragen:
Ist es nicht ausreichend, wenn das Fenster für die Mittelwert/Kontrast-Bildung (mein Beispiel 10x10) quadratisch ist? Bei dir kann es ja länger als breit sein. Ist das denn sinnvoll?
Was wird denn in Bild[] übergeben? Die Farbe eines Pixels? Oder eher ein Graustufenwert? Wie liegt der Wert denn vor als Integer im Double-Format (also ohne Nachkommastellen)?
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
' schrieb:Ja, ok. Das sollte durch eine DLL zu toppen sein. Ich tippe auf 100ms.
Also wenn das mal mit so einer Geschwindigkeit laufen würde, wäre ich mehr als nur hocherfreut.
Zitat:Ist es nicht ausreichend, wenn das Fenster für die Mittelwert/Kontrast-Bildung (mein Beispiel 10x10) quadratisch ist? Bei dir kann es ja länger als breit sein. Ist das denn sinnvoll?
Im Grunde wäre das vollkommen ausreichend, ich lasse mir nur generell immer alle Möglichkeiten offen aber mir fällt wirklich kein Grund ein warum man es nicht quadratisch machen würde. Gut, vielleicht könnte man dadurch auch wieder etwas vereinfachen.
Zitat:Was wird denn in Bild[] übergeben? Die Farbe eines Pixels? Oder eher ein Graustufenwert? Wie liegt der Wert denn vor als Integer im Double-Format (also ohne Nachkommastellen)?
Ich probiere gerade mit einer RGB Kamera als auch mit einer BW Kamera herum aber selbst bei der RGB Kamera wird nur ein Farbanteil übergeben also kann man es getrost immer als Graustufenbild betrachten. Die Werte in Bild[] liegen als 8bit Integer vor.
Bisher hat sich durch erneutes herumprobieren meinerseits keine nennenswerte Änderung mehr ergeben, vielleicht baue ich das nun noch nach diesem anderen Beispiel um wenn mir tatsächlich nicht noch etwas einfaällt..was aber gerade wohl der fall sein dürfte.
Vielen Dank übrigens für deine hervorragende und dauerhafte Hilfe, ich vermute mal bei meiner dilletantischen Vorgehensweise hätten sicherlich viele andere bereits ihre Nerven verloren.
' schrieb:Die Werte in Bild[] liegen als 8bit Integer vor.
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?
Zitat:Vielen Dank übrigens für deine hervorragende und dauerhafte Hilfe, ich vermute mal bei meiner dilletantischen Vorgehensweise hätten sicherlich viele andere bereits ihre Nerven verloren.
Neben der Neigung zum Programmieren hab ich auch noch die Neigung zum Altruismus.
Jeder, der zur wahren Erkenntnis hindurchdringen will, muss den Berg Schwierigkeit alleine erklimmen (Helen Keller).
/
Problem beim Verwenden von 2D Arrays
