Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

Image Comparison for Dynamic and Multilingual screen

Offen
  • Stimmt etwas nicht?
#2,426 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 5 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
25/100
Issue-Typ
Feature
Klarheit
Muss geklärt werden
Aktivitätsstatus
Ruhig
Tech-Stack
java
Bereich
computer-vision, testing-qa

Rechercherichtung

Beginne mit der Überprüfung von SimilarityMatchingOptions und der verknüpften Dokumentation des Appium Images-Plugins zur Ähnlichkeitsberechnung und Vorkommenssuche. Vergleiche den angeforderten Textausschluss, den Schwellenwert, die Maskierung von Koordinaten oder Elementen sowie KI-basierte Alternativen und lege anschließend einen umsetzbaren Umfang und Tests fest, die das beabsichtigte Verhalten bei mehrsprachigem und dynamischem Text nachweisen.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Hi,
I am using Appium Images plugin to perform visual testing, I have found Similarity Calculation and Occurences Lookup to be particularly useful for my use case where I am comparing if a screen matches the baseline, and if a certain element screenshot is present as a subset of screen.
For multilingual apps, I have found one limitation is that it picks up the translation differences which results in reduced value of ComparisonResult. For example,
English Screen

Image

German Screen

Image

Similarity Result

Image

In case, where the baseline screenshot is the same language (English) then the similiarity score comes out to be 0.999995768070221 while when the baseline screenshot is in a different language (German) then the similarity is significantly low 0.8476240038871765 due to the different text on image.

To counter this difference, one approach would be to run tests against different locales in which baseline images stored for comparison correspond to the lanague of app under test. While this approach is helpful, it adds an overhead to run tests on multiple lanaguages and does not scale if no of supported languages is large.

This is also relevant for cases where the text is variable for example, name/address/price of an on-screen element can differ. While mocking the result to have always same values for image comparison can be done, this is not always the possibility and easier to achieve.

For such image comparison, I would like to have a feature that basically ignores any text on the screen when performing image similiarity. Would it be possible to have such an option in SimilarityMatchingOptions where this flag can be passed to either consider or ignore on-screen text together with a threshold value which decided if and how much on-screen text will be taken into account during image similarity check? Another idea is to pass element ID or screen coordinates which should be excluded from image comparison, maybe to mask/blackout them, this way we can manually pass elements which have dynamic text to be excluded for similiarity matching?

Or perhaps if this is not a possibility, would it be possible to achieve this visual testing without relying on external providers and only using Appium MCP with some sort of image comparison tooling either using Images plugin or via LLM native image models. There is a feature request I have also put up for https://github.com/appium/appium-mcp/issues/418. There is a tool available for finding elements using AI but not sure if it can be extnded to also use AI for image comparison.

If there is a rather more suitable approach that already exists, I would be also interested in trying it out. thanks

Vorherrschende Sprache
Java
Sterne
1.3k
Forks
755
Ø Merge
5 T. 14 Std.
Gemergte PRs (30 T.)
8

Entwicklungsumgebung

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus appium/java-client

Alle Issues in appium/java-client

Ähnliche Issues

Weitere Issues zu Java

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.