osvaldo massakazu kohatsu
DESCRIPTION
TRADUTOR BASEADO EM TÉCNICAS DE RECONHECIMENTO ÓTICO E REALIDADE AUMENTADA PARA DISPOSITIVOS MÓVEISTRANSCRIPT
UNIVERSIDADE ESTADUAL DE MARINGÁ
CENTRO DE TECNOLOGIA - DEPARTAMENTO DE INFORMATICA - DIN ESPECIALIZAÇÃO EM DESENVOLVIMENTO DE SISTEMAS PARA WEB
ARTRANSLATOR: PROTÓTIPO DE UM TRADUTOR BASEADO EM TÉCNICAS DE RECONHECIMENTO ÓTICO E REALIDADE AUMENTADA PARA DISPOSITIVOS
MÓVEIS
OSVALDO MASSAKAZU KOHATSU
MARINGÁ
2012
OSVALDO MASSAKAZU KOHATSU
ARTRANSLATOR: PROTÓTIPO DE UM TRADUTOR BASEADO EM TÉCNICAS DE RECONHECIMENTO ÓTICO E REALIDADE AUMENTADA PARA DISPOSITIVOS
MÓVEIS
Monografia apresentada à Universidade Estadual de Maringá como requisito parcial à obtenção do título de especialização de desenvolvimento de sistemas para web. Orientadora Dra Heloise M. Paris Teixeira.
MARINGA 2012
UNIVERSIDADE ESTADUAL DE MARINGÁ
CENTRO DE TECNOLOGIA - DEPARTAMENTO DE INFORMATICA - DIN ESPECIALIZAÇÃO EM DESENVOLVIMENTO DE SISTEMAS PARA WEB
OSVALDO MASSAKAZU KOHATSU
ARTRANSLATOR: PROTÓTIPO DE UM TRADUTOR BASEADO EM TÉCNICAS DE RECONHECIMENTO ÓTICO E REALIDADE AUMENTADA PARA DISPOSITIVOS
MÓVEIS
Monografia aprovada em ____/____/____ para obtenção do título de Especialista em Desenvolvimento de Sistemas para Web.
Banca Examinadora:
_______________________________________ Orientadora Dra. Heloise Manica Paris Teixeira
_______________________________________ Professor Dr. Edson A. Oliveira Junior
_______________________________________ Professor Dr. Renato Balancieri
DEDICATÓRIA
Dedico esta monografia aos meus pais que me deram muito apoio e carinho nos
momentos mais difíceis da minha vida e contribuíram durante todo meu crescimento
e também nessa nova etapa de minha vida. A minha namorada pela mais pura forma
e incondicional de amor, companheirismo, incentivo, paciência e ajuda sem medir
esforços sempre presentes em minha vida, a minha orientadora que colaborou com
presteza para o desenvolvimento e concretização deste trabalho.
AGRADECIMENTOS
Agradeço a Deus, pela vida, paz e tranqüilidade em todos os momentos de minha
vida. A todas as pessoas do meu convívio que acreditaram e contribuíram direta e
indiretamente para a conclusão deste trabalho. A todos os professores da
especialização por compartilharem seus conhecimentos. A todos os amigos que
conheci durante o curso e pelos momentos de amizade e convivência.
PENSAMENTO
“A vida é uma peça de teatro que não permite ensaios.
Por isso, cante, chore, dance, ria e viva intensamente,
antes que a cortina se feche e a peça termine sem aplausos.”
Charles Chaplin
RESUMO
Em uma era dirigida pela informação e o advento de dispositivos móveis mais
robustos, ter a informação aliada à mobilidade trilha caminhos à comodidade. Neste
cenário, em um mundo globalizado onde a comunicação entre pessoas de diferentes
países e línguas tem se tornado cada vez mais comum, é necessário o
conhecimento em idiomas que são mais utilizados ou que fazem parte do cotidiano
profissional. O conhecimento de um idioma demanda tempo. Este trabalho
apresenta um protótipo de um tradutor de textos baseado em técnicas de
reconhecimento de caracteres para entrada de dados, tradução automática por meio
de webservices para processamento e realidade aumentada para visualização dos
resultados. O reconhecimento de caracteres responde satisfatoriamente no quesito
de entrada de dados enquanto que a tradução instantânea foi inviabilizada devido a
uma alteração na disponibilidade do webservice de tradução.
SUMÁRIO
1. INTRODUÇÃO.................................................................................................... 1
1.1. O problema de pesquisa.............................................................................. 1
1.2. Objetivos...................................................................................................... 3
1.3. Justificativa e Motivação.............................................................................. 3
1.4. Procedimentos metodológicos..................................................................... 4
1.4.1. Materiais e métodos............................................................................. 5
1.5. Limitações da pesquisa............................................................................... 5
1.6. Organização do documento......................................................................... 6
2. REVISÃO TEÓRICA........................................................................................... 8
2.1. Sistema operacional Android....................................................................... 8
2.1.1. Sistema de runtime............................................................................... 9
2.1.2. Bibliotecas............................................................................................ 10
2.1.3. Framework de aplicação....................................................................... 11
2.2. OCR (Reconhecimento Ótico de Caracteres) ............................................. 14
2.3. Realidade aumentada.................................................................................. 17
2.3.1. Aplicativos de tradução............................................................................. 18
2.4. Trabalhos correlatos.................................................................................... 21
3. ARTRANSLATOR: TRADUÇÃO INSTANTÂNEA PARA DISPOSITIVOS PORTÁTEIS............................................................................................................ 24
3.1. Ambiente de desenvolvimento..................................................................... 24
3.2. Modelo do protótipo..................................................................................... 26
3.2.1. Biblioteca Tesseract............................................................................. 28
3.2.2. API de processamento de imagens...................................................... 32
3.2.3. API camera manager............................................................................ 34
3.2.4. API de reconhecimento de caracteres.................................................. 41
3.2.5. API de tradução.................................................................................... 45
3.2.6. API de realidade aumentada................................................................ 48
3.2.7. Classes acessórias............................................................................... 50
4. TESTE DO PROTÓTIPO E RESULTADOS...................................................... 52
4.1. Ambiente de teste........................................................................................ 52
4.2. Descrição do Teste...................................................................................... 52
4.3. Resultados................................................................................................... 61
5. CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS.................................... 63
REFERÊNCIAS BIBLIOGRÁFICAS........................................................................ 65
LISTA DE FIGURAS
Figura 1.1 – Exemplos de símbolos em Idiomas não-latinos.
Figura 1.2 – Teclado QWERT.
Figura 2.1 – Arquitetura do Android.
Figura 2.2 – Emulador do Kit de Desenvolvimento Android.
Figura 2.3 – Emulação da Câmera do Emulador.
Figura 2.4 – Exemplo de aplicação do OCR.
Figura 2.5 – Definição dos Ambientes Real e Virtual e da Realidade Misturada.
Figura 2.6 – TranslatAR para Nokia N900.
Figura 2.7 – iTranslate para iPhone.
Figura 2.8 – Tela do aplicativo Jibbigo.
Figura 3.1 – Modelo do protótipo.
Figura 3.2 – Arquitetura da biblioteca Tesseract.
Figura 3.3 – Classe do reconhecimento de caracteres TessBaseAPI.
Figura 3.4 – Classe CameraManager.
Figura 3.5 – Função AdjustFramingRect da classe CameraManager.
Figura 3.6 – Atributos da classe CaptureActivity.
Figura 3.7 – Principais funções da classe CaptureActivity.
Figura 3.8 – Classe OcrInitAsyncTask e as funções para transferência
dos arquivos de idiomas.
Figura 3.9 – Classe OCRRecognizeAsyncTask.
Figura 3.10 – Método runHttpRequest de TranslationHelper.
Figura 3.11 – Método Translate de TranslationHelper.
Figura 3.12 – Métodos doInBackground e onPostExecute de TranslateAsyncTask.
Figura 4.1. Texto retirado de revistas.
Figura 4.2. Texto em Telas LCD.
Figura 4.3 – Site do JMF da Oracle.
Figura 4.4 – Execução da classe WebCamBroadcaster.
Figura 4.5 – Atribuição do IP na Classe SocketCamera.
Figura 4.6 – Tela do emulador sendo carregado.
Figura 4.7 – Menu de Opções.
Figura 4.8 – Tela de opções.
Figura 4.9 –Tela de opções de idiomas.
Figura 4.10 – Transferência e instalação do arquivo do idioma
Figura 4.11 – Texto envolto pelo retângulo delimitador.
Figura 4.12 – Erro no reconhecimento do texto.
Figura 4.13 – Sucesso no reconhecimento de caracteres e no texto reconhecido.
Figura 4.14 – Falha no reconhecimento de caracteres.
LISTA DE TABELAS
Tabela 1.1 – Exemplos de verbetes em idiomas com símbolos não latinos.
Tabela 2.1 – O Android em código fonte.
Tabela 2.2 – Trabalhos Correlatos.
Tabela 4.1 – Resultados do teste empírico.
1
1 INTRODUÇÃO
1.1 O problema de pesquisa
A linguagem escrita é um importante meio de transmissão da informação
inserido no cotidiano das pessoas. Contudo, quando a escrita se encontra em uma
língua desconhecida pelo leitor da informação, ela não é compreendida. Para
amenizar esse problema, soluções tecnológicas de tradução são propostas, desde
dicionários eletrônicos a tradutores instantâneos. Nos primeiros dicionários
eletrônicos, o texto não compreendido é manualmente inserido como entrada dos
aplicativos. Esses buscam em um índice alfabético e apresentam ao usuário o
resultado em forma de texto ou saída de voz. Um exemplo desse tipo de dicionário é
o Franklin TGA-470 Global Translator [FRANKLIN ELETRONIC PUBLISHERS,
2011].
O desenvolvimento da Internet e redes sem fio promoveram a
comunicação entre pessoas em qualquer hora e lugar. Com o surgimento de
dispositivos móveis com maior capacidade de processamento, foram concebidos
novos tradutores eletrônicos, como o iTranslate [APPLE STORE, 2011] e o Jibbigo
[JIBBIGO, 2011]. Esses dispositivos auxiliam a compreensão de textos, porém
necessitam que o usuário forneça a entrada de dados por meio de digitação (no
caso do Franklin TGA-4701) ou pronúncia (no caso do Jibbigo). Dessa forma, torna-
se necessário que o usuário tenha conhecimento do idioma para pronunciar as
palavras ou digitar os símbolos corretamente, o que nem sempre é uma tarefa
simples. Essa dificuldade é comum em idiomas de origem oriental como o chinês,
coreano, árabe entre outros que possuem escritas cujos símbolos são peculiares.
Essa problemática é exemplificada no seguinte cenário. Um usuário, que
conhece somente a língua portuguesa brasileira se encontra em um país de língua
inglesa e ao avistar uma placa indicando “water” deseja saber seu significado.
Utilizando o Franklin TGA-470 basta digitar “water” ou pronunciar “wô t r” no Jibbigo.
Neste cenário, os dois aplicativos citados provavelmente atenderão a necessidade
de tradução do usuário.
1 O Franklin TGA-470 é um tradutor eletrônico portátil digital.
2
Suponha que o usuário seguiu sua viagem para um país de língua de
origem latina ou neolatina, como o espanhol, francês entre outras. Também não
haveria muita dificuldade com os verbetes “água” e “eau” ou pronunciar “a̠ɣ ̞wa” e
“eau”. Como no cenário anterior, os dois aplicativos citados provavelmente
atenderiam a necessidade de tradução do usuário.
Finalmente, o usuário segue sua viagem para um país no oriente. Nesse
último cenário o usuário poderá se deparar com caracteres não-latinos, como os
ilustrados na Figura 1.1 e Tabela 1.1. Neste momento surgem as dificuldades: como
digitar tais símbolos no teclado QWERT (tipo de teclado cujas primeiras letras são o
QWERT) de seu dispositivo, que não suporta esses caracteres (Figura 1.2)? Como
pronunciá-los?
Figura 1.1. Exemplos de símbolos em Idiomas não latinos.
Fonte: O Autor.
Idioma Nome Nativo
Arabic العربية
Armenian Հայերեն
Bashkir башҡорт теле
Kashmiri क�मीर�, كشميري
Kazakh қазақ тілі
Marathi (Marāṭhī) मराठ
Tabela 1.1. Exemplos de verbetes em idiomas com símbolos não latinos.
Fonte: Google Inc., 2011.
3
Figura 1.2. Teclado QWERT
Fonte: Android Central 2012.
Nesse contexto, este trabalho propõe auxiliar a entrada de dados em
tradutores por meio do desenvolvimento de um protótipo para tradução instantânea.
A solução proposta nesta pesquisa utiliza entrada de texto visual por meio de um
dispositivo móvel provido de uma câmera e suporte touchscreen. Para tornar a
solução viável, foi utilizado um sistema de reconhecimento ótico de caracteres para
a transcrição do verbete em tipo de entrada legível para sistemas computacionais.
1.2 Objetivos
Objetivo geral
Este trabalho tem como objetivo geral contribuir com tradução instantânea
de textos que contenham símbolos de difícil compreensão pelos usuários com a
utilização de dispositivos móveis.
Objetivos específicos
• Empregar técnicas de Realidade Aumentada (RA) para simplificar o processo
de visualização de dados para tradução de textos;
• Permitir a tradução de textos entre diferentes idiomas com entrada de dados
por reconhecimento ótico de caracteres (OCR).
1.3 Justificativa e motivação
Com as vertentes do desenvolvimento mundial direcionadas para o
processo de globalização da economia, é imprescindível o estudo ou o
conhecimento de idiomas ou a competência para comunicar-se em uma língua
diferente da língua mãe. De acordo com Armin Schwegler [SCHWEGLER,2012],
quando economistas (e linguistas) escrevem sobre globalização e seus efeitos sobre
4
a sociedade moderna, classificam o idioma como sendo um bem econômico, ou seja,
pessoas que se comunicam em outros idiomas diferente da língua-pátria são
detentoras deste bem. Em adição conclui também que, no mundo globalizado as
interconexões são realizadas por intermédio de grupos de pessoas multilíngüe.
A globalização tornou essencial às pessoas se comunicarem umas com
as outras para diferentes fins como realizar negócios, diálogo político,
desenvolvimento de pesquisas, socialização, entretenimento, entre outros. Os
idiomas favorecem o relacionamento interpessoal e servem para estabelecer elos.
Entretanto, a diferença de idiomas ainda é um obstáculo na comunicação entre
pessoas.
Tradutores e dicionários eletrônicos são utilizados para atenuar as
dificuldades de tradução e no aprendizado de novas línguas. Com o advento de
dispositivos móveis mais modernos e capazes de realizar tarefas e aplicações mais
complexas, além da capacidade de conexão com a Internet, a possibilidade de
desenvolvimento de aplicativos mais práticos e eficientes tornou-se viável. Com isso,
um dispositivo móvel como um celular pode ser provido de dicionários ou tradutores
instantâneos para serem utilizados em qualquer hora e lugar.
Grande parte dos dispositivos móveis atuais é capaz de executar os
aplicativos sobre sistemas operacionais. Alguns deles como o Galaxy S2 da
Samsung, Atrix da Motorola, iPhone da Apple e Optimus da LG possuem capacidade
de processamento equivalente ao de um microcomputador desktop. Esses
verdadeiros “computadores de bolso” proporcionam a experiência de um desktop em
qualquer lugar na palma da mão.
Este cenário de desenvolvimento motivou o estudo e adoção de
funcionalidades inovadoras (providas por áreas de pesquisa como a visão
computacional, programação para dispositivos móveis, tradução instantânea online e
realidade aumentada) para o desenvolvimento do protótipo proposto nesta pesquisa.
1.4 Procedimentos Metodológicos
Quanto à natureza, esta pesquisa é classificada como aplicada. Para o
desenvolvimento da pesquisa, inicialmente foi realizado uma revisão da literatura,
buscando conhecer os principais conceitos, tecnologias e ferramentas existentes. O
levantamento bibliográfico e estudo de conceitos sobre sistema de reconhecimento
ótico de caracteres, ambiente de desenvolvimento Android, integração de serviços
5
Web e Realidade Aumentada permitiu a definição dos recursos tecnológicos
adotados no desenvolvimento do protótipo. Foram utilizados como fontes de
pesquisa artigos científicos, livros e relatórios técnicos, monografias, teses, fóruns
entre outras fontes confiáveis sobre o tema da pesquisa.
Com base na literatura, a seleção dos recursos utilizados no
desenvolvimento do protótipo considerou a facilidade de integração, desempenho,
usabilidade, manutenabilidade e portabilidade. Por ser um protótipo de tradução, é
relevante considerar o desempenho, enquanto a portabilidade em questão trata-se
dos componentes em si e não do produto final (protótipo).
Na modelagem e desenvolvimento do protótipo priorizou-se a utilização
de ferramentas e tecnologias de código aberto ou softwares livres, tais como a
linguagem Java, serviços web, ambiente de desenvolvimento Eclipse, e plugins
Android. Para a avaliação do protótipo, realizou-se testes controlados.
1.4.1 Materiais e Métodos
Entre outros, os softwares utilizados no desenvolvimento do protótipo são:
biblioteca de reconhecimento ótico de caracteres; Tesseract; serviço web de
tradução; Google Translate; IDE Eclipse com plugins ADT (Android Development
Tools); o kit de desenvolvimento Android; Android SDK.
O hardware utilizado no desenvolvimento, testes e avaliação é composto
de um notebook com processador Intel Centrino Core Duo Processor 1.83 GHz,
RAM de 0,99 Gibabytes SDRAM e um smartphone provido do sistema operacional
Android com câmera e sistema touchscreen disponíveis ou um emulador.
1.5 Limitações da Pesquisa
A presente pesquisa apresenta as seguintes limitações. A primeira refere-
se ao fato do aplicativo não realizar o reconhecimento dos caracteres capturados
pela câmera numa taxa de 100% de acurácia. Outra limitação refere-se ao tempo de
processamento decorrente deste reconhecimento. A maior parte do tempo completo
de processamento do aplicativo é utilizado pela etapa de reconhecimento. O tempo
total é composto pelo tempo gasto do resultado do reconhecimento de caracteres,
pela troca de mensagens com o serviço de tradução e pela exibição da tradução
para o usuário na tela do dispositivo. Como trabalho futuro se faz necessário um
estudo para melhorar a acurácia e tempo de processamento do aplicativo proposto.
6
Uma limitação do protótipo, quanto a tradução de textos, atribui-se a
quantidade de máxima de caracteres a serem traduzidos. Esta quantidade máxima
limita-se a 4.500 caracteres. Caso o texto a ser traduzido ultrapasse este limite, o
texto é truncado considerando-se sempre a posição do primeiro caracter como ponto
de início para a contagem dos caracteres.
Os testes finais do protótipo foram restritos em relação à etapa de
tradução instantânea. Tal restrição se deve ao fato da versão do Google Translate
API passar a ser paga durante a etapa de execução de testes finais no protótipo.
Conforme Jeff Chin [CHIN, 2012], gerente de produtos da Google, a versão gratuita
do Google Translate tornou-se obsoleta e removida desde o dia 01 de dezembro de
2011, dando lugar a versão paga com suporte a 50 idiomas.
Atualmente a tradução do Google é oferecida aos usuários comuns
somente pelo site do Google Translate e pela tradução de páginas da Internet,
sendo o Web Service disponível apenas na versão paga. Como trabalho futuro, os
testes poderão ser complementados com a aquisição da versão paga ou pela
solicitação de uma versão disponibilizada pela Google para Universidades.
1.6 Organização do Documento
O presente trabalho é organizado como segue. O capítulo 1 aborda
questões relacionadas ao problema de pesquisa, justificativa, objetivos, metodologia,
material e limitações da pesquisa.
O capítulo 2 apresenta os principais conceitos das tecnologias adotadas
para o desenvolvimento do protótipo, como o sistema operacional Android, o
reconhecimento ótico de caracteres, a realidade aumentada e o sistema de tradução
instantânea. São descritos alguns trabalhos correlatos e uma breve comparação
entre eles e este trabalho.
O capitulo 3 descreve o protótipo desenvolvido, o ambiente de
desenvolvimento, arquitetura, as classes desenvolvidas, as bibliotecas open source
utilizadas como a API de processamento de imagens e a Tesseract e o código fonte
das funções principais. Estão inclusas, a API da câmera, a API do reconhecimento
ótico de caracteres e a API de tradução. Neste capítulo também apresenta-se uma
arquitetura do protótipo e as ligações com web services.
7
O capítulo 4 aborda o teste do protótipo. São descritos o ambiente
experimental, o tipo das entradas, os passos do teste, resultados obtidos e
conclusões sobre os resultados obtidos.
Finalmente, o capítulo 5 apresenta a conclusão deste trabalho,
contribuições, trabalhos futuros e um retrospecto do trabalho.
8
2 REVISÃO TEÓRICA
Este capítulo apresenta os principais temas estudados para o
desenvolvimento do trabalho. São introduzidos conceitos sobre a arquitetura do
sistema operacional Android e seus componentes, reconhecimento ótico de
caracteres, realidade aumentada e trabalhos correlatos na área.
2.1 Sistema Operacional Android
O Android é um sistema operacional inicialmente desenvolvido pela
Google e que atualmente está sendo continuado pela Open Handset Alliance. Porém,
a gerência do projeto e a engenharia de processos é de responsabilidade da Google
[ANDROID DEVELOPER, 2011]. É um sistema operacional livre e de código aberto
(sob licença Apache 2.0), executado sobre um kernel Linux (monolítico) versão 2.6
modificado para serviços essenciais como segurança, gerenciamento de memória,
pilha de rede e modelo de drivers. O kernel do Linux também é responsável pela
comunicação entre o hardware e o software, ou seja, ele funciona como uma
camada de abstração entre hardware e software. Pra ser mais específico, o Android
corresponde a uma pilha de softwares que inclui um sistema operacional, um
middleware e as aplicações chave.
O Android é basicamente estruturado em kernel linux, bibliotecas, sistema
de Android, framework de aplicações e as aplicações propriamente ditas. A Figura
2.1 ilustra uma visão geral da arquitetura Android. A camada mais inferior é a
correspondente à camada do kernel Linux. Nesta camada localizam-se os
componentes que fazem a comunicação entre o hardware do dispositivo, como
câmera, auto falantes, disco de armazenamento, etc, e o Android. Logo acima
localizam-se as bibliotecas do sistema e a máquina virtual Dalvik que faz a execução
dos aplicativos. O Application Framework é a camada que corresponde aos
componentes que gerenciam e que são utilizados no desenvolvimento de novas
aplicações. Por fim, a camada de aplicações localiza-se no topo da pilha de
softwares, onde estão os aplicativos (programas) do dispositivo, tais como agenda
telefônica, navegador, calculadora, entre outros.
9
Figura 2.1. Arquitetura do Android
Fonte: Android Developer, 2011.
2.1.1 Sistema de Runtime
Esta pilha de softwares consiste em aplicações Java sendo executadas,
cada qual com sua instância e processo próprios, em um framework de aplicação
baseado em orientação a objetos sobre bibliotecas nativas Java executadas em uma
máquina virtual Dalvik com compilação JIT (Just-in-Time). Essa compilação JIT ou
tradução dinâmica é essencial pois otimiza a performance de execução, ao passo
que dispositivos móveis possuem uma arquitetura de hardware restrita.
A máquina virtual Dalvik suporta a execução de múltiplas VMs
eficientemente. É uma máquina baseada em registradores e executa classes
compiladas por um compilador Java que converte o código fonte em um executável
“.dex” através da ferramenta “dx”. O formato “.dex”, Dalvik Executable, é otimizado
para um consumo mínimo de memória.
A arquitetura do Android permite que os aplicativos sejam desenvolvidos
na linguagem de programação Java. O aplicativo controla o dispositivo através de
bibliotecas Java desenvolvidas pela Google.
10
2.1.2 Bibliotecas
O Android possui um conjunto de bibliotecas C/C++ usado por vários
componentes do sistema Android. Elas estão disponíveis aos desenvolvedores
através do framework de aplicações Android. As bibliotecas escritas em C/C++
incluem:
• Surface Manager: gerencia o acesso ao subsistema de display e realiza a
composição das camadas gráficas 2D e 3D de múltiplas aplicações;
• Framework de media OpenCore: bibliotecas que suportam a reprodução e
gravação dos mais populares formatos de áudio e vídeo, assim como
arquivos de imagens estáticas, incluindo Mpeg4, H.264, Mp3, Aac, Amr, Jpg,
Png.
• SQLite: um poderoso e leve sistema de gerenciamento de banco de dados
relacional;
• OpenGL ES 2.0: uma API 3D gráfica que prove aceleração 3D de hardware
(quando disponível) ou um software rastreador 3D altamente otimizado;
• SGL: uma engine 2D gráfica subjacente;
• WebKit: engine de layout;
• SSL: Utilizado para armazenamento de keystores. Cada aplicação contém
sua própria keystore onde são armazenados os certificados SSL, para
verificação em webservices.
• FreeType: para renderização de fontes vetoriais e bitmaps.
• LibWebCore: uma engine que provê um navegador Android e embed.
• Biblioteca System C: uma implementação derivado do BSD da biblioteca
system padrão do C (libc) adaptado para dispositivos com Linux;
Além do C, o Android é escrito também em XML (12 milhões de linhas de
código), Java (2,1 milhões de linhas de código), em C++ (1,75 milhão de linhas de
código) e outras linguagens conforme ilustra a Tabela 2.1.
11
Tabela 2.1. O Android em código fonte.
Fonte: Android Developer, 2011.
2.1.3 Framework de Aplicação
A plataforma Android oferece aos desenvolvedores a construção de
aplicações extremamente ricas e inovadoras, pois é permitido o acesso completo ao
framework das APIs usadas nas principais aplicações. A arquitetura da aplicação é
projetada para simplificar o reuso dos componentes. Qualquer aplicação pode prover
suas funcionalidades e qualquer outra pode fazer o uso destas.
O framework para o desenvolvimento de aplicações contém os seguintes
serviços e componentes:
12
• Um conjunto de Views rico e extensível que pode ser usado para construir
uma aplicação, incluindo listas, grids, caixas de texto, botões e até um
navegador web embutido;
• Servidores de conteúdo que provêem o acesso de aplicações a dados de
outras aplicações (como lista de contatos), ou para compartilhar seus próprios
dados;
• Gerenciador de recursos que provê o acesso a recursos não codificados
como strings localizadas, gráficos e arquivos de layout;
• Um gerenciador de notificações que permite que todas as aplicações exibam
mensagens de alerta ou erro na barra de status;
• Um gerenciador de atividades que gerencia o ciclo de vida de uma aplicação
e provê uma navegação padrão.
A Figura 2.2 apresenta a interface do emulador virtual de um dispositivo
móvel, o AVD (Android Virtual Device), usado para a realização dos testes e
execução do aplicativo proposto nesta pesquisa.
Figura 2.2. Emulador do Kit de Desenvolvimento Android
Fonte: O Autor.
Uma limitação existente no emulador do Android é quanto o requisito
câmera. O emulador do Android não prove a emulação de uma câmera, requisito
necessário para este trabalho. O emulador faz apenas a indicação de que a câmera
13
será utilizada pelo aplicativo, mas uma vez executado o projeto, a câmera restringe-
se a apenas a visualização de um fundo com quadriculado, conforme a Figura 2.3.
Até o presente momento, a Google não forneceu indícios de estar trabalhando em
alguma implementação ou pelo menos uma data de quando ela estará disponível
nos emuladores.
Figura 2.3. Emulação da Câmera do Emulador
Fonte: O Autor.
A solução adotada para a emulação de um dispositivo de câmera foi por
meio da conexão de uma webcam e execução de applets em Java. O código fonte
de domínio público para esta solução é apresentada em Gibara [GIBARA, 2011]. As
classes consistem em:
• CameraSource: Uma interface que fornece ao usuário a possibilidade da
escolha da fonte da câmera a ser utilizada no emulador;
• GenuineCamera: Implementação de CameraSource que utiliza o dispositivo
câmera original do emulador (aquele que apresenta um fundo quadriculado);
• HttpCamera: Implementação que utiliza imagens obtidas através de um
inputstream de uma conexão HTTP;
• SocketCamera: Implementação que obtêm imagens diretamente de uma
conexão TCP/IP;
• BitmapCamera: Implementação que utiliza um bitmap como emulação de uma
câmera;
14
• WebcamBroadcaster: Um pequeno aplicativo Java que utiliza as bibliotecas
JMF para a transmissão de uma seqüência de imagens através de uma rede.
Com essas classes, a solução consiste em: executar o aplicativo
WebcamBroadcaster para a transmissão do stream de vídeo, obtido de uma
webcam instalada, através de uma porta utilizando sockets. Enquanto isso, a classe
SocketCamera, será executada no aplicativo Android. Esta classe fará a captura das
imagens do socket de transmissão e enviará para o emulador como se fosse a
câmera do dispositivo.
Outro problema constatado foi em relação ao código fonte do autor Tom
Gibara. As classes publicadas [GIBARA, 2011] utilizam funções que já estão em
desuso pelas novas implementações do SDK do Android. Como não serão utilizadas
todas as classes, adaptações foram feitas apenas nas classes SocketCamera e
WebcamBroadcaster.
2.2 OCR (Reconhecimento Ótico de Caracteres)
OCR é acrônimo para Optical Character Recognition ou Reconhecimento
Ótico de Caracteres [AIM, 2000]. É uma tecnologia que permite com que sistemas
computacionais reconheçam caracteres por meio de um mecanismo ótico. O
mecanismo ótico é uma interpretação de imagens e compreensão de sinais em
forma textual. O reconhecimento ótico é feito pelo humano através dos olhos.
Enquanto este reconhecimento é feito pelos olhos (entrada), a interpretação
(processamento) varia de pessoa para pessoa de acordo com muitos fatores como
qualidade da câmera do dispositivo, porcentagem de ruído das imagens, formato
dos caracteres de entrada, entre outros.
Três dos problemas enfrentados pelos desenvolvedores de sistemas OCR
podem ser comparados com o mecanismo humano. Primeiro, o ser humano ao ler
um texto que não esteja em sua língua nativa, pode até reconhecer alguns
caracteres, porém não compreende o sentido das palavras e seus significados.
Porém, caso o texto que se deseja ler seja composto por números, o ser humano é
capaz de interpretá-los, pois estes possuem um significado universal. Por este
motivo, esta é uma das funcionalidades que muitos sistemas OCR conseguem
prover sem dificuldades: o reconhecimento apenas de caracteres numéricos e uma
pequena variação de caracteres alfabéticos.
15
Segundo, as similaridades no formato entre alguns caracteres numéricos e
alfabéticos também configura-se como um empecilho. Ao ser analisada uma string
de letras e números, pode ocorrer uma pequena diferença visível entre, por exemplo,
a letra maiúscula “O” e o numeral “0”, a letra maiúscula “S” e o “5”, a letra maiúscula
“I” e o “1” entre outros. Para os humanos, entretanto, basta a compreensão do
contexto para determinar o significado exato. Na computação, essa tarefa é mais
complicada, pois não existe esta “compreensão do contexto”.
O terceiro problema refere-se à questão do contraste entre a cor do texto e a
cor de fundo e a sobreposição de letras ou imagens. A similaridade entre as cores
de texto e de fundo e a sobreposição entre elas e a dificuldade de distinção e
interpretação dos caracteres são diretamente proporcionais. Quanto maior a
similaridade entre as cores, maior a dificuldade do reconhecimento pelo sistema
OCR. O mesmo vale para o olho humano, ao se deparar com fundos e caracteres de
cores semelhantes.
As primeiras versões de OCR eram simples e requeriam calibragem do
sistema. Esta calibragem constituia-se da prévia programação de imagens
associadas a cada caracter e utilizando-se de apenas um tipo de fonte.
Implementações atuais abordando OCR abrangem tanto caracteres do alfabeto
latino quanto caracteres orientais como o chinês, japonês, etc. Algumas dessas
implementações são de código fonte aberto, mas ainda encontram problemas na
integração com os sistemas operacionais. A maioria pode ser executado em
plataformas linux e windows, porém ainda não suportam o Android, exceto em
código nativo. É necessário a implementação de uma interface para a integração de
bibliotecas nativas da linguagem C que ainda não são suportadas pelo Android.
O OCR é utilizado para a entrada automática de dados em um
computador, armazenamento, compartilhamento ou processamento. Os primeiros
sistemas foram dedicados para entrada de grande quantidade de dados. O primeiro
grande uso foi no processamento de cartões de venda de crédito de petróleo [AIM,
2000]. Atualmente as aplicações com OCR englobam leitores de caixa registradora
de fita e scanners de página. Uma aplicação inovadora são os scanners de Kurzweil
que auxiliam indivíduos com deficiência visual. Estes dispositivos escaneiam textos
que são processados pelo computador e convertidos para a linguagem falada.
Atualmente a tecnologia OCR tem sido largamente utilizada em aplicações de visão
computacional tais como: operações bancárias (digitalização e compensação de
16
cheques sem interferência humana); aplicações de planos de saúde (digitalização de
receitas e formulários de seguros para cada paciente); agências governamentais
(digitalização de processos); digitalização em grande massa de livros, revistas e
publicações (utilizadas por bibliotecas e museus, a fim de diminuir espaço, tornar
textos e livros localizáveis e permitir disponibilizá-los online, como mostra a Figura
2.4); aplicações como o Microsoft OneNote [CVISION, 2011]; aplicações
proprietárias e comerciais como o Kanji OCR da Toshiba usada para
reconhecimento de caracteres japoneses [MORI, 2002].
A Figura 2.4 mostra o procedimento de digitalização de um livro por meio
de OCR. O livro é totalmente digitalizado e são gerados imagens das páginas do
livro (Page Images). Desta forma, o livro pode ser armazenado digitalmente, porém
não pode ser utilizada de forma sistemática, como a criação de índices, divisão de
capítulos, índices de figuras, etc. Para que isso seja possível, a lista de imagens das
páginas do livro devem ser convertidas em formato texto ou hipertexto por OCR.
Com as páginas em formato texto, o processo de extração de informação torna-se
mais simples. Assim, é possível criar índices com links para os capítulos e imagens,
marcação de conteúdo, facilitando a navegação do usuário pelo livro.
Figura 2.4. Exemplo de aplicação do OCR.
Fonte: IBM Research, 2011.
17
2.3 Realidade Aumentada
Realidade Aumentada (Augmented Reality - AR) é o termo utilizado para
uma visão direta ou indireta de um ambiente do mundo real, no qual elementos são
“aumentados” por dados gerados por computador tais como: sons, vídeos ou
gráficos [THOMAS, 2009].
De acordo com Son-Lik Tang (1998), a realidade aumentada é uma
tecnologia na qual imagens, modelos tridimensionais, ou simples informações
geradas por computador são sobrepostos (aumentados) na visão do mundo real do
usuário, fornecendo ao usuário, informação adicional gerada a partir de um modelo
computacional num tempo rápido o suficiente para que o conteúdo adicionado possa
ser alterado ou atualizado conforme a visão física.
Basicamente, é uma abordagem que se encontra no limite entre o mundo
real (realidade) e o mundo virtual (virtualidade). Segundo Kirner e Tori (2006), a
Virtualidade ou Realidade Virtual é uma aplicação com interface em um ambiente
tridimensional, sintético gerado por computador no qual o usuário pode interagir em
tempo real. Quando objetos pertencentes a esta interface transpassam para a
realidade, é conhecido por realidade aumentada. Da mesma forma que objetos reais
são visualizados no ambiente virtual é considerada virtualidade aumentada [BIER et
al., 1993; STONE et. al., 1994].
Para compreender a Realidade Aumentada é preciso ter em mente os
conceitos de real (mundo real) e virtual (MUVE’s – Multi-User Virtual Environments).
O mundo real é o mundo composto por objetos reais, e em contrapartida, o mundo
virtual é o mundo composto por objetos virtuais, como por exemplo, o jogo Second
Life.
A realidade aumentada e a virtualidade aumentada são paradigmas que
se definem entre estes dois mundos, e juntos, compõem a Realidade Misturada
[NIJHOLT, 2005]. Porém, a realidade e a virtualidade aumentada possuem conceitos
opostos. Enquanto a Realidade Aumentada é a transposição de objetos virtuais
(para a visualização em tempo real direta ou indiretamente) no mundo real, a
Virtualidade Aumentada é a transposição de objetos reais no mundo virtual.
Facilmente pode-se exemplificar ambos os conceitos para uma melhor clareza. Um
exemplo de Realidade Aumentada pode ser visto no filme “Who Framed Roger
Rabbit” ou shows da vocaloid Hatsune Miku da Yamaha, onde personagens, que
18
são desenhos gerados por computador, interagem (são transpostos) com atores
reais em ambientes reais. O “Avatar” também é um filme que foi baseado em
técnicas de Virtualidade Aumentada ao inserir atores reais em ambientes gerados
por computador e interagindo com personagens virtuais. Uma ilustração das
definições acima descritas pode ser vista na Figura 2.5.
Figura 2.5. Definição dos Ambientes Real e Virtual e da Realidade Misturada.
Fonte: O Autor.
2.3.1 Aplicativos de tradução
A combinação da tecnologia de realidade aumentada com as dimensões
social e colaborativa da Web 2.0 pode ser a base de novos ambientes de
aprendizagem adaptados às realidades e experiências dos nativos digitais. Esta
combinação integra um conceito que muitos profissionais, como Paul Mason do blog
do BBC News, designam por Web 3.0 [MASON, 2012].
Como dito anteriormente, a visualização dos objetos virtuais pode ser feito
direta ou indiretamente. Para que os objetos virtuais sejam visualizados no ambiente
real e sejam manuseados deve-se utilizar um software com capacidade de visão do
ambiente real e do posicionamento dos objetos virtuais.
De acordo com Tori et al. (2006), o hardware de Realidade Aumentada
pode usar dispositivos de Realidade Virtual, mas tende a não obstruir as mãos, que
devem atuar naturalmente no ambiente misturado. Técnicas de rastreamento visual,
usando visão computacional e do poder de processamento de imagens são
importantes neste caso. Kirner e Siscoutto (2007) descrevem que com a
popularização da webcam, dispositivos móveis e com o avanço das técnicas de
19
visão computacional e do poder de processamento destes microcomputadores, o
rastreamento óptico passou a ser uma realidade, em função da disponibilidade e do
baixo custo.
Como API de tradução pode-se escolher um dicionário com um banco de
dados dos verbetes indexado. O tamanho do banco de dados dependerá do número
de idiomas que o tradutor irá abranger. Uma das vantagens de uma API de tradução
baseado neste paradigma é a sua utilização mesmo sem uma conexão com a
Internet. Por outro lado, a tradução realizada é feita isoladamente por verbetes, ou
seja, caso seja necessária uma tradução baseada no contexto, não pode ser
empregada.
Outra solução possível para o módulo de tradução é a utilização de um
serviço de tradução. Existem diversos serviços para tradução online. A maioria utiliza
o sistema de tradução baseado no SYSTRAN [SYSTRAN, 2011]. O SYSTRAN é um
sistema proprietário híbrido de tradução online instantâneo em 52 idiomas. Este
sistema híbrido combina as vantagens da tecnologia lingüística com técnicas
estatísticas que permitem com que o sistema aprenda automaticamente através de
traduções existentes e validadas [SYSTRAN, 2011]. Em outras palavras, o sistema
une a previsibilidade e a consistência da máquina tradutora baseada em regras
gramaticais com a fluência e flexibilidade dos modelos estatísticos. As técnicas de
auto-aprendizado permitem aos usuários treinarem o sistema para um domínio
específico ou de negócios para alcançar uma melhor qualidade nas traduções. Babel
Fish do Yahoo, o Babylon da AOL e o Google Translate do Google Inc. (este possui
uma peculiariedade sobre os demais) são exemplos de tradutores online que
utilizam possuem o sistema de tradução baseado no SYSTRAN por serem
alternativas gratuitas. Os dois primeiros tradutores fornecem opções de tradução
pré-definidas, impossibilitando ao usuário uma tradução além destas opções
fornecidas.
O Google Translate é uma engine gratuita de tradução estatística
fornecida pelo Google Inc. para a tradução de uma porção de texto, um documento
ou até mesmo uma página web inteira para um outro idioma. Inicialmente, o Google
Translate também utilizava um tradutor baseado no SYSTRAN, porém em 2007,
decidiu-se por trocar o SYSTRAN por um sistema próprio de tradução criado pelo
Google e que já era anteriormente usado para suas traduções em árabe, chinês e
russo. Em alguns casos, a tradução gerada pelo Google Translate pode não ser
20
adequada quanto o desejado, porém em outros casos como no Inglês-Francês é
muito boa [TCWORLD, 2011]. Essa dificuldade se deve a máquina de tradução ser
baseada em regras e estatísticas. Esse tipo de modelo é melhor aplicável se o texto-
alvo é curto e é particularmente evidente para traduções do chinês para o inglês.
[TCWORLD, 2011].
O paradigma do dicionário de verbetes apresenta resultados favoráveis
apenas para a tradução de palavras isoladas. Os dois últimos apresentam resultados
não muito favoráveis, mas quase próximos aos obtidos pela mente humana. O
Google Translate, assim como a maioria dos sistemas de tradução comerciais do
estado da arte utilizados atualmente foram desenvolvidos usando uma abordagem
baseado em regras, as quais demandaram de esforços dos lingüistas para definir os
vocabulários e as gramáticas. Utiliza-se a tradução de verbetes conhecidos ou
busca-se por sua tradução isoladamente e estas são alinhadas conforme a
aplicação de técnicas de aprendizado estatísticas para a construção de um modelo
de tradução. Essa técnica de aprendizado consiste basicamente em uma série de
computadores alimentados por bilhões de palavras de textos e exemplos das
traduções humanas entre as diversas linguagens [GOOGLE INC., 2011]. Desta
forma, o computador constrói padrões baseados na análise dos dados de entrada.
Assim, o Google Translate oferece aos usuários a oportunidade de usufruir do
sistema e ainda aprimorar as traduções.
A escolha pela API do Google Translate como componente do protótipo
desta pesquisa, deve-se ao fato do mesmo ser um serviço disponível gratuitamente
aos desenvolvedores e possuir a flexibilidade da opção do idioma alvo. Além destas
vantagens, esta API fornece um módulo para a requisição de detecção do idioma de
entrada, facilitando assim para que o usuário do aplicativo indique somente o idioma
no qual deseja a tradução. Até o momento, o Google Translate passou por 24
estágios de desenvolvimento (atualizações), cada um com melhorias no sistema de
tradução ou com a adição de um novo idioma.
Há duas formas de integrar a API Google Translate: através de um cliente
GUI Java ou através da utilização de serviços web. Na implementação de um cliente
Java, seria necessária a inclusão de uma biblioteca Java de 320 Kbytes e
importação de classes da API do Google. Na abordagem de serviços web, a troca
das mensagens é feita através de objetos JSON entre o servidor e o aplicativo.
JSON são pequenos objetos javascript para troca de dados que são inteligíveis para
21
humanos (ler e escrever) e de fácil utilização para que máquinas servidoras
analisarem e gerem respostas. São compostos de uma coleção de pares de nomes
e valores. Essa coleção pode ser um objeto, uma tupla, uma estrutura, um dicionário,
uma tabela hash, uma lista-chave ou um array associativo. Além disso, diminui-se a
ocorrência de erros por não ter que reescrever código, mas sim apenas a construção
dos objetos JSON. Como em ambos modelos seria necessária uma conexão com a
Internet, optou-se pela implementação com serviços Web.
2.4 Trabalhos Correlatos
O TranslatAR (Figura 2.6) consiste de um tradutor em Realidade
Aumentada desenvolvido utilizando a câmera e o sistema touchscreen do
smartphone Nokia N900 combinados com uma API de OCR e um serviço de
tradução online (Google Translation API).
O paradigma abordado no TranslatAR é o mesmo abordado neste
trabalho, denominado “magic lens”. A plataforma N900 roda sobre o sistema
operacional Maemo 5 Linux, o que aumenta a portabilidade da aplicação. Porém o
Maemo 5 é o sistema operacional baseado no Linux desenvolvido pela Nokia,
ficando restrito a seus dispositivos. Em contrapartida o Android tem se popularizado
entre os dispositivos móveis, onde se destacam, Motorola, Sony Ericsson, Samsung,
LG e HTC.
Figura 2.6 – TranslatAR para Nokia N900
Fonte: Fragoso, 2011.
Outros trabalhos correlatos são os dispositivos de tradução eletrônica
stand alone denominados “automatic translation helpers” [FRAGOSO, 2011]. Estes
dispositivos provêem funcionalidades tanto de tradutores como também de
dicionários. iTranslate (Figura 2.7) é um aplicativo para o iPhone da Apple que é
22
capaz de traduzir em 50 idiomas, nos dois sentidos e fornece uma funcionalidade
“text-to-speech”, que possibilita ao usuário ouvir a tradução no idioma indicado
[SONICMOBILE, 2011].
Figura 2.7 – iTranslate para iPhone
Fonte: Sonic Mobile, 2011.
Um trabalho relevante a ser citado é o aplicativo Jibbigo [JIBBIGO, 2011].
Jibbigo, ilustrado na Figura 2.8, é um aplicativo para iPhone que fornece uma
tradução através da pronúncia da frase ou palavras a serem traduzidas. Como saída,
o aplicativo “fala” como seria a tradução no idioma em questão. Apesar do número
reduzido de idiomas de tradução, os desenvolvedores do aplicativo apontam como
sua maior vantagem, sua disponibilidade de uma forma exacerbada. No site do
Jibbigo [JIBBIGO, 2011] são mostrados fotos dos lugares mais isolados do mundo,
com a inscrição: “Você pode usar o Jibbigo aqui”.
23
Figura 2.8 – Tela do aplicativo Jibbigo
Fonte: Jibbigo, 2011
A Tabela 2.2 apresenta as principais características desta pesquisa e dos
trabalhos correlatos citados anteriormente.
Esta Pesquisa
(ARTranslator)
Jibbigo iTranslate TranslatAR
Portabilidade Android Android e iOS iOS Maemo 5 Linux
Número de Idiomas 63 9 (Em pares) 50 63
Disponibilidade Online Offline Offline Online
Reconhecimento
por voz
Não Sim Sim, para
alguns
idiomas
Não
Licença Livre Proprietária Livre Livre
Tabela 2.2. Trabalhos Correlatos.
Fonte: O Autor.
24
3 AR-TRANSLATOR: TRADUÇÃO INSTANTÂNEA PARA DISPOSITIVOS PORTÁTEIS
Este capítulo apresenta uma modelagem da arquitetura do protótipo
desenvolvido neste trabalho. São descritos o ambiente de desenvolvimento,
ferramentas, linguagens, tecnologia utilizadas, bibliotecas importadas, classes
implementadas e a plataforma de execução do aplicativo. Ao final são descritas as
dificuldades encontradas durante o desenvolvimento bem como as soluções
adotadas e uma descrição de como elas influenciam na execução do protótipo.
O protótipo proposto neste trabalho consiste em um protótipo que utiliza
bibliotecas de visão computacional, de reconhecimento ótico de caracteres de
código fonte livre e um serviço web gratuito para tradução instantânea. Todas essas
bibliotecas foram utilizadas no desenvolvimento do aplicativo proposto, que pode ser
executado em qualquer dispositivo com o sistema operacional Android.
3.1 Ambiente de desenvolvimento
O desenvolvimento do protótipo foi realizado em um computador com Duo
Processor 1.83 GHz e 1GB de memória RAM e sistema operacional Windows XP
SP2. Como a plataforma Android utiliza um kernel Linux modificado, aplicativos
desenvolvidos são apenas pacotes de classes escritas na linguagem Java
compiladas e arquivos XML de configuração e definição. O desenvolvimento do
protótipo proposto foi feito utilizando o kit de desenvolvimento Java 6 (versão
1.6.0_29) e o ambiente de desenvolvimento Eclipse SDK release 3.6.1.
A escolha pela programação para o sistema operacional Android deve-se
ao fato de grande parte dos dispositivos móveis terem suporte a este sistema
operacional, como os fabricados por Samsung, HTC, T-Mobile, Sony Ericsson e
recentemente pela Motorola. Conforme Christina Bonnington da CNN Tech, o
Android OS lidera a competição de sistemas operacionais para celulares, fechando o
ano de 2011 com 52,5% do mercado global de dispositivos móveis, contra 25% do
ano anterior. A parcela correspondente ao iOS (sistema operacional para iPhone)
teve uma leve queda de 16,6% para 15%. Deve-se ressaltar que esse número do
iOS compreende o mercado de celulares e também o de tablets. O Symbian segue
rumo à sua obsolescência, perdendo o topo do ranking de 2010 com 36,3%,
reduzindo drasticamente para 17%. Os dados apontam ainda que a pequena parcela
25
ocupada pelo Windows Mobile diminuiu de 2,7% para 1,5%. O relatório não chega a
mencionar o Palm OS que é o pioneiro no segmento, mas hoje encontra-se obsoleto
tendo a versão 6.0 Cobalt como sua última versão e nem o Blackberry OS,
desenvolvido pela RIM (Research in Motion) restrito aos aparelhos Blackberry
[BONNINGTON, 2011].
Apesar dos aplicativos serem escritos em Java, não há um código na
plataforma e o bytecode Java não é diretamente executado. As classes Java são
recompiladas em executáveis Dalvik e executados em uma máquina virtual Dalvik
(máquina de execução do Android). Essa máquina virtual é uma Virtual Machine
modificada para o Android, com dispositivos otimizados que são executados com
energia proveniente de uma bateria e com uma CPU de baixa capacidade.
Para que o código Java seja executado como um aplicativo Android, a
emulação é feita por meio da integração do IDE Eclipse com suporte ao Android
SDK release 14.
O Android SDK junto a ferramenta de desenvolvimento Android forneceu
um conjunto rico de ferramentas, como depurador, bibliotecas, emulador,
documentação, exemplos de códigos e tutoriais, ao mesmo tempo que auxilia no
aproveitamento dos recursos ricos do Eclipse, como assistente de conteúdo,
recursos open source e integração com JUnit.
A câmera do dispositivo é simulada por meio de uma webcam instalada
ao computador e a execução de um applet que serve de interface entre a webcam e
a câmera do dispositivo virtual Android.
O aplicativo que dá suporte à emulação da câmera do dispositivo virtual é
o WebcamBroadcaster, uma classe java que captura os quadros de uma webcam e
os transmite por meio de uma conexão, que pode ser TCP/IP ou por sockets. É
importante ressaltar o fato do sistema operacional ser necessariamente o Windows
XP ou Linux. A classe WebcamBroadcaster utiliza funções da biblioteca Java Media
Framework (JMF). Porém, essa biblioteca não oferece suporte aos sistemas
operacionais mais recentes, sendo um projeto que foi descontinuado. Ao ser
instalado em sistemas operacionais mais recentes, a biblioteca não detecta
dispositivos de entrada de vídeo, apenas de áudio, sendo inviável para o
desenvolvimento do projeto.
26
3.2 Modelo do protótipo
Uma modelagem do protótipo, ilustrada na Figura 3.1, é formada pelos
seguintes componentes: biblioteca de visão computacional do Google Leptonica,
biblioteca OCR do Google Tesseract, API Camera Manager, API de OCR, API de
tradução e API de Realidade Aumentada e componentes externos como o idioma de
treinamento do OCR e as mensagens do Google Translate.
Quando o aplicativo é iniciado a atividade principal, a CaptureActivity é
instanciada. Esta classe contém como atributos os objetos principais das outras APIs,
como pode ser observado na Figura 3.6. Esta classe é responsável pela
instanciação e inicialização das outras classes, como por exemplo, a
OcrInitAsyncTask e TessBaseAPI para inicialização do OCR, atribuição de
SurfaceHolder para a inicialização da câmera e criação dos menus de preferência e
de contexto.
Ao pressionar o botão de disparo, a CaptureActivity envia o stream de
imagens para o objeto OcrRecognizeAsyncTask. Esta classe é responsável pelas
chamadas à classe que realmente faz o reconhecimento dos caracteres, a
decodeThread. A decodeThread realiza o reconhecimento dos caracteres e em caso
de sucesso, envia o texto para a CaptureActivity, ou uma mensagem de erro em
caso de erro.
Em caso de erro, a CaptureActivity exibe na sua tela, a mensagem de erro
no reconhecimento de caracteres, sem a instanciação das classes de tradução.
Em caso de sucesso, a CaptureActivity envia o texto reconhecido (em
formato texto) para a classe TranslateAsyncTask. Esta atividade é responsável por
decodificar os códigos dos idiomas de tradução e original para o modelo utilizado
pelo Google Translate e enviar uma requisição contendo os códigos dos dois
idiomas e o texto a ser traduzido. Ao receber a resposta com o texto traduzido, a
classe TranslateAsyncTask, "aumenta" o texto na tela de pré visualização da
CaptureActivity.
As seções seguintes descrevem cada parte do modelo proposto.
27
Figura 3.1. Modelo do protótipo
Fonte: O autor.
28
3.2.1 Biblioteca Tesseract
A biblioteca Tesseract OCR é responsável pelo reconhecimento ótico
dos caracteres de entrada. Adicionalmente, foi necessário importar a biblioteca
Google Leptonica, que contém funções de visão computacional os quais o
Tesseract depende. Originalmente a arquitetura da biblioteca Tesseract (Figura
3.2) foi desenvolvida pela HP-UX em C. Atualmente, o projeto é continuado pelo
Google que fornece também uma interface Java para utilização nativa das
funções.
A Figura 3.2 ilustra o fluxo de trabalho do Tesseract. Todo o processo
segue o tradicional pipeline passo-a-passo. Primeiramente é passada como
entrada uma imagem (na escala cinza ou colorida) para o processamento. Neste
processamento, a imagem é binarizada e os objetos são “extraídos” do fundo da
imagem.
No próximo passo, é realizada uma análise sobre esses objetos e linhas
delimitadoras são traçadas em torno da imagem referente ao texto. Esse texto
“delimitado” é analisado e quebrado em palavras de acordo com o espaçamento
entre letras. O reconhecimento continua como um processo de dois passos. No
primeiro passo, as palavras são reconhecidas uma a uma. Cada palavra é
passada para o classificador do idioma de treinamento. Caso não seja
reconhecida, é armazenada pelo classificador como um dado de treinamento, pois
as mesmas podem ser encontradas posteriormente até atingir o final do texto.
Caso o classificador tenha utilizado estas palavras para o reconhecimento, um
segundo passo é realizado para as mesmas a partir do início do texto.
Para que a biblioteca seja suportada pela plataforma Android, ela foi
compilada em uma biblioteca que fornece uma API Java provida de acesso às
funções Tesseract compiladas nativamente.
A API Java resume-se à classe TessBaseAPI (Figura 3.3). Esta classe
é uma simples interface Java para o mecanismo de OCR da Tesseract. Nem todos
os métodos JNI (Java Native Interface) disponíveis estão implementados, mas o
suficiente para o propósito deste trabalho. Inicialmente, as bibliotecas nativas
Tesseract e Leptonica (libtess.so e liblept.so), que estão no formato “.so” (shared
object) são carregadas para a utilização das funções nativas e o construtor da
classe faz a instanciação do objeto.
29
Figura 3.2. Arquitetura da biblioteca Tesseract.
Fonte: Tesseract, 2011.
A função InitOcrEngine da classe CaptureActivity faz a inicialização da
Tesseract com um modelo de específico de idioma. Esta função recebe como
parâmetros o caminho do modelo de idioma e o nome do idioma. Os arquivos de
modelo devem estar localizados no diretório raiz Tessdata. O nome do idioma é uma
string ISO 639-3. O padrão ISO 639-3 é um padrão internacional que determina
códigos para a representação de nomes de idiomas. Descreve códigos de 3
caracteres para a identificação de um idioma [W3, 2011]. Caso o parâmetro
contenha um valor nulo, a inicialização será feita por padrão no idioma inglês.
Em alguns casos, pode ocorrer do usuário escolher um modelo de idioma
que ainda não tenha sido instalado no aplicativo. Nesses casos, o aplicativo irá
realizar uma verificação pelo idioma de reconhecimento escolhido. Caso o modelo
não esteja instalado, o aplicativo fará uma chamada à função downloadFile da
classe OcrInitAsyncTask (Figura 3.8).
30
Figura 3.3 – Classe do reconhecimento de caracteres TessBaseAPI.
Fonte: O Autor.
Esta função realiza uma conexão ao repositório de idiomas do OCR
Tesseract em [TESSERACT, 2012], posposto do modelo de idioma e da extensão
“.gz”. Com a URL formada, a função downloadFile a passará como parâmetro para a
função downloadGzippedFileHttp. Ao receber o arquivo compactado, uma chamada
ao método gunzip que armazenará o arquivo em um objeto do tipo GZIPInputStream,
fará a descompressão do arquivo e apagará o arquivo compactado.
31
Os arquivos de modelo de idiomas são armazenados na memória interna
ou em um cartão de disco removível, sendo este, um dos requisitos para a execução
do aplicativo deste projeto.
Como os idiomas utilizados podem ser armazenados em um dispositivo
de armazenamento móvel, caso este aplicativo seja instalado em outro dispositivo
móvel com os arquivos de modelo, o aplicativo faz a instalação a partir do cartão de
memória, antes de buscar no repositório do servidor. Esta instalação utilizará a
função installFromAssets que por sua vez chamará a função installZipFromAssets
para descompactar os arquivos.
O método Clear e End são simples chamadas aos respectivos métodos
nativos. O primeiro, libera espaço na memória utilizado por resultados de
reconhecimento de caracteres e dados temporários, enquanto que o segundo fecha
a Tesseract e libera toda a memória, o equivalente a destruir o objeto TessBaseAPI.
Uma vez que End é usado nenhuma das funções da API pode ser utilizada.
As funções setVariable, setPageSegMode e setDebug executam os
métodos nativos correspondentes e realizam atribuições em variáveis e parâmetros
de configuração do Tesseract.
A função wordConfidences é utilizada quando o reconhecimento de
caracteres é realizado de modo contínuo. Neste modo, o reconhecimento é feito de
modo contínuo e as palavras são pré reconhecidas e são armazenadas de forma
que seja possível aumentar a confiabilidade do reconhecimento e que seja atingido o
resultado esperado.
As funções setRectangle, setImage e getUTF8Text são as funções
utilizadas para o processamento OCR propriamente dito. A setRectangle irá criar um
retângulo de delimitação para reconhecimento de caracteres na imagem. Pode ser
passado um objeto rect (retângulo) ou somente as coordenadas esquerda e topo e
tamanhos de largura e altura. Cada chamada a setRectangle deleta o resultado de
reconhecimento previamente feito.
A função setImage provê a imagem que passará pelo processo de OCR.
A imagem passada como argumento para a função nativa pode ser de 4 tipos: File,
Bitmap, Pix ou Image Buffer. File é um tipo de arquivo genérico do sistema de
arquivos. Bitmap é uma imagem em formato de um mapa de bits. Pix é a
representação da imagem no formato da API Leptonica. Image Buffer é uma imagem
32
em formato de um conjunto de bytes armazenado no buffer. TessBaseAPI fará a
chamada correspondente à função nativa.
A função getUTF8Text simplesmente retorna o texto resultado do
processamento do OCR em formato UTF8.
3.2.2 API de Processamento de Imagens
A API Tesseract utiliza como biblioteca de funções de visão
computacional, a biblioteca do Google, Leptonica. Essa biblioteca provê uma grande
quantidade de funções e ferramentas tanto para processamento de imagens,
também conhecido por imaging quanto para análise de imagem, que inclui
operações fundamentais de processamento, transformações, técnicas de
renderização, entrada e saída, transformações affine entre outras [TOM POWERS,
2011].
A biblioteca Leptonica possui um pequeno número de estrutura de dados
ao contrário da sua quantidade de funções, ambas utilizando o paradigma de
orientação a objetos. As funções estão divididas em duas bibliotecas: funções de
alto nível, que utilizam um conjunto esparso de estruturas de dados como Pix, Box,
etc, e as de baixo nível que utilizam intrinsicamente tipos de dados do C. Os
arquivos da biblioteca de baixo nível, possuem o sufixo “low” anexado ao nome de
arquivo na biblioteca de alto nível correspondente. Quando uma estrutura de dados
está associada a um array um “a” é adicionado ao nome do arquivo, como em Pixa.
Ao se tratar de arquivos de imagens, é extensa a quantidade de formatos
existentes, porém somente alguns são suportados pelo Leptonica. Alguns como os
simples BMP e PNM, são suportados sem problemas. Quanto aos tipos de imagens
com compressão com bibliotecas open source se enquadram o (gzip) PNG, (JFIF)
JPEG e o novo (libvpx, uma biblioteca de compressão de vídeo) WEBP que são
suportados por todos os navegadores. Há o suporte para um formato não suportado
pelos navegadores, a compressão TIFF CCITT-G4. O Leptonica não oferece suporte
ao formato GIF, pois o tipo de compressão (LZW) foi recentemente patenteada. Para
que o suporte a estes formatos esteja disponível, o Leptonica utiliza as bibliotecas
externas libjpeg, libtiff, libpng, libz, libgif e libwebp. Como o formato de imagem
utilizado neste projeto é o JPEG apenas a biblioteca libjpeg.so é carregada em
tempo de execução.
33
A classe AdaptiveMap contém métodos para mapeamento de imagens
adaptativas. Para o uso da biblioteca Tesseract será necessária apenas a
implementação do método de normalização do fundo de uma imagem.
A classe Binarize contém métodos para binarização de imagens. A função
otsuAdaptiveThreshold. Threshold adaptativo é um algoritmo de segmentação de
imagem para a definição dos objetos de uma imagem de seu fundo, dependendo de
suas condições de iluminação [LIAO, 1999]. O algoritmo utilizado pelo Leptonica é o
Otsu. Outros detalhes podem ser encontrados no anexo.
A classe Box representa um container para o box nativo da biblioteca
Leptonica. Contém funções para a criação do box que irá conter a restrição da
porção do texto que será enviada à API de reconhecimento de caracteres. Todas as
coordenadas passadas devem ser valores inteiros e não negativos.
As definições para as constantes utilizadas pela biblioteca Leptonica
localizam-se na classe Constants contém as.
A classe Convert contém métodos de conversão de qualquer tipo de
imagem para imagens com 8 bits de canal. As imagens são convertidas e o retorno
será uma imagem em 8 bits em escala de cinza ou um código de erro.
A classe Enhance contém métodos para melhorar a nitidez das imagens.
A função unsharp masking fará a chamada para a função nativa correspondente que
criará uma camada sobre a imagem, tratando a nitidez.
A classe JpegIO contém métodos de entrada e saída de arquivos no
formato Jpeg. A função compressToJpeg compacta/converte qualquer imagem
bitmap para o formato Jpeg, com qualidade padrão (85%) e codificação seqüencial.
A diferença da codificação seqüencial da progressiva, é que na primeira os bits são
codificados um a um em ordem, enquanto que na segunda, os bits semelhantes no
mapa de bits são codificados em bloco uma única vez.
A classe Pix é a representação Java de um objeto Pix nativo da biblioteca
Leptonica. Cada objeto da classe Pix contém atributos como localizações horizontal
e vertical do pixel e a cor em formato de bits. Implementa vários métodos nativos
como clone, copy, getDimensions, entre outros.
A classe Pixa é a representação Java de um objeto nativo PixA. Um
objeto PixA é uma representação de um array de pixels e o container o qual
pertencem, podendo ser um mapa de pixels.
34
A Classe ReadFile contém métodos para criação de objetos de 32 bbp
(bits por pixel) ou 8 bbp a partir de dados codificados. Os formatos suportados por
este objeto são o bitmap e o jpeg. Os métodos são utilizados para leitura e escrita de
imagens.
A Classe Rotate implementa métodos de rotação básico de imagens a
partir de seu centro. Para pequenas rotações um clone é retornado. Em outros casos,
a rotação é feita por amostragem de área.
A Classe Scaling contém métodos para redimensionar imagens. As
imagens podem ser redimensionadas, pelo eixo x ou y independentemente ou
mantendo a proporção original.
A Classe Skew contém métodos de detecção de rotação e distorção Esta
classe localiza e retorna o ângulo de inclinação, fazendo, primeiramente uma
varredura por um conjunto de ângulos iguais e depois faz uma pesquisa binária até a
convergência.
Estas classes da biblioteca Leptonica podem ser obtidas gratuitamente
sobre licença GNU e licença Apache 2.0 em GoogleCode e utilizadas livremente em
qualquer projeto. Instruções de como utilizar as classes também podem ser
encontradas no site do Leptonica no GoogleCode. [GOOGLE CODE, 2011].
3.2.3 API Camera Manager
A API Camera Manager contém classes que fazem o gerenciamento de
configuração e das ações da câmera do dispositivo.
A classe AutoFocusCallBack implementa a interface callback da classe
Camera do Android. Apenas dois atributos são utilizados o manipulador,
autoFocusHandler e um inteiro indicando a mensagem de notificação do
manipulador. A função setHandler faz apenas uma atribuição de um manipulador
para a câmera. A função onAutoFocus faz o tratamento das mensagem vindas do
manipulador, em caso de sucesso ou falha no foco da câmera.
A classe CameraConfigurationManager é a classe responsável pelo
gerenciamento das configurações da câmera como zoom, resolução, contexto do
Android, formato do preview, resolução da tela. O construtor faz a atribuição do
contexto da aplicação. A função getCameraResolution retorna a resolução da
câmera do dispositivo. Para tanto, esta função recebe apenas o tamanho do display
35
do objeto WindowManager do objeto context e retorna um objeto do tipo Point com
os parâmetros da resolução.
A principal classe da API, Camera Manager (Figura 3.4) é o controlador
de todas as funções da câmera do dispositivo. Seu construtor carrega as
configurações atribuídas para a câmera, instancia os objetos PreviewCallback e
AutoFocusCallback. São implementados também funções para controle de
luminância YUV, controle do retângulo delimitador do reconhecimento de caracteres
(adjustFramingRect), inicialização e finalização do driver da câmera, iniciar e
encerrar a pré-visualização e fazer chamadas para a API de reconhecimento de
caracteres. Esta chamada é feita pelo método requestOcrDecode.
Figura 3.4 – Classe CameraManager.
Fonte: O Autor.
A função AdjustFramingRect (Figura 3.5) é a função que cria o retângulo
delimitador baseado nas coordenadas do usuário. Caso o ponto passado pelo
usuário seja maior do que a largura e/ou altura limites, a função delimita-os para o
valor máximo.
36
Figura 3.5 – Função AdjustFramingRect da classe CameraManager
Fonte: O Autor.
A classe FlashLightManager é a classe responsável pelo gerenciamento
do hardware do flash do dispositivo. Contém métodos para habilitar e desabilitar o
flash e inicializar o serviço.
A classe PreviewCallBack é a implementação da interface
android.hardware.Camera.PreviewCallback. Esta classe é utilizada para recuperar
os quadros da pré-visualização conforme eles são visualizados para o usuário. Estes
quadros serão utilizados pela API de OCR para reconhecimento dos caracteres. A
função responsável por isso é a onPreviewFrame. Ela faz a instanciação de
setPreviewCallback e de um manipulador do tipo previewHandler.
A classe ShutterButton é uma classe derivada da classe de imagens de
uma content view, a android.widget.ImageView. Esta classe é uma representação
das imagens que aparecem no aplicativo. Neste caso, define o botão para tirar uma
foto para ser utilizado na tela do dispositivo. Assim como as variáveis do aplicativo
deste projeto, a imagem referente a esta classe está indicada no arquivo XML
capture que localiza-se em res/layout.capture.xml. Neste arquivo a classe
ShutterButton é referenciada à imagem ic_camera_indicator_photo localizada em
drawable. O construtor recebe o parâmetro do contexto ao qual este botão
pertencerá e se este se encontra em modo pressionado. A função performClick fará
uma chamada ao método onShutterButtonClick que chama o foco, recebe a imagem
pré-visualizada e libera o foco. Esta seqüência de eventos é importante, pois este
botão simula o botão da câmera física. Nesta classe define-se também a interface
onShutterButtonListener que será chamada quando o botão da câmera estiver
pressionado.
37
A atividade principal da API da câmera, CaptureActivity (Figura 3.6 e
Figura 3.7), é responsável por todo o processo de captura das imagens e chamada
aos métodos de reconhecimento de caracteres. Ela faz o carregamento das classes
da API Camera Manager e também a API Tesseract. A atividade armazena também
atributos como o modo de captura, os idiomas original e de tradução padrão, os
idiomas original e de tradução correntes, as preferências do usuário, o botão de
captura, o resultado do reconhecimento de caracteres anterior, o local de
armazenagem dos dados temporários, entre outros. Ao ser criada, pelo método
onCreate, a atividade inicializa a classe CameraManager, o botão da câmera, as
views da tradução e do resultado do OCR. Nesta classe são implementados
métodos que são utilizados durante todo o processo de captura, como:
• getStorageDirectory: Monta um diretório em um dispositivo de
armazenagem externo, como um cartão SD, e retorna um objeto do
tipo File que será armazenado no espaço reservado especificado.
• initCamera: faz a inicialização do dispositivo da câmera,
carregando o driver, faz a atribuição da API Tesseract e do botão
de captura.
• initOcrEngine: carrega o idioma de reconhecimento, instancia a API
Tesseract e a atividade assíncrona de OCR.
• resetStatusView: redefine todas as variáveis da view desta
atividade como o texto de OCR e a visibilidade do botão de captura.
• retrievePreferences: recupera as preferências definidas pelo
usuário. Caso alguma opção seja alterada, este método altera as
opções para seus respectivos valores.
• handleOcrContinuousDecode: utilizado para o reconhecimento
contínuo. Os sucessivos reconhecimentos são armazenados e
também os tempos entre eles. Quando este intervalo se reduz a
zero o reconhecimento é definido.
• handleOcrDecode: o resultado do reconhecimento dos caracteres e
o arquivo de imagem capturado do quadro da câmera são
recuperados. Os idiomas de reconhecimento e de tradução são
definidos e a atividade de tradução TranslateAsyncTask é
instanciada e executada.
38
• onCreateContextMenu: define as opções do menu de contexto do
aplicativo. São apenas duas opções: copiar o texto reconhecido e
copiar o texto traduzido.
• onCreateOptionsMenu: define as opções do menu do aplicativo.
São dois itens: de configurações e sobre.
• onDestroy: faz uma chamada ao método onDestroy da atividade e
finaliza a API Tesseract.
• onKeyDown: realiza uma chamada ao método click do botão de
captura da câmera ou de atraso no foco.
• onOptionsItemSelect: faz uma chamada a atividade de preferências
e atualiza com os novos valores definidos pelo usuário.
• onShutterButtonClick: executa o método click do botão de captura.
• onShutterButtonFocus: executa um atraso no foco automático da
câmera.
• onPause: chama o método onPause da atividade e finaliza o driver
da câmera.
• onResume: retoma a atividade após uma chamada ao método
onPause. Primeiramente faz chamadas aos métodos
resetStatusView e retrievePreferences. Faz uma verificação do
idioma de reconhecimento, da API Tesseract e do diretório externo
de armazenagem. Após todas essas verificações executa o método
resumeOcr.
• resumeOcr: carrega um novo manipulador da atividade e uma nova
instância da API Tesseract e chama a função initCamera, que faz o
restante das inicializações.
• setSourceLanguage: define o idioma de reconhecimento.
• setTargetLanguage: define o idioma de tradução.
• setSpanBetweenTokens: atribui espaços entre as palavras
reconhecidas.
• setStatusViewTop: Imprime as mensagens do estado do
reconhecimento para o modo de captura de imagens.
• setStatusViewTopContinuous: Imprime as mensagens do estado
do reconhecimento para o modo contínuo de reconhecimento.
39
• showErrorMessage: Mostra mensagens de erro na tela corrente.
• stopHandler: Faz uma chamada ao método stop do manipulador.
• surfaceCreated: Inicializa a câmera com a superfície do aplicativo
passada por parâmetro.
• surfaceDestroyed: Atribui valor falso para o atributo de superfície.
Utilizado para o reconhecimento de caracteres a partir de um
quadro de imagem da câmera, em formato bitmap.
Figura 3.6 – Atributos da classe CaptureActivity.
Fonte: O Autor.
O envio e o processamento das mensagens da CaptureActivity fica sob
responsabilidade da classe CaptureActivityHandler. Este manipulador é responsável
também por realizar todo o gerenciamento das chamadas a API de OCR e
inicialização da câmera após o reconhecimento. Mais importante do que o
40
gerenciamento das mensagens da atividade, o manipulador realiza todo o processo
de comunicação entre a atividade de captura e o sistema de OCR, fazendo a
inicialização ou reinicialização deste último. O processamento do reconhecimento de
caracteres é executado ao fazer uma chamada ao método start do decodeThread,
um dos atributos do manipulador.
Figura 3.7 – Principais funções da classe CaptureActivity.
Fonte: O Autor.
41
3.2.4 API de Reconhecimento de Caracteres
A classe DecodeThread, herdada da classe thread, é o processo que
armazena a atividade de captura da câmera e a API Tesseract, faz a inicialização de
seu próprio manipulador, DecodeHandler e de um contador regressivo, usado para o
reconhecimento contínuo.
Assim, como a classe CaptureActivity possui um manipulador, a classe
DecodeThread também o possui. O manipulador é responsável por fazer as
chamadas à API de OCR. Além do método para o gerenciamento das mensagens,
possui dois métodos ocrDecode e ocrContinuousDecode, porém esta última é
utilizada para reconhecimento contínuo. O princípio básico de execução de ambas é
mesmo. Atribuições da API Tesseract e da PlanarYUVLuminanceSource são feitas.
A imagem bitmap é processada para escala em tons de cinza e então é invocada o
método execute da classe OcrRecognizeAsyncTask (Figura 3.9).
Todo o processo de inicialização e carregamento das bibliotecas e
arquivos necessários para a utilização da API de reconhecimento de caracteres é de
responsabilidade da classe OcrInitAsyncTask. Basicamente, esta classe provê
métodos para que o reconhecimento seja executado sem problemas. Se um idioma
de reconhecimento seja selecionado e o arquivo modelo não esteja instalado no
cartão de memória, o método downloadFile conecta-se ao servidor pela url
"http://tesseract-ocr.googlecode.com/files/" acompanhado pelo idioma e a extensão
".gz".
O arquivo recebido do servidor é um arquivo compactado, que deve ser
descompactado pelo método gunzip que transforma o arquivo recebido do tipo File
em um dado do tipo GZIPInputStream e depois em um arquivo FileOutputStream.
Após a descompactação do arquivo, o arquivo compactado original é deletado. Caso
o idioma já esteja instalado no cartão de memória, transferido ou ainda previamente
baixado do servidor, a função installFromAssets fará a leitura seqüencial do arquivo
do modelo diretamente do cartão ou caso o mesmo esteja em formato ".gz", a
função installZipFromAssets faz a descompactação e instalação do mesmo.
42
Figura 3.8 – Classe OcrInitAsyncTask e as funções para transferência
dos arquivos de idiomas.
Fonte: O Autor.
A função getGZipSizeUncompressed é utilizada por todas as outras que
utilizam métodos de descompactação de arquivos para se ter o conhecimento do
tamanho do arquivo no estado descompactado mesmo antes de ser descompactado.
Três métodos para informar o usuário sobre o andamento do processo de
43
inicialização também são implementados: onPreExecute, onProgressUpdate e
onPostExecute. Estes três métodos são executados antes, durante e depois da
execução da thread OcrInitAsyncTask, nesta ordem. O primeiro informa que o
aplicativo está verificando por modelos de idiomas instalados. O segundo informa
sobre o estado dos idiomas se devem ser baixados do servidor, descompactados e
outros. O terceiro informa se houve êxito na inicialização da API OCR ou falha, como
por exemplo, na conexão com a internet.
A classe OcrRecognizeAsyncTask (Figura 3.9) representa a thread para o
reconhecimento de caracteres. Enquanto o processo de OCR é realizado pela classe
decodeHandler, OcrRecognizeAsyncTask informa ao usuário sobre o resultado do
reconhecimento e a imagem utilizada no reconhecimento ou se houve falha no
processamento.
44
Figura 3.9 – Classe OCRRecognizeAsyncTask.
Fonte: O Autor.
45
3.2.5 API de tradução
A API de tradução consiste de uma classe que implementa chamadas aos
webservices do Google Translate. A tradução do texto é feita através da chamada do
método translate da classe TranslationHelper. O método translate basicamente
recebe como argumentos o texto a ser traduzido, o idioma de entrada (este podendo
ser opcional) e o idioma de saída.
De posse destes parâmetros, o método constrói a string da URL do
serviço Google Translate. Basicamente, a url do Google Translate consiste de um
prefixo básico: “https://www.googleapis.com/language/translate/v2?”. Esta string com
a url, é seguida do padrão “key” seguido pela chave que pode ser obtida no site do
Google Translate, “&q=”, o texto a ser traduzido, “&source”, o idioma original,
“&target” e idioma para o qual se deseja a tradução. Os idiomas devem seguir o
padrão do Google, indicados por siglas de 2 caracteres ou de 3 caracteres (ISO-
6393), com exceção do idioma chinês que possui 5 caracteres para diferenciar o
simplificado do tradicional, que podem ser obtidas no site oficial do Google Translate
e também referenciados no código fonte deste projeto.
Para padronizar este processo de recuperação de nomes e siglas para os
idiomas foi desenvolvida a classe LanguageCodeHelper. As funções
getLanguageName e getTranslationLanguageName recebe como parâmetros o
código do idioma e retorna o seu nome. Por outro lado, a função mapLanguageCode
faz o mapeamento dos códigos do padrão ISO-6993 para o padrão ISO-6391. Ela é
utilizada para um recebimento de um pacote de modelo de idioma não encontrado
no aplicativo, por exemplo.
Esses parâmetros são passados para um método protegido da classe
TranslationHelper, o runHttpRequest (como pode ser visto na Figura 3.10) , que de
posse do contexto da URI do Google Translate faz a requisição para o webservice
do Google Translate. Este método realiza o tratamento de erros sobre a resposta
recebida (APIException) ou ainda quando a tradução não está disponível. O método
envia uma requisição e recebe um objeto JSON em formato stream com o resultado
da tradução. O resultado é passado como retorno para a função translate.
46
Figura 3.10 – Método runHttpRequest da classe TranslationHelper.
Fonte: O Autor.
Com o resultado, a função translate, ilustrada na Figura 3.11, verifica se
houve erro ou não e retorna a tradução.
Esses métodos são invocados pela classe TranslateAsyncTask. Esta
classe é uma extensão da classe android.os.AsyncTask. A TranslateAsyncTask é
uma tarefa assíncrona que permite que a thread da User Interface seja
apropriadamente manipulada e que operações e chamadas a métodos sejam
realizadas em background e os resultados podem ser exibidos enquanto a user
interface permanece ativa. Uma AsyncTask possui 4 métodos da classe pai que
podem ser implementados. Obrigatoriamente o método doInBackground deve ser
implementado. Na maioria dos casos, como o deste projeto, quando a computação
dos dados necessita ser exibida ao usuário, o método onPostExecute também é
implementada na classe filha.
O construtor da classe TranslateAsyncTask apenas faz a inicialização dos
atributos da classe como a atividade, o text view da atividade, o idioma original, o
idioma para o qual será feita a tradução, o texto original.
O método doInBackground recebe esses parâmetros e faz a instanciação
de um objeto da classe TranslationHelper e faz a chamada ao método translate
passando os parâmetros necessários (conforme a Figura 3.12).
47
Figura 3.11 – Método Translate de TranslationHelper.
Fonte: O Autor.
O método onPostExecute faz atribuições aos elementos da View como o
text view e type face e exibe o resultado da tradução na view ativa.
48
Figura 3.12 – Métodos doInBackground e onPostExecute da classe
TranslateAsyncTask.
Fonte: O Autor.
3.2.6 API de Realidade Aumentada
Existem diversos frameworks para a implementação da realidade
aumentada em dispositivos móveis, em computadores desktop e para Internet. No
contexto de dispositivos móveis estão disponíveis serviços on-line para a
implementação da realidade aumentada, como o Layar (Lightweight AR) [LAYAR.
2011].
49
O Layar é um navegador (browser) para realidade aumentada com
interatividade com milhões de objetos aumentados (layers) cadastrados em seu
banco de dados. É uma plataforma que auxilia e acelera o desenvolvimento de
aplicações em realidade aumentada, fornecendo toda a estrutura envolvida para sua
implementação como chamadas a câmera do dispositivo, busca dos metadados e
visualização dos resultados, bastando apenas ao usuário decidir o que e como
compartilhar utilizado no aumento. Porém, a utilização da realidade aumentada no
aplicativo deste projeto tem um propósito diferente.
A implementação da realidade aumentada neste projeto, consiste de duas
partes: os dados em tempo real (pré-visualização da câmera) que são aumentados e
os metadados (resultado da tradução) que são utilizados no processo de aumento
da realidade. Essas duas partes são combinadas gerando a realidade aumentada. O
que diferencia a abordagem utilizada no Layar e a deste projeto, é que no Layar os
metadados são previamente armazenados no banco de dados, enquanto que neste
projeto, os metadados são requisitados para e computados pelo servidor em tempo
real, sem qualquer armazenamento. Devido a isso, a implementação da realidade
aumentada será realizada de forma diferente.
A exibição em tempo real da câmera do dispositivo corresponde a
realidade em realidade aumentada. Os dados da câmera estão disponíveis
utilizando as funções da API da câmera do Android no pacote
android.hardware.Camera. Além disso, como a aplicação faz utilização dos dados
dos quadros da previsualização da câmera, as chamadas são feitas à função
setPreviewCallback do objeto Camera.PreviewCallback que possibilita ao aplicativo
a obtenção da pré-visualização na forma de imagens quadro a quadro, ao invés da
função setPreviewDisplay, que faz apenas exibição da pré-visualização.
Enquanto que para algumas aplicações a localização (GPS) e a posição
(sensores de orientação como accelerometer, vetor de rotação) do dispositivo são
importantes para a computação, neste projeto esses fatores não fazem diferença e
não alteram a computação do resultado final. Sendo assim, o uso de API dos
sensores e de localização tornam-se dispensáveis.
O correspondente aos metadados, que são objetos utilizados no processo
de aumento, são os resultados de tradução dos parâmetros de entrada. Como a
idéia de realidade aumentada é a renderização de objetos sobre a pré-visualização
da câmera em tempo real, que compreende desde simples desenhos e quadros de
50
informações à objetos tridimensionais (todos presentes em bibliotecas do Android
como android.graphics e android.opengl), o simples fato de inserir um quadro com o
resultado da tradução, completa o paradigma de realidade aumentada que é feita
pela função doInBackground e exibida pela função onPostExecute da classe
TranslateAsyncTask.
3.2.7 Classes Acessórias
Algumas classes não pertencem a nenhuma API, mas são utilizadas por
algumas classes para oferecer suporte a algumas operações, estas são as classes
acessórias.
A classe BeepManager é um gerenciador de sons e vibrações do
aplicativo. Cada vez que um som deve ser emitido como um sinal de alerta ou erro
uma chamada aos métodos desta classe é realiza. Esta classe contém um atributo
do tipo android.Media.MediaPlayer, sendo criado pelo método buildMediaPlayer e
que será responsável pela reprodução dos sons. Para a reprodução do efeito de
vibração, é feita apenas uma reprodução com o volume no modo de vibração.
A classe FinishListener implementa as interfaces
DialogInterface.OnClickListener e DialogInterface.OnCancelListener e Runnable.
Esta classe é apenas um simples listener utilizado para finalizar o aplicativo em
alguns casos.
O propósito da classe abstrata LuminanceSource é padronizar diferentes
implementações de bitmaps entre as plataformas em uma interface padrão para
valores de luminância em escalas de cinza. Ela apenas fornece métodos imutáveis
de recorte e criação de cópias. Isso garante que os bitmaps não sofram
modificações na fonte de iluminação original. Os valores de luminância variam de 0
(preto) a 255 (branco) [BLACKBERRY, 2011].
A classe PlanarYUVLuminanceSource implementa a iluminação do
tipoYUV da classe abstrata LuminanceSource. O padrão YUV anteriormente
batizado como YCrCB é um modelo de representação de cor que possui dados de
luminância (luminosidade), o padrão Y, e crominância (cor), os padrões U e V. Foi
criado originalmente para que informações em cores possam ser afixadas em
padrões de escalas de cinza [PCMAG, 2011]. As relações entre esse padrão e o
padrão RGB que vinculam Y a R, G e B, U a R e à luminância e V a B e à luminância,
são:
51
• Y = 0.299R + 0.587G + 0.114B
• U = -0.147R - 0.289G + 0.436B = 0.492(B - Y)
• V = 0.615R - 0.515G - 0.100B = 0.877(R - Y)
Esta classe é utilizada pela biblioteca de leitor de código de barras da API
BlackBerry 7.0.0. As preferências do aplicativo são definidas pela atividade
PreferencesActivity. Ao ser criada, as preferências são carregadas. Ao serem
alteradas pelo usuários, elas são retidas para que quando invocados os métodos
onPause e onResume, estas possam ser recuperadas. As preferências ficam
armazenadas no dispositivo de armazenamento externo.
52
4 TESTE DO PROTÓTIPO E RESULTADOS
Este capítulo descreve o teste realizado no protótipo e os resultados
obtidos.
4.1 Ambiente de teste
A estrutura física consiste de um tablet Samsung Galaxy TAB P1000,
provido de câmera principal 3.0 Mega Pixel e com suporte a touchscreen. A conexão
com a Internet é disponibilizada pela rede sem fio local ou pela conexão banda larga
3G Tim do chip do tablet. O dispositivo de armazenamento externo consiste de um
cartão micro SD de 2 Gibabytes de armazenamento.A estrutura lógica é definida
pelo sistema operacional Android versão 2.2 conhecido também por FroYo (Frozen
Yogourt, versão de maio de 2010).
Os testes foram realizados com a utilização de textos de origem variada
tais como artigos de revistas (Figura 4.1) e jornais impressos, textos gerados e
exibidos em telas LCD (Figura 4.2) e textos manuscritos e vídeos. Os textos foram
selecionados de diferentes tipos de mídia, pois possuem diferentes tipos de
resolução, granularidade, definição, luminosidade, entre outras características. O
propósito do teste em diferentes tipos de mídia também deve-se ao fato de poder
verificar a performance do sistema OCR, uma das limitações deste trabalho.
Foram comparados o número de tentativas necessárias até a completude
do reconhecimento e se esta encontra-se na forma correta, ou seja, número de
tentativas e número de erros encontrados antes de se alcançar êxito no
reconhecimento.
4.2 Descrição do teste
Para o teste foram selecionados vários tipos de mídias. Os textos variam
o tipo de mídia e o tipo da letra (como caligrafia, cor e tipo da fonte). A mídia de onde
são retirados é importante, pois esta influencia em atributos variáveis como
luminância, contraste e saturação de cor.
53
Figura 4.1. Texto retirado de revistas.
Fonte: IstoÉ, 2011.
Figura 4.2. Texto em Telas LCD.
Fonte: Esportes Terra, 2012.
Como citado anteriormente, o emulador do Android não provê uma
emulação da câmera por meio de uma webcam. Por isso, primeiramente é
necessário executar a classe WebcamBroadcaster, que recupera as imagens
sequenciais providas por uma webcam e transmite esses quadros por uma conexão.
A classe webcambroadcaster utiliza bibliotecas do framework JMF (Java Media
Framework). Esse framework pode ser obtido no site da Oracle [ORACLE, 2012]
(Figura 4.3).
54
Figura 4.3 – Site do JMF da Oracle.
Fonte: Oracle, 2012.
Após baixar o instalador do JMF, basta instalá-lo e reiniciar o computador.
Ao executar o webcambroadcaster, uma tela para configuração da entrada de áudio
e vídeo aparecerá. Nessa tela selecione o JMStudio (Figura 4.4) e caso a webcam
ainda não esteja configurada poderá ser feita no JMStudio.
Com a webcam configurada, é necessário decidir se o aplicativo será
executado no emulador ou num dispositivo móvel. Caso o aplicativo seja executado
em um dispositivo móvel, basta exportá-lo como um aplicativo no menu Android
Tools. Caso o aplicativo seja executado no emulador, é necessário adicionar a
classe SocketCamera ao projeto do ARTranslator. Com a classe adicionada, é
preciso configurar o IP da webcam (Figura 4.5) indicado pelo JMStudio. Para isso,
basta atribuir o número do IP para o atributo address.
55
Figura 4.4 – Execução da classe WebCamBroadcaster.
Fonte: O Autor.
Figura 4.5 – Atribuição do IP na Classe SocketCamera.
Fonte: O Autor.
56
Após a configuração da webcam, executar o projeto ARTranslator como
uma aplicação Android. O eclipse irá compilar o projeto e abrir o emulador indicado
por padrão no SDK Manager automaticamente (Figura 4.6). Dependendo do
computador este processo poderá demorar alguns minutos.
Figura 4.6 – Tela do emulador sendo carregado.
Fonte: O Autor.
Ao executar o ARTranslator, pode-se configurar o idioma de entrada e o
idioma de tradução, escolhendo a opção settings (Figura 4.7). Na tela de
configurações, basta escolher as opções recognize (para o idioma de entrada) e
translate to (para o idioma de tradução) (Figura 4.8) e o idioma para cada opção
como indicado na Figura 4.9.
Figura 4.7 – Menu de Opções.
Fonte: O Autor.
57
Figura 4.8 – Tela de opções.
Fonte: O Autor.
Figura 4.9 –Tela de opções de idiomas.
Fonte: O Autor.
Caso o idioma selecionado para reconhecimento de caracteres ainda não
foi utilizado, o protótipo não encontrará o arquivo de treinamento referente. Neste
caso, o protótipo procura no repositório de idiomas do Tesseract o arquivo e o instala,
como mostra a Figura 4.10.
58
Figura 4.10 – Transferência e instalação do arquivo do idioma.
Fonte: O Autor.
Com os idiomas de entrada e tradução selecionados, basta focar na tela
principal o texto a ser traduzido. Ajuste o retângulo delimitador de acordo com o
tamanho do texto. Com o texto focado e envolto pelo retângulo, para iniciar o
processo de reconhecimento de caracteres, basta clicar no ícone de captura (Figura
4.11).
Figura 4.11 – Texto envolto pelo retângulo delimitador.
Fonte: O Autor.
Ao pressionar o botão de captura, o processo de reconhecimento de
caracteres se inicia automaticamente. Neste processo podem ocorrer três casos:
1. Sucesso no reconhecimento de caracteres, mas o texto não é
reconhecido corretamente (Figura 4.12);
59
2. Sucesso no reconhecimento de caracteres e o texto é reconhecido
(Figura 4.13);
3. *Falha no reconhecimento de caracteres (Figura 4.14).
Figura 4.12 – Erro no reconhecimento do texto.
Fonte: O Autor.
Figura 4.13 – Sucesso no reconhecimento de caracteres e no texto reconhecido.
Fonte: O Autor.
Figura 4.14
Esses erros no reconhecimento de
OCR. Este sistema nunca obteve uma taxa de reconhecimento que seja 100%
perfeito [AIM, 2000]. Com o conhecimento desta limitação, um requisito importante é
o rápido processamento e correção precisa da entrada. Porém para qu
bons resultados, outros fatores devem ser considerados além do sistema OCR. A
estes fatores a serem considerados somam
a serem processados e a precisão da captura de imagens do hardware.
Quanto a quali
Association (ECMA) criou especificações para um padrão de qualidade para o
documento impresso. Propriedades óticas como, reflexo, quantidade de opacidade e
ruídos, espessura, rigidez, superfície e outras
manual, processamento, impressão e codificação, estão documentadas em ECMA
15 [ECMA, 1977]. A última revisão do documento,
recomendadas para o uso de documentos paginados ou para um documento de
linha única.
O cumprimento destas especificações ou de parte delas, garantem um
documento de melhor qualidade para o tratamento pelo OCR e uma conseqüente
melhora no reconhecimento de caracteres
Outro tópico a ser discutido refere
idéia original da implementação da realidade aumentada compreende a exibição do
resultado da tradução como parte integrante da pré
Figura 4.14 – Falha no reconhecimento de caracteres.
Fonte: O Autor.
erros no reconhecimento de caracteres são comuns no
nunca obteve uma taxa de reconhecimento que seja 100%
perfeito [AIM, 2000]. Com o conhecimento desta limitação, um requisito importante é
o rápido processamento e correção precisa da entrada. Porém para qu
bons resultados, outros fatores devem ser considerados além do sistema OCR. A
estes fatores a serem considerados somam-se, variáveis como a qualidade dos itens
a serem processados e a precisão da captura de imagens do hardware.
Quanto a qualidade da entrada, a European Computers Manufacturers
(ECMA) criou especificações para um padrão de qualidade para o
documento impresso. Propriedades óticas como, reflexo, quantidade de opacidade e
ruídos, espessura, rigidez, superfície e outras características para manipulação
manual, processamento, impressão e codificação, estão documentadas em ECMA
A última revisão do documento, contém especificações
recomendadas para o uso de documentos paginados ou para um documento de
O cumprimento destas especificações ou de parte delas, garantem um
documento de melhor qualidade para o tratamento pelo OCR e uma conseqüente
melhora no reconhecimento de caracteres [ECMA, 1977].
Outro tópico a ser discutido refere-se quanto a Realidade Aumentada.
idéia original da implementação da realidade aumentada compreende a exibição do
resultado da tradução como parte integrante da pré-visualização da câmera. O
60
Falha no reconhecimento de caracteres.
caracteres são comuns no sistema
nunca obteve uma taxa de reconhecimento que seja 100%
perfeito [AIM, 2000]. Com o conhecimento desta limitação, um requisito importante é
o rápido processamento e correção precisa da entrada. Porém para que se obtenha
bons resultados, outros fatores devem ser considerados além do sistema OCR. A
se, variáveis como a qualidade dos itens
a serem processados e a precisão da captura de imagens do hardware.
European Computers Manufacturers
(ECMA) criou especificações para um padrão de qualidade para o
documento impresso. Propriedades óticas como, reflexo, quantidade de opacidade e
características para manipulação
manual, processamento, impressão e codificação, estão documentadas em ECMA-
contém especificações
recomendadas para o uso de documentos paginados ou para um documento de
O cumprimento destas especificações ou de parte delas, garantem um
documento de melhor qualidade para o tratamento pelo OCR e uma conseqüente
dade Aumentada. A
idéia original da implementação da realidade aumentada compreende a exibição do
visualização da câmera. O
61
resultado seria apresentado como um metadado inserido na tela de contexto ao
mesmo tempo em que outros elementos da realidade fosse visualizado pelo usuário.
Porém, essa prática foi descartada pois ocorreu um conflito ao realizar as operações
atribuídas ao plano de fundo (doInBackground) e exibição do resultado (execução
pós processamento, onPostExecute). Para evitar esse conflito, duas threads foram
implementadas para serem executadas em contextos separados. A thread
assíncrona de reconhecimento dos caracteres é executada durante a chamada da
pré-visualização da câmera, enquanto que a thread da tradução é executada após o
reconhecimento dos caracteres sendo exibida no contexto de tradução. Com isso,
como pode ser verificado nas Figura 4.13, a pré-visualização da câmera é exibida
enquanto é sobreposta pela tradução do verbete.
Uma dificuldade no desenvolvimento do protótipo refere-se quanto a
tradução dos textos. Em dezembro de 2011, de acordo com Jeff Chin, a API do
Google Translate deixou de ser gratuita para fazer parte de uma série de aplicativos
pagos do Google, conhecido como Google Apps for Business [CHIN, 2012].
Os testes realizados com o Google Translate (quando ainda encontrava-
se disponível gratuitamente) revelaram que as requisições de tradução enviadas ao
Google Translate obtiveram resposta em todos os casos (desde que uma conexão
com a internet era disponível).
Os números correspondentes aos testes realizados pelo protótipo,
correspondem às tentativas de reconhecimento dos textos. Nestes testes, foi
considerado que a tradução seria realizada em 100% dos casos, ao invés da
indisponibilidade da tradução (Translation Unavailable), como pode ser visto nas
Figuras 4.12 e 4.13.
4.3 Resultados
Durante o teste empírico nos diversos tipos de textos foram anotados o
número de tentativas realizadas até o reconhecimento com exatidão. Os melhores
resultados foram apresentados em textos com luminosidade uniforme e com melhor
contraste entre o texto e o fundo. O resultado dos testes pode ser visualizado na
Tabela 4.1.
62
Tabela 4.1 – Resultados do teste empírico
Os resultados obtidos indicam que meios físicos, impressos possuem
estatísticas melhores quanto ao reconhecimento dos caracteres. Porém, os números
acima representam uma estatística sobre uma pequena amostra de testes. Testes
feitos separadamente aos dos testes acima, demonstram pequenas divergências
quanto aos números acima, pois muitos são os fatores que influenciam, como, por
exemplo, o formato dos caracteres.
Quanto mais próximos os caracteres estiverem da grafia de forma, mais
precisas são as chances do reconhecimento dos caracteres. O sistema de OCR
apresentou dificuldades no reconhecimento de caracteres na forma cursiva. A
pequena diferença na crominância entre os caracteres e o fundo, e o fato dos
caracteres estarem sobrepostos uns aos outros são fatores que dificultam o
reconhecimento.
Tipo de Mídia Número de Tentativas
Número de Acertos
Número de Erros
Jornais 20 17 3
Revistas 20 15 5
Textos em LCD 20 14 6
Textos em Papel 20 17 3
Textos em Papel Escritos a Mão
20 7 13
Texto em Vídeos 20 8 12
63
5 CONSIDERAÇÕES FINAIS E TRABALHOS FUTUROS
Este trabalho buscou auxiliar a entrada de dados em tradutores por meio
do desenvolvimento de um protótipo para tradução instantânea. A solução proposta
utilizou entrada de texto visual por meio de um dispositivo móvel provido de uma
câmera e suporte touchscreen. Para o desenvolvimento do protótipo, realizou-se um
estudo sobre Realidade Aumentada, sistema Android em dispositivos móveis,
reconhecimento de caracteres e tradução instantânea.
O trabalho busca contribuir para o desenvolvimento de aplicativos para a
plataforma Android, existentes para diversos outros dispositivos, utilizando muitas
das bibliotecas e aplicações já existentes e serviços web disponíveis a fim de criar
aplicativos intuitivos e disponibilizá-los a comunidade.
A proposição do paradigma de visão computacional por meio do
reconhecimento ótico de caracteres contribui para um dos objetivos específicos
deste trabalho, porque a barreira encontrada pelo usuário ao ter que se digitar um
texto que está além do limite de sua compreensão é eliminada, tornando o capaz da
tradução em muitos idiomas.
Uma breve descrição do ambiente de desenvolvimento, as bibliotecas
utilizadas, as classes desenvolvidas e alguns problemas encontrados durante o
desenvolvimento foram relatados. Durante a fase de testes do protótipo, alguns
problemas também foram constatados. Uma dificuldade na execução desta pesquisa
refere-se a API do Google Translate. Esta abordagem não exigiu uma programação
maçante, porém sua funcionalidade corresponde à metade da funcionalidade de
todo o protótipo (reconhecimento/tradução), a tradução. Esta problemática poderá
ser abordada em um trabalho futuro.
Tendo como referência alguns outros automatic translation helpers
presentes em outras plataformas, uma extensão interessante a ser implementada é
a tradução pelo reconhecimento de voz. Por meio de APIs de reconhecimento de
voz, como o disponível para a plataforma Android, é possível capturar palavras e
sentenças ditas por um ser humano ou simulado por computador, enviar os dados
para processamento do tradutor e retornar ao usuário um streaming de voz com a
tradução no idioma desejado.
64
A API de tradução seria a mesma já utilizada por este aplicativo. Porém,
para este paradigma é imprescindível que o usuário indique corretamente tanto o
idioma original quanto o idioma de saída, para que a saída da tradução por voz seja
corretamente pronunciada. Caso contrário, a saída ouvida pelo usuário pode ser
confusa e até, em alguns casos, indistinguível.
Um estudo baseado na experimentação, interpretação, e avaliação de
resultados quanto ao tempo de resposta deste protótipo pode ser considerado
relevante para um trabalho futuro, visto que no presente trabalho não foram
levantados tópicos para instrumentação, treinamento, participantes, hipóteses,
variáveis e nem utilizada alguma técnica estatística. O trabalho englobaria todo o
escopo de uma experimentação, desde o planejamento e execução até a análise e
interpretação dos resultados obtidos.
Outra extensão interessante a ser desenvolvida é a disponibilidade offline.
Enquanto que para a tradução verbete por verbete a implementação de um banco
de dados de palavras é uma solução simples, o mesmo não pode ser dito para a
tradução dependendo do contexto.
65
REFERÊNCIAS
AIM Global Inc. Optical Character Recognition (OCR). Pittsburgh, PA, USA, 2000. 10 p.
ANDROID CENTRAL. Teclado QWERTY. Disponível em: < http://cdn.androidcentral.com/sites/androidcentral.com/files/articleimage/2437/2010/11/km-3.jpg >. Acesso em: 15 jan. 2012.
ANDROID DEVELOPER. What is Android? Disponível em: <http://developer.android.com/guide/basics/what-is-android.html>. Acesso em: 15 de mar. 2011.
APPLE STORE. Apple Web Apps iTranslate. Disponível em: <http://www.apple.com/webapps/productivity/itranslate.html>. Acesso em: 20 mar. 2011.
BIER, E., STONE, M., FISHKIN, BUXTON, W., BAUDEL, T. (1994). A taxonomy of see-through tools. Proceedings of the SIGCHI Confer ence on Human Factors in Computing Systems: Celebrating interdependence, pp. 358-364, 0897916506, Boston, April 1994, ACM, New York.
BIER, E., STONE, M., PIER, K., BUXTON, W., DEROSE, T. (1993). Toolglass and magic lenses: the see-through interface , Proceedings of the 20th Annual Conference on Computer Graphics and interactive Techniques SIGGRAPH '93, 0897916018, pp. 73-80, ACM, New York.
BLACKBERRY REFERENCE. Planar YUV Luminance Source Blackberry JDE 7.1.0 API Reference. Disponível em: <http://www.blackberry.com/developers/docs/7.1.0api/net/rim/device/api/barcodelib/PlanarYUVLuminanceSource.html>. Acesso em: 15 nov. 2011.
BONNINGTON, Christina. Android crushed the smartphone competition last quarter. Disponível em: <http://edition.cnn.com/2011/11/16/tech/mobile/android-competition-gartner/index.html>. Acesso em: 16 nov. 2011.
CHIN, Jeff. Paid version of Google Translate API now open for b usiness. Disponível em: <http://googlecode.blogspot.com/2011/08/paid-version-of-google-translate-api.html>. Acesso em: 25 jan. 2012.
CVISION TECHNOLOGIES INC. Applications of OCR. Disponível em: <http://www.cvisiontech.com>. Acesso em: 28 set. 2011.
EUROPEAN COMPUTER MANUFACTURERS ASSOCIATION. Recommended OCR Paper Specifications. 2. ed. Geneva - Switzerland, 1977. 24 p.
FRAGOSO, Victor; GAUGLITZ, Steffen; KLEBAN, Jim. TranslatAR: A Mobile Augmented Reality Translator on the Nokia N900. California, Santa Barbara, Eua: Ucsb, 2010. 7 p.
66
FRANKLIN ELECTRONICS PUBLISHERS. Global Translator in Travel Accessories. Disponível em: <http://www.franklin.com/estore/product/TGA-470/>. Acesso em: 20 mar. 2011.
GIBARA, Tom. Webcam Broadcaster. Disponível em: <http://www.tomgibara.com/android/>. Acesso em: 10 jul. 2011.
GOOGLE CODE. Leptonica - An open source C library for efficient image processing and image analysis operations. Disponível em: <http://code.google.com/p/leptonica/>. Acesso em: 06 out. 2011.
GOOGLE INC. Google Translate. Disponível em: <http://www.google.co.uk/help/faq_translation.html>. Acesso em: 20 mai. 2011.
IBM Research. IBM Research Case Studies . Disponível em: < http://domino.watson.ibm.com/odis/odis.nsf/pages/case.32.html>. Acesso em: 05 abr. 2011.
ISTOÉ - POR QUE ELES (E OUTROS CRAQUES) ESTÃO NO BR ASIL . São Paulo - Sp: Editora3, v. 2177, 29 jul. 11. Semanal.
JIBBIGO. Jibbigo Mobile Voice Translation Apps. Disponível em: http://www.jibbigo.com/website/. Acesso em: 14 out. 2011.
KIRNER, C. ; TORI, R. . Fundamentos de Realidade Aumentada . Em: Fundamentos e Tecnologia de Realidade Virtual e Aumentada. 1 ed. Porto Alegre: Sociedade Brasileira de Computação - SBC, 2006, v. 1, p. 23-37.
KIRNER, Claudio; SISCOUTTO, Robson. Realidade Virtual e Aumentada: Conceitos, Projeto e Aplicações. Petrópolis, Rj: Sbc, 2007.
LAYAR AR Browser. Layar Augmented Reality Browser . Disponível em: <http://www.layar.com>. Acesso em: 28 ago. 2011.
LIAO, Ping-sung; CHEN, Tse-sheng; CHUNG, Pau-choo. A Fast Algorithm for Multilevel Thresholding. Journal Of Information Science And Engineering, Taiwan, p. 713-727. 30 dez. 1999.
MASON, Paul. Suddenly the way to Web 3.0 seems clear. Disponível em: <http://www.bbc.co.uk/blogs/newsnight/paulmason/2010/09/suddenly_the_way_to_web_30_see.html>. Acesso em: 24 jan. 2012.
MORI, Shunji; SUEN, Ching Y.; YAMAMOTO, Kazuhiko. Historical Review of OCR Research and Development. Proceedings Of The Ieee,Yokohama, Japan, p. 1029-1058. 06 ago. 2002.
NIJHOLT, Anton; TRAUM David. The virtuality Continuum revisited , presented at CHI 2005 Workshop on the virtuality continuum revisited. Abril, 2005.
ORACLE Sun Developer Network. Oracle Sun Developer Network JNI Tecnology. Disponível em: <
67
http://java.sun.com/developer/onlineTraining/Programming/JDCBook/jni.html>. Acesso em: 07 ago. 2011.
ORACLE. Java Media Framework . Disponível em: <http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.html>. Acesso em: 09 fev. 2012.
PCMAG. PCMAG Encyclopedia Definition of YUV. Disponível em: <http://www.pcmag.com/encyclopedia_term/0,2542,t=YUV&i=55165,00.asp>. Acesso em: 17 out. 2011.
RAIS, Naveed Bin; HANIF, M. Shehzad; TAJ, Imtiaz A.. Adaptive Thresholding Technique for Document Image Analysis. Inria - Fr: Ieee, 2010. 6 p.
SCHWEGLER, Armin. Language and Globalization. Disponível em: <http://www.google.com.br/url?sa=t&rct=j&q=armin%20schwegler%20globalization&source=web&cd=1&ved=0CCUQFjAA&url=http%3A%2F%2Fwww.globalization101.org/uploads/File/Syllabus-Lang-Globalization.pdf>. Acesso em: 15 jan. 2012.
SONICMOBILE. iTranslate for iPhone. Disponível em: http://www.sonicomobile.com/itranslate-iphone/. Acesso em: 14 out. 2011.
SYSTRAN. SYSTRAN - Online translation, translation software and tools. Disponível em: <http://www.systransoft.com/>. Acesso em: 25 abr. 2011.
TANG, Son-lik; KWOH, Chee-keong; TEO, Ming-yeong. Augmented reality systems for medical applications. 17. ed. Nanyang Technology University - Singapore: Engineering In Medicine And Biology Magazine, Ieee, 1998. 49-58 p.
TCWORLD. Comparison of online machine translation tools. Disponível em: <http://www.tcworld.info/tcworld/translation-and-localization/article/comparison-of-online-machine-translation-tools/>. Acesso em: 25 abr. 2011.
TERRA NETWORKS BRASIL S.A. (Brasil). Esportes Terra. Disponível em: <http://esportes.terra.com.br/>. Acesso em: 02 fev. 2012.
TESSERACT, Ocr. Tesseract OCR - An OCR Engine that was developed at HP Labs between 1985 and 1995... and now at Google. Disponível em: <http://tesseract-ocr.googlecode.com/files/>. Acesso em: 02 fev. 2012.
THOMAS, Bruce H.; SANDOR, Christian. What Wearable Augmented Reality Can Do For You. Passau, Lower Bavaria, Germany: Ieee Cs, 2009. 8 p.
TOM POWERS. Unofficial Leptonica v1.68 Documentation. Disponível em: http://tpgit.github.com/UnOfficialLeptDocs/>. Acesso em: 14 out. 2011.
W3. ISO 639 Language Codes. Disponível em: <http://www.w3.org/WAI/ER/IG/ert/iso639.htm>. Acesso em: 01 out. 2011.
ZORZAL, Ezequiel R.. Realidade Aumentada. Disponível em: <http://realidadeaumentada.com.br>. Acesso em: 24 jan. 2012.