Hog processing
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,157
On Slideshare
2,157
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
74
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. FACOLTA Dr INGEGNERIA - DIPARTIMENTO Dr SISTEMI E INFORMATICA Elaborato di Progettazione e Produzione Multimediale HOG-Processing: A library for Pedestrian Detection Elaborato di: Coordinatori: Alessio Anzivino Dr. Walter Nunziati Matteo Spampani PhD Lorenzo Seidenari ANNO ACCADEMICO 2009/2010
  • 2. Indice 1 Introduzione 3 2 Descrizione del metodo 5 2.1 Computazione dei gradienti 6 2.2 Costruzione degli istogrammi 8 2.3 Normalizzazione dei blocchi 9 2.4 Costruzione dei descrittori (Detection window) . 11 2.5 Classificatore SVM .... 12 2.6 Miglioramento prestazioni 13 2.6.1 Mean-shift . . . . . 14 3 Architettura dell'implementazione 19 3.1 Ambiente di sviluppo 19 3.2 Modello UML . . . . 20 3.3 Descrizione delle classi 22 3.4 Utilizzo della libreria 31 1
  • 3. INDICE 2 4 Test 35 5 Sviluppi futuri 42 Bibliografia 45
  • 4. Capitolo 1 Introduzione In questo documento gli autori propongono un' implementazione del metodo HOG (Histogram of Oriented Gradients) [10] per la rilevazione di pedoni all'interno di immagini. Inizialmente il metodo sara analizzato da un punto di vista teorico per poi passare alla descrizione dettagliata dell'implementazione. 11 metodo si basa sulla valutazione di istogrammi calcolati sulla base dell'orientazione dei gra- dienti dell'immagine di input. L'idea e che i margini e Ie forme di oggetti possono essere ben caratterizzati dall'intensita locale dei singoli gradienti. La computazione dei singoli istogrammi e ottenuta dividendo l'immagine in una griglia di celie e per ognuna di esse viene elaborato un istogramma relativo ai gradienti dei singoli pixel. Successivamente Ie celle sono raggruppate in regioni denominate blacchi. Inoltre, per svincolare la risposta dalle condizioni di luminosita dell'immagine, puo essere utile normalizzare i singoli blocchi. Dalle informazioni ricavate dai singoli blocchi si ottiene poi un descrittore che verra utilizzato 3
  • 5. CAPITOLO 1. INTRODUZIONE 4 per la detection. Le precedenti operazioni vengono eseguite su finestre di dimensione finita che analizzano l'im- magine a pili scale. Per ogni finestra si ottiene quindi un descrittore che viene poi passato ad un classificatore SVM lineare che fornisce la predizione sulla presenza 0 meno di un pedone. Essendo Ie procedure di costruzione dei singoli descrittori indipendenti tra loro, e possibile eseguirle contem- poraneamente con una gestione multithread. In questa modo si ottiene un notevole miglioramento delle prestazioni. La robustezza dell'algoritmo utilizzato dall'SVM e l'accurata scansione dell'immagine a pili scale producono spesso un'addensamento di finestre di detection per ogni singolo pedone, quindi e necessaria un'operazione di fusione (mean-shift) [81 che porti all'individuazione di un'unica finestra finale. Il lavoro si conclude con una fase di test in cui verranno confrontati i risultati sperimentali con quelli della letteratura esistente.
  • 6. Capitola 2 Descrizione del metoda In questo capitolo andremo ad analizzare la nostra implementazione del metodo HOG ponendo particolare attenzione alle fasi principali della procedura. Nel settore del object recognition, l' uso di istogrammi di gradienti orientati e molto popolare [10][13]. In ogni caso, il concetto della computazione di istogrammi locali relativi ai gradienti orientati dell'immagine (HOG) e un metodo introdotto da Dalal et al. [10]. In questo lavoro, al fine di ottenere i descrittori di una singola immagine, sono stati effettuati i seguenti passi di elaborazione: 1. Computazione dei gradienti dell'immagine; 2. Costruzione degli istogrammi; 3. Normalizzazione dei blocchi; 4. Scansione dell'immagine e costruzione dei descrittori; 5. Classificazione dei descrittori tramite SVM lineare; 5
  • 7. Dx = (−1 , 0 , 1) Dy = (−1 , 0 , 1)T I Ix = I ∗ Dx Iy = I ∗ Dy
  • 8. CAPITOLO 2. DESCRIZIONE DEL METODO 7 ￿ 2 2 • magnitudo: | G |= Ix + Iy y I • angola: θ = arctan( Ix ) Un esempio di gradiente e mostrato in figura 2.2. II (a) (b) (c) Figura 2.2: Esempio di applicazione del filtro per l'ottenimento del gradiente dell'immagine. La figura a) mostra l'immagine originale, la figura b) mostra il risultato dell'applicazione del filtro orizzontale e la figura c) mostra il risultato dell'applicazione del filtro verticale. I gradienti possono essere considerati con segno 0 senza segno. Quest'ultimo caso e giustificato dal fatto che la direzione del contrasto non ha importanza. In altre parole, noi avremmo il solito risultato analizzando un oggetto bianco posizionato su uno sfondo nero 0 viceversa un oggetto nero posizionato su sfondo bianco. Nel nostro caso abbiamo considerato gradienti senza segno con valori che vanno da 0 a 11:. Il filtro utilizzato per l' ottenimento dei gradienti e uno dei pili semplici ma anche uno dei pili efficaci; esistono tuttavia altre maschere pili complesse che possono essere utilizzate per ottenere il gradiente dell'immagine da analizzare: uno di questi e il filtro di Sobel. Nel caso di immagini a colori viene inoltre effettuata un'operazione preliminare di conversione a scala di grigi; questa per evitare di dover considerare un contributo di intensita diverso per ogni piano di colore (RGB).
  • 9. [0 , 40 ) [40 , 80 ) [80 , 120 )
  • 10. CAPITOLO 2. DESCRIZIONE DEL METODO 9 di un oggetto e in genere pili significativo di un punto in una regione uniforme dell'immagine. Ci aspettiamo quindi che pili canali ci sono pili dettagliati saranno gli istogrammi (figura 2.3). Quando tutti gli istogrammi sono stati creati, possiamo costruire il descrittore dell'immagine concatenando tutti gli istogrammi in un singolo vettore. In ogni caso, a causa di eventuali variazioni di luminosita nell'immagine e opportuno norma- lizzare Ie celle. La procedura di normalizzazione e descritta nel capitolo successivo. Figura 2.3: La figura mostra un esempio di possibile istogramma calcolato per 4 canali (sinistra), 8 canali (centro) e 16 canali (destra). 2.3 N ormalizzazione dei blocchi Come accennato nella sezione 2.2, prima di creare i descrittori e necessaria una fase di normaliz- zazione, questa a causa delle variazioni di luminosita che ci possono essere in un'immagine. La normalizzazione degli istogrammi e fatta a partire da gruppi di celle detti blocchi. Per ogni blocco viene calcolato un fattore di normalizzazione e tutti gli istogrammi nel blocco sono normalizzati in base a tale fattore. Il descrittore finale e quindi rappresentato dal vettore delle componenti di tutte Ie celle dopo che sono state normalizzate raggruppandole per blocchi. Nella nostra implementazione abbiamo utilizzato un solo tipo di blocchi: rettangolari 0 quadrati partizionati in celle anch'esse quadrate 0 rettangolari (R-HOG).
  • 11. CAPITOLO 2. DESCRIZIONE DEL METODO 10 Gli R-HOG sono cornposti da sX s celle di Y)xY) pixel, ognuna contenente 0 canali, dove s, y), 0 sono pararnetri. Per rnigliorare ulteriorrnente la qualita dei descrittori puo essere utile introdurre il concetto di sovrapposizione (overlap) dei blocchi. Cio significa che blocchi tra loro adiacenti condividono un certo nurnero di celle che dipende ovviarnente dal pararnetro di overlap. La figura 2.4 rnostra un esernpio di creazione di blocchi di 2x2 celle utilizzando un fattore di overlap pari a 1. Figura 2.4: Esernpio di costruzione di blocchi con sovrapposizione. Da notare che nel caso di blocchi costruiti con overlap, un istograrnrna di una deterrninata cella puo appartenere a diversi blocchi e, quindi, puo constribuire alla norrnalizzazione di diversi blocchi. In questa caso puo sernbrare che il descrittore finale contenga inforrnazioni ridondanti rna in realta l'utilizzo dell'overlap puo in alcuni casi rnigliorare Ie prestazioni. Schemi di normalizzazione Per effettuare la norrnalizzazione degli istograrnrni nei singoli blocchi possono essere utilizzati diverse tecniche. Nella nostra irnplernentazione ne abbiarno testate solo alcune rna la libreria
  • 12. v ￿ v ￿k ε v → v/(￿ v ￿1 +ε) ￿ v → v/ ￿ v ￿2 +ε2 2
  • 13. (4 × 8) × (2 × 2) × 9 = 1152 {xk , yk } ∈ χ × {−1 , 1} xk yk xk φ
  • 14. CAPITOLO 2. DESCRIZIONE DEL METODO 13 di decisione nella forma: f (x) = w · φ(x) + b e f (x) e ottimale nel senso che massimizza la distanza tra il punto pili vicino φ(xi ) e l'iperpiano. L'etichetta di x e successivamente ottenuta considerando il segno di f (x) Per effettuare l'addestramento abbiamo utilizzato: • INRIAPerson dataset: composto da 1218 immagini negative e 2416 immagini positive per la fase di training, e 288 immagini positive e 453 immagini negative per la fase di test [1] . • Libsvrn library: e il classificatore SVM utilizzato [7]. 2.6 Miglioramento prestazioni Le procedure di rilevazione finora analizzate costituiscono un'implementazione base del metodo HOG. Possono infatti essere ulteriormente migliorate Ie prestazioni con tecniche addizionali. Innanzitutto il metodo base prevede la creazione sequenziale dei vari descrittori quando si scorre l'immagine con la finestra di detection; questa gestione puo essere notevolmente migliorata introducendo una creazione multithreading dei descrittori. Utilizzando pertanto ca1colatori con pili CPU i tempi di esecuzione migliorano notevolmente. In secondo luogo la robustezza del classificatore utilizzato e la densa scansione dell'immagine portano ad avere molte finestre di rilevazione nelle prossimita di una persona.E quindi necessaria una procedura di fusione per l'ottenimento di una finestra unica. L'algoritmo utilizzato e il mean- shift.
  • 15. yi , i = 1, . . . , n Hi ￿ n ˆ 1 D2 [y, yi , Hi ] f (y) = | Hi |−1/2 t(wi ) exp(− ) n(2π)3/2 i=1 2
  • 16. D2 [y, yi , Hi ] = (y − yi )￿ Hi−1 (y − yi ) y yi t(wi ) ￿ n ˆ 1 −1/2 −1 D2 [y, yi , Hi ] ∇f (y) = | Hi | Hi (yi − y)t(wi ) exp(− )= n(2π)3/2 i=1 2 ￿ n ￿ 1 ￿ D2 [y, yi , Hi ] 3/2 | Hi |−1/2 Hi−1 yi t(wi ) exp(− ) − n(2π) i=1 2 ￿￿ n ￿ ￿ 1 ￿ D2 [y, yi , Hi ] 3/2 | Hi |−1/2 Hi−1 t(wi ) exp(− ) y n(2π) i=1 2 ￿i 2 | Hi |−1/2 t(wi ) exp(− D [y,yi ,Hi ] ) 2 ￿i (y) = ￿ n 2 [y,y ,H ] | Hi |−1/2 t(wi ) exp(− D 2 i i ) i=1 ￿ n ￿i = 1 i=1 n ￿ n ￿ ∇f (y) ￿ ˆ ￿ = ￿i (y)Hi−1 yi − ￿i (y)Hi−1 y ˆ f (y) i=1 i=1 n ￿ −1 Hh (y) = ￿i (y)Hi−1 i=1
  • 17. Hi ￿ n ￿ ˆ ∇f (y) ￿ m(y) = Hh ≡ Hh (y) ￿i (y)Hi−1 yi − y fˆ(y) i=1 ˆ ∇f (y) = 0 m(y) = 0 ￿ n ￿ ￿ ym = Hh (ym ) ￿i (y)Hi−1 yi i=1 yi ym yi , i = 1, . . . , n ym Hi Hi diag [Hi ] ￿ ￿ diag [Hi ] = (exp (si ) σx )2 , (exp (si ) σy ) , (σs )2 σx , σy , σs
  • 18. CAPITOLO 2. DESCRIZIONE DEL METODO 17 (I -1~ 10 Figura 2.5: Percorso del mean shift per il raggiungimento dei massimi locali. La figura 2.6 mostra invece il risultato dell'applicazione dell'algoritmo sopra presentato per la fusione delle finestre individuate dal detector.
  • 19. CAPITOLO 2. DESCRIZIONE DEL METODO 18 r..·/'· · · .·· · · · · · · ·. · · · · · · ·. ·/···I i I . !:T - / ,I ! . I . , ; L...... Eliminazione delle finestreJ con l)eSO negativo (a) Mal)IW ogni detection in uno Sl)azio 3D [x,Y,scala) Goa x AI)I) lico ilmean shift ! t _.._.-. _ .._ .._ _ _ .._ .._ " .1 (b) Figura 2.6: Fusione delle finestre di detection usando l'algoritmo mean-shift.La figura a) mostra il risultato della detection prima dell'applicazione del mean-shift. La figura b) mostra invece il risultato della fusione delle finestre, ossia il goal dell'algoritmo. La figura c) mostra sinteticamente i passi del metodo.
  • 20. Capitola 3 Architettura dell'implementazione L'obbiettivo principe del nostro lavoro consisteva nella creazione di una libreria Processing che implementasse il metodo HOG. II modello strutturale che e stato studiato e stato concepito in modo da semplificare e agevolare il pili possibile una eventuale futura rielaborazione del codice. Chiunque avra quindi la possibilita di modificare l'implementazione delle varie classi sfruttando Ie nostre interfacce. 3.1 Ambiente di sviluppo II linguaggio di programmazione utilizzato e il Processing [4]. II Processing e un linguaggio di programmazione open source e un ambiente di sviluppo per utenti che vogliono programmare con immagini, animazioni, e in generale materiale multimediale. E' utilizzato da studenti, artisti, designer, ricercatori. IIlinguaggio e basato su Java [3] e puo essere quindi sfruttato anche in IDE di programmazione quali Eclipse [2]. Un programma in Processing e chiamato Sketch. Gli Sketch sono salvati all'interno di Sketch- 19
  • 21. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 20 book, una cartella che e usata di default per salvare tutti i progetti. L'approccio utilizzato per l'implementazione della libreria consiste in 3 punti fondamentali: • Astrazione delle classi coinvolte nel progetto e creazione di un diagramma UML [11]; • implementazione in Eclipse delle classi; • riorganizzazione delle classi ed utilizzo di Pattern per rendere pili usabile e scalabile il codice; 3.2 Madella UML La figura 3.1 mostra il modello UML della libreria. Di seguito si andra ad analizzare come utilizzare la libreria per la personalizzazione dei vari parametri. II modello mostra gli oggetti principali, esistono tuttavia altre classi che concorrono all'obbiettivo finale. Come si vede dalla struttura del modello, si e cercato di rendere il codice il pili possibile riusabile tramite l'utilizzo di interfacce. I client restano quindi inconsapevoli della classe che effettivamente implementa questi oggetti poiche conoscono solo l'interfaccia. Questa proprieta riduce molto Ie dipendenze implementative tra sottosistemi. Inoltre i pattern usati nello sviluppo di HOG sono detti creazionali e permettono di istanziare classi concrete indirettamente, cioe senza chiamare 10 specifico costruttore, rna rifacendosi a metodi che restituiscono l'oggetto istanziato. Ancora una volta si ribadisce quindi il fatto che il sistema debba essere scritto facendo riferimento alle interfacce e non alle implementazioni.
  • 22. ~ • CrfOltf'Grlld.rnHCQmput01ltlonil C;;rlld·rnt,COmpl,lt.tlon ~ • cre::u:eHlslogr::unCOmpUt01llor1fl. HlslograrnComput,)t1on f-3 • crrilf,81l;l1cbComputiltionO' f1lock'Comput~llon §2 • • (rei1.teDeS(rlptOrCOfYl4)l.lIlllOon()~ crfOltrOr",ctot(J Ottrctor OescrlptorComptllta,uon o ~ ~ ~ @ ~...-//.J - ---"iT"" z~_··,·_·· ._..,___ "-i t;5 ',- t-rj Qq' .., .. / ' / /~ ./" "'" '---""-" ~.--- ------.-.~ f-3 f-3 .., .... §3 ~ ~ W 1.-----------.1 '""'." "l '----I i ~ ~ f-' o Grlldle.nlsCompUtaUofll «rFe> > ! 0 ~"UipIOtCOtr'lpu ...lIlion ! o Detector ._~----" . " ... --·... rt1d'f'nlVcoctot!JU ! • compllte(tesenptorO: f10ittlJ <.:r'aIe:> > • '1lmpll!._dt!Ie!(.l(~: A.tJ'I"U .. l<PolnllO> ~ 1- I·V.···......",..·.......,,·. 'J"....... lIL'l <c.t~i1~·t:>,. f • detect(): ArJit)'lISf<PolnUU> t"" o • lu.inO 'O~ 0.. ~ ,/ "l,,_ • 1o.,Uood, Ii I: _old 1.;>- ~ ~ >-" o ' "-. ' c: e Afi_HI"fOgrllm"ComputOlltion G A~_Blocks{omputatlon G AS_ Deser IptorComputatloti tt:l ~ . ~ II (·eU ....idlh; int CI bloc.k_helgtn Int r II c-rll_hright inl CI block..v.ldTh: int 0.. II b,ns_lnt (J ':~II_OYiI!ll.t.D.IJ:l G A~_[)(lrelor ~ ~ (1) DI Jlgnfd bQr;;Jftiin >-" CI g( Grad~entsComputJition S' «(lillIe!'> II YOlet. Vote.r II he Hi,togrilm,Compllotlon ~ • gelB.."O;ir11 «ul-e.» CI be 8lDeks.Ccmpllla.t1cn >-" (7 .., • A~_HI.sto!ilra.mS<:OrYJl)LltilOon(): 1 '" lo.d a dl; ~Hriptor<ompl,lltatton CI 'fItlndow -Mdlt't int o .., (1) e Pflt.eICr.lldlt'r'lIVeClQI a wlndow_hright inl ~ S" CI milonlrudl! flo')l < <c.iJb:> @BlO'k CI numbet, of .'ESIze.~: In D .. ngle flO.ll1 a histogramS HlslOgraml)U a model 'tJm_modc.' • gf'M;Jgnih.ldfO flo •• • Blockn. ,old • V.<AnvleH no" • toY(c,or() floOlIU • toBlockU: Block G th"oqt;,m D hl.5-l0QI,)m flo,)ln II' bin" Int o cell ",Idth: Int D c('l1_ht-,ght int / , • •ddVoTeU: _oid I public "Ote(noat mi1.9nltudt) ( rel1Jrn 1; I@ L~Norml I a Ll Norm I tv f-'
  • 23. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 22 3.3 Descrizione delle classi In questa sezione andremo ad analizzare brevemente Ie classi e Ie interfacce che compongono il modello concettuale sopra analizzato. HOG Factory L'interfaccia HOG_Factory rappresenta il punto di accesso alla nostra libreria. Essa possiede tutti i metodi necessari ad istanziare i singoli oggetti per l'esecuzione delle varie procedure di detection. Tali metodi vengono ovviamente implementati dalla classe HOG che rappresenta la realizzazione dell'interfaccia. In particolare abbiamo i seguenti metodi: • createGradientsComputationO : restituisce un oggetto di tipo AS _ GradientsComputation (conforme all'interfaccia GradientsComputation); • createHistogramsComputationO: restituisce un oggetto di tipo AS _ HistogramsComputation (conforme all'interfaccia HistogramsComputation). Ha come parametri: bins: numero di canali di un istogramma; cell_ width: larghezza di una cella (in pixel); cell_ height: altezza di una cella (in pixel); signed: booleano che indica se l'istogramma deve essere costruito su 0 _180 0 0 0 su 0 _360 0 0 ; voter: oggetto conforme all'interfaccia Voter; • createBlocksComputationO: restituisce un oggetto di tipo AS _ HistogramComputation (conforme all'interfaccia BlocksComputation). Ha come parametri:
  • 24. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 23 bloek_ width: larghezza di un blocco (in numero di celIe); block_height: altezza di un blocco (in numero di celIe); overlap: indica il fattore di sovrapposizione tra blocchi; norm: oggetto conforme all'interfaccia Norm; • createDescriptorComputationO: restituisce un oggetto di tipo AS _ DescriptorComputation (conforme all'interfaccia DescritorComputation). • createDetectorO: restituisce un oggetto della c1asse AS _ Detector (conforme all'interfaccia Detector). Ha come parametri: ge: oggetto della c1asse GradientsComputation; he: oggetto della c1asse HistogramsComputation; be: oggetto della c1asse BlocksComputation; de: oggetto della c1asse DescriptorComputation; window_ width: larghezza della finestra di detection (in pixel); window_height: altezza della finestra di detection (in pixel); stride: indica il valore in pixel dello spostamento della finestra di detection (10 stesso valore sia per l' asse verticale che per quello orizzontale); number_ 01_ resizes: indica il numero di resize che verranno effettuati durante l'analisi dell'immagine; La c1asse HOG e implementato come pattern Singleton e pertanto presenta il metodo ereateln- stanee() che ne permette l'istanziazione.
  • 25. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 24 GradientsComputation L'interfaccia GradientsComputation e l'interfaccia che, tramite la sua realizzazione AS _ GradientsComputation, si occupa di calcolare il gradiente di un'immagine. In particolare restituisce per ogni pixel dell'immagine il valore del magnitudo e dell'angolo relativo al gradiente. L'unico metoda a disposizione e: • computeGradientsO: restiuisce una matrice di oggetti PixelGradientVector. Ha come parametri: zmage: oggetto di tipo PImage; rappresenta l'immagine da analizzare. parent: oggetto della classe PApplet; permette la gestione di un'applet processing. PixelGradientVector Un oggetto della classe PixelGradientVector permette la memorizzazione del gradiente relativo a un pixel dell'immagine. In particolare ne memorizza il magnitudo e l'angolo. Ha come metodi principali: • getMagnitudeO: restituisce il valore del magnitudo; • getAngleO: restituisce il valore dell'angolo; HistogramsComputation L'interfaccia HistogramsComputation e l'interfaccia che, tramite la sua realizzazione AS _ HistogramsComputation, si occupa di calcolare gli istogrammi dell'immagine utilizzando il valore dei gradienti dei pixel. L'unico metoda a disposizione e:
  • 26. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 25 • computeHistogramsO: restituisce una matrice di oggetti Histogram ognuno dei quali e relativo a una particolare cella. Ha come parametri: - pgv: matrice di oggetti PixelGradientVector. Histogram Un oggetto della c1asse Histogram permette la memorizzazione delle informazioni relative a un sin- golo istogramma. In particolare l'istogramma e memorizzato come vettore di reali con dimensione pari al numero di canali scelti. Ha come metodi principali: • addVoteO: restituisce un booleano che indica l'esito della votazione (restituisce true se andata a buon fine). Ha come parametri: vote: rappresenta il valore del voto; bin: indica il canale di appartenenza del voto; • toVectorO: resituisce il vettore che rappresenta l'istogramma. Voter Rappresenta l'interfaccia che permette la votazione all'interno di un'istogramma. Si e scelto di gestire la votazione tramite interfaccia in quanto i metodi di votazione possono essere molteplici. In particolare nella nostra implementazione abbiamo messo a disposizione la c1asse EasyVoter (ogni voto ha peso unitario) e la c1asse MagnitudeItselfVoter (ogni voto ha come peso il valore del magnitudo). Chiunque avesse la necessita di utilizzare altre tecniche di votazione puo quindi
  • 27. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 26 semplicemente realizzare c1assi che implementano l'interfaccia Voter senza dover cambiare a1cuna riga di codice. L'interfaccia prevede un unico metodo: • voteO: restituisce un reale che indica il valore risultante del voto. Ha come parametri: - magnitude: rappresenta il valore del magnitudo associato a un gradiente. BlocksComputation L'interfaccia BlocksComputation e l'interfaccia che, tramite la sua realizzazione AS _ BlocksComputation, si occupa di creare i blocchi di celIe ed effettuarne eventualmente la normalizzazione in base a una norma stabilita. Ha come metodi: • computeBlocksO: restituisce una matrice di oggetti Block. Ha come unico parametro: - histograms: matrice di oggetti della c1asse Histogram. • normalizeBlocksO: restituisce una matrice di oggetti di tipo Block normalizzati in base alIa tecnica di normalizzazione scelta. Ha come unico parametro: unnormalized blocks: matrice di oggetti Block (blocchi non ancora normalizzati). Norm Rappresenta l'interfaccia che permette la normalizzazione di un'istogramma. Si e scelto di ge- stire la normalizzazione tramite interfaccia in quanto i metodi di normalizzazione possono essere molteplici. In particolare nella nostra implementazione abbiamo messo a disposizione la c1asse
  • 28. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 27 L2_Norm (norma di tipo L2) e la c1asse Ll_Norm (norma di tipo Ll). Chiunque avesse la neces- sita di utilizzare altre tecniche di normalizzazione puo quindi semplicemente realizzare c1assi che implementano l'interfaccia Norm senza dover cambiare a1cuna riga di codice. L'interfaccia prevede un unico metodo: • normalize 0: restitusee un vettore di reali. Dato in ingresso un vettore istogramma resti- tuisce quindi il relativo istogramma normalizzato. Ha come unico parametro: - vector: vettore di reali da normalizzare. Block Un oggetto della c1asse Block permette la memorizzazione delle informazioni relative a un singolo blocco. In particolare ogni singolo blocco contiene una matrice di istogrammi (oggetti della c1asse Histogram). Ha come metodi principali: • toVectorO: restituisce il descrittore del blocco, cioe un unico vettore di reali contenenti i singoli istogrammi concatenati. • toBlockO: effettua l'operazione inversa al metodo toVectorO. A partire dal descrittore di un blocco (vettore di reali) crea un oggetto Block. Ha come parametro: - block_ descriptor: vettore di reali rappresentante il descrittore di un blocco.
  • 29. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 28 DescriptorComputation L'interfaccia DescriptorComputation e l'interfaccia che, tramite la sua realizzazione AS _ DescriptorComputation, si occupa di creare il descrittore finale dato in input una matrice di blocchi (oggetti della classe Block). Ha come metodo: • computeDescriptorO: restituisce il descrittore come vettore di reali. Ha come parametri: - blocks: matrice di oggetti della classe Block Detector L'interfaccia Detector e l'interfaccia che, tramite la sua realizzazione AS _ Detector, si occupa di effettuare Ie operazioni di detection di pedoni all'interno di un'immagine di input. Inoltre consente anche di creare un file di training necessario all'addestramento del modello. Ha come metodi: • trainO: ha come obbiettivo quello di scrivere un file contenente di descrittori delle singole finestre di detection utilizzate per 10 scorrimento e analisi dell'immagine. II formato del file rispetta Ie specifiche dell'applicativo svm-train (contenuto nel pacchetto di LIBSVM): Ha come parametri: - pos_ directory: percorso della directory dalla Quale prelevare gli esempi positivi; neg_ directory: percorso della directory dalla Quale prelevare gli esempi negativi; training_filename: nome del file di output; - parent: oggetto della classe PApplet necessario per la gestione della applet processing.
  • 30. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 29 - mndom_ windows_from_ negatives: numero di sottoimmagini (di dimensione pari a quelle della finestra di detection) da prelevare randomicamente da una singola immagine negativa. • loadModelO: permette di caricare il modello ottenuto dalla fase di allenamento (il modello e generato dall'applicativo svm-tmin). Ha come parametro: - modeCfilename: percorso del file che contiene il modello. • simple_detect 0: restituisce una lista di punti (ArrayList di oggetti della classe Point _ 3D) ottenuti dalla detection sull'immagine. Tali punti corrispondono aIle detection positive. Questo metodo implementa una versione base del detector. In particolare 10 scorrimento delle finestre di detection e sequenziale (senza utilizzo di Thread) e non viene applicata nessuna operazione di fusione delle finestre in output (senza utilizzo del mean shift). Riceve come parametri: - img_ original: oggetto della classe PImage che contiene l'immagine da analizzare; - parent: oggetto della classe PApplet necessario per la gestione della applet processing. • detectO: versione avanzata del metodo simple_detect(). Esso utilizza una gestione multi- thread per 10 scorrimento delle finestre di detection e adotta mean shift come algoritmo di fusione delle finestre. Restituisce una lista di punti (ArrayList di oggetti della classe Point _ 3D) ottenuti dalla detection sull'immagine. Tali punti corrispondono aIle detection positive. Riceve come parametri: - img_ original: oggetto della classe PImage che contiene l'immagine da analizzare; - parent: oggetto della classe PApplet necessario per la gestione della applet processing.
  • 31. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 30 Point 3D Permette di mappare una finestra di detection nello spazio 3-dimensionale (x, y, scala), dove la coppia (x, y) rappresenta il punto centrale della finestra e scala indica il fattore di scala per l'otteni- mento della dimensione effettiva della finestra stessa. Ad ogni oggetto della classe e associato anche un ulteriore attributo weight, che puo essere utilizzato come valore di confidenza della rilevazione. Hog Printer Permette la stampa delle detection effettuate sia su file che a video. Ha come metodi: • print_results _ onvideoO: stampa i risultati della detection all'interno dell' Applet a video. In particolare disegna attorno ad ogni finestra di detection positiva un rettangolo. Ha come parametri: - parent: oggetto della classe PApplet necessario per la gestione della applet processing; detected_points: ArrayList di oggetti della classe Point _ 3D da stampare; window_ width: larghezza della finestra di detection; window_height: altezza della finestra di detection; rgb_ boxes: permette di specificare il colore del bordo dei rettangoli. • print_results _ onfileO: scnve i risultati della detection m un file di testo. Ha come parametri: detected_points: ArrayList di oggetti della classe Point _ 3D da stampare; window width: larghezza della finestra di detection;
  • 32. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 31 - window_height: altezza della finestra di detection; - filename: percorso su disco del file dove scrivere i risultati. - image_ name: nome dell'immagine su cui e stata effettuata la detection. 3.4 Utilizzo della libreria Forniamo di seguito una descrizione per l'installazione e l'utilizzo della libreria, per la creazione di piccole applicazioni che necessitano della rilevazione di pedoni all'interno di immagini. Installazione Innanzitutto e necessario scaricare la libreria dal sito ufficiale del progetto [5] per scancare la versione aggiornata della libreria. Una volta ottenuto l'archivio, esso deve essere decompresso e inserito all'interno della cartella code del proprio sketchbook, su Linux solitamente e jsketchbook, su Mac OS X e Windows e la cartella Processing all'interno dei propri documenti. In generale comunque la cartella del progetto puo essere salvata in qualunque posizione, basta che all'interno contenga il file .pde dell'applicazione e allo stesso livello la cartella code contenente la libreria. U tilizzo per la procedura di detection Di seguito andiamo ad analizzare i passi base per l'utilizzo della libreria necessari alIa detection di pedoni all'interno di un'immagine: 1. importazione della libreria tramite la direttiva import hog. *; 2. definizione dei parametri per la detection, la loro descrizione verra fatta successivamente;
  • 33. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 32 3. creazione dell'istanza di HOG con il metodo HOG.createInstanceO; 4. creazione dell'oggetto di interfaccia GradientsComputation con il metodo hog.createGradientsComputation(. . .); 5. creazione dell'oggetto di interfaccia BlocksComputation con il metodo hog.createBlocksComputation(. . .); 6. creazione dell'oggetto di interfaccia DescriptorComputation con il metodo hog.createDescriptorComputation(. . .); 7. creazione dell'oggetto di interfaccia Detector con il metodo hog.createDetector(. . .); 8. caricamento del modello con il metodo detector.load _ model(. . .); 9. esecuzione procedura di detection sull'immagine con il metodo detector.detect (. . .) oppure detector.simple_ detect (. .); 10. stampa dei risultati a video con Hog_ Printer.print _ results _ onvideo (. . .) e/ 0 su file con Hog _ Printer.print _ results _ onfile (. . .); U tilizzo per la creazione del file di training Di seguito andiamo ad analizzare i passi base per l'utilizzo della libreria necessari alIa creazione del file di training necessario all'addestramento tramite applicativo svm-tmin.
  • 34. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 33 1. importazione della libreria tramite la direttiva import hog. *; 2. definizione dei parametri per la detection, la loro descrizione verra fatta successivamente; 3. creazione dell'istanza di HOG con il metodo HOG.createInstanceO; 4. creazione dell'oggetto di interfaccia GradientsComputation con il metodo hog.createGradientsComputation(. . .); 5. creazione dell'oggetto di interfaccia BlocksComputation con il metodo hog.createBlocksComputation(. . .); 6. creazione dell'oggetto di interfaccia DescriptorComputation con il metodo hog.createDescriptorComputation(. . .); 7. creazione dell'oggetto di interfaccia Detector con il metodo hog.createDetector(. . .); 8. esecuzione procedura di creazione del file di training con il metodo detector.train(. . .); 11 file di testo ottenuto puo successivamente essere utilizzato come file di input per l'addestramento del c1assificatore. La procedura di apprendimento puo essere effettuata usando l'applicativo svm- train.
  • 35. CAPITOLO 3. ARCHITETTURA DELL'IMPLEMENTAZIONE 34 Esempio di applicativo Processing Forniamo adesso un esempio di applicativo Processing che utilizza la nostra libreria HOG. Nell'e- sempio sono anche evidenziati i vari passi da eseguire per analizzare un'immagine. Importazione della libreria HOG void setupO { Plmage img = Loadlmage("prova .png"); Carica.mento dell'immagine size(img .width, img .height); image(img,El,El); II Standard settt ngs (these are optt ma L settt ngs ) Settaggio dei para.metri int window_width=64; int window_height=128; int bins = 9; int ce LL_size = 8; int bLock_size = 2; boo Lean signed = fa Lse; int over Lap = 1; int stride=16; i nt number_oLres i zes=5 ; Sequenza dei passi per ottenere iI detector String modeL Lo = "/Users/matteo/Desktop/5Elneg_oLs25ElEl_modeL .txt"; l HOGJactory hog=HOG .createlnstanceO; Creazione istanza di HOG GradientsComputat ion gc=hog .createGradientsComputat ionO; Voter voter=Magni tudeltse LfVoter .createMagni tudeltse LfVoterO; HistogramsComputatton hc=hog .createHistogramsComputatton( bins, ce LL_size, ce LL_size, signed, voter); Norm norm=LLNorm .createLLNorm(El.l); BLocksComputatton bc=hog .createB LocksComputatton(b Lock_size, bLock_size, over Lap, norm); DescriptorComputat ion dc=hog .createDescriptorComputat ionO; Detector detector=hog .createDetector(gc, hc, bc, dc, window_width, window_height, stride, numbecoLresizes); try { detector. Load_mode L(mode LLo); Carica.mento del modello ArrayUst4'oinL3D> detected_points = detector.detect( img, this); Hog_Printer .prinLresu Lts_onvideo(this, detected_points, window_width, window_height, Hog_Printer .RED); } catch (I nterruptedExcept i on ex) { ex .printStackTrace0 ; Esecuzione del detector e stampa dei risultati a video } catch (I OExcept i on e) { e .printStackTrace0 ; } } Figura 3.2: Esempio di applicativo Processing.
  • 36. #f alseN egatives M issRate = #trueP ositives+#f alseN egatives #trueP ositives P recision = #trueP ositives+#f alseP ositives
  • 37. #f alseN egatives #trueP ositives #f alseP ositives ao bp bgt area (bp ∩ bgt ) ao = area (bp ∪ bgt ) ao
  • 38. area (bp ∩ bgt ) = (396 − 305) × (411 − 127) = 91 × 284 = 25844 area (bp ∪ bgt ) = (443 − 259) × (458 − 90) = 184 × 368 = 67712 25844 ao = 67712 = 0.38
  • 39. CAPITOLO 4. TEST 38 • larghezza finestra di detection (window_width): 64 • altezza finestra di detection (window_height): 128 • numero di canali (bins): 9 • dimensione delle celIe (cell_size): 8 • dimesione dei blocchi (block _ size) 2 • tipo di istogramma (signed) : senza segno • tipo di voter: magnitude voter • tipo di normalizzazione: L2 norm Tenendo fissi questi valori abbiamo poi valutato Ie differenze andando a variare altri parametri quali: • overlap • parametro di addestramento C. II parametro C e fondamentale in quanto e il parametro che pesa gli errori nella fase di adde- stramento. Valori diversi possono quindi influire molto nella performance del detector. Abbiamo costatato che per valori maggiori di 1 l'accuratezza peggiora in quanto vengono considerati come positivi un eccessivo numero di esempi. Anche valori troppo bassi di C peggiorano l'accuratezza, rna in questo caso il classificatore appare troppo poco tollerante in quanto rileva un numero ecces- sivamente piccolo di esempi positivi. I risultati migliori sono stati ottenuti con un valore di C pari a 0.01.
  • 40. CAPITOLO 4. TEST 39 La figura seguente mostra i risultati ottenuti su un'immagine di test al variare del parametro c. C= 100 C= 10 C=1 C=0.1 C =0.01 C =0.001 Figura 4.2: La figura mostra i risultati della classificazione su un'immagine di prova al variare del parametro C. I rettangoli in verde mostrano i risultati senza applicazione del mean shift, i rettangoli blu mostrano invece i risultati dopo l'operazione di fusione. Abbiamo infine valutato i valori di precision e missrate suI test set, utilizzando sia overlap pari a 1 che overlap pari a a (quindi nessuna sovrapposizione di blocchi), mantenendo il parametro C al valore 0.01. I risulati migliori per quanto riguarda il caso senza overlap con immagini positive e il seguente:
  • 41. CAPITOLO 4. TEST 40 • precision: 61% • missrate: 44% Per quanto riguarda invece il caso senza overlap con immagini negative il risultato e il seguente: • #falsePositives: 80 su un totale di 453 immagini. I risultati seguenti mostrano invece il caso con overlap con immagini positive: • precision: 59% • missrate: 51% Per quanto riguarda Ie immagini negative il risultato e il seguente: • #falsePositives: 83 su un totale di 453 immagini. Abbiamo inoltre testato come varia il tempo di esecuzione dell'algoritmo al variare di a1cuni parametri. II grafico di figura 4.3 mostra la relazione tra tempo di esecuzione e dimensione dell'immagine, nelle due varianti con overlap e senza overlap. 80 60 20 O~~~-- 200x150 320x240 400x300 640J<480 800x600 dimensions immagins -0 overlap _ 0 -0 overlap _ 1 Figura 4.3: Tempo di esecuzione al variare della dimensione dell'immagine.
  • 42. CAPITOLO 4. TEST 41 II grafico di figura 4.4 mostra la relazione tra tempo di esecuzione e numero di resize effettuati, con uno stride variabile. 30 22.5 1 .$ o 15 i 5 10 15 20 It resize o stride - 16 px 0 stride - 8 px 0 stride - 4 px Figura 4.4: Tempo di esecuzione al variare del numero di resize e dello stride.
  • 43. Capitola 5 Sviluppi futuri La libreria sviluppata implementa attualmente una versione base del metodo descritto. Tuttavia es- sa e stata strutturata in modo che sia facilmente modificabile ed estendibile. Ci sono effettivamente alcuni punti che possono essere migliorati per aumentare Ie performance. In particolare sarebbe necessario un lavoro maggiormente approfondito per quanto riguar- da la scelta dei parametri da utilizzare, crediamo in questo modo che sia possibile migliorare ulteriormente gli indici di prestazione. Altro aspetto da migliorare riguarda la strategia di scorrimento delle finestre. Esistono infatti tecniche di analisi che permettono di velocizzare notevolmente la procedura di detection [12]. Infine, sarebbe interessante studiare l'effettiva efficacia di piccole accortezze, non fondamentali per raggiungere 10 scopo e omesse durante l' implementazione, che invece sono state utilizzate dagli autori del metodo. In particolare e stata omessa una fase preliminare di normalizzazione di contrasti e colori e nella computazione dei gradienti non e stato utilizzato il Gaussian smoothing: un particolare filtro che permette di rimuovere piccoli dettagli e rumori che possono infiuenzare 42
  • 44. CAPITOLO 5. SVILUPPI FUTURI 43 negativamente il c1assificatore SVM.
  • 45. Bibliografia [1] InriaPerson dataset. http://pascal. inrialpes. fr/data/human/. [2] Progetto Eclipse. http://www . eclipse. org. [3] Progetto Java. http: / / java. sun. com. [4] Progetto Processing. http://www . processing. org. [5] Alessio Anzivino and Matteo Spampani. HOG-Processing: A library for pedestrian recognition, 2010. http://hogprocessing . altervista. org. [6] B. E. Boser, 1. M. Guyon, and V. N. Vapnik. A training algorithm for optimal margin classifiers. In D. Haussler, editor, 5th Annual ACM Workshop on COLT, pages 144-152, Pittsburgh, PA, 1992. ACM Press. [7] Chih-Chung Chang and Chih-Jen Lin. LIBSVM: a library for support vector machines, 200l. Software available at http://www.csie.ntu.edu.tw;-cjlin/libsvm. [8] Dorin Comaniciu and Peter Meer. Mean shift: A robust approach toward featu- re space analysis. IEEE Trans. Pattern Anal. Mach. Intell., 24(5):603-619, 2002. http://dx.doi.org/10.1109/34.1000236. 44
  • 46. BIBLIOGRAFIA 45 [9] N. Cristianini and J. Shawe-Taylor. Statistical Learning Theory. Cambridge Univeristy Press, 2000. [10] Navneet Dalal and Bill Triggs. Histograms of oriented gradients for human detection. In Cordelia Schmid, Stefano Soatto, and Carlo Tomasi, editors, International Conference on Computer Vision and Pattern Recognition, volume 2, pages 886-893, INRIA Rhone-Alpes, ZIRST-655, avo de l'Europe, Montbonnot-38334, June 2005. [11] Lano Kevin. Uml2. WILEY & SONS LTD., November 2009. [12] Christoph H. Lampert, Matthew B. Blaschko, and Thomas Hofmann. Beyond sliding windows: Object localization by efficient subwindow search. In CVPR, 2008. http://dx .doi. org/10. 1109/CVPR.2008.4587586. [13] A. Shashua, Y. Gdalyahu, and G. Hayon. Pedestrian detection for driving assistance systems: Single-frame classification and system level performance. In Proceedings of IEEE Intelligent Vehicles Symposium, 2004. [14] V. Vapnik. Statistical Learning Theory. Wiley, 1998.