Graustufenauswertung für Bildserie

OK, "richtiger Grauwert" muss ich anderes ausdrücken. Die Frage ist ob das VI die richtige Anzahl von Pixel im Bereich von 0 bis Schwellwert ermittelt. Denn mit zunehmender Risslänge (dunklere Pixel) sollte der Wert "Anzahl der Pixel" im Bereich 0 bis Schwellwert steigen oder sehe ich das falsch?

Ich bin mir auch nicht sicher ob die Umrechnung vom Ausgangs-RGB-Bild in das Graustufenbild 100% exakt ist, da ich die eingefügten Fremd-Subs nicht genau verstehe. Ebenso weiß ich zwar das man eine Umwandlung in, "Boolescher Wert nach (0,1)" sowie "I32" macht, aber warum man das genau macht versteh ich nicht 100%tig.

Einen Fehler hab ich schon gefunden, welcher aber direkt vom Bild kommt. Denn durch die verwendete Kamera-Automatik sind alle Bilder nie 100% mit den selben Parametern aufgenommen wurden.

MFG
FrDtPa

Anzeige

Hallo FrDtPa,

bei Fragen wie "ich weiß nicht, ob mein VI korrekt arbeitet", sollte der Fragesteller immer Beispieldaten (bei dir ein Bild) und das erwartete Ergebnis (bei dir der erwartete Grauwert dieses Bildes) bereitstellen.

Dann (und nur dann) können wir beurteilen, ob dein VI das macht, was es soll!
Bis dahin kannst du aber durchaus selbst alle Debugging-Tools von LabVIEW nutzen…

Zitat:da ich die eingefügten Fremd-Subs nicht genau verstehe.

LabVIEW-Hilfe dazu lesen?

Zitat:Ebenso weiß ich zwar das man eine Umwandlung in, "Boolescher Wert nach (0,1)" sowie "I32" macht, aber warum man das genau macht versteh ich nicht 100%tig.

1. Boolsche Werte lassen sich so schlecht aufaddieren, deshalb die Umwandlung nach "0/1".
2. Die Umwandlung nach 0/1 erzeugt einen anderen Datentyp als I32. Dummerweise hat der einen oberen Maximalwert, der bei größeren Bildern schnell einen Overflow bewirkt. Deshalb wandelt man in einen Datentyp um, der einen deutlich größeren Maximalwert ermöglicht…

Hallo,

Zitat: Zitat:
Ebenso weiß ich zwar das man eine Umwandlung in, "Boolescher Wert nach (0,1)" sowie "I32" macht, aber warum man das genau macht versteh ich nicht 100%tig.

1. Boolsche Werte lassen sich so schlecht aufaddieren, deshalb die Umwandlung nach "0/1".
2. Die Umwandlung nach 0/1 erzeugt einen anderen Datentyp als I32. Dummerweise hat der einen oberen Maximalwert, der bei größeren Bildern schnell einen Overflow bewirkt. Deshalb wandelt man in einen Datentyp um, der einen deutlich größeren Maximalwert ermöglicht…

vielen Dank für die Erklärung .

Ich hab mal in einer Zip-Datei Beispielbilder hoch geladen, bei den ich per Paint :lol:ein Riss künstlich im immer selben Bild erzeugt habe. Wenn ich diese Bilder nun einlese und das Programm mit einem Schwellwert von 100 durchlaufen lasse, sackt die anzahl der Pixel zubeginn des Risses komischer Weise erst ab und steigt dann erst wieder.
Erwarten würde ich das der Wert sofort ausgehend von "Anfangsgrauwert" steigt und nicht erst absinkt.

MFG


  Beispielbilder.zip (Größe: 4,96 MB / Downloads: 253)

was da los ist, aber ich kann deinen Zip-File nicht herunterladen. Außerdem kennen wir nicht deinen aktuellen Sourcecode.

Gruß, Jens

Nachtrag: Einer der größten Probleme bei Bildverarbeitung machen Bilder, die nicht unter gleichen Beleuchtungsbedingungen und Belichtungseinstellungen aufgenommen wurden.

mysteriös, warum der Zip-Anhang nicht geht , naja gut hab einen Weg gefunden um meine beschriebenen Probleme zu lösen.

Nur..., da bin ich bei einer Sache auf eure Hilfe angewiesen. Ich hab mal das Beispiel-VI wieder hoch geladen. Ich möchte zuerst das VI starten und danach im Lauf des VI den Schwellwert eingeben. Sozusagen VI starten, Schwellwert per Hand eingeben und dann läuft erst der Loop vollständig durch. Ich bin mir ziemlich sicher das das gehen müsste, weiß aber irgendwie nicht wie... . Könnt Ihr mir das bitte mal zeigen? Vielen Dank Jungs

Das mit den gleichen Beleuchtungsbedingungen und Belichtungseinstellungen hab ich schon gelöst , trotzdem Danke für den Tip


MFG FrDtPa




  Grauwertausw.vi (Größe: 13,57 KB / Downloads: 241)

Hallo FrDtPa,

Zitat:Sozusagen VI starten, Schwellwert per Hand eingeben und dann läuft erst der Loop vollständig durch.

Dein VI soll also warten, bis der User einen Wert eingetippt hat und womöglich einen "OK"-Button gedrückt hat!?
Wieso sieht man dann in deinem VI nirgends eine Wartefunktion? Und auch keinen OK-Button?

Zitat: Zitat:
Sozusagen VI starten, Schwellwert per Hand eingeben und dann läuft erst der Loop vollständig durch.

Dein VI soll also warten, bis der User einen Wert eingetippt hat und womöglich einen "OK"-Button gedrückt hat!?

Genau so stell ich mir das vor .

Zitat:Wieso sieht man dann in deinem VI nirgends eine Wartefunktion? Und auch keinen OK-Button?

Das VI ist sozusagen ein Teil-VI aus einem umfangreicheren VI. Hab es jetzt einfach mal so raus kopiert. War bislang immer nicht in der Sittuation, dass während des Betriebs des VIs eingegriffen werden sollte, daher meine Unwissenheit^^.

Wie soll sowas grundsätzlich aussehen?


MFG

Hallo FrDtPa,

wie soll so etwas aussehen?

In Pseudocode etwa so:

Code:

repeat
  wait for user input
until Button=OK
read input

Ist das jetzt eine LabVIEW-Frage oder geht es um allgemeines Programmierverständnis?
Es gibt bestimmt auch BeispielVIs zum Thema "User-Input"…

Zitat:In Pseudocode etwa so:
Code:
repeat
wait for user input
until Button=OK
read input

Ja so stell ich mir das vor.

Zitat:Ist das jetzt eine LabVIEW-Frage oder geht es um allgemeines Programmierverständnis?

Es geht schon speziell um Labview. Soweit ich mich belesen habe, müsste das Problem doch mit einer Eventstrukturen zu lösen sein, oder nicht? Wie soll sowas aussehen?

Hallo FrDtPa,

mein Pseudocode besteht aus einer Schleife, die solange iteriert, bis der User einen OK-Button drückt. Dann wird der Input gelesen…

Probiere doch einfach mal selbst, sowas zu programmieren!
Und solange du noch nicht einmal eine einfache Schleife selbst hinbekommst, solltest du nicht mit der Eventstruktur hantieren. Tut mir leid, aber so ist es nun mal…