Un QR code se décode à 1,2:1. Ne concevez rien qui s'en approche

Personne ne publie le chiffre, et c'est le point de départ

Il n'existe aucun seuil de contraste publié pour la lecture de QR codes intégrée aux appareils photo de l'iPhone et d'Android. La détection de codes-barres d'Apple se trouve dans le framework Vision et celle d'Android dans les services Google Play, tous deux fermés, tous deux non documentés sur ce point, et aucun n'a jamais énoncé de minimum. Tout article qui en nomme un - 3:1, 4:1, 40 % - cite soit une consigne de design écrite pour autre chose, soit rien du tout.

Cela vaut la peine d'être dit franchement plutôt que contourné, parce que la forme de la réponse honnête en découle. Trois choses peuvent être établies sans posséder de laboratoire : ce que fait un décodeur open source, parce que son code source est publié ; ce que mesure la norme de qualité d'impression, parce que c'est une norme publiée ; et ce que fait un code donné sur un téléphone donné, parce que cela demande vingt minutes et une imprimante. Tout le reste sur ce sujet relève de l'impression de quelqu'un.

Si la question revient sans cesse, c'est que le contraste est la seule variable d'un QR code qu'un designer contrôle sans l'avoir voulu. La taille de module est une décision délibérée. La correction d'erreurs est une décision délibérée. La couleur, elle, est choisie pour une palette de marque trois ans avant que quiconque ne pense à un QR code, et le code en hérite. La question pratique n'est donc pas « quel est le minimum » mais « quelle marge cette palette me laisse-t-elle », et celle-là a une réponse.

Ce qu'un décodeur mesure réellement, c'est une différence locale

Un décodeur ne compare jamais votre couleur de premier plan avec votre couleur de fond. Il convertit l'image de l'appareil photo en un unique canal de gris, décide pour chaque petit voisinage de pixels où tombe la frontière entre le sombre et le clair dans ce voisinage, et lit les modules sur le résultat. La binarisation est l'étape où un décodeur transforme une photographie en gris en pixels purement noirs et blancs avant d'essayer de lire le moindre module. Tout ce qui touche à la tolérance au contraste se décide là.

ZXing est le décodeur qu'il vaut la peine de lire, parce que c'est le seul largement déployé dont le code source est public. Son binariseur hybride par défaut découpe l'image en blocs de 8 x 8 pixels, calcule le pixel le plus clair et le pixel le plus sombre de chaque bloc, et place le seuil de ce bloc à mi-chemin entre les deux. En dessous d'une dimension d'image de 40 pixels, il abandonne l'approche locale et seuille l'image entière d'un coup.

La constante intéressante, c'est la garde posée sur cette boucle. Si l'écart entre le pixel le plus clair et le pixel le plus sombre d'un bloc est de 24 ou moins, sur 255, ZXing n'en tire aucun seuil : il suppose que le bloc ne contient que des pixels clairs ou que des pixels sombres et emprunte une estimation à ses voisins. Vingt-quatre niveaux sous le blanc, c'est le gris #E7E7E7, soit un rapport de contraste d'environ 1,24:1. Sur une image numérique propre et avec une taille de module généreuse, c'est le plancher.

Deux conséquences en découlent, et toutes deux sont plus utiles que le chiffre lui-même. La première, c'est que le contraste se mesure localement, sur à peu près la surface de quelques modules, et non à l'échelle de la page - c'est pourquoi un dégradé lent derrière un code est bien moins dangereux qu'il n'en a l'air, et pourquoi une photographie derrière un code est fatale. Un dégradé conserve la différence locale intacte partout ; une photographie inverse, à mi-chemin du symbole, le côté de la frontière sur lequel tombe un module.

La seconde, c'est que le contraste et la taille sont le même problème habillé autrement. Les blocs font huit pixels d'appareil photo sur huit, et non huit modules sur huit : le nombre de modules qui tombent dans un bloc dépend donc entièrement de la taille à laquelle le symbole atterrit sur le capteur. Un code qui remplit le cadre obtient plusieurs blocs par module et un seuil calculé sur les bords de ce module même. Un code photographié de trop loin obtient un bloc à cheval sur plusieurs modules et un seuil moyenné sur l'ensemble, soit une différence effective plus faible à partir exactement du même visuel. Dimensionner un code pour sa distance de lecture fait donc partie de son budget de contraste, ce n'est pas un sujet distinct.

Le chiffre du fichier de design et le chiffre que reçoit l'appareil photo sont différents

Tout ce qui se trouve entre le fichier de design et le capteur d'image retranche du contraste, et les pertes se cumulent au lieu de s'annuler. C'est toute la raison pour laquelle les chiffres recommandés se situent six fois au-dessus du plancher du décodeur, et cela vaut la peine d'être détaillé plutôt que résumé, parce que la plupart des postes sont corrigeables et que les corrections coûtent peu.

• Le papier n'est pas blanc. Les papiers de bureau et d'offset non couchés réfléchissent environ 80 à 90 % de la lumière qui les frappe. Un rapport de 21:1 dans le fichier n'arrive pas à 21:1 ; il arrive à ce que le support permet, avant même qu'une goutte d'encre ne soit déposée.
• L'encre s'étale. Sur un support absorbant, les modules sombres débordent sur les cellules claires voisines, ce qui relève la valeur la plus sombre et abaisse la plus claire dans chaque bloc que mesure le décodeur. Le kraft, le papier journal et le papier thermique des tickets sont les pires.
• Le brillant et le pelliculage ajoutent de la lumière aux deux. La réflexion spéculaire dépose la même quantité de lumière blanche sur les modules sombres et sur les clairs, ce qui relève le niveau de noir et comprime le rapport - la même arithmétique que le terme de voile dans la formule de contraste. Un pelliculage mat coûte un peu de netteté et rachète plus de contraste qu'il n'en coûte.
• La lumière ambiante fait la même chose. Un code derrière une vitrine en plein jour a un voile de reflets par-dessus. Un code dans un restaurant sombre a en face de lui un appareil photo qui pousse le gain de son capteur, ce qui ajoute du bruit à la quantité même que mesure le binariseur.
• L'exposition automatique est réglée pour le cadre, pas pour le code. Un code sombre sur une petite étiquette claire dans une photo majoritairement sombre est exposé pour la partie sombre, et l'étiquette écrête vers le blanc en entraînant les modules avec elle.
• Le flou est le multiplicateur. L'erreur de mise au point et le mouvement de la main moyennent chaque pixel avec ses voisins, et c'est précisément cette moyenne qui réduit l'écart du plus clair au plus sombre dans un bloc de 8 x 8. Un faible contraste et un léger flou ne s'additionnent pas, ils se multiplient, et c'est pourquoi un code limite passe quand on cale le téléphone et échoue quand on ne le cale pas.

Les écrans ont leur propre version de la même liste, ce qui surprend ceux qui supposent qu'un afficheur est un environnement maîtrisé. Un téléphone à 20 % de luminosité en plein soleil, derrière un film de protection mat, affichant un code dans un navigateur qui lui a appliqué un filtre de mode sombre, ne délivre pas le rapport qu'annonce le fichier de design. Le rapport du fichier est le plafond de ce qui est atteignable, jamais la valeur qui arrive.

La réponse à « quel contraste faut-il aux téléphones » est donc que les téléphones en demandent très peu et que les chaînes de production en demandent beaucoup. La marge que vous budgétez n'est pas une marge face au décodeur. C'est une marge face aux huit points ci-dessus, dont aucun n'est visible sur l'écran où la décision se prend.

L'échelle de contraste : un test qui produit votre propre chiffre

Pour trouver le plancher de contraste d'un travail précis, imprimez le même code à huit niveaux de contraste décroissants sur le matériau réel et notez où il cesse de fonctionner. Cela prend une vingtaine de minutes, cela coûte une feuille de papier, et cela produit un chiffre valable pour votre imprimante, votre support et les téléphones de vos clients plutôt que pour ceux de quelqu'un d'autre.

Les huit barreaux ci-dessous sont des gris sur blanc, choisis pour que chacun tombe sur un rapport de contraste rond. Générez huit fois le même contenu, une fois par couleur de premier plan, gardez le fond blanc pur, gardez la forme et la taille de module identiques sur les huit, et disposez-les sur une seule feuille dans l'ordre indiqué.

1. Imprimez les huit barreaux à la taille finale sur le support final. Une feuille, les huit codes à la taille qu'aura le code réel, sur le matériau qu'utilise le travail réel. Une impression laser de bureau sur papier copieur n'est pas le test si le travail part sur du kraft, une étiquette de bouteille ou une carte de menu - l'étalement de l'encre varie selon le matériau et se retranche du même budget que la couleur.
2. Scannez chaque barreau avec deux téléphones, appareil photo natif uniquement. Un iOS et un Android, avec l'application appareil photo intégrée plutôt qu'une application de scan. Les applications de scan dédiées sont plus tolérantes que les natives et valideront des barreaux que vos clients ne pourront pas lire. Notez le premier barreau qui échoue sur l'un ou l'autre téléphone.
3. Recommencez sous la lumière où vivra le code. Emportez la même feuille sur le lieu réel - la table du restaurant, le rayon du magasin, le panneau extérieur au crépuscule. L'éclairage déplace le point de défaillance de plus de barreaux que n'importe quelle autre variable, et c'est l'étape que l'on saute.
4. Recommencez à la distance réelle et sous un angle réel. Scannez depuis l'endroit où une personne se tient réellement, puis une fois à environ 30 degrés de la perpendiculaire. La distance réduit le nombre de pixels par module, ce qui rétrécit la différence que voit chaque bloc ; l'angle coûte un peu plus de la même chose.
5. Recommencez sans caler le téléphone. Tenez-le comme on le fait sans y penser, d'une seule main, en mouvement. Le flou réduit l'écart du plus clair au plus sombre dans chaque bloc : cette série échouera donc généralement un barreau plus tôt que la série soignée. Le chiffre négligent est le vrai chiffre.
6. Concevez deux barreaux au-dessus de la première défaillance. Prenez le pire résultat de toutes les conditions et remontez de deux barreaux sur l'échelle. Deux barreaux, c'est la marge de travail pour les variables que le test n'a pas pu inclure - un autre téléphone, une journée plus froide, une tête d'impression usée, un pelliculage que l'échantillon n'avait pas.

Un barreau mérite une note. La ligne #000000 est un témoin plutôt qu'un test : si le noir sur blanc échoue sur cette feuille, le problème est la taille, la mise au point, les reflets ou la zone de silence, et rien de plus bas sur l'échelle ne vous apprendra quoi que ce soit tant que ce n'est pas réglé.

La couleur n'est pas le contraste, et les deux mesures divergent

Le rapport de contraste d'une couleur prédit mal la façon dont cette couleur se comporte devant un appareil photo, parce que les deux chiffres sont construits différemment. Un rapport de contraste est un chiffre unique qui compare la luminance relative de deux couleurs, allant de 1:1 pour deux couleurs identiques à 21:1 pour du noir sur du blanc. Il pondère le vert à 71 % de la luminosité perçue, applique une courbe de gamma et ajoute un petit terme de voile qui pénalise délibérément les paires sombres. Le canal de gris d'un appareil photo pondère le vert à 59 %, le rouge à 30 % et le bleu à 11 %, et n'ajoute rien.

Le bleu pur se détache, et c'est le résultat utile du tableau. À 8,6:1 et avec une différence de luminance de 226, il n'est devancé que par le presque-noir sur les deux mesures, ce qui fait du bleu profond la couleur saturée la plus sûre pour un QR code, et de loin. Les rouges profonds et les prunes sombres viennent ensuite. Toute couleur dont le rapport vient du fait qu'elle est sombre plutôt que saturée se comporte bien. Quelles palettes cela laisse utilisables, et où elles ont leur place, c'est le sujet des codes QR en couleur.

C'est sur le vert pur que les deux mesures divergent le plus, et c'est pourtant là qu'il faut faire confiance au rapport. Son rapport de 1,4:1 paraît catastrophique alors que sa différence de luminance de 105 égale les 104 de l'orange : l'appareil photo voit donc davantage dans un code vert que le rapport ne le laisse croire. Cela ne suffit toujours pas : 105 sur 255, c'est moins de la moitié de l'échelle avant même que le papier, la lumière et l'objectif ne prennent leur part, et les codes verts sont ceux qui fonctionnent immanquablement sur la maquette et échouent en rayon.

Le jaune, le cyan et l'ambre échouent sur les deux mesures, et aucune technique ne les sauve. Le jaune sur blanc donne à l'appareil photo une différence de 29 niveaux sur 255 - à peine au-dessus des 24 à partir desquels ZXing cesse purement et simplement de chercher un bord. Un code jaune n'est pas un code risqué, c'est un objet décoratif qui se scanne de temps en temps dans des conditions parfaites.

Quand une couleur de marque n'atteint pas la cible, la correction est toujours la même et toujours dans le même sens : assombrissez le code, n'éclaircissez pas le fond. Les fonds doivent rester proches du blanc pour que la différence de réflectance survive à l'impression, et une couleur de marque descendue de deux ou trois crans garde généralement son identité tout en doublant son rapport. Là où c'est inacceptable, mettez la couleur de marque dans le cadre, le libellé et l'appel à l'action autour du code, et laissez le code lui-même sombre - les QR codes aux couleurs d'une marque relèvent surtout de cela, et cela ne coûte aucun contraste.

Les modules clairs sur fond sombre sont un problème à part

Un QR code inversé - des modules clairs sur un fond sombre - peut avoir un rapport de contraste parfait et échouer malgré tout, parce que le rapport est symétrique et que le décodeur ne l'est pas. Le blanc sur noir se calcule au même 21:1 que le noir sur blanc, et aucun contrôle de contraste, où que ce soit, ne le signalera. Ce qui varie, c'est la volonté du logiciel à l'autre bout d'essayer l'image dans les deux sens.

Les applications appareil photo actuelles de l'iPhone et d'Android gèrent généralement les codes inversés, et cela n'a cessé de s'améliorer. C'est sur le matériel plus ancien que cela casse : les imageurs fixes, les scanners de caisse et les équipements d'entrepôt attendent fréquemment des données sombres sur un fond clair et n'ont aucune passe d'inversion, et ZXing lui-même n'inverse que si l'application appelante enveloppe l'image dans la source de luminance inversée qu'il fournit - une décision prise par celui qui a construit l'application, pas par le code.

La règle pratique, c'est que l'inversion est un pari sur le lecteur, pas une propriété du code. Pour une affiche, un écran ou une publication sociale lus par des téléphones, un code inversé est un choix de design raisonnable. Pour tout ce qu'un client pourrait scanner avec un équipement inconnu, ou tout ce qui est lu à une caisse, c'est un pile ou face pris pour des raisons esthétiques, et la version sûre - un code sombre dans un panneau clair, posé sur le fond sombre - coûte un rectangle.

Il y a une dernière asymétrie qui mérite d'être nommée, parce qu'elle est invisible à l'écran. Imprimer un code clair sur un fond sombre revient à déposer un large aplat sombre, et un aplat s'étale plus qu'une couverture éparse. Ce sont les modules clairs qui rétrécissent, et ce sont eux que le décodeur lit comme la moitié claire de la paire. Un code inversé perd donc plus de contraste à l'impression que le même code dans le bon sens.

Ce que la norme d'impression mesure à la place d'un rapport

Le monde du QR code a sa propre mesure de contraste, et ce n'est pas un rapport. Le contraste de symbole est la mesure de qualité d'impression que la norme ISO/IEC 15415 définit comme la différence de réflectance entre le point le plus clair et le point le plus sombre d'un symbole. Il s'exprime en points de pourcentage et se note de A jusqu'à F. Un vérificateur le rapporte aux côtés de la modulation, des dégâts aux motifs fixes, de la non-uniformité de la grille et de la correction d'erreurs inutilisée, et la note globale du symbole est la pire de toutes.

La distinction compte parce qu'une différence de réflectance et un rapport de contraste ne sont pas deux versions interchangeables de la même chose. La réflectance, c'est de la lumière linéaire ; un rapport de contraste y ajoute une courbe de gamma et un terme de voile. Faites le calcul et l'écart est grand : une différence de réflectance de 40 %, le niveau couramment exigé par les cahiers des charges du commerce de détail, correspond, face à un blanc idéal, à un rapport de contraste d'environ 1,6:1, et une différence de 70 % à environ 3:1. Une paire de couleurs qu'un vérificateur d'accessibilité web rejette catégoriquement peut faire un code-barres parfaitement conforme.

Ce n'est pas un permis de concevoir à 3:1. C'est une explication de la raison pour laquelle les deux industries divergent : un vérificateur mesure un échantillon imprimé sous une lumière contrôlée, à distance fixe, avec le symbole qui remplit l'ouverture, tandis que le rapport d'un designer doit survivre à un téléphone sorti d'une poche. La norme mesure l'objet, et le rapport sert d'approximation pour toute la chaîne.

Le piège logé dans la norme, c'est la lumière qu'elle utilise. La vérification des codes-barres s'effectue sous un éclairage rouge à 660 nanomètres, la longueur d'onde qu'utilisaient les premiers scanners laser et que les vérificateurs modernes émulent encore ; la note d'un symbole se cite avec elle, comme dans 4.0/20/660. L'encre rouge réfléchit la lumière rouge : un code rouge sur du papier blanc n'a donc presque aucun contraste à 660 nm et se note comme illisible alors qu'il se scanne parfaitement sur n'importe quel téléphone. C'est la raison précise pour laquelle un QR code rouge peut passer tous les contrôles que fait un designer et échouer à une caisse ou sur un imageur d'entrepôt.

La règle qui en découle : tout ce qui est lu par un équipement fixe plutôt que par des clients devrait être noir sur blanc, à la taille que réclame la documentation de cet équipement, et vérifié plutôt qu'apprécié à l'œil. Tout ce qui est lu par des téléphones dispose de l'espace colorimétrique entier, moins les parties que le tableau ci-dessus élimine.

Les chiffres sur lesquels concevoir

Visez un rapport de contraste d'au moins 7:1 pour tout ce qui est imprimé, d'au moins 4:1 pour tout ce qui s'affiche à l'écran, et traitez 3:1 comme le point en dessous duquel un code ne doit pas partir en production, quelle que soit son allure sur la maquette. Ce sont des cibles de design qui intègrent déjà les pertes des sections précédentes, pas des seuils que quelqu'un aurait mesurés sur un téléphone.

• Impression, conditions non maîtrisées - menus, emballages, signalétique, autocollants. 7:1 ou mieux. Le noir ou le presque-noir sur blanc donne 21:1 et ne coûte rien ; l'écart entre 21:1 et 7:1 est l'espace où une couleur de marque tient.
• Impression sur support absorbant ou ingrat - kraft, papier journal, tickets, tissu, surfaces gravées. Ne dépensez pas de contraste du tout. Du noir sur le fond le plus clair disponible, et mettez plutôt le budget dans la taille de module.
• Écrans - sites web, présentations, écrans d'application, vidéo. 4:1 ou mieux, étant entendu que la luminosité du spectateur et la lumière ambiante échappent à votre contrôle.
• Tout ce qui est lu par des scanners fixes, ou régi par une spécification. Noir sur blanc, vérifié. La couleur est ici un risque sans contrepartie, et le rouge est un risque avec un mode de défaillance bien précis.
• En dessous de 3:1. Ne le publiez pas. Ce n'est pas un code limite que certains téléphones arriveront à lire - c'est un code dont toute la marge est dépensée avant même que le papier ne soit choisi.

Un contrôle facile à oublier : les trois repères de coin comptent. Un scanner localise un QR code par ses motifs de détection avant de décoder quoi que ce soit : un code dont les modules sont sombres et dont les coins sont posés dans une couleur d'accent pâle a donc son contraste le plus faible exactement là où la défaillance est irrécupérable. Quel que soit l'outil que vous utilisez, évaluez séparément la couleur des coins face au fond et retenez le pire des deux chiffres comme contraste réel du code.

KoloQR, un générateur de QR codes gratuit avec des QR codes circulaires et de formes personnalisées, calcule cette paire automatiquement : la pastille à côté de l'aperçu indique le rapport de contraste de la couleur du motif et celui de la couleur des coins face au fond, affiche le pire des deux et valide à 4:1. Elle considère un fond transparent comme blanc, puisque c'est là qu'atterrit généralement un code transparent. Vous pouvez monter l'échelle dans le générateur en exportant le même contenu avec chacun des huit gris ci-dessus et en imprimant la feuille.

La limite honnête de tout ce qui précède : aucun de ces chiffres ne garantit un scan sur du matériel que nous n'avons pas testé, et nous n'avons délibérément publié aucun chiffre pour un téléphone nommé, parce que nous n'en avons mesuré aucun. L'échelle existe pour que vous puissiez le faire. Vingt minutes et une feuille de papier produisent un chiffre vrai pour votre travail, ce qui vaut plus que n'importe quel chiffre de cet article.

Quand le contraste n'est pas vraiment le problème

La plupart des QR codes que l'on accuse de manquer de contraste échouent pour l'une de quatre autres raisons, et augmenter le contraste n'y change rien. Passer d'abord cette liste en revue est plus rapide que de dérouler l'échelle, parce que trois des quatre se voient sans téléphone.

• Le code est trop petit pour la distance. En dessous d'environ 0,4 mm par module à l'impression, les appareils photo de téléphone peinent quelles que soient les couleurs. Mesurez un module avant d'ajuster quoi que ce soit d'autre.
• La zone de silence a été rognée. ISO/IEC 18004 impose une marge libre de quatre modules autour du symbole, et un designer qui récupère cet espace pour sa mise en page est l'une des causes les plus courantes d'un code qui photographie à merveille et ne se décode jamais.
• L'image a été enregistrée en JPEG quelque part dans la chaîne. La compression JPEG dépose de légers halos autour de chaque module, ce qui abaisse la différence locale à l'intérieur des blocs mêmes que mesure le binariseur. Cela ressemble à un problème de contraste et c'est un problème de format de fichier.
• Les reflets. Un pelliculage brillant ou un écran qui renvoie un plafonnier ne réduit en rien le contraste du fichier - il ajoute une tache lumineuse sur une partie du symbole, et les blocs sous cette tache perdent leur différence pendant que le reste du code va bien. Incliner le téléphone règle le problème, et c'est là qu'on le reconnaît.

La correction d'erreurs a elle aussi sa place dans cette liste, mais en négatif. Passer le niveau de M à H n'aide en rien un code peu contrasté, parce que la correction d'erreurs répare des modules que le décodeur a mal lus et qu'un faible contraste empêche le décodeur de lire le symbole tout court. L'arbitrage entre capacité de récupération et taille de module est une vraie décision, et ce n'est pas le levier pour ce problème-ci. Le levier pour ce problème, c'est un premier plan plus sombre, un fond plus clair ou un code plus grand.

La défaillance voisine qu'il vaut la peine de connaître, puisque la décoration et le contraste se paient sur le même budget : les formes de module décoratives encrent moins chaque cellule que les modules carrés, ce qui réduit la différence locale que mesure le binariseur exactement comme le fait un faible contraste. Ce que coûte réellement une forme de QR code personnalisée déroule ce calcul, et les deux effets se cumulent - un code habillé dans une couleur de marque pâle puise deux fois dans un seul budget.