Embed Size (px)
Citation preview
UNICENP – CENTRO UNIVERSITÁRIO POSITIVO NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE ENGENHARIA DA COMPUTAÇÃO
SISTEMA DE CONTROLE DE ACESSO POR IBUTTON
COM VERIFICAÇÃO BIOMÉTRICA DA GEOMETRIA DA
MÃO
Curitiba 2003
UNICENP – CENTRO UNIVERSITÁRIO POSITIVO
NÚCLEO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
CURSO DE ENGENHARIA DA COMPUTAÇÃO
SISTEMA DE CONTROLE DE ACESSO POR IBUTTON COM
VERIFICAÇÃO BIOMÉTRICA DA GEOMETRIA DA MÃO
Autor: Guilherme Boreki Prof. Orientador: Alessandro Zimmer
Curitiba 2003
i
RESUMO
Neste trabalho é apresentado um novo sistema de controle de acesso baseado em
uma chave eletrônica individual e uma chave biométrica. A chave eletrônica é fornecida
via a leitura de um iButton, dispositivo eletrônico que possui um código próprio único
garantido pelo fabricante, já a chave biométrica é formada por primitivas geométricas
extraídas à partir de imagens da mão obtidas via um scanner tradicional. O sistema aqui
apresentado se diferencia de outros sistemas biométricos por uma técnica de extração de
primitivas à partir de uma análise do perfil de curvatura da imagem que é invariante à
rotação e à translação, não exigindo o uso de pinos ou dispositivos restritivos à posição da
mão no equipamento de aquisição de dados.
Palavras-chave: segurança, controle de acesso, ibutton, geometria da mão, biometria, perfil de curvatura.
ii
ABSTRACT
This work presents a new access control system based on a biometric code formed
by geometric features extracted from the hand. The system was designed to be used with a
an individual private key and a biometric code. The private key is provided by an iButto
while the biometric code is formed by geometric primitives extracted from hand images,
which are aquired by a common desktop scanner. The proposed system distinguishes itself
from other similar systems mainly because of the use of a feature extraction technique
based on the analysis of the curvature profile of the image. Through this, the system is
invariant to the rotation and translation of the hand, becoming unnecessary the use of any
kind of devices to restrict the positions of the hand (such as pins or pegs).
Index-terms: hand geometry, ibutton, biometry, difference of slopes.
iii
SUMÁRIO
RESUMO...............................................................................................................................I
ABSTRACT ........................................................................................................................ II
LISTA DE FIGURAS........................................................................................................VI
LISTA DE TABELAS....................................................................................................VIII
LISTA DE ABREVIATURAS..........................................................................................IX
1 INTRODUÇÃO ........................................................................................................... 1
2 ESPECIFICAÇÃO ...................................................................................................... 2 2.1 DESCRIÇÃO ........................................................................................................ 2
2.2 ESTUDO TEÓRICO ............................................................................................. 4
2.2.1 Controle de Acesso e Biometria .................................................................... 4
2.2.1.1 Reconhecimento da Geometria da Mão..................................................... 9
2.3 ESPECIFICAÇÃO DO SOFTWARE................................................................. 10
2.3.1 Sistema de Cadastro e Controle .................................................................. 12
2.3.1.1 Cadastro do iButton................................................................................. 13
2.3.1.2 Cadastro dos Dados do Usuário .............................................................. 13
2.3.1.3 Cadastro da Geometria da Mão ............................................................... 13
2.4 ESPECIFICAÇÃO DE HARDWARE................................................................ 14
2.4.1 iButton ......................................................................................................... 14
2.4.2 Placa Microprocessada (8031) ................................................................... 16
2.4.3 Sensor de Batimentos Cardíacos................................................................. 17
3 PROJETO .................................................................................................................. 20 3.1 PROJETO DE SOFTWARE ............................................................................... 20
3.1.1 Aquisição da Imagem .................................................................................. 20
3.1.2 Processamento da Imagem.......................................................................... 22
3.1.2.1 Conversão para Escala de Cinza.............................................................. 22
3.1.2.2 Binarização .............................................................................................. 23
3.1.2.3 Detecção da Bordas ................................................................................. 25
3.1.2.4 Afinamento .............................................................................................. 27
3.1.2.5 Extração do grau de Curvatura ................................................................ 29
3.1.2.6 Extração de Características...................................................................... 33
3.1.2.7 Geração do BioCode ................................................................................ 36
3.1.3 Sistema de Cadastro .................................................................................... 37
iv
3.1.3.1 Cadastro do Usuário ................................................................................ 37
3.1.3.2 Verificação do Acesso............................................................................. 38
3.1.3.3 Base de Dados ......................................................................................... 40
3.1.4 PROTÓTIPO DE TELAS............................................................................. 41
3.1.4.1 Tela de Login........................................................................................... 41
3.1.4.2 Tela de Auto Check do sistema ............................................................... 42
3.1.4.3 Tela de Cadastro de Usuários .................................................................. 43
3.1.4.4 Tela de Testes de Algoritmos .................................................................. 44
3.1.4.5 Tela inicial do sistema ............................................................................. 45
3.1.4.6 Tela de verificação .................................................................................. 45
3.2 PROJETO DE HARDWARE.............................................................................. 46
3.2.1 Sistema de Leitura do iButton ..................................................................... 47
3.2.1.1 Receptáculo de Leitura ............................................................................ 47
3.2.1.2 Programa de Leitura ................................................................................ 48
3.2.2 Sistema de Identificação dos Batimentos Cardíacos................................... 50
3.2.3 Software de Integração (8031) .................................................................... 52
3.3 CRONOGRAMA DO PROJETO ....................................................................... 54
3.4 ESTIMATIVA DE CUSTOS .............................................................................. 55
3.5 PLATAFORMA DE DESENVOLVIMENTO ................................................... 56
3.6 PROTOCOLO DE TESTES E VALIDAÇÃO ................................................... 56
3.6.1 Módulo de Reconhecimento Biométrico...................................................... 57
3.6.2 Módulo de Aquisição de Imagens................................................................ 57
3.6.3 Módulo de Cadastro .................................................................................... 57
3.6.4 Módulo de Leitura do iButton ..................................................................... 58
3.6.5 Módulo de Detecção de Batimentos Cardíacos .......................................... 58
3.6.6 Sistema Completo ........................................................................................ 58
4 IMPLEMENTAÇÃO ................................................................................................ 60 4.1 IMPLEMENTAÇÃO DO SOFTWARE ............................................................. 60
4.1.1 Aquisição da Imagem .................................................................................. 60
4.1.2 Processamento da Imagem.......................................................................... 62
4.1.3 Extração do Contorno ................................................................................. 62
4.1.4 Extração de Características ........................................................................ 63
4.1.4.1 Extração do Grau de Curvatura ............................................................... 63
4.1.4.2 Filtragem do resultado............................................................................. 64
v
4.1.4.3 Cálculo do comprimento e da largura ..................................................... 68
4.1.4.4 Geração do Biocode................................................................................. 69
4.1.4.5 Classificador ............................................................................................ 70
4.1.5 Cadastro de usuários................................................................................... 70
4.2 IMPLEMENTAÇÃO DO HARDWARE............................................................ 71
4.2.1 Leitura do iButton........................................................................................ 71
4.2.2 Batimentos Cardíacos ................................................................................. 72
4.3 CAIXA DE ISOLAMENTO ............................................................................... 73
4.4 TESTES E VALIDAÇÃO DO PROJETO.......................................................... 75
4.4.1 Módulo de Reconhecimento Biométrico...................................................... 76
4.4.2 Módulo de Aquisição de Imagens................................................................ 76
4.4.3 Módulo de Cadastro .................................................................................... 76
4.4.4 Módulo de Leitura do iButton ..................................................................... 76
4.4.5 Módulo de Detecção de Batimentos Cardíacos .......................................... 77
4.4.6 Sistema Completo ........................................................................................ 77
5 RESULTADOS .......................................................................................................... 78
6 CONCLUSÕES.......................................................................................................... 81
7 REFERÊNCIAS BIBLIOGRÁFICAS .................................................................... 82
ANEXO 1 – PLACA MICROPROCESSADA (KIT 8031)............................................ 84
ANEXO 2 – DIAGRAMA DE CASOS DE USO DO SISTEMA .................................. 85
ANEXO 3 – DIAGRAMA DE CLASSES DO SOFTWARE......................................... 86
ANEXO 4 – DIAGRAMA DE SEQUENCIA PARA ADQUIRIR IMAGEM............. 87
ANEXO 5 – DIAGRAMA DE SEQUÊNCIA PARA GERAÇÃO DO PADRÃO....... 88
ANEXO 6 – DIAGRAMA DE SEQÜÊNCIA DE CADASTRO DE USUÁRIOS ....... 89
ANEXO 7 – DIAGRAMA DE SEQUENCIA PARA CARREGAR USUÁRIOS........ 90
ANEXO 8 – DIAGRAMA DE SEQÜÊNCIA DA VERIFICAÇÃO DE ACESSO ..... 91
ANEXO 9 – CAIXA DE ISOLAMENTO ....................................................................... 92
ANEXO 10 – GRÁFICO DE DISPERSÃO DOS USUÁRIOS DE TESTE ................. 93
ANEXO 11 – CÓDIGO FONTE DO PROCESSAMENTO DE IMAGENS ............... 94
ANEXO 12 – CÓDIGO FONTE DO SOFTWARE DO 8031 ..................................... 116
vi
LISTA DE FIGURAS
Figura 1 - Diagrama de blocos para validação de um usuário no sistema............................. 2
Figura 2 – Percentual de participação das tecnologias de biometria no total........................ 8
Figura 3 - Imagem da mão, conforme vinda do scanner, convertida para tons de cinza..... 11
Figura 4 - Imagem após algoritmo de detecção de borda.................................................... 11
Figura 5 - Somente “Contorno” da Imagem, pronta para extração de características......... 11
Figura 6 - Diagrama de Blocos para cadastro de usuário .................................................... 14
Figura 7 - Imagens de um iButton ....................................................................................... 15
Figura 8 - Diagrama de blocos do ibutton ........................................................................... 15
Figura 9 - Diagrama de blocos da leitura e persistência do código do ibutton.................... 17
Figura 10 - Sensor de Batimentos Cardíacos ...................................................................... 18
Figura 11 - Posicionamento do Sensor de Batimentos na mão ........................................... 19
Figura 12 - Camadas para aquisição da imagem ................................................................. 21
Figura 13 - Imagem em escala de cinza .............................................................................. 25
Figura 14 - Histograma da imagem em escala de cinza ...................................................... 25
Figura 15 - Imagem binarizada............................................................................................ 25
Figura 16 - Extração de bordas aplicado diretamente a uma imagem em tons de cinza ..... 26
Figura 17 - Detecção de Borda em uma imagem Binarizada .............................................. 26
Figura 18 - Zoom de uma parte da imagem onde a borda foi detectada ............................. 28
Figura 19 - Grupos possíveis de pontos que violam o “esqueleto principal”...................... 29
Figura 20 - Imagem antes do Afinamento e imagem após afinamento ............................... 29
Figura 21 - Aplicação do DOS sobre uma curva qualquer.................................................. 30
Figura 22 - Cálculo do ângulo entre os vetores. .................................................................. 31
Figura 23 - Gráfico de diferença de Curvatura.................................................................... 33
Figura 24 - Imagem com destaque nos pontos de maior curvatura ..................................... 33
Figura 25 - Gráfico de curvatura da mão com marcação de um dedo............................... 34
Figura 26 - Contorno da mão com marcação nos pontos ressaltados na Figura 25 ............ 35
Figura 27 - Cálculo da largura do dedo ............................................................................... 36
Figura 28 - Tela de Login .................................................................................................... 41
Figura 29 - Tela de check-up dos módulos do sistema........................................................ 42
Figura 30 - Tela de cadastro de usuários ............................................................................. 43
Figura 31 - Tela de testes de algoritmos.............................................................................. 44
vii
Figura 32 - Tela de seleção de módulos .............................................................................. 45
Figura 33 - Tela de verificação............................................................................................ 46
Figura 34 - Circuito para de leitura do iButton................................................................... 48
Figura 35 – Fluxograma do programa para leitura do iButton ............................................ 49
Figura 36 - Onda real de funcionamento do sensor de batimentos cardíacos ..................... 50
Figura 37 - Onda resultante do sensor devido a variação do volume de sangue................. 51
Figura 38 - Circuito para tratamento dos batimentos cardíacos .......................................... 52
Figura 39 - Fluxograma do software do 8031 ..................................................................... 53
Figura 40 – Tela intermediária de aquisição de imagens .................................................... 61
Figura 41 - Imagem do contorno com o detalhe do Pulso e após o corte............................ 61
Figura 42 - Passos para extração do contorno ..................................................................... 62
Figura 43 - Gráfico de resposta do método DOS ................................................................ 65
Figura 44 – Gráfico com aplicação de um filtro Gaussiano ................................................ 66
Figura 45 - Gráfico com aplicação de um filtro de média................................................... 66
Figura 46 - Pontos de alta curvatura da amostra ................................................................. 67
Figura 47 - Imagem com as medidas de largura e comprimento......................................... 68
Figura 48 - Imagem binarizada com influência da iluminação externa .............................. 73
Figura 49 - Histograma de uma imagem sem a caixa de isolamento .................................. 73
Figura 50 - Luz confinada no scanner................................................................................. 74
Figura 51 - Luz Refletida para fora da área de leitura do scanner ...................................... 75
Figura 52 - Histograma de uma imagem utilizando a caixa de isolamento......................... 75
viii
LISTA DE TABELAS
Tabela 1 - Tabela comparativa de biometria ......................................................................... 7
Tabela 2 - Protocolo de comunicação entre software e 8031.............................................. 39
Tabela 3 - Campos da tabela de usuários no Banco de Dados ............................................ 41
Tabela 4 - Cronograma do Projeto ...................................................................................... 54
Tabela 5 – Estimativa de Custos ......................................................................................... 55
Tabela 6 - Desvios Padrão dos Biocodes............................................................................. 79
ix
LISTA DE ABREVIATURAS
ADO – Activex Data Objects
API – Application Programming Interface
ANSI – American National Standards Institute
BD – Banco de Dados
BPM – Batimentos Por Minuto
CMOS – Complementary Metal Oxide Semiconductor
CRC – Cyclical Redundancy Check
DOS – Difference of Slopes
DIB – Device Independent Bitmap
DSN – Data Source Names
ECG – Eletro-CardioGrafia
EPROM – Electric Programmable Read Only Memory
FAR – False Aception Rate
FRR – False Rejection Rate
IBG – International Biometric Group
LED – Light Emitting Diode
LSD – Light Sensitive Diode
PC – Personal Computer
PIN – Personal Identification Number
PPG – Photo PlethysmoGraphy
RAM – Random Access Memory
RGB – Red Green Blue
SGBD – Sistema Gerenciador de Banco de Dados
SQL – Structured Query Language
TTL – Transistor Transistor Logic
UML – Unified Modeling Language
1
1 INTRODUÇÃO
A cada ano que passa, devido à evolução dos componentes eletrônicos e tecnologias
computacionais, novas metodologias são elaboradas para fazer o controle de pessoas
autorizadas a locais de acesso restrito com maior facilidade, não permitindo que pessoas
não autorizadas entrem no local.
Algumas tecnologias atuais para o controle de acesso pessoal são cartões magnéticos
(Magnetic Tags), Smart Cards, o próprio ibutton, e diversos outros, que permitem ao
portador do cartão ter um número identificador único (PIN – Personal Identification
Number) que o associa aos locais cuja permissão é válida para o acesso.
Os objetos de controle de acesso têm a falha de serem transferíveis, e podem ser
roubados facilmente, com isso, permitindo a violação da segurança do local. Para evitar
estes problemas, muitos locais implementam a utilização de senhas junto com o
identificador pessoal, assim sem a presença do usuário se torna mais difícil à entrada não
permitida dentro dos setores controlados.
As senhas estão cada vez mais comuns em nosso dia-a-dia, e devido ao número de
senhas que temos que nos lembrar, acabamos gerando dois problemas, um deles é a
utilização de senhas iguais para acessar ambientes diferentes e o segundo problema, está no
fato de a variedade de senhas proporcionar um esquecimento cada vez mais comum.
O problema da senha pode ser resolvido pelo fato de que todos os seres vivos têm
características inerentes que são únicas e intransferíveis. Os seres humanos, por exemplo,
possuem diversas características individuais, como a impressão Digital, impressão da
palma da mão, a íris, a retina, a face, e a geometria da mão.
Estas características podem ser identificadas utilizando-se meios computacionais
apropriados. A este estudo chamamos de Biometria, e, por ser único, pessoal e
intransferível, pode substituir a utilização de senhas na maioria dos casos, garantindo assim
a entrada somente da pessoa apropriada.
2
2 ESPECIFICAÇÃO
A seguir será tratada a especificação do projeto, onde descreveremos o princípio de
funcionamento do sistema como um todo, descrevendo alguns dos requisitos iniciais para a
completude do projeto, como por exemplo, as tecnologias envolvidas na leitura e
identificação e utilização de uma chave eletrônica, algumas das características biométricas
da mão e o funcionamento básico de um sistema capaz de identificar batimentos cardíacos.
2.1 DESCRIÇÃO
O projeto realizado é um sistema de controle de acesso, baseado em ibutton para a
identificação do usuário, juntamente com um código biométrico referente à geometria da
mão, garantindo a individualidade de cada usuário, e um sinal de prova de vida, garantindo
que o usuário possui sinais vitais, evitando desta maneira meios mais violentos de quebra
da segurança no ambiente.
O funcionamento principal do sistema se baseia em um processamento das entradas
envolvidas para gerar um sinal de saída referente à abertura ou não da porta de entrada ao
ambiente controlado, conforme mostrado na Figura 1.
Figura 1 - Diagrama de blocos para validação de um usuário no sistema
ibutton
Imagem da mão
Batimentos
Análise
Sinal de
controle
Porta
3
Inicialmente o ibutton dará a identificação do usuário perante o sistema, permitindo
ao sistema efetuar a busca dos dados do usuário dentro de uma base de dados de pessoas
que possuem a permissão necessária para entrar na área restrita.
Uma vez com os dados do usuário em mãos, inicia-se o processo de
reconhecimento biométrico, juntamente com a leitura do sinal do batimento cardíaco, pois
se esse der negativo, a porta se manterá fechada.
A descrição acima representa uma tentativa de entrada, partindo do princípio que o
sistema já teria um usuário com ibutton e código biométrico salvos em algum lugar. Para
esta ação ocorrer, o sistema contará com um módulo de controle, onde um funcionário que
tenha permissão para liberar o acesso ao ambiente controlado estará fazendo o cadastro das
pessoas com acesso ao ambiente.
O cadastro será feito em parte como o módulo de identificação. Inicialmente o
usuário colocará o ibutton no leitor para que o código seja reconhecido, o número do
ibutton será o código identificador do usuário o qual deve ser único para cada usuário
cadastrado.
Para efetuar o cadastro da mão, o usuário deverá colocar a mão no scanner diversas
vezes, para que o sistema seja capaz de reconhecer as variações de uma mesma geometria
de mão, estabelecendo valores padrões para as características lidas. Estes valores padrões
ficarão armazenados no banco de dados, juntamente com as informações do usuário.
Qualquer tentativa de entrada no ambiente de acesso restrito deverá então atender
aos requisitos do sistema conforme descritos abaixo:
• O código do ibutton deve estar cadastrado na base de dados;
• O sinal do coração deve condizer com o sinal de uma pessoa viva;
• A geometria lida da mão deve estar dentro do limite de aceitação para comparação
com os dados da geometria armazenados na base de dados;
4
2.2 ESTUDO TEÓRICO
Neste ponto serão descritas algumas das teorias que envolvem as tecnologias das
quais este projeto se utilizará para conseguir atingir os resultados esperados.
2.2.1 Controle de Acesso e Biometria
Biometria, como definido por [1] é “A ciência de identificar ou autenticar a
identidade de um indivíduo baseando-se em características fisiológicas ou
comportamentais”.
Para fazer um controle efetivo de acesso a ambientes, existem três maneiras
básicas, conforme descritas abaixo:
• O que você tem;
• O que você sabe;
• O que você é;
O que a pessoa possui, define algo físico, que identifica esta pessoa ao sistema,
como SmartCards, cartões magnéticos, e o próprio ibutton que será usado neste projeto.
Este tipo de controle tem o inconveniente de ser transferível, portanto o sistema nunca será
capaz de garantir com um grau elevado de certeza que o usuário com o meio de acesso, é
realmente o usuário cadastrado no sistema. Alguns exemplos desta quebra de segurança
são o empréstimo de cartões, ou até o roubo dos mesmos.
O que a pessoa sabe, trata da utilização de senhas pessoais, uma metodologia de
segurança muito utilizada, e que tem certo grau de garantia, mas da mesma maneira que a
anterior, pode ser transferível, uma pessoa pode passar sua senha para colegas, ou até
mesmo esquece-la devido à grande quantidade de senhas que cada pessoa deve possuir nos
dias de hoje.
E por último, temos o conceito que será abrangido neste trabalho, o que a pessoa é,
isto quer dizer, algo intrínseco a pessoa, que não é transferível, não pode ser emprestado, e
não pode ser imitado (ou os meios para fazê-lo são ao menos, muito mais complexos do
que nas metodologias citadas acima). Este conceito envolve não somente características
físicas individuais como impressão digital, reconhecimento facial, reconhecimento da
5
geometria da mão, íris, retina, entre outros, mas também envolve características
comportamentais, como reconhecimento de digitação, reconhecimento vocal, etc.
Neste documento será comentado principalmente sobre o reconhecimento de
geometria da mão, visto que esta é a biometria utilizada no projeto para fazer o controle
dos usuários.
A Tabela 1 (originalmente apresentada em [2]) apresenta um comparativo entre as
tecnologias biométricas mais utilizadas, os pontos de comparação são como segue abaixo:
• Verificação É quando um método biométrico é capaz de fazer um reconhecimento
de um para um, ou seja, um código biométrico padrão é comparado com um código
candidato e o sistema responderá se os dois códigos são referentes à mesma pessoa.
• Identificação Identifica quando este tipo de biometria é capaz de fazer
reconhecimento dentro de uma base, onde somente com o código biométrico o
sistema é capaz de reconhecer um usuário entre vários. Quantos mais pontos
analisados para a diferenciação dos indivíduos, maior a capacidade de identificação
da biometria.
• Precisão Indica o “quão bem” a biometria é capaz de diferenciar os usuários.
• Individualidade Representa o índice de individualidade do código biométrico, ou,
num grupo de quantas pessoas este código deixa de ser único.
• Problemas comuns São os problemas que podem gerar o não reconhecimento de
uma pessoa.
• Falsa aceitação induzida Demonstra a facilidade que alguém teria para criar uma
réplica do código biométrico e passar pelo sistema.
• Falsa negação induzida Representa a dificuldade de alguém conseguir fazer com
que o sistema não reconheça seu código biométrico (não sendo identificado).
• Níveis de segurança Ambientes em que o sistema pode ser instalado
satisfatoriamente.
6
• Estável em longo prazo “Quão bem” o sistema passa a funcionar em longo prazo
sem necessitar de atualizações no código biométrico.
• Aceitação dos usuários Índice de aceitação do sistema por usuários.
• Intrusividade O quanto o sistema invade a privacidade do usuário, ou necessita da
sua cooperação.
• Facilidade de Uso O sistema é fácil para que qualquer usuário possa utilizá-lo?
• Baixo Custo Valor para implantação do sistema em um ambiente.
• Hardware Tipo de hardware utilizado pelo sistema.
7
Biometria Verificação Identificação Precisão Individualidade Problemas Comuns Falsa aceitação induzida Falsa negação induzida
Digital Sim Sim Muita Alta 1 em 500+ Secura, sujeira, idade Muito Difícil Muito Difícil
Reconhecimento de Face Sim Não Alta Sem dados Iluminação, idade, adereços Difícil Fácil
Geometria da Mão Sim Não Alta 1 em 500 Ferimento da mão, idade Muito Difícil Médio
Reconhecimento de Voz Sim Não Média 1 em 50 Ruído, clima, doenças Médio Fácil
Íris Sim Sim Muita Alta 1 em 131,000 Iluminação Muito Difícil Muito Difícil
Retina Sim Sim Muita Alta 1 em 10,000,000 Adereços Muito Difícil Muito Difícil
Assinatura Sim Não Média 1 em 50 Mudanças na assinatura Médio Fácil
Digitação Sim Não Baixa Sem dados Ferimentos da mão, cansaço Difícil Fácil
DNA Sim Sim Muita Alta Sem dados Nenhum Muito Difícil Muito Difícil
Biometria Níveis de
segurança
Estável em
longo prazo
Aceitação
dos usuários
Intrusivo Facilidade de Uso Baixo Custo Hardware
Digital Alto Alto Médio Alguns sistemas Alto Sim Especial, barato
Reconhecimento de Face Médio Médio Médio Não Médio Sim Comum, barato
Geometria da Mão Médio Médio Médio Não Alto Não Especial, médio-custo
Reconhecimento de Voz Médio Médio Alto Não Alto Sim Comum, barato
Íris Alto Alto Médio Não Médio Não Especial, caro
Retina Alto Alto Médio Muito Baixo Não Especial, caro
Assinatura Médio Médio Médio Não Alto Sim Especial, médio-custo
Digitação Médio Baixo Alto Não Alto Sim Comum, barato
DNA Alto Alto Baixo Extremamente Baixo Não Especial, caro
Tabela 1 - Tabela comparativa de biometria
8
Cada uma das tecnologias citadas acima é mais utilizada em algumas áreas e menos
em outras. A Figura 2 apresenta a divisão destas tecnologias estimadas para 2003 pelo
IBG( International Biometry Group) [3].
Figura 2 – Percentual de participação das tecnologias de biometria no total
Sempre que falamos em sistemas de biometria, temos que ter em mente dois termos
que indicarão o índice de segurança do sistema, são eles:
Taxa de Falsa Rejeição Esta taxa indica qual é o percentual de indivíduos que não
conseguirão passar pelo sistema, mesmo apresentando a biometria correta ( a partir de uma
aquisição da mesma pessoa, o sistema reacusará seu acesso). Um dos objetivos dos
sistemas é sempre possuir uma pequena taxa de falsa rejeição.
Taxa de Falsa Aceitação Este é um ponto muito perigoso nos sistemas, indica qual o
percentual de tentativas, onde a amostra não corresponde ao mesmo indivíduo que efetuou
o cadastro, e mesmo assim, o sistema o identificará, ou seja, uma pessoa se passando pelo
dono do código pode ser aceito em um ambiente protegido. Este valor deve ser o mais
próximo possível de zero.
Divisão de Mercado por Tecnologias para 2003
Dinâmica de Digitação
0,3%
V erif icação de A ss inatura
2,4%
Reconhec imento V ocal4,1% Reconhec imento de
Iris7,3%
Geometria da Mão10,0%
Reconhec imento Fac ial11,4%
Outros Dispos itivos12,4%
Reconhec imento de Digitais52,1%
9
2.2.1.1 Reconhecimento da Geometria da Mão
O reconhecimento de geometria da mão é um dos sistemas de biometria mais
antigos, sendo utilizado desde a década de 70.
Este tipo de biometria conforme mostrado anteriormente é recomendado para
ambientes com níveis de segurança entre médio e baixo de acordo com os padrões de
segurança e isso se deve principalmente ao nível de individualidade.
A geometria da mão de uma pessoa não é uma medida com um índice de
individualidade muito grande, pois os sistemas normalmente utilizam poucas medidas de
características para gerar o código biométrico. Diferentemente do reconhecimento de íris
onde centenas de pontos reconhecem um indivíduo, no reconhecimento de mão este
número é reduzido para poucas dezenas.
Os sistemas de reconhecimento de geometria de mão se utilizam de diversas medidas
de comparação; alguns utilizam medidas tridimensionais, outros bidimensionais (como
será o caso deste projeto), alguns dos sistemas verificam todos os cinco dedos da mão
enquanto outros somente dois ou três dedos.
Este tipo de biometria possui algumas vantagens e em contra partida, desvantagens.
Abaixo seguem exemplos disso.
Vantagens
• Amigável, fácil de ser utilizado.
• Requer pequeno espaço de armazenamento para o código biométrico.
Desvantagens
• Pouca distinção em grupos.
• Sistema grande, reduzindo algumas possibilidades de instalação onde o espaço
físico é restrito.
• Ferimentos na mão pode distorcer a análise.
Existem diversos processos para a aquisição dos dados e para a comparação entre
duas mãos. A metodologia que será, à priori, utilizada neste trabalho está brevemente
descrita a seguir.
10
2.3 ESPECIFICAÇÃO DO SOFTWARE
Nesta seção será descrita a parte de software em si, sua metodologia de
funcionamento.
Inicialmente temos uma imagem adquirida através de um scanner de mesa comum.
Esta imagem não estará em condições de ser analisada, pois conterá informações que não
são úteis, na verdade são prejudiciais a eficácia do sistema. O primeiro passo, por exemplo,
será fazer a conversão da imagem para escala de cinza, pois nenhuma informação de cor
será utilizada para a criação do padrão e, portanto, não será utilizada na comparação
padrão-canditado.
Tendo uma imagem válida (como a mostrada na Figura 3), será dado inicio ao
tratamento já direcionado a aquisição de características da mão, todo o fundo (que por estar
exposta num scanner de mesa, possivelmente estará completamente preto) será excluído,
pois será descartado.
A imagem da mão ainda não estará preparada para uma extração de características,
pois muitos dos dados da imagem ainda podem ser desconsiderados, como por exemplo a
ranhura da mão, defeitos internos, etc. Basicamente, este projeto visa reconhecer somente a
geometria da mão, que pode ser aproximada pelo contorno da mão na imagem. Usando um
algoritmo de detecção de bordas chegaremos a uma imagem mais próxima do contorno,
onde as características poderão ser extraídas, a imagem resultante será parecida com a
mostrada na Figura 4.
A partir da imagem com o contorno, pode ser utilizado um algoritmo que elimine o
que restou dentro da imagem da mão, tendo como resultado somente o contorno externo.
Com base neste contorno externo, as características já podem ser extraídas mais
facilmente. Por exemplo, processando a imagem de cima para baixo pode-se encontrar as
pontas dos dedos, e os “vales” que separam os dedos. Estas duas informações já permitem
o cálculo da altura dos dedos e, somente percorrendo pelo caminho formado por eles,
podemos facilmente retirar as informações de largura, máxima, mínima e média de cada
um dos dedos conforme mostrado na Figura 5.
11
Figura 3 - Imagem da mão, conforme vinda do
scanner, convertida para tons de cinza
Figura 4 - Imagem após algoritmo de detecção de
borda
Figura 5 - Somente “Contorno” da Imagem, pronta para extração de características
12
Para a geração do padrão (o código biométrico a ser comparado com as imagens
candidatas), o usuário deverá colocar sua mão diversas vezes, assim no momento do
cadastramento, o sistema poderá estabelecer valores médios, baseados nas variações da
mão conforme apontado por [4].
O método utilizado trabalha somente com o contorno da mão, de modo que a
variação de posicionamento na mão não irá influenciar na medida biométrica. A diferença
entre aquisições de uma mesma pessoa será bem reduzida, pois a mão de uma pessoa não
terá variações físicas entre as aquisições. Ainda assim, serão utilizadas várias imagens para
gerar os dados do padrão. Isto se deve ao fato de que diferenças podem acontecer devido a
fatores externos ou por situações especiais no método de análise utilizado.
Temos aqui classes distintas, aquisições para o mesmo usuário, e aquisições para
usuários diferentes. A diferença extra-classes dará o nível de individualidade do usuário.
Espera-se que as aquisições entre um mesmo indivíduo sejam bem próximas,
enquanto para indivíduos diferentes, seja o mais diferente possível. A diferença intra-classe
deve tender a zero, enquanto a diferença extra-classes deve ser grande.
2.3.1 Sistema de Cadastro e Controle
Para o cadastramento de indivíduos o sistema terá um módulo à parte, que utilizará
a parte de reconhecimento de mãos.
O objetivo deste software é unir em uma base de dados às informações de quem
terá permissão para entrar no ambiente de acesso restrito. Aqui serão armazenadas algumas
informações pessoais do usuário, seu código do ibutton e a imagem padrão para
verificação. Para acessar o ambiente, esta imagem padrão será comparada com as imagens
adquiridas para identificar se estas pertencem a um mesmo usuário.
O cadastro dos usuários neste sistema deverá ser feito por alguém que seja
responsável pelo acesso das pessoas ao ambiente, e nunca pelo próprio usuário.
13
2.3.1.1 Cadastro do iButton
Cada ibutton possui um código identificador único, que pode ser adquirido via
hardware, como será explicado mais à frente, neste projeto este código único será utilizado
para identificar também os usuários, portanto cada usuário do sistema terá o seu ibutton
pessoal.
Para efetuar o cadastro do ibutton, existirá um campo na tela de cadastro onde
deverá ser colocado o código numérico, o preenchimento será feito automaticamente,
colocando-se o ibutton no leitor, o código será lido e passado para a tela de cadastro.
2.3.1.2 Cadastro dos Dados do Usuário
O software terá alguns campos para informações de identificação pessoal do
usuário, como nome, endereço, número de alguns documentos, etc. Estes dados serão
entrados de maneira comum, digitando-os na tela.
2.3.1.3 Cadastro da Geometria da Mão
Para cadastrar o código biométrico da geometria da mão, o usuário inicialmente
colocará a mão no scanner para que esta seja lida e processada conforme descrito acima.
Este procedimento será repetido num mínimo de três vezes, até que se possa ter três
imagens com uma qualidade suficiente para conseguir montar o padrão. O dados padrão
serão os dados que ficarão armazenados na base de dados sendo resultado de uma “média”
das características destas três aquisições, tendo, portanto alguma informação da tolerância
que a mão terá com relação a diferenças.
A Figura 6 apresenta o diagrama de blocos de um cadastro completo de um novo
usuário no sistema.
14
Figura 6 - Diagrama de Blocos para cadastro de usuário
2.4 ESPECIFICAÇÃO DE HARDWARE
Este projeto contará ainda com uma parte de hardware complexa necessária para a
aquisição dos dados do ibutton, pois este possui um protocolo de comunicação bem
definido e precisa de um microprocessador para a leitura.
2.4.1 iButton
O ibutton é um chip encapsulado em uma caixa de aço inoxidável de 16 mm
(Figura 7). Com este tamanho reduzido, o ibutton permite ao seu portador que o leve para
qualquer lugar, pois pode ser facilmente guardado e não possui uma sensibilidade muito
alta com variações de ambiente. Esta invariabilidade permite que sistemas de controle de
acesso baseados em ibutton sejam instalados em praticamente qualquer lugar, tanto
aplicações indoors quanto outdoors e até mesmo ambientes onde as variações de
temperatura sejam bastante elevadas, especificações descritas no datasheet do componente
[6].
ibutton
BD
Criação da
imagem
padrão
Aquisição 1 Aquisição 2 Aquisição 3
Cadastro
do UsuárioDados do
usuário
15
Figura 7 - Imagens de um iButton
Para manter o custo de produção baixo, o ibutton utiliza somente uma linha para
dados e terra. A energia para seu funcionamento é “roubada” desta linha de comunicação
(energia “parasitada”), sendo portanto, desnecessário qualquer tipo de bateria [7].
A Figura 8, mostra uma visão geral do ibutton. O chip no interior é produzido com
tecnologia CMOS e consume somente um mínimo de corrente quando em estado de
espera. Para manter o consumo de energia o menor possível durante os momentos de
atividade e para ser compatível com os níveis de tensão existentes, a linha de dados do
ibutton é desenvolvida como saída em “coletor aberto”, conforme especificado no
datasheet [7]. A fonte de corrente da linha de dados retorna para o aterramento se o ibutton
for removido do local de leitura.
Figura 8 - Diagrama de blocos do ibutton
O tempo de leitura nominal de um ibutton é menor que 5ms, e sua faixa de
temperatura de operação é ampla, podendo variar de –40 ºC a +85ºC, com relação ao nível
16
de tensão aplicado, este deve se manter entre 2,8V a 6V. Estes valores são calculados de
acordo com o capacitor interno utilizado no ibutton (que irá gerar a energia necessária para
que o ibutton seja capaz de responder ao protocolo).
O ibutton que será utilizado neste projeto é o 1990A que dentre as características
principais [8] podem ser destacados o código interno de 64 bits único (garantido pelo
fabricante), sendo divididos em 8 bits identificando a família do produto, 48 bits de código
serial identificador e 8 bits de CRC. O cálculo do CRC é calculado através do resto da
divisão do código identificador pelo polinômio X8 + X5 + X4 +1.
Outra característica é a velocidade de transmissão que é de 16 kbits por segundo, e
o protocolo 1-wire.
O protocolo de comunicação utilizado nos ibuttons chama-se 1-wire, pois se utiliza
somente 1 linha de dados, sendo esta portanto, half-duplex, ou seja, é capaz de transmitir
nas duas direções, mas desde que em intervalos separados de tempo [7].
A troca de dados entre o ibutton e o dispositivo mestre (normalmente um
microcontrolador) é definido por intervalos de tempo, a sincronização entre o
microprocessador e o ibutton são sempre baseadas na rampa do sinal iniciando-se quando o
ibutton é colocado no conector de leitura.
2.4.2 Placa Microprocessada (8031)
O ibutton necessita de um dispositivo mestre para fazer a comunicação via 1-wire
[8], neste projeto será utilizado o Kit (8031), que se trata de um Kit de desenvolvimento
com um sistema mínimo para o funcionamento de um microcontrolador 8031.
O sistema mínimo é composto por uma memória RAM 62256 de 256kBits, além de
uma EPROM para conter o software do 8031, possui ainda um cristal de 11,0592 MHz
para gerar os pulsos de clock necessários com o sinal, seu esquema pode ser visto no
ANEXO 1.
A razão na escolha deste microprocessador entre outras está basicamente pela
experiência adquirida durante o curso em trabalhar com ele, e pela facilidade de se utilizar
o sistema, mas isso de modo algum impede que o sistema seja desenvolvido utilizando
17
outro microprocessador ou microcontrolador, desde que sejam atendidas as características
individuais de cada um.
A leitura do código do ibutton será feita inicialmente pelo 8031, e este terá a
responsabilidade de transmitir ao software para o reconhecimento da base de dados,
conforme explicado anteriormente, de modo que podemos expandir o “bloco” da leitura do
ibutton, desde a entrada no conector até a persistência do código em banco de dados
conforme mostrado abaixo na Figura 9:
Figura 9 - Diagrama de blocos da leitura e persistência do código do ibutton
A placa do 8031 também será responsável por receber os sinais do batimento
cardíaco e interpretá-lo, retornando somente a informação se o sinal corresponde a uma
pessoa viva ou não. Basicamente se trata de um contador por tempo, que espera um valor
que comumente indica uma pessoa saudável, algo acima de 60 BPM por exemplo, isso é
conseguido facilmente utilizando-se os timers do 8031, que podem ser regulados para fazer
a contagem de tempo de uma maneira razoavelmente confiável, utilizando-se o timer para
a contagem dos batimentos e as interrupções para a leitura do iButton a placa
microprocessada se mostra uma opção ideal.
2.4.3 Sensor de Batimentos Cardíacos
Este projeto consiste ainda de um sensoriamento dos batimentos cardíacos, de
modo a evitar que “mãos falsas” sejam utilizadas, evitando também atitudes mais violentas
por parte de pessoas não autorizadas a acessar o ambiente.
O sensor utilizado será o mesmo que é visto comumente em bicicletas ergométricas
e esteiras para exercícios, medindo o batimento cardíaco enquanto o usuário se exercita.
Microcontrolador
8031 ibutton
Software de
Controle
BD
1-Wire RS232
18
Como o objetivo principal é somente ter uma prova de vida do usuário do sistema, este tipo
de sensor atenderá a necessidade deste projeto.
Ao contrário do ECG que monitora o sinal elétrico gerado pelo coração, este sensor
de batimentos cardíacos monitorará o fluxo de sangue que passa em uma extremidade do
corpo.
A medição realizada pelo sensor é referente ao pulso cardiovascular que é
encontrado através do corpo humano. Este pulso resulta em uma mudança do volume de
sangue arterial durante cada batida do coração. Esta mudança pode ser detectada nas
extremidades do corpo, como os dedos ou a orelha usando uma técnica chamada
fotopletismografia (PPG – Photoplethysmography)[9].
O sensor utilizado tem o formado de “grampo” conforme mostrado na Figura 10, e
deve ser fixado no local onde a medição vai ser realizada. Este sensor possui um LED que
ilumina o tecido, e um LSD (Light Sensitive Diode), um foto receptor que está calibrado
para o mesmo comprimento de onda da cor do LED e, portanto, irá detectar a quantidade
de luz que foi efetivamente transferida através do tecido.
Figura 10 - Sensor de Batimentos Cardíacos
Conforme descrito em [10], a variação de luz recebida pelo LSD será variável
devido a quantidade de sangue que está circulando no momento naquela extremidade, pois
quanto mais sangue na região, mais difratada será a luz, e portanto menos luz será
recebida.
O sensor será utilizado no dedo polegar, como apresentado na Figura 11, pois este
possui uma variação menor nas aquisições, conforme explicado na sessão de
implementação.
19
Figura 11 - Posicionamento do Sensor de Batimentos na mão
A comunicação do sensor se dará através do decodificador Pulse-F, o mesmo
encontrado em projetos microprocessados que utilizam este sensor, pois o decodificador
faz o tratamento analógico do sinal e retorna dados digitai, facilitando o trabalho de
implementação.
20
3 PROJETO
Nesta fase são apresentadas as técnicas que foram selecionadas para o
desenvolvimento deste projeto, tanto em relação ao software quanto ao hardware. São
descritos os conceitos e apresentados os esquemáticos dos circuitos que serão necessários
na fase de implementação. Basicamente o projeto divide-se em duas partes principais, o
projeto do software e o projeto do hardware.
3.1 PROJETO DE SOFTWARE
As partes constituintes do projeto de software envolvem tanto a parte de aquisição e
processamento de imagem, quanto os softwares de controle; como cada um deles deverá
ser implementado, e a razão para cada uma das técnicas escolhidas, visando sempre um
bom desempenho apesar deste não ser requisito primário e facilidade de manutenção no
futuro.
Apesar de o microcontrolador possuir por definição um software, este não será
descrito junto ao projeto de software por estar intimamente ligado ao hardware. Por esta
razão, este será descrito nos tópicos a respeito do projeto de hardware.
3.1.1 Aquisição da Imagem
Para fazer a aquisição da imagem, utilizaremos o conjunto de funções
disponibilizado pela biblioteca Twain.
O Twain Development Kit é gratuito e tem como objetivo padronizar o acesso a
dispositivos de aquisição de imagens, não só scanners, mas câmeras e outros dispositivos
de aquisição. O conjunto de funções utilizados pode ser o mesmo através de uma interface
única conforme mostrado no diagrama de camadas da Figura 12.
O Twain possui três níveis de implementação, sendo que cada uma delas possui um
nível maior ou menor de abstração, permitindo ao usuário ter um controle maior sobre o
dispositivo de captura de imagem. Neste projeto utilizaremos o nível mínimo, onde o
Twain recomenda as melhores configurações para o dispositivo.
21
As mensagens necessárias para realizar a aquisição da imagem estão demonstradas
abaixo, maiores detalhes sobre os parâmetros e as respostas podem ser conseguidas na
especificação oficial da API [20].
Camada de Aplicação Aplicação do usuário
Twain
Camada de Protocolo Source Manager
Twain
Camada de Aquisição Device Driver
Interface
Camada de Dispositivo Dispositivo
Figura 12 - Camadas para aquisição da imagem
Os passos para realizar a aquisição da imagem através do Twain estão descritos
abaixo:
1. Carregar o Source Manager – Esta fase consiste em trazer à memória as
bibliotecas do TWAIN que contém as funções para aquisição de imagens, no
windows isto pode ser feito com a API LoadLibrary e GetProcAddress[21].
2. Abrir o Source Manager – Com o endereço conseguido na etapa anterior, deve ser
criado uma estrutura do tipo TW_IDENTITY para abrir a “conexão” com o
dispositivo, MSG_OPENDSM.
3. Selecionar a Fonte – Para vários dispositivos, deve-se escolher qual deles é o que
estará sendo utilizado, é realizado através da função MSG_USERSELECT.
4. Abrir a fonte – Abre o dispositivo propriamente dito, função MSG_OPENS.
5. Negociar as configurações – Para receber uma imagem comum do dispositivo (o
caso deste projeto), basta pedir a configuração CAPXFERCOUNT, usando a
função MSG_SET.
6. Requisitar a aquisição ao dispositivo – Alguns dispositivos já possuem uma
interface padrão para seleção da imagem, o método MSG_ENABLEDS invoca esta
interface.
7. Reconhecer se a transferência está pronta (ready) – Esta parte é de ação somente
do TWAIN, refere-se a verificação se o dispositivo está pronto para transmitir.
8. Iniciar e realizar a transferência – Realiza a transferência em si, retornando um
ponteiro para uma estrutura TW_IMAGEINFO, que contém a imagem.
22
9. Fechar o dispositivo Fonte – Finaliza a transação, MSGENDXFER,
MSG_DISABLEDS.
O ANEXO 4 mostra como o Twain será utilizado dentro do sistema, sendo que a
principal característica aqui é a de que estes métodos do Twain e das próprias APIs do
windows serão abstraídos dentro de uma classe controladora, que retornará a imagem
através de um único método getimage.
3.1.2 Processamento da Imagem
Para efetuar o cadastro e verificação biométrica do usuário, é necessário um forte
processamento na imagem original adquirida do scanner, visando principalmente
conseguir converter as informações gráficas visuais em parâmetros numéricos que podem
ser utilizados para comparação.
A seguir são apresentados todos os passos necessários para a extração do contorno
da imagem, e na seqüência os métodos de análise do contorno para extração dos dados de
característica.
3.1.2.1 Conversão para Escala de Cinza
A imagem da maneira como é lida contém informações que não serão tratadas pelo
sistema. Uma destas informações são as cores, visto que o sistema identificará somente a
geometria da mão, a cor pode ser descartada, facilitando o processamento, por isso, a
imagem é convertida para escala de cinza.
Para fazer a conversão de uma imagem em cores para escala de cinza, devemos
inicialmente saber como as informações referentes a cores são armazenadas. Utilizaremos
para execução deste trabalho a estrutura RGB (Red Green Blue), onde cada pixel da
imagem é armazenado em espaço de memória de 3 bytes (isso para uma imagem utilizando
16 milhões de cores) e pode ser representado por três funções R(x,y), G(x,y) e B(x,y),
sendo cada um dos bytes para as componentes de cor RGB, o valor em cada um dos bytes
representa a presença, e a quantidade da cor que aparecerá neste pixel, por exemplo, para
termos um “vermelho” puro, basta colocar o valor 255 (valor máximo de amplitude
utilizando a resolução de 1 byte), na componente R do pixel, e 0 nas componentes G e B, o
23
mesmo ocorre para as outras componentes, caso a componente B tenha um valor maior, a
cor resultante será um tom de azul, o mesmo corre com a componente G.
Um pixel em escala de cinza terá sempre as três componentes (R, G e B) com o
mesmo valor (R(x,y) = G(x,y) = B(x,y)), assim o resultante sempre será acinzentado, sendo
que os dois limites são RGB = 0,0,0 para a cor preto, e RGB = 255,255,255 para a cor
branco. Para fazer uma relação entre a imagem colorida e converte-la em escala de cinza,
pode ser feita uma média simples entre os valores de RGB, e setando o valor RGB da
imagem resultado para o valor desta média.
Abaixo segue um algoritmo em pseudocódigo para a conversão de uma imagem
colorida em escala de cinza usando média simples entre as componentes de cor.
Para i de 1 até [Largura da Imagem] Para j de 1 até [Altura da Imagem] ValorMédia = (ValorRPixel(i,j)+ValorGPixel(i,j)+ValorBPixel(i,j))/3;
ValorRPixel(i,j) = ValorMédia; ValorGPixel(i,j) = ValorMédia; ValorBPixel(i,j) = ValorMédia; Fim Para Fim Para
3.1.2.2 Binarização
Entende-se por binarização a operação de converter uma imagem que se encontra
em escalas de cinza para apenas dois níveis (preto e branco). A operação é relativamente
simples, pois basta analisar cada pixel da imagem e verificar se este se encontra acima ou
abaixo de um determinado limite de corte (threshold). Um pixel abaixo deste limite (e,
portanto mais próximo de zero) será convertido para preto (0), enquanto um pixel que
esteja acima do limite será convertido para branco (255).
O problema colocado pela binarização está na seleção deste limite, pois este pode
ser diferente para cada imagem, uma vez que a configuração do scanner utilizado pode
influenciar na distribuição de tons de cinza da imagem.
Abaixo está demonstrado um pseudocódigo para a realização da binarização.
24
Para i de 1 até [Largura da Imagem] Para j de 1 até [Altura da Imagem] Se ValorRPixel(i,j) > [Threshold] então ValorRPixel(i,j) = 255;
ValorGPixel(i,j) = 255; ValorBPixel(i,j) = 255;
Senão ValorRPixel(i,j) = 0;
ValorGPixel(i,j) = 0; ValorBPixel(i,j) = 0;
Fim Se Fim Para Fim Para
A operação de conversão para preto e branco em si é uma operação simples de ser
implementada, mas como descrito acima, depende de um valor para o corte, este valor
pode ser diferente para cada imagem, pois o corte ideal neste caso seria o tom exato que
separa o objeto principal, neste caso a imagem da mão, do fundo, que neste caso terá um
tom único.
Para resolver o problema da seleção de limiar será implementado um método de
seleção automática de limiar, conhecido como “método de limiarização de Otsu” [11]. O
método de Otsu se baseia na informação de que em uma imagem ideal, o histograma dos
níveis de cinza da imagem possui dois grandes grupos de cores distintos, sendo um da
imagem e outro do fundo, através de cálculos baseados principalmente em estatísticas e
probabilidades o método de Otsu encontra o vale entre os “picos” do histograma, que será
um valor aproximado para separar a imagem do fundo.
A Figura 13 mostra uma imagem que poderia ter sido adquirida pelo scanner, já
convertida para escalas de cinza, na Figura 14 é mostrado o histograma dos níveis de cinza
da Figura 13, esta imagem felizmente se encontra no caso padrão, portanto podemos
claramente distinguir os dois “grupos” de cores no histograma, um grupo mais próximo do
preto, e outro mais próximo do branco, utilizando uma implementação do Método de Otsu,
temos o resultado para o limiar de corte ideal, que neste caso tem o valor 150 (representado
pela Linha pontilhada na Figura 14.
A binarização completa utilizando-se o limiar recomendado pelo algoritmo em
questão é mostrada na Figura 15.
25
Figura 13 - Imagem em escala de cinza
Figura 14 - Histograma da imagem em escala de
cinza
Figura 15 - Imagem binarizada
3.1.2.3 Detecção da Bordas
A detecção de bordas e contornos é uma função de suma importância em projetos
que visam reconhecer padrões dentro de imagens, pois a imagem inicial colorida ou até
mesmo em escalas de cinza possui informações que não são úteis ao algoritmo que estará
analisando as características da imagem, neste caso, a informação primordial é o contorno
da mão, informações de variação de cor, e do fundo da imagem devem, portanto, ser
descartadas.
Um algoritmo de detecção de borda aplicado diretamente a uma imagem em escala
de cinza resultaria numa imagem difícil de ser analisada computacionalmente, conforme
mostrado pela Figura 16, a borda é muito complexa pois possui informações sobre a palma
da mão, e outras características que devem ser ignoradas, a extração de características de
uma imagem como esta seria muito complexa matematicamente.
26
Figura 16 - Extração de bordas aplicado diretamente a uma imagem em tons de cinza
Uma solução para este problema está na utilização de uma imagem binarizada,
operação explicada anteriormente, mas resumindo, é a máscara da mão, uma imagem bem
distinta, onde a informação do objeto (a mão) e do fundo da imagem estão bem separadas,
uma imagem em preto e branco.
Dentro da imagem em escalas de cinza, as informações que não serão utilizadas,
como impressões nos dedos e na palma da mão, sujeiras e outras coisas do gênero, estarão
sempre em um tom próximo do resto da mão, isso é facilmente visualizado pela Figura 16,
portanto em uma imagem binarizada, o algoritmo de detecção de bordas resultará
exatamente no contorno da mão, este efeito pode ser observado na Figura 17.
Figura 17 - Detecção de Borda em uma imagem Binarizada
27
Existem diversos algoritmos para fazer a detecção de bordas[12], dos quais
podemos utilizar como exemplo o Método Sobel, o Método Canny, Marr-Hildreth, entre
outros, esta diversidade de métodos que podem ser utilizados, pode inicialmente tomar
muito tempo, pois qual destes métodos será o mais satisfatório? Esta seria uma pergunta
difícil de ser respondida se estivéssemos tentando detectar as bordas direto em uma
imagem em escala de cinza, como a imagem será binarizada, esta função torna-se mais
simples, sem a necessidade de se recorrer a métodos mais poderosos (e mais custosos
computacionalmente).
O contorno na imagem binarizada estará bem definido sendo separado pelo fundo
que estará representado pela cor preta, e pela mão, representada pela cor branca, uma
maneira simples de se detectar a borda é fazer uma comparação entre pixels vizinhos, e
verificar se eles são diferentes, se forem diferentes representam uma borda.
Este método de detecção de borda além de ser de simples implementação, também
proverá o resultado dentro de um tempo razoável, pois a comparação é feita somente entre
dois vizinhos (no algoritmo de sobel por exemplo, cada pixel deve ser calculado com seus
9 vizinhos, realizando duas multiplicações por matrizes 3x3 para cada pixel da imagem).
Abaixo está um algoritmo em pseudo-código representando uma detecção de borda
através da comparação dos vizinhos, o resultado é o mesmo já mostrado Figura 17.
Para i de 1 até [Largura da Imagem]-1 Para j de 1 até [Altura da Imagem]-1 Se ((ValorRPixel(i,j) <> ValorRPixel(i+1,j))
ou (ValorRPixel(i,j) <> ValorRPixel(i,j+1))) então Pixel(i,j) = [Cor Preta]; Senão Pixel(i,j) = [Cor Branca];
Fim Se Fim Para Fim Para
3.1.2.4 Afinamento
A extração de características feita através do contorno do objeto precisa ter
informações coerentes, e apesar de a aplicação do contorno através do vizinho mais
próximo resultar numa imagem aparente ideal, este ainda possui um problema associado.
Antes de podermos retirar informações coerentes da imagem devemos analisar o contorno
que queremos, este deve ser uma linha de 1 pixel de largura em qualquer um de seus
28
pontos, pois assim esta linha pode ser seguida computacionalmente, literalmente como
uma “pista”, como veremos adiante.
O algoritmo que irá extrair as características deve ser capaz de navegar entre
qualquer um destes pixels vizinhos, e para ser capaz de “seguir” este contorno, a imagem
deve ter somente dois pixel vizinhos em qualquer direção. Neste caso em especial isto é
possível, pois estaremos trabalhando somente com o contorno externo da mão.
Considerando que qualquer um dos 8 pontos que contornam um pixel sejam considerados
vizinhos, na detecção de borda utilizada teremos vários pixels. Portanto, a regra de que
somente 1 pixel pode dar continuidade a linha é quebrada.
A Figura 18 mostra parte da imagem cuja borda foi extraída (Figura 17), esta
imagem representa um “zoom” de modo que o detalhe de pixels vizinhos possa ser
visualizado, e podemos notar diversos pixels em que existe mais de um vizinho.
Esta imagem ainda precisa ser tratada antes que possamos retirar as informações, é
necessário retirar o “esqueleto principal” da imagem, um procedimento conhecido como
“Afinamento” (Thinning) [13][14] ou Esqueletonização.
Figura 18 - Zoom de uma parte da imagem onde a borda foi detectada
Novamente existem diversos métodos que podem ser estudados e aplicados, mas a
maioria deles tem objetivos muito mais genéricos. A operação realizada sobre a imagem a
ser afinada pode ser reduzida se for utilizado um algoritmo específico para este caso.
Analisando a Figura 18 podemos ver que existe um padrão na maneira como os pixels
estão relacionados com seus vizinhos. Por se tratar de um contorno direto e fechado, e pelo
contorno ter sido originado a partir de uma imagem binarizada, podemos deduzir que
teremos um conjunto limitado de vizinhos que quebram a regra do esqueleto principal.
29
Estes pontos estão em grupos de quatro pixels, onde numa matriz 2x2, 3 pixels
internos estão na cor preta e temos que a diagonal principal da matriz em um dos dois
sentidos está com valores diferentes, podemos simplesmente igualar estes valores,
tornando a diagonal principal equilibrada, esta conversão pode ser visualizada na Figura
19, onde estão representados os 4 grupos possíveis de pontos a serem afinados.
Figura 19 - Grupos possíveis de pontos que violam o “esqueleto principal”
A Figura 20 mostra o resultado da aplicação deste algoritmo sobre a imagem,
podemos ver que a primeira imagem possui alguns pontos em que mais de um pixel é
vizinho dentro da linha principal, o que já não ocorre na segunda imagem, esta portanto,
pode ser seguida e pode fornecer com sucesso o caminho para a extração das
características.
Figura 20 - Imagem antes do Afinamento e imagem após afinamento
3.1.2.5 Extração do grau de Curvatura
A partir deste ponto existem diversas maneiras de se analisar a imagem para que
sejam identificadas as características individuais desta imagem. Uma metodologia possível
seria simplesmente analisar a imagem tentando identificar os pontos característicos, como
30
tamanho, largura, dos dedos e outros já citados acima. Neste trabalho, utilizaremos uma
técnica que toma o grau de curvatura entre pontos da imagem como característica
principal.
Detectando-se os pontos de maior grau de curvatura dentro de uma imagem
podemos identificar um objeto em especial dentro de uma imagem [15]. No caso deste
trabalho especificamente, estaremos identificando imagens de mãos, sendo que cada uma
delas possuirá características individuais, capazes de serem distinguidas dentro de um
conjunto de outras imagens. Estas características são representadas pelos locais de maior
grau de curvatura, como as pontas dos dedos, os vales entre os dedos e as curvas do
contorno da mão em geral.
Para calcularmos os pontos de maior curvatura existem diversas técnicas, que
podem ser conferidas em [16] e [17]. Dentre estas técnicas escolhemos uma em especial
para ser utilizada, conhecida como DOS (Difference of Slopes), principalmente pela sua
simplicidade e fácil implementação.
O método DOS consiste basicamente em percorrer o contorno da imagem com dois
vetores de mesmo tamanho, e calcular o ângulo formado entre estes vetores. A Figura 21
mostra como isso ocorre em uma curva qualquer. Os dois vetores V1 e V2 possuem o
mesmo tamanho, e devem ficar em seqüência um do outro, V1’ representa a propagação de
V1, de modo que existe um ângulo entre V1’ e V2. A extração da curvatura pode ser
descrita como encontrar todos os ângulos θ entre vetores, para todos os pixels da imagem,
ou seja, colocar V1 no primeiro pixel do contorno, calcular θ, deslocar V1 em um pixel (e
conseqüentemente deslocar V2 também) encontrar o novo θ, todos os θ encontrados
representam toda a curva do contorno do objeto.
Figura 21 - Aplicação do DOS sobre uma curva qualquer
V2
V1
V1’ θ V2
V1V1’
θ
31
Figura 22 - Cálculo do ângulo entre os vetores.
A Figura 22 mostra a representação geométrica dos vetores no plano cartesiano,
considerando o inicio dos vetores na origem dos eixos, deste modo, podemos calcular os
valores de α, β e θ simplesmente aplicando regras simples de trigonometria.
Temos que α é o ângulo entre V1’ e o eixo x, β o ângulo entre V2 e o eixo x, e θ o
ângulo que queremos, que o ângulo formado entre V1’ e V2.
O valor de α pode ser encontrado utilizando-se a relação do triangulo formado pela
origem e o ponto final de V1’, trabalhando com um triângulo retângulo podemos utilizar a
relação que o ângulo entre a hipotenusa do triangulo forma com os catetos como se segue:
α = Arctg( Cateto Oposto / Cateto Adjacente)
O cateto oposto é a própria altura do ponto final de V1’, a mesma relação pode ser
utilizada com V2, com isso teremos o valor de β. O valor de θ pode então ser facilmente
calculado, pois este será a diferença entre β e α. Como dito anteriormente, este cálculo
deve ser realizado para todo o contorno da mão, resultando em um gráfico que poderá
então ser analisado.
Existe algumas peculiaridades[18] com relação a este método de cálculo de
curvatura, como por exemplo a mudança do quadrante referente ao arco-tangente, que pode
gerar variações abruptas dentro do gráfico de curvatura, e conseqüentemente prejudicará
qualquer análise posterior. Para estes casos é feito um tratamento a parte, analisando-se
qual a direção e sentido de cada um dos vetores, e se necessário invertendo os operandos
V1’
V2
x
y
b
aθ
βα
32
na subtração, podendo ainda, ser acrescentado um valor de ajuste para melhorar o
resultado.
O método DOS trabalha com dois vetores de tamanho definidos, podendo ainda ter
um conjunto de pixels que serão saltados entre os vetores (chamado por alguns
pesquisadores de método DOS+). O tamanho dos vetores, e o tamanho do espaço entre os
vetores é calculado heuristicamente, pois deve ser adaptado a cada problema em que o
método é utilizado[18]. É impossível ter uma definição de quais são os valores ideais para
o reconhecimento de geometria da mão neste ponto de projeto, pois os dados práticos que
possuímos ainda são pequenos, estes valores serão definidos na fase de implementação
após o desenvolvimento de uma base de dados com uma quantidade de usuários suficientes
para uma análise precisa.
Os dados da diferença de curvatura em todo o contorno da mão, irá gerar uma
imagem como a da Figura 23, onde cada ponto determina o ângulo formado pelos vetores
naquele ponto.
Podemos notar que o gráfico gerado tem uma característica bem interessante pois
os pontos com maior grau de curvatura representam exatamente os as pontas dos dedos,
mais especificamente, a curva formada pela ponta dos dedos, enquanto o “comprimento”
do dedo em si tem uma variação de curvatura baixíssima ficando próximo do zero.
Isto fica mais claro quando visualizamos a Figura 24, pois esta representa a imagem
da mão afinada, com os pontos de maior curvatura colocados em detalhe. Cada ponto no
gráfico representa um pixel na imagem da mão, portanto o comprimento do “circuito”
fechado compreendido pelo contorno da mão é igual ao comprimento do eixo “x” do
gráfico, de modo que podemos saber exatamente quais pontos no gráfico referenciam
determinados pontos na imagem.
33
Figura 23 - Gráfico de diferença de Curvatura
Figura 24 - Imagem com destaque nos pontos de maior curvatura
3.1.2.6 Extração de Características
As características que precisam ser extraídas variam de sistema a sistema. Neste
sistema, estaremos utilizando 10 medidas, um valor que não é alto, reduzindo o nível de
individualidade, mas ainda assim, proporcionando um grau aceitável de segurança.
As 10 medidas são basicamente o comprimento de cada um dos 5 dedos da mão e a
largura média destes dedos. Com isso, estabelecemos uma restrição do sistema, a mão do
usuário deverá ter os 5 dedos, ou ao menos parte de cada um dos 5 dedos para ser
considerado um usuário válido.
34
O comprimento dos dedos será obtido diretamente do gráfico resultante do DOS,
pois o comprimento de um dedo é a distancia percorrida entre dois picos de maior
variação, que seria a ponta do dedo e o vale entre dois dedos.
Já a largura não pode ser adquirida diretamente do gráfico do DOS, portanto
teremos que voltar à imagem que originou os dados. Pelos picos do gráfico, podemos
estimar a posição do dedo e na imagem podemos conseguir a largura do dedo traçando
uma reta perpendicular a curva do contorno do dedo até o outro lado do dedo, variando
isso através de toda a distância entre dois picos do gráfico, teremos conseguido, desta
forma, percorrer todo o dedo, de onde podemos conseguir a largura média.
É necessária uma análise completa do gráfico de curvatura para conseguir extrair
com certa precisão as características biométricas. Podemos claramente notar os picos no
gráfico, que representam os pontos de maior curvatura. Aqui temos outra característica do
DOS, pois a curvatura não é calculada exatamente no ponto de curvatura[18], mas sim
levemente deslocada devido ao cálculo realizado com vetores, e também do espaço
utilizado entre os vetores, felizmente esta característica do método não será um problema
para os objetivos que pretendemos alcançar pois esta variação estará presente em todas as
aquisições e será aproximadamente a mesma (o deslocamento do grau de curvatura será
constante ou muito próximo), de modo que não irá interferir na comparação das imagens.
Analisando um gráfico resultante do DOS, podemos notar os diversos pontos de
alta curvatura detectados. O cálculo da curvatura é iniciado a partir da parte inferior da
mão, seguindo então no sentido anti-horário (características desta implementação), a
Figura 25 mostra alguns picos em cinza, referentes a um dedo em especial, os pontos de
alta curvatura que estão em cinza são os mesmos marcados na Figura 26.
Figura 25 - Gráfico de curvatura da mão com marcação de um dedo
35
Os pontos de alta curvatura iniciam-se no pixel 479 no exemplo, marcado como
ponto 1 na Figura 26. Seguindo até o próximo pico, temos o comprimento percorrido da
base até a ponta do dedo. Com a ponta se encontrando no pixel 596 e obtendo o
comprimento deste lado como de 596-479=117 pixels. Esperamos que no lado oposto
tenhamos um comprimento muito próximo pois o próximo pico se encontra em 615 (ponto
3 na Figura 26) e o ponto 4 se encontra em 728, temos que 728-615=113.
Podemos dizer que o comprimento lateral do dedo é aproximadamente a média
destas distâncias, (117+113)/2=115.
Podemos ver que houve uma variação de alguns pontos no tamanho de cada lado, o
que já era de se esperar, pois a curvatura do dedo é diferente e cada pessoa terá o
comprimento lateral do seu próprio dedo variando. Isto faz parte da característica
biométrica da mão do usuário, e não será suficiente para influir no reconhecimento.
Figura 26 - Contorno da mão com marcação nos pontos ressaltados na Figura 25
Além da informação dos comprimentos laterais para cada dedo, temos também que
encontrar as informações referentes à largura média para cada dedo. O cálculo que fizemos
agora para o comprimento será muito útil nesta parte pois temos agora a restrição do
1
23
4
36
comprimento do dedo, sabemos que o cálculo da curvatura ocorrerá somente dentro da
faixa especificada pelo comprimento lateral de cada dedo.
Retomando o exemplo anterior, temos que o dedo em si se encontra dentro da faixa
de 479 e 596, portanto a varredura se dará nestes 117 pixels, mas não analisaremos o
gráfico, e sim a imagem do contorno da mão.
Percorreremos cada um dos pixels compreendidos entre 479 e 596 na imagem do
contorno da mão, e para cada pixel, traçaremos um vetor sobre o contorno do dedo,
traçaremos então um segundo vetor, perpendicular a este primeiro, que irá se prolongar até
encontrar o outro lado do dedo, o que pode ser visualizado na Figura 27. A área de busca
será delimitada pelos pixels de inicio e fim de cada um dos lados da imagem, evitando que
o vetor seja prolongado para uma área em que não exista um lado oposto.
Figura 27 - Cálculo da largura do dedo
Pela Figura 27, temos diversas larguras para o mesmo dedo, das quais calcularemos
a média para resultar o valor médio da largura do dedo.
3.1.2.7 Geração do BioCode
Entende-se por biocode o código numérico utilizado para persistir as informações a
respeito das características de uma determinada chave biométrica. A quantidade de dados
que será persistida no biocode representará a quantidade de informações que realmente
serão utilizadas na verificação dos dados.
37
No caso deste projeto as informações serão o tamanho e largura dos dedos, portanto
o biocode será relativamente pequeno, podendo este ser armazenado em uma string dentro
do banco de dados, junto com as outras informações do usuário.
O biocode será o dado padrão da imagem, explicado no tópico sobre cadastro dos
usuários, este padrão além das informações de medidas da mão, conterá também a
informação da variabilidade que esta apresentou durante as aquisições, a variabilidade
deverá ser próxima a zero, pois geometria da mão será a mesma. Os dados armazenados no
biocode e o tamanho reservado para eles são:
• Comprimento para cada um dos dedos (2 Bytes)
• Variação de comprimento (1 Byte)
• Largura média para cada um dos dedos (2 Bytes)
• Variação de Largura (1 Byte)
Com isso temos que o tamanho referente a cada dedo no biocode representará 6
Bytes, sendo o tamanho total de cada biocode de 30 Bytes.
A variação máxima permitida só pode ser afirmada com certeza depois de alguns
experimentos práticos, o que ainda não é possível no momento, esperamos que a variação
seja próxima de zero, conforme dito anteriormente mas devido a diferenças ocasionadas
pela resolução da imagem, e do próprio método DOS, podemos ter um pequeno percentual
de diferença que deve ser aceito.
3.1.3 Sistema de Cadastro
O software de controle consiste basicamente na parte do sistema responsável por
cadastrar os usuários no Banco de Dados e atribuir as permissões a estes usuários, de modo
que se tenha a informação de quais usuários podem acessar quais áreas em determinado
momento.
3.1.3.1 Cadastro do Usuário
O cadastro do usuário é uma parte relativamente simples que consiste no
cadastramento das informações pessoais do usuário em si, assim como os dados
38
necessários para que seja possível fazer a identificação deste usuário com base na imagem
da sua mão.
Toda a parte de pré-processamento da imagem já descrita anteriormente também
estará presente nesta fase, visto que neste ponto serão gerados os dados do “padrão”
estabelecido para o usuário. Este padrão nada mais é do que várias aquisições da mesma
imagem, sendo que cada uma delas será analisada e uma “média” dos dados será calculada,
estabelecendo certos limites de variação apresentados pelo usuário. Uma vez tendo o
padrão, seus valores e seus limites são confrontados com cada um dos candidatos, e o
candidato só será aceito se estiver dentro dos limites estabelecidos.
Quando tratamos de biometria física, a variação de medidas de um mesmo sujeito
tem pouca variabilidade, diferentemente de biometrias comportamentais (voz, assinatura),
onde o mesmo individuo pode causar uma variação no seu próprio valor biométrico. Em
biometria comportamental, o número de amostras para um mesmo usuário deve ser grande,
pois assim tem-se uma base que demonstre as variações causadas no usuário por fatores
externos, como ruídos e erros da aquisição.
Neste projeto, onde utilizamos a biometria física da geometria da mão, a variação
deve ser muito pequena, de forma que a razão da utilização de diversas medições e geração
de dados padrão para o usuário existe para evitar possíveis utilizações incorretas do
sistema ou problemas ocasionados devido a fatores externos, ou ainda diferenças
ocasionadas pelo próprio método de pré-tratamento e filtragem de ruídos. Por esta razão o
número de aquisições pode ser reduzido, já que a geometria da mão possuirá pequeno grau
de variabilidade nas diversas medidas. A variação ideal será igual a zero, utilizaremos
neste projeto um total de três aquisições, pois com isto será possível obter os dados do
usuário em si e evitar problemas devido à aquisição.
3.1.3.2 Verificação do Acesso
O sistema terá duas divisões principais, definidas basicamente pelo tipo de usuário,
onde um é o administrador, capaz de realizar o cadastro de um usuário e o outro é o
usuário em si, que fará a tentativa de acesso ao sistema, isto fica bem definido no diagrama
de casos de uso apresentado no ANEXO 2.
39
Esta divisão não irá influenciar ou ser influenciada pelo processamento da imagem,
visto que as duas partes do software deverão fazer a conversão da imagem em dados
numéricos que possam ser comparados, com isso podemos estabelecer as classes do
sistema, que estão demonstradas no diagrama de classes no ANEXO 3, a maneira como
estas classes serão utilizadas para fazer o cadastro no sistema está demonstrada no
diagrama de seqüência do ANEXO 6, neste diagrama vemos que antes de ler o código do
ibutton o software envia um byte a serial, que representa a informação que o software quer
ler.
O byte a ser enviado é parte do protocolo de comunicação estabelecido entre o
software e o sistema com o 8031, que tem as mensagens conforme definido na Tabela 2.
Código Direção Descrição Tam. da msg 01h PC 8031 Requisição de Código de iButton 1 bytes 02h PC 8031 Requisição da confirmação dos Bat. 1 byte 03h PC 8031 Código do iButton, serão zeros se
nenhum iButton estiver no leitor 8 bytes
04h PC 8031 Identificação do Bat. Cardíaco. FFh para sinal OK, e 55h caso o sinal não seja identificado
2 bytes
05h PC 8031 Liberar Acesso 1 byte Tabela 2 - Protocolo de comunicação entre software e 8031
A verificação do acesso é a parte que será mais utilizada pelos usuários do sistema,
pois se refere a uma tentativa de acesso a um determinado ambiente. Para este acesso ser
bem sucedido ele deverá respeitar a diversos fatores:
• O iButton deve ter sido lido de modo correto, para que o seu código de identificação
possa ser pesquisado na base de dados (e obviamente, este código deve estar
associado a algum usuário nesta base).
• A imagem scaneada da mão deverá resultar em um biocode compatível com o padrão
no banco de dados, o que acontecerá se a mão do usuário realizando a tentativa for
realmente a mesma mão de quem fez o cadastro no sistema.
• E por último, o sinal do batimento cardíaco da pessoa deve representar um sinal vital
válido, esta verificação será feita contando os batimentos cardíacos por minuto, que
deverão estar dentro da faixa de 50-150 BPM.
40
A contagem dos batimentos será feita pelo hardware com 8051, resultando em uma
entrada booleana indicando se este sinal é válido ou não, o mesmo ocorre com o iButton, o
software propriamente só consultará o código no banco de dados, pois receberá o valor lido
via porta serial. Toda a parte de verificação do acesso pode ser vista com maior facilidade
no diagrama de seqüência do ANEXO 8.
3.1.3.3 Base de Dados
O gerenciador de bancos de dados utilizado inicialmente será o Microsoft Access,
devido a sua facilidade de utilização, a facilidade de instalação e sua distribuição, uma vez
que toda a máquina que tenha o pacote do Microsoft Office instalado terá o Microsoft
access. O gerenciador de bancos de dados não irá influir no desempenho da pesquisa, pois
a informação do padrão será convertida em um código numérico, conhecido como biocode.
Todas as consultas dentro do sistema serão feitas utilizando-se comandos do padrão
ANSI da linguagem SQL, de modo que se o SGBD (Sistema Gerenciador de Bancos de
Dados) for trocado, nenhuma consulta dentro do sistema precise ser modificada, estaremos
utilizando para o acesso ao banco de dados os componentes do ADO (Activex Data
Objects) da Microsoft, este é um conjunto de objetos que facilita a utilização do banco de
dados fornecendo classes universais para o acesso a qualquer SGBD, a configuração é feita
com o provider, que contém as informações para o acesso a cada tipo de base de dados.
Dentro do sistema o provider é somente uma string qualquer, e pode facilmente ser
alterado, portanto a utilização do ADO juntamente com SQLs no padrão ANSI, torna este
sistema facilmente portável para qualquer outro SGBD que respeite os estes padrões.
Como existe somente um tipo de dado a ser armazenado, que são as informações
referentes ao usuário, uma tabela suprirá as necessidades de persistência do sistema. A
Tabela 3 mostra os campos que serão armazenados na tabela de usuários.
41
Campo Tipo TamanhoidUsuario Inteiro 2IdIbutton Binário 8strNome String 255dtNasc Data 4strEnd String 255strFone String 14strEmail String 30
strBioCode String 30Tabela 3 - Campos da tabela de usuários no Banco de Dados
Na implementação do sistema, o Banco de dados será abstraído por uma classe
cDatabaseController, que fará todas as ações necessárias para persistir e carregar usuários
o Banco, isto pode ser visualizado no Diagrama de Classes do ANEXO 3.
3.1.4 PROTÓTIPO DE TELAS
Neste capítulo são apresentadas as telas montadas para a utilização do sistema. O
sistema possui basicamente 5 telas principais, a tela de login, tela de Auto-Check, tela de
testes, tela de cadastro e tela de verificação. Cada uma delas é apresentada com maiores
detalhes na seqüência.
3.1.4.1 Tela de Login
Para fazer o cadastro de usuários no sistema é necessário antes fornecer uma senha
de administrador, que será entrada na tela mostrada na Figura 28.
A senha será configurada diretamente no banco de dados, de modo que qualquer
usuário de fora do sistema não consiga alterar os registros utilizando o Access.
Figura 28 - Tela de Login
42
3.1.4.2 Tela de Auto Check do sistema
Ao iniciar, automaticamente o sistema realizará um auto check-up para verificar se
todos os módulos necessários para seu funcionamento estão funcionais, mostrando ao
usuário a progressão deste teste e o seu resultado.
Os parâmetros testados são:
• Dispositivo de Aquisição: Verifica a existência o Twain Driver instalado e
operacional na máquina.
• Sistema Microprocessado: Procura pela placa microprocessada com 8031
nas portas de comunicação COM1 e COM2 (a comunicação será feita
automaticamente na porta identificada), verificando se ela está presente e
funcional.
• Banco de Dados: Verifica a existência do DSN “pFinal” e se é possível
realizar consulta e atualizações na tabela do sistema.
Os ícones indicadores de funcionalidade de cada módulo podem ser vistos na
Figura 29.
Figura 29 - Tela de check-up dos módulos do sistema
Caso existam problemas em qualquer um dos módulos do sistema, a inicialização
resultará em falha. Uma mensagem será mostrada ao usuário indicando que o sistema não
está em condições perfeitas de uso, mas a priori, o sistema não será bloqueado e mesmo
com algum módulo falho, outros módulos poderão ser utilizados.
43
3.1.4.3 Tela de Cadastro de Usuários
A tela de cadastro disponibilizará uma lista com todos os usuários cadastrados, esta
lista será implementada através de um DBList da Borland, integrando os objetos do
formulário a um objeto Data Source, a vantagem em se utilizar tais objetos é que permitem
um nível alto de abstração e são implementados usando-se práticas de programação
otimizadas para bibliotecas já existentes.
Nesta tela será mostrado um conjunto de 4 imagens, que não serão armazenadas no
banco de dados, estas imagens são utilizadas somente para a geração do código biométrico.
Ainda será mostrado um gráfico de dispersão com o biocode dos usuários, de modo
que seja possível verificar a existência de sobreposições no momento do cadastro, na
prática esta informação só deve ser disponibilizada para os administradores, pois os
usuários não devem saber quais os usuários podem se passar por eles.
A Figura 30 mostra a implementação da tela como descrita acima.
Figura 30 - Tela de cadastro de usuários
44
3.1.4.4 Tela de Testes de Algoritmos
Nesta tela podemos ver cada um dos algoritmos utilizados funcionando
separadamente de modo a analisarmos o seu resultado, esta tela não será acessível aos
usuários.
A Figura 31 mostra a tela, onde além de testar os algoritmos com os valores
padrões usados pelo sistema, é possível alterá-los de modo a achar o melhor resultado.
Figura 31 - Tela de testes de algoritmos
45
3.1.4.5 Tela inicial do sistema
Após a verificação dos módulos, o sistema entrará numa tela de seleção dos
módulos. Esta tela é mostrada na Figura 32. Módulos funcionais, como verificação e
Cadastro, e também módulos de testes serão disponibilizados aos usuários.
Figura 32 - Tela de seleção de módulos
3.1.4.6 Tela de verificação
A tela de verificação é onde o usuário irá conferir se a sua mão confere com os
dados biométricos de uma pessoa no banco de dados.
Possuirá um local para entrada do código do ibutton e um botão que realizará a
leitura do código da placa microprocessada, este código é então pesquisado no banco de
dados, e o preenchimento dos outros campos é feito com os dados lidos.
Para o candidato será disponibilizada uma leitura de imagem, que será a mão para
conferência com o biocode do banco de dados. Como existe ainda a necessidade de
verificar a existência de batimentos cardíacos, um indicador de que o coração está batendo
será mostrado, este possuirá dois valores, a contagem de batimentos cardíacos do minuto
46
atual, e do minuto anterior, uma destas precisará ser maior do que 50 para que o batimento
seja considerado válido.
Também será mostrado um gráfico de dispersão onde um círculo representa o
“alvo” a ser atingido e seu raio a faixa de usuários válidos para verificação, e um “x”
marca a posição atingida pela imagem lida no momento. Para validar o acesso será
necessário que o “x” se encontre dentro do círculo.
Uma mensagem indicando se o acesso foi permitido ou negado é mostrado no canto
inferior direito.
Figura 33 - Tela de verificação
3.2 PROJETO DE HARDWARE
Neste capítulo estaremos discutindo a respeito de toda a parte de Hardware
necessária para o funcionamento pleno deste projeto, isto inclui a leitura do iButton em seu
receptáculo, o interfaceamento entre o iButton e a placa microprocessada e entre a placa
microprocessada e o computador.
Além disso, como comentado no capítulo sobre o Projeto de Software, estaremos
discutindo o Software utilizado no Microprocessador 8031, pois este tem maior relação
com a parte de Hardware em si, do que com a parte de processamento de imagem.
47
3.2.1 Sistema de Leitura do iButton
Esta parte do projeto visa descrever o funcionamento do sistema de leitura do
iButton, que envolve desde o momento em que o iButton é colocado no receptáculo,
passando pela leitura através do protocolo 1-wire, finalizando com o envio do código do
iButton ao software no PC utilizando-se da porta serial para esta tarefa.
3.2.1.1 Receptáculo de Leitura
O receptáculo para leitura do iButton é uma parte relativamente simples e necessita
de somente dois fios para a conexão. Um deles é o fio terra, referência entre todo o
sistema, e portanto o mesmo da placa microprocessada; o outro se refere a linha de dados
que será conectado a porta P1.0 do Microcontrolador 8031. Conforme explicado na fase de
especificação, o iButton necessita somente de uma linha devido ao seu protocolo 1-Wire
que trabalha com janelas de tempo de leitura e janelas de escrita
Para a aplicação que estamos utilizando, é necessário um resistor de pullup[8][19]
para garantir que a tensão no nível lógico seja 5V.
Os iButtons trabalham com tensões que podem variar entre 2,8 V e 6 V, onde
qualquer tensão acima de 2,2V será interpretada como nível lógico 1, e tensões abaixo de
0,8V serão interpretadas como nível lógico zero. Esta restrição de 2,8 V é necessária para
recarregar o capacitor interno do iButton que supre a necessidade de alimentação para o
iButton quando o meio estiver em nível baixo. O valor do capacitor é algo em torno de 800
pF.
A Figura 34 mostra o circuito para a leitura do iButton conforme especificações
recomendadas pelo fabricante[7]. Um resistor de pullup de 22KΩ mantém a tensão em 5V
quando o nível da linha for 1. A porta P1.1 contém um LED que indicará quando um
iButton está posicionado no receptáculo.
48
Figura 34 - Circuito para de leitura do iButton
3.2.1.2 Programa de Leitura
O procedimento para leitura do iButton deve ser iniciado logo que um iButton seja
colocado no receptáculo de leitura, existe um conjunto de comandos que deve ser
executado para que esta leitura seja realizada[8][19].
Inicialmente envia-se um comando de reset para o iButton, definindo que o
processo de leitura será iniciado.
O pulso de reset provê a sincronização do iButton com o sistema mestre. É definido
como um pulso baixo de duração 480 µs seguido de um pulso alto, também com duração
de 480 µs. O iButton irá detectar o comando de reset e aguardará um intervalo de 30 µs
quando então irá gerar um pulso de presença de duração de 120 µs.
O procedimento de leitura pelo 8031 é feito através de janelas de leitura do iButton.
O microcontrolador altera o nível da linha e o iButton gerará uma alteração na mesma linha
em resposta ao estímulo do microcontrolador. O 8031 deve colocar a linha em nível lógico
1 por um período máximo de 15 µs. Caso a resposta do iButton seja 1, o mesmo mantérá
linha no mesmo nível, enquanto que se a resposta for zero iButton irá colocar a linha em
nível baixo por 15 µs. Durante estes 15 µs após o tempo em que o mestre colocou a linha
em nível alto, este poderá re-ler o valor na linha, que estará lendo a resposta do iButton ao
estímulo. Repetindo estes passos iterativamente, o iButton enviará respostas relativas a
cada um dos seus 64 bits, de modo que podem então ser verificados pelo microcontrolador
através do cálculo do CRC.
49
Um fluxograma para o programa do 8031 que fará a leitura do iButton pode ser
visualizado na Figura 35.
O microcontrolador repetirá o procedimento armazenando em sua memória interna
o valor dos bytes lidos. Após a leitura completa dos 8 bytes, cada byte será enviado através
da serial, precedidos pelo byte de cabeçalho conforme especificado no protocolo.
Figura 35 – Fluxograma do programa para leitura do iButton
50
3.2.2 Sistema de Identificação dos Batimentos Cardíacos
O sistema para identificação dos batimentos cardíacos se baseia no sensor de
fotopletismografia. Conforme comentado na especificação, este sensor funciona enviando
um sinal luminoso através de um LED e recebendo o mesmo com um fotodiodo. A tensão
de saída do LSD terá uma variação de acordo com o volume de sangue que se encontra
entre o emissor e o receptor.
Valores de batimentos aceitáveis para um ser humano estão entre 50-150 BPM.
Para fazer esta contagem será utilizada uma interrupção do 8031, pois como a freqüência
de batimentos é baixa (1-5Hz) quando comparada às freqüências do sistema (12MHz), não
irá causar problemas no processamento, como o bloqueio devido a contínuas interrupções.
Para fazer a decodificação do sinal analógico que resulta do sensor devido a
variação do volume do dedo, será utilizada um módulo Pulse-F, cuja função é retornar um
pulso digital sempre que um batimento é detectado.
Este módulo trabalha com uma tensão de alimentação de 1,2V, sendo necessário
um divisor de tensão, e para casamento das impedâncias um amplificador operacional
configurado como buffer.
O módulo gera para o sensor uma onda quadrada de 1,03 KHz, e durante este pulso
o sensor irá gerar uma resposta analógica equivalente à luz refratada no dedo com o
volume corrente, princípio da fotopletismografia.
Figura 36 - Onda real de funcionamento do sensor de batimentos cardíacos
51
Esta variação tem um comportamento periódico, analisando somente os pontos
amostrados da onda de resposta do qual podemos obter uma onda como a da Figura 37-A.
O período desta onda é variável, até mesmo em uma pessoa sadia em repouso[9], já a
amplitude deste sinal terá uma variação pequena, pois o volume de sangue que passa pelo
vaso sanguíneo é sempre muito próximo. E, mesmo entre indivíduos diferentes, a variação
de amplitude é pequena. Por esta razão podemos utilizar um determinado limite na
amplitude, cuja variação estabelece um batimento cardíaco.
O módulo pulse-F fará o tratamento desta onda de modo que teremos como
resposta um sinal digital, como mostrado pela Figura 37-B.
Figura 37 - Onda resultante do sensor devido a variação do volume de sangue
O sinal digital será conectado diretamente a interrupção do 8031. A cada chamada,
um incremento é feito no registrador de batimentos. O valor deste registrador é reiniciado a
cada minuto e, desta forma, em cada minuto teremos o valor dos batimentos no minuto
anterior
A Figura 38 mostra um circuito para implementação dos batimentos com o módulo
pulse-F, mais dois amplificadores. O primeiro pela alta impedância de saída, e o segundo
para amplificar o sinal que estará na faixa de 1,2 V para um nível que seja aceito na porta
TTL do 8031.
A
B
t
t
V
52
Figura 38 - Circuito para tratamento dos batimentos cardíacos
3.2.3 Software de Integração (8031)
O software que fará a integração do sensor de batimentos cardíacos e será
responsável por realizar a leitura do iButton será desenvolvido em assembly e ficará no
microcontrolador 8031. Este sistema irá se comunicar com o software do PC através da
interface serial RS-232.
O software “conversará” com o PC utilizando-se do protocolo definido na Tabela 2.
Como o software fará a leitura dos iButtons, é necessário ter noção completa de quanto
tempo cada instrução leva para ser processada no 8031, pois os tempos do iButton são
cruciais para uma leitura correta. O tempo de cada instrução pode ser encontrado em
manuais e em livros a respeito do 8031, como por exemplo em [23] .
53
Figura 39 - Fluxograma do software do 8031
A leitura do iButton após realizada será simplesmente enviada pela serial com um
cabeçalho de mensagem, já a parte de batimentos cardíacos, a cada overflow do contador
no circuitos será enviado um sinal de interrupção na INT1, o 8031 processará o valor
recebido na porta P2.0-P2.3 somando-o com um valor que já esteja na memória do 8031. O
Timer1 do 8031 será configurado para colocar zero nesta posição de memória a cada 60s,
de modo que possamos ter os batimentos por minuto do usuário.
54
3.3 CRONOGRAMA DO PROJETO
O cronograma do projeto foi definido inicialmente com base no Manual de Projeto
Final 2003 cedido no inicio do ano, onde os deadlines para as fases de Proposta,
Especificação, Projeto e Validação já estão definidas, portanto subdividimos alguns
módulos e colocamos o tempo esperado para sua realização, o cronograma é visto na
Tabela 4.
Mês Fev Mar Abr Mai Jun Semana S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Proposta Especificação
Projeto Reconhecimento Biométrico
Aquisição de Imagens Cadastro do Usuário
Leitura do iButton Detecção de Batimentos Cardíacos
Consolidação dos Módulos Documentação Final
Testes e Validação do Projeto
Mês Jul Ago Set Out Nov Semana S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4 S1 S2 S3 S4
Proposta Especificação
Projeto Reconhecimento Biométrico
Aquisição de Imagens Cadastro do Usuário
Leitura do iButton Detecção de Batimentos Cardíacos
Consolidação dos Módulos Documentação Final
Testes e Correções Defesa Final
Prioridade 1
Prioridade 2
Tabela 4 - Cronograma do Projeto
55
3.4 ESTIMATIVA DE CUSTOS
Os custos do projeto foram estimados com base em pesquisa de mercado dos valores
atuais dos produtos utilizados, estes valores não refletem os menores valores do mercado,
mas sim os valores encontrados em nossa pesquisa, visto que muitos destes softwares
foram utilizados dentro das dependências da universidade e portanto não agregaram valor
real ao desenvolvimento do projeto, mas a estimativa em si considera todos os gastos para
reproduzir o desenvolvimento aqui descrito.
A Tabela 5 mostra o investimento necessário para o desenvolvimento deste projeto,
considerando somente os softwares e hardwares utilizados para o funcionamento pleno do
sistema, não sendo considerado os equipamentos de análise como osciloscópio, fonte,
multímetro, entre outros, pois estes são de suma importância para realização da
implementação.
Recurso Quantidade Investimento (R$)Microsoft Windows XP Professional 1 1.262,00Borland C++ Builder 5 1 350,00Kit UnicenP Desenvolvimento 8051 1 75,00Scanner Hewlet Packard ScanJet 6300J 1 1.500,00IButtons 2 15,00Sensor de Batimentos Cardíacos 1 15,00Computador Pessoal Intel Celeron 1.3 Ghz 1 1.800,00Fechadura elétrica 1 75,00Componentes eletrônicos 1 50,00Horas de Desenvolvimento 450 11.250,00Total 16.392,00
Tabela 5 – Estimativa de Custos
Existem ainda recursos que são necessários mais não possuem custo, é o caso da
biblioteca de acesso a banco de dados MDAC (Microsoft Data Access Components) que é
distribuída junto com o sistema operacional Windows, ou pode ser baixado no site da
microsoft (www.microsoft.com) , o mesmo ocorre com a biblioteca TWAIN, que deve ser
conseguida através do site (www.twain.org).
Outra observação a ser feita é com relação a fechadura elétrica, pois para um sistema
completamente funcional ela é uma ferramenta chave, que neste projeto será simulada com
um LED indicando a abertura da porta.
56
3.5 PLATAFORMA DE DESENVOLVIMENTO
Descreveremos aqui as necessidades para desenvolvimento deste projeto, lembrando
que alguns dos softwares e hardwares foram escolhidos pela familiaridade do
desenvolvedor com as ferramentas, principalmente devido a utilização durante o período
de graduação. Neste caso, estas podem não ser as melhores ferramentas disponíveis no
mercado, entretanto atendem as necessidades para realização deste projeto.
O ambiente de desenvolvimento é constituído basicamente por:
• Computador Celeron 1Ghz, 128 MB Ram
• Sistema Operacional Microsoft Windows 2000 BR
• Borland C++ Builder 5
• OrCAD Release 9.1
• Visual Paradigm UML (free – community edition)
• Inno Setup 4.0 Install wizard (free)
• MultiSim 2001
• Kit UnicenP Desenvolvimento 8051
• Scanner Hewlet Packard ScanJet 6300J
• Microsoft Office 97
• Microsoft Data Access Components
• TWAIN Development Kit
• 2 iButtons
• Sensor de Batimentos Cardíacos
Apesar de não estar explícito acima, foram utilizados diversos outros equipamentos
para análise e auxílio, como osciloscópio, multímetros entre outros.
3.6 PROTOCOLO DE TESTES E VALIDAÇÃO
O protocolo de testes e validação define as regras a serem seguidas para garantir a
completude dos objetivos definidos no início deste projeto, em outras palavras, faz a
validação do funcionamento do sistema.
A validação será feita em cada um dos módulos parcialmente, e em seguida, no
sistema completo. Neste ponto, separamos o sistema nos módulos a serem validados, que
57
serão o Sistema de Reconhecimento Biométrico, Sistema de Cadastro, Sistema de Leitura
do iButton e Sistema de Detecção de batimentos Cardíacos.
3.6.1 Módulo de Reconhecimento Biométrico
Este módulo consiste no reconhecimento de uma imagem, tendo como resposta um
valor binário indicando se duas imagens são da mesma pessoa ou não.
O teste de validação para este módulo será realizado com quatro imagens para
geração do padrão, e uma quinta para verificação. Adquiridas no padrão especificado por
este trabalho, salvas no disco rígido e que não sejam recusadas pelo sistema. A validação
dá-se somente pelas funções do sistema que fazem o pré-processamento, extração de
características e comparação das imagens, sendo o resultado então avaliado.
A biometria da geometria da mão não é uma medida biométrica com alto grau de
individualidade, conforme discutido na especificação deste trabalho, portanto
eventualmente podem existir duas mãos de pessoas diferentes onde o sistema pode ter
dados biométricos próximos, resultando numa falta aceitação, reconhecendo uma imagem
que não pertence ao usuário real. O mesmo pode ocorrer quando uma imagem da mesma
pessoa é recusada, resultando numa falta rejeição do usuário.
3.6.2 Módulo de Aquisição de Imagens
Este módulo consiste na aquisição das imagens do scanner e fazendo o salvamento
da mesma no disco rígido.
A validação deste módulo é feita colocando-se uma imagem qualquer no scanner e
verificando se a mesma foi scaneada e salva no disco, não será disponibilizado nenhum
tipo de configuração do scanner para a aquisição da imagem, a aquisição será realizada
utilizando-se as configurações padrões do projeto.
3.6.3 Módulo de Cadastro
Esta fase do teste consistirá em efetuar o cadastro completo de um usuário no banco
de dados, sendo a geração do padrão efetuada com imagens do disco rígido.
58
O sistema será considerado válido se as informações entradas pelo usuário
estiverem presentes no banco de dados após a execução e salvamento, podendo ser
visualizado através do próprio Microsoft Access.
3.6.4 Módulo de Leitura do iButton
A leitura do iButton inclui o sistema do 8031 e o receptáculo para leitura do
iButton, e pretende fazer a validação do protocolo de leitura, garantindo que o sistema
estará lendo corretamente o valor de cada iButton utilizado.
A validação deste módulo é feita colocando-se um iButton no receptáculo, e
verificando o valor lido, que será transmitido pela serial, podendo ser visualizado via
HyperTerminal, ferramenta do windows que permite fazer conexão com as portas seriais.
O código retornado para um mesmo ibutton deverá ser sempre o mesmo, e nenhum
outro ibutton colocado no receptáculo poderá retornar o mesmo código.
3.6.5 Módulo de Detecção de Batimentos Cardíacos
Esta fase tem por objetivo validar o funcionamento da detecção de batimentos
cardíacos, que será integrada ao sistema do 8031.
A validação será feita através de um LED indicativo. O usuário deverá colocar o
sensor de batimentos na pele entre o polegar e o indicador, o sistema deverá acender o
LED em um intervalo de no máximo 60 segundos. Enquanto que se nenhum usuário
estiver utilizando o sensor, o LED deverá permanecer apagado.
3.6.6 Sistema Completo
A validação do sistema completo deve ser feita em uma base com um número de
usuários que possa ser representativo, pretendemos ter inicialmente uma base com 30
voluntários quatro imagens de cada pessoa, a validação deve feita sempre com usuários
válidos, desconsiderando pessoas que tenham defeitos na geometria da mão, por exemplo,
pessoas que não possuam os 5 dedos.
59
Inicialmente a validação é feita colocando-se um usuário já cadastrado tentando
acessar o ambiente, utilizando o iButton no receptáculo, o sensor de batimentos cardíacos e
a própria mão, o sistema deverá ser capaz de reconhecer que os dados entrados são da
mesma pessoa, e acender um sinal indicando que a porta do ambiente seria aberta, no caso
de o LED não acender, o usuário deve tentar novamente, pois o resultado aparentemente
errôneo pode ter sido causado por algum fator externo.
Para validação completa, deve ser feita uma tentativa de acesso de outra pessoa, por
exemplo, passar o iButton que está cadastrado com um determinado usuário para uma outra
pessoa, cuja mão não seja a mesma que foi cadastrada, o sistema deverá portanto recusar
não acendendo o LED indicativo.
Salientamos que mesmo que o sistema aceite um usuário cuja mão não seja a
mesma do cadastro, isto é aceitável pois a biometria da geometria da mão não é uma chave
biométrica 100% segura, conforme dito na especificação, sendo utilizado somente para
ambientes de segurança baixa ou média, a definição de quando o sistema está dentro da
probabilidade de falsa aceitação e falsa rejeição depende de fatores estatísticos calculados
com base em outros projetos já realizados com a mesma chave biométrica.
O projeto será considerado válido desde que respeite os dados acima descritos.
60
4 IMPLEMENTAÇÃO
Neste ponto serão discutidos todos os aspectos referentes a implementação do que foi
especificado na fase de projeto. Para não tornar a leitura desta fase repetitiva e cansativa,
será dado ênfase aos tópicos em que não foi possível utilizar as técnicas descritas no
projeto, sendo, portanto, descrito os problemas que levaram as mudanças, e as soluções
propostas com seus resultados.
4.1 IMPLEMENTAÇÃO DO SOFTWARE
A parte de software em si estava bem dividida, e foram necessárias algumas
mudanças do projeto, devido a resultados feitos com relação aos testes. As necessidades de
mudanças serão discutidas nos tópicos subseqüentes.
4.1.1 Aquisição da Imagem
A aquisição da imagem foi implementada conforme mencionado no capítulo de
projeto, utilizando-se o TWAIN driver e as APIs TWAIN.
Quando invocado, o TWAIN mostra ao usuário, a tela de seleção do próprio
scanner. O usuário deve interagir nesta interface, pedindo para que seja adquirida uma
imagem de toda a superfície do vidro. O programa de aquisição do scanner irá
disponibilizar um menu de retorno ao projeto final que quando invocado, enviará como
retorno a imagem adquirida no formato DIB.
Dentro do programa de aquisição e tratamento, foi criada uma tela intermediária,
mostrando ao usuário a imagem que está sendo adquirida no momento, que inicialmente
neste protótipo deve ser validada.
A Figura 40 mostra a tela criada para aquisição de imagens, nela pode ser visto uma
miniatura da imagem que foi adquirida, consideramos uma imagem válida, aquela em que
toda a mão do usuário se encontra dentro da área da imagem, cujo pulso está abaixo da
linha mostrada na parte inferior da miniatura.
61
Figura 40 – Tela intermediária de aquisição de imagens
Este aviso e a necessidade de o pulso estarem na parte inferior da imagem ocorre
devido ao corte do pulso durante o processamento na geração do contorno. O valor de corte
é fixo, portanto nenhum dedo deve se encontrar nesta área. Toda a região abaixo da linha
será substituída por uma curva com grau de curvatura baixa, de modo a não ser tratado
como ponto característico na passagem do método DOS.
A Figura 41 mostra o contorno de uma imagem de mão, com os detalhes do pulso, e
na seqüência a mesma imagem com o contorno fechado usando uma curvatura baixa.
Através deste contorno fechado, o método DOS é utilizado, e a parte do pulso não é
considerada como grau de alta curvatura, onde se encontram os pontos característicos.
Figura 41 - Imagem do contorno com o detalhe do Pulso e após o corte
62
4.1.2 Processamento da Imagem
A fase de implementação do processamento de imagens em si divide-se
basicamente em duas partes iniciais pois o método de extração de características necessita
de um contorno fechado para calcular a diferença do grau de curvatura nos pontos, e a
entrada pelo scanner é uma imagem em escalas de cinza, portanto, esta fase naturalmente
divide-se em extração do contorno, e a extração de características.
4.1.3 Extração do Contorno
Para o funcionamento pleno, a implementação deveria prover ao método de
extração de curvatura um contorno fechado, que representasse a mão do usuário.
Para chegar a este contorno, conforme descrito na fase de projeto foram necessários
alguns algoritmos de tratamento, alguns dos quais não apresentaram resultados
satisfatórios e necessitaram de adaptações para um melhor funcionamento.
Os passos realizados para a extração do contorno podem ser visualizados na Figura
42. Inicialmente a imagem é adquirida via scanner, e já se encontra em escalas de cinza. O
primeiro passo, que não havia sido previsto na fase de projeto é um filtro passa-baixas para
suavizar o ruído que pode existir nas extremidades da mão. Este passo na filtragem serve
principalmente para melhorar o resultado da binarização através do método de Otsu, pois
se um pixel independente se encontra fora da área de binarização, este na imagem
binarizada será uma componente de alta freqüência que pode prejudicar a extração da
borda posteriormente, com o filtro passa-baixas a probabilidade de que um pixel isolado
esteja isolado reduz, visto que o filtro trabalha com a análise da vizinhança.
Figura 42 - Passos para extração do contorno
A binarização foi implementada conforme descrito em fase de projeto, com um
método de detecção automática de limiares, o Limiar de Otsu. A imagem binarizada possui
Imagem em escala de Cinza
Filtro Passa-Baixas
Limiar de Otsu
Binarização Deteção de Bordas(Filtro de Limiar)
Fechamento do Contorno
Afinamento
63
componentes de alta freqüência em todo o contorno do objeto de análise, contorno que
pode ser facilmente retirado usando-se um filtro passa-altas, mantendo somente as
componentes de alta freqüência. Este filtro resultará em um contorno referente à mão
scanneada na qual será realizado o fechamento do contorno, explicado no tópico sobre a
aquisição de imagens, e o afinamento.
O afinamento teve mudanças mais significativas em relação aos outros algoritmos.
Como explicado na fase de projeto, alguns padrões indesejados acabam saindo como
resultado da detecção de bordas. Aqui foi introduzido um algoritmo para identificar se um
determinado pixel é essencial para o contorno do objeto, e caso não seja este é retirado da
imagem.
A implementação do algoritmo de afinamento e todos os outros utilizados no
projeto podem ser encontrados no CDROM que acompanha este documento.
4.1.4 Extração de Características
Para a extração de características estão envolvidos diversos tratamentos da imagem.
Alguns destes tratamentos tiveram que ser adaptados de modo a se conseguir um melhor
resultado.
Alguns dos métodos utilizados para chegar a um resultado ideal necessitam de
parâmetros que devem ser ajustados ao problema em que o método está sendo utilizado,
neste caso, a extração de características de uma mão. A seguir explicaremos quais
resultados se aproximam mais do ideal.
4.1.4.1 Extração do Grau de Curvatura
Conforme dito na fase de projeto, o método utilizado para a extração do grau de
curvatura em um determinado ponto do contorno consiste em dois vetores, e um espaço
entre os vetores, ambos com o tamanho fixo.
O tamanho dos vetores(w) e o espaço(m) entre eles são parâmetros que devem ser
experimentados para se achar a solução que seja mais ideal para este problema.
64
Para conseguir definir os valores a serem utilizados, foi realizado um
processamento em lote das imagens da nossa base, com os valores de w variando de 30 a
120 de 10 em 10, e os valores de m variando de 1 a 15, inicialmente de 5 em 5, e num
segundo momento variando de 1 a 5 com intervalos de 1 pixel.
Analisando a forma dos resultados, temos a impressão de que os resultados estão
muito próximos, com a diferença de que o tamanho dos morros está levemente diferente.
Mas quando voltamos a imagem tratada, vemos que a região considerada de alta curvatura
começa a mudar, e se o valor do comprimento é considerado com base nesta área, quanto
mais próxima do ponto central de curvatura, mais próxima será a aquisição.
Uma vez finalizados os processamentos, foi feita a análise destes resultados,
tentando identificar quais os parâmetros necessários para se ter a região de curvatura bem
definida, e que possa ser utilizado na análise de qualquer outra imagem.
Os valores de w se tornam funcionais quando seu tamanho está a partir de 70-80
pixels, deixando de apresentar resultados satisfatórios próximo de 100. Levando em
consideração a variação do estado inicial e testes complementares realizados com outras
imagens, nota-se que o valor de w=90 sempre apresenta um resultado com pouca variação
nas regiões de alta curvatura, por esta razão, este valor está sendo utilizado nesta
implementação.
Já o valor de m, o espaço entre os vetores, não teve influencia positiva muito
grande, com valores grandes de m, as áreas de alta curvatura começam a ser distorcidas, e
valores pequenos não fornecem uma variação positiva grande. Devido a esta indiferença no
resultado, podemos tomar uma valor pequeno de m, que para este projeto foi escolhido um
valor de igual a 1.
4.1.4.2 Filtragem do resultado
O resultado do método DOS não pode ser trabalhado diretamente, pois os pontos de
alta curvatura, apesar de estáveis possuem um certo grau de variação, o ponto central tende
a variar e com esta variação, o tamanho do contorno entre os pontos também varia, a ideia
inicial seria utilizar o contorno como medida de comprimento, mas como descrito a seguir,
isto não foi possível.
65
Nos testes realizados, a variação do contorno chega a 10% entre amostras de uma
mesma classe, obviamente estes valores não puderam ser utilizados, pois uma faixa de
variação com 5-10% se torna inviável para comparações já que diferenças entre classes
podem ter valores dentro desta faixa, o que permitira o reconhecimento errôneo de um
individuo com uma probabilidade mais alta. Para solucionar este problema um
processamento a mais foi incluído para conseguir fazer a extração da característica.
A Figura 43 mostra um gráfico de resultado do método DOS aplicado a uma
imagem de mão. Cada grupo de dois picos representa a curvatura de ponta ou base de um
dedo. Isto foi outro ponto que apresentou variação insatisfatória visto que eventualmente
aparecem dois picos, e eventualmente toda a ponta do dedo é representada por um pico só,
como se fosse uma região única de alta curvatura, isto é prejudicial na análise do resultado,
sendo que algum tipo de trabalho é preciso ser realizado antes de se tentar retirar qualquer
tipo de informação com relação a geometria da mão.
Figura 43 - Gráfico de resposta do método DOS
Uma idéia foi tentar trabalhar sempre com um pico único para os dedos, e um pico
único para os vales, pois se existe 1 pico somente, podemos considerar a ponta do dedo
estando na região central deste pico, graficamente podemos ver que a posição deste pico
tem variações para imagens da mesma classe, mas o tamanho desta variação é muito
menor, resultando em um valor mais preciso.
Inicialmente foi utilizado um filtro gaussiano, com o valor de sigma sendo variado
em diversos tamanhos. Os testes apresentaram valores mais apropriados quando sigma
estava sendo utilizado como o dobro do tamanho de w (tamanho do vetor do DOS). Outra
vantagem além da união dos picos foi que os pontos de baixa curvatura são aproximados a
zero. Logo, mesmo que eventualmente possa existir um ponto isolado que tenha uma
66
curvatura mais elevada, este tipo de filtragem irá aproximá-lo com os valores da
vizinhança, e este será excluído da análise.
A Figura 44 mostra o conjunto de dados da Figura 43 com a aplicação do filtro
gaussiano, com sigma sendo o dobro do valor de w. Podemos ver que mesmo com um
valor aparentemente grande de sigma, ainda temos resquícios de um segundo pico
próximo, podendo ainda prejudicar a imagem.
Figura 44 – Gráfico com aplicação de um filtro Gaussiano
Uma solução para eliminar estes segundos picos, seria fazer tentativas com valores
de sigma ainda maiores, este problema pode ser resolvido de maneiras diferentes, foi usado
na implementação um filtro de média simples, com uma janela de análise do mesmo
tamanho de w. O resultado desta filtragem é mostrada na Figura 45, onde podemos ver
claramente que os picos duplos foram completamente eliminados.
Figura 45 - Gráfico com aplicação de um filtro de média
Para achar o ponto central que mais se aproxima do “meio” do dedo, não foi
utilizado o ponto mais alto do pico em questão, mais sim o ponto central da faixa de alta
67
curvatura. Para definir a largura desta faixa, foram considerados somente os pontos cujo
valor estavam acima da média total da amostra + ½ da média.
A Figura 46 mostra o gráfico da média, com as regiões de maior curvatura pintadas
em cinza, o limiar utilizado para definir a região de alta curvatura está representado pela
linha negra entre 10 e 20, e é definida pelos pixels do contorno que estão localizados
dentro desta faixa.
Figura 46 - Pontos de alta curvatura da amostra
Os pontos centrais são calculados como os pontos que se encontram no meio desta
área de alta curvatura, e com base nestes pontos é possível calcular o comprimento dos
dedos.
O valor que é resultante refere-se a posição do ponto central, no contorno da
imagem, portanto para chegarmos a este ponto dentro da imagem, o contorno deve ser
percorrido novamente, e os pontos adotados.
Existem dois pontos que devem ser tratados como exceção, são estes o ponto
externo do dedo mínimo, e o ponto externo do polegar, pois estes se encontram em regiões
de baixa curvatura, mas são necessários para o cálculo do comprimento destes dedos.
A posição onde este ponto se encontraria é estimada, usando-se o tamanho do
comprimento do lado interno do dedo, e somando-se com mais 15% (pois o contorno do
lado externo se mostrou maior que o lado interno para se ter medidas mais coerentes).
Mesmo com esta aproximação, a medida do comprimento destes dois dedos tem uma
variação um pouco maior, precisando ser tratada de maneira diferente no momento do
reconhecimento.
68
4.1.4.3 Cálculo do comprimento e da largura
A partir deste ponto, o sistema possui 11 pontos, que representam os pontos
centrais das áreas de maior curvatura. O cálculo do comprimento pode ser calculado
traçando-se um triângulo entre três destes pontos, o valor aproximado do comprimento
seria a linha média do triângulo.
Esta linha média estará sempre dentro da área do dedo, pois como os pontos que
formam a sua base estão nos “cantos” dos dedos, a linha média sempre será traçada
internamente. Partindo deste princípio, a largura pode ser calculada a partir de linhas
perpendiculares a reta que define a linha média do triângulo.
Esta linha média é dividida em 20 pontos, que são os pontos onde a largura será
“amostrada”. Uma reta perpendicular é traçada até que seja encontrada a “borda” do dedo,
e a largura aproximada do dedo é calculada pela média de todas estas larguras.
A Figura 47 mostra uma imagem com as medidas demonstradas graficamente, onde
a linha pontilhada no meio do dedo é a linha que representa o comprimento, e as linhas
perpendiculares a esta são as linhas base para a medida da largura.
Figura 47 - Imagem com as medidas de largura e comprimento
69
4.1.4.4 Geração do Biocode
Para manter a informação da medida biométrica de comprimento e largura,
persistente em algum meio, é necessário extrair um conjunto de dados reduzido, e que
ainda assim, seja capaz de fazer a individualização dos usuários.
Até o momento, os métodos de extração de dados retornaram 5 medidas de
comprimento e 5 medidas de largura, para cada um dos dedos da mão. Para o
armazenamento o objetivo é reduzir este número uma única informação de comprimento, e
uma informação de largura.
Para isso é necessário fazer uma análise de “importância” de cada uma das medidas
adquiridas da mão. Dentre os dedos, quais os que apresentam maiores e menores taxas de
variação, de modo que esta diferença seja reproduzida na geração do biocode e assim,
tenha uma “prioridade” diferenciada na verificação padrão-candidato.
Com estas informações e alguns testes chegamos a conclusão que as seguintes
equações proporcionam um grau razoável de individualização.
C = 0* Cd1 + 2* CD2 +2 *CD3 +CD4 + 0.1 * CD5 e
L = 0* Ld1 + 2* LD2 +2 *LD3 +LD4 + 0.1 * LD5
onde:
• C é o valor único para representar o valor médio de comprimento dos dedos;
• L é um valor para representar o valor médio de largura dos dedos
• CD1, CD2, ..., CD5 é o valor de comprimento de cada um dos dedos, iniciando a partir
do polegar.
• LD1, LD2, ..., LD5 é o valor de largura de cada um dos dedos, iniciando a partir do
polegar.
Analisando a fórmula utilizada para o calculo do biocode notamos que o peso dado ao
primeiro dedo (o polegar) é zero, isto se deve ao seu alto grau de variação onde a sua
utilização acaba prejudicando a separação das classes. Por este alto grau de variação, o
polegar pode ser desconsiderado no cálculo do biocode, e por ser excluído, este pode ser o
portador do sensor de batimentos cardíacos, sem influenciar no grau de individualização.
70
4.1.4.5 Classificador
O classificador faz parte de módulo de verificação do sistema e tem por objetivo
classificar o candidato. Literalmente indicar a qual classe ele pertence, neste caso, tem-se
uma classe padrão, e a função do classificador é verificar se o candidato pertence ou não a
esta classe.
Para isto foi necessário definir uma função de classificação, que pudesse informar
qual a distância do candidato para o padrão. A função implementada é a de um
classificador euclidiano simples. Como o biocode é representado por dois números
normalizados entre 0 e 100, calcula-se a hipotenusa do triangulo retângulo formado entre
os dois pontos (coordenadas do Candidato e coordenadas do Padrão), considerando um
ângulo reto. A equação propriamente dita é:
Diferença = Raiz Quadrada( |Padrão.y – Candidato.y| 2
+ |Padrão.x – Candidato.x| 2)
Caso este valor de diferença, seja menor que o valor do índice de aceitação (o raio
do círculo do gráfico de dispersão) que como explicado anteriomente resultou em 3, o
indivíduo será aceito dentro da classe. Qualquer valor acima do índice de aceitação resulta
na não aceitação dentro da classe em questão.
4.1.5 Cadastro de usuários
A tela de cadastro de usuários é um reflexo visual das informações persistentes no
banco de dados. O banco de dados foi implementado no formato Microsoft Access 2000 e
como definido em fase de projeto, foi implementado com apenas uma tabela para conter as
informações dos usuários cadastrados.
O banco de dados foi definido como um DSN (Data Source Name – Fonte de
Dados) no sistema operacional. Uma fonte de dados no sistema é visível para todos os
usuários, inclusive para as aplicações de serviços do NT, isto quer dizer que qualquer
usuário do sistema poderia iniciar o software deste projeto, e caso o banco de dados
estivesse presente, este seria encontrado. Vale frisar que o arquivo de banco de dados deve
estar num diretório que todos os usuários tenham acesso.
71
Na implementação do acesso ao banco de dados, foram utilizados componentes de
integração da Borland, visando a facilidade de implementação e o resultado final obtido. O
acesso de baixo nível (feito com códigos SQL) foi realizado somente em casos quando a
atualização é feita diretamente pelo sistema, e não pelo usuário da tela de cadastro. Isto
ocorre no cadastro do ibutton, pois o sistema faz a leitura e automaticamente atualiza na
tabela, e na atualização do biocode, pois este é um campo onde o usuário não possui
acesso.
4.2 IMPLEMENTAÇÃO DO HARDWARE
A parte de hardware foi implementada basicamente em dois módulos, Leitura do
iButton, e leitura dos batimentos cardíacos, algumas mudanças foram necessárias visando
obter um melhor desempenho ou um resultado mais apropriado.
4.2.1 Leitura do iButton
O circuito para leitura do valor do ibutton foi implementado como havia sido
especificado na fase de projeto, e foi conectado a porta P1.0 do 8031.
O software do 8031 fica em constante verificação desta porta, enviando o comando
de reset e preset, que poderiam representar um hand-shake com o ibutton. Logo que um
ibutton é encontrado no receptáculo todas as interrupções do microcontrolador são
desativadas, visando manter as janelas de tempo com a precisão requisitada pelo procolo 1-
wire.
O código do iButton é armazenado em 8 bytes da memória interna do 8031, e
ficarão nesta posição até que um novo ibutton seja lido, ou que o software faça requisição
do valor, quando este endereço será então zerado.
Apesar de o código ser armazenado na memória interna do microcontrolador, é
recomendável que a leitura pelo software seja feita enquando o ibutton se encontra no
receptáculo pois como o programa se encontra em loop de leitura até que o ibutton seja
retirado, a sobreposição dos códigos do ibutton pode resultar em bytes aleatórios (lixo de
memória), com o ibutton no receptáculo é garantido que o valor lido será o que está no
receptáculo.
72
4.2.2 Batimentos Cardíacos
Os batimentos cardíacos foram lidos através de um sensor de fotopletismografia e
conectado em um módulo pulse-F, o que simplificou o desenvolvimento desta parte do
projeto, uma vez que o pulse-F recebe o sinal analógico e fornece um resultado digital
equivalente a pulsação do usuário.
Para utilizar este módulo o sistema teve que ser adaptado, pois a tensão de
funcionamento deste é de 1,2 V, enquanto a placa do 8031 é padrão TTL 5V. Para resolver
este problema foi utilizado inicialmente um divisor de tensão reduzindo de 5 para 1,2 V. e
no sinal resultante um amplificador não-inversor com ganho 2,5 fazendo com que o sinal
pudesse ser ligado diretamente na interrupção zero do microcontrolador.
Os batimentos cardíacos são contados por minuto, portanto um dos timers do
microcontrolador foi direcionado a tarefa de zerar a contagem do sensor. Para isto, dois
endereços de memória são utilizados, um auxiliar, que conta os batimentos no minuto
corrente e um secundário que contém as informações de batimentos no minuto anterior.
Qualquer um destes dois valores deve ser superior a 50 para garantir a vitalidade do
usuário.
A cada chamada a interrupção do microcontrolador, o contador de batimentos é
incrementado. Inicialmente surgiu a dúvida se as chamadas sucessivas às interrupções não
seriam problemáticas, mas rapidamente concluímos que não, pois enquanto um batimento
cardíaco possui baixas freqüências na faixa dos Hz, o microcontrolador realiza suas tarefas
com um clock aproximado de 12 MHz. As tarefas que possuem janelas de tempo bem
definidas cuja duração necessita de precisão desativam as outras interrupções e portanto
não sofrerão interferências externas como dos batimentos.
Com a implementação finalizada, alguns testes constataram que este sensor não é
ideal para este tipo de aplicação, pois como é um sensor de pletismografia (analisa a
variação do volume entre o sensor), variações no local de posicionamento, oscilações na
mão, e até mesmo a simples abertura do sensor acaba sendo considerada um batimento
cardíaco. Em um ambiente controlado, mãos simuladas poderiam ser aprovadas como
verdadeiras com esta facilidade em se burlar o sensor.
73
4.3 CAIXA DE ISOLAMENTO
Durante a realização de testes de aquisição de imagens, constatou-se que a
iluminação do meio externo iria influenciar nas imagens, a influência externa causaria uma
modificação tão acentuada, que seria suficiente para prejudicar os métodos utilizados,
principalmente o método de detecção de limiar de Otsu, que visa separar a imagem do
fundo.
O projeto elaborado baseia-se que o fundo será o mais uniforme possível, ficando o
mais próximo possível, enquanto o objeto terá coloração mais clara. Com a interferência
externa, algumas áreas do fundo estavam ficando com coloração diferente, confundindo-se
com o objeto.
A Figura 48 mostra uma imagem binarizada, com a interferência causada pela
iluminação externa, podemos ver que no lado esquerdo da imagem, parte do fundo foi
binarizado em branco, confundindo-se com a própria imagem da mão.
Podemos ver pela área demarcada no histograma da Figura 49, que os dois picos
que deveriam separar o objeto do fundo, estão unidos, isso mostra que parte do objeto e do
fundo se confundem, estando representados pela mesma intensidade de cor, dificultando a
identificação automática do limiar.
Uma solução para este problema seria o isolamento do scanner, de modo que a
iluminação externa não tivesse influência sobre a imagem sendo aquisicionada. Este
isolamento foi feito através de uma caixa de acrílico.
Figura 48 - Imagem binarizada com influência da
iluminação externa
Figura 49 - Histograma de uma imagem sem a
caixa de isolamento
74
A caixa montada foi feita com placas de acrílico preto, em dimensões suficientes
para ficar em cima do scanner, como o sensor de batimentos cardíacos deverá ser fixo no
scanner também, a caixa conta com uma placa de acrílico transparente em sua parte
inferior, onde o sensor de batimentos estará presente.
As medidas das placas necessárias para a montagem são:
• 1 Placa transparente de 22x30 cm;
• 1 placa de 12x26 cm;
• 1 placa de 26x32 cm (superior);
• 2 placas de 12x32 cm (laterais);
Mesmo com a luz externa sendo isolada, a caixa traria outro problema, a confinação
da luz do próprio scanner, uma vez que a luz emitida pelo próprio scanner está confinada
em um local fechado, ela será refletida nas paredes, ocasionando novamente problemas
para o pré-processamento. Efeito demonstrado na Figura 50.
Devido ao modo como o scanner lê a imagem, isto pode facilmente ser resolvido
colocando-se uma inclinação na tampa superior da caixa, isto se deve ao fato de que o
scanner lê a imagem movendo uma lâmpada junto com sua área de leitura(representados
pelo retângulo cinza na Figura 50), se a luz for direcionada para qualquer área que não
esteja sendo lida no momento, a luz não estará influenciando na aquisição.
Figura 50 - Luz confinada no scanner
Luz emitida pelo
scanner Luz refletida
pela caixa
75
Figura 51 - Luz Refletida para fora da área de leitura do scanner
A Figura 51 mostra como a luz é refletida para fora da área de leitura do scanner,
com a inclusão de uma leve inclinação no eixo da tampa superior, inclinação de
aproximadamente 30º. Deste modo, a imagem não possui nenhuma interferência no fundo,
onde este fica concentrado na área escura como é esperado para a utilização do método de
limiarização de Otsu.
A Figura 52 mostra o histograma de uma imagem adquirida no mesmo ambiente,
mas com a utilização da caixa de isolamento. Podemos ver que neste histograma, existe um
intervalo representado pela linha pontilhada onde nenhum ou poucos pixels se encontram,
de modo que é possível separar com facilidade o objeto do fundo.
Figura 52 - Histograma de uma imagem utilizando a caixa de isolamento
4.4 TESTES E VALIDAÇÃO DO PROJETO
Após concluída toda a fase de implementação o projeto foi submetido ao protocolo
de testes e validação definido anteriormente. Como ficará explícito a frente, ele foi capaz
de atender a todos os requisitos definidos.
Luz emitida pelo
scanner Luz refletida pela
caixa para fora da
área de leitura
76
4.4.1 Módulo de Reconhecimento Biométrico
O módulo de reconhecimento biométrico se apresentou estável e funcional, quando
submetidas quatro imagens o sistema foi capaz de gerar o biocode e para imagens que não
atenderam aos requisitos para geração do contorno, o sistema emitiu avisos visuais
indicando que a imagem não era válida e precisava ser substituída.
O sistema foi submetido a este teste com diversas amostras do banco de dados de
30 usuários, estes tiveram seu biocode gerado, e diversas imagens foram selecionadas para
fazer a verificação de acesso. Com este teste foi possível estabelecer valores de falsa
aceitação e falsa rejeição, descritos com mais calma na conclusão.
Considera-se portanto que este módulo é válido e passou pelos testes mínimos.
4.4.2 Módulo de Aquisição de Imagens
O software do projeto foi executado em máquinas com dois tipos diferentes de
scanner, ambos da marca Hewlett-Packard. Em ambos os casos quando requisitada uma
imagem a tela do próprio scanner era invocada (devido a utilização do Twain Driver) e a
imagem que estava no scanner era passada ao projeto.
O módulo atendeu as expectativas descritas anteriormente.
4.4.3 Módulo de Cadastro
O módulo de cadastro se mostrou funcional, pois foram realizados diversos
cadastros, e o módulo cumpriu com a obrigação de manter a informação persistente.
Foram realizados testes de atualização e exclusão de registros já salvos, o que
também ocorreu com sucesso. Módulo de cadastro está previamente testado e aprovado.
4.4.4 Módulo de Leitura do iButton
Os testes realizados com este módulo foram feitos com somente dois ibuttons
diferentes. O código lido era diferente como esperado, e em diversas chamadas a funçãoo
de leitura, os códigos retornados eram consistentes com o valor retornado em testes
anteriores.
77
4.4.5 Módulo de Detecção de Batimentos Cardíacos
O sensor inicia em posição de repouso, e como esperado, não conta batimentos
nenhum, caso seja colocado em uma região que não seja uma mão, uma borracha por
exemplo, o sensor não apresenta sinal. Ao ser colocado na mão, mais propriamente no
polegar, este mostra um sinal digital equivalente a cada batida do coração. Este valor pode
ser contado para se definir se o usuário está vivo ou não. Portanto este módulo está
funcional.
4.4.6 Sistema Completo
A utilização simultânea de todos os módulos em conjunto ocorreu bem, de maneira
estável e funcional. Foi possível cadastrar usuários com cálculo automático de biocode,
fazer a verificação com a imagem sendo adquirida na hora e com os batimentos
verificados.
Considerados que o sistema passou por todos os testes iniciais, e está com um nível
de estabilidade aceitável.
78
5 RESULTADOS
Uma vez com os métodos de extração de características finalizado, faz-se necessária
uma verificação prática da funcionalidade do método biométrico, para atestar que o grau de
individualização atingido é suficiente para um sistema com os objetivos propostos.
A partir de uma base de usuários com 80 indivíduos diferentes e 4 amostras de cada
um, foi realizada a extração de suas características usando-se os parâmetros previamente
descritos neste documento. Os resultados obtidos foram plotados em um gráfico de
dispersão.
Visando facilitar a identificação de amostras da mesma classe, o gráfico foi plotado
utilizando duas medidas, para que o resultado seja demonstrado em um plano cartesiano
comum. Estas duas medidas são o valor médio de largura que representa o eixo das
ordenadas, e o valor médio de comprimento, representando o eixo das abscissas.
O gráfico de resultado desta plotagem está incluso como anexo neste documento,
sendo referenciado pelo nome de ANEXO 10.
Neste gráfico, podemos ver através dos valores nos eixos que os dados estão
normalizados em uma faixa de valores entre 0 e 100. Cada uma das marcas mostradas
representa um dos usuários, cada usuário forneceu um mínimo de 4 amostras, como pode
ser visto no gráfico. Ao redor destas amostras temos um círculo representando a média das
amostras fornecidas, e a “área de aceitação”, a região que define a aceitação de um
determinado candidato como membro deste conjunto.
A área de aceitação foi calculada com base em uma análise da variação das amostras
que foram adquiridas. Inicialmente foi calculado o biocode para cada um dos usuários da
base, e com isso calculado o desvio padrão das suas amostras.
Apesar do número limitado de amostras (4 por usuário) o desvio padrão mostrou
qual a variação dos elementos, e podemos ver que estes variam até no máximo 9 pontos,
isto nos seus valores máximos, pois uma variação nesta amplitude é altíssima. Tirando a
média destes desvios temos os valores de 1,54 e 3,22 a Tabela 6 é lista completa de desvios
padrão no qual está média foi calculada.
79
Com os valores da média foi possível estimar um valor ideal próximo da média real
das amostras, e o raio desta área de aceitação na implementação foi de 3 pontos.
Comprimento Largura Comprimento Largura 0,48 0,94 1,42 0,85 0,69 1,01 1,86 3,90 4,34 5,07 2,78 1,44 1,01 5,65 1,35 1,97 1,22 3,81 1,32 3,98 1,21 1,93 1,23 0,50 1,74 3,12 0,72 3,58 0,80 1,75 0,73 5,31 2,06 2,04 1,42 0,85 1,12 1,93 0,78 1,18 1,28 3,39 1,27 1,45 2,00 2,94 2,31 8,70 0,96 1,36 1,89 5,88 0,57 3,47 4,08 6,78 0,16 1,41 3,16 8,10 Média Compr. 1,54 Média Largura 3,22
Tabela 6 - Desvios Padrão dos Biocodes
O gráfico ideal teria as amostras de mesmas classes sempre dentro do círculo, em
uma área bem reduzida, enquanto a média entre as classes seria o mais distante possível.
Através do gráfico podemos ver claramente que não é isso o que está ocorrendo, pois as
médias tendem a se concentrar em uma determinada região e existe dispersão entre
amostras da mesma classe.
Para que uma pessoa possa se passar por outra no sistema, usando somente os seus
dados biométricos originais, sem nenhum tipo de esforço adicional para burlar
forçadamente o sistema, é necessário que seus círculos médios se sobreponham. Quanto
maior a taxa de variação da aceitação (maior o círculo da média) mais sobreposições
podem ser esperadas, sobreposições estas, que influem diretamente no grau de
individualização proporcionado pelo sistema.
A priori, analisando a base de dados arquivada pode-se ver que o sistema tem a
capacidade de diferenciar os usuários até um determinado nível, onde começam a aparecer
sobreposições nos círculos médios, como descrito no documento de especificação deste
projeto a responsabilidade do módulo biométrico é fazer somente a verificação, não a
identificação do usuário, sendo a identificação dada por um ibutton, deste modo, para que
80
o usuário possa burlar com sucesso o sistema, além de conseguir a chave eletrônica do
usuário original, sua mão deve se encontrar dentro do círculo médio, o que reduz a
probabilidade de sucesso.
Com os valores dos resultados da biometria, foi possível calcular os índices de falsa
aceitação (FAR) e falsa rejeição (FRR), mas vale a pena frisar que a base de dados
utilizada continha comente 80 usuários (total de 320 imagens). Esta base é reduzida para
uma informação consistente, portanto mais testes se fazem necessários para validar estes
números.
Dentre as 320 imagens, temos que 6 delas podem se passar por usuários que não
são aqueles que são os donos efetivos do o cadastro, isto proporciona 1,7% de falsa
aceitação, que é o parâmetro mais perigoso de um sistema. Este número é relativamente
alto, pois o ideal seria zero, mas pode ser reduzido com a adição de mais parâmetros na
geração do biocode.
Temos ainda que 31 imagens são recusadas, mesmo fazendo parte da mesma classe.
Isto resulta em um índice de falsa rejeição de aproximadamente 9%, mesmo que este seja
um índice menos importante que a falsa aceitação, pois o usuário só tem o trabalho de
colocar a mão novamente no scanner. Este número é extremamente alto e métodos para
reduzir esta variação devem ser procurados.
81
6 CONCLUSÕES
O desenvolvimento deste projeto permitiu demonstrar que é possível a utilização de
um método de extração do grau de curvatura em um contorno fechado para extrair as
características da mão de uma pessoa e com isso obter um sistema que desconsidere a
variação de rotação e translação da mão do usuário. Com isso nenhum tipo de medida de
redução de liberdade como pinos de posição, ou scanners no formato da mão, foram
necessários.
Os indíces de falsa aceitação e falsa rejeição que foram atingidos podem ainda ser
reduzidos, mas se mostraram aceitáveis para uma utilização desde que a biometria não seja
usada para identificação. Mesmo com uma quantidade relativamente reduzida de medidas
(somente largura e comprimento dos dedos) é possível ter um grau de individualização
mínimo, fazendo com que seja viável a implementação de um sistema baseado nestes
princípios, desde que este utilize como meio de identificação uma chave externa (como um
ibutton). Desta forma, a chave externa faz com que a probabilidade de que uma pessoa
possa se passar por outra seja bastante reduzida, já que além de se apoderar do objeto
chave, necessita ainda possuir uma geometria da mão compatível.
O tipo de sensor utilizado para detectar os batimentos cardíacos não é ideal, uma
vez que os valores são aproximados e o valor medido varia devido ao posicionamento do
sensor na mão. Outro inconveniente deste sensor é a necessidade de posicionamento em
um dos dedos, que se encontra na área onde as características são adquiridas, causando a
perda de uma das informações que, apesar de resultar em uma variação praticamente
desprezível, pode, em casos especiais, ser fator relevante para individualização. Para uma
implementação comercial, outros tipos de sensores deveriam ser testados, visando a
facilidade de uso, melhoria no resultado e melhor posicionamento.
Futuramente, melhorias podem ser implementadas neste projeto, como por
exemplo, utilizar outras medidas na geração do código biométrico. Estas podem ser
tamanho/largura da palma da mão, altura da mão, entre outras. A utilização de um outro
meio de aquisição de imagens, que seja mais rápido, como uma câmera digital por exemplo
e também a expansão para outros tipos de chaves eletrônicas além do ibutton, como smart
cards, magnetic tags, etc...
82
7 REFERÊNCIAS BIBLIOGRÁFICAS
[1] National Center for State Courts-Court Technology Laboratory; Biometrics Overview (http://ctl.ncsc.dni.us/biomet web/BMOverview.html), 2003. [2] National Center for State Courts-Court Technology Laboratory; Biometrics Comparison (http://ctl.ncsc.dni.us/biomet web/BMCompare.html), 2003. [3] International Biometry Group; Biometrics Market Report 2003-2007 (http://www.ibgweb.com), 2003. [4] Reillo R. Sanchez, Avila C. Sanchez, Marcos A. Gonzalez, Biometric Identification Through Hand Geometry Measurements, IEEE Trans. On Pattern Analysis and Machine Intelligence, 2000. [5] Anil K. Jain, Arun Ross, A Prototype Hand Geometry-based Verification System. Michigan State University, Us, 2000. [6] Dallas Semiconductors Corp., Book of ibutton Standards (http://www.ibutton.com/ibuttons/standart.pdf), 2003. [7] Dallas Semiconductors Corp., Application Note 74, Reading and Writing to Ibuttons via serial interfaces, 2003. [8] Dallas Semiconductor Corp., Ibutton-1990A Datasheet (http://www.ibutton.com/ibuttons/DS1990A.pdf), 2003. [9] PASCO Scientific; Instruction Sheet for the PASCO Model CI-6543B, 2003.
[10] Center For Microcomputer Applications, Amsterdam, The Netherlands, 2003. [11] N. Otsu, A Threshold Selection Method from Gray-level Histograms, IEEE Transactions on Systems,Man and Cybernetics, 1979. [12] R. J. Parker, Algorithms for Image Processing and Computer Vision, Wiley Computer Publishing. 1997. [13] R. Plamondon, C. Y. Suen, M. Bourdeau, C. Barrière, Methodologies for evaluating Thinning Algorithms for Character Recognition. [14] L. Lam, S.W Lee, Thinning Methodologies – A comprehensive Survey, IEEE Transactions on Pattern and Machine Intelligence, 1992. [15] R. Legault, C.Y Suen, A Comparison of Methods of Extracting Curvature Features, Center for Pattern Recognition and Machine Intelligence, Concordia University Montreal, 1992. [16] M. Worring, A. W. M. Smeulders, The Accuracy and Precision of Curvature Estimation Methods, University of Amsterdam, 1992. [17] L. O’ Gorman, An Analisys of Feature Detectability from Curvature Estimation, AT&T Bell Laboratories, Murray Hill, 1988. [18] A. Zimmer, Sistema híbrido para verificação de assinaturas manuscritas, Departamento de Engenharia elétrica e computação da Universidade Estadual de Campinas – Tese de doutorado a ser publicada, 2003. [19] F. Bomfim, Controle de Acesso a Ambientes baseado em iButton, Núcleo de Ciências Exatas e Tecnológicas, UnicenP – Centro Universitário Positivo, 2002.
83
[20] Twain Working Group, TWAIN Specification 1.9 (www.twain.org), 2000.
[21] Microsoft, MSDN - Microsoft Developer Network (msdn.microsoft.com), 2003.
[22] Visual Paradigm, Visual Paradigm UML (www.visual-paradigm.com), 2003.
[23] Philips Semiconductor, 80C51 family programmer’s guide and instruction set, 2002.
84
ANEXO 1 – PLACA MICROPROCESSADA (KIT 8031)
85
ANEXO 2 – DIAGRAMA DE CASOS DE USO DO SISTEMA
86
ANEXO 3 – DIAGRAMA DE CLASSES DO SOFTWARE
87
ANEXO 4 – DIAGRAMA DE SEQUENCIA PARA ADQUIRIR IMAGEM
88
ANEXO 5 – DIAGRAMA DE SEQUÊNCIA PARA GERAÇÃO DO PADRÃO
89
ANEXO 6 – DIAGRAMA DE SEQÜÊNCIA DE CADASTRO DE USUÁRIOS
90
ANEXO 7 – DIAGRAMA DE SEQUENCIA PARA CARREGAR USUÁRIOS
91
ANEXO 8 – DIAGRAMA DE SEQÜÊNCIA DA VERIFICAÇÃO DE ACESSO
92
ANEXO 9 – CAIXA DE ISOLAMENTO
93
ANEXO 10 – GRÁFICO DE DISPERSÃO DOS USUÁRIOS DE TESTE
94
ANEXO 11 – CÓDIGO FONTE DO PROCESSAMENTO DE IMAGENS class cImgObject private: unsigned char ** byteMatrix; unsigned char ** byteMatrixAux; int iWidth; int iHeight; public: cImgObject(TImage * img); ~cImgObject(); int LimiarOtsu(); void Clear(int iValue); void Draw(TImage * img); void Binarizar(int iLimiar); void FiltroEspacial(int iMatrix[3][3]); void BordaVizinhanca(); int AfinamentoFim(); vector<float> ExtractBiocode(); vector<float> ExtractMedidas(); vector<float> CalculateBiocode(vector<float> vetMedidas); vector<float> ExtractAverage(vector<float>, vector<float>, vector<float>, vector<float>); int CountVizinhos(unsigned char ** byteMatrix,int i, int j); bool IsConector(unsigned char ** byteMatrix,int i, int j); void FecharContorno(); bool ExtractContorno(); bool ContornoValido(); void Arc(int center_x,int center_y,int rx,int ry,int iQuad); void Line(int x1,int y1, int x2, int y2); void GetNPoint(int x1, int y1, int x2, int y2, int nl, int &xn, int &yn); void GetVizinho(unsigned char ** byteMatrix, int X,int Y,int X1,int Y1,int &X2, int &Y2); vector<int> Gauss(float fSigma, vector<double> iVetor); vector<double> CalcDos(int m, int w); vector<float> DrawTriangles(vector<int> vPoints); ;
95
#include "imgObject.h" /** * Desenha uma linha entre dois pontos * * @param x1 Coordenada x do primeiro ponto * @param y1 Coordenada y do primeiro ponto * @param x2 Coordenada x do segundo ponto * @param y2 Coordenada y do segundo ponto */ void cImgObject::Line(int x1,int y1, int x2, int y2) int n, dx, dy, iTx, iTy; float t, dt, x, dxdt, y, dydt; dx = x2-x1; // Diferenca entre x dy = y2-y1; // Diferenca entre y dxdt = dx; dydt = dy; n = abs(dx) > abs(dy) ? abs(dx) : abs(dy); dt = 1. / n; // Calculo do tamanho do pulo x = x1; y = y1; /* * Pinta os pixels que fazem parte da linha */ for (t = 0; t <= 1; t += dt) iTx = (x+dxdt*t); iTy = (y+dydt*t); byteMatrix[iTx][iTy] = 0; /** * Realiza o fechamento inferior do contorno (corte do pulso) */ void cImgObject::FecharContorno() int iInicio=-1, iFim=-1; for(int i=10;i<iWidth-10;i++) for(int j=iHeight-300;j<iHeight;j++) byteMatrix[i][j] = 255; for(int i=10;i<iWidth-10;i++) if ( byteMatrix[i][iHeight-301] == 0 && iInicio == -1) iInicio = i; else if ( byteMatrix[i][iHeight-301] == 0) iFim = i; Arc(iWidth/2,iHeight-300,iFim-iWidth/2,280,3); Arc(iWidth/2,iHeight-300,iWidth/2-iInicio,280,4); /** * Desenha um arco (1/4 de circulo) referente a um dos quadrantes * de uma ellipse * * @param center_x Valor em x do ponto do centro da ellipse
96
* @param center_y Valor em y do ponto do centro da ellipse * @param rx Raio da ellipse no eixo X * @param ry Raio da ellipse no eixo Y * @param iQuad Numero do quadrante a ser desenhado seguindo o padrão: * 1 | 2 * ---+--- * 4 | 3 */ void cImgObject::Arc(int center_x,int center_y,int rx,int ry,int iQuad=0) /* termos intermediarios para realizar loop da ellipse */ long t1 = rx*rx, t2 = t1<<1, t3 = t2<<1; long t4 = ry*ry, t5 = t4<<1, t6 = t5<<1; long t7 = rx*t5, t8 = t7<<1, t9 = 0L; long d1 = t2 - t7 + (t4>>1); // Termos de erro long d2 = (t1>>1) - t8 + t5; int x = rx, y = 0; // Pontos da Ellipse while (d2 < 0) // Até que a curva resulte em -1 switch(iQuad) case 1: if(center_x - x > 0 && center_x - x < iWidth && center_y - y >0 && center_y - y < iHeight) byteMatrix[center_x - x][ center_y - y] = 0; break; case 2: if(center_x + x > 0 && center_x + x < iWidth && center_y - y >0 && center_y - y < iHeight) byteMatrix[center_x + x][ center_y - y] = 0; break; case 3: if(center_x + x > 0 && center_x + x < iWidth && center_y + y >0 && center_y + y < iHeight) byteMatrix[center_x + x][ center_y + y] = 0; break; case 4: if(center_x - x > 0 && center_x - x < iWidth && center_y + y >0 && center_y + y < iHeight) byteMatrix[center_x - x][ center_y + y] = 0; break; y++; // 1 posição para cima para alinhamento t9 += t3; if (d1 < 0) // Movimentação direta para cima d1 += t9 + t2; d2 += t9; else // Movimentação para cima e esquerda x--; t8 -= t6; d1 += t9 + t2 - t8; d2 += t9 + t5 - t8; do // finalização Quadrante superior dir. switch(iQuad) case 1: if(center_x - x > 0 && center_x - x < iWidth &&
97
center_y - y >0 && center_y - y < iHeight) byteMatrix[center_x - x][ center_y - y] = 0; break; case 2: if(center_x + x > 0 && center_x + x < iWidth && center_y - y >0 && center_y - y < iHeight) byteMatrix[center_x + x][ center_y - y] = 0; break; case 3: if(center_x + x > 0 && center_x + x < iWidth && center_y + y >0 && center_y + y < iHeight) byteMatrix[center_x + x][ center_y + y] = 0; break; case 4: if(center_x - x > 0 && center_x - x < iWidth && center_y + y >0 && center_y + y < iHeight) byteMatrix[center_x - x][ center_y + y] = 0; break; x--; // Alinhamento de 1 casa a esquerda t8 -= t6; if (d2 < 0) // Movimento cima e esquerda y++; t9 += t3; d2 += t9 + t5 - t8; else // Movimento direto a esquerda d2 += t5 - t8; while (x>=0); /** * Captura o n-esimo ponto de uma determinada reta * * * @param x1,y1 Ponto Inicial da reta * @param x2,y2 Ponto Final da reta * @return xn,yn n-esimo ponto da reta */ void cImgObject::GetNPoint(int x1, int y1, int x2, int y2, int nl, int &xn, int &yn) int n, dx, dy; double t, dt, x, dxdt, y, dydt; int iCount=0; dx = x2-x1; dy = y2-y1; dxdt = dx; dydt = dy; n = abs(dx) > abs(dy) ? abs(dx) : abs(dy); dt = n==0? 0: 1. / n; x = x1; y = y1; for (t = 0; t <= 1; t += dt) if(iCount == nl) xn = (x+dxdt*t);
98
yn = (y+dydt*t); return; iCount++; /** * Utiliza a técnica dos triangulos na imagem para extração dos valores * de comprimento e largura dos dedos * * @param vPoints Vetor de resultados do método DOS+filtragem * @return Vetor com os pontos de comprimento e largura intercalados */ vector<float> cImgObject::DrawTriangles(vector<int> vPoints) int iMidX, iMidY, iCount, iInitX, iInitY, iX=0, iY=0,iInitX2, iInitY2, iFirstX, iFirstY, iRefX, iRefY,xn,yn, iCountLine,xn1,yn1; int iContorno=0,i,j, iNumLargura, iPosX, iPosY, iPosX2,iPosY2; int iCountMedia; float fLarguraX, fLarguraY, fLarguraMedia; bool bOverSize; vector<float> vecDedos; vector<int> vLastX, vLastY; float fSize; int iFirst=-1, iSecond=-1, iLast=-1, iSecondLast=-1; try //"Cria" o primeiro e ultimo pontos, considerando o tamanho // dos anteriores + 10% for(i=0;i<vPoints.size();i++) if(vPoints.at(i) == 1 && iFirst == -1) iFirst = i; else if(vPoints.at(i) == 1 && iFirst != -1 && iSecond == -1) iSecond = i; else if(vPoints.at(i) == 1 && iFirst != -1 && iSecond != -1) iSecondLast = iLast; iLast = i; if(iFirst!=-1 && iSecond !=-1) if (iFirst-(iSecond-iFirst)-0.12*(iSecond-iFirst) >0 ) vPoints.erase(&vPoints.at(iFirst-(iSecond-iFirst) -0.12*(iSecond-iFirst))); vPoints.insert(&vPoints.at(iFirst-(iSecond-iFirst) -0.12*(iSecond-iFirst)),1); else vPoints.erase(&vPoints.at(0)); vPoints.insert(&vPoints.at(0),1); if (iLast!=-1 && iSecondLast != -1) vPoints.erase(&vPoints.at(iLast+fabs(iLast-iSecondLast) +0.12*(iLast-iSecondLast))); vPoints.insert(&vPoints.at(iLast+fabs(iLast-iSecondLast) +0.12*(iLast-iSecondLast)),1); iMidX = iWidth /2; iCount = iHeight; while(byteMatrix[iMidX][--iCount] != clBlack)
99
iInitX = iMidX; iInitY = iCount; GetVizinho(byteMatrix, iInitX, iInitY, iInitX, iInitY, iX, iY); iContorno++; iFirstX = iInitX; iFirstY = iInitY; while(iFirstX!= iX || iFirstY != iY) iInitX2 = iInitX; iInitY2 = iInitY; iInitX = iX; iInitY = iY; GetVizinho(byteMatrix, iInitX, iInitY,iInitX2, iInitY2,iX, iY); if ( vPoints.size()-iContorno >0 && vPoints.at(vPoints.size()-iContorno) == 1) vLastX.push_back(iInitX); vLastY.push_back(iInitY); iContorno++; /* * Desenha os triangulos */ for(i=1;i<vLastX.size();i++) if ( i%2 == 0 && i != 0) // Calcula o ponto do centro da base do triangulo iMidX = (vLastX.at(i) + vLastX.at(i-2))/2; iMidY = (vLastY.at(i) + vLastY.at(i-2))/2; //calcula a altura do triangulo fSize = sqrt(pow(fabs(iMidX-vLastX.at(i-1)),2) +pow(fabs(iMidY-vLastY.at(i-1)),2)); //Calculo da largura fLarguraX = (fabs(fabs(vLastX.at(i-1)) - fabs(iMidX)))/20; fLarguraY = (fabs(fabs(vLastY.at(i-1)) - fabs(iMidY)))/20; fLarguraMedia = 0; iCountMedia = 0; // Divide a linha media em diversos pontos de medida for(j=0;j<20;j++) if(iMidX > vLastX.at(i-1)) iPosX = iMidX - (fLarguraX *j); else iPosX = iMidX + (fLarguraX *j); if(iMidY > vLastY.at(i-1)) iPosY = iMidY - (fLarguraY *j); else iPosY = iMidY + (fLarguraY *j); //Calcula do ponto de referencia para reta perpendicular iRefX = iPosX - vLastX.at(i-1); iRefY = iPosY - vLastY.at(i-1); iCountLine = 1; xn = iPosX; yn = iPosY; bOverSize = false;
100
// faz a reta perpendicular para um dos lados while(xn >0 && yn >0 && xn < iWidth && yn < iHeight && byteMatrix[xn][yn] != clBlack && byteMatrix[xn+1][yn] != clBlack && byteMatrix[xn-1][yn] != clBlack && byteMatrix[xn][yn+1] != clBlack && byteMatrix[xn][yn-1] != clBlack && iCountLine < 150) GetNPoint(iPosX,iPosY, iPosX + iRefY,iPosY-iRefX, iCountLine, xn,yn); iCountLine++; if (iCountLine >=150) bOverSize = true; iCountLine = 1; xn1 = iPosX; yn1 = iPosY; // faz a reta perpendicular para um dos lados while(xn1 >0 && yn1 >0 && xn1 < iWidth && yn1 < iHeight && byteMatrix[xn1][yn1] != clBlack && byteMatrix[xn1+1][yn1] != clBlack && byteMatrix[xn1-1][yn1] != clBlack && byteMatrix[xn1][yn1+1] != clBlack && byteMatrix[xn1][yn1-1] != clBlack && iCountLine < 150) GetNPoint(iPosX,iPosY, iPosX -iRefY,iPosY+iRefX, iCountLine, xn1,yn1); iCountLine++; if (iCountLine >=150) bOverSize = true; if ( bOverSize == false) fLarguraMedia += sqrt(pow(abs(yn-yn1),2) +pow(fabs(xn-xn1),2)); iCountMedia++; vecDedos.push_back(fSize); vecDedos.push_back(fLarguraMedia/iCountMedia); return vecDedos; catch(...) ShowMessage(IntToStr(iContorno) + " " +IntToStr(i)+ " "+IntToStr(vPoints.size())); vecDedos.push_back(0); vecDedos.push_back(0); return vecDedos; /** * Passa um filtro Gaussiano em um vetor de Dos
101
* retorna os picos encontrados em um filtro de gauss+media * * @param fSigma Parametro sigma de um filtro gaussiando qualquer * @param iVetor Vetor de resultados do método DOS * @return Vetor com os valores do Dos filtrados por gauss e média */ vector<int> cImgObject::Gauss(float fSigma, vector<double> iVetor) double *dGauss; double *dMedia; double *dGaussAux; double dMediaGeral=0; int iGaussSize; int iMediaDiv; int i,j; int iSize; double dMediaSoma, dMaior; int iMediaSize; vector<int> iVetorPicos; AnsiString sAux; iSize = iVetor.size(); iGaussSize = iSize*0.1; iMediaSize = iSize*0.02; dGauss = new double[iGaussSize]; dMedia = new double[iSize]; dGaussAux = new double[iSize]; try /* Calcula a função gaussiana com um tamanho de 10% do total dos valores passados */ for(i=0;i<iGaussSize;i++) dGauss[i] = 1/fSigma*exp(-pow(i,2)/pow(fSigma,2)); for(i=0;i<iSize;i++) dGaussAux[i] = 0; for(j=0;j<iGaussSize;j++) for(i=0;i<iSize-iGaussSize;i++) dGaussAux[i+j] = dGaussAux[i+j] + iVetor[i] * dGauss[j]; catch(...) ShowMessage("Erro no calculo do Gauss " +IntToStr(i)); try dMediaGeral = 0; for(i=0;i<iSize;i++) dMediaSoma = 0; iMediaDiv = 0; for(j=i-iMediaSize/2;j<i+iMediaSize/2;j++) if ( j >= 0 && j <iSize) dMediaSoma += dGaussAux[j]; iMediaDiv++; if(iMediaDiv ==0) dMedia[i] = dMediaSoma; else dMedia[i] = dMediaSoma/iMediaDiv; dMediaGeral += dMedia[i];
102
dMediaGeral /= iSize; catch(...) ShowMessage("Erro no calculo da média " +IntToStr(i)); try i=0; int iInit; while(i<iSize) while(i<iSize && dMedia[i]< (dMediaGeral+dMediaGeral*.5)) iVetorPicos.push_back(0); i++; dMaior = 0; iInit = i; while(i<iSize && dMedia[i] >= (dMediaGeral+dMediaGeral*.5)) iVetorPicos.push_back(0); if ( dMedia[i] >= dMaior) dMaior = dMedia[i]; i++; if(i<iSize && iInit!=i) iVetorPicos.erase(&(iVetorPicos.at((int)((iInit+i-1)/2)))); iVetorPicos.insert(&(iVetorPicos.at((int)((iInit+i-1)/2))),1); catch(...) ShowMessage("Erro ao tentar achar os Picos "+IntToStr(i)); return iVetorPicos; /** * Funcao que retorna o proximo vizinho em um contorno * * @param imgMao A imagem que contem o Contorno * @param X A posicao X do ponto anterior (para definir o sentido do contorno) * @param Y A posição Y do ponto anterior (para definir o sentido do contorno) * @param X1 A posição X de onde se quer pegar o vizinho (no outro sentido de X) * @param Y1 A posição Y de onde se quer pegar o vizinho (no outro sentido de Y) * @param X2 Posição X do vizinho (retorno) * @param Y2 Posicao Y do vizinho (retono) */ void cImgObject::GetVizinho(unsigned char ** byteMatrix, int X,int Y, int X1,int Y1, int &X2, int &Y2) for(int i=X-1;i<=X+1;i++) for(int j=Y-1;j<=Y+1;j++) if(byteMatrix[i][j] == 0) if (!(i==X && j==Y) && !(i==X1 && j==Y1)) X2 = i; Y2 = j; return;
103
/** * Realiza o cálculo da diferença de curvatura de um contorno fechado qualquer * * @param iPular Tamanho entre os vetores de comparação * @param iVetSize Tamanho dos vetores * @return Um vetor com a curvatura de todos os pontos do contorno */ vector<double> cImgObject::CalcDos(int iPular, int iVetSize) int iInitX, iInitY; int iInitX2, iInitY2; int iX, iY; int X,Y; int iV11X,iV11Y,iV12X,iV12Y; // Posições inicial e final do primeiro vetor int iV21X,iV21Y,iV22X,iV22Y; // Posições inicial e final do segndo vetor int iNextX, iNextY; // Proximo ponto do contorno int iNextX2, iNextY2; // Proximo ponto do contorno para segundo vetor int i; int iCount; int iCaminho=0; int iMidX, iMidY; // Posições do primeiro pixel do contorno vector<double> iDos; int *iResult; double dAlphaV1, // Angulo do primeiro vetor com o eixo x dAlphaV2, // Angulo do segundo vetor com o eixo x dAlpha; // Diferença entre os angulos bool bInicio = true; // Flag para saber se é a primeira vez do loop try iMidX = iWidth /2; iCount = iHeight; /* * Procura pelo primeiro pixel, de baixo para cima, que faz * parte do contorno da imagem */ while(byteMatrix[iMidX][--iCount] != clBlack) iInitX = iMidX; iInitY = iCount; /* * Procura pelo pixel vizinho daquele encontrado anteriormente */ GetVizinho(byteMatrix, iInitX, iInitY, iInitX, iInitY,iX, iY); iInitX2 = iX; iInitY2 = iY; /* * Inicialização de variáveis para contornar o objeto */ X = iInitX; Y = iInitY; iNextX = X; iNextY = Y; iNextX2 = iInitX2; iNextY2 = iInitY2; i =1;
104
/* * Repetir o laço, até que o mesmo ponto no contorno seja encontrado * por isso o contorno precisa ser fechado */ while(iNextX != X || iNextY != Y || bInicio == true) iCaminho++; bInicio=false; /* * Reinicialização das variáveis de contorno */ iInitX = iNextX; iInitY = iNextY; iInitX2 = iNextX2; iInitY2 = iNextY2; iV11X = iNextX; iV11Y = iNextY; i=0; iCount = 0; /* * Percorre o contorno, até que o tamanho do vetor seja atingido * assim temos os pontos inicial e final do primeiro vetor */ while(i++ < iVetSize) iX = 0; iY = 0; GetVizinho(byteMatrix, iInitX, iInitY, iInitX2, iInitY2,iX, iY); if (iX != 0 && iY != 0) iInitX2 = iInitX; iInitY2 = iInitY; iInitX = iX; iInitY = iY; if(iCount == 0) iNextX = iX; iNextY = iY; iNextX2 = iInitX2; iNextY2 = iInitY2; iCount++; else break; iV12X = iInitX; iV12Y = iInitY; i=0; /* * Percorre o contorno, até que o tamanho do espaço ENTRE os vetores * seja atingido */ while(i++ < iPular) iY = 0; GetVizinho(byteMatrix, iInitX, iInitY, iInitX2, iInitY2,iX, iY); if (iX != 0 && iY != 0) iInitX2 = iInitX; iInitY2 = iInitY; iInitX = iX; iInitY = iY; if(iCount == 0)
105
iNextX = iX; iNextY = iY; iNextX2 = iInitX2; iNextY2 = iInitY2; iCount++; else break; iV21X = iV12X; iV21Y = iV12Y; i=0; /* * Percorre o contorno até que o tamanho do segundo vetor seja * atingido novamente, para que o angulo entre eles possa ser calculado */ while(i++ < iVetSize) iX = 0; iY = 0; GetVizinho(byteMatrix, iInitX, iInitY, iInitX2, iInitY2,iX, iY); if (iX != 0 && iY != 0) iInitX2 = iInitX; iInitY2 = iInitY; iInitX = iX; iInitY = iY; else break; iV22X = iInitX; iV22Y = iInitY; iV12X = iV21X + (iV12X - iV11X); iV12Y = iV21Y + (iV12Y - iV11Y); /* * Faz o cálculo do angulo do segundo vetor com o eixo x */ if(fabs(iV21Y - iV22Y) ==0 ) dAlphaV1 = 0; else if(fabs(iV22X - iV21X)==0) dAlphaV1 = 90; else dAlphaV1 = 180/M_PI*atan((fabs(iV21Y - iV22Y))/fabs(iV22X - iV21X)); /* * Faz o cálculo do angulo do primeiro vetor com o eixo x */ if(fabs(iV11Y - iV12Y) ==0) dAlphaV2 = 0; else if( fabs(iV12X - iV11X)==0) dAlphaV2 = 90; else dAlphaV2 = 180/M_PI*atan(fabs(iV21Y - iV12Y)/fabs(iV12X - iV21X)); /* * Faz o calculo da diferença de vetores */ if ( dAlphaV2 > dAlphaV1) dAlpha = fabs(dAlphaV2) - fabs(dAlphaV1); else if ( dAlphaV1 > dAlphaV2) dAlpha = fabs(dAlphaV1) - fabs(dAlphaV2); else if ( dAlphaV1 == dAlphaV2) dAlpha = 0; iDos.push_back((int)dAlpha); if(iCaminho > 15000) throw(0); catch(...) iDos.clear();
106
return iDos; return iDos; bool cImgObject::ContornoValido() int i,j; for(i=2;i<iWidth-2;i++) for(j=2;j<iHeight-2;j++) if(byteMatrix[i][j] == 0 && CountVizinhos(byteMatrix,i,j) > 2) return false; return true; vector<float> cImgObject::ExtractAverage( vector<float> Img1, vector<float> Img2, vector<float> Img3, vector<float> Img4) vector<float> vetResult; vector<float> vetMedias; vector<vector<float>*> vetImgs; float fMedia, fMaior; int i, k; vetImgs.push_back(&Img1); vetImgs.push_back(&Img2); vetImgs.push_back(&Img3); vetImgs.push_back(&Img4); if(Img1.size() < 10 || Img2.size() < 10 || Img3.size() < 10 || Img4.size() < 10) return vetResult; /* * Calcula a média com os valores iniciais */ for(i=0;i<10;i++) fMedia = ((Img1.at(i) + Img2.at(i) + Img3.at(i) + Img4.at(i))/4.0f); vetMedias.push_back(fMedia); /* * Loop entre os 10 "dedos" da amostra */ for(k=0;k<10;k++) fMaior = vetMedias.at(k); /* * Verifica qual das amostras tem o valor mais distante da * média inicial */ for(i=0;i<4;i++) if (fabs(vetMedias.at(k) - fMaior) < fabs(vetMedias.at(k) - (vetImgs.at(i))->at(k)))
107
fMaior = (vetImgs.at(i))->at(k); /* * Recalcula a média, desconsiderando o valor mais distante */ fMedia = ((vetImgs.at(0))->at(k) + (vetImgs.at(1))->at(k) + (vetImgs.at(2))->at(k) + (vetImgs.at(3))->at(k) - fMaior) / 3; vetResult.push_back(fMedia); return vetResult; /** * Extrai as medidas do contorno fechado usando o método Dos, e o filtrando * seu resultado. * * @return Um vetor com 10 posições equivalentes a largura e compr. dos dedos */ vector<float> cImgObject::ExtractMedidas() vector<float> vetResult; vector<double> vecDos; vecDos = CalcDos(1, 90); if(vecDos.size() > 0) vetResult = DrawTriangles( Gauss(180, vecDos ) ); return vetResult; /** * Calcula o Biocode de uma determinada amostra de 10 posições equivalentes * a largura e comprimento dos dedos (no formato dado pela saida do metodo * drawtriangles * * @param vetMedidas Vector de 10 posições com os valores de comprimento * e largura intercalados * @return Vetor de duas posições, a primeira comprimento normalizado * e a segunda largura normalizada */ vector<float> cImgObject::CalculateBiocode(vector<float> vetMedidas) float fMedidaCompr, fMedidaLarg; vector<float> vetResult; /* * Normalização do comprimento formando resultados entre 0-100 */ fMedidaCompr = (((2*vetMedidas.at(2) + 2*vetMedidas.at(4) + vetMedidas.at(6) + 0.1* vetMedidas.at(8) )-2900)*100)/900; /* * Normalização da largura formando resultados entre 0-100 */
108
fMedidaLarg = (((vetMedidas.at(3) + vetMedidas.at(5) + vetMedidas.at(7) + 0.1*vetMedidas.at(9) )-370)*100)/140; vetResult.push_back(fMedidaCompr); vetResult.push_back(fMedidaLarg); return vetResult; bool cImgObject::ExtractContorno() int iMatrix[3][3]=1,1,1,1,1,1,1,1,1; int iLimiar, iReduzir=0, i, j, iCounter=0, iCounterAux =0; unsigned char ** byteBac; bool bFirst = true; /* * Armazena a matriz original para poder retornar caso o contorno resultante * seja invalido */ byteBac = new unsigned char*[iWidth]; for(i=0;i<iWidth;i++) byteBac[i] = new unsigned char[iHeight]; for(j=0;j<iHeight;j++) byteBac[i][j] = byteMatrix[i][j]; do /* * Na primeira vez nao ha necessidade de copiar a matriz * caso na primeira vez de errado, em todas as outras a matriz * eh retornada ao estado original */ if(!bFirst) for(i=0;i<iWidth;i++) for(j=0;j<iHeight;j++) byteMatrix[i][j] = byteBac[i][j]; FiltroEspacial(iMatrix); // Passa um filtro passa-baixas /* * Caso seja uma contagem par, reduz o limiar, caso impar * aumenta o limiar */ if(iCounter % 2 ==0) iLimiar = LimiarOtsu()-iReduzir; else iLimiar = LimiarOtsu()+iReduzir; Binarizar((iLimiar==255)? 90: iLimiar); // Binarizacao FiltroEspacial(iMatrix); // Novo filtro para tirar ruidos da binarizacao Binarizar(254); // Nova binarizacao BordaVizinhanca(); // Extrai o contorno FecharContorno(); // Fecha o contorno iCounterAux = 0 ; while(AfinamentoFim() !=0 && iCounterAux < 10) iCounterAux++; // Coloca o contorno em largura 1 if(iCounter % 2 ==0) //Reduz somente nas contagens pares iReduzir++;
109
bFirst = false; iCounter++; /* * Reduções muito grandes podem gerar valores errados na amostra * caso limiar reduzido em mais de 3 tentativas, deve-se descartar * a imagem */ if(iReduzir > 5) for(i=0;i<iWidth;i++) delete byteBac[i]; delete byteBac; return false; while(ContornoValido() == false); for(i=0;i<iWidth;i++) delete byteBac[i]; delete byteBac; return true; vector<float> cImgObject::ExtractBiocode() vector<float> vecResult; ExtractContorno(); vecResult = ExtractMedidas(); if(vecResult.size() >0) return CalculateBiocode(vecResult); else return *new(vector<float>); /** * Verifica se um determinado pixel dentro de um contorno realiza uma * conexão (e portando é essencial ao contorno) * * @param byteMatrix Matriz com a "imagem" * @param i posição x do ponto * @param j posição y do ponto * @return Booleano indicando se é essencial ou não */ bool cImgObject::IsConector(unsigned char ** byteMatrix,int i, int j) int iOld, iNew, k, l; /* Um pixel essencial é aquele que quando eliminado, causa * uma descontinuacao na linha * portanto para identifica-los conta-se a quantidade de vizinhos orfaos * (com somente 1 vizinho) antes e depois da retirada, se a exclusao * do pixel nao causa o aumento dos orfaos vizinhos, entao ele não é * essencial */ if (byteMatrix[i][j] == 0) iOld =0; for(k=i-1;k<=i+1;k++) for(l=j-1;l<=j+1;l++) if(byteMatrix[k][l] == 0) if(CountVizinhos(byteMatrix,k,l)==1) iOld++; byteMatrix[i][j] = 255;
110
iNew = 0; for(k=i-1;k<=i+1;k++) for(l=j-1;l<=j+1;l++) if(byteMatrix[k][l] == 0) if(CountVizinhos(byteMatrix,k,l)==1) iNew++; byteMatrix[i][j] = 0; if (iOld == iNew) return false; else return true; else return false; /** * Conta o numero de pixels pretos na vizinhança de um determinado pixel * * @param byteMatrix Matriz com a "imagem" * @param i posição x do ponto * @param j posição y do ponto * @return Numero de pixels vizinhos (entre 0 e 8) */ int cImgObject::CountVizinhos(unsigned char ** byteMatrix,int i, int j) int h,w; int iVizinhos = 0; for(h=j-1;h<=j+1;h++) for(w=i-1;w<=i+1;w++) if((w >0 && h > 0 && w< iWidth && h < iHeight) && (byteMatrix[w][h] == 0 || byteMatrix[w][h] == 128)) iVizinhos++; /* * Caso o ponto analisado seja preto, então desconsidera-se * este como vizinho */ if ( byteMatrix[i][j] == 0) return iVizinhos-1; else return iVizinhos; /** * Funcao que converte a linha principal em uma linha de largura 1 pixel * retirando os pontos não-conectores */ int cImgObject::AfinamentoFim() int i, j,w,h,k,l; int iVizinhos; int iAlterados=0; for(i=1; i<iWidth-1;i++) for(j=1;j<iHeight-1;j++) /* * Retira todos os pontos que não são conectores */ if(byteMatrix[i][j] == 0) if (!IsConector(byteMatrix,i,j)) byteMatrix[i][j] = 255; iAlterados ++;
111
return iAlterados; /** * Extrai o contorno de uma imagem binarizada fazendo a análise de frequencia */ void cImgObject::BordaVizinhanca() int i, j; unsigned char ** byteBac; Clear(255); for(i=0; i<iWidth-1;i++) for(j=0;j<iHeight-1;j++) /* * Faz a verificação para ver se existe variacao maior que o * limiar na horizontal */ if ( byteMatrix[i][j] != byteMatrix[i+1][j]) byteMatrixAux[i][j] = 0; for(i=1; i<iWidth-1;i++) for(j=0;j<iHeight-1;j++) /* * Faz a verificação se existe variação de frequencia * na vertical, cuidando para que não sejam colocados * pontos desnecessários (não-conectores) */ if((byteMatrix[i][j] != byteMatrix[i][j+1]) && (byteMatrix[i][j] == byteMatrix[i+1][j])) byteMatrixAux[i][j+1] = 0; byteBac = byteMatrix; byteMatrix = byteMatrixAux; byteMatrixAux = byteBac; /** * Preenche a matrix com um determinado valor * * @param iValue Valor a ser preenchido (default =0) * */ void cImgObject::Clear(int iValue=0) int i,j; for(i=0;i<iWidth;i++) for(j=0;j<iHeight;j++) byteMatrixAux[i][j] = iValue; /** * Passa um filtro espacial na byteMatrix da classe, com base em pesos * atribuidos para o calculo da vizinhança *
112
* @param iMatrix Matriz com os pesos do filtro */ void cImgObject::FiltroEspacial(int iMatrix[3][3]) int i,j, iSob, jSob; unsigned char ** byteBac; float fGrad; float fValor; /* * Calcula o efeito do filtro na matriz original, colocando o resultado * na matriz auxiliar para que os resultados nao sejam influenciados * pela filtragem parcial da imagem */ for(j=0;j<iHeight;j++) byteMatrixAux[0][j] = byteMatrix[0][j]; byteMatrixAux[iWidth-1][j] = byteMatrix[iWidth-1][j]; for(i=0;i<iWidth;i++) byteMatrixAux[i][0] = byteMatrix[i][0]; byteMatrixAux[i][iHeight-1] = byteMatrix[i][iHeight-1]; for(i=1;i<iWidth-1;i++) for(j=1;j<iHeight-1;j++) fGrad = 0; /** * Calcula o gradiente Sobel sobre o pixel dado * tanto na vertical quanto na horizontal */ for(iSob=-1;iSob<=1;iSob++) for(jSob=-1;jSob<=1;jSob++) fGrad += (int)byteMatrix[i+iSob][j+jSob] * iMatrix[iSob+1][jSob+1]; fValor = fGrad/9; byteMatrixAux[i][j] = fValor; byteBac = byteMatrix; byteMatrix = byteMatrixAux; byteMatrixAux = byteBac; /** * Realiza a binarização da bytematris de acordo com o valor de um limiar * * @param iLimiar Limiar de corte para binarização */ void cImgObject::Binarizar(int iLimiar) int i,j; for(i=0;i<iWidth;i++) for(j=0;j<iHeight;j++) /** * Ajuste da imagem, joga os pontos mais proximos de branco * para branco, e os mais proximos de preto para preto * tendo como resultado uma imagem PB com a "mascara" da mão
113
*/ if(byteMatrix[i][j] > iLimiar) byteMatrix[i][j] = 255; else byteMatrix[i][j] = 0; /** * Extração automática do valor mais próximo do idela para binarizar uma imagem * levando em consideração a separação do objeto do fundo * * @return valor entre 0-255 representando o limiar de separação */ int cImgObject::LimiarOtsu() unsigned int iNumPixels[256]; float fProb[256], fMedia[256], ww[256], mu[256], mutotal[256], var[256], ratio[256]; int i, j, klimiar; float vartotal,maxratio; for(i=0;i<256;i++) iNumPixels[i] = 0; fMedia[i] = 0; // Contagem de pixels em cada nivel de cinza for(i=0;i<iWidth;i++) for(j=0;j<iHeight;j++) iNumPixels[byteMatrix[i][j]]++; // Calcula a probabilidade de cada Nivel for(i=0;i<256;i++) fProb[i] = (float) iNumPixels[i] / (iWidth*iHeight); // Seta a primeira media como a probabilidade fMedia[1] = (float) fProb[1] ; ww[1] = (float) fProb[1] ; mu[1] = (ww[1] != 0) ? fMedia[1]/ww[1] : 0.0 ; for (i = 2; i < 256; i++) ww[i] = ww[i-1] + fProb[i] ; fMedia[i] = fMedia[i-1] + (float) fProb[i]*i ; mu[i] = (ww[i] != 0) ? fMedia[i]/ww[i] : 0 ; for (i = 1; i < 256; i++) mutotal[i] = ((1-ww[i]) != 0) ? (fMedia[255] - fMedia[i])/(float)(1-ww[i]) : 0 ; /* sigmaB^2= wow1(mu1-m2)(mu1-m2) */ var[i] = ww[i]*(1- ww[i])* (mu[i] - mutotal[i])*(mu[i] - mutotal[i]) ; vartotal = 0 ; /* sigmaT^2= Soma (i-muT)^2 Pi */ for (i = 1; i < 256; i++) vartotal += (i-mu[255]) * (i-mu[255]) * fProb[i] ;
114
for (i = 1; i < 256; i++) ratio[i] = var[i]/vartotal ; /* calculo do limiar klimiar */ i = 1; maxratio = (float) ratio[i]; klimiar = i ; for (i = 2; i < 256 ; i++) if( ratio[i] > maxratio ) maxratio = (float) ratio[i]; klimiar = i ; return klimiar; /** * Desenha a bytematrix dentro de um TImage */ void cImgObject::Draw(TImage * img) int i,j; img->Width = iWidth; img->Height = iHeight; for(i=0;i<img->Width;i++) for(j=0;j<img->Height;j++) img->Canvas->Pixels[i][j] = RGB(byteMatrix[i][j],byteMatrix[i][j],byteMatrix[i][j]); /** * Contrutor */ cImgObject::cImgObject(TImage * img) int i,j; this->iWidth = img->Width; this->iHeight = img->Height; byteMatrix = new unsigned char*[iWidth]; byteMatrixAux = new unsigned char*[iWidth]; for(i=0;i<iWidth;i++) byteMatrix[i] = new unsigned char[iHeight]; byteMatrixAux[i] = new unsigned char[iHeight]; for(j=0;j<iHeight;j++) byteMatrixAux[i][j] = 0; byteMatrix[i][j] = GetRValue(img->Canvas->Pixels[i][j]); /** * Destrutor */
115
cImgObject::~cImgObject() int i; for(i=0;i<iWidth;i++) delete byteMatrix[i]; delete byteMatrix;
116
ANEXO 12 – CÓDIGO FONTE DO SOFTWARE DO 8031 ;=============================================================================== ;//|UNICENP - Centro Universitário Positivo // ;//|Núcleo de Ciências Exatas e Tecnológicas // ;//|Curso de Engenharia da Computação // ;//|__________________________________________________________________________// ;//|Módulo com programa para 8051 do Projeto final de curso: // ;//| // ;//| SISTEMA DE CONTROLE DE ACESSO POR IBUTTON // ;//| COM VERIFICAÇÃO BIOMÉTRICA DA GEOMETRIA DA MÃO // ;//| // ;//| Aluno: Guilherme Boreki // ;//|__________________________________________________________________________// ;//|==========================================================================// ;//| // ;//| // ;//| ____ ______ __ // ;//| /___/''\_ | | |_/' /`. // ;//| \_ \_ \|__| |__/' _/ // ;//| _____ \__\ ________ / _ _ ____ // ;//| /____/ \_/ ,' ,' \_ `. `. | | | |_ _ _ ___ ___ _ _| .. | // ;//| `\_ \_ \,' ,-' \__`./ | | | | \ | | _| __| ^ | ''_/ // ;//| \__\ ,' ____________ | |_| | | | | |_ |== | | | // ;//| | | | .-|\ ___________\ `\___/'_|_|_|___|___|_|_|_| // ;//| .---.----' | | | | .--------. | // ;//| | | | `\| | |01010101| | Engenharia da Computação // ;//| `---`--_ | ____| | |11100100| | // ;//| | | | |\ `\| |________| | // ;//| _/---/ \_ | \ `------------'\ // ;//| /---/' \ \ \---____\----------\ // ;//| `\__\_ _/. `. \|-o-|||| ==== ### | // ;//| `. `. `. `------------------' // ;//| /---/ `.______/__/ / // ;//| _'__/' ._ /' // ;//| | | _/\___\ /--/' // ;//| `\__`\_/ | | | // ;//| |__|___| // ;//| ................... // ;//|__________________________________________________________________________// ;//| // ;//| Informações sobre o Programa: // ;//| // ;//| O timer zero está sendo usado para atualizar o valor dos batimentos // ;//| no endereço 20h (com o valor de 21h) e zerar 21h para contagem. // ;//| th0 e tl0 sao iniciados em 3001d, tendo dois multiplicadores, // ;//| o primeiro por 16, armazenado em 22h, fazendo com q o overflow leve // ;//| 1s, o segundo em 23h, de 60, fazendo o overflow total com duração de // ;//| 1minuto, tendo a medida dos batimentos em bmp // ;//| // ;//| A abertura da porta será realizada através do bit 7 da porta P1, // ;//| quando 1 indica que a porta está aberta. // ;//| // ;//| O fechamento não é automático, portanto o bit p1.7 deve ser colocado em // ;//| zero externamente (fechando-se a porta) // ;//| // ;//| O receptáculo de leitura do iButton deve ser colocado no bit 0 da porta // ;//| p1. // ;//| // ;//| O bit p1.1 recebe um sinal indicando quando o sinal de presença do // ;//| iButton foi recebido. // ;//| // ;//| // ;//| Sempre que um iButton for lido o valor será armazenado nos 8 bytes // ;//| de memoria de 24h a 2Bh // ;//| // ;//|__________________________________________________________________________// ;//===========================================================================//
117
;//=========================================================================== ;//| ;//| Definições de Variáveis como endereços de memória ;//| ;//=========================================================================== BATIMENTOS EQU 20H ; Contagem aproximada ; de batimentos na amostra (minuto) ; anterior BATTEMP EQU 21H ; Contagem atual do minuto corrente ; de batimentos cardíacos SEGCOUNTER EQU 22H ; Valor de overflow para contagem ; de 1 segundo no timer0 MINCOUNTER EQU 23H ; Valor de overflow secundário para ; contagem de 1 minuto no timer 0 ; 60x o valor de 22h VETIBUTTON EQU 24H ; Vetor de valores do codigo do ; iButton ;//=========================================================================== ;//| ;//| Inicio do Programa ;//| ;//=========================================================================== ORG 00h SJMP main ORG 03h ; Interrupção INT0 CALL Bat_Cardiacos ; Funcao que faz a cotnagem de ; Batimentos RETI ORG 0Bh ; Interrupção do Timer 0 CALL Atualiza_Bat ; Funcao que atualiza os bat. RETI ORG 23h ; Interrupção Serial CALL Recebe_Serial RETI ORG 30h ;//=========================================================================== ;//| ;//| Função inicial de configuração do sistema ;//| ;//=========================================================================== main: MOV IE, #00h ; Zera vetor de Interrupções MOV TCON, #00h ; Zera vetor do Timer MOV TMOD, #00h ; Zera vetor tmod MOV SCON, #00h ; Zera vetor da serial MOV PCON, #00h ; Zera vetor pcon MOV TH0, #0Bh ; Timer 0 Usado para limpar o contador MOV TL0, #B9h ; de batimentos, reset a cada minuto ; Timer inicializado em 3001 usando ; os endereços 22h e 23h como ; multiplicadores MOV SEGCOUNTER, #10h MOV MINCOUNTER, #3Ch MOV TH1, #0FDh ; Timer 1 usado para auto-reload da MOV TL1, #0FDh ; serial, configurado para dar ; como resposta a velocidade de ; 19200 na transmissao MOV TMOD, #00100001b ; Timer 1 e Timer 0 em modo 1 MOV SCON, #01010000b
118
MOV PCON, #10000000b SETB ET0 ; Habilita interrupçao do timer 0 SETB IT0 ; INT0 funciona com borda de descida SETB IE0 ; Habilita int0 SETB EX0 ; Habilita interrução externa 0 SETB ES ; Habilita a interrupção da serial SETB TR0 ; Inicia o Timer 0 SETB TR1 ; Inicia o Timer 1 SETB EA ; Habilita o uso de interrupções MOV IP,#00000010b MOV P1, #00h ; Inicializa P1 com zero MOV BATIMENTOS, #00h ; Inicializa 20h com zero MOV BATTEMP, #00h ; Inicializa 21h com zero ; Inicialização do codigo do iButton MOV VETIBUTTON, #'i' MOV VETIBUTTON+1, #'b' MOV VETIBUTTON+2, #'u' MOV VETIBUTTON+3, #'t' MOV VETIBUTTON+4, #'t' MOV VETIBUTTON+5, #'o' MOV VETIBUTTON+6, #'n' MOV VETIBUTTON+7, #'.' MOV DPTR, #0000h main_loop: LCALL Verificar_iButton ; Verifica se existe ibutton na linha JC main_iButton CLR p1.1 ; Nao tem ibutton MOV A, BATIMENTOS ; Le o valor acumulado de batimentos ; (que estão no endereço 20h) MOV B, #30H ; Valor minimo para considerar ; batimentos OK (48bpm) CLR C ; Limpa Flag de subtração SUBB A,B JC main_batNoOk main_batOk: SETB p1.4 ; Seta P1 para batimentos ok LJMP main_loop_end main_batNoOk: CLR p1.4 ; Limpa P1 para poucos bat. LJMP main_loop_end main_iButton: SETB p1.1 ; Flag de que existe um ibutton PUSH IE ; Armazena IE MOV IE, #00h ; Retira todas as interrupcoes ; para nao influenciar nos tempos ; de leitura do iButton LCALL Command_Read LCALL Le_Byte_iButton MOV VETIBUTTON, A LCALL Le_Byte_iButton MOV VETIBUTTON+1, A LCALL Le_Byte_iButton MOV VETIBUTTON+2, A LCALL Le_Byte_iButton MOV VETIBUTTON+3, A LCALL Le_Byte_iButton MOV VETIBUTTON+4, A LCALL Le_Byte_iButton MOV VETIBUTTON+5, A LCALL Le_Byte_iButton MOV VETIBUTTON+6, A LCALL Le_Byte_iButton MOV VETIBUTTON+7, A POP IE ; Restaura IE
119
CLR C SUBB A, R7 JNZ main_loop LJMP main_loop_end main_loop_end: LJMP main_loop ;//=========================================================================== ;//| ;//| Faz a atualização do Valor dos baimentos neste minuto no endereço 20H ;//| ;//=========================================================================== Atualiza_Bat: MOV TH0, #0Bh ; Recarrega valores do timer MOV TL0, #B9h CLR TF0 ; Limpa flag de interrupcao do timer DJNZ SEGCOUNTER, Atualiza_Bat_Fim MOV SEGCOUNTER, #10h DJNZ 37H, Manter_Porta CLR P1.7 Manter_Porta: DJNZ MINCOUNTER, Atualiza_Bat_Fim MOV SEGCOUNTER, #10h ; Recarrega multiplicadores MOV MINCOUNTER, #3Ch MOV BATIMENTOS, BATTEMP ; Troca os valores MOV BATTEMP, #00H ; Reinicia contagem JMP Atualiza_Bat_Fim Atualiza_Bat_Fim: RET ;//=========================================================================== ;//| ;//| Faz a atualização do contador de batimentos cardiacos, no endereço 21H ;//| ;//=========================================================================== Bat_Cardiacos: INC BATTEMP Fim_Bat_Cardiacos: RET ;//=========================================================================== ;//| ;//| Recebe e decodifica o valor da porta serial, de acordo com o protocolo ;//| especificado no documento de projeto. Chamando as funções responsáveis ;//| para fornecer a resposta. ;//| ;//=========================================================================== Recebe_Serial: jnb ri, $ MOV A,SBUF ; Recebe em A o valor da serial CLR RI ; Limpa flag de recepção MOV R1,A
120
CLR C ; Limpa o Carry SUBB A,#65d ; Compara A com "A" JZ Leitura_iButton MOV A,R1 CLR C ; Limpa o Carry SUBB A,#66d ; Compara A com "B" JZ Leitura_Batimentos MOV A,R1 CLR C ; Limpa o Carry SUBB A,#70d ; Compara A com "F" JZ Abrir_Porta MOV A,R1 CLR C ; Limpa o Carry SUBB A,#71d ; Compara A com "G" JZ Echo_bat MOV A,R1 CLR C ; Limpa o Carry SUBB A,#72d ; Compara A com "H" JZ Echo_batTMP ; Caso nao seja nenhum dos codigos ; acima, retorna um eco do que ; chegou na serial MOV A,R1 CLR ti MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag de envio baixar CLR ti RETI Echo_bat: MOV A, BATIMENTOS CLR ti MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag de envio baixar CLR ti RETI Echo_batTMP: MOV A, BATTEMP CLR ti MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag de envio baixar CLR ti RETI ;//=========================================================================== ;//| ;//| Le o valor do iButton conectado a P1.0 ;//| preenche a mensagem de resposta (9 bytes) com o valor da iButton ;//| e responde usando a serial ;//| ;//=========================================================================== Leitura_iButton: MOV A, #03H ; Seta a para #03h, valor do cabeçalho ; de resposta para codigos do ibutton, ; conforme especificado no documento ; de projeto CLR ti ; Reseta Buffer de Envio MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag ser setado pelo mc MOV R2, #08h ; Seta o numero de bytes para envio(8) MOV R1, #VETIBUTTON ; Endereço inicial onde os valores ; de iButtons estão armazenados Leitura_iButton_loop8:
121
CLR ti MOV A, @r1 MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag de envio baixar MOV @r1, #'*' ; Limpa a memoria INC r1 DJNZ r2, Leitura_iButton_loop8 CLR ti RETI ;//=========================================================================== ;//| ;//| Le o valor dos batimentos na 20h e verifica se sao maiores q 50 ;//| preenche a mensagem de resposta (2 bytes) indicando se existe ;//| batimentos ou não, responde pela serial ;//| ;//=========================================================================== Leitura_Batimentos: MOV A, #04H ; Seta a para #05h, valor do cabeçalho ; de resposta para codigos do bat ; cardiaco, conforme especificado ; no documento de projeto CLR ti ; Reseta Buffer de Envio MOV SBUF,A ; Envia o valor de A JNB ti,$ ; Aguarda o flag ser setado pelo mc MOV A, BATIMENTOS ; Le o valor acumulado de batimentos ; (que estão no endereço 20h) MOV B, #30H ; Valor minimo para considerar ; batimentos OK (50bpm) CLR C ; Limpa Flag de subtração SUBB A,B ; Caso os batimentos sejam menores que ; 50, envia 55 Atraves da rotina ; Leitura_Batimentos_BatNotOk ; Caso contrario usa a ; Leitura_Batimentos_BatOk ; e envia FF (ver doc de projeto) JC Leitura_Batimentos_BatNotOk Leitura_Batimentos_BatOk: CLR ti MOV SBUF, #FFh ; Envia ffh (Valor para batmentos OK) JNB ti,$ ; Aguarda o flag de envio baixar CLR ti SJMP Leitura_Batimentos_Fim Leitura_Batimentos_BatNotOk: CLR ti MOV SBUF, #55h ; Envia 55h (Valor para nao-OK) JNB ti,$ ; Aguarda o flag de envio baixar CLR ti SJMP Leitura_Batimentos_Fim Leitura_Batimentos_Fim: RETI ;//=========================================================================== ;//| ;//| Seta a p1.7 para verdadeiro, indicando que a porta está aberta ;//| ;//=========================================================================== Abrir_Porta: SETB p1.7 ; Seta o bit p1.7, indicando q a ; porta está aberta MOV 37H, #10D ; Contador que mantem a porta 5 segs RETI ;//=========================================================================== ;//| ;//| Considera o iButton na porta p1.0 e um cristal de 11.0592 Mhz no uC
122
;//| Este procedimento envia um sinal de reset ao iButton e verifica se ;//| o pulso de presença eh retornado, o resultado é colocado no Carry ;//| 1 quando existe iButton no receptaculo e zero caso contrario ;//| ;//| Detalhes sobre as funcoes de leitura do iButton no documento ;//| Application Note 74 Reading and writting data to ibutton via ;//| serial interfaces. Dallas semicondutors ;//| ;//=========================================================================== Verificar_iButton: PUSH B ; Armazena o valor de B PUSH ACC ; Armazena o valor de A MOV A, #4 ; CLR p1.0 ; Inicia o pulso de reset MOV B, #221 ; Seta o intervalo de 480 us DJNZ B, $ ; aguarda com a linha em baixa SETB p1.0 ; Libera a linha MOV B, #6 ; Novo intervalo de tempo CLR C ; limpa o flag de presença Verificar_iButton_Aguardar: ; Finaliza quando a linha for para ; nivel alto JB p1.0, Verificar_iButton_EspNAlto ; Aguarda por 3360 us ; enquando a linha estiver em baixa DJNZ B, Verificar_iButton_Aguardar DJNZ ACC, Verificar_iButton_Aguardar ; Nenhum ibutton se a linha for ; para n. alto SJMP Verificar_iButton_Fim Verificar_iButton_EspNAlto: MOV B, #110 ; Tempo de espera ; para pulso de presença Verificar_iButton_NAlto: ORL C, /p1.0 ; Verifica se existe pulso ; de presença ; Aguarda com a linha em alta DJNZ B, Verificar_iButton_NAlto Verificar_iButton_Fim: POP ACC ; Restaura A POP B ; Restaura B RET ;//=========================================================================== ;//| ;//| Considera o iButton na porta p1.0 e um cristal de 11.0592 Mhz no uC ;//| Le 1 Byte do iButton ;//| ;//=========================================================================== Le_Byte_iButton: PUSH B ; Armazena valor de B MOV A, #0FFH ; Codigo de Leitura do iButton MOV B, #08h ; Leitura de 8 Bits Le_Byte_iButton_loop: RRC A ; Pega o Bit ACALL Envia_bit ; Envia o Bit ; Proximo Bit DJNZ B, Le_Byte_iButton_loop RRC A ; Ultimo Bit de A POP B ; Restaura B PUSH A MOV A, #01h CLR C SUBB A,B POP A
123
JC DO_CRC RET ;//=========================================================================== ;//| ;//| Considera o iButton na porta p1.0 e um cristal de 11.0592 Mhz no uC ;//| Envia 1 bit ao iButton ;//| ;//=========================================================================== Envia_bit: CLR p1.0 ; Inicia o intervalo de tempo NOP ; Aguarda para garantir que o iButton NOP ; receba o sinal baixo por pelo menos NOP ; 1 us NOP ; MOV p1.0, C ; envia o bit NOP ; Intervalo para permitir ao valor NOP ; retornado pelo ibutton para NOP ; estabilizar antes de ler o bit NOP ; NOP ; NOP ; MOV C, p1.0 ; Amostra o valor do bit PUSH B ; Armazena B MOV B, #12H ; Aguarda ateh o fim do slot de tempo DJNZ B, $ ; POP B ; restaura B SETB p1.0 ; Finaliza o slot de tempo RET ;//=========================================================================== ;//| ;//| Verificação do CRC do código do iButton (Datasheet do ds1990a) ;//| ;//=========================================================================== DO_CRC: PUSH ACC MOV A, R5 MOV R6, A MOV A, R4 MOV R5, A MOV A, R3 MOV R4, A MOV A,R2 MOV R3, A MOV A, R1 MOV R2, A MOV A, R0 MOV R1, A POP ACC MOV R0, A PUSH ACC PUSH B PUSH ACC MOV B,#8 CRC_LOOP: XRL A,R7 RRC A MOV A,R7 JNC ZERO XRL A,#18H ZERO: RRC A MOV R7,A POP ACC RR A PUSH ACC DJNZ B,CRC_LOOP POP ACC
124
POP B POP ACC ;//=========================================================================== ;//| ;//| Envio do Comando que indica leitura do codigo do iButton ;//| Usando os tempos considerando um timer de 11.059 Mhz ;//| ;//=========================================================================== Command_Read: CLR P1.0 NOP NOP NOP NOP NOP NOP NOP SETB P1.0 MOV B, #29 DJNZ B, $ CLR P1.0 NOP NOP NOP NOP NOP NOP NOP SETB P1.0 MOV B, #29 DJNZ B, $ CLR P1.0 MOV B, #28 DJNZ B, $ SETB P1.0 MOV B, #4 DJNZ B, $ CLR P1.0 MOV B, #28 DJNZ B, $ SETB P1.0 MOV B, #4 DJNZ B, $ CLR P1.0 NOP NOP NOP NOP NOP NOP NOP SETB P1.0 MOV B, #29 DJNZ B, $ CLR P1.0 NOP NOP NOP NOP NOP NOP NOP SETB P1.0 MOV B, #29 DJNZ B, $ CLR P1.0 MOV B, #28 DJNZ B, $ SETB P1.0
125
MOV B, #4 DJNZ B, $ CLR P1.0 MOV B, #28 DJNZ B, $ SETB P1.0 MOV B, #4 DJNZ B, $ RET
