Bild filtern/ strukturiert absuchen

  • 0x0FF04CEFC ?

    Das ist mein Workaround zu BitmapGetPixel. Man kann auch den Wert von BitmapGetPixel so umwandeln, dass er die negative Zahl darstellt die 0xFF04CEFC darstellt.

    Du hast das ja mit Stringvergleichen gelöst, aber ich glaube Integervergleiche sollten schneller sein.

    So muss man nur einmal den Farbcode umwandeln und nicht jeden Farbcode den man von BitmapGetPixel zurückbekommt.

  • Muss irgendwie aus diesen Daten, die ich ausgespuckt bekomme erschließen können ob diese gefundenen Pixel zwei Sitzplätze nebeneinander darstellen.. LG

    Aus den bisherigen spärlichen Infos "Stadion" schließe ich, dass die Bilder der "Blöcke", also die Sitzplatzpositionen immer gleich sind?

    Die Koordinaten des Pixels passend zum ersten Platz in der obersten Reihe zu finden, sollte klar sein! Der Abstand von Sitzplatz zu Sitzplatz ist auch klar definiert...

    Da muss man ehrlich gesagt kein Genie sein, um anhand der Koordinaten eines beliebigen Pixels auf die entsprechende Reihe und Spalte im "Block" zu kommen. Zwei Zahlen miteinander zu multiplizieren bzw. zu dividieren, sollte jeder hinbekommen.

    Btw,, wenn es ausschliesslich um benachbarte Plätze geht, dann wäre ein klassisches "Pixelsearch" am allereinfachsten.

    Ohne jegliches Gedöns mit GDI(+)! Und auch ohne "Pixelsearch()" übrigens...

    Was macht Pixelsearch? Ein "String", in diesem Fall die Bilddaten aka "Pixel" werden in den Speicher geladen. Zugriff erhält man über einen Pointer auf diese Daten, Länge ist bekannt, Bidgröße in Pixel mal vier (Bytes pro Pixel)

    Legt man "über" diese Daten eine char-Struct, kann man einfachst den String auslesen und beliebige Sequenzen per StringInstr() in Mikrosekunden finden.

    Die Koordinaten der gefundenen Position sind zu ermitteln und anhand derer ggf. per LUT (LookUpTabelle) den Sitzplatznamen.

    Bei Verwendung von _GDIPlus_BitmapGetPixel() in "langen" Schleifen, bzw. um komplette Bilder zu durchsuchen wird mir immer ganz schlecht....

  • Ich verstehe nicht genau, wie ich das mit Pixelsearch umsetzen soll, damit muss ich die bilder soch immer öffnen oder wie muss ich das verwenden?

    Habe soweit alles am laufen mit diesem gdiplus, er gibt mir am ende immer eine kordinate eines pixels eines freien Platzes und vergleicht deren abstände, falls mehrere vorhanden sind. Sind 2 Plätze dich nebeneinander auf der x-Koordinate bekomme ich eine nachricht aufs Handy, soweit also sehr gut und an dieser Stelle nochmal lieben Dank für eure Mühe!

    Was mir nun noch etwas Kopfzerbrechen macht sind die Links zu den einzelnen Blöcken, denn diese muss ich bei jedem 'Spieltag' erneuern. Gibt es einen Weg, dass sich dass Programm die $url, hinter der sich die Grafik von den Sitzplätzen des Blockes verbergen automatisch zieht?

    Tut mir leid wenn ich dumme Fragen stelle, mehr als Erfahrungen in Java bis Klasse 12 am Gym und TI+ von den alten Taschenrechnern bringe ich leider nicht mit, bin im Moment Tag und Nacht am einlesen bis die Birne qualmt gngn.

    Achja, ich würde mich trotzdem seh interessieren, wie das mit Pixelsearch im genaueren funktioniert, da dass logischerweise schneller gehen würde.. Im Moment benötige ich ca. 12 Sek pro Block, was beschränkt auf etwa 16 Lukrative Blöcke ein delay delta von maximal ~ 3min ergibt..

  • Gibt es einen Weg, dass sich dass Programm die $url, hinter der sich die Grafik von den Sitzplätzen des Blockes verbergen automatisch zieht?

    Ja, mehrere... mit InetGet kannst du es als Datei speichern, mit InetRead ($INET_BINARYTRANSFER) bekommst du ein Binary-String, mit dem du dann eine Bitmap erstellen kannst. Hier ein Bsp. mit InetRead:

  • Ich verstehe nicht genau, wie ich das mit Pixelsearch umsetzen soll, damit muss ich die bilder soch immer öffnen oder wie muss ich das verwenden?

    Pixelsearch() als Autoit-Funktion sollst du gar nicht verwenden, ich hatte nur aufgezeigt, wie Pixelsearch "intern" funktioniert und wie man diese Funktionalität nutzen kann....

    Natürlich musst du die Bilder öffnen (was allerdings NICHTS mit dem Anzeigen auf dem Bildschirm zu tun hat! ), allerdings besteht ein Geschwindigkeitstechnisch himmelweiter Unterschied, ob du einzelne Pixeldaten per GDI(+)-Funktion in einer AutoItschleife suchst, oder diese Arbeit einer höchstoptimierten "internen" Funktion wie bspw. StringInstr() überlässt.

    Weitere Informationen, wie das funktioniert, findet man u.a. HIER

    s. auch den gespoilerten Abschnitt "Suche vom Bild im Bild". Übrigens benötigt man die damals von mir verwendete "prospeed.dll" nicht unbedingt, auf heutigen Maschinen ist selbst die 1000x langsamere AutoIt-Version schnell genug^^


    Im Moment benötige ich ca. 12 Sek pro Block, was beschränkt auf etwa 16 Lukrative Blöcke ein delay delta von maximal ~ 3min ergibt..

    Zeig mal, was du bisher hast, damit man mal konkret "Hilfe" leisten kann...

  • ok werde mich die nächste std mal akribisch damit beschäftigen, poste nacher dann was ich soweit habe.

    Btw find ichs wirklich erstaunlich wie hilfsbereit einige sind, wirklich super! Da bekommt man als eingerosteter im bereich programmieren glatt den zweiten Frühling:D

  • oKey, also wenn ich das richtig verstanden habe, muss ich aus dem bild eine bitmap machen, daraus einen string und den denn mit stringinstring nach meinen farbigen Pixeln durchsuchen, richtig? Ich hab jetzt einiges gelesen im Netz, komme aber nicht richtig darauf wie ich das anstellen soll.. ich glaube ich weiß nich nach welchen Befehlen ich überhaupt suchen muss, zumal ich immernoch verwirrt bin, da ich denke Pixelsearch öffnet doch immer ein fenster bzw benötigt koordinaten auf dem bildschirm?

    Anbei mal der Teil des Programms, der sich um die Bilder mit den Sitzplätzen kümmert und das passende Bild als Beispiel dazu: