reconhecimento de impressões digitais

UNIVERSIDADE FEDERAL DA BAHIA
FACULDADE DE CIÊNCIAS DA COMPUTAÇÃO
BRUNO ARGOLO BITTENCOURT DE OLIVEIRA
RECONHECIMENTO DE IMPRESSÕES DIGITAIS:
UMA APLICAÇÃO UTILIZANDO CAMPOS BLOB
Salvador
2006
BRUNO ARGOLO BITTENCOURT DE OLIVEIRA
RECONHECIMENTO DE IMPRESSÕES DIGITAIS:
UMA APLICAÇÃO UTILIZANDO CAMPOS BLOB
Monografia apresentada ao Curso de graduação em Ciências da
Computação, Faculdade de Ciências da Computação,
Universidade Federal da Bahia, como requisito parcial para
obtenção do grau de Bacharel em Ciências da Computação.
Orientador: Prof. Leopoldo Souza
Salvador
2006
AGRADECIMENTOS
Muitos foram aqueles que contribuíram para este trabalho. É a eles que me dirijo nas
breves palavras abaixo:
À Professora. Fabíola Greve e todos os participantes do GAUDI (Grupo de
Algoritmos e Computação Distribuída), especialmente Amadeu Júnior, que me
cederam materiais, indicaram fontes e me permitiram participar de seminários, que
muito contribuíram para elaboração deste trabalho.
Ao Professor Orientador Leopoldo Souza, pela dedicação e tempo gasto no processo
de orientação, e também por permitir a realização deste trabalho.
Aos meus amigos e família pela ajuda e compreensão nos momentos de que tive que
me ausentar.
À Jane minha namorada que me apoiou com paciência durante todo o processo de
desenvolvimento deste trabalho.
Muito obrigado por possibilitarem esta experiência única, que é de grande
importância para mim.
SUMÁRIO
1. INTRODUÇÃO .......................................................................................................................... 3
2. OBJETIVO ................................................................................................................................. 3
3. EMBASAMENTO TEÓRICO .................................................................................................... 4
3.1 BLOB (Binary Large Objects)............................................................................................... 4
3.2 Impressões digitais ................................................................................................................ 5
3.2.1 FM (False Match) e FNM (False Non Match) ................................................................. 5
3.2.2 Linhas Dactilares ............................................................................................................ 6
3.2.3 Núcleos e Deltas............................................................................................................. 7
3.2.4 Sistema de Henry............................................................................................................ 8
3.2.5 Minúcias (Detalhes de Galton)........................................................................................ 9
3.3 UDF (User Defined Function) ............................................................................................... 9
3.4 PostgreSQL ......................................................................................................................... 10
3.5 CYGWIN............................................................................................................................ 10
3.6 NFIS2 (NIST Fingerprint Image Software 2)....................................................................... 11
3.6.1 PCASYS ...................................................................................................................... 12
3.6.2 MINDTCT ................................................................................................................... 12
3.6.3 NFIQ ............................................................................................................................ 20
3.6.4 BOZORTH3................................................................................................................. 21
3.7 FVC 2004(Fingerprint Verification Competition): ............................................................... 22
4. PROJETO ................................................................................................................................. 23
4.1 UDFs no Postgres................................................................................................................ 24
4.1.1 UDFs em C no Postgres................................................................................................ 24
4.1.2 UDFs em Java no Postgres............................................................................................ 27
5 ESTATÍSTICAS ........................................................................................................................ 30
6. CONCLUSÕES E PERSPECTIVAS FUTURAS ...................................................................... 34
7. REFERÊNCIAS........................................................................................................................ 36
LISTA DE FIGURAS
Figura 1: FM, FNM e taxa de cruzamento.......................................................................................... 6
Figura 2: Linhas dactilares...................................................................................................................7
Figura 3: Delta e núcleo de uma impressão digital..............................................................................7
Figura 4: Sistema de linhas...................................................................................................................8
Figura 5: As cinco classes propostas por Henry, em destaque os núcleos e deltas..............................9
Figura 6: Movimentação das janelas..................................................................................................13
Figura 7: Formas de onda...................................................................................................................14
Figura 8: Mapa direcional..................................................................................................................15
Figura 9: Mapa de baixo fluxo...........................................................................................................16
Figura 10: Mapa de qualidade............................................................................................................17
Figura 11: Impressão digital antes e depois da binarização...............................................................18
Figura 12: Padrões para detecção de finais de cristas........................................................................18
Figura 13. Padrões usados para detectar minúcias.............................................................................19
Figura 14: Minúcias detectadas..........................................................................................................20
Figura 15: Gráfico das incidências de FM para os quatro bancos de dados da FVC2004.................32
Figura 16: Gráfico das incidências de FNM para os quatro bancos de dados da FVC2004..............33
Figura 16: gráfico da qualidade das impressões dos quatro bancos de dados da FVC2004..............34
LISTA DE TABELAS
Tabela 1: As quatro bases de dados da FVC 2004.............................................................................22
Tabela 2: Tipos em C equivalentes a tipos SQL para o PostgreSQL.................................................25
Tabela 3: Incidências de FM..............................................................................................................31
Tabela 4: Incidências de FNM para os quatro bancos de dados da FVC2004...................................32
Tabela 5: qualidade das impressões nos quatro bancos de dados da FVC2004.................................34
LISTA DE CÓDIGOS
Código 1: Convenção de chamada versão 1.......................................................................................25
Código 2: Exemplo de UDF versão 1.................................................................................................26
Código 3: Exemplo de como registrar uma função............................................................................26
Código 4: Definição do domain lo.....................................................................................................26
Código 5: Método run da classe RunComand....................................................................................27
Código 6: Registrando a UDF runcomand(varchar, varchar)............................................................27
Código 7: Registrando a UDF ID_extrairMinucias(oid)....................................................................28
Código 8: Extraindo as minúcias........................................................................................................28
Código 9: Registrando a UDF ID_compararMinuciasINT(oid, oid, integer)....................................29
Código 10: Comparando impressões digitais.....................................................................................30
Código 11: Buscando impressões do mesmo dedo............................................................................30
Código 12: registrando a UDF ID_qualidade(oid).............................................................................31
Código 13: Comparando os 8 primeiros dedos com todos os outros de um banco da FVC..............31
Código 14: Obtendo a taxa de FM.....................................................................................................32
Código 15: Obtendo a taxa de FNM...................................................................................................33
Código 17: obtendo a qualidade das impressões dos quatro bancos de dados da FVC2004.............34
RESUMO
O foco deste trabalho é o estudo de maneiras para incorporar o reconhecimento de
impressões digitais em um banco de dados popular e de código aberto, de modo a simplificar esse
processo para os usuários de bancos de dados, estimulando o uso desta tecnologia, visando o
aprimoramento das técnicas existentes e propondo alternativas simples e seguras para se trabalhar
com a datiloscopia.
São estudadas duas aproximações para extender o SGBD, para que seja possível fazer
todo o controle, armazenamento e comparação das impressões apenas através do mesmo.
A proposta geral é contribuir com um passo inicial para que tanto a comunidade
desenvolvedora de software livre quanto a comunidade privada possam construir aplicações de
reconhecimento de impressões digitais eficientes, seguras e integradas.
1
ABSTRACT
This paper focuses in the study of alternatives to incorporate the fingerprint recognition
technology in a popular yet open source database, in a way to simplify the fingerprint recognition
process to database users. Stimulating the use of this technology, aiming the improvement of the
existent techniques, proposing simple and safe alternatives to work with dactiloscopy.
Two different approaches are proposed to extend the DBMS (Database Management
System), in order to make it possible to control, store and compare fingerprints only throughout it.
The general proposal is to contribute with an initial push so both the free software
community and the private one may build efficient, safe and integrated fingerprint recognition
applications.
2
1. INTRODUÇÃO
Num mundo cada vez mais interconectado, a necessidade de validar a identidade de um
indivíduo de maneira rápida e segura se torna cada vez mais evidente. O reconhecimento de
impressões digitais, abordado na biometria, vem se mostrando uma alternativa promissora no que se
refere aos meios automáticos de identificação pessoal.
A biometria aborda diversos meios de identificação pessoal, reconhecimento pela face,
retina, íris, voz, entre outros. A datiloscopia é a parte da biometria que estuda o reconhecimento de
impressões digitais. Esta ciência vem sendo usada desde 1893 quando o Home Ministry Office, do
Reino Unido, concordou que dois indivíduos distintos não podem ter as mesmas impressões digitais
(Maio et al., 2003). Logo após isto, grandes departamentos criminais adotaram a idéia de registrar
as impressões digitais de todos os criminosos capturados.
Apesar da improvisação de métodos para aumentar a eficiência do reconhecimento
manual das impressões, o crescimento excessivo da demanda e a lentidão da realização de todo o
processo de reconhecimento levou os departamentos da lei a depreender esforços consideráveis em
pesquisas sobre a automação do reconhecimento de impressões digitais. Estes esforços culminaram
com surgimento dos AFISs (Automatic Fingerprint Identification Systems) (Maio et al.,2003).
Primeiramente usados pelas agências de manutenção da lei, os AFIS logo se revelaram
como uma boa tática para redução do número de fraudes em aplicações comerciais, seja em catracas
eletrônicas, gerenciamento de informações de cunho confidencial ou simplesmente para destravar o
teclado de um celular.
2. OBJETIVO
Tornar a tecnologia de reconhecimento de impressões digitais mais segura e acessível à
comunidade por meio do encapsulamento das funções de reconhecimento e classificação de
impressões digitais em banco de dados livre e do armazenamento das impressões propriamente ditas
também no banco de dados através de campos BLOB (Binary Large Objects), possibilitando, ainda,
uma maior visibilidade da tecnologia pelos desenvolvedores de software livre e por empresas
privadas. Aumentando, possivelmente, o interesse destas nesta tecnologia, o que traria grandes
benefícios ao desenvolvimento da área.
3
3. EMBASAMENTO TEÓRICO
3.1 BLOB (Binary Large Objects)
Muitos dos antigos sistemas de bancos de dados foram desenvolvidos para manipular
dados pequenos, representados em campos de 255 bytes ou menos. Campos grandes constantemente
apresentavam problemas para os SGBDs (Sistema de Gerenciamento de Banco de Dados) (Shapiro
et al., 1999).
SGBDs mais recentes apresentam suporte a campos LOBs (Large Objects), nos quais é
possível armazenar grandes quantidades de dados. Os campos BLOB são nada mais do que campos
LOB, porém com conteúdo binário, uma vez que campos LOB podem conter texto em ASCII, por
exemplo.
Muitas das pesquisas feitas sobre o desenvolvimento de mecanismos para gerenciar
sistemas de dados com campos LOB têm como foco os seguintes objetivos (Shapiro et al., 1999):
•
Alocação e desalocação devem ser eficientes;
•
O gerenciador de campos LOB deve ter boa performance de I/O (Input / Output), sendo que
as operações de leitura e escrita devem alcançar taxas próximas às de transferência de disco;
•
Campos LOB devem ser recuperáveis, mas o processo de recuperação não deve tornar as
operações no campo mais lentas.
Pesquisas em sistemas de bancos de dados e de sistemas de arquivos resultaram em
mecanismos de armazenamento rápidos e eficientes, o que faz os usuários de bancos de dados se
perguntarem cada vez mais sobre as vantagens de se utilizar armazenamento em BLOB (Shapiro et
al., 1999).
Kurt (Löwnertz, 1998) comenta no livro Change and Exchange que os sistemas de
gerenciamento eletrônico de documentos mais integrados e seguros são aqueles que usam campos
BLOB. O argumento utilizado é que os documentos devem ser acessados somente pelo sistema de
gerenciamento para que uma integração total do processo possa ser assegurada. Ninguém pode criar
editar ou apagar um documento sem passar pelo SGBD. Além disso, existe a possibilidade de
utilização dos mecanismos de controle de integridade, transação e controle de concorrência,
eliminando possíveis problemas de inconsistência. Por outro lado, essa idéia esbarra no problema
do pouco conhecimento que o SGBD possui sobre o dado armazenado como BLOB (na verdade o
BLOB é considerado uma "caixa preta") (Queiroz, 2002). O SGBD não fornece mecanismo para
4
possibilitar a criação de índices ou criação de operações sobre estes campos, sendo necessário o
desenvolvimento de "extensões" do SGBD para poder trabalhar com estes campos (Queiroz, 2002).
A armazenagem em campos BLOB tem seu preço. Os arquivos podem ocupar mais
espaço e a leitura e escrita se tornarem mais lentas. Porém, neste projeto não entraremos no mérito
sobre qual sistema de armazenamento é mais eficiente, mas simplesmente construiremos uma
aplicação que utilize armazenamento em campos BLOB aplicado no reconhecimento de impressões
digitais.
3.2 Impressões digitais
No que se refere à aquisição, existem duas maneiras mais utilizadas: uma é a impressão
tintada, onde o individuo mela o dedo com tinta e rola o mesmo sobre um papel, na intenção de não
ocorrerem borrões e manchas, mas, ainda assim, os mesmos ocorrem rotineiramente, seja por falta
ou excesso de tinta ou ainda pela execução errada do movimento de rolagem do dedo (Chong et al.,
1992), (Hong et al., 1996). Se a qualidade não corresponder a um padrão aceitável torna-se
extremamente difícil a verificação da impressão (Coetze et al., 1993), (Eleccion, 1973); o outro
método consiste na utilização de um sensor biométrico, onde a impressão é lida diretamente do
dedo da pessoa através de um scanner.
Dependendo do domínio da aplicação um sistema biométrico pode operar on-line ou
off-line. Um sistema on-line tem fortes restrições quanto ao tempo de resposta e é, em geral,
completamente automático. Sistemas off-line podem ter menor restrição de tempo e a atividade
pode ser supervisionada por um técnico. Por exemplo, em um sistema prisional um expert forense
pode guiar a coleta das impressões podendo garantir um maior nível de qualidade das impressões.
3.2.1 FM (False Match) e FNM (False Non Match)
Um sistema biométrico típico comete dois tipos de erros: falsa aceitação (FM - FALSE
MATCH) e falsa rejeição (FNM - FALSE NON MATCH) (Maio et al., 2003). A falsa aceitação
ocorre quando o sistema verifica erroneamente a legitimidade de um impostor. Já na falsa rejeição o
individuo legitimo não é reconhecido quando duas de suas impressões são verificadas.
As taxas de FM e FNM são dependentes uma da outra. Uma baixa taxa de FM conduz a
uma alta taxa de FNM e vice-versa. O número de minúcias que serão comparadas é dependente do
nível de segurança especificado. Quanto maior a segurança, maior é o número de minúcias
verificadas, mas isso aumenta a taxa de falsa rejeição (Costa, 2001), podendo gerar transtornos para
os usuários do sistema. A relação entre as taxas de FM e FNM é mostrada na figura 1.
5
Figura 1: FM, FNM e taxa de cruzamento.
Taxas de FM e FNM não foram levantadas para este projeto já que isso é uma preocupação
específica do tipo de aplicação no qual o sistema será utilizado.
3.2.2 Linhas Dactilares
Na literatura, a caracterização de aspectos de impressões digitais tem sido apresentada
por Galton (Karu et al., 1996), Henry (Henry, 1905) e pelo FBI (FBI, 1984). Galton foi o primeiro a
fazer um estudo dos aspectos das impressões digitais (Costa, 2001).
Galton constatou que a impressão digital é formada por linhas, chamadas de linhas
dactilares. Essas linhas se dividem em cristas e vales, onde as cristas são formadas pela parte em
relevo das linhas, e os vales situam-se entre duas cristas. Em uma imagem, tanto em papel, como
em meio magnético, as cristas são representadas pela parte escura da imagem, e os vales pela parte
clara (Oliveira, 2002).
6
Figura 2: Linhas dactilares.
3.2.3 Núcleos e Deltas
Henry foi o primeiro a dividir as impressões em diferentes classes, definindo um
sistema de classificação designado de o sistema de Henry (Rao et al., 1978).
Para se classificar as impressões são utilizados pontos singulares chamados núcleos e
deltas (figura 3)
Figura 3: Delta e núcleo de uma impressão digital.
O núcleo fica localizado na área central da impressão digital (Costa, 2001). O delta é
um ângulo ou triângulo formado pelas cristas e pode ser formado pela bifurcação de uma linha
simples ou pela brusca divergência de duas linhas paralelas. Os deltas representam o ponto de
divergência das linhas dactilares mais internas que tendem a envolver a região nuclear de uma
impressão digital. Em impressões digitais isentas de pontos delta, verifica-se somente os sistemas
de linhas basilar e marginal, caso dos arcos planos. As impressões que apresentam um ou dois
deltas, possuem três sistemas de linhas denominados: nuclear (região central de impressão), basilar
(linha que serve de base, abaixo da região nuclear) e marginal (região das características situadas
nas margens de impressão) como mostrado na figura 4.
7
Figura 4: Sistema de linhas.
3.2.4 Sistema de Henry
Este sistema classifica as impressões digitais em cinco classes. São elas:
•
Arco Plano: Não apresentam delta, as linhas são levemente curvas, atravessando o dado de
um lado ou outro.
•
Arco Angular: Apresentam acentuada elevação das linhas no centro, em forma de tenda.
Pode apresentar um delta, mas sem linha ou fragmento de linha entre o delta e o núcleo.
•
Presilha Interna (Direita): Apresenta um delta à direita do observador, as linhas dactilares
correm para a esquerda em forma de laçadas, ou seja, as linhas formam-se à esquerda do
observador, curvam-se e tendem a voltar para o mesmo lado.
•
Presilha Externa (Esquerda): Apresentam um delta à esquerda do observador, as linhas
dactilares correm para a direita do observador, ou seja, as linhas formam-se na direita do
observador, curvam-se no centro da impressão e tendem a voltar para o mesmo lado.
•
Verticilo: Apresentam dois deltas, sendo um à direita e outro à esquerda o observador; as
linhas nucleares ficam encerradas entre os dois deltas, assumindo configurações variadas.
8
Figura 5: As cinco classes propostas por Henry, em destaque os núcleos e deltas.
Segundo O FBI (Federal Bureau of Investigation), foi constatado que 65% dos padrões
são presilhas, 30% são verticilos e 5% são arcos (Moayer et al., 1975).
3.2.5 Minúcias (Detalhes de Galton)
As minúcias são acidentes que se encontram nas cristas, quando estas terminam
abruptamente ou se bifurcam. O conjunto de acidentes (minúcias) em uma impressão digital é único
e pode ser usado para distinguir um ser humano de outro. Segundo Costa (2001), doze minúcias
encontradas em uma impressão digital são suficientes para que seja feita a identificação de uma
pessoa.
O retorno de um programa comparador de minúcias é geralmente um score ou
pontuação, que indica o grau de similaridade entre as impressões ou simplesmente a quantidade de
minúcias em comum. Para tomar a decisão se as impressões são de um mesmo dedo utiliza-se um
ponto de corte t. Se a quantidade de minúcias em comum nas duas impressões ultrapassar o valor de
t então temos um casamento, do contrário dizemos que as duas impressões não puderam ser
verificadas como pertencendo ao mesmo dedo.
3.3 UDF (User Defined Function)
Em bancos de dados SQL (Structured Query Language) uma UDF é um mecanismo
para estender as funcionalidades do SGBD ao se criar funções que podem ser usadas nos comandos
9
SQL. UDFs podem ser invocadas do mesmo modo que as funções intrínsecas do SGBD, como a
função replace (varchar, varchar, varchar), por exemplo.
Conceitualmente a UDF é executada uma vez por linha da consulta, por exemplo, numa
tabela de elementos químicos, chamada “ELEMENTOS”, onde cada elemento tem seu ponto de
fusão em Farenheights, poderíamos construir uma UDF chamada FarenheightToCelsius (float) onde
ao rodar o comando SQL: SELECT elemento, FarenheightToCelsius( pontoFusao ) as pontoFusao FROM
ELEMENTOS
será retornado o nome do elemento e o ponto de fusão em Celsius para cada linha da
tabela.
UDFs não devem ser confundidas com Stored Procedures. Esta última permite apenas
que o usuário agrupe comandos SQL ou de outra linguagem. Ela pode aceitar parâmetros e executar
comandos mas não é uma expressão e portanto não pode ser usada como uma UDF.
3.4 PostgreSQL
PostgreSQL é um sistema de gerenciamento de dados objeto-relacional, baseado no
Postgres 4.2, desenvolvido na Universidade da Califórnia no departamento de Ciências da
Computação. O Postgres foi pioneiro em diversos conceitos que apenas se tornaram disponíveis em
bancos de dados comerciais muito tempo depois.
O PostgreSQL suporta grande parte dos padrões SQL e devido a seu tipo de licença
BSD (Berkeley Software Distribution), pode ser modificado e distribuído por qualquer um
gratuitamente e para qualquer propósito, seja privado, comercial ou acadêmico, de código aberto ou
fechado.
Este foi o SGBD escolhido, pois além de ser um sistema aberto com licença flexível o
PostgreSQL é um banco altamente flexível onde UDFs e Procedures podem ser construídas em
mais de uma dúzia de linguagens diferentes.
3.5 CYGWIN
O CYGWIN é um ambiente LINUX para Windows, que consiste de duas partes: uma
DLL dygwin1.dll que age como uma camada de emulação de API provendo grande parte das
funcionalidades das APIs do LINUX e um conjunto de ferramentas que provêm acesso as estas
funcionalidades, entre estas ferramentas está um SHELL LINUX.
10
O CYGWIN não roda aplicativos nativos do Linux. É necessário recompilar a aplicação
para que a mesma possa rodar. O mesmo também não serve para tornar aplicativos linux cientes das
funcionalidades UNIX.
3.6 NFIS2 (NIST Fingerprint Image Software 2)
Em conjunto com o GAUDI (Grupo de Algoritmos e Computação Distribuída) da
UFBA (Universidade Federal da Bahia), com o qual foi obtida maior parte da bibliografia sobre
impressões digitais, foi obtido ainda o pacote de softwares NFIS2, pertencente ao NIST (National
Institute of Standards and Technology) e ao FBI (Federal Bureal of Investigation).
O FBI vem utilizando tecnologia digital para ajudar a colher, guardar e localizar
impressões desde 1970. No começo dos anos noventa, a agência começou a desenvolver uma
sistema para permitir o compartilhamento de impressões digitais entre diferentes agências. Este
sistema é chamado de IAFIS (Integrated Automated Fingerprint Identification System).
Ao longo dos anos o FBI acumulou mais de quarenta milhões de impressões e chegam a
lidar com mais de sessenta mil requisições diárias relacionadas às mesmas. A demanda, originada
inicialmente para dar suporte a investigações criminais, começaram também a abranger pedidos
para condução de checagem de civis, a carga de trabalho que era antes 80% criminal e 20% civil
está rapidamente se aproximando de 50% criminal e 50% civil.
Devido à necessidade de um grande melhoramento na velocidade, a qualidade da
verificação automática de impressões digitais o FBI em conjunto com o NIST criou o NFIS. Este
pacote, agora na versão 2, contém código fonte em C e roda na plataforma Unix, mas pode ser
compilado no Windows usando o CYGWIN. O NFIS2 é dividido em sete pacotes dos quais apenas
cinco serão usados neste projeto, são eles:
o PCASYS: Classificador impressões digitais
o MINDTCT: Detector de minúcias.
o NFIQ: Rede neural para detecção da qualidade da imagem
o BOZORTH3: um sistema de comparação de minúcias
o IMGTOOLS: pacote de softwares manipuladores de imagens.
Destes pacotes merecem destaque o MINDTCT e o BOZORTH3, que juntos são
responsáveis pela identificação de uma impressão digital. O PCASYS e o NFIQ podem ser
11
utilizados meramente como forma de aumentar performance do sistema ao possibilitar a criação de
índices.
3.6.1 PCASYS
Possibilita a classificação das impressões em um dos seguintes tipos: arco, arco angular,
presilha esquerda, presilha direita, verticilo e cicatriz. Não será usado neste projeto pelo fato de só
trabalhar com impressões pertencentes ao SD14 (NIST special database 14).
3.6.2 MINDTCT
Os algoritmos usados no MINDTCT foram inspirados pelo "Home Office's Automatic
Fingerprint Recognition System" especialmente o conjunto de algoritmos comumente referidos
como "HO39".
O MINDTCTD foi desenvolvido para receber uma imagem scaneada a 19,9 ppmm e
com 256 níveis de cinza. O programa pode ler arquivos nos formatos: ANSI/NIST, WSQ (Wavelet
Scalar Quantization), JPEGL (JPEG Loss Less), e formatos IHEAD.
a. Geração de mapas de qualidade de imagem
Devido ao fato de que a qualidade da imagem de uma impressão digital poder variar,
especialmente no caso de impressões latentes (impressões deixadas em cenas de crime), torna-se
crítica a possibilidade de analisar a imagem e determinar áreas degradadas. Diversas características
podem ser medidas para se obter uma representação da qualidade da área. O que inclui determinar o
fluxo direcional das cristas, regiões de baixo contraste, pequeno fluxo de cristas e grandes
curvaturas. Estas três últimas condições representam áreas instáveis na imagem onde a detecção das
minúcias não é confiável.
a.1 Mapa Direcional
Este é um mapa de fluxo das cristas, que tem como propósito representar áreas da
imagem com estrutura de cristas suficientes para a detecção de minúcias. Cristas visíveis e bem
formadas são essenciais para que se possa haver confiança na detecção das minúcias. O mapa
direcional guarda ainda a orientação geral das cristas.
A técnica usada pelo MINDTCT para fazer o mapa direcional consiste em dividir a
imagem em blocos de 8x8 pixels, onde todos os pixels de cada bloco recebem os mesmos
resultados. Ao usar a estratégia de blocos deve-se escolher a área necessária para extrair as
informações. O MINDTCT utiliza uma janela de 24 pixels de onde são extraídas as informações
para determinar a direção do fluxo das cristas de um bloco. O centro da janela é posicionado no
12
centro do bloco como mostrado na figura 01. Este processo ajuda a diminuir a descontinuidade da
direção dos fluxos das cristas.
Figura 6: movimentação das janelas.
A última linha da figura 06 ilustra o funcionamento do esquema de janelas. Na figura os
blocos estão representados pela linha e coluna, ou seja, o bloco 1,1 é o bloco na linha 1 coluna 1. A
imagem mais à esquerda mostra o bloco 1,1 sendo computado, em seguida a janela se move um
bloco para a direita; estamos agora na segunda imagem onde o bloco 1,2 é computado; em seguida
vem o bloco 2,1 e o 2,2.
Uma vez descrito o modus operandi do esquema de janelas e blocos, podemos explicar
como se dá o processamento em cada bloco. Para cada bloco, a janela é rotacionada
incrementalmente em ângulos de 11,25º e para cada rotação uma transformada de Fourier discreta é
feita e armazenada para cada bloco.
Para determinar a direção do fluxo das cristas em cada bloco cada uma das orientações
da janela é analisada. Dentro de cada orientação as linhas da janela são somadas formando um vetor
de 24 somatórios de linhas. As 16 orientações geram um vetor com 16 vetores de somatórios de
linhas. Cada vetor deste é sobreposto a quatro tipos de onda de freqüências crescentes. Isto é
13
mostrado na figura 7. A primeira forma de onda tem um único período, a segunda tem dois
períodos, a terceira tem quatro períodos e a quarta tem oito períodos. Os valores de seno e co-seno
são calculados para cada unidade do vetor. O quadrado do seno é somado ao quadrado do co-seno
produzindo um coeficiente de ressonância que representa quão bem o vetor se encaixa na forma de
onda.
Figura 7: formas de onda.
A primeira forma de onda representa as cristas e vales com largura de cerca de 12
pixels. A segunda forma de onda representa cristas e vales com 6 pixels de largura. A terceira forma
de onda representa cristas e vales com 3 pixels de largura. Finalmente a quarta forma de onda
representa cristas e vales com 1,5 pixel de largura. Dadas imagens de 19,69 ppmm este
procedimento cobre cristas e vales com valores que vão de 0,6mm a 0,075mm.
14
Figura 8: mapa direcional.
a.2 Mapa de baixo contraste
Em alguns casos é difícil ou até impossível determinar a direção dominante em certas
partes da imagem, principalmente em áreas de baixo contraste ou com manchas e borrões. É
desejável realizar a detecção destas áreas e prevenir que sejam associadas direções de fluxo de
cristas artificialmente às mesmas. Minúcias não são detectadas em áreas de baixo contraste.
Uma maneira de distinguir blocos com baixo contraste de blocos, com cristas bem
definidas é comparar a distribuição das intensidades dos pixels. Numa área com baixo contraste a
intensidade varia pouco entre os pixels. Já quando as intensidades dos pixels variam de muito alto
para muito baixo isto quer dizer que a área apresenta cristas bem definidas.
a.3 Mapa de baixo fluxo
É possível que ao derivar o mapa direcional alguns blocos fiquem sem direção
dominante. Estes blocos geralmente são áreas de baixa qualidade. Então, alguns destes blocos terão
direção definida com base nos seus vizinhos. Porém, é gerado um mapa que guarda quais blocos
não tiveram a direção definida no primeiro momento. Estes blocos ganham graus de
confiabilidade/qualidade menores do que outros. O mesmo ocorre em áreas com grandes curvaturas,
principalmente com os deltas. No caso de uma minúcia ser identificada numa área de grande
curvatura esta minúcia ganha um grau de confiabilidade/qualidade baixo. A figura 9 mostra
marcadas com cruzes brancas as áreas de grande curvatura.
15
Figura 9: mapa de baixo fluxo.
a.4 Mapa de qualidade
Como vimos, os blocos de baixo contraste, grandes curvaturas ou aqueles a que não
foram atribuídas direções numa primeira análise apontam para blocos de baixa qualidade, que
culminam na formação de um mapa de qualidade como mostrado na figura 10, onde cada número
representa um fator de qualidade do bloco de mesma posição:
16
0000000000000000000000000000000000000000000000000
0111111122222222112222222222222222222222211000000
0112222233333333333444444444444444444444333211100
0122222223233444444444444444444444444444433321110
0122222223333444444444444444444444444444443332210
0122233233333444444444444444444444444444444333210
0122333333344444444444444444444444444444444444210
0123333333444444444444444444444443333344444444210
0123334444444444444444444444444443333344444444210
0124444444444444444444444444444443323344444444210
0124444444444444444444444444444433333333444444210
0124444444444444444444444444444433333333344444210
0124444444444444444444444444444433233233333344210
0124444444444444444444444444444433333323333344210
0124444444444444444444444444444433333333323344210
0124444444444444444444444444444444443333333344210
0124444444444444433333444444444444444443333344210
0124444444444444333333444444444444444444444444210
0124444444444444332233444444444444444444444444210
0124444444444444332233444444444444444444444444210
0124444444444444333333444444444444444444444444210
0124444444444444333333444444444444444444444444210
0124444444444444444444444444444444444433333444210
0114444444444444444444444444444444444433333444210
0114444444444444444444444444444444444433233444210
0114444444444444444444444444444444444433333444210
0113444444444333333333343333334444444433333444210
0113444444444333333333333333334444444444444444210
0014444443333334333323332333333444444444444444210
0001111111111111111111111111111111111111111111110
0000000000000000000000000000000000000000000000000
Figura 10: mapa de qualidade.
b. Binarização da imagem
O algoritmo de detecção de minúcias foi desenvolvido para trabalhar com imagens
binárias (pretas e brancas). Uma técnica para binarizar imagens é o algoritmo de Threshold.
Threshold é uma palavra da língua inglesa que significa limiar, limite. O algoritmo do threshold
baseia-se em escolher um ponto limite para o nível de cinza (no caso de 0 a 255) e transformar
todos os pixels abaixo ou neste limite em 0 e todos acima deste limite em 1. Desta forma temos a
binarização da imagem que deixará de ser em níveis de cinza para se tornar preta e branca. É
importante notar que devido aos diferentes níveis de contraste e qualidade das diferentes áreas de
uma mesma impressão digital, o ideal é dividir a imagem em pequenos blocos de 8x8 ou 10x10
pixels, e então calcular um ponto limite diferente para cada um desses blocos, isso se chama
threshold adaptativo. A figura 11 mostra uma imagem antes e depois da binarização.
17
Figura 11: impressão digital antes e depois da binarização.
c. Detecção de minúcias:
Este passo consiste em scanear a imagem binária em busca de padrões que indiquem o
fim ou a bifurcação de cristas. Um destes padrões pode ser verificado na figura 12. O padrão mais à
esquerda contém 6 pixels binários em uma configuração 2x3. Este padrão representa o fim de uma
crista que veio da direita. O mesmo ocorre com o próximo padrão e o depois deste, na verdade o
este conjunto de padrão podem ser representados como mostrado no padrão mais à direita.
Figura 12: padrões para detecção de finais de cristas.
Candidatos à minúcia são detectados ao se scanear consecutivos pares de pixels em uma
imagem procurando seqüências que casem com os padrões. Os scaneamentos são feitos vertical e
horizontalmente, para fazer a varredura horizontal basta rotacionar os padrões no sentido horário.
Usando esta representação uma série de padrões de minúcias é descrito como mostrado
na figura 13. São dois padrões representando finais de cristas e o resto representa diferentes
18
bifurcações de cristas. Os padrões recebem ainda o atributo apearing/disapearing que serve para
representar a direção da qual a crista veio.
Figura 13. Padrões usados para detectar minúcias.
d. Remoção de minúcias falsas:
Com a utilização destes padrões minúcias são detectadas usando apenas seis pixels. Isso
minimiza as chances de não se detectar uma minúcia mas em compensação muitas falsas minúcias
são detectadas, sendo necessário removê-las.
Neste passo, fragmentos de finais de cristas e marcas de tinta indesejáveis (ilhas) e
possíveis pontos vazios dentro das cristas são removidos. Também são removidas as minúcias
detectadas sobre áreas nas quais não foram detectados a direção do fluxo das cristas, ou localizadas
em áreas marcadas como de baixa qualidade.
e. Atribuição de qualidade às minúcias
Mesmo com a remoção de minúcias falsas, muitas destas minúcias persistem, e um
sistema para medir a qualidade da minúcia pode ajudar a diminuir o impacto das minúcias falsas na
medida que podemos dar preferência a comparação das minúcias de mais alta qualidade.
Dois fatores são combinados para se produzir uma pontuação de qualidade para cada
minúcia detectada. O primeiro fator é pego diretamente do mapa de qualidade, com quatro sendo a
maior e zero a menor qualidade. O segundo fator é baseado em estatísticas simples dos pixel (média
e desvio padrão) imediatamente vizinhos num raio de 11 pixels. Uma região de alto contraste na
impressão terá um nível de contraste significativo que deve cobrir toda a escala cinza (de 0 a 255).
Conseqüentemente, a média da intensidade dos pixels nas vizinhanças deve estar bastante perto de
19
127. Por razões similares a intensidade de pixel de uma vizinhança ideal deve apresentar um desvio
padrão maior que sessenta e quatro.
f. Saída
O MINDTCT gera como saída originalmente os quatro mapas supracitados e um
arquivo contendo as minúcias extraídas contendo as informações: condenadas x e y, a direção ou
orientação do bloco onde a minúcia se encontra t, e um nível de qualidade gerado como descrito
acima. Na figura 14 pode-se ver uma representação gráfica do arquivo de saída.
Figura 14: minúcias detectadas.
As saídas referentes aos mapas existem apenas com o fim de se estudar o algoritmo, e
como já foram usadas para computar o arquivo contendo as minúcias elas não são necessárias.
Portanto para os objetivos deste projeto foi alterado o código fonte em C do MINDTCT para que a
saída do programa seja apenas as minúcias detectadas.
3.6.3 NFIQ
O NFIQ é o software que determina a qualidade de uma impressão utilizando-se de uma
rede neural. Ele atribui um nível de qualidade de 1 a 5, onde 1 representa o nível mais alto de
qualidade e 5 o nível mais baixo. Deve-se ter em mente que o NFIQ não distingue imagens que são
impressões de imagens que não são impressões. Ou seja, não se deve esperar que ao executar o
NFIQ numa imagem que não seja uma impressão digital, seja atribuído necessariamente um valor
baixo de qualidade.
20
3.6.4 BOZORTH3
O BOZORTH3 é o programa que faz o casamento entre as impressões digitais, sua
entrada é a saída do MINDTCT. Este algoritmo é insensível a rotações e translações e tem três
passos principais:
•
Construir duas tabelas de comparação de minúcias, uma para cada impressão.
•
Construir uma tabela de compatibilidade entre as impressões
•
Percorrer a tabela de compatibilidade e acumular o número de minúcias em comum.
a. Construção das tabelas de comparação
O primeiro passo do algoritmo é computar medidas relativas de cada minúcia de uma
impressão em relação a todas as outras minúcias do mesmo dedo. Estas medidas relativas são
guardadas numa tabela de comparação de minúcias e é o que provê a insensibilidade do algoritmo
às rotações e translações.
Para o caso de translações são acumuladas as distâncias entre as minúcias, que são
relativamente invariantes apesar da elasticidade da pele forçar com que trabalhemos com uma
margem de complacência.
Para resolver o problema das rotações são extraídas medidas dos ângulos entre a linha
que liga duas minúcias e a orientação das minúcias, o que torna as medidas invariantes à rotação.
b. Construção das tabelas de compatibilidade
Neste passo pegam-se as duas tabelas de comparação e procuram-se entradas
compatíveis entre as duas tabelas gravando-as da tabela de compatibilidade. Para saber se as
entradas são compatíveis testa-se se as distancias estão dentro de uma tolerância Td. Depois testamse se os ângulos formados entre as orientações das minúcias e a linha que as liga está dentro de uma
tolerância TӨ.
Se a distância relativa e os ângulos das minúcias estiverem dentro das tolerâncias
aceitáveis será gravada a relação entre os dois pares de minúcias na tabela de compatibilidade.
c. Percorrer a tabela de compatibilidade
Após construir as tabelas de compatibilidade, pode-se notar que esta é apenas uma lista
de links separados entre duas minúcias que forma um grafo de compatibilidade. Para determinar
quão bem duas impressões batem deve-se percorrer o grafo achando o maior caminho de
associações de minúcias. A pontuação será então o tamanho do maior caminho do grafo.
21
d. Resultado
Idealmente a pontuação deve ser alta se as duas impressões forem do mesmo dedo e
baixa se não forem. A construção da tabela de compatibilidade dificilmente consegue representar
todas as minúcias compatíveis sendo que a pontuação final do programa não é ótima. A pontuação
representa de forma imprecisa o número de minúcias em comum entre as duas impressões. Como
regra geral um escore maior do que 40 indica um casamento com boa margem de segurança, porém
dependendo da aplicação podem ser usados escores menores ou maiores aferindo diretamente as
taxas de FM e FNM.
Por padrão apenas as 150 melhores minúcias são reconhecidas pelo MINDTCT para
cada dedo, apesar de uma impressão ter tipicamente menos do que 80 minúcias. Isso quer dizer que
o BOZORTH3 pode ser usado mesmo quando o extrator de minúcias é muito sensível e gera muitas
minúcias falsas. Pode-se ainda definir no BOZORTH3 quantas minúcias serão levadas em
consideração para o casamento.
3.7 FVC 2004(Fingerprint Verification Competition):
A FVC é uma competição internacional de algoritmos de reconhecimento de impressão
digital. Os algoritmos não são disponibilizados, mas as bases de dados nas quais os mesmos
trabalham sim. São quatro bases de dados, três de impressões reais e um de impressões sintéticas
criadas com o software SfinGe v3.0.
DB1
DB2
DB3
DB4
Tipo do sensor
Sensor ótico
Sensor ótico
Sensor termal de varredura
SFinGe v3.0
Tamanho da imagem
640x480 (307 Kpixels)
328x364 (119 Kpixels)
300x480 (144 Kpixels)
288x384 (108 Kpixels)
Dedos X IDs
100x8
100x8
100x8
100x8
Resolução
500 dpi
500 dpi
512 dpi
500 dpi
Tabela 1: as quatro bases de dados da FVC 2004.
Seguem algumas informações sobre a aquisição das impressões:
Estudantes de Ciências da computação da Universidade de Bologna foram voluntários
na extração das impressões. Os voluntários foram divididos em 3 grupos de 30 pessoas, cada um
associado a uma das três bases de dados e consequentemente com diferentes scanners de impressão
digital cada.
Impressões do indicador e dedo médio de cada voluntário foram adquiridas de modo
que nenhum esforço foi feito para controlar a qualidade da imagem e os scanners não foram
limpados sistematicamente.
22
As aquisições foram feitas em três sessões, entre cada sessão havia um espaçamento de
duas semanas. Em cada sessão quatro impressões foram adquiridas de cada um dos quatro dedos de
um voluntário. Diferentes pedidos foram feitos aos usuários como aumentar ou diminuir a pressão
contra o scanner, ou rotacionar o dedo levemente entre scaneamentos para que a base de dados
ficasse mais próxima da realidade.
Ao fim cada base de dados tinha um total de 120 dedos e 12 impressões de cada dedo
(foram 1440 impressões). Mas apenas as impressões de 100 dedos, 8 para cada dedo foram
disponibilizadas aos participantes da FCV e público em geral.
Estas serão as impressões usadas no projeto. Cada base de dados vem com as
impressões no formato tif. Como o pacote da NFIS trabalha apenas com WSQ (Wavelet Scalar
Quantization, criado pelo FBI para compactação de impressões digitais), JPEG Loss-Less ou
formato RAW, foi feito uso do WSQ viewer 1.1 um freeware da Cognaxon Software para visualizar
e transformar as impressões no formato WSQ.
4. PROJETO
Para realizar o projeto, instalamos o SGBD PostgreSQL. Este pode ser baixado da
pagina oficial www.postgresql.org. A instalação para Windows já oferece uma série de extensões,
uma delas é o suporte a lo (Large Objects). Esta extensão é constituída apenas por um domain, que
é um tipo de dados que pode ser definido pelo usuário, chamado lo, e um conjunto de funções para
manipular os campos lo. Este domain lo é o equivalente aos campos BLOB de outros SGBDs
O objetivo deste projeto é integrar todas as ferramentas necessárias para o
reconhecimento de impressões em um SGBD, integrando inclusive as impressões que não serão
armazenadas no sistema de arquivos, mas sim em campos lo.
Para tanto foram estudadas duas aproximações, uma utilizando UDFs em C, onde os
algoritmos de reconhecimento de impressões digitais poderiam ler diretamente dos campos BLOB,
onde não haveria a necessidade de exportar o arquivo para o sistema de arquivos, rodar os
algoritmos retornar os resultados e apagar os arquivos.
A outra aproximação estudada foi a de criar uma UDF em pl/Java para executar
comandos do sistema operacional, e utilizar esta UDF encapsulada em outras UDFs escritas em
plpg/SQL, de modo a extrair os arquivos do campo blob, rodar os algoritmos, obter os resultados e
apagar os arquivos. O que na verdade geraria uma falha de segurança.
23
Sem a menor dúvida a aproximação envolvendo UDFs em C é mais segura e mais
rápida e poderia ser a escolhida. Porém devido à complexidade e ao pouco conhecimento na
linguagem C, somado ainda ao curto tempo para a realização deste estudo, nos levou a utilizar a
segunda aproximação, não como uma solução definitiva do problema mas apenas para que
possamos continuar o estudo. As duas aproximações serão descritas nas seções abaixo.
4.1 UDFs no Postgres
Para poder utilizar uma linguagem, o PostgreSQL tem que ser compilado com suporte a
esta. Depois deve ser utilizado o comando CREATE LANGUAGE para disponibilizar esta
linguagem para cada banco de dados ou para todos. Existem diversas linguagens oficialmente
suportadas pelo PostgresQL como: PLpg/SQL, PL/Java, PL/Tcl, PL/Perl, PL/Python entre outras,
além de poder fazer chamadas para rotinas compiladas em C ou compiladas dinamicamente em C
ou C++. As linguagens também podem ser criadas no modo TRUST (sem acesso a recursos que
possam comprometer a segurança do sistema) ou UNTRUSTED (com acesso irrestrito aos recursos
da linguagem).
4.1.1 UDFs em C no Postgres
Para fazer uma UDF em C as funções são compiladas para objetos dinamicamente
carregáveis também chamados shared libraries. Depois de compiladas as shared libraries são
registradas no SGBD usando-se o comando CREATE FUNCTION.
Duas convenções de chamadas diferentes são utilizadas para funções em C para o
PostgreSQL, versão 0 e versão 1. A versão 0 deve deixar de ser usada e é mantida por questões
apenas de compatibilidade devido a isso não será aqui apresentada. A versão 1 requer que seja
escrita uma macro PG_FUNCTION_INFO_V1() para cada função criada, entre outra convenções.
A primeira vez que uma UDF em uma shared library é chamada, o SGBD carrega o
arquivo objeto na memória para que a função seja chamada. O comando CREATE FUNCTION
deve então especificar duas informações: o caminho do arquivo e a função dentro do arquivo.
a. Convenção de chamada versão 1
Esta convenção é baseada em macros para suprimir muito da complexidade de se passar
argumentos e resultados. A declaração de uma função C na versão 1 é sempre:
24
PG_FUNCTION_INFO_V1(funcname);
Datum funcname(PG_FUNCTION_ARGS)
Código 1: convenção de chamada versão 1.
Este modo de declaração das funções não é necessário para funções internas, mas
apenas para aquelas que são carregadas dinamicamente.
Numa função escrita na versão 1 cada argumento é pegado usando a macro
PG_GETARG_xxx(), onde xxx corresponde ao tipo do argumento em C, ver tabela 2 para
equivalências entre os tipos SQL e C, o resultado é retornado usando PG_RETURN_xxx().
PG_GETARG_xxx() recebe como argumento o numero do argumento da função começando do 0.
Ou seja PG_GETARG_INT32(0) pega o primeiro argumento de uma função. PG_RETURN_xxx()
recebe como argumento o valor ou objeto a retornar.
Tipo em SQL
Tipo em C
Definido em
abstime
AbsoluteTime
utils/nabstime.h
boolean
bool
postgres.h
bytea
bytea*
postgres.h
"char"
char
(nativo)
character
BpChar*
postgres.h
cid
CommandId
postgres.h
Date
DateADT
utils/date.h
smallint (int2)
int2
or int16
postgres.h
integer (int4)
int4
or int32
postgres.h
real (float4)
float4*
postgres.h
double precision (float8) float8*
postgres.h
name
Name
postgres.h
oid
Oid
postgres.h
oidvector
oidvector*
postgres.h
path
PATH*
utils/geo_decls.h
point
POINT*
utils/geo_decls.h
reltime
RelativeTime
utils/nabstime.h
text
text*
postgres.h
tid
ItemPointer
storage/itemptr.h
time
TimeADT
utils/date.h
time with time zone
TimeTzADT
utils/date.h
timestamp
Timestamp*
utils/timestamp.h
varchar
VarChar*
postgres.h
xid
TransactionId postgres.h
Tabela 2: Tipos em C equivalentes a tipos SQL para o PostgreSQL.
25
Um exemplo de uma UDF em C versão 1 é mostrada no código 2:
/*
Arquivo teste.c
*/
#include "postgres.h"
#include <string.h>
PG_FUNCTION_INFO_V1(incrementar);
Datum incrementar(PG_FUNCTION_ARGS)
{
int32 arg = PG_GETARG_INT32(0);
PG_RETURN_INT32(arg + 1);
}
Código 2: exemplo de UDF versão 1.
b. Compilando e registrando uma UDF no PostgreSQL
Para compilar uma UDF para a função descrita na seção anterior, contida do arquivo
teste.c, devemos compilar o arquivo teste.c para um arquivo objeto e depois transformá-lo em um
objeto compartilhado. Para tanto podemos usar os comandos no Shell do CYGWIN ou em qualquer
sistema operacional compatível com Unix.
cc -fpic -c teste.c
cc -shared -o teste.so teste.o
Após ter criado o arquivo teste.so, deve-se ter certeza de que o mesmo se encontra em
uma pasta na qual o postgreSQL tenha permissão de acesso. Finalmente devemos registrar a UDF
no SGBD. O que pode ser feito ao se executar o comando:
CREATE FUNCTION incrementar(integer) RETURNS integer
AS 'DIRETÓRIO/teste', 'incrementar'
LANGUAGE C STRICT;
Código 3: exemplo de como registrar uma função.
c. Acessando campos lo
Existem também tipos de dados que não são mapeados na linguagem C, um exemplo
desses tipos é o campo lo. Como descrito na seção 3.5.6 o campo lo é um domain. Sua definição é
como segue:
CREATE DOMAIN lo AS oid;
Código 4: definição do domain lo.
O que significa que todo campo lo é na verdade um campo oid (Object ID), devemos
estar atentos para o fato de que nem todo campo oid é um lo. Sabendo disso e com a tabela de
mapeamento de tipos de PostgreSQL para C (tabela 2), podemos usar o tipo Oid definido em
26
postgres.h para fazer referência a campos lo. No arquivo be-fsstubs.c que acompanha a extensão lo
do Postgres podem ser encontradas diversas funções em C, estas funções servem para abrir, fechar,
ler, escrever, importar e exportar objetos lo. Baseado nestas funcionalidades, concluímos que é
possível adaptar o código em C dos algoritmos do NFIS2 para que estes aceitem não apenas
arquivos mas também campos lo como entrada e como saída.
4.1.2 UDFs em Java no Postgres
Para efeito deste projeto teremos apenas uma UDF em Java e esta servirá apenas para
executar comandos no sistema operacional retornando resultados. Para tanto criou-se uma classe
Java chamada RunComand, que ao contrário dos códigos em C não precisam de nenhuma
convenção de escrita, apenas que os métodos a serem registrados no SGBD sejam estáticos. A
classe RunComand contém apenas um método estático descrito a abaixo. Este método recebe dois
parâmetros, o comando e a pasta na qual o mesmo será executado.
public static String run(String comando, String pasta){
String s = null;
String ret = new String("");
try{
File f = new File(pasta);
Process p = Runtime.getRuntime().exec(comando, null, f);
BufferedReader stdInput = new BufferedReader(new InputStreamReader(p.getInputStream()));
BufferedReader stdError = new BufferedReader(new InputStreamReader(p.getErrorStream()));
while ((s = stdInput.readLine()) != null) { ret += s; } // Lê a saída do comando
while ((s = stdError.readLine()) != null) { ret += s; } // Lê qualquer erro gerado pelo comando
return ret;
} catch (IOException e) {
ret = "Ocorreu uma exceção:\n";
return ret + e.getStackTrace();
}
}
Código 5: método run da classe RunComand
A classe RunComand foi então compilada em um arquivo JAR, o qual teve o endereço
adicionado ao arquivo de configuração postgreSQL.conf, na linha referente ao classpath do
PL/Java. Após reiniciado o serviço do PostgreSQL a função foi registrada no SGBD com o
comando SQL descrito no código 6:
CREATE OR REPLACE FUNCTION runcomand(varchar, varchar)
RETURNS varchar AS 'RunComand.run'
LANGUAGE 'javau' VOLATILE;
Código 6: registrando a UDF runcomand(varchar, varchar).
27
a. Extração das minúcias
Em seguida foi criada a UDF ID_ExtrairMinucias(oid) na linguagem plpg/SQL. Esta
UDF recebe como parâmetro um campo oid, onde deve ser passado o oid do campo lo que guarda
uma impressão digital. Este parâmetro é usado para se exportar a impressão para o sistema de
arquivos, onde o MINDTCT vai ser executado, gerando um outro arquivo contendo as minúcias.
Este último é então importado para o banco, e após apagarmos todos os arquivos gerados no sistema
de arquivos o oid do arquivo importado é retornado pela função. O código fonte de
ID_extrairMinucias(oid) segue abaixo:
CREATE OR REPLACE FUNCTION ID_extrairMinucias(oid) RETURNS OID AS '
DECLARE
transID integer;
vArquivo varchar;
vRetorno oid;
BEGIN
SELECT transactionid INTO transID FROM pg_locks WHERE pid = pg_backend_pid() AND
transactionId is not null;
vArquivo := transID || ''_'' || $1;
PERFORM lo_export($1, ''C:/util/arquivos/''|| vArquivo || ''.wsq'' );
PERFORM runComand(''C:/util/arquivos/MINDTCT '' || vArquivo || ''.wsq ''|| vArquivo,
''C:/util/arquivos'');
vRetorno := lo_import(''C:/util/arquivos/'' || vArquivo || ''.xyt'');
PERFORM runComand(''cmd /c del '' || vArquivo || ''.*'', ''C:/util/arquivos'');
RETURN vRetorno;
END; '
LANGUAGE 'plpgsql' VOLATILE;
Código 7: registrando a UDF ID_extrairMinucias(oid).
Foi utilizada ainda a variável transID, que guarda o ID da transação. Este ID é usado ao
se exportar os arquivos para que transações diferentes não tentem ler ou gravar um arquivo de
mesmo nome.
Esta função foi desenvolvida para aumentar a velocidade do sistema visto que na
primeira versão para cada comparação de impressões as minúcias eram extraídas. Ocasionando em
um tempo de resposta muito grande por parte da função de comparação. Como as minúcias só
precisam ser extraídas uma vez para cada impressão, decidimos extrair as minúcias de todos os
dedos e guardá-las também no banco. Isso pode ser feito via trigger ou simplesmente rodando o
comando mostrado no código 8.
UPDATE <tabela> SET <xyt> = ID_extrairMinucias( <wsq> )
Código 8: extraindo as minúcias.
28
Onde <tabela> é o nome da tabela, <xyt> o nome do campo lo que vai receber as
minúcias e <wsq> o nome do campo que contém as impressões. Uma vez este comando executado,
contanto que as impressões não sofram alterações, não será mais necessário extrair minúcias para
esta tabela.
Em comparação com a primeira versão que extraia as minúcias a cada comparação, esta
nova apresentou performance 10 vezes mais rápida, utilizando um espaço extra muito pequeno,
visto que um arquivo de minúcias tem em média 700 bytes.
b. Comparação das minúcias
Uma vez com as minúcias guardadas no banco de dados, criamos a UDF
ID_compararMinuciasINT (oid, oid, integer) como descrito no código 9.
CREATE FUNCTION ID_compararMinuciasINT(oid, oid, integer) RETURNS integer AS '
DECLARE
min1 ALIAS FOR $1; min2 ALIAS FOR $2; qtd_minucias ALIAS FOR $3;
transID integer; vMatch integer; vArquivo1 varchar; vArquivo2 varchar;
BEGIN
SELECT transactionid INTO transID FROM pg_locks WHERE pid = pg_backend_pid() AND
transactionId is not null;
vArquivo1 := transID ||''_''|| min1;
vArquivo2 := transID ||''_''|| min2;
PERFORM lo_export(min1, ''C:/util/arquivos/''|| vArquivo1);
PERFORM lo_export(min2, ''C:/util/arquivos/''|| vArquivo2);
vMatch := parseInt(runComand(''C:/util/arquivos/BOZORTH3 -t ''|| qtd_minucias ||'' || vArquivo1 || '' '' ||
vArquivo2, ''C:/util/arquivos''));
PERFORM runComand(''cmd /c del '' || vArquivo1 ||'' ''|| vArquivo2, ''C:/util/arquivos'');
RETURN vMatch;
END; '
LANGUAGE 'plpgsql' VOLATILE;
Código 9: registrando a UDF ID_compararMinuciasINT (oid, oid, integer).
Esta função também se utiliza do ID da transação para assegurar concorrência. São
passados três argumentos, os dois primeiros são campos oid e devem receber os oids das minúcias
já extraídas. O terceiro argumento informa quantas minúcias serão comparadas pelo BOZORTH3.
Quanto ao funcionamento, esta UDF exporta os dois arquivos de minúcias, executa o BOZORTH3
gravando o resultado em uma variável e exclui os arquivo exportados, retornando então a
quantidade de minúcias em comum entre as duas impressões.
Foi criada ainda outra UDF ID_compararMinucias (oid, oid, integer, integer), que
apenas encapsula a UDF ID_compararMinuciasINT (oid, oid, integer), passando um threshold no
último parâmetro. Se o valor do comparador de minúcias atingir este threshold o valor retornado é
true, do contrario é false.
29
Apesar das otimizações descritas na seção anterior o sistema ainda leva cerca de 100
segundos para comparar uma impressão com oitocentas outras num celeron 2.2Gz. com 512 de ram
e HD de 5400 RPM, ou seja, cerca de 125 milisegundos por comparação.
Para comparar uma impressão com todas as restantes no banco de dados podemos usar o
seguinte comando SQL:
SELECT T.nome as nome1, P.nome as nome2, ID_compararMinuciasINT(T.xyt, P.xyt, 150) as qtd FROM
db4 P INNER JOIN db4 T ON T.nome ='1_1'
Código 10: comparando impressões digitais.
Com este comando obteremos o número de minúcias em comum entre a impressão 1_1 e
todas as outras da tabela DB4. Já se quisermos apenas as impressões que pertencem ao dedo 1
podemos executar o comando:
SELECT T.nome as nome1, P.nome as nome2 as qtd FROM db4 P INNER JOIN db4 T ON T.nome ='1_1'
WHERE ID_compararMinucias (T.xyt, P.xyt, 150, 40)
Código 11: buscando impressões do mesmo dedo.
Onde 40 é o número mínimo de minúcias entre as duas impressões para que estas
possam ser consideradas como sendo pertencentes ao mesmo dedo. Este número é chamado de
threshold e pode variar dependendo do tipo da aplicação devendo-se observar que ao aumentá-lo
aumentamos também a taxa de FNM, diminuindo a taxa de FM. Ao diminuí-lo aumentamos a taxa
de FM e diminuímos a taxa FNM.
c. Qualidade das impressões utilizadas
Como descrito em 3.6.3 o NFIQ é um software que retorna um valor de 1 a 5 indicando
a qualidade de uma imagem contendo uma impressão digital. Para integrar o NFIQ ao SGBD foi
criada a UDF descrita no código 12:
30
CREATE OR REPLACE FUNCTION ID_qualidade(oid) RETURNS int4 AS '
DECLARE
qualidade integer;
transID integer;
BEGIN
SELECT transactionid INTO transID FROM pg_locks WHERE pid = pg_backend_pid() AND
transactionId is not null;
PERFORM lo_export($1, ''C:/util/arquivos/''|| transID || ''_'' || $1 || ''.wsq'');
qualidade := parseInt(runComand(''C:/util/arquivos/Nfiq '' || transID || ''_'' || $1 || ''.wsq'',
''C:/util/arquivos''));
PERFORM runComand(''cmd /c del '' || transID || ''_'' || $1 || ''.wsq'', ''C:/util/arquivos'');
RETURN qualidade;
END;'
LANGUAGE 'plpgsql' VOLATILE;
Código 12: registrando a UDF ID_qualidade(oid).
5. RESULTADOS
Para ter uma idéia das taxas de FM e FNM dos algoritmos de detecção e comparação de
minúcias, comparamos os oito primeiros dedos dos 4 bancos de dados de impressões da FVC com
todos os oitocentos dedos de cada banco. O seguinte INSERT foi usado uma vez para cada banco.
INSERT INTO dados (db, id1, id2, match)
SELECT 'db1', nome1, nome2, qtd FROM (
SELECT T.nome as nome1, P.nome as nome2, ID_compararMinuciasINT(T.xyt, P.xyt, 150) as
FROM db1 P INNER JOIN db1 T ON T.nome ='1_1'
UNION
qtd
UNION
SELECT T.nome as nome1, P.nome as nome2, ID_compararMinuciasINT(T.xyt, P.xyt, 150) as qtd
FROM db1 P INNER JOIN db1 T ON T.nome ='8_1'
) tmp WHERE qtd >= 20
Código 13: comparando os 8 primeiros dedos com todos os outros de um banco da FVC
Deste modo inserimos os dados de comparação das minúcias na tabela “dados” criando
um pequeno datawarehouse para prosseguirmos com nossa análise de forma mais rápida. Vamos
usar nesta análise só as comparações em que vinte ou mais minúcias em comum foram encontradas,
por isso a cláusula WHERE qtd >= 20.
Para saber a taxa de FM para cada threshold de 20 a 40 foi utilizado o comando descrito
no código 14:
31
SELECT db, CASE WHEN match < 40 THEN match ELSE 40 END, count(*)
FROM dados WHERE dedo(id1) <> dedo(id2)
GROUP BY db, case when match < 40 then match else 40 end
ORDER BY 1, 2
Código 14: obtendo a taxa de FM.
Com o resultado do SELECT pôde ser montada a seguinte tabela e gráfico, o que nos
permite avaliar a taxa de FM para cada threshold escolhido.
Tabela 3: incidências de FM para os quatro bancos de dados da FVC2004.
Figura 15: gráfico das incidências de FM para os quatro bancos de dados da FVC2004.
Como pode ser observado, não houve falsa aceitação com nenhum threshold acima de
35, confirmando o que é dito no guia do usuário do BOZORTH3 (Watson et al., 2004), de que um
threshold de 40 é geralmente suficiente para podermos afirmar que duas impressões pertencem ao
mesmo dedo.
Para analisarmos a taxa de FNM foram criadas uma tabela chamada FNM e a função:
32
CREATE OR REPLACE FUNCTION preenchefnm() RETURNS int4 AS '
DECLARE
i INTEGER := 20;
BEGIN
LOOP
EXIT WHEN i > 40;
INSERT INTO "FNM" (db, threshold , FNM)
SELECT db, i, 64 - count(*) FROM dados
WHERE dedo(id1) = dedo(id2) AND match >= i GROUP BY db;
END LOOP;
RETURN 1;
END; '
LANGUAGE 'plpgsql' VOLATILE;
Código 15: obtendo a taxa de FNM.
Apos rodar a função acima temos os seguintes valores na tabela FNM, tendo em mente
que o valor máximo de FNM para cada banco neste caso é de 64, uma vez que para cada um 8
dedos testados em cada banco deveriam ser encontrados 8 casamentos:
Tabela 4: incidências de FNM para os quatro bancos de dados da FVC2004.
Figura 16: gráfico das incidências de FNM para os quatro bancos de dados da FVC2004.
Também foram analisadas as qualidades de todas as impressões de cada um dos bancos
de dados da FVC2004 utilizando a função ID_qualidade(oid) como descrito no código 16.
33
SELECT * FROM (
select 'db1', qualidade(wsq) from db1
union all
select 'db2', qualidade(wsq) from db2
union all
select 'db3', qualidade(wsq) from db3
union all
select 'db4', qualidade(wsq) from db4
) tmp order by 1,2 desc;
Código 17: obtendo a qualidade das impressões dos quatro bancos de dados da FVC2004
Compilando-se os resultados do SELECT do código 16 apresentamos tabela e gráfico
referentes às qualidades das impressões:
Tabela 5: qualidade das impressões nos quatro bancos de dados da FVC2004.
Figura 16: gráfico da qualidade das impressões dos quatro bancos de dados da FVC2004.
34
6. CONCLUSÕES E PERSPECTIVAS FUTURAS
Neste trabalho foi apresentado um estudo sobre o reconhecimento de impressões digitais
e métodos para incorporar alguns destes algoritmos em bancos de dados. Para tanto usamos o
PostgreSQL e o software NFIS2.
Os dois métodos de integração partem do mesmo princípio, porém com aproximações
diferentes. Ambos utilizam UDFs para estender as funcionalidades do SGBD PostgreSQL. Estas
UDFs são responsáveis por todo o processo de reconhecimento de impressões digitais.
Observamos que as quatro bases de dados da FVC2004 possuem em sua maioria uma
qualidade boa ou ótima, mesmo com os condições de aquisição descritas no item 3.7. São 3200
impressões e um total de 300 dedos reais e 100 dedos virtuais (criadas utilizando o software SFinGe
v3.0), 8 impressões de cada dedo. Esta base de dados foi, portanto, considera suficiente para a
realização dos nossos estudos.
Apesar de dois métodos terem sido apresentados, apenas um deles foi implementado.
Para este foram feitos testes de reconhecimento para cada uma nas bases de dados da FVC2004 e
medidas as taxas de FM e FNM para todos os thresholds de 20 a 40. Estas estatísticas podem ser
usadas para definir um threshold mais adequado para um tipo de aplicação específica.
Concluímos que o objetivo deste estudo foi concluído, no sentido de que foram
propostos e implementados métodos para integrar o reconhecimento de impressões digitais ao
PostgreSQL, um SGBD de código aberto e bastante popular. No que se refere à segurança o método
implementado não alcançou o objetivo pretendido pelo fato de exportar as impressões e minúcias
para o sistema de arquivos. Porém um outro método foi proposto usando UDFs em C para ler os
arquivos diretamente do campo lo. Este método elimina a necessidade de haver qualquer tipo de
armazenamento de impressões digitais no sistema de arquivos, satisfazendo a questão referente à
segurança.
Como resultado desta pesquisa, propõe-se os seguintes desenvolvimentos futuros:
•
Implementação do método utilizando UDFs em C. Pois estes seriam, mais seguros e mais
rápidos.
•
Realização de estudos sobre a influência da resolução das imagens nos algoritmos de
extração de minúcias.
•
Adaptação do PCASYS para que este possa reconhecer impressões que são estejam
necessariamente formatadas no como no banco de dados especial do NIST chamado de
SD14. Isto feito, extender o PostgreSQL para utilizar o PCASYS.
35
7. REFERÊNCIAS
CHONG, Michael M. S.; GAY, Robert K. L.; TAN, H. N.; LIU, J.. Automatic Representation of
Fingerprints for Data Compression by B Spline Functions. Pattern Recognition, vol. 25, n 10, pp.
1199 1210, 1992.
COETZEE, Louis; BOTHA, Elizabeth C.. "Fingerprint Recognition in Low Quality Images".
Pattern Recognition, vol. 26, n 10, pp. 1441 1460, 1993.
COSTA, Silvia. Classificação e Verificação de Impressões Digitais. 2001.
ELECCION, Marce. Pattern Recognition Automatic Fingerprint Identification. IEEE Spectrum, pp.
36 45, 1973.
FBI: Federal Bureau of Investigation. The Science of Fingerprints: Classification and Uses. U.S.
Government Printing Office, Washington, DC (1984).
FVC2004, Finger Print Verification Competition of 2004. Disponível em:
<http://bias.csr.unibo.it/fvc2004/databases.asp>. Acesso em: 10 out. 2006.
HENRY, E. R.. Classification and Uses of Fingerprints. Wyman and Sons Ltda, 1905.
HONG, Lin; JAIN, Anil; PANKANTI, Sharath; BOLLE, Ruud. Fingerprint Enhancement. Proc.
Third IEEE Workshop on Applications of Computer Vision, pp. 202 207, 1996.
KARU, Kalle; JAIN, Anil J.. Fingerprint Classification. Pattern Recognition, vol. 29, n 3, pp. 389
404, 1996.
LÖWNERTZ, Kurt. Change and Exchange. Electronic document management in building design,
pp 53 53. 1998.
MAIO; MALTONI; JAIN, A.K.; PRABHAKAR, S. Handbook of Fingerprint Recognition. . pp. 2
50. 2003.
MOAYER, Bijan; FU, King Sun. A Syntactic Approach to Fingerprint Pattern Recognition. Pattern
Recognition, vol. 7, pp. 1 23, 1975.
POSTGRESQL. Disponível em: http://www.postgresql.org/docs/8.1/interactive/preface.html e
http://www.postgresql.org/about/. Acesso em 20 nov. 2006.
OLIVEIRA, Adriano. Sistema Biométrico de Controle de Acesso SisBioaccess. Universidade do
Sul de Santa Catarina. Araranguára. 2002.
QUEIROZ, Gilberto. Extensão do SGBD PostgreSQL com operadores espaciais. pp. 6 7. 2002.
RAO, Kameswara; BALCK, Kenneth. Finding the Core Point in a Fingerprint. IEEE Transactions
on Computers, vol. C 27, n 1, 1978.
SHAPIRO, Michael ; MILLER, Ethan. IEEE Managing Databases with Binary Large Objects.
1999.
WATSON, Craig I.; GARRIS, Michael D.; TABASSI, Elham; WILSON, Charles L.; MCCABE, R.
Michael; JANET, Stanley. User's Guide to NIST Fingerprint Image Software 2(NFIS2). 2004
36