http://www.flickr.com/photos/qriouscode/5573326659/in/set-72157626254478081

Jack

Bien sûr que le QR code novela était visible en grand, et sûrement avec un autre éclairage que celui d’un écran. Dans ce cas précis, il faudrait publier une photo avec des contrastes retravaillés. Je pense que le défaut vient du coup de flash qui se reflète dans une partie du code. Qu’aucun décodeur ne s’en sorte est bien la preuve que la photo pourrait être retravaillée pour que l’on puisse flasher ce code du web aussi (et peut-être même sur la reproduction photographique IRL).

L’essentiel, dans tout ça, est de publier des benchmarks. Et comme je le disais dans un précédent commentaire, je compte en publier un autre avec d’autres décodeurs, dont i-nigma et qrafter. Notez cependant que, la plupart du temps, les décodeurs proposés sont ceux fondés sur flashcode. On peut supposer qu’ils sont très répandus aujourd’hui. Au tout début, c’était surtout quickmark, et ma (probablement vieille) version de quickmark lite a eu du mal à s’en sortir. S’il existe quelque part une étude donnant les stats d’installation et d’utilisation des décodeurs 2D, je suis preneur. Je ne l’ai pas encore trouvée. Je voudrais la faire, mais ça coûte pas mal d’argent à monter, si on veut faire cela sérieusement.

Jack

Merci,
Gilles

Benoit

This is very helpful feedback. I spend a lot of time testing my codes and artwork on several readers, so it was nice to hera see that the readers that I was weak on are ones I have not heard of or used.

There is an interesting question here I ask. 2 actually.

1. Should readers that function not as well, be upgraded?

2. What is the intention of the artist ?

and

3. If some of the better readers evolved to be better then then the standard, what new standard should we adapt. Since I cannot control what reader someone has, how much of it is my responsibility to work at the lowest common denominator vs. that person learning about standards and getting a better app.

Again, great article. Thank you for including some of my work in this piece.

Patrick Donnelly, QrArts

Oui, pour i-nigma, je l’ai, mais il ne doit pas être au même endroit que mes autres applis, et je l’ai oublié du coup. L’idée du test était surtout de montrer que ces tests sont nécessaires, et bien sûr normalement on en fait plus (mais sur moins de codes à la fois). Pascal, vos remarques sont toutes très justes.

10 secondes : c’est déjà beaucoup pour quelqu’un qui n’aurait pas l’habitude de patienter. C’est vrai que barcode scanner nécessite parfois un peu plus de temps (vu tout ce qu’il fait en arrière-plan). J’ai d’ailleurs laissé dans ma version du lecteur bookbeo la visualisation des points de recherche, qui montre qu’il est en train de se passer quelque chose.

Conditions de test : mon éclairage était celui d’une pièce normale. Ce n’était pas un éclairage extérieur, et effectivement pour le code collaboratif cela doit marcher en IRL. Le truc c’est que si cela ne marche pas à l’écran, ceux qui testent sur écran sont déçus. Il suffit souvent de retoucher les contrastes de la photo pour s’en sortir.

J’ai également fait des tests avec des logiciels en ligne, mais soit ils ne marchaient pas, soit ils ne décodaient pas. C’est à revoir. J’ai également des bibliothèques de décodage sur une machine linux, mais je ne les ai pas utilisés ici.

Tout à fait OK pour le commentaire de variabilité android. D’ailleurs, le code source de ZXing en fait mention.

Pour le btc-2, j’ai oublié d’expliquer le choix que j’ai fait : je scannais tous les codes et laissait le décodeur m’en présenter un. Normalement c’est ce que doit faire le décodeur en présence de plusieurs codes.

Je suis bien d’accord que certains codes pourraient mieux marcher avec une toute petite modification. Le btc-4 pourrait certainement avoir de meilleurs résultats avec une garde plus importante sur le côté droit, et un alignment pattern plus visible.

Ce benchmark (qui m’a juste pris une grosse heure pour les 400 tests environ effectués (182 combinaisons code/décodeur plus des tests de contrôle ; en moyenne chaque présentation de code a été faite 2 fois, au cas où, donc faut multiplier les actions par 2)), peut lui même être benchmarké ! Autrement dit, que d’autres fassent de même sur la même base de codes, cela pourrait être intéressant.

Cependant votre test me semble présenter quelques défauts :
- tel que présenté ici, il n’est pas reproductible.
Les conditions, par exemple support et éclairage, peuvent jouer sur la qualité de lecture.
- il existe une variabilité pour les android : liée au modèle du téléphone (les caractéristiques techniques des caméras) Le test avec un iphone 3g aurait donné, à mon avis, des résultats différents d’avec le 3gs
- il faudrait réaliser le même test plusieurs fois (plus de 20 chacun) pour voir s’il n’existe pas de variabilité.
- Le temps 10 secondes me pose problème. Les applications de lecture ont un temps de réaction différent, qui ne joue pas au final sur la capacité de lecture. Les 10 secondes seront parfois courtes pour BarcodeScanner par exemple. Ce lecteur est très complet (WIFI, EVENTS…), pas intrusif (pas de renvoi vers un serveur pour des fins « statistiques ») mais il est un peu lent. Pour lui, les 10 secondes c’est un peu court à mon avis.

Je ne pense pas qu’il existe de personnalisation idéale, qui satisfasse toutes les applications de lecture (avec toutes les combinaisons OS/caméra possibles).
Si l’on souhaite une parfaite lecture il faut peu (ou pas) de modification du QR code.

Lorsque je réalise des personnalisations, je teste (évidemment) avec plusieurs applications : BarcodeScanner (si le résultat est trop lent, j’essaie d’améliorer) Neoreader, Mobiletag (dont les versions donnent des résultats TRES différents), Quickmark et i-nigma.

i-nigma me semble d’ailleurs le grand absent de votre test. Cette application est très souvent très performante pour les QR codes design (et elle est souvent conseillée par les designers…) disponible pour iphone, android et de nombreux modèles…

Il faudrait certainement tester les QR codes avec un logiciel (des services le propose aussi) qui permet de connaître la perte de données engendrée par la personnalisation …

En conclusion je pense qu’il n’existe pas de test parfait (il faut essayer avec un maximum d’applications si possible avec plusieurs types de téléphones, dont un blackberry qui « coince » assez facilement – caméra ? ) car il est impossible de connaître les conditions de lecture par l’utilisateur final :
- quelles sont les caractéristiques de son téléphone ?
- quelle application va-t-il utiliser ?
- est-il patient ?
- conditions d’éclairages ?
- etc.

Après avoir pris un maximum de précautions reste au final le choix : prendre le risque que certains utilisateurs ne puissent scanner le QR code ou pas ?

Autre remarque sur votre choix de QR codes :
- le QR code collaboratif fonctionnait IRL , la photo doit jouer. (c’est d’ailleurs peut-être le cas pour d’autres la différence écran/papier pourrait avoir une influence)
- le btc-2 c’est lequel que vous scannez ??
- pour le boidron… un tout petit rien le fait marcher (avec BarcodeScanner) … le « quatrième carré » (comme vous l’expliquez… trop souvent martyrisé) Avec un rond légèrement plus grand cela fonctionne…

En tout cas, bravo pour la patience, j’ai toujours en tête le test des applications du point de vue du support des fonctionnalités… mais je n’ai pas encore trouvé le temps (et le courage…)

Pascal @eQRoeil