Annotazioni automatiche per la videosorveglianza: l

Transcript

Università degli Studi di Modena e
Reggio Emilia
Facoltà di Ingegneria di Modena
Corso di Laurea Specialistica in Ingegneria Informatica
Annotazioni automatiche
per la videosorveglianza:
l'ambiente Visor
Relatore
Ch.ma Prof. Rita Cucchiara
Correlatore
Dott. Ing. Roberto Vezzani
Tesi di Laurea di
Alessandro Pelliciari
Anno Accademico 2006/2007
Indice
Introduzione
1
2
Lavori Correlati
11
1.1
Video Repository e Datasets . . . . . . . . . . . . . . . . . . . . . . .
11
1.2
Progetti realizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
1.2.1
VACE
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
1.2.2
PETS Metrics . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
1.2.3
ETISEO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
1.2.4
ODViS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
1.2.5
CAViAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Il framework ViSOR
33
2.1
Visione Generale
2.2
L'annotazione di video
. . . . . . . . . . . . . . . . . . . . . . . . . .
35
2.3
Ground Truth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
2.3.1
39
2.4
2.5
3
7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gli errori umani . . . . . . . . . . . . . . . . . . . . . . . . . .
Livello semantico: ViSOR
33
. . . . . . . . . . . . . . . . . . . . . . . .
41
2.4.1
Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.4.2
Denizione dell'ontologia . . . . . . . . . . . . . . . . . . . . .
43
Livello sintattico: ViPER . . . . . . . . . . . . . . . . . . . . . . . . .
47
2.5.1
Perchè utilizzare ViPER
. . . . . . . . . . . . . . . . . . . . .
47
2.5.2
Strumenti di interazione con il formato . . . . . . . . . . . . .
49
2.5.3
Schema generale del formato . . . . . . . . . . . . . . . . . . .
49
Metriche di valutazione
53
3.1
54
I livelli semantici
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
4
5
INDICE
3.2
Pixel-Based
3.3
3.4
54
Frame-Based
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
Object-Based
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
Video Content Analysis
67
4.1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
4.1.1
Descrizione del sistema . . . . . . . . . . . . . . . . . . . . . .
68
4.1.2
Principali caratteristiche . . . . . . . . . . . . . . . . . . . . .
70
Il sistema Sakbot
Architettura sviluppata
73
5.1
Gestione degli Eventi . . . . . . . . . . . . . . . . . . . . . . . . . . .
73
5.2
Da Sakbot a Visor
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
5.2.1
Punto di vista temporale: Sakbot . . . . . . . . . . . . . . . .
75
5.2.2
Punto di vista ad oggetti: Visor . . . . . . . . . . . . . . . . .
76
5.2.3
Approcci possibili . . . . . . . . . . . . . . . . . . . . . . . . .
77
5.3
Descrizione della struttura creata
5.4
Caratteristiche dell'architettura
5.5
5.6
5.7
6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . .
78
. . . . . . . . . . . . . . . . . . . . .
81
Esempi di applicazione . . . . . . . . . . . . . . . . . . . . . . . . . .
82
5.5.1
Baricentro e bounding box . . . . . . . . . . . . . . . . . . . .
82
5.5.2
Un buon compromesso: l'ellisse
. . . . . . . . . . . . . . . . .
84
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
5.6.1
Dettagli implementativi di Sakbot . . . . . . . . . . . . . . . .
85
5.6.2
Modulo realizzato . . . . . . . . . . . . . . . . . . . . . . . . .
86
5.6.3
Interfaccia graca . . . . . . . . . . . . . . . . . . . . . . . . .
87
5.6.4
Classi astratte: ereditarietà e polimorsmo . . . . . . . . . . .
89
5.6.5
Utilità del polimorsmo all'interno dell'architettura . . . . . .
91
5.6.6
Libreria TinyXML
. . . . . . . . . . . . . . . . . . . . . . . .
92
5.6.7
Acquisizione e riorganizzazione logistica dei dati . . . . . . . .
94
5.6.8
Esportazione dei dati . . . . . . . . . . . . . . . . . . . . . . .
97
Implementazione
Risultati sperimentali . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Un esempio di valutazione con ViPER-PE
103
6.1
ViPER-PE: descrizione ed obiettivi
6.2
Object Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.2.1
. . . . . . . . . . . . . . . . . . . 104
Detection (level = 1) . . . . . . . . . . . . . . . . . . . . . . . 106
INDICE
6.3
5
6.2.2
Localization (level = 2) . . . . . . . . . . . . . . . . . . . . . . 106
6.2.3
Statistical Comparison (level = 3) . . . . . . . . . . . . . . . . 106
6.2.4
Target Matching
. . . . . . . . . . . . . . . . . . . . . . . . . 106
Framewise Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3.1
Metriche di valutazione . . . . . . . . . . . . . . . . . . . . . . 107
6.4
Il le Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.5
Il le Evaluation Parameters . . . . . . . . . . . . . . . . . . . . . . 109
6.6
File di output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
6.7
Test realizzati . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Conclusioni
119
Elenco delle gure
121
A Calcolo dell'ellisse
123
Bibliograa
127
Introduzione
La videosorveglianza è ormai entrata a far parte del viver comune e di molte applicazioni del settore industriale.
La possibilità di osservare e capire cosa accade
all'interno della scena rivoluziona l'idea di controllo e di prevenzione in numerosi
campi, da quello della sicurezza in luoghi pubblici (aeroporti, uci, banche..)
a
quello del monitoraggio della viabilità su autostrade e incroci ed a molti altri. Dal
lato prettamente tecnico, il tema della videosorveglianza include una serie di attività
che riguardano la visione articiale, che vanno dalla basilare elaborazione dell'immagine (applicazioni di ltri, segmentazione, labelling, edge detection,. . . ) a tecniche
più avanzate (come object detection, segmentazione del moto, pattern recognition,
feature extraction . . . ).
Uno degli obiettivi nali è il tracking di oggetti, fase alla quale segue l'analisi
(identicazione, riconoscimento, rilevamento della postura) ed inne l'utilizzo delle
informazioni estratte in base al contesto e alle modalità previste (come inferenze
sul comportamento, classicazione, controllo). L'attività di tracking in particolare
consiste nell'inseguimento di un oggetto d'interesse all'interno di una sequenza di
frame attraverso l'object detection (l'individuazione degli oggetti).
Perciò, nel dominio della videosorveglianza, l'object detection e il tracking sono
di centrale importanza per ogni moderno sistema di elaborazione video e di analisi
comportamentale; da più di un decennio a questa parte, molti algoritmi sono stati
proposti al ne di risolvere il problema della scene understanding. Il livello di comprensione varia largamente dalla sola individuazione degli oggetti in movimento al
monitoraggio tramite camere multiple, no alla comprensione degli eventi che accadono all'interno della scena. Più in dettaglio, esempi di applicazioni aascinanti
da realizzare potrebbero essere il monitoraggio di metropolitane, il riconoscimento
di ingorghi sulle strade, l'identicazione di oggetti lasciati per terra e di persone in
atteggiamenti sospetti.
7
8
Introduzione
I sistemi di videosorveglianza automatici costituiscono una rete di sensori video
che osservano gli oggetti (e le persone) in movimento in un dato ambiente alla
ricerca di pattern che rappresentano attività normali/anormali, eventi di interesse,
e altri obiettivi specici. Un ruolo vitale immaginato per questi sistemi è il loro uso
come strumento attivo per la prevenzione del crimine, il rinforzamento delle leggi
e il controllo delle true e degli scambi illegali, come quelli per la droga; ciò è in
netto contrasto con la maggior parte dei sistemi esistenti nel mondo reale, utilizzati
principalmente come strumento forense per investigazioni dopo il fatto.
La videosorveglianza automatizzata è attraente perché promette di rimpiazzare
la costosa opzione umana nel monitoraggio delle telecamere, ma questa promessa
può facilmente trasformarsi in un'arma a doppio taglio se il rendimento del sistema
non è al livello desiderato. In generale, questo livello di prestazioni tende ad essere
molto elevato, se corrisposto alla preparazione di un operatore umano che dispone
di tutta la conoscenza naturale di cui il calcolatore è privo.
Inoltre, il problema di ottenere un tracking e un'object detection nel complesso
robusti diventa ancora più dicile da arontare se si considera il requisito che i sistemi di videosorveglianza devono operare per tutti i periodi del giorno e in condizioni
climatiche che si modicano continuamente. Questa situazione di alta aspettativa
nei confronti del sistema e il requisito stringente appena visto permettono un margine di errore minimo sulle prestazioni di questi sistemi. E' quindi naturale chiedersi se
ci sono progressi quanticabili nella forma di un sistema di videosorveglianza robusto e di grado commerciale come risultato delle ricerche passate e presenti in questa
direzione: la
valutazione delle prestazioni di un sistema di videosorveglianza sta
assumendo perciò sempre più importanza.
A parte i test funzionali, ci sono molte altre ragioni per valutare le prestazioni
dei sistemi e degli algoritmi che riguardano la videosorveglianza: interesse scientico, misurazione del miglioramento durante lo sviluppo, benchmarking con la concorrenza, propositi commerciali e inne requisiti legali/regolatori. Tuttavia, molta
letteratura che descrive questi algoritmi non riesce a dare una misura obiettiva della
qualità dei risultati. Per esempio, per gli algoritmi di compressione video il criterio
è di minimizzare la dierenza assoluta tra i risultati decodicati e gli originali con il
PSNR come metrica standard. Purtroppo per gli algoritmi sulla videosorveglianza
non esiste un criterio standard. Qualche metrica di valutazione è già stata proposta in letteratura, ma al più copre solo una parte limitata del completo insieme di
Introduzione
9
metodi e algoritmi.
Sfortunatamente la valutazione delle prestazioni è di per sé molto dicoltosa, e
inoltre spesso richiede la creazione di strumenti specici e la generazione del ground
truth.
Il ground truth è quell'insieme di annotazioni e misurazioni che vengono
considerate come reali che servono per validare o vericare altre misurazioni o annotazioni, spesso derivanti da analisi automatiche.
Quasi sempre esso è generato
manualmente, richiedendo tempi rilevanti, e in più può utilizzare dati e metriche
speciche solo per un certo algoritmo, diventando quindi statisticamente non corretto. Spesso inoltre contiene risultati troppo specici per permetterne un confronto
con altri algoritmi.
Anche possedendo le metriche, la stessa base su cui si compie l'elaborazione
rappresenta un problema da arontare.
All'interno dei video le situazioni sono
molteplici, con dierenti gradi di dicoltà.
La soluzione di avere un set di video
comune è stata puntualizzata ma è carente dal punto di vista pratico.
ViSOR
1
è un repository online di video realizzato dal laboratorio ImageLab del-
l'Università di Modena e Reggio Emilia che mira a colmare queste lacune, cercando
di essere un portale per collezionare video e valutazioni di algoritmi, in cui la
comunità possa confrontare i propri risultati tramite un formato di annotazione
aperto, comune ed espandibile dalla stessa. ViSOR fa parte del progetto europeo
VIDIVIDEO, il cui obiettivo è la ricerca semantica sui video.
Inoltre, lo stesso
laboratorio ha sviluppato un sistema di videosorveglianza, denominato Sakbot, per
l'analisi del traco e della comprensione degli eventi all'interno di una scena tramite
le operazioni dettagliate sopra.
Nell'ambito che concerne ViSOR, in questo progetto verrà sviluppata un'architettura per permettere la generazione di annotazioni automatiche dalle informazioni
che Sakbot elabora nei video processati, attraverso l'acquisizione, la riorganizzazione e l'esportazione di questi dati.
Lo scopo è duplice:
da una parte, fornire
annotazioni automatiche a basso livello (come una semplice segmentazione) per permettere un'astrazione maggiore sulla valutazione (ad esempio sulla classicazione);
dall'altra, creare un architettura in grado di permettere la valutazione obiettiva di
algoritmi presenti e futuri del sistema Sakbot, fornendo le annotazioni nel formato
comune di ViSOR e acconsentendo così la sua importazione nel framework online.
1 http://imagelab.ing.unimore.it/visor/
Capitolo 1
Lavori Correlati
Intorno alla performance evaluation dei sistemi di tracking ed object detection sono
stati realizzati diversi progetti con l'obiettivo di denire ed utilizzare un approccio
comune ed eciente.
1.1
Video Repository e Datasets
La prima condizione fondamentale e imprescindibile per la valutazione di algoritmi
appartenenti all'ambito della videosorveglianza è la base di dati su cui si lavora.
Malgrado sia inevitabile che i ricercatori tendano a stimare le performance dei
propri algoritmi su set di dati generati localmente, il vantaggio di compiere dei test
su sequenze video appropriate e largamente disponibili ore un'importante opportunità per il benchmarking ; per abilitare un benchmarking appropriato con altri
algoritmi, l'idea è di valutare gli stessi con un set di video standard.
Le condizioni naturali che minano la robustezza e l'attendibilità degli algoritmi di
tracking e detection sono varie:
1. le condizioni del tempo - vento, pioggia e neve hanno un eetto drammatico
sull'aspetto della scena sotto osservazione;
2. le variazioni di luminosità che occorrono come conseguenza della rotazione del
sole - la luce del sole diretta contro condizioni di cielo coperto; le luci articiali
11
12
Lavori Correlati
e notturne (come ad esempio le luci ai lati delle strade, oppure i fanali delle
auto);
3. i moti irrilevanti che possono essere generati da un'ampia varietà di sorgenti
dierenti: dipendenti dal vento (piante, bandiere), ombre (di persone e nuvole), superci riesse (pozzanghere sulla strada, nestre) e superci trasparenti
(nestre).
Molte di queste condizioni hanno un impatto diverso l'una dall'altra - ad esempio, la neve che cade può essere individuata dall'algoritmo di analisi del moto; i
livelli medi di luminosità della scena possono crescere signicativamente perché la
neve ha un alto coeciente di riessione; il movimento di oggetti attraverso la
neve può lasciare tracce visibili che con il conseguente disgelo potrebbero generare
pozzanghere sul terreno, anch'esse con un alto coeciente di riessione.
Si possono facilmente identicare le condizioni ideali di un'immagine per il
detection e il tracking, che sono spesso usate dai ricercatori per dimostrare l'ecacia
dei loro algoritmi - una tranquilla e asciutta giornata, ben illuminata ma a cielo
coperto - che evita molte delle problematiche associate alle condizioni descritte sopra.
In più, per provvedere ad una valutazione più adabile, i video selezionati devono invocare il sistema VCA
1
nella maniera giusta. Questi video devono essere
rappresentativi e contenere sia lo scenario tipico che lo scenario nel caso peggiore.
A parte i contenuti del video, anche le caratteristiche dell'immagine, la risoluzione
e il frame rate hanno impatto sulle performance del VCA.
Per queste ragioni, molti test set di dati video sono disponibili pubblicamente
attraverso Internet. Una visione d'insieme di questi set è data nella tabella 1.1, dove
è presente ed evidenziato ViSOR. Esistono anche sequenze non pubbliche (come la
MPEG-4 Hallway sequence ), ma a causa del loro ristretto accesso ed utilizzo, sono
meno utili per scopi di valutazione.
Per valutare la piena varianza dei dati in input, è necessario avere molte sequenze
di test. Considerare una completa rappresentazione in ingresso richiederebbe una
performance evaluation esosa in termini di tempo e con ampi requisiti di storage
1 sistema VCA: sistema di
video content analysis, si veda il cap. 4
1.1 Video Repository e Datasets
13
Figura 1.1: Datasets Video disponibili pubblicamente
per i dati video. L'ammontare di dati necessari per la valutazione è dipendente dal
livello desiderato di importanza statistica del test.
Un'ulteriore proprietà dei set di dati risiede nella complessità e nella varietà
delle sde percettive presenti nella sequenza. Per esempio, una sequenza video su
una strada comprenderà più oggetti che si muovono ad un'alta velocità, mentre una
sequenza di parcheggi contiene solo un piccolo numero di oggetti che si muovono ad
una velocità limitata.
14
Lavori Correlati
La complessità del dataset può quindi essere caratterizzata da vari tipi di meccanismo: il livello delle interazioni dei soggetti, la frequenza e la complessità delle
occlusioni dinamiche, il periodo di tempo in cui i soggetti rimangono dietro a occlusioni statiche e la distinguibilità degli stessi, per citarne alcuni. Solo assicurandosi
che il dataset contenga un raggio di sde percettive sucientemente ricco e diversicato è possibile testare adeguatamente un algoritmo di tracking.
Per esempio, una sequenza video acquisita sotto condizioni ideali di immagine che
contiene solo un oggetto chiaramente distinto ad un istante particolare non è da
considerarsi un risultato convincente per quanto riguarda un reale sistema di sorveglianza. Quel dataset sarà appropriato per la calibrazione e il training del sistema,
ma non lo è per una valutazione delle performance oggettiva.
E' quindi assolutamente necessaria una distinzione fra l'ammontare di dati usato
per lo sviluppo e quello usato per la valutazione, visto che la valutazione sul set di
dati dello sviluppo darebbe ovviamente risultati non attendibili. Inoltre, per orire
una valutazione adabile e un breve ciclo di sviluppo dell'algoritmo, il set di dati
per la valutazione è tipicamente molto più grande del training set.
A anco dei video che si basano su scene di vita reale, anche video sintetici
possono essere utilizzati per valutare algoritmi di visione articiale [1]. Tipicamente, la quantità di realismo di queste sequenze è limitata: tuttavia, il processo di
annotazione GT è estremamente semplicato.
1.2
Progetti realizzati
L'incredibile importanza acquistata dalla performance evaluation degli algoritmi di
tracking, object detection ed event analysis ha portato i ricercatori ad incontrarsi
per discutere di eventuali soluzioni ed a dedicare conferenze ad essa. In congiunzione con l'IEEE Face and Gesture Recognition Conference, a Grenoble il 31 Marzo
2000 si è tenuto il primo workshop sulla valutazione delle performance, denominato
Performance Evaluation of Tracking and Surveillance (PETS).
Questa conferenza è stata realizzata proprio perché la crescita nello sviluppo del
1.2 Progetti realizzati
15
campo della videosorveglianza non ha avuto come complementare la sistematica valutazione delle prestazioni delle tecniche implementate. Specialmente, era dicile
fare confronti tra algoritmi pubblicati in letteratura se erano stati testati su dierenti datasets sotto condizioni completamente diverse.
Lo scopo di PETS era di
permettere ai ricercatori di testare i propri algoritmi e presentare i propri risultati
2
sullo stesso dataset appositamente reso disponibile. Dal 2000, altri 7 PETS
3
PETS)
(e VS-
workshop si sono tenuti in collaborazione con le conferenze più famose, con
periodicità annuale.
Recentemente, c'è stato un aumento di attività addizionali che mirano ad orire
ulteriore supporto e integrazione per la valutazione delle perfomance nel contesto
della videosorveglianza: da progetti che mirano ad assistere il ricercatore nella ricerca del ground truth, a framework che intendono integrare gli algoritmi da testare
al loro interno, fornendo supporti di calcolo e visualizzazione degli errori e dei risultati, a progetti più ampi che prevedono la denizione di metriche o di approcci più
complicati.
Nella fattispecie, le alternative alle conferenze PETS sono rappresentate dai progetti VACE e ETISEO, mentre per quanto riguarda i framework descritti appena
sopra vi sono i progetti CAVIAR e ODVIS.
Nonostante i numerosi progetti, come si vedrà, sono ancora molti i problemi che
ruotano intorno ad un sistema di valutazione delle prestazioni sulla videosorveglianza.
1.2.1 VACE
Il programma Video Analysis and Content Extraction (VACE), supportato dall'
Advanced Research and Development Activity (ARDA), nasce nel 2000 ed ha come
obiettivo lo sviluppo di nuovi algoritmi ed implementazioni per l'estrazione automatica dei contenuti video e la comprensione degli eventi.
2 http://www.cvg.rdg.ac.uk/slides/pets.html
3 http://www.pets2007.net/
16
Lavori Correlati
Il programma presenta diverse fasi; attualmente si è vicini alla conclusione della
seconda. Nella prima sono stati decisi e formalizzati i passaggi necessari per l'interazione tra i vari partecipanti ed è stato denito il framework comune su cui lavorare.
VACE nasce con tre obiettivi principali:
•
creare un'infrastruttura completamente integrata basata su Informedia (progetto precedente), ovvero un propotipo di ambiente per l'estrazione di metadati, l'indicizzazione e le ricerche
•
fornire un testbed unicato e facilmente consultabile ed aggiornabile
•
sviluppare visualizzazioni di informazioni video e sommarizzazioni su grandi
collezioni di dati video
Questi obiettivi sono tra loro abbastanza ortogonali, coinvolgendo non solo la valutazione delle prestazioni nella visione articiale, ma anche processi di information
retrieval e rappresentazione della conoscenza.
Figura 1.2: Estrazione dei metadati in VACE I
L'architettura realizzata è stata modularizzata per supportare l'intercambiabilità, dove i moduli che elaborano il video per il riconoscimento di oggetti, testo o face
possono essere sostituiti con componenti sviluppati da altre organizzazioni di ricerca. Inoltre, basandosi sulla denizione di interfaccia standard inclusa nel progetto,
è possibile inserire e creare moduli con livelli semantici più elevati.
17
Figura 1.3: Visione concettuale dell'architettura di elaborazione
I metadati estratti dai nuovi moduli saranno immediatamente reperibili per eventuali ricerche all'interno del sistema e saranno inoltre allineati temporalmente con
i video processati, permettendo cosi il loro utilizzo con altri metadati sincronizzati
per la costruzione di interfacce alle collezioni video ecienti ed ecaci.
Dal punto di vista della valutazione delle prestazioni, VACE utilizza ViPER (si
veda al cap.
2.5) per le annotazioni sul ground truth, concentrandosi prevalente-
mente su bounding box e punti che identicano univocamente gli oggetti. In questo
contesto infatti, VACE II ha considerato come task primario l'object detection e il
tracking.
Le metriche utilizzate sono state concepite come operazioni sulle aree per le
annotazioni sui contorni degli oggetti e calcoli sulle distanze per le annotazioni dei
punti. Per la fase di detection, le metriche ad area riguardano l'overlap spaziale tra
ground truth e i risultati dell'algoritmo. La metrica è denita come Sequence Frame
Detection Accuracy (SFDA) e cattura sia l'accuracy (miss e falsi allarmi) che la
precision (allineamento spaziale).
18
Lavori Correlati
Per la fase di tracking, invece, sulle aree si utilizza un punteggio unico per rappresentare l'accuratezza (intesa come il numero corretto di tracce) e la precisione
(intesa come corrispondenza spaziale e temporale); questo punteggio è denito come
Average Tracking Accuracy (ATA). Entrambi questi parametri hanno un corrispettivo analogo basato sulle distanze.
Per questa fase, inoltre, vengono utilizzati 4 criteri:
1. Percentuale del dataset tracciato - è la frazione fra il numero di frame in cui
l'algoritmo ha tracciato l'oggetto rispetto ai frame totali in cui è presente.
2. Overlap medio tra i bounding box - è la percentuale di sovrapposizione dei
bounding box di ground truth e output del sistema divisa per la percentuale
del dataset tracciato
3. Overlap medio tra le bitmap - è il confronto tra l'immagine dell'output del
sistema e quella del ground truth
4. Distance Transform tra le due bitmap, sia partendo da quella del ground truth
che partendo da quella dell'output del sistema
VACE, nonostante l'attenta pianicazione delle fasi di valutazione, non è riuscito
a proporsi come strumento eciente per valutazioni general-purpose.
1.2.2 PETS Metrics
Le metriche PETS sono state sviluppate per essere sia un meccanismo di ausilio che
complementare ai tradizionali workshop PETS, creando un portale apposito.
Obiettivi
L'obiettivo generale è quello di orire un meccanismo automatico per comparare
in maniera quantitativa un selezione di algoritmi che lavorano sugli stessi datasets.
L'approccio è dierente tra attività correlate come ETISEO (si veda in 1.2.3) in cui
un coordinatore super-partes compie le valutazioni sui risultati presentati. La principale motivazione che ha spinto i ricercatori a sviluppare questo progetto è che al
secondo PETS, nel 2001, fu richiesto ai partecipanti di spedire i risultati dei propri
19
Figura 1.4: Portale PETS Metrics
algoritmi (sul dataset comune) in formato XML, ma nonostante questo non fu facile confrontarli e capire come potessero essere integrati per ottenere risultati migliori.
Quindi, le PETS Online Metrics mirano a:
1. Orire un repository online di datasets, metriche e risultati, in continua crescita
2. Permettere la valutazione automatica dei risultati inviati
3. Fornire risultati quantitativi che possono essere visionati all'interno di classiche organizzate per metrica.
Siccome i ricercatori sviluppano i propri algoritmi su piattaforme dierenti con una
varietà di linguaggi diversi e tipicamente con proprie strutture dati per salvare i
risultati, PETS Metrics ha deciso per un formato standard non proprietario e indipendente da piattaforme e linguaggi di programmazione, come l'XML. In più,
quest'ultimo può essere generato facilmente in vari linguaggi. Perciò, i risultati che
devono essere inviati sul sito di PETS Metrics devono osservare il suo XML Sche-
20
Lavori Correlati
ma, ovvero una denizione delle direttive su come costruire l'XML da sottoporre al
progetto. L'XML Schema di PETS Metrics è visibile in gura 1.5.
Figura 1.5: PETS Metrics XML Schema
Volendo fungere da repository online per risultati, metriche e datasets è necessario che il processo di creazione del ground truth sia pianicato in modo ottimale.
Tra i vari tool esistenti per la creazione delle annotazioni del ground truth, PETS
4
Metrics ha scelto il progetto AVITRACK , che è in grado di fornire annotazioni
assistite da una predizione lineare del moto degli oggetti.
Il ground truth viene eettuato in 4 passi:
1. Si assegna un unico ID e una classicazione (come persona, macchina, etc) ad
ogni oggetto sico in movimento, per ogni frame.
2. Ogni oggetto sico in ogni frame viene incapsulato in un bounding box appositamente più largo del dovuto. La predizione automatica del moto aiuta ad
aggiungere rapidamente i bounding box ai frame successivi e/o precedenti.
4 http://www.avitrack.net/
21
3. Ogni oggetto viene segmentato all'interno del proprio bounding box identicato i pixel di contorno degli oggetti e utilizzando l'algoritmo ood ll per
ottenere i pixel interni.
4. A questo punto, tramite la fase precedente è possibile estrarre automaticamente il vero bounding box.
Per la segmentazione del moto PETS Metrics ha implementato quattro metriche:
per ognuna di queste, più è basso il punteggio più l'algoritmo è eciente e vicino al
grund truth. Tutte le metriche sono la somma di due parti: un false positive score,
che è l'errore sull'identicazione dei contorni dell'oggetto, e un false negative score,
che invece è l'errore sull'identicazione del foreground interno all'oggetto.
La prima metrica, Negative Rate Metric (NR), da un'indicazione generale della
segmentazione dell'oggetto.
1
N R = (N Rf n + N Rf p )
2
dove
N Rf n
e
N Rf p
indicano rispettivamente la false negative rate e la false
positive rate (si veda a pag. 54) sui pixel.
La seconda metrica, Misclassication Penalty Metric(MP), descrive quanto bene
un algoritmo può estrarre uno specico oggetto penalizzando i pixel misclassicati
di una quantità pari alla loro distanza dal bordo dell'oggetto del ground truth.
1
M P = (M Pf n + M Pf p )
2
PNf n i
PNf p i
j=1 df n
j=1 df p
j
j
dove M Pf n =
e M Pf p =
. df n e df p sono le distanze del j −
D
D
esimo pixel falso negativo e del k − esimo pixel falso positivo dal contorno della
segmentazione di riferimento. Il fattore di normalizzazione D è la somma di tutte
le distanze dei pixel dal contorno dell'oggetto in un frame.
La terza metrica, Rate of Misclassications Metric (RM), valuta il grado medio
di errore quando avvengono più errori della media di errori che di norma accade.
1
RM = (RMf n + RMf p )
2
22
Lavori Correlati
dove
RMf n
Nf n
j
1 X df n
=
Nf n j=1 Ddiag
e
RMf p
Nf p
1 X dkf p
=
; Ddiag
Nf p k=1 Ddiag
è la diagonale distan-
za del frame.
La quarta metrica, Weighted Quality Measure Metric (WQM), quantica la
discrepanza spaziale tra la segmentazione del moto stimato e la segmentazione
dell'oggetto di riferimento appartentente al ground truth.
1
W QM = ln ( (W QMf n + W QMf p ))
2
dove
W QMf n
Nf n
1 X
=
wf n dif n
Nf n j=1
e
W QMf p
Nf p
1 X
=
wf p dkf p ; wf n
Nf p k=1
e
wf p
sono pesi
scelti arbitrariamente.
Concludendo, una volta che i dati sono stati inviati nel formato XML seguendo
l'apposito Schema, vengono calcolate automaticamente le metriche appena citate e
l'algoritmo viene inserito nella classica della rispettiva categoria, mostrando così
direttamente il confronto con gli altri algoritmi. In tal modo, idealmente, sarà possibile comprendere oggettivamente qual'è l'algoritmo o l'insieme di algoritmi migliore
per quella determinata esigenza.
Considerazioni
PETS, tramite i workshop e le metriche online, rappresenta forse il tentativo più
eciente di framework sulla valutazione delle prestazioni: il suo principale punto a
sfavore è rappresentato dalle limitazioni imposte dallo standard.
1.2.3 ETISEO
A dierenza di PETS che lavora dal punto di vista degli algoritmi, il progetto ETISEO [2], nanziato dal Ministero francese, studia le dipendenze tra le qualità dei
video e gli algoritmi. Esso mira ad identicare le adeguate caratteristiche di una scena per un dato algoritmo e ad evidenziare le debolezze di questi ultimi per ulteriori
miglioramenti.
Gli altri progetti orono sequenze video a vari livelli di dicoltà globali con il
ground truth associato. Tuttavia, gli stessi livelli globali possono essere costituiti
23
da diversi problemi di video processing (ad esempio ombre, poco contrasto, etc).
Conseguentemente, il processo di valutazione non riesce ad andare in profondità
su ogni algoritmo:
in modo specico, per un dato algoritmo, la valutazione non
indica a quali problemi di elaborazione del video bisogna fare attenzione, la cui
correzione/miglioramento è spesso cruciale; non indica neppure in quali condizioni
questo algoritmo può acquisire prestazioni soddisfacenti.
Quindi, ETISEO cerca di valutare gli algoritmi di elaborazione video dato un
certo obiettivo di visione (individuazione degli oggetti, classicazione, riconoscimento degli eventi), un tipo di scena (ad esempio la strada) e un livello di dicoltà ben
denito (ad esempio ombre contrastanti). Lo scopo ultimo è di studiare le dipendenze tra un video processing task e le caratteristiche video, deniti in questo contesto
come problemi di elaborazione video.Per fare questo, il progetto utilizza una precisa
e pianicata metodologia che consiste in questi passaggi:
•
Per prima cosa, ETISEO indirizza in modo separato ogni problema che viene
accuratamente denito e classicato.
Ad esempio, le ombre possono essere
studiate come ombre a dierenti livelli di intensità, alla stessa intensità ma
con diversi tipi di immagini di background, oppure ombre con dierenti fonti
di illuminazione.
•
Secondariamente, ETISEO colleziona le sequenze video che illustrano solo quel
dato problema, con diversi livelli di dicoltà e di complessità.
•
A questo punto, ETISEO calcola 3 tipi di dati associati per ogni video sequenza. Il primo è il ground truth, realizzato da operatori umani tramite il tool
5
ViPER (si veda al cap. 2.5) ad ognuno dei livelli di elaborazione video . Il
secondo è l'annotazione generale delle sequenze video che riguardano le dicoltà dell'elaborazione e le condizioni di registrazione. Il terzo dato concerne
la calibrazione della videocamera e le informazioni contestuali circa la zona di
interesse.
•
Inoltre, ETISEO ha denito varie metriche per valutare le prestazioni di un
sistema di videosorveglianza ad ogni livello.
5 Analizzati in modo appropriato al cap. 5.5.2
24
Lavori Correlati
•
Inne, ETISEO ore uno strumento di valutazione automatico e essibile per
analizzare accuratamente come un dato algoritmo si occupa di un determinato
problema.
Tutte le metriche che il progetto utilizza si basano su funzioni di matching : per
la maggior parte di queste, infatti, è necessario far corrispondere l'area o intervalli
di tempo degli oggetti nei dati di riferimento (ovvero di ground truth) con gli oggetti
individuati dall'algoritmo. Se il valore della misura di matching è più alto di una
soglia predenita, si considera valida la corrispondenza.
ETISEO utilizza per lo più la funzione Dice Coecient
2 · card(RD
T
C)/(card(RD) + card(C)),
dove
RD
D1.
Essa è denita come
è l'intervallo di tempo o l'area
del Reference Data, ovvero dei dati di riferimento (ground truth), e
C
è l'analogo del
Candidate Data, cioè i dati dell'output dell'algoritmo. Come indice di prestazione,
vengono utilizzati la Precision
(GD/OD),
la Sensitivity
(GD/RD)
o l'F-Score :
2 · P recision · Sensitivity
P recision · Sensitivity
dove
GD
è il numero di good detections (in altre parole i True Positive),
il numero totale di detections (TP+FP), e
RD
OD
è
è il numero di dati di riferimento
(TP+FN).
Per l'object detection, si utilizzano 4 metriche, di cui una principale e 3 complementari:
•
number of objects metric: valuta il numero di oggetti individuati di cui si
ha un matching (basato sui bounding box) nei dati di riferimento; purtroppo
questa metrica non può misurare la precisione del rilevamento. Infatti, anche se
è la metrica principale, essa non può distinguere tra un algoritmo che individua
il 130% dell'area dell'oggetto rispetto ad un altro che ne individua esattamente
il 100%;
•
object area metric: valuta il numero di pixel nei dati di riferimento che sono
stati individuati;
•
split metric: qualica la frammentazione degli oggetti individuati; in modo
particolare, essa elabora il numero di blob (oggetti individuati) per un oggetto
25
ground truth, utilizzando un'altra funzione di matching, denita come
card(RD
T
C)/card(C).
D2 =
E' quindi molto utile per individuare casi di over-
detection (ad esempio, quando una persona è rilevata come due oggetti);
•
merge metric: qualica la sovrapposizione di oggetti individuali. Nonostante nella maggioranza delle situazioni queste due metriche sono sempre risultate vicine al 100%, con un datasets appropriato si potrebbero risaltare e
successivamente correggere gli errori di split and merge.
Per supportare le metriche precedenti, inoltre, si utilizza la 2D/3D distance
metric, che misura la distanza media tra i baricentri degli oggetti individuati e i
corrispondenti del ground truth. Analogamente alla metrica sull'area degli oggetti,
essa serve per calcolare la precisione del rilevamento.
Va aggiunto che i risultati di valutazione di queste metriche possono inuenzare
negativamente alcuni algoritmi che riescono, a dierenza di altri, ad individuare oggetti dicili da catturare (come gli oggetti lontani dalla videocamera). E' perciò
necessario tenere in conto i risultati del numero di oggetti rilevati: se un algoritmo
ottiene buoni risultati sulle distanze ma pessimi sul numero di oggetti, signica che
quest'ultimo riesce a gestire bene oggetti facili da individuare, a discapito di quelli dicili. Se invece i risultati sono invertiti, è chiaro che l'algoritmo ha diminuito
la propria accuratezza di rilevamento per avere un frequenza di detection molto alta.
Per la fase di tracking, si impiegano 3 metriche, una principale e 2 complementari:
•
tracking time metric: misura la percentuale di tempo nel quale un oggetto di
riferimento è individuato e tracciato (la corrispondenza si valuta sui bounding
box). Il suo grande difetto è che dipende completamente dalla fase di detection ;
•
object ID persistence metric: aiuta a valuta la persistenza dell'ID, ma favorisce l'under-detection ;
•
object ID confusion metric: computa il numero di ID di oggetti di riferimento
per ogni oggetto individuato; lo scambio di ID può avvenire ad esempio quando
due persone si incontrano. Essa favorisce l'over-detection.
Queste ultime due metriche devono necessariamente essere utilizzate insieme alla
metrica principale per evitare di trarre conclusioni fuorvianti.
26
Lavori Correlati
Per i livelli più alti, come la classicazione di oggetti e il riconoscimento di eventi,
si utilizzano ancora una volta le corrispondenze sui bounding box o su condizioni
temporali.
ETISEO riesce quindi a fornire un largo set di dati e di metriche per valutare gli algoritmi di video processing, che si combinano ad un eettiva realizzazione
pratica avvenuta in due fasi principali, durante le quali i partecipanti hanno potuto
prima prendere familiarità con i requisiti richiesti e successivamente eettuare le
valutazioni. Nonostante questo, vi sono state comunque diverse incomprensioni tra
i partecipanti, in modo particolare nel denire gli oggetti e gli eventi di interesse.
Inoltre, non è stata posta attenzione sui requisiti hard-time, ovvero in tempo reale;
la denizione dei livelli di dicoltà all'interno dei cosiddetti problemi è ancora
acerba e poco precisa (vengono utilizzati ad esempio termini come normale o scuro), e la selezione di sequenze video nel progetto non è suciente perché il confronto
tra queste sequenze è soggettiva e approssimativa. In futuro, è prevista la progettazione e l'implementazione di una metrica oggettiva e quantitativa per misurare
automaticamente i livelli di dicoltà dei problemi di elaborazione video.
1.2.4 ODViS
Il progetto ODViS [3] (Open Development for Video Surveillance ) nasce dal bisogno
di ottenere un'analisi empirica diretta sui sistemi di tracking e videosurveillance
senza attribuire un carico non dovuto al designer dell'algoritmo.
ODViS è un framework totalmente indipendente per la ricerca e lo sviluppo dei
sistemi di videosorveglianza; sebbene esistano già vari applicativi che si occupano
della generazione del ground truth, della gestione delle metriche, della visualizzazione e della caratterizzazione degli errori, questi non sono stati esplicitamente creati
in modo general-purpose per supportare la comunità dei ricercatori di quest'area
tematica.
Sono stati creati secondo le necessità del momento, in modo comple-
tamente separato, senza considerare apertamente il problema dell'interoperabilità
tra i suddetti.
Addirittura, con l'obiettivo di capire e visualizzare le performan-
ce relative ai propri sistemi, molti ricercatori hanno ri-sviluppato le funzionalità di
visualizzazione, misura dell'errore e processing video, in modo superuo.
Il sistema ODViS è estensibile, in quanto permette ai ricercatori di inserire
27
al proprio interno modelli di video sorveglianza, avendo la possibilità cosi di valutare i propri algoritmi di tracking ed event detection in un ambiente provvisto
di un'interfaccia graca interattiva.
Utilizzando questo sistema, i ricercatori pos-
sono facilmente denire dati ground truth, visualizzare il comportamento dei loro
algoritmi, ed automaticamente misurare e riportare errori in tramite dierenti formati. Si può cosi evitare tutto l'overhead comunemente associato con una profonda
valutazione delle performance.
Figura 1.6: Esempio del sistema ODViS in uso
Nella gura 1.6 vi è riportato un esempio di utilizzo del sistema, tramite le varie
nestre:
•
nestra della coda degli eventi: mostra a che frame si sono vericati gli eventi
individuati dal tracker e quelli costruiti a mano (ground truth);
•
nestra di analisi dell'errore: mostra l'utilizzo di una metrica inclusa nel sistema (la distanza euclidea) fra il ground truth e il modello del tracker; la linea
verticale corrisponde al frame mostrato nella nestra principale.
28
Lavori Correlati
Figura 1.7: Architettura di ODViS
ODViS è scritto in C++ usando le librerie QT
6
e il sistema operativo Linux.
Siccome le QT sono supportate anche su Windows, il porting di ODViS non dovrebbe
essere complicato (ma non è stato ancora eettuato). La prima versione stabile di
ODViS (che è anche quella attualmente disponibile) supporta il usso video in due
formati, le AVI e liste di frame.
Il usso di controllo di un modulo di sorveglianza all'interno del framework
ODViS è mostrato in g. 1.7.
Un modulo di sorveglianza deve implementare questa interfaccia se intende utilizzare ODViS. Per integrare un modulo, occorre linkarlo ad ODViS: solo un modulo
può essere linkato alla volta, ma nel futuro sono previste istanze multiple. Esso contiene una serie di funzioni di avvio e di stop che iniziano e terminano le sequenze
di tracking, la funzione di tracking che aggiorna i parametri monitorati e un set di
event detectors. La funzione di trigger (trigger function ) è necessaria per costruire un'istanza del tracking engine, e inizializzarla con un vettore di parametri che
descrive la congurazione iniziale del soggetto monitorato.
Il tracking engine è il componente principale del modulo di videosorveglianza:
6 http://trolltech.com/products/qt
29
fondamentalmente prende in input un vettore di parametri e ne produce uno nuovo
basato sull'analisi dei dati disponibili; la lettura dei dati video grezzi è ottenuta
utilizzando le DATA I/O API che orono al ricercatore un set di routine per accedere
a pixel, regioni, ed altre informazioni ausiliare come il timecode salvato con il video.
Ogni istanza del Tracking Engine mantiene un proprio stato interno. Ad ogni
frame, per ogni immagine istantanea di tracking viene controllata una condizione
di halting invocando le halting functions, che deniscono appunto le condizioni
che causano lo stop del sistema. La funzione di halting può prendere in ingresso il
vettore di parametri prodotto dal tracking engine per quel frame. Come esempio si
può considerare ad esempio che la funzione di halting venga invocata quando una
struttura monitorata lascia la scena.
Concludendo, ODViS si presenta con un'architettura molto scalabile e generalpurpose, ma forse non riesce, proprio per questa sua natura, a soddisfare le esigenze di molti. L'idea di un framework che comprenda tutte le fasi necessarie per
le fasi di tracking, detection, event analysis e performance evaluation è brillante,
ma dicilmente realizzabile: costringerebbe molti ricercatori a ri-adattare i propri
VCA all'interno del sistema. Per questi motivi ODViS è tuttora poco utilizzato e
supportato.
1.2.5 CAViAR
CAViAR, Context Aware Vision using Image-based Active Recognition [4] [5], è un
framework modulare plug-and-play fondato dall' EC's Information Society Technology e progettato e sviluppato all'Univ. of Edinburgh (Regno Unito), all'Instituto
Superior Tecnico (Lisbona, Portogallo), e all'Institut National Polytechnique de
Grenoble (Francia); il progetto è iniziato nel 2002 ed è terminato nel 2005.
CAViAR è stato progettato specicatamente per permettere a più implementazioni concorrenti di moduli equivalenti di lavorare in competizione uno con l'altro,
inserendoli all'interno del sistema per confrontare diversi approcci a problemi basati
su condizioni che variano su un ampio spettro di possibilità.
Il sistema è basato su un controller globale e su un numero di moduli per l'elaborazione delle informazioni.
Ogni modulo ore una completa descrizione di se
30
Lavori Correlati
stesso utilizzando CVML [6], includendo i suoi set di dati di input e di output e una
lista completa di parametri pubblici. Ogni parametro ha una descrizione che include
l'utilizzo raccomandato come ad esempio il passo minimo, massimo e incrementale
e le dipendenze con gli altri parametri.
Figura 1.8: Descrizione del modulo di CAViAR in CVML
L'implementazione include un componente base che contiene tutte le funzionalità
dei moduli comuni come ad esempio l'interfaccia che collega controller e parti per
la gestione dei parametri.
Dopo ogni run (dove un set di dati in input è elaborato per produrre dati di
output), ogni modulo farà un report al controller sulla complessiva qualità e quantità
dei risultati. Questo è chiamato feedback di alto livello e il modulo base aggiunge
le informazioni riguardati circa il tempo e le risorse spese. Il controller di CAViAR
è l'implementazione globale di un controller di sistema classico. All'avvio esso legge
una lista di possibili moduli che possono essere utilizzati compatibilmente con l'input
disponibile e l'output desiderato.
Il controller può funzionare in due modalità, una real-time e una oine di apprendimento. Durante questo apprendimento il controller scorre una o più sequenze
video dove il ground truth è già stato generato. Il controller può quindi confrontare
passo per passo i propri risultati con il ground truth fornito e per ogni modulo esplorare parti dello spazio dei parametri per capire quali di questi hanno un'inuenza
31
sull'output di quel modulo e sul sistema considerato nella sua interezza. Esso salva
poi la sua conoscenza in uno dei due modi disponibili, tramite reti neurali o regole create dinamicamente, per fare uso della conoscenza acquisita nel modo online,
quando le strette condizioni richieste dal real-time non permettono nessuna complessa esplorazione dello spazio dei parametri. La fase di apprendimento ha come scopo
anche quello della performance evaluation, per determinare quale tra vari moduli
equivalenti lavora meglio in circostanze stabilite.
I moduli di CAViAR comunicano i feedback, i dati e le informazioni di controllo
attraverso precise API; per le comunicazioni è sempre utilizzato CVML. L'architettura CAViAR è scritta in una combinazione di C++ e schemi e regole logiche
che utilizzano Clips. Esso utilizza le più svariate librerie, come le Imalab, le Intel's
OpenCv, le CoreLibrary.
Anche CAViAR presenta il problema di ODViS: un framework in cui integrare
moduli a piacere per avere una base comune su cui confrontare e testare i propri
algoritmi è un'idea ambiziosa e molto dicile da realizzare. Per questo, sebbene sia
molto più diuso di ODViS, CAViAR non è riuscito ad imporsi come standard de
facto.
32
Lavori Correlati
Capitolo 2
Il framework ViSOR
L'ambiente generale in cui si sviluppa il progetto verrà denito come il ViSOR
framework, un ambiente destinato a fornire un servizio di ricerca e recupero di di
video in base a determinate richieste e di valutazione degli algoritmi del sistema di
visione articiale che tramite la conoscenza e l'elaborazione genera informazioni utili
a questi due obiettivi.
Tale ambiente viene spesso denito come framework VCA, dove l'acronimo
VCA sta a indicare il sistema di video content analysis che si occcupa di elaborare
i dati attraverso opportuni algoritmi, una volta acquisito il video.
2.1
Visione Generale
Tutti i settori della visione articiale, quali medical imaging, multimedia, analisi del
traco e sorveglianza mirano a costruire un framework VCA generale e completamente integrato. Una distinzione deve essere fatta fra quei sistemi che rischiano di
sorire di un fallimento critico se i termini di scadenza temporali vengono violati
(hard-time), e quelli che non ne sorono (soft-real time).
Per i sistemi di video-
sorveglianza in real-time, dove l'operatore vuole ricevere allarmi per certi eventi, è
richiesto al sistema di lavorare con un piccolo ritardo.
Se un allarme deve essere
generato quando una macchina entra nella scena, il sistema VCA non può applicare
la classicazione quando l'oggetto lascia la scena, ma fare questa classicazione al
volo.
33
34
Il framework ViSOR
Figura 2.1: Visione d'insieme dell'ambiente
Il framework ViSOR ha tre moduli principali.
Il primo è il modulo del video content analysis, dove l'acquisizione video è applicata (frame grabbing da una camera); gli oggetti in movimento vengono segmentati
dall'immagine video in input.
Le caratteristiche degli oggetti (come la velocità e
la dimensione) vengono raccolte e vengono generati dei metadata legati a queste
caratteristiche: essi vengono poi salvati nel database generale, che è successivamente
utilizzato per la ricerca e il recupero di contenuti e per la valutazione delle prestazioni. Siccome l'acquisizione video per la sorveglianza e il traco è applicato in modo
continuativo (non-stop), l'analisi dei contenuti è fatta in real-time.
Il secondo modulo è la ricerca e il recupero di dati, dove gli utenti possono
compiere ricerche all'interno del database, attraverso tutti i video depositati, in base
a criteri specici (come il tipo di oggetto, la dimensione, la velocità e la traiettoria).
I risultati ritornati sono presentati all'utente attraverso un'interfaccia graca. Visto
2.2 L'annotazione di video
35
1
che la ricerca può essere eettuata o-line , il modulo non è condizionato dal fattore
real-time e dalle sue stringenti condizioni.
Il terzo modulo comprende la performance evaluation degli algoritmi di video
content analysis.
I metadati, generati nel passo di analisi, sono confrontati con i
risultati aspettati, cioè i così deniti
ground truth (GT), attraverso opportune
metriche di valutazione.
Principalmente, il progetto verrà sviluppato all'interno del primo e del terzo
modulo. Nei seguenti capitoli tutti i moduli verranno espansi e dettagliati.
2.2
L'annotazione di video
La valutazione delle prestazioni di un sistema prevede diversi requisiti (g. 2.2).
I punti chiave per realizzarla sono denire e possedere:
•
un ground truth
•
l'output del sistema interessato
•
alcune metriche di valutazione
per ottenere quindi dei risultati, da cui sarà necessario estrarne una visualizzazione e le opportune conclusioni.
L'output del sistema che si intende valutare e i dati di ground truth devono essere
pienamente confrontabili tra loro, secondo uno schema logico preciso.
E' quindi
necessario un formato di annotazione comune tra sistema e ground truth, perché
tramite la metrica designata si possano comparare ed estrarre risultati adabili;
le annotazioni sono i metadati attraverso i quali si possono ottenere valutazioni o
eettuare ricerche sui video elaborati e analizzati (g. 2.3).
Il formato di annotazione è composto essenzialmente da due livelli:
•
livello semantico:
è il livello della comprensione, denisce come andranno
categorizzate e modellate le entità da annotare
1 Ovvero dopo il video processing; come si vedrà in 2.4, la ricerca si può eettuare online sul
sito di ViSOR
36
Il framework ViSOR
Figura 2.2: Processo di valutazione delle prestazioni
Figura 2.3: Visione d'insieme: annotazioni
•
livello sintattico : è il livello del linguaggio, denisce le regole di scrittura del
formato
Prima di analizzare in modo più attento questi due livelli occorre approfondire
cosa si intende per ground truth.
2.3
Ground Truth
Il ground truth è un componente fondamentale nel framework (come è possibile
osservare in g. 2.4) e in generale nella performance evaluation.
2.3 Ground Truth
37
Figura 2.4: Visione d'insieme: ground truth
I dati di ground truth vengono creati con l'intento di orire dati indipendenti e
obiettivi (riguardo alla classicazione, alla locazione e alla dimensione, ad esempio)
che possono essere collegati alle osservazioni estratte dalla sequenza video.
Per
esempio, nella sorveglianza in remoto, il ground truth può identicare l'utilizzo
della locazione corrente, il tipo di agricoltura o la geometria di strutture costruite
dall'uomo, per poi confrontare il tutto con i dati estratti dal satellite o dalle riprese
aeree. In questo caso, i dati di ground truth potrebbero tipicamente essere generati
da perizie manuali, che includono l'ispezione di regioni molto ampie.
La generazione di questi dati richiede un gran impegno di tempo ed è soggetta
all'errore ed all'incertezza.
Dove le caratteristiche dell'immagine sono soggette a
cambiamenti (ad esempio la crescita delle coltivazioni e il raccolto), è importante
assicurare la coincidenza temporale dell'immagine catturata e del ground truth. In
aggiunta, la qualità del ground truth è altamente dipendente dalle competenze dei
geometri che eseguono i rilevamenti topograci.
I dati di ground truth per il video tracking presentano alcune dierenti sde.
La prima riguarda l'indicazione della posizione di un soggetto, usando il bounding
box che lo circumscrive, un singolo punto che lo identica unicamente come il punto
più alto dell'oggetto o il centroide.
38
Il framework ViSOR
Secondariamente, si punta un accurato contrassegno del contorno dell'obiettivo.
Questo può abilitare una varietà di misurazioni basate sulle regioni per determinare
la qualità della segmentazione, i dettagli di quella determinata forma e della sua
apparenza.
Inne, possono essere generate le informazioni di classicazione.
Questo è ge-
neralmente il più semplice da produrre siccome è necessario solo un valore per
traccia.
Per le prime due categorie il ground truth può essere determinato passando
frame per frame l'intera sequenza e caratterizzando i soggetti nella scena, tramite
metodi puramente manuali o strumenti semi-automatici. Il metodo manuale è abbastanza comodo per la prima categoria, ma è particolarmente noioso e lungo per
contrassegnare i contorni, specialmente se è richiesto di annotare migliaia di soggetti. L'approccio semi-automatico (supervisionato) utilizza un algoritmo di tracking
e detection per trovare e identicare facilmente soggetti corrispondenti ai frame
precedenti, permettendo l'intervento manuale per la correzione di eventuali errori
dell'algoritmo stesso. Una conseguenza nell'utilizzare questo metodo per generare il
ground truth è che è polarizzato in favore dello stesso algoritmo di detection che
deve essere valutato.
In generale, questi metodi di estrazione del ground truth sono soggettivi e tendenti ad errori, particolarmente considerando la natura tediosa dell'acquisizione e
la possibile inclinazione del valutatore che eettua il ground truth - se il valutatore compie delle scelte che possono risultare simili a quelle di un certo algoritmo o
metodo, può favorire indirettamente un particolare labelling.
In aggiunta, allo stimatore può anche essere richiesto di categorizzare la visibilità
di ogni soggetto monitorato, e questo include la valutazione di occlusioni parziali o
complete quando un soggetto si incrocia con un altro soggetto statico o mobile nell'immagine. Diversi ricercatori possono vedere in modo dierente come questi eventi
sono rappresentati nel ground truth - in alcuni casi, il ground truth viene generato solo quando può essere identicato univocamente. Negli altri casi, il valutatore
può annotare solo i soggetti parzialmente invisibili, o inferire sull'intero soggetto
(basandosi sulla conoscenza dei frame precedenti).
Questo è un chiaro compromesso tra il tempo speso per acquisire il ground truth
2.3 Ground Truth
39
e l'accuratezza e l'attendibilità dei dati risultanti. Ciò è particolarmente vero se la
qualità della segmentazione e la susseguente analisi delle forme è da valutare, perché
l'acquisizione manuale dei dati di conne del soggetto porterebbero ad un eccessivo
impiego di tempo.
2.3.1 Gli errori umani
Il ground truth è quindi necessario come dogma per vericare la precisione e l'efcacia dei propri algoritmi: si assume che l'osservatore umano sia equo e infallibile.
Questo, come anticipato in 2.3, non è sempre vero, ed è necessario tener conto della
variabilità dell'osservazione umana quando si confrontano i risultati al ground truth.
Per esempio, se le dimensioni del bounding box realizzate da due osservatori umani
variano del 5%, la dierenza del 5% tra i risultati del tracker e il ground truth è
probabilmente insignicante.
List et al [7] ha compiuto un interessante studio sulla variabilità di più osservazioni contemporanee, all'interno del progetto CAViAR (si veda 1.2.5). Le principali
attività osservate sono costituite da alcune persone che vagano o camminano, più un
combattimento simulato tra due ricercatori. La sequenza inoltre include alcuni casi
dicili, come persone praticamente ferme, persone in situazioni ambigue e piccoli
soggetti in regioni scure sul fondo della scena principale. Nel compiere il labelling,
gli osservatori conoscevano la disposizione dei mobili, quali i punti di informazione,
le scrivanie, i divani etc.
Sono stati utilizzati 3 livelli per riportare e categorizzare il labelling a mano:
1. Spatial Tracking: la descrizione geometrica degli individui in movimento, il
matching degli oggetti e dei gruppi, le posizioni del bounding box.
2. Temporal Tracking: le dierenze a tempo di frame di un determinato soggetto
e dei suoi comportamenti all'interno del contesto.
3. Human Behaviour Labelling: l'assegnazione di un'ipotesi di comportamento
del soggetto o del gruppo, che consiste di quattro etichette: movimento, ruolo,
situazione e comportamento generico.
40
Il framework ViSOR
Gli esperimenti all'interno dell'object detection al primo livello portano alla conclusione che il riconoscimento è accurato al 95% circa.
E' da notare che il terzo
osservatore ha contrassegnato generalmente il 20% in più rispetto al primo osservatore, e il secondo un sorprendente 80% rispetto a quest'ultimo, poiché il secondo ha
riconosciuto come soggetti anche persone praticamente ferme. La ragione di queste ampie dierenze risiede nella diversa opinione che gli osservatori umani hanno
riguardo all'importanza dei soggetti.
Per quanto riguarda i gruppi, deniti univocamente grazie al requisito di almeno
90% di overlap, non ci sono grosse divergenze. Gli errori di posizione si limitano a
1-2 pixels (2-3 per i gruppi), quelli di dimensione al 3% (4%-8% per i gruppi), quindi
entro valori più che accettabili.
Per i risultati del temporal tracking, è stato registrato quanto velocemente gli
osservatori notavano gli oggetti e i gruppi dopo la loro apparizione iniziale, quanto
bene erano in accordo sul tempo di uscita, e quanto spesso durante il tracking perdevano le tracce di questi. Per l'apparizione degli oggetti il risultato è stato che gli
osservatori li hanno validati entro i 2 frame (entro i 5 per i gruppi). Per l'uscita le
dierenze non hanno raggiunto il singolo frame; la perdita delle tracce dei soggetti
è risultata inferiore al 3% per gli individui e ad un solido 0% per i gruppi.
Inne, per quanto riguarda l'analisi del comportamento, le dierenze principali
risiedono nella denizione del movimento e nel confronto dei ruoli; questo è dovuto
al fatto che gli osservatori sono inuenzati dalla loro personale interpretazione
di cosa accade nella scena.
In alcuni casi, purtroppo, queste interpretazioni sono
molto diverse o ambigue. Nel caso di situazioni disambigue, i risultati confermano
un'interpretazione concorde nell'80% dei casi circa, e in alcuni casi al 100%.
Per i gruppi, invece, non vi è questa variabilità e i risultati sono consistenti. Nel
caso dei due ricercatori che combattono, ad esempio, tutti gli osservatori non hanno
avuti dubbi sul ruolo. Forse questo è dovuto al fatto che può essere più dicile per
un osservatore decidere se un individuo sta muovendosi o meno (o sta coprendo quel
ruolo) piuttosto che identicare con una certa sicurezza il proposito dell'individuo
all'interno del gruppo (relazionato quindi ad altri).
2.4 Livello semantico: ViSOR
2.4
41
Livello semantico: ViSOR
ViSOR (Video Surveillance Online Repository ) è una collezione condivisa di video
relativi alla sorveglianza e delle rispettive annotazioni, sviluppata presso l'ImageLab
[8] al Dipartimento di Ingegneria dell'Informazione all'Università di Modena e Reggio
Emilia.
ViSOR fa parte del progetto europeo VIDIVIDEO, il cui obiettivo è la
ricerca semantica sui video, sulla base di un vasto thesaurus di concetti audio-visivi
di apprendimento delle macchine.
Figura 2.5: ViSOR homepage
2.4.1 Obiettivi
Lo scopo di ViSOR è di raccogliere e rendere pubblicamente disponibile questa
collezione di video alla comunità di ricercatori che si occupano di video sorveglianza
e della ricerca dei video (video retrieval ).
Inoltre, vi è il proposito di scambiare,
confrontare e discutere risultati su un'ampio spettro di problemi attraverso un forum
creato appositamente. E' il cuore dell'ambiente descritto in questa tesi; il core di
ViSOR si occupa quindi delle parti evidenziate in g. 2.6.
42
Il framework ViSOR
Figura 2.6: Visione d'insieme: portale ViSOR
Poiché questa condivisione di video potrebbe portare anche alla divulgazione di
informazioni personali, si adotta una politica che garantisce il rispetto della privacy:
•
L'accesso è protetto e consentito solo ad utenti registrati
•
L'abilitazione di un account è controllata da un moderatore
•
Alcuni contenuti video sono modicati per eliminare informazioni utili all'identicazione (un esempio è l'oscuramento dei volti)
•
le responsabilità sono a carico del proprietario del video (inteso come colui che
lo carica sul repository)
La collezione creata sarà strutturata in modo da contenere sia scenari outdoor che
indoor, come strade, parchi pubblici, uci e campus universitari, nell'arco di tutte
le 24 ore del giorno, spesso con viste dierenti: questo permette potenzialmente di
inviare richieste come trovami tutti i video che contengono una persona che stanno
correndo dalle 7 alle 8 pomeridiane, oppure trovami tutte le sequenze video in
questa determinata area in cui una due persone sono ferme a discutere.
Insieme ai video, il progetto contiene annotazioni di metadati, generati sia manualmente (ovvero dati di ground truth) che automaticamente.
In questo modo,
43
gli utenti che interagiscono con il repository possono eettuare sui propri algoritmi
valutazioni di prestazione e confronto con altre attività concorrenti.
2.4.2 Denizione dell'ontologia
Per assicurare l'interoperabilità tra gli utenti è stato denito un formato di annotazione standard insieme alla struttura della conoscenza base. La conoscenza che
può essere estratta dalle sequenze di videosorveglianza è costruita come una semplice
lista di concetti: questa tassonomia è una forma base di ontologia dove i concetti
sono gerarchicamente strutturati ed univocamente deniti. E' ovviamente possibile
arricchire dinamicamente questa lista, sotto la supervisione del manager del progetto, per permettere la crescita di questa struttura senza pregiudicarne l'omogeneità
e l'unicità dei componenti, evitando così la nascita di sinonimi e ambiguità.
Figura 2.7: Ricerca e risultati sui concetti video in ViSOR
La tassonomia denita per classicare forme, oggetti ed eventi signicativi all'interno di un ambiente di videosorveglianza è rappresentata visualmente in g. 2.8.
44
Il framework ViSOR
In essa, un concetto può rappresentare diverse cose; per esempio, può descrivere il
Figura 2.8: Tassonomia gerarchica delle categorie sui concetti video
contesto del video (località, orari, tempo etc..), un'oggetto sico caratteristico o presente nella scena (persone, animali, edici), oppure un'azione/evento individuabile
(cadute, esplosioni, interazioni).
Allo stesso tempo, i concetti deniti possono essere dierentemente relazionati
nello spazio del tempo. Perciò, si introduce anche un'altra tassonomia basata sul
tempo: un concetto può infatti essere correlato all'intero video (ad esempio per la
località o le caratteristiche della camera), ad un intervallo temporale (una persona
nella scena), o ad un singolo frame/istante (un'esplosione o l'entrata di una persona
nella scena).
Una prima lista di concetti è stata ottenuta come un sottoinsieme di due diversi
set già predeniti, rispettivamente la 101-concept list di UvA [9] e LSCOM [10].
Siccome queste liste sono state denite per contesti generici, solo una piccola parte
può essere eletta per servire la videosorveglianza.
In più, le liste UvA e LSCOM
sono basate solamente sui key-frame e non bastano a descrivere attività ed eventi.
In altre parole, non si è interessati solo a concetti individuabili analizzando separatamente ogni keyframe, ma anche ad eventi/azioni che richiedono un'analisi
temporale. La denizione di evento è estremamente importante nel caratterizzare
i contenuti del video: un evento è tipicamente avviato da qualche cambiamento di
45
stato catturato all'interno della sequenza, come l'inizio del movimento di un oggetto. L'abilità di ragionare ad eventi è un passaggio dicile ma necessario verso la
comprensione video.
Gli oggetti sono qualsiasi entità denita e individuata in un intervallo di tempo
e rappresentata da un set di caratteristiche visive che mutano all'interno di questi,
mentre gli eventi sono fatti vericati da un set di regole, condizioni e relazioni.
L'ontologia di ViSOR è strutturata in diverse classi, ognuna delle quali appartiene ad una delle categorie riportate in g. 2.8. Un'annotazione video può essere
considerata come un set di istanze di queste classi; ad ogni istanza viene poi assegnata una lista di attributi relativi. Alcuni di questi descrivono direttamente la natura
della classe stanziata, ovvero sono connessi a quell'entità con una relazione IS-A
(ad esempio informazioni come uomo, donna, bambino etc possono essere assegnati
ad istanze della classe Person ). Altri attributi, invece, descrivono alcune caratteristiche dell'entità, in relazione HAS-A (come il contorno, il colore e la posizione di
un istanza FixedObject ).
Attualmente il formato di annotazione utilizzato è il formato di ViPER, ed è in
sviluppo un modulo MPEG-7.
ViPER denisce le regole con le quali le persone possono annotare i propri
video, denendo quindi il livello di sintassi appropriato per un formato comune.
Ogni traccia che sarà annotata diverrà un descrittore. I descrittori sono di diversi
tipi (vedi g.2.1), ed ognuno di questi, come si è visto, possiede diversi concetti, che
possono essere dinamici o statici. Qual'è la dierenza tra questi ultimi due??
46
Il framework ViSOR
Descriptor Name
Category
Viper Type
Person
PhysicalObject
Object
BodyPart
PhysicalObject
Object
GroupOfPeople
PhysicalObject
Object
FixedObject
PhysicalObject
Object
MobileObject
PhysicalObject
Object
ActionByAPerson
Action/Event
Object
ActionByPeople
Action/Event
Object
ObjectEvent
Action/Event
Object
Event
Action/Event
Object
Video
Context
Content
Clip
Context
Content
Location
Context
Content
Tabella 2.1: Descrittori di ViSOR
Is-a Concepts
Name
Building
House
Oce
Windows
Denition
Type
Dynamic
Shots of an exterior of
bvalue
False
...
bvalue
False
...
bvalue
False
...
bvalue
False
Type
Dynamic
bbox
True
2D Position of the gravity center
point
True
Contour of the object
polygon
True
a building [ID LSCOM 226]
...
Has-a Concepts
Name
Position_BBOX
PositionBar
Contour
Denition
Tabella 2.2: Un estratto della concept list del descrittore FixedObject
2.5 Livello sintattico: ViPER
47
I concetti statici hanno un unico valore, che corrisponde ad una sua caratteristica
intrinseca (in relazione IS-A, già citata precedentemente): questa è invariante nel
tempo, e indissolubilmente legata al descrittore.
I concetti dinamici, invece, rappresentano caratteristiche del descrittore che cambiano nel tempo, come la forma, il contorno, la traiettoria, la velocità, etc...; la relazione che contraddistingue i concetti dinamici è quindi quella HAS-A. I concetti
dinamici possiedono perciò una lista di valori, ognuno di questi associato ad un certo
intervallo temporale.
Nella tabella 2.2 è ad esempio possibile osservare i concetti dinamici e statici
deniti per il descrittore FixedObject.
2.5
Livello sintattico: ViPER
ViPER (Video Performance Evaluation Resource ) è un toolkit di programmi Java,
sviluppato dal Language and Media Processing Laboratory (LAMP [5]) dell'università del Maryland, che permette la valutazione di algoritmi per analisi video confrontando l'output generato da un qualche programma con una versione ideale della
verità (Truth ).
2.5.1 Perchè utilizzare ViPER
ViPER soddisfa i seguenti requisiti:
•
la lista dei concetti è personalizzabile, ma allo stesso tempo ben denita;
•
è largamente diuso , evitando così le dicoltà di condividere un nuovo for-
2
mato specico;
•
è intuitivo e semplice da imparare e utilizzare;
•
è self containing, in quanto la descrizione dei dati di annotazione è inclusa
assieme ai dati;
2 E' utilizzato ad esempio da ETISEO (si veda 1.2.3) e VACE (si veda 1.2.1)
48
Il framework ViSOR
•
è possibile realizzare un'annotazione su ogni singolo frame;
•
contiene un sistema di annotazione general-purpose e imparziale;
•
è open source.
Figura 2.9: ViPER-GT
Per assicurare che i ricercatori possano ripetere e vericare le valutazioni, ViPER
mette a disposizione:
1. Un metodo standard per rappresentare i risultati delle analisi e i metadati
del ground truth.
In questo modo si è in grado di pubblicare questi dati,
permettendo alle parti interessate di eseguire valutazioni anche con altri tool,
o di confrontare i diversi algoritmi.
2. Un sistema per congurare la valutazione. ViPER utilizza il tipo di le EPF
(Evaluation Parameter File) contenente i parametri per la valutazione, in
combinazione con un le di tipo PR (PRoperties) contenente un elenco di
proprietà.
49
3. Uno strumento per eettuare la valutazione, ViPER-PE.
4. Un modo signicativo di presentare i risultati.
2.5.2 Strumenti di interazione con il formato
I tool fondamentali del toolkit ViPER sono:
•
ViPER-GT: Ground Truth Authoring Tool, ore all'utente un'interfaccia graca Java per il processo di generazione di metadati ground truth. Permette
l'annotazione, frame dopo frame, di video multimediali tramite metadati che
vengono salvati nel formato proprietario di ViPER (XGTF, ma anche XML).
Funziona anche da editor per i metadati stessi.
•
ViPER-PE: Performance Evaluation Tool, é un tool Java a linea di comando
per la valutazione delle prestazioni. Ore una varietà di metriche per eseguire
comparazioni tra le di metadati video oppure per confrontare un set di dati
risultanti da un'elaborazione automatica con i dati ground truth.
Fornisce
metriche precise e ricorsive, valutazioni sia su ogni singolo frame sia basate
sugli oggetti, e un meccanismo di ltraggio per valutare un subset di dati
rilevanti. Descritto in modo più attento nel cap. 6.
2.5.3 Schema generale del formato
Possiamo riassumere il formato di annotazione e i suoi componenti per punti.
•
Un Descrittore
è un record che descrive uno o più elementi del video
è un oggetto che si conforma ad uno schema denito dall'utente
è composto da diversi attributi con nome e tipo associato
ha un unico ID e un periodo associato nel quale è valido
è uno di questi tre tipi: File, Content, Object
50
Il framework ViSOR
∗
File:
esso si riferisce a dati che rappresentano il video nella sua
interezza, oppure altri metadati riguardanti quest'ultimo, come il
formato del le e il framerate.
∗
Content: istanze di questo tipo possono occorrere solo una alla volta,
e non possono cambiare durante il corso della propria vita.
∗
Object: si riferisce ad un oggetto che può avere diverse istanze in
qualunque istante di tempo, e queste istanze possono cambiare nel
tempo. Ogni istanza ha il proprio periodo di vita (time span ) e un
set di attributi.
•
Un attributo
Ogni descrittore ha diversi attributi.
Un attributo può essere uno dei seguenti tipi:
∗
svalue : stringa di caratteri
∗
lvalue : valore numerato - una delle possibilità denite dall'utente
∗
bbox, polygon, etc. - uno tra i vari tipi di dato riferiti alle forme
∗
reference : riferimento ad un altro descrittore
D'ora in poi, gli attributi verrano deniti concetti.
Il formato viene salvato in XML, che rappresenta ormai da tempo il metalinguaggio più diuso e oggettivamente più ecace per questo tipo di utilizzo.
Il le è formato principalmente da due parti:
•
cong, dove sono deniti i descrittori e i loro attributi
•
data, dove vi sono le istanze dei descrittori per uno o più le
Qui di seguito viene riportato un semplice esempio di un le di ViPER:
" 1.0 " e n c o d i n g=" UTF -8 " ?>
" http: // lamp . cfar . umd . edu / viper #"
/ viperdata #">
1
<? xml
2
<v i p e r
v e r s i o n=
x m l n s=
" http: // lamp . cfar . umd . edu
x m l n s : d a t a=
3
4
< c o n f i g>
<d e s c r i p t o r
5
" Information "
" false "
name=
<a t t r i b u t e
6
d y n a m i c=
9
10
</ a t t r i b u t e>
11
<a t t r i b u t e
12
" false "
d y n a m i c=
<d e s c r i p t o r
" fvalue " />
t y p e=
" Person " t y p e=" OBJECT ">
" HeadPosition " t y p e=" point " d y n a m i c=" true " />
name=" HeadEllipse " t y p e=" ellipse " d y n a m i c=" true " />
name=
<a t t r i b u t e
15
<a t t r i b u t e
name=
16
</ d e s c r i p t o r>
17
</ c o n f i g>
18
<d a t a>
" cam3_120405A1 . mpg ">
" Information ">
< a t t r i b u t e name=" FRAMERATE ">
<d a t a : f v a l u e
v a l u e=" 1.0 " />
<s o u r c e f i l e
20
<f i l e
21
22
23
f i l e n a m e=
"0"
i d=
name=
24
</ f i l e >
25
<o b j e c t
26
" 77 :79 " i d="0" name=" Person ">
" HeadPosition ">
< d a t a : p o i n t f r a m e s p a n=" 77 :77 " x="7" y=" 232 " />
< d a t a : p o i n t f r a m e s p a n=" 78 :78 " x=" 11 " y=" 244 " />
f r a m e s p a n=
<a t t r i b u t e
27
28
29
30
name=
31
32
<a t t r i b u t e
" HeadEllipse ">
f r a m e s p a n=" 77 :77 " h e i g h t=" 23 "
r o t a t i o n=" 97 " w i d t h=" 113 " x="7" y=" 232 " />
<d a t a : e l l i p s e
r o t a t i o n=" 99 " w i d t h=" 119 " x=" 10 " y=" 242 " />
r o t a t i o n=" 98 " w i d t h=" 114 " x=" 11 " y=" 244 " />
33
name=
34
35
36
37
38
39
40
</ o b j e c t>
41
<o b j e c t
42
. . .
" 86 :94 "
f r a m e s p a n=
43
</ o b j e c t>
44
</ s o u r c e f i l e >
46
" FRAMERATE "
name=
</ d e s c r i p t o r>
14
45
" lvalue ">
t y p e=
− p o s s i b l e s>
< d a t a : l v a l u e −enum v a l u e=" SEQUENCE " />
< d a t a : l v a l u e −enum v a l u e=" FRAMES " />
</ d a t a : l v a l u e − p o s s i b l e s>
7
19
" FILE ">
" SOURCETYPE "
t y p e=
name=
<d a t a : l v a l u e
8
13
51
"1"
i d=
" Person ">
name=
</ d a t a>
</ v i p e r>
Analizzandolo brevemente, si può notare come all'interno di questo le vi siano
due istanze di descrittori della classe Person, descritti attraverso due concetti
(deniti da ViPER come attributi), il baricentro della testa e la sua forma racchiusa
in un ellisse; in altre parole, vengono annotate due persone in movimento.
52
Il framework ViSOR
Capitolo 3
Le metriche di valutazione sono un'altra importante componente nella valutazione
delle prestazioni.
Figura 3.1: Visione d'insieme: metriche
Siccome un VCA
1
completo comprende più livelli semantici, la valutazione può
essere fatta su un determinato livello. Gli algoritmi che compiono solamente la segmentazione di oggetti in movimento, senza tracking attraverso frame multipli, può
1 Video Content Analysis, si veda al cap. 4
53
54
essere valutata esclusivamente in base ai pixel. Gli algoritmi che al contrario emettono allarmi (ad esempio al riconoscimento di macchine) possono essere valutati solo
per la loro classicazione, e non per la qualità della loro segmentazione. Perciò, per
prima cosa è necessario denire cosa deve essere valutato per ogni livello semantico.
Per ogni livello sono quindi richieste dierenti metriche.
3.1
I livelli semantici
I livelli semantici deniti per la valutazione sono:
1. Pixel-based: segmentazione degli oggetti in movimento e del background statico
2. Object-based per frame: caratteristiche dell'oggetto all'interno di quel determinato frame
3. Object-based over object life time: classicazione e caratteristiche dell'oggetto in base al suo tempo di vita
4. Behaviour of objects: comportamento degli oggetti e analisi degli eventi
E' possibile raggruppare questi livelli in tre macro-categorie:
(valutazione sui pixel),
Pixel-Based
Frame-Based (valutazione sui frame) e Object-Based
(valutazione sugli oggetti).
3.2
Pixel-Based
Il primo passo da compiere per ottenere una valutazione delle performance è utilizzare metodi statistici standard sul confronto tra due popolazioni di valori. A livello
di pixel la valutazione viene eettuata per ottenere la qualità della segmentazione
degli oggetti e del background statico.
Si sfruttano quindi i seguenti concetti:
3.2 Pixel-Based
•
55
True Positive (TP) : numero di pixel correttamente individuati, ovvero quei
pixel appartenenti all'output del sistema che a quel determinato frame hanno
una corrispondenza (basata su colore o luminosità, ad esempio) con il rispettivo
pixel appartenente ad un oggetto del ground truth
•
False Positive (FP) : numero di pixel individuati come appartenenti ad oggetti
dal sistema, ma che non presentano un riscontro nel ground truth
•
True Negative (TN) : numero di pixel su cui sia il sistema che il ground truth
considerano come pixel di background (quindi non oggetti)
•
False Negative (FN) : numero di pixel non individuati dal sistema come oggetti
ma che sono presenti nel ground truth
Tali metriche sono utili perché sono la base per stimare l'indice relativo alla specicità e alla sensibilità e per la costruzione di curve ROC. Mentre i veri negativi
non vengono praticamente calcolati poiché lo spettro di questi è troppo ampio, i
falsi negativi fanno capire al ricercatore che il proprio algoritmo (o sistema) non
riconosce pixel (od oggetti) classicati dal ground truth.
Da queste metriche, infatti, è possibile ricavare i seguenti indici:
•
Tracker Detection Rate (TRDR)
•
False Alarm Rate (FAR)
•
Detection Rate (Recall)
•
Specicity
•
Accuracy
•
Positive Prediction (Precision)
=
=
=
=
=
TP
T GT
FP
TP + FP
TP
TP + FN
TN
FP + TN
TP + TN
TF
=
TP
TP + FP
56
•
Negative Prediction
=
TN
FN + TN
•
False Negative Rate
=
FN
TN + TP
•
False Positive Rate
=
FP
FP + TN
dove TGT rappresenta il numero totale di pixel (frame per il livello successivo) per
gli oggetti del ground truth e TF il numero totale di pixel (frame) dell'intera sequenza.
La Detection Rate o Recall viene spesso denitiva anche come Sensibilità ed è
il rapporto tra il numero di pixel correttamente individuati, ovvero i true positive, e
il totale dei pixel del ground truth, cioè la somma tra true positive e false negative;
è dunque la probabilità che un pixel da individuare venga eettivamente individuato.
La Specicità viene invece calcolata come il numero di pixel che non devono essere
individuati (true negative) divisi per il totale di quelli che realmente non devono
esserlo (includendo quindi anche i falsi positivi). In altre parole, da un punto di vista statistico è la probabilità che un pixel che non ha un corrispondente nel ground
truth non venga individuato come pixel di un oggetto da parte del sistema.
La Positive Prediction (più comunemente denita come Precision ) rappresenta esattamente la precisione del sistema, ovvero quanti pixel vengono individuati correttamente sui tutti i pixel.
In letteratura, non sono ancora state denite delle metriche standard a livello di
pixel.
Zhang [11] ha elencato vari metodi di valutazione per la segmentazione delle immagini, sia empirici che analitici (questi ultimi, ad esempio, considerano i principi,
i requisiti e la complessità degli algoritmi).
Correia et al. [12] propone metriche per la valutazione dei metodi di segmentazione di un'immagine con l'obiettivo di creare misure obiettive che corrispondessero
3.3 Frame-Based
57
alla valutazione di un osservatore umano. Gli autori concludono aermando che la
valutazione della segmentazione degli oggetti in un video è un problema per il quale
non è ancora stata trovata una soluzione in letteratura.
Erdem et al. [13] presenta tre metriche di valutazione che non richiedono ground
truth segmentato. Loro suggeriscono di utilizzare sia la dierenza spaziale sul colore,
sul moto e sui contorni dell'immagine segmentata che la dierenza temporale dell'istogramma dei colori dell'oggetto nel frame corrente rispetto ai frame precedenti.
Gli autori sostengono che, sotto determinate assunzioni, il processo di annotazione
ground truth (che richiede un'enorme quantità di tempo) non è necessario. Tuttavia, quando si guarda al di là della segmentazione, il ground va comunque generato
manualmente.
Prati et al. [14] ha analizzato vari algoritmi di segmentazione delle ombre, modicando le metriche Detection Rate e False Alarm Rate e ridenendole come Shadow
Detection Rate e Shadow Discrimination Rate. Successivamente viene fatto un confronto tra vari algoritmi a livello di pixel, comparandoli frame per frame. Purtroppo,
il risultato nale sulle ombre a livello di oggetti non è considerato.
Oberti et al. [15] propone l'utilizzo della curva Receiver Operating Characteristics
(ROC). Loro hanno fatto notare che le curve ROC ottenute possono essere sfruttate
per estrarre informazioni utili sulle performance del sistema, quando avvengono
cambiamenti alle condizioni della scena.
Le curve ROC possono essere utilizzate
anche per trovare il punto di lavoro ottimale per un set di parametri.
Chalidabhongse et al. [16] propone come metrica la Perturbation Detection Rate
(PDR) che trae alcuni vantaggi dall'analisi della curve ROC, per il background sub-
straction, ovvero ottenendo la segmentazione del moto grazie alla sottrazione tra
l'immagine e il background calcolato no a quel momento.
3.3
Frame-Based
Le metriche basate su frame sono utilizzate per misurare le performance di un sistema di videosorveglianza su ogni frame della sequenza video. Queste metriche non
tengono conto delle risposte del sistema che riguardano il preservare l'identità di un
oggetto durante il suo periodo di vita.
Ogni frame viene testato individualmente per osservare se il numero di oggetti e
le loro caratteristiche (dimensione e posizionamento) corrispondono ai dati relativi
58
al ground truth per quel particolare frame. Il risultato viene poi ottenuto prendendo
la media sull'intera sequenza delle statistiche acquisite da ogni frame. Chiaramente,
questo rappresenta un approccio bottom-up, ovvero dal basso verso l'alto.
Al livello frame valgono le seguenti considerazioni:
•
I True Positive sono il numero di frames dove sia il risultato del ground truth
che quello del sistema concordano sulla presenza di uno o più oggetti, e il
bounding box di almeno uno o più di questi ha una corrispondenza tra i due
risultati (parziale o completa, dipende dalla soglia).
•
I False Positive sono il numero di frames dove i risultati del sistema contengono
almeno un oggetto, mentre quelli ground truth non ne contengono nessuno
oppure nessuno degli oggetti del GT cade all'interno del bounding box di
ogni oggetto del sistema.
•
I True Negative sono il numero di frame dove sia i risultati del ground truth
che del sistema concordano sul fatto che non vi sono oggetti presenti.
•
I False Negative sono invece rappresentati dal numero di frame dove il ground
truth contiene almeno un oggetto, mentre il sistema non ne contiene nessuno
oppure nessuno degli oggetti del sistema trova delle corrispondenze con uno
degli oggetti presenti nel GT.
Valgono inoltre gli stessi indici riportati in 3.2.
Mariano et al. [17] ha presentato sette metriche per la valutazione degli algoritmi
di object detection confrontando le proprietà dei bounding box degli oggetti. In tutti
i modi, gli autori hanno già aggiunto che le metriche proposte vanno estese per gli
algoritmi che monitorano gli oggetti nel tempo e nello spazio.
Nascimento e Marques [18] propongono nuove metriche che coprono anche lo split
e il merge di più oggetti, ovvero tengono conto della scissione e della fusione di
quest'ultimi. Oltre a queste, sfruttano anche le metriche comuni sopra citate, come
la false alarm rate e la detection rate.
3.4 Object-Based
3.4
59
Object-Based
La valutazione basata sugli oggetti calcola le metriche fondandosi sul completo
periodo di vita e sulla traettoria di ogni traccia del sistema e del ground truth.
Needham e Boyle [19] hanno presentato alcuni metodi di valutazione per il po-
sitional tracking (le traiettorie degli oggetti): quanto bene può un algoritmo determinare la posizione di quel dato oggetto?
Loro hanno proposto metriche sulla
distanza tra due traettorie, sia nel dominio spaziale che in quello temporale, e
hanno denito una misura per l'area tra le queste ultime due. Tuttavia, gli autori
considerano solo traettorie di uguale lunghezza. In un sistema che lavora con grandi
variazioni di dati in input (ad esempio come ombre molto lunghe e larghe a causa
del sorgere del sole o i riessi in un giorno di pioggia), la lunghezza dell'intervallo di
tempo degli oggetti monitorati può non corrispondere alla lunghezza degli intervalli
del GT.
Rossi e Bozzoli [20] hanno presentato un semplice metodo di valutazione delle
prestazioni per il loro sistema di tracking confrontando quanti oggetti attraversano
una certa retta. Questa metodologia è molto semplice e richiede piccoli sforzi per la
creazione del GT. Pero', purtroppo, i risultati sono intrisecamente insucienti per
una valutazione generale.
Xu e Ellis [21] hanno presentato un approccio che può gestire con il grouping
(la presenza di gruppi) e le occlusioni parziali. L'approccio non richiede GT e non
può essere utilizzato per confrontrare più algoritmi. La prima misura è l'errore di
tracking tra il valore della posizione corrente e quello predetto (dai frame precedenti),
la seconda è la path coherence.
Pingali e Segen [22] propongono due metodi, presentando le metriche per la
misura delle cardinalità, la misura dell'accuratezza temporale e quella spaziale. Il
primo metodo richiede un'estesa disponibilità del GT, mentre il secondo metodo è
scalabile in base al dettaglio di questi. Per descrivere la locazione degli oggetti in
determinati istanti vengono utilizzati gli eventi.
Più eventi sono annotati, più il
ground truth è accurato. Gli autori hanno usato dei segmenti lineari per annotare
questi eventi sul set di video stabilito, tramite uno strumento dotato di interfaccia
graca.
Black, Ellis e Rosin [1] hanno proposto tre metriche per confrontare le traiettorie
degli oggetti del GT con quelle individuate dal sistema. La metrica path coherence
60
assume che la traiettoria dovrebbe essere omogenea alle condizioni di direzione
e moto.
La metrica color coherence misura la distanza media tra gli istogrammi
dell'oggetto tracciato.
tivi dell'immagine.
Si suppone che la distanza sia costante tra frame consecu-
Per lo più, la metrica shape coherence da un'indicazione del
bounding box atteso per quello oggetto, confrontato poi con i bounding box trovati.
Tramite queste tre metriche è possibile evitare l'utilizzo del GT, una volta assunte
determinate ipotesi.
Analizzando livelli semantici più alti (come la classicazione di oggetti e l'analisi
di comportamenti ed eventi), pare che la questione diventi più semplice per quanto
riguarda il confronto tra i risultati del sistema VCA e quelli del GT. Ancora però non
è chiaro come presentare i risultati delle performance. In più, non è chiaro neanche
come devono essere gestiti i periodi di tempo che si riferiscono alla classicazione
dei comportamenti.
Vari ricercatori hanno proposto metriche simili tra loro, più o meno accurate;
tra queste, una delle più dettagliate è quella proposta da Yin et al [23]. Yin parte
dal concetto di frame-based e passa a quello object-based pensando che TP, FP e
FN non vanno stimati in termini di campioni di frame, ma devono essere misurati
considerando le tracce (usando quindi il concetto di overlap temporale ) per essere
più completi e precisi.
Per le metriche introdotte da Yin, è necessaria una premessa sul motion tracking.
Il motion tracking è la stima della posizione e dell'estensione spaziale degli oggetti
che non appartengono allo sfondo per ogni frame di una sequenza video. Il risultato
del tracking è un set di tracce
Tj ,
con
j = 1 . . . M,
per tutti gli M oggetti in
movimento della scena.
Una traccia
Tj
è denita come:
Tj
= {
xij , Bij }, i = 1 . . . N ,
dove
xij
e
Bij
sono
rispettivamente il centro e l'estensione spaziale (solitamente denita come bounding
box e rappresentata da esso) dell'oggetto
j
per il frame
i
ed
N
è il numero di frame
totali.
Prima di tutto è importante denire i concetti di overlap (sovrapposizione) spaziale e temporale tra le tracce, i quali sono richiesti per quanticare il livello di
3.4 Object-Based
61
Figura 3.2: Overlap spaziale: intersezione e unione
matching (ovvero di corrispondenza) tra le tracce del Ground Truth (denito GT)
e quelle del Sistema (ST), sia nello spazio che nel tempo.
L'overlap spaziale è denito come il livello di sovrapposizione A(GTi ,
tracce
GTi
e
STj
in un frame specico
STj )
tra le
k.
T
Area(GTik STjk )
S
A(GTik , STjk ) =
Area(GTik STjk )
E' stata denita anche una variabile binaria
O(GTi , STj ),
basata su una soglia
Tov ,
impostata arbitrariamente.
(
O(GTik , STjk ) =
L'overlap temporale
T O(GTi , STj )
1
0
se
se
A(GTik , STjk ) > Tov
A(GTik , STjk ) ≤ Tov
è un valore che indica la sovrapposizione nel-
l'intervallo dei frame tra la traccia del sistema
(
T O(GTi , STj ) =
dove
T OS
j
e la traccia GT
i:
T OE − T OS , T OE > T OS
0, T OE ≤ T OS
è il massimo tra gli indici del primo frame delle due tracce, e
T OE
è
62
il minimo tra quelli dell'ultimo frame.
Come criterio per l'associazione spazio-temporale si utilizza la seguente condizione:
T
Length(Area(GTi STj )
S
> T Rov
Se questa condizione è vera, è possibile associare le due tracce utilizzate e iniziare
la valutazione delle performance della traccia di sistema.
Yin denisce i True Positive anche come Correct detected track (CDT) ed aerma che una traccia GT è stata correttamente trovata se sono soddisfatte due
condizioni:
1. L'overlap temporale tra la traccia
i
del GT e la traccia
j
del sistema è più
T Rov
T
≥ T Rov
Length(Area(GTi )
grande di un soglia predenita chiamata
2. Anche l'overlap spaziale tra la traccia
essere suciente
N
X
j
del sistema e quella
i
del GT deve
A(GTik , STjk )
k=1
N
≥ Tov
Gli errori di frammentazione sono considerati a parte; Se ogni traccia del GT è individuata correttamente (da una o più tracce del sistema), il numero di CDT equivale
al numero di tracce GT.
Sebbene per gli operatori umani sia facile riconoscere un falso allarme anche in
situazioni complesse, per un sistema automatico è molto più dicile.
I False Positive sono deniti anche come False Alarm Track (FAT) e si considera una traccia del sistema come falso allarme se quella traccia soddisfa almeno
una delle seguenti condizioni:
3.4 Object-Based
1. Una traccia
soglia
T Rov
63
j
del sistema non deve avere un overlap temporale più largo della
con qualunque traccia
i
del Ground Truth.
T
< T Rov
Length(Area(STj )
2. Anche se ha una sovrapposizione temporale con la traccia
j
i
del GT, la traccia
del sistema non deve aver alcun overlap spaziale con una delle tracce GT.
N
X
A(GTik , STjk )
k=1
N
< Tov
La metrica FAT è importante perché è indica all'operatore che sistemi in cui la false
alarm rate non è prossima allo zero non devono essere considerati ecaci, indipendentemente dalla performance relativa al TP.
I False Negative sono rideniti anche come Track Detection Failure (TDF) ; si ritiene che una traccia del GT non viene considerata se si verica almeno una delle
seguenti condizioni:
1. Una traccia
i
del GT non ha un overlap temporale più largo di
qualunque delle tracce
j
T Rov
con una
del sistema
T
< T Rov
Length(Area(GTi )
2. Una traccia
i del GT non ha un overlap spaziale suciente con nessuna traccia
del sistema (sebbene ne possa avere uno temporale)
N
X
A(GTik , STjk )
k=1
N
< Tov
Questa condizione è analoga alla seconda sui False Positive: è semplicemente
invertito il punto di vista.
L'overlap spaziale viene spesso denito controllando se il centroide della traccia
del sistema è all'interno dell'area della traccia del ground truth (come ad esempio
64
propone Bashir et al [24]). Varianti di questa denizione suggeriscono di considerare
non il 100% dell'area di quest'ultima traccia ma il 120%.
Oltre a ridenire le metriche classiche sotto il nuovo punto di vista delle tracce,
Yin aggiunge nuove misurazioni avanzate sul motion tracking.
La frammentazione delle tracce (Track Fragmentation, TF) viene introdotta da Yin
per indicare la mancanza di continuità di una traccia del sistema in riferimento ad
una traccia del GT.
Figura 3.3: Track Fragmentation
In condizioni ottimali, TF dovrebbe essere zero: ciò sta ad indicare che il sistema
riesce ad orire un tracking continuo e stabile rispetto al ground truth. Considerano
la possiblità di associazioni multiple tra le tracce del GT e quelle del sistema, la
frammentazione è misura dai risultati di corrispondenza delle tracce. Nell'esempio
riportato in g. 3.3 la traccia del sistema si interrompe due volte rispetto a quella
del ground truth: perciò TF è 2.
Per ottenerla, viene introdotta la metrica ID Change (IDC) che si propone di
contare il numero di cambiamenti di ID per ogni traccia
bounding box
Dj,k
dell'oggetto della traccia
del ground truth, dove
NDj,k
STj
STj .
Per ogni frame
può essere sovrapposto a
NDj,k
k,
il
aree
è dato da:
NDj,k =
X
O(Gik , Djk )
i
E' possibile stimare il numero totale di IDC in una sequenza video sommando i
j
IDC ottenuti grazie a singole associazioni e una determinata procedura.
Un'altra delle metriche introdotte da Yin è la latenza della traccia del sistema
(LT), che rappresenta il periodo temporale tra l'instante in cui un oggetto inizia ad
essere monitorato e la prima apparizione dell'oggetto.
La latenza ottimale ovvia-
mente dovrebbe essere zero; se invece è molto alta, signica che il sistema non è
3.4 Object-Based
65
Figura 3.4: ID Change
abbastanza sensibile da abilitare il tracking in tempo oppure che la detection non
è qualitativamente abbastanza elevata da innescare il tracking.
semplicemente come
LT =
frame iniziale di
STj −
La LT si calcola
frame iniziale di
GTi .
Anche la vicinanza della traccia (Closeness of Track (CT) ) viene considerata.
Essa è stimata come sequenza di overlap spaziali tra una traccia del sistema e la
traccia del GT associata a questa:
CT (GTi , STj ) = {A(GTi1 , STj1 ), . . . A(GTiN , STjN }
Da questa è possibile ricavare la vicinanza media e la deviazione standard su M
coppie per un'intera sequenza: esse sono rispettivamente denite CTM e CTD.
Oltre alla vicinanza anche la completezza della traccia (Completeness of Track (TC) )
viene analizzata: questa viene denita come il periodo di tempo in cui la traccia
del sistema si sovrappone temporalmente a quella del GT diviso il periodo di tempo
totale delle tracce GT. Una traccia risulta essere completa quando questo indice è
al 100%.
PN
TC =
O(GTik , STjk
number of GTi
k=1
Se per una traccia GT sono associate più tracce del sistema, si sceglie la traccia
con la maggior completezza; è poi possibile, analogamente alla vicinanza, ottenere
la completezza media (TCM) e la deviazione standard (TCD).
66
Inne, ricercando una metrica per l'accuratezza Yin introduce la Track Matching
Error (TME), che misura l'errore di posizione di una traccia del sistema.
Figura 3.5: Track Matching Error
N
X
T ME =
dove
Dist()
Dist(GT Cik , ST Cjk )
k=1
Length(GTi
T
STj )
è la distanza Euclidea tra il centroide della traccia GT (GTC) e quello
della traccia del sistema (STC). Yin ne denisce poi le versioni più complesse come
il Track Margin Error per l'intera sequenza (TMEMT) e la deviazione standard associata (TMEMTD).
Capitolo 4
Un sistema di video content analysis è la parte del framework (si veda la g. 4.1)
che si occupa di acquisire i dati dai video, elaborare i frame, individuare e seguire
gli oggetti in movimento grazie a diverse tecniche di visione articiale. E' la parte
che cerca di sostituirsi all'occhio umano nella scene undestanding, ovvero la comprensione della scena.
Figura 4.1: Visione d'insieme: VCA
67
68
Per identicare e riconoscere i comportamenti umani, le posture, o altri eventi
all'interno della sequenza il VCA utilizza a livello più alto algoritmi di classicazione
e analisi che sfruttano i risultati ottenuti al livello inferiore. Per valutare in modo
oggettivo la bontà di questi algoritmi è necessario acquisire l'output in un formato
comune al ground truth, con l'obiettivo nale di migliorare questi e il sistema che
vi ruota intorno.
4.1
Il sistema Sakbot
Il sistema di videosorveglianza su cui viene realizzata l'annotazione automatica è il
sistema Sakbot.
4.1.1 Descrizione del sistema
Sakbot (Statistic and Knowledge-based Object Tracker )[25] è un sistema di visione
articiale general-purpose che spazia dall'analisi del traco alla videosorveglianza,
sviluppato presso il laboratorio ImageLab [8] all'Università di Modena e Reggio
Emilia dal 2001. Questo sistema si occupa di compiere object detection e tracking
in situazioni complesse dove vi sono persone in movimento e veicoli, con dierenti
forme, velocità, traiettorie, presenza di strutture e possibili occlusioni.
Sakbot è quindi pensato per gestire diverse problematiche operazionali:
•
il cambiamento delle condizioni di luminosità a causa delle condizioni atmosferiche, delle ore del giorno e delle ombre;
•
i lievi ma frequenti movimenti della videocamera, dovuti alle vibrazioni e al
vento
•
i cambiamenti del background: il background della scena potrebbe cambiare
in base al fermarsi/ripartire di oggetti nella scena;
•
gli oggetti in movimento possono muoversi con qualsiasi traiettoria e velocità,
perciò non è possibile applicare l'approccio basato sulla frame dierence ,
metodo che calibra la dierenza sulla base della velocità dell'oggetto; allo
stesso tempo, non possono essere usati modelli di moto.
4.1 Il sistema Sakbot
69
Figura 4.2: Interfaccia graca di Sakbot
Per modellare una tecnica di background update veloce e robusta, è stato denito un approccio (chiamato S&KB background update) basato sull'adattamento
statistico del background, insieme con un aggiornamento del background selettivo e
knowlegde-based.
L'adattamento statistico fa i conti con l'apparente cambiamento della scena durante il tempo, mentre la selezione basata sulla conoscenza previene l'aggiornamento del background con i punti di foreground.
Grazie all'adattamento, il sistema riesce ad integrare oggetti che stazionano a
lungo (ad esempio, veicoli parcheggiati), o aree abbandonate da oggetti che prima
erano sullo sfondo; grazie alla selettività il sistema può discriminare oggetti con
movimento apparente da oggetti con movimento reale.
70
Figura 4.3: Object detection e tracking in Sakbot
4.1.2 Principali caratteristiche
Le principali caratteristiche di Sakbot sono:
•
l'uso delle informazioni sul colore (invece dei soli livelli di grigio) durante l'intero processo di individuazione degli oggetti in movimento, la cui sensibilità
viene migliorata;
•
l'utilizzo di una funzione mediana con adattamento assicura alta reattività ai cambiamenti del background e buona accuratezza, anche se vengono
considerati solo pochi frame;
•
l'inclusione del feedback basato sulla conoscenza è progettato in modo che
non includa nel background parti di oggetti in movimento. Questo aggiornamento selettivo, basato sulla conoscenza dell'intero oggetto e non solo del
singolo pixel, abbatte i falsi positivi e previene possibili situazioni di stallo
nell'aggiornamento;
•
lo sfruttamento del modulo di individuazione delle ombre (shadow detection )
per il miglioramento sia della segmentazione che dell'aggiornamento del background;
4.1 Il sistema Sakbot
•
71
la denizione di un set di regole essibili che lavorano sugli oggetti in movimento per orire tracking e classicazione applicabili a scenari dierenti.
Nel tempo, ulteriori sviluppi hanno portato all'implementazione di una parte
della scene understanding, tramite la classicazione degli oggetti e l'analisi e la
comprensione delle posture e delle facce nel caso delle persone, e della gestione di
più camere di diverse tipologie.
L'architettura di Sakbot è illustrata a grandi linee in g.
4.4.
Essa non verrà
esaminata oltre perché in questo progetto non è stata modicata, ma solo analizzata per fare da base all'obiettivo nale. L'implementazione di questo sistema sarà
descritta nel cap. 5.6.1.
72
Figura 4.4: Sakbot: architettura generale
Capitolo 5
Sakbot è il sistema di videosorveglianza su cui eettuare valutazioni delle prestazioni
degli algoritmi presenti e futuri: all'interno di esso è stata progettata e implementata l'architettura che si occupa di catturare, riorganizzare, trasformare ed esportare
l'output dei suddetti algoritmi, in modo tale che poi possa essere possibile confrontare il ground truth presente in ViSOR per un dato video con l'output appena
citato.
5.1
Gestione degli Eventi
Sakbot è composto da vari moduli, contenenti diverse classi, che interagiscono tra
loro in una gerarchia ben denita.
Per far comunicare gli oggetti generati dalle vari classi e soprattutto per permettere che le informazioni scalino la gerarchia ed arrivino no ai livelli superiori, si
utilizza un sistema di eventi parametrici che permette a chi li implementa di poter
mandare informazioni anche a chi non è visibile direttamente.
A livello di programmazione infatti ogni oggetto può passare parametri solo ad
oggetti che ha istanziato direttamente (ovvero gli) o che comunque discendono
da lui; non gli è possibile passare parametri all'oggetto da cui è stato istanziato
(padre).
La soluzione utilizzata in Sakbot prevede l'ausilio di classi che, sotto
opportuni accorgimenti, ricevano i parametri dall'oggetto interessato e li passino
alla classe che li cattura.
73
74
Nel sistema, un evento può corrispondere a qualunque cosa accada all'interno di
esso, dipendentemente dal contesto: l'apertura di un le, l'arrivo di un nuovo frame,
l'apparizione di un nuovo oggetto, etc...
Un evento quindi si tramuta in un messaggio inviato al gestore eventi. Sono
necessarie alcune condizioni perchè questo avvenga:
•
una classe che vuole generare un evento deve ereditare dalla classe base CE-
ventGenerator
•
la classe che cattura gli eventi deve derivare sia dalla classe CEventManager
che dalla classe CEventGenerator
Le classi CEventManager e CEventGenerator si occupano rispettivamente di
gestire e generare gli eventi tramite metodi appositamente deniti. Gli eventi possiedono un proprio identicatore (ID) e due parametri in cui vi risiedono i dati
passati.
I due parametri sono wParam, in cui come convenzione viene passato il
puntatore all'oggetto che ha generato l'evento e lParam, dove risiede un valore di
interesse dell'evento.
Le due funzioni principalmente utilizzate per la gestione degli eventi sono:
•
SendEvent(UINT idEvent, UINT wParam, UINT lParam) : metodo che permette la generazione di un evento
•
CaptureEvent (UINT idEvent, UINT wParam, UINT lParam) : metodo che
permette la cattura di un evento
I dati di interesse all'interno dei due parametri sono passati come UINT (unsigned
int) perchè non è possibile conoscere a priori (all'arrivo di un evento) la natura
di questi dati.
Spetterà allo sviluppatore eettuare il casting al tipo giusto per
riottenere i dati.
5.2
Da Sakbot a Visor
Per arrivare a comparare l'output del sistema con il ground truth di ViSOR per
un determinato video, è necessario compiere diversi passaggi, come estrapolare le
5.2 Da Sakbot a Visor
75
informazioni di Sakbot e riorganizzarle e catalogarle in modo tale che siano conformi
allo standard dell'ambiente utilizzato.
Come appena visto nel cap.
5.1, il modo più eciente per estrapolare il pro-
cessing di Sakbot è creare delle classi che si inseriscano in questo sottosistema
e catturino gli eventi mentre percorrono il sistema no alla radice. L'architettura
realizzata si inserisce quindi a anco della radice del sistema, in modo assolutamente trasparente, osservando e analizzando tutti i dati che passano all'interno degli
eventi, ottenuti facendo ereditare la classe dalle classi base CEventGenerator e CEventManager e utilizzando il metodo CaptureEvent(). Il punto in cui l'architettura
viene agganciata al sistema è illustrata in modo più dettagliato in g. 5.1.
Esaminando i contenuti nei cap. 2.4 e 4.1, appare evidente la profonda dierenza
che risiede nella struttura dei due sistemi.
5.2.1 Punto di vista temporale: Sakbot
Il video processing di Sakbot analizza il video frame per frame, e ad ogni frame
una lista di eventi viene generata (dipendentemente da cosa è accaduto):
•
l'apertura/chiusura di una sorgente video
•
l'inizio del processing
•
l'apparizione di una nuova traccia
•
l'arrivo di un nuovo frame
•
la lista di tracce presenti all'interno nel video in quel frame
•
...
Questi sono solo alcuni eventi che corrispondono ad avvenimenti accaduti all'interno del sistema. Nell'ottica di costruire l'architettura per questo progetto, è quindi
necessario che ad ogni frame si controllino questi eventi e si acquisiscano i dati di
interesse.
L'output di Sakbot è dunque completamente
temporale: il punto di
vista è calibrato sull'istante di tempo, invece di essere all'interno di un determinato
soggetto presente sulla scena video.
76
Figura 5.1: Trasparenza del modulo sviluppato rispetto al sistema
5.2.2 Punto di vista ad oggetti: Visor
In ViSOR la situazione è completamente diversa. Il punto di vista è centrato sugli
elementi. Ogni le di annotazione di ViSOR è rispetta il seguente schema:
•
File 1:
Oggetto 1 - framespan 1
∗
Attributo 1 - framespan - valore
1 periodo di tempo in cui è visibile, misurato in frame: da .. a ..
5.2 Da Sakbot a Visor
∗
∗
77
Attributo 2 - framespan
·
valore 1
·
valore 2
·
...
...
Oggetto 2 - framespan
...
•
File 2: ...
E' possibile riassumere l'idea che sta alla base delle annotazioni di ViSOR (e
di ViPER) denendola come una struttura a
le/oggetti. ViSOR si permette di
guardare le sorgenti video da un'ottica a posteriori, ovvero a conti fatti, cosa che
non è possibile in Sakbot, che per sua stessa natura aronta il processing frame per
frame.
5.2.3 Approcci possibili
Gli approcci possibili per creare questo passaggio intermedio sono essenzialmente
due:
•
approccio batch : si raccolgono tutte le informazioni che Sakbot genera mentre viene processato il video in oggetto. Le informazioni vengono elaborate e
riordinate solo in un successivo momento.
Vantaggi:
∗
alla fase di analisi da parte di Sakbot viene aggiunta un'unità che si
occupa solamente di salvare tutti gli eventi; il tempo impiegato nel
logging è irrilevante rispetto al processing;
∗
dopo l'analisi, si possiedono tutti i dati estratti dal processing: si
conoscono quindi a priori il numero di elementi e i valori, non è
necessario agire dinamicamente per riorganizzare l'esportazione;
∗
più semplice da implementare.
78
Svantaggi:
∗
è inevitabile un'ulteriore operazione di riorganizzazione/assemblaggio al termine del processing di Sakbot, che può richiedere molto
tempo, specialmente se quest'operazione viene eettuata leggendo
2
da le (con conseguenti costi di I/O );
∗
l'analisi da parte di Sakbot genera grosse moli di dati che vengono
salvati inutilmente, creando un'overhead superuo.
•
approccio on-the-y : si genera il le di esportazione al volo, ovvero durante
il processing di Sakbot.
Frame per frame gli eventi vengono riorganizzati e
catalogati in opportune strutture.
Vantaggi:
∗
nessuna ulteriore operazione dopo il processing video;
∗
vengono catturati e memorizzati soltanto i dati necessari, non vi sono
salvataggi inutili: il tutto è gestito dinamicamente senza allocazioni
superue.
Svantaggi:
∗
maggiori (ma accettabili) tempi di elaborazione a causa dei controlli e
dei confronti eettuati durante la riorganizzazione e la catalogazione
dei dati;
∗
maggiore complessità nell'implementazione.
Dopo averli valutati entrambi, si è scelto di applicare il secondo in quanto più
performante.
5.3
Descrizione della struttura creata
A questo punto, è da analizzare in quale struttura vengano salvati i dati. Questa
struttura non può che essere complessa, per via delle relazioni che intercorrono tra
le, descrittori, concetti (statici/dinamici) e stati.
Essa deve ovviamente rifarsi
all'ontologia presente in ViSOR, vista nel cap 2.4, poichè tutti i video annotati in
2 I/O: input/output
5.3 Descrizione della struttura creata
79
modalità manuale (ground truth), con cui fare il confronto diretto tramite appositi
strumenti, rispettano quest'ultima.
E' possibile avere una prima idea di come salvare i dati osservando la gura 5.2.
Figura 5.2: Prima idea della struttura dati
In questa, si può notare come per ogni le (sequenza video) esistano un numero
indenito di descrittori, ovvero soggetti apparsi sulla scena video; ognuno di questi
descrittori, a sua volta, oltre ad essere delineato da caratteristiche come il nome e
il proprio ID, presenta una serie di concetti che lo rappresentano. I concetti, come
visto nei capitoli precedenti, sono caratteristiche appartenenti al soggetto. Anche
questi, a seconda della loro natura (statica o dinamica), possiedono uno o più valori,
deniti come stati.
Lo schema in g. 5.2 è utile per avvicinarsi alla struttura realizzata, ma non
ne mostra a fondo le proprietà. Difatti, i descrittori sono classicati in varie cate3
gorie , possiedono un ID e informazioni aggiuntive; gli stati, inoltre, sono anch'essi
tipizzati in base al valore che deve essere salvato.
3 Si veda la tab. 2.1
80
La g. 5.3 pone invece maggiormente l'attenzione sull 'assetto e sull 'ossatura
della struttura dati da salvare, non presentando esempi (quali invece erano quelli in
g. 5.2).
Figura 5.3: Architettura dei dati
Essa parte dal punto di vista di un le, e rispetto alla gura precedente mette in
risalto gli attributi che i vari elementi hanno, come il nome, l'ID, ma soprattutto
il frame iniziale e quello nale in cui si presentano. Questo è valido per i descrittori
e per gli stati, perché per i primi indica in quale intervallo temporale (che ha come
unità di misura il frame) si sono presentati, mentre per gli stati indica in quali frame
hanno assunto quel determinato valore.
5.4 Caratteristiche dell'architettura
81
Sempre dallo schema 5.3 si evince come tutti i tipi di descrittori presentano
liste di concetti, e quindi occorre astrarre una superclasse padre (d'ora in poi
denita classe astratta ) che li rappresenti e ne accomuni le proprietà, come avviene
ad esempio per l'oggetto Descriptor Base.
Le classi dei descrittori erediteranno
dunque le caratteristiche comuni da quest'ultimo.
5.4
Caratteristiche dell'architettura
Una volta salvati, è necessario preoccuparsi di come esportare i dati. La presenza
di una struttura abbastanza complessa, composta da liste di elementi dalle carat4
teristiche diverse anche all'interno della propria macroclasse
ha obbligato l'attenta
pianicazione dell'attività di esportazione.
L'architettura è stata costruita in modo tale che:
•
sia facilmente scalabile ed espandibile : l'ontologia di ViSOR viene arricchita
continuamente dalla comunità di nuove categorie e tipi. Essa non deve essere
quindi assemblata in modo chiuso, ma deve essere possibile includere questi
nuovi tipi in tempi rapidi. In quest'ottica, l'utilizzo di classi astratte permette
di mantenere la stessa struttura in caso di espansione: sono da denire solo le
particolarità della nuova classe, dato che il resto viene ereditato dalla propria
classe astratta;
•
l'esportazione non preveda una chiusura rispetto al formato (XML, testo, etc)
e non dipenda da esso in modo stretto; in altre parole, denito l'approccio per
l'esportazione, questo è implementabile per qualunque nuovo formato;
•
l'esportazione sia isolata livello per livello : ogni livello si occupa di estrarre
e controllare i dati delegando la richiesta ai livelli inferiori e consegnando il
risultato al livello superiore.
Ciò permette, rispetto ad un controllo centra-
lizzato, di non sapere quali e quanti dati sono da estrarre, il che risulterebbe
essere un grosso problema dato il numero dei livelli presenti e la complessità conseguente; il linguaggio di programmazione utilizzato (C++) fornisce a
4 i descrittori possono essere di tipo Person, BodyPart etc..; gli stati possono essere string,
double...
82
questo proposito le potenti funzionalità del polimorsmo e dell'ereditarietà.
L'approccio seguito può essere quindi denito esportazione a catena .
Ulteriori caratteristiche (minori) sviluppate sono:
•
5
il download online del cong schema , in modo da averlo sempre costantemente
aggiornato, di pari passo con le evoluzioni della comunità;
•
l'eventuale fusione di più valori presenti in frame diversi: siccome la cattura
dei dati viene fatta al volo, può capitare che, in un concetto dinamico, stati
consecutivi aventi valori uguali vengano inseriti nella lista in modo separato. Il sistema realizzato provvede al controllo e alla risoluzione di questi casi
accorpando i due stati in oggetto; il tutto viene realizzato con il già citato
principio del polimorsmo, evitando così di preoccuparsi della varietà di tipi
di dato presenti.
5.5
Esempi di applicazione
Ma quali sono gli elementi di Sakbot che si vogliono serializzare per il confronto
con il ground truth di ViSOR? E a che livello? Ora verranno descritte le applicazioni
pratiche di esempio realizzate per vericare e mostrare l'utilizzo della struttura.
5.5.1 Baricentro e bounding box
Essenzialmente, l'architettura sviluppata è stata edicata appositamente per essere
general-purpose verso gli elementi da esportare: si può esportare direttamente la
segmentazione generata dai rispettivi algoritmi (quindi a livello pixel-based, vedi
sez. 3.2), il tracking ed object detection (passando quindi al frame-based, con una
particolare attenzione sulle tracce, vedi 3.3), arrivando anche alla valutazione di
comportamenti e classicazione (object-based, vedi 3.4). La nozione fondamentale
nello sviluppo e nella progettazione di questa libreria è appunto la libertà di inserire
nella struttura i dati di qualsiasi tipo e origine, in modo da permettere anche in
futuro di utilizzarla per la valutazione delle prestazioni con nuovi algoritmi.
5 http://imagelab.ing.unimo.it/visor/Downloads
5.5 Esempi di applicazione
83
Figura 5.4: Bounding box
Come base per testare l'architettura appena presentata e darne un esempio di
utilizzo concreto, è stata creata l'annotazione automatica di oggetti appartenenti al
tipo di descrittore denito come Person, e sono stati creati più concetti associati
(sia statici che dinamici):
•
l'attributo CR_Person (statico), che nel caso di un descrittore Person dovrebbe essere per forza salvato con valore 1;
•
il baricentro dell'istanza del descrittore, con nome PositionBar (dinamico):
esso, le cui coordinate derivano dal rapporto dei momenti del primo ordine
rispetto all'area (che altro non è che il momento di ordine 0), ci da' un'indicazione signicativa e identicativa del soggetto.
E' di solito la proprietà
più utilizzata quando si fa riferimento a metriche di tipo point, su cui le
prestazioni vengono valutate tramite opportune distanze;
•
il bounding box dell'istanza del descrittore, con nome Position_BBOX (dinamico): è il rettangolo minimo (non orientato) che circonda il soggetto. E' uno
degli approcci più utilizzati per la valutazione delle prestazioni, dato che spesso il processo di creazione del ground truth di questi è relativamente semplice
e può essere ottenuto anche tramite predizioni lineari del moto tra frame. Il
6
bounding box rappresenta il trade-o tra la valutazione di un semplice punto ,
6 Come già accennato, spesso questo punto è il centroide/baricentro dell'oggetto.
84
troppo povera per dare informazioni adeguate sulla precisione dell'algoritmo,
e la valutazione dell'intera immagine bitmap che, anche se fornisce risultati
accurati sulla qualità della segmentazione (di meglio non si può), rappresenta un lavoro disumano in termini di tempo e di impegno per l'annotazione
7
ground truth ).
5.5.2 Un buon compromesso: l'ellisse
Anche se il bounding box rappresenta un'ottimo compromesso, che permette al ricercatore di comprendere attraverso la valutazione delle prestazioni se i propri algoritmi
sono ecienti o meno (grazie agli indici visti al cap. ), analizzando attentamente
il problema si è notato che con il medesimo sforzo è possibile ottenere maggiore
accuratezza. Ma come?
Il principale difetto del bounding box è che non è orientato:
nel caso in cui
l'asse del soggetto sia in posizione verticale od orizzontale, il soggetto stesso è rappresentato con buona approssimazione, ma se l'oggetto ha un asse con una certa
inclinazione, non solo l'approssimazione diventa eccessiva, ma il risultato può essere
fuorviante.
Si è pensato quindi di orientare il bounding box, ovvero di catturare al suo
posto il rettangolo minimo orientato come l'oggetto: facendo così è possibile ottenere
approssimazioni più o meno costanti e più precise sul soggetto. Un ulteriore passo
nell'approssimazione può poi essere eettuato sostituendo al bounding box orientato
8
(che d'ora in poi verrà denito come oriented box ) l'ellisse corrispondente , avente
come angolo lo stesso dell'oriented box e come assi i lati di quest'ultimo passanti
per il centro dell'ellisse.
La metrica dell'ellisse non è implementata in Sakbot, a dierenza del bounding box e del centroide; essa è stata implementata durante il progetto attraverso i
momenti, partendo dalla mask image
9
fornita da Sakbot.
7 Annotare l'immagine bitmap signica contrassegnare ogni punto di ogni oggetto per ogni
frame.
8 Si veda l'appendice A.
9 Ovvero l'insieme di punti che costituisce l'oggetto all'interno dell'immagine video binarizzata.
5.6 Implementazione
85
Figura 5.5: Ellisse
5.6
Implementazione
La costruzione delle annotazioni automatiche prevede l'implementazione di una libreria dedicata ad esse all'interno del sistema Sakbot. E' quindi necessario capire
ed esplorare a fondo l'implementazione del sistema stesso.
5.6.1 Dettagli implementativi di Sakbot
Sakbot è stato sviluppato in Visual C++ ed ha una struttura completamente modulare, in modo che sia possibile espanderlo per ogni nuova caratteristica che si intende
implementare; nel corso degli anni il software del sistema è cresciuto in modo considerevole, raggiungendo allo stato attuale la presenza di 19 moduli per l'elaborazione
video e di migliaia di righe di codice eettivo. Ogni modulo varia la sua complessità
in base alla funzione:
•
Domotica: è il modulo principale, da cui parte l'esecuzione di Sakbot.
•
SingleCameraProcessing: acquisizione e gestione delle videocamere.
•
SakbotLib: classicazione dopo l'object detection e tracking.
•
ImageLib: gestione della segmentazione, dell'object detection e del tracking; è
il vero core di Sakbot.
86
•
GraphicLib: gestione dell'interfaccia graca.
•
HandoLib: gestione multicamera.
•
PersonLib: analisi delle posture e del comportamento delle persone.
•
UtilityLib: set di classi che servono gli altri moduli in operazioni comuni.
•
GeometricLib: calibrazione e utilizzo della geometria all'interno del sistema.
•
FaceRecognition: riconoscimento dei volti.
•
OpenCVSupport: supporto delle librerie grache OpenCV di Intel
•
TrackerProbab/AdHocTracker:
10
analisi probabilistica delle traettorie e degli
oggetti
Per citare solo i moduli principali. Ogni modulo contiene determinate classi, che
interagiscono tra loro in una gerarchia ben denita e comunicano tramite eventi (si
veda in 5.1).
5.6.2 Modulo realizzato
Per implementare l'architettura vista in 5.3 è stata creata una libreria (sempre in
C++ un-managed ) a parte all'interno di Sakbot, denita come AnnotationLib.
I le che lo compongono e che ne rappresentano le classi sono:
•
Header
AnnotationExport.h
ListOfFiles.h
ListOfDescriptors.h
concepts.h
descriptors.h
states.h
10 http://www.intel.com/technology/computing/opencv/
5.6 Implementazione
•
87
source:
AnnotationExport.cpp
A questi vanno aggiunte le risorse utilizzate per l'esportazione di alberi XML
tramite la libreria open source TinyXML (si veda 5.6.6). Il le AnnotationExport (e
l'oggetto associato) rappresentano il cuore della riorganizzazione e dell'esportazione
delle annotazioni; l'oggetto in questione possiede una lista di le (video), ovvero
un'oggetto della classe ListOfFiles, i quali a loro volta hanno una lista di descrittori
(ListOfDescriptors ).
Gli elementi che costituiscono l'architettura sono implementati rispettivamente
nei le corrispondenti (descriptors.h, concepts.h, states.h ), mentre i le sono descritti
dalla classe ProcessedFile all'interno del le ListOfFiles.h.
5.6.3 Interfaccia graca
La libreria è stata implementata all'interno di Sakbot, perciò integra con il sistema
stesso le possibili interazioni e preferenze dell'utente.
In particolare, in gura 5.6 è possibile osservare come l'utente possa decidere
(attraverso le preferenze) se abilitare o meno le annotazioni e possa cambiare i percorsi che riguardano il salvataggio di queste ultime per ogni formato implementato
(ViPER-XML e testo). Inne vi è anche la possibilità di cambiare l'url da cui scaricare la parte di cong per l'esportazione. Se il le di cong non è raggiungibile, se
ne carica automaticamente uno presente in locale.
88
Figura 5.6: Interfaccia graca: preferenze
Figura 5.7: Interfaccia graca: salvataggio dati
5.6 Implementazione
89
In g. 5.7 è invece possibile salvare le annotazioni in qualunque momento in uno
dei formati disponibili e per tutti i le processati. Il salvataggio fa partire la catena
di esportazione.
5.6.4 Classi astratte: ereditarietà e polimorsmo
Come accennato precedentemente, perchè si possa costruire una struttura che riesca a delegare i propri compiti ai sudditi (evitando cosi il controllo centralizzato), è
necessario plasmare delle superclassi, o classi astratte, che possiedano le caratteristiche comuni dei vari tipi di quella categoria e permettano comportamenti diversi
in risposta alla stessa richiesta, sulla base del tipo di oggetto interrogato.
Le classi astratte implementate sfruttano i meccanismi di ereditarietà e polimorsmo presenti in C++.
Ereditarietà
L'ereditarietà ha una forte presenza nel mondo reale ed è pure una caratteristica
naturale del pensiero ogni concetto complesso non si crea ex-novo, ma deriva da
concetti più semplici, che vengono ereditati e integrati con ulteriori approfondimenti. Gli oggetti possono assumere, per eredità, le caratteristiche di altri oggetti
e aggiungere caratteristiche proprie, esattamente come avviene nell'evoluzione del
processo conoscitivo.
Polimorsmo
Il polimorsmo è più complicato e meno intuitivo dell'ereditarietà: esso rappresenta
la possibilità di mandare agli oggetti lo stesso messaggio ed ottenere da essi comportamenti diversi, sul modello della vita reale, in cui termini simili determinano
azioni diverse, in base al contesto in cui vengono utilizzati. Letteralmente, la parola polimorsmo indica la possibilità per uno stesso oggetto di assumere più forme;
in un software ad oggetti, esso indicherà l'attitudine di un oggetto a mostrare più
implementazioni per una singola funzionalità.
90
Per rendere l'idea più chiara, utilizzando ancora una volta un esempio del mondo reale, si pensi al diverso comportamento che assumono un uomo, una scimmia
e un canguro quando eseguono l'azione del camminare. L'uomo camminerà in modo eretto, la scimmia in maniera decisamente più goa e curva mentre il canguro
interpreterà tale azione saltellando.
Figura 5.8: Esempio di polimorsmo
Per fare un esempio di utilizzo in un linguaggio di programmazione ad oggetti, si
presuma di voler disegnare delle gure geometriche. Per tale sistema è stata denita
una classe padre chiamata Shape dalla quale avremo fatto derivare tutte le classi
che si occupano della gestione di una gura geometrica ben precisa. Quando verrà
richiamato il metodo draw() per disegnare una linea, un cerchio o un rettangolo, il
sistema sarà in grado di capire autonomamente quale gura geometrica debba essere
disegnata, lasciando alla classe padre Shape il compito di invocare il metodo della
classe glia chiamata in causa.
In un linguaggio non ad oggetti un simile comportamento necessiterebbe, dal
punto di vista del codice, di un costrutto tipo switch-case.
Quindi, questa tecnica è sviluppata tramite funzioni-membro con lo stesso nome e gli stessi argomenti, ma appartenenti a oggetti di classi diverse; si basa sul
processo di late binding (aggancio ritardato): gli indirizzi delle funzioni da chiamare non vengono risolti al momento della compilazione, come avviene normalmente
(early binding ), ma al momento dell'esecuzione, perché solo in quella fase il C++
può conoscere la funzione selezionata, in base ai dati che condizionano il usso del
programma.
5.6 Implementazione
91
Ma come si realizza in termini pratici questo polimorsmo?
Si utilizza uno specicatore da anteporre alla funzione interessa: grazie alla specica virtual, il C++ rinvia la scelta della funzione appropriata alla fase di esecuzione
(late binding).
Una classe base, se denita con funzioni virtuali, spiega cosa sono in grado di
fare gli oggetti delle sue classi derivate.
Estremizzando questo concetto, si può creare una classe base con funzioni virtuali senza codice, dette funzioni virtuali pure. Non avendo codice, queste funzioni
servono solo da schema di comportamento per le classi derivate e vanno dichiarate
nel seguente modo: virtual void draw() = 0;.
A dierenza delle normali funzioni virtuali, le funzioni virtuali pure devono essere
ridenite tutte nelle classi derivate (anche con corpo nullo, quando non servono).
Se una classe derivata non ridenisce anche una sola funzione virtuale pura della
classe base, rimane una classe astratta e non può ancora essere istanziata (a questo
punto, una sua eventuale classe derivata, per diventare concreta, è suciente che
ridenisca l'unica funzione virtuale pura rimasta).
Le classi astratte sono di importanza fondamentale nella programmazione in
C++ ad alto livello, orientata a oggetti. Esse presentano agli utenti delle interfacce
pure , senza il vincolo degli aspetti implementativi, che sono invece forniti dalle loro
classi derivate. Una gerarchia di classi, che deriva da una o più classi astratte, può
essere costruita in modo incrementale, nel senso di permettere il ranamento
di un progetto, aggiungendo via via nuove classi senza la necessità di modicare
la parte preesistente. Agli utenti questo ranamento incrementale è totalmente
trasparente, in quanto vedono sempre la stessa interfaccia e utilizzano sempre le
stesse funzioni (che, grazie al polimorsmo, saranno sempre selezionate sull'oggetto
appropriato).
5.6.5 Utilità del polimorsmo all'interno dell'architettura
Grazie a queste proprietà è stato possibile implementare i diversi tipi di descrittori
e stati in una struttura che permette una certa indipendenza dal numero di ti-
92
pi inseriti e dall'inserimento di nuovi.
Queste classi astratte (CDescriptor_Base,
CConcept_Base, CConcept_State_Base ), presenti nei rispettivi le, sono a capo
dei vari tipi presenti nell'ontologia di ViSOR, con funzioni sia di ereditarietà che di
polimorsmo.
E' comodo inserire in una lista di puntatori di tipo CConcept_State_Base tutti
i vari tipi di stato (bool, oat, etc. . . ) senza preoccuparsi di creare liste separate
per ognuno dei tipi. Ma qual'è il problema principale nell'adottare questa tecnica,
che sfrutta appieno l'ereditarietà?
Una volta inseriti nella lista di puntatori, questi stati (in realtà gli della classe
CConcept_State_Base, non direttamente istanziati) non hanno più visibilità come
propri tipi, ma occupano lo spazio riservato alla classe padre. Nel momento in cui
è necessario, ad esempio, scrivere su un le le informazioni racchiuse in questi stati,
bisogna conoscere a quale sottoclasse appartengono, poichè essendo stati inseriti in
una lista di puntatori di stati generici, non si può conoscere se si ha da scrivere
un int o un'array di char.
Occorrerebbe quindi eettuare (conoscendolo a priori)
ilcasting al tipo di stato, per scrivere su le correttamente.
La tal condizione, in un contesto complesso e in continua evoluzione, può essere veramente proibitiva per lo sviluppo. E' impensabile procedere controllando
manualmente e riaggiustando gli elementi ogni qualvolta vengono estratti dalle
liste: anzi, spesso non è aatto possibile, a causa dell'eterogeneità creatasi durante
l'inserimento in una di queste.
Ergo l'ereditarietà, se concepita come unica soluzione, risolve il problema della
scalabilità e dell'espansione dei tipi (non sarà necessario allocare una lista per ogni
tipo di elemento) ma, d'altro canto, crea complicazioni non indierenti nel recupero
degli oggetti per operazioni speciche.
Tale complicazione viene poi gestita dal
poliformismo.
5.6.6 Libreria TinyXML
ViSOR utilizza la sintassi di ViPER, che come si è visto è composta da schema
strutturali deniti in XML.
Per agevolare la programmazione e l'esportazione degli elementi acquisiti si è
5.6 Implementazione
93
scelto di utilizzare una libreria al ne di una formattazione corretta in questo metalinguaggio. Anche se vi era la possibilità di realizzare la scrittura in XML from scrat-
ch (ovvero iniziando da zero), la decisione di astrarre quest'operazione di ulteriore
strato è da vedere in un'ottica di maggior consistenza, chiarezza e riusabilità.
La libreria utilizzata si chiama
TinyXML. TinyXML è un semplice e piccolo
parser XML scritto in C++ che può essere facilmente integrato all'interno di altri
programmi; è rilasciato con licenza open source.
In poche parole, TinyXML codica/decodica un documento XML, e costruisce
da quello un Document Object Model (DOM) : i dati XML possono essere codicati/decodicati in oggetti C++ che possono essere letti e modicati, e poi scritti su
disco o su un altro usso output.
Inoltre, si possono creare documenti XML dal
nulla grazie agli oggetti C++ presenti nella libreria.
Figura 5.9: TinyXML
Nella gura 5.9 è presentata la gerarchia degli oggetti che TinyXML ore.
A seconda delle operazioni che si vogliono svolgere è possibile generare la struttura da le o istanziare un oggetto TiXMLDocument, a cui agganciare una
TiXMLDeclaration e vari TiXMLElement ; a loro volta, a questi potranno esserne
agganciati altri, per creare l'albero DOM. In più TinyXML permette la gestione
degli attributi tramite l'oggetto TiXMLAttribute e quella dei commenti e del testo
tramite gli oggetti TiXMLComment e TiXMLText. Per eventuali estensioni si può
utilizzare l'oggetto TiXMLUnknown.
Questi oggetti prevedono il completo controllo per la navigazione dell'albero, sia
in maniera verticale (parent-child ) che in maniera orizzontale (sibilings ), orendo
opportuni metodi per gestirli.
94
5.6.7 Acquisizione e riorganizzazione logistica dei dati
La prima fase necessaria per la creazione delle annotazioni è la cattura e il salvataggio
dei dati nella struttura vista precedentemente.
Risposte agli eventi
Questa fase viene realizzata all'interno del le principale del modulo creato, Anno-
tationExport. Si è già visto come la classe AnnotationExport, aancata in modo
trasparente ad uno dei moduli alla radice Sakbot, per catturare gli eventi debba
ereditare i metodi necessari dalla classe CEventManager e CEventGenerator, denite con la classe CObjWithEvents. Da essa viene ereditato il metodo CaptureEvent
(UINT idEvent, UINT wParam, UINT lParam) (si veda in 5.1): il metodo grazie
al quale è possibile salvarsi tutte le informazioni che riguardano il processing video.
I principali eventi catturati dal metodo sopracitato sono:
•
EVENT_VS_OPEN : segnala l'apertura di una VideoSource
•
EVENT_VS_UPDATE : segnala l'aggiornamento dei dati di una VideoSource
•
EVENT_VS_NEWFRAME : indica l'arrivo di un nuovo frame
•
EVENT_TR_NEW_TRK : indica che una nuova traccia (un nuovo soggetto)
è entrato nella scena
•
EVENT_TR_LSTTRACKS_UPD : contiene l'aggiornamento di tutte le tracce al frame corrente
In risposta a questi eventi, per ognuno di essi, vengono eettuate determinate operazioni atte a raccogliere e immagazzinare in modo corretto i dati riorganizzandoli e catalogandoli man mano che arrivano.
Una volta svolta l'operazio-
ne scatenata da un evento, l'oggetto AnnotationExport si occupa di rigirare
l'evento al suo parent, di modo che quest'ultimo possa continuare la catena degli eventi e non si accorga dell'oggetto dell'annotazione, semplicemente ritornando
m_pObjWithEventParent->CaptureEvent(iEvent, wParam, lParam).
5.6 Implementazione
95
Una volta catturato l'evento VS_OPEN, si acquisisce il wParam corrispondente
tramite un'opportuno cast, poi si procede alla creazione di un nuovo le associato
alla VideoSource, aggiornando la lista di les. A questo punto si associa la lista di
descrittori corrente con la lista di descrittori del le (tramite copia di puntatori) e
si attendono ulteriori eventi riguardanti il le associato.
Il VS_UPDATE serve per aggiornare alcuni dati che riguardano la sorgente
video, ovvero il le. Infatti, quando viene inviato l'evento di apertura della Video-
Source, non tutti i dati (come ad esempio il nome del le) sono stati già inizializzati.
Essi vengono salvati successivamente: il fatto in sé non crea problemi in presenza di
una singola sorgente, dato che il wParam acquisito è un puntatore; se fosse inviata
come copia, i valori non verrebbero aggiornati, cosa che invece accade possedendo
l'indirizzo. L'evento VS_UPDATE è stato creato appositamente per questo motivo.
All'ingresso di un nuovo soggetto all'interno della scena viene inviato l'evento
TR_NEW_TRK : sebbene esso non sia strettamente necessario (potrebbe essere incluso nell'evento che contiene la lista delle tracce), permette una suddivisione delle
operazioni che rende la comprensione globale più chiara. Nel lParam è contenuto
l'oggetto Track, che contiene tutte le informazioni sulla traccia; dopo averlo acquisito, si crea il descrittore corrispondente e i concetti che si intende associarli.
Successivamente, gli stessi concetti vengono agganciati al descrittore inserendoli
nella sua lista di concetti, e il descrittore a sua volta viene inserito nella rispettiva
lista del le corrente.
L'evento TR_LSTTRACKS_UPD è l'evento più importante e la principale fonte di dati per l'annotazione sugli oggetti a livello di frame.
Acquisita la lista di
tracce dal parametro tramite casting,
CPointerList<CTrack> plstTracks = (CPointerList<CTrack> *) lParam;
si procede nel seguente modo:
•
si inizia a scorrere la lista di tracce; per ogni traccia
si scorre la lista di descrittori; per ogni traccia
IDi = IDj
e se la traccia
i
è visibile:
i − esima:
j − esima,
se è vericata
96
∗
si aggiorna il descrittore con il nuovo FrameEnd, ovvero l'ultimo
frame in cui è presente
∗
si calcolano i momenti
11
e le operazioni utili ad ottenere l'ellisse (che
è rappresentata da un concetto)
∗
si creano gli stati in base a cosa ed a quale tipo si intende salvare
∗
si recuperano i concetti del descrittore e si aggiorna il loro stato
Stati consecutivi che presentano lo stesso valore
L'aggiornamento dello stato dei concetti, come si è visto, avviene tramite l'aggiunta
degli stati al concetto in questione. Infatti, i concetti possono essere statici o dinamici: nel primo caso possiederanno un solo valore (quindi un solo stato), mentre nel
secondo caso una lista di valori (perché il concetto cambia questi valori nel tempo).
Può capitare quindi che in questa lista vi siano valori consecutivi uguali (ad
esempio, sia al frame
i
che al frame
i+1
il valore è
k ).
L'oggetto che rappresenta
uno stato è stato creato in modo da avere un framespan (ovvero un intervallo di
tempo in frame, partendo dal frame FrameStart no al FrameEnd ) e un valore; di
norma, l'intervallo degli stati è di un frame, perché i valori del concetto nel tempo
sono cambiati (infatti spesso questo accade a causa dei soggetti in movimento), ma
si possono presentare casi in cui l'intervallo è maggiore.
Siccome l'acquisizione e la riorganizzazione avviene in tempo reale, ovvero mentre avviene il processing, non è possibile sapere a priori quali stati presenteranno
valori uguali. Ad ogni frame è quindi necessario controllare se, per ogni concetto, lo
stato immediatamente precedente in termini di tempo contiene lo stesso valore: se
eettivamente è lo stesso, al frame
i non viene creato un nuovo stato con framespan
[i:i], ma viene aggiornato il framespan dello stato precedente (che ha quindi Frame-
Start
i − 1).
Il nuovo framespan sarà quindi [i
− 1:i].
Successivamente, se il valore
è ancora lo stesso, potrà essere di nuovo aggiornato.
Il controllo avviene in modo automatico da parte dello stesso stato, tramite il
polimorsmo.
11 I momenti si calcolano sull'
AlphaPlane
della traccia, che è una maschera binaria che rap-
presenta l'oggetto e la cui origine è denita come il pixel più in alto e più a sinistra di
questi.
5.6 Implementazione
97
Una volta che un concetto richiama il metodo SetState(CConcept_State_Base
* pState,int iFrame), questi richiede il controllo del valore dell'ultimo stato tramite il metodo CheckLastStateValue(CConcept_State_Base * pState), che restituisce
un valore booleano. Questa funzione è dichiarata virtual nella classe astratta Concept_State_Base: quando viene richiamata, essa passa il controllo alla sottoclasse
specica che si occuperà di controllare nel modo opportuno l'uguaglianza dei valori.
Ad esempio, se il controllo riguarda il confronto di due double, essa consisterà in
una semplice uguaglianza; al contrario, se riguarda l'ellisse, l'operazione sarà un po'
più complicata. Anche se queste operazioni sono dierenti da tipo a tipo (e quindi
da sottoclasse a sottoclasse), con lo stesso metodo è possibile invocare la modalità
appropriata al momento giusto.
5.6.8 Esportazione dei dati
La fase di esportazione sfrutta al massimo i concetti di polimorsmo ed ereditarietà per assumere la completa indipendenza nella gestione delle liste da esportare.
L'esportazione attualmente può avvenire in due modi: schema XML (conforme all'ontologia di ViSOR) e in testo semplice, per una maggiore leggibilità in fase di
test. Per ogni tipo di esportazione viene denito un metodo, come ad esempio Ex-
portToTxt() per il formato testo. Isolando i metodi in base ai formati, è possibile
aggiungerne altri creando i metodi associati; se il sistema fosse realizzato in un'unica
funzione che si occupa dell'esportazione, l'adattabilità sarebbe molto minore.
Inoltre, ribadendo che l'ontologia di ViSOR è in continua evoluzione, l'aggiunta
di nuovi descrittori, concetti e stati deve essere trasparente all'esportazione. Delegando tramite il polimorsmo le operazioni di esportazione direttamente all'interno
della classe dell'elemento è perciò possibile delegare all'elemento i compiti da svolgere quando vi è una richiesta di recupero dati. In tal modo, all'aggiunta di un
elemento occorre denire come dovrà comportarsi in caso di richieste di esportazione. Un'unità esterna che controlla i tipi ed eettua le conversioni dei vari stati
rappresenterebbe un collo di bottiglia in cui viene creata confusione e in cui vi è il
rischio di inconsistenza; quest'approccio, invece, è più distribuito ed ore maggior
chiarezza e riusabilità.
98
In gura 5.10 e 5.11 sono rappresentate le operazioni svolte nel sistema durante
la fase di esportazione.
Nella prima parte (g. 5.10), viene creato il documento TinyXML che si occuperà
di contenere l'albero XML da stampare su le; successivamente, viene scaricato il
le di congurazione dello schema strutturale dal sito di ViSOR.
A questo punto l 'header del le XML viene generato:
si eettua il parsing
del cong online, si aggancia la parte iniziale (che prevede alcune informazioni sul
formato e dei commenti) e la parte di cong al documento TinyXML, che rappresenta
la radice dell'albero.
L'esportazione quindi inizia a scorrere le liste in modo ricorsivo su vari livelli,
per il recupero delle informazioni; le liste, come si è visto, sono del tipo Descriptor
Base, Concept Base e State Base : sono fatte per contenere elementi comuni, ma
che presentano caratteristiche dierenti. Non è possibile estrarre da queste liste i
reali sottotipi per riuscire a conoscere in che modo esportare i dati; piuttosto, gli
elementi Base fanno da ponte ai veri elementi che dovranno essere esportati, grazie
ai metodi virtual() (e quindi al polimorsmo).
Nella seconda parte (g. 5.11) i risultati delle esportazioni risalgono l'albero
sotto forma di elementi TinyXML corrispondenti ai rispettivi componenti; questi
elementi vengono agganciati al loro elemento padre no ad arrivare alla radice.
Il le XML viene quindi salvato su le percorrendo l'albero completo appena
costruito.
5.6 Implementazione
Figura 5.10: Esportazione dei dati nel formato di ViSOR (I
99
◦
parte)
100
Figura 5.11: Esportazione dei dati nel formato di ViSOR (II
◦
parte)
5.7 Risultati sperimentali
5.7
101
Risultati sperimentali
Da vari test eettuati, si deduce che l'implementazione dell'architettura non incide
signicativamente sui tempi e sull'utilizzo di memoria del sistema Sakbot.
L'aumento del tempo di elaborazione con il modulo delle annotazioni attivato è
minore dell'1%; la scelta di un approccio ``on-the-y ha permesso di salvare solo ed
esclusivamente i dati necessari per l'esportazione, evitando così l'overhead presente
con l'altro approccio e quindi i tempi di processing.
L'utilizzo di memoria è incrementato di circa il 4%, poichè la mole di dati da
salvare è comunque notevole, soprattutto in video che presentano scene aollate.
Nonostante questo, la memoria si mantiene pressochè costante, poichè si è posta una
particolare attenzione alla gestione della memoria e all'individuazione di eventuali
sprechi; come è ben noto, il linguaggio C++ non possiede garbage collector :
la
liberazione della memoria allocata attraverso i puntatori spetta allo sviluppatore.
Per quanto riguarda l'esportazione, il tempo necessario per eettuarla è fortemente inuenzato dall'operazione I/O di scrittura su le dell'annotazione, ma nonostante questo non prevede più del 2% del tempo totale che occorre per ottenere
il risultato perseguito.
102
Capitolo 6
Un esempio di valutazione con
ViPER-PE
In questo capitolo si vedrà in modo pratico come è possibile ottenere misurazioni oggettive sulla qualità degli algoritmi del sistema grazie al formato di annotazione e all'architettura realizzata. Nell'ambiente ViSOR, quindi, questa parte è rappresentata
dalla valutazione obiettiva e dalla visualizzazione dei risultati (g. 6.1).
Figura 6.1: Visione d'insieme: valutazione e presentazione
103
104
6.1
ViPER-PE: descrizione ed obiettivi
Il toolkit ViPER, oltre a fornire uno strumento per annotare manualmente il ground
truth dotato di interfaccia graca (ViPER-GT, si veda 2.5), include anche un un
altro applicativo utile alla valutazione: ViPER-PE. Come è possibile dedurre anche dal nome, l'obiettivo di questo software è di eettuare la valutazione tra due
annotazioni create in conformità con il formato di ViPER.
La valutazione eettuata utilizzando ViPER-PE consiste nel misurare quanto un
le di target
1
(tipicamente il le contenente i metadati del ground truth) e un le di
candidate (tipicamente contenente i dati provenienti da un'elaborazione automatica)
siano simili. Per determinare il grado di similitudine ViPER (come già accennato in
2.5) utilizza un le di proprietà (Properties le, PR) e un le contenente i parametri
della valutazione (Evaluation Parameter File, EPF). In output viene creato un le
(Output le, O) contenente la valutazione eettuata (si veda 6.2).
Figura 6.2: Schema di ViPER-PE
Sono possibili due diversi tipi di analisi: object analysis e framewise analysis.
6.2
Object Analysis
Quest'analisi è a livello di oggetto: tenta di far combaciare gli oggetti target con gli
oggetti candidate, e di rispondere alla domanda: Quanto sono vicini due oggetti?.
1 I dati del ground truth sono chiamati così in quanto ogni algoritmo cerca di generare i dati
TARGET nel miglior modo possibile, producendo un elenco di dati CANDIDATE.
6.2 Object Analysis
105
Utilizzando questa losoa determina quali oggetti target e candidate sono abbastanza vicini da potersi considerare lo stesso oggetto, e quindi mostra quali oggetti
hanno determinato un match, un miss oppure un false, e per ognuno genera una
serie di risultati numerici. Questo comporta la denizione di alcune metriche per il
confronto di questi oggetti (g. 6.3).
Figura 6.3: Metriche utilizzabili in ViPER-PE
Le metriche e le tolleranze possono essere congurate nel le delle proprietà.
L'object analysis è suddivisa in diverse fasi, ognuna delle quali è ad un livello più
ranato di valutazione.
106
6.2.1 Detection (level = 1)
Per ogni tipo di descrittore ViPER-PE controlla i frame dove sono presenti oggetti.
Se un candidate si sovrappone temporalmente a un target per abbastanza tempo
(o, equivalentemente, per un numero suciente di frame), allora sia il target che il
candidate vengono conteggiati come match. Da notare che non importa dove il target
e il candidate si trovano spazialmente nel frame, l'importante è che siano presenti
temporalmente (quasi) negli stessi frame. Per determinare quando due oggetti sono
sucientemente vicini si utilizza una distanza tra i due framespan (range_metric )
e una tolleranza (range_tol ). Se la distanza è maggiore della tolleranza gli oggetti
non vengono contati.
6.2.2 Localization (level = 2)
Opera in modo simile alla detection, però qui entra in gioco la posizione nello spazio.
Invece di guardare a tutti i frame di un oggetto, confronta solo quei frame dove gli
attributi sono simili. Il termine simili è sempre denito dall'utente tramite una
distanza (<attribute_type> _metric ) e una tolleranza (<attribute_type> _tol ).
6.2.3 Statistical Comparison (level = 3)
A partire dai match della localization, calcola la distanza media (level3_metric =
mean ), minima ( = minimum ), mediana ( = median ) e massima ( = maximum), e
poi confronta questo valore con la tolleranza (level3_tol ). Quest'analisi è utile per
oggetti che si trovano su molti frame.
6.2.4 Target Matching
Dopo questi tre livelli di analisi, ViPER-PE ha una lista di candidate che hanno dei
target corrispondenti. In base al tipo di analisi che vogliamo eettuare, è necessario
decidere in che modo accoppiare oggetti target e candidate (target_match ):
•
SINGLE-GREEDY : semplice accoppiamento 1 a 1.
•
SINGLE-BEST: accoppiamento 1 a 1 che minimizza la somma delle distanze.
•
MULTIPLE: accoppiamento MOLTI a MOLTI.
6.3 Framewise Analysis
6.3
107
Framewise Analysis
Questo tipo di analisi esamina gli oggetti frame per frame, e per ogni frame genera
una lista di metriche di valutazione.
6.3.1 Metriche di valutazione
Per denire quali metriche utilizzare occorre settare opportunamente il le contenente i parametri della valutazione (EPF).
Denendo:
T = target,
C = candidate,
size(X) =
#X =
dimensione di
X,
numero di istanze di
X
Le metriche utilizzabili sono:
•
e/dice/overlap/maxdev/l/h/euclidean/manhattan/dierence : da utilizzare in
base al tipo di oggetto, si veda la gura 6.3
•
matchedpixels =
size(T
T
C):
numero di pixel contati come MATCH (ovvero
i true positive)
•
missedpixels =
size(T ) − size(T
T
C):
numero di pixel contati come MISS
(ovvero false negative)
•
falsepixels =
size(T ) − size(T
T
C):
numero di pixel contati come FALSE
(ovvero i false positive)
•
arearecall <soglia> =
numero di target la cui Recall supera lo soglia data
numero totale di Target
ogni Recall è calcolata come:
size(T
T
C)/size(T ).
108
•
areaprecision <soglia> =
numero di Candidate la cui Precision supera lo soglia data
numero totale di Candidate
ogni Precision è calcolata come:
size(C
T
T )/size(C).
Figura 6.4: Target e Candidate
In più ve ne sono alcune relazionate al numero di istanze di target e candidate:
•
Detection Accuracy :
if (#T + #C) == 0 return undefined;
else return
•
2·min(#T,#C)
;
#T +#C
Object Count Recall :
if #T == 0 return undefined;
else if (#C < #T ) return (#C/#T ); else return 1;
•
Object Count Precision :
if #C == 0 return undefined;
else if (#T < #C) return (#T /#C);
else return 1;
6.4 Il le Properties
109
Come è facilmente intuibile, queste ultime tre metriche sono normalizzate con
un intervallo che va da 0 a 1.
6.4
Il le Properties
Il Properties File è un le di congurazione in cui è possibile aermare la metrica
che si intende utilizzare, il livello di object analysis e le tolleranze.
Le principali preferenze per la valutazione sono:
•
il livello di analisi: nel caso si voglia eettuare una localization, il livello è 2;
•
la modalità di target matching
•
la metrica da utilizzare per il confronto delle aree: dice, overlap, etc . . .
•
la metrica da utilizzare per le distanze sulle stringhe: Levenshtein, Hamming,
etc . . .
•
la metrica specica per il livello scelto: nel livello 3 ad esempio si può utilizzare
media, varianza, etc. . .
•
le tolleranze (o soglie) temporali, speciche per livello o per attributo
La forza di ViPER-PE sta nella sua capacità di fornire uno strumento di valutazione general-purpose adattabile per un ampio spettro di casi e contesti.
La
valutazione può avvenire sia su precise forme che corrispondono a determinati oggetti, tramite le metriche per le aree, sia su entità rappresentate da punti o da
stringhe.
Oltre alla metrica dell'uguaglianza, dicilmente applicabile in contesti
con un così elevato dettaglio, vengono fornite metriche che orono un confronto
statistico normalizzabile e riutilizzabile.
6.5
Il le Evaluation Parameters
Se nel le delle proprietà vengono decise le metriche da utilizzare per eettuare la
valutazione, nell'EPF si notica al sistema quali sono gli oggetti da confrontare.
110
Il le dei parametri della valutazione è formato da una lista di sezioni: EQUIVALENCE, EVALUATION, FILTER.
La parte di EQUIVALENCE viene utilizzata per risolvere il disaccoppiamento
tra i nomi: esso è un problema comune durante la valutazione.
Infatti, lo stesso
attributo (o descrittore) potrebbe avere un nome diverso nei le ground truth e
candidate; una lista di equivalenze provvede a chiarire qualunque ambiguità.
Nella sezione di EVALUATION vanno elencati i descrittori e gli attributi di
cui si intende compiere la valutazione, secondo la sintassi descritta nel manuale di
ViPER-PE [26].
La lista di descrittori e attributi va costituita sia per la fase di
object analysis che per quella riguardante la framewise analysis. Sia per i descrittori
che per i rispettivi attributi inoltre è possibile specicare l'utilizzo di metriche e
tolleranze diverse da quelle di default presenti nel le delle proprietà.
Inne, la sezione FILTER è stata implementata poichè spesso è utile esaminare
solo una parte dei dati che si hanno a disposizione. Tramite i ltri è possibile isolare
quel sottoinsieme di dati che soddisfa certi requisiti. Mentre la sezione EVALUATION specica la metrica da utilizzare e quali tipi di descrittori valutare, i ltri
forniscono un controllo preciso su quali descrittori valutare.
E' possibile lavorare
separatamente su target input, target output, candidate input e candidate output.
I ltri in input fanno in modo che alcuni oggetti non vengano letti in ViPERPE: in altre parole quegli oggetti che non passano un ltro in input è come se
non esistessero; sembra cioè che questi oggetti non facciano parte dei dati.
Per
escludere dalla valutazione interi descrittori è suciente non includerli nella sezione
EVALUATION. I ltri in output specicano invece che i descrittori scartati dai ltri
in input e quelli che non passano i ltri in output non devono essere stampati in
output.
Occorre prestare attenzione perchè un errato utilizzo dei ltri potrebbe
portare a valutazioni non valide. Se per esempio si adopera solamente un ltro sul
target, l'utilizzo di un sottoinsieme della verità porta all'incremento del totale delle
false detection; è bene quindi che i ltri siano sempre applicati sia al target che al
candidate.
6.6 File di output
6.6
111
File di output
I risultati della valutazione vengono salvati su le, il le di output. Il formato del
le è testuale, consentendo cosi l'elaborazione e l'acquisizione dei dati per generare
eventuali graci riassuntivi.
Il le è suddiviso in varie sezioni.
All'inizio del le vi sono gli input parameters, una lista di proprietà utilizzate
per la valutazione; successivamente, vengono elencati i ltri applicati e gli oggetti da
2
valutare con le metriche stabilite . Dopo questo breve sommario, inizia la valutazione vera e propria, suddivisa nelle due parti principali descritte precedentemente,
ovvero l'Object Evaluation e la Framewise Evaluation.
Nell'object evaluation, un oggetto può essere classicato sotto diversi livelli di
detection in base ai risultati conseguiti; vengono quindi elencati tutti gli oggetti
conteggiati come miss o false durante i vari livelli di analisi (si veda cap 6.2).
Levels :
•
0: non esistono altri oggetti dello stesso tipo nel le.
•
1: l'oggetto non soddisfa metriche e tolleranze sui frame per ogni altro oggetto
dello stesso tipo.
•
2: la localization non rileva alcun match.
•
3: la statistical comparison non rileva alcun match.
•
3c: il descrittore non fa match con un oggetto così bene come un altro.
Se un tipo di oggetto nel candidate fa match con oggetti del target, non presenta
problemi nel passare i livelli elencati sopra. Dopo i risultati in questi livelli vengono
quindi elencate le Detections, dove sono elencati tutti i match.
Per ogni frame (l'insieme dei frame considerati è l'unione dei framespan del
target e della somma dei framespan dei candidate individuati), è mostrato il valore
2 Le informazioni vengono raccolte dai le PR e EPF
112
numerico della distanza tra target e candidate : 0 è la distanza minima (cioè perfetta
identità tra gli oggetti), 1 è la distanza massima (nessun candidate fa match col
target ).
Inoltre, vengono mostrati la media dei valori della distanza, la distanza
statistica (si veda in 6.2.3) e il valore medio per l'overlap, la metrica dice e l'extent.
Inne, vi è il sommario per l'object evaluation. I dati sono forniti elencando Precision
e Recall prima per ogni tipo di oggetto, e poi per il totale.
Giunge quindi il turno della Framewise Evaluation, ovvero la valutazione frame
per frame. Per ogni frame vengono visualizzati i risultati per le metriche scelte nel
le EPF; in ultima istanza sono mostrate le medie nali per ogni metrica (pixel
matched, missed e falsely detected riportano la somma totale dei pixel); per rendere
più chiaramente l'idea, è possibile osservare l'esempio seguente, in cui si riportano i
risultati per un frame e per il totale.
For frame 1605
Detection Accuracy:
0.6666666666666666
Object Count Recall: 0.5
Object Count Precision: 1
Dice coefficient:
Target overlap:
0.5856427059442004
0.6413844465936461
Maximum deviation:
Pixels matched:
Pixels missed:
0.6489415878545485
1065.4468085102023
2106.053191489099
Pixels falsely detected: 230.55319148933197
Object Area Recall: 0.35861555317352317
Box Area Precision: 0.8221040185643844
Localized Object Area Recall:
0.5
Localized Box Area Precision:
1.0
Total for all frames
Detection Accuracy:
0.825793551612097
Object Count Recall: 1
Object Count Precision: 0.7032779906343125
6.7 Test realizzati
113
Dice coefficient:
Target overlap:
0.49696838381590314
0.32971600611678675
Maximum deviation:
Pixels matched:
Pixels missed:
0.5678654790713002
4299132.451114162
2156265.548885301
Object Area Recall: 0.6702839934423572
Box Area Precision: 0.5691756658617229
0.5236077481840193
0.6296296296296297
6.7
Test realizzati
3
Come esempio dimostrativo si è preso un le video dal repository di ViSOR
e
lo si è fatto elaborare da Sakbot per generare le annotazioni automatiche grazie
all'architettura realizzata.
Una volta ottenute le annotazioni automatiche, sono stati creati i le PR ed EPF
per confrontare i descrittori presenti nel le generato con il ground truth scaricato
dal sito.
L'obiettivo è valutare grazie a ViPER-PE, a livello di frame, quando è corretta
la segmentazione; non verranno perciò analizzati i risultati sulla Object Evaluation,
poichè non relativi agli scopi pressi.
E' possibile mostrare un primo feedback dei risultati estraendo dall'output di
ViPER-PE il risultato sul totale dei frame alla ne della Framewise Evaluation.
Total for all frames
#### Valido per tutte le feature valutate
Detection Accuracy:
0.9626556016597511
Object Count Recall: 1
Object Count Precision: 0.928
3 http://imagelab.ing.unimore.it/visor/video_details.asp?idvideo=71
114
#### Per il bounding box
Dice coefficient:
0.36182361224867077
Target overlap:
0.26451372065261675
Pixels matched:
545274.0
Pixels missed:
185624.0
0.896551724137931
0.64
#### Per l'ellisse
Dice coefficient:
0.6207183318540974
Target overlap:
0.4935180652085695
Pixels matched:
82143.58835817437
Pixels missed:
34403.03291310558
0.48695652173913045
0.3089430894308943
Anche solo per ottenere una valutazione sommaria, gli indici del totale dei frame
precisano obiettivamente chiari risultati statistici. Considerati i pixel matched, missed e falsely detected è possibile calcolare la Precision e la Recall sia del bounding
box che dell'ellisse.
Per il bounding box, Recall e Precision sono del 74,6% e del 78,1%, mentre per
l'ellisse corrispondono rispettivamente al 70,5% e al 50,7%.
Non solo è possibile
estrarre questi indici, ma grazie alle metriche sulla sovrapposizione (Dice e Target
Overlap ) possiamo concordare su quanto le forme individuate dal sistema e quelle
annotate come ground truth corrispondano.
In questo particolare caso, ad esempio, è possibile osservare una maggiore precisione nel bounding box rispetto all'ellisse: il coeciente dice e l'overlap sono più
vicini allo 0 (e quindi più vicini all'identità) nella prima forma.
Possedendo ta-
li informazioni possiamo in questo caso confermare il fatto che il bounding box è
statisticamente più eciente poichè è meno preciso nel descrivere il soggetto annotato; l'ellisse fornisce comunque buoni risultati, considerando la maggiore fedeltà alla
sagoma del soggetto.
6.7 Test realizzati
115
Se poi si vuole analizzare meglio il risultato della valutazione, è possibile ottenere
dagli valori conseguiti per ogni frame un graco riassuntivo e comparativo sui diversi
indici.
Nelle gure 6.5 e 6.6 sono mostrati i graci riguardanti il bounding box sugli
indici di dice, overlap, recall e precision.
Figura 6.5: Bounding box: dice - overlap
E' poi possibile ottenere una misura unica dalla g. 6.6, calcolando l'F-Measure
4
(g. 6.7).
Per avere invece un'idea su quanto sia distribuita la campana delle recall e
delle precision è possibile osservare il graco in g. 6.8, il quale, ponendo sull'asse
orizzontale la recall e sull'asse verticale la precision, rappresenta in modo geometrico
la zona in cui più frame hanno i due valori in comune, permettendo una migliore
scelta delle tolleranze.
Analoghe valutazioni possono essere compiute per l'ellisse.
4 Utilizzata anche in ETISEO, si veda cap. 1.2.3
116
Figura 6.6: Bounding box: recall - precision
Figura 6.7: Bounding box: f-measure
6.7 Test realizzati
117
Figura 6.8: Bounding box: distribuzione di recall e precision
Figura 6.9: Baricentro
Il baricentro, essendo un punto, non può presentare metriche di dice/overlap e
recall/precision. Per esso è possibile analizzare la distanza tra il target e candidate:
118
le due metriche utilizzabili per i punti sono la manhattan distance e l'euclidean
5
distance . Esse sono molto simili, come è possibile notare in g. 6.9.
Concludendo, questa valutazione non vuole aermare quanto validi siano gli
eettivi risultati, ma intende dimostrare che grazie a questi strumenti è possibile
eettuare una valutazione completa, accurata ed obiettiva.
5 Si veda la g. 6.3.
Conclusioni
In questa tesi è stata proposta la progettazione e l'implementazione all'interno dell'ambiente ViSOR di un'architettura per generare annotazioni automatiche, attraverso l'acquisizione, la riorganizzazione e l'esportazione dei dati di elaborazione di
un sistema di videosorveglianza nell'ambito della valutazione delle prestazioni degli
algoritmi riguardanti questa tematica.
Dopo una prima introduzione sull'argomento, sui progetti correlati e sull'ambiente in cui si è lavorato, è stata analizzata l'architettura progettata e ne è stata
proposta l'implementazione realizzando una libreria C++ all'interno del sistema
Sakbot. Inne, attraverso un esempio è stato mostrato come dalle annotazioni automatiche generate, attraverso appositi tool, è possibile ottenere una valutazione
completa ed obiettiva degli algoritmi e dei livelli semantici interessati.
L'architettura è stata progettata in modo tale da essere la base per la valutazione
delle prestazioni degli algoritmi presenti e futuri del sistema di videosorveglianza
in esame.
L'obiettivo è stato pienamente raggiunto; l 'infrastruttura realizzata
possiede diverse caratteristiche:
•
è espandibile: sono facilmente aggiungibili nuovi descrittori, nuovi concetti o
stati, senza che sia necessaria una modica alla struttura;
•
è modulare: ogni oggetto presente nell'ontologia è stato analizzato e isolato
in modo da chiarirne la funzione minimizzando le dipendenze. Ogni livello si
occupa di estrarre e controllare i dati delegando la richiesta ai livelli inferiori
e consegnando il risultato al livello superiore;
•
è aperta rispetto al formato: è possibile aggiungere l'esportazione in diversi
formati oltre a quelli già realizzati (testo e ViPER-XML);
119
120
•
Conclusioni
l'implementazione non altera in maniera consistente le prestazioni del sistema di videosorveglianza, e la fase di acquisizione dei dati appare a questi
completamente trasparente;
•
l'annotazione generata è perfettamente compatibile con il formato di ViSOR,
che è aperto e già utilizzato da larga parte della comunità.
Nonostante i punti appena citati, rimane ancora molto da fare. L'applicazione realizzata è infatti dipendente dal sistema di videosorveglianza in cui è stata sviluppata.
I possibili sviluppi futuri possono essere molteplici:
•
esportazione nel formato MPEG-7, o altri formati minori;
•
inserimento di nuovi descrittori e di nuovi tipi di dato;
•
realizzazione di un'interfaccia graca per la selezione delle feature da annotare e per la gestione degli elementi della struttura (inserimento, modica,
cancellazione di descrittori e stati);
•
applicazione dell'esportazione anche a moduli di Sakbot di più alto livello,
quali consistent labeling, behaviour analysis, etc. . .
Elenco delle gure
1.1
Datasets Video disponibili pubblicamente . . . . . . . . . . . . . . . .
13
1.2
Estrazione dei metadati in VACE I
. . . . . . . . . . . . . . . . . . .
16
1.3
Visione concettuale dell'architettura di elaborazione . . . . . . . . . .
17
1.4
Portale PETS Metrics
. . . . . . . . . . . . . . . . . . . . . . . . . .
19
1.5
PETS Metrics XML Schema . . . . . . . . . . . . . . . . . . . . . . .
20
1.6
Esempio del sistema ODViS in uso
. . . . . . . . . . . . . . . . . . .
27
1.7
Architettura di ODViS . . . . . . . . . . . . . . . . . . . . . . . . . .
28
1.8
Descrizione del modulo di CAViAR in CVML
. . . . . . . . . . . . .
30
2.1
Visione d'insieme dell'ambiente
. . . . . . . . . . . . . . . . . . . . .
34
2.2
Processo di valutazione delle prestazioni
. . . . . . . . . . . . . . . .
36
2.3
Visione d'insieme: annotazioni . . . . . . . . . . . . . . . . . . . . . .
36
2.4
Visione d'insieme: ground truth . . . . . . . . . . . . . . . . . . . . .
37
2.5
ViSOR homepage . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.6
Visione d'insieme: portale ViSOR . . . . . . . . . . . . . . . . . . . .
42
2.7
Ricerca e risultati sui concetti video in ViSOR . . . . . . . . . . . . .
43
2.8
Tassonomia gerarchica delle categorie sui concetti video . . . . . . . .
44
2.9
ViPER-GT
48
3.1
Visione d'insieme: metriche
3.2
Overlap spaziale: intersezione e unione
3.3
Track Fragmentation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
53
. . . . . . . . . . . . . . . . .
61
. . . . . . . . . . . . . . . . . . . . . . . . . . .
64
3.4
ID Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
3.5
Track Matching Error . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
4.1
Visione d'insieme: VCA
67
. . . . . . . . . . . . . . . . . . . . . . . . .
121
122
ELENCO DELLE FIGURE
4.2
Interfaccia graca di Sakbot . . . . . . . . . . . . . . . . . . . . . . .
69
4.3
Object detection e tracking in Sakbot . . . . . . . . . . . . . . . . . .
70
4.4
Sakbot: architettura generale
. . . . . . . . . . . . . . . . . . . . . .
72
5.1
Trasparenza del modulo sviluppato rispetto al sistema . . . . . . . . .
76
5.2
Prima idea della struttura dati . . . . . . . . . . . . . . . . . . . . . .
79
5.3
Architettura dei dati
. . . . . . . . . . . . . . . . . . . . . . . . . . .
80
5.4
Bounding box . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
5.5
Ellisse
85
5.6
Interfaccia graca: preferenze
5.7
Interfaccia graca: salvataggio dati
. . . . . . . . . . . . . . . . . . .
88
5.8
Esempio di polimorsmo . . . . . . . . . . . . . . . . . . . . . . . . .
90
5.9
TinyXML
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
◦
5.10 Esportazione dei dati nel formato di ViSOR (I parte) . . . . . . . . .
99
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
88
5.11 Esportazione dei dati nel formato di ViSOR (II
◦
6.1
Visione d'insieme: valutazione e presentazione
. . . . . . . . . . . . . 103
6.2
Schema di ViPER-PE
6.3
Metriche utilizzabili in ViPER-PE . . . . . . . . . . . . . . . . . . . . 105
6.4
Target e Candidate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
6.5
Bounding box: dice - overlap . . . . . . . . . . . . . . . . . . . . . . . 115
6.6
Bounding box: recall - precision . . . . . . . . . . . . . . . . . . . . . 116
6.7
Bounding box: f-measure . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.8
Bounding box: distribuzione di recall e precision . . . . . . . . . . . . 117
6.9
Baricentro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
parte)
. . . . . . . . 100
. . . . . . . . . . . . . . . . . . . . . . . . . . 104
Appendice A
Calcolo dell'ellisse
In questa appendice verrà descritto quali sono i fondamenti teorici utilizzati per
calcolare l'ellisse data una determinata regione connessa.
Per ottenere l'oriented
box (o meglio ancora l'ellisse) è possibile procedere in due modi:
•
calcolare l'MVEE (Minimum Volume Enclosing Ellipse) :
tecnica alquanto
complicata che mira a determinare l'ellisse con volume minore su un set di
punti cercando un vettore
sitiva
E
c ∈ Rn
e una matrice simmetrica strettamente po-
che minimizzi il determinante
det(E −1 ),
appartenente all'equazione
dell'ellisse. Il metodo non viene analizzato oltre perchè non è stato applicato;
ulteriori informazioni possono essere trovate in [27];
•
utilizzare i
momenti di primo e di secondo ordine.
Siccome i due metodi appena riportati portano a risultati molto simili, il secondo
è migliore poichè meno complesso e più discretizzabile.
I momenti delle immagini e i momenti invarianti giocano un ruolo molto importante nel riconoscimento degli oggetti e nell'analisi delle forme.
I momenti generici bidimensionali di ordine
di grigio
f (x, y)
(p + q)esimo di un'immagine a livelli
sono deniti come:
Z
+∞
Z
+∞
mpq =
−∞
xp y q f (x, y)dxdy
−∞
123
p, q = 0, 1, 2..
124
Dato che i momenti vengono calcolati nel progetto su immagini binarie (denite
I ),
si può omettere
f (x, y),
avendo trasformato la funzione di distribuzione di pro-
babilità in una variabile binaria che è attiva quando i pixel sono presenti e settata
a 0 altrimenti:
Z Z
xp y q dxdy
mpq =
p, q = 0, 1, 2..
I
Lavorando sui pixel, è necessario discretizzare il momento:
mpq =
X
xp y q
A
dove
1
A è il set di elementi
su cui lavora la sommatoria. Grazie ai momenti è pos-
sibile ottenere misure invarianti rispetto alle trasformazioni ani (quali rotazione,
translazione, scala, etc. . . ).
I momenti invarianti alla traslazione sono, ad esempio, i momenti centrali :
µpq =
X
(x − xc )p (y − yc )q
A
dove
xc
e
yc
sono le coordinate del baricentro (o centroide)
ressato.
1 In questo caso, gli elementi sono i pixel neri nell'array dell'immagine.
c,
dell'oggetto inte-
125
Gettando uno sguardo più attento ai momenti, si può notare che:
Area = m00 ,
xc =
m10
,
m00
yc =
m01
,
m00
θ = tan−1
b
,
a−c
w=
q
p
6(a + c − b2 + (a − c)2 ,
w=
q
p
6(a + c + b2 + (a − c)2
dove
a=
m20
− x2c ,
m00
b = 2(
c=
m11
− xc yc ),
m00
m02
− yc2 ,
m00
Tramite questi parametri è possibile inferire l'ellisse equivalente, dove
il suo centro,
θ
la sua inclinazione,
w
e
l
C(xc , yc ) sarà
rispettivamente l'asse maggiore e minore.
Le formule antecedenti sono vericabili passo per passo. Ad esempio, l'area è il
momento bidimensionale di ordine 0:
gli elementi di A.
P
A
x0 y 0 ⇒
P
A
1,
ovvero la somma di tutti
126
Bibliograa
[1] J. Black, T. Ellis, and P. Rosin, A novel method for video tracking performance
evaluation, Joint IEEE International Workshop on Visula Suirvellance and
Performance Evaluation of Tracking and Surveillance (VS-PETS), 2003.
[2] A.
T.
Nghiem,
F.
Bremond,
M.
Thonnat,
and
V.
Valentin,
ETISEO,
performance evaluation for video surveillance systems, 2007.
[3] C. Jaynes, S. Webb, R. M. Steele, and Q. Xiong, An Open Development Environment for Evaluation of Video Surveillance Systems, IEEE International
Workshop on Performance Evaluation of Tracking and Surveillance (PETS),
2002.
[4] T. List, J. Bins, R. B. Fisher, D. Tweed, and K. R. Thórisson, Two Approaches
to a Plug-and-Play Vision Architecture
CAVIAR and Psyclone, 2006.
[5] D. Tweed, W. Feng, R. B. Fisher, J. Bins, and T. List, Exploring techniques
for behaviour recognition via the CAVIAR modular vision framework, 2006.
[6] T. List and R. B. Fisher, CVML - an XML-based computer vision markup
language,
IEEE International Conference on Pattern Recognition (ICPR),
2004.
[7] T. List, J. Bins, J. Vazquez, and R. B. Fisher, Performance evaluating the
evaluator, 2005.
[8] http://imagelab.ing.unimore.it/imagelab/, ImageLab Website.
[9] C. G. M. Snoek, M. Worring, J. C. van Gemert, J. M. Geusebroek, and A. W. M.
Smeulders, The challenge problem for automated detection of 101 semantic
concepts in multimedia, ACM Multimedia, 2006.
127
128
BIBLIOGRAFIA
[10] M. R. Naphade,
L. Kennedy,
J. R. Kender,
S. F. Chang,
J. R. Smith,
P. Over, and A. Hauptmann, A Light Scale Concept Ontology for Multimedia
Understanding for TRECVID 2005, IBM Research Technical Report, 2005.
[11] Y. J. Zhang, A survey on evaluation methods for image segmentation, Pattern
Recognition, vol. 29, no. 8, 1996.
[12] P. L. Correia and F. Pereira, Objective evaluation of video segmentation
quality, IEEE Transactions on Image Processing, vol. 12, no. 2, 2003.
[13] C. E. Erdem, B. Sankur, and A. M. Tekalp, Performance measures for vdeo
object segmentation and tracking, IEEE Transactions on Image Processing,
vol. 13, no. 7, 2004.
[14] A. Prati, I. Mikic, M. M. Trivedi, and R. Cucchiara, Detecting moving shadows: algorithms and evaluation, IEEE Transactions on Pattern Analysis and
Machine Intelligence, vol. 27, no. 7, 2003.
[15] F. Oberti, A. Teschioni, and C. S. Regazzoni, ROC curves for performance
evaluation of video sequences processing systems for surveillance applications,
IEEE International Conference on Image Processing (ICIP), 1999.
[16] T. H. Chalidabhongse, K. Kim, D. Harwood, and L. Davis, A perturbation
method for evaluating background subtraction algorithms, Joint IEEE In-
ternational Workshop on Visula Suirvellance and Performance Evaluation of
Tracking and Surveillance (VS-PETS), 2003.
[17] V. Y. M. et al., Performance evaluation of object detection algorithms, IEEE
International Conference on Pattern Recognition (ICPR), 2002.
[18] J. Nascimento and J. S. Marques, New performance evaluation metrics for
object detection algorithms, IEEE International Workshop on Performance
Evaluation of Tracking and Surveillance (PETS), 2004.
[19] C. J. Needham and D. Boyle, Performance evaluation metrics and statistics for positional tracker evaluation, Computer Vision System: International
Conference, 2003.
BIBLIOGRAFIA
[20] M. Rossi and A. Bozzoli, Tracking and counting moving people,
129
IEEE
International Conference on Image Processing (ICIP), 1994.
[21] M. Xu and T. Ellis, Partial observation vs. blind tracking through occlusion,
British Machine Vision Conference (BMVC), 2002.
[22] S. Pingali and J. Segen, Performance evaluation of people tracking systems,
1996.
[23] F. Yin, D. Makris, and S. Velastin, Performance evaluation of object tracking algorithms, IEEE International Workshop on Performance Evaluation of
Tracking and Surveillance (PETS), 2007.
[24] F. Bashir and F. Porikli, Performance evaluation of object detection and tracking system, IEEE International Workshop on Performance Evaluation of
Tracking and Surveillance (PETS), 2006.
[25] R. Cucchiara, C. Grana, G. Neri, M. Piccardi, and A. Prati, The Sakbot system
for moving object detection and tracking, European Workshop on Advanced
Video-Based Surveillance Systems, 2001.
[26] D. Mihalcik, ViPER-PE Manual.
[27] N. Moshtagh, Minimum volume enclosing ellipsoids, 2006.
[28] D. P. Young and J. M. Ferryman, PETS Metrics: On-Line Performance Evaluation Service, Joint IEEE International Workshop on Visula Suirvellance
and Performance Evaluation of Tracking and Surveillance (VS-PETS), 2005.
[29] V. Manohar, M. Boonstra, V. Korzhova, P. Soundararajan, D. Goldgof, R. Kasturi, S. Prasad, H. Raju, R. Bowers, and J. Garofolo, PETS vs. VACE Evaluation Programs: A Comparative Study, IEEE International Workshop on
Performance Evaluation of Tracking and Surveillance (PETS), 2007.
[30] http://viper-toolkit.sourceforge.net/, ViPER Website.
[31] X. Desurmont, R. Wijnhoven, E. J. O. Caignartd, M. Baraise, W. Favoreelf,
and J. F. Delaigle, Performance evaluation of real-time video content analysis
systems in the CANDELA project, 2005.
130
BIBLIOGRAFIA
[32] L. M. Brown, A. W. Senior, Y. l. Tian, J. Connell, A. Hampapur, C. F. Shu,
H. Merkl, and M. Lu, Performance evaluation of surveillance systems under
varying conditions, 2004.
[33] T. Ellis,
Performance metrics and methods for tracking in surveillance,
IEEE International Workshop on Performance Evaluation of Tracking and
Surveillance (PETS), 2002.
[34] X. Desurmont, R. Sebbe, F. Martin, C. Machy, and J. F. Delaigle, Performance
evaluation of frequent events detection systems, IEEE International Workshop
on Performance Evaluation of Tracking and Surveillance (PETS), 2006.
[35] J. Nascimento and J. Marques, Performance evaluation of object detection
algorithms for video surveillance, 2005.
[36] N. Lazarevic-McManus, J. Renno, D. Makris, and G. A. Jones, Designing
evaluation methodologies: The case of motion detection, IEEE International
Workshop on Performance Evaluation of Tracking and Surveillance (PETS),
2006.
[37] http://imagelab.ing.unimore.it/visor/, ViSOR Portal.
[38] http://datasets.visionbib.com/index.html, Datasets Reference.
[39] R. Vezzani and R. Cucchiara, ViSOR: Video Surveillance Online Repository, British Machine Vision Association and Society for Pattern Recognition
Symposium on Security and surveillance: performance evaluation, 2007.
[40] http://www.informedia.cs.cmu.edu/arda/, VACE Portal.
[41] L. O. Rocha, L. U. V. Elho, P. C. Ezar, and P. C. Arvalho, Image MomentsBased Structuring and Tracking of Objects,
XV Brazilian Symposium on
Computer Graphics and Image Processing, 2002.
[42] D. Mihalcik and D. Doermann, The Design and Implementation of ViPER.

Annotazioni automatiche per la videosorveglianza: l

Transcript

Documenti analoghi

RIGIDITÀ STIFFNESS COMFORT COMFORT

Programma del corso - SisInf Lab

Specifics of CANopen protocol implementation

cross country - Speed Bikes

TERZA A Allegato n 2 Simulazioni terza prova

Nolan® range - Motorinfo.hu

Implementation of CANopen protocol

Tourmax Apribili

Page 1 of 2 Sun Java System Messenger Express

Linee di estrusione Profili Giunto Termico Extrusion Lines for PA