Algoritmo de Gaze Tracking

O algoritmo de Gaze Tracking ´e composto por quatro etapas principais. A primeira etapa trata-se da localiza¸c˜ao das coordenadas do centro de cada um dos olhos na imagem capturada pela webcam. O segundo passo ´e a localiza¸c˜ao da coordenada do ponto de ˆancora, ou seja, a coordenada do canto interno de cada um dos olhos. O terceiro passo corresponde `a calibra¸c˜ao do sistema para cada usu´ario, utilizando um modelo de classifica¸c˜ao para correlacionar o vetor de caracter´ıstica, tamb´em chamado de vetor centro-ˆancora, com uma regi˜ao pr´e-determinada de um padr˜ao de calibra¸c˜ao gerado na

tela do smartphone. A quarta etapa trata-se da detec¸c˜ao da dire¸c˜ao do olhar do usu´ario utilizando o modelo de classifica¸c˜ao obtido na etapa anterior.

Em primeiro lugar, a fim de detectar a localiza¸c˜ao do centro do olho, foi implemen- tado o algoritmo de localiza¸c˜ao no centro do olho proposto por Valenti et al. [51, 58]. Este algoritmo obteve resultados de alta precis˜ao e foi desenvolvido utilizando t´ecnicas de processamento digital de imagens e reconhecimento de padr˜oes de baixo custo com- putacional. Entretanto, como ele n˜ao foi proposto originalmente para utiliza¸c˜ao em HMDs, a implementa¸c˜ao realizada n˜ao atingiu uma precis˜ao satisfat´oria e precisa de alguns ajustes para ser utilizada como uma forma de intera¸c˜ao com os objetos virtuais apresentados pelo prot´otipo em realidade aumentada.

O algoritmo de localiza¸c˜ao no centro do olho proposto por Valenti et al. [51, 58] baseia-se em padr˜oes isocˆentricos invariantes formados por isofotas 2, que podem ser obtidos a partir do gradiente da imagem de um olho em escala de cinza, e tem trˆes variantes. As trˆes variantes do algoritmo consistem em: 1) um m´etodo b´asico, baseado em atributos, em que o centro do olho ´e estimado como sendo o centro das curvas de n´ıveis; 2) um m´etodo intermedi´ario, baseado em atributos, que utiliza o m´etodo b´asico em conjunto com o algoritmo Mean-Shift (MS) [96] para melhorar a estabilidade e precis˜ao do m´etodo; 3) uma vers˜ao aprimorada, atrav´es de um m´etodo h´ıbrido, que utiliza o m´etodo b´asico em conjunto com um classificador k-Nearest Neighbor (k-NN) e o algoritmo Scale Invariant Feature Transform (SIFT) [97] para melhorar ainda mais a precis˜ao e a robustez do sistema.

Os resultados preliminares obtidos a partir da experimenta¸c˜ao e an´alise do m´etodo proposto por Valenti et al. [51, 58], na condi¸c˜ao experimental original, indicam que as variantes mais b´asicas (ou seja, o m´etodo b´asico e o m´etodo b´asico em conjunto com o algoritmo Mean-Shift ) conseguem atingir bons resultados mantendo um desempenho que respeita as restri¸c˜oes de execu¸c˜ao em tempo real. Enquanto isso, a vers˜ao aprimorada do m´etodo, apesar de atingir resultados um pouco melhores, n˜ao respeita as restri¸c˜oes de tempo real e de baixo custo computacional que s˜ao exigidas pelo projeto em quest˜ao. Sendo assim, a implementa¸c˜ao realizada consiste na variante do m´etodo intermedi´ario, que utiliza o m´etodo b´asico junto ao algoritmo Mean-Shift (MS) com o intuito de al- can¸car resultados satisfat´orios para o problema de localiza¸c˜ao do centro do olho, mesmo com restri¸c˜oes de baixo custo computacional e de execu¸c˜ao em tempo real.

2

Isofotas s˜ao curvas que conectam pontos de mesma intensidade luminosa em uma imagem em escala de cinza.

Esses resultados preliminares tamb´em mostram que o mesmo algoritmo pode ser utilizado para detectar os cantos dos olhos. Na verdade, Valenti et al. [99] usaram o algoritmo para executar a tarefa de detec¸c˜ao de canto do olho, mas os resultados en- contrados n˜ao foram est´aveis. Para superar esse problema, em primeiro lugar, podemos inferir a posi¸c˜ao aproximada do canto interno do olho, usando a regi˜ao do olho detectada pelo classificador em cascata baseado em atributos Haar que est´a dispon´ıvel na biblioteca OpenCV. Em seguida, basta aplicar o m´etodo b´asico junto com algoritmo Mean-Shift (MS) apenas na regi˜ao de interesse que cont´em o canto do olho. Este procedimento retorna uma localiza¸c˜ao de canto de olho que n˜ao ´e est´avel o suficiente para a aplica¸c˜ao de Gaze Tracking. Portanto, para melhorar a estabilidade, calcula-se a m´edia m´ovel das ´ultimas dez coordenadas de canto do olho obtidas pelo procedimento anterior. Esta metodologia resulta numa localiza¸c˜ao de canto do olho com maior estabilidade. En- tretanto, conforme ´e mostrado na Se¸c˜ao 5.2, essa solu¸c˜ao apresentou uma dependˆencia muito grande da qualidade da detec¸c˜ao da regi˜ao do olho, prejudicando o desempe- nho geral do algoritmo de Gaze Tracking quando testado no prot´otipo de HMD. Essa limita¸c˜ao dever´a ser abordada em trabalhos futuros.

A Figura 5.6 ilustra a implementa¸c˜ao do algoritmo. A seguir, os seis est´agios do algoritmo s˜ao explicados.

Figura 5.6: Os est´agios do algoritmo de Gaze Tracking Fonte: Imagem adaptada a partir de [111]

Est´agio 1 - Captura do Frame e Convers˜ao para Escala de Cinza: Neste est´agio, o frame ´e capturado e convertido de uma imagem com trˆes canais R, G e B para uma imagem com um ´unico canal em escala de cinza.

Est´agio 2 - Sele¸c˜ao da Regi˜ao de Interesse: Neste est´agio, o classificador em cascata baseado em atributos Haar, que est´a dispon´ıvel na biblioteca OpenCV, ´e utilizado para

obter regi˜ao de interesse do olho.

Est´agio 3 - C´alculo das Isofotas: Neste est´agio, o algoritmo executa o c´alculo de curvatura das isofotas, para cada olho, usando o m´etodo proposto por Valenti et al. [58].

Est´agio 4 - Vota¸c˜ao do Centro e C´alculo do Centermap: Neste est´agio, o algoritmo executa o mecanismo de Vota¸c˜ao do Centro proposto por Valenti et al. [58], a fim de calcular o centermap3. O centermap funciona como fun¸c˜ao bidimensional de distribui¸c˜ao de probabilidade, onde as coordenadas mais votadas tˆem uma chance maior de ser a localiza¸c˜ao verdadeira do centro do olho. O quarto est´agio da Figura 5.6 mostra a imagem do centermap. As regi˜oes mais claras do centermap tˆem uma probabilidade maior de ser a verdadeira localiza¸c˜ao do centro do olho.

Est´agio 5 - Algoritmo Mean-Shift: Neste est´agio, o algoritmo MS ´e aplicado sobre a imagem do centermap do olho. A janela deslizante do algoritmo MS percorre a imagem do centermap procurando pela ´area com maior densidade de votos. A janela deslizante do algoritmo MS est´a representada por um retˆangulo azul no quinto est´agio do algoritmo, na Figura 5.6.

Est´agio 6 - Localiza¸c˜oes do Centro e do Canto do Olho e o Vetor Centro- ˆAncora: Neste est´agio, a localiza¸c˜ao do centro do olho ´e calculada como sendo a coordenada mais votada do centermap que esteja pr´oxima do centro da janela deslizante do algoritmo MS. A localiza¸c˜ao do canto interno do olho ´e calculada atrav´es da metodologia previamente explicada. O sexto est´agio da Figura 5.6 mostra as localiza¸c˜oes estimadas do centro e do canto interno do olho. Al´em disso, esse est´agio da Figura 5.6, tamb´em mostra o vetor centro-ˆancora (de cor verde) obtido pelo algoritmo.

Ap´os todos esses est´agios, ´e necess´ario calibrar o sistema de acordo com o usu´ario. O objetivo da calibra¸c˜ao ´e conseguir um modelo de classifica¸c˜ao que ir´a relacionar o vetor de centro-ˆancora espec´ıfico de um usu´ario com as regi˜oes pr´e-determinadas da tela do HMD. O modelo de classifica¸c˜ao pode ser obtido atrav´es de diversas maneiras, tais como: Redes Neurais Artificiais e SVM (Support Vector Machine). No processo de

3

O centermap ´e o acumulador de votos do mecanismo de vota¸c˜ao do centro. Ele possui as mesmas dimens˜oes da imagem. Cada elemento do centermap acumula a quantidade de votos recebida pelo pixel correspondente a ele na imagem original.

calibra¸c˜ao, o usu´ario deve olhar para as regi˜oes conhecidas da tela do HMD enquanto a cˆamera grava o comportamento do olho do usu´ario. Atrav´es desse processo ´e poss´ıvel relacionar o vetor centro-ˆancora, retornado pelo algoritmo, com as regi˜oes conhecidas da tela, resultando em um modelo de classifica¸c˜ao.

5.2

Experimentos e Avalia¸c˜ao do Prot´otipo

Esta se¸c˜ao apresenta os experimentos que foram realizados para avaliar o desempenho do algoritmo de Gaze Tracking em diferentes plataformas de hardware, a acur´acia do algoritmo e a experiˆencia de usu´ario durante a utiliza¸c˜ao do prot´otipo. Sendo assim, os objetivos dos experimentos s˜ao: identificar qual ´e a melhor placa de desenvolvimento para execu¸c˜ao do algoritmo; avaliar a qualidade de sua implementa¸c˜ao; e validar o prot´otipo desenvolvido.

Para alcan¸car esses objetivos, ´e essencial a conformidade do hardware com alguns requisitos de tempo-real e de dispositivos vest´ıveis. Por exemplo, a acessibilidade da interface do usu´ario, uma estrutura compacta e de baixo peso s˜ao alguns dos requisitos necess´arios para um HMD de realidade aumentada. Enquanto isso, para identificar a dire¸c˜ao de olhar do usu´ario em tempo real, o algoritmo deve fornecer as informa¸c˜oes de rastreamento do olhar pelo menos duas vezes por segundo, em caso de baixa velocidade de movimento do olho, ou pelo menos quatro vezes por segundo, em caso de alta velo- cidade de movimento do olho [113]. Portanto, o hardware e o software necessitam de ter uma taxa de frame por segundo (FPS) m´ınima entre 2 e 4 FPS para satisfazer esse requisito. Todos estes requisitos foram considerados na sele¸c˜ao do hardware.

A seguir, os experimentos s˜ao descritos e os resultados obtidos s˜ao apresentados. Ao final, ´e realizada uma breve discuss˜ao sobre as limita¸c˜oes e os problemas de experiˆencia do usu´ario que foram identificados.

5.2.1

Desempenho

Quatro placas de desenvolvimento foram escolhidas para avaliar o desempenho do hard- ware e software. Todas elas respeitam os requisitos de dispositivos vest´ıveis e podem funcionar usando uma bateria como fonte de alimenta¸c˜ao [102]. Foram selecionadas os seguintes sistemas embarcados: Intel Edison (CPU Intel Atom Dual-Threaded @ 500

MHz, Microcontrolador Intel Quark de 32-bit @ 100 MHz, 1 GB de RAM LPDDR3, 1MB de cache L1), Wandboard Quad (CPU Quad Core i.MX6 Freescale @ 1 GHz, 2 GB DDR3 RAM), Raspberry Pi 3 Model B (CPU Quad Core Broadcom BCM2837 de 64 bits @ 1.2GHz, 1GB de SDRAM), Cubieboard (CPU Single Core ARM Cortex A8 @ 1 GHz, 1 GB DDR3).

O Linux foi utilizado como sistema operacional para cada placa de desenvolvimento. Na Intel Edison, foi utilizado o framework Yocto para construir o sistema operacional. Al´em disso, todas as placas utilizam a vers˜ao mais b´asica do sistema operacional, com intuito de melhorar o desempenho do hardware. Ap´os a instala¸c˜ao dos sistemas opera- cionais, a biblioteca OpenCV foi compilada com as dependˆencias de Python ativadas para possibilitar a execu¸c˜ao do algoritmo.

A m´etrica definida para avaliar o sistema tratou-se da taxa de frame por segundo (FPS). Foi utilizado um v´ıdeo para avaliar o desempenho do hardware. Embora o sis- tema use uma cˆamera como sensor de imagem, essa abordagem foi escolhida para evitar a interferˆencia das limita¸c˜oes da cˆamera no desempenho do algoritmo, pois esse equipa- mento captura as imagens a uma taxa de, no m´aximo, 30 FPS.

Figura 5.7: Desempenho, em FPS, das plataformas de hardware avaliadas com intervalo de confian¸ca de 99%

A Figura 5.7 mostra os resultados obtidos ap´os a avalia¸c˜ao. As barras de erro, pre- sentes no gr´afico, representam os intervalos de confian¸ca de 99%. Todas as placas de desenvolvimento apresentaram uma taxa de FPS satisfat´oria para aplica¸c˜ao em quest˜ao. Essa avalia¸c˜ao de desempenho mostrou que todas as plataformas de hardware escolhidas

tˆem poder computacional suficiente para receber novas aplica¸c˜oes.