Para utilizá-la é simples: o usuário só precisa usar óculos 3D, comandos de voz e as mãos para manipular os objetos. Além disso, todo o sistema usa apenas dispositivos de baixo custo, como o Kinect, e não requer o uso de monitores especiais para a exibição da imagem 3D, ficando ao alcance de todos.

Aplicações

O Fusion4D foi desenvolvido como opção de manipulação direta para o atlas anatômico VIDA, do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab). Este atlas é destinado a aulas de anatomia que usam uma grande quantidade de modelos e órgãos reais, o que torna difícil e caro manter os laboratórios. O projeto representa uma alternativa para complementar o estudo através de peças anatômicas e livros dereferência. Existe ainda o potencial para seu uso fora do ambiente do laboratório, permitindo aos estudantes a visualização dos modelos 3D em casa ou em outras situações de ensino a distância.

Além da aplicação no projeto VIDA para ensino da medicina, o Fusion4D poderá ser usado para outras aplicações médicas e educacionais, bem como em jogos, publicidade, engenharia, navegação em ambientes virtuais ou telepresença, entre outras áreas.

Como funciona?

O Fusion4D utiliza imagens 3D anaglifas e um dispositivo Kinect para detecção do esqueleto e captura de voz do usuário.  O usuário interage com o sistema usando comandos de voz em inglês. Tais comandos permitem que se selecione o objeto a ser manipulado e a maneira de interagir com ele.

Comandos

O comando “grab” seleciona um objeto e permite movimentar, rotacionar ou ampliar o objeto com as mãos até que o objeto seja solto pelo comando “release“.

O comando “explode” permite observar o objeto 3D em detalhes; o comando “show label“ mostra uma etiqueta descritiva do objeto manipulado, e o comando “change model“ permite escolher outros modelos disponíveis no sistema.

Finalmente, o comando “time” permite ver como o objeto seria no passado e no futuro movimentando a linha do tempo com uma das mãos. Se o usuário precisar de ajuda sobre o sistema, o comando “help” mostra uma lista de comandos de voz.

Este projeto foi desenvolvido como trabalho de formatura pelos alunos Keila Keiko Matsumura e Roberto Sonnino, formandos da turma de 2011 do Curso Cooperativo de Engenharia de Computação, e orientado pelos professores Dr. Romero Tori (orientador) e Dr. Ricardo Nakamura (coorientador), membros do Laboratório de Tecnologias Interativas da Escola Politécnica (Interlab).

Para mais informações do projeto e dos resultados obtidos e trabalhos futuros, acesse o site do Fusion4D.

Introdução

Logo do Sistema

Conceitos:

• Business Process Management (BPM)

BPM é uma prática de desenvolvimento, execução, análise de desempenho e simulação de Processos de Negócios para trabalhar no na continua otimização e ciclos de vida desses processos.

• Service-Oriented Architecture (SOA)

Uma prática de desenvolvimento de software que emprega disciplinas e linguagens de modelagem para fornecer soluções táticas e estratégicas aos problemas das empresas. Ela defende uma visão total da analise, desenho e arquitetura de todas as entidades organizacionais do software, concebendo-as como recursos de serviços-orientados, isto é, serviços.

Exemplo de Processos Aliados a Serviços

• Processo de Lançamento de Celulares:

Metodologia

• Estudo do Processo

Exemplo de Processo Modelado em Linguagem EPC

• Concepção do Projeto de Software

• Implementação do Projeto

Implementação com a ferramenta webMethods

• Testes e Análise de Performance

• Monitoramento e Manutenção do Processo

Dashboard de Monitoramento do Processo

Resultados Esperados

Parcerias

Parceiros

O cenário vislumbrado para a aplicação publicitária é o de uma vitrine de shopping, na qual as reações expressas pelas características faciais dos passantes são registradas e avaliadas. A partir desta análise, é possível verificar como o design da vitrine e a maneira de exposição das mercadorias afetam as reações dos consumidores, tanto positivamente como negativamente. Constituindo assim uma maneira de se avaliar e comparar os impactos alcançados com diferentes estratégias.

O sistema realiza a aquisição e processamento de uma sequência de imagens obtidas através de uma webcam e possibilita, através da produção de gráficos, a exibição de informações relevantes a um usuário da área de publicidade e propaganda que deseje medir a eficácia de uma campanha publicitária.

Apesar de a ideia do nosso projeto ser bastante simples, o título do projeto ser um pouco obscuro para quem não está familiarizado com estes termos. Vamos começar explicando o título e as coisas ficarão mais claras.

O que é…

… Veículo aéreo não-tripulado?

Um Veículo Aéreo Não-Tripulado, também conhecido pela abreviação VANT, é qualquer tipo de aeronave (como aviões, balões, helicópteros) que não precise de um piloto para ser guiada. No nosso projeto, utilizamos um dirigível cheio de gás hélio para representar o VANT.

… Mensagem CPDLC?

O CPDLC (Controller Pilot Data Link Communications) é uma aplicação utilizada para a comunicação entre os controladores de voo, localizados nas torres de comando, e os pilotos, localizados na aeronave tripulada. Uma mensagem CPDLC é uma mensagem de texto que segue o formato definido na especificação da Organização Internacional de Aviação Civil (ICAO – International Civil Aviation Organization). O piloto recebe e envia mensagens CPDLC utilizando um dispositivo denominado MCDU.

… Controle?

No contexto do nosso projeto, controle significa o envio de comandos, que poderão ser aceitos ou recusados pela aeronave.

O projeto

Agora sim: o nosso projeto trata de controlar um balão a partir do envio de comandos, como virar à direita, subir ou descer e alterar a velocidade, utilizando um protocolo de comunicação já existente e já utilizado na Aeronáutica hoje. Comportando-se como um VANT autônomo, o balão deve tomar decisões sobre estes comandos recebidos, decidindo se pode ou não executá-los, com base em variáveis medidas de um conjunto de sensores embarcados.

Motivação

A ideia do nosso projeto é que ele sirva como uma prova de conceito, ou seja, que ele mostre que é possível, controlar um VANT à distância, apenas através da troca de mensagens CPDLC e que, ainda assim, o voo realizado seja tão ou mais seguro quanto ele seria se existisse um piloto a bordo.

Um dos motivos para isso é que existem diversas situações em que a presença do piloto restringe a duração do voo. Um exemplo disso são voos de monitoramento de áreas de fronteira. Estes voos normalmente são utilizados para coleta de imagens, e não existe uma carga sendo transportada ou um destino específico. É interessante, portanto, não depender de um piloto, que pode ficar exaurido fisica e psicologicamente em um voo muito longo.

Outro motivo é que existem muitos acidentes aéreos causados por falha humana. Um piloto, por ser um ser humano, naturalmente está sujeito a cometer erros, mais ainda se não tiver um treinamento adequado. Se for possível substituí-lo por um sistema computacional devidamente projetado, implementado e testado, o número de acidentes será reduzido, tornando o espaço aéreo um lugar mais seguro.

Implementação

O sistema pode ser dividido em três módulos, mostrados na figura abaixo:

Diagrama de blocos do sistema de controle implementado

ACARS

O ACARS (Aircraft Communications Addressing and Reporting System) é um simulador de código aberto que foi utilizado no projeto, nós fizemos apenas pequenas alterações no código-fonte. O simulador completo que foi utilizado é composto por dois submódulos. O primeiro é o servidor ATC, cuja função é centralizar a comunicação entre o controlador e o piloto, registrando aeronaves e transmitindo para o destinatário (controlador ou piloto) as mensagens que são recebidas. O segundo submódulo possui, entre outras coisas, uma interface, mostrada abaixo, que permite o envio de mensagens CPDLC para as aeronaves – no nosso caso, o balão.

Interface para criação de mensagens no padrão CPDLC

Módulo Python

Idealmente, as mensagens CPDLC seriam enviadas diretamente do servidor do ACARS para o balão. Contudo, o microcontrolador utilizado no projeto (Atmega128 usado no Arduino Uno) possui severas restrições de processamento, tendo apenas 32KB disponíveis para o código-fonte e 1KB para a área de dados. Assim, foi introduzido um módulo que representa parte do sistema que normalmente ficaria na aeronave, mas que roda em um computador em terra. Este subsistema é responsável por receber mensagens CPDLC, traduzi-las para mensagens MBCP (My Blimp Control Protocol) e então transmiti-las ao balão. O MBCP é um protocolo bastante simples desenvolvido especificamente para o projeto.

Abaixo é mostrada a interface que foi desenvolvida para este módulo: ela imita a aparência de um MCDU, mostrando mensagens recebidas pela aeronave (denominadas de uplink, em laranja) e enviadas (de downlink, em verde).

Interface do módulo Python, emulando um MCDU

Módulo embarcado

Finalmente, temos o módulo embarcado. Este é composto pelo programa que roda no Arduino assim como pelos circuitos eletrônicos auxiliares que permitem a leitura dos sensores, o controle dos motores e o envio/recebimento de mensagens MBCP via rádio. Utilizando as leituras dos sensores, o balão consegue inferir qual o seu estado com relação ao ambiente em que se encontra, tomando decisões sobre a possibilidade de execução de um comando, e rejeitando aqueles que puderem colocá-lo em uma situação de risco.

A figura abaixo mostra a gôndola que é presa ao balão, com os três motores à mostra, assim como os três sensores infravermelhos, utilizados para detectar a distância de obstáculos frontais e laterais.

Gôndola que é presa ao balão, com sensores e motores visíveis

Dentro desta gôndola ficam os circuitos descritos acima, e mostrados na figura abaixo. Da esquerda para a direita, temos:

• Arduino: contém o microcontrolador que permite a execução da lógica de controle do balão.
• Placa de cirtuito impresso: projetada e desenvolvida especialmente para o projeto. As três placas menores (duas vermelhas e uma verde) são sensores inerciais – uma IMU (Inertial Movement Unit), um acelerômetro e uma bússola digital.
• Transceptor: permite envio e recebimento de mensagens de rádio.

Circuitos eletrônicos embarcados no balão

Esta foi uma brevíssima descrição do projeto. Quem estiver interessado em conhecer os detalhes pode entrar em contato ou fazer o download da monografia, que em breve estará disponível.

E não percam a demonstração prática, que acontecerá no dia 14 de dezembro, no Galpão da Administração da Poli!

Tivemos a participação de 86 colegas respondendo o cargo, o cargo registrado em carteira, tempo te formado, salário bruto e a quantidade de funcionários na empresa. Apesar do relativamente pequeno número de respostas, essa pesquisa nos possibilita ter uma visão razoável de quão aquecido anda o mercado de engenharia de computação no Brasil.Pretendemos fazer essa pesquisa anualmente, incrementando e evoluindo as perguntas conforme os feedbacks recebidos. Continuarei meu árduo trabalho de incentivo, com amor e carinho, para que mais pessoas respondam ao questionário.

A tabela da pesquisa pode ser vista nesse arquivo do Google Spreadsheet, mas, a tabulação e geração dos dados foi feita nesse arquivo de Excel.

Como pode ser observado no formulário de preenchimento, foram definidos intervalos para os salários, portanto, os valores das médias não são exatos (uma pessoas que ganha R$11.000,00 aparecerá nos dados como se ganhasse R$25.000,00) e devem ter gerado certa discrepância. Lição aprendida… ano que vem, deixaremos que cada um coloque o salário exato para melhorar a precisão da pesquisa.

Salário médio

O salário médio dos 86 participantes é de R$6.854,65, um salário muito bom, quando se observa que a média da região metropolitana de São Paulo (a maior do país) é de menos de R$1.700,00, conforme apuração do IBGE.

Cargo

Como o campo de cargo podia ser preenchido livremente, obtivemos respostas bastante diversas (bombeiro?), dificultando um pouco a tabulação dos dados. Foram agrupados cargos que, ao meu ver, pareciam coerentes, mas, ainda assim, obtivemos um “outros” de 14% das respostas.

(clique nas imagens para ampliar)

De todos os cargos preenchidos, as maiores médias salariais foram a de analistas financeiros e de negócios e a de engenheiros de software. As menores médias ficaram com desenvolvedores e analistas de sistema.

Tempo formado

Tivemos uma boa divisão de participantes para cada um dos tempos definidos, nos possibilitando ter uma boa visão.

Seguindo para os resultados, obtivemos o padrão esperado por um engenheiro. Quem se formou há mais tempo, ganha mais, com uma média de R$12.100,00 (observando a minha cagada na hora de criar os valores – 10.000 a 25.000). Quem se formou a menos de um ano ganha uma média de aproximadamente R$4.500,00.

Quantidade de funcionários da empresa

Aqui as respostas foram bem discrepantes com uma maioria esmagadora de politécnicos trabalhando em empresas com mais de 100 funcionários.

Essa discrepância acaba invalidando um pouco a pesquisa, já que pontos fora da curva acabam contando muito quando temos apenas meia dúzia de pessoas em um determinado tamanho de empresa.

Conclusões

A conclusão geral dessa pesquisa é que precisamos fazer mais pesquisas! Os dados obtidos foram satisfatórios, mas, mais respostas, saltos salariais menores e outras perguntas teriam melhorado em muito seu valor.

Concluo que nossa área está quente, mas precisamos “valorizar nosso passe” ainda mais.

Até a próxima, com melhores e perguntas e, se meu “amor e carinho” der certo, mais respostas!

O que é a Ploobs Engine ?

É uma Engine para criação de jogos e aplicativos gráficos desenvolvida em XNA 4.0, C# .Net 4.0 e HLSL. Criada para ser simples de extender e fácil de usar, mesmo para aqueles que não conhecem com profundidade computação gráfica.

Cena com Reflexão, Refração, Animação, Glow, iluminação e SkyBox

O framework construído é bastante extenso, sendo constituído de diversos módulos responsáveis pelas tarefas mais comuns utilizadas em jogos como: Controle de Entrada, Simulação Física, Renderização Gráfica, Inteligência Artificial e Controle de Recursos.

O foco principal da Engine esta na parte gráfica, que usa a técnica de renderização Deferred Shading, a mesma encontrada em jogos como Startcraft II, Crysis II e KillZone II.

O render construído fez parte do nosso projeto de formatura. Uma explicação bastante profunda do funcionamento da técnica e da nossa implementação pode ser encontrada na nossa tese.

Quais são as Funcionalidades Principais ?

A PloobsEngine suporta praticamente todas as funcionalidades de uma Engine Directx 9c, sendo as principais:

• Deferred Render com suporte a Bump Map, Specular Map, Glow Map e Paralax Map (técnicas usadas para simular materiais e aumentar o realismo dos jogos)
• Sistemas de partículas
• Simulação física
• Som 3D e 2D
• Luzes Dinâmicas com Sombra
• Animação por ossos (Bone Animation)
• Terrenos
• Reflexão e Refração em Tempo Real
• Sistema de GUI (HUD)

Foram utilizados diversos algoritmos e técnicas encontradas em jogos que estão atualmente no mercado, sempre que possível escolhíamos algoritmos que exploravam ao máximo a GPU.

O nosso grande diferencial esta no uso da técnica Deferred Shading ao extremo, nenhuma Engine XNA não comercial utiliza esta técnica desta forma.

Para uma lista bem mais completa das funcionalidades, de uma olhada no site do projeto.

Ambient Scattering, Vegetação e Partículas ao fundo

O que você precisa para começar a usar a Ploobs Engine ?

Para um uso mais simples, somente conhecimento básico de C# é necessário, não é preciso conhecer computação gráfica ou XNA.

Para o desenvolvedor, é necessário instalar a XNA 4.0 SDK, o .Net 4.0 Framework e o Visual Studio 2010 completo ou express. Em termos de hardware é necessário apenas ter uma placa de vídeo compatível com DirectX 10 (Shader Model 3.0).

Por onde que eu começo ??!!

Temos uma seção com tutoriais básicos no site do projeto, além de alguns pacotes com diversos demos de funcionalidades (cerca de 30 demos bastante comentados) .

Estamos trabalhando para criar outros tutoriais e alguns demos reais (pequenos Showcases). Junto com a DLL da Engine, temos um documento (.chm) explicando os conceitos básicos da Engine.

Como que a Engine é distribuída ?

Atualmente existem as seguintes formas de distribuição:

Iluminacao e Lod

• Código Fonte Completo através do nosso repositório Mercurial (este repositório contem apenas a ultima versão estável no branch principal).
• DLL Única contendo todas as dependências e documentação.
• Através dos pacotes de Demos.

A idéia é lançar uma versão estável periodicamente e diversas outras versões betas intermediarias. Caso algum bug crítico seja encontrado, iremos corrigir a versão estável o mais rápido possível. Os Demos e o arquivo de documentação serão atualizados apenas no lançamento de versões estáveis, a documentação do site será atualizada assim que as versões intermediárias forem lançadas. Pretendemos manter compatibilidade com as versões antigas sempre que for possível.

Nosso RoadMap

Num futuro próximo pretendemos melhorar a estabilidade, a  documentação e corrigir os bugs que vão “surgindo”, em um futuro um pouco mais distante pretendemos adicionar suporte a Rede.

Junte-se a nós !!!

Iluminacao avancada

Antes de tudo, o projeto não tem fins financeiros.

Precisamos de pessoas que gostem de computação gráfica (não é necessário nenhum conhecimento prévio, temos diversos materiais para auxiliar no aprendizado do pessoal), principalmente programação de  shaders (código que roda na placa de vídeo).

Precisamos também de pessoas dispostas a fazer demos e Showcases (pessoas que não irão entrar em contato com o core da Engine).

Duvidas ? Quer saber mais ? Deixe um comentário aqui ou mande um email: contato@ploobs.com.br

Time Atual

Thiago Dias Pastor – COOP10

Bruno Duarte Correa – COOP10

Links

XNA 4.0 Alpha Release: http://ploobs.com.br/?p=725

Site do projeto: http://ploobsengine.codeplex.com/

DLL, Documentação e Tutoriais (Xna 3.1 Version): http://sourceforge.net/projects/ploobsengine/files/

Nosso Fórum: ploobs.com.br/forum

Nosso Blog: ploobs.com.br/

Nosso Twitter : @ploobsengine

Agradecimentos

• Toda a galera do COOP10 por ter nos aguentado nesses últimos anos, em especial o Filipão e o Kayatt.
• Ao Professor Ricardo Nakamura, nosso orientador no TCC, e seus conselhos sagazes.
• A nossa Equipe da ImaginCup 2010, a experiência adquirida mudou completamente o desenvolvimento da engine.

ScreenShots

Normalizing latin chars (á, é, ç, …) to ASCII chars (a, e, c, …) in our search index and queries was pretty easy. We changed the text field definition to the following schema:

1
2
3
4
5
6
7
8
9

<fieldType name="text" class="solr.TextField" omitNorms="false">
	<analyzer>
		<charFilter class="solr.HTMLStripCharFilterFactory"/> <!-- strip HTML -->
		<tokenizer class="solr.StandardTokenizerFactory"/>
		<filter class="solr.StandardFilterFactory"/>
		<filter class="solr.LowerCaseFilterFactory"/>
		<filter class="solr.ASCIIFoldingFilterFactory"/> <!-- convert accented chars to ASCII -->
	</analyzer>
</fieldType>

A more difficult problem was to sort accented string fields. By default, the class of the sunspot’s string field is solr.StrField. The string field is used for sorting, but was showing problems to sort accented inputs. For the inputs “árvore”, “bola”, “ano” it was showing the sorted result: “ano”, “bola”, “árvore” (the correct result would be “ano”, “árvore”, “bola”).

The problem with accented chars sorting is that non-ASCII chars are represented as HTML entites (for example, á instead of á) and special chars as “&” goes after alphanumeric chars in a sort.

To solve this, we changed the string field’s class to solr.TextField but making sure that its tokenizer would not create more than one token for each entry. The tokenizer we used was the KeywordTokenizer. The final schema for the string field was:

1
2
3
4
5
6
7

<fieldType name="string" class="solr.TextField" omitNorms="true">
	<analyzer>
		<tokenizer class="solr.KeywordTokenizerFactory"/>
		<filter class="solr.LowerCaseFilterFactory"/>
		<filter class="solr.ASCIIFoldingFilterFactory"/>
	</analyzer>
</fieldType>

Não sou nenhuma fã da Apple e sequer tenho um produto da empresa. Mas quando vi o livro vendendo na Campus Party nesse ano, acabei comprando por ser um “livro de histórias” da computação e porque fiquei sabendo que o Woz iria dar uma palestra na Campus e autografar os livros. Por fim, não consegui ir a palestra, mas fiquei sabendo que foi muito bacana.
Quando se fala em Apple, em geral, as pessoas associam a figura de Steve Jobs. Porém, a empresa foi fundada por dois Steves, o Jobs e o Wozniak como bem mostrado no filme “Piratas do Vale do Silício“. O livro, antes de ser de fato sobre a história da Apple, é uma biografia de Steve Wozniak, desde seus tempos de criança até sua vida após a Apple.

No início do livro, Woz conta como seu pai foi seu grande motivador a se tornar um engenheiro. A forma como ele o motivava era bem interessante: apenas respondia o que o filho o perguntava sem querer “adiantá-lo”, mas de uma forma que o induzia a ter mais curiosidade em entender sobre eletrônica. Com certeza, pode-se notar que ele fez um excelente trabalho com marcas profundas na formação de Woz.

Durante sua infância Woz se envolveu em vários projetos de eletrônica, tanto junto com seu pai quanto com os Garotos Eletrônicos. Por exemplo, quando Woz tinha 11 anos, construiu a sua própria estação de radioamador e obteve uma licença de radioamador. Aos 13 anos, foi eleito presidente do clube de eletrônica de sua escola e ganhou o primeiro prêmio em uma feira de ciências regional por uma calculadora baseada em transistores.

Wozniak também esclarece algumas coisas que dizem por ai sobre a Apple e a invenção do computador pessoal. De fato, Woz projetou sozinho o primeiro computador pessoal que existiu, que veio a se tornar o Apple I.

O livro me levou a conclusão de que o verdadeiro empreendedor da Apple era o Steve Jobs, enquanto o Wozniak era o inventor de seu produto. Isso fica bem claro quando, pressionado por um investidor, Woz diz que não queria sair de seu emprego na HP para tocar a Apple junto com Jobs. Queria que fosse uma coisa paralela na sua vida como tinha sido até então. Ou seja, a Apple jamais teria existido se Jobs e Woz não tivessem se juntado. Apesar de Woz deixar claro que os dois eram muito diferentes, por outro lado, eles, de certa forma, se completavam: sem a iniciativa de Jobs, a Apple não teria sido criada e sem a grande sacada de Woz, a Apple não teria seu produto.

Um boato que esclarece no livro é de que teria saído da Apple por estar insatisfeito com as atitudes de seus administradores. Na verdade, após sofrer um acidente de avião e ficar 5 semanas afastado do trabalho com amnesia, Woz decidiu continuar afastado da empresa e voltar a Berkeley para terminar seu curso de Engenharia. Depois de terminar o curso, voltou novamente a trabalhar na Apple. Porém, ele sentiu que já não havia mais espaço para inovar e, quando uma outra ideia de tecnologia surgiu em sua cabeça, decidiu que era hora de se dedicar a ela. A ideia era simplesmente o que hoje conhecemos por controle remoto universal.

Após isso, ele ainda se aventurou na área da docência: começou a dar aulas de informática para crianças.

A principal lição que fica do livro é que o incentivo a curiosidade e a criação de condições para a descoberta das respostas às questões levantadas pelas crianças podem gerar grandes frutos: pessoas com pensamento independente como Woz. Ele conseguiu vislumbrar que cada pessoa poderia ter um computador em casa e que isso transformaria suas vidas, mesmo quando quase todos achavam isso uma grande bobagem.

iWoz é um bom livro e sua leitura é recomendada para todos aqueles da área da computação, pois trata de questões bem comuns da nossa área de uma forma muito humana.

P.S.: A única coisa que me irritou no livro é um erro de tradução do inglês para o português. Traduziram “register” como “registro”, quando, na verdade, deveria ser registrador. FAIL!!!

.

Teoria envolvida

Para a última etapa do projeto, foi necessário conhecer e organizar todas as faces pelos momentos em que elas aparecem nas tomadas do vídeo e a que pessoas elas correspondem. Para isso, foram utilizados alguns conceitos e teorias já apresentados nos artigos anteriores da série, mas também outros tópicos ainda não estudados. Para todos os assuntos, serão listadas fontes interessantes para estudo.

Detecção de características faciais (olhos, nariz, boca):

Técnica de Viola e Jones com as cascatas adequados para cada característica facial. Mais detalhes sobre essa técnica em Detecção e rastreamento de faces em vídeos – Como detectar faces em vídeos?.

Transformação Afim:

Link da Wikipedia sobre transformação afim Link da Wikipedia sobre a matriz de transformação Como realizar transformação afim utilizando o OpenCV Link interessante para um projeto da Universidade do Porto que trata de mosaico de imagens. Com a leitura, além de aprender sobre transformação afim e correlação, você entenderá outra possibilidade de uso desse tipo de transformação e também outras teorias envolvidas para a realização desse projeto.

Correlação:

Fast Normalized Cross-Correlation Como realizar Template Matching utilizando o OpenCV Código exemplo sobre Template Matching utilizando OpenCV

Kmeans:

Link da Wikipedia sobre Kmeans Link explicando sobre Kmeans Link para uma explicação curta e um exemplo Slides explicativos sobre o Kmeans

.

Aplicação no projeto

A ideia central dessa etapa era preparar os dados para a criação da estrutura de indexação a ser utilizada pelo hipervídeo. Para isso, inicialmente, seriam identificadas as expressões faciais para a face de cada pessoa presente em uma tomada. O objetivo era guardar a face mais frontal possível e também os pontos necessários para a transformação afim que ocorre como passo seguinte. Com essa transformação afim e a aplicação da máscara, preparávamos as faces pela criação de um padrão para que elas pudessem ser comparadas através de um método simples como o de correlação. Com o valor da correlação entre as faces calculado, utilizava-se o Kmeans para criar grupos de faces semelhantes, o que corresponderiam a faces de uma mesma pessoa. Os parágrafos abaixo explicarão com mais detalhes essas etapas. Primeiramente, foi adicionado ao sistema uma funcionalidade que permitia extrair de todo quadro do vídeo apenas a imagem de cada face existente. Com a imagem da face; olhos, nariz e boca eram identificados usando o algoritmo de Viola e Jones com um filtro de Haar em cascata adequado para cada caso. Para diminuir a quantidade de falsos positivos para essas características faciais, foram criadas regiões de interesse para cada uma delas e o método citado era aplicado apenas nessas regiões. A partir do retângulo correspondente aos olhos e ao nariz, eram extraídas as coordenadas do centro dessas características. Na figura 1 pode-se observar as características faciais detectadas.

Figura 1 - Pode-se observar o centro encontrado para o nariz, olhos e boca.

Além de útil para a próxima etapa, uma face que contém dois olhos e um nariz, é uma face ”mais frontal” do que uma que não as contém, o que é muito mais interessante para o projeto. Assim, para cada quadro do vídeo, se a imagem da face não possuísse dois olhos e um nariz, tentava-se fazer uma troca pela imagem da face do próximo quadro, contanto que nessa fossem identificadas mais características faciais. Com esse procedimento, o sistema tenta obter a melhor face possível para cada pessoa em uma tomada. O próximo passo foi, utilizando os centros encontrados anteriormente, realizar uma transformação afim da face encontrada para uma face padrão em tons de cinza. Essa tinha um tamanho pré definido (64 pixels de altura e 48 de largura) e também uma posição padrão para os olhos e o nariz (olho esquerdo: (34,26); olho direito: (15,26); nariz: (24,39) ) que foi definida a partir de medições em diversas faces e baseado em proporções faciais encontradas em [1]. Com esse procedimento, tentamos eliminar problemas de translação e rotação de uma face para outra antes da etapa de correlação. Na tentativa de eliminar problemas de iluminação, foi feita uma equalização do histograma. Depois da transformação afim, também era aplicada uma máscara à imagem. Essa máscara permite comparar somente a região dos olhos e do nariz, excluindo regiões inadequadas como a boca e os cantos da imagem já que essas regiões sofrem frequentes modificações inclusive para uma mesma pessoa, o que atrapalharia o processo de cálculo da correlação com o objetivo de encontrar faces de uma mesma pessoa. Na figura 2 observa-se o processo descrito acima para trâs casos.

Figura 2: A figura apresenta, na coluna da esquerda, a face após a transformação afim e equalização do histograma. Ao centro a máscara aplicada à imagem e na coluna da direita o resultado para a aplicação da máscara.

Até esse ponto, os problemas principais estavam relacionados a encontrar os olhos e o nariz nas faces. Nem sempre conseguíamos faces frontais em uma tomada, pois, ou ela realmente não era frontal, ou o detetor falhava, tanto não encontrando a característica desejada quanto devolvendo um falso positivo. O ajuste para esse tipo de detecção se mostrou um trabalho minucioso e longo. Em seguida, deu-se início à próxima etapa. Ela consistiu em calcular a correlação entre todas as imagens e com esses dados, montar uma matriz. Essa matriz era passada para o Kmeans, que separava as faces em grupos, sendo que cada um desses grupos possui faces de uma mesma pessoa que apareceu em diversas tomadas do vídeo. Durante essa parte do projeto, também foi projetado o segundo passo para a retirada de falsos positivos. O processo de correlação já implementado também foi utilizado para calcular a correlação entre a face candidata encontrada no vídeo e uma face padrão ideal composta por uma média de faces humanas. Se o valor resultante for acima de um limiar de alto valor, o candidato é aceito como face, caso contrário, é descartado por se tratar de um falso positivo.

.

É isso aí pessoal, encerra-se aqui essa série de quatro artigos sobre detecção e rastreamento facial dentro do contexto da criação de um hipervídeo. Espero que tenham aproveitado.

.

Referências

[1] R. M. Bertollo, D. L. da Silva, L. Oliveira, R. D. Bergoli, and M. G. de Oliveira. Avaliacao da harmonia facial em relacao as proporcoes divinas de fibonacci. Revista Portuguesa de Estomatologia, Medicina Dentaria e Cirurgia Maxilofacial, 49(N4), 2008. . .

.

.

Artigos da série:

Anterior: Como rastrear faces em vídeos?

.