Réparer un code QR

Magazine
Marque
GNU/Linux Magazine
Numéro
198
|
Mois de parution
novembre 2016
|
Domaines


Résumé
Nous terminons cette première série sur la lecture des codes QR par la réparation automatique de sa zone de format et de sa zone de données.

Body

Cet article permet de lire un code QR abîmé ou décoré d’un petit logo en utilisant la correction d’erreur de Reed-Solomon. On corrigera aussi la zone de format.

Dans l’article précédent [1], nous avons codé une bibliothèque qui permet de manipuler le corps F256 et son anneau de polynômes : nous les utilisons pour corriger un code QR défectueux ou muni d’une imagette décorative. Le code est disponible sur GitHub [2].

Deux zones d’un code QR peuvent être corrigées :

- Les zones de format qui contiennent les informations minimales pour commencer à lire les données. Elles sont présentes en double : cinq bits de données et dix de correction.

- La zone centrale qui contient les données découpées en blocs : chacun a ses données brutes et sa correction.

1. Correction de la zone de format

J’ai utilisé les idées de Wikiversity [3] pour cette partie.

Voici le véritable code de la fonction qui vérifie la validité des zones de format et qui les corrige si possible.

01:   def verifformat(self):
02:     if self.form is None:
03:       self.formats()
04:     r0=bin2dec(self.form[0][5:])
05:     r1=bin2dec(self.form[1][5:])
06:     hamming={i:set() for i in range(16)}

On commence par transformer les deux zones de format en nombres, r0 et r1 lignes 4 et 5. Ce sont en fait des éléments de F256, c’est pourquoi on utilisera plus loin (lignes 9 et 10) le XOR bit à bit.

La table de hashage hamming contient, en fonction du nombre d’erreurs, les formats possibles. Il suffit ainsi de prendre le minimum des clés pour un format correspondant unique (et non vide) pour obtenir le format correct.

07:     for form in range(32):
08:       r=resteformat(form)
09:       reste0=r0^r
10:       reste1=r1^r
11:       c0=bin(reste0).count("1")
12:       c1=bin(reste1).count("1")
13:       hamming[c0].add(form)
14:       hamming[c1].add(form)

On teste alors tous les codes possibles, il n’y en a que 25=32, c’est peu donc la force brute est possible et même souhaitable (contrairement à la section suivante).

On calcule le reste de chaque format possible (une division euclidienne où la soustraction est un XOR binaire) et où le diviseur est le nombre 1335 soit 10100110111 en binaire. La fonction resteformat est dans qrcodestandard.py.

def resteformat(n):

  mod=16*1335 # 0x357

  n*=1024

  for i in range(5):

    if len(bin(n))>=len(bin(mod)):

      n^=mod

    mod//=2

  return n

On le compare aux formats présents et on ajoute sa distance de Hamming (le nombre de bits distincts donc le nombre de 1 dans le XOR des lignes 9 et 10). Les lignes 13 et 14 ajoutent si nécessaire le format aux formats qui ont la même distance dans hamming.

15:     m=min(h for h in hamming if hamming[h])
16:     if m:
17:       self.formatok=False
18:     else:
19:       self.formatok=True
20:     if len(hamming[m])>1:
21:       print("Erreur, conflit de formats.")
22:       exit(1)
23:     self.form[0]=[int(i) for i in bin(hamming[m].pop())[2:]]
24:     self.form[0]=[0]*(5-len(self.form[0]))+self.form[0]

Enfin, ligne 15, on cherche la distance de Hamming la plus petite et pour laquelle au moins un format existe. Si elle est nulle, il n’y a pas eu besoin de corriger. Si elle n’est pas nulle, on teste s’il y a plusieurs formats possibles. Si oui, on ne peut pas corriger, il y a ambiguïté. Sinon, on corrige et on remplace.

2. Correction de la zone de données

Nous allons lire puis corriger le code QR de la figure 9.

linux

Fig. 9 Le code QR à corriger.

Le principe est de transformer la totalité de chaque bloc du message (chaque bloc en clair plus sa correction concaténée) en un polynôme à coefficients dans F256,c’est pourquoi nous avons besoin des deux fonctions message2poly et poly2message qui font l’interface (dans qrcorps.py).

2.1. Interface

Pour corriger un code QR qui contient des erreurs, on a besoin de traduire une liste de bits en un polynôme et inversement.

199: def message2poly(message):
200:   poly=[]
201:   for i in range(len(message)//8):
202:     poly.append(F256(bin2dec(message[8*i:8*i+8])))
203:   return Polynome(tuple(poly))

Cette fonction transforme une liste de bits en un polynôme en convertissant chaque octet en un élément de F256, la liste des octets donne les coefficients du polynôme.

205: def poly2message(poly):
206:   mess=poly.coefficients
207:   liste=[]
208:   for c in mess:
209:     b=[int(i) for i in bin(c.val)[2:]]
210:     liste=liste+[0]*(8-len(b))+b
211:   return liste

Cette fonction est la réciproque de la précédente : elle transforme les coefficients d’un polynôme de notre classe en une liste de bits en faisant attention à ce que l’octet ait bien 8 bits.

2.2. Principe mathématique

Le principe est le même, en plus complexe, que la preuve par neuf. Par exemple, on doit transmettre un nombre n (par exemple n = 457859), on calcule le reste r de sa division euclidienne par 9 qui est 2. Donc le nombre n × 10 + 9 − r = 4578597 est divisible par 9. Il suffit de vérifier si le nombre transmis est un multiple de 9 pour savoir s’il y a un problème. Bien évidemment, un message trop altéré ne sera pas détectable, pas plus qu’on ne pourra corriger le message mais l’idée est la même. L’ISBN et le numéro de Sécurité Sociale utilisent ce genre de méthode [4].

Si on se donne un message m de n octets et l’erreur e de n octets aussi, le message reçu est r = m + e (l’addition n’est pas la concaténation mais l’addition vectorielle). Autrement dit, comme on est en caractéristique 2, e = r + m.  Le message m est fourni avec sa correction construite de manière à ce que si a est notre élément générateur du groupe des inversibles de F256,

formule1
m  est le dernier élément du message. Autrement dit si le message est altéré (mais pas trop), cette somme n’est plus nulle.

On utilise le principe de la transformée de Fourier discrète dans les corps finis pour déterminer les positions des erreurs puis leur valeur. Ce n’est pas exactement une transformée de Fourier parce qu’on ne calcule pas la somme sur la totalité des éléments de F256 mais sur une plus petite partie, ici du nombre d’octets correcteurs.

2.3. Le code

La fonction est dans qrcodestandard.py, je me suis appuyé sur le travail de B. Barras [5]. Il y a plusieurs manières de procéder mais la force brute n’est plus envisageable car si un bloc contient 55 octets soit 440 bits, il faut tester 2440 ≈ 2,839 × 10132 cas. J’ai choisi, vu le travail mené précédemment, d’utiliser une version modifiée de la division euclidienne :

01: def corrige(clair,redondant):
02:   toutpoly=message2poly(clair+redondant)
03:   syndrome=[toutpoly(F256(F256.exp(i))) for i in range(len(redondant)//8)]
04:   if set(syndrome)!={F256(0)}:
05:     syndpoly=Polynome(tuple(syndrome[::-1]))

Le polynôme toutpoly est donc notre polynôme de F256[X]. Ses nracines sont les puissances du générateur 2, de   au nombre d’octets moins 1 de la partie redondante, si le message n’est pas entaché d’erreurs. On calcule donc les n images par la fonction polynôme associée de ces puissances dans le syndrome.

Si toutes les valeurs du syndrome sont nulles, le code QR n’est pas endommagé. Remarquer que les éléments de ma classe sont hashables sinon on ne pourrait pas créer un ensemble qui en contient.

Si le code est endommagé ligne 04, on transforme le syndromeS = [S0 ,S1 , ..., Sn−1] en le polynôme syndpoly ligne 05 donc

formule2
, c’est-à-dire que le coefficient dominant est Sn−1 et le coefficient constant est S .

06:     r,v=Polynome.construction([1]+[0]*syndpoly.degre()),Polynome.construction([0])07:  rr,vv=syndpoly,Polynome.construction([1])
08:     while r.degre()>=len(syndpoly)//2:
09:       q=r//rr
10:       r,v,rr,vv=rr,vv,r-q*rr,v-q*vv

Appelons pk les positions des erreurs et v le polynôme de degré m tel que

formule3
.

L’équation fondamentale est v × syndpoly + vv × X= r, ce qui ressemble fort à une égalité de Bezout. Il faut cependant arrêter le calcul avant que le dernier reste ne soit nul et recoder l’algorithme.

11:     vder=v.der()
12:     racines=[i for i in range(255,255-len(toutpoly),-1) if v(F256(F256.exp(i)))==F256(0)]

On détermine la dérivée de v (qui nous servira pour déterminer les erreurs) puis ses racines bk, directement reliées aux positions des erreurs (ce sont les inverses,

formule4
).

13:     if 2*len(racines)>=len(syndrome):
14:       print("Il y a trop d’erreurs dans le bloc n°"+str(ii)+".",file=sys.stderr)
15:       exit(1)

S’il y a trop d’erreurs, on précise le bloc concerné et on sort.

16:     erreurs={i:r(F256(F256.exp(i)))/vder(F256(F256.exp(i)))/F256(F256.exp(i)) for i in racines}

On calcule les valeurs des erreurs pour chaque racine bkde v, c’est-à-dire

formule5
.

17:     for i in erreurs:
18:       toutpoly[255-i]+=erreurs[i]
19:     toutmessage=poly2message(toutpoly)
20:     return toutmessage[:len(clair)],toutmessage[len(clair):],len(racines)
21:   return clair,redondant,0

On corrige les erreurs du bloc courant et on retourne le bloc en clair corrigé, le bloc redondant corrigé et le nombre d’erreurs corrigées.

Si on n’a pas demandé de corriger, on retourne tout tel quel et   (aucune erreur corrigée).

> ./qrdecode.py -i linux.png -a1

Fichier : linux.png

Niveau de correction : Low

Masque :

█··█··

█··█··

█··█··

█··█··

█··█··

█··█··

Dimensions : 105×105

Version : 22

Il y a eu besoin de corriger 61 erreur(s) dans la zone de données.

Mode : Byte

Longueur du message : 949

Message :

Hello everybody out there using minix -

I'm doing a (free) operating system (just a hobby, won't be big and

...

Bon, je coupe, vous avez compris la teneur de la suite du message.

Conclusion

La lecture des codes QR est terminée. On aurait pu coder d’autres algorithmes de correction par curiosité.

Maintenant, il nous reste à créer nos propres codes QR...

Références

[1] PATROIS N., « Fabriquer un corps fini », GNU/Linux Magazine n°196, septembre 2016, p. 32 à 37.

[2] Le code et les exemples sont présents ici : https://github.com/GLMF/GLMF198

[3] Reed–Solomon codes for coders :https://en.wikiversity.org/wiki/Reed%E2%80%93Solomon_codes_for_coders.

[4] EVEILLEAU T., « Les clés de détection d'erreur »http://therese.eveilleau.pagesperso-orange.fr/pages/truc_mat/textes/cles.htm.

[5] BARRAS B., « Codes de Reed Solomon », 1999 :  http://infoscience.epfl.ch/record/198834/files/rs.pdf?version=1.


Sur le même sujet

Mise en œuvre d’autotools

Magazine
Marque
GNU/Linux Magazine
Numéro
234
|
Mois de parution
février 2020
|
Domaines
Résumé

Le vénérable autoconf reste très utilisé parmi les projets bien établis. Un minimum de compréhension de sa syntaxe et de son fonctionnement permet donc de contribuer efficacement à ceux-ci, voire de proposer un toilettage.

Un oscilloscope pour le traitement de signaux radiofréquences : gr-oscilloscope pour GNU Radio 3.7 et 3.8

Magazine
Marque
GNU/Linux Magazine
Numéro
234
|
Mois de parution
février 2020
|
Domaines
Résumé

Nous proposons d’utiliser un oscilloscope radiofréquence comme source de données GNU Radio pour les applications nécessitant une large bande passante, telles que les mesures de temps de vol. Cette exploration sera l’occasion de découvrir la nouvelle mouture de GNU Radio attendue depuis 6 ans, la version 3.8, avec son lot de nouveautés et d’incompatibilités.

C++ Moderne : C++20 et au-delà

Magazine
Marque
GNU/Linux Magazine
Numéro
234
|
Mois de parution
février 2020
|
Domaines
Résumé

Suite à la conférence de Cologne du mois de juillet 2019, le périmètre de la version C++20 a été figé, et cette version est la plus riche depuis C++11, elle introduit quelques nouveaux concepts significatifs.

C++ Moderne : C++17 (partie 2)

Magazine
Marque
GNU/Linux Magazine
Numéro
233
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Dans le précédent article sur C++ 17, nous avons abordé les évolutions du langage et les évolutions de la STL orientées sur les types de bases. Continuons aujourd'hui notre découverte de C++ 17 !

Utiliser un outil de génération de documentation avec Doxygen

Magazine
Marque
Linux Pratique
Numéro
117
|
Mois de parution
janvier 2020
|
Domaines
Résumé

Documenter du code est souvent une partie d'un projet qui peut paraître longue, fastidieuse, voire ennuyeuse pour certains. Néanmoins, cette étape est cruciale pour la compréhension et la maintenabilité du code. Depuis longtemps, des outils permettant de faciliter cette tâche existent. Cet article a pour but de présenter Doxygen, l'un de ces outils de génération de documentation, et les atouts qu'il peut apporter à ses utilisateurs.

Par le même auteur

Préparer un code QR

Magazine
Marque
GNU/Linux Magazine
Numéro
199
|
Mois de parution
décembre 2016
|
Domaines
Résumé
Les articles précédents [1-6] vous ont donné envie de créer vos propres codes QR ? Ce sera chose faite ici même, pour le moment on prépare les données binaires.

Dessiner un code QR

Magazine
Marque
GNU/Linux Magazine
Numéro
199
|
Mois de parution
décembre 2016
|
Domaines
Résumé
Et voilà le dernier article de cette longue série sur les codes QR. À son issue, nous saurons les dessiner.

Réparer un code QR

Magazine
Marque
GNU/Linux Magazine
Numéro
198
|
Mois de parution
novembre 2016
|
Domaines
Résumé
Nous terminons cette première série sur la lecture des codes QR par la réparation automatique de sa zone de format et de sa zone de données.

Fabriquer un corps fini

Magazine
Marque
GNU/Linux Magazine
Numéro
196
|
Mois de parution
septembre 2016
|
Domaines
Résumé
Pour corriger un code QR avec erreur ou rature, nous avons besoin de construire le corps fini F256 et son anneau de polynômes.