Sviluppo di moduli software ottimizzati per il calcolo del movimento in situazioni reali

Transcript

1 Universitá di Genova Facoltá di Ingegneria Dipartimento Interscuola di Informatica Bioingegneria, Robotica e Ingegneria dei Sistemi Tesi di Laurea Triennale in Ingegneria Elettronica Sviluppo di moduli software ottimizzati per il calcolo del movimento in situazioni reali Relatore: Prof. Fabio Solari Correlatore: Dott. Manuela Chessa Studenti: Andrea Badano Francesco Gurrieri Genova, 28 Settembre 2012 Anno Accademico

2 Ringraziamenti Desideriamo ringraziare il Professore Fabio Solari e la Dottoressa Manuela Chessa, per averci dato l opportunità di lavorare ad una tesi per noi di grande interesse e stimolo. Ringraziamo tutte le persone presenti in laboratorio, che in questi mesi ci hanno accolto, aiutato e fatto sorridere. Ringraziamo Francesco, che si è sempre premurato di aiutarci anche dopo essersi laureato. Francesco e Andrea Volevo ringraziare la mia famiglia, che mi ha sostenuto e incoraggiato in questi tre anni di Corso di Studi. La mia fidanzata e, soprattutto, la sua infinita pazienza. Il mio compagno di tesi, che é riuscito a sopportarmi e ad insegnarmi a lavorare in gruppo. 2

3 Francesco Ringrazio la mia famiglia per avermi appoggiato a aiutato nel corso del mio percorso di studi all università e i miei compagni di corso con i quali ho condiviso questa bellissima esperienza durata 3 anni. Un ringraziamento particolare a Francesco Gurrieri che si é rivelato ottimo amico oltre che ad un buon compagno di lavoro. Andrea 3

4 Indice 1 Il Flusso Ottico Introduzione Stato dell arte Tecniche differenziali Tecniche basate sulla corrispondenza tra regioni Tecniche basate sullo studio della fase Tecniche basate sul calcolo dell energia L algoritmo basato su codifica di popolazione L architettura Neurale Il filtraggio spaziale Il filtraggio temporale La componente di velocità e la velocità totale Il raffinamento dei risultati (corse-to-fine refinement) Scelte di implementazione: perchè GPU? Dalla GPU al GPGPU Computing GPGPU vs. CPU Processing

5 3.3 CUDA L architettura L organizzazione della memoria Le Librerie opencv Il modulo GPU La Classe GpuMat L implementazione Decomposizione piramidale Filtraggi spazio-temporali Filtraggi spaziali Filtraggi temporali Energia e calcolo della componente di velocità lungo un orientamento Full Velocity : stima del flusso ottico Livelli successivi della piramide : il coarse-to-fine refinement Expand Filtraggio spaziali Warping Filtraggi temporali Component Velocity e Full Velocity Merge Flow Gestione della memoria Test e risultati La visualizzazione del flusso ottico

6 5.2 Il random dot sequence test Precisione e affidabilità della stima del flusso ottico Sequenze sintetiche Sequenze Reali Le prestazioni dell algoritmo Metodologia di acquisizione dei tempi Tabelle Realizzazione di una dimostrazione Conclusioni Sviluppi Futuri Bibliografia 66 6

7 Abstract Motion estimation is features a which concerns most of artificial vision system. We exploited a neuromorphic architecture previously implemented in Matlab to create a GPU software module with the aim of providing a realtime solution to the motion detection problem, along with the idea to take advantage from the huge GPU s computation capability in general purpose computing. At the beginning we tested our codes funcionality using some easy artificial sequences and then with real-worlds video sequences too, comparing our results respect to the state-of-art algorithms.

8 Introduzione Lo scopo di questa tesi é implementare un modulo software per il calcolo del flusso ottico. Misureremo la bontà del nostro lavoro secondo parametri di precisione e memoria impiegata, ma l obbiettivo del lavoro é quello di sviluppare un programma che lavori in real-time, ovvero che dia in uscita un flusso video con più di 10 fps (frames per second). Partendo da un codice scritto ad alto livello, in linguaggio Matlab, siamo passati ad un linguaggio che ci permettesse di ottenere prestazioni di velocità sensibilmente migliori. Abbiamo deciso di adottare il C++ e di sfruttare particolari librerie che sfruttano la scheda grafica. Come spiegato nel corso del primo capitolo, l algoritmo da noi implementato di inserisce in un panorama molto vasto di risoluzioni al problema del calcolo del flusso ottico. Ogni approccio ha punti di forza e lacune,che trovano immediato riscontro alla prova dei fatti: con alcuni tipi di sequenze un tipo di approccio può risultare vincente mentre con altri tipi no. Nel secondo capitolo approfondiremo le caratteristiche dell algoritmo a codifica di popolazione da noi implementato. La particolaritá é che é ispirato a come rispondono le cellule sottocorticali del nostro sistema visivo. Algoritmi di questo tipo -chiamati neuromorfi- hanno il vantaggio di reagire bene con diverse tipologie di sequenze in input e lo svantaggio di risultare computa- 1

9 zionalmente onerosi. Nei capitoli 3 e 4 spiegheremo come abbiamo ripensato alcuni passaggi dell algoritmo e come abbiamo sfruttato le strutture a nostra dispozione per riuscire a ottenere prestazioni competitive nonostante la mole di calcoli tipica degli algoritmi neuromorfi. Nel quinto capitolo analizzeremo infine i risultati ottenuti: la velocitá di calcolo stimata in fps e la quantitá di memoria utilizzata al crescere delle dimensioni dei video in ingresso, la precisione su diversi tipi di sequenze. Inoltre metteremo alla prova il nostro algoritmo analizzando sequenze reali, che come spiegheremo sono notoriamente molto difficili da elaborare correttamente a causa delle condizioni non ideali a cui sono sottoposte (luminositá non costante, movimenti non voluti della webcam e dell ambiente sullo sfondo). 2

10 Capitolo 1 Il Flusso Ottico 1.1 Introduzione Il problema trattato in questa tesi è la stima del flusso ottico a partire da sequenze di immagini. Data una sequenza di immagini in ingresso bisogna calcolare per ogni pixel le informazioni riguardanti il vettore movimento: direzione, verso e intensità (in pixel/s). Per capire meglio le scelte compiute nello svolgimento della tesi è però necessario approfondire il concetto di flusso ottico e quali sono i metodi attualmente conosciuti per estrapolarlo. Data una matrice bidimensionale - un immagine -, il flusso ottico è il campo vettoriale che definisce punto per punto direzione verso e velocità degli elementi luminosi (pixel). Esistono in letteratura diversi approcci per calcolare tale informazione. Per ogni tipo di tecnica utilizzata, vi sono ricercatori che hanno studiato diversi algoritmi, cercando di ottenere buone prestazioni in termini di errore 3

11 medio angolare, deviazione standard dell errore angolare e densità. Quando si analizzano i risultati bisogna tenere conto di alcune ipotesi di fondo molto restrittive, difficilmente verificabili anche solo su sequenze sintetiche che simulano casi reali (come la Yosemite). Le suddette ipotesi sono: Il campo vettoriale delle velocità è considerato tempo-invariante ( cambia poco tra due frame in ingresso successivi ). L illuminazione è considerata costante. In scene reali queste ipotesi vengono puntualmente contraddette e, quindi, le performance di errore medio angolare e densitá risultano basse. Da tenere sicuramente in considerazione è il fatto che le sequenze di test non hanno sample rate particolarmente elevati. Aumentando opportunamente la campionatura in ingresso le suddette ipotesi risulterebbero verificate. Un simile scenario sarebbe attuabile solo con implementazioni con prestazioni computazionali in grado di reggere una sample rate alta. Passando poi alla fase di implementazione, bisogna assicurarsi che l algoritmo non sia troppo oneroso computazionalmente. Per avere poi una rilevanza pratica l idealità sarebbe elaborare almeno 10 fps (frames per seconds). 4

12 1.2 Stato dell arte Tecniche differenziali Le tecniche differenziali sono basate sull applicazione dell operatore derivata (rispetto le coordinate x, y, t) dell intensità luminosa I. Particolarità di queste tecniche è quella di stabilire un vincolo al fine di ridurre le dimensioni del problema. Horn and Schunk [B.K.P. Horn, 1981] decisero ad esempio di porre come vincolo quello di minimizzare il l integrale 1.1 [ ( I v + It ) 2 + λ 2 ( u v 2 2) ] dx dy (1.1) D dove u e v sono le componenti del vettore velocitá stimato v(x,t)= ((v(x,t),v(x,t)) e λ é un termine che rappresenta l influenza dell uniformitá del campo. Partendo da questo vincolo è possibile ricavare delle equazioni iterative per stimare la velocità. Questo approccio, dal punto di vista analitico corretto, porta ad errori dovuti ad un utilizzo prematuro dell operatore di derivazione. Barron, Fleet and Beauchemin[Barron et al., 1994a] sono riusciti a migliorare le performance di tale algoritmo facendo uno smoothing delle immagini in ingresso. La modifica ha portato a grandi risultati su input sintetici di basso indice di difficoltà (si é passati da un errore angolare di a soli 2.02 con la sequenza Translating Tree)[Barron et al., 1994b]. I risultati su altri tipi di sequenze risultano poco soddisfacenti, in relazione ad algoritmi sviluppati successivamente. Nonostante la modifica di Barron, infatti, gli errori su sequenze anche sintetiche sono elevati:basti pensare agli di errore medio sulla Yosemite. Per ottenere risultati migliori bisogna alzare il livello delle soglie, compromettendo però la densità dei risultati. 5

13 Partendo da una base comunque ottima, Lucas and Kanade hanno deciso di utilizzare un altro vincolo. Hanno deciso di minimizzare la seguente espressione W 2 (x) [ I(x, t) v + I t (x, t)] 2 (1.2) x Ω Dove W assume la funzione di passabanda. Lucas e Kanade sono arrivati a risultati molto buoni dal punto di vista dell errore angolare medio ( si parla di errori medi che vanno dai 0.78 ai 4.8 su sequenze sintetiche), ma che presentano gli stessi limiti dell algoritmo di Horn and Shunk modificato da Barron : la densità dei risultati, che raramente supera il 50% Tecniche basate sulla corrispondenza tra regioni L idea di base di questo approccio è quello di suddividere le immagini in ingresso in regioni e cercare le zone che, tra un frame e l altro, più si assomigliano. Il criterio con quale viene fatta questa scelta può essere quello della massima cross-correlazione tra le regioni o quello della minima SSD (sum of squared difference). Prendiamo in esame proprio quest ultimo criterio. n n SSD 1,2 (x, d) = W (i, j)[i 1 (x + (i, j)) I 2 (x + d + (i, j))] 2 (1.3) j= n i= n Dove W rappresenta una funzione finestra bidimensionale e d la distanza tra le due regioni dell immagine I 1 e I 2. Lo studioso Anandan (1987) è stato il primo a teorizzare l utilizzo di una simile tecnica[anandan, 1987]. Il suo metodo ricerca una corrispendenza in uno spazio 3x3 pixel mediante una funzione finestra 5x5 pixel. Sfrutta una tecnica piramidale, che gli permette di raffinare i propri risultati. Le prestazioni di accuratezza ottenute da 6

14 Anandan sono comprese tra i 4.5 e i 15, con una density sempre massima (100%). Dai test eseguiti, risulta che tale algoritmo sia adatto in caso di input con grande rumore di fondo e con poche immagini in ingresso [Barron et al., 1994c] Tecniche basate sullo studio della fase I primi a studiare algoritmi per l estrazione del flusso ottico ricavati da informazioni sulla fase furono Fleet e Jepson[Fleet and Jepson, 1990]. Essi proposero di filtrare le immagini in ingresso mediante dei filtri passa-banda. Ogni filtro era sensibile ad una particolare velocità. La componente di moto era ricercata nella fase delle matrici in uscita da tali filtri. Pensarono ad un simile approccio perchè ritennero che la componente di fase in output dai loro filtri era meno sensibile alle piccoli oscillazioni della componente in ampiezza fino a poco tempo prima analizzata[fleet and Jepson, 1993]. Nonostante ciò, capirono che basare un algoritmo sull informazione di fase portava ad altri motivi di instabilità, risolvibile mediante un opportuno vincolo alla variazione spazio-temporale all ampiezza dell output del filtro. Il supporto temporale è di 21 frame. I risultati con input sintetici sono buoni, con errori angolari mediamente sotto 1 ma con density molto variabile a seconda dell input e dei parametri con cui si effettuano i calcoli [Barron et al., 1994d] Tecniche basate sul calcolo dell energia Infine, troviamo quegli algoritmi che calcolano il flusso ottico dalle informazioni ricavate dall energia associata ad ogni pixel, calcolata filtrando le immagini con banchi di filtri sensibili a diverse velocità. L algoritmo che si 7

15 approfondirà d ora in avanti rientra per l appunto in questa categoria. L algoritmo a codifica di popolazione è un algoritmo neuromorfo. Si ispira a come il nostro cervello gestisce ed elabora le informazioni che gli arrivano dal sistema visivo. Non è, come quelli trattati fino a questo momento, un algoritmo di misura, in quanto si usano banchi di filtri con sensibilità a diverse velocità, anziché misurare la velocità. La filosofia di tale algoritmo è quella di imitare il comportamento di gruppi di cellule risiedenti nella corteccia visiva primaria (l area V1). Questo principio dona all algoritmo una grande flessibilità alle più diverse tipologie di input. Il prezzo da pagare è un costo computazionale molto elevato. Tale algoritmo prevede infatti una serie di filtraggi spazio-temporali con dei filtri detti di Gabor (che modellano per l appunto il comportamento delle cellule corticali dei mammiferi), per poter estrarre l energia associata ad ogni porzione d immagine, ricavare informazioni riguardanti le varie componenti di velocità e, quindi, direzione verso e modulo del flusso ottico. Un aspetto basilare dell algoritmo è quello di sfruttare la tecnica della piramide[j.r. Bergen P.J. Burt J.M. Ogden, 1985], al fine ricavare informazioni riguardanti diverse frequenze spazio-temporali usado un numero limitato di filtri. 8

16 Capitolo 2 L algoritmo basato su codifica di popolazione Il codice implementato si basa su un architettura neuromorfa distribuita che si ispira al funzionamento del sistema visivo dei mammiferi, simulando il comportamento della corteccia primaria (V1), la quale proietta le informazioni visive sulle aree occipitali V3 e MT, fino al lobo parietale.[david Milner, 1995] L algoritmo implementato effettua la stima del flusso ottico raccogliendo i dati provenienti da una popolazione di cellule, il cui comportamento é simulato da una serie di filtraggi spazio-temporali delle immagini attraverso filtri di Gabor tridimensionali. I contributi provenienti dai differenti elementi della popolazione vengono uniti secondo il metodo della somma pesata per ottenere il risultato dell attività dell intera popolazione. Infine avviene un processo di raffinamento del risultato, basato sul processo della decomposizione piramidale. 9

17 2.1 L architettura Neurale In questa sezione viene approfondito il funzionamento della struttura algoritmica implementata per il calcolo del flusso ottico bidimensionale, la quale può essere schematizzata come vediamo nella figura 2.1: Figura 2.1: Schema dell architettura neurale. Il riquadro a sinistra rappresenta un unità complessa della popolazione di cellule. Ciascuna unità é sensibile a uno tra 16 diversi orientamenti θ nello spazio e 5 velocità V θ 1 nel dominio temporale. Viene così calcolata l energia di tali unità per velocità e orientamenti differenti, da questi dati si stima poi la componente di velocità per ciascun orientamento v θ c (decoding strategy) e infine la velocità totale che riunisce il contributo dei 16 orientamenti. La stima ottenuta viene poi ricalcolata attraverso un processo di rifinitura (coarse-to-fine) basata su decomposizione piramidale delle immagini. 10

18 2.2 Il filtraggio spaziale Sfruttando la separabilità dei filtri di Gabor tridimensionali la parte spaziale del filtro viene calcolata separatamente da quella temporale, permettendo di tenere basso il costo computazionale. In questa fase viene adottata una rappresentazione multi-canale, dove ciascun canale é sensibile ad un orientamento spaziale θ specifico. Questo approccio permette di risolvere alcuni problemi di ambiguità del moto locale dovuti al ben noto problema dell apertura.[manuela Chessa, 2009] Il problema dell apertura sorge quando il campo ricettivo del filtro é molto più piccolo del contorno che viene osservato,é possibile stimare solamente alla componente di movimento del contorno perpendicolare al bordo di quest ultimo. Rimane del tutto cieca ad ogni movimento parallelo al contorno osservato: il risultato di questo fenomeno si traduce in una sottostima del movimento.[hildreth, 1984] Utilizzando un approccio multi-canale sensibile a più orientamenti é possibile ovviare a questo problema. Si utilizza quindi un set di filtri di Gabor la cui componente spaziale g(x) é definita dall equazione 2.1: g(x, y; ψ, θ) = e ( x2 θ 2σx 2 y2 θ 2σy 2 ) e j(ω 0x θ +ψ) (2.1) Dove ω 0 é la frequenza spaziale radiale di picco, σ x e σ y determinano il supporto spaziale dei filtri, ψ é la fase della modulazione sinusoidale e x θ sono le coordinate spaziali ruotate.[manuela Chessa, 2009] Il dominio spaziale viene campionato uniformemente tramite 16 orientamenti che coprono l angolo da 0 a 2π utilizzando la stessa frequenza di radiale di picco. Inoltre per evitare sbilanciamenti tra le convoluzioni della parte reale e immaginaria y θ 11

19 dei filtri viene rimossa la componente continua. 2.3 Il filtraggio temporale Successivamente viene calcolata la componente temporale del set di filtri di Gabor: similmente a quanto visto per il filtraggio nel dominio dello spazio, ogni unità é sintonizzata su una velocità specifica. Con un approccio multi-canale simile a quello visto precedentemente vengono rilevati gli stimoli per 5 velocità diverse. La funzione di trasferimento f(t) legata al dominio temporale del filtro é definita dalla seguente formula: f(t; ω t ) = e ( t2 2σ 2 t ) e jωtt 1(t) (2.2) Dove con ω t si indica la frequenza di picco temporale calcolata secondo la seguente relazione 2.3 ω t = v θ ω 0, σ t (2.3) σ t determina il supporto nel dominio temporale e 1(t) é la funzione gradino unitario. Combinando le due componenti separabili del filtro si ottiene la funzione di trasferimento globale del filtro di Gabor 3D. Chiamando con h(x, t) la funzione di trasferimento globale del filtro avremo che quest ultima sarà ottenuta dalla seguente relazione h(x, t) = g(x)f(t). Il filtro così ottenuto verrà applicato alla sequenza di immagini in ingresso I(x, t) ottenendo la risposta complessa: Q(x 0, t; v θ ) = h(x 0 x, t τ)i(x, τ)dxdτ (2.4) 12

20 Da cui successivamente viene ricavata l energia, calcolata come il modulo quadrato della risposta complessa: E(x 0, t; v θ ) = Q(x0, t; v θ ) 2 t = e jψ(t) Q(x 0, t; v θ )e jωtτ dτ 0 2 (2.5) seguente Dove ψ(t) = ψ + ω t t = ψ + ω 0 v θ t 2.4 La componente di velocità e la velocità totale Una volta calcolati i valori dell energia per i diversi orientamenti spaziali e per le diverse velocità di tuning, bisogna leggere questi dati in modo tale da estrapolarne una stima affidabile. Il primo passo lo si ottiene con la stima della componente di velocità il procedimento grazie al quale si ottiene un valore di velocità (dai cinque di partenza) per ciascuno dei sedici orientamenti spaziali. Per ottenere ciò si possono utilizzare diversi approcci come ad esempio il cosiddetto Winner Takes All o il centro di gravità, nel nostro algoritmo viene utilizzato il metodo del centro di gravità (detto anche somma pesata) in quanto risulta essere un buon compromesso per mantenere basso il costo computazionale. L approccio WTA, infatti, richiederebbe un numero elevato di unità per ciascuno degli orientamenti temporali andando a pesare sia sulla memoria richiesta che sul costo computazionale complessivo dell algoritmo. Utilizzando l approccio del centro di gravità invece é possibile ottenere una stima affidabile, sfruttando il minor numero possibile di 13

21 unità della popolazione. Dunque la componente di velocità viene calcolata secondo la formula sottostante: v θ c(x 0, t) = Mi=1 v θ i E(x 0, t; v θ i ) Mi=1 E(x 0, t; v θ i ) (2.6) Dove con vi θ sono indicate le M velocità ( M = 5 nel nostro caso) e dove E(x 0, t; vi θ ) rappresenta il movimento di energia per ciascun orientamento spaziale. Successivamente viene calcolata la velocità totale lungo gli assi x e y dell immagine a partire dai valori delle vc θ e combinando i contributi dei sedici orientamenti spaziali. Con questo passaggi come visto sopra si riesce ad evitare il problema dell apertura e ad avere una stima affidabile del flusso ottico. 2.5 Il raffinamento dei risultati (corse-to-fine refinement) L ultimo aspetto da prendere in considerazione é quello che concerne il dominio delle frequenze. Infatti i filtri utilizzati nella nostra implementazione si comportano come passa banda nel dominio delle frequenze centrati su una singola frequenza radiale di picco. Dunque é necessario tenere conto di tutta la gamma di frequenze che caratterizzano l informazione contenuta nelle immagini naturali per ottenere una stima affidabile.[manuela Chessa, 2009] Per raggiungere questo obbiettivo viene utilizzata la tecnica della decomposizione piramidale dell immagine, la quale permette di mantenere un basso costo computazionale. Vengono utilizzate N scale diverse, ciascuna avente le dimensioni dimezzate rispetto alla scala al livello superiore, a partire dall 14

22 immagine di partenza. Il flusso ottico viene calcolato a partire dalla scala con le dimensioni più piccole e nel procedimento del rifinimento viene espanso e utilizzato per il warping delle immagini della scala superiore, dopo il filtraggio spaziale, infine viene calcolato il flusso ottico residuo. 15

23 Capitolo 3 Scelte di implementazione: perchè GPU? In questa sezione affrontiamo l argomento della scelta di implementare il nostro algoritmo su GPU. L algoritmo bio-ispirato da noi implementato infatti presenta caratteristiche compatibili con l implementazione su scheda grafica, prima su tutte la possibilità di parallelizzare i calcoli effettuati. L architettura a codifica popolazione implementata offre infatti un ottima struttura di partenza per il calcolo parallelo, ogni canale spaziale differente infatti può essere calcolato indipendentemente dagli altri, ciò significa che i calcoli relativi a ciascun elemento della popolazione possono essere svolti non sequenzialmente. Per comprendere meglio questo concetto é utile quindi vedere quali sono le caratteristiche principali delle GPU e quali vantaggi offre il GPGPU (General Purpose Graphic Process Unit Computing) rispetto all implementazione su CPU. 16

24 3.1 Dalla GPU al GPGPU Computing Con Graphic Process Unit(GPU) si indica una periferica hardware dedicata il cui compito principale é quello di tradurre dati in immagini 2D formate da pixel. Il ruolo principale della GPU é quello di alleggerire il carico computazionale della CPU intervenendo soprattutto nel calcolo tridimensionale. L architettura dei processori grafici é infatti ottimizzata per tradurre scene appartenenti a spazi 3D in immagini bidimensionali; processo che avviene attraverso quella che si chiama Pipeline Grafica. L evoluzione degli stadi di questa pipeline si sono evoluti da un implementazione software ad un co-processore grafico della CPU ad una fixed-function pipeline fino ad una pipeline grafica programmabile i cui stadi sono diventati via via più generali. Grazie a questa evoluzione della pipeline grafica é stato possibile utilizzare le GPU anche al di fuori del tradizionale ambito del calcolo grafico, con notevoli prestazioni in termine di potere computazionale. Possiamo prendere come esempio il gruppo GAMMA alla University of North Carolina Chapel Hill che impiega i processori grafici per applicazioni quali i diagrammi di Voronoi, rilevamento delle collisioni, simulazioni di nuvole, simulazioni della crescita dei cristalli, simulazioni di vernici viscose e altro.[crow, 2004] 3.2 GPGPU vs. CPU Processing In questa sezione vogliamo analizzare le differenze tra l approccio con implementazione CPU e l implementazione GPU soffermandoci sulle caratteristiche che ci hanno portato ad optare per la scelta della scheda grafica.il primo vantaggio é offerto dalla possibilità di parallelizzare l architettura della co- 17

25 difica di popolazione: mentre le CPU forniscono un alto livello di prestazioni su codici sequenziali, le GPU permettono di raggiungere prestazioni migliori nel calcolo parallelo. Basti pensare che i processori grafici moderni possiedono centinaia di core, numero di gran lunga superiore a quello delle CPU. Un altra peculiarità delle GPU é quella dello stream processing. Questo tipo di architettura si basa sugli stream, ovvero un set di dati, e su piccoli programmi detti kernel. Grazie a queste strutture é possibile raggiungere diversi livelli di parallelismo: Parallelismo a livello di istruzione: un singolo kernel esegue diverse operazioni su tutti gli elementi di uno stream con la possibilitá di eseguire in parallelo istruzioni indipendenti. Parallelismo a livello di dato: un singolo kernel esegue la stessa istruzione su ciascuno degli elementi dello stream in ingresso. Un altro vantaggio dei processori grafici é dato da un fattore tecnologico, infatti nelle CPU sta diventando sempre più difficile aggiungere transistori addizionali per migliorare il calcolo sequenziale. Al contrario i processori grafici possono sfruttare in maniera più efficace i transistori e ciò permette alle GPU di avere un fattore di incremento delle prestazioni migliore con il perfezionarsi della tecnologia a semiconduttore.[erik Lindholmm, 2001] Da notare inoltre che negli ultimi anni l evoluzione delle schede grafiche in termini di potere computazionale, larghezza di banda e efficienza di calcolo é stata ben superiore a quella delle CPU, grazie anche all ottimo segmento di mercato in cui sono inserite le GPU legato principalmente al settore di videogiochi il quale richiede costantemente nuove tecnologie per la sua evoluzione. 18

26 Il grafico 3.1 mette in evidenza la diversa crescita del potere computazionale misurato in FLOP/s (floating point operations per second) confrontando schede prodotte dalla NVIDIA con processori Intel,differenze che possono essere apprezzate anche sulla larghezza di banda come propone il grafico 3.2 Figura 3.1: Potenza Computazionale: GPU vs CPU. 19

27 Figura 3.2: Larghezza di Banda: GPU vs CPU. Nonostante questi vantaggi le schede grafiche presentano anche alcuni punti di debolezza. Primo su tutti quello dovuto al riutilizzo dei dati e alla memoria. I processori grafici infatti sono altamente ottimizzati per la singola elaborazione dei dati, dove una volta elaborato il risultato i dati utilizzati vengono dismessi. Infatti l architettura delle GPU é costituita da datapath più piccoli e possiede una memoria meno capiente rispetto a quella delle CPU.[K. Fatahalian, 2004] Ai fini del nostro algoritmo questo fattore ha portato ad alcune problematiche: la bassa disponibilità di memoria si é scontrata con il volume di dati prodotto dal nostro algoritmo. La memoria a disposizione infatti non permette di elaborare sequenze video in ingresso ad 20

28 alta risoluzione, per poter fare ciò é necessario infatti riallocare la memoria ad ogni ciclo del coarse-to-fine refinement causando un sensibile calo in termini di velocità di calcolo. Il secondo svantaggio é legato alla velocità degli accessi in memoria e al riutilizzo dei dati, le CPU infatti in questo ambito hanno prestazioni migliori rispetto alle memorie delle GPU. Pertanto i codici che presentano un grande riutilizzo dei dati avranno un efficienza maggiore nell implementazione su processore; riutilizzo che é tuttavia presente nell algoritmo a codifica di popolazione. Un ultimo fattore di cui tenere conto quello economico. In questo campo le GPU hanno sicuramente la meglio, non tanto perché costruire una scheda grafica sia più semplice o meno costoso rispetto ad una CPU, ma soprattutto grazie al forte mercato in cui sono inserite le GPU trainato dal settore dei videogame. Le schede grafiche risultano quindi più economiche, se si assume una base di valutazione prestazione/costi, e anche meno dispendiose in termini energetici assumendo prestazioni/watt come base di valutazione. Tuttavia effettuando questo tipo di valutazioni dobbiamo sempre ricordarci di quali sono i limiti delle GPU che hanno un range di applicazioni più limitato rispetto alle CPU e non possono sostituire i processori tradizionali in tutte le loro applicazioni 3.3 CUDA Esaminati i motivi che ci hanno portato ad optare per l implementazione su scheda grafica andiamo ora a presentare brevemente una particolare architettura della NVIDIA sulla quale verrà implementato il nostro algoritmo: l architettura CUDA (Compute Unified Device Architecture). La nostra im- 21

29 plementazione infatti é stata realizzata avvalendosi di librerie compatibili con questa architettura particolare e risulta quindi compatibile con tutte le schede grafiche NVIDIA che siano dotate del supporto specifico. CUDA dispone di numerosi core che co-operano e interagiscono tra di loro scambiandosi vicendevolmente informazioni. Risulta per tanto essere estremamente ottimizzata per il calcolo parallelo, mentre non presenta vantaggi per problemi che richiedono calcolo seriale L architettura Figura 3.3: Schema di una tipica architettura CUDA La figura 3.3 mostra l architettura tipica di una scheda grafica CUDAcompatibile. Nella figura si possono vedere alcuni blocchi fondamentali costituiti da coppie di multi-processori stream, tuttavia il numero di multiprocessori che costituiscono ciascun blocco variano in base alla generazione 22

30 CUDA della scheda. All interno ciascun multi-processore é formato da una serie di processori stream (il cui numero dipende dalla generazione di CUDA a cui appartiene la scheda) che condividono logica di controllo e la memoria cache per le istruzioni. L intero sistema condivide inoltre una memoria globale del tipo GDDR DRAM. Questa memoria diversa dalle RAM delle CPU nelle applicazioni grafiche contiene le texture e le informazioni per il rendering tridimensionale, ma può essere anche utilizzata come un chip di memoria nelle applicazioni non grafiche. La latenza di questa memoria risulta più lunga rispetto alla tradizionale memoria di sistema, tuttavia la grande larghezza di banda compensa almeno in parte questo problema. L architettura CUDA si basa su una struttura gerarchica che si compone di tre elementi fondamentali: le griglie, i blocchi e i thread; organizzati come mostrato in figura 3.4: 23

31 Figura 3.4: Gerarchia dell architettura CUDA Vediamo ora qual é la funzione di ciascun elemento: Griglie: Sono formate da gruppi di thread che vengono eseguiti all interno dello stesso kernel. La CPU utilizza le griglie per eseguire chiamate a CUDA; più griglie possono essere eseguite simultaneamente. Nel caso il sistema sia costituito da più schede grafiche in parallelo non é possibile condividere le griglie tra due GPU diverse. Blocchi: Le griglie si compongono di blocchi, ovvero unità logiche formate da un certo numero di thread coordinati e da una quantità di memoria condivisa. Tutti i thread all interno di un blocco utilizzano lo 24

32 stesso programma. I blocchi non vengono condivisi tra multi-processori diversi. Thread: I blocchi si compongono di thread che vengono eseguiti individualmente dai core di un multi-processore. Ciascuna thread ha a disposizione una certa quantità di memoria di registro L organizzazione della memoria Anche l organizzazione della memoria nell architettura CUDA é di tipo gerarchico ed esistono per tanto diversi tipi di memoria il cui ruolo é schematizzato in figura 3.5: 25

33 Figura 3.5: Organizzazione della memoria CUDA Memoria globale: é una memoria in lettura e scrittura lenta e senza l ausilio di cache. Ha bisogno di letture/scritture sequenziali allineate su 16 byte per essere utilizzata efficientemente. Memoria per le textures: memoria di sola lettura ottimizzata per l accesso spaziale a due dimensioni. Memoria per le costanti: La zona di memoria in cui vengono salvate le costanti e gli argomenti dei kernel. Dotata di cache. 26

34 Memoria Condivisa: E la porzione di memoria che viene condivisa dai thread che appartengono ad uno stesso blocco, per le operazioni di lettura e scrittura. Memoria Locale: viene utilizzata generalmente per tutti i dati che non riescono ad essere salvati nei registri. Non é dotata di cache, ma ha la possibilità di letture e scritture simultanee. Registri: La memoria più veloce a disposizione. Ogni thread ha a disposizione un set di registri per il salvataggio e il recupero veloce di dati come contatori, utilizzati frequentemente dai thread. 3.4 Le Librerie opencv Chiariti quali motivi ci hanno portato a scegliere le schede grafiche per il nostro algoritmo, parliamo ora delle librerie che si sono utilizzate per realizzare la nostra implementazione. Per la realizzazione del progetto abbiamo sfruttato le opencv. Ovvero delle librerie open source che forniscono una serie di funzioni ottimizzate per la computer vision e dotate di un modulo per la programmazione in GPU. Le opencv mettono a disposizione le API per i linguaggi C/C++ le quali sfruttano automaticamente chiamate a CUDA. Queste librerie hanno il vantaggio di essere indipendenti dal sistema operativo, e di essere portabili per sistemi operativi Windows, Linux e Mac Os. Inoltre sono state progettate per sfruttare al meglio la potenza computazionale e con particolare attenzione per la programmazione real-time.[gary Bradski, 2008] Le opencv nascono dall iniziativa di un gruppo di ricerca della Intel che lavorava ad applicazioni ad alta intensità per le CPU. Uno dei membri 27

35 di questa squadra di ricerca visitando le universitá aveva notato che alcuni gruppi universitari avevano sviluppato internamente infrastrutture per la computer vision e che ogni studente lasciava in eredità ciò che aveva realizzato come punto di partenza per le ricerche successive di altri studenti. Allo stesso modo le opencv sono state concepite per creare strutture per la computer vision accessibili a tutti. La nostra scelta é stata quella di utilizzare le API di C++ delle opencv per creare un programma che fosse orientato agli oggetti, utilizzando le funzioni messe a disposizione dal modulo GPU Il modulo GPU Le opencv mettono a disposizione diversi moduli di programmazione, ciascuno orientato ad uno scopo ben preciso. Il modulo maggiormente utilizzato da noi é quello per lo sviluppo di applicazioni per GPU. Questo modulo richiede una scheda grafica che sia CUDA-compatibile in quanto progettato per sfruttare questo tipo di architettura, chiamando funzioni da linguaggi ad alto livello come C/C++. Utilizzando questo modulo tuttavia é necessario prestare attenzione ad alcuni particolari quando si procede nella programmazione, al fine di ottenere il miglior risultato possibile dal punto di vista delle prestazioni in termini di velocità di esecuzione. Il modulo GPU é stato sviluppato in maniera che sia il più simile possibile ai moduli che vengono utilizzati per la programmazione delle CPU, tuttavia la scheda grafica ha la propria memoria interna e prima di poter elaborare i dati tramite processore grafico é necessario effettuare l upload degli stessi sulla memoria della GPU. Ciò avviene tramite la chiamata del metodo upload(gpumat m) della classe Mat che permette di caricare i dati presenti nella struttura Mat, utilizzata 28

36 per la programmazione CPU, nella sua controparte GpuMat utilizzata per la computazione GPU. In questo passaggio é necessario prestare particolare attenzione, infatti va scelto attentamente il numero di canali utilizzato dall algoritmo al fine di ottenere un codice efficiente per la GPU. Generalmente é preferibile utilizzare uno o quattro canali con la dimensione char o float per gli elementi, altri tipi di dato possono sollevare errori o eccezioni con l utilizzo di alcune funzioni.[gábor, ] Nel nostro algoritmo elaboriamo una sequenza di immagini a canale singolo in bianco e nero utilizzando elementi float a 32-bit (CV 32FC1). Nella scrittura del codice una particolare attenzione va dedicata alla gestione della memoria, infatti le allocazioni di memoria sono onerose in termini di tempo ed é pertanto buona norma eseguire le allocazioni una volta sola all interno del programma al fine di ottenere prestazioni migliori. Il modulo GPU, inoltre, fornisce una serie di funzioni ottimizzate per le operazioni elemento-per-elemento tra matrici le quali vengono utilizzate ampiamente nell implementazione del codice, con incremento delle prestazioni rispetto ad un approccio che prevede l accesso al singolo elemento di ciascuna matrice La Classe GpuMat Dedichiamo una piccola sezione alla descrizione della struttura GpuMat, la quale costituisce il tassello fondamentale per lo sviluppo della nostra implementazione. Le informazioni delle immagini contenute nella sequenza in ingresso vengono infatti caricate nella memoria della scheda grafica ed elaborate grazie alla struttura fornita da questa classe. Le GpuMat sono contenitori adatti a contenere informazioni relative ad immagini bidimensionali 29

37 ed hanno una struttura molto simili a quella di una matrice, tuttavia tengono in memoria anche altre informazioni che rendono la loro struttura più complicata rispetto a quella di un semplice array. Le GpuMat sono costituite da due parti fondamentali, un intestazione (header) e la matrice dati. L header contiene alcune informazioni sui dati contenuti nella matrice dati come ad esempio il numero di righe e di colonne, il numero di canali e la dimensione degli elementi della matrice. All interno dell intestazione vi é un puntatore alla zona di memoria in cui sono salvate le informazioni vere e proprie. La matrice dati infatti é la zona di memoria in cui sono contenuti i valori associati a ciascun elemento della matrice. La sua organizzazione é simile a quella degli array tuttavia le locazioni contenenti i dati non sono continue come mostra la figura 3.6: Figura 3.6: Occupazione della memoria in GpuMat 30

38 L esempio mostra l organizzazione della memoria per una matrice 1000 x 500 a tre canali con dimensione di interi senza segno ad 8-bit. In alto si può vedere una riga di codice che viene utilizzata per chiamare il costruttore per la suddetta matrice. Nelle righe sottostanti viene mostrato come avviene l accesso ad un elemento tramite indici: image.data é il puntatore alla locazione di memoria contenete il primo elemento dell array. image.step indica la lunghezza di una riga in memoria image.ptr(y) é un metodo che restituisce il puntatore al primo elemento della riga y image.channels() é un metodo che restituisce il numero di canali Da notare che la lunghezza di una riga in memoria é diverso dal numero di colonne moltiplicato per la dimensione di un elemento. Infatti come già detto l area di memoria in cui vengono salvati i dati non é continua, ma in fondo ad ogni riga vi sono alcune locazioni lasciate libere, per questa caratteristica é buona norma non utilizzare vettori colonna ai fini della gestione della memoria. Va sottolineata una certa indipendenza tra l header e la matrice dati, infatti l intestazione può essere creata a priori senza che la matrice dati contenga alcun dato significativo, in tal caso il puntatore alla matrice dati contenuto nell header viene contrassegnato come bad-ptr per indicare che la matrice dati non contiene alcun dato significativo. 31

39 Capitolo 4 L implementazione 4.1 Decomposizione piramidale L algoritmo prevede inizialmente una decomposizione piramidale. Lo scopo di tale passaggio é avere diverse copie (n) - tutte a risoluzione diversa - delle immagini in ingresso. Prima però si rende necessaria una pre-elaborazione dei frame in input al sistema: entriamo quindi nella fase di border padding. Sorge infatti il problema delle dimensioni: per poter ottenere sei scale diverse, dobbiamo essere sicuri che le immagini di partenza abbiano un numero di righe e colonne tale da poter essere diviso per due sei volte. Nel caso in cui tale condizione non sia soddisfatta utilizzamo la funzione gpu::copymakeborder(), con parametro BorderType = Replicate. Chiediamo cioè alla funzione di replicare i bordi dell immagine originaria per farle ottenere le dimensioni adatte all algoritmo. int sx1 = sequence [0]. cols, sy1 = sequence [0]. rows, sx2, sy2 ; 32

40 int fac = pow (2.0, g_nscales ); sx2 = ceil (( double ) sx1 / fac )* fac ; sy2 = ceil (( double ) sy1 / fac )* fac ; /////// sequence contiene i frames a grandezza naturale if ( ( sx1!= sx2 ) ( sy1!= sy2 ) ) for ( frame =0; frame < g_nframes ; frame ++) gpu :: copymakeborder ( sequence [ frame ], scalevector [ g_nscales -1][ frame ],0,sy2 -sy1,0,sx2 -sx1, BORDER_REPLICATE,0, stream ); else for ( frame =0; frame < g_nframes ; frame ++) sequence [ frame ]. copyto ( scalevector [ g_nscales -1][ frame ]); Nella figura 4.1un esempio: Una volta replicati i bordi si può fare un presmoothing delle immagini, al fine di tagliare le frequenze troppo alte che impedirebbero di rispettare la frequenza di sottocampionamento. Quindi si può passare al sottocampionamento. Nella nostra implementazione abbiamo usato la funzione gpu::pyrdown che si prende il compito sia di effettuare il prefiltraggio sia di diminuire la risoluzione. In particolare, andando sul reference delle opencv [opencv deve- 33

41 Figura 4.1: Input e Output della border padding lopment team, 2012] si può vedere che si utilizza il filtro gaussiano 5x5 pixel mostrato in figura 4.2 Figura 4.2: Filtro Gaussiano utilizzato dalla funzione gpu::pyrdown Alla fine di questa prima fase abbiamo quindi riempito la struttura ScaleVector con gli undici frame in ingresso a n risoluzioni differenti. Questa particolare funzione va chiamata una sola volta. L algoritmo lavora su undici immagini, ma man mano che arrivano nuove immagini da elaborare é possibile -anzi, al fine delle prestazioni necessario - tenere conto dei precedenti risultati. In questo modo viene prefiltrata e scalata solo la nuova immagine in ingresso al sistema e non di nuovo anche le dieci precedenti. 34

42 La struttura scalevector viene quindi liberata dopo il primo ciclo, lasciando spazio per un altra struttura che contiene le n scale del frame più recente: gpu::gpumat *PyrOut. 4.2 Filtraggi spazio-temporali In questa fase vengono filtrati gli undici frame medianti i filtri di Gabor. Sarebbe un procedimento computazionalmente molto oneroso, poiché si tratta di filtraggi su tre dimensioni ( le due dimensioni spaziali più quella temporale). Qui entra in gioco la possibilitã di decomporre i filtri di Gabor in due parti: una che si occupa della parte spaziale e una che si occupa della parte temporale. Andiamo a trattare separatamente i due diversi filtraggi Filtraggi spaziali Bisogna convoluire le undici immagini a risoluzione più bassa con dei filtri di Gabor orientati. Lo scopo é ottenere in uscita per ogni immagine trentadue matrici, ognuna che porta informazione riguardante un diverso orientamento - sia di parte reale che della parte immaginaria-. Utilizziamo filtri che dividono i 2π radianti in multipli di π. Si può dimostrare che non é necessario utilizzare 8 sedici diversi filtri per ogni immagine. L informazione riguardante gli angoli da π a 2π la otteniamo dai primi otto orientamenti. Per quello che riguarda la parte reale, essendo una funzione pari, semplicemente copiando i primi orientamenti. Per la parte immaginaria (funzione invece dispari) cambiando il segno dei primi orientamenti. 35

43 A questo punto viene immediato utilizzare la funzione gpu::filter2d() che effettua una convoluzione bidimensionale dell immagine in ingresso. Ma é possibile migliorare ulteriormente le performance dell implementazione scomponendo ancora i filtri bi-dimensionali in filtri monodimensionali, e convoluire prima rispetto ad una dimensione e poi rispetto all altra sfruttando la funzione gpu::sepfilter2d(). gpu :: sepfilter2d ( input, output, CV_32F, kernelx, kernely ); Nonostante queste ottimizzazioni alcuni filtraggi monodimensionali venivano ancora ripetuti, rallentando l esecuzione del programma. Abbiamo quindi sfruttato il metodo operator() abbiamo disaccoppiato il filtraggio per colonne dal filtraggio per righe, in modo da riutilizzare più volte alcuni risultati senza doverli ricalcolare. In questo modo siamo passati da trentadue filtraggi bi-dimensionali a venticinque filtraggi mono-dimensionali. filtercol1 -> operator ()( scalevector [ scale ][ frame ],T1 [ scale ], stream ); filterrow1 -> operator ()(T1[ scale ], G_spaceRe [ scale ][0][ frame ], stream ); filterrow2 -> operator ()(T1[ scale ], G_spaceIm [ scale ][0][ frame ], stream ); Come si vede nel codice, per parte reale ed immaginaria dell orientamento 0π utilizziamo due volte il filtraggio per colonne, calcolandolo però una sola volta. 36

44 I risultati vengono salvati in un array circolare chiamato unifiedspace. Mediante tale particolare struttura dati é possibile infatti elaborare soltanto le nuove immagini in ingresso tenendo conto dei vecchi risultati, così come avevamo fatto nella parte di decomposizione piramidale Filtraggi temporali La parte temporale dei filtraggi di Gabor si può implementare mediante somme pesate di parte reale ed immaginaria degli undici frame precedenemente filtrati con i filtri di Gabor orientati. I pesi non sono nient altro che le funzioni f(t) in equazione 4.1 e 4.2. Tali filtri possono avere supporto temporale variabile (nel nostro caso, undici pixel). Noi abbiamo usato dei filtri sensibili a cinque velocità diverse. Ricaviamo quattro matrici temporanee che, combinate tra loro con addizioni o sottrazioni, forniscono il risultato del filtraggio spazio-temporale. Chiamati ftc e fts ( Filtro Temporale Coseno e Filtro Temporale Seno ) i filtri temporali, possiamo scrivere GaborT Re,orient = frames i=0 (GaborS Re,orient ftc i GaborS Im,orient fts i ) (4.1) GaborT Im,orient = frames i=0 (GaborS Re,orient fts i + GaborS Im,orient ftc i ) (4.2) dove GaborT sono i risultati dei filtraggi spazio-temporali, GaborS i risultati dei filtraggi spaziali. Le somme pesate e le combinazioni delle matrici temporanee vanno fatte per ogni singolo orientamento. 37

45 Abbiamo utilizzato la funzione gpu::addweighted(). Implementando i filtraggi temporali in questa maniera risulta necessario effettuare 11(frame) x 16 (orientamenti) x 5 (velocità ) x 2 (parte reale e parte immaginaria) x 2 = 3520 somme per ogni scala. Eseguendo dei test abbiamo notato che eseguire questa parte di codice risultava molto dispendioso in termini di tempo. Inoltre abbiamo riscontrato un incoerenza: eseguire il codice su una scheda video GeForce 525M GTX con 96 core non portava a grandi vantaggi rispetto ad eseguirlo su una GeForce 8800 GTS con 16 Core. Il motivo risiede nel fatto che scritto così il codice chiedeva alla scheda grafica di effettuare larga parte delle 3520 somme sequenzialmente, di fatto annullando i vantaggi dall usare un architettura dotata di molti core. Abbiamo pensato di unire l informazione dei diversi orientamenti e di parte reale e immaginaria in un unica matrice. La filosofia é di fare meno elaborazione su matrici più grandi: questo per favorire l utilizzo in parallelo delle centinaia di core delle più moderne schede grafiche. T 1 = T 2 = frames i=0 frames i=0 (GaborS ftc i ) (4.3) (GaborS fts i ) (4.4) Combinando le opportune righe e colonne delle matrici temporanee T1 e T2 arriviamo agli stessi risultati di prima, con un costo computazionale decisamente più esiguo: siamo riusciti a passare da 3520 a sole 110 somme. GaborT Re = frames i=0 (T 1 r,0:c 16 T 2 r,c 16:c 32 ) (4.5) 38

46 frames GaborT Im = (T 1 r,c 16:c 32 + T 2 r,c 0:c 16 ) (4.6) i=0 dove r é il numero di righe di una matrice il cui contenuto informativo é di un solo orientamento. 4.3 Energia e calcolo della componente di velocità lungo un orientamento A questo punto nelle strutture GaborR e GaborI rispettivamente la parte reale e la parte immaginaria del risultato dei filtraggi spazio-temporali. Partendo da queste informazioni si può stimare la velocità lungo un dato orientamento. Per ragioni di performance abbiamo compattato le informazioni su tutti gli orientamenti in una sola matrice. Abbiamo quindi 6(scale)x5(velocità )x2(re e Im) = 60 matrici. Per prima cosa calcoliamo l energia : E vel = per i cinque valori di velocità. Ora applichiamo la formula del centro di gravità Re 2 vel + Im2 vel (4.7) v θ c = Mi=1 (v θ i E θ,vel ) Mi=1 (E θ,vel ) (4.8) In tale formula ogni matrice dipende dall angolo theta e, quindi, dall orientamento. Compattando tutti gli orientamenti in una matrice di dimensioni maggiori ottieniamo una formula semplificata che riduce sensibilmente 39

47 il costo computazionale: v c = Mi=1 (v i E vel ) Mi=1 (E vel ) (4.9) Moltiplicando tale matrice per la funzione coseno e per la funzione seno otteniamo le due componenti della stima della velocità per ogni orientamento. Fondamentale in questa fase dell algoritmo prestare grandissima attenzione ai valori non validi. Ogni divisione fatta abbiamo tenuto conto dei valori nulli a denominatore e, prima di compiere effettivamente l operazione, mediante tale maschera abbiamo modificato il denominatore. In questo modo abbiamo evitato divisioni per zero, cosa che avrebbe portato ad un inesorabile propagarsi di NaN ( not a number ). Poiché lavorando con le GPU non é possibile accedere pixel per pixel, abbiamo ricorso a dei confronti con matrici delle opportune dimensioni inizializzate a zero. Ecco in un esempio semplificato il procedimento: gpu :: compare ( denominatore, zeros, mask, CMP_EQ, stream ); denominatore. setto ( Scalar (0.01), mask ); gpu :: bitwise_or ( mask, global_mask, global_mask ); L informazione contenuta in queste maschere é stata mantenuta in una variabile globale, poiché servirà sapere anche ad altre funzioni quali saranno i dati validi sui quali operare e quali no. Un problema riscontrato nel passaggio concettuale ad operare con matrici più grandi, contenenti informazioni su tutti gli orientamenti, é stato quando abbiamo dovuto moltiplicare il risultato del centro di gravità con seno e 40

48 coseno di theta. overload: Le OpenCV infatti offrono la funzione multiply con due void gpu :: multiply ( const GpuMat & a, const GpuMat & b, GpuMat & c, double scale =1, int dtype =-1, Stream & stream = Stream :: Null () ) void gpu :: multiply ( const GpuMat & a, const Scalar & sc, GpuMat & c, double scale =1, int dtype =-1, Stream & stream = Stream :: Null () ) Possiamo per cui moltiplicare una matrice con uno scalare (come serve a noi) o due matrici. Quando abbiamo condensato il contenuto informativo dei diversi orientamenti in un unica matrice non potevamo più ricorrere a nessuno dei due metodi disponibili. Si é reso necessario costruire una struttura per la funzione pari e una per le funzioni dispari. Ognuna di tali matrici doveva avere valori costanti a gruppi di r righe, dove r é il numero di righe della matrice dello scale corrente. 41

49 cos(0) 0,0 cos(0) 0,1... cos(0) 0,c cos(0) 1, cos(0) r, cos(0) r,c cos( π 8 ) (r+1),0 cos( π 8 ) (r+1),1... cos( π 8 ) (r+1),c cos( π 8 ) (r+2), cos( π 8 ) r 2, cos( π 8 ) r 2,c cos( 15π 8 ) r 16, cos( 15π 8 ) r 16,c Analogamento per la funzione seno. Una volta inizializzate queste matrici é possibile implementare agevolmente la moltiplicazione: gpu :: multiply ( M1, cose [ scale ], ComponentReBig, 1, -1, stream ); gpu :: multiply ( M1, sen [ scale ], ComponentImBig, 1, -1, stream ); 4.4 Full Velocity : stima del flusso ottico A questo punto dobbiamo combinare le componenti di velocità per ottenere la stima del flusso ottico. In questa fase aggiorniamo i valori della maschera che tiene conto dei pixel invalidi. Alla fine del procedimento dove l algoritmo 42

50 non é riuscito a dare una stima accettabile del flusso settiamo al valore zero. Otteniamo due matrici che contengono valori corrispondenti alla proiezione della velocità lungo gli assi x e y. Tali valori hanno come unità di misura i pixel per frame. Abbiamo ora una stima del flusso alla prima scala, quindi a partire dalle immagini con risoluzione più bassa. L algoritmo fino a questo punto é riuscito a trarre informazioni su una certa banda di frequenze dell immagine di partenza. Passando alla scala successiva senza cambiare filtri l algoritmo sarà ricettivo verso componenti a frequenze maggiori. Per ogni scala ripercorriamo quindi i passi appena visti, aggiungendo alcune parti per tener conto dei risultati ottenuti nelle scale precedenti. 4.5 Livelli successivi della piramide : il coarseto-fine refinement Expand Finita l elaborazione dell immagine a risoluzione più bassa, i risultati vengono espansi. Si moltiplica per due il risultato perché, raddoppiando le dimensioni dell immagine col passaggio alla scala successiva, il movimento stimato ha un peso doppio. Inoltre raddoppiando le dimensioni sorge il problema di calcolare il valore dei nuovi pixel. Nell implementazione abbiamo invocato il metodo gpu::pyrup() : aggiunge dei pixel a zero nei punti dove non ha informazione e successivamente convoluisce con un filtro Gaussiano con lo stesso kernel della funzione gpu::pyrdown() moltiplicato per 4 [opencv development team, 2012]. Sarebbe stato possibile effettuare altre scelte : o 43

51 utilizzare la funzione gpu::remap() o utilizzare la funzione gpu::resize(). In particolare quest ultima offriva il vantaggio di utilizzare l interpolazione bilineare per calcolare i valori sconoscuti. Facendo dei test risulta però lievemente più veloce la soluzione da noi adottata Filtraggio spaziali Nei livelli successivi della piramide si richiama la stessa funzione descritta precedentemente, che esegue gli stessi calcoli con le immagini a più alta risoluzione Warping Il flusso ottico calcolato al livello precedente viene replicato per ogni frame mediante delle moltiplicazioni, tenendo il frame centrale come istante temporale iniziale. Quindi usiamo i risultati ottenuti per calcolare i domini che andremo ad utilizzare per fare il warping. Questa tecnica permette di ridurre le distanze tra i punti corrispondenti della sequenza, pertanto deve essere calcolato solo il flusso ottico residuo. Per il warping sfruttiamo la funzione di libreria gpu::remap() che ha proprio lo scopo di rimappare l immagine in ingresso con dei domini passati dall utente. I domini gli abbiamo calcolati combinando il flusso ottico espanso con i domini cartesiani che sono stati calcolati una volta per ogni scala all inizio del procedimento in un apposita funzione d inizializzazione. Così facendo il costo computazionale non pesa ad ogni iterazione sui tempi d esecuzione del programma. 44

52 la variabile r prima del codice sopracitato aveva il valore del numero di righe dell immagine in ingresso alla scala presa in esame. Abbiamo moltiplicato r*24 perché le matrici che contengono informazione di tutti gli orientamenti sono le matrici originarie incolonnate l una sotto l altra. Avendo ventiquattro matrici (otto per gli orientamenti della parte reale e sedici per gli orientamenti della parte immaginaria), il risultato non potrà che avere le dimensioni (r*24,c). Con il seguente frammento di codice ricaviamo i domini ed eseguiamo il warping dei filtraggi spaziali: for ( int frame =0; frame < g_nframes ; frame ++) { for ( int orient = 0; orient < g_norient + g_norient /2; orient ++) { Vx[ scale ][ frame ]. copyto ( Vxbig [ scale ]( Range (r * orient,r*( orient +1) ),Range :: all ())); Vy[ scale ][ frame ]. copyto ( Vybig [ scale ]( Range (r * orient,r*( orient +1) ),Range :: all ())); } gpu :: subtract (X[ scale ], Vxbig [ scale ], Xnbig [ scale ], mask [ scale ],-1, stream1 ); gpu :: subtract (Y[ scale ], Vybig [ scale ], Ynbig [ scale ], mask [ scale ],-1, stream2 ); //////////////////// WARPING gpu :: remap ( unifiedspace [ scale ]. read ( frame ), warp [ scale ][ frame ], Xnbig [ scale ], Ynbig [ 45

53 scale ], INTER_LINEAR, stream ); } Vxbig e Vybig, ovvero le matrici di dimensioni (r*24)*c, dipendono come Vx e Vy dal tempo. Per non occupare spazio in memoria le calcoliamo ad ogni iterazione del ciclo for che scorre i frame, le usiamo per ricavare i domini e poi sovrascriviamo. Utilizziamo invece la dimensione [scale] per motivi di costo computazionale. Se non la usassimo dovremmo ad ogni iterazione del coarse to fine disallocare la matrice e riallocarne una di dimensioni diverse Filtraggi temporali I filtri temporali e le modalità di filtraggio rimangono le stesse viste nella scala a risoluzione più bassa. L unica cosa che cambia in questa fase una volta entrati nel coarse-to-fine é la struttura da cui si prendono le immagini in ingresso. Non più nell array circolare ma in un array di matrici che tiene conto dei risultati del warping senza andare ad intaccare i filtraggi spaziali. Infatti le informazioni contenute in UnifiedSpace (l array circolare) devono rimanere inalterate al fine di essere riutilizzate quando entrerà un nuovo frame in ingresso al sistema. Per tener conto dei diversi momenti in cui viene chiamata la funzione population optical flow::filtgabortime() viene passato un parametro int scale, che fornisce indicazione della scala che si sta elaborando. 46

54 4.5.5 Component Velocity e Full Velocity Nelle scale successive alla prima tali funzioni si ripetono allo stesso identico modo visto nella scala a risoluzione più bassa Merge Flow Con la funzione population optical flow::merge flow() combiniamo i risultati delle differenti scale. In questo modo il flusso ottico risultante alla fine della coarse-to-fine sarà dato dal contributo apportato da ogni scala e, quindi, dal contributo di filtri spazio-temporali sensibili a diverse frequenze dell immagine. Nell implementazione abbiamo semplicemente usato la funzione di libreria gpu::add() per sommare il flusso ottico espanso della scala precedente con il flusso ottico della scala attuale (in uscita dalla funzione population optical flow::full velocity() ). 4.6 Gestione della memoria Nello sviluppare il codice abbiamo notato che deallocare e allocare GpuMat ha un forte impatto sulle prestazioni. La gestione della memoria della scheda grafica é un punto nevralgico della programmazione GPU. Per questo motivo abbiamo pensato di utilizzare quasi esclusivamente variabili di classe, in maniera che non dovessero venire deallocate ad ogni metodo invocato. Inoltre per la particolarità dell algoritmo (i.e., per l approccio piramidale) é sorta la necessità di allocare una copia di ogni variabile per ogni scala. Così facendo dopo la prima coarse-to-fine tutte le strutture risultano già allocate e, da quel momento in poi, non ci saranno più sprechi di tempo per gestire la 47

55 memoria e il tempo trascorso sarà di effettivo calcolo (filtraggi, moltiplicazioni, somme). Abbiamo implementato una funzione ( init structures() ) che chiamiamo appena conosciamo la risoluzione delle immagini in ingresso. Ha il compito di allocare le variabili di classe per ogni scale, oltre che di inizializzare alcune matrici di cui, note le dimensioni, si può calcolare il contenuto. Ci riferiamo in particolare a parte dei domini utilizzati nella funzione distribut optic and warp() o le matrici con seno e coseno di theta utilizzati nella funzione component velocity(). Questo tipo di approccio ha come principale svantaggio l ingente quantitativo di variabili allocate anche se non utilizzate nell immediato. Per i nostri scopi e con i nostri mezzi é stato un prezzo non esagerato da pagare. Volevamo infatti implementare una versione più veloce possibile di tale algoritmo, e avevamo a disposizione modelli di schede grafiche con quantitativi di memoria superiori o uguali ad 1 GB: nvidia GeForce 525M / 680 GTX. Partendo dal nostro codice é comunque immediato implementare una versione light che richieda meno memoria in maniera da garantire piena compatibilità (CUDA é utilizzabile su schede grafiche a partire dalla serie nvidia GeForce 8, con quantitativi di memoria disponibili variabili tra 256 MB e 640MB per le serie meno recenti). Le uniche variabili che é assolutamente necessario mantere di classe sono quelle che contengono i dati che sarebbe troppo oneroso ricalcolare ( i.e. i filtraggi spaziali dei frame precedenti) o quelle che servono a più d una funzione. 48

56 Capitolo 5 Test e risultati In questo capitolo tratteremo la parte relativa ai test che sono stati effettuati per verificare la correttezza dell algoritmo implementato, dai test più semplici come quello del Random Dot ai test più specifici come quelli per il calcolo dell errore angolare, impiegando sequenze sintetiche di cui si conosce il flusso ottico reale. Dopo aver verificato la correttezza dell algoritmo abbiamo eseguito anche alcuni test sulle prestazioni del nostro programma in termini di velocità di calcolo e utilizzo della memoria, mettendo a confronto i risultati emersi da test realizzati su schede grafiche differenti. 5.1 La visualizzazione del flusso ottico Il flusso ottico è un campo vettoriale che contiene le informazioni sulla velocità per ogni punto presente nella sequenza video. Ottenute tali informazioni sorge la necessità di trovare un modo di decodificare i risultati ottenuti in maniera che siano intuitivamente comprensibili. Per il nostro lavoro abbia- 49

57 mo individuato due tra gli approcci presenti in letteratura: il metodo quiver presente nel ambiente Matlab e la codifica di colore tratta dal sito del college americano di Middlebury. [Middlebury Academic, ] La prima tecnica consiste nel rappresentare i vettori del campo vettoriale utilizzando delle frecce, mentre con il secondo metodo ricorre ad una particolare colorazione dell immagine alla quale é associata una codifica del movimento tramite una colormap, ovvero una mappa che ad ogni colore fa corrispondere verso, intensità e direzione del vettore, come mostrato in figura 5.1. Avendo utilizzato nella maggior parte dei test le sequenze disponibili sul sito Middlebury spesso abbiamo preferito la soluzione della codifica di colore. Nelle figure 5.2 e 5.3 proponiamo un confronto tra i due approcci sulla sequenza rubik s cube [Stuart Russel, 1995]. test color pattern Figura 5.1: Codifica di colore 50

58 Figura 5.2: Rubik: Quiver Figura 5.3: Rubik: Color s code 5.2 Il random dot sequence test Il primo test che abbiamo effettuato é stato quello sulla sequenza sintetica chiamata Random Dot. Questo particolare test fornisce una prima indicazione sul funzionamento dell algoritmo, infatti la sequenza in ingresso viene generata in modo tale che il movimento sia direzionato lungo un solo orientamento, a velocità nota. La sequenza si compone di uno sfondo e di un quadrato che si muove su di esso con una velocità predefinita. I valori associati allo sfondo ed al quadrato in movimento sono generati in modo casuale, in modo che possano essere rilevati dai filtri utilizzati per la nostra implementazione. Infatti i filtri spaziali che abbiamo utilizzato sono passabanda e quindi insensibili alla componente continua, se si fosse utilizzato un quadrato ed uno sfondo uniformi non sarebbe stato possibile effettuare una stima attendibile. Nel nostro caso abbiamo scelto una velocità di 1 pixel/frame e 51

59 8 diverse direzioni nello spazio da 0 a 2π a multipli di π. Una volta ottenuti 8 i risultati abbiamo verificato che intensità, direzione e verso del flusso ottico fossero coerenti con la nostra scelta iniziale. Nella figura 5.4 proponiamo i risultati ottenuti con un random dot visualizzati tramite codifica di colore. test color pattern Figura 5.4: Random Dot 5.3 Precisione e affidabilità della stima del flusso ottico In questa sezione approfondiremo la fase di testing dedicata alla precisione del nostro algoritmo. Dopo aver effettuato il primo test del random dot, abbiamo scelto di analizzare alcune sequenze sintetiche per poter stimare l 52

60 affidabilità della stima prodotta dal nostro algoritmo attraverso l analisi dell errore angolare. Dato il flusso ottico possiamo esprimere un vettore direzione nello spazio-tempo (u, v, t) T, dove u, v sono le componenti del vettore nello spazio e t la componente nel tempo secondo la formula: v 1 u2 + v (u, v, t)t (5.1) Da qui dato il vettore v c stimato dal nostro algoritmo e noto il vettore v e del flusso ottico che si vuole stimare si può calcolare l errore angolare come lo scostamento tra i due vettori v c e v e avvalendosi della la seguente formula: ψ E = arccos( v c v c ) (5.2) Sequenze sintetiche Siamo dunque partiti da una serie di sequenze sintetiche di cui si conosce il ground truth, ovvero il valore esatto del flusso ottico che si vuole stimare, e abbiamo calcolato l errore angolare commesso nella stima dal nostro algoritmo. Per le diverse sequenze sono stati utilizzati filtri temporali con base da 7 o 11 frame, a seconda dei casi ottenendo i risultati riportati in tabella

61 Sequenza Frame Errore medio Deviazione standard Grove Grove Urban Urban Hydrangea RubberWhale Translating Tree Diverging Tree Yosemite Yosemite Tabella 5.1: Risultati AAE su sequenze note Nei test svolti viene anche indicato il valore relativo alla densità del campo vettoriale. La voce density esprime la percentuale di valori validi in rapporto ai valori stimati dal nostro algoritmo. Non avendo applicato soglie sull energia la density risulta pari al 100% per tutti i test effettuati. Per tutte le sequenze da 7 frame il test é stato effettuato ecludendo l ultimo frame di ciascuna delle sequenze analizzate. Quest ultime si compongono infatti di 8 frame, ma per questioni di implementazione la base temporale utilizzata per l algoritmo deve avere un numero dispari di frame e per questa ragione abbiamo deciso di eseguire i test prendendo in considerazione solo i primi 7 frmaes di ogni sequenza. Da questi dati si può trarre spunto per un confronto sulla precisione dell algoritmo di partenza implementato in ambiente Matlab e l implementazione GPU sull errore medio. 54

62 Implementazione Yosemite Hydrangea RubberWhale Matlab Modulo GPU Figura 5.5: Ground Truth Figura 5.7: RubberWhale sequence Figura 5.6: Flusso stimato Figura 5.8: Ground Truth Figura 5.10: Hydrangea sequence Figura 5.9: Flusso stimato 55

63 5.3.2 Sequenze Reali I test sulle sequenze reali sono il vero banco di prova per valutare l affidabilità della nostra implementazione. Il caso reale é ovviamente il più complicato: tutti gli approcci per il calcolo del flusso ottico necessitano di avere una luminosità pressoché costante, almeno rapportata alla frame rate applicata in acquisizione. Naturalmente questa ipotesi di fondo non é praticamente mai verificata nei casi reali. Riuscire ad avere un implementazione robusta a rumori pervasivi come quello di una luminosità fortemente discontinua sarebbe indice di un ottimo lavoro. Figura 5.11: Walking 56

64 Figura 5.12: Dog Dance Figura 5.13: Mano che si muove verso destra lungo l asse x, webcam 5.4 Le prestazioni dell algoritmo In questa sezione esponiamo i risultati dei benchmark da noi eseguiti, relativi a prestazioni in termini di velocità di calcolo e occupazione della memoria per il nostro algoritmo. I test sono stati svolti su due schede grafiche diverse: Nvidia GeForce 8800 Gts e Nvidia GeForce 525M Gtx. Abbiamo svolto test al variare dei parametri fondamentali dell algoritmo (numero di scale, supporto temporale) e per differenti risoluzioni di immagini 57

65 in ingresso. Le schede su cui abbiamo lavorato sono schede di generazioni diverse traendo spunto per indagare come cambiamenti di tecnologia produttiva e architettura incidano poi sulle prestazioni finali. La nvidia GeForce 8800 GTS ha 128 Core, 512 MB di memoria dedicata, interfaccia a 256 bit e banda di memoria di 64 GB/s. La nvidia GeForce 525M GTX ha 96 core, 1 GB di memoria dedicata, interfaccia a 128 bit e banda di memoria di 28.8 GB/S. Nonostante le specifiche tecniche dipingano la GeForce 8800 GTS come una potenzialmente migliore, in realtà il processo produttivo, la generazione e l architettura svolgono un ruolo fondamentale. La GeForce 8800 GTS appartiene alla serie 8, ed é entrata in commercio nel Dicembre del Il processo produttivo é 90nm. La 525M appartiene alla serie 500 uscita nel 2011, la cui tecnologia produttiva é a 40nm. Queste differenze sostanziali sono emerse in maniera evidente durante lo svolgimento dei test. Per immagini piccole (fino a 128x128) la differenza di velocità tra le due schede non é eccessiva: si attesta tra il 15% e il 30%. Aumentando la risoluzione delle immagini in ingresso invece il divario si fa maggiore. Dall analisi delle prestazioni si evince che il tempo di esecuzione dell algoritmo cresce più lentamente rispetto alla risoluzione delle immagini in ingresso. Si passa da 0.121s con 4096byte a 0.480s con byte: da 135 kbyte/s a kbyte/s, sintomo di un utilizzo più efficiente dell architettura della scheda grafica a livello di dati elaborati in parallelo. Variare il supporto dei filtri temporali permettere di ottenere, a parità di numero di scale e di risoluzione, uno speed-up fino al 30%. Variare il numero di scale a parità degli parametri porta invece ad uno speed-up massimo del 58

66 12-15%. Qualitativamente però abbiamo notato che cambiare il supporto temporale da 11 a 7 frame influisce maggiormente sulla precisione nella stima del flusso, rispetto alla diminuzione del numero di scale Metodologia di acquisizione dei tempi. Per acquisire i tempi abbiamo adottato una metodologia ben precisa. Il nostro algoritmo é stato pensato in maniera da concentrare tutte le operazioni più onerose in termini di trasferimenti di memoria in un primo ciclo di inizializzazione. Per i frame acquisiti successivamente il programma raggiunge il regime di funzionamento. Per prendere i tempi abbiamo usato due metodi delle librerie OpenCV, cv::gettickcount() e cv::gettickfrequency(). Abbiamo preso i tempi dopo la fase iniziale, una volta acquisito il frame successivo. Quindi i tempi mostrati nelle tabelle di questo capitolo tengono conto dell elaborazione eseguita a partire dal filtraggio spazio-temporale della scala a risoluzione più bassa fino alla merge() finale. I tempi mostrati sono, se non specificato diversamente, tempi medi. 59

67 5.4.2 Tabelle randomdot 64x64, 11 frame Scale Tempo di esecuzione Minimo 6 scale s 0.117s 5 scale s 0.099s 4 scale s 0.081s 3 scale s 0.062s randomdot 64x64, 11 frame Scale Tempo di esecuzione Minimo 6 scale s min 0.144s 5 scale s min 0.122s 4 scale s min 0.093s 3 scale s min 0.069s Figura 5.14: NVidia GeForce 525M Figura 5.15: NVidia GeForce 8800 randomdot 128x128, 11 frame: Scale Tempo di esecuzione Minimo 6 scale s 0.200s 5 scale s 0.180s 4 scale s 0.157s randomdot 128x128, 11 frame Scale Tempo di esecuzione Minimo 6 scale s 0.240s 5 scale s 0.205s 4 scale s 0.165s Figura 5.16: NVidia GeForce 525M Figura 5.17: NVidia GeForce 8800 randomdot 128x128, 7 frame Scale Tempo di esecuzione Minimo 6 scale s 0.160s 5 scale s 0.140s 4 scale s 0.122s 3 scale s 0.102s Figura 5.18: NVidia GeForce 525M randomdot 128x128, 7 frame Scale Tempo di esecuzione Minimo 6 scale s 0.206s 5 scale s 0.171s 4 scale s 0.137s 3 scale s 0.107s Figura 5.19: NVidia GeForce

68 randomdot 256x256, 7 frame Scale Tempo di esecuzione Minimo 6 scale s 0.472s 5 scale s 0.446s Figura 5.20: NVidia GeForce 525M randomdot 256x256, 11 frame Scale Tempo di esecuzione Minimo 6 scale s 0.699s 5 scale s 0.661s Figura 5.21: NVidia GeForce 525M randomdot 11 frame, 6 scale Dimensioni ingresso Memoria utilizzata 64x byte 128x byte 256x byte 320x byte Figura 5.22: NVidia GeForce 525M randomdot 11 frame, 6 scale Dimensioni ingresso Memoria utilizzata 64x byte 128x byte 256x256 out of memory 320 x 320 out of memory Figura 5.23: NVidia GeForce 8800 randomdot 7 frame, 6 scale Dimensioni ingresso Memoria utilizzata 64x byte 128x byte 256x byte 320x byte Figura 5.24: NVidia GeForce 525M randomdot 7 frame, 6 scale Dimensioni ingresso Memoria utilizzata 64x byte 128x byte 256x256 out of memory 320 x 320 out of memory Figura 5.25: NVidia GeForce Realizzazione di una dimostrazione Abbiamo pensato di realizzare a fini dimostrativi una funzione che cattura i frame da webcam e che, in tempo reale, calcoli il flusso ottico. La scelta di rendere configurabili alcuni parametri chiave (come il numero di scale nel 61

69 quale decomporre l immagine, o la dimensione del supporto temporale) ha di certo facilitato l implementazione di questa Demo. Grazie ai test sui tempi di cui sopra, abbiamo visto che con la scheda grafica 525M GTX ottenevamo dei risultati vicini al real-time con dimensioni in ingresso al sistema 128x128, 5 scale e supporto temporale di 7 frame. Poiché la webcam acquisisce frame di dimensioni 640x480, abbiamo deciso di filtrare le immagini in ingresso con la funzione cv::pyrdown() due volte, al fine di lavorare con risoluzione 160x120. La Demo acquisisce dapprima 7 frame, inizializza le strutture ed elabora le prime immagini della sequenza video. Successivamente si entra in un while dentro il quale ad ogni iterazione viene catturato un nuovo frame mediante l operatore >> della classe cv::videocapture. Vengono fatti i filtraggi spaziali su quest ultima immagine e, utilizzando i risultati precedenti salvati nella struttura CircularBuffer::unifiedSpace viene calcolato il flusso ottico. Le proiezioni sugli assi x e y del vettore velocità vengono usate come argomento della funzione MotionToColor(), al fine di rendere comprensibili i risultati all utente. Vengono quindi visualizzati in finestre diverse il frame in ingresso, il frame in uscita con la codifica di colore e la ColorWheel, ovvero la legenda che associa a direzione verso e intensità del campo vettoriale un colore diverso come in figura 5.1. Quindi si passa all iterazione successiva, un nuovo frame viene preso da webcam, viene elaborato ed entrambi vengono mostrati all utente. Sulla scheda grafica nvidia GeForce 525M GTX, con risoluzione e parametri descritti precedentemente il programma riesce a fornire un flusso in uscita di circa 6,6 fps (1 frame / 0.15 s). In figura 5.26 vediamo i risultati di una persona che si muove lungo l asse x, in entrambi i versi. 62

70 Figura 5.26: movimento nei due versi lungo l asse x 63