Kreisausschnitt mittels _GDIPlus_ und PixelCheckSum

  • Hallo,

    gibt es eine Möglichkeit mit Hilfe der _Gdi_Plus_ Funktionen aus einer Grafik ( jpg oder Desktopfoto ) einen Kreisausschnitt auf die enthaltenden PixelFarben zu analysieren?

    zB. Schneide bei Mauseposition einen Kreis ( 4 -5 Pixel aus und berechne eine PixelFarbquersumme )?

    oder eher mit Pixelchecksum (nur Rechtecke) bzw. PixelGetColor() und das für +-x Pixel

    Gruß

    Einmal editiert, zuletzt von vcopsmtl (20. Januar 2020 um 12:00) aus folgendem Grund: _GDI_plus statt GUI_Plus

  • Musashi 20. Januar 2020 um 12:25

    Hat den Titel des Themas von „_GuiPlus_“ zu „Kreisausschnitt mittels _GDIPlus_ und PixelCheckSum“ geändert.
  • Die _GUI_Plus_ Funktionen sind mir gänzlich unbekannt. Solltest du aber Funktionen der GDIPlus.au3 meinen, solltest du deinen Post dahin gehend anpassen,

    Im Beitragstext wurde es bereits von vcopsmtl geändert. Ich habe aber auch mal den Titel angepasst ;).

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Danke für Anpassungen!!

    Aanbei eine Frage zu PixelGetColor: - seit wann wird ein Dezimalwert zurückgegeben? Ich hab alte Skripte ( 2 Jahre alt ) da wird der Hex-Code zurückgegeben.

  • Anbei eine Frage zu PixelGetColor: - seit wann wird ein Dezimalwert zurückgegeben?

    Ich hab alte Skripte ( 2 Jahre alt ) da wird der Hex-Code zurückgegeben.

    Selbst in Forenbeiträgen (EN/DE) aus dem Jahre 2007 gibt PixelGetColor einen Dezimalwert zurück.

    Sicher, dass Du da nicht irgendwo Hex() verwendest ?

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Hallo,

    hab einen anderen Thread gefunden und diese Funktion angepasst sodass es jetzt klappt.

    Was ich jetzt machen will ist die durchschnittliche Farbe zu bestimmen.

    Das Einlesen von pixelgetcolor in eine Variable geht ( in DEC schreibweise :) und ich weiss immer noch nicht warum ich das mit Hex-Werten verglichen hab:/) Ich hoffe der Dec-Wert ist fortlaufen und nicht von den einzelnen Farben (RGB) zusammengesetzt ( BSP 0xFFFFFF = ‭16777215‬ und nicht 255255255 ) Ich hoffe es ist zu verstehen was ich meine )

    Ich will in HEX wandeln da die AU3-Window Info ebenfalls Hex Color ausgibt -> Wie kann ich die AU3 Window Info dauerhaft im Koord Mode -> Screen starten ( ist bei Neustart immer wieder auf Window zurückgesetzt )

    Ich habe jedoch Probleme daraus den Durchschnitt in Hexadezimal mir anzeigen zu lassen.

    Abgewandelt vom HEX-Beispiel:

    Code
    $Zahl = 6 / 2
    Local $sHex1 = Hex($Zahl)
    
    ; Zeigt das Ergebnis.
    MsgBox($MB_SYSTEMMODAL, $Zahl, $sHex1 & @CRLF & StringLen($Zahl))

    Sobald eine Division enthalten ist kann ich es nicht mehr nachvollziehen. Teilweise scheint es als würde jedes einzelne Zeichen in den entsprechenden HEX-Wert gewandelt. Hab die Msgbox unten angehangen.

    Ich bitte um Hilfe.

    • Offizieller Beitrag

    Das führt zu einem falschen Ergebnis.

    Obwohl "6 / 2" ein Integerwert ist, wird dieser von der Hexfunktion nicht als solcher erkannt.

    Zitat

    Function Hex

    Numbers passed as non-integers (those with decimal separator or exponent) are processed as doubles.

    Das Ergebnis ist (auch aus Sicht der AutoItfunktion "IsInt") ein Integer, tatsächlich ergibt 6/2 aber nicht 3, sondern 3.0! Und das ist ein Double.

    Erst mit "Hex(Int($Zahl))" erhält man das erwartete Ergebnis.

    Und die Länge 1 ist völlig korrekt, Vornullen zählen nicht.

  • Danke ich Verstehe!!

    eigentlich logisch, da die Variable, wenn verwendet nicht mit dem Ergebnis, sondern mit dem Wert ( in dem Fall der Formel ) ersetzt wird. Zu sehr wie ein Mensch gedacht.

  • Hallo BugFix

    Das Ergebnis ist (auch aus Sicht der AutoItfunktion "IsInt") ein Integer, tatsächlich ergibt 6/2 aber nicht 3, sondern 3.0! Und das ist ein Double.

    Ich bin gerade hier drüber gestolpert. Autsch. Das habe ich bisher nicht gewusst. :whistling:

    Woher weißt du, dass Division immer ein Double zurück gibt?

    Grüße autoiter

    • Offizieller Beitrag

    Woher weißt du, dass Division immer ein Double zurück gibt?

    Ob das definitiv so ist, kann ich gar nicht mal sagen. Aber zumindest rechnet Autoit mit Ergebnissen von Divisionen als Double. Das ist der Funktionsbeschreibung von Hex zu entnehmen und somit im AutoIt-Kontext für mich manifestiert.

    Ich mach mir mal Gedanken, ob sich das irgendwie prüfen lässt.

    EDIT:

    Ich habe zwar noch kein sicheres Verfahren zum Test auf Double gefunden, aber zumindest ist mir aufgefallen, dass das Ergebnis einer Division (mit Rest) auf keinen Fall Float sein kann. Denn wie hier zu sehen ist, speichert Float einen falschen Wert, Double dagegen den korrekten. Sehr seltsam.

    Ergebnis:

    Code
    INT   5/3 1
    INT   6/3 2
    DBL   5/3 1.66666666666667
    DBL   6/3 2
    FLOAT 5/3 1.66666662693024
    FLOAT 6/3 2
  • Haha, owei. Wieder ein Bsp. dafür, dass man bei AutoIt nicht zu genau hinschauen sollte :D

    Ich habe mir die Beschreibung von Hex angeschaut. Du meinst: Numbers passed as non-integers (those with decimal separator or exponent) are processed as doubles.

    Das bedeutet aber nicht, dass AutoIt alle Ergebnisse von Divisionen als Double zurück gibt, sondern nur, dass die Funktion Hex, übergebene Werte mit Dezimaltrennzeichen oder Exponent als Double behandelt.

    Ohne jetzt wie du zu genau hinzuschauen, was wirklich gemacht wird, würde ich daher sagen, die Division wird vor der Übergabe an Hex ausgeführt und Hex bekommt bei 6/2 den Int Wert 3 übergeben.

    Grüße autoiter

  • Das bedeutet aber nicht, dass AutoIt alle Ergebnisse von Divisionen als Double zurück gibt, sondern nur, dass die Funktion Hex, übergebene Werte mit Dezimaltrennzeichen oder Exponent als Double behandelt.

    Möglicherweise bringt das folgende "Bugticket" etwas Licht in die Sache (obwohl bereits älter) :

    32-bit integers converted to doubles after division

    Zitat von Melba23 :

    "As the vast majority of division operations return a value having a fractional component, I do not see how AutoIt can be expected to do other than convert the result into double format."

    [übersetzt :]

    "Da die überwiegende Mehrzahl der Divisionen einen Wert mit einer Bruchteilkomponente zurückgibt, sehe ich nicht, wie man von AutoIt etwas anderes erwarten kann, als das Ergebnis in das Double-Format zu konvertieren."

    EDIT :

    Aus dem selben Beitrag (von jchd) :

    Code
    ConsoleWrite(VarGetType(Floor(1/3)) & @LF)
    ConsoleWrite(VarGetType(Ceiling(1/3)) & @LF)

    "both return Int32, as expected. Else it would be an actual bug, contrary to integer division always returning a double: a (questionable) design decision against which we can't do much."

    "beide geben wie erwartet Int32 zurück. Sonst wäre es tatsächlich ein Fehler, im Gegensatz zur ganzzahligen Division, die immer ein Double zurückgibt: eine (fragwürdige) Designentscheidung, gegen die wir nicht viel tun können."

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (26. Februar 2020 um 16:41) aus folgendem Grund: Antwort erweitert

  • Haha, die verrückte Welt von AutoIt. Danke dir für den Link Musashi.

    Ich liebe diese Sprache, weil manso schnell ans Ziel kommt. Aber bei all dem, was einem abgenommen wird, bleibt für mich dann immer mal wieder Konfusion zurück :D

    Code
    ConsoleWrite("IsInt(6/2): " & IsInt(6/2) & @CRLF)
    ConsoleWrite("IsFloat(6/2): " & IsFloat(6/2) & @CRLF)
    ConsoleWrite("Hex(6/2): " & Hex(6/2) & @CRLF)
    ConsoleWrite("Hex(3.0): " & Hex(3.0) & @CRLF)
    ConsoleWrite("Hex(3): " & Hex(3) & @CRLF)

    IsInt(6/2): 1

    IsFloat(6/2): 0

    Hex(6/2): 4008000000000000

    Hex(3.0): 4008000000000000

    Hex(3): 00000003

    Ich bin bedient :S

    Grüße autoiter

    Einmal editiert, zuletzt von autoiter (26. Februar 2020 um 16:47)

  • Ich liebe diese Sprache, weil man so schnell ans Ziel kommt.

    Alles hat halt seinen Preis :P.

    Im Bugticket findet man einen Kommentar von jchd (ein echter Insider).

    Ich habe meinen Beitrag dbzgl. erweitert (s.o.).

    Offenbar würde eine Änderung dieser Funktion(en) haufenweise Probleme nach sich ziehen, daher belässt man es wohl lieber bei dieser "Designentscheidung".

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

    Einmal editiert, zuletzt von Musashi (26. Februar 2020 um 17:36) aus folgendem Grund: typo

  • Tja, was soll man machen ^^

    Wäre es dann nicht angebracht in der AutoIt-Hilfe beim Operator / wenigstens darauf hinzuweisen, dass als Ergebnis einer Division von Ganzzahlen immer ein Wert des Typs Double geliefert wird, auch wenn AutoIt bei der Anzeige .0 wegschneidet und die Funktionen IsInt und IsFloat dich anlügen?

    water  Tweaky was haltet ihr davon ;)

    Grüße autoiter

  • Vorab :

    Bevor sich jemand die Mühe macht einen work-around zu erstellen, empfehle ich eine Google-Suche.

    Es gibt diverse (auch aktuelle) Threads zu diesem und verwandten Themen.

    Beispiele :

    calc-double-and-integer

    float-to-integer-but-integer-get-to-big

    Wäre es dann nicht angebracht in der AutoIt-Hilfe beim Operator / wenigstens darauf hinzuweisen, dass als Ergebnis einer Division von Ganzzahlen immer ein Wert des Typs Double geliefert wird ...

    Kurz gesagt : JA ;) !

    Sobald das Thema hier (halbwegs) abgeschlossen wurde, werde ich eine entsprechende "Warnung" in den Thread Sammelthread "AutoIt Interne Funktionen : Erwartetes Ergebnis -> Tatsächliches Ergebnis" aufnehmen.

    Die Hilfe hat aber natürlich eine größere "Reichweite" ^^.

    Gruß Musashi

    86598-musashi-c64-png

    "Am Anfang wurde das Universum erschaffen. Das machte viele Leute sehr wütend und wurde allenthalben als Schritt in die falsche Richtung angesehen."

  • Die Hilfe hat aber natürlich eine größere "Reichweite" ^^ .

    Vor allem ist die Hilfe auch die Referenz. Dort sollen die Angaben stimmen! Aktuell ist das schlicht nicht korrekt (auch wenn es so aussieht und in den meisten Fällen nicht auffällt).

    Grüße autoiter

  • Sobald ich Zeit finde, werde ich das mal im engl. Forum diskutieren und mich dann wieder melden.
    Sollte ich das vergessen, bitte um kurze Erinnerung ;)