O sistema de reconhecimento descrito acima está implementado sobre um framework12 mais genérico para reconhecimento de gestos, também desenvolvido como parte deste trabalho, que divide o reconhecimento em componentes que realizam a aquisição, segmentação e análise da imagem, além da classificação do gesto e que permite substituir facilmente qualquer um desses quatro componentes. O estudo de novas estratégias de reconhecimento e interfaces baseadas em gestos, além do que foi feito neste trabalho, é de grande interesse para a continuidade desta ———————
12 Nesse trabalho utiliza-se a definição de Johnson & Foote (1998) para framework de software: um
projeto reutilizável para um sistema de software que pode ser representado por um conjunto de classes abstratas, com sua interface bem definida, que devem ser instanciadas para realizar a implementação de uma aplicação ou API específica.
pesquisa em trabalhos futuros, motivo pelo qual optou-se por criar este framework mais geral, com base na pesquisa de soluções alternativas para problemas similares analisadas durante a revisão de literatura. O framework deve ser útil não só para explorar o uso de gestos em outros domínios e aplicações como também para testar e comparar, com base em critérios como robustez ou tempo de processamento diferentes soluções e algoritmos para cada um de seus componentes, em diversos domínios.
Cada uma das atividades em que o reconhecimento de gestos geralmente se divide corresponde a um módulo nesta arquitetura. O modelo dos gestos está na classe G2gGesture. G2gCapture provê uma interface para capturar imagens 2D de uma ou mais câmeras ou sequências de vídeo pré-gravadas (usadas para testes, por exemplo). As imagens devem ter as mesmas dimensões, mas não necessariamente o mesmo número de cores. Um dispositivo pode, por exemplo, fornecer uma imagem colorida da cena e uma imagem em escala de cinza representando um mapa de profundidades. Sobre essas imagens é que é feita a segmentação, cuja interface é definida por G2gSegmentation. G2gAnalysis e G2gRecognition definem as interfaces para as classes que implementam a análise e o reconhecimento dos gestos, respectivamente.
O fluxo de informações pelo sistema em cada passo de tempo é o seguinte. Uma ou mais imagens servem de entrada para o módulo de captura de imagens, que as disponibiliza como um objeto IplImage do OpenCV (OpenCV, 2010). Esse formato de imagem equivale ao formato BMP (pixels armazenados em um vetor, sem compactação e com canais de cores entrelaçados) e foi escolhido não só pela comodidade em implementações que usem o OpenCV mas também pela velocidade de acesso a seus elementos.
O módulo de segmentação faz uso dessas imagens e provê um objeto da mesma classe (e tamanho, mas não necessariamente número de cores) contendo a imagem segmentada.
Baseada nessa imagem, a análise fornece um objeto G2gFeatureCol, uma coleção de características que, por sua vez, é usada pelo reconhecimento para, por fim, se obter um gesto como saída.
A Figura 9 mostra esse fluxo de informações em um diagrama de atividades da UML 2.2 que representa o modelo de fluxo de objeto da Framework de Gestures2Go.
Figura 9 - Modelo de fluxo de objetos do framework
G2gFeatureCol é uma coleção de objetos do tipo G2gFeature. Cada um desses objetos contém uma string de identificação que descreve a característica e um vetor de valores de ponto flutuante ou uma imagem. O vetor de valores, ou um único valor, são usados mais frequentemente, mas armazenar as características em uma imagem pode ser útil, por exemplo, para trabalhar no domínio da frequência. G2gFeature já define diversos identificadores, para as características utilizadas mais frequentemente na literatura de reconhecimento de gestos, visando facilitar a interface entre módulos de análise e reconhecimento desenvolvidos separadamente. O desenvolvedor pode, no entanto, utilizar o sistema com identificadores definidos por si mesmo.
Desc2Input é um módulo opcional que acompanha mas é na verdade distinto de Gestures2Go. Ele é responsável por facilitar, de uma forma bastante simples, tanto a integração com aplicações ou sistemas que não precisam estar cientes de Gestures2Go quanto interação multimodal. Esse módulo simplesmente traduz as entradas que recebe, que são descrições (como um identificador numérico, uma string ou uma descrição em XML, por exemplo), para outro tipo de entrada, por exemplo para um sistema operacional ou gerenciador de interface (como por exemplo um evento de "key down" ou "mouse movement") ou para outro sistema, como um engine de jogos. As entradas de Desc2Input podem ser descrições de gestos fornecidas por Gestures2Go ou vindas de qualquer outro sistema, como por exemplo um sistema de reconhecimento de voz ou das entradas de um tapete de dança, e aí reside a possibilidade de interação multimodal. Uma implementação desse módulo para Microsoft Windows é descrita na seção 3.3.
Como esta arquitetura é formada em grande parte por interfaces, é possível criar uma única classe que, através de herança múltipla, implemente toda a funcionalidade do sistema. Isto em geral é considerado uma má prática em orientação a objetos e evitá-la é inclusive uma das razões por que a agregação é considerada preferível à herança (Eckel, 2003). Existem padrões de projeto (design patterns) que poderiam ter sido usados para forçar o uso de agregação e impedir a herança múltipla, mas esta arquitetura opta por permiti-la por uma razão. O reconhecimento de gestos pode ser bastante custoso em termos de processamento e, para ser usada como forma de interação, deve ser realizada em tempo real. Muitos algoritmos podem ser melhor otimizados para velocidade ao realizar mais de uma atividade (por exemplo, segmentação e análise) em conjunto. Além disso, a análise e o reconhecimento estão fortemente acoplados em alguns algoritmos e forçar sua separação poderia fazer com que o problema de reconhecimento se tornasse ainda mais complexo. Portanto, ainda que em geral seja recomendável evitar o uso de herança múltipla e implementar cada atividade em um classe distinta, facilitando a troca de módulos ou seu desenvolvimento em paralelo, Gestures2Go mantém a possibilidade de utilizá-la por boas razões.
Por fim, todas as classes neste sistema devem implementar os métodos init() e cleanup(), preferíveis ao uso dos operadores new e delete (o
sistema está implementado em C++) para evitar problemas com herança múltipla e sincronização (Eckel, 2003).
5 TESTES E RESULTADOS
Ao longo do desenvolvimento do trabalho e principalmente em suas etapas finais, foram realizados seis tipos de teste com o sistema. No primeiro, visando reduzir o acoplamento entre a segmentação e o reconhecimento de posturas para testar a estratégia adotada, foram feitos testes estáticos deste reconhecimento com 96 imagens de mão já segmentadas, incluindo variações para diversas posturas. O segundo tipo de teste foi interativo, utilizando um aplicativo que permite a calibração do sistema, exibe a postura detectada (se estiver entre as possíveis) e permite o envio de comandos para outras janelas. Esse aplicativo foi usado para testar todos os tipos de gestos e o uso de seus parâmetros. No terceiro tipo de teste esse mesmo aplicativo foi usado para avaliar a integração com outros sistemas e a precisão do uso da posição da mão como parâmetro para permitir a manipulação de objetos no desktop. A velocidade de diversas etapas do reconhecimento foi medida no quarto tipo de testes. Como já foi comentado, esses primeiros quatro testes foram utilizados constantemente durante o desenvolvimento, como forma simples de teste de regressão, mas os resultados desses testes durante o processo de desenvolvimento não foram, em sua maior parte, registrados. No quinto foram realizados os testes mais interessantes, a integração e o passo-a-passo cognitivo com outros aplicativos. Esses testes são descritos em maior detalhe nas subseções seguintes.
O último teste, que também se relaciona com as posturas, mediu simplesmente a dificuldade de se adicionar novos elementos ao conjunto de posturas conhecidas. Um usuário sem experiência com o sistema adicionou a esse conjunto 3 posturas: uma com somente os dedos indicador e médio estendidos e as posturas 12 e 16 (OK e garra) mostradas na Figura 2. Foram necessários menos de 10 minutos por postura para manipular o modelo 3D de mão utilizado, gerar figuras de referência e rodar um executável sobre elas para incluir suas características ao conjunto de posturas conhecidas.