Marco Polo Munt Rocha
Implementação do algoritmo de fluxo ótico Lucas-Kanade para sistemas embarcados
Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao
Recife 2019
Marco Polo Munt Rocha
Implementação do algoritmo de fluxo ótico Lucas-Kanade para sistemas embarcados
Trabalho apresentado ao Programa de Graduação em Enge- nharia da Computação do Centro de Informática da Univer- sidade Federal de Pernambuco como requisito parcial para obtenção do grau de Bacharel em Engenharia da Computa- ção.
Área de Concentração: Sistemas Embarcados Orientador: Edna Natividade da Silva Barros
Recife 2019
FICHA
BANCA
I dedicate this dissertation to all my family.
AGRADECIMENTOS
Agradeço primeiramente à Deus por ter me dado forças durante a caminhada no curso de graduação. Agradeço também a minha família que sempre me apoiou e deram todo suporte necessário. Aos meus amigos, que me deram o tempo deles para me ouvir e me ajudar.
Em especial, agradeço a Lucas Fernando da Silva Cambuim que me ajudou em todo processo de implementação, validação e sintetização e a Diogo Azevedo Pereira Dantas por ter cedido os operadores de ponto flutuante em pipeline e me auxiliado na sintetização do projeto.
ABSTRACT
In the field of computer vision, there are several applications that use optical flow. One of the most widely used methods is Lucas-Kanade due to its robustness. However, it demands a high computational cost and even its implementation in the computer vision library, OpenCV, does not achieve real time results. A System Verilog architecture has been implemented to optimize optical flow processing. The simulation results showed that the implementation is obtaining the optical flow equivalent to OpenCV. Moreover, has been estimated that the solution can be used in real time.
Keywords: Computer Vision. Embedded systems.
RESUMO
No campo de visão computacional, existem diversas aplicações que utilizam o fluxo ótico. Um dos métodos mais empregados é o Lucas-Kanade devido a sua robusteza. Porém, ele demanda um alto custo computacional e mesmo sua implementação na biblioteca de visão computacional, OpenCV, não consegue resultados em tempo real. Foi implementado uma arquitetura em System Verilog para otimizar o processamento do fluxo ótico. Os resultados da simulação mostraram que a implementação está obtendo um fluxo ótico equivalente ao OpenCV.
Além disso, foi estimado que a solução pode ser utilizada em tempo real.
Palavras-chave: Visão computacional. Sistemas embarcados.
LISTA DE FIGURAS
Figura 1 – Máscara para se obter a derivada na direção horizontal . . . 15
Figura 2 – Máscara para se obter a derivada na direção vertical . . . 15
Figura 3 – Visão geral do algoritmo Lucas-Kanade . . . 15
Figura 4 – Visão Geral da arquitetura . . . 16
Figura 5 – Arquitetura do conversor para cinza . . . 17
Figura 6 – Arquitetura do Sobel X . . . 18
Figura 7 – Arquitetura do Sobel Y . . . 18
Figura 8 – Arquitetura da Derivada Temporal . . . 19
Figura 9 – Arquitetura do Janelamento . . . 20
Figura 10 – Arquitetura do Criador de Equação . . . 21
Figura 11 – Arquitetura do Resolvedor de equação . . . 22
Figura 12 – Estratégia de implementação . . . 23
Figura 13 – Codificação de cores do fluxo ótico. . . 24
Figura 14 – Imagem de fluxo gerada do OpenCV usando Lucas Kanade . . . 25
Figura 15 – Imagem de fluxo gerada da implementação em Python . . . 25
Figura 16 – Imagem de fluxo gerada da implementação em Python . . . 25
Figura 17 – Imagem de fluxo gerada da implementação em C++ . . . 25
Figura 18 – Imagem de fluxo gerada da implementação em C++ . . . 26
Figura 19 – Imagem de fluxo gerada da implementação em C++ com precisão reduzida 26 Figura 20 – Validação do conversor de cinza . . . 27
Figura 21 – Validação da derivação horizontal . . . 27
Figura 22 – Validação da derivação vertical . . . 28
Figura 23 – Validação da derivação no tempo . . . 28
Figura 24 – Validação do parâmetro∑iIx(qi)Ix(qi) . . . 29
Figura 25 – Validação do parâmetro∑iIx(qi)Iy(qi) . . . 29
Figura 26 – Validação do parâmetro∑iIy(qi)Iy(qi) . . . 30
Figura 27 – Validação do parâmetro∑iIx(qi)It(qi) . . . 30
Figura 28 – Validação do parâmetro∑iIy(qi)It(qi) . . . 31
Figura 29 – Validação do fluxo na componente horizontal. . . 31
Figura 30 – Validação do fluxo na componente vertical. . . 32
LISTA DE TABELAS
Tabela 1 – Erros da implementação em System Verilog . . . 32
SUMÁRIO
1 INTRODUÇÃO . . . 11
2 FUNDAMENTOS . . . 13
3 SISTEMA PROPOSTO . . . 16
3.1 PRÉ-PROCESSAMENTO . . . 17
3.1.1 Conversor para cinza . . . 17
3.1.2 Filtro de Sobel . . . 18
3.1.3 Derivada temporal . . . 19
3.2 CÁLCULO DE FLUXO . . . 19
3.2.1 Janelamento . . . 19
3.2.2 Criador de equação . . . 20
3.2.3 Resolvedor de equação . . . 22
4 RESULTADOS . . . 23
4.1 IMPLEMENTAÇÃO EM PYTHON . . . 24
4.2 IMPLEMENTAÇÃO EM C++ . . . 25
4.2.1 Implementação em C++ com precisão reduzida . . . 25
4.3 IMPLEMENTAÇÃO EM SYSTEM VERILOG . . . 26
5 CONCLUSÃO . . . 34
REFERÊNCIAS . . . 35
11 11 11
1
INTRODUÇÃO
O Fluxo ótico é o conceito de captura de movimentos em imagens consecutivas de um vídeo, que pode ser aplicado para todo pixel pertencente a uma imagem, gerando um fluxo denso, ou para um sub-conjunto de pixeis específicos, gerando um fluxo esparso.
Ele é utilizado em diversas aplicações do nosso dia a dia como na captura de movimento de um mouse ou em câmeras de vídeo para estabilização de imagens. Ele também é utilizado em detecção de movimento Cucchiara et al. (2003), compressão de vídeos Krishnamurthy et al.(1995), controle de navegação de drones, segmentação e detecção de objetos, tracking e reconstrução 3DAdiv(1985). Porém, todas essas aplicações necessitam de um processamento em tempo real, serem pequenos, de baixo custo e terem um baixo consumo energético para ser utilizado.
Um dos principais métodos para calcular o fluxo ótico é o proposto por Bruce D. Lucas e Takeo Kanade, apelidado de Lucas-KanadeLucas & Kanade(1981)Baker & Matthews(2004).
Este método assume que o fluxo é constante na vizinhança do pixel a ser calculado e utiliza o critério dos mínimos quadrados para obter uma solução para um sistema de equação, o que torna esse algoritmo robusto e confiávelBarronet al.(1994). Porém, este algoritmo é lento ao ser usado para calcular um fluxo denso, pois para cada pixel, são necessários vários cálculos complexos para obter os valores da vizinhança, agrupa-los para criar um sistema linear para, em seguida, resolvê-lo, o que demanda grande tempo computacional. Utilizando a biblioteca OpenCV em Python foi estimado que o algoritmo demora cerca de 0,2 segundos para analisar dois quadros consecutivos de um vídeo, ou seja, atinge uma taxa de 5 quadros por segundo o que inviabilizaria o seu uso em qualquer aplicação.
Com linguagens de descrição deHardware, como aSystem Verilog, é possível modelar um subsistema no nível de abstração RTL com possível prototipação em umField-programmable gate arrayou FPGA. Estes subsistemas têm a capacidade de computar processos complexos em poucos ciclos declock. Naturalmente, implementações de um cálculo de fluxo ótico com prototipação em uma FPGA foram realizadas em vários trabalhosMaya-Rueda & Arias-Estrada (2003);Diazet al.(2006);Kalyan & Malathi(2011). Sathya Kalyanet al. simularam o Lucas Kanade atingindo uma taxa de até 700 quadros por segundoKalyan & Malathi(2011), porém este trabalho não apresentou uma arquitetura tão robusta para se obter esta taxa.
12 12 12 Portanto, o objetivo deste trabalho foi o de implementar uma arquitetura em System Verilog que calcule o fluxo ótico utilizando o método Lucas-Kanade para processamento em tempo real, com menor quantidade de recursos de armazenamento e processamento.
13 13 13
2
FUNDAMENTOS
Este capítulo descreve a fundamentação teórica do fluxo ótico para um melhor entendi- mento deste trabalho.
Para duas imagens em sequência, assumindo queI seja o nível de intensidade de brilho, que a movimentação entre as imagens seja pequena e que não exista diferenças fotométricas nas imagens, a restrição de constância de brilho pode ser dada pela fórmula 2.1. O nível de intensidade de brilhoI, pode ser obtido através de uma conversão da imagem colorida para cinza.
I(x,y,t) =I(x+∆x,y+∆y,t+∆t) 2.1 Onde∆xé o deslocamento na horizontal da imagem na região (x, y, t) depois de um tempo∆t,∆yé o deslocamento na vertical da imagem na região (x, y, t) depois de um tempo∆t. Ao expandir o lado direito da equação em uma série de Taylor obtendo-se a equação 2.2.
I(x+∆x,y+∆y,t+∆t) =I(x,y,t) +∂I
∂x∆x+∂I
∂y∆y+∂I
∂t∆t+O2 2.2 Onde ∂I∂x é a derivada parcial na direção horizontal(também denotada por Ix),∂∂yI é a derivada parcial na direção vertical(também denotada porIy) e ∂I∂t é a derivada parcial no tempo (também denotada porIt). Ao fazer as substituições desconsiderando oO2e dividindo a equação por∆t é possível obter a equação 2.3.
∂I
∂xFx+∂I
∂yFy+∂I
∂t =0 2.3
Essa equação não é suficiente para determinar os valores de fluxo horizontalFxe vertical Fy.
O método de Lucas-Kanade resolve este problema considerando a suposição de que o fluxo é constante em regiões vizinhas do pixel em análise, essas regiões são definidas através de uma janela cujo centro é o pixel de análise. Dessa forma, a equação de fluxo pode ser definida
14 14 14 conforme a equação 2.4
Ix(q1)Fx+Iy(q1)Fy = −It(q1) Ix(q2)Fx+Iy(q2)Fy = −It(q2)
...
Ix(qn)Fx+Iy(qn)Fy = −It(qn)
2.4
Ondeq1,q2, . . . ,qnsão pixels dentro da janela eIx(qi),Iy(qi)eIt(qi)são, respectivamente, as derivadas parciais na horizontal, vertical e no tempo analisado no pontoqi. Essa equação pode ser transformada em um sistema matricialAv=b, onde:
A=
Ix(q1) Iy(q1) Ix(q2) Iy(q2)
...
Ix(qn) Iy(qn)
v=
Fx Fy
b=
−It(q1)
−It(q2) ...
−It(qn)
2.5
Pode-se verificar que há mais equações que variáveis. Para calcular o fluxo, o método Lucas-Kanade utiliza o conceito de mínimos quadrados e, utiliza a seguinte equação:
v= (ATA)−1ATb 2.6
OndeAT é a transposta da matriz A e(ATA)−1é a inversa da matrizATA. Realizando as multiplicações, é possível chegar à equação 2,7, que é a equação de fluxo proposta no método de Lucas-Kanade.
v=
∑iIx(qi)2 ∑iIx(qi)Iy(qi)
∑iIx(qi)Iy(qi) ∑iIy(qi)2
−1
∑iIx(qi)It(qi)
∑iIy(qi)It(qi)
2.7
Para se obter as derivadas em relação à horizontal e à vertical, o método utilizado neste trabalho utilizou o filtro de Sobel. Este operador convolve a imagem com as máscaras que são apresentadas nas figuras 1 e 2.
A convolução de uma imagem é feita através da multiplicação dos elementos de uma máscara com os elementos de uma janela, de mesmo tamanho da máscara, da imagem. Feita a multiplicação, todos os elementos são somados para se obter o resultado final.
Uma visão geral do algoritmo pode ser observada na figura 3.
15 15 15
Figura 1: Máscara para se obter a derivada na direção horizontal
Figura 2: Máscara para se obter a derivada na direção vertical
Figura 3: Visão geral do algoritmo Lucas-Kanade
16 16 16
3
SISTEMA PROPOSTO
Na figura 4 é possível ter uma visão geral do sistema proposto para o cálculo de fluxo ótico usando o método de Lucas-Kanade. O sistema é dividido em dois módulos que realizam operações necessárias para se obter o fluxo ótico. O primeiro módulo obtêm os dados necessários para se calcular o fluxo da imagem, já o segundo obtêm o fluxo a partir dos dados calculados do primeiro módulo.
Figura 4: Visão Geral da arquitetura
Como pode ser visto na figura acima, duas imagens consecutivas de um vídeo, chamadas
17 17 17 de frames, tem suas componentes em vermelho(R), verde(G) e azul (B) transformadas em cinza, Y1para o frame(t) eY2 para o frame(t+1). Y1 é utilizado para se obter a derivada espacial na horizontal e vertical a partir da aplicação do filtro de Sobel. Y1 eY2são utilizados para obter a derivada no tempo. As derivadas são agrupadas em janelas e tem os parâmetros da equação de fluxo calculado pelo sub-módulo “Criador de equação” e a equação em si, é resolvida pelo
“Resolvedor de equação”, obtendo os fluxos em suas componentes horizontalFx e verticalFy.
3.1 PRÉ-PROCESSAMENTO
Este módulo tem a responsabilidade de calcular os dados da derivação horizontal ∂I∂x (abreviado paraIx), derivação vertical ∂I∂y (abreviado paraIy) e derivação temporal ∂I∂t (abreviado paraIt) que são essenciais para o cálculo do fluxo ótico.
3.1.1 Conversor para cinza
O conversor para cinza transforma os componentes R, G e B em um valor que corresponde ao nível de lumaY do pixel, também chamado de nível de intensidadeI, em um ciclo de clock.
Isto é possível, pois o conversor possui uma arquitetura descrita pela figura 5, onde>>né um operador dendeslocamentos de bits para a direita que equivale a uma divisão do valor de entrada por 2n.
Figura 5: Arquitetura do conversor para cinza
Ao realizar os cálculos de deslocamento é possível obter a fórmula 3.1, que é uma aproximação da conversão para cinza utilizado na biblioteca OpenCV.
Y =0.296875·R+0.578125·G+0.109375·B 3.1
18 18 18
3.1.2 Filtro de Sobel
O filtro de Sobel, como explicado na fundamentação, é um operador que convolve uma imagem com duas máscaras para obter uma aproximação da derivada horizontalIxe da derivada verticalIy. Como a operação de convolução precisa de um conjunto de pontos, é necessário que haja uma forma de obter tal conjunto, este problema é solucionado a partir das três FIFOS que se encontram no começo da arquitetura, onde a saída de uma FIFO é a entrada de outra, o tamanho de cada FIFO é igual à largura da imagem. A partir do momento em que as duas primeiras FIFOS estão completas com dados válidos, a cada ciclo é obtido uma coluna do janelamento da convolução. Como as máscaras são diferentes entre si, duas arquiteturas em pipeline foram implementadas: uma paraIxe outra paraIy, ambas estão colocadas nas figuras 6 e 7. O operador
<<nrealizandeslocamentos de bits para a esquerda que equivale a uma multiplicação do valor
de entrada por 2n.
Figura 6: Arquitetura do Sobel X
Figura 7: Arquitetura do Sobel Y
Como é necessário que se complete pelo menos duas FIFOS com o tamanho da largura da imagem e são necessários mais 3 ciclos para realizar os cálculos da convolução, o número de ciclos necessários para se obter o primeiro valor válido de derivada é dado pela fórmula 3.2.
ciclos=2·LarguraDaImagem+3 3.2
19 19 19
3.1.3 Derivada temporal
A derivada no tempoIt é calculada pela diferença de nível de intensidade entre dois frames consecutivos, sendo assim, esse sub-módulo poderia ter uma resposta válida com apenas um ciclo de clock, porém a resposta deste sub-módulo não estaria sincronizada com o sub- módulos de Sobel X e Sobel Y, porém esta sincronia é importante para se obter os valores corretos de fluxo e, para resolver isso, foi necessário colocar uma FIFO antes da saída deste sub-módulo para carregar o valor de It enquanto os valores de Ix e Iy não ficam prontos. A arquitetura implementada pode ser observada na figura a seguir:
Figura 8: Arquitetura da Derivada Temporal
3.2 CÁLCULO DE FLUXO
Este módulo é responsável por calcular o fluxo ótico horizontalFxe fluxo verticalFya partir das derivadas espaciais e temporais calculadas no módulo anterior.
3.2.1 Janelamento
Como o método utilizado é o Lucas-Kanade, deve-se ter uma estrutura para guardar as derivadas espaciais e temporais do pixel de análise pe seus vizinhos. O número de vizinhos depende do tamanho da janela de análise do algoritmo Lucas-Kanade e, para este trabalho, o tamanho da janela escolhido foi de 3, o que significa que cada pixel analisado existem 8 vizinhos.
Como o próximo módulo precisa dos 9 valores deIx,Iy eIt, a seguinte arquitetura em pipeline foi implementada.
20 20 20
Figura 9: Arquitetura do Janelamento
É possível observar que este sub-módulo possui uma estrutura parecida com os sub- módulos Sobel X e Sobel Y, isto se deve ao fato de que existe uma necessidade de obter um conjunto de dados que estão envolvidos em uma janela. A diferença entre os sub-módulos é que, neste caso, precisamos de todos os valores deIx,IyeItque são vizinhos ao pixel de análise, e, é preciso usar registradores para guardar os 9 dados de cada derivada e usar a saída de cada registrador para passar todos os dados necessários para o próximo sub-módulo.
3.2.2 Criador de equação
O Criador de equação recebe todas as derivadas no espaço e no tempo do pixel de análise p e seus vizinhos, para obter os parâmetros da equação 2.7. Note que ocorrem sucessivas multiplicações e somas que, em um sistema computacional genérico, seriam feitos de forma sequencial. Já a arquitetura proposta, não possui essas limitações.
21 21 21
Figura 10: Arquitetura do Criador de Equação
22 22 22
3.2.3 Resolvedor de equação
Para resolver o sistema linear de equações, o método de substituição foi utilizado. Este método consiste em obter o valor de uma variável como dependente da outra, substituir este valor em outra equação e encontrar o valor da variável dependente. Após as substituições e simplificações, as equações 3.3 e 3.4 são obtidas e estão descritas abaixo.
Fy= ∑iIx(qi)Iy(qi)·∑iIx(qi)It(qi)−∑iIx(qi)2·∑iIy(qi)It(qi)
∑iIy(qi)2·∑iIx(qi)2+ ∑iIx(qi)Iy(qi)2 ; 3.3 Fx= ∑iIx(qi)Iy(qi)·Fy−∑iIx(qi)Iy(qi)
∑iIx(qi)2 ; 3.4 É possível observar que o valor deFydeve ser obtido antes deFx, ou seja, os resultados não saem juntos. Porém, este não é o único problema, os parâmetros da fórmula estariam dessincronizados também. Para que o cálculo seja o mais paralelo possível, em pipeline e sem haver dessincronização ou atrasos entre os valores, FIFOS foram colocadas para carregarem os parâmetros de equação enquanto não fosse o momento certo de usá-los. Outra FIFO foi colocada para carregar o valor deFyenquanto o cálculo deFxnão for finalizado, tal arquitetura é mostrada na figura a seguir:
Figura 11: Arquitetura do Resolvedor de equação
23 23 23
4
RESULTADOS
Para realizar uma implementação em RTL, foi necessária uma compreensão profunda do método do Lucas-Kanade que foi alcançado pela implementação do algoritmo em linguagens de mais alto nível. Esta abordagem permitiu que não houvesse um salto grande entre o conhecimento teórico e uma implementação em uma linguagem descritiva de Hardware. Outro ponto positivo foi que em cada implementação feita, foi possível fazer uma breve validação dos resultados obtidos, fazendo com que o tempo de depuração fosse menor. Neste intuito, este trabalho seguiu uma abordagem de implementação apresentada na figura 12. Em que cada etapa da implementação foi realizado um processo de validação de resultados. Para testar as implementações, foi utilizada o banco de imagens do Middlebury. Bakeret al.(2011).
Figura 12: Estratégia de implementação
24 24 24 O primeiro passo foi obter os resultados de fluxo ótico utilizando o estado da arte, a biblioteca OpenCV, para se obter um ponto de referência. Com os resultados, uma implementação canônica do Lucas-Kanade foi feita em Python e comparado com o estado da arte, enquanto não era obtido um resultado equivalente ao estado da arte, o próximo estágio de implementação não era iniciado. Ao se obter um resultado equivalente em Python, um código em C++ foi implementado, utilizando abordagens de baixo nível e comparado com a versão em Python.
Uma outra versão em C++ foi implementada, porém utilizando números inteiros na maior parte do processamento para se estudar os efeitos da redução na precisão dos cálculos. Com a versão em C++ com precisão reduzida testada, começou a implementação de cada sub-módulo apresentado na figura 3 começando pelo conversor para cinza. Depois, para cada sub-módulo implementado, foi realizado um teste e comparação com o resultado do código equivalente em C++ com precisão reduzida. Python foi utilizada primeiro devido a sua facilidade em realizar modificações, depurações e a possibilidade de utilizar bibliotecas que cuidam de operações matriciais, com essa implementação, o entendimento do algoritmo ficou mais claro para que começasse uma implementação em C++. Se a primeira implementação fosse em C++, haveria problemas para encontrar erros e o tempo de implementação seria maior.
4.1 IMPLEMENTAÇÃO EM PYTHON
Na implementação canônica em Python foi feita a leitura do arquivo utilizando a biblio- teca OpenCV para obter os componentesR,GeBde cada pixel, porém todo processamento de conversão para cinza, derivação temporal, derivação espacial e cálculo de fluxo foram realizados usando os recursos de Python e bibliotecas como Numpy e Scipy para lidar com as operações matriciais. Ao obter os fluxos em cada pixel, os dados foram convertidos para uma imagem de fluxo, em que cada cor corresponde a uma direção, módulo e sentido do fluxo. Esta codificação pode ser observada na figura 13. Os resultados foram comparados com o resultado do estado da arte, OpenCV, que estão demonstrados na figura 14 e 15.
Figura 13: Codificação de cores do fluxo ótico.
25 25 25
Figura 14: Imagem de fluxo gerada do OpenCV usando Lucas Kanade
Figura 15: Imagem de fluxo gerada da im- plementação em Python
4.2 IMPLEMENTAÇÃO EM C++
Na implementação em C++, o processo de leitura foi o mesmo que o de Python, usando a biblioteca OpenCV. Já a conversão para cinza, derivação e cálculo de fluxo foi realizado usando os recursos de C++. Nesta implementação foi utilizado o método de substituição para resolver as equações lineares de fluxo. Novamente, os valores foram convertidos para uma codificação de cores e comparado com a implementação em Python que pode ser observada nas figuras 16 e 17.
Como esta implementação utilizou o método de substituição ao invés do método matricial, os vetores de fluxo manteve a direção e sentido dos vetores na implementação em Python, porém os módulos destes ficaram menores.
Figura 16: Imagem de fluxo gerada da im- plementação em Python
Figura 17: Imagem de fluxo gerada da im- plementação em C++
4.2.1 Implementação em C++ com precisão reduzida
Na implementação anterior, a conversão para cinza, derivação e o cálculo de parâmetros da equação linear de fluxo foram feitas usando números na representação em ponto-flutuante.
Porém, na proposta da implementação em System Verilog, números em ponto-flutuante são usados somente na resolução da equação de fluxo (sub-módulo Resolvedor de Equação). Portanto, uma implementação em C++ usando números inteiros nas etapas mencionadas foi necessária
26 26 26 para se observar as perdas que ocorrem ao se reduzir a precisão. Para tal, uma imagem de fluxo foi gerada e comparada com a implementação anterior, o resultado pode ser visto nas figuras 18 e 19.
Figura 18: Imagem de fluxo gerada da im- plementação em C++
Figura 19: Imagem de fluxo gerada da im- plementação em C++ com precisão redu- zida
4.3 IMPLEMENTAÇÃO EM SYSTEM VERILOG
Para esta implementação, a biblioteca OpenCV foi utilizada para obter os componentes R, G e B de cada pixel e gravadas em arquivos de texto. Estes arquivos foram utilizados como entrada para o módulo de pré-processamento. A partir disso, cada sub-módulo foi implementado e validado escrevendo a sua saída em um arquivo de texto e comparado com a saída da implementação em C++ com precisão reduzida. Para que os arquivos em texto fossem completamente validados, a ferramenta Diffuse foi utilizada. Esta ferramenta compara dois arquivos e destaca as diferenças entre eles. Os resultados podem ser observados a seguir e todas as imagens seguem a mesma regra: o arquivo à direita é a saída do sub-módulo validado e o arquivo à esquerda é a saída do processamento correspondente em C++ com precisão reduzida.
27 27 27
Figura 20: Validação do conversor de cinza
Figura 21: Validação da derivação horizontal
28 28 28
Figura 22: Validação da derivação vertical
Figura 23: Validação da derivação no tempo
29 29 29
Figura 24: Validação do parâmetro∑iIx(qi)Ix(qi)
Figura 25: Validação do parâmetro∑iIx(qi)Iy(qi)
30 30 30
Figura 26: Validação do parâmetro∑iIy(qi)Iy(qi)
Figura 27: Validação do parâmetro∑iIx(qi)It(qi)
31 31 31
Figura 28: Validação do parâmetro∑iIy(qi)It(qi)
Figura 29: Validação do fluxo na componente horizontal.
32 32 32
Figura 30: Validação do fluxo na componente vertical.
Nas figuras 20 – 28, a diferença entre os arquivos é devida ao fato de que a implementação em System Verilog continua escrevendo no arquivo de saída mesmo depois de a imagem estar completamente processada, nesta situação, os sub-módulos respondem com 0. Já nas figuras 29 e 30, os fluxos estão próximos ao esperado, e só em alguns pontos existem uma diferença que pode ser desconsiderada. Esta diferença é devido ao processamento de números em ponto-flutuante em System Verilog. Foi calculado o erro máximo, médio e em porcentagem utilizando as fórmulas 4.1, 4.2 e 4.3 respectivamente e foi obtido os resultados expressados pela tabela 1.
ErrMax=max
{i} f luxoC(i)−f luxoVerilog(i)
4.1
AvgErr= ∑i f luxoC(i)−f luxoVerilog(i) i
4.2 AvgErr= ∑i f luxoC(i)−f luxoVerilog(i)
∑if luxoC(i)
4.3
Tabela 1: Erros da implementa- ção em System Verilog
Erro Fx Fy
Máximo 2.52 3.52 Médio 0.061 0.058 Porcentagem 0.42% 1.13%
A implementação foi então sintetizada na Cyclone IV GX EP4CGX15DF31C7 e a análise mostrou que foram utilizados cerca de 13545 elementos lógicos totais (cerca de 9% da placa), 3975 registradores totais, 117 pinos totais (cerca de 23% da placa), 144 689 bits de memória
33 33 33 total (cerca de 2% da placa), 88 multiplicadores de 9 elementos (cerca de 12% da placa) e a análise revelou que a arquitetura pode utilizar uma frequência máxima de clock de 64,79 MHz.
Para uma imagem utilizada, que possui as dimensões de 584 × 388 pixels, 2386 ciclos de clock são necessários para se obter o primeiro fluxo válido e, como a partir desse ponto, cada ciclo responde com o fluxo de um pixel, estima-se que a implementação possui um tempo de atraso de 0,03 segundos, e que um mapa de fluxos da imagem inteira é gerado a cada 3,5 milissegundos, o que corresponde a 280 quadros por segundo.
34 34 34
5
CONCLUSÃO
Neste trabalho foi proposto e implementado um sistema para cálculo de fluxo ótico utilizando o método de Lucas-Kanade em System Verilog. Nas simulações, a implementação ao nível de RTL obteve resultados que foram próximos ao estado da arte e foi possível estimar que a solução pode ser utilizada em tempo real. Os trabalhos futuros são: realizar a validação dos módulos no tempo para verificar se foi atingido uma velocidade de processamento necessária para ser usado em aplicações de tempo real e sintetizar o projeto para um FPGA. Um conceito que não foi abordado neste trabalho foi o de pirâmidesBouguet(2000) que reduz a resolução da imagem para se obter um fluxo em regiões que não respeitem a condição que a movimentação seja pequena de um frame para o outro, este conceito também poderá ser abordado em trabalhos futuros.
35 35 35
REFERÊNCIAS
Adiv, G. (1985). Determining three-dimensional motion and structure from optical flow generated by several moving objects. IEEE Transactions on Pattern Analysis and Machine Intelligence, PAMI-7(4):384–401.
Baker, S. & Matthews, I. (2004). Lucas-kanade 20 years on: A unifying framework.International Journal of Computer Vision, 56(3):221–255.
Baker, S., Scharstein, D., Lewis, J. P., Roth, S., Black, M. J., & Szeliski, R. (2011). A database and evaluation methodology for optical flow. International Journal of Computer Vision, 92(1):1–
31.
Barron, J. L., Fleet, D. J., & Beauchemin, S. S. (1994). Performance of optical flow techniques.
International Journal of Computer Vision, 12(1):43–77.
Bouguet, J.-Y. (2000). Pyramidal implementation of the lucas kanade feature tracker description of the algorithm. OpenCV Document, Intel, Microprocessor Research Labs, 1.
Cucchiara, R., Grana, C., Piccardi, M., & Prati, A. (2003). Detecting moving objects, ghosts, and shadows in video streams. IEEE Transactions on Pattern Analysis and Machine Intelligence, 25(10):1337–1342.
Diaz, J., Ros, E., Pelayo, F., Ortigosa, E. M., & Mota, S. (2006). Fpga-based real-time optical- flow system. IEEE Transactions on Circuits and Systems for Video Technology, 16(2):274–279.
Kalyan, T. & Malathi, M. (2011). Architectural implementation of high speed optical flow computation based on lucas-kanade algorithm. 4.
Krishnamurthy, R., Moulin, P., & Woods, J. (1995). Optical flow techniques applied to video coding. InProceedings., International Conference on Image Processing, 1:570–573 vol.1.
Lucas, B. & Kanade, T. (1981). An iterative image registration technique with an application to stereo vision (ijcai). 81.
Maya-Rueda, S. & Arias-Estrada, M. (2003). Fpga processor for real-time optical flow compu- tation. In Y. K. Cheung, P. & Constantinides, G. A., editors,Field Programmable Logic and Application, 1103–1106.
