Estrazione Real-Time Di Caratteristiche Immagine Di Basso Livello A Bordo Di Telecamera

UNIVERSIT
`
A DEGLI STUDI DI FIRENZE
Facolt` a di Ingegneria - Dipartimento di Sistemi e Informatica
Tesi di laurea in Ingegneria Informatica
Estrazione real-time di
caratteristiche immagine di basso
livello a bordo di telecamera
Candidato
Leonardo Galteri
Relatori
Prof. Alberto Del Bimbo
Ing. Marco Bertini
Correlatore
Ing. Lorenzo Seidenari
Anno Accademico 2010/2011
A mio padre
i
Indice
1 Introduzione 1
1.1 Feature Locali . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Estrattori di feature . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Struttura della tesi . . . . . . . . . . . . . . . . . . . . . . . 6
2 Rilevamento di feature 7
2.1 FAST Corner Detection . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Cerchio di Bresenham . . . . . . . . . . . . . . . . . . 8
2.1.2 Il criterio Segment Test . . . . . . . . . . . . . . . . . 9
2.1.3 Original FAST . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Generic FAST . . . . . . . . . . . . . . . . . . . . . . 13
2.1.5 Learned FAST . . . . . . . . . . . . . . . . . . . . . . 16
2.1.6 Punteggio e soppressione dei non massimi . . . . . . . 17
2.1.7 Stima di ripetitività . . . . . . . . . . . . . . . . . . . 19
2.2 Rilevamento dei contorni . . . . . . . . . . . . . . . . . . . . 20
2.2.1 Gradiente . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Sviluppo del rilevamento contorni . . . . . . . . . . . 23
2.2.3 Operatore di Sobel . . . . . . . . . . . . . . . . . . . 24
2.2.4 Quantizzazione . . . . . . . . . . . . . . . . . . . . . 26
3 Data mining 30
3.1 Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Misura di clustering . . . . . . . . . . . . . . . . . . . 33
3.1.2 Algoritmi di clustering . . . . . . . . . . . . . . . . . 35
ii
3.2 K-means . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1 Metodi di inizializzazione . . . . . . . . . . . . . . . . 41
3.2.2 Diagramma di Voronoi . . . . . . . . . . . . . . . . . 43
3.3 Validità dei cluster . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.1 Concetti fondamentali . . . . . . . . . . . . . . . . . 44
3.3.2 Indici di validità . . . . . . . . . . . . . . . . . . . . . 45
4 Sviluppo del Software 49
4.1 Piattaforma Axis . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.1 Speciche P1343 . . . . . . . . . . . . . . . . . . . . . 50
4.1.2 Codec video . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.3 API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Esecuzione dellapplicazione . . . . . . . . . . . . . . 54
4.2.2 Acquisizione delle immagini . . . . . . . . . . . . . . 56
4.2.3 Esecuzione algoritmi . . . . . . . . . . . . . . . . . . 58
4.2.4 Interfaccia di rete . . . . . . . . . . . . . . . . . . . . 62
4.3 Interfaccia utente . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.1 Tecnologia AJAX . . . . . . . . . . . . . . . . . . . . 66
4.3.2 XMLHttpRequest . . . . . . . . . . . . . . . . . . . . 67
4.3.3 Streaming dei dati . . . . . . . . . . . . . . . . . . . 70
4.3.4 Interfaccia graca . . . . . . . . . . . . . . . . . . . . 73
4.4 Metodi di trasmissione . . . . . . . . . . . . . . . . . . . . . 78
4.4.1 Codica dei dati . . . . . . . . . . . . . . . . . . . . . 78
4.4.2 Multipart Mixed-Replace . . . . . . . . . . . . . . . . 82
5 Risultati Sperimentali 83
5.1 Valutazione della performance . . . . . . . . . . . . . . . . . 85
5.2 Velocità di esecuzione . . . . . . . . . . . . . . . . . . . . . . 86
5.2.1 Stima di analisi senza rappresentazione . . . . . . . . 87
5.2.2 Stima di analisi con rappresentazione . . . . . . . . . 91
5.2.3 Modica del frame rate di acquisizione . . . . . . . . 94
5.3 Compressione dei dati . . . . . . . . . . . . . . . . . . . . . . 96
iii
6 Conclusioni e sviluppi futuri 99
A Codice sorgente dellalgoritmo Generic FAST 103
A.1 Fast.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.2 Fast.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.3 Fast9.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
A.4 Nonmax.cpp . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
A.5 Pixel.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
B Software Development Kit 116
B.1 Compilatore CRIS . . . . . . . . . . . . . . . . . . . . . . . . 116
B.2 Installazione SDK . . . . . . . . . . . . . . . . . . . . . . . . 117
B.3 Creazione del package . . . . . . . . . . . . . . . . . . . . . . 117
B.4 Upload sulla camera . . . . . . . . . . . . . . . . . . . . . . . 118
B.5 Interfacce dellSDK . . . . . . . . . . . . . . . . . . . . . . . 119
Bibliograa 121
Ringraziamenti 129
iv
Elenco delle gure
2.1 Cerchio di Bresenham di raggio 3 . . . . . . . . . . . . . . . . 9
2.2 Esempio del criterio Segment Test per n = 9 e n = 12 . . . . . 10
2.3 Algoritmi FAST a confronto . . . . . . . . . . . . . . . . . . . 15
2.4 Leetto delleliminazione dei non massimi . . . . . . . . . . . 19
2.5 Il funzionamento delloperatore di Sobel e le componenti del
gradiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Quantizzazione dellimmagine ottenuta con Sobel . . . . . . . 27
2.7 Thresholding dellimmagine al variare della soglia t . . . . . . 29
3.1 Esempio di dendrogramma . . . . . . . . . . . . . . . . . . . . 36
3.2 Algoritmo di Lloyd . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Diagramma di Voronoi . . . . . . . . . . . . . . . . . . . . . . 44
4.1 La camera Axis P1343 . . . . . . . . . . . . . . . . . . . . . . 50
4.2 Il diagramma degli stati dellapplicazione . . . . . . . . . . . . 55
4.3 Il funzionamento di XMLHttpRequest . . . . . . . . . . . . . 69
4.4 Client Polling . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Server Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.6 Rappresentazione dei corner . . . . . . . . . . . . . . . . . . . 74
4.7 Rappresentazione degli edge . . . . . . . . . . . . . . . . . . . 75
5.1 Le scene utilizzate per misurare la performance dellapplicazione 84
5.2 Quantità di corner rilevati in una scena molto dettagliata . . . 85
5.3 Tempi di esecuzione in una scena di medio dettaglio . . . . . . 88
5.4 Performance dellalgoritmo FAST . . . . . . . . . . . . . . . . 89
5.5 Performance dellalgoritmo Sobel . . . . . . . . . . . . . . . . 90
v
5.6 Performance dellalgoritmo k-means . . . . . . . . . . . . . . . 92
5.7 Dierenza di performance . . . . . . . . . . . . . . . . . . . . 93
5.8 Tempo di esecuzione di FAST al variare del tasso di acquisizione 95
5.9 Dimensione media delle immagini codicate . . . . . . . . . . 96
5.10 Confronto della codica Run-length su scene diverse . . . . . . 98
vi
Elenco degli algoritmi
1 Original FAST n = 12 and r = 3 . . . . . . . . . . . . . . . . 11
2 Generic FAST n = 9 and r = 3 . . . . . . . . . . . . . . . . . 14
vii
Sommario
La realizzazione di tecniche di visione computazionale in grado di rileva-
re caratteristiche immagine di basso livello è un argomento che ha ricevuto
una grande attenzione nella comunità scientica. Metodi sempre pi` u inno-
vativi hanno permesso di eseguire lestrazione dei punti di interesse in tem-
po reale consentendo lo sviluppo di applicazioni complesse nellambito della
videosorveglianza.
Questo lavoro di tesi studia alcune tecniche di rilevazione e fornisce inoltre
i seguenti contributi:
La creazione di una variante di un algoritmo di rilevazione corner che
si adatta perfettamente a qualsiasi tipo di immagine e che mantiene le
caratteristiche di velocità e robustezza.
Lapplicazione di una tecnica di clustering per linterpretazione dei
punti di interesse estratti e lo studio di metodi di inizializzazione e
di validazione di tale metodo.
Lo sviluppo di una applicazione per una telecamera di videosorveglian-
za nalizzata allestrazione delle feature in tempo reale mediante le
suddette tecniche.
La realizzazione di un sistema client-server per la rappresentazione dei
punti di interesse rilevati dallapplicazione.
Lanalisi delle prestazioni e del carico di trasmissione dellapplicazione.
Capitolo 1
Introduzione
Il settore della visione articiale ha subito negli ultimi anni un processo di
continuo sviluppo, ed è stato oggetto di numerosi studi. Tecniche di elabo-
razione di immagini sempre pi` u performanti sono state studiate per la riso-
luzione di problemi in molti ambiti di ricerca e implementate su macchine
sempre pi` u potenti.
La recente evoluzione tecnologica ha inoltre favorito la creazione e la dif-
fusione sempre maggiore di dispositivi digitali per lacquisizione video, come
ad esempio fotocamere, webcam e telefoni cellulari di ultima generazione.
Le telecamere di videosorveglianza hanno avuto un forte sviluppo in questo
contesto. Alla ne degli anni 90 inizia lera della videosorveglianza basata
su dispositivi digitali andando a sostituire la precedente tecnologia analogi-
ca. Il cavo coassiale usato dalle camere a circuito chiuso non è pi` u adatto
al trasferimento dei dati, viene quindi utilizzato lo standard Ethernet per il
trasferimento dati sul protocollo TCP/IP.
Levoluzione della videosorveglianza digitale con le nuove telecamere, chia-
mate IP, ha permesso la completa integrazione di questi sistemi nelle reti
di calcolatori moderne, favorendone la diusione. Inoltre la possibilità di
trattare le immagini come dati digitali ha favorito il continuo sviluppo di
applicazioni di elaborazione ed analisi che lavorano in tempo reale. Fanno
parte di questo ambito le applicazioni che rilevano feature di basso livello.
1
CAPITOLO 1. INTRODUZIONE
1.1 Feature Locali
Una feature locale è una parte di immagine che dierisce dalle zone circo-
stanti ad essa. Tipicamente è associata alla variazione di una o pi` u proprietà
dellimmagine, compresi intensità e colore. Le feature possono essere semplici
punti ma anche contorni o piccole zone dellimmagine stessa.
Di seguito diamo le possibili denizioni di edge e corner al ne di miglio-
rare lintera comprensione del testo.
Denizione 1.1.1 (Edge) Si parla di edge o contorno quando esiste un
conne tra due regioni di unimmagine.
In generale gli edge possono essere di qualsiasi forma. Una denizione pi` u
formale e adeguata al contesto della visione computazionale può essere:
Denizione 1.1.2 (Edge) Un edge o contorno è linsieme dei punti del-
limmagine il cui gradiente ha intensità elevata.
Anche i corner possono avere diverse interpretazioni:
Denizione 1.1.3 (Corner) Un corner o angolo è lintersezione di due
edge.
Oppure pi` u genericamente:
Denizione 1.1.4 (Corner) Un corner o angolo è un punto per il quale
esistono due edge nella zona circostante che hanno direzioni dierenti.
Le feature locali costituiscono un potente strumento che viene utilizzato
in unampia gamma di sistemi ed applicazioni. Le motivazioni di impiego
possono essere molteplici e dipendono dal contesto in cui si lavora. Per prima
cosa si può focalizzare linteresse su alcune tipologie di feature locali poiche
esse possono assumere particolari interpretazioni semantiche nel contesto di
una applicazione. Ad esempio gli edge rilevati da fotograe aeree possono
corrispondere a strade [71].
In secondo luogo le feature possono rappresentare un insieme limitato di
punti localizzati e individuabili singolarmente, tali che la loro posizione possa
2
essere valutata con precisione in ogni istante nel tempo. Questo è il caso delle
applicazioni di riconoscimento [9, 64] e tracciamento oggetti [36, 66].
Inne un insieme di feature locali può anche essere usato per la rappresen-
tazione di unimmagine che permetta di riconoscere oggetti o scene particolari
senza ricorrere alluso della segmentazione. In questo caso quindi lattenzio-
ne viene posta sullanalisi statistica dei punti caratteristici. Questo modo di
impiego delle feature locali è stato introdotto da Schiele e Crowley [55] e poi
anche da Schmid e Mohr [56].
Vale la pena ricordare il fatto che le feature locali hanno un ruolo centrale
anche nel riconoscimento di oggetti da parte del sistema visivo umano [11].
1.2 Estrattori di feature
Nel campo della visione computazionale e dellelaborazione di immagini, il
concetto di estrazione di feature si riferisce a quei metodi il cui scopo è quello
di analizzare i pixel presenti nellimmagine mediante operatori matematici
al ne di decidere sulla presenza dei punti di interesse cercati. Le feature
risultanti sono un sottoinsieme del dominio dellimmagine, spesso sotto forma
di punti isolati, curve continue oppure regioni interconnesse.
Gli estrattori di feature possono essere classicati in base al tipo di
caratteristica rilevata:
Rilevatori di contorni o edge;
Rilevatori di angoli o corner;
Rilevatori di regioni o blob;
Rilevatori di angoli
Il primo rilevatore di corner risale al 1977 per opera di Moravec [41, 42].
Lo scopo era quello di studiare la similarità tra una determinata zona e le
regioni circostanti ad essa, usando come misura la somme dei quadrati delle
dierenze. Beaudet propose una misura per il riconoscimento dei corner
basata sul determinante della matrice Hessiana [10].
3
Kitchen e Rosenfeld [34] furono i primi ad introdurre gli operatori della
geometria dierenziale per la risoluzione di questo tipo di problema. Il rile-
vamento in questo caso si basava sulla misura della direzione del gradiente
lungo un egde.
Harris e Stevens [23] introdussero un operatore, derivandolo dal rilevatore
di Moravec,che considera una nestra locale nellimmagine e determina la me-
dia delle variazioni di intensità ottenute traslando tale nestra di poche posi-
zioni nelle varie direzioni. Zheng and Wang [78] migliorarono questo metodo
proponendone una versione meno onerosa dal punto di vista computazionale.
Wang e Brady [72] proposero un metodo per rilevare i corner basato
sulla misurazione delle curvature superciali, agevolando inoltre lestrazione
in tempo reale.
Un algoritmo pi` u recente, il SUSAN [60], dà vita ad un nuovo tipo di
rilevatori di corner basati sul paragone di intensità di pixel allinterno di una
maschera circolare. Trajkovic e Hedley [70] hanno proposto un rilevatore
che usa la stessa intuizione delloperatore SUSAN ma con qualche dierenza,
vengono considerate le variazioni di intensità lungo ogni linea che attraversa
il punto preso in considerazione. Anni dopo viene introdotto lalgoritmo
FAST [51, 52], una versione rilassata del precedente metodo SUSAN, il quale
è particolarmente performante in termini di velocità di esecuzione e fornisce
ottimi risultati anche dal punto di vista della robustezza. La tecnica pi` u
recente appartenente a questo gruppo si chiama AGAST [39] che rappresenta
una versione di FAST adattiva.
Rilevatori di contorni
Alcuni rilevatori di edge basati su immagini a livelli di grigio furono sviluppati
negli anni 60 e 70, tra i pi` u famosi si citano Roberts [49], Prewitt [47] e
Sobel [62]. Questi semplici metodi vengono utilizzati ancora oggi in varie
applicazioni nonostante il successivo sviluppo di tanti altri rilevatori [26].
Loperatore di Canny [14] fa parte della categoria di questi operatori, tuttavia
è molto pi` u sosticato rispetto ai precedenti.
4
Per quanto riguarda le immagini a colori sono stati inizialmente propo-
sti metodi che estendevano le funzionalità dei precedenti operatori di Ro-
berts [18], Sobel e Canny. Altri metodi successivamente vennero sviluppati
basandosi su una analisi vettoriale dellimmagine, come il rilevatore MVD
(minimum vector dispersion) [69] e loperatore vettoriale range [68].
Altri metodi studiati riguardavano lanalisi della distanza Euclidea tra un
pixel e le zone circostanti [77], altri risolvevano il problema da un punto di
vista matriciale, analizzando gli autovettori [77], e altri ancora tentavano un
approccio basato sullentropia di una data regione rispetto ai vettori dello
spazio dei colori RGB dellimmagine [59].
1.3 Obiettivi
Lobiettivo del lavoro svolto è la progettazione di una applicazione per una
telecamera IP. Lo scopo principale di tale applicazione è lestrazione real-time
di feature di basso livello, quali corner e edge. In letteratura è presente una
notevole quantità di rilevatori di feature, tuttavia solo una parte di essi si pre-
sta allimpiego in unapplicazione che lavora in tempo reale. Lalgoritmo di
rilevamento corner chiamato FAST risulta particolarmente adatto allo scopo
grazie alla sua velocità di esecuzione. Tra gli obiettivi della tesi si include
anche la creazione di un algoritmo simile a FAST ma che si adatta meglio
alle speciche di qualità delloutput e di portabilità del codice. Loperatore
di Sobel, nonostante sia un metodo ormai datato, fornisce ottime prestazioni
per quanto riguarda lestrazione di edge.
Al ne di interpretare i dati prodotti dagli algoritmi si tenta di par-
tizionare le feature in cluster secondo il metodo tradizionale di clustering
k-means.
Un altro scopo della tesi è quello di realizzare un sistema client-server
nalizzato alla rappresentazione real-time delle feature rilevate su una pa-
gina Web, utilizzando le recenti tecnologie per il trasferimento dei dati e
studiando vari approcci ingegneristici per velocizzare i tempi di risposta
dellapplicazione.
5
1.4 Struttura della tesi
Il lavoro di tesi è organizzato in questo modo:
Capitolo 2: viene descritto lalgoritmo FAST per il rilevamento corner
e proposta una sua variante adatta al progetto, viene descritto un siste-
ma di rimozione dei non massimi e proposta una stima per laccuratezza
dei risultati ottenuti. Viene inoltre trattato largomento dellestrazione
dei contorni di unimmagine, specicando il funzionamento dellopera-
tore di Sobel e discusso un possibile metodo per elaborare ulteriormente
limmagine ottenuta mediante il rilevatore di edge.
Capitolo 3: viene discusso il concetto generale di data mining, detta-
gliando la parte riguardante il clustering e descrivendo il funzionamento
del k-means. Vengono discussi anche metodi possibili per linizializza-
zione degli algoritmi di partizionamento ed esposte alcune tecniche di
validazione dei cluster.
Capitolo 4: rappresenta la parte fondamentale del progetto, viene
mostrato il funzionamento dellapplicazione in tutte le sue componenti.
Viene anche descritta la parte riguardante la piattaforma della camera
Axis e viene discussa la recente tecnologia Web chiamata AJAX.
Capitolo 5: contiene alcuni risultati sperimentali sulla performance
dellapplicazione e sulla quantità di dati trasmessa.
Capitolo 6: si conclude la tesi secondo alcune considerazioni e vengono
proposte alcune tematiche per gli sviluppi futuri.
6
Capitolo 2
Rilevamento di feature
In questo capitolo vengono discusse in dettaglio alcune tecniche di rilevamen-
to di feature. In particolare viene studiato un recente algoritmo di estrazione
di corner particolamente veloce e viene proposta una variante che si adatta
meglio a qualsiasi tipo di immagine. Successivamente viene discusso anche
il problema di rilevamento degli edge, trattando tecniche tradizionali e stu-
diando alcuni metodi possibili per il trattamento delle immagini elaborate
dagli estrattori di edge.
2.1 FAST Corner Detection
Il rilevamento degli angoli o corner in un immagine è un approccio usato nei
sistemi di visione computazionale per estrarre alcune tipologie di informa-
zione e trarre conclusioni riguardo i contenuti di unimmagine. I rilevatori
presenti in letteratura in genere non sono molto robusti e nel caso in cui si
utilizzi algoritmi appartenenti allamibito di machine learning spesso si ri-
chiede una consistente supervisione durante lelaborazione. Un altro grosso
problema riguarda la velocità di esecuzione. Non tutti gli algoritmi presentati
sono veloci dal punto di vista computazionale e solo pochi di essi si prestano
ad elaborare i dati in applicazioni real-time.
Lalgoritmo FAST costituisce la base per la costruzione di un rilevatore
di angoli robusto e veloce. Questo metodo rappresenta una versione rilassata
7
CAPITOLO 2. RILEVAMENTO DI FEATURE
dellalgoritmo SUSAN.
In questa sezione verrà illustrato il funzionamento dellalgoritmo FAST,
le tecniche utilizzate per migliorare le sue prestazioni e verrà anche discusso
un metodo per la stima dellaccuratezza nel trovare gli angoli.
2.1.1 Cerchio di Bresenham
Lalgoritmo FAST elabora ogni pixel di unimmagine I, a meno di un sot-
toinsieme molto limitato di pixel, estraendo informazioni dai punti circostanti
ciascun pixel. Nel nostro caso, la zona dei punti adiacenti al pixel di interesse
p, si chiama cerchio di Bresenham.
Denizione 2.1.1 (Cerchio di Bresenham) Si denisce cerchio di Bre-
senham linsieme di punti che approssima un cerchio in un sistema di visua-
lizzazione composto da pixel.
Il cerchio, centrato in p e con raggio r, viene generato mediante un algoritmo
iterativo [13]. Lidea è quella di suddividere idealmente il cerchio in 8 ottanti,
creare il primo e generare i restanti basandosi sulla simmetria.
Siano x
p
e y
p
le coordinate del punto p, supponiamo di iniziare a generare
il cerchio da (x
p
+r, y
p
) andando in senso antiorario. Sotto queste condizioni
i candidati ad essere il prossimo punto del cerchio sono:
PixelNordOvest = (x
p
+ r 1, y
p
1)
PixelNord = (x
p
+ r, y
p
1)
Per selezionare il pixel corretto si considera il punto medio tra i due pixel
candidati: se questo cade allinterno del cerchio ideale si sceglie il PixelNord,
altrimenti se cade allesterno si sceglie il PixelNordOvest. La procedura viene
quindi iterata anche per i restanti punti dellottante e il cerchio quindi viene
completato come mostrato in gura 2.1.
Per lalgoritmo FAST viene scelto il cerchio di Bresenham con raggio 3,
quindi i pixel circostanti che vengono presi in esame sono 16. Per semplicità di
notazione, faremo riferimento ai pixel del cerchio in base alle loro posizioni
cardinali rispetto al centro del cerchio p, i pixel pi` u signicativi saranno
rappresentati dai quattro punti cardinali del cerchio:
8
Figura 2.1: Cerchio di Bresenham di raggio 3
p
N
di coordinate (x
p
, y
p
3).
p
W
di coordinate (x
p
3, y
p
)
p
S
di coordinate (x
p
, y
p
+ 3)
p
E
di coordinate (x
p
3, y
p
)
Poiche questi pixel saranno utilizzati per decidere come eettuare i test
dellalgoritmo FAST, verranno in seguito chiamati pixel di decisione. Una
modalità alternativa di notazione è quella di assegnare un numero ad ogni pi-
xel del cerchio, partendo da p
N
a cui viene assegnato il numero 1 e procedendo
in senso orario secondo lordinamento dei numeri naturali.
2.1.2 Il criterio Segment Test
Il criterio Segment Test è il principio su cui si basa lalgoritmo FAST [51].
Si considera un cerchio di Bresenham con raggio r uguale a 3, attorno ad un
angolo candidato p e si cerca larco pi` u lungo nel quale lintensità di ogni suo
pixel è maggiore di p di una certa soglia t, oppure lintensità di ogni pixel è
minore dellintensità di p dellla medesima soglia t. Sia n
c
il numero di pixel
contigui con questa proprietà e sia n una soglia pressata, se
n
c
n
allora p è un angolo.
9
Denizione 2.1.2 Siano a e b due pixel appartenenti ad unimmagine e
siano I(a) e I(b) rispettivamente le loro intensità. Si dice che a è pi` u chiaro
di b se I(a) > I(b). Analogamente si dice che a è pi` u scuro di b se I(a) <
I(b).
Sia I(p) lintensità del pixel p, allora si denisce il criterio Segment Test:
Denizione 2.1.3 (Criterio Segment Test) Esiste un angolo in p se, in
un cerchio di Bresenham di raggio r e centro in p, ci sono almeno n pixel i
quali sono tutti pi` u chiari di I(p) di una soglia t, oppure sono tutti pi` u scuri
di I(p) di una soglia t.
In gura 2.2 è mostrato un esempio relativo ai pixel contigui necessari anche
il criterio Segment Test dia esito positivo in base al numero n.
Figura 2.2: Esempio del criterio Segment Test per n = 9 e n = 12
2.1.3 Original FAST
Il criterio Segment Test è utilizzato per rilevare gli angoli in unimmagine,
tuttavia si possono usare metodi per velocizzare il procedimento, incremen-
tando quindi la performance. Sia n il numero minimo di pixel contigui richie-
sti anche p sia un angolo. Allora se di fatto p è un corner saranno necessari
almeno n test per determinarlo. Tuttavia saranno sucienti meno test nel
caso in cui p non è un angolo. Questo rappresenta il punto di partenza per
diminuire il carico computazionale dellalgoritmo.
10
Algoritmo 1 Original FAST n = 12 and r = 3
Examine pixel N and S
if [I(p) - I(p
N
)[ < t e [I(p) - I(p
S
)[ < t
p not a corner
Examine pixel E
if 2 o more pixels are brighter than p by t
if Only 2 pixels are brighter than p by t
Examine pixel W
if 3 pixels are brighter than p by t
Execute Segment Test Criterion
else
p not a corner
else if 2 o more pixels are darker than p by t
if Only 2 pixels are darker than p by t
Examine pixel W
if 3 pixel are darker than p byt
else
p not a corner
11
Consideriamo a tal proposito due pixel diametralmente opposti del cerchio
di Bresenham p
N
e p
S
. Se entrambi hanno intensità tale che:
[I(p) I(p
N
)[ < t e [I(p) I(p
S
)[ < t
allora, dato n
NS
il numero di pixel compreso tra p
N
e p
S
, p non può essere un
angolo se n è maggiore di n
NS
. Nel nostro caso, poiche il raggio del cerchio
di Bresenham è lungo 3, il numero di pixel totale è 16 e quindi si avrà che il
numero di pixel compresi tra due estremi opposti del cerchio n
NS
è pari a 7.
Mediante unaccurata selezione dellordine in cui vengono eseguiti i test
si ottengono risultati migliori in termini di performance. Lordine dei test
dipende dal valore di n, il numero di pixel contigui richiesto perche p si clas-
sicato come angolo. Tuttavia si devono limitare le possibilità sulla scelta
di n in quanto ci sono valori per cui lalgoritmo FAST non funziona bene,
ovvero non riconosce correttamente gli angoli presenti allinterno dellimma-
gine. Infatti per n < 9, si ha un vincolo troppo debole, oltre che agli angoli
vengono rilevati anche gli edge. Al contrario, se n > 12 il vincolo è troppo
forte, quindi tutti gli angoli meno acuti dellimmagine vengono ignorati. Nel
caso in cui n sia uguale a 12, verrà eseguito lAlgoritmo 1 [50]. Seguendo
queste regole si ottiene un metodo molto performante per il rilevamento degli
angoli, tuttavia mostra alcuni limiti:
1. Vengono rilevati pi` u angoli adiacenti.
2. Lordine dei test usato per n = 12, non generalizza bene per n < 12.
3. La scelta e lordine dei test contiene assunzioni implicite riguardo a
come langolo appare nellimmagine.
4. La conoscenza appresa svolgendo i primi 4 test diventa inutile una volta
eseguito il Segment Test.
Il problema del punto numero 1 verrà trattato e risolto nella sezione Punteggio
e soppressione dei non massimi, per il problema posto al punto 2 verrà invece
proposto un algoritmo originale, che deriva dal metodo appena proposto,
nella sezione Generic Fast, inne i problemi dei punti 3 e 4 verranno trattati
nella sezione Learned Fast.
12
2.1.4 Generic FAST
Utilizzando lAlgoritmo Original FAST per n minore di 12, si ottengono
pessimi risultati in quanto tanti angoli non vengono riconosciuti. Il motivo
risiede nel fatto che nellalgoritmo originale per eettuare il criterio Segment
Test, e quindi per riconoscere che il pixel in questione è un angolo, è necessario
che almeno 3 pixel dei 4 scelti sul cerchio di Bresenham abbiano unintensità
maggiore del pixel centrale pi` u una soglia. Tuttavia se n è minore di 12,
saranno sucienti 2 di essi per potersi candidare ad essere corner.
Consideriamo a tal proposito i 4 pixel di decisione p
N
, p
W
, p
S
e p
E
.
Se di questi solo 2 superano il test ma sono diametralmente opposti, allora
necessariamente p necessariamente non potrà essere un corner. Al contrario,
se 2 pixel di decisione su 4 passano il test e non sono situati ai lati opposti del
cerchio di Bresenham, allora p può essere un angolo, quindi verrà eseguito il
criterio Segment Test per stabilire se il pixel è etichettabile come corner. A
causa di questa condizione pi` u ristretta, ovvero il fatto che sono sucienti 2
pixel di decisione su 4 invece dei 3 rispetto alla versione originale, comporta
il fatto che il criterio Segment Test venga eseguito pi` u frequentemente. La
conseguenza immediata di questo fenomeno è ovviamente un leggero calo di
performance, tuttavia molto attenuato dal fatto che se da una parte il criterio
viene eseguito pi` u volte rispetto allalgoritmo Original FAST, dallaltra i pixel
richiesti da esso per vericare lesistenza del corner sono di meno. Lo pseudo-
codice dellalgoritmo è mostrato in Algoritmo 2 mentre il codice scritto in
C++ si trova nellappendice A.
Come nellalgoritmo originale, la procedura viene eseguita per ogni pixel
dellimmagine ma in questo caso i risultati sono migliori. Come si può vedere
dalla gura 2.3, il Generic FAST rileva perfettamente tutti i corner delle
forme allinterno dellimmagine, mentre lalgoritmo originale non riesce ad
estrarre gli angoli della stella ad otto punte, in quanto hanno unampiezza
troppo elevata per superare il test dei 12 pixel.
13
Algoritmo 2 Generic FAST n = 9 and r = 3
Examine pixel N and S
if [I(p) - I(p
N
)[ < t e [I(p) - I(p
S
)[ < t
p not a corner
Examine pixel E
if 1 or more pixels are brighter than p by t
if Only 1 pixel are brighter than p by t
Examine pixel W
if 2 pixels or more are brighter than p by t
if Only 2 pixels are brighter than p by t
if pixels are diametrically opposed and W not examined
p not a bright corner
else
else
p not a bright corner
if 1 or more pixels are darker than p by t and p not a bright corner
if Only 1 pixel are darker than p by t
Examine pixel W
if 2 pixels or more are darker than p by t
if Only 2 pixels are darker than p by t
if pixels are diametrically opposed and W not examined
p not dark a corner
else
else
p not a dark corner
14
(a) Generic FAST (n = 9)
(b) Original FAST (n = 12)
Figura 2.3: Algoritmi FAST a confronto
15
2.1.5 Learned FAST
Un altro approccio al problema del riconoscimento degli angoli è basato sul-
lapprendimento automatico. Rosten [52] propone un metodo composto da
2 fasi. Per costruire un buon rilevatore, ssato n e unopportuna soglia t,
gli angoli vengono rilevati da un insieme di immagini denite a priori (pre-
feribilmente prese dal contesto in cui si deve lavorare). Il passo successivo è
quello di eseguire un algoritmo lento che testa tutti i 16 pixel del cerchio di
Bresenham per ogni pixel dellimmagine.
I pixel circostanti p presi in esame possono trovarsi in 3 stati diversi:
Pi` u chiaro di p;
Pi` u scuro di p;
Simile a p,
Formalizzando, sia S
x
lo stato del pixel p
x
, con x 0..16, allora:
S
x
=
_
_
b, I
x
I
p
t (Chiaro)
d, I
x
I
p
+ t (Scuro)
s, I
p
t < I
x
< I
p
+ t (Simile)
(2.1)
Scegliendo un x, si calcola S
x
per ogni p P, dove P rappresenta linsieme di
tutti i pixel di ogni immagine del set iniziale. Il passo successivo è quello di
partizionare P in tre sottoinsiemi P
b
, P
d
e P
s
, dove ogni pixel p è assegnato
a P
S
x
.
Sia K
p
la variabile booleana che indica vero se p è un angolo e falso
altrimenti. La seconda fase del metodo prevede di utilizzare lalgoritmo ID3,
selezionando allinizio la x che contiene la maggior quantità di informazioni
riguardo alla caratteristica di essere un angolo, misurata dallentropia di K
p
.
Lentropia K per linsieme P viene calcolata come:
H(P) = (c + c) log
2
(c + c) c log
2
c c log
2
c
dove c = p[K
p
vero (numero di angoli)
e c = p[K
p
falso (numero di non angoli)
(2.2)
16
La scelta di x determina quindi il guadagno di informazione:
H(P) H(P
d
) H(P
b
) H(P
s
) (2.3)
Avendo selezionato la x che massimizza il guadagno di informazione, il pro-
cesso viene applicato ricorsivamente su tutte le tre partizioni, ovvero x
b
viene
selezionato per partizionare P
b
in P
b,d
, P
b,s
e P
b,b
e cos` via, dove ogni x vie-
ne scelta in modo da massimizzare il guadagno di informazione relativo alla
partizione a cui si riferisce. Questo procedimento termina quando lentro-
pia di una partizione è nulla, ovvero quando tutti i p in questo sottoinsieme
hanno lo stesso valore di K
p
. Questo procedimento crea un albero di decisio-
ne che può classicare correttamente tutti gli angoli rilevati nellinsieme di
apprendimento e che quindi contiene implicitamente le regole del rilevatore
di angoli prescelto. Il fatto che i dati di allenamento non contengono una
copertura completa su tutti gli angoli possibili implica che questo metodo di
rilevamento non è del tutto uguale al metodo che usa il Segment Test, quindi
i risultati non saranno uguali. Una buona tecnica per migliorare la qualità
dei dati estratti è quella di modicare leggermente lalbero di decisione ot-
tenuto in seguito allapprendimento, in modo che esso dia gli stessi risultati
del Segment Test sullinsieme di immagini iniziale.
2.1.6 Punteggio e soppressione dei non massimi
Il criterio Segment Test tende a rilevare tanti angoli adiacenti lun laltro,
quindi per trovare un unico candidato di un gruppo di angoli adiacenti biso-
gna usare un metodo per assegnare un punteggio a ciascuno di essi, scegliere
quello con punteggio migliore e rimuovere tutti gli altri.
Punteggio
Lidea è quella di trovare una funzione V che per ogni angolo rilevato me-
diante il criterio Segment Test, assegni un punteggio in modo da scegliere il
migliore in un intorno scelto a priori. Ci possono essere pi` u modi per denire
V:
1. Il valore pi` u alto di n tale che p sia rilevato come angolo.
17
2. Il valore pi` u alto di t tale che p sia rilevato come angolo.
3. La somma delle dierenze di intensità in valore assoluto tra i pixel
nellarco contiguo e il pixel centrale.
Le denizioni dei punti 1 e 2, nonostante la semplicità di implementazione,
non sono adatte come funzione di punteggio in quanto sono grandezze for-
temente quantizzate, ovvero in prossimità di un gruppo di angoli molti di
questi avranno lo stesso punteggio e non sarà possibile scegliere un singolo
candidato. La soluzione quindi è selezionare la terza denizione, con qual-
che modica per incrementare la performance. Lidea è quella di trovare la
massima soglia per cui langolo viene rilevato ancora come tale. Infatti se
la soglia t è suciente per annotare un pixel come angolo, non è detto che
anche la soglia t + 1 lo sia. Allora quello che accade è una ricerca binaria
della soglia massima, ripetendo ciclicamente lalgoritmo FAST utilizzato per
rilevare gli angoli nche tale soglia non viene rilevata. Quel valore sarà il
punteggio dellangolo, in generale dierente dai vicini. Formalizzando:
V = max
_
xB
[I
x
I
p
[ t,
xD
[I
x
I
p
[ t
_
(2.4)
dove
B = x[I
x
I
p
+ t (Pixel chiari)
D = x[I
x
I
p
t (Pixel scuri)
Se viene utilizzata la versione Generic FAST esiste un ulteriore accorgimento
da fare per migliorare la performance. Il problema risiede nella duplice natura
degli angoli, che posso essere chiari o scuri. Quando deve essere assegnato un
punteggio agli angoli, si è già a conoscenza di questa loro proprietà. Quindi
quando si esegue il criterio Segment Test, lo si eettua in base alla natura
dellangolo, evitando cos` un deterioramento di performance.
Soppressioni dei non massimi
Una volta assegnato il punteggio a ciascun corner, si può procedere con leli-
minazione dei non-massimi, ovvero di quei corner che non rappresentano un
18
punto di massimo locale rispetto ai vicini. La tecnica usata è quella di fare
scorrere sopra ogni candidato una nestra 3x3 di pixel e guardare se ci sono
altri angoli in tale zona. Se sono presenti allora si mettono a confronto i pun-
teggi ottenuti in precedenza, quindi nel caso ne trovasse almeno uno con un
punteggio superiore, langolo al centro della nestra 3x3 viene rimosso dalla
lista. Alla ne rimarranno solo i massimi locali in ogni regione dellimmagine
come mostrato in gura 2.4
Figura 2.4: Leetto delleliminazione dei non massimi
2.1.7 Stima di ripetitività
La ripetitività indica che il rilevamento di feature è indipendente dai cambia-
menti delle condizioni di una data immagine, in questo caso di angoli. Tali
condizioni possono essere i parametri della camera utilizzata, la posizione di
essa rispetto alla scena, le variazioni di luminosità e il rumore presente. Un
rilevatore di angoli è ben costruito se in due dierenti immagini, prese sulla
stessa scena, rileva gli stessi punti caratteristici in entrambe.
Il tasso di ripetitività è denito come il numero di punti che si ripetono
in due immagini sul numero totale di punti rilevati [57]. Per misurare il
19
numero totale di punti rilevati bisogna tenere conto che le immagini che
stanno riprendendo la medesima scena possono dierire, come nel caso in
cui esse siano state riprese da due punti di vista diversi oppure nel caso in
cui una delle due sia ridotta in scala rispetto allaltra. In presenza di tali
eventi esistono dei punti che potrebbero non essere osservabili in entrambe
le immagini, quindi si avrebbe un condizionamento negativo sulla misura del
tasso di ripetitività. In questi caso quindi vengono considerati esclusivamente
i punti che giacciono sulla medesima scena.
Esiste unaltra considerazione da fare, ovvero quella dellincertezza del
rilevamento. Può accadere che un punto rilevato su una prima immagine
non cada esattamente dove previsto sulla seconda immagine, ma in una zona
vicina. Larea di questo intorno si denota con e quindi considerando questa
eventualità si parla di -ripetitività.
Nel caso in cui si desideri vericare la ripetitività di due immagini che
dieriscono per il punto di vista, ovvero se si è nelle condizioni in cui una
scena viene ripresa da due angolazioni diverse, allora sarà necessario che esse
siano in relazione mediante una omograa.
2.2 Rilevamento dei contorni
I contorni di unimmagine, detti anche edge fanno parte di quelle caratte-
ristiche che rappresentano la struttura e le proprietà di un oggetto in una
scena. Bruschi cambiamenti delle proprietà di unimmagine indicano in gene-
re eventi o cambiamenti importanti del mondo sico di cui le immagini sono
la rappresentazione. Questi cambiamenti possono essere ad esempio: discon-
tinuità della profondità, discontinuità dellorientamento delle superci, mo-
dica delle proprietà dei materiali, e variazioni dellilluminazione proveniente
dallambiente circostante.
Esistono molti metodi per rilevare gli edge, in generale è possibile classi-
carli in due categorie: metodi basati sulla ricerca e metodi basati sullat-
traversamento dello zero. I metodi basati sulla ricerca rilevano i contorni
cercando i massimi ed i minimi della derivata del primo ordine dellimmagi-
ne, di solito cercando la direzione in cui si ha il massimo gradiente locale. I
20
metodi basati sullattraversamento dello zero cercano i punti in cui la deri-
vata del secondo ordine passa per lo zero, solitamente la funzione laplaciana
o unespressione dierenziale di una funzione non-lineare. Loperatore di
Sobel [62] fa parte della prima categoria.
In questa sezione verrà introdotto il concetto di gradiente, verranno il-
lustrati i passi fondamentali delledge detection e successivamente verrà de-
scritto il funzionamento delloperatore di Sobel sia dal punto di vista pratico
che da quello matematico. Inne verranno discussi metodi per trattare i
risultati delloperatore di Sobel, come la binarizzazione dellimmagine e la
quantizzazione.
2.2.1 Gradiente
Il gradiente di una funzione f(x) indica come essa cambia al variare della
x. Si può pensare ad un immagine come un array di campioni di qualche
funzione continua che rappresenta lintensità dellimmagine. Quindi per ana-
logia cambiamenti signicativi tra i valori di grigio di unimmagine possono
essere rilevati utilizzando unapprossimazione discreta del gradiente. Il gra-
diente è lequivalente bidimensionale della derivata prima di una funzione ed
è denito dal vettore:
f(x, y) = G[f(x, y)] =
_
G
x
G
y
_
=
_
f
x
f
y
_
(2.5)
Ci sono due importanti proprietà associate al gradiente:
1. Il vettore G[f(x, y)] punta in direzione del tasso di massimo incremento
della funzione f(x, y).
2. La norma del gradiente data da
_
G
2
x
+ G
2
y
, equivale al tasso di massimo
incremento di f(x, y) per distanza unitaria nella direzione del gradiente
G.
Ad ogni modo è di uso comune approssimare la norma del gradiente come:
|G| [G
x
[ + [G
y
[ (2.6)
21
La direzione del gradiente è denita da:
(x, y) = arctan
_
G
y
G
x
_
(2.7)
dove langolo è misurato rispetto allasse x.
Approssimazione del gradiente
Per le immagini digitali, le derivate nellequazione 2.5 sono approssimate
mediante dierenze. La pi` u semplice tra le possibili approssimazioni del
gradiente è:
G
x
f[i, j + 1] f[i, j] (2.8)
G
y
f[i, j] f[i + 1, j] (2.9)
tenendo conto che j corrisponde alla direzione positiva sulle x e i alla quella
negativa sulle y. Tutto questo può essere implementato mediante le maschere
di convoluzione:
G
x
=
_
1 1
_
G
y
=
_
1
1
_
(2.10)
Quando viene calcolata lapprossimazione del gradiente è di fondamentale
importanza che le derivate parziali rispetto a x e y siano calcolate esattamente
nella stessa posizione nello spazio. Tuttavia, usando queste approssimazioni
G
x
è lapprossimazione del gradiente nel punto interpolato
_
i, j +
1
2
_
e G
y
quella in
_
i +
1
2
, j
_
.
Per questa ragione vengono usate le matrici di convoluzione 22 piuttosto
che le 2 1 e 1 2:
G
x
=
_
1 1
1 1
_
G
y
=
_
1 1
1 1
_
(2.11)
In questo modo i punti sui quali viene calcolato il gradiente rispetto a x e a
y coincidono nella stessa posizione. Il punto però giace in mezzo ai 4 pixel
nellintorno 22 nella posizione interpolata
_
i +
1
2
, j +
1
2
_
. Questa situazione
può generare qualche ambiguità, quindi la procedura classica è quella di
utilizzare un approccio alternativo basato sulle matrici di convoluzione 3 3
22
e calcolare il gradiente del pixel centrale. Questo metodo è quello utilizzato
nelloperatore di Sobel che verrà descritto in seguito.
2.2.2 Sviluppo del rilevamento contorni
In generale prima di eseguire il vero e proprio algoritmo di rilevamento dei
contorni, le immagini vengono trattate con tecniche apposite in modo da
migliorare la qualità dei risultati. Queste fasi preliminari sono opzionali, è
possibile procedere direttamente col rilevamento dei contorni ma si otterrà
una immagine di qualità peggiore.
Rimozione del rumore
Poiche il calcolo del gradiente basato sui valori dellintensità di solo due punti
è molto sensibile al rumore, in genere limmagine viene ltrata per miglio-
rare la qualità dei risultati di rilevamento. I ltri utilizzati possono essere
diversi, in genere si sceglie quello pi` u adatto per il tipo di rumore presente
nellimmagine. Tuttavia esiste un trade-o tra lintensità dei contorni e la
riduzione di rumore, infatti aumentando il ltraggio si ottengono contorni
meno marcati.
Miglioramento dellimmagine
Per facilitare il rilevamento dei contorni, è necessario determinare i cam-
biamenti di intensità nelle zone adiacenti ad un punto preso in esame. Il
miglioramento dellimmagine enfatizza quei pixel dove esiste un signicativo
cambiamento nei valori dellintensità in un dato intorno. In questo modo
limmagine si adatta meglio allo scopo dellapplicazione. Una tecnica comu-
ne di miglioramento è detta contrast stretching che ha lo scopo di aumentare
la dinamica dellimmagine il cui istogramma è concentrato in un intervallo
limitato dei valori possibili.
23
Rilevamento
Una volta eseguiti i due passi precedenti si esegue lalgoritmo vero e proprio
di rilevamento. Quello che viene richiesto consiste nel trovare quei punti ad
alto contenuto di edge. Tuttavia alcuni pixel hanno valore diverso da zero
per il gradiente, e non tutti rappresentano un contorno per una particolare
applicazione. Quindi vengono usati alcuni metodi per determinare quali punti
sono edge, come ad esempio il Thresholding.
2.2.3 Operatore di Sobel
Loperatore di Sobel è uno dei rilevatori di contorni pi` u utilizzati. Esso
fornisce unapprossimazione poco accurata del gradiente dellimmagine, ma
è comunque di qualità suciente per poter essere utilmente usato in molte
applicazioni. Un altro fattore molto importante è la sua velocità di esecuzione
che è un requisito fondamentale per le applicazioni real-time.
Loperatore applica due matrici di convoluzione 3 3 allimmagine ori-
ginale per calcolare valori approssimati delle derivate, una in direzione oriz-
zontale ed una in direzione verticale. Se chiamiamo I limmagine sorgente,
e G
x
e G
y
le due immagini i cui punti rappresentano rispettivamente i va-
lori approssimati delle derivate in orizzontale ed in verticale, loperazione è
descritta da:
G
x
=
_
_
1 0 +1
2 0 +2
1 0 +1
_
_
I e G
y
=
_
_
1 2 1
0 0 0
+1 +2 +1
_
_
I (2.12)
dove indica loperatore di convoluzione.
Combinando le due approssimazioni derivative ottenute in ogni pixel
dellimmagine si ottiene quindi la norma del vettore gradiente:
|G| =
_
G
2
x
+ G
2
y
(2.13)
Limmagine ottenuta è quindi la composizione delle due immagini ottenute
calcolando il gradiente in una singola direzione, una volta rispetto allasse
orizzontale ed una rispetto allasse verticale, come si può vedere in gura
2.5.
24
(a) Immagine originale (b) Operatore di Sobel
(c) Gradiente orizzontale normaliz-
zato
(d) Gradiente verticale normalizzato
Figura 2.5: Il funzionamento delloperatore di Sobel e le componenti del
gradiente
25
In questo modo è possibile creare unimmagine composta dai valori risul-
tanti delloperatore. Infatti se questo algoritmo di rilevazione viene eseguito
su unimmagine a 256 livelli di grigio, quello che si ottiene è una nuova
immagine dove i valori della norma del gradiente rappresentano lintensità
dei nuovi pixel. Nel caso in cui la norma risultasse maggiore dellintensità
massima, il valore del pixel verrà posto al massimo consentito dalla scala di
grigi.
Da un punto di vista formale, poiche la funzione che denisce lintensità
luminosa di unimmagine digitale è nota solo in punti discreti, le derivate
di questa funzione non possono a rigore essere denite a meno di assume-
re lesistenza di una sottostante funzione luminosità continua che sia stata
campionata nei punti dellimmagine. Con alcune altre assunzioni la deriva-
ta della funzione luminosità può essere calcolata come funzione della stessa
immagine digitale. Quindi i valori del gradiente in ogni pixel dellimmagine
sono funzioni dei valori della luminosità in quel punto.
2.2.4 Quantizzazione
I risultati delloperatore di Sobel possono essere trattati in modo da enfatiz-
zare le caratteristiche degli edge, ma anche in modo da creare una sorta di
suddivisione dellimmagine in aree nelle quali le variazioni di grigi avvengono
lentamente. Il metodo utilizzato si chiama quantizzazione e in questo caso è
applicato ad un immagine in scala di grigi.
Formalmente, sia n il numero di bit usato per rappresentare limmagine,
allora il numero totale di livelli di grigio che descrive limmagine sarà dato
da:
N = 2
n
(2.14)
Per rappresentare limmagine ottenuta dalloperatore di Sobel servono 8 bit
per pixel, quindi ci saranno 256 grigi in totale. Se vogliamo rappresentare la
stessa immagine con meno bit allora sarà necessario quantizzare limmagine
appropriatamente. Sia f(x, y) la funzione che indica il valore dellintensità
del pixel situato nelle coordinate x e y, e sia l il numero di bit desiderato per
rappresentare limmagine iniziale di b = 8 bit. Allora denito d = b l come
26
(a) Originale (b) Sobel (c) 7 bit
(d) 6 bit (e) 5 bit (f ) 4 bit
(g) 3 bit (h) 2 bit (i) 1 bit
Figura 2.6: Quantizzazione dellimmagine ottenuta con Sobel
la dierenza tra il numero di bit delle due rappresentazioni si ottiene che:
q(x, y) =
f(x, y)
2
d
| (2.15)
sarà la funzione che ad ogni pixel assegna una classe di appartenenza nella
scala quantizzata, ovvero un valore intero compreso tra 0 e 2
l
1. In base
a questi valori discreti trovati, quindi è possibile assegnare i nuovi valori di
grigi per visualizzare limmagine quantizzata, secondo la formula:
f
q
(x, y) = q(x, y) 2
d
+ 2
d1
(2.16)
27
Un eetto che si ottiene è sicuramente un peggioramento della qualità
dellimmagine, infatti appaiono dei falsi contorni e non è pi` u possibile distin-
guere due oggetti che dieriscono per variazioni di grigi della stessa classe di
appartenenza. Daltra parte si osserva un notevole risparmio nella codica
dellimmagine poiche i livelli di grigio da memorizzare saranno minori rispet-
to allo stato di partenza di 256 colori in modo proporzionale al numero di bit
utilizzati nellimmagine quantizzata. Nella gura 2.6 si nota come variano le
immagini elaborate in base al livello di grigi scelto. Si osservi che le die-
renze tra le immagini con pi` u di 32 colori sono quasi impercettibili allocchio
umano.
Thresholding
Esiste un approccio particolare nel caso in cui si intenda quantizzare lim-
magine sorgente con un solo bit, ovvero quando un pixel o assume valore
0 (nero) oppure assume valore 1 (bianco). Si tratta della binarizzazione
dellimmagine, che può essere eseguita con il metodo della quantizzazione
precedentemente descritto, oppure possono essere fatte ulteriori osservazioni.
Dovendo trattare un immagine modellata dalloperatore Sobel, si cerca di
utilizzare la binarizzazione per esaltare le caratteristiche dei contorni, quindi
di fatto assegnando un valore a ciò che è ritenuto un edge e laltro valore a
ciò che non lo è ritenuto. Questa selezione può essere fatta in maniera molto
semplice introducendo una soglia t. La tecnica in questione viene chiamata
sogliatura o thresholding.
Limmagine su cui viene eseguita la sogliatura diventa una funzione cos`
denita:
f
t
(x, y) =
_
_
_
0 f(x, y) < t
1 altrimenti
(2.17)
Nelle implementazioni pi` u semplici i pixel neri rappresentano lo scenario del-
limmagine, mentre quelli bianchi sono in primo piano. Poiche stiamo trat-
tando edge nel nostro caso, è utile invece invertire le parti, evidenziando i
contorni col nero e lasciare lo sfondo bianco. Rimane da decidere come sce-
gliere t in modo che risulti la migliore soglia per mettere in rilievo i contorni
28
estratti dalloperatore di Sobel. Esistono diversi metodi in letteratura per
scegliere il parametro automaticamente. Una semplice tecnica consiste nello
scegliere il valore medio o il valore mediano tra i valori presenti nellimmagi-
ne. Otsu [44] propone un metodo di scelta adattivo, ponendo come obiettivo
la minimizzazione della somma pesata delle varianze delle due classi (bianco
e nero). Sauvola [54] utilizza un metodo computazionalmente pi` u oneroso,
ma di qualità superiore che prevede il calcolo della media e della deviazione
standard dellintensità dei pixel appartenenti allimmagine. Tipicamente si
cerca di calcolare la soglia in modo che gli edge risultino il 30% del numero
totale dei pixel. In gura 2.7 si nota come gli egde siano pi` u netti e marcati
allaumentare della soglia.
(a) t = 64 (b) t = 128 (c) t = 192
Figura 2.7: Thresholding dellimmagine al variare della soglia t
29
Capitolo 3
Data mining
Il data mining è una scienza piuttosto recente che comprende vari campi di
studio dellinformatica. Consiste nel processo di estrazione di nuove informa-
zioni da grandi quantità di dati, includendo metodi statistici oppure tecniche
derivate dallintelligenza articiale, ma anche dalla gestione dei database.
A dierenza dellapprendimento automatico lattenzione viene focalizzata
sulla ricerca di informazioni ancora non conosciute piuttosto che generaliz-
zare modelli conosciuti a nuovi insiemi di dati. Lattuale scopo del data
mining è lanalisi automatica o semiautomatica di grandi quantità di da-
ti per estrarre modelli precedentemente sconosciuti come il raggruppamento
dei dati (clustering), avvenimenti insoliti (rilevamento anomalie) oppure ge-
nerazione di dipendenze fra i dati(regole di associazione). Le informazioni
estratte possono essere viste come una sintesi delle caratteristiche dei dati in
ingresso e utilizzate successivamente per ulteriori analisi oppure come esempi
nel campo dellapprendimento automatico.
I due primari obiettivi del data mining tendono ad essere la predizione e
la descrizione. La predizione implica lutilizzo di variabili dellinsieme di dati
per prevedere valori ancora sconosciuti oppure valori che alcune variabili di
interesse assumeranno in futuro. Daltra parte la descrizione concentra la sua
funzione nel trovare modelli che descrivano i dati che in seguito possano essere
interpretati dagli umani. Sotto queste assunzioni è possibile suddividere il
campo delle attività del data mining in due categorie principali:
30
CAPITOLO 3. DATA MINING
1. Data mining predittivo: produzione del modello del sistema descrit-
to dallinsieme dei dati fornito.
2. Data mining descrittivo: produzione di informazioni nuove e non
banali basate sullinsieme dei dati fornito.
Limportanza relativa di predizione e descrizione in particolare applica-
zioni del data mining può variare notevolmente a seconda del problema. Gli
obiettivi di descrizione e predizione vengono raggiunti in seguito allutilizzo
di varie tecniche che Kantardzic [29] suddivide in 6 categorie:
1. Classicazione: ricerca di una funzione di apprendimento predittiva
che classica gli oggetti in una o pi` u classi predenite.
2. Regressione: ricerca di una funzione di apprendimento predittiva che
associ un elemento dellinsieme di dati ad una variabile di predizione a
valori reali.
3. Clustering: problema descrittivo in cui si cerca di identicare un
insieme nito di categorie o settori per descrivere i dati.
4. Sommarizzazione: problema descrittivo che comprende metodi per
trovare una descrizione compatta dellinsieme dei dati.
5. Dependency modeling: ricerca di un modello locale che descrive
dipendenze signicative tra le variabili o tra i valori di una caratteristica
in un insieme di dati.
6. Rilevamento cambiamenti e deviazioni: rilevamento dei cambia-
menti pi` u signicativi in un insieme di dati.
In questo capitolo verrà discusso il problema descrittivo del clustering e in
particolare verrà descritto il funzionamento dellalgoritmo k-means e una sua
inizializzazione ottimale. In seguito verrà trattato il problema della selezione
del numero di cluster e la rappresentazione di questi su unimmagine.
31
3.1 Clustering
Il clustering è un insieme di tecniche il cui scopo è assegnare un insieme di
oggetti ad un certo numero di gruppi, chiamati cluster o settori, in modo che
gli oggetti allinterno di uno stesso cluster siano pi` u simili tra loro rispetto
agli oggetti allinterno degli altri settori.
Gli algoritmi di clustering dieriscono signicativamente tra di loro in
base alla denizione stessa di cluster. Le tipiche denizioni di settore variano
in base al problema proposto: gruppi entro i quali i propri membri hanno
distanza minima fra di loro, aree dense allinterno dellinsieme di dati iniziale,
intervalli o particolari distribuzioni statistiche.
Il signicato di cluster varia a seconda dellalgoritmo utilizzato ed è una
delle molte decisioni da prendere quando si deve selezionare la migliore tec-
nica per il risolvere il particolare problema. I modelli di cluster si possono
dierenziare in base alle seguenti dicotomie:
Agglomerativo/Divisivo: Questo aspetto è relativo alla struttura e
alle operazioni dellalgoritmo. Un approccio agglomerativo inizia con
molteplici cluster di un solo elemento e successivamente unisce i settori
insieme no a quando non si verica una determinata condizione di
stop. Al contrario un approccio divisivo inizia con tutti gli oggetti
allinterno di un singolo cluster, quindi inizia a dividersi in pi` u settori
no a quando non si verica un data condizione di arresto.
Monotetico/Politetico: Questo aspetto si riferisce allutilizzo se-
quenziale o simultaneo degli oggetti. La maggior parte degli algoritmi
ha un approccio politetico, ovvero ogni oggetto è partecipe nel calcolo
della distanza tra settori, e le decisioni vengono prese in base a ta-
li distanze. Gli algoritmi monotetici invece considerano gli oggetti in
sequenza per dividere il data set nei vari settori.
Hard/Fuzzy: Unclustering di tipo hard assegna ogni oggetto ad un
singolo cluster durante le sue operazioni e anche alle ne del processo
nel suo output. Un clustering di tipo fuzzy assegna un grado di appar-
tenenza ad alcuni settori ad ogni oggetto dellinsieme iniziale. Si può
32
passare dal tipo fuzzy allaltro tipo diclustering assegnando ad ad ogni
oggetto il settore con il maggior grado di appartenenza.
Deterministico/Stocastico: Questo problema è il pi` u rilevante tra
gli approcci di partizionamento per ottimizzare lerrore quadratico di
una funzione. Lottimizzazione può essere ottenuta utilizzando le tecni-
che tradizionali oppure tramite una ricerca aleatoria nello spazio degli
stati che consiste nellinsieme totale delle possibili label.
Incrementale/Non-incrementale: Questo problema sorge nel caso
in cui linsieme di oggetti da essere partizionato è ampio e quindi i
vincoli sul tempo di esecuzione o sullo spazio di memoria inuiscono
sullarchitettura dellalgoritmo. Lavvento del data mining ha favorito
lo sviluppo di algoritmi diclustering che minimizzano il numero di ite-
razioni sullinsieme di oggetti durante lesecuzione, oppure che riducono
lampiezza delle strutture dati usate nelle operazioni dellalgoritmo.
Ad ogni modo la costruzione di un algoritmo diclustering lascia molta essi-
bilità nel decidere la sua implementazione.
3.1.1 Misura di clustering
Come è stato detto in precedenza, lo scopo delclustering è di identicare un
numero opportuno di gruppi tali che gli elementi appartenenti ad un gruppo
siano in qualche modo pi` u simili tra loro che non agli oggetti appartenenti
ad altri gruppi. Si necessita quindi di una denizione di similarità o distanza
tra oggetti per sviluppare gli algoritmi. In base ai dati dellinsieme iniziale si
hanno misure dierenti, infatti nel caso di dati quantitativi si usano misure
di distanza mentre se siamo in presenza di dati qualitativi abbiamo bisogno
di misure di associazione.
Sia X la matrice dei dati che identica i valori dellinsieme di elementi
di partenza. Tale matrice ha n righe pari al numero totale di elementi e m
colonne, una per ogni variabile descrive lelemento da elaborare.
33
Misura di distanza
Supponendo che le m variabili della matrice X siano numeri e non attributi,
si può denire la distanza tra due unità p e q in diversi modi:
Distanza Euclidea:
d(p, q) =
_
n
i=1
(p
i
q
i
)
2
(3.1)
Distanza Manhattan:
d(p, q) =
n
i=1
[p
i
q
i
[ (3.2)
Distanza Mahalanobis [38](vettoriale):
d(p, q) =
_
(p q)
T
S
1
(p q) (3.3)
dove S è la matrice di covarianza tra le componenti dei due vettori.
Misura di associazione
Nel caso in cui non si stia trattando dati quantitativi ma dati che rappresen-
tano attributi bisogna usare una strategia diversa. Supponiamo di avere m
attributi, ciascuno dei quali può essere presente (valore 1) o assente (valore
0) in una generica unità. Supponiamo di voler confrontare la similarità tra
un elemento p e un altro q, allora si dovrà dare riferimento alla tabella:
p/q 1 0 tot
1 a b a + b
0 c d c + d
tot a + c b + d t
Tabella 3.1: Tabella di similarità
34
dove a rappresenta il numero di attributi comuni ai due elementi, d il
numero di attributi assenti in entrambi gli elementi, b il numero di elementi
presenti in p ma non in q e c il numero di elementi presenti in q ma non in p.
Si possono denire diversi indici di similarità:
Indice di Russell e Rao [53]:
S(p, q) =
a
t
(3.4)
Indice di Jaccard [27]:
S(p, q) =
a
a + b + c
(3.5)
Indice di Sokal e Michenener [63]:
S(p, q) =
a + d
t
(3.6)
Si osservi che lindice di Jaccard ha importanza quando le co-assenze hanno
poco signicato nel problema.
Nel caso in cui invece gli attributi non siano dicotomici, ovvero quando gli
attributi possono assumere pi` u di due modalità, la misura è pi` u complessa.
Lo scopo iniziale è quello di trovare una codica di tipo disgiuntivo per ogni
variabile qualitativa. In seguito si valuta la costruzione di indici che non
prendono in considerazione le co-assenze, in quanto queste non avrebbero
alcun signicato.
3.1.2 Algoritmi di clustering
Dopo la denizione delle misure di distanza e di associazione, è necessario
scegliere il metodo di classicazione ed un eventuale criterio di aggregazione o
suddivisione. I metodi di classicazione si dierenziano in base alle dicotomie
introdotte in precedenza, anche se i conni di denizione di tali algoritmi non
sono cos` ben marcati.
35
Algoritmi gerarchici
Denizione 3.1.1 (Dendrogramma) Si denisce dendrogramma un dia-
gramma ad albero che rappresenta una gerarchia di categorie basate sul grado
di similarità o sul numero di caratteristiche in comune.
Un esempio di dendrogramma è mostrato in Figura 3.1.
Figura 3.1: Esempio di dendrogramma
Un algoritmo diclustering di tipo gerarchico costruisce un dendrogramma
che rappresenta il raggruppamento annidato di elementi e livelli di similarità
lungo i quali questi raggruppamenti cambiano. La maggior parte di questi
algoritmi sono varianti degli algoritmi single-link [61], complete-link [33] e
minimum-variance [43, 73].
Nellalgoritmo single-link la distanza tra due cluster è la minima distanza
fra tutte le coppie di elementi presi dai due settori, un oggetto preso dal primo
cluster laltro dal secondo. Nel complete-link la distanza tra due cluster è
la massima fra tutte le coppie di distanze tra gli oggetti nei due cluster.
In entrambi i casi, due settori vengono uniti per formarne uno pi` u grande
basandosi sul criterio di minima distanza.
In generale il complete-link genera cluster compatti, mentre il single-link
tende a creare settori che sono irregolari o allungati. Daltra parte il metodo
single-link risulta essere pi` u versatile, in quanto riesce in alcuni casi a rilevare
cluster concentrici.
36
Algoritmi partizionali
Un algoritmo partizionale diclustering ottiene una singola partizione dei dati
invece di una struttura dei cluster, come il dendrogramma prodotto dagli
algoritmi gerarchici. Questo comporta un vantaggio nelle applicazioni che
devono lavorare su grandi quantità di dati in quanto le costruzioni delle
strutture sono molto onerose dal punto di vista computazionale.
Le tecniche partizionali di solito producono i cluster ottimizzando una
funzione denita localmente o globalmente, a seconda se si intende compren-
dere lintero data set o solo un sottoinsieme di esso. Una ricerca combinatoria
allinterno dellintero insieme delle partizioni per un valore ottimo è proibi-
tiva, quindi il tipico approccio è quello di iterare lalgoritmo pi` u volte con
dierenti stati iniziali e scegliere la migliore congurazione ottenuta da queste
iterazioni come output.
Questo tipo di algoritmi può essere ulteriormente suddiviso in due tron-
coni:
Algoritmi basati sullerrore quadratico: Lo scopo è di minimizzare
una funzione di errore e calcolare in tal modo i centroidi del cluster.
Funziona molto bene nel caso in cui si abbia un data set con cluster
naturali isolati e compatti. Di questi algoritmi fanno parte il k-means
che verrà trattato in dettaglio successivamente, e il criterio dellerrore
quadratico del clustering.
Algoritmi basati sulla teoria dei gra: Il pi` u famoso di questi è
basato sulla costruzione dellalbero ricoprente minimo (Minimum Span-
ning Tree o MST) dei dati [76]. Una volta generato lalbero, vengono
rimossi gli archi del MST con le maggiori lunghezze in modo da creare
le partizioni.
Algoritmi Mixture-Resolving
In questo tipo di metodi, si fa lassunzione che gli elementi in un cluster
siano estratti da una distribuzione, di solito si assume che ogni elemento sia
generato da una mistura di Gaussiane e lobiettivo è quello di identicare
37
i suoi parametri. I tradizionali approcci a questo problema sono quelli di
ottenere iterativamente uno stimatore di massima similarità dei vettori pa-
rametrici della densità [28]. Per stimare i parametri delle distribuzioni, viene
utilizzato lalgoritmo Expectation-Maximization (EM) [16] .
La maggior parte di metodi Mixture-Resolving considera ogni cluster
come una distribuzione singola e successivamente vincola la forma dei settori.
Algoritmi Fuzzy
I tradizionali metodi diclustering generano partizioni; in una partizione ogni
oggetto appartiene ad uno ed un solo cluster. Da questo punto di vista i
cluster sono quindi disgiunti fra di loro. La tipologia di clustering chiamata
Fuzzy estende questa nozione, dando la possibilità di associare ogni elemento
ad ogni settore denendo una funzione di appartenenza [75]. Il pi` u comune
algoritmo Fuzzy diclustering è il fuzzy c-means (FCM).
La scelta della funzione di appartenenza è il problema pi` u importante in
questo tipo di clustering. Può essere selezionata basandosi sulla similarità
tra cluster oppure in base ai centroidi dei cluster.
3.2 K-means
Il k-means è un tradizionale metodo diclustering il cui scopo è di partizionare
un insieme di n elementi in k cluster in modo tale che ogni oggetto appartenga
al settore con la distanza minore.
Questo problema è computazionalmente costoso (NP-completo), tuttavia
in genere che vengono usate delle euristiche per la convergenza ad un ottimo
locale. Di fatto il k-means può essere considerato una variante dellalgoritmo
EM per le misture delle distribuzioni Gaussiane.
Dato un insieme di elementi (x
1
, x
2
, ..., x
n
), dove ogni oggetto è un
vettore reale d-dimensionale, lalgoritmo k-means ha lo scopo di partizionare
gli n elementi in k insiemi S = (S
1
, S
2
, ... , S
k
), con k n, in modo da
38
minimizzare la somma dei quadrati della distanza intra-cluster:
arg min
S
n
i=1
x
j
S
i
|x
j

i
|
2
(3.7)
dove
i
rappresenta la media dei punti in S
i
.
Il k-means è molto dispendioso dal punto di vista computazionale, infatti
in generale:
il problema è NP-completo nello spazio euclideo d anche se esistono
solo 2 settori;
il problema è NP-completo per un numero generico di k anche in uno
spazio bidimensionale;
se k e d sono ssati il problema ha complessità O(n
dk+1
log n).
Il problema dellelevato costo computazionale viene risolto mediante lutilizzo
di euristiche.
Limplementazione pi` u comune deriva dallalgoritmo di Lloyd [35], un
procedimento iterativo mediante il quale i centroidi dei cluster vengono
aggiornati, come illustrato in Figura 3.2.
1. Scegli k centroidi che coincidano con altrettanti k elementi
casuali dellinsieme dei dati oppure scegli k centroidi casuali
contenuti allinterno dellipervolume contenente linsieme dei dati.
2. Assegna ogni elemento al centroide pi` u vicino.
3. Per ogni cluster, ricalcola il centroide in base agli elementi del
cluster stesso.
4. Se non si verica il criterio di convergenza, torna al passo 2.
Figura 3.2: Algoritmo di Lloyd
La convergenza dellalgoritmo avviene quando i valori dei centroidi non
sono cambiati rispetto allultima iterazione oppure sono variati di una quan-
tità inferiore ad una soglia denita a priori. Tuttavia, data la natura euri-
stica di questo algoritmo, la convergenza allottimo globale non è garantita
39
e il risultato dipende strettamente dallinizializzazione dei centroidi. Inoltre
nonostante sia un metodo piuttosto veloce in genere, nel caso peggiore esso
può essere molto lento nel convergere e in tale contesto è stato dimostrato
che anche nel caso bidimensionale esiste un particolare stato iniziale per cui
lalgoritmo prende un tempo esponenziale per convergere, ovvero 2
(n)
.
Questo metodo nonostante la particolare facilità di implementazione e la
velocità di convergenza, presenta diversi punti deboli. Oltre al fatto che non
garantisce la convergenza ad un ottimo globale come detto in precedenza,
si può notare che lalgoritmo funziona bene solo nel caso di cluster isolati,
compatti e di dimensioni simili. Infatti il metodo tende a creare cluster della
stessa dimensione anche in presenza di settori naturali di grandezza diversa.
Per questi motivi sono state proposte tante varianti allalgoritmo, la let-
teratura infatti contiene versioni modicate mirate a compensare le dicoltà
incontrate dal k-means. Alcune di queste varianti cercano di selezionare una
buona partizione iniziale in modo che lalgoritmo possa convergere pi` u agevol-
mente allottimo globale [6]. Unaltra variazione prevede invece la possibilità
di dividere o unire i cluster generati dalliniziale algoritmo. In genere per fare
questo si impone che un cluster venga diviso quando la sua varianza risulta
maggiore di una certa soglia, mentre due cluster vengono uniti quando la di-
stanza tra i due centroidi è minore di unaltra soglia [8]. Utilizzando questa
variante è possibile ottenere la partizione ottimale partendo da unarbitraria
partizione iniziale.
Unaltra versione dellalgoritmo prevede la selezione di una dierente fun-
zione da minimizzare, Diday e Symon [17] presentano unclustering dinamico
basato sulla stima della funzione di massima verosimiglianza (maximum-
likelihood).
Pelleg e Moore [46], pi` u recentemente, hanno proposto una versione mo-
dicata chiamata x-means, che risolve il problema del costo computazionale
che cresce allaumentare del valore dei parametri, risolve il problema del-
linizializzazione di k e cerca un rimedio per il problema della convergenza
allottimo globale.
40
3.2.1 Metodi di inizializzazione
Lo stato iniziale del modello del k-means condiziona il risultato nale del-
loutput, infatti esso tende a posizionare i centroidi direzionandosi verso un
ottimo locale. Poiche il problema dellottimizzazione globale è NP-completo,
di recente lo studio dei metodi di inizializzazione alla ricerca di un risultato
sub-ottimo è risultato di particolare interesse.
He et al. [25] categorizzano i metodi di inizializzazione in tre maggiori fa-
miglie chiamate metodi di campionamento aleatorio, metodi di ottimizzazione
della distanza e metodi di stima della densità
Metodi di campionamento aleatorio
Forse i pi` u utilizzati in letteratura, questi metodi inizializzano i cluster sele-
zionando campioni casuali, anche non appartenenti allinsieme dei dati, op-
pure scegliendo parametri casuali generati in modo non euristico dagli input.
Il metodo di Forgy [20] prevede linizializzazione dellalgoritmo mediante la
generazione di input casuali predisposti ad essere i centroidi iniziali, men-
tre MacQueen [37] propone una tecnica riconducibile alla precedente, con la
dierenza che i dati non vengono generati in maniera aleatoria, ma i cluster
vengono inizializzati mediante le prime k istanze del data set.
Il problema di questi metodi risiede nel fatto che se k è troppo piccolo
la soluzione trovata potrebbe non essere soddisfacente alla luce della dispo-
sizione naturale dei cluster, e daltra parte se k è troppo grande potrebbe
avvenire il fenomeno dei cluster vuoti.
Un metodo alternativo è quello di generare i cluster iniziali perturbando
leggermente la media dei valori di input [24, 65]. In questa maniera ogni
centroide iniziale ha quasi la stessa probabilità di essere scelto allinizio
dellalgoritmo k-means, in modo da evitare quindi il problema dei cluster
vuoti.
Metodi di ottimizzazione della distanza
In molti metodi diclustering riconoscere le caratteristiche di un insieme di
dati signica minimizzare localmente le varianze intra-cluster senza ottimiz-
41
zare la separazione intra-cluster. Tuttavia ottimizzare le distanze tra le po-
sizioni iniziali dei centroidi al ne di ottenere una soddisfacente separazione
intra-cluster è una buona considerazione da fare. Il metodo Simple Cluster
Seeking (SCS) [67] è stato proposto per fare quanto appena detto, attraver-
so laggiornamento di un soglia esso stabilisce quali siano i centroidi iniziali
ottimizzando le distanze tra i centroidi iniziali.
Un metodo pi` u semplice ma eventualmente pi` u oneroso dal punto di vista
computazionale è stato proposto da Katsavounidis [30], utilizzando coppie or-
dinate di distanze per linizializzazione. La dierenza dal precedente metodo
è che non viene utilizzata una soglia per linizializzazione. Inoltre poiche la
generazione di nuovi centroidi non inuisce su quelli già esistenti, la com-
plessità di questo algoritmo può essere paragonabile ad una iterazione dello
stesso k-means utilizzando una tecnica di buering per salvare le distanze
tra ogni esempio di input e i centroidi esistenti.
Metodi di stima della densità
Questa categoria di metodi di inizializzazione si basa sullassunzione che i
dati di input seguano una distribuzione Gaussiana. Perciò identicando le
aree dense dello spazio generato dai dati di ingresso, i centroidi cos` creati
aiutano il k-means a creare cluster compatti. Kaufman e Rousseeuw [31]
hanno introdotto un metodo che stima la densità mediante il paragone tra
coppie di distanze e inizializza i centroidi iniziali usando gli esempi di ingresso
dalle aree ad alta densità locale. Questo metodo però ha il difetto che il tempo
richiesto potrebbe essere superiore a quello del k-means stesso nel caso in cui
il numero di n esempi sia molto grande.
Pi` u recentemente Al-Daoud e Roberts [5] hanno proposto un metodo che
combina lapprossimazione della densità locale con linizializzazione random.
Metodo Range
Esiste un metodo non classicabile tra una delle precedente famiglie, pro-
posto da Mohamudally e Khan [32], chiamato metodo Range, che prevede
linizializzazione dei centroidi facendo leva sul massimo intervallo dei valori
42
che ogni parametro può assumere. Supponiamo di avere due parametri X, Y
e supponiamo di avere scelto k come numero di cluster. Allora la posizione
iniziale dei centroidi sarà data dalle equazioni:
c
i
=
(max X min X)
k
n (3.8)
e
c
j
=
(max Y min Y )
k
n (3.9)
dove n indica il numero del cluster per cui viene calcolato il centroide, che
quindi varia tra 1 e k.
Usando la distanza Euclidea è necessario che gli attributi vengano norma-
lizzati in modo che essi abbiano un impatto uguale sul calcolo della distanza.
In questo modo si evita di generare cluster che sono inuenzati dagli attributi
con le pi` u forti variazioni di valori. Questo metodo fornisce la normalizza-
zione dei dati, infatti i centroidi sono calcolati mediante la suddivisione dei
massimi intervalli degli attributi e dal numero di cluster.
3.2.2 Diagramma di Voronoi
Un tipico modo di rappresentazione dei cluster in uno spazio bidimensionale
è la costruzione di un diagramma di Voronoi a partire dei centroidi generati
dallalgoritmo di clustering. Un diagramma di Voronoi è uno speciale tipo
di decomposizione di uno spazio metrico, determinato dalle distanze rispetto
ad un insieme discreto di elementi dello spazio. In questo caso gli elementi
corrispondono ai centroidi dei cluster ed ognuno di essi è associato ad una
cella di Voronoi ovvero allinsieme dei punti dello spazio la cui distanza da
un dato centroide non è pi` u distante dagli altri centroidi. La metrica per
denire questi diagrammi non deve essere necessariamente euclidea, infatti
esistono anche implementazioni con metriche di Mahalanobis o Manhattan.
Un esempio di diagramma è mostrato in gura 3.3, dove sono rappresentati
i centroidi e i relativi cluster. I metodi usati per generare i diagrammi di
Voronoi sono lalgoritmo di BowyerWatson [12, 74] e lalgoritmo di Fortu-
ne [21] che calcola il diagramma in un tempo O(nlog n), dove n rappresenta
il numero di centroidi, quindi computazionalmente vantaggioso.
43
Figura 3.3: Diagramma di Voronoi
3.3 Validità dei cluster
Uno dei problemi pi` u importanti delclustering è la stima dei risultati nel
trovare il partizionamento che soddisfa al meglio i dati di input. Questo è il
tema principale della validità dei cluster.
3.3.1 Concetti fondamentali
In termini generali ci sono tre approcci per stimare la validità dei cluster.
Il primo è basato sui criteri esterni, ovvero vengono stimati i risultati di un
algoritmo diclustering basato su una struttura dati pressata. Il secondo
approccio è basato su criteri interni. Si può stimare i risultati dellalgoritmo
diclustering in termini quantitativi, quindi coinvolgendo anche i vettori dei
dati stessi. Inne il terzo criterio è basato sui criteri relativi, ovvero si stima
una struttura diclustering mettendola a confronto con altri risultati generati
dallo stesso algoritmo ma con parametri dierenti.
Questi sono i due criteri per la stima della validità dei cluster e per la
loro ottimalità:
44
1. Compattezza: i membri di ciascun cluster devono essere vicini fra di
loro il pi` u possibile. Una tipica misura di compattezza è la varianza,
che quindi deve essere minimizzata.
2. Separazione: i cluster stessi devono essere ben distanziati. Ci sono
tre comuni approcci che misurano le distanze tra due cluster dierenti:
Collegamento singolo: misura la distanza tra i membri pi` u vicini
dei cluster.
Collegamento completo: misura la distanza tra i membri pi` u di-
stanti.
Paragone dei centroidi : misura la distanza tra i centroidi dei
cluster.
I primi due approcci sono basati su test statistici e il loro maggiore svan-
taggio è lalto costo computazionale. Inoltre, gli indici relativi a questi ap-
procci hanno lo scopo di misurare il grado in cui un data set soddis una
struttura denita a priori.
3.3.2 Indici di validità
I metodi di validità che verranno discussi in questa sezione sono un ottimo
mezzo a disposizione per dare una stima quantitativa ai risultati dellalgorit-
mo diclustering usato.
Criteri esterni
Lidea base in questo approccio è quella di vericare se i dati del set iniziale
sono strutturati o meno. A tal proposito si consideri una struttura di cluster
C = C
1
, C
2
, ... , C
n
e una partizione P = P
1
, P
2
, ... , P
n
. Facendo rife-
rimento a una coppia di punti (x
1
, x
2
), si utilizza la misura di associazione
denita al punto 3.3.1. Nello specico a rappresenta il caso in cui entrambi
punti appartengano allo stesso cluster C e alla stessa partizione P, e analo-
gamente vengono descritti b, c e d. Gli indici già presentati, Jaccard, Russel
45
e Rao e Sokal e Michenener, prendono valori tra 0 e 1. Un altro indice è
quello di Folwkes e Mallows [22]:
FM =
a
m
1
m
2
(3.10)
dove m
1
= a + b e m
2
= a + c. Per tutte queste misure, alti valori indicano
forte correlazione tra C e P.
Esiste anche un approccio pi` u statistico alla validità mediante criteri
esterni, infatti si può utilizzare il metodo Monte Carlo oppure la statistica
di Huberts.
Criteri interni
Con questo approccio si cerca di stimare la validità del metodo diclustering
esclusivamente basandosi sulle caratteristiche e sui valori dei dati dellinsieme
di input.
Per i cluster generati da un algoritmo gerarchico, si usa una Cophenetic
Matrix P
c
, ovvero una matrice che rappresenta il diagramma gerarchico di
creazione dei cluster. Lelemento della matrice P
c
(i, j) rappresenta il numero
delliterazione nella quale due vettori x
i
e x
j
coesistevano nello stesso cluster
per la prima volta. Si può quindi denire un indice chiamato Cophenetic
Correlation Coecient, che misura il grado di similarità tra la Cophenetic
Matrix P
c
e la matrice di similarità tra i due vettori P.
Criteri relativi
I precedenti approcci si basano su test statistici, pertanto hanno il forte svan-
taggio di essere computazionalmente costosi. Un metodo di validità dierente
è quello basato su i criteri relativi chee non include test statistici. Lidea fon-
damentale di questo approccio è di scegliere il migliore schema diclustering
secondo un criterio predenito. Pi` u precisamente, sia P
alg
linsieme di para-
metri associato ad uno specico algoritmo di clustering. Tra tutte le possibili
strutture diclustering C
i
, i = 1, ... , n
c
, si sceglie quello che soddisfa meglio
linsieme dei dati. Tipicamente si utilizza il parametro n
c
che identica il
numero di cluster per scegliere la migliore struttura.
46
Selezionando un indice di performance q, si procede in questo modo:
1. Si fa lavorare lalgoritmo per ogni valore di n
c
, tra un minimo c
min
e
un massimo c
max
, valori deniti a priori.
2. Per ogni valore di n
c
si esegue lalgoritmo r volte facendo variare gli
altri parametri (se esistono).
3. Si valutano i migliori valori di q ottenuti da ciascun n
c
.
In generale possiamo interpretare i risultati di questa procedura in base a
come si comporta q in base a n
c
. Infatti se q non sembra diminuire (aumen-
tare) al crescere di n
c
, si cerca il massimo (minimo) tra i risultati. Daltra
parte, per gli indici che aumentano (diminuiscono) allaumentare del numero
di cluster si cercano i valori di n
c
per i quali si vericano variazioni locali
signicative nei risultati.
Lindice Dunn [19] cerca di identicare cluster compatti e ben separati
mediante lequazione:
D
n
c
= min
i=1,...,n
c
_
min
j=i+1,...,n
c
_
s(c
i
, c
j
)
max
k=1,...,n
c
diam(c
k
)
__
(3.11)
dove s(i, j) è la funzione di dissimilarità tra due cluster denita da:
s(i, j) = min
xC
i
,yC
j
d(x, y) (3.12)
mentre diam(c) è la funzione che rappresenta il diametro di un cluster, che
può essere interpretata come una misura di dispersione dei cluster, denita
da:
diam(C) = max
x,yC
d(x, y) (3.13)
Lobiettivo primario di questa misura è quello di massimizzare le distanze
fra cluster e minimizzare i loro diametri. Tuttavia ci sono diversi svantaggi
nellutilizzo di questo metodo, a cominciare dallalto costo computazionale.
Inoltre si osserva come lindice sia molto sensibile al rumore presente nei
dati che tende ad aumentare le lunghezze dei diametri dei cluster. Pal e
Biswas [45] hanno presentato una versione modicata del calcolo dellindice
47
facendo uso degli alberi di minima copertura (MST) in modo da minimizzare
linuenza del rumore sui risultati.
Una altro indice utilizzato è quello di Davies-Bouldin [15]. Si denisce
la misura di dispersione di un cluster S
n
(C
k
) come la distanza media degli
elementi di un dato cluster C
k
dal suo centroide e una misura di dissimilarità
tra due cluster S(C
i
, C
j
). Lindice di Davies-Bouldin sarà denito da:
DB =
1
n
c
n
c
i=1
_
max
i=j
_
S
n
(C
i
) + S
n
(C
j
)
S(C
i
, C
j
)
__
(3.14)
I cluster sono compatti e ben separati se il risultato di questo indice è piccolo.
Anche per questo indice sono state presentate varianti [45] per migliore la
performance, anche grazie allutilizzo di MST.
Per quanto riguarda ilclustering gerarchico esistono quattro tipi di indici
di validità, che vengono calcolati ad ogni passo delle loro iterazioni. Si trat-
ta degli indici RMSSTD [58] (Root-mean-square standard deviation), SPR
(Semi-partial R-squared), RS (R-squared) e CD(Cluster Distance).
48
Capitolo 4
Sviluppo del Software
Lo sviluppo del progetto per lestrazione di feature è stato realizzato mediante
lutilizzo di una telecamera di rete Axis [1]. In seguito allacquisizione delle
immagini è stato possibile elaborare le informazioni ottenute per rilevare le
caratteristiche desiderate, nel nostro caso edge e corner, e inviarle ad un
client connesso. La telecamera utilizzata è una Axis P1343 ssa, adatta
alla videosorveglianza di luoghi pubblici sia interni che esterni. Il lavoro
si è sviluppato mediante la creazione dellapplicazione su un PC usando un
apposito Software Development Kit (SDK) fornito dalla società Axis (si faccia
riferimento allappendice B). Lapplicazione è stata poi montata sulla camera
e mandata in esecuzione.
Lapplicazione si basa sulla continua interazione tra client, il browser,
e server, la camera Axis stessa. Il server è stato programmato in C++
utilizzando le interfacce messe a disposizione dal Software Development Kit
della società Axis. Lo scopo è stato quello di creare un sistema di cattura
ed elaborazione immagini mediante gli algoritmi di rilevamento feature. Il
passo successivo è stato quello della creazione di uno standard per salvare
le caratteristiche ottenute e inviarle al client in attesa. Il client invece è
basato su una semplice pagina HTML che viene resa dinamica dallutilizzo
di JavaScript. Ogni richiesta al server è stata fatta usando la tecnologia
AJAX.
In questo capitolo verrà esposto il funzionamento della telecamera utiliz-
49
CAPITOLO 4. SVILUPPO DEL SOFTWARE
zata, sia dal punto di vista delle sue componenti che dellambiente di svi-
luppo, la progettazione del server dellapplicazione in tutte le sue principali
componenti e la realizzazione dellinterfaccia lato client con lutilizzo delle
recenti tecnologie per i browser.
4.1 Piattaforma Axis
La telecamera Axis è un dispositivo che genera ussi video di alta qualità.
Questi dati vengono trasmessi su rete IP e sono visualizzabili in tempo reale
da qualsiasi computer che sia collegato in rete.
4.1.1 Speciche P1343
La telecamera Axis P1343 è ssa, ovvero non è possibile farla ruotare lungo
lasse orizzontale (pan) o inclinare rispetto allasse verticale (tilt), è varifocale
ma non consente un controllo remoto dello zoom. La camera è provvista del
Figura 4.1: La camera Axis P1343
processore integrato ARTPEC-3 (Axis Real Time Picture Encoder), creato
per la compressione delle immagini. Questo chip supporta vari tipi di sensori
CCD e CMOS; dispone di funzioni incorporate per la regolazione della ni-
tidezza, la compensazione della retroilluminazione, la riduzione dei disturbi
e il bilanciamento del bianco. Supporta lelaborazione simultanea di ussi
Motion-JPEG e H.264, ed è in grado di elaborare le immagini acquisite in
contemporanea da un massimo di 4 fonti video a una velocità massima di
30 fotogrammi al secondo nonche di comprimerle in tempo reale. Tuttavia
il processore non è in grado di eseguire calcoli in virgola mobile in quanto è
sprovvisto di FPU.
50
La telecamera è dotata di una memoria RAM di 128 MB e una memoria
ash di 128 MB. In questo modello è presente anche un sistema I/O audio,
con microfono integrato e uscita a livello di linea.
La camera P1343 può essere alimentata anche per mezzo della tecnologia
Power over Ethernet, ovvero può usare lo stesso cavo Ethernet che la collega
alla rete come fonte elettrica.
Inne, per quanto riguarda le caratteristiche ottiche, lobiettivo della ca-
mera è varifocale, ovvero la lente garantisce un ampia gamma di lunghez-
ze focali in cui il fuoco (e lingrandimento) cambia a seconda della loro
variazione.
4.1.2 Codec video
Il processore della camera Axis P1343 è in grado di elaborare ed inviare ussi
di video nei formati Motion-JPEG e H.264 a seconda della scelta dellutente,
ma non ha la capacità di codicare nel formato MPEG-4 Part 2, come diversi
altri modelli.
Motion-JPEG
Il Motion-JPEG, o M-JPEG, è un nome informale di una classe di formati
video dove ciascun frame o semiquadro interlacciato di un video digitale viene
compresso separatamente come unimmagine JPEG. Inizialmente sviluppato
per le applicazioni multimediali per PC, questo tipo di formato è utilizza-
to adesso da diversi dispositivi video portatili, come ad esempio le camere
digitali.
Il formato Motion-JPEG usa forma di compressione con perdita, basata
sulla trasformata discreta del coseno (DCT) in modo da convertire ciascun
frame o semiquadro del video originale dal dominio del tempo al dominio
della frequenza. In questo dominio linformazione viene ridotta mediante il
processo di quantizzazione. Questo metodo è conveniente perche nel dominio
della frequenza i coecienti delle frequenze alte che caratterizzano limma-
gine sono tipicamente valori relativamente piccoli con alta compressibilità.
51
I coecienti quantizzati vengono quindi messi in sequenza e inviati senza
ulteriore perdita di informazione.
Nella maggior parte delle implementazioni M-JPEG è consentito alluten-
te di avere il controllo sul tasso di compressione, mentre nei sistemi embedded
questi parametri sono spesso pressati e non modicabili. La camera Axis
ore la possibilità di controllare la qualità della compressione mediante le
sue API (Application Programming Interface).
Il fatto che ogni frame venga elaborato indipendentemente dagli altri, a
dierenza dei formati MPEG 2 e H.264/MPEG-4 AVC, limita la sua ecienza
di compressione, ma da un altro punto di vista il costo computazionale e
loccupazione di memoria sono inferiori. Da questa analisi segue che la qualità
dellimmagine del formato M-JPEGè funzione direttamente della complessità
spaziale di ciascun frame.
H.264
Lo standard H.264 è uno dei formati pi` u utilizzati per la compressione video.
Questo standard è utilizzato in un grande numero di applicazioni come per
esempio nella trasmissione di contenuti video a basso bit-rate attraverso le
reti wireless, nel video streaming attraverso internet e nella distribuzione di
contenuti in Blu Ray Disc. Il punto di forza di H.264 sta nella compressione
che rispetto al precedente MPEG2 è migliore di oltre il 50%. Ore una
qualità pari allo standard MPEG2 a quasi la metà del data-rate, con una
risoluzione no a quattro volte superiore a quella supportata dal formato
MPEG-4 Part 2 a parità di data-rate.
Il formato H.264 usa sostanzialmente lo stesso processo di compressione
del precedente MPEG2 ma, a spese di una maggiore complessità e quindi
di tempo di calcolo, esso consente un migliore sfruttamento delle ridondanze
statistiche e riduce la percezione soggettiva delle distorsioni. La trasformata
DCT viene applicata su blocchi di immagine pi` u piccoli (4x4), viene ridotto
leetto brick mediante un ltro di ricostruzione nel processo di decodica e
si ha anche un miglioramento della codica entropica.
52
4.1.3 API
La camera Axis ha a disposizione un insieme di API (Application Program-
ming Interface) basate sul protocollo HTTP, chiamato VAPIX
R
[2]. Questo
strumento consente allutente di richiedere immagini, controllare le funzio-
nalità della camera, variare o richiedere i valori dei parametri interni ed
altro. Ogni richiesta inviata è gestita dal Web server integrato della camera.
VAPIX
R
è composto da:
HTTP API
Parameter API
RTSP API
Per ottenere lo stream di un video dalla camera in genere si usa M-JPEG
o H.264. Unaltra opzione molto ineciente è quella di richiedere periodica-
mente immagini singole e poi riordinarle. In questo caso viene aperta una
connessione HTTP per ogni richiesta e una volta ultimato il trasferimen-
to dellimmagine viene subito chiusa. Il numero di stream video che può
fornire la camera è variabile in base al modello. La P1343 riesce a servire
circa 10 stream al massimo, ma in tal caso le prestazioni di servizio risulta-
no estremamente deteriorate ed il frame-rate del video ricevuto sarà molto
basso.
Una caratteristica molto vantaggiosa di queste API è la possibilità di
richiedere uno stream video con caratteristiche in base alle proprie esigenze.
Infatti in seguito alla richiesta HTTP è possibile specicare dei parametri,
seguendo unapposita sintassi, in modo da ricevere il tipo video desiderato.
Tra i parametri selezionabili ci sono il numero di frame al secondo dello
stream (frame-rate o FPS), la risoluzione del video, la compressione JPEG
delle immagini (nel caso di uno stream M-JPEG), il testo in sovrimpressione
ed altri.
53
4.2 Server
Il server del progetto sviluppato è rappresentato dalla telecamera stessa.
Esso si occupa di fornire tutti i servizi e le funzionalità richiesti da un utente
tramite browser.
La costruzione del server è stata interamente scritta nel linguaggio ad
oggetti C++, utilizzando alcune librerie standard e appoggiandosi alle inter-
facce fornite dallSDK della Axis. Il ruolo fondamentale del progetto viene
assunto dai vari gestori, ovvero oggetti che hanno il compito di organizzare e
sincronizzare le operazioni principali per lesecuzione. I gestori si suddividono
in:
Gestore immagini: apre uno stream di immagini non compresse in
base alla risoluzione desiderata e gestisce lelaborazione dei dati secondo
i parametri scelti dallutente;
Gestore segnali: è il responsabile della gestione dei segnali di control-
lo dellapplicazione, quando il client invia un segnale di stop il gestore
si occupa di avvisare lapplicazione e interromperla;
Gestore parametri: usando linterfaccia predisposta dallSDK questo
gestore si pone da intermediario tra lutente e lapplicazione per la
selezione e laggiornamento in tempo reale dei parametri;
Gestore HTTP: si occupa di gestire linterazione tra applicazione e
utente, quindi disponendo i dati in uscita in modo da essere inviati al
browser;
Gestore thread: crea un nuovo thread nel caso in cui ci sia bisogno
di ussi di esecuzione separati.
4.2.1 Esecuzione dellapplicazione
Il usso dellesecuzione del programma prevede una prima fase di inizializ-
zazione delegata ai vari gestori, i parametri inizialmente assumono valori
assegnati in base alle decisioni dellutente oppure in base ai valori di default
54
e inoltre vengono create le CGI usate per il trasferimento dei dati. Una volta
terminate queste operazioni preliminari si entra nel ciclo principale dellap-
plicazione. Questa fase è composta da cinque stati diversi che lapplicazione
può assumere nel tempo:
IDLE: in questo stato lapplicazione è ferma, rimane in attesa nche
non riceve un segnale di inizio esecuzione;
START: viene aperto uno stream secondo la risoluzione di immagine
denita dallutente e poi si predispone un cambio di stato immediato;
RUN: stato principale dellapplicazione, vengono eseguiti gli algoritmi
di rilevamento feature e si tiene traccia di eventuali cambiamenti;
RECONFIG: il parametro della risoluzione è stato cambiato, quin-
di in questo stato si chiude il vecchio stream per aprirne uno nuovo
secondo le nuove disposizioni;
STOP: lo stream video viene chiuso e lapplicazione torna nello stato
di quiete;
Il diagramma degli stati è mostrato in gura 4.2.
Figura 4.2: Il diagramma degli stati dellapplicazione
Il programma quindi rimane allinterno questo ciclo, elaborando ogni
frame che viene acquisito dal relativo gestore.
55
4.2.2 Acquisizione delle immagini
Lacquisizione delle immagini è delegata allapposito gestore, che si occupa
anche di assegnare le operazioni di elaborazione dellimmagine agli oggetti
competenti e salvare le feature ottenute.
Sostanzialmente il processo è suddiviso in due fasi: apertura e elabora-
zione. Nella fase di apertura vengono letti i parametri desiderati dallutente
e quelli default per aprire uno stream video di immagini non compresse. La
prima scelta riguarda la risoluzione del video, ovvero la quantità di pixel
che compone la larghezza e laltezza dellimmagine. Questo è un punto di
decisione fondamentale perche lapplicazione spende parte del tempo per ese-
guire lacquisizione dellimmagine e inoltre la scelta di risoluzioni pi` u elevate
implica un tempo di elaborazione maggiore anche da parte degli algoritmi.
Perche lesecuzione sia veloce in genere si scelgono risoluzioni basse, ovvero
160 120, 240 180 o 320 240. Superato questo scalino il tempo di acqui-
sizione ed elaborazione delle immagini sarà troppo alto e comprometterà la
velocità di esecuzione dellapplicazione, riuscendo ad inviare le informazioni
elaborate solo poche volte al secondo.
In questa sezione è possibile anche decidere il frame-rate di acquisizione e
il formato dellimmagine. Al ne dellelaborazione dellimmagine, viene scelto
il formato YUV chiamato Y800, per cui si ottiene un immagine non compressa
in scala di grigi. Laltra opzione sarebbe stata di acquisire limmagine in
formato JPEG, ma ciò non avrebbe consentito un facile accesso ai singoli
pixel per lestrazione dei punti caratteristici.
La seconda fase invece prevede lutilizzo dello stream precedentemente
aperto per salvare il frame corrente in un buer di memoria. Successivamente
i dati memorizzati vengono inviati ai blocchi degli algoritmi di competenza,
a seconda di quali vengano abilitati dallutente, ovvero lalgoritmo FAST,
loperatore di Sobel e il k-means. Qualora si decidesse di attivare uno di
questi algoritmi, è necessario passare anche i parametri specici per ognuno
di essi.
56
Frame-rate
Esiste un punto di fondamentale importanza in questa sezione dellapplica-
zione riguardante il frame-rate di acquisizione. Si parte dal fatto che la tele-
camera può al massimo acquisire 30 frame al secondo, valore che rappresenta
non solo un limite superiore ma anche un importante punto di riferimento. Il
problema della scelta della risoluzione dello stream video limita fortemente
la quantità di frame al secondo che la camera riesce poi a elaborare con gli
algoritmi; infatti questo numero diminuisce allaumentare della risoluzione.
Una possibile soluzione per massimizzare la quantità di immagini elaborate
è quello di diminuire il frame-rate di acquisizione opportunamente. Infatti se
viene scelta una risoluzione piuttosto elevata è piuttosto inutile mantenere
un frame-rate di acquisizione a 30 FPS quando lapplicazione in realtà riesce
a lavorarne molte di meno.
La soluzione ottimale è quella di far coincidere il valore del parametro
di FPS con il numero di immagini elaborate al secondo, ma di fatto non è
realizzabile. Il problema sta nel fatto che il frame-rate di acquisizione non è
modicabile in tempo reale, ovvero la procedura è sempre quella di chiudere
lo stream esistente e crearne uno nuovo secondo i nuovi input. Questa ope-
razione comporta alcuni secondi di elaborazione, pertanto non si può creare
un sistema adattivo per la scelta di questo valore.
Unaltra soluzione, questa volta sub-ottimale, è quella di trovare il valore
ottimo per ogni risoluzione possibile e selezionarlo opportunamente ogni volta
che viene aperto uno stream. Il problema che si pone in questo contesto è
di natura diversa, ovvero la soluzione è funzionale solo nel caso in cui si
ha la sicurezza che la scena rimanga sempre la stessa. Infatti basta che la
telecamera inquadri una scena pi` u dettagliata o meno dettagliata che il valore
scelto non è pi` u ottimo e la situazione diventa sconveniente. Infatti se una
scena ha un alto contenuto informativo, la camera impiega pi` u tempo sia ad
acquisire e memorizzare limmagine che successivamente ad elaborarla con
gli algoritmi di rilevamento. Daltra parte se la scena è scarna di dettagli, la
riduzione del frame-rate funge da freno per lapplicazione, che quindi elabora
ed invia i dati ad una frequenza minore rispetto alle sue potenzialità.
57
Per il progetto si è scelto una modalità alternativa, che prende i tratti
principali dalle due soluzioni proposte in precedenza. Per prima cosa sono
stati confrontati i risultati di performance relativi alla generazione di dati
elaborati sulle varie scene alle diverse risoluzioni. Valutando il numero di FPS
generati nel caso peggiore (scena molto dettagliata) e caso migliore (scena
monocromatica) si è scelto il valore medio. Assumendo che la probabilità di
avere pi` u o meno dettagli in una scena segua una distribuzione Gaussiana, il
valore medio scelto rappresenterebbe anche levento pi` u probabile.
Ovviamente questa situazione ideale si dissocia dalla realtà, ma è stato
osservato che scegliendo il valore in questo modo ci si trova il pi` u delle volte in
condizioni ottimali, e gli svantaggi dovuti alla presenza o assenza di dettagli
sono considerevolmente ridotti.
4.2.3 Esecuzione algoritmi
Gli algoritmi di rilevamento feature rappresentano lessenza dellapplicazio-
ne, quello per cui lintero progetto è stato creato. Il punto di partenza è
rappresentato dal gestore immagini che si occupa di passare il frame appena
ottenuto alle strutture di competenza.
Lapplicazione prevede due algoritmi di rilevamento diversi, FAST e So-
bel, che possono essere attivati a discrezione dellutente e inoltre è data la
possibilità di una loro coesistenza. Un algoritmo di clustering, il k-means,
può essere eseguito sui dati ricevuti dallalgoritmo di rilevamento di corner,
ovviamente solo nel caso in cui questo sia attivo. Per memorizzare le feature
risultanti dagli algoritmi sono stati predisposti tre buer di testo allinterno
del gestore immagini, uno per ogni algoritmo. Lo stesso gestore si occupa di
svuotare i buer una volta ottenuta una nuova immagine.
Implementazione FAST
Per quanto riguarda lalgoritmo FAST, viene creato un oggetto apposito che
si occupa di tutte le funzioni possibili del metodo, quindi rilevamento, asse-
gnazione di punteggio, rimozione non massimi. Viene dunque passato allog-
58
getto non solo il buer contenente i valori di ogni singolo pixel dellimmagine
acquisita, ma anche tutti i parametri necessari allelaborazione:
dimensione dellimmagine;
valore della soglia di rilevamento;
attivazione/disattivazione della soppressione dei non massimi;
attivazione/disattivazione del k-means;
numero di cluster per il k-means
Lalgoritmo di rilevazione corner utilizzato è il Generic FAST discusso
al paragrafo 2.1.4. Questa scelta deriva dal fatto che lalgoritmo originale
ha una qualità di rilevamento inferiore. Daltra parte nemmeno il Learned
FAST è stato ritenuto adatto al nostro scopo. Infatti se da una parte ha
un tempo di esecuzione inferiore al Generic FAST, dallaltra presenta due
grosse limitazioni in questo contesto applicativo. La prima riguarda il fatto
che allenare un rilevatore su una scena particolare implica che, nel caso in
cui la camera acquisisca un panorama completamente diverso, non si avrebbe
garanzia della stessa qualità della scena iniziale. Il Generic FAST invece ha
lo stesso comportamento in qualsiasi scenario si trovi a lavorare. La seconda
limitazione è in qualche modo legata alla prima. Lallenamento di un rileva-
tore prevede la creazione di migliaia di righe di codice in C++, quindi per
inserire le righe di codice nel programma il procedimento diventa oltremodo
macchinoso, perdendo quindi la portabilità dellapplicazione stessa. Quindi
in questo contesto, a scapito di un breve intervallo di ritardo di tempo rispet-
to alla versione automatizzata, è stata scelta una versione leggera, portabile
e robusta dellalgoritmo.
Il metodo di memorizzazione dei risultati derivati dallesecuzione del FA-
ST è stato scelto in modo da facilitare la lettura da parte del client. Il buer
di testo creato nel gestore immagini viene quindi riempito dalle coordinate
degli angoli rilevati, assegnando ad ogni cifra del numero di coordinata il
rispettivo carattere ASCII, e inoltre sono stati usati due caratteri speciali
per creare una sorta di sintassi. Infatti cera la necessità che le coordinate
59
x e y fossero separate tra di loro cos` come le coppie stesse di coordinate. Il
carattere usato per la separazione inter-coordinate è stato scelto il punto e
virologa, mentre per la separazione intra-coordinate il carattere virgola.
Ai ni di una migliore performance, è stato realizzato un ulteriore articio
nel caso di soppressione dei non massimi. Infatti in questa situazione, per
lassegnazione dei punteggi e la successiva rimozione degli angoli, è necessario
che i dati rilevati dallalgoritmo siano rappresentati come coppie di interi
e non come array di caratteri. Daltra parte, durante il rilevamento delle
feature è superuo salvare le coordinate dei corner nel buer testuale poiche
la successiva soppressione dei non massimi comporta la creazione di una
dierente stringa testuale. Quindi è stato suciente selezionare il modo di
memorizzazione delle feature (testuale/intero) in base alla presenza o assenza
della soppressione dei non massimi, in modo da non spendere tempo per
lesecuzione di operazioni che poi sarebbero risultate inutili.
Implementazione Sobel
Lalgoritmo di rilevamento di edge utilizzato è loperatore di Sobel. La sua
implementazione è piuttosto semplice e non ci sono artici particolari per
migliorare la performance. Allo stesso modo dellalgoritmo FAST, lintensità
dei pixel viene memorizzata come testo in un buer creato appositamente, in
modo che ad ogni cifra del valore venga assegnato il corrispondente carattere
ASCII. In questo caso la creazione di una specica sintassi è semplicata,
visto che ogni pixel è identicato da un valore e i dati vengono elaborati
sequenzialmente. Per distanziare i caratteri che indicano lintensità dei vari
pixel gli uni dagli altri è stato utilizzato il carattere punto e virgola.
Anche in questo caso lutente può interagire direttamente per specica-
re il comportamento dellalgoritmo, quindi il gestore immagini oltre ai dati
dei pixel invia alloggetto responsabile dellalgoritmo di rilevamento edge i
parametri:
dimensione dellimmagine;
tipo di quantizzazione richiesta;
60
livello di soglia, nel caso in cui limmagine venga binarizzata;
Per quanto riguarda la quantizzazione, viene passato un valore intero n
compreso tra 0 e 7. Lidea è stata quella di assegnare ognuno di questi valori
ad una classe di quantizzazione, rendendo il procedimento automatico. In-
fatti eseguendo n volte lo shift-left di 2 si ottiene un risultato che corrisponde
al numero totale di grigi che rappresenta limmagine. Quindi ricalibrando i
valori in uscita dallalgoritmo di Sobel in base alla nuova scala di grigi si è
potuto costruire limmagine quantizzata.
Implementazione k-means
Lalgoritmo di clustering k-means è stato integrato allinterno dellalgoritmo
FAST, in quanto i dati estrapolati dal rilevamento corner sono stati usati
come linsieme iniziale del k-means. Anche in questo caso, le coordinate dei
centroidi sono state salvate come testo in un apposito buer seguendo la
stessa sintassi utilizzata per lalgoritmo FAST.
Il numero di partizioni k è scelto dallutente e tale valore viene passato
alla struttura di competenza del k-means; tuttavia è stato reso disponibile
lutilizzo un indice di validità per trovare il numero ottimale di partizioni.
Lidea di base è stata quella di dover scegliere unopportuna misura di qualità
delle partizioni in modo tale che non fosse troppo complessa dal punto di
vista computazionale, non comprendesse calcoli in virgola mobile e desse un
buon risultato sullinsieme di feature rilevate. Lindice scelto è stato quello
di Davies-Bouldin perche risponde a tutti questi requisiti. Tuttavia è stata
fatta unulteriore considerazione sul calcolo dellindice. Nonostante questo
metodo preveda un tempo di esecuzione relativamente basso se eettuato su
un numero di cluster denito a priori, bisogna considerare che questo tipo
di indice fa parte dei criteri relativi di misura, quindi richiede che il calcolo
venga eettuato su un intervallo di partizioni, ovvero a partire da un numero
minimo di cluster no ad un massimo. Dal punto di vista computazionale può
essere davvero proibitivo assumere una strategia di questo tipo, soprattutto
al crescere del volume dellinsieme di feature. La decisione presa è stata
quella di creare una funzione gestibile direttamente dallutente, in modo che
61
lindice migliore potesse essere selezionato solo quando richiesto. Unaltra
soluzione studiata è quella di aggiornare il numero di partizioni chiamando
la stessa funzione periodicamente dopo un certo numero di frame.
Il metodo scelto per linizializzazione dei centroidi è stato il metodo Ran-
ge, in quanto è risultato quello che ha soddisfatto al meglio i requisiti di
qualità e velocità di esecuzione. I metodi random utilizzati nonostante la
buona performance hanno mostrato scarsi risultati in prossimità di cluster
non troppo separati tra di loro.
Sempre in merito allinizializzazione dei centroidi è stata fatta unaltra
considerazione. Il punto principale si basa sul fatto che una scena sia per
la maggior parte del tempo statica, ovvero con apparente assenza di movi-
mento allinterno di essa. In tale contesto, calcolando i centroidi dei cluster
tra due frame consecutivi si può notare come la posizione di questi vari in
misura molto ridotta rispetto alla grandezza dellimmagine. La probabilità
che un centroide sia situato in un intorno di pochi pixel rispetto allo stesso
centroide del frame precedente è molto alta. Quindi la procedura utilizza-
ta per linizializzazione è stata quella di creare un primo input di centroidi
mediante il metodo Range e poi per ogni altro frame inizializzare i centroidi
con i valori ottenuti dallesecuzione del k-means sullimmagine precedente.
In questo modo, essendo lerrore tra due centroidi consecutivi molto ridotto,
viene aumentata la velocità di convergenza dellalgoritmo, di fatto limitando
considerevolmente il numero di iterazioni.
4.2.4 Interfaccia di rete
Dopo lacquisizione delle immagini e la relativa elaborazione, il problema che
si pone è quello di realizzare un sistema ecace per linvio dei dati ottenuti
al client. Queste mansioni vengono ricoperte dal gestore HTTP mediante
luso delle interfacce dellambiente Axis.
Denizione 4.2.1 (Common Gateway Interface) Una Common Gate-
way Interface o CGI è una tecnologia standard usata dai Web server per
interfacciarsi con applicazioni esterne. Ogni volta che un client richiede al
62
Web server un URL corrispondente ad un programma CGI, il server lo esegue
in tempo reale, generando dinamicamente informazioni.
Il Gestore HTTP viene inizializzato mediante la creazione di due CGI
speciche per linterazione con il client:
Data CGI : utilizzata per linvio dei dati riguardanti le feature al client;
Update CGI : utilizzata per laggiornamento dei parametri riguardanti
i vari algoritmi;
In questo modo ogni volta che il client richiede lutilizzo di un programma
CGI, il server risponde mediante loutput e lo invia al client in tempo reale.
Invio dei dati
Il sistema di invio dei dati è stato creato in modo che per ogni tipo di featu-
re richiesta venga utilizzata una singola CGI in grado di lavorare in base al
contesto in cui si trova. Infatti la scelta del tipo di feature richiesta è stata de-
legata allutente, che interagisce mediante il browser. La richiesta dellutente
contiene un parametro secondo il quale la CGI decide come comportarsi. Ci
sono tre tipi di richiesta:
1. Corner;
2. Edge;
3. Corner + Edge;
Una volta selezionata la modalità, il gestore HTTP si occupa anche di atti-
vare lalgoritmo relativo prima dellinvio dei dati e di disattivarlo una volta
terminato il compito. Il buer di memoria contenente le feature desiderate
viene posto in uscita e inviato al client mediante il protocollo HTTP, usando
lapposita libreria fornita da Axis.
63
Multithreading
Il punto fondamentale nellinvio dei dati è che viene aperta una sola connes-
sione tra client e server per tutta la durata della trasmissione. Il motivo di
questa scelta nasce dal fatto che per mantenere aperta una singola connessio-
ne, il usso di esecuzione deve iterare dentro un ciclo allinterno del relativo
programma CGI per ogni frame elaborato. Tuttavia una volta inviata la
richiesta di dati, il usso di esecuzione esegue correttamente il rilevamento
feature per la prima immagine acquisita, riempie il buer di competenza ed
entra nel ciclo della CGI. A questo punto, per mantenere la connessione aper-
ta, lapplicazione rimane intrappolata allinterno del ciclo e, non potendo pi` u
elaborare nuove immagini, continua a mandare i risultati del primo frame
acquisito nche lutente non termina la comunicazione.
La soluzione è stata quella di creare un sistema multithread, in modo che
ogni richiesta dellutente possa essere gestita tramite un usso di esecuzione
parallelo a quello principale. Il passo successivo è stato quello di coordinare i
due thread, quello principale e quello di richiesta, in modo che ad ogni elabo-
razione di un frame corrisponda un output verso il client. Il primo approccio
è stato quello di creare un semplice semaforo creato con le apposite variabili
di mutua esclusione. Quindi, imponendo che linvio dei dati avvenga solo
dopo la terminazione del rilevamento delle feature e quindi dopo il riempi-
mento dei buer di memoria, è garantito che i pacchetti dei dati riguardanti
le caratteristiche immagine vengano inviati integri e sequenzialmente.
La soluzione pi` u complessa è quella di creare una coda di priorità per la
gestione dei thread, in modo che pi` u client possano collegarsi ai programmi
CGI e ottenere contemporaneamente dati, anche di diverse feature. Il pro-
blema in questo caso è che le risorse a disposizione sono limitate e la gestione
dellinvio di dati verso pi` u client è computazionalmente pesante se trattata
dalla singola camera, quindi il contributo dellecienza di elaborazione degli
algoritmi scelti viene in questo modo perso.
64
Delimitazione dei pacchetti
Lultima considerazione fatta riguardo la trasmissione dei dati è stata quel-
la di porre alcune delimitazioni ai pacchetti inviati, in modo che il client
potesse distinguere le sezioni di dati inviate e elaborarle come blocchi a se
stanti. Inoltre nel caso di invio di pacchetti con pi` u tipologie di feature al suo
interno, ad esempio linvio contemporaneo di corner ed edge, si è fatto uso
di altri delimitatori speciali, in modo diverse caratteristiche potessero essere
riconosciute e trattate dierentemente per la rappresentazione.
Aggiornamento dei parametri
Per conferire allapplicazione una certa dinamicità, è stato reso possibile lag-
giornamento in tempo reale dei parametri degli algoritmi utilizzati, come ad
esempio la soglia per lalgoritmo FAST, la quantizzazione dellimmagine ot-
tenuta con Sobel e altri. Il principio su cui si basa questa operazione è
piuttosto banale: lutente agisce mediante interfaccia graca facendo variare
i parametri in base alle proprie esigenze; in questo modo viene inviata una
richiesta alla CGI di aggiornamento che si occupa di ricongurare il para-
metro variato in base al valore ricevuto. La funzione callback che gestisce il
parametro viene chiamata, quindi il valore viene aggiornato in tempo reale
senza bisogno di riavviare lapplicazione.
Esiste solo un caso in cui laggiornamento non avviene in tempo reale ov-
vero quando si desidera cambiare la risoluzione di acquisizione dellimmagine.
Questo fatto è dovuto dai limiti della camera stessa, che ha bisogno del tempo
necessario per chiudere lo stream video ed aprirne uno nuovo con la risoluzio-
ne desiderata, quindi avviare un nuovo thread e ricominciare lelaborazione
dei dati.
4.3 Interfaccia utente
Quello descritto no adesso riguardava tutto ciò che avviene allinterno della
camera, ovvero le modalità di generazione ed invio dei dati. Laltro aspetto
65
di fondamentale interesse riguarda la richiesta e la rappresentazione dei dati
riguardanti le feature.
Il client dellapplicazione è rappresentato da un semplice Web browser,
che collegandosi alla camera mediante lindirizzo IP è in grado di ricevere i
ussi di informazione. Tuttavia per sviluppare un sistema di richieste ade-
guato alle speciche di dinamicità e velocità di interazione è stato necessario
lutilizzo della tecnologia AJAX.
Per la rappresentazione delle feature ottenute, quindi allo scopo di dare
un senso ai dati elaborati è stato utilizzato il JavaScript, in modo tale da
disegnare le caratteristiche direttamente sulla pagina web.
4.3.1 Tecnologia AJAX
Con il termine AJAX (Asynchronous JavaScript and XML) [3] si indica un
insieme di alcune tecnologie, sviluppate in modo indipendente, che aggre-
gandosi tra loro danno vita ad un meccanismo ancora pi` u potente. AJAX
incorpora le seguenti tecniche:
HTML e CSS per il markup e lo stile di presentazione;
DOM (Document Object Model ) manipolato attraverso un linguaggio
ECMAScript come JavaScript o JScript per mostrare le informazioni
ed interagirvi;
XML e XSLT per interscambio e manipolazione dei dati;
XMLHttpRequest per le richieste asincrone di dati al server;
JavaScript che funge da collante per tutta la struttura;
Le prime applicazioni Web lavoravano secondo un solito schema: ad ogni ri-
chiesta HTTP verso un Web server succedeva un processo interno di recupero
ed elaborazione dati, uneventuale comunicazione verso sistemi collegati ad
esso e inne linvio di una pagina HTML al client. Questo modello tuttavia è
un adattamento delloriginale utilizzo del Web come mezzo di comunicazione
66
ipertestuale, e quindi non ha la stessa ecacia se utilizzato per le applicazio-
ni. Infatti il problema nasce dal fatto che durante il tempo di elaborazione
del server, il client non esegue nessuna operazione perche in attesa della
risposta. Inoltre si deve tenere conto del tempo che impiega il client a rica-
ricare linterfaccia di una pagina per ogni richiesta. Tutto questo ha favorito
lintroduzione di AJAX per migliorare le prestazioni delle applicazioni Web.
Unapplicazione AJAX elimina la classica interazione invia/ricevi tra le
due parti introducendo uno strato intermediario, chiamato motore AJAX, tra
lutente e il server. Invece di caricare una pagina Web, allinizio della sessione,
il browser carica un motore AJAX scritto in JavaScript e in genere nascosto
allutente. Questa struttura è responsabile sia del rendering dellinterfaccia
graca che della comunicazione con il server come intermediario per conto
dellutente. In questo modo il client non si trova mai nella situazione in cui
deve attendere la risposta del server prima di intraprendere qualsiasi azione.
Ogni azione dellutente che avrebbe generato una richiesta HTTP assu-
me la forma di una chiamata di una funzione in JavaScript verso il motore
AJAX. Ogni richiesta che non richiede un riscontro diretto del server, viene
gestita dal motore stesso, mentre se cè la necessità di qualche dato aggiun-
tivo di qualsiasi natura, AJAX invia richieste asincrone senza congestionare
linterazione con lutente.
4.3.2 XMLHttpRequest
XMLHTTP è un set di API che possono essere usate da JavaScript, JScript,
VBScript e altri linguaggi di scripting dei browser per trasferire XML o altri
dati tra un Web server e un client tramite il protocollo HTTP. Il pi` u grande
vantaggio di XMLHTTP è la possibilità di aggiornare dinamicamente una
pagina Web senza ricaricare lintera pagina. Viene usato da alcun siti Web
per velocizzare applicazioni dinamiche.
XMLHttpRequest è un elemento fondamentale di AJAX, ed è utilizzato in
molti siti Web per implementare applicazioni fruibili via browser dinamiche
ed interattive. Questo oggetto ha la caratteristica di consentire lo sviluppo di
uninterfaccia utente molto dinamica e allo stesso tempo permette di mante-
67
nere le strutture di funzionamento pi` u importanti nel livello applicativo della
pila protocollare.
Dopo avere istanziato loggetto si ha a disposizione una serie di metodi ed
attributi per modellare lapplicazione secondo i requisiti. Il metodo open()
pone le basi per eseguire la richiesta, specicando il tipo di operazione de-
siderata e lURL per la connessione. Le operazioni possibili in una richiesta
XMLHttpRequest sono:
GET: richiede la rappresentazione di una risorsa specica;
POST: invia i dati da essere elaborati alla risorsa specica, includendoli
nella richiesta stessa;
PUT: carica una rappresentazione nella risorsa specica;
DELETE: cancella una risorsa specica;
HEAD: richiede la stessa risposta che avrebbe ricevuto con il metodo
GET, ma senza il corpo della risposta;
OPTIONS: ritorna le operazioni possibili che il server supporta per
lURL specicato;
Oltre a questi due parametri obbligatori per eseguire una richiesta, loggetto
consente di specicarne altri opzionali. Il primo di questi riguarda la natura
della richiesta, asincrona (di default) o sincrona. Oltre a questo è possibile
inserire utente e password, nel caso in cui si necessiti di autenticazione per
accedere al server.
Il metodo send() è il responsabile dellinvio della richiesta e, a seconda
delloperazione scelta, può includere al suo interno dei contenuti per il server.
Per riuscire a modellare uninterfaccia funzionale è necessario conosce-
re a fondo gli attributi delloggetto XMLHttpRequest, in quanto essi com-
prendono sia i dati inerenti alla richiesta che i controlli relativi allo stato
dellinterazione. Essi sono cos` composti:
onreadystatechange: gestore dellevento lanciato ad ogni cambiamento
di stato della richiesta;
68
readyState: indica lo stato corrente dellistanza di XMLHttpRequest;
responseText: costituisce la risposta del server in formato testuale;
status: indica il codice HTTP restituito dal server;
Figura 4.3: Il funzionamento di XMLHttpRequest
Lattributo readyState è particolarmente importante in quanto al variare
del valore assunto lapplicazione si comporta in modo diverso:
Stato 0: richiesta non inizializzata;
Stato 1: richiesta inizializzata;
Stato 2: richiesta inviata;
Stato 3: richiesta in ricezione;
Stato 4: richiesta terminata;
In Figura 4.3 è mostrato il diagramma degli stati riferito alla richiesta
XMLHTTP.
69
4.3.3 Streaming dei dati
Grazie allutilizzo della tecnologia AJAX ed in particolare delloggetto XM-
LHttpRequest è possibile ottenere uno stream di dati dalla telecamera, costi-
tuito da pacchetti informativi opportunamente delimitati. Ognuno di questi
pacchetti contiene al suo interno un blocco di feature, ovvero una lista di cop-
pie di coordinate nel caso in cui lutente intenda rilevare gli angoli della scena,
una lista di intensità di pixel se intende rilevare i contorni, una combinazione
delle precedenti se lutente desidera visualizzarli contemporaneamente.
Sono state messe a punto due diverse tecniche per realizzare lo streaming
che fanno parte di due losoe di interazione client-server completamente
diverse:
Client Polling;
Server Push;
Una volta ottenuti i pacchetti di feature è stato possibile interpretarli e
rappresentarli sulla pagina Web in tempo reale.
Client Polling
Questa tecnica è stata piuttosto facile da implementare vista la sua natura,
che si basa sulla richiesta dei dati eettuata in un dato intervallo di tempo
periodico al server. Dopo che lutente decide il tipo di algoritmo di rile-
vamento viene creato un oggetto XMLHttpRequest, una connessione viene
aperta con il server, i dati delle caratteristiche immagine vengono prelevati
dai buer di memoria e inviati dal gestore di rete del server. La camera
in questo caso chiude subito la connessione, quindi termina lesecuzione del
programma CGI. Dallaltra parte, il client ottiene i dati, li interpreta e li ela-
bora per la rappresentazione e inne distrugge loggetto XMLHttpRequest.
Al termine di tutta questa procedura invia una nuova richiesta esattamente
come prima e si ripete nche lutente chiude lapplicazione. La Figura 4.4
mostra il funzionamento della tecnica.
Ci sono due possibili implementazioni di questa tecnica, ma entrambe
hanno pesanti svantaggi. La prima, quella appena descritta che prevede la
70
Figura 4.4: Client Polling
creazione e la distruzione di oggetti XMLHttpRequest ogni intervallo di tem-
po pressato, ha il grosso svantaggio di eettuare tante richieste al secondo
provocando un deterioramento delle risorse, sia per quanto riguarda la came-
ra che il browser stesso. Inoltre il fatto di dovere instaurare una connessione
ad ogni richiesta rende necessario un intervallo di tempo perche le due parti
si mettano in comunicazione, aumentando cos` il ritardo di arrivo del pac-
chetto. Il risultato è pessimo, il browser riceve meno pacchetti di quanti ne
riesce a generare la camera a causa della lag ed entrambi i sistemi sono sotto
costante stress computazionale a causa delle continue richieste. La seconda
implementazione è migliore dal punto di vista di utilizzo delle risorse, ma
invia ancora meno pacchetti della precedente. Lidea è quella di eettuare
una richiesta ogni volta che un pacchetto viene completamente ricevuto. In
questo modo vengono fatte meno richieste, ma i pacchetti arrivati saranno
pochi e il sistema sarà molto dipendente dal ritardo di trasmissione.
Server Push
Questa tecnica è un po pi` u complessa della precedente, anche perche è stato
necessario modicare il funzionamento server adattandolo allo scopo (pa-
ragrafo 4.2.4). Lidea si basa sul mantenere aperta ununica connessione
tra le due parti, eliminando il ritardo di arrivo dei pacchetti e rendendo il
trasferimento dei dati molto pi` u leggero. Per realizzare la richiesta è stata
utilizzata una caratteristica di XMLHttpRequest che ha permesso lelabo-
71
razione dei dati per ogni pacchetto mandato dal server in tempo reale. Il
funzionamento generale di questo metodo è mostrato in Figura 4.5.
Figura 4.5: Server Push
Lattributo onreadystatechange viene creato in modo che contenga al suo
interno la funzione che elabora la risposta dal server. Quindi ogni volta che
lattributo readyState varia, questa funzione viene eseguita. Per fare in mo-
do di avere una connessione permanente si sfrutta lo stato 3 dellattributo
readyState. Il motivo risiede nel fatto che la camera non chiude la nestra
di connessione nche lutente stesso non termina lapplicazione (o esce dalla
pagina della visualizzazione), quindi no a quando vengono elaborate imma-
gini e inviati pacchetti contenenti le stringhe di feature, il readyState non
potrà mai assumere valore 4, ovvero la richiesta non potrà essere considera-
ta terminata. Invece durante lo stato 3, ovvero quando si stanno ricevendo
progressivamente i pacchetti e la connessione quindi è ancora attiva, si può
leggere lo stream di dati ed interpretarli per la visualizzazione. I caratteri ine-
renti le feature verranno salvati sequenzialmente nellattributo responseText,
con le opportune separazioni interne ed esterne. Basterà scorrere larray di
caratteri ricevuto mediante un indice ed isolare le parti di competenza per
preparare i dati alla rappresentazione. Quando lutente chiude lapplicazio-
ne, lattributo readyState si stabilisce sul valore 4 e la connessione termina
normalmente.
Questa soluzione è di gran lunga migliore rispetto al Client Polling in
quanto il numero di pacchetti informativi inviati è pari alla quantità di im-
magini che la camera riesce ad elaborare, riferendosi ovviamente allunità
72
di tempo. Il ritardo di connessione è presente solo allinizio, in quanto le
variabili per il collegamento vengono allocate una sola volta, quindi si ha
la garanzia che i pacchetti arrivino ordinati senza ritardo gli uni dagli altri.
Inne laltro grande vantaggio nellutilizzo di questa tecnica riguarda luti-
lizzo delle risorse dei sistemi coinvolti, in particolare il browser, che vengono
alleggeriti dei carichi computazionali dovuti alle continue connessioni.
4.3.4 Interfaccia graca
Il sistema di rappresentazione dei dati si basa sul JavaScript e ovviamente su
HTML. Non potendo andare a modicare direttamente lo stream di immagi-
ni ottenuto con le API della camera, è stato necessario trovare una soluzione
alternativa basandosi appunto sulle richieste XMLHTTP. Daltra parte per
garantire allutente la possibilità di utilizzo dellapplicazione in modo dina-
mico, interattivo e semplice è stata creata uninterfaccia graca per mezzo
degli oggetti HTML in modo da trattare gli algoritmi secondo i parametri
desiderati in tempo reale.
Come precedentemente descritto, è possibile usare lapplicazione secon-
do tre modalità che si dierenziano tra loro dal tipo di algoritmo utilizzato
(FAST, Sobel o entrambi). A tale scopo sono state create tre pagine Web dif-
ferenti, una per ogni modalità, in modo da disegnare linterfaccia pi` u consona
allo scopo.
Rappresentazione corner
Quando lutente intende rilevare i corner della scena, quindi utilizzare lal-
goritmo FAST, si utilizza un tipo di rappresentazione che interagisce con le
API fornite da Axis. Infatti lidea è stata quella di sovrapporre un canvas
HTML ad uno stream video ottenuto mediante le API, entrambi di dimen-
sione 480360. Canvas è una estensione dellHTML standard che permette
il rendering dinamico di immagini bitmap gestibili attraverso un linguaggio
di scripting, JavaScript nel caso specico. La rappresentazione dei corner
avviene semplicemente disegnando sul canvas, quindi colorando ogni pixel
corrispondente alle coordinate ricevute mediante la richiesta XMLHTTP,
73
come si può vedere in Figura 4.6. Leetto ottenuto è lo stesso di come se
avessimo modicato direttamente le immagini dello stream video delle API.
Figura 4.6: Rappresentazione dei corner
Linterpretazione dei pacchetti avviene in modo molto semplice avendo
denito le regole di separazione dei contenuti, basta trovare i caratteri speciali
e convertire le stringhe di caratteri che rappresentano le coordinate in interi.
Questi numeri vengono usati per disegnare i corner sul canvas.
Poiche il disegno delle feature avviene alla ricezione di ogni pacchetto,
sarà necessario cancellare i risultati della precedente elaborazione sul canvas
prima di andare a disegnare la nuova lista di corner, altrimenti si crea una
situazione che non corrisponde alla realtà in quanto feature appartenenti alla
scena verrebbero a coesistere con le altre del frame successivo. Il modo pi` u
semplice per ovviare a questo è quello di utilizzare una funzione specica che
consiste semplicemente di rendere ogni pixel del canvas trasparente.
74
Rappresentazione edge
Nel caso in cui si intenda visualizzare loutput delloperatore di Sobel, e
quindi anche le relative quantizzazioni dellimmagine, si dovrà agire in mo-
do dierente. Non è possibile appoggiarsi ad uno stream video fornito dalle
API, infatti limmagine elaborata della scena viene mandata al client inte-
ramente, specicando ogni singolo valore di intensità dei pixel. Conoscendo
la risoluzione dellacquisizione dellimmagine e sapendo che i valori dei pi-
xel elaborati vengono mandati sequenzialmente, si ricostruisce limmagine
disegnando ogni punto sul canvas col valore intero interpretato nella richie-
sta XMLHTTP. Poiche ogni pixel è rappresentato in scala di grigi, bisogna
costruire la struttura delegata al disegno su canvas in modo appropriato. In-
fatti la modica del colore di un pixel appartenente al canvas viene eseguita
mediante una funzione specica che richiede i valori di rosso, verde e blu del
punto. La soluzione è stata banalmente quella di prendere il valore di grigio
della richiesta e assegnarlo ad tutti e tre i canali di colore necessari. In Figura
4.7 è mostrata la rappresentazione degli edge.
(a) Sobel (b) Thresholding
Figura 4.7: Rappresentazione degli edge
Rispetto alla rappresentazione dei corner si ha un notevole peggioramen-
to della performance, infatti nonostante il corpo della risposta del server
contenga tanti pacchetti quanti vengono generati dallelaborazione della ca-
mera, il motore JavaScript non riesce a disegnare i frame sucientemente
75
veloce. Questo è dovuto al fatto che laccesso ai singoli valori di un array in
JavaScript è molto lento.
Rappresentazione cluster
Lalgoritmo k-means viene eseguito sulla camera elaborando i corner rilevati
mediante lalgoritmo FAST. I cluster vengono quindi disegnati, a discrezione
dellutente, nello stesso canvas dove risiedono i corner. La camera non calcola
i conni dei cluster ne assegna agli angoli rilevati segni di appartenenza
ad un settore. Vengono inviate esclusivamente le coordinate dei centroidi
e il client stesso disegna il diagramma di Voronoi relativo in tempo reale.
Questa scelta è stata dettata dal fatto che per calcolare il diagramma sarebbe
stato necessario fare calcoli in virgola mobile, cosa che la camera non può
fare. Lalternativa sarebbe stata quella di usare lapposita libreria messa a
disposizione da Axis per poter approssimare calcoli di questo tipo ma al costo
di un pesante deterioramento delle prestazioni.
La responsabilità della rappresentazione del diagramma di Voronoi la
prende quindi il client, grazie allutilizzo di JavaScript.
`
E stata utilizzata
a tale scopo una libreria open-source di Raimond Hill [4] per il calcolo dei
conni dei cluster. Per quanto riguarda il rendering delle linee di separa-
zione cos` ottenute sono state fatte modiche ed adattamenti in modo che
il diagramma venisse disegnato sul canvas delle feature e avesse grandezza
esattamente uguale alla dimensione del canvas stesso.
Stima della velocità di rappresentazione
Per valutare leettiva frequenza di pacchetti al secondo che il browser riesce
a rappresentare è stato utilizzato un sistema di misura simile a quello per
la stima del frame-rate di un video. Per eseguire la stima si inizializza la
misura che chiamiamo FT a 0. Quindi supponendo di avere ricevuto il k-
esimo pacchetto, la stima del tempo medio di arrivo tra un frame e laltro si
ottiene mediante lequazione:
FT
k
= FT
k1
+
(t
k
t
k1
) FT
k1
f
s
(4.1)
76
dove t
k
è un valore intero che rappresenta listante di tempo dellarrivo del
pacchetto e f
s
è un valore stabilito a priori, usato per stabilizzare la stima in
modo che il suo valore non oscilli troppo bruscamente attorno ad una soglia
dopo larrivo di ogni pacchetto. Si osservi che in JavaScript listante di tempo
di arrivo può essere calcolato con unapposita funzione che restituisce la data
attuale, che comprende anche i millesimi di secondo. In ogni caso vale sempre
la proprietà t
k
> t
k1
.
Il calcolo eettivo della frequenza di disegno delle feature, denita come
CDPS (Corner Drawn Per Second), sempre supponendo di disegnare la
k-esima lista di corner, sarà dato da:
CDPS
k
=
1
FT
k
(4.2)
assumendo che FT
k
sia misurato in secondi. Questo valore e il numero to-
tale di corner contenuti allinterno del pacchetto ricevuto vengono disegnati
anchessi sul canvas e aggiornati in tempo reale assieme alle feature.
Si può fare una stima delle prestazioni di rappresentazione degli edge
usando le stesse formule relative al calcolo dei corner, in tal caso però viene
denita come EDPS (Edge Drawn Per Second).
Controlli manuali
Una delle peculiarità pi` u importanti dellapplicazione è la possibilità di avere
il controllo sui parametri di qualsiasi algoritmo utilizzato in tempo reale.
Lutente quindi può gestire semplicemente il funzionamento dellapplicazione
utilizzando dei controlli integrati nellinterfaccia graca della pagina Web,
senza necessità di riavviare lapplicazione ne di ricaricare la pagina stessa.
Gli input vengono gestiti da oggetti HTML, come slider, bottoni e menu a
cascata, in base al parametro da regolare. Ad esempio, per variare la soglia
del rilevatore di angoli è stato utilizzato uno slider mentre per attivare la
soppressione dei non massimi è stato scelto un semplice bottone.
Gli oggetti HTML ovviamente non possono interagire col server da soli.
Ancora una volta JavaScript risolve il problema integrandosi con tali oggetti.
A seconda dellevento legato alloggetto HTML esiste una specica funzione
77
che gestisce la situazione per comunicare con la camera. Il passo successivo
è quello di fare una richiesta con loggetto XMLHttpRequest alla CGI di ag-
giornamento del server che provvederà alla variazione del parametro secondo
il valore scelto dallutente.
4.4 Metodi di trasmissione
La trasmissione di dati tra il server e il client è stata ulteriormente migliorata
focalizzando lattenzione sullutilizzo delle risorse a disposizione. Infatti sono
stati usati alcuni approcci ingegneristici per rendere la comunicazione tra le
due parti pi` u leggera e per contenere la spesa di risorse del browser.
Il primo studio fatto riguarda le situazioni in cui la banda a disposi-
zione per la connessione non è molto ampia, quindi quando si necessita di
diminuire la quantità dei bit trasmessi però mantenendo la stessa qualità di
informazione. La codica dei dati in uscita del server è utile per i contesti in
cui si dispone di scarse risorse e inoltre comporta un altro risultato inatteso
riguardo il tempo impiegato nel rappresentare le feature.
Il secondo studio svolto riguarda invece lutilizzo della memoria del bro-
wser e di conseguenza lecienza del motore JavaScript. Lutilizzo di una
singola connessione per il trasferimento dati comporta il fatto che il buer
contenente la stringa delle feature venga continuamente riempito. Poiche
la dimensione del buer è limitata dal browser, dopo un certo intervallo di
tempo giunge al limite massimo e quindi causa linterruzione della rappre-
sentazione delle feature. Sfruttando il fatto che uno stream di dati è di fatto
un messaggio formato di pi` u parti si ovvia a questo problema con un tipo di
contenuto che permette di contenere il corpo della risposta entro dimensioni
molto limitate.
4.4.1 Codica dei dati
I dati inviati dalla camera verso lutente inizialmente non erano codicati in
modo da risparmiare sulla banda della trasmissione dati. La situazione che
si presentava era condizionata dal fatto che i valori delle feature non erano
78
rappresentati come interi ma come caratteri, uno per ogni cifra e inoltre si
aggiungevano i caratteri di separazione. Nel caso peggiore, per inviare una
coppia di coordinate riferite ad un corner, erano necessari tre caratteri per
il numero dellascissa, tre per lordinata e in pi` u altri due caratteri speciali
per separare le due coordinate sia tra di loro che rispetto a quelle degli altri
angoli.
Il motivo della scelta di codica testuale dei dati è legato al fatto che il
browser possa comunicare con la camera senza la perdita di alcuna informa-
zioni.
In questo caso tuttavia non cera la disponibilità di un compressore JPEG
e i dati inviati avevano una grandezza eccessiva che si desiderava tentare di
ridurre. Vista limpossibilità di trattare i dati come numeri interi, si è scelto
di utilizzare codiche alternative che si adattavano al tipo di problema.
Il progetto si sviluppa in modo che i caratteri in uscita vengano codicati
dalla camera e decodicati dal client prima della loro rappresentazione, uti-
lizzando però un linguaggio diverso, ovvero JavaScript. La codica delta e la
codica Run-length sono le compressioni dati scelte. Per motivi di ecienza
non è possibile risolvere questo problema facendo uso di algoritmi comples-
si, e quindi pi` u performanti dal punto di vista della compressione. Le due
codiche usate infatti sono metodi molto banali e non sempre sono funzio-
nali, tuttavia la loro velocità di esecuzione non compromette la performance
dellapplicazione. Inoltre la scelta di questi metodi di compressione molto
semplici è dettata dal fatto che la codica e la decodica delle informazioni
viene svolta mediante due linguaggi diversi, C++ e JavaScript.
Codica delta
La codica delta è un modo per immagazzinare o trasmettere dati usando le
dierenze tra i dati sequenziali piuttosto che sullinsieme completo dei dati,
attualmente utilizzata anche dai Web server per mandare gli aggiornamenti
delle pagine Web in forma di dierenza tra le versioni [40]. A volte la codica
delta è chiamata compressione delta, in particolare quando è richiesta la
storia dei cambiamenti (per esempio nei progetti software). Le dierenze
79
sono registrate in valori discreti chiamati delta o di. Poiche i cambiamenti
sono di solito piccoli, la codica delta riduce notevolmente la ridondanza
dei dati. Insiemi di uniche delta sono sostanzialmente pi` u ecienti nella
riduzione di spazio che i loro equivalenti non codicati.
La natura dei dati da codicare inuenza lecacia di un particolare
algoritmo di compressione. La compressione delta ore il suo meglio quando
i dati hanno variazioni piccole o costanti. Per un insieme non ordinato di
dati, questo metodo potrebbe orire una compressione piccola o nulla.
Questo tipo di codica è stato particolarmente performante nel caso di
invio di corner, riducendo notevolmente la grandezza del pacchetto trasmes-
so. Il motivo sta nel fatto che lalgoritmo FAST rileva gli angoli in sequenza,
partendo dalla prima riga e scendendo lungo laltezza dellimmagine no ad
elaborare lultima riga. Alla luce di queste considerazioni si osserva imme-
diatamente che nel caso in cui due angoli si trovino sulla stessa riga dellim-
magine, lordinata del secondo angolo viene sicuramente codicata col valore
nullo e quindi sarà necessario solo un carattere invece dei tre potenziali. Al-
lo stesso modo anche lascissa ha buone probabilità di essere codicata con
meno di tre caratteri in quanto esiste una buona probabilità che due angoli
consecutivi possano trovarsi a meno di 10 (quindi un carattere per la codica)
o 100 pixel (due caratteri) di distanza su una stessa riga.
Nel caso invece dellinvio di edge invece questa tecnica non ha prodotto
risultati eccellenti, tuttavia per la rappresentazione delle immagini con tanti
livelli di grigio ha comunque fornito una piccola riduzione del traco dati
rispetto al formato non compresso.
Codica Run-length
La codica Run-length cerca nei dati da comprimere una serie di valori uguali
e la sostituisce con un solo elemento, quindi un carattere speciale e inne il
numero di volte che esso va ripetuto. Per esempio supponiamo di avere
unimmagine dove la prima riga è formata da cento pixel neri, la codica
memorizzerà il primo pixel nero poi metterà il carattere speciale e in seguito
memorizzerà il numero 100. Cos` invece di occupare cento locazioni la prima
80
riga ne occuperà solo tre. Il carattere speciale è denito diversamente da ogni
implementazione dellalgoritmo e serve a distinguere un elemento normale da
uno compresso. Lalgoritmo funziona bene in presenza di immagini con pochi
colori molto uniformi, ovvero in serie di dati che abbiano molte ripetizioni al
loro interno.
Questo tipo di codica è stato impiegato per le immagini trattate con
lalgoritmo di Sobel e i risultati ottenuti sono stati dierenti a seconda della
modalità di rappresentazione desiderata. Nel caso dellimmagine non quan-
tizzata, non solo la dimensione dellinformazione inviata non diminuiva ma
addirittura aumentava considerevolmente. Tuttavia quantizzando limmagi-
ne, quindi scegliendo rappresentazioni con sempre meno quantità di grigi,
lecienza della codica aumentava in modo sorprendente, no ad arrivare
ad un risultato eccellente nel caso della binarizzazione. Il fenomeno si spie-
ga semplicemente considerando il fatto che in unimmagine non quantizzata,
quindi con 256 livelli di grigio, la probabilità di trovare due pixel consecutivi
con la stessa intensità è molto bassa, sia per la natura della scena ripresa
che per il rumore presente. Al contrario, diminuendo il numero di grigi usati
per la rappresentazione, la probabilità aumenta in modo sostanziale, gli ef-
fetti dovuti al rumore contribuiscono sempre di meno e la quantità di dati
trasmessi diminuisce di conseguenza.
Il caso limite della binarizzazione è particolarmente adatto a questo tipo
di codica, in quanto si può codicare intere righe di immagine con pochis-
simi caratteri. Un eetto molto signicativo in questo contesto riguarda
la rappresentazione stessa. La codica Run-length non solo abbatte i costi
dimensionali di trasmissione, ma consente a JavaScript di poter disegnare
limmagine ricevuta in un tempo minore. Infatti poiche ogni coppia di valori
presenti nel pacchetto indica il valore dellintensità e il numero di occorrenze
consecutive, è possibile disegnare con JavaScript interi rettangoli monocro-
matici di pixel, a seconda del colore, senza accedere ad ogni singolo punto
appartenente al canvas. Laumento di velocità in questo caso è rilevante nel
caso in cui i pixel da disegnare siano un numero sucientemente elevato.
81
4.4.2 Multipart Mixed-Replace
Lo streaming delle feature dalla camera verso il client inizialmente veniva
eettuato riempendo un buer di caratteri allinterno delloggetto XMLHtt-
pRequest il quale allarrivo di ogni pacchetto accodava la nuova stringa di
caratteri allultima posizione occupata, determinando quindi una crescita co-
stante della dimensione del buer. Col passare del tempo il processo veniva
ripetetuto ciclicamente e si giungeva ad una situazione limite in cui il buf-
fer raggiungeva la grandezza massima consentita e il motore JavaScript si
arrestava n quando non veniva ricaricata la pagina stessa.
La soluzione utilizzata per questo grave problema è stata quella di con-
siderare lo streaming come linvio di un messaggio composto da pi` u parti,
ovvero in questo caso da pi` u blocchi di feature. A tal proposito la standard
internet MIME Multipurpose Internet Mail Extensions permette di specica-
re e descrivere il formato dei messaggi [48]. Un messaggio MIME Multipart
contiene un conne che viene posto tra tutte le coppie di pacchetti che com-
pongono lintero messaggio. Ogni parte ha un proprio header che ne specica
il tipo di contenuto, nel nostro caso semplice testo, e un corpo.
La potenzialità di MIME permette di utilizzare estensioni dello standard
stesso che specicandola natura del messaggio e in che modo le parti che lo
compongono sono correlate. Una di queste estensioni è stata ritenuta partico-
larmente adatta allo scopo: Mixed-Replace. Il tipo di contenuto multipart/x-
mixed-replace è stato sviluppato come parte della tecnologia server push e
dello streaming HTTP. Ogni parte che compone il messaggio mixed-replace
ha una propria semantica, tuttavia ognuna di esse invalida la precedente,
prendendone il posto sul buer che memorizza il messaggio, nel momento
in cui essa viene ricevuta completamente. Questa è la stessa infrastruttura
utilizzata dagli stream M-JPEG che quindi permette il trasferimento di dati
nel tempo senza problemi relativi alla memorizzazione sul client.
82
Capitolo 5
Risultati Sperimentali
La stima della velocità di esecuzione è uno studio molto importante per
questa tipologia di programmi, in quanto lestrazione di feature di basso
livello rappresenta la fase iniziale di analisi di algoritmi molto pi` u complessi
e di conseguenza limitando il costo computazionale nel rilevamento dei punti
di interesse, si migliora la velocità di esecuzione anche delle operazioni pi` u
sosticate.
Per misurare le prestazioni dellapplicazione sviluppata, sono stati ese-
guiti gli algoritmi di rilevamento feature e sono stati calcolati i loro tempi di
esecuzione su un piccolo insieme di scene che di dierenziano in base al nume-
ro di corner rilevati a parità di soglia e di risoluzione di acquisizione. Le scene
che vengono prese di riferimento sono quelle mostrate nelle gure 5.1a, 5.1b e
5.1c. Ognuna di queste scene avrà un numero di corner caratteristico che di-
penderà sia dalla risoluzione che dalla soglia impostata sullalgoritmo FAST.
Unimmagine ad alto dettaglio avrà verosimilmente un numero pi` u elevato di
angoli rispetto alle scene meno dettagliate. Una stima del numero al variare
della soglia e della risoluzione può essere vista in Figura 5.2. La quantità di
corner diminuisce notevolmente allaumentare della soglia in quanto il crite-
rio Segment Test 2.1.2 assegna sempre pi` u risultati negativi. Idealmente se
si impostasse la soglia al valore massimo, ovvero 255, non verrebbe rilevato
alcun angolo indipendentemente dalla risoluzione di acquisizione o dal livello
di dettaglio della scena. Al contrario si nota che al diminuire della soglia
83
CAPITOLO 5. RISULTATI SPERIMENTALI
(a) Scena ad alto contenuto di dettagli
(b) Scena a medio contenuto di dettagli
(c) Scena a basso contenuto di dettagli
Figura 5.1: Le scene utilizzate per misurare la performance dellapplicazione
84
il numero di angoli rilevati cresce in modo quadratico, il criterio Segment
Test assegna sempre pi` u risultati positivi. Anche in questo caso, impostando
idealmente la soglia dellalgoritmo FAST al minimo valore possibile, ovvero
0, si ottiene un numero di corner pari esattamente alla dimensione dellim-
magine stessa, quindi un numero dipendente dalla risoluzione di acquisizione
ma indipendente dal livello di dettaglio della scena.
0
2000
4000
6000
8000
10000
12000
10 20 30 40 50 60
C
o
r
n
e
r
Threshold
160x120
240x180
360x240
480x360
640x480
Figura 5.2: Quantità di corner rilevati in una scena molto dettagliata
5.1 Valutazione della performance
Le prestazioni dellapplicazione vengono misurate in base al numero di frame
al secondo che la camera riesce ad elaborare, che deniamo FPPS (Frame
Processed Per Second), da non confondere con la quantità di frame al secondo
che la telecamera acquisisce, che deniamo FCPS (Frame Captured Per
Second). Questo numero rappresenta il limite superiore per la stima della
performance, perche sicuramente lapplicazione non può elaborare pi` u frame
85
di quanti ne vengano acquisiti, pertanto vale sempre la relazione:
FCPS FPPS (5.1)
Il numero di frame acquisiti in un secondo inoltre non può superare la soglia
di 30, in quanto è vincolato dalle impostazioni di fabbrica della telecamera
stessa.
Per calcolare il numero di frame elaborati non è possibile utilizzare un
apposito proler, in quanto il rmware presente sulla camera non lo prevede.
La soluzione è quindi quella di creare una struttura adatta alla misurazione
dei tempi mediante lutilizzo della libreria standard <time.h>. In questo
modo tuttavia la valutazione del tempo eettivo di esecuzione dei singoli
algoritmi misurato in millisecondi è poco accurata per le scene troppo detta-
gliate, quindi in generale si preferisce utilizzare la misura di performance in
termini di frame elaborati al secondo, ovvero considerando anche i tempi di
acquisizione e memorizzazione delle immagini. Ad ogni modo è interessante
valutare i tempi di esecuzione di tutti gli algoritmi su scene non particolar-
mente dettagliate, poiche in questi casi i tempi rilevati variano con meno
intensità e si può eseguire una stima pi` u accurata.
Per quanto riguarda il trasferimento di dati si svolge uno studio sulla
quantità media di informazione trasferita per ogni tipologia di codica uti-
lizzata. Le misurazioni vengono eettuate al variare del numero di livelli di
grigio desiderato per la rappresentazione dellimmagine.
5.2 Velocità di esecuzione
La stima della performance degli algoritmi viene fatta impostando il valore
massimo del tasso di acquisizione di frame da parte della telecamera, ovvero
30 FCPS. Esiste unimportante considerazione da fare riguardo la perfor-
mance. La necessità di rappresentazione dei dati implica lutilizzo di alcune
strutture e funzioni che rallentano pesantemente lesecuzione degli algoritmi.
Come è stato discusso nel capitolo 4, non è possibile modicare direttamente
lo stream di immagini ottenuto mediante le API e quindi si deve inviare i
dati riguardanti le feature su uno stream parallelo a quelle delle immagini,
86
delegando il compito di riunire i due ussi al client. Daltra parte lo stream
delle feature deve essere convertito in formato testuale prima dellinvio ver-
so il browser, tuttavia in questo modo si condiziona leettiva performance
dellapplicazione. A tal proposito viene fatta uno studio parallelo sulla ve-
locità di esecuzione dei vari algoritmi, considerando prima il caso senza la
rappresentazione dei dati e poi il caso con la rappresentazione.
5.2.1 Stima di analisi senza rappresentazione
Per calcolare leettiva velocità dellapplicazione senza la penalizzazione do-
vuta alla trasmissione, vengono eseguiti gli algoritmi per estrarre le feature
ma non vengono codicati come caratteri e non vengono inviati al client. Vie-
ne preso il tempo che intercorre tra lelaborazione di due frame consecutivi e
fatta una stima del tutto simile al calcolo della velocità di rappresentazione
delle caratteristiche del paragrafo 4.3.4. Lanalisi di performance si concen-
tra sulla stima di FPPS per lalgoritmo FAST al variare della soglia, della
risoluzione e del tipo di scena ripresa, per lalgoritmo Sobel al variare della
risoluzione dellimmagine e per lalgoritmo k-means al variare del numero di
cluster e della soglia riferita allalgoritmo FAST. Per valutare quanto inui-
scono i vari algoritmi sullesecuzione dellapplicazione si faccia riferimento
alla Figura 5.3. In questo caso la risoluzione viene ssata a 320240 e viene
fatta variare la soglia dellalgoritmo FAST. Da una prima analisi si nota che
in generale lalgoritmo FAST e lalgoritmo Sobel hanno quasi lo stesso tempo
di esecuzione, anche se il primo aumenta al diminuire della soglia. Il motivo
risiede nel fatto che diminuendo tale valore lalgoritmo di rilevamento corner
eettua il criterio Segment Test con probabilità maggiore e di conseguenza
si richiede pi` u tempo per terminare. Daltra parte loperatore di Sobel è
indipendente dalla scena ripresa o dal valore della soglia, quindi il tempo di
esecuzione rimane sempre uguale.
La soppressione dei non massimi per lalgoritmo FAST invece assume un
comportamento dierente. Se la soglia viene diminuita il numero di corner
aumenta in modo quadratico, e quindi loperazione di eliminazione deve es-
sere eseguita su buer sempre pi` u grandi. Il tempo di esecuzione pertanto
87
0
10
20
30
40
50
60
70
80
90
100
60 50 40 30 20 10
E
x
e
c
u
t
i
o
n

T
i
m
e

(
m
s
)
Threshold
FAST
Suppression
Sobel
K-means
Figura 5.3: Tempi di esecuzione in una scena di medio dettaglio
segue landamento quadratico del numero di angoli. Allo stesso modo anche
lalgoritmo k-means è strettamente legato al numero di corner rilevati, ma
avrà un aumento pi` u consistente del tempo di esecuzione poiche dipende an-
che da altri fattori, quali il numero di partizioni e il numero di iterazioni per
la convergenza.
Stima dellalgoritmo FAST
Il tempo di esecuzione dellalgoritmo FAST dipende strettamente dalla scena
inquadrata poiche ad unimmagine con tanti dettagli corrispondono tanti
corner, quindi viene speso pi` u tempo per lelaborazione rispetto ad una scena
poco dettagliata. In Figura 5.4a sono mostrati i valori di FPPS al variare
del valore della soglia confrontati tra le scene di riferimento utilizzate.
La risoluzione di acquisizione dei frame inuisce notevolmente nel tempo
di esecuzione di FAST come mostrato in Figura 5.4b. Il fatto pi` u rilevan-
te è il forte calo di performance dalla risoluzione di 320240 pixel a quella
di 480360 pixel. Il motivo di questo deterioramento di performance è do-
88
16
18
20
22
24
26
28
30
10 20 30 40 50 60
F
F
P
S
Threshold
High
Mid
Low
(a)
0
5
10
15
20
25
30
10 20 30 40 50 60
F
F
P
S
Threshold
240x180
320x240
480x360
(b)
Figura 5.4: Performance dellalgoritmo FAST
89
vuto al fatto che allaumento dei pixel da elaborare coincide un incremento
del tempo necessario alla telecamera per lacquisizione dei frame e per la
memorizzazione dei dati.
Stima dellalgoritmo Sobel
Il tempo di esecuzione per lestrazione degli edge mediante loperatore di
Sobel non dipende dalla scena ripresa ne da altri parametri. Lunica cosa
che inuisce è la quantità di pixel appartenenti allimmagine, ovvero alla
risoluzione. Come mostrato in Figura 5.5, anche in questo caso il calo di
performance pi` u netto si ha tra la risoluzione di 320240 pixel e 480360
pixel.
0
5
10
15
20
25
30
35
160x120 240x180 360x240 480x360 640x480
F
P
P
S
Resolution
Figura 5.5: Performance dellalgoritmo Sobel
Stima dellalgoritmo k-means
Lanalisi dellalgoritmo k-means è piuttosto interessante perche permette di
valutare la performance secondo diversi punti di vista. Infatti questo algo-
90
ritmo dipende sia dal numero di feature rilevato, sia dal numero di iterazioni
prima della convergenza, sia dal numero di cluster impostato. Facendo varia-
re il numero di settori k, si ottiene il risultato mostrato in Figura 5.6a. Il calo
di performance allaumentare dei cluster varia in modo pressoche lineare.
Fissando invece il numero di partizioni e facendo variare la soglia del
rilevamento di corner si nota come questo algoritmo sia particolarmente
performante nel caso in cui linsieme di feature sia piuttosto limitato, co-
me mostrato in Figura 5.6b. Ovviamente per la stima del k-means bisogna
prendere in considerazione anche il tempo di esecuzione dellalgoritmo FAST
che fornisce i dati necessari al partizionamento.
5.2.2 Stima di analisi con rappresentazione
La rappresentazione delle feature sul client implica che i dati riguardanti le
feature prodotte dagli estrattori vengano codicati in forma testuale, causan-
do un netto calo della performance di quasi tutti gli algoritmi. In questo caso
conviene trattare la stima della velocità di esecuzione in termini di dierenza
di performance tra le due modalità, ovvero si calcolano le dierenze di FPPS
tra il caso senza rappresentazione dei dati e il caso con la rappresentazione.
A tal scopo si denisce la misura che indica la dierenza di frame al secondo
elaborati come:
DFPPS = FPPS
nr
FPPS
r
(5.2)
dove i pedici r e nr indicano rispettivamente la presenza e lassenza della
rappresentazione dei dati. Nel caso dellalgoritmo FAST questo valore è
abbastanza importante, ma a bassissime risoluzioni non è molto rilevante in
quanto i corner rilevati sono pochi. In Figura 5.7a si nota come anche ad
alte risoluzioni questa dierenza venga attenuata.
Ancora pi` u signicativa è la dierenza nellesecuzione dellalgoritmo So-
bel, soprattutto a basse risoluzioni come si può vedere in Figura 5.7b. Il
motivo di questo fenomeno risiede nel fatto che nel caso dellutilizzo dello-
peratore di Sobel si ha la necessità di trasmettere lintera immagine al client,
quindi ogni singolo valore dei pixel dellimmagine elaborata deve essere codi-
91
8
10
12
14
16
18
20
3 4 5 6 7 8 9 10
F
P
P
S
K
240x180
360x240
(a)
0
5
10
15
20
25
30
10 20 30 40 50 60
F
P
P
S
Threshold
160x120
240x180
360x240
(b)
Figura 5.6: Performance dellalgoritmo k-means
92
0
2
4
6
8
10
12
14
16
10 20 30 40 50 60
D
i
f
f
e
r
e
n
c
e

F
F
P
S
Threshold
240x180
320x240
480x360
(a) Algoritmo FAST
0
5
10
15
20
25
30
160x120 240x180 360x240 480x360 640x480
D
i
f
f
e
r
e
n
c
e

F
P
P
S
Threshold
(b) Algoritmo Sobel
Figura 5.7: Dierenza di performance
93
cato in forma testuale e di conseguenza il tempo di esecuzione totale viene
drasticamente aumentato.
Per quanto riguarda lalgoritmo k-means non cè un deterioramento delle
prestazioni, in quanto è necessario il salvataggio e linvio di pochi centroidi
e quindi il tempo di esecuzione rimane praticamente invariato.
Lultimo punto su cui è importante focalizzarsi riguarda la soppressione
dei non massimi per lalgoritmo FAST. In condizioni normali, eseguire questo
tipo di operazione comporta una spesa accessoria, in termini di tempo di
esecuzione, oltre la normale esecuzione dellalgoritmo FAST. Tuttavia nel
caso in cui si necessita di una rappresentazione delle feature rilevate, e quindi
dellinvio al client delle informazioni, questo tipo di operazione diminuisce
il tempo di esecuzione dellalgoritmo FAST. Questo risultato può sembrare
contraddittorio, tuttavia il risultato si spiega banalmente. Se cè necessità di
rimuovere i non massimi, allora non cè alcun motivo di codicare le feature
estratte in formato testuale prima della soppressione. Questo procedimento
può essere normalmente svolto alla ne, quindi eseguito su una quantità di
dati relativamente pi` u piccola. Di conseguenza il tempo di esecuzione totale
risulta minore rispetto al caso senza soppressione.
5.2.3 Modica del frame rate di acquisizione
Nella sezione 4.2.2 è stato discusso un metodo molto ecace per aumentare
la performance dellapplicazione. La tecnica si basa sulla possibilità di cam-
biare il tasso di acquisizione di frame da parte della telecamera, quindi di
fatto risparmiando sul tempo totale impiegato per la memorizzazione delle
immagini riprese. Eettuando dei test sullesecuzione dellalgoritmo FAST si
notano notevoli miglioramenti soprattutto se vengono selezionate risoluzioni
molto alte. Come si osserva dalla Figura 5.8, se viene scelto un opportuno
tasso di acquisizione il guadagno di performance è notevole. Ad esempio, ad
una risoluzione di 320240 pixel lesecuzione dellalgoritmo facendo riferi-
mento a questa tecnica comporta no ad un guadagno di 3 FPPS rispetto
allesecuzione originale, ovvero quella a 30 FCPS. Nel caso della risoluzione
480360 pixel si hanno ottimi risultati, infatti nel caso migliore si ha un
94
guadagno di quasi 8 FPPS rispetto allesecuzione originale. Alla luce dei
0
5
10
15
20
25
0 5 10 15 20 25 30
F
P
P
S
FCPS
320x240
480x360
MAX1
MAX2
Figura 5.8: Tempo di esecuzione di FAST al variare del tasso di acquisizione
risultati ottenuti è importante conoscere quali sono le condizioni in cui la
telecamera deve lavorare e calibrare i parametri di acquisizione in modo da
ottenere il valore di FPPS pi` u vicino possibile al massimo.
La stessa tecnica può essere applicata per lesecuzione dellalgoritmo So-
bel, tuttavia non è altrettanto ecace. Esiste un minimo guadagno ma solo
a risoluzioni piuttosto alte, mentre nel resto dei casi questo metodo si rivela
completamente inecace. Daltra parte esiste un grande vantaggio rispet-
to allesecuzione dellalgoritmo FAST. Il tempo di esecuzione delloperatore
di Sobel non dipende dalla scena inquadrata, quindi il valore massimo di
FPPS rilevato facendo variare il numero di FCPS potrà essere preso come
riferimento per garantire unesecuzione pi` u eciente dellalgoritmo.
95
5.3 Compressione dei dati
Lo studio della quantità di dati trasmessi è molto importante per una ap-
plicazione che prevede uno scambio continuo di informazioni in un sistema
client-server. Nei casi in cui la banda disponibile della connessione non sia
sucientemente ampia è necessario congurare lapplicazione in modo da
minimizzare il pi` u possibile la grandezza dei dati. A tal proposito nel pa-
ragrafo 4.4.1 sono stati presentati alcuni metodi per ridurre la quantità di
informazione trasmessa.
0
10
20
30
40
50
60
70
80
90
2 4 8 16 32 64 128 256
K
B
Livelli di grigio
Raw
Run-Length
Delta
Figura 5.9: Dimensione media delle immagini codicate
Facendo variare il numero di livelli di grigio usati per la rappresentazione
dellimmagine elaborata con loperatore di Sobel si può mettere a confron-
to la quantità di dati trasmessa per ogni codica utilizzata. I test vengono
eseguiti acquisendo immagini di una scena molto dettagliata ad una risolu-
zione di 160120 pixel e per ogni numero discreto di livelli di grigio viene
calcolato il valore medio della quantità di dati trasmessa utilizzando le varie
codiche. In Figura 5.9 si può notare che non esiste una codica migliore
96
per tutti i livelli di grigio, ma ogni codica risulta la migliore in un certo
intervallo. La trasmissione di immagini con 16 o pi` u livelli di grigio è pi` u
conveniente eseguirla la codica delta, altrimenti conviene utilizzare la codi-
ca Run-length che risulta estremamente conveniente per le immagini binarie,
riuscendo a comprimere i dati di oltre il 67% rispetto al formato non com-
presso. Tuttavia al crescere dei livelli di grigio i risultati diventano pessimi,
soprattutto per la rappresentazione a 256 colori che viene trasmessa con una
quantità di dati grande pi` u del doppio rispetto al formato non compresso.
Questo fenomeno si spiega banalmente considerando la natura della codica
stessa, infatti nel caso di immagini binarie ci sono lunghe ripetizioni di uno
stesso valore, mentre nel caso di immagini a 256 colori le ripetizioni di valori
allinterno del buer dei pixel saranno molto improbabili.
La dimensione delle immagini codicate con Run-Length dipende anche
dalla scena ripresa, infatti se è poco dettagliata serviranno molti meno ca-
ratteri per codicare limmagine. Come si può vedere in Figura 5.10 in una
scena in cui ci sono meno dettagli la dimensione dellimmagine codicata è
molto minore rispetto ad una pi` u dettagliata e inoltre al crescere dei livel-
li di grigio segue un andamento quadratico. Questo determina una buona
compressione anche per le immagini codicate con pochi livelli di grigio ri-
spetto in pi` u alle immagini binarie, ma resta sempre molto inecace per le
immagini a 256 colori.
97
0
10
20
30
40
50
60
70
80
90
2 4 8 16 32 64 128 256
K
B
Livelli di grigio
RL-Hi-txt
RL-Low-txt
Figura 5.10: Confronto della codica Run-length su scene diverse
98
Capitolo 6
Conclusioni e sviluppi futuri
In questo lavoro è stata sviluppata unapplicazione per lestrazione in tempo
reale di feature di basso livello a bordo di una telecamera Axis. In letteratura
è presente unampia gamma di rilevatori di corner e di edge, ma solo pochi
di essi sono adatti ad un sistema con risorse molto limitate, nel caso specico
una camera di videosorveglianza. I risultati del lavoro svolto sono:
La creazione e limplementazione di un rilevatore di corner molto ve-
loce, robusto e portabile.
Limplementazione di un rilevatore di edge basato sulloperatore di
Sobel.
Linterpretazione delle feature estratte con un algoritmo di clustering.
La realizzazione di un sistema client-server per la rappresentazione
delle feature.
La riduzione del traco di dati mediante opportune codiche.
Il rilevatore di corner creato con lalgoritmo Generic FAST è risultato
particolarmente performante in termini di velocità di esecuzione a basse ri-
soluzioni di immagine. Anche dal punto di vista della qualità delle feature i
risultati ottenuti sono stati quelli attesi. Tuttavia le risorse limitate della ca-
mera non hanno permesso una eciente elaborazione delle immagini ad alta
99
CAPITOLO 6. CONCLUSIONI E SVILUPPI FUTURI
risoluzione, quindi di fatto limitando i possibili utilizzi dei rilevatori creati
ad applicazioni che non richiedono immagini con grandi quantità di pixel.
Lalgoritmo k-means è stato utilizzato per dare una possibile interpreta-
zione riguardo gli angoli estratti ed è risultato particolarmente eciente per
insiemi di dati non troppo grandi. Per quanto riguarda la qualità del parti-
zionamento dellalgoritmo si può fare diverse considerazioni. Questo metodo
funziona molto bene in caso di insiemi di dati compatti e ben separati tra
di loro. Nel caso dei corner estratti dal rilevatore proposto, vengono utiliz-
zate esclusivamente le coordinate spaziali degli angoli come parametri per
lesecuzione dellalgoritmo, quindi non cè garanzia di avere insiemi di da-
ti compatti in modo da avere separazioni nette e anche mediante lutilizzo
dellindice di compattezza il risultato non è sempre quello atteso. Tuttavia
è possibile pensare ad unestensione del metodo utilizzato, includendo nei
parametri dellalgoritmo di partizionamento anche gli edge. Supponendo di
eseguire il metodo di thresholding sullimmagine elaborata dalloperatore di
Sobel con una soglia opportuna, si possono unire i contenuti informativi delle
due tipologie di feature ed eseguire lo stesso algoritmo di partizionamento.
Successivamente stimando il numero di feature per ogni settore ottenuto si
può avere unidea generale sulla qualità di informazione allinterno dei va-
ri cluster. Se lapplicazione viene eseguita su una telecamera PTZ in questo
modo è possibile direzionare linquadratura in base alle informazioni ottenute
dallalgoritmo k-means.
Lutilizzo dellalgoritmo k-means ha permesso di fare unulteriore osser-
vazione. Facendo variare la soglia dellalgoritmo FAST si è potuto notare
che i centroidi si comportavano in maniera diversa. Se si imposta una so-
glia molto alta i corner rilevati sono pochi, quindi le posizioni dei centroidi
variano considerevolmente tra un frame e laltro e di conseguenza le forme
dei cluster sono molto diererenti. Diminuendo la soglia invece si è osserva-
to che le posizioni dei centroidi tendono ad essere pi` u stabili, mantenendo
le loro coordinate in un intorno di pixel sempre pi` u piccolo. Tuttavia se la
soglia viene diminuita eccessivamente, allora lalgoritmo FAST rileva anche
i corner deboli, ovvero la rilevazione viene pesantemente inuenzata dal
rumore termico presente nelle immagini riprese. Leetto ottenuto in questo
100
caso è che i centroidi perdono la stabilità e la loro posizione torna a variare
intensamente. Lidea di fondo è che ci sia una correlazione tra la soglia del-
lalgoritmo FAST e la stabilità dei centroidi. A tal proposito si può pensare
di eseguire uno studio sullerrore medio delle posizioni dei centroidi tra un
frame e il successivo al variare della soglia, e in seguito scegliere in modo
adattivo il valore di soglia che minimizza quellerrore.
Il sistema di interazione tra client e server è pesantemente condizionato
dal fatto che non è possibile modicare lo stream video direttamente a bor-
do della camera, ne è possibile utilizzare il compressore JPEG per inviare
le immagini annotate. Questo comporta due grandi svantaggi, da una par-
te la diminuzione delle prestazioni della telecamera e dallaltra un eccessivo
traco dati. Pertanto se la società Axis renderà possibile le operazioni cita-
te si otterranno risultati decisamente migliori per la rappresentazione delle
caratteristiche estratte.
Il lavoro svolto per lestrazione delle feature di basso livello ha posto le
basi per una serie di possibili sviluppi futuri:
Tracking - I corner hanno in genere un alto livello di ripetitività, quin-
di un oggetto in movimento presenterà verosimilmente le stesse feature
in ogni frame. Una camera PTZ può seguire un oggetto mediante i
propri meccanismi basandosi sui corner rilevati. Inoltre le feature si
possono anche usare per stimare il moto della telecamera stessa.
Classicazione - Gli oggetti tendono ad assumere una disposizione
di feature caratteristica, quindi una camera può essere in grado di ri-
conoscere e classicare alcune tipologie di elementi grazie ai rilevatori.
Ad esempio si può allenare unapplicazione per riconoscere i veicoli che
transitano in un certo punto di unautostrada, quindi classicandoli in
automobili, camion, moto o SUV.
Compressione - Lo studio delle feature allinterno di unimmagine ri-
presa può essere molto indicativo riguardo il contenuto di informazione
della scena. Infatti elementi molto dettagliati, come ad esempio tar-
ghe delle automobili, insegne, volti umani e altro, tendono ad avere un
101
grande numero di punti di interesse, sia corner che edge. Invece zone
piuttosto uniformi, ad esempio muri e strade, presentano un numero di
feature molto basso. Si possono sfruttare queste caratteristiche strut-
turali per creare unapplicazione che comprime limmagine in base al
livello di dettaglio delle zone riprese [7], quindi in base al numero di
feature rilevate. In pratica, lo scopo è quello di ottenere unimmagine
che abbia una qualità molto elevata nelle zone con molti punti di inte-
resse e la minima possibile nei luoghi in cui le feature sono assenti. In
questo modo si ha anche il vantaggio del risparmio nella compressione
dei dati.
102
Appendice A
Codice sorgente dellalgoritmo
Generic FAST
A.1 Fast.h
#i f ndef FAST H
#define FAST H
#include <s t r i ng . h>
#include Pi xel . h
using namespace st d ;
typedef unsigned char ui nt 8 t ;
cl ass Fast
protected :
i nt m l ower t ;
i nt m hi gher t ;
i nt m n ;
void make of f s e t s ( i nt pi xe l [ ] , i nt r ow s t r i de ) ;
bool zer o dar k ( const ui nt 8 t p , const i nt pi xe l [ ] ) ;
bool z e r o br i ght ( const ui nt 8 t p , const i nt pi xe l [ ] ) ;
103
APPENDICE A. CODICE SORGENTE DELLALGORITMO GENERIC FAST
bool e i ght dar k ( const ui nt 8 t p , const i nt pi xe l [ ] ) ;
bool e i g ht br i g ht ( const ui nt 8 t p , const i nt pi xe l [ ] ) ;
public :
Fast ( )
Fast ( )
Pi xel f a s t de t e c t ( const ui nt 8 t im , i nt xs i ze , i nt ys i ze ,
i nt s t r i de , i nt b , i nt &r et num cor ner s ) ;
void f as t det ect nonmax ( const ui nt 8 t im , const i nt &xs i ze ,
const i nt &ys i ze , const i nt &s t r i de , const i nt &b , i nt&
r et num cor ner s , i nt s uppr es s i on ) ;
i nt f a s t c o r n e r s c o r e ( const ui nt 8 t p , const i nt pi xe l [ ] , i nt
t s t a r t , bool br i ght ) ;
i nt f a s t s c o r e ( const ui nt 8 t i , i nt s t r i de , Pi xel cor ner s ,
i nt num corners , i nt b) ;
Pi xel nonmax suppressi on ( const Pi xel cor ner s , const i nt
s cor es , i nt num corners , i nt &ret num nonmax ) ;
bool f u l l s e g t e s t b r i g h t ( const ui nt 8 t p , const i nt pi xe l [ ] )
;
bool f u l l s e g t e s t d a r k ( const ui nt 8 t p , const i nt pi xe l [ ] ) ;
;
#endif
A.2 Fast.cpp
#include Fast . h
void Fast : : f as t det ect nonmax ( const ui nt 8 t im , const i nt&
xs i ze , const i nt& ys i ze , const i nt &s t r i de , const i nt &b , i nt
& r et num cor ner s , i nt s uppr es s i on )
i nt num corners ;
i nt s c or e s ;
104
Pi xel c or ne r s ;
Pi xel nonmax ;
c or ne r s = f a s t de t e c t ( im , xs i ze , ys i ze , s t r i de , b ,
r et num cor ner s ) ;
num corners = r et num cor ner s ;
i f ( s uppr es s i on )
s c or e s = f a s t s c o r e ( im , s t r i de , cor ner s , num corners , b) ;

nonmax = nonmax suppressi on ( cor ner s , s cor es , num corners ,
r et num cor ner s ) ;
f r e e ( s c or e s ) ;
f r e e ( nonmax) ;
f r e e ( c or ne r s ) ;
bool Fast : : f u l l s e g t e s t b r i g h t ( const ui nt 8 t p , const i nt

pi xe l [ ] )
i nt pi x count = 1;
i nt pt r = 1;
i f ( p [ pi xe l [ 0 ] ] > m hi gher t )
while ( p [ pi xe l [ pt r ] ] > m hi gher t )
i f (++pi x count >= 9)

return true ;
pt r ++;
pt r = 15;
//CounterCl ockWise

return true ;
105
ptr ;
i f ( p [ pi xe l [ 8 ] ] > m hi gher t )
pi x count = 1;
pt r = 9;
//Cl ockWise

return true ;
pt r = ( pt r + 1) % 16;
pt r = 7;
//CounterCl ockWise

return true ;
pt r > 0 ? pt r : pt r = 15;
return f al se ;
bool Fast : : f u l l s e g t e s t d a r k ( const ui nt 8 t p , const i nt pi xe l

[ ] )
i nt pi x count = 1;
i nt pt r = 1;
i f ( p [ pi xe l [ 0 ] ] < m l ower t )
while ( p [ pi xe l [ pt r ] ] < m l ower t )

return true ;
pt r ++;
106
pt r = 15;
//CounterCl ockWise

return true ;
ptr ;
i f ( p [ pi xe l [ 8 ] ] < m l ower t )
pi x count = 1;
pt r = 9;
//Cl ockWise

return true ;
pt r = ( pt r + 1) % 16;
pt r = 7;
//CounterCl ockWise

return true ;
pt r > 0 ? pt r : pt r = 15;
return f al se ;
A.3 Fast9.cpp
#include Fast . h
i nt Fast : : f a s t c o r n e r s c o r e ( const ui nt 8 t p , const i nt pi xe l [ ] ,
i nt t s t a r t , bool br i ght )
107
i nt t max = 255;
i nt t mi n = t s t a r t ;
i nt t ;
i f ( br i ght )
while ( t mi n != ( t max 1) && t mi n != t max )
t = ( t max + t mi n ) / 2;
m hi gher t = p + t ;
i f ( ! f u l l s e g t e s t b r i g h t ( p , pi xe l ) )
t max = t ;
el se
t mi n = t ;
el se
while ( t mi n != ( t max 1) && t mi n != t max )
t = ( t max + t mi n ) / 2;
m l ower t = p t ;
i f ( ! f u l l s e g t e s t d a r k ( p , pi xe l ) )
t max = t ;
el se
t mi n = t ;
return t mi n ;
void Fast : : make of f s e t s ( i nt pi xe l [ ] , i nt r ow s t r i de )
pi xe l [ 0 ] = 0 + r ow s t r i de 3;
pi xe l [ 1 ] = 1 + r ow s t r i de 3;
pi xe l [ 2 ] = 2 + r ow s t r i de 2;
pi xe l [ 3 ] = 3 + r ow s t r i de 1;
108
pi xe l [ 4 ] = 3 + r ow s t r i de 0;
pi xe l [ 5 ] = 3 + r ow s t r i de 1;
pi xe l [ 6 ] = 2 + r ow s t r i de 2;
pi xe l [ 7 ] = 1 + r ow s t r i de 3;
pi xe l [ 8 ] = 0 + r ow s t r i de 3;
pi xe l [ 9 ] = 1 + r ow s t r i de 3;
pi xe l [ 1 0 ] = 2 + r ow s t r i de 2;
pi xe l [ 1 1 ] = 3 + r ow s t r i de 1;
pi xe l [ 1 2 ] = 3 + r ow s t r i de 0;
pi xe l [ 1 3 ] = 3 + r ow s t r i de 1;
pi xe l [ 1 4 ] = 2 + r ow s t r i de 2;
pi xe l [ 1 5 ] = 1 + r ow s t r i de 3;
i nt Fast : : f a s t s c o r e ( const ui nt 8 t i , i nt s t r i de , Pi xel

cor ner s , i nt num corners , i nt t )
i nt n ;
i nt pi xe l [ 1 6 ] ;
i nt s c or e s = ( i nt ) mal l oc ( si zeof ( i nt ) num corners ) ;
make of f s e t s ( pi xel , s t r i de ) ;
for ( n=0; n < num corners ; n++)
s c or e s [ n ] = f a s t c o r n e r s c o r e ( i + c or ne r s [ n ] . y s t r i de +
c or ne r s [ n ] . x , pi xel , t , c or ne r s [ n ] . br i ght ) ;
return s c or e s ;
Pi xel Fast : : f a s t de t e c t ( const ui nt 8 t im , i nt xs i ze , i nt ys i ze

, i nt s t r i de , i nt t , i nt &r et num cor ner s )
i nt num corners = 0;
i nt n pos = 0;
i nt r s i z e =512;
109
i nt pi xe l [ 1 6 ] ;
i nt x , y ;
i nt pos t r , ne g t r ;
i nt b count , d count ;
const ui nt 8 t p ;
Pi xel px ;
Pi xel r e t c o r ne r s ;
r e t c o r ne r s = ( Pi xel ) mal l oc ( si zeof ( Pi xel ) r s i z e ) ;
make of f s e t s ( pi xel , s t r i de ) ;
for ( y=3; y < ys i z e 3; y++)
for ( x=3; x < xs i z e 3; x++)
p = im + y s t r i de + x ;
b count = 0;
d count = 0;
pos t r = p + t ;
ne g t r = p t ;
i f ( p [ pi xe l [ 0 ] ] > pos t r )
b count++;
i f ( p [ pi xe l [ 8 ] ] > pos t r )
b count++;
i f ( b count >= 1)
i f ( p [ pi xe l [ 1 2 ] ] > pos t r )
b count++;
i f ( b count == 1)
i f ( p [ pi xe l [ 4 ] ] > pos t r )
b count ++;
i f ( b count >=2)
110
m hi gher t = pos t r ;
i f ( f u l l s e g t e s t b r i g h t ( p , pi xe l ) )
i f ( num corners == r s i z e )
r s i z e =2;
r e t c o r ne r s = ( Pi xel ) r e a l l o c ( r e t c or ne r s , si zeof (
Pi xel ) r s i z e ) ;
r e t c o r ne r s [ num corners ] . x = x ;
r e t c o r ne r s [ num corners ] . y = y ;
r e t c o r ne r s [ num corners ] . br i ght = true ;
num corners++;
continue ;
i f ( p [ pi xe l [ 0 ] ] < ne g t r )
d count++;
i f ( p [ pi xe l [ 8 ] ] < ne g t r )
d count++;
i f ( d count >= 1)
i f ( p [ pi xe l [ 1 2 ] ] < ne g t r )
d count++;
i f ( d count == 1)
i f ( p [ pi xe l [ 4 ] ] < ne g t r )
d count ++;
i f ( d count >= 2)
m l ower t = ne g t r ;
i f ( f u l l s e g t e s t d a r k ( p , pi xe l ) )
i f ( num corners == r s i z e )
r s i z e =2;
111
r e t c o r ne r s = ( Pi xel ) r e a l l o c ( r e t c or ne r s , si zeof (
Pi xel ) r s i z e ) ;
r e t c o r ne r s [ num corners ] . x = x ;
r e t c o r ne r s [ num corners ] . y = y ;
r e t c o r ne r s [ num corners ] . br i ght = f al se ;
num corners++;
continue ;
r et num cor ner s = num corners ;

return r e t c o r ne r s ;
A.4 Nonmax.cpp
#include Fast . h
#define Compare (X, Y) ( (X)>=(Y) )
Pi xel Fast : : nonmax suppressi on ( const Pi xel cor ner s , const i nt
s cor es , i nt num corners , i nt &ret num nonmax )
i nt num nonmax = 0;
i nt l as t r ow ;
i nt r ow s t ar t ;
i nt i , j ;
i nt n pos = 0;
Pi xel ret nonmax ;
const i nt s z = ( i nt ) num corners ;
i nt poi nt above = 0;
i nt poi nt bel ow = 0;
i nt prev row ;
i nt s c or e ;
112
Pi xel pos ;
i f ( num corners < 1)
ret num nonmax = 0;

return 0;
ret nonmax = ( Pi xel ) mal l oc ( num corners si zeof ( Pi xel ) ) ;

l as t r ow = c or ne r s [ num corners 1] . y ;
r ow s t ar t = ( i nt ) mal l oc ( ( l as t r ow+1) si zeof ( i nt ) ) ;
for ( i =0; i < l as t r ow +1; i ++)
r ow s t ar t [ i ] = 1;
prev row = 1;
for ( i =0; i < num corners ; i ++)
i f ( c or ne r s [ i ] . y != prev row )
r ow s t ar t [ c or ne r s [ i ] . y ] = i ;
prev row = c or ne r s [ i ] . y ;
for ( i =0; i < s z ; i ++)
s c or e = s c or e s [ i ] ;
pos = c or ne r s [ i ] ;
i f ( i > 0)
i f ( c or ne r s [ i 1] . x == pos . x1 && c or ne r s [ i 1] . y == pos . y &&

Compare ( s c or e s [ i 1] , s c or e ) )
continue ;
i f ( i < ( s z 1) )
113
i f ( c or ne r s [ i +1] . x == pos . x+1 && c or ne r s [ i +1] . y == pos . y &&

Compare ( s c or e s [ i +1] , s c or e ) )
continue ;
i f ( pos . y != 0 && r ow s t ar t [ pos . y 1] != 1)
i f ( c or ne r s [ poi nt above ] . y < pos . y 1)

poi nt above = r ow s t ar t [ pos . y 1] ;
for ( ; c or ne r s [ poi nt above ] . y < pos . y && c or ne r s [
poi nt above ] . x < pos . x 1; poi nt above++)
for ( j=poi nt above ; c or ne r s [ j ] . y < pos . y && c or ne r s [ j ] . x <=

pos . x + 1; j ++)
i nt x = c or ne r s [ j ] . x ;
i f ( ( x == pos . x 1 [ [ x ==pos . x [ [ x == pos . x+1) &&
Compare ( s c or e s [ j ] , s c or e ) )
goto cont ;
i f ( pos . y != l as t r ow && r ow s t ar t [ pos . y + 1] != 1 &&

poi nt bel ow < s z )
i f ( c or ne r s [ poi nt bel ow ] . y < pos . y + 1)

poi nt bel ow = r ow s t ar t [ pos . y+1] ;
for ( ; poi nt bel ow < s z && c or ne r s [ poi nt bel ow ] . y == pos . y
+1 && c or ne r s [ poi nt bel ow ] . x < pos . x 1; poi nt bel ow
++)
for ( j=poi nt bel ow ; j < s z && c or ne r s [ j ] . y == pos . y+1 &&

c or ne r s [ j ] . x <= pos . x + 1; j ++)
114
i nt x = c or ne r s [ j ] . x ;
i f ( ( x == pos . x 1 [ [ x ==pos . x [ [ x == pos . x+1) &&
Compare ( s c or e s [ j ] , s c or e ) )
goto cont ;
ret nonmax [ num nonmax++] = c or ne r s [ i ] ;

cont :
;
f r e e ( r ow s t ar t ) ;
ret num nonmax = num nonmax ;
return ret nonmax ;
A.5 Pixel.h
#i f ndef PIXEL H
#define PIXEL H
#include <s t di nt . h>
typedef struct
ui nt 16 t x , y ;
bool br i ght ;
Pi xel ;
#endif
115
Appendice B
Software Development Kit
Il Software Development Kit integrato di Axis è un insieme di strumenti
ed interfacce nalizzato allo sviluppo di applicazioni per i prodotti Axis.
Ogni software viene sviluppato come un Embedded Axis Package(EAP) e poi
installato sulla telecamera.
B.1 Compilatore CRIS
Prima di utilizzare lSDK è necessario installare compilatore CRIS, fornito
dalla stessa Axis, che è un GCC GNU Compiler Collection per i processori
usati nei prodotti Axis, come ad esempio lARTPEC-3. Per poter creare
applicazioni compatibili con la camera Axis, quindi utilizzare il compila-
tore CRIS, è necessario lavorare in un sistema UNIX. Per linstallazione è
suciente usare il comando:
===============================================================
> dpkg -i cris-dist-v32-r93-i386.deb
===============================================================
Questo provvederà ad installare il compilatore sotto /usr/local.
116
APPENDICE B. SOFTWARE DEVELOPMENT KIT
B.2 Installazione SDK
Per quanto riguarda linstallazione dellSDK è necessario avere il le in-
stall sdk.bin. I comandi da eseguire in questo caso sono:
===============================================================
> chown nome_utente install_sdk.bin
> ./install_sdk.bin
> cd axis/emb-app-sdk-[ver]
===============================================================
dove ver si riferisce alla versione dellSDK che si desidera installare.
Gli strumenti forniti dal Software Development Kit installato, compren-
dono librerie ed interfacce, le di ambiente, binari precompilati, manuali e
documentazione, applicazioni di esempio e, a seconda della versione utiliz-
zata, possono essere disponibili strumenti opzionali come debugger e proler
specici per la telecamera.
B.3 Creazione del package
Il primo passo per la creazione del software è linizializzazione delle variabili
dambiente per lSDK. La procedura è quella di posizionarsi sulla directory
root dellSDK mediante la shell e digitare il comando:
===============================================================
> . ./init_env
===============================================================
Tale comando provvederà ad eseguire le seguenti operazioni:
controllare la posizione del compilatore e il suo corretto funzionamento;
impostare la variabile dambiente AXIS TOP DIR;
aggiungere AXIS TOP DIR/tools/build/bin al path;
aggiungere AXIS TOP DIR/tools/scripts al path.
117
Il passo successivo prevede la compilazione dei sorgenti al ne di creare
un package EAP. Posizionandosi nella directory contenente i le sorgenti
dellapplicazione, si digita il seguente comando per ottenere il package:
===============================================================
> create-package.sh
===============================================================
Tale comando farà le seguenti operazioni:
creazione del le .target-makefrag;
esecuzione del comando make nella directory corrente;
controlla se il le package.conf esiste ed è sintatticamente corretto e
se necessario, chiede i parametri mancanti e provvede a creare il le
package.conf;
se non esiste, crea e lascia vuoto il le param.conf;
crea un pacchetto che comprende i le binari insieme con i le html e
i le di congurazione.
Una volta eseguito questo comando, verranno aggiunti i seguenti le nella
directory corrente:
.target-makefrag: speciche di compilazione;
nomeApplicazione: applicazione eseguibile (le binario);
nomeApplicazione maxVersion minVersion ARTPEC-3.eap:
package le.
B.4 Upload sulla camera
Loutput prodotto viene inne caricato sulla telecamera attraverso linterfac-
cia graca oppure mediante uno script da shell di comando:
118
===============================================================
> eap-install.sh axis_device_ip psw_root install
===============================================================
Allo stesso modo per mandare in esecuzione o fermare lapplicazione si può
usare linterfaccia graca oppure i comandi da shell:
===============================================================
> install-onto-target.sh start
> install-onto-target.sh stop
===============================================================
B.5 Interfacce dellSDK
Le interfacce messe a disposizione svolgono un ruolo fondamentale per lo
sviluppo dellapplicazione, infatti esse contengono tutte le funzioni inerenti
alla gestione dello stream video e alla interazione con i client.
Interfaccia Media Capture
Questa interfaccia viene utilizzata per leggere le immagini dalla camera, sia
nel formato non compresso YUV che nel formato compresso JPEG. Si può
specicare il frame-rate secondo il quale le immagini vengono catturate e
modicare anche altri parametri dello stream, come la risoluzione e la rota-
zione. Si può inoltre ricevere una serie di immagini consecutive, una quantità
predenita chiamata burst.
Interfaccia Parameter
Lo scopo di questa interfaccia è quello di fornire allo sviluppatore un modo
semplice per memorizzare dati e impostazioni dellapplicazione. I parametri
specici del software possono essere pressati in sede di creazione, ma in
questo modo si ha anche la possibilità di farli variare a run-time. Possono
essere denite funzioni callback per specicare azioni da compiere ogni qual
volta un parametro venga aggiornato.
119
Interfaccia Http
Linterfaccia in questo caso fa in modo che lapplicazione si comporti come
una CGI (Common Gateway Interface) o come una pagina web dinamica.
Ciò è reso possibile da un re-indirizzamento URL che invece di mostrare la
pagina web indicata, manda direttamente allapplicazione. Lutente in questo
modo può vedere le informazioni grazie al browser.
120
Bibliograa
[1] http://www.axis.com.
[2] http://www.axis.com/techsup/cam_servers/dev/cam_http_api_
index.php.
[3] http://www.adaptivepath.com/publications/essays/archives/
000385.php.
[4] http://www.raymondhill.net/voronoi/rhill-voronoi.php.
[5] Moh B. Al-Daoud and Stuart A. Roberts. New methods for the
initialisation of clusters. Pattern Recogn. Lett., 17:451455, May 1996.
[6] Michael R. Anderberg. Cluster analysis for applications / Michael R.
Anderberg. Academic Press, New York, 1973.
[7] Andrew D. Bagdanov, Marco Bertini, Alberto Del Bimbo, and Lorenzo
Seidenari. Adaptive video compression for video surveillance applica-
tions. In Proc. of ISM Intl Symposium on Multimedia, Dana Point,
California, USA, December 2011. IEEE. (Oral).
[8] G. Ball and D. Hall. Isodata: A novel method of data analysis and
pattern classication. Technical report, Stanford Research Institute,
Menlo Park, 1965.
[9] Adam Baumberg. Reliable feature matching across widely separated
views, 2000.
121
BIBLIOGRAFIA
[10] P.R. Beaudet. Rotational invariant image operators. In Proceedings of
the 4th International Joint Conference on Pattern Recognition, pages
579583, 1978.
[11] I. Biederman. Recognition-by-components: A theory of human image
understanding. Psychol Review, 94(2):115147, 1987.
[12] A. Bowyer. Computing Dirichlet tessellations. The Computer Journal,
24(2):162166, January 1981.
[13] J. E. Bresenham. Algorithm for computer control of a digital plotter,
pages 16. ACM, New York, NY, USA, 1998.
[14] J Canny. A computational approach to edge detection. IEEE Trans.
Pattern Anal. Mach. Intell., 8:679698, November 1986.
[15] D L Davies and D W Bouldin. A cluster separation measure. IEEE
Transactions on Pattern Analysis and Machine Intelligence, 1(2):224
227, 1979.
[16] A. P. Dempster, N. M. Laird, and D. B. Rubin. Maximum likeli-
hood from incomplete data via the em algorithm. JOURNAL OF THE
ROYAL STATISTICAL SOCIETY, SERIES B, 39(1):138, 1977.
[17] E. Diday and J. Simon. Clustering Analysis. In K. Fu, editor, Digital
Pattern Recognition. Springer-Verlag, Berlin/Heidelberg/NY, 1976.
[18] Robert D. Dony and Ieee Simon Haykin. Neural network approaches to
image compression. In Proc. IEEE, pages 288303, 1995.
[19] J. C. Dunn. Well separated clusters and optimal fuzzy-partitions.
Journal of Cybernetics, 4:95104, 1974.
[20] E. Forgy. Cluster analysis of multivariate data: eciency versus
interpretability of classications. Biometrics, 21:768780, 1965.
[21] S Fortune. A sweepline algorithm for voronoi diagrams. In Proceedings
of the second annual symposium on Computational geometry, SCG 86,
pages 313322, New York, NY, USA, 1986. ACM.
122
BIBLIOGRAFIA
[22] E. B. Fowlkes and C. L. Mallows. A Method for Comparing Two Hie-
rarchical Clusterings. Journal of the American Statistical Association,
78(383):553569, 1983.
[23] C. Harris and M. Stephens. A Combined Corner and Edge Detection.
In Proceedings of The Fourth Alvey Vision Conference, pages 147151,
1988.
[24] Ji He, Ah hwee Tan, and Chew lim Tan. Art-c: A neural architecture for
self-organization under constraints. In In Proceedings of International
Joint Conference on Neural Networks (IJCNN, pages 25502555, 2002.
[25] Ji He, Man Lan, Chew lim Tan, Sam yuan Sung, and Hwee boon
Low. Initialization of cluster renement algorithms:. In in Proceedings
of International Joint Conference on Neural Networks (IJCNN, pages
297302, 2004.
[26] Mike Heath, Sudeep Sarkar, Thomas Sanocki, and Kevin Bowyer. Com-
parison of edge detectors: A methodology and initial study. In Initial
Study, Computer Vision and Image Understanding, pages 3854. IEEE
Computer Society Press, 1996.
[27] Paul Jaccard.

Etude comparative de la distribution orale dans une
portion des Alpes et des Jura. Bulletin del la Societe Vaudoise des
Sciences Naturelles, 37:547579, 1901.
[28] Anil K. Jain and Richard C. Dubes. Algorithms for clustering data.
Prentice-Hall, Inc., Upper Saddle River, NJ, USA, 1988.
[29] Mehmed Kantardzic. Data Mining: Concepts, Models, Methods and
Algorithms. John Wiley & Sons, Inc., New York, NY, USA, 2002.
[30] I. Katsavounidis, C. C. Jay Kuo, and Zhen Zhang. A new initializa-
tion technique for generalized Lloyd iteration. IEEE Signal Processing
Letters, 1(10):144146, October 1994.
[31] Leonard Kaufman and Peter J. Rousseeuw. Finding Groups in Data:
An Introduction to Cluster Analysis. John Wiley & Sons, 1990.
123
BIBLIOGRAFIA
[32] N. Khan, D.M. Mohamudally. A multiagent system (mas) for the gene-
ration of initial centroids for k-means clustering data mining algorithm
based on actual sample. In Journal of Next Generation Information
Technology, volume 1, page 495, 2010.
[33] Benjamin King. Step-Wise Clustering Procedures. Journal of the
American Statistical Association, 62(317):86101, 1967.
[34] Les Kitchen and Azriel Rosenfeld. Gray-level corner detection. Pattern
Recognition Letters, 1(2):95 102, 1982.
[35] Stuart P. Lloyd. Least squares quantization in pcm. IEEE Transactions
on Information Theory, 28:129137, 1982.
[36] Bruce D. Lucas and Takeo Kanade. An iterative image registration
technique with an application to stereo vision. pages 674679, 1981.
[37] J. B. MacQueen. Some methods for classication and analysis of multi-
variate observations. In L. M. Le Cam and J. Neyman, editors, Proc. of
the fth Berkeley Symposium on Mathematical Statistics and Probability,
volume 1, pages 281297. University of California Press, 1967.
[38] P. C. Mahalanobis. On the generalised distance in statistics. In Procee-
dings National Institute of Science, India, volume 2, pages 4955, April
1936.
[39] Elmar Mair, Gregory D. Hager, Darius Burschka, Michael Suppa, and
Gerhard Hirzinger. Adaptive and generic corner detection based on the
accelerated segment test. In European Conference on Computer Vision
(ECCV10), September 2010.
[40] J. Mogul, B. Krishnamurthy, F. Douglis, A. Feldmann, Y. Goland,
A. van Ho, and D. Hellerstein. Delta encoding in HTTP. RFC 3229
(Proposed Standard), January 2002.
[41] Hans Moravec. Towards automatic visual obstacle avoidance. In Procee-
dings of the 5th International Joint Conference on Articial Intelligence,
page 584, August 1977.
124
BIBLIOGRAFIA
[42] Hans P. Moravec. Visual mapping by a robot rover. In Proceedings of
the 6th international joint conference on Articial intelligence - Volume
1, pages 598600, San Francisco, CA, USA, 1979. Morgan Kaufmann
Publishers Inc.
[43] F. Murtagh. A survey of recent advances in hierarchical clustering
algorithms which use cluster centers. Computer Journal, 26:354359,
1984.
[44] N. Otsu. A threshold selection method from gray-level histograms. IEEE
Transactions on Systems, Man and Cybernetics, 9(1):6266, January
1979.
[45] N.R. Pal and J. Biswas. Cluster validation using graph theoretic
concepts. Pattern Recognition, 30(6):847 857, 1997.
[46] Dan Pelleg and Andrew W. Moore. X-means: Extending k-means wi-
th ecient estimation of the number of clusters. In Proceedings of
the Seventeenth International Conference on Machine Learning, ICML
00, pages 727734, San Francisco, CA, USA, 2000. Morgan Kaufmann
Publishers Inc.
[47] J. M. S. Prewitt. Object enhancement and extraction. Picture Processing
and Psychopictorics. Lipkin and Rosenfeld, Eds. New York, 1970.
[48] P. Resnick. Internet Message Format. RFC 5322 (Draft Standard),
October 2008.
[49] Lawrence G. Roberts. Machine Perception of Three-Dimensional So-
lids. Outstanding Dissertations in the Computer Sciences. Garland
Publishing, New York, 1963.
[50] Edward Rosten. High performance rigid body tracking. PhD thesis,
University of Cambridge, Febuary 2006.
[51] Edward Rosten and Tom Drummond. Fusing points and lines for high
performance tracking. In IEEE International Conference on Computer
Vision, volume 2, pages 15081511, October 2005.
125
BIBLIOGRAFIA
[52] Edward Rosten and Tom Drummond. Machine learning for high-
speed corner detection. In European Conference on Computer Vision,
volume 1, pages 430443, May 2006.
[53] P F Russell and T R Rao. On habitat and association of species of ano-
pheline larvae in south-eastern madras. Journal of the Malaria Institute
of India, 3(1):153178, 1940.
[54] J. Sauvola and M. Pietikainen. Adaptive document image binarization.
Pattern Recognition, 33(2):225 236, 2000.
[55] Bernt Schiele and James L. Crowley. Probabilistic object recognition
using multidimensional receptive eld histograms. pages 610619, 1996.
[56] Cordelia Schmid and Roger Mohr. Local grayvalue invariants for ima-
ge retrieval. IEEE Transactions on Pattern Analysis and Machine
Intelligence, 19:530535, 1997.
[57] Cordelia Schmid, Roger Mohr, and Christian Bauckhage. Evaluation of
interest point detectors. Int. J. Comput. Vision, 37:151172, June 2000.
[58] Subhash Sharma. Applied multivariate techniques. John Wiley & Sons,
Inc., New York, NY, USA, 1996.
[59] Akira Shiozaki. Edge extraction using entropy operator. Comput. Vision
Graph. Image Process., 36:19, November 1986.
[60] S. M. Smith and J. M. Brady. Susan - a new approach to low level image
processing. International Journal of Computer Vision, 23:4578, 1995.
[61] P.H.A. Sneath and R.R. Sokal. Numerical Taxonomy. The Principles
and Practice of Numerical Classication. Freeman, 1973.
[62] Irwin Edward Sobel. Camera models and machine perception. PhD
thesis, Stanford, CA, USA, 1970.
[63] R. R. Sokal and C. D. Michener. A statistical method for evalua-
ting systematic relationships. University of Kansas Science Bulletin,
38:14091438, 1958.
126
BIBLIOGRAFIA
[64] Simon Taylor, Edward Rosten, and Tom Drummond. Robust feature
matching in 2.3s. In IEEE CVPR Workshop on Feature Detectors and
Descriptors: The State Of The Art and Beyond, June 2009.
[65] Bo Thiesson, Christopher Meek, David Maxwell Chickering, and David
Heckerman. Learning mixtures of bayesian networks. In in Cooper &
Moral, 1997.
[66] Carlo Tomasi and Takeo Kanade. Detection and tracking of point
features. Technical report, International Journal of Computer Vision,
1991.
[67] J T Tou and R C Gonzalez. Pattern recognition principles. Image
Rochester NY, 7:377, 1974.
[68] Panos E. Trahanias and Anastasios N. Venetsanopoulos. Color edge
detection using vector order statistics. IEEE Transactions on Image
Processing, 2(2):259264, 1993.
[69] Panos E. Trahanias and Anastasios N. Venetsanopoulos. Vector or-
der statistics operators as color edge detectors. IEEE Transactions on
Systems, Man and Cybernetics, Part B (Cybernetics), 26(1):135143,
February 1996.
[70] Miroslav Trajkovic and Mark Hedley. Fast corner detection. Image and
Vision Computing, 16(2):75 87, 1998.
[71] John C. Trinder and Yandong Wang. Automatic road extraction from
aerial images. Digital Signal Processing, 8(4):215 224, 1998.
[72] Han Wang and Michael Brady. Real-time corner detection algorithm
for motion estimation. Image and Vision Computing, 13(9):695 703,
1995.
[73] Jr. Ward. Hierarchical grouping to optimize an objective function.
Journal of the American Statistical Association, 58:236244, 1963.
127
BIBLIOGRAFIA
[74] D. F. Watson. Computing the n-dimensional Delaunay tessellation with
application to Voronoi polytopes. The Computer Journal, 24(2):167
172, January 1981.
[75] Lot A. Zadeh. Fuzzy sets. Information and Control, 8(3):338353,
1965.
[76] C. T. Zahn. Graph-theoretical methods for detecting and describing
gestalt clusters. IEEE Trans. Comput., 20:6886, January 1971.
[77] Silvano Di Zenzo. A note on the gradient of a multi-image. Computer
Vision, Graphics, and Image Processing, 33(1):116125, 1986.
[78] Zhiqiang Zheng, Han Wang, and Eam Khwang Teoh. Analysis of gray
level corner detection. Pattern Recogn. Lett., 20:149162, February 1999.
128
Ringraziamenti
Desidero per prima cosa ringraziare il Prof. Alberto Del Bimbo per avermi
dato lopportunità di poter lavorare su questo progetto e quindi avere reso
possibile questa magnica esperienza.
Ringrazio vivamente anche Lorenzo Seidenari e Marco Bertini per aver-
mi guidato durante tutto lo sviluppo dellapplicazione e per tutti i preziosi
consigli che mi hanno dato, e ringrazio anche tutti gli altri ragazzi del MICC
per avermi fatto sempre sentire a mio agio.
Desidero ringraziare fortemente i miei genitori e mia sorella per avermi
sostenuto in tutti questi anni di studio. Ringrazio Elisabetta per essermi
stata sempre accanto anche nei momenti pi` u dicili e per avermi stimolato
a dare sempre il massimo.
Un doveroso ringraziamento a tutti i ragazzi con cui ho condiviso questi
anni di studio, che tra LAN party e Tressette mi hanno fatto dimenticare
il signicato della parola noia: Niccolò, Sandro, Simone, Federico, Dimo,
Marco, Claudio, Lorenzo, Andrea, Giacomo, David, Alessandro, Giovanni e
tutti gli altri.
Un particolare grazie a Tommaso, anche se ora abita a Trieste mi è sempre
rimasto vicino.
Inne ringrazio anche Bruco, Papia, Aloha, Cicce, Army e Invinciball
perche suonare insieme a loro è una delle cose pi` u belle nella mia vita.
129

Estrazione Real-Time Di Caratteristiche Immagine Di Basso Livello A Bordo Di Telecamera

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Estrazione Real-Time Di Caratteristiche Immagine Di Basso Livello A Bordo Di Telecamera

Uploaded by

Copyright:

Available Formats

UNIVERSIT

s c or e s = f a s t s c o r e ( im , s t r i de , cor ner s , num corners , b) ;

bool Fast : : f u l l s e g t e s t b r i g h t ( const ui nt 8 t p , const i nt

while ( p [ pi xe l [ pt r ] ] > m hi gher t )

i f (++pi x count >= 9)

i f (++pi x count >= 9)

i f (++pi x count >= 9)

i f (++pi x count >= 9)

bool Fast : : f u l l s e g t e s t d a r k ( const ui nt 8 t p , const i nt pi xe l

while ( p [ pi xe l [ pt r ] ] < m l ower t )

i f (++pi x count >= 9)

i f (++pi x count >= 9)

i f (++pi x count >= 9)

i f (++pi x count >= 9)

while ( t mi n != ( t max 1) && t mi n != t max )

while ( t mi n != ( t max 1) && t mi n != t max )

void Fast : : make of f s e t s ( i nt pi xe l [ ] , i nt r ow s t r i de )

i nt Fast : : f a s t s c o r e ( const ui nt 8 t i , i nt s t r i de , Pi xel

Pi xel Fast : : f a s t de t e c t ( const ui nt 8 t im , i nt xs i ze , i nt ys i ze

for ( x=3; x < xs i z e 3; x++)

r et num cor ner s = num corners ;

ret num nonmax = 0;

ret nonmax = ( Pi xel ) mal l oc ( num corners si zeof ( Pi xel ) ) ;

for ( i =0; i < s z ; i ++)

i f ( c or ne r s [ i 1] . x == pos . x1 && c or ne r s [ i 1] . y == pos . y &&

i f ( c or ne r s [ i +1] . x == pos . x+1 && c or ne r s [ i +1] . y == pos . y &&

i f ( pos . y != 0 && r ow s t ar t [ pos . y 1] != 1)

i f ( c or ne r s [ poi nt above ] . y < pos . y 1)

for ( j=poi nt above ; c or ne r s [ j ] . y < pos . y && c or ne r s [ j ] . x <=

i f ( pos . y != l as t r ow && r ow s t ar t [ pos . y + 1] != 1 &&

i f ( c or ne r s [ poi nt bel ow ] . y < pos . y + 1)

for ( j=poi nt bel ow ; j < s z && c or ne r s [ j ] . y == pos . y+1 &&

ret nonmax [ num nonmax++] = c or ne r s [ i ] ;

You might also like