[devmad]

Bonjour

Je me lance dans l'essai d'implémenter une reconnaissance de plaque d'immatriculation basée uniquement sur un RPi2.

Quasi aucune doc en français sur google, j'ai juste trouvé une référence sur ce forum datant du mois de mai http://forum.raspfr.org/viewtopic.php?id=1314 et rien d'autre

J'ai compilé tout ce qu'il fallait hier (Leptonic, Tesseract, OpenCV, OpenALPR, plus de 6 heures de compil quand même !)

Ca fonctionne mais la reconnaissance prends environ 7 secondes par images.

Après test, je me rends compte que si je lance alpr avec un nom de fichier qui n'existe pas, il met 6 secondes avant de m'afficher un "file not found" et que si je lance alpr img1.jpg img2.jpg img3.jpg il fait l'analyse des 3 images en 9 secondes.

Comme si alpr prenait 6 secondes pour se charger et ne prenait que 1 seconde par image ?

En utilisant strace, il fait une pause de 5 secondes après un appel de mmap2 de 47Mo (temps cpu affiché de 25% et mémoire RSS maxi de 52Mo, occupée 424 sur 925Mo)

J'ai pas le courage de tout recompiler sur un PC pour faire un test comparatif voir si cela vient du RPi, est-ce quelqu'un à compilé et testé OpenALPR sur une archi PC ?

[jb1]

Bonsoir,
si tu as compilé, tu as donc le(s) source(s),

la commande strings sur alpr, rien d'anormal?
si tu es pugnace, dbg et disassemble,
je regarde tes observations
A+
JB1

[jb1]

avec google openalpr, plusieurs choix,
sur le site officiel
A+
JB1

on est bien d'accord tu es affrancit pour l'utilisation?

[devmad]

Bonsoir JB1

Pour l'instant j'ai ajouté des traces dans les sources pour essayer de localiser le problème, c'est bien dans le constructeur, dans les routines d'initialisations, une pause de 5 secondes avant de commencer l'analyse des images ?!

je vais continuer à tracer les sources pour essayer de localiser le problème.

Personne sur ce forum n'a déjà compiler openalpr sur un raspberry pi2 ?

[jb1]

Bonjour,
man gcc,
machine option

Code :

ARM Options -mapcs-frame  -mno-apcs-frame -mabi=name -mapcs-stack-check  -mno-apcs-stack-check -mapcs-float  -mno-apcs-float -mapcs-reentrant  -mno-apcs-reentrant -msched-prolog  -mno-sched-prolog
           -mlittle-endian  -mbig-endian  -mwords-little-endian -mfloat-abi=name -mfp16-format=name -mthumb-interwork  -mno-thumb-interwork -mcpu=name  -march=name  -mfpu=name -mstructure-size-boundary=n
           -mabort-on-noreturn -mlong-calls  -mno-long-calls -msingle-pic-base  -mno-single-pic-base -mpic-register=reg -mnop-fun-dllimport -mpoke-function-name -mthumb  -marm -mtpcs-frame  -mtpcs-leaf-frame
           -mcaller-super-interworking  -mcallee-super-interworking -mtp=name -mtls-dialect=dialect -mword-relocations -mfix-cortex-m3-ldrd -munaligned-access

ceci permet de compiler sur une machine plus rapide (en incluant le debug)

tu as quoi comme machine linux?
A+
JB1

[devmad]

La compilation initiale c'est du lourd, plus de 6 heures, mais maintenant, le cycle de modifier les sources pour tracer ce problème d'initialisation (de bibliothèques ?) n'est pas plus lourd que de faire de la cross-compilation sur mon PC et déploiement sur le RPi.

[jb1]

tu as bien un RPi 2B+ avec un GB de mémoire?
A+
JB1

[devmad]

le Pi2B quadcore ARMv7 (broadcom BCM2709) à 900Mhz et avec 1Go

[jb1]

bonsoir,
sauf si cela te gène, tu peux mettre en MP ton binaire?
A+
JB1

[devmad]

Le binaire alpr utilise 83 librairies, dont 20 sont générées par la compilation de openalpr (18 venant de opencv)

Et pas vu comment attacher un fichier par MP ?

[gambit]

Ah ben ça pouvait se porter sur RPI.

[devmad]

A part ce petit souci d'initialisation, que j'ai localisé mais pas résolu, ça marche sacrément bien !

Le RPi2 met un peu moins de 1 seconde pour reconnaitre la plaque, couplé avec l'option motion sur la caméra pour ne bosser que sur détection de mouvement;

[gambit]

J'avais pas fait gaffe à la section : >
Il serait convenable de demander à un admin de déplacer ce fil dans la section /logiciel

[gambit]

Ceci dit, tu peux également rapidement tester sur un pc en utilisant docker : le dockerfile est fournit sur le github du projet:

Code :

docker build -t openalpr https://github.com/openalpr/openalpr.git

Sur mon vénérable pc, cela prends 5mn. Et ça marche :

Code :

time docker run -it --rm -v $(pwd):/data:ro openalpr -c eu h786poj.jpg
libdc1394 error: Failed to initialize libdc1394
plate0: 10 results
    - H786P0J     confidence: 89.8356
    - H786POJ     confidence: 87.6114
    - HN786P0J     confidence: 85.2152
    - H2786P0J     confidence: 85.0755
    - H3786P0J     confidence: 84.8286
    - HS786P0J     confidence: 84.7763
    - H786PQJ     confidence: 84.7612
    - H786PDJ     confidence: 84.5669
    - HN786POJ     confidence: 82.9909
    - H2786POJ     confidence: 82.8513

real    0m1.601s
user    0m0.024s
sys    0m0.010s

Cool non?
Je précise que la libdc1394 concerne une interface de programmation de haut niveau pour appareil sur un port 1394. Donc on s'en fout ou presque. Faudrait juste changer pour libdc1394-22

[devmad]

Y'en a aussi une version toute prête dans les dépots standards de debian jessie

sudo apt-get install openalpr

C'est après avoir utilisé ces versions binaires pour amd64 que j'ai décidé de le compiler sur un Raspberry et que je tombe sur ce problème d'initialisation anormalement long

[gambit]

+1 pour la cavalière

Je proposais docker parce que ça évite de pourrir son système de tout un tas de paquets ou de fichiers pour juste tester un soft.