Jouer avec QR Code

Technologie de code barre à deux dimensions créée au milieu des années 90 pour des besoins logistiques dans les usines Toyota, le QR Code semble en train d'exploser et surgit de plus en plus souvent dans nos environnements.
Ces codes sont utilisés pour délivrer des informations, ou, surtout, renvoyer vers des informations via une URL ou un numéro de téléphone programmés dedans par ex.
A l'aide d'un téléphone portable équipé d'un appareil photo et d'un logiciel spécialisé (ex. Mobiletag) on peut donc en quelques secondes lire le code et obtenir ces informations. On voit donc ainsi surgir ces codes sur des affiches, renvoyant vers un site web, sur des arrêts de bus, renvoyant vers la page indiquant les horaires à l'arrêt, sur des produits alimentaires, renvoyant vers des recettes, etc.
 
Il existe également la technologie Flashcode, qui est un équivalent franco-français, présentant l'avantage de pouvoir stocker 5 à 6 fois plus de données mais l'inconvénient d'être, justement, purement français quand le QR Code a 15 ans d'existences et une utilisation mondiale.
 
QR Code est par ailleurs utilisable librement, de très nombreuses solutions existant pour générer ses propres codes gratuitement, de même que pour la lecture. Flashcode est, inversement, une solution propriétaire et cryptée mise en avant par les opérateurs français et dont la mise en oeuvre passe par l'ouverture du porte-monnaie...
 
Ceci étant posé, il me semble inutile de préciser va notre préférence.
 
Le QR Code peut donc embarquer des informations de type URL, carte de visite, numéro de téléphone, texte à afficher, etc. La quantité d'information maximale est de l'ordre de 3Ko en 8bits.
Visuellement ce sont des matrices de points allant de 25x25 points à 59x59 selon la quantité d'information encodée.

Le QR Code c'est très joli, mais on peut jouer avec ?

C'est la question que nous nous posions : quelles sont les limites à la personnalisation ? Comment conserver le fonctionnement technique, la lisibilité par les logiciels, tout en s'appropriant le graphisme pour en faire quelque chose de plus sympa. Comment proposer à nos clients cet outil sans forcément abandonner la créativité ? Voilà qui méritait quelques expérimentations.

 
Grossièrement, on voit que la lisibilité de la chose repose sur un aspect binaire, matérialisé par des blancs et des noirs. On suppose d'emblée que ce sont les écarts de contraste qui vont jouer, plus que le fait d'avoir vraiment du blanc et du noir.
 
Ce site pose quelques bases et expériences simples, ainsi que celui-ci.
 
Essayons de faire mieux avec un exemple un peu extrême dans le "n'importe  quoi" (je suis g33k, pas graphiste !) qui va nous permettre de vérifier si on peut s'amuser :
 
Il s'agit d'un authentique QR Code, et il fonctionne avec certains lecteurs même sous cette forme peu orthodoxe. 
MobileTag sur un iPhone 3GS arrive à le lire à condition qu'il ne soit pas trop petit, sur Android les différents tests menés n'ont pas fonctionné.Cette première expérience est donc partiellement réussie, donc : on peut jouer, mais il y a donc des limites !
 
Avec notre lecteur capricieux (et après avoir compris qu'il avait besoin de plus de recul) on est arrivés à cette version qu'il accepte aussi.
 
Certains aménagements ne sont peut-être plus nécessaires. Ce qui semble important c'est qu'il reconnaisse les trois carrés dans les angles et celui situé vers dans le quart inférieur droit. 
 
On voit donc qu'il n'est pas nécessaire de proposer une structure strictement noire et blanche et que ce sont bien les écarts de densité qui vont faire le jeu, ainsi que le ménagement des parties structurantes.
 
Sans avoir mis la main sur une documentation très explicite, le pari est qu'il doit y avoir une forme de transformation de l'image prise par la caméra en mode noir et blanc ou quelque chose de ce type. On aurait alors pour chaque point une transformation : tu es noir ou tu es blanc.
 
Si tel est le cas, les teintes un peu trop claires risqueraient de ne pas être interprétées.
Essayons quelque chose comme ça :
L'oeil du lecteur humain distingue bien le code et on voit qu'il s'agit du même que dans les images précédentes.
Cependant, l'oeil du lecteur silliconé de votre serviteur refuse obstinément, lui, de lire ce code.
Après plusieurs essais on arrive à une version fonctionnelle, plus dense, tout en conservant l'aspect graphique et les motifs :
 
Un petit tour du côté de notre logiciel de traitement d'image préféré nous permet de comprendre ce qui se passe.
Si l'on prend les deux versions de ce code affichées ci-dessus et qu'on les transforme en mode bitmap, on arrive donc à une image qui ne connaît pas la nuance : un point est noir ou blanc, pas gris. Voyons ce que donnent nos deux variantes ainsi tranchées :
 
Les choses sont un peu plus nettes ainsi. Et il faut noter que la réduction de ces images pour l'affichage dans cette page leur rend un peu de lisibilité. A taille réelle le code de gauche est encore plus brouillon. Pour parler chiffre, une mesure intéressante a été faite dans les images en niveaux de gris (étape intermédiaire avant le passage en bitmap) : on a à gauche un noir à 20% environ et à gauche à 60%.
 
Exemples similaires :
 
L'exemple de gauche fonctionne sur le 3GS avec Mobiletag mais nul par ailleurs dans nos tests.
Il semble clair que la différence de densité entre le fond et les zones du tag est trop faible. Les modules du tag sont dans "gris foncé" qui est en fait plus clair qu'un gris neutre. Au jeu du "noir et blanc" c'est un peu le brouillard.

Autre élément important qui ressort des différentes expérimentations : de l'air !

Un code peut être très lisible, si on ne le laisse pas respirer il meurt.

Une démonstration avec ce nouvel exemple. A gauche le code n'est pas reconnu. A droite c'est le même code et il est pourtant reconnu sans problème :
 
 
La différence est ténue mais essentielle : à droite il y a un espace blanc qui habille le code et fait en particulier la rupture avec la photo de la main. Ceci a été vérifié dans d'autres exemples.
 

Et le trait ?

On a donc vu que la densité est importante, plus que la couleur à proprement parler, la respiration aussi, parlons maintenant du trait. Faut-il forcément des blocs carrés ou peut-on là aussi avoir un peu de liberté ?
 
La réponse en image avec ces trois exemples, tous fonctionnels :
 
On va donc d'une version aux angles un peu arrondis à une version très "destroy", en passant par une approche "peinture". 

D'autres limites ?

Premier point : tout le monde n'a pas le même équipement. Ces tests ont été fait avec un iPhone 3GS qui possède un autofocus et permet une lecture de codes plus petits ou plus complexes.
 
Comme indiqué plus haut, la matrice peut aller de 25x25 à 59x59 points. On peut donc plus que doubler la densité de points. La lisibilité va donc pontentiellement être moindre. La taille d'affichage du code, que ce soit sur écran ou sur votre support du monde réel, va donc être très importante. Les recommandations sont souvent de ne pas descendre sous la taille de 4cm x 4cm.
On comprendra facilement que si l'on prend le dernier exemple plus haut pour l'appliquer à un code comme celui qui suit on va avoir un problème de lisibilité et que la taille de reproduction sera très certainement l'arbitre :
 
 

C'est un peu plat non ?

 
Quitte à jouer, ne peut on pas être un peu plus rock'n roll ? 
Il est tant d'assumer ma g33kitude et en profiter pour faire rire mes enfants, tout ça pour une cause noble : recherche et développement.
 
 
Les plus attentifs auront donc reconnu le code utilisé depuis le début de cet exemple. Oui, je me suis dévoué et j'ai brisé la barrière du numérique pour cette expérience 3D sans lunettes.
 
La technologie est donc là, et l'explosion du parc de téléphone mobiles évolués, de smartphones, en tête desquels on trouve les iPhone et la famille Android, rend possible l'utilisation de ces codes à une échelle moins confidentielle qu'une assemblée de g33ks.
 
Et en plus, on peut s'amuser !
 
Marc.