V11 Final Proiect De Diploma Fleaca Valentin [613406]

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

PROIECT DE DIPLOMĂ

Conducător științifi c: Prof. dr. ing. Adrian FLOREA

Absolvent: [anonimizat]: Calculatoare

– Sibiu, 2017 –

2

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

IMPLEMENTAREA UNEI TEHNOLOGII DE
TRANSMISIE DIGITALĂ, CARE PERMITE
CONTROLUL DE LA DISTANȚĂ ȘI
GESTIONAREA CONȚINUT ULUI DIGITAL
VIZIBIL PE ECRANE OBIȘNUITE

Conducător științific : Prof. dr. ing. Adrian FLOREA

Absolvent: [anonimizat]: Calculatoare

3
Cuprins
Cuprins ………………………….. ………………………….. ………………………….. ………………………….. ……………….. 3
Capitolul 1. Introducere ………………………….. ………………………….. ………………………….. ……………………. 5
1.1 Scopul proiectului ………………………….. ………………………….. ………………………….. ………………. 5
1.2 Obiective ………………………….. ………………………….. ………………………….. ………………………….. . 6
1.3 Structura lucrării ………………………….. ………………………….. ………………………….. ………………… 8
Capitolul 2. Raspberry Pi ………………………….. ………………………….. ………………………….. …………………. 10
2.1 Prezentare generală ………………………….. ………………………….. ………………………….. …………… 10
2.1.1 Hardware ………………………….. ………………………….. ………………………….. ………………….. 10
2.1.2 Procesor ………………………….. ………………………….. ………………………….. ……………………. 11
2.1.3 Performanțe ………………………….. ………………………….. ………………………….. ………………. 11
2.1.4 Specificații ………………………….. ………………………….. ………………………….. ……………….. 13
2.2 Raspbian Jessie ………………………….. ………………………….. ………………………….. ………………… 15
2.2.1 Ce aduce nou versiunea de Jessie față de Wheezy ………………………….. …………………… 16
2.3 Python ………………………….. ………………………….. ………………………….. ………………………….. … 16
2.3.1 Comparația cu alte limbaje ………………………….. ………………………….. ……………………… 17
2.3.2 Librăria „NumPy” ………………………….. ………………………….. ………………………….. ……… 18
2.3.3 Librăriile „urllib” și „requests” ………………………….. ………………………….. ………………… 19
2.3.4 Librăria „json” ………………………….. ………………………….. ………………………….. …………… 20
2.4 Supervisor ………………………….. ………………………….. ………………………….. ……………………….. 21
2.5 OpenCV ………………………….. ………………………….. ………………………….. ………………………….. 22
Capitolul 3. Procesarea Imaginilor ………………………….. ………………………….. ………………………….. …….. 23
3.1 Imagine dig itală ………………………….. ………………………….. ………………………….. ……………….. 23
3.1.1 Spațiul RGB ………………………….. ………………………….. ………………………….. ……………… 23
3.2 Operații pe imagini ………………………….. ………………………….. ………………………….. …………… 24
3.2.1 Conv ersia unei imagini color într -o imagine greyscale ………………………….. ……………. 24
3.2.2 Netezire Gaussiană ………………………….. ………………………….. ………………………….. …….. 25
3.2.3 Segmentarea imaginii („Thresholding”) ………………………….. ………………………….. ……. 26
3.2.4 Dilatarea și eroziunea ………………………….. ………………………….. ………………………….. …. 27
3.2.5 Extragerea background -ului ………………………….. ………………………….. …………………….. 27
Capitolul 4. Algoritmi de detecție a obiectelor într -o imagine ………………………….. ……………………….. 30
4.1 Viola -Jones framework ………………………….. ………………………….. ………………………….. ……… 30
4.1.1 Selecția trăsăturilor de tip H aar ………………………….. ………………………….. ………………… 31
4.1.2 Imagine integrală ………………………….. ………………………….. ………………………….. ……….. 32
4.1.3 Algoritmul de învățare AdaBoost ………………………….. ………………………….. …………….. 33
4.1.4 Arhitectura cascadată ………………………….. ………………………….. ………………………….. …. 34
4.1.5 Implementarea în OpenCV a framework -ului Viola -Jones ………………………….. ……….. 37

4
4.2 Histograma paternurilor b inare locale ………………………….. ………………………….. ………………. 42
4.3 Histograma gradientelor orientate (HOG) ………………………….. ………………………….. ………… 44
4.3.1 Implementarea algoritmului ………………………….. ………………………….. …………………….. 44
4.3.2 Implementarea în OpenCV a descriptorului HOG ………………………….. …………………… 49
Capitolul 5. Captarea unei secvențe video ………………………….. ………………………….. ………………………. 52
5.1 Conectarea camerei la Raspberry Pi ………………………….. ………………………….. ………………… 52
5.1.1 Cameră video USB ………………………….. ………………………….. ………………………….. …….. 52
5.1.2 PiCamera ………………………….. ………………………….. ………………………….. ………………….. 52
5.2 Detecția mișcărilor ………………………….. ………………………….. ………………………….. ……………. 54
Capitolul 6. Aplicarea noțiunilor teore tice în dezvoltarea aplicației ………………………….. ………………… 55
6.1 Descrierea aplicației ………………………….. ………………………….. ………………………….. ………….. 55
6.1.1 Modulul 1: platforma de detecție și contorizare a persoanelor ………………………….. ….. 55
6.1.2 Modulul 2: Interfața web ………………………….. ………………………….. …………………………. 58
6.2 Use case -ul aplicației ………………………….. ………………………….. ………………………….. ………… 61
6.2.1 Descriere detaliată a use case -urilor ………………………….. ………………………….. ………….. 62
6.3 Structura aplicației ………………………….. ………………………….. ………………………….. ……………. 79
6.4 Diagrama UML ………………………….. ………………………….. ………………………….. ………………… 80
6.5 Schema bloc a algoritmului ………………………….. ………………………….. ………………………….. … 81
6.6 Fazele premergătoare aplicației finale ………………………….. ………………………….. ……………… 82
6.7 Probleme întâmpin ate și soluții propuse ………………………….. ………………………….. …………… 83
Capitolul 7. Rezultate și concluzii ………………………….. ………………………….. ………………………….. …….. 85
7.1 Testarea aplicației pe Raspberry Pi 3 Model B ………………………….. ………………………….. ….. 85
7.2 Testarea aplicației pe calculatorul personal ………………………….. ………………………….. ………. 88
7.3 Concluzii ………………………….. ………………………….. ………………………….. …………………………. 89
Anexa 1 ………………………….. ………………………….. ………………………….. ………………………….. …………….. 90
Manual de utilizare -Raspberry Pi 3 – ………………………….. ………………………….. ………………………….. …. 90
8.1 Compilare OpenCV 3 ………………………….. ………………………….. ………………………….. ……….. 90
8.2 Instalarea serviciului „supervisor” ………………………….. ………………………….. …………………… 92
Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ……….. 94

5
Capitolul 1 .
Introducere

„Computer science is an empirical discipline. […] Each new machine that is built is
an experiment. Actually constructing the machine poses a question to nature; and we listen
for the answer by observing the machine in operation and analyzing it by all analytical and
measurement means available. Each new program that is buil t is an experiment. It poses a
question to nature, and its behavior offers clues to an answer.”
Allen Newell (1975)
Computer Science as Empirical Inquiry: Symbols and Search . p. 114

1.1 Scopul proiectului
Campaniile publicitare pe panouri (LCD, afișe, vinilin) sunt scumpe atât ca și cost
material dar și ca timp . Conținutul de publicitate trebuie înlocuit în fiecare panou, la nivel local
si individual. De asemenea, nu există niciun fel de feedback sub orice formă, din partea
publicului țintă către agentul publicitar. Aceste problem e sunt întâmpinate de către majoritatea
supermarket -urilor, lanțurilor de magazine, hotelurilor și agențiilor de media.
Wall -i este o soluție flexibilă, digitală de difuzare, care permite să controleze și să
gestioneze conținutul digital in ecranele existente (televizoare, proiectoare, ecrane LCD, etc.)
la distanță, atenuând cheltuielile de investiții, de călătorie și de timp. Acesta permite redarea
de conținut multimedia pentru orice tip de afișare, inclusiv tablete și smartphone -uri.
Sistemul este compus dintr -o aplicație web (dezvoltată in PHP, HTML, CSS,
JAVASCRIPT), găzduit de un server Linux, unde este controlat și m anipulat conținutul digital
și de adaptoare plug -and-play (ba zate pe Raspberry Pi), ce permit comunicarea între server și
adaptoare.
Scopul acestui proiect este acela de a implementa un instrument de măsurare care să
permit ă transmiterea unui feedback corect (real) , de la publicul țintă către utilizatorii Wall -i, în
ideea de a evalua și de a îmbunătăți eficiența anunțurilor, prin intermediul unor metrici
importante. Proiectul se va axa pe algoritmul de numărare a persoanelor , găzduit de

6
Raspberry Pi. Algoritmul se va folosi de o cameră web atașată la Raspberry Pi și va
contoriza numărul de persoane ce trec prin fața televizoarelor, oferind metrici despre
publicul țintă .
Proiectul va include programarea unui Raspberry Pi pentru a avea o cameră
web/PiCamera ce va număra perso ane, precum și dezvoltarea unei aplicații web cu un panou
de vizualizare (dashboard) pentru valorile audienței.
Proiectul va include utilizarea diferitelor tipuri de domenii de cunoștințe , și anume:
 Programare in Python și PHP
 Folosirea bibliotecilor GUI de desenare a grafice lor
 Algoritmi de tip procesare de imagini ( computer vision ) pentru detecția fețelor
umane
 Arhitectură bazată pe Linux
O versiune pilot va fi stabilită într -un scenariu de test real, cum ar fi un supermarket
sau centru de cumpărături, în scopul de a valida platforma dezvoltată de numărare a
persoanelor.
1.2 Obiective
Proiectul e structurat pe mai multe faze de dezvoltare fiecare cu obiective și livrabile
proprii.
1. Etapa „Technical Planning” (planificare tehnică) urmărește următoarele obiective :
 Prezentarea generală a algoritmil or existenți de recunoaștere a feței și a oamenilor
realizați în Python precum și a bibliotecilor open -source. Identificarea celei mai
potrivite biblioteci pentru utilizare. Principalul obiectiv este de a identifica
bibliotecile ce sunt capabile să identif ice persoane in video -uri în timp real.
Recunoașterea fețelor este de asemenea importantă, dar nu necesară. În cazul in care
recunoașterea feței este posibilă, ar fi foarte interesant de recunoscut dacă oamenii
se uită direct la cameră.
 Prezentarea genera lă a librăriilor open -source de realizare a diagramelor , graficelor
și de analiză a datelor bazate pe limbajul Python sau PHP . Tabloul de bord va
necesita grafice de tip linie pentru serii de timp, diagrame plăcintă și coloană.

7
 Planificarea dezvoltării tehnice și a planului de lucru al proiectului , împreună cu
supraveghetorii.

2. Etapa „People Counting Platform” (dezvoltarea platformei de numărare a
persoanelor) , are obiective le:
 Elaborarea unui algoritm de detecție a fețelor și/sau a persoanelor, folosind , dacă
este posibil, librării open -source compatibile cu limbajul Python și o cameră web.
Algoritmul ar trebui să includă un mecanism de contorizare ce detectează
persoanele ce circulă în întreaga zonă de acțiune a camerei sau într-o anumită zonă
definită de utilizator. Algoritmul ar trebui să fie dezvoltat pentru a opera pe deplin
pe Raspberry Pi.
 Dezvoltarea unui serviciu de monitorizare pe Raspberry Pi care trimite date , în timp ,
către aplicația web de monitorizare. Datele ar trebui să fie optimizate in ceea ce
privește dimensiunea, în scopul de a salva lățimea de bandă (în scopuri de
comunicare 4G).
Ca și obiectiv de livrat , în urma acestei etape va rezulta – platforma de monitorizare
a persoanelor operabilă pe Raspberry Pi.

3. Etapa „Web Application Dashboard” (dezvoltarea interfeței web a tabloului de bord)
își propune următoarele obiective :
 Dezvoltarea unei aplicații web care prezintă următoarele metrici:
o Diagramă de tip serie cu numărul de persoane î n timp
o Diagramă de tip „plăcintă ” cu procentul de persoane detectate zilnic,
săptămânal și lunar
Metricile tabloului de bord trebuie să fie afișate în funcție de contextul selectat
(display -uri, timpul cum ar fi ziua/săptămâna/luna curentă) . Aplicația web client (front –
end) ar trebui să fie dezvoltată fo losind HTML, JAVASCRIPT și CSS.
 Dezvoltarea aplicați ei web server (back -end) va fi dezvoltată in framework -ul
Django (pentru Python), care primește și stochează datele cu privire la numărul de
persoane, de pe mai multe Raspberry Pi -uri.

8
În urma acestei e tape, va fi livrată o aplicație web cu metricile dorite (număr de
persoane, starea de spirit a acestora).

4. Etapa „Pilot” cu obiectivele:
 Stabilirea unui proiect pilot într -un scenariu de test, din lumea reală, dacă este
posibil, într -un supermarket (cum ar fi Mega Image, Kaufland sau Carrefour).
 Validarea acurateței algoritmului dezvoltat
Proiectul va fi dezvoltat pe baza următorului plan de lucru:

Fig 1.1 Plan de lucru [1]
1.3 Structura lucrării
In capitolul 2 e ste prezentat, sumar, mini calculatorul Raspberry Pi, atât la nivel
hardware (specificații, performanțe) cât și la nivel software – sistem de operare.
Capitolele 3 și 4 reprezintă un studiu bibliografic specific domeniilor Computer Vison
și Machine Learni ng. Astfel, capitolul 3 prezintă noțiuni legate de procesarea imaginilor ce au
fost necesare prelucrării și extragerii de informații. În timp ce capitolul 4 urmărește partea de
învățare automată (machine learning), în cadrul căruia su nt prezentați diverși algoritmi , ce
aparțin de procesarea imaginilor (computer vision), de detecție a feț elor umane prin găsirea
trăsăturilor de tip „ Haar” (Viola -Jones algoritm), de detecție a oamenilor prin algoritmul de tip
HOG ( histogram of oriented gradients ) sau prin simp la detecție a mișcării .
Capitolul 5 prezintă modul de lucru al librăriei OpenCV in cadrul limbajului Python,
cu secvențe video, respectiv cu prelucrarea imaginilor.

9
Aplicarea noțiunilor teoretice in vederea dezvoltării platformei de monitorizare a
oameni lor este descrisă in detaliu in capitolul 6.
Rezultatele obținute în urma testelor efectuate în cadrul proiectului precum și
interpretarea lor sunt prezentate in capitolul 7.
Anexat, se găsește ghidul de instalare împreună cu manualul de utilizare al apl icației.
Ultimul capitol ilustrează bibliografia utilizat ă in realizarea acestei lucrări.

10
Capitolul 2. Raspberry Pi
2.1 Prezentare general ă
Raspberry Pi este un calculator de tipul SBC (Single -Board Computer) de dimensiuni
reduse, aproximativ cât un card de credit, produs in Marea Britanie de către Raspberry Pi
Foundation cu scopul de a promova învățarea noțiunilor de bază din domeniul informaticii in
școli.
Există mai multe generații de Raspberry Pi pe piață. Prima generație ( Rasberry Pi 1
Model B) fiind p usă in vânzare in f ebruarie 2012. Această generație dispunea si de un model
mai simplu și mai ieftin: Model A . În 2014, Raspberry Pi Foundation pune în vânzare o nouă
placă cu un design îmbunătățit (Rasberry Pi 1 Model B+ respectiv Model A+). În noiembrie
2015 este pus in vânzare Rasberry Pi Zero de dimensiuni mai mici decâ t predecesoarea
generație datorită reducerii capacităților de input/output , ceea ce a scăzut prețul de bază la doar
5$. Raspberry Pi 2 , eliberat pe piață in februarie 2015, vine cu mai mu ltă capacitate RAM, î n
timp ce Raspberry Pi 3 Model B, eliberat in februarie 2016, vine î mpreu nă cu on -board WiFi,
Bluetooth ș i posibilitatea de USB Boot.
Toate modele sunt de tipul „system on chip” (SoC; circuite integrate ce înglobează toate
componentel e unui calculator) , ce in clud procesoare(CPU) compatibile ARM și procesoare
grafice on -chip (GPU de tipul VideoCore IV).
2.1.1 Hardware

Fig. 2.1 Diagrama bloc [2]
Diagrama din figura 1.1 prezinta arhitectura modelelor A, B, A+, B+. Cu precizarea că
modelele A, A+, Pi Zero nu prezintă componentele „Ethernet” și „USB hub”. Adaptorul
Ethernet este conectat intern de un port USB adițional. Pentru modelele A, A+, Pi Zero portul
USB este conectat direct de circuitul integrat (syste m on chip; SoC).

11
2.1.2 Procesor
Raspberry Pi 1 folosește un procesor echivalent cu cel a primei generații de telefoane
inteligente; 700 MHz ARM1176JZF -S, ce dispune de cache de L1 de 16KB și un cache L2 de
128 KB. Cache -ul de nivel 2 e in principal folosit de către GPU.
Raspberry Pi 2 folosește ARM Cortex -A7 900MHz 32 bit quad -core cu L2 cache
partajat de 256 KB.
Raspberry Pi 3 folosește ARM Cortex A53 1.2 GHz 64 -bit quad core cu 512 KB L2
cache partajat.

Fig 2 .2 Raspberry Pi 3 Model B [3]
2.1.3 Performanțe
Raspberry Pi 3 dotat cu un quad -core Cortex -A53 este descris ca fiind de 10 ori mai
rapid decâ t Raspberry Pi 1 [4]. Fiind puternic dependent de task threading, benchmark -urile
arată că RPi 3 est e cu aproximativ 80% mai rapid decât RPi 2 pe task -uri paralelizate.

12
THREAD -URI 1 2 3 4
PI ZERO 17.2 34.5 – –
PI2 7.5 7.6 7.7 7.9
PI3 4.2 4.4 4.4 4.5

Tabel 2.1 Benchmark sortare. Timpi de execuție (s) . [5]
Raspberry Pi 2 este descri s ca fiind de 4 -6 ori mai puternic decât prima generație. În
benchmark -urile paralelizate, RPi 2 poate să fie de până la 14 ori mai rapid decâ t un RPi 1
Model B+. [6]
Raspberry Pi 1 operând la 700 MHz ajung e la performanțe similare cu un Pentium II
de 300 MHz din 1997 -99.

13
2.1.4 Specificații Tip
Model A
Model B
Zero Generație
1
1+
1
1+
2
3
PCB 1.2 Data eliberării
Feb 2012
Noie m. 2014
Aprilie 2012
Iulie 2014
Feb 2015
Feb 2016
Noiem. 2015 Preț
25$
20$
35$
25$
35$
35$
5$ Arhitectură
ARMv6Z
(32 bit)
ARMv7A
(32 bit)
ARMv8A(64
/32bit)
ARMv6Z
(32 bit) CPU
700 MHz single -core ARM1176JZF -S
900 MHz 32 -bit quad -core ARM
Cortex -A7
1.2 GHz 64 -bit quad -core ARM Cortex –
A53
1 GHz single -core ARM1176JZF -S Tip
Model A
Model B
Zero

14

GPU
Broadcom VideoCore IV
@ 250 MHz
OpenGL ES 2.0
MPEG -2 și VC -1, 1080p
30Hz Memorie
(SDRAM)
256MB(partajată
cu GPU)
512MB(partajată
cu GPU)
1GB(partajă cu
GPU)
512MB(partajată
cu GPU) Porturi
USB 2.0
1 direct
din ch ip
2
4
1 Micro –
USB Video
input
15 pini
interfață
cameră
MIPI;
RPi
camera
sau RPi
NoIR
camera
Nu
prezintă Video
output
HDMI
1.3
Mini –
HDMI,
1080p60 Audio
input
I²S Audio
output
Analogic
via 3.5
mm jack;
digital
via
HDMI,
I²S
Mini –
HDMI,
stereo
audio
prin
PWM pe
GPIO Tip
Model A
Model B
Zero Generație
1
1+
1
1+
2
3
PCB 1.2

15

Generație
1
1+
1
1+
2
3
PCB 1.2 Capacitate de
stocare (on -board)
SD,MMC,SDIO
slot
MicroSDHC slot
SD,MMC,SDIO
slot
MicroSDHC slot
MicroSDHC slot,
USB BOOT Mode
MicroSDHC Rețea (on –
board)
Nu
prezintă
10/100
Mbit/s
Ethernet
USB
adapter pe
USB hub
10/100
Mbit/s
Ethernet,
802.11n
wireless,
Bluetooth
4.1 Nu
prezintă Putere
disipată
300mA
(1.5 W)
200mA
(1W)
700mA
(3.5W)
600mA
(3.0W)
800mA
(4.0W)
160mA
(0.8W) Dimensiuni
85.6 x 56.5
(mm)
65×56.5×10
(mm)
85.6×56.5
(mm)
85.6x 56.5×1
7 (mm)
65x30x5
(mm) Greutate
31g
23g
45g
9g
Tabel 2.2 Specificații [2]
Din motive de performanțe mai bune, aplicația va fi dezvoltată și testată pe un
Raspberry Pi 3 Model B (cel mai performant la momentul actual).
2.2 Raspbian Jessie
Principalul sistem de operare folosit de Raspberry Pi este Raspbian, o distribuție Linux
bazată pe Debian. Diferitele versiuni de Debian sunt numite după caractere din animația „Toy
Story”. Recentele versiuni de Raspian sunt bazate pe Debia n Wheezy (pinguinul din „Toy
Story 2”), însă Raspbian a fost recent up datat la o nouă versiune stabilă de Debian, numită
„Jessie”.

16
2.2.1 Ce ad uce nou versiunea de Jessie față de Wheezy
Primul lucru ce iese in evidență la pornirea sistemului Jessie este compo rtamentul de a
„boot”-a direct către interfața grafică a desktop -ului și nu către linia de comandă din Linux.
Aceasta a fost o decizie luată, de către dezvoltatorii sistemului, deoarece acesta este
comportamentul așteptat pentru toate c alculatoarele modern e; interfața pentru un calculator
personal începând cu anul 2015 este de tip „desktop GUI” (graphical user interface desktop –
ferestre și iconițe), nu doar text pe ecran. Este posibilă și setarea de a boot -a către linia de
comandă dacă se preferă acest lucr u, folosind aplicația de configurare a Raspberry Pi venită cu
sistemul de operare.
Aspectul meniurilor, checkbox -urilor, a butoanelor radio a fost modificat față de cel din
Wheezy, deoarece Jessie e bazat pe versiunea 3 a GTK+, in timp ce predecesorul său este bazat
pe versiunea 2. GTK+ ; cunoscut ca și „GIMP Toolkit” , GTK reprezintă un set de instrumente
de tipul „cross -platform” ce își au sco pul de a crea interfețe grafice cu utilizatorul. Cu acest set
de instrumente a fost realizat mediul LXDE al desktop -ului Rasp bian. „Lightweight Desktop
Environment” (LXDE) reprezintă un mediu desktop gratuit ce necesită foarte puține resurse
pentru a rula. Este scris in C și rulează pe sisteme Unix.
Pe bara de meniuri, în partea dreapta -sus, a apărut o nouă iconiță de „eject ”. Acesta este
un nou plug -in ce permite driverului USB să fie „scos” fără riscul de a pierde date. Se știe ca
este riscantă simpla scoatere a unui stick USB din dispozitiv, mai ales dacă au fost copiate date
pe stick . Daca în timp ce sistemul copia ză datele, in procese fundal (background), este scos
dispozitivul USB, datele vor fi corupte sau se vor pierde. Iconița de „eject” rezolvă această
problemă, prin înlăturarea timpului de așteptare al proceselor de scriere ce așteaptă să fie
finalizate.

2.3 Python
Python este un limbaj de programare de nivel înalt, int erpretat, orientat pe obiecte și cu
semantică dinamică (cunoscută și sub numele de semantica execuției). Semantica unui limbaj
descrie procesele pe care un calculator le urmărește când execută un program într -un anume
limbaj de programare. Semantica dinamică a unui limbaj de programare definește „când” și
„cum” variatele construcții a limbajului ar trebui să producă un anumit comportament al
programului. Structurile de date de tip high -level int egrate, combinate cu scrierea dinamică și
legarea dinamică, fac ca Python să fie foarte atrăgător pentru modelul Rapid Application
Development (RAD) și preferat când vine vorba de un limbaj de legătură („scripting
languange”) pentru conectarea unor compone nte deja existente.
Modelul RAD este bazat pe dezvoltări iterative de prototipuri fără a implica vreo
planificare. Modulele funcționale sunt dezvoltate în paralel ca și prototipuri ce vor fi ulterior
integrate. Acest lucru favorizează timpul de livrare al produsului final.
Python are o sintaxă simplă, ușor de învățat, ceea ce reduce costurile implicate de
mentenanța codului. Acesta suportă module și pachete, încurajând astfel programarea modulară
și reutilizarea codului .

17
Deseori programatorii se „îndrăgost esc” de Python datorită productivității ridicate ce o
oferă. Deoarece nu există pasul de compilare, ciclul de editare -testare -depanare este foarte
rapid. Depanarea programelor î n Python este ușoară: un bug sau un input greșit nu va cauza
niciodată un „segm entation fault”, în schimb, când interpretorul depistează o eroare, acesta va
arunca o excepție. Când programul nu prinde excepția, interpretorul va printa urma
programului („stack trace”). Un depanator („debugger”) permite inspectarea variabilelor,
evalua rea expresiilor arbitrare, setarea de „breakpoints” , rularea linie cu linie a programului.
Debuggerul e scris în Python în sine.

2.3.1 Comparația cu alte limbaje
Python a reușit să ajungă în top 3 programe ca și u tilizare conform cu HIPEAC 2017:

Fig 2.3 Lista celor mai utilizate limbaje în 2016. [7]
Python este adesea comparat cu alte limbaje interpretate precum Java, JavaS cript, Perl,
Tcl sau Smalltalk. Compararea cu C++, Common Lisp sau Scheme poate fi de asemenea
benefică. Urmează să fie evidențiate câteva diferențe intre cele mai populare limbaje.
 Java
Programele scrise în P ython sunt de așteptat să ruleze mai î ncet decât cele scrise
în Java, însă durează mult mai puțin ca timp de dezvoltare. Programele sc rise în
Python sunt de 3 -5 ori mai scurte decât programele echivalente scrise în Java.

18
Un programator în Python nu pierde timp cu declararea tipurilor variabilelor ,
iar listele și dicționarele polimorfice din Python, pentru care există un puternic
suport sintactic înglobat în limb aj, își fac loc în aproape toate programele
Python .
Deoarece nu se declară tipul variabilelor, la ru n time, se pierde mai mult timp.
De exemplu, pentru evaluarea expresiei „a+b”, întâi trebuie inspectate obiectele
a și b pentru a găsi tipul lor , neștiut î n timpul compilării. Apoi va fi invocată
operația de adunare apropiată, ce poate fi o metodă supra -definită de către
utilizator. Java, pe de altă parte, poate executa calcule eficiente pe întreg sau
flotant, dar necesită ca variabilele a și b să aibă tip. Java nu permite supra –
încărcarea operatorilor cu metode definite de utilizator.
Din aceste motive, Python e văzut mai mult ca un limbaj de legătură între
componente scrise în alte limbaje. De fapt, cele două limbaje fac o combinație
perfectă, Java pentru componente de bază, iar Python pentru legarea acestora .
 JavaS cript
Subsetul „bazat pe obiecte” al lui Python este în mare echivalent cu JavaScript.
Ca și JavaScript (diferit de Java), Python suportă un stil de programare ce
utilizează simple funcții și vari abile fără a fi nevoie de definiții de clase. Totuși,
pentru JavaScript, asta e tot ce poate. Pe când Python suportă scrierea de
programe mult mai mari și o mai bună reutilizare de cod prin stilul programării
orientate pe obiect, în care clasele și moșteni rea joacă un rol important.
 C++
Aproape toate cele spuse pentru Java se aplică și pentru C++. Pe când codul
scris în Python e de pana la 5 ori mai scurt decât echivalentul său în Java, de
cele mai multe ori e de 5 -10 ori mai scurt decât echivalentul codulu i scris in
C++. Se spune că ceea ce scrie un programator în Python, în două luni, doi
programatori C++ nu pot termina într -un an. Python „strălucește” în sudarea
componentelor scrise în C++.
 Common Lisp și Scheme
Aceste limbaje sunt apropiate de Python și semantică dinamică, dar atât de
diferite în sintaxă, încât se pune problema: este un avantaj sau dezavantaj lipsa
sintaxei pentru Lisp? Trebuie notat că Python are capabilități introspective
similare cu Lisp și programele scrise în Python pot construi și e xecuta fragmente
de co d din „din mers”.
2.3.2 Librăria „NumP y”
NumPy reprezintă pachetul fundamental pentru calculele științifice dezvoltate în
Python. Conține, pe lângă altele, următoarele:
 Un puternic N -dimensional vector de obiecte
 Funcții de algebră linia ră
 Transformări Fourier
 Capabilități de generare de numere aleatoare
 Ustensile pentru integrarea de cod Fortran/C/C++

19
Pe lângă utilizarea științifică evidentă, NumPy poate fi folosit și ca un container multi –
dimensional eficient pentru date generice. Tipu ri arbitrare de date pot fi definite. Acest fapt
face ca NumPy să fie integrat cu ușurință și rapid cu o varietate de baze de date.
NumPy este succesorul altor două biblioteci științifice Python mai vechi. Librăria
derivă din codul de bază al vechiul „Nume ric” și poate fi considerat un înlocuitor al acestuia.
Include de asemenea funcționalități introduse de „Numarray”.
În figurile următoare vor fi arătate câteva exemple de declarare și utilizare al vectorilor
de tip NumPy.

a) b)
Fig 2.3.2 a) și b) Exemple de folosire a vectorilor NumPy

2.3.3 Librăriile „url lib” și „requests”
Librăria „urllib” este un pachet alcătuit din următoarele module specializate pe lucrul
cu URL -uri:
 urllib.request pentru deschiderea și citirea URL -urilor .
 urllib.error ce c onține excepțiile aruncate de urllib.request
 urllib.parse pentru parsarea URL -urilor
 urllib.robotparser pentru parsarea de fișiere „robots.txt”
Fișierele „robots.txt” sau „robots exclusion protocol” reprezintă un standard folosit de
website -uri pentru comu nicarea cu „web crawlers” (sau „internet bots” – aplicații soft ce rulează
task-uri pe internet) sau cu alți roboți web.

20
Exemplu de preluare a titlurilor returnate de pagina Google la căutarea „funny cats” :

Fig 2.3.3 .a Urllib.parse exemplu
Librăria „R equests” este o librărie HTTP scrisă în Python, cu ajutorul cărei se poate
adăuga ușor conținut precum: antete HTTP, date pentru formula re, fișiere de tip „multipart”
sau parametri doar.
Mai jos avem un exemplu de trimitere a unei imagini .jpg alături de 2 variabile :
current_time (timpul curent al trimiterii) împreună cu adresa MAC a dispozitivului:

Fig 2.3.3.b Requests.post exemplu
În figura de mai sus se observă că închiderea conexiunii se realizează de două ori. Acest
lucru a fost necesar deoarece în cazul unei excepții apărute : pierderea conexiunii la internet,
acces nepermis la website, URL -ul nu a fost găsit etc. acea conexiune realizată de librărie ar fi
rămas deschisă și ar fi blocat î ntreaga metodă, codul ne ajungând la linia de închidere a
conex iunii. Închiderea conexiunii pe ramura „catch” asigură că următoarea dată când se ajunge
cu execuția la modulul de trimitere a datelor, obiectul `r` creat de biblioteca Requests în urma
apelului de tip POST cu „multipart data” (atât fișiere cât și valori) este recreat cu succes.
2.3.4 Librăria „json”
Un JSON (JavaScript Object Notation), specificat de RFC 7159 [8] este un format de
schimb de date ușor inspirat din sintaxa obiectelor din JavaScript (cu toate că nu e subset strict
al Ja vaScript -ului). Este folosit în principal pentru trimiterea datelor între un server și o
aplicație web, ca și o alternativă pentru formatul XML.
Principalele două părți ce alcă tuiesc un JSON sunt :

21
 Cheile : o valoare de tip „String” marcată între ghilimele
 Valori le : pot fi de mai multe tipuri (string, număr, expresie booleană, vector,
obiecte)
 Perechea Cheie/Valoare: urmărește un format specific, cele două fiind delimitate
prin ‘:’, iar perechile între ele fiind delimitate de ‘,’

Fig 2.3.4 .a Exemplu de JSON
Figura de mai sus pentru accesarea valorii “acesta este” se poate folosi următoarea
sintaxă:
Obiect[“cheie_parinte”][“cheie_copil_2 ”] [0]

Librăria „json” este un API ce favorizează lucrul cu obiecte de tipul JSON.

Fig 2.3.4.b Exemplu de utilizare a librăriei „json”
De asemenea, librăria oferă o metodă foarte simplă de convertire a datelor din formatul de
dicționar Python în obiect JSON .
.

Fig 2.3.4.c Exemplu de convertire din dic ționar în JSON
2.4 Supervisor
Supervisor este un sistem de tipul client -server ce permite utilizatorilor să controleze
un număr de procese pe sisteme de tip UNIX. Nu poate rula pe nicio versiune de Windows.
Supervisor este alcătuit din două componente:

22
 Supervisord – componenta de tip server. E responsabilă cu startarea proces elor
copil prin apeluri proprii, răspunde la comenzi din partea clienților , restartează
procesele întrerupte din motive de erori apărute în execuția lor, păstrând totodată
un jurnal al evenimentelor. Folosește un fișier de configurare
(/etc/supervisord.con f) în stilul fișierului „Windows -INI”
 Supervisorctl – componenta de tip client. Asigură o interfață în linie de comandă
pentru funcționalitățile oferite de supervisord. Din supervisorctl, un user se poate
conecta la diferitele procese din supervisord, prei a statusul subprocesului controlat,
poate opri și porni subprocesul. Comun icația între client -server se realizează fie
printr -un domain socket de tip UNIX fie prin internet (TCP) .
Mai multe detalii legate de configurarea și folosirea acestui serviciu pot f i găsite în
„Manualul de folosire” anexat lucrării.
2.5 OpenCV
OpenCV (Open Source Computer Vision Library) este o librărie „open source”
destinată programelor ce urmăresc viziunea calculatoarelor („computer vision”) și învățarea
automată („machine learning”). OpenCV a fost dezvoltată i nițial de compania Intel, prima
versiune alfa fiind deschisă publicului la „IEEE Conference on Computer Vision and Pattern
Recognition„ în anul 2000. A fost construită cu scopul de a aduce o interfață pentru aplicațiile
de tip „c omputer vision” și să accelereze utilizarea percepției mașinăriilor („machine
perception”) în produse comerciale.
Librăria are mai mult de 2500 de algoritmi optimizați, ce includ atât algoritmi clasici
cât și cei la nivel de state -of-the-art din domeniul c omputer vision și machine learning. Acești
algoritmi pot fi folosiți pentru:
 detecția și recunoașterea fețelor
 identificarea obiectelor
 clasificarea acțiunilor umane în secvențe video
 detecția mișcării
 extragerea de modele 3D ale obiectelor
 producerea de m odele 3D pe baza camerelor stereo
 combinarea imaginilor pentru a produce o imagine de o rezoluție mai mare a
întregii scene,
 găsirea imaginilor similare dintr -o bază de date cu imagini
 îndepărtarea „ochilor roși” din imagini făcute cu blițul.
 Urmărirea miș cărilor ochilor
 Recunoașterea de peisaje pentru a putea crea conexiuni cu realitatea
augmentată
OpenCV are o comunitate de peste 47 de mii de utilizatori, iar numărul total de
descărcări depășesc 14 milioane. Librăria este folosită de companii precum Googl e, Yahoo,
Microsoft, Intel, IBM, Sony, Honda sau Toyota . Ca și utilizare, la nivel global, OpenCV e
folosit de la detecția intrușilor în camere de supraveghere în Israel, monitorizarea
echipamentelor miniere în China, ajutarea roboților să navigheze și să r idice obiecte la Willow
Garage (compania de roboți ce a dat systemul de operare „Robot Operating System”), detecția

23
cazurilor de înec în piscinele din Europa, rularea de artă interactivă în Spania și New York,
inspectarea etichetelor de pe produse în fabri ci din întreaga lume până la detecția rapidă a
fețelor în Japonia.
Prezintă interfețe pentru C++, C, Python, Java și MATLAB. Suportă sistemele de
operare Windows, Linux, Android și MAC OS. OpenCV se înclină în mare măsură către
aplicații în timp real, iar în prezent, interfețe pentru CUDA și OpenGL sunt în curs de
dezvoltare. Librăria este scrisă nativ în C++ și are o interfață bazată pe matrițe („templates”)
ce funcționează ușor cu containere STL („Standard Template Library”).
De-a lungul întregii lucrări vor fi făcute referiri la modul de operare a diferiților
algoritmi de detecție folosiți pentru modulul întâi al aplicației în cadrul librăriei OpenCV.
Capitolul 3. Procesarea Imaginilor
3.1 Imagine digitală
O imagine digitală este o reprezentare a unei imagin i reale bidimensionale, ca o
mulțime finită de valori numerice, codificate după un anumit sistem.
Deși principiile optice care stau la baza unei camere simple de fotografiat sunt
cunoscute de mai demult, abia in 1825 un francez pe nume Joseph Nicephore a reușit să prima
fotografie alb -negru folosind un material fotosensibil bazat pe petrol, similar cu smoala și care
se întărea după expunerea prelungită la lumină, având un timp de expunere de ordinul zecilor
de ore.
În 1861, în timpul lecturii despre teorem a culorii la Royal Institution of Great Britain
[9], matematicianul și fizicianul James Clerk Maxwell a produs prima fotografie color,
imaginea unei panglici colorate, fotografiind obiectul de trei ori folosind filtre diferite de roșu,
verde și albastru, iar apoi combinând imaginile într -una singură. Din cauza acestei fotografii,
Maxwell e creditat ca fiind fondatorul teoriei culorilor aditive.

Fig. 3.1 Panglica fotografiată de Maxwell [10]
3.1.1 Spațiul RGB
Spațiul RGB poate fi văzut ca totalitea culorilor posibile ce pot rezulta din combinarea
celor trei culor i: roșu, verde și albastru. Un exemplu intuitiv ar fi cubul RGB prezentat mai jos.

24

Fig 3.1.1 Cubul RGB ideal
În care se poate observa că nivelul maxim de intensitate pe fiecare direcție reprezintă
imaginea primară. Iar suma intensităților maxime a celor trei culori formează culoarea albă.
Fiecare culoare e reprezentată pe 8 biți, formând un triplet de trei astfel de octeți. De
exemplu, alb = (255, 255, 255) ce poate fi codificat sub formă hexa ca și #FFFFFF.

3.2 Operații pe imagini
3.2.1 Conversia unei imagini color într -o imagine greyscale
Conversia unei imagini din spațiul RGB într -o imagine greyscale (alb -negru) se poate
matematic în trei feluri:
1. Metoda mediei aritmetice
Greyscale = (R + B + G ) / 3
Din cauza diferitelor lungimi de undă a celor trei colori, culorile au contribuții diferite
în formarea imaginii. Formula de mai sus consideră că fiecare dintre cele trei culori are o
contribuție de 33 % din total. În realitate acesta nu e cazul, următoarea metodă obține valori
mult mai bune.
2. Metoda mediei ponderate sau a luminozității
Greyscale = 0.299 * R + 0.587 * G + 0.114 * B
Culoarea roșie are cea mai mare lungime de undă, deci o contribuție de 30 %, pe când
culoarea verde cea care dă un efect calmant ochiului contribuie cu pana la 60%.
3. Metoda intensității luminoase
Greyscale = (max(R,G,B) + min(R,G,B)) / 2
Metoda aceasta face media între cea mai proeminentă culoare și cea mai puțin
proeminentă.

25
Librăria „OpenCV” folosește cea de -a doua metodă de convertire din spațiul RGB/BGR
către greyscale. Operația rezumându -se la un simplu apel de funcție „cvtColor”.

Fig 3.1.2 Convertire RGB în greyscale în OpenCV
Primul parametru fiind imaginea color ce va fi convertită, iar al 2 lea fiind constanta de
identificare din ce spațiu înspre care se face conversia. Funcția returnează imaginea convertită
în variabila grayImage.
3.2.2 Netezire Gaussiană
În procesarea imaginilor, o netezire Gaussiană („Gaussian smoothi ng”) este rezultatul
netezirii unei imagini folosind o funcție Gaussiană. Este larg răspândită în aplicațiile grafice
pentru a reduce zgomotul și a detaliilor din imagini. Matematic, aplicarea de netezire Gaussiană
este identică cu aplicarea unei convoluți i a imaginii cu o funcție Gaussiană.
Pentru fiecare pixel din imagine se aplică funcția lui Gauss (ce reprezintă și distribuția
normală în statistică).

Formula 3.2.2 Distribuția Gaussină în două dimensiuni
Unde x și y sunt coordonatele pixelului curent, σ este deviația standard. Această formulă
produce o suprafață a cărei contururi reprezintă cercuri concentrice cu distribuția Gaussiană
din centrul punctului. Valorile din distribuție sunt folosite pentru crearea unei matrici de
convoluție ce va fi aplica tă imaginii originale. Prin procesul de convoluție , fiecare pixel va
avea noua valoare setată la o medie ponderată a vecinilor săi din vecinătate.

Fig 3.2.2 Exemplu de netezire Gaussiană

26
În OpenCV se folosește metoda cv2.GaussianBlur(img, sigma, border Type) ce
returnează noua imagine:
 Img – imaginea inițială
 Sigma – tuplu pe direcția x și y reprezentând deviația standard
 borderType – metoda de extrapolare a pixelilor
3.2.3 Segmentarea imaginii („Thresholding”)
Cea mai simplă formă de segmentare este cea bin ară („Binary Thresholding”).
Algoritmul primește o imagine sursă, iar pentru fiecare pixel (x, y) se aplică următorul
algoritm:

Fig 3.2.3 .a Pseudocodul pentru Binary Thresholding
Unde sunt date pragul („threshold”) și valoarea maximă.

Fig. 3.2.3.b Bin arizarea imaginii folosind o valoare de prag=0 și valoarea maximă =
255
În OpenCV se va folosi metoda (ret,dest)= cv2.Threshold(src, threshold, maxValue,
mode):
 dest – imaginea rezultată

27
 src – imaginea sursă
 threshold – valoarea de prag
 maxValue – valoarea maximă
 mode – modul segmentării. Exp cv2.THRESH_BINARY.
3.2.4 Dilatarea și eroziunea
Ambele transformări morfologice sunt operații simple bazate pe forma imaginii. De
regulă sunt aplicate pe imagini binarizate.
Ideea de bază ce stă in spatele eroziunii este erod area limitelor („foreground” -ului)
obiectului. O fereastră glisantă numită „kernel” traversează imaginea, pixelul curent din
imaginea originală va fi considerat (fie el 1 sau 0) dacă toți pixelii din kernel sunt 1, altfel va
fi erodat (setat la 0) , fapt ce duce la reducerea dimensiunii regiunii albe. Este utilă pentru
reducerea zgomotului slab, dezlipirea a două obiecte conectate.
Dilatarea este procesul opus eroziunii. Un pixel va fi 1 daca cel puțin un pixel din kernel
este 1. Crescând astfel dimensiunea regiunii albe. De regulă, în cazurile de reducerea
zgomotului, eroziunea va fi urmată de dilatare. Eroziunea micșorează obiectul, dar
îndepărtează zgomotul. Dilatarea va reface dimensiunea obiectului.

Fig 3.2.4 Exemplu transformări morfologice
1)Imaginea originală 2)eroziune 3)dilatare
Cele două operații vor fi implementate în OpenCV astfel:
 cv2.erode (img, kernel, iterations)
 cv2.dilate(img, kernel, iterations)
O posibilă inițializare pentru kernel este:
kernel = np.ones((5,5), np.uint8)
Folosindu -ne de NumPy inițializăm o matrice de 5×5 plină de 1
3.2.5 Extragerea background -ului
Extragerea backgroundului este un pas important de preprocesare în multe aplicații de
procesare a imaginilor. De exemplu, pentru un numărător de vizitatori dintr -o instituție folosind
o cameră statică ce contorizează numărul de persoane ce intră sau iasă dintr -o cameră, sau
pentru o cameră pentru traficul rutier, e nevoie de extracția persoanei sau a vehiculului din
imagine. Practic, trebuie extras planul mișcător („f oreground -ul”) de cel static („background”).

28
Dacă avem o imagine a backgroundului singură, precum imaginea unei camere fără
vizitatori sau a unui drum fără mașini, acest lucru este ușor. Diferența dintre noua imagine și
cea veche (backgroundul) va reprezen ta foregroundul. Dar, în majoritatea cazurilor, nu avem
o astfel de imagine și prin urmare trebuie extras backgroundul din imaginea avută. Acest lucru
devine și mai complicat când există umbre ale vehiculului . Deoarece și umbra se mișcă, simpla
diferență a r marca -o ca și foreground.
Câțiva algoritmi au fost introduși pentru acest scop. OpenCV are implementați trei
astfel de algoritmi ce sunt foarte ușor de folosiți. Aceștia vor fi detaliați în subcapitolele ce
urmează.
3.2.5.1 BackgroundSubstractor MOG
Reprezintă un algoritm de segmentare a backgroundului/foregroundului bazat pe un
amestec Gaussian („Gaussian Mixture”) . A fost introdus în articolul „An improved adaptive
background mixture model for a real -time tracking with shadow detection” de către P.
KadewTraKuPon g și R.Bowden în 2001. [11]. Folosește o metodă de modelare a fiecărui pixel
din background cu un amestec de K distribuții Gaussiene ( K între 3 și 5). Ponderile amestecului
reprezintă proporțiile de timp în care acele culori stau în scenă. Culorile probabilistice ale
backgroundului sunt acelea care stau mai mult (sunt mai statice).
3.2.5.2 BackgroundSubstractor MOG2
Și acest algoritm este bazat pe un amestec Gaussian pentru segmentarea
backgroundului/foregroundului. Este bazat pe două ar ticole ale lui Z. Zivkovic, „Improved
adaptive Gaussian mixture model for background substraction” [12] în 2004 și ”Efficient
Adaptive Density Estimation per Image Pixel for the task of Background Substraction” [13] în
2006. O trăsătură importantă al acestui algoritm este acela că selectează numărul potrivit de
distribuții Gaussiene pentru fiecare pixel. În cazul anterior, se luau K astfel de distribuții.
Acesta asigură o mai bună adaptabilitate la v ariațiile scenei datorate schimbărilor de iluminare.
Spre deosebire de prima variantă, această variantă oferă și posibilitatea detecției de umbre
printr -un parametru implicit detecShadows = true al metodei.
3.2.5.3 BackgroundSubstractor GMG
Acest algoritm combină e stimarea statistică a backgroundului imaginii și segmentarea
Bayesiană per pixel. A fost introdus de Andrew B. Godbehere, Akihiro Matsukawa, Ken
Goldber în lucrarea lor „Visual Tracking of Human Visitors under Variable -Lightning
Conditions for a Responsive Audio Art Installation” [14] în 2012.
Folosește primele (120 default) de frame -uri pentru modelarea backgroundului.
Presupune un algoritm de segmentare probabilistică a foregroundului ce identifică posibilele
obiecte ale foregr oundului folosind inferența Bayesiană. Estimările sunt adaptive; noile
observații sunt cu pondere mai mare decât cele vechi pentru acomodarea iluminării variabile.
Câteva operații morfologice de filtrare precum deschiderea („opening” ce presupune dilatarea
unui set erodat) și închiderea („closing” ce presupune eroziune a dilatației setului respectiv)
sunt folosite pentru îndepărtarea zgomotului.

29
Toți trei algoritmii presupun instanțierea de obiecte specifice algoritmului dorit:
 cv2.createBackgroundSubstra ctorMOG()
 cv2.createBackgroundSubstractorMOG2()
 cv2.createBackgroundSubstractorGMG()
Urmați de apelul metodei apply ce returnează frame -ul conținând doar foregroundul.

Fig 3.2.5 Rezultate diferite obținute în funcție de diferiții algoritmi de segmentare
[15]

30
Capitolul 4. Algoritmi de detecție a obiectelor într-o
imagine
4.1 Viola -Jones framework
Problema ce trebuie rezolvată este detecția unei fețe umane într-o imagine. Un om
poate face asta natural, cu ușurință , însă un calculator are nevoie de instrucțiuni precise și
anumite constrângeri.
Framework -ul Viola -Jones pentru detecție de obiecte propus în anul 2001 de către Paul
Viola și Michael Jones, este primul de acest tip ce aduce rezultate foarte bune în cadrul detecției
de obiecte în timp real. Deși poate fi antrenat să detecteze o varietate de clase de obiecte,
principalul obiect iv a fost rezolvarea prob lemei detecției fețelor umane.
Față de alte sisteme de detecție a obiectelor, Viola -Jones se distinge cel mai clar pr in
rapiditatea cu care fețele umane pot fi detectate. Operând pe imagini de 384 x 288 pixeli, fețele
puteau fi detectate pe un calculator obișnuit (la acea vreme, 700MHz Pentium III [16]) la 15
cadre pe secundă. În alte sisteme (framework -uri) de detecție de fețe, informație adițională
precum diferențele între imagini în secvențe video sau culoarea pixelilor din imagini color au
fost folosite pentru a atinge o rată mare proc esare a cadrelor pe secundă. Sistemul Viola -Jones
ating e această performanță, fără informații adiționale despre imagine, folosind doar
reprezentarea ei în alb -negru (greyscale).
Sunt trei mari contribuții pe care framework -ul le aduce în domeniul detecției fețelor .
Prima contribuție este o nouă reprezentare a imaginii, numită imagine integrală ce permite
evaluarea trăsăturilor de tip Haar foarte rapidă. Aceste trăsături de tip Haar („Haar -like
features”) sunt trăsături ale imaginilor digitale folosite în recunoașterea de obiecte. Imaginea
integrală poate fi calculată dintr -o imagine folosind foarte puține operații pe pixel. Odată
calculată, oricare dintre aceste trăsături de tip Haar pot fi calculate la orice scală sau locație în
timp constant.
A doua contribuție a articolului introdus de Viola și Jones este un simplu și eficient
clasificator („classifier”) ce este construit , folosind un număr mic de trăsături importante dintr –
o librărie imensă de posibile trăsături, utilizând AdaBoost . În cadrul fiecărei ferestre (sub
imagini) din imagine, numărul total de t răsături de tip Haar este foarte mare, mult mai mare
decât numărul de pixeli. Ca să fie asigurată clasificarea rapidă, procesul de învățare trebuie să
excludă o majoritate foarte largă de trăsături posibile și să se concentreze pe o porțiune
restrânsă de t răsături critice. Selecția trăsăturilor este realizată de algoritmul de învățare
AdaBoost limitând fiecare clasificator slab („weak classifier”) să depindă doar de o singură
trăsătură. Ca urmare, fiecare stagiu all procesului de stimulare („boosting proces s”), ce
selectează un nou clasificator slab, poate fi văzut ca un proces de selectare a unei trăsături.
Cea de -a treia contribuție adusă este dată de metoda de combinare succesivă a
clasificatorilor din ce în ce mai complexi, într -o structură cascadată ce crește exponențial
viteza de detecție prin concentrarea asupra regiunilor promițătoare din imagine.

Algoritmul cuprinde patru etape:

31
1. Selecția trăsăturilor Haar
2. Crearea imaginii integrale
3. Învățare AdaBoost
4. Clasificatori cascadați
În cele ce urmează vor f i detaliate aceste patru etape.
4.1.1 Selecția trăsăturilor de tip Haar
Trăsăturile simple folosite de Viola și Jones aduc aminte de familia de funcții Haar
folosite de Papageorgiou în lucrarea sa „A general framework for object detection” susținută
la „Internat ional Conference on Computer Vision” în 1998.
Funcția wavelet Haar reprezintă o secvență de funcții rescalate de tip treaptă. Această
funcție poate fi descrisă ca:

Fig 4.1.1.a Familia de funcții wavelet Haar
Viola și Jones au adoptat ideea de a folosi f uncții Haar și au creat așa numitele trăsături
de tip Haar. O astfel de trăsătură consideră regiuni dreptunghiulare adiacente în locații specifice
dintr -o fereastră de detecție („detectio n window”) , însumează intensitatea pixelilor în fiecare
regiune și ca lculează diferența dintre aceste sume. Diferența este apo i folosită pentru a cataloga
secțiuni din imagine. Aceste regiuni dreptunghiulare sunt de aceeași dimensiune și formă și
sunt adiacente vertical sau orizontal.
Tipurile de trăsături dreptunghiulare f olosite de Vioala -Jones implică două, trei sau
patru astfel de regiuni adiacente. Suma pixelilor albi se scade sumei pixelilor negri din regiunile
adiacente.

Fig 4.1.1.b Trăsături din: A și B două regiuni dreptunghiulare; C trei regiuni; D
patru regiuni [16].
În faza de detecție a algoritmului Viola -Jones, o fereastră de dimensiuni cunoscute este
mutată de -a lungul imaginii de intrare, iar pentru fiecare subregiune din imagine, se calculează
trăsătura de tip Haar. Diferența es te apoi comparată cu un prag (threshold) învățat ce separă
obiectele de non obiecte. Deoarece o astfel de trăsătură de tip Haar este un cla sificator slab

32
(„weak learner”), un număr mare de astfel de trăsături sunt necesare să descrie un obiect cu
suficient ă acuratețe. De aceea, în algoritmul propus de Viola și Jones, aceste trăsături de tip
Haar sunt organizate în așa numitele clasificări cascadate pentru a forma un clasificator
puternic („strong learner”). Principalul avantaj al acestor trăsături de tip Ha ar în fața altor feluri
de trăsături e dat de viteza de calcul. Datorită folosirii imaginii integrale, o astfel de trăsătura
Haar de orice dimensiune poate fi calculată in timp constant (aproximativ 60 instrucțiuni
procesor pentru regiuni de două dreptungh iuri).
Toate fețele umane prezintă câteva caracteristici similare. Aceste regularități, pot fi
depistate folosind trăsături de tip Haar. Câteva astfel de trăsături comune ale fețelor umane
sunt:
 Regiunea ochilor este mai întunecată decât cea a pomeți lor

Fig 4.1.1.c Trăsătură Haar suprapusă peste ochi și pomeți [17]
 Porțiunea superioară a nasului este mai luminoasă decât cea a ochilor

Fig 4.1.1.d Trăsătură Haar suprapusă peste nas și ochi [17]
Compunerea următoarelor caracteristici formează trăsături faciale recunoscubile:
 Localizarea și dimensiunea pentru: ochi, gură, puntea nasului
 Valoarea: gradientul intensității pixelilor
4.1.2 Imagine integrală
Trăsăturile dreptunghiulare pot fi calc ulate foarte rapid folosind o reprezentare
intermediară pentru imagine numită de Viola și Jones „integral image” (imagine integrală).
Această reprezentare, la locația x și y, conține suma pixelilor deasupra și la stanga de x și y
inclusiv.

Formula 4.1.2. 1 pentru calcularea imaginii integrale
Unde ii(x, y) este imaginea integrală, iar i(x, y) este imaginea originală.

33
Fig 4.1.2 .a Valoarea imaginii integrale în punctul (x,y) ca suma porțiunii hașurate
Imaginea integrală poate fi compusă într -o singură tre cere prin imaginea originală
folosind următoarea pereche de recurențe:

Unde s(x, y) este suma cumulativă pe rând, cu precizarea că:
s(x, -1) = 0 și ii( -1, y) = 0
Folosind imaginea integrală, orice sumă dreptunghiulară poate fi calcu lată pe baza a
patru referințe.

Fig 4.1.2.b Folosirea imaginii integrale pentru calcularea sumelor
Considerând imaginea de mai sus, pentru calcularea sumei pixelilor din dreptunghiul D
va fi nevoie de cele 4 referințe (1, 2, 3, 4).
Valoarea imaginii integrale în punctul 1 este suma pixelilor din dreptunghiul A.
Valoarea pentru locația 2 este A+B, pentru locația 3 este A+C, iar pentru locația 4 este
A+B+C+D. De unde reiese că suma D este calculată după formula:
D = 4 + 1 – (2+ 3)

4.1.3 Algoritmul de învățare AdaBoost
AdaBoost, ce vine de la „Adaptive Boosting”, este un meta algoritm de machine
learning formulat de Yaov Fr eund și Robert Schapire ce au câ știgat premiul Gödel în 2003
pentru munca lor. Poate fi folosit în conjuncție cu multe alte tipuri de algoritmi de învățare
pentru a le îmbunătăți performanțele. Rezultatele produse de alți algoritmi de învățare („weak
learners”) este combinat într -o sumă ponderată ce reprezintă rezultatul final produs de
clasificatorul amplificat („boosted classifier”). AdaBoost este adaptiv în se nsul că acei „weak
learners” sunt optimizați pe baza instanțelor greșit clasificate de clasificatorii anteriori.
AdaBoost este senzitiv la date zgomotoase.
Viteza cu care sunt evaluate aceste trăsături nu compensează, totuși, pentru numarul lor
mare. De e xemplu, într -o fereastră standard de 24×24 pixeli, sunt un total de M = 162,336

34
posibile trăsături de verificat, ceea ce ar fi extrem de costisitor de evaluat pentru a testa o
singură imagine. De aceea, framework -ul de detecție al obiectelor propus de Viol a și Jones,
folosește o variantă a algoritmului de învățare AdaBoost atât pentru a selecta cele mai
reprezentative trăsături dar și pentru a învăța clasificatorii ce le folosește. Acest algoritm
construiește un clasificator puternic pe baza unei combinații liniare ponde rate între
clasificatorii slabi:

Fiecare clasificator slab este o funcție de tip threshold bazată pe trăsătura f j:

Valoarea de threshold θ j și polaritatea s j ϵ ±1 sunt determinate în procesul de învățare,
precum și coeficienții α j.
În con tinuare va fi prezentată o variantă simplificată a algoritmului de învățare.
Input: Un set de N imagini pozitive și negative de învățat cu etichetele corespunzătoare (xi,
yi). Dacă imaginea i este o față yi = 1 altfel yi = -1.
1. Inițializare: atribuie o pon dere w1i = 1/N pentru fiecare imagine i.
2. Pentru fiecare trăsătură fj cu j = 1,….,M
a. Renormalizează ponderile ca însumate să dea unu
b. Aplică trăsătură fiecărei imagini din setul de învățat, după care găsește
thresholdul optimal și polaritatea θj , sj ce minimizează eroarea de clasificare:
, unde

c. Atribuie o pondere αj pentru hj ce e invers proporțională cu rata de eroare. În
acest fel, clasificatorii mai buni sunt considerați în proporție mai mare.
d. Ponderile pentru următoarea iterație 𝒘𝒋+𝟏𝒊 sunt reduse pentru imaginile i care
au fost corect clasificate
3. Setează clasificatorul final la:

4.1.4 Arhitectura cascadată
Arhitectura cascadată, pe lângă că reduce radical timpul de calcul, îmbunătățește și
performanța detecției. Cheia constă în faptul că mici clasificatoare amplificate („boosted
classifiers”) se pot construi ca să respingă multe dintre sub -ferestrele negative în timp ce
detectează aproape toate instanțele pozitive. Clasificatoare simple sunt folosite ca să respingă

35
majoritatea sub -ferestr elor, urmând apoi mai multe clasificatoare mai complexe ce asigură rata
de falsuri pozitive cat mai mică .
Etapele din cascadă sunt construite antrenând clasificatorii folosind AdaBoost. Pornind
de la un clasificator puternic bazat pe două trăsături (Fig 4. 1.1.c și d) , un filtru pentru fețe poate
fi obținut ajustând thresholdul pentru clasificator să minimizeze falsurile negative. Thresholdul
AdaBoost inițial, 1
2∑𝛼𝑡𝑇
𝑡=1 e proiectat să obțină o eroare scăzută pe datele de antrenament. Un
threshol d mai mic produce o rată de detecție mai mare, dar și rata falsurilor pozitive este mai
mare. Reglând thresholdul, filtrul bazat pe cele două trăsături poate obține performanțe de
100% rată detecție dar cu 50% rată de falsuri pozitive. Un astfel de clasifi cator însumează în
medie în jur de 60 instrucțiuni procesor. [16]
Procesul de detecție în arhitectura cascadată este următorul:
 Un rezultat pozitiv al primului clasificator activează evaluarea celui de al doilea
clasificator ce la rândul lui a fost ajustat să obțină rate de detecție foarte ridicate.
 Un rezultat pozitiv al celui de al doilea clasificator activează pe un al treilea.
Procesul continuă.
 Un rezultat negativ din partea oricărui clasificator duce la rejectarea imediată a
sub ferestrei respective.
Structura cascadei reflectă faptul ca în cadrul oricărei imagini, un număr foarte mare de
sub-ferestre sunt negative. Cu asta, arhitectura încearcă să respingă cât mai multe posibile
ferestre negative încă din primele etape.
În imaginea de mai jos se observă cum orice răspuns ne gativ, respinge sub -imaginea
respectivă. Doar când și ultimul clasificator răspunde pozitiv (T) se poate conclude că este
vorba de o față în imaginea respectivă.

Fig 4.1.4.a Procesarea cascadată

Un sim plu algoritm p entru învățarea cascadată e dat mai jos:
 Se alege valoarea pentru f valoarea maximă acceptabilă pentru falsuri
pozitive pe strat și d rata minimă acceptabilă a detecției pe strat
 Se alege ținta ratei medii de falsuri pozitive: Ftarget
 P = setul de exemple pozitive
 N = setul de exemple negative

36

Fig 4.1.4.b Algoritmul de învățare cascadată
Deoarece activarea fiecărui clasificator depinde în totalitate de comportamentul
predecesorului său, rata de falsuri pozitive pentru întreaga cascadă este :

Unde F este rata de falsuri pozitive, K este numărul de clasificatoare, fi este rata de fals
pozitiv pentru al i -lea clasificator. Analog pentru rata globală de detecție cu precizarea ca di
este rata de detecție.

Avantaje ale algoritmului Viola -Jones :
 Selecția trăsăturilor eficientă
 Detector invariant de scală și locație
 În loc să scaleze imaginea în sine, se scalează trăsăturile
 O astfel de schemă generică poate fi antrenată pentru detecția de alte obiecte (mașini,
mâini, zâmbete, ochi)
Dezavantaje a le algoritmului Viola -Jones:
 Detectorul e cel mai eficient doar pe imagini frontale
 De abia poate detecta o rotire a feței cu 45 de grade în jurul axei verticale sau orizontale
 Senzitiv la lumină
 Se detectează de mai multe ori aceeași față datorită suprapu nerilor sub -ferestrelor
Detectorul creat de Viola și Jones conținea mai mult de 6000 de trăsături (din cele
162336 posibile) împărțite în 38 de etape având 1, 10, 25, 25 și 50 de trăsături de verificat în
primele 5 etape. Conform autorilor, în medie, 10 tr ăsături din cele 6000+ sunt evaluate per sub –
fereastră.

37
4.1.5 Implementarea în OpenCV a framework -ului Viola -Jones
OpenCV vine atât cu un antrenor („trainer”) cât și cu un detector. Dacă dorim să
antrenăm un clasificator pentru a ne detecta orice obiect precum mașina, avion, etc. se poate
folosi OpenCV pentru a crea unul.
Clasificatori pre -antrenați pentru față, ochi, zâmbet etc. pot fi găsiți direct în OpenCV.
Acești clasificatori sunt stocați în fișiere de tip XML stocate în folderul
opencv/data/haarcascades/ .

Fig 4.1.5.a Fișiere haarcascade prezente în OpenCV
Un fișier de tipul haarcascade.xml prezintă următoarele informații:
 Primele două rânduri sunt standard pentru începutul de fișier
 <featureType> – tipul trăsăturilor descrise în cadrul tag -urilor <rects >, poate fi
fie HAAR fie LBP
 <height> și <width> – dimensiunea unei ferestre de tip trăsătură
 <stageParams> <maxWeakCount> – numărul maxim de clasificatoare slabe pe
toate nivelele (etapele din cascadă)
 <stageNum> – numărul total de nivele cascadate
 <stag e> – sunt de descrise numărul de clasificatoare pe nivelul respectiv
împreună cu thresholdul
 <internalNodes> – (din codul sursă) semnifică node.left node.right
node.featureIdx node.threshold; primele două zicând pe baza thresholdului care
nod să -l ia urmă torul; ultimele două reprezentând trăsătura de analizat pentru
nodul respectiv
 <features> împreună cu <rects> descriu trăsăturile (dreptunghiurile) negre și
cele albe. (fig. 4.1.1.b)

38

Fig 4.1.5.b Fragmente din fișierul haarcascade_frontalface_default.xml
Pentru un fișier de tip LBP (Local Binary Patterns Histograms)
„lbpcascade_frontalface.xml” diferențe le apar în cadrul tag -urilor <internalNodes> din
clasificatoare și tag -ul <rects> e înlocuit de un singur <rect> :

Fig 4.1.5.c

39
Primele trei valori semnif ică node.left node.right node.featureId; primele două zicând
pe baza thresholdului care nod să -l ia următorul; featureId reprezentând trăsătura de analizat
pentru nodul respectiv (un dreptunghi din cele 139 de dreptunghiuri prezente în fișier);
Ultimele 8 valori din <internalNodes> reprezintă punctele de diferență din 4 dreptunghiuri
calculate pe baza imaginii integrale.
Diferențele între cele două tipuri de trăsături: Haar și LBP sunt:
 LBP oferă precizie la nivel de întreg pe când H aar operează pe numere flotante.
Deci atât perioada de învățare cât și de detecție este de câteva ori mai rapidă
decât perioada necesară pentru a învăța o structura Haar. Acesta este
principalul fapt (calcul computațional mai mic) pentru care am ales o
abordare bazată pe LBP în aplicația suportată de Raspberry Pi.
 Mărimea fișierului lbp.xml este undeva la ~1500 linii pe când cel haar.xml
ajunge la ~33300 de linii; de unde reiese și viteza.
 Calitatea detecției depinde foarte mult de setul de antrenament și de parametrii
de învățar e selectați. Se poate învăța un clasificator LBP să oferă performanțe
aproape la fel de bune cu a unuia bazat pe Haar într -un interval mult mai mic de
timp.
Un exemplu de folosire a algoritmului Viola -Jones îl găsim prezentat în figura 4.1.5.d ,
în care s -au folosit doi clasificatori cascadați obținuți pe baza trăsăturilor de tip HAAR
 Haarcascade_frontalface_default.xml
 Haarcascade_smile.xml

40

Fig 4.1.5.d Codul aferent detecției de fețe și zâmbete într -o imagine
Codul este compatibil și cu o structură cas cadată bazată pe LBP. Singura modificare
ce trebuie adusă codului este calea către fișierul cascadat de tip XML.

Fig 4.1.5.e Imaginea rezultată în urma detecție de fețe și zâmbete din imagine

41
Explicarea parametrilor metodelor folosite:
 CascadeClassifier (stringPathToXMLcascade) – se asteaptă să primească un fișier
XML de tip Haar sau LBP și returnează obiectul de tip clasificator cascadat în variabilă.
 detectMultiScale(image[, scaleFactor[, minNeighbors[, flags[, minSize[,
maxSize]]]]]) [18]
o unde [ ] reprezintă parametri obționali
o image – matrice de tip CV_8U reprezentând imaginea unde să acționeze
detecția
o scaleFactor – parametru ce specifică cât de mult e redusă dimensiunea imaginii
pentru fiecare scală a imaginii (fig 4 .1.5.f). Modelele din datele de antrenament
vizibile în XML au dimensiune fixă. Pentru ca fețe de diferite dimensiuni din
imaginea de intrare să fie detectate, imaginea de intrare va fi scalată în jos cu
acest pas . O valoare de 1,05 înseamnă ca imaginea va fi redusă în fiecare pas cu
5%. Cu cât e mai mic, șansele ca o față să fie detectată cresc însă algoritmul va
deveni mult mai lent, deoarece vor fi mai multe imagini de verificat. Scalarea
se face folosind pixelii vecini.

Fig 4.1.5.f Exemplu de scalare în jos a imaginii de intrare
o minNeighbors – parametru ce specifică câți vecini fiecare regiune candidat
trebuie să aibă ca să fie reținut. Acest parametru va afecta calitatea fețelor
detectate: o valoare mai mare va însemna detecții mai puține însă cu mai mare
acuratețe . De regulă valori între 5 și 8.
o flags – Parametru folosit în vechea arhitectură cascadată. Nu mai este folosit în
cea nouă.
o minSize – valoarea minima posibilă a obiectului. Obiecte mai mici de atât vor
fi ignorate.
o maxSize – mărimea maximă posibilă a obiectului.
o Funcția va returna grupuri de (x, y, w, h) din imagine reprezentând zonele unde
au fost fețe detectate
 x – coordonata pe x a punctului de start al dreptunghiului detectat
 y – coordonata pe y
 w – lățimea dreptunghiului pornind din x
 h – înălțimea dreptunghiului pornind din y
 rectangle(image, topLeftPoint, bottomRight Point, color, lineDepth)
o image – imaginea pe care se va desena un dreptunghi
o topLeftPoint – colțul din stânga sus al dreptunghiului
o bottomRightPoint – colțul din dreapta j os al dreptunghiului
o color – culoarea cu care se va desena

42
o lineDepth – grosimea liniei de desenare
 roi_gray = gray[y:y+h, x:x+w] – notație specifică NumPy. Din imaginea „gray” se va
extrage o fâșie plecând de la y până la y+h, analog și pe x.
4.2 Histogram a paternurilor binare locale
Histograma paternurilor binare locale („Local Binary Patterns Histogram”) cunoscut și sub
numele de codul LBP. Ideea din spatele algoritmului este de a nu privi întreaga imagine ca un
vector pe mai multe dimensiuni ci să fie descri se trăsăturile locale ale unui obiect. Trăsăturile
extrase astfel vor avea dimensionalitate mică implicit. O idee bună, însă reprezentarea imaginii
suferă din cauza variație de lumină.
Metodologia LBP își are rădăcini în analiza 2D a texturilor. Idea de b ază a algoritmului
este de a restrânge o structură locală dintr -o imagine comparând fiecare pixel cu vecinii lui. Se
consideră un pixel din centru unei matrici 3×3 (ea reprezentând vecinii) ca fiind un threshold
pentru cei din jurul său. Dacă intensitatea pixelului central este mai mare decât unui vecin,
atunci acel vecin va avea valoarea 1, altfel va avea valoarea 0. Pornind dintr -un colț anume al
vecinilor, se obține o reprezentare binară. Cu 8 vecini posibili, se obțin 2^8 combinații posibile
numite „Loc al Binary Patterns”. Primul operator LBP descris în literatură a folosit vecinătate
de 3 x 3ca în figura de mai jos.

Fig 4.2.a Formarea vectorului LBP [19]
Pentru o vecinătate de 3×3 se obțin 2^8 = 256 de paternuri posibile. P rin urmare,
vectorul LBP va avea valoarea minimă 0, iar valoarea maximă de 255. Se poate astfel construi
histograma binară pe 256 de valori ce va reprezenta vectorul final de trăsături.
O descriere mai formală a operatorului LBP poate fi dată de formula:

Unde:
 (xc , yc ) fiind pixelul central cu intensitatea i c
 ip intensitatea pixelului vecin
 s este funcția semn (1 dacă x ≥ 0; 0 altfel)
Această descriere permite capturarea de detalii fine în imagini. De fapt , autorii [20] au
reușit să concureze cu rezultate „state of the art” pe clasificare de texturi. La scurt după ce acest
operator a fost publicat, s -a observat că o vecinătate fixă nu reușește să encodeze detaliile ce
diferă în scală. Astfel, operatorul a fost extins să folos ească o vecinătate variabilă. Ide ea a fost
să se alinieze un număr arbitrar de vecini pe un cerc de rază variabilă, ce ar pe rmite găsirea
următoarelor vecinătăți :

43

Fig 4.2.b Exemplu de vecinătăți în funcție de raza r și numărul de vecini p
Pentru un punct dat (x c , yc ), poziția vecinului (xp , yp), p ϵ P se poate calcula conform
relațiilor:

Dacă un punct de pe cerc nu corespunde cu coordonatele din imagine, atunci acel
punct va fi interpolat. OpenCV implementează interpolarea biliniară:

Fig 4.2.c Exemplu de transformări grayscale ce demonstrează că operatorul LBP
este robust față de ele
Tot ce mai rămâne de făcut este cum să fie încorporată informația spațială în modelul
de recunoaștere a feței. Reprezentarea propusă de autori [20] este să fie divizată imaginea
creată de LBP în m regiuni locale și să fie extrasă histograma din fiecare. Vectorul spațial
de trăsături este apoi format din concatenarea de histograme locale. Aceste histograme
poartă numele de „Local Binary Pa tterns Histograms”.

44
4.3 Histograma gradientelor orientate (HOG)
Histograma unei imagini este o reprezentare grafică a distribuției tonalităților
(culorilor) într -o imagine digitală.
Histograma gradientelor orientate („Histogram of oriented gradients” <HOG>) este un
descriptor de trăsături folosit în „computer vison” și procesarea de imagini pentru detecția de
obiecte. Tehnica presupune numărarea orientărilor gradientului în porțiuni localizate din
imagine. Metoda este calculată pe baza unui grid dens de celu le neuniform așezate și se
folosește de suprapunerea locală a contrastului normalizat pentru mărirea acurateței.
În anul 2005, Navneet Dalal și Bill Triggs, doi cercetători la „French National Institute
for Research In Computer Science and Automation (IN RIA)” și -au prezentat contribuția
suplimentară adusă descriptorilor HOG (deja existenți încă din 1994 dar nu sub denumirea de
HOG) la „Conference on Computer Vision and Pattern Recognition (CVPR)” [21]. În acest
articol, s -au foc usat asupra detecției de pietoni în imagini statice.
Ideea esențială din spatele descriptorului HOG este aceea că aparițiile și formele locale
ale obiectului dintr -o imagine pot fi descrise ca o distribuție a intensității gradientului sau a
direcției de c ontur (margine). Imaginea este împărțită în regiuni mici conectate între ele numite
celule, iar pentru pixelii din cadrul fiecărei celule se calculează histograma orientării
gradientului. Descriptorul este concatenarea acestor histograme. Pentru mărirea ac urateței,
histogramele locale pot avea contrastul normalizat prin calcularea unei porțiuni a intensității
dintr -o regiune mai mare a imaginii, numită bloc, iar apoi se folosește această valoare pentru a
normaliza toate celulele dintr -un bloc. Normalizarea duce la invarianță mai bună a schimbărilor
de iluminare și umbrire.
Descriptorul HOG are câteva avantaje cheie în fața altor descriptori. Deoarece operează
pe celule locale, este invariant la transformările geometrice și fotometrice mai puțin î nsă față
de orientările obiectului. Aceste schimbări pot apărea doa r în regiuni spațiale mai mari. Mai
mult, după cum au descoperit Dalal și Triggs [21], eșantionarea spațială brută („coarse grain
sampling”), eșantionarea fină du pă orientare („fine orientațion sampling”) și normalizarea
locală fotometrică puternică permit ca mișcarea individuală a diferitelor părți ale pietonilor să
fie ignorată atâta timp cat păstrează o poziție verticală dreaptă. De aceea, descriptorul HOG
este potrivit pentru detecția oamenilor din imagini .
4.3.1 Implementarea algoritmului

Fig 4.3.1.a Schema bloc a algoritmului de calculare a descriptorului HOG
4.3.1.1 Calcularea gradientului
Primul pas al calcului de trăsături pentru majoritatea detectoarelor este pre -procesarea
imaginilor pentru a fi asigurată folosirea culorilor normalizate. Însă, după cum arată în lucrarea
lor Dalal și Triggs [21], acest pas poate fi sărit pentru calcularea descriptorului HOG, deoarece
se obțin practic acelea și rezultate și fără normalizare. Astfel, primul pas devine calcularea

45
gradientului. Cea mai comună metodă este aplicarea derivatei discrete pe una sau pe amândouă
dintre direcțiile verticală sau orizontală. Mai specific, aplicarea unui filtru pentru culoa re sau
intensitate a datelor din imagine:
[-1, 0, 1] și [ -1, 0, 1]T
Dalal și Triggs au testat și alte măști mai complexe, precum operatorul Sobel 3×3 sau
măști diagonale, dar aceste măști au adus rezultate slabe în detecția oamenilor din imagini. Au
testat și testarea de netezire Gaussiană, dar au concluzionat că în lipsa oricărei neteziri se obțin
rezultate mai bune în practică.
Pentru calcularea gradientului, în OpenCV, se poate folosi și operatorul Sobel de
dimensiune 1.

Fig 4.3.1.1.a Exemplu de calc ulare a gradientului în OpenCV

Fig 4.3.1.1.b Operatorul Sobel de dimensiune unu pe direcția y respectiv x
Unde funcția Sobel are următorii parametrii:
 Imaginea de intrare
 Tipul de date al ieșirii
 Derivata pe x
 Derivata pe y
 Dimensiunea operatorului. În to ate cazurile este ksize x ksize mai puțin când
ksize = 1. În cazul acesta dimensiunea devine 3 x 1 sau 1 x 3
Calcularea magnitudinii și a unghiului gradientului se face folosind metoda
cartToPolar astfel:

Fig 4.3.1.1.c Calculul magnitudinii și a unghiu lui gradientului

46

1) 2) 3) 4)
Fig 4.3.1.1.d 1) Imaginea originală, 2) gradientul pe x, 3) gradientul pe y,
4) magnitudinea gradientului [22]
Se poate observa cum gradientul pe x acționează asupra liniilor verticale, în timp ce
gradientul pe y asupra celor orizontale. Magnitudinea gradientului se observă ori de câte ori e
o diferență pronunțată în intensitate.
La nivel de fiecare pixel, gradientul are o direcție și o magnitudine. Pentru imaginile
color, gradienții pe cele trei canale sunt evaluați. Magnitudinea gradientului pentru un pixel
este magnitudinea maximă dintre cei trei gradienți, iar unghiul corespunde gradientului maxim.
4.3.1.2 Votul ponderat în domeniul spațial și orientarea celulelor
Acest pa s este unul reprezentativ pentru non -liniaritatea descriptorului. Fiecare pixel
din cadrul unei celule exprimă un vot ponderat pentru un canal de histogramă orientat pe baza
valorilor găsite în calculul gradientului. Celulele însuși pot fi dreptunghiulare sau radiale în
formă, iar canalele histogramei vor fi egal depărtate între 0 și 180 de grade în cazul gradientului
fără semn sau între 0 și 360 de grade în cazul celui cu semn. Dalal și Triggs au descoperit că
gradientele fără semn folosite în conjuncție c u 9 canale de histogramă au dat cele mai bune
performanțe în experimentul lor de detecție de oameni [21]. Cât pentru votul ponderat,
contribuția pixelilor poate fi fie magnitudinea gradientului însuși sau o funcție a magnitudinii .
În teste, magnitudinea gradientului a dat cele mai bune rezultate. Altă posibilitate pentru votul
ponderat ar putea fi date de rădăcina pătrată a magnitudinii gradientului .

Fig 4.3.1.2 .a În stânga – imaginea împărțită în celule de 8×8; în dreapta, săg ețile
arată direcția gradientului în timp ce lungimea ei arată magnitudinea [22]
Histograma gradientelor este, în esență, un vector de 9 numere ce corespunde
unghiurilor 0, 20, 40, 60..160 de grade.

47

Fig 4.3.1.2.b Compunerea hi stogramei gradientelor [22]
Figura de mai sus ilustrează cum se compune histograma gradientelor. Locul din
histogramă e selectat de direcție (unghi), în timp ce valoarea e dată de magnitudinea
gradientului. Pixelul albastru are un unghi de 80 de grade și o magnitudine de 2, ce va fi
însumată pe poziția 5 din histogramă. Pixelul roșu având un unghi de 10 grade (10 fiind la
jumătatea dintre 0 și 20), votul pixelului se împarte egal între cele două containere.
4.3.1.3 Blocuri descriptive
Ca să conteze pentru iluminare și contrast, forțele gradientului trebuie normalizate
local. Acest lucru înseamnă gruparea celulelor în blocuri mai mari, conectate spațial.
Descriptorul HOG va fi vectorul concatenat al componentelor histogramei de celule
normalizate din toate blocurile. Aceste blocuri, de regulă, se suprapun, ceea ce înseamnă că
fiecare celulă contribuie mai mult decât o singură dată pentru descriptorul final. Există două
geometri principale pentru blocuri:
 Dreptunghiulare R -HOG
o Sunt grid -uri pătratice reprezentate de trei parametri:
 Numărul de celule per bloc
 Numărul de pixeli per celulă
 Numărul de canale pe celulă de histogramă
o Sunt calculate pentru o singură scală fără aliniere după orientare
o Sunt folosite în conjuncție ca să formeze info rmația spațială

Fig 4.3.1.3.a Exemplu R -HOG
 Circulare C -HOG
o Pot fi găsite în două variante:
 O singură celulă centrală
 O celulă centrală divizată unghiular

48
o Sunt reprezentate de patru parametri:
 Numărul de containere unghiulare și radiale
 Raza containerul ui din centru
 Factorul de expansiune pentru raza containerelor radiale
suplimentare

Fig 4.3.1.3.b Exemplu C -HOG
În experimentul lor, Dalal și Triggs, au găsit parametri optimi : celule de 8×8 pixeli
(16×16 pixeli per bloc) cu 9 canale de histogramă pentru R-HOG . Cât pentru C -HOG, cei doi
au descoperit că cele două mari vari ații obțin aceeași performanță și că două containere radiale
cu patru unghiulare, un rază de la centru de 4 pixeli și un factor de expansiune de 2 dau cele
mai bune rezultate.
4.3.1.4 Normalizar ea blocului
Dalal și Triggs au explorat patru metode diferite pentru normalizarea blocurilor. Fie ν
vectorul non normalizat ce conț ine histogramele dintr -un bloc, || ν || k norma de ordinul k = 1,2
și e o constantă mică. Atunci, procesul de normalizare poat e fi unul dintre următoarele:
 L2-norm :

 L2-hys = L2 -norm urmat de o tăiere (limitând pe ν la 0.2) și renormalizând
 L1-norm:

 L1-sqrt:

În lucrarea lor, Dalal și Triggs au descoperit ca cele mai slabe performanțe sunt date
de L1 -norm, în timp ce celel alte trei dau valori similare.
4.3.1.5 Clasificator de tip SVM sau rețea neuronală
Ultimul pas al algoritmului de detecție al obiectelor folosind descriptori ai histogramei
gradientelor orientate este punerea descriptorilor într -un sistem de recunoaștere bazată p e
învățarea supervizată. „Support vector machine” (SVM) este un clasificator binar ce caută
hiperplanul optimal pe post de funcție de decizie. Odată învățat pe imagini ce conțin un specific
obiect, clasificatorul SVM poate să ia decizii despre prezența sau absența unui obiect, precum
un om, în alte imagini adiționale.

49
Trăsăturile descriptorilor de gradient pot fi date și unei rețele neuronale ce ar da o
acuratețe mult mai mare în comparație cu SVM. Clasificatorul neural poate accepta trăsătura
descriptorulu i ca o funcție binară sau funcția optimă.
Figura de mai jos prezintă detecția pe bază de descriptor HOG

Fig. 4.3.1.5.a Exemplu de funcționare al descriptorului HOG [21]
Explicații:
 a) media imaginii gradientului în setul de im agini de antrenament
 b) fiecare „pixel” arată ponderea maximă pozitivă dată de SVM pe un bloc
centrat pe pixel
 c) similar cu b) dar pentru negativă
 d) imaginea de test
 e) descriptorul R -HOG
 f) si g) descriptorul R -HG ponderat corespunzător cu ponderile po zitive și
negative date de SVM
Se poate observa că descriptorul acționează în principal pe conturul siluetei (în special
cap, umeri și picioare).
4.3.2 Implementa rea în OpenCV a descriptorului HOG
Biblioteca OpenCV conține un descriptor HOG căruia i se adaugă un detector liniar
SVM.

50

Fig 4.3.2 .a Exemplu de folosire a descriptorului HOG în OpenCV

Fig 4.3.2.b Imaginea rezultată în urma rulării detectorului HOG
Parametrii funcției detectMultiScale sunt cei care:
 Măresc numărul de detecții fals -pozitive
 Influențează acuratețea detecției rezultând în pierderea unor detecții
 Afectează dramatic viteza procesului de detecție
detectMultiScale(img, [hitThreshold [, winStride [, padding [, scale [, finalThreshold [,
useMeanShiftGrouping]]]]]] :
 Img – imaginea pe care apl icăm detecția
 hitThreshold – distanța Euclidiană maximă între inputul trăsăturilor HOG și planul
clasificator dat de SVM
 winStride – tuplu pentru dimensiunea pe x și pe y a ferestrei glisante ce traversează
imaginea . Alături de scale, acești parametri au i mplicații extrem de importante în
acuratețea și viteza detecției . Cu cât fereastra are valori mai mici, cu atât va fi nevoie
de mai multe ferestre de analizat ceea ce ridică timpul computațional.
 padding – tuplu pentru numărul de pixeli pe direcțiile x și y pentru care fereastra glisantă
este delimitată în imaginea originală

51
 scale – la fel cu scaleFactor de la Viola -Jones, arată cu cât va fi micșorată imaginea
pentru noua scală din imaginea piramidală . Valorile mici cresc timpul de procesare.
Este folosit p entru detecția aceluiași obiect având scale diferite (aflându -se la distanțe
diferite)
 finalThreshold – nu există documentație pentru Python
 useMeanShiftGrouping – de tip boolean, corecția pentru regiuni ale aceluiași obiect ce
se suprapun
Din motive de c alcul computațional prea costisitor pentru un Raspberry Pi, pentru
detecția persoanelor dintr -o secvență video, s -a recurs la simpla detecție a mișcărilor între două
imagini consecutive. Această presupunere ca o mișcare (de o anumită dimensiune) reprezintă
o persoană este aproximativă. Considerând că printr -un magazin se plimbă doar oameni și
pentru o regiune suficient de mare (să înglobeze și mișcarea unui cărucior împins de către un
om) se obțin rezultate mulțumitoare în cadrul numărării persoanelor dintr -o imagine. În
capitolul 5 vor fi prezentate noțiunile teoretice prezentate în capitolul 3 implementate pentru
detecția mișcărilor într -o secvență video.

52
Capitolul 5. Captarea unei secvențe video
5.1 Conectarea camerei la Raspberry Pi
5.1.1 Cameră video USB
În figura de mai jos se pot observa pașii necesari conectării unei camere obișnuite web
de tip USB la Raspberry Pi în vederea captării și preluării de imagini folosind OpenCV.

Fig. 5.1.1 Conectarea camerei USB și captarea de frame -uri
Trebuie precizat ca met oda preocesează_frame(frame) este o metodă fictivă, în locul
ei, în codul atașat pe DVD al aplicației finale, fiind o serie de operații de detecție, contorizare
și desenare a regiunilor de interes detectate.

5.1.2 PiCamera
Pentru o cameră specializată în trimit erea datelor înspre Raspberry Pi, codul de mai sus
va fi adaptat folosind interfața specializată PiCamera astfel:

53

Fig 5.1.2 Exemplu de preluare a frame -urilor de la PiCamera
PiRGBArray reprezintă un vector în 3 dimensiuni (rânduri, coloane, culori) din tr-o
captură RGB ne -encodată. Vectorul este accesibil prin atributul array .
Specificațiile și limitările tehnice ale Pi camerei pot fi găsite în tabelul de mai jos:

Tabel 5.1.2 PiCamera v2 specificații tehnice

54
5.2 Detecția mișcărilor
În continuare vor fi pr ezentați pașii efectuați pentru detecția oamenilor prin prisma
detecție mișcărilor între frame -uri consecutive. Noțiunile teoretice au fost prezentate în
capitolul 3, iar preluarea de imagini a fost detaliată în subcapitolul anterior.
Metoda cv2.Accumulate Weighted(src, dest, alpha) calculează suma ponderată a unei
imagini src și un acumulator dst, acesta devenind media unei secvențe de frame -uri conform
formulei:

Fig 5.2.a Formula pentru metoda AccumulateWeighted
Algoritmul implementat se adaptează condiț iilor de lumină datorită mediei secvenței
de frame -uri.

Fig 5.2 Algoritmul de detecție a mișcărilor
Dacă s -a optat pentru una din cele 3 variante de detecție a persoanelor bazată pe extrage
de background prin MOG, MOG2 sau GMG, partea de cod de deasupra de linia fgmask =
thresh va fi ștearsă , iar linia respectivă va fi înlocuită cu rezultatul metodei apply a algoritmului
respectiv.

55
Capitolul 6. Aplicarea noțiunilor teoretice î n dezvoltarea
aplicației

În cele ce urmează se ilustrează pașii practici îndep liniți în realizarea aplicației,
folosindu -ne de conceptele teoretice prezentate anterior.
6.1 Descrierea aplicației
Aplicația este orientată pe extragerea anumitor informații dintr -o secvență video în timp
real și trimiterea acestora către o altă aplicație ( practic , către un API: application
programming interface) pentru a putea fi redate sub formă de grafice și diagrame. Informații
precum: numărul de fețe umane ce privesc înspre cameră , numărul total de persoane
detectate , starea de spirit a persoanelor ce p rivesc direct spre camera video
(prezența/absența zâmbetului din fiecare față detectată) dintr -un anumit interval setat de
utilizator vor putea fi vizualizate .
Proiectul este alcătuit din 2 module (aplicații) :
 Platforma ,rezidentă pe Raspberry Pi, de captare a imaginilor (secvență
video), extragere a informațiilor din imagini și prelucrarea acestora pentru
a putea fi trimise către interfața web .
 Interfața web: panoul de control unde sunt afișate datele primite de la mai
multe Raspberry Pi -uri precum și d iverse analize și statistici prezentate sub
formă de grafice și diagrame.
6.1.1 Modulul 1: platforma de detecție și contorizare a persoanelor
Platforma, are un comportament de sistem automat, în sensul că nu are nevoie de
intervenția omului, decât in faza de ins talare și reglare a parametrilor de detecție. La pornirea
Raspberry -ului, aplicația pornește automat, fiind instalată sub formă de serviciu, cu ajutorul
sistem ului „Supervisor” [23].
Pentru contorizarea numărului de perso ane ce trec în zona (preajma) unui panou sau ecran
de publicitate au fost analizate trei soluții posibile:
1. Procesarea de imagini preluate de către o cameră video (web sau PiCamera)
atașată la Raspberry Pi

56
 Avantaje
o Detecția fețelor umane dintr -o imagine est e, posibil, cea mai
precisă metodă dintre toate cele analizate deoarece principalul
obiectiv este de a contoriza numărul de persoane ce privesc către
dispozitivul publicitar (panou, ecran etc.), camera video fiind în
imediata apropiere a acestuia.
 Dezavant aje
o Cost computațional mai ridicat (→ mai multă energie disipată )
decât în cazul celorlalte metode
o Necesitatea de a cumpăra o cameră video fie ea de tip web
(conector de tip USB) → cost de 5$ – 100$ sau de tip PiCamera →
cost de aproximativ 20$
o O aproximare grosieră a raz ei de acțiune maximală a algoritmului
de detecție fiind de 15 -20 de metri
2. Detecția și contorizarea device -urilor ce dispun de conexiune la Wi -Fi: telefoane
inteligente, tablete, laptopuri etc.
 Avantaje
o Cea mai mare rază de acțiune: o antenă de 5dB ajunge la o rază de
până la 300 metri fără obstacole .
 Dezavantaje
o O rază de acțiune mult prea largă poate duce la o probleme precum:
poate sau nu deținătorul device -ului sa vadă panoul/ecranul
publicitar?
o Necesitatea de a cumpăra un adaptor Wi -Fi mai performant decât
cel existent pe Raspberry Pi model 3 B → cos t de 5-30$
o Majoritatea oamenilor nu își țin funcția de Wi -Fi pornită, mai ales
la cumpărături deoarece aceasta consumă bateria → metoda nu e
destul de precisă, multe persoane pot să treacă „neo bservate”
3. Detecția și contorizarea device -urilor ce au funcția de Bluetooth pornită
 Avantaje
o Funcția de Bluetooth poate fi regăsită și în telefoanele simple, nu
neapărat în cele inteligente → acoperire mai largă decât cea cu
funcția de Wi -Fi

57
 Dezavantaje
o Cea mai mică rază de acțiune chiar și cu un amplificator (5-10$
unul obișnuit, 100$ unul profesionist)
o Metoda necesită ca funcția de Bluetooth să fie pornită ceea ce duce
la un consum al bateriei, iar în ultima vreme această funcție e tot
mai puțin utilizată , transferurile realizând u-se prin internet.

O posibilă soluție pentru ca utilizatorii sa aibă funcția de Bluetooth/ Wi -Fi pornită ar
putea să fie dată de afișarea unui mesaj , într-un colț al panoului/ecranului publicitar , de
forma: „ Puteți primi un joc g ratuit pentru telefon dacă vă conectați (pair) cu device -ul
nostru ” (conceptul de „gamification ”). Acest concept presupune aplicarea de principii și
elemente ce țin de design -ul jocurilor în contexte ce nu implică jocurile. Tehnicile de
„gamification” sunt menite să stimuleze dorințele naturale ale oamenilor pentru socializare,
învățare, stăpânire, competiție, realizare, statut, auto -exprimare, altruism sau pur și simplu
răspunsul lor la încadrarea unei situații ca joc sau joacă.
După analizarea avantaje lor/dezavantaje lor ale acestor variante, pentru realizarea
acestui modul s-a ales folosirea unei camere video de tipul PiCamera î mpreună cu o
serie de algoritmi din seria „ Computer Vision” . PiCamera a fost aleasă in detrimentul celei
clasice de tip web pe USB , deoarece este dedicată pentru Raspberry Pi : se conectează direct
pe GPU și e capabilă de encodare video de 1080p la 30 Hz. Fiind atașată direct la GPU,
impactul asupra CPU este minimal, lăsând astfel loc pentru alte procesări . Cu alte cuvinte,
preluarea frame -urilor este mult mai performantă (rapidă) decât în cazul protocolului USB.

58
6.1.2 Modulul 2: Interfața web
Acest modul al aplicației vizează doar meniul „Audience” (audiență), ce a fost realizat
de mine , din interfața website -ului de comandă al unui Wall -i.

Fig 6.1.2 .a Interfața web a modulului
Pot fi vizualizate informații precum:
 Numărul de persoane ce au fost detectate în volumul de
vizualizare al camerei într-un interval de timp .

 Numărul de persoane ce au fost dete ctate privind spre
cameră, mai exact numarul de fețe umane depistate în
același interval de timp .

 Procentul de persoane al căror fețe au fost detectate
zâmbind sau râzând.

Deși, inițial, se dorea integrarea acestui modul în aplicația deja existentă Wall -i
realizată în Django (framework pentru dezvoltări de aplicații web în Python), din considerente
tehnice și ce țin de resurse umane (persoan a ce a realizat aplicația inițială s -a retras și a trebuit
înlocuit), interfața Wall -i a fost portată pe cod PHP.

59

Fig 6.1.2.b Exemplu de preluare și inserare în baza de date a datelor primite de la modulul 1
Exemplul de mai sus prezintă o parte a „back -end”-ului (partea de server) a modulului
2, în care se primește prin metoda „POST” un JSON trimis de modulul 1 al aplicați ei, se
convertește într -un array asociativ din PHP și se inserează într -un tabel din baza de date
MySQL.
Diagrama de timp împreună cu graficele de tip coloane au fost realizate în partea de
„front -end” (partea de client) și anume în JavaScript f olosind librări a ajutătoare pentru desenare
de grafice „flot”.
Un exemplu utilizare a librărie i „flot” pe baza unui JSON de configurare (fig 6.1.2.d)
îl putem vedea mai jos:

Fig 6.1.2.c Exemplu de utilizare „flot”
Funcția $.plot(placeholder, data, chart_options) prim ește ca parametrii:
 Elementul html unde va fi afișat graficul. Notația $(”#chart -placeholder”)
specifică „jQuery” preia din pagina html elementul (aici div -ul) cu id -ul
„chart -placeholder”

60
 data reprezintă valorile extrase din baza de date despre numărul de
persoane, fețe, zâmbete.
 chart _options este un JSON de forma:

Fig 6.1.2.d Exemplu de JSON de configurare pentru „flot”

61
6.2 Use case -ul aplicației
Schema următoare ilustrează, într -un mod general, bazat pe pictograme și imagini, lista de
acțiuni sau pași, c e definesc interacțiunile dintre act or și sistem.

Fig 6.2 Use case general al aplicației
Legendă :
1. – reprezintă mașina de calcul (Raspberry Pi –ul) pe care rulează softul
2. – reprezintă PiCamera ce va prelua imagini continuu
3. – reprezintă conexiune a la internet
4. – reprezintă fișierul de configurare de tip .JSON al aplicației
5. – reprezintă ieșirea din aplicație
6. – reprezintă un utilizator (director de marketing) al aplicației integrale
Wall -i
7. – reprezintă un use case. Acestea vor fi detaliate fiecare în parte.

62
6.2.1 Descriere detaliată a use case -urilor
6.2.1.1 Prezentare generală
Use Case: Colectare metrici legate de publicul țintă
Descriere: Un utilizator folosește aplicația pentru a afla informații legate de
publicul (persoanele) ce urm ărește un anumit anunț video publicitar ; informații precum: câte
persoane au trecut prin fața anunțului, câte din ele au văzut anunțul (numărul de fețe detectate
ca fiind orientate direct pe direcția camerei), starea lor de spirit (zâmbesc sau nu) vor fi t rimise
către modulul 2 al aplicației pentru afișare.
Actori: Mașina de calcul, PiCamera, Utilizator
Precondiții: 1. PiCamera trebuie să fie conectată la Raspberry Pi
2. Mașina de calcul trebuie să aibă conexiune la internet
3. Pregătirea fișierului de configurare de tip .JSON ce va conține
parametrii aplicației. Acești parametri pot fi dați și din linie de comandă.
4. Serviciul „ supervisor ” trebuie să fie instalat și configurat pe
mașina de calcul pentru ca aplicația să pornească automat. Se p oate po rni
aplicația și manual î n lipsa serviciului.
Scenariul principal:
1. Pornire mașină de calcul. Următoarele 2 cazuri sunt posibile:
a. Aplicația este inițiali zată de serviciul „ supervisor ”, iar colectarea și
transmisia datelor poate începe
b. În lipsa serviciului „supervisor ” este necesar încă un pas de pornire a
aplicației, din linie de comandă este dat modul de lucru al aplicației: fie
din fișierul de configurație fie prin adăugarea mai multor parametri liniei
de comandă.
2. Verificare precondiții : există o PiCamera conectată și există conexiune la
internet
a. În caz contrar, actualizare jurnal cu motivul eșuării
3. Calibrarea perimetrului de detecție al camerei , inițializarea variabilelor
specifice algoritmilor de detecție din program și a variabilelor de adresă (unde
vor fi trimise datele) pe baza parametrilor de intrare
4. Pornește camera și așteaptă un timp scurt (aprox 0.3s) pentru a se încălzi
camera
5. Camera începe să preia frame cu frame până când utilizatorul oprește aplicația
sau pe baza unui parametru de intrare, se a tinge numărul maxim de frame -uri ce
urmează să fie captate.
6. Convertire frame in greyscale [cap 3.1.2]

63
7. Stabilire limite ale perimetrului de detecție
8. Detecție fețe fie prin metoda algoritmului cascadat de tip Viola Jones [cap 4.1]
sau prin descriptor de tip HOG [cap 4.2] (în funcție de parametrii de intrare) în
perimetrul delimitat anterior
9. Detecție zâmbet în regiunea unde a fost găsită o față pe baza aceluiaș i algoritm
Viola Jones însă apelat cu alte date de intrare
10. Detecție persoane prin detecția miș cărilor /diferențelor între 2 frame -uri
consecutive prin metode [cap 3.2] :
a. Extragere de background
b. Extragere de contur
c. Thresholding
11. Afișare , dacă e setat parametrul de afișare, pe display -ul mașinii de calcul a unei
ferestre cu imaginea curentă, de timp real (~5 f ps), căreia i s-au aplicat chenare
de demarcație pentru detecțiile specifice
12. Contorizare și prelucrare valori obținute pentru a putea fi trimise sub formă de
JSON
13. Trimitere frame curent împreună cu rez ultatele obținute către adresa/adresele
web a modululu i 2, la intervale de timp egale, deja specificate de utilizator in
fișierul de configurare sau din linie de comandă.
14. Modulul 2 se va ocupa de preluarea și stocarea datelor într -o bază de date și
afișarea de statistici ale metricilor obținute într-o interfa ță web.
Postcondiții:
La intervale regulate de timp vor fi trimise pachete de date conținând o imagine
(de tip .JPG) și un JSON către modulul 2 al aplicației. JSON -ul trimis este de forma
{număr_fețe : x; număr_zâmbete : y; număr_total_persoane : z; MAC_addr : v;
timp_curent : t;}

6.2.1.2 Inițializare și verificare

Fig 6.2.1.2 .a Schema de inițializare și verificare
Use case: Inițializare și verificare
Descriere: Pornirea și verificarea sistemului în vederea rulării cu succes a aplicației

64
Actori: Mașina de calcul , PiCamera , Conexiunea la internet, Fișier de
configurare sau listă de par ametri dați in linie de comandă, Utilizator (Opțional)
Precondiții: 1. Serviciul „ supervisor ” trebuie să fie instalat și configurat pe mașina
de calcul, însă nu obligatoriu. Se poate porni aplicația și manual în lipsa
serviciului.
Scenariul principal:
1. Pornire mașină de calcul
2. Serviciul „supervisor ” este inițializat automat, iar la rândul său inițializează
aplicația
a. În lipsa serviciului, este necesară intervenția utilizatorului, naviga rea
către directorul aplicației și rularea în terminal a unei comenzi de forma:
„python main.py –cfg 1 –parametru valoare …” [mai multe detalii în
manualul anexat] .
3. Se verifică conexiunea cu PiCamera, conexiunea la internet și se validează
parametrii de configurare (prezența fișierului config.json sau a listei de
parametrii din linie de comandă)
a. În caz că oricare din condițiile de mai sus sunt găsite ca invalide, se
actualizează jurnalul aplicației (fișierul de log) și jurnalul serviciului
„supervisor ”, iar acesta va restarta aplicația dacă e configurat astfel,
altfel aplicația va fi doar oprită.
Postcondiții: 1. Ieșire a sau restartare a aplicație i în caz că etapele de verificare eșuează
2. Captarea și prelucrarea frame -urilor poate să înceapă
Parametr ii aplicației sunt următorii:

Fig 6.2.1.2.b Parametrii din linie de comandă a aplicației

65
Unde:
 Threaded – specifică dacă preluarea frame -urilor de la cameră se va face pe un
thread separat de main sau nu (1- insemnând „da”; parametru de performanță)
 Disp lay – specifică dacă imaginile capturate vor fi afișate sau nu pe display -ul
dispzoitivului (parametru de performanță)
 Benchmark – dacă testul curent va fi doar un test de benchmark, de analizat viteza
de procesare (FPS) a Raspberry -ului în funcție de opți unile de rulare date. Acest
parametru e în legătură cu „frames”.
 Frames – numărul maxim de frame -uri ce vor fi capturate până ce aplicația se va
opri
 Width – rezoluția pe orizontală a pozelor capturate
 Height – rezoluția pe verticală a pozelor capturate
 Cascade – dacă se va folosi un fișier de tipul Haar sau LBP pentru detecția fețelor
 peopleDetector – modul de detecție pentru persoane.
 Interval – intervalul de trimitere a datelor (metodele send_event 0 și 1)
 Config – specifică dacă a fost dat un fișier de configurare de tip JSON sau în linie
de comandă
Acești parametri pot fi proveniți și dintr -un fișier de configurare JSON de forma:

Fig 6.2.1.2.c Parametrii din fișierul de configurare JSON

66
Parametrii ce diferă față de cei din linia de comandă:
 Framerate – posibilitatea de a regla rata de capturare a frame -urilor pe secundă a
camerei (implicit era 30 FPS)
 Detector – pentru față și zâmbet sunt parametrii metodei detectMultiScale ; atât pentru
față și zâmbet cât și pentru regiunea în care se pot detecta perso ane se vor folosi cele 4
linii; motion_area fiind dimensiunea la cv2.ContourArea(contur) prezentat în capitolul
5.2
 Receiver – pot fi configurate mai multe adrese către care se vor trimite datele împreună
cu imaginile.
6.2.1.3 Captare și extragere frame -uri

Fig. 6.2.1.3 .a Schema de captare a frame -urilor
Use case: Extragere frame -uri
Descriere: Extragerea frame -urilor captate de PiCamera atașată
Actori: Mașina de calcul, PiCamera
Precondiții: 1. Etapa de inițializare ș i verificare trecută cu succes
Scenariul principal:
1. Extra gerea frame cu frame a imaginilor captate de PiCamera [cap. 5]
2. Stocarea fiecărui frame într -o structură de date corespunzătoare
3. Convertire frame color în grayscale (alb -negru) [cap. 3.1.2]
Postcondiții:
1. Fiecare frame preluat de la PiCa mera va fi stocat într -o structură de date de tip vector
„numpy” de forma: (rânduri, coloane, culoare), iar apoi va fi convertit în grayscale pentru a
putea fi procesat mai ușor de către algoritmii de detecție.

67
În procesarea secvențială, firul principal se ocupă și de captare și de procesare. Astfel,
pentru a procesa un frame se așteaptă după operațiile de I/O necesare la nivelul camerei dând
astfel o latență globală a întregii procesări.
Din motive de performanță, am decis să exploatez procesarea multif ir (multi -threaded)
în preluarea frame -urilor. Astfel, secvenț a de cod ce se ocupă cu preluarea frame -urilor de la
PiCamera a fost mutat pe un fir (thread) separat d e cel al programului principal.
În capitolul 7 vor fi prezentate valorile obținute în caz ul ambelor abordări.

Fig. 6.2.1.3.b Schema logică de captare a unui frame
Mașina de calcul inițializează PiCamera și firul secundar, ce la rândul lui va începe să
capteze frame -uri cu o rată de FPS (frames per second) între 1 și 90 fps în funcție de lim itările
hardware ale camerei și a rezoluției imaginii. [cap 5.1.2] . Captarea de frame -uri continua până
când aplicație este oprită sau firul este terminat de către sistemul de operare sau de către
procesul părinte (main) din motive de excepții critice apăr ute.
Mașina de calcul va prelua frame -ul curent captat și salvat sub formă de vector numpy
și îl va procesa, aplicâ ndu-i-se algoritmii de de tecție prezentați anterior [cap 4]. De îndată ce
un frame a fost terminat de procesat, firul principal va prelua un alt frame curent memorat de
către firul secundar și procesul se repetă până când aplicația este oprită fie voluntar din cauza
unor excepții tratate fie involuntar de către sistemul de operare în cazul excepțiilor netratate și
critice (cameră deconectată).
Se poate observa că firul secundar suprascrie mereu variabila frame -ului curent cu cel
mai recent frame capturat, fapt ce duce la pierderea unor frame -uri întrucât procesarea de
frame -uri este mult mai lentă decât capt area de frame -uri. Însă, acest lucru nu afectează
acuratețea detecției deoarece ființa umană poate fi considerată o entitate lentă în comparație cu

68
viteza de procesare a unui sistem de calcul. O persoană se deplasează, în medie, pe jos, cu o
viteză de 1,4 m/s, în timp ce viteza de procesare a sistemului atinge și cote de 15 -20 frame -uri
pe secundă. Fapt ce anulează această problemă de pierdere a frame -urilor.
Exemplu

Fig. 6.2.1.3.c Exemplu ilustrativ -pierdere frame -uri
6.2.1.4 Benchmarking – FPS

Fig 6.2.1.4 Schema benchmarking use case
Use c ase: FPS benchmarking
Descriere: Analiza numărului de frame -uri procesate pe secundă în funcție de
diferitele abordări ale algoritmilor de detecție și a abordării simplu/multi -fir.
Actori: Mașina de calcul, PiCamera, Conexiunea la internet
Precondiții: 1. Et apa de inițializare și verificare trecută cu succes
2. Pornirea aplicației având parametrul –benchmarking setat pe 1

69
3. Setarea din parametri a unui număr maxim de frame -uri de capturat
pentru fiecare simulare în parte.
Scenariul principal:
1. Aplicația este pornită în modul benchmark
2. Până se atinge limita de frame -uri de procesat pe fiecare caz in parte se v or executa
secvențial simulări bazate pe combinațiile următoare :
a. Un singur fir de procesare / fir separat pentru preluare de frame -uri + firul
princ ipal
b. Opțiune de redare pe display a capturii / fără afișaj
c. Detecție fețe pe baza fișierului de intrare de tip haar_cascade / LBP_cascade
d. Detecție persoană pe baza detecției mișcărilor prin una din cele 4 metode:
difer ența dinamică a background -ului/ MOG/ MOG2/ GMG
e. Trimitere de date / fără trimitere de date
3. Afișare valori și actualizare jurnal
Postcondiții:
1. Fișierul benchmark.log trebuie să fie actualizat cu valorile obținute în urma tuturor
simulărilor.
6.2.1.5 Detecție

Fig 6.2.1.5 Schema detecției de persoane, fețe, zâmbet
Use case: Folosirea algoritmilor de detecție
Descriere: Folosirea algoritmilor de detecție în găsirea metricilor legate de audiență

70
Actori: Mașina de calcul
Precondiții: 1. Variabila de tip vector „numpy” trebuie să conțină frame -ul curent
transformat in grayscale , rezultat în urma use case -ului de „captare și extragere de frame –
uri”
Scenariul principal:
1. În funcție de parametrii dați la inițializare, se va extrage din frame -ul curent doar
chenarul cu regiunea de interes (roi – region of interes t). Urmâ nd ca doar această
porțiune din imagine să fie supusă algoritmilor următori.
2. Detectare și contorizare persoană în regiunea de interes prin una din variantele
următoare [cap 3.2.4 și cap 4.2] :
a. Diferenț ă dinamica a background -ului cu extragere de con tururi și thresholding
b. Extragere de background MOG
c. Extragere de background MOG2
d. Extragere de background GMG
e. Descriptor de tip HOG (histogram of oriented gradients)
3. Detectare și contorizare față umană găsită în regiunea de interes rezultată în urma
algoritm ului de detecție Viola -Jones alături de fișierul de antrenament fie de tip
haar_cascade sau de tip LBP_cascade („cascade _frontalface.xml”) , iar noua sau noile
regiuni de interes devin chenarele din imagi ne unde a fost detectată una sau mai multe
fețe. (acțiune luată din motive de optimizare)
4. În noua sau noile regiuni de interes va fi aplicat din nou același algoritm de detecție
Viola -Jones însă având un alt fișier de input („cascade_smile.xml”) pentru detecția
zâmbetelor di n imagine, ce vor fi ș i ele cont orizate la rândul lor .
Postcondiții:
1. Trei variabile de tip contor au să fie actualizate la finalul procesării frame -ului
curent. Cele 3 variabile sunt:
a. Număr fețe detectate
b. Număr zâmbete în cadrul fețelor detectate
c. Număr persoane din imagine
Se poate obse rva că din toate cele 5 metode de detecție a unei persoane dintr -o imagine,
doar una din ele este bazată pe un model matematic și anume: descriptorul HOG. Cu toate
acestea, aproximarea grosieră că o regiune suficient de mare dintr -o imagine găsită ca și
conținând o mișcare, poate fi considerată de fapt mișcarea unei persoane respectiv o persoană,
a fost preferată în defavoarea descriptorului HOG deoarece acesta consum ă resurse
computaționale foarte mari, făcând practic întreaga aplicație inutilizabilă pe un Raspberry Pi 3
Model B.
De asemenea, pentru contorizarea persoanelor s -a folosit și o linie ajutătoare ce are rolul de
a contoriza câte persoane (chenare) intersectează linia respectivă.
Metodele actuale, state of the art , ale detecției de persoane umane , folosesc metoda
descriptorului HOG pe sisteme puternice de calcul par alel precum plăci video dedicate sau pe
plăcuțe de tip nVidia Cuda [24]. În capitolul următor am evaluat performanțele aplicației pe
calculatorul personal fa ță de cele obținute de Raspberry Pi 3 Model B.

71
Schimbarea regiunii/regiunilor de interes a fost de preferat din considerente logice precum:
un zâmbet poate apărea doar în regiunea în care o față a fost găsită. Cu toate acestea, ace astă
observație presupune o încredere mai mare în acuratețea algoritmului de detecție de fețe umane.
Dacă nu se impunea această restricție pentru detecția zâmbetelor, ar fi fost posibil ca într -un
frame, la un moment dat, să existe mai puține fețe detectate decât zâmbete ceea ce a r fi dus la
două posibile explicații: a) algoritmul de detecție a zâmbetelor a detectat fals unele regiuni ca
având zâmbete; b) algoritmul de detecție a fețelor a „ratat” anumite regiuni în care există fețe
umane. Datorită faptului că detecția numărului de fețe ce privesc direct camera, respectiv
anunțul publicitar este de prioritate mai mare decât, câte dintre aceste persoane zâmbesc sau
nu, a fost aleasă această abordare de a căuta zâmbete doar în regiunile cu fețe detectate.

6.2.1.6 Prelucrare rezultate

Fig 6.2.1.6 .a Schema de prelucrare și trimitere rezultate obținute
Use case: Prelucrare și trimitere rezultate
Descriere: Valorile obținute în urma detecției nu pot fi trimise la după fiecare frame
procesat întrucât ar cauza un trafic mult prea ridicat la nive lul rețelei și nu ar putea fi controlat
intervalul dintre 2 astfel de procesări. De aceea se preferă stocarea valorilor în structuri de date
de tip bufere și trimiterea unor valori de tip medie pe un interval de timp definit în parametri.
Pentru acest use case au fost abordate doua variante diferite de prelucrare a datelor
obținute.
Actori: Mașina de calcul, Serverul Linux rezident în „cloud”
Precondiții: Use case -ul „detecție” trecut cu succes. Mai concret, un frame a fost procesat și
valorile obținute în urma algoritmilor de detecție au fost actualizate.
Scenariul principal (varianta 1 – bazată pe medii) :
1. Valorile obținute în urma detecției sunt salvate în structuri de date de tip dicționar
([‘fețe’: int, ‘zâmbete’: int, ‘persoane’: int]. Fiecare grupare d e 3 elemente va reprezenta
valorile obținute în urma procesării unui frame

72
2. La un interval regulat (interval de eșantionare – sampling) , specificat în parametrii de
configurare, aceste valori vor fi însumate și salvate înt r-un nou dicționar ce va conține
într-o intrare informații legate de:
a. Câte frame -uri au avut măcar o față detectată (frames_with_faces)
b. Câte frame -uri au avut măcar un zâmbet detectat (frames_with_smiles)
c. Câte frame -uri au avut măcar o persoană detectată (frames_with_people)
d. Suma rotunjită a contoarelor fețelor per frames_with_faces
e. Suma rotunjită a contoarelor zâmbetelor per frames_with_smiles
f. Suma rotunjită a contoarelor persoanelor per frames_with_people
g. Numărul de frame -uri procesate
Valorile din dicționarul de la punctul 1 vor fi reseta te la 0.
3. La un alt interval (i nterval de trimitere a datelor)
a. intrările din acest dicționar vor fi însumate și împărțite la acest interval.
Obținând astfel, media eșantionelor într -un interval mai mare, de trim itere a
datelor, iar datele vor fi grupate sub formă de JSON și trimise către toate
adresele date în parametrii de configurare
b. Frame -ul curent este convertit din vector „numpy” în .jpg și va fi trimis către
toate adresele date în parametrii de configurare
Dicționarul de la punctul 2 va avea valorile r esetate la rândul lui.

Fig 6.2.1.6.b model varianta 1 prelucrare și trimitere a datelor
Unde:
 ‘faces’, ‘smiles’, ‘people’ conțin valorile explicate la punctul 3.a
 ‘frames_w_faces’, ‘frames_w_smiles’, ‘frames_w_people’ conțin valorile
precizate în punctul 2
 ‘total_frames’ reprezintă numărul total de frame -uri procesate în intervalul de
trimitere
 ‘current_time’ reprezintă timpul curent (local) de când vor fi trimise datele
 ‘event_type’ este un simplu delimitator între cele 2 variante de trimitere a
datelor, pentru ca cele 2 metode să poată lucra independent una de cealaltă
Trebuie menționat că la toate aceste valori se atașează o intrare și pentru
‘MAC_address’ pentru a putea identifica în mod unic de pe ce device au fost trimise datele
respectiv frame -urile respective.

73
Pentru trimiterea unui frame (imagine.jpg), din motive de eficiență (să nu mai fie
necesară adăugarea de informații suplimentare în pachet) , am decis ca fișierul de tip .JPG să
aibă informațiile de identificare direct in nume, astfel:
 MAC -ADDR ESS_TIMP -CURENT.jpg (aa:bb:cc:dd:ee:ff_YYYY -MM -DD h -m-
s.jpg)
Modelul matematic utilizat în realizarea acestei variante de prelucrare a va lorilor
obținute este următorul:

Formula 6.2.1.6 Număr mediu de detecții
Unde :
o N – intervalul de trimitere către s erver a datelor colectate ; numărul de eșantioane
de trimis
o S – numărul de frame -uri captate într -un interval de eșantionare
o 𝑥𝑗 – număr detecții din frame -ul j
o 𝑓𝑖 – număr de frame -uri ce conțin măcar o detecție din intervalul curent de
eșantionare
o [ ] – partea întreagă rezultată în urma rotunjirii în sus a valorii
Exemplu :
Fie intervalul inițial de trimitere N = 5 secunde cu intervalul de eșantionare n = 1
secundă. La o procesare de 10 frame -uri pe secundă, cu următoarele date de test :
𝑥0= [0 1 1 2 2 1 1 0 1 2] => 𝑓0=8 ; realitate: 2 persoane ce se apropie
𝑥1= [2 2 1 2 2 1 1 2 2 2]=> 𝑓1=10 ; realitate: 2 persoane
𝑥2= [2 2 2 3 3 2 2 2 3 3]=> 𝑓2=10 ; realitate:3 -> aceleași 2 persoane + încă una
𝑥3= [3 1 1 2 3 2 1 2 1 2]=> 𝑓3=10 ; realitate: 3 persoane
𝑥4= [2 2 1 2 2 3 2 3 3 3]=> 𝑓4=10 ; realitate: 3 persoane
𝑥5= [3 3 2 2 1 2 1 0 2 1]=> 𝑓5=9 ; realitate: 3 persoane; una din ele este aproape de ieșirea
din cadrul camerei
𝑥6= [2 1 1 2 0 2 2 1 2 2]=> 𝑓6=9 ; realitate: 2 persoane
𝑥7= [1 1 0 1 2 1 2 1 2 2]=> 𝑓7=9 ; realitate 2 persoane
𝑥8= [2 1 1 1 0 1 0 1 0 0]=> 𝑓8=6 ; realitate 2 persoane, una fiind mai aproape de ieșirea
din cadru decât cealaltă
𝑥9= [1 1 0 0 0 0 0 0 0 0]=> 𝑓9=2 ; realitate o persoană ce tocmai ieșea din cadrul camerei
𝑁𝑟. 𝑚𝑒𝑑𝑖𝑢 𝑑𝑒 𝑑𝑒𝑡𝑒𝑐ț𝑖𝑖=
[ ∑[∑𝑥𝑗𝑆
𝑗=1
𝑓𝑖]𝑁
𝑖=1
𝑁
]

74
Fiecare element al unui vector x reprezintă numărul de detecții dintr -un frame. Numărul
de elemente al unui vector x reprezintă numărul de frame -uri procesate în intervalul de
eșantionare n = 1 s ecundă.
Numărul mediu de detecții, calculat cu formula 6.1.2.6 este:
𝑦1=[∑[∑𝑥𝑗10
𝑗=1
𝑓𝑖]5
𝑖=1
5]=[[11
8]+[17
10]+[24
10]+[18
10]+[23
10]
5]= [2+2+3+2+3
5]= [12
5]=3
𝑦2= [[17
9]+[15
9]+[13
9]+[7
6]+[2
2]
5]=[2+2+2+2+1
5]= [9
5]=2
Pe primul interval de 5 secunde, media va da de 3 persoane, ceea ce e un rezultat destul
de aproape de adevăr întrucât din 5 secunde, 2 au fost cu 2 persoane, 3 au fost cu 3 persoane.
Pe al 2 lea interval de 5 secunde, media de 2 persoane este iarăși apropiată de adevăr (o
secundă – 3 persoane, 3 secunde – 2 persoane, 1 secundă – o persoană).
Dacă creștem intervalul de trimitere N la 10 secunde se obține:
𝑦3=
[ ∑[∑𝑥𝑗10
𝑗=1
𝑓𝑖]10
𝑖=1
10
]
=[[11
8]+[17
10]+[24
10]+[18
10]+[23
10]+[17
9]+[15
9]+[13
9]+[7
6]+[2
2]
10]
= [2+2+3+2+3+2+2+2+2+1
10]=[21
10]=3

Problema ce se pune în continuare este legată de domeniul de „logică fuzzy”: în
intervalul de 10 secunde au fost 3 sau 2 persoa ne în cadru? Intuitiv, am zice că au fost 3
(numărul maxim) însă, consider că o abordare mai potrivită ar fi una de tip fuzzy: 40% din timp
(4/10) au fost trei persoane, iar 50% (5/10) din timp au fost doar două. Din motive de creștere
a complexității ce d uce la creșterea puterii de calcul, această abordare fuzzy nu a fost
implementată în aplicație, rămânând la latitudinea utilizatorului de a găsii intervalele de
trimitere respectiv de eșantionare cele mai potrivite.

O simplă abordare de genul medie aritme tică ar da următorul rezultat:
𝑦= [11+17+24+18+23+17+15+13+7+2
10]= [147
10]=15
E clar că e departe de realitate.

A fost nevoie de un astfel de model matematic datorită următoarei probleme majore:
 Cum poate fi identificată o persoană ca fiind aceeași în două frame -uri
consecutive? Neavând nicio legătură între două frame -uri a unui chenar detectat ca

75
fiind o persoană, nu se putea spune dacă persoana respectivă este aceeași în ambele
frame -uri. Astfel, s -a recurs la aflarea valorilor medii.

Scen ariul principal (varianta 2 – bazată pe modificări de valori: creșteri/descreșteri):
1. Valorile obținute în urma detecției sunt salvate în structuri de date de tip dicționar
([‘fețe’: int, ‘zâmbete’: int, ‘persoane’: int]. Fiecare grupare de 3 elemente va
reprezenta valorile obținute în urma procesării unui frame
2. La un interval regulat (interval de eșantionare – sampling), specificat în parametrii
de configurare, aceste valori vor fi parcurse și salvate , în noi variabile de tip contor ,
câte oscil ații există î ntre aceste valori. Mai exact:
a. De câte ori se schimbă monotonia șirului (valori constante urmate de o
creștere a următoarei valori parcurse)
3. Se calculează media aritmetică rotunjită în sus a acestor valori
4. La un alt interval, de trimitere a datelor, acest e contoare vor fi împachetate sub
formă de dicționar de tip JSON (Figura 6.2.1.6.c).

Fig 6.2.1.6.c Model varianta 2 prelucrare și trimitere a datelor
Din motive de compatibilitate cu modulul 2 al aplicației, se păstrează același format
pentru trimiterea datelor, diferind doar tipul evenimentului: event_type = 1.
Exemplu:
Păstrăm valorile și notațiile de la exemplul de mai sus, din varianta 1.
𝑥0= [0 1 1 2 2 1 1 0 1 2] => 𝑐0= [0 1 1 2 2 2 2 2 2 2](evoluția în timp a valorii lui 𝑐0)
=>𝑐0=2 realitate: 2
𝑥1= [2 2 1 2 2 1 1 2 2 2]=>𝑐1=[0 0 0 1 1 1 1 2 2 2]=> 𝑐1=2 realitate: 2
𝑥2= [2 2 2 3 3 2 2 2 3 3]=>𝑐2=[0 0 0 1 1 1 1 1 2 2]=> 𝑐2=2 realitate: 3
𝑥3= [3 1 1 2 3 2 1 2 1 2] =>𝑐3=[0 0 0 1 2 2 2 3 3 4]=> 𝑐3=4 realitate: 3
𝑥4= [2 2 1 2 2 3 2 3 3 3] =>𝑐4=[0 0 0 1 1 2 2 3 3 3]=> 𝑐4=3 realitate: 3
𝑥5= [3 3 2 2 1 2 1 0 2 1] =>𝑐5=[0 0 0 0 0 1 1 1 2 2]=> 𝑐5=2 realitate: 3
𝑥6= [2 1 1 2 0 2 2 1 2 2]=>𝑐6=[0 0 0 1 1 2 2 2 3 3]=> 𝑐6=3 realitate: 2
𝑥7= [1 1 0 1 2 1 2 1 2 2] =>𝑐7=[0 0 0 1 1 1 2 2 3 3]=> 𝑐7=3 realitate: 2

76
𝑥8= [2 1 1 1 0 1 0 1 0 0] =>𝑐8=[0 0 0 0 0 1 1 2 2 2]=> 𝑐8=2 realitate: 2
𝑥9= [1 1 0 0 0 0 0 0 0 0] =>𝑐9=[0 0 0 0 0 0 0 0 0 0]=> 𝑐9=0 realitate: 1
𝑦1= [∑𝑐𝑖5
𝑖=1
5]= [2+2+2+4+3
5]= [13
5]=3
𝑦2= [∑𝑐𝑖5
𝑖=1
5]= [2+3+3+2+0
5]= [10
5]=2
Se observă că se obțin rezultate similare pe acest caz, chiar dacă la nivel de secundă,
această metodă nu are acuratețe pre a mare.

Postcondiții:
Cele două variante de prelucrare a datelor lucrează concomitent și independent una de
cealaltă. Ele fiind implementate fiecare pe câte un fir (thread) separat. Astfel, la intervalul de
trimitere, ambele fire vor trimite către modulul 2 al aplicației eveniment ul specific lor.
După cum se poate observa și în figura de mai jos (6.2.1.6.d), firul principal de execuție
(procesare) este responsabil cu crearea a două alte fire secundare de tip „ daemon ”. Un proces
(fir) de tip daemon este ter minat (sfârșit) automat în momentul în care procesul principal (main)
este terminat. Dacă cele 2 fire nu erau de tip daemon ar fi fost necesară supravegherea și
încheierea acestora în momentul închiderii aplicației (firului principal). Ambele fire secundar e
folosesc aceleași valori pentru intervalele de eșantionare și respectiv de trimitere a datelor.
Datorită secvențialității din crearea celor 2 fire secundare: întâi este creat evenimentul
0, iar apoi evenimentul 1, cele două fire secundare nu vor ajunge n iciodată să blocheze
(conflict) partea de rețea (trimitere) a datelor, deși au aceleași valori pentru eșantionare,
respectiv trimitere.
Funcția de „Așteaptă” a fost realizată prin intermediul unui „sleep” al firului de durata
intervalului de eșantionare. Astfel, după fiecare sleep, firul respectiv își va actualiza valorile
din structuri conform celor două scenarii prezentate anterior.

77

Fig. 6.2.1.6.d Schema firelor de execuție a evenimentelor de trimitere și actualizare a
datelor
Metoda de trimitere a da telor sub formă de JSON este următoarea:

Fig. 6.2.1.6.e Metoda de trimitere a datelor sub formă de json
Ca și explicații date în ajutorul snippet -ului de mai sus:
 Parametrii metodei:

78
o self – este identic cu parametrul „this” din alte medii de programare, cu
excepția că, în Python, nu există acest parametru ascuns implicit. Primul
parametru al oricărei metode devine referința obiectului curent.
o Data – reprezintă dicționarul obținut în urma parcurgerii unuia dintre cele 2
scenarii prezentate anterior. (fig 6 .2.1.6.b & c) . La acest dicționar urmând
să fie adăugată și valoarea MAC adresei.
 Pentru fiecare adresă (url) dată în fișierul de configurare se vor executa următorii
pași:
o Se instanțială un obiect de tipul „Request” din biblioteca „urllib” importată
în Py thon
o Se setează headerul corespunzător unei conexiuni de tip HTTP
o Cele 2 metode apelate (dumps & encode) din cadrul librăriei „json”
importate, au rolul de a:
 Converti dicționarul nativ din Python în format JSON
 Codifica datele sub standardul „UTF -8”
o Se de schide conexiunea și se trimit datele prin intermediul metodei clasei
request – „urlopen” ce primește ca și parametrii un obiect de tipul „Request”
instanțiat mai devreme și un al doilea parametru ce conține datele codificate
anterior.
o Pentru a delimita „scope ”-ul variabilei de tip „response” s -a folosit structura
„with…as…”, variabila distrugâdu -se la ieșirea din acel bloc de cod.
Observatie
Structura „try…catch” a fost necesară datorită problemelor ce pot apărea la deschiderea
unei conexiuni (lipsa conexi unii la internet) sau în timpul trimiterii datelor (exceptie de tip
„HTTPError” – pentru orice status diferit de cel de succes 200). În lipsa blocului „try…catch”,
întreaga aplicație ar fi fost oprită de către sistemul de operare datorită unei excepții apă rute si
netratate.
În momentul actual, în cazul unei excepții apărute la trimiterea datelor, acestea sunt pur
și simplu ignorate rezultând în pierderea datelor. Ca și dezvoltări ulterioare , trebuie găsită o
metodă de salvare a datelor într -un buffer până când acestea pot fi trimise cu succes.
Metoda trimiterii de frame -uri a fost detaliată în capitolul 2.3.3.

79
6.3 Structura aplicației

Fig 6.3 Structura pe directoare a aplicației
 conf.json – fișierul de configurare (de tip text – json) prezentat în subcapitol ele
anterioare
 main.py – fișierul ce gestionează restul fișierelor, acesta fiind principalul punct de
intrare în aplicație
 multi_threaded.py / single_threaded.py – fișiere ce conțin „engine” -ul (motorul)
întregii aplicații. În funcție de parametrii de co nfigurare va fi inclus și executat ,de către
main, unul dintre aceste două fișiere
 directorul „cascades” conține fișierele de intrare necesare algoritmilor de detecție de
față și de zâmbet
 în direct orul „includes” se găsesc clasele sau simple metode folos ite de aplicație.

80
6.4 Diagrama UML

Fig. 6.4 Diagrama UML a aplicației

81
6.5 Schema bloc a algoritmului

Fig 6.5 Schema bloc a algoritmului
În schema de mai sus pot fi observate cele patru fire ale aplicației:
 Main – se ocupă cu inițializarea celorlalte fire și instanțierea claselor folosite
 VideoStream – se ocupă cu preluarea continuă a frame -urilor de la PiCamera
 SendEvent_0 și SendEvent_1 cele două fire ce lucrează independent, pe aceleași date
brute (primite de la detector) însă pe prelucrări diferite ale ac estor date

82
Intervalul de eșantionare fiind prestabilit la o secundă, cel de trimitere fiind configurabil.

6.6 Fazele premergătoare aplicației finale
Aplicația a fost dezvoltată în mai multe faze sau etape:
1. Setarea mediului
a. Instalarea sistemului de operare Ra spbian
b. Setarea unui mediu virtual pentru Python
c. Compilarea bibliotecii OpenCV
2. Detecția fețelor umane
a. Pe baza unor poze statice
b. Pe baza unei secvențe video în timp real
c. Evaluarea diferitelor abordări posibile pentru găsirea parametrilor optimi
pentru o acur atețe cât mai mare a detecției, dar și a unei pr ocesări numerice
cât mai scăzute .
3. Detecția zâmbetelor
a. Adăugarea la algoritmul anterior și a detecției de zâmbete
b. Evaluarea noilor performanțe obținute și găsirea unui optim al parametrilor
4. Detecția unei într egi persoane
a. Evaluarea diferitelor abordări posibile și a performanțelor pentru detecția
dintr -o secvență video în timp real.
b. Integrarea noului algoritm în aplicație
c. Evaluarea performanțelor de după integrare și găsirea unui optim
5. Algoritmi de numărare a detecțiilor într-un interval de timp prestabilit
6. Trimiterea datelor către server
a. Crearea unui sistem de test online pentru recepționarea datelor
b. Trimiterea datelor sub formă de JSON
c. Trimiterea imaginilor de tip jpg/png
d. Integrarea modulului de trimitere a da telor cu întreaga aplicație
e. Evaluarea performanțelor cu noua funcționalitate
7. Rezolvarea problemelor/excepțiilor ulterior apărute în trimiterea datelor
8. Instalarea serviciului „ supervisor ” pentru ca aplicația să pornească ca și serviciu
9. Interfața utilizatoru lui (modulul 2)

83
6.7 Probleme întâmpinate și soluții propuse
1. Temperatura – supraîncălzirea plăcuței
a. Problema a apărut după integrarea în aplicație și a detecției de persoane
(detecția mișcării), temperatura crescând de la ~700 Celsius până la valori
apropiate de 950 C după aproximativ 2 ore de rulare continuă.
b. Soluții:
i. HeatSink
ii. Cooler
iii. Reducerea frecvenței procesorului ARM
iv. Optimizări la nivel software
Primele două soluții au ieșit din calcul deoarece exista deja o carcasă ce nu putea
fi modifcată cu ușurință. Ultimele două fiind soluțiile adoptate în lucrarea curentă.
Optimizările de la nivelul codului precum :
 înlocuirea împărț irilor la 2 cu shiftări pe biți
 mutarea în var iabile și definirea lor î n afara buclelor de program a
calculelor ari tmetice dintre val ori constante
 restructurarea anumitor metode de detecție să acționeze doar pe o
anumită porțiune din imagine
 împreună cu reducerea frecvenței de procesare de la 1200 MHz la
1000 MHz au determinat o scădere a temperaturii cu 100 C, ducând
temperatura la valor i maxime acceptabile pentru Raspberry Pi.

Fig 6.7.1 Utilizarea CPU și a memoriei

Fig 6.7.2 Temperatura CPU și GPU
Cele două figuri de mai sus arată temperatura maximă la care s -a stabilizat
Raspberry -ul chiar și după aproape două zile de rulare con tinuă a întregii aplicații
(detecție + trimitere de date).

2. Excepții de tip HTTP
a. Problemă: În cazul pierderii co nexiunii la internet, bibliotecile „Urllib” și
„Requests” ar fi aruncat excepții netratate de aplicație . Algoritmul de detecție

84
continuând să funcționeze însă, chiar dacă s -ar fi restabilit conexiunea la
internet, modulul rețea al aplicației ar fi rămas în aceeași stare de excepție.
b. Soluție: Prinderea și tratarea excepțiilor respective. Aplicația actuală
„prinde” aceste excepții apărute, le tipărește și trece mai departe. La reluarea
conexiunii, trimiterea datelor se reia. Datele ce nu au putut fi trimise în
intervalul respectiv sunt pierdute. Această problemă rămânând d e
implementat în versiunile următoare.
Trebuie precizat că doar simpla prindere a e xcepțiilor nu a fost de ajuns în
cazul trimiterii de imagini, dearece rămânea deschisă conexiunea și în ciuda
revenirii conexiunii, imaginile tot nu ar fi fost trimise. Soluție: pe blocul
„catch” după afișarea erorii s -a inchis conexiunea. (vezi capitolul 2.3.3).

85
Capitolul 7. Rezultate și concluzii
7.1 Testarea aplicației pe Raspberry Pi 3 Model B
În cele ce urmează vor fi prezentate rezultatele privind performanța (rata de procesare)
obținute în diferite etape ale aplicației. Rata de procesare fiind numărul total de frame -uri
împărțit la timpul total de execuție . Având rezoluția implicită de 320 x 240.

Fig 7.1.a Detecție față (Haar) + zâmbet (Haar)

Fig 7.1.b Detecție față (LBP) + zâmbet (Haar)

86
Diferența între single threaded și multi threaded este acee a că pe abordarea multi
threaded, procesul de preluare a frame -urilor de la cameră a fost mutat pe un fir separat
(elimanarea timpului de așteptare după operațiile de I/O ). Se poate observa cum același
timp de I/O afectează performanța și în cazul afișării pe ecran a imaginii captate. Însă, cea mai
mare îmbunătățire este dată de folosirea detectorului bazat pe trăsături LBP în defavoarea celui
de tip Haar.
În cele ce urmează, din motive de performanță evidente, se va folosi varianta cu detecția
fețelor pe baza trăsăturilor LBP, având un fir separat pentru preluarea imaginilor (multi –
threaded) și cu varianta de display .

Fig 7.1.c Detecție față (LBP) + zâmbet (Haar) + colectare și trimitere date către server
Se observă cum are loc o scădere a FPS -ului de aproape 3 frame -uri pe secundă.

Fig 7.1.d Idem 7.1.c + trimitere frame +detecție mișcare prin metoda adaptivă (4)

87
Era de așteptat ca FPS -ul să scadă datorită detecției oamenilor (a mișcărilor). Trimiterea
regulată a unui frame deodată cu datele scade apr oximativ cu ~0.2 frame -uri pe secundă.
Detecția persoanelor prin metoda HOG, făcea aproape imposibilă rularea aplicației pe
Raspberry Pi, obținând rate de procesare sub 0.7 FPS, în timp ce detecția mișcărilor bazată pe
extragerea de background prin MOG, M OG2 sau GMG duceau la performanțe cu 5 până la 8
FPS mai slabe decât cea prin simpla utilizare a variantei adaptive a diferențelor dintre imagini.
Pentru creșterea razei de detecție, rezoluția imaginii a trebuit mărită de la 320×240 la
640×480. Fapt ce a dus la creșterea detecției feței de la ~3 metri până la 6 -7 metri distanță. Însă,
acest fapt a dus la scăderea ratei de procesare până la 2 -3 FPS (limite încă acceptabile datorită
vitezei scăzute de deplasare a unui om ).
Aplicația a fost testată și într -un mediu cu zgomot (lumină), un mediu apropiat unui
magazin, într -un laborator. Chenarul alb fiind zona de acțiune a algoritmilor de detecție.

Fig 7.1.e Testare aplicație într -un mediu cu zgomot

88
Din această imagine putem trage următoarele concluzii :
 Persoanele ce se mișcă în plane diferite (apropiat, depărtat) vor fi văzute doar ca una
singură
 Algoritmul de detecție a feței funcționează doar pe fețe suprinse frontal
 Detecția zâmbetelor depinde de detecția fețelor
7.2 Testarea aplicației pe calculatorul per sonal
Aplicația a fost testată și pe calculatorul personal, unde s -au obținut următoarele
performanțe (rezoluție implicită 320 x 240) :

Fig 7.2.a Detecție față (LBP) + zâmbet (Haar) + colectare și trimitere date către
server
Performanțele obținute de proc esorul calculatorului (i7 6700k @ 4GHz) sunt de mai
mult de 3 ori mai bune decât cele obținute de procesorul Raspberry -ului (1,2 GHz Arm).
Detecția mișcărilor (metoda 4) scade și aici tot cu aproximativ 2 frame -uri rata de
procesare. Curios este faptul ca metoda 0 (descriptorul HOG) scade de 3 ori rata de procesare.

Fig 7.2.b Detecție față (LBP) + zâmbet (Haar) + colectare și trimitere date către
server + trimitere frame -uri + detecție pieton HOG

89
7.3 Concluzii
Deși ar putea părea nepractică ideea de a conside ra o regiune din imagine, în care s -a
detectat o mișcare, ca fiind o persoană, această presupunere duce la rezultate mulțumitoare atât
pe plan de acuratețe cât și pe plan al performanțelor Raspberry -ului, mai exact a limitărilor
hardware ale acestuia.
De amintit faptul c ă metodele actuale state -of-the-art, folosesc pentru detecția
pietonilor, metode bazate pe descriptor de tip HOG, însă pe mașini de calcul puternice (plăci
grafice, nVidia CUDA etc).
Aplicația este momentan implementată în câteva magazine din Portugalia. Ar fi
trebuit integrată și în magazinele de la noi, însă din motive de legislație (nu permite legea
filmarea persoanelor fără acordul lor) nu s -a putut. Chiar dacă aplicația dezvoltată nu reține
imaginile, ele fiind suprascrise la fiecare n ouă procesare. Același lucru se întâmplă și cu
imaginile trimise. Acestea vor fi suprascrise la fiecare nouă primire.
În final, se poate spune că am atins toate obiectivele principale stabilite inițial. Cel mai
mare obstacol fiind dat de limitările hardwa re ale Raspberry -ului. Rata de procesare scăzută
(de sub 3 FPS) nu afectează totuși acuratețea detecțiilor la o distanță rezonabilă (sub 7 metri).
Pentru a mării această rază a detecției trebuie mărită atât rezoluția imaginii cât și ajustarea
parametrilor detecției prezentați în capitolul 4.
În viitor, trebuie găsită o soluție cu un fundament matematic mai solid pentru detecția
persoanelor (cum ar fi descriptorul HOG) însă acest lu cru ar implica schimbarea dis pozitivului
hardware folos it (renunțarea la Raspb erry Pi), poate chiar o abordare de procesare pe plăci
grafice.

90
Anexa 1
Manual de utilizare
-Raspberry Pi 3-
8.1 Compilare OpenCV 3
Se presupune că pe Raspberry Pi a fost instalată o copie nouă a sistemului de operare
Raspbian Jessie. Pașii necesari pentru compilarea librăriei sunt următorii:
1. Expandarea sistemului de fișiere pentru a include tot spațiul posibil de pe cardul
micro -SD
a. $ sudo raspi -config

Fig 8.1 .a Rasp -config
b. 1.Expand File System – Enter – <Finish> – $ sudo reboot
c. $ df –h Verificare dacă s pațiul pe disk s -a mărit prin

Fig 8.1.b Spațiul pe disk
d. $ sudo apt -get purge wolfram -engine Ștergerea aplicației nefolositoare nouă
„Wolfram engine” pentru mărirea spațiului
2. Instalarea dependețelor
a. $ sudo apt -get update & $ sudo apt -get upgrade
b. $ sudo apt-get install build -essential cmake pkg -config Instalare Cmake
pentru compilarea librăriei OpenCV
c. $ sudo apt -get install libjpeg -dev libtiff5 -dev libjasper -dev libpng12 -dev
Instalarea unor pachete I/O pentru imagini ce permit încărcarea diferitelor
forma te ale imaginilor pe disk (JPEG, PNG, TIFF etc).
d. $ sudo apt -get install libavcodec -dev libavformat -dev libswscale -dev lib4vl –
dev & $ sudo apt -get install libxvidcore -dev libx264 -dev Instalarea unor
pachete video I/O pentru lucrul direct cu fluxuri video

91
e. $ sudo apt -get install libgtk2.0 -dev OpenCV vine cu un sub -modul numit
highgui ce realizează funcții de display și GUI. Pentru instalarea acestuia
trebuie instalată librăria GTK
f. $ sudo apt -get install libatlas -base-dev gfortran Multe operații din OpenCV
(operații pe matrici) pot fi optimizate folosind câteva extra dependențe.
g. $ sudo apt -get install python3 -dev Instalare Python 3 .4 (Jessie vine cu 2.7)
3. Descărcarea codului sursă OpenCV
a. Descărcare și dezarhivare OpenCV 3.1.0

Fig 8.1.c Descărcare și dezarhivar e OpenCV 3.10
b. Descărcare și dezarhivare OpenCV_contrib pentru instalarea completă a
librăriei

Fig 8.1.d Descărcare și dezarhivare OpenCV_contrib
4. Python3 PIP
a. Instalare pachet PIP

Fig 8.1.e Instalare pachet PIP
b. Instalarea virtualenv și virtualenwrapper

Fig 8.1.f Instalare virtualenv și virtualenwrapper
c. Modificare ~/.profile să includă următoarele linii la finalul fișierului:

Fig 8.1.g Configurare ~/.profile
d. $ source ~/.profile Activarea fișierului modificat
e. $ mkvirtualenv cv –p python3 Crearea unui me diu virtual pentru Python3
numit „cv”
f. Folosirea mediului virtual creat

Fig 8.1.h Folosirea mediului virtual „cv”
g. $ pip install numpy Instalarea librăriei NumPY
5. Compilarea și instalarea OpenCV
a. Build -uirea folosind Cmake

Fig 8.1.i Parametri pentru compil area OpenCV folosind CMake

92
b. $ make –j4 Compilarea
c. Instalarea

Fig 8.1.j Instalarea librăriei compilate OpenCV
6. Pașii finali în instalare
a. Redenumirea fișierului cv2.cpython -34m.so la cv2.so pentru creearea ușoară
a unui sy m-link.

Fig 8.1.k Redenumirea fiși erului de output în urma instalării OpenCV
b. Crearea unui sym -link pentru mediul virtual

Fig 8.1.l Crearea unui sym -link pentru mediul virtual „cv”
7. Testarea instalării cu succes
a. Comenzile următoare ar trebui să dea același output:

Fig 8.1.m Instalarea cu succes a OpenCV
Instalarea librăriei „requests” Python adițională:
 $ pip install requests

8.2 Instalarea serviciului „ supervisor ”
Instalarea via PIP:
o $ pip install supervisor
Creearea fișierului de configurare:
o echo_supervisord_conf > /etc/supervisord.conf
Singurele modificări aduse acestui fișier sunt prezentate în fig 8.2. Pentru parametrul :
command, au fost necesare două căi, una pentru mediul virtual Python creat anterior, cealaltă
pentru aplicația propriu -zisă

93

Fig 8.2 Fișierul de supervisord.conf

94
Bibliografie

[1] Work Plan of Computer Vision Algorithm for People Counting System
[2] „Wikipedia – Raspberry Pi,” https://en.wikipedia.org/wiki/Raspberry_Pi.
[3] „Raspberry Pi 3 Comparison ” https://www.peterdavehello.org/2016/02/raspberry -pi-3-
out-what -is-the-difference -a-simple -comparison -chart -and-some -references/.
[4] „„Raspberry Pi 3” https://www.raspberrypi.org/blog/raspberry -pi-3-on-sale/.
[5] „„Raspberry Pi 3 vs Pi 2 power consumtion” http://raspi.tv/2016/how -much -power –
does-raspberry -pi3b-use-how-fast-is-it-compared -to-pi2b.
[6] „Raspberry Pi performance comparisons” http://raspi.tv/2015/raspberry -pi2-power -and-
performance -measurement.
[7] HiPEAC Vision 2017 https://www.h ipeac.net/v17.
[8] „RFC7159 JSON,” https://tools.ietf.org/html/rfc7159.html.
[9] „Royal Instituion” https://en.wikipedia.org/wiki/Royal_Institution.
[10 „First Color Photograph” http://www.historyofinformation.com/expanded.php?id=4122.
[11 „An Improved Adaptive Background Mixture Model for Realtime Tracking with
Shadow Detection ” „In Proc. 2nd European Workshop on Advanced Video Based
Surveillance Systems, AVBS01. Sept 2001. VIDEO BASED SURVEILLANCE
SYSTEMS: Computer Vision and Distributed Pr ocessing, Kluwer Academic Publishers ”
P. KaewTraKulPong and R. Bowden
http://www.ee.surrey.ac.uk/CVSSP/Publications/papers/KaewTraKulPong –
AVBS01.pdf.
[12 „Improved Adaptive Gaussian Mixture Model for Background Subtraction ” In
Proc.ICPR,2004 Zoran Zivkovic
http://www.zoranz.net/Publica tions/zivkovic2004ICPR.pdf.
[13 „Efficient adaptive densi ty estimation per image pixel for the task of background
subtraction ” Zoran Zivkovic http://www.zoranz.net/Publications/zivkovicPRL2006.pdf.
[14 „Visual Tracking of Human Visitors under Variable -Lighting Conditions for a
Responsive Audio Art Installation ” Andrew B. Godbehere, Akihiro Matsukawa, Ken
Goldberg http://goldberg.berkeley.edu/pubs/acc -2012 -visual -tracking -final.pdf.
[15 „Python OpenCV tutorials ” http:/ /opencv -python –
tutroals.readthedocs.io/en/latest/py_tutorials/py_video/py_bg_subtraction/py_bg_subtrac
tion.html.

95
[16 „Robust Real -Time Face Detection ” International Journal of Computer Vision 57(2),
137–154, 2004
PAUL VIOLA Microsoft Researc h, One Microsoft Way, Redmond, WA 98052, USA
MICHAEL J. JONES Mitsubishi Electric Research Laboratory, 201 Broadway,
Cambridge, MA 02139, USA
http://www.vision.caltech.edu/html -files/EE148 -2005 -Spring/pprs/viola04ijcv.pdf.
[17 „Viola -Jones framework ”
https://en.wikipedia.org/wiki/Viola%E2%80%93Jones_object_detection_framework.
[18 „OpenCV docume ntation”
http://docs.opencv.org/2.4/modules/objdetect/doc/cascade_classification.html.
[19 „OpenCV d ocumentation ” Ahonen, T., Hadid, A., and Pietikainen, M. Face Recognition
with Local Bin ary Patterns. Computer Vision – ECCV 2004 (2004), 469 –
481http://docs .opencv.org/2.4/modules/contrib/doc/facerec/facerec_tutorial.html.
[20 „OpenCV d ocumentation ”
http://docs.opencv.org/2.4/modules/contrib/doc/facerec/facerec_tutorial.html.
[21 „Histograms of Oriented Gradients for Human Detection ” Navneet Dalal and Bill Triggs
INRIA Rhone -Alps, ˆ 655 avenue de l’Europe, Montbonnot 38334, France
http://lear.inrialpes.fr/people/triggs/pubs/Dal al-cvpr05.pdf.
[22 „Learn OpenCV ” http://www.learnopencv.com/histogram -of-oriented -gradients/.
[23 „Supervisord” http://supervisord.org/.
[24 „nVidia Cuda ” http://www.nvidia.com/object/cuda_home_new.html.
[25 „Requests tutorial ” http://www.pythonforbeginners.com/requests/using -requests -in-
python.
[26 „Urrlib docume ntation ” https://docs.python.org/3/library/urllib.html.
[27 „NumPy documentation ” https://docs.scipy.org/doc/numpy -dev/about.html.
[28
] „Python documentation ” https://www.python.org/doc/essays/blurb/.
„Practical Python and OpenCV: An Introductory, Example Driven Guide to Image
Processing and Computer Vision 2nd Edition ” Adrian Ros ebrok

„Procesarea imaginilor și elemente de computer vision ” – Editura Universității „Lucian
Blaga”, S ibiu 2003, ISBN 973 -651-739-x Remus Brad