Java Bildschirmkoordinaten vs Bilder Dimensionen

Java-Forum Java-Grundlagen
1

Hallo, für eine Sache an der ich derzeit werkele will ich im Endeffekt einen Screenshot machen und in dem Screenshot die rgb Werte bestimmter Pixel betrachten.

Nur irgendwie sind da nicht immer alle Längen und Breiten gleich.
Was ich meine:
Ich habe Bildschirmauflösung 1920x1080 und aber 175% Skalierung aktiviert.

Wenn ich nun aber mittels Toolkit.getDefaultToolkit().getScreenSize() die Bildschirmdimensionen anfrage, zeigt er mir nur 863x1535 an, also kleiner.
Der „Robot“ scheint , da mit mousemove rumgetestet, auch die gleichen Dimensionen zu verwenden.

Wenn ich hingegen über die normale Druckfunktion des Notebooks („Drucken“ Taste auf dem Notebook) einen Screenshot mache, hat das entsprechende png Bild sogar angeblich nur 1293x779 Pixel.

Also nochmal kleiner.

Also ich blicke da nicht durch.
Eigentlich wollte ich mit

			PointerInfo a = MouseInfo.getPointerInfo();
			Point b = a.getLocation();

oder Ähnlichem vorab auf dem Bildschirm mir ein bestimmtes Pixel raussuchen, dann screenshot mahcen und im gespeicherten Screenshot von jenem bestimmten Pixel die rgb Werte auslesen.
Wenn sich hier aber die Pixeldimensionen 20 mal auf unbekannte Weise verändern und skalieren, geht das ja wohl gar nicht :frowning:

Weiß jemand wie man hier die einen in die anderen Dimensionen „umrechnet“?
Wie wäre es eigentlich wenn ich mit dem robot getscreencapture ein bufferedimae bekäme (ohne es in einer Datei zwischenzuspeichern).
Hätte das dann noch mal andere Pixelzahln in Länge und Breite? :-/

2

Nun, man kommt wohl an die ganzen Koordinaten und Transformationen ran - siehe auch die letzte Antwort von Screenshots werden mit schwarzen Bereichen aufgefüllt? - #4 von Marco13 . Aber … es kann kompliziert sein - selbst wenn man nur einen Monitor hat :D. Die Skalierungen sind ein wichtiger Punkt. Bei solchen Sachen wie der „eingebauten“ Screenshot-Funktion weiß man ggf. nicht, ob die Taskleiste mitgerechnet wird (obwohl sich damit die Breite nicht ändern sollte :confused: ).

Mal ein paar Stufen höher:

oder Ähnlichem vorab auf dem Bildschirm mir ein bestimmtes Pixel raussuchen, dann screenshot mahcen und im gespeicherten Screenshot von jenem bestimmten Pixel die rgb Werte auslesen.

Für das Bestimmen der Farbe gibt es eine extra Funktion, Robot (Java Platform SE 8 ) , d.h. vielleicht braucht man gar keinen Screenshot.

(Die Frage, was die x/y dort sind, und ob die skaliert werden müssen, stellt sich dann noch, aber ich hoffe/vermute, dass das alles recht einfach und in dem Sinne „konsistent“ sein sollte, dass man da einfach die Koordinaten verwenden können sollte die man von anderen Stellen, z.B. von MouseInfo.getPointerInfo() bekommt…)

EDIT: Nur zur Klärung: Wenn du mehrere Pixel in der Nähe des Mauszeigers analysieren willst, wäre ein Screenshot natürlich sinnvoll - eine detailliertere Beschreibung des Ziels könnte helfen - ist es immernoch das gleichen wie im verlinkten Thread?)

3

Hallo,
die Methode vom Robot kenne ich teilweise, wobei ich im Sinne der Geschwindigkeit es vermutlich bei vielen Prüfpixeln schneller geht wenn es als Bild zwischengespeichert ist und daraus dann die rgb werte abgelesen werden. Meint zumindest mal das Internet weil da bei der Robot Funktion Alles mögliche aufgerufen werden muss, und das jedes mal neu pro pixel.

Mein grundlegendes Problem ist im übrigen noch Dasselbe:
Ich habe die Casinoseite und will bspw. vom Rechteck rechts oben, wo die zuletzt gedrehten Zahlen drin sind, ebe jene Zahlen auslesen.
Ideal wäre das natürlich mit OCR, was aber selbst für solche Standardzahlen offenbar eine Riesensache ist, wo man Datenströme auslesen muss oder sich mit nutzlosen Maven Programmen und Co. rumschlagen muss.

Daher bin ich teilweise am Aufgeben und wäre derzeit shcon für eine Farbbestimmung froh.
Daher liebäugle ich derzeit mit einer relativ simplen Strategie:
Ich kann ja ablesen so in welcher Höhe ungefähr sich die zuletzt gedrehte Zahl befinden muss.
egal ob sie in rot links, steh, grün mittig oder schwarz rechts.

ich könnte also vemrutlich eifnahc hingehen und in passender Höhe so eine Pixelzeile betrachten und von links nahc rechts gucken bis ich auf eine Farbe stoße die nicht der allgemeinen Hintergrundfarbe entspricht.
Die muss dann der Farbe der zuletzt gezogenen Zahl entsprechen.

In der Theorie so schön und gut aber wenn sich., nur wiel ich ne 175% Skalierung benutze, dann natürlich die Pisitionen aller Pixel sosntwie verschieben und das gewollte Pixel statt bei (1100, 200) dann plötzlich bei (678, 57) liegt, ist das unschön.
Vor Allem wenn ich vorher nicht weiß was wohin „verschoben“ wird.
Und ich kann ja die „Position“ des Pixels nur anhand des realen bildschirms, den ich sehe, bestimmen.
irgedeine „zeig mir die mausposition“ funktion, maus über das wunschpixel und ich kenne die position.
Falls nicht robot, toolkit und Co. dann andersartige auflösungen ungefragt benutzen wollen.

Zu diesem Problem mit den ungewollten Auflösungsänderungen, weil java meint es müsste sich um skalierungsmsit kümmern den es gefälligst iignorieren soll, stieß ich hierauf:

offenbar eina abgeänderte mousemove funktion, die unabhängig von der skalierung funktionieren sollte.
Wie der Herr dort nun aber zwischen realem pixel und „virtuellem Pixel“ hin und her rechnet ist mir noch unklar.

Weil irgendeine Logik muss der Computer ja haben, wie er die realen 1920x1080 irgendwie auf 1535x863 runterrechnet. hoffentlich einen linearen Zusammenhang sonst wärs richtig sch… :-/

zumal muss ich ja auch die koordinaten wissen wenn ich bspw. eienn bestimmten knopf unten rechts mit dem robot klicken lassen will.
Wenn der wegen iiotische auflösungsänderungen ganz anderswo hinklickt, wäre das ziemlich mies.

wobei ich, falls ich toolkit zum positionsbestimmen benutze, wohl diese koordinaten so auch 1 zu 1 für den robot nutzen kann weil gleiches koordinatensystem.

ocr wäre mir zwar immer noch lieber gewesen aber tesseract mit seinen „maven depencies“ BS, unnötige IDEs, .jar Files die man an unbekannten orten reinpulvern muss.
Man findet ja bei google nicht mal eine gescheite anleitung die nicht auf der annahme basiert dass man eclipse, maven, linux und anderer msit hat oder nutzt.

als normaler windows nutzer mit java und stinknormaler konsole findest du da nichts, was sich nur mit eingien java befehlen lösen lässt. zumindest keine gute anleitung.

4

Es gibt ein paar Punkte, auf die man da jetzt näher eingehen könnte - aber aus Zeitmangel, erstmal kurz:

Geschwindigkeit es vermutlich bei vielen Prüfpixeln schneller geht wenn es als Bild zwischengespeichert ist und daraus dann die rgb werte abgelesen werden.

Ja.

weil java meint es müsste sich um skalierungsmsit kümmern den es gefälligst iignorieren soll,

Stell’ deine Skalierung auf 1.0. Und wenn du das nicht willst, muss sich irgendjemand oder irgendwas darum kümmern. So ist das halt. Ein Problem geht nicht notwendigerweise weg, nur weil man es ignoriert.

Aber der verlinkte Gist macht wohl etwas, was du in ähnlicher Form brauchen wirst. Die Beschreibung mit dem „Error Field“ habe ich nur überflogen, und sie wirkt überkompliziert, und es stellt sich dann auch immer die Frage, wo der Skalierungsfaktor denn herkommmt, aber … dazu hatte ich ja schon auf den anderen Thread verlinkt.

(Was dort gerechnet wird ist dann ziemlich trivial)

Man findet ja bei google nicht mal eine gescheite anleitung die nicht auf der annahme basiert dass man eclipse, maven, linux und anderer msit hat oder nutzt.

Einerseits verstehe ich diese Vorbehalte gegen „Infrastrukturen“ wie Maven. Ich habe (viel zu?) lange auch mit einem Texteditor programmiert und möglichst wenige externe JARs verwendet, die ich händisch in den Classpath geschrieben habe. Aber … Lern’ damit umzugehen. Und wenn du denkst, „Java und Eclispe und Maven“ sei Sche!ße, dann empfehle ich dir, dir mal

  • JavaScript und VSCode und npm, oder
  • C++ und Visual Studio und CMake

anzuschauen, und dann wirst du wissen, „Java und Eclispe und Maven“ ist im Vergleich dazu die Manifestation des Wortes „Glückseligkeit“.

tl;dr: Man kann sich für das konkrete Problem ja was basteln, was einem das Leben einfacher macht. (Das ist übrigens das, was Programmierer den ganzen Tag über tun sollten. Ich meine, IMMER und STÄNDIG. Das ist nicht nur so dahin gesagt. Das ist WICHTIG).

Hab’ gerade nicht mehr viel Zeit, darum kannst du, wenn du willst, mal dieses Programm starten/anschauen, und sagen, was es auf der Konsole ausgibt:

package bytewelt;

import java.awt.AWTException;
import java.awt.Dimension;
import java.awt.DisplayMode;
import java.awt.GraphicsConfiguration;
import java.awt.GraphicsDevice;
import java.awt.GraphicsEnvironment;
import java.awt.MouseInfo;
import java.awt.Point;
import java.awt.PointerInfo;
import java.awt.Rectangle;
import java.awt.Robot;
import java.awt.geom.AffineTransform;
import java.awt.geom.Point2D;
import java.awt.image.BufferedImage;

public class RobotWithScalingTest
{
    public static void main(String[] args) throws Exception
    {
        
        System.out.println("Screen size is " 
            + RobotWithScaling.getScreenSize());
        System.out.println("Virtual screen size is " 
            + RobotWithScaling.getVirtualScreenSize());

        BufferedImage screenshot = RobotWithScaling.createFullScreenCapture();
        System.out.println("Full screen screenshot size is "
            + screenshot.getWidth() + " " + screenshot.getHeight());
        
        
    }
}

class RobotWithScaling
{
    private static final Robot ROBOT;
    private static final AffineTransform TRANSFORM;
    static 
    {
        Robot r = null;
        try
        {
            r = new Robot();
        }
        catch (AWTException e)
        {
            System.err.println("Could not initialize robot");
        }
        ROBOT = r;
        
        GraphicsEnvironment ge = 
            GraphicsEnvironment.getLocalGraphicsEnvironment();
        GraphicsDevice gd = ge.getDefaultScreenDevice();
        GraphicsConfiguration gc = gd.getDefaultConfiguration();
        TRANSFORM = gc.getDefaultTransform();
        
        System.out.println("TRANSFORM is " + TRANSFORM);
    }

    public static synchronized BufferedImage createFullScreenCapture()
    {
        Dimension d = getScreenSize();
        return createScreenCapture(new Rectangle(0, 0, d.width, d.height));
    }
    
    public static synchronized BufferedImage createScreenCapture(Rectangle rect) 
    {
        Point2D p0 = new Point2D.Double(rect.getMinX(), rect.getMinY());
        Point2D p1 = new Point2D.Double(rect.getMaxX(), rect.getMaxY());
        Point tp0 = convertToDevicePoint(p0);
        Point tp1 = convertToDevicePoint(p1);
        Rectangle tRect = new Rectangle(
            tp0.x, tp0.y, tp1.x - tp0.x, tp1.y - tp0.y);
        return ROBOT.createScreenCapture(tRect);
    }
    
    public static Dimension getScreenSize()
    {
        GraphicsEnvironment ge = 
            GraphicsEnvironment.getLocalGraphicsEnvironment();
        GraphicsDevice gd = ge.getDefaultScreenDevice();
        DisplayMode dm = gd.getDisplayMode();
        int w = dm.getWidth();
        int h = dm.getHeight();
        return new Dimension(w, h);
    }

    public static Dimension getVirtualScreenSize()
    {
        Dimension d = getScreenSize();
        Point p = new Point(d.width, d.height);
        Point tp = convertToDevicePoint(p);
        return new Dimension(tp.x, tp.y);
    }
    
    private static Point2D convertToDevice(Point2D p)
    {
        Point2D result = new Point2D.Double();
        TRANSFORM.transform(p, result);
        return result;
    }
    private static Point convertToDevicePoint(Point2D p)
    {
        Point result = new Point();
        TRANSFORM.transform(p, result);
        return result;
    }
    
}
6

Ich bin mir unsicher, wie man das Problem reproduzieren kann.

Meinst du diese 1 oder diese 2 Einstellung?

Auch eine schnelle Suche im Internet, dass getScreenSize falsche Werte liefern würde, war nicht erfolgreich.

Ich möchte das nur ungerne selber ausprobieren.

7

Ich meine das erste Bild. da habe ich oben 175% eingestellt und unten wie erwähnt 1920x1080 (das höchste was mein 2015er Qosmio so hinkriegt).

8

Ich sehe hier gar kein Bild. Übersehe ich etwas?

Ahh, jetzt verstehe ich, du meinst mein Bild. Ok, vielleicht kann ich es später testen.

9

"Einerseits verstehe ich diese Vorbehalte gegen „Infrastrukturen“ wie Maven. Ich habe (viel zu?) lange auch mit einem Texteditor programmiert und möglichst wenige externe JARs verwendet, die ich händisch in den Classpath geschrieben habe. Aber … Lern’ damit umzugehen. "

Weißt du, eime programme bestehen zu 90% aus einer einzigen Java Datei, die ich simpel mit javac blabla.java und java blabla in der Konsole ausführe.

Mal lasse ich was ausrechnen, mal mache ich jenes, mal dieses.

Für Profiprogrammierer hier vermutlich „Kinderkram“ den ich da so vor mich hin bastle.
Und sei es nur ein Programm das mal alle Lottozahlkombinationen als Arrays bastelt und mit denen rechnet oder so.

Und dann will man in einem programm einfach nur aus einem Bild oder auch direkt vom bildschirm eine Zahl, wohlgemerkt im billigsten Standardcomputerfont, simpler wirds echt nimmer, ablesen lassen.

Internetanleitungen sind dann extrem umstöndliche 200 Dateien und Ordner Strikturen bei Github.
Oder eine Anleitung die damit anfängt dass man erst mal eine fcking xml Datei für irgendwelche „maven dependencies“ chreiben soll.

Dann muss man natürlich auch Mist Eclipse und Co. nutzen, irgendwelche jar files zu hunderten wo pfadmässig hinterlegen (die java dateien rauszurücken dmait man sie im programm importieren kann geht ja nicht -.-).

heißt, wenn ich das ausführen will, muss ich shcon mal physich da sein, eclipse rotz anmachen, dort irgendwelche jars importieren und das kompilieren und ausführen.

Ich will keinen so unnötig umständlichen mist.
Ich will an sich einfahc nur eine, womöglich shcon vorab kopmpilierte (javac und so) java datei, die ich mittels bat datei oder dem taskmanager auto ausführ programm automatisch aufrufen lassen kann und die

  1. screenshot machen
  2. ocr.

usw macht.
ohne mich, ganz von alleine.

Und ich hocke in Malle, theoretisch wenn ich nicht viel zu arm für sowas wäre.

Da will ich dann keine IDEs starten oder gar noch irgendein Maven Quatsch händeln, der nahc erstem lesen auch nix Anderes ist wie eclipse.
Projektmanagementkrams, wo man für jeden Mist eigenes Projekt, name, Klasse, Datei, etc. angeben muss.
Nur um hallo Welt zu printen.

Können die herren chronischgelangweilt ja in ihren 200 Dateien Rechnerzentren nutzen wo hunderttausende Leute schaffen.
Für meine sprichwörtlich 2 java Dateien, die ich mal so alle paar Wochen zsutande bringe, braucht es kein Projektmanagerprogramm oder anderen Mist.

Simpel java Datei, kompilieren, Ausführen. 2 zeieln ind er Konsole, braucht es weder Maven, Eclipse, noch sosntwas dafür.

Eclipse bspw. macht es mir nur unnötig schwierig, wenn ich bspw. wie jeder Normalsterbliche meine .java Datei auch mal sehen will weil ich sie bspw. kopieren will kann ich die ganzen Isntllationsordner von eclipse durchsuchen -.-

Komme mir vor, als würde ich das Haus vom Nikolaus zeichnen willen in paint und jeder Depp sagt mir, als Erstes muss ich 2 Jahre lang Photoshop studieren, Adobe After Effects erlernen und Co.

Over the Top für den geringen kleinkram den ich machen will.

PS: ich deutete nur an, dass Eclipse und Maven shceiße sind.
Java ist okay.
Wenn wir von Programmiersprachen ausgehen, dann wäre Autohotkey ein richtiger „shceiß“ Kandidat mit seinem legacy vs expression mode Müll :slight_smile:
Aber java ist cool.

Werde deinen Code mal testen :slight_smile:

10

Was ich so mit meinen begrenzten Kenntnissen und Google mir anlas, wird offenbar beim Skalieren hingegangen und es werden irgendwie Pixel vergrößert bzw zu größeren Blöcken zusammengefasst irgendwie.

Daher wird die Anzahl an realen Pixeln auf komischen Wegen zu virtuellen Pixel hin transformiert.
Und Robot und Co. geht halt nicht von den realen Pixeln aus sondern richtet sich daran was das System sagt wie viele virtuelle Pixel da sind.

Wobei, wenn man ja die Umrehcnungsquote kennen würde, könnte man ja ein real üixel position auf eine crituelle pixel position umrechnen.
Was offenbar das von mir zwischendurch verlinkte tut, glaube ich zumindest :slight_smile:

11

Ein Pixel ist immer ein Pixel. Ich denke auch nicht, dass Windows da eine affine Transformation anwendet. Ich denke, da kommt andere Magie zum Einsatz.

12

Nun, den Rant nehme ich mal zur Kenntnis. Wie gesagt: Wenn dich das bei Java schon nervt, geh’ davon aus, dass es bei ALLEN anderen Programmiersprachen+Umgebungen (die ich bisher gesehen habe) um viele, viele Größenordnungen besch!ssener ist. Ich entwickle in meiner Freizeit mit Java+Maven+Eclipse „zur Entspannung“, weil ich mich nicht mit dem haarsträubenden Mist beschäftigen will, den es da in anderen Welten gibt.

Das ist bestenfalls nützlich für dich. Aber für ALLE anderen Menschen ist das, was du da generierst, nutzloser Datenmüll. (Und wenn du meinst, dass du dir damit irgendwelche relevanten Programmierkenntnisse aneignest: Das ist eher unwahrscheinlich).

Solange das Programm nicht erkennen soll, ob auf dem Screenshot ein Vogel zu sehen ist, geht’s ja. Weißt du… wenn irgendwer mal eine Funktion geschrieben hätte wie

public static String detectTextIn(BufferedImage image) { ... }

dann könnte jeder diese Funktion verwenden. Wenn du so eine Funktion findest: Zeig sie mir. Wenn du keine findest, kannst du entweder darüber nachdenken, warum du so eine Funktion nicht findest, oder du kannst die Antwort auf diese Frage finden, indem du mal versuchst, die selbst zu implementieren.

Ansonsten ist natürlich vieles von dem, was du da schreibst, grober Unfug, und zwar auf allen möglichen Ebenen der Analyse, aber auch das ignoriere ich jetzt mal.

Zurück zum Kernthema:

Wie genau Windows dort an welchen Stellen welche Pixel umrechnet, weiß ich halt nicht (und werde das jetzt sicher nicht auf meinem Desktop testen). Aber … wenn du sagst, was das Testprogramm ausgibt, kann man vielleicht etwas erraten…

13

Ach so, jetzt geht es um Texterkennung… Das also ist des Pudels Kern. Sag das doch direkt. Google kann das doch auch auf Smartphones. Es ist für erfahrene Programmierer:innen also eine mittelschwere Aufgabe. Der Haken an der Sache ist, dass die Ergebnisse ungenau sind, und noch mal durch eine Autokorrektur gejagt werden müssen, wenn sie zum Beispiel vorgelesen werden sollen.

Das waren die schlechten Nachrichten. Die guten sind: Es gibt Libs, die die Position von Texten in Bildern einigermaßen genau bestimmen können. Aber, wie gesagt, nur einigermaßen genau. Mit so etwas ist immer ein Fehler behaftet.

Das hat aber alles eigentlich weniger mit der „Dimensionsproblematik“ zu tun… Man könnte für alle Fragen mehrere Fässer öffnen.

14

Und man könnte zu allen möglichen Themen kontextfrei und ohne die geringste Ahnung von irgendwas zu haben unnützen Senf dazugeben. Man könnte es auch bleiben lassen. Weitere themenfremde Beiträge werden gelöscht, ggf. gefolgt von einer Sperre.

1 „Gefällt mir“
17

Leute, wegen mir müsst ihr euch doch nicht streiten :slight_smile:

Was mir, nach etwas leserei über Resolution, Scaling und nochmal Nahcgucken meienr Einstellungen so auffällt:
Als Auflösung habe ich wie erwähnt
1920x1080.
Skalierungsfaktor ist 125% (ich war da durcheinander weil zwar 175% vorausgewählt war, aber ich eine „benutzerdefinierte Skalierung“ von 125% habe.
So oder so sind es am Ende 125%.

Toolkit.getDefaultToolkit().getScreenSize() liefert mir wie erwähnt 1536x864 zurück.
Primitives Rechnen zeigt mir dass 1920/1536 ziemlich genau 1,25 aka 125% ergibt.
Gleiches gilt für 1080/864.

Kurzum, ich vermute äusserst stark dass gilt:
Reale Koordinaten/Skalierungsfaktor=neue virtuelle Koordinaten

Bringt mir jetzt zwar direkt vermutlich nicht viel weil Java eh schon nur die virtuellen Koordinaten zurückgibt und agr nicht mit den realen arbeitet.

Aber gut zu wissen :slight_smile:

@Marco13:
" Das ist bestenfalls nützlich für dich. Aber für ALLE anderen Menschen ist das, was du da generierst, nutzloser Datenmüll."

Da ich nicht im geringsten für mein kleines Hobbyprogrammieren bezahlt werden, zähle nur ich. Was juckt mich was Andere darüber denken. Rücke ich eh nicht raus :stuck_out_tongue:
Kann es Datenmüll sein. Wenn ich in ner Firma wäre, müsste ich vermutlich eh deren Projektmanagementmist nutzen.
Aber für meine kleine Garagenprogrammiererei muss es nur für mich funktionieren.
Und da lege ich mir schlicht und ergreifend für simples OCR keine 20 verschiedenen Programme zu, die nur in irgendwelchen Programmiergruppen oder sowas Sinn machen wo man Angst haben muss dass irgendwer den Überblick über die 200 verschiedenen Firmenprojekte verliert.

Ich werde vermutlich weiterhin nach einer gescheiten 1. 2. 3. Anleitung suchen wie man unter Windows, ohne Maven, Raven und Co. , einfahc nur Tesseract installiert und nutzt.
Oder ein anderes OCR Teil, wobei die ja in undurchsichtigen Github Strukturen vorliegen.

Verstehe nicht was man an Eclipse will.
Dass es automatishc eine main methode in jede Klasse klatscht?
oder man sprichwörtlich VOR dem Shcrieben der klasse schon angeben muss welche Inputvariabeln+Datentyp (aka fertige Signatur) das Endprodukt haben wird?

Sehen nicht den Mehrwert, ausser dass ich nicht mehr easy an meine .java und .class Dateien rankomme.

18

Ich glaube, dass ich dich recht schnell überzeugen dir recht schnell klar machen könnte, was für ein an Magie grenzendes Werkzeug Eclipse ist. Vieles davon wird vielleicht nicht sooo relevant sein, wenn man alles in eine Riesenklasse mit einer 1000zeiligen main-Methode klatscht, aber … auch da ist es schon praktisch.

Zum Kernthema:

Tatsächlich war einer der Hauptgründe, warum ich nach der Ausgabe des Testprogramms gefragt habe, dass ich mir nicht sicher war, was dort auf was skaliert wird (also welche Methode nun die „echten“ oder „skalierten“ Koordinaten liefert oder erwartet).

Wenn man also mit getPointerInfo Koordinaten bekommt - sind das dann „virtuelle“, die bis x=1920 gehen, oder sind das „echte“, die nur bis 1536 gehen? Und wenn der Robot ein mouseMove machen soll, bekommt er dann die „echten“ oder die „virtuellen“?

Wenn man das weiß, kann man die ja recht leicht hin- und her rechnen, wie man es braucht. (Die convertToDevice- oder convertToDevicePoint-Methoden aus dem Schnipsel - ggf. muss man die transformation da invertieren, das ist halt die offene Frage…)

19

Wobei ich die bis x=1920 ja wohl als die echten bezeichnen würde, dennn das ist die gewählte Bildschirmauflösung.
Die Anderen kommen erst durch die Skalierung zustande.