Hog processing

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

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

INDICE 2

4 Test 35

5 Sviluppi futuri 42

Bibliografia 45

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

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.

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

Dx = (−1 , 0 , 1)

Dy = (−1 , 0 , 1)T

I

Ix = I ∗ Dx
Iy = I ∗ Dy

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).

[0 , 40 )

[40 , 80 )

[80 , 120 )


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).


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

v v k ε

v → v/( v 1 +ε)

v → v/ v 2 +ε2
2

(4 × 8) × (2 × 2) × 9 = 1152

{xk , yk } ∈ χ × {−1 , 1} xk
yk
xk φ


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.

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

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

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


(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.


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.

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

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.

~
• 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'IU .. lPolnllO
~ 1- I·V.···......,..·.......,,·. 'J....... lIL'l c.t~i1~·t:,. f • detect(): ArJit)'lISfPolnUU
t
o • lu.inO 'O~
0..
~
,/
l,,_ • 1o.,Uood, Ii I: _old
1.;-
~
~
-
o ' -. '
c: e Afi_HIfOgrllmComputOlltion
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; ~Hriptorompl,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 thoqt;,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-'


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:


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.


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:


• 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


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


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.


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.


- 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;


• 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;



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;


- 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;


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.


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.


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.

#f alseN egatives
M issRate = #trueP ositives+#f alseN egatives

#trueP ositives
P recision = #trueP ositives+#f alseP ositives

#f alseN egatives

#trueP ositives

#f alseP ositives

ao bp
bgt

area (bp ∩ bgt )
ao =
area (bp ∪ bgt )

ao

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

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.

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:

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 640J480 800x600
dimensions immagins

-0 overlap _ 0 -0 overlap _ 1

Figura 4.3: Tempo di esecuzione al variare della dimensione dell'immagine.

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.

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

CAPITOLO 5. SVILUPPI FUTURI 43

negativamente il c1assificatore SVM.

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

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.

Hog processing

Recommandé

Recommandé

Contenu connexe

Similaire à Hog processing

Similaire à Hog processing (20)

Dernier

Dernier (8)

Hog processing