Pixelsearch / alternative für Bilder

  • Hallo,

    ich versuche ein Bild ( 7k x7k ) welches ich mit bitmapcreatefromfile einlese nach bestimmten Pixeln zu durchsuchen und die gefundenen Koordinaten zu speichern. Ich habe zu Testzwecken die Suchgrösse beschränkt ( kleiner Monitorgrösse um einiges Nachzuvollziehen und die Suche zu beschleunigen ). Da soweit alles funktionierte hab ich die Begrenzung entfernt und mit imagegetwidth entsprechend geändert. Nun ging garnichts mehr. Nach genauere Analyse von pixelsearch() stellte ich fest das hwnd nicht gleich hbmp ist. pixelsearch sucht nur im Fenster / Desktop.

    Gibt es eine Möglichkeit pixelsearch doch zur zusammenarbeit zu überreden? oder einen alternativen Befehl den ich bisher nciht gefunden habe ODER sollte /muss ich anders an die Sache herantreten ( kann man eine Gui erstellen die grösser als die Monitorauflösung ist )?

    Gruß

  • Hi,

    ich versuche ein Bild ( 7k x7k ) welches ich mit bitmapcreatefromfile einlese nach bestimmten Pixeln zu durchsuchen

    Verstehe ich nicht. Du hast schon eine Datei (die heißt deswegen so, weil da DATEN, in deinem Fall die Pixel, drin sind), die lädst du in den Speicher, schiebst sie von dort in den Grafikspeicher, lässt diese Daten auf dem Bildschirm anzeigen, um dann mit einem Datensuchprogramm am BILDSCHIRM nach Übereinstimmungen zu suchen?!

    ODER sollte /muss ich anders an die Sache herantreten

    DAS ist die richtige Frage, welche mit JA beantwortet werden muss!

    Wenn du bereits eine Bilddatei hast, dann stell diese uns zur Verfügung und gib an, welche der "Pixel" (ich nehme an du meinst eine Farbe innerhalb der Grafik) du suchst.

    Oscar

    Was hast Du denn vor?

    Wette?:D:party:

  • ... am BILDSCHIRM ...

    Das wollte ich vermeiden!!

    Daher der Versuch mit bitmaploadfromfile() das Handle an pixelsearch() zu übergeben, jedoch habe ich nicht beachtet das Pixelsearch nur Fensterhandle übernehmen kann ( oder sehe ich das falsch ).

    Da das Bild ( eingescannt ) eine Gesamthöhe und Breite von jeweils 7000x7000 Pixel im *.tif Format ( 25MB unkomprimiert 8Bit Farbe ) hat, bin ich davon ausgegangen das ich es nicht unskaliert auf den Bildschirm bringen kann (hab nur 2500x1600Pixel )

    Was versuche ich: Ich suche im Bild nach schwarzen Punkten und will diese in einer .txt speichern, Punkte in einer Region sollen dann zusammengefasst werden ( gr. Punkt, kl. Punkt etc.).

    Daher die Frage ob es zu Pixelsearch eine Alternative gibt wie ich das Bild ohne Monitor "lesen" kann oder eine andere Inspirationen/Herangehensweise.

    Bitte nicht mit HEX-Editoren anfangen ;(

  • Daher die Frage ob es zu Pixelsearch eine Alternative gibt wie ich das Bild ohne Monitor "lesen" kann oder eine andere Inspirationen/Herangehensweise.

    Ja, die Alternative nennt sich GDI+. Damit kannst du ohne das Bild anzuzeigen modifizieren und auslesen.

    Trotzdem bleibt die ursprüngliche Frage noch stehen, um was für ein Bild handelt es sich? Kannst du die Daten eventuell anders bereitstellen?

    Erzähl uns doch mal genau was du machen möchtest, werde konkret.

  • @vcopsmtl

    Du hast immer noch nicht begriffen um was es überhaupt geht...:Face:

    DU BRAUCHST KEINEN BILDSCHIRM!

    Wenn du irgendwelche Daten aus einer Datei auslesen und bearbeiten willst, brauchst du dafür kein BILD! Und schon überhaupt gar keine "Darstellung" auf einem Monitor oder gar in einer GUI.

    Einem Computer ist es völlig schnurz, nach was er in einem Haufen Daten sucht!

    Es ist allein deine beschränkte VORSTELLUNG von einem Bild, und dessen "Bearbeitung"....

    Mal angenommen, deine Datei liegt im 32Bit-BMP-Format vor, dann ist ein Bildpunkt durch die 4 "Farbbytes" ARGB beschrieben. https://de.wikipedia.org/wiki/Windows_Bitmap

    Für "rein schwarz" also die 4 Bytes 0x00000000.

    Wer hindert dich daran, diese Datei als binary zu öffnen, und per AutoIt-StringInstr()-Funktion nach der Position der 4 Bytes chr(0)&chr(0)&chr(0)&chr(0) zu suchen?

    Durch die im Datei-Header enthaltene bekannte Höhe und Breite des "Bildes" ergibt sich über die Position die Zeile und Spalte des Bildpunktes "schwarzes Pixel".

    Um ein "rotes Pixel" 0x00FF0000 zu finden, suchst du dann nach chr(0)&chr(255)&chr(0)&chr(0).....

    Das Laden der Datei und anschließendes Durchsuchen per StringInstr() dauert eine Handvoll Millisekunden incl. Schreiben der Textdatei mit den Koordinaten der "Pixelfarbe"

    Für das TIF(F)-Format gilt selbiges. Das ist kein BILD- sondern eine DATEI-Format!

    Die Umwandlung in eine durchsuchbare Bitmap (was anderes macht keinen Sinn) erfolgt, wie von alpines beschrieben, per _GDIPlus_BitmapCreateFromFile()


    Und überhaupt!

    Wer braucht in einer Textdatei die Koordinaten von schwarzen Bildpunkten?

    Da bekomm ich ja Bauchkrämpfe! Die Koordinaten sind doch bereits im "Bild" enthalten und können von dort direkt weiterverarbeitet werden.:Face:

  • Du hast immer noch nicht begriffen um was es überhaupt geht...

    DU BRAUCHST KEINEN BILDSCHIRM!

    Er hat mir eine PN geschrieben und ich hab in ein kleines Beispiel geschickt um das Bild mal nach solchen schwarzen Punkten / Felder zu durchsuchen.

    Leider ist GDI+ bei sowas (wenn man wirklich) jeden Pixel einzeln durchgeht (für das genauste Ergebnis) ziemlich langsam.

    Man könnte noch die Durchschnittsfarbe von einem Bildbereich berechnen, allerdings weiß ich nicht ob GDI+ so eine Funktion anbietet,

    das einzige was mir da in den Sinn kommt wäre einen bspw. 50x50 Bereich zu croppen und diesen mit Gauß zu blurren oder einem ähnlichen Filter und dann irgend einen Pixel davon abzulesen.

    Aber GDI+ ist der richtige Weg, das weiß er jetzt auch, nur muss man jetzt intelligent an die Aufgabe rangehen um das einigermaßen flott zu machen.

  • Der Trick ist doch, zu beschreiben was man benötigt, und nicht sich die Würmer aus der Nase ziehen zu lassen und zu jammern, was alles mit dem Schrott den man fabriziert hat NICHT funktioniert. Und dann für diese "falsche " Vorgehensweise auch noch Lösungen abzufragen!

    Diese Posts sind insgesamt wieder mal feinste Beispiele von X-Y-Problemen (siehe Link in meiner Sig)

    Fast alles, was in irgendeiner Art und Weise mit "Pixeln" zu tun hat, wurde hier im Forum (von vielen auch aus Geschwindigkeitsgründen mittels ASM) schon unzählige Male durchgekaut.

    Das ist für die "Cracks" ein einfach zu beackerndes Feld!

    Man sollte sich mal Fragen wie mies ein Startpost sein muss, dass sich diese Leute nicht mit "Lösungen" einklinken...

    Und nach dem 8. Post ist es immer noch nicht besser1

    Ich verweise mal auf einen weiteren Link in meiner Sig, "Wie man Fragen richtig stellt..."

    Lernresistenz wird nicht belohnt!

    • Offizieller Beitrag

    Nun bleib mal auf dem Teppich. Ich kann hier keine Aggressivität entdecken.

    Du solltest nur nicht gleich angepisst sein, wenn intensiv nachgefragt wird.

    Ich kann mit deinem Startpost auch nichts anfangen und habe mich deshalb von Anfang an raus gehalten. - Gehe aber auch von einem X-Y Problem aus.

    Im Übrigen solltest du in einem Programmiererforum keine bauchpinselnde Konversation erwarten. Wir machen das alles in unserer Freizeit und lieben daher zeitsparenderweise kurz und knackig Fakten.

  • Danke erstmal an alle die sich beteiligt habe, hab mit Alpines PN, von daher bin ich jetzt weiter :)

    Die Kernaussage: " eine alternative zu Pixesearch welches Header einer Bilddatei verarbeitet ist uns nicht bekannt ( aktueller stand ) und schau mal nach gdi+pixelget" -> wäre auch hilfreich gewesen.

    Andy wollte dich nicht beleidigen!!!!

  • Er hat mir eine PN geschrieben und ich hab in ein kleines Beispiel geschickt um das Bild mal nach solchen schwarzen Punkten / Felder zu durchsuchen.

    Magst Du uns das Script als Beispiel zur Verfügung stellen?

    Ich kenne solche Fragestellungen aus dem wissenschaftlichen Bereich, wo man das Aufkommen von Bildpunkten zählt. Klingt auf jeden Fall interessant.

    Beispiel: Punkte-Diagramm und Farbpunkte zählen.

  • Magst Du uns das Script als Beispiel zur Verfügung stellen?

    Das war nichts wildes, nur ein kleines Script um das Bild zu laden und die Hauptattraktion waren zwei ineinander geschachtelte For-Schleifen (Bildzeilen und Bildspalten durchgehen) und die Ausführung von _GDIPlus_BitmapGetPixel. Das Skript braucht bei 7000x7000 sowieso einige Minuten bis es durchläuft.

    Den Algorithmus wie man die Flecken findet habe ich nicht gecodet, da habe ich nur Tipps gegeben.

    Und das war nicht mehr als: Bild durchsuchen bis man einen schwarzen Pixel findet und von dort aus alle Nachbarn (und Nachbarn der Nachbarn abklappern) bis keine schwarzen Pixel mehr gefunden werden, dann hat man alle abgespeicherten Pixel als Region für den schwarzen Fleck.

    Da das natürlich sehr zeit- und rechenintensiv ist habe ich noch einen zweiten Vorschlag gemacht: Filter drüberlegen (Kontrast erhöhen, etc) und anschließend das Bild in kleine Rechtecke unterteilen und sie gleichmäßig mit Gauß blurren, dann nimmt man sich aus dem Quadrat einfach einen Pixel raus und schaut ob er über einem bestimmten Schwellwert liegt, und es sich somit um einen schwarzen Fleck handeln kann.

    Letzteres ist natürlich nicht so genau aber das ist ja unterschiedlich von Anwendungsgebiet zu Anwendungsgebiet.

  • Vielen Dank Alpines - das klingt sehr interessant.

    Danke erstmal an alle die sich beteiligt habe, hab mit Alpines PN, von daher bin ich jetzt weiter

    Hallo vcopsmtl, vielleicht magst Du im Ergebnis ein Codebeispiel zum Testen posten.

  • Geb hier mal einen Aktuellen Stand:

    bei mir braucht er für das Bild etwa 1h.

    Da es aber nicht bei 1 Bild bleibt habe ich *.ini mit speicherung der Bilddatei und abgebrochenen X / Y Koordinaten eingefügt incl. soweit Fehlerbearbeitung. Suche bisher nur nach 0x000000 was bisher zu wenig ist, den muss ich denk ich noch ändern.

    zZ nur komplette x/y suche, zusammen legen der Pixel wollte ich später machen. Da ich bei + die bereits gefundenen wieder rauslöschen müsste um doppelte und mehr Funde zu vermeiden.

    OffTopic: Will ne msgbox() mit viel infos machen und die Zeile ist sehr lang und vor allem unübersichtlich ( viele @crlf und & , hab bei einigen Befehlsbeispielen Lösungen gesehen war, irgendwas mit _ ( unterstrich ) oder ähnlich. Hab die aber immer gelöscht und nicht so getestet. Ist dies nur beim Posten mgl. und der Compiler gibt dann sowieso einen Fehler oder funktioniert das wirklich? Wenn ja wie geht das nochmal?

    Einmal editiert, zuletzt von vcopsmtl (23. Juni 2018 um 17:45)

  • Da mir die Dauer von über einer Stunde sehr grausam erscheint und ich grad lust hatte etwas zu programmieren, hab ich mal eine Programm geschrieben, was deutlich schneller ist.

    Ich hab das ganze in Java implementiert, einfach weil es schneller ist und ich Java im Moment viel öfter benutze.

    Die Dauer für ein 10MB jpg-file ist < 3 Sekunden.

    Das ganze läuft über die Kommandozeile (kann also mit runwait,... gestartet werden und benötigt keine Benutzereingaben).

    Ein Fenster implementiere ich vielleicht noch (momentan ist es noch leer)

    Die Ausgabe besteht aus einer Bit-Datei, die einfach für jeden Pixel 0 oder 1 in eine Textdatei schreibt, je nachdem ob dort ein Treffer war, oder nicht.

    Außerdem kann noch eine Datei mit allen Bereichen ausgegeben werden. In der steht dann in jeder Zeile ein Bereich und dort alle Pixelkoordinaten, die zu dem Bereich gehören.

    Bei der gesuchten Farbe können beliebige RGB-Werte angegeben werden (auch eine gewisse Range, also Rot von 0 bis 50,...). Außerdem kann auch der Alphawert berücksichtigt werden.

    Beim suchen des Bereiches kann definiert werden, ob die Moore- oder VonNeumann-Nachbarschaft verwendet werden soll.

    Zwei Beispiele zum ausführen mit der enthaltenen 7x5 Pixel testdatei:

    java -jar ImageAnalyser.jar -nogui -path test.png -scanColor 0,0,0 -scanArea true -outBits bits.txt -outArea area.txt -scanNeighborhood neumann

    java -jar ImageAnalyser.jar -nogui -path test.png -scanColor 0,60,0,60,0,60 -scanArea true -outBits bits.txt -outArea area.txt -scanNeighborhood neumann

    Die gesamte Hilfe:

    Spoiler anzeigen

    Manpage/Help of ImageAnalyser:

    -man

    -help

    Displays this manpage/helpfile

    -nogui silent mode (starts the programm without gui)

    -path <path>

    REQUIRED to start an analysis!

    Specifies the path of the image to open at startup

    -scanColor <r,g,b>|<a,r,g,b>|<rFrom,rTo,gFrom,gTo,bFrom,bTo>|<aFrom,aTo,rFrom,rTo,gFrom,gTo,bFrom,bTo>

    REQUIRED to start an analysis!

    Specifies the color to filter. This is are colorvalues between 0 and 255, seperated by a ","!

    Possible is the exact value Red,Green,Blue / Alpha,Red,Green,Blue or the Ranges.

    Examples:

    Scan white: -scancolor 255,255,255

    Scan white with half the opacity: -scancolor 127,255,255,255

    Scan black to darkgrey: -scancolor 0,50,0,50,0,50

    Scan black to darkgrey with opacity 127 to 255: -scancolor 127,255,0,50,0,50,0,50

    -scanNeighborhood <moore>|<neumann>

    Default: neumann

    Specifies the neighborhood to search if scanArea is true.

    Moore are all 8 neighbors, Neumann just 4 (top,left,bottom,right)

    -scanArea <true>|<false>

    Specifies if the search should scan an area or just single bits.

    -outBits <path>

    Specifies the path of the bitoutput.

    This file lists 0 if the Bit is in the given range, 1 otherwise.

    There will be one line of 0 or 1 for every Pixelline.

    -outArea <path>

    Specifies the path of the arealist output

    This file lists all areas. Each area is written in one line.

    An area contains all bits of the area separated by spaces. The coordinates are seperated with a ",".

    Du solltest aber nicht nach sehr großen verbundenen Bereichen suchen, dann tritt ein Stackoverflow-Error auf. Da muss ich die nächsten Tage (nach der Klausur am Dienstag vllt.) mal dran gehen, dass ich die Rekursion rausbekomme und stattdessen Schleifen o.ä. benutze.

    Der Sourcecode ist ebenfalls enthalten, falls sich jemand dafür interessiert ;)

    MfG Kanashius.

  • und schau mal nach gdi+pixelget" -> wäre auch hilfreich gewesen.

    Geb hier mal einen Aktuellen Stand:

    bei mir braucht er für das Bild etwa 1h.

    Weißt du was du bist?

    Diesen Ausdruck zu verwenden verbietet mir meine Kinderstube, fängt aber mit "A" an....

    Hier geht es um Bild(be bzw. ver)arbeitung von Bilddatengrößen von 7000x7000x4 Byte => 196MB und du kommst mit dem LANGSAMSTEN GDI(+) - gedöns wie GetPixel() an. Dabei habe ich schon etliche Male dargestellt, dass dieses Vorgehen, einzelne Pixel per "Grafikbefehl" aus von einem auf einem Bildschirm (bzw Grafikspeicher) dargestellten Bild auszulesen, völliger Nonsens ist.

    Ich bin endgültig raus...

    Nur mal so am Rande, HIER hatte ich etwas ähnliches vorgestellt.

    Zählt die Farben innerhalb eines Bildes und schreibt jede Farbe mit ihrer jeweils vorkommenden Anzahl in eine Datei. Für bspw. ein 3MB großes Bild benötigt das Script gerade mal 40 Millisekunden, für ein 27MB Bild 250ms . Das approximiert auf 196MB ergibt eine Laufzeit von...na, probiert es selber aus...

    Jedenfalls sollte das ganze "Problem" in einigen wenigen SEKUNDEN gelöst sein.

    Wäre es auch längst, wenn der TE mal seinen Arsch hochheben und in diesem Thread ein Beispielscript und die dazugehörige Bilddatei posten würde!

    Stattdessen werden diese Informationen per PN versendet...wtf...:Face:

    //EDIT:

    @vcopsmtl, überleg dir mal in einer ruhigen Minute, was du hier im Forum innerhalb der letzten 11 Tage nach der Erstellung deines Threads erreicht hast.

    Ist das Ergebnis deine Zielvorgabe? Was würdest du als Vorgesetzter eines Mitarbeiters, der sämtliche Vorteile des Internetz und des dort gesammelt vorhandenen KnowHow´s nicht in der Lage ist nur annähernd zu nutzen, machen?

    Loben? Befördern? Weitere 11 Tage abwarten?

    Wenn du erfolgreich Foren nutzen willst, solltest du daran arbeiten, schon im ersten Thread alles an Informationen bereitzustellen, was für eine Lösung deines Problems nötig ist.

    Und nicht das was DU denkst, denn genau DARAN bist du ja gescheitert, ansonsten wärst du nicht hier!

    Lernresistenz wird gnadenlos geahndet...

    ciao
    Andy


    "Schlechtes Benehmen halten die Leute doch nur deswegen für eine Art Vorrecht, weil keiner ihnen aufs Maul haut." Klaus Kinski
    "Hint: Write comments after each line. So you can (better) see what your program does and what it not does. And we can see what you're thinking what your program does and we can point to the missunderstandings." A-Jay

    Wie man Fragen richtig stellt... Tutorial: Wie man Script-Fehler findet und beseitigt...X-Y-Problem

    Einmal editiert, zuletzt von Andy (24. Juni 2018 um 11:51)