Erst die Grafik verkleinern, dann den QR-Code einsetzen

Wir begannen mit 12 erfundenen Kampagnen-URLs. Vier Ziele standen für einen Workshop, das Buch eines Creators, ein Produkt und einen Fotografiekurs. Zu jedem gab es eine kurze Variante, eine Variante mit Kampagnenparametern und eine längere Variante mit zusätzlichen Parametern. Innerhalb jedes Vergleichs zwischen den Abläufen blieb die vollständige URL unverändert.

Jede URL wurde mit zwei Fehlerkorrekturstufen codiert und in zwei Formaten gespeichert. So entstanden je Exportablauf und Grafikgröße 48 Dateien. Das sind verschiedene Bedingungen für dieselben 12 URLs, keine 48 Kunden, Kampagnen oder unabhängigen Versuche. Beide Software-Decoder konnten alle 24 großen Ausgangsbilder lesen, bevor der Exportvergleich begann.^[1]

Am deutlichsten war der Unterschied bei 540 × 540 Pixeln. Nach dem Verkleinern der fertigen Grafik lasen beide Decoder die exakte URL aus 16 von 48 Dateien aus. Wurde zuerst der Hintergrund verkleinert und der QR-Code danach in Endgröße eingesetzt, gelang das bei allen 48. Die Verbesserung zeigte sich bei beiden Fehlerkorrekturstufen sowie in PNG und JPEG.

Für den QR-Code war in jedem Paar derselbe Bereich reserviert: ein Quadrat von 90 × 90 Pixeln. Der zweite Ablauf passte den Code mit ganzen Pixeln für seine kleinen Quadrate in diesen Bereich ein. Weder der Link noch die Kampagnenparameter wurden gekürzt, und auch das Ziel änderte sich nicht. Die Tabelle zeigt die Ergebnisse der vier Gruppen mit jeweils 12 Dateien.

Für ein Unternehmen, das Kreativarbeit beauftragt, verändert das die Anforderungen an die Lieferung. Eine Quelldatei, die sich korrekt öffnen lässt, und ein funktionierender QR-Code in der großen Vorlage sind sinnvolle Prüfungen. Die kleinere Grafik braucht trotzdem ihren eigenen Check. Die Freigabe sollte die tatsächlichen Ausgabeabmessungen und die konkrete Datei nennen, statt bei der Ausgangsdatei zu enden.

Ein QR-Code besteht aus einem Raster kleiner Quadrate, den sogenannten Modulen. Der Link und die Codiereinstellungen bestimmen dieses Raster. DENSO WAVE, der Entwickler des QR Code, erläutert, dass längere Daten und andere Fehlerkorrekturstufen größere Raster erfordern können. Ein Standard-QR-Code braucht außerdem auf jeder Seite einen freien Rand von vier Modulen, die sogenannte Ruhezone.^[2][3]

In die ausgelieferte Grafik müssen also das gesamte Raster und sein Rand passen. Im ersten Ablauf war der QR-Code bereits Teil eines Bildes mit 2.160 × 2.160 Pixeln, bevor das gesamte Bild verkleinert wurde. Die Neuberechnung der Pixel konnte Kanten vermischen oder das Raster zwischen die späteren Pixelgrenzen legen. Im zweiten Ablauf verkleinerten wir den Hintergrund und zeichneten das ursprüngliche QR-Raster anschließend direkt auf ganze Pixel.

Ein gemessenes Beispiel macht den Unterschied greifbar. Die längere Workshop-URL enthielt 199 Bytes. Mit Fehlerkorrekturstufe M entstand ein Raster von 57 × 57 Modulen. Einschließlich Ruhezone war die belegte Fläche 65 Module breit. Die Ausgangsgrafik wies jedem Modul fünf Pixel zu; damit war diese Fläche 325 Pixel breit.

Beim Verkleinern der Grafik auf 540 Pixel wurde diese Fläche auf 81,25 Pixel abgebildet, mit 1,25 Pixeln zwischen den Modulgrenzen. Keiner der beiden Decoder konnte die URL aus der entstandenen PNG-Datei auslesen. Wurde dasselbe Raster direkt in Endgröße gezeichnet, benötigte es ein Pixel pro Modul und eine kleinere Fläche von 65 Pixeln. Nun lasen beide Decoder die vollständige URL aus.

Hier werden zwei vollständige Exportabläufe verglichen. Belegte Größe, Position und Filterung änderten sich gemeinsam. Der Test isoliert deshalb keine einzelne Ursache. Er zeigt aber, warum „den QR-Code in der Vorlage größer machen“ als Produktionsanweisung nicht ausreicht: In diesem Beispiel war das kleinere fertige Symbol dasjenige, das die Decoder lesen konnten.

Lass die vorgesehene URL unverändert, während du den Export anpasst. Kampagnenparameter können Teil eines vereinbarten Messplans sein. Wer sie entfernt, verändert den ausgelieferten Link. Überlegt das Team später, eine verwaltete Weiterleitung oder eine kürzere Zieladresse zu nutzen, ist das eine eigene Entscheidung mit separaten Ziel- und Attributionsprüfungen. Unser Versuch hat diese Alternative nicht untersucht.

Der Vergleich aller Größen zeigt, wie weit das Hauptergebnis reicht. Bei 1.080, 720 und 540 Pixeln konnten beide Decoder jede Datei lesen, bei der der QR-Code zuletzt eingesetzt wurde. Beim Verkleinern der fertigen Grafik war das Muster anders: Beide Decoder waren bei 32, 37 beziehungsweise 16 von jeweils 48 Dateien erfolgreich.

Kleinere Grafiken schnitten dabei nicht durchgehend schlechter ab. Bei den Exporten mit 720 Pixeln gelangen mehr gemeinsame Leseerfolge als bei denen mit 1.080 Pixeln. Unterschiedliche Größenverhältnisse und die daraus berechneten Pixel können für einen Decoder andere Ergebnisse erzeugen. Eine allgemeingültige Mindestgröße für QR-Codes in Pixeln lässt sich daraus nicht ableiten.

Bei 360 Pixeln war der reservierte QR-Bereich nur noch 60 × 60 Pixel groß. Einige Raster einschließlich Ruhezone benötigten 65 oder 85 Module in der Breite. Selbst ein ganzes Pixel pro Modul passte nicht hinein. Diese 24 Fälle mit abschließendem Einsetzen kennzeichneten wir daher als nach dem festgelegten Verfahren nicht erstellbar, statt sie als Decoderfehler zu zählen.

Die Tabelle vergleicht bei 360 Pixeln deshalb nur die 24 verbleibenden Paare. Beide Decoder konnten sechs verkleinerte Grafiken und 18 Dateien mit abschließend eingesetztem Code lesen. Sechs der erstellbaren Dateien mit abschließendem Einsetzen bestanden den gemeinsamen Test weiterhin nicht. Das Verfahren verbesserte diese kleine Gruppe, machte aber nicht jeden kleinen Export lesbar.

Bei einer kompakten Kampagnengrafik ist deshalb als Nächstes zu entscheiden, wie viel Platz für Code und Rand reserviert wird. Kläre das, bevor jedes verfügbare Quadrat als gleichwertig gilt. Bereichsgröße, vollständige URL, Codierung und fertige Ausgabe gehören ins Briefing. Ein Modul von einem Pixel, das in diesem kontrollierten Test funktionierte, ist keine Größenempfehlung für Smartphonekameras oder Druckmaterial.

Fehlerkorrektur hilft einem QR-Decoder, codierte Daten auszulesen, wenn ein Teil der Information beschädigt ist. Eine höhere Stufe kann für denselben Inhalt aber auch ein größeres Raster erfordern. Unsere M- und H-Codierungen brachten innerhalb des festen Bereichs deshalb eine echte Abwägung mit sich. Die höhere Einstellung ergänzte nicht nur Schutz bei einem ansonsten identischen Bild.^[7]

Bei 540 Pixeln waren beide Decoder bei verkleinerten Grafiken mit M in fünf von 12 Fällen erfolgreich, mit H in drei von 12, jeweils in beiden Dateiformaten. In anderen gepaarten Vergleichen war H jedoch besser: in acht Vergleichen mit den ausführlichen URLs bei 1.080 Pixeln und in zwei PNG-Vergleichen mit Kampagnen-URLs bei 720 Pixeln. „Immer die niedrigere Stufe wählen“ würde die Ergebnisse falsch wiedergeben.

Auch bei den Dateiformaten gab es keine einfache Rangfolge. Bei 720 Pixeln und Stufe M lasen beide Decoder 10 PNG- und 12 JPEG-Exporte der verkleinerten Grafik. Das macht JPEG nicht grundsätzlich zur sichereren Wahl. Es zeigt, warum ein Ergebnis für ein gespeichertes Format nicht automatisch auf ein anderes übertragen werden sollte.

Bei 54 der 360 erzeugten Dateien kamen die Decoder außerdem zu unterschiedlichen Ergebnissen. Bei 1.080 und 720 Pixeln konnte ZXing-C++ jede Datei lesen; quirc war für die niedrigeren gemeinsamen Gesamtergebnisse verantwortlich. Bei 540 Pixeln verbesserte sich jeder Decoder für sich, wenn der QR-Code zuletzt eingesetzt wurde. Der gemeinsame Erfolg ist unser Hauptergebnis; die Einzelresultate bleiben im Download verfügbar.

Für einen Creator, der Dateien an einen Kunden übergibt, heißt das: das vorgesehene Format benennen und den exakt ausgelieferten Link bestätigen. Der Softwaretest prüft die Bilddatei. Ein separater Check am vorgesehenen Smartphone, Bildschirm oder Druckstück prüft einen weiteren Teil der tatsächlichen Nutzung. Gemessen haben wir den ersten. Der zweite bleibt deshalb ein praktischer Schritt für das Team, das die Grafik einsetzt.

Kopiere die folgenden Felder in ein Kreativbriefing oder eine Übergabenotiz. Fülle sie für jede benötigte Ausgabegröße aus. Sie verbinden die Zielentscheidung des Unternehmens mit den Exporteinstellungen des Designers und der Person, die das fertige Material prüft. Die Downloadversion erfordert keine Anmeldung und lässt sich an deinen Ablauf anpassen.

Kampagne und Einsatz: [Benenne die Kampagne, die gewünschte Aktion nach dem QR-Code und den vorgesehenen Einsatzort dieser Grafik.] Linkverantwortung: [Benenne die Person, die das Ziel und seine Parameter freigeben darf.] Freigegebene vollständige URL: [Füge die exakte Zeichenfolge einschließlich aller benötigten Parameter und Prozentkodierungen ein.]

Fertige Grafik: [Breite × Höhe in Pixeln.] QR-Bereich: [Position und reservierte Breite × Höhe.] Ruhezone: [Bestätige einen freien Rand an allen vier Seiten.] Raster und Einpassung: [Halte die Modulanzahl und die verwendeten ganzen Pixel pro Modul fest, soweit Generator oder Exportprozess diese Angaben bereitstellen.]

Codierung und Export: [Benenne Generator, Fehlerkorrekturstufe und relevante Optionen.] Reihenfolge: [Gib an, ob der QR-Code in den endgültigen Abmessungen eingesetzt wurde.] Gespeichertes Format: [PNG oder JPEG mit den verwendeten Einstellungen.] Ausgelieferte Datei: [Halte den Dateinamen oder eine andere eindeutige Dateikennung fest.]

Dateiprüfung: [Benenne den oder die Decoder, die getestete Datei und das Ergebnis.] Ausgelesene URL: [Vergleiche die vollständig zurückgegebene Zeichenfolge mit der freigegebenen URL.] Offenes Ergebnis: [Halte einen Fehlschlag, einen Unterschied zwischen den Decodern oder ein Platzproblem fest und wer es klärt.] Ersetze ein ungeprüftes Ergebnis nicht durch ein Häkchen.

Nutzungsprüfung: [Benenne den vorgesehenen Bildschirm oder das Druckstück, das verwendete Smartphone oder andere Lesegerät, die zuständige Person und das Prüfdatum.] Zielprüfung: [Bestätige, dass der freigegebene Link zur vorgesehenen Seite führt und alle benötigten Kampagnenparameter auf dem geplanten Weg erhalten bleiben.] Diese Prüfungen gehen über unseren Bilddateivergleich hinaus.

Das Briefing sollte die Zuständigkeiten einfach machen. Die Kampagnenverantwortlichen geben den Link frei, der Designer erstellt die vereinbarten Ausgaben und die prüfende Person kontrolliert die tatsächlichen Dateien und den vorgesehenen Einsatz. Ändert danach jemand Link, Abmessungen oder Exporteinstellungen, aktualisiere das Briefing und prüfe die betroffene Ausgabe erneut.

Stell dir vor, ein Unternehmen beauftragt einen Creator mit der Bewerbung eines Herbstworkshops. Benötigt werden eine quadratische digitale Grafik für einen Bildschirm am Veranstaltungsort und eine kleinere Version für eine Kampagnennachricht. Das Unternehmen hat einen Link mit Angaben zu Quelle, Medium, Kampagne und Partner freigegeben. Dieses Produktionsszenario ist erfunden. Es verwendet eine unserer tatsächlich getesteten URLs, um die Übergabe konkret zu machen.

Die freigegebene URL ist das Workshopbeispiel mit 199 Bytes im Download. Der Kampagnenname lautet autumn_2026, das Medium qr und das Inhaltsfeld bezeichnet einen erfundenen Creator-Partner. Diese Angaben bleiben in beiden Ausgaben in der URL. Der Creator entfernt sie nicht, um die Informationsmenge im Code zu verringern.

Die beispielhafte Übergabenotiz nennt eine PNG-Datei mit 540 × 540 Pixeln und einen QR-Bereich mit 90 × 90 Pixeln ab x=378, y=378. Verwendet wird die gemessene M-Codierung: ein Raster mit 57 Modulen, eine Ruhezone von vier Modulen und ein ganzes Pixel pro Modul. Die fertige belegte Fläche misst 65 × 65 Pixel und liegt mittig im reservierten Bereich.

Der Designer verkleinert zuerst den Hintergrund und setzt danach dieses Raster ein. Die Notiz identifiziert die gespeicherte Datei und hält das gemessene Ergebnis fest: ZXing-C++ und quirc gaben beide die ursprüngliche URL exakt zurück. Sie nennt auch das Ergebnis der Alternative: Keiner konnte die URL aus der entsprechenden PNG-Datei lesen, die durch Verkleinern der fertigen Vorlage entstanden war. Beide Ergebnisse stammen aus unserem Versuch, nicht aus einer echten Kundenkampagne.

Das Unternehmen muss den tatsächlichen Bildschirm am Veranstaltungsort und den vorgesehenen Ablauf mit dem Smartphone weiterhin prüfen. Wird die kleinere Version durch einen anderen Dienst erneut komprimiert oder skaliert, prüft das Team auch die daraus entstehende Datei oder Anzeige. Diesen Dienst haben wir nicht untersucht. Der ursprüngliche Erfolg belegt nicht, was nach einer weiteren Umwandlung passiert.

Angenommen, das Briefing fordert später eine Grafik mit 360 Pixeln bei unverändertem relativen QR-Bereich. Der Bereich wird dann 60 Pixel breit, der Code benötigt einschließlich Rand aber 65 Module. Mit unserem Verfahren aus ganzen Pixeln lässt er sich nicht erstellen. Der Designer sollte den Platzkonflikt melden und mehr Raum oder eine andere Ausgabeform vereinbaren, statt einen erfolgreichen Export zu melden, der gar nicht möglich war.

Darin liegt der Nutzen einer konkreten Übergabe: Das Gespräch findet statt, solange sich die Grafik noch ändern lässt. Das Team kann seinen freigegebenen Link behalten, die betroffene Ausgabe erkennen und verhindern, dass eine erfolgreiche große Vorschau als Freigabe aller späteren Dateien gilt.

Vor dem Decodieren der Testexporte legten wir die 12 erfundenen URLs, das Bildlayout, die Größen und die Einstellungen fest. Die URLs nutzten example.com und wurden nie aufgerufen. Vier Zielfamilien hatten jeweils drei Datenprofile mit 39 bis 203 Bytes. Getestet wurden die Fehlerkorrekturstufen M und H, vier Breiten quadratischer Grafiken und zwei Speicherformate. Zusammen ergab das 384 geplante Dateibedingungen für die beiden Abläufe.^[1]

Segno 1.6.6 erzeugte Standard-QR-Codes im Byte-Modus; das automatische Anheben der Fehlerkorrekturstufe war deaktiviert. Jede Kombination aus URL und Korrekturstufe wurde einmal codiert. Beide Abläufe nutzten danach exakt dieselbe Matrix. Die quadratische Ausgangsgrafik hatte eine Seitenlänge von 2.160 Pixeln. Pillow 13.0.0 führte eine einzige LANCZOS-Skalierung aus; JPEG nutzte Qualität 85 bei deaktiviertem Chroma-Subsampling. Alle Codes waren schwarz auf weiß mit einer Ruhezone von vier Modulen.^[4]

Beide Decoder erhielten dasselbe vollständige gespeicherte Bild, umgewandelt in 8-Bit-Graustufen. Wir verwendeten ZXing-C++ 3.1.1 und einen festgelegten quirc-Build mit festen Einstellungen. Erfolg erforderte die ursprünglichen URL-Bytes ohne abweichendes erfolgreiches Ergebnis. Es gab keine zusätzlichen Ausschnitte, vergrößerten Wiederholungsbilder oder manuellen Rettungsversuche. Das Paket enthält Decodereinstellungen, Geometrie und Ergebnisse jeder Datei.^[5]

Alle 24 Ausgangsbilder bestanden beide Decoderprüfungen. Von den 384 geplanten Exporten wurden 360 erzeugt; 24 ließen sich mit abschließendem Einsetzen nicht erstellen. Übrig blieben 168 gepaarte Ablaufvergleiche. Wir bewahren jede Bedingung auf, auch Decoderunterschiede, erstellte, aber nicht lesbare Dateien und Vergleiche zugunsten beider Fehlerkorrekturstufen. Die Ergebnisse beschreiben diese künstlich erzeugten Dateien und Software-Builds, keine Scanerfolgsraten von Verbrauchern.

Bestehende Empfehlungen erklären bereits, wie wichtig Platz, Ruhezonen und Bildqualität sind. QRotto hat außerdem Ausgangsauflösungen nach Skalierung und Weichzeichnung verglichen. Unser Beitrag ist enger gefasst: ein festgelegter Vergleich des Zeitpunkts, zu dem der QR-Code beim Grafikexport eingesetzt wird, während vollständige URL und codierte Matrix innerhalb jedes Paars gleich bleiben. Die vollständigen Tabellen und Angaben zur Vorbereitung stehen unten bereit.^[6]