Download Reconocimiento de Patrones utilizando Tecnologías

Reconocimiento de Patrones utilizando Tecnologías de Internet
Marcelo Vera, Renato Salinas, PhD
Departamento de Ingeniería Eléctrica, Universidad de Santiago de Chile
rsalinas@lauca.usach.cl
Resumen
Este trabajo presenta la implementación de un sistema de monitoreo y reconocimiento de eventos mediante
lenguaje Java. El objetivo primario consiste en evaluar la eficacia de detectar intrusión en forma remota, vía
Internet, minimizando los falsos positivos y garantizando una respuesta a un usuario preestablecido. El tipo
de respuesta puede ser vía mensaje de texto, email, o bien un llamado a su celular, o quizás una acción de
control.
Keywords: Java, Internet, Pattern Recognition, Intrusion Detection
INTRODUCCIÓN
Nuestro estudio tiene como objetivo el generar una base práctica para el desarrollo de un sistema de
reconocimiento, monitoreo de imágenes y envío de respuesta (habilitando al usuario para tomar acción
respecto del fenómeno observado) utilizando tecnologías de Internet. En particular, la transmisión de datos
vía protocolo IP y procesamiento, mediante lenguaje Java, de la información obtenida. El enfoque de este
trabajo apunta a la implementación de un sistema híbrido, de bajo costo, modular y escalable, con las
bondades de la detección automática y del buen juicio humano. En un lenguaje más concreto, supongamos
que nuestra problemática es la detección de intrusión en forma remota, es decir, queremos controlar el
ingreso a alguna habitación o recinto. El sistema, una vez instalado y configurado, podrá detectar movimiento
en dicha habitación y contar los objetos que cambiaron. Al ser detectado algún cambio se emitirá una alarma
en forma de correo electrónico para el usuario final. El usuario notificado del evento podrá acceder a la
información recogida por la cámara, tanto actual como histórica, simplemente ingresando a una página Web
destinada para ello (Panel de Control). Acá podrá verificar los indicadores de estado, las imágenes
procesadas, configurar el sistema en forma remota y emitir una función de respuesta hacia la cámara (o
sistema de captura y procesamiento). Los beneficios de esta modalidad de acceso son evidentes: bajo costo y
accesible desde cualquier parte del mundo utilizando una plataforma estándar. La figura 1 muestra un
esquema básico del sistema propuesto.
Captura y
Procesamiento
de imagen (1):
Cámara, PC
conectado a internet,
Java
INTERNE
T
Cliente(3):
Estación conectada
a Internet (PC,
Celular, PDA, etc.)
Despliegue(2):
Servidor WEB,
Front End,
Base de Datos de
imágenes
Figura 1. Diagrama del sistema propuesto.
El esquema original se basa en un subsistema que captura, analiza y envía la imagen o imágenes procesadas
(1) a un sistema de despliegue web (2). Los clientes del servicio (3) acceden a la información necesaria por
medio de páginas web dinámicas (programadas con Java Servlets), que además les permiten interactuar con
el sistema de captura y procesamiento y recibir alarmas (vía correo electrónico).
Esquema general de funcionamiento interno.
Dado lo expuesto en la sección anterior, la idea de utilizar Java fue totalmente congruente, dado el origen del
mismo. Java nació como herramienta de programación para pequeños equipos conectables a una red. Por
tanto se pensó que lo más coherente como implementación sería una cámara que contuviera un sistema
procesador de información, con una máquina Virtual Java incorporada y con las clases Java programadas
para realizar la tarea de reconocimiento de patrones y de comunicación vía ftp con un servidor de
publicación. Es evidente que en términos de hardware esta situación, si bien es bastante atractiva, también es
mucho más compleja. Sin embargo, consideramos que una aproximación aceptable de este sistema sería una
cámara web comercial conectada con un computador personal, con las clases programadas y los protocolos
de comunicación correspondientes. Esta consideración es válida y consistente con la idea original dada la
portabilidad de la plataforma de programación Java. Esto quiere decir que las clases programadas para este
trabajo pueden ser ejecutadas en cualquier dispositivo que tenga una máquina virtual instalada y los recursos
disponibles según cada caso (contexto gráfico para procesamiento de imágenes y protocolo de comunicación
TPC/IP). De hecho, podrían ser ejecutadas en una cámara portátil adaptada con los sistemas de
procesamiento correspondientes, teniendo en consideración solamente los problemas al nivel de hardware,
interfaces gráficas, sistemas de archivo y comunicaciones. Lo anterior puede sonar bastante imbricado, pero
cualquier computador personal actual (por pequeño que sea) posee estas características y su adaptación a un
dispositivo más pequeño sería un problema que sale del ámbito de este trabajo. Más aún, las cámaras
digitales actuales manejan tanto el sistema de archivos requerido, cómo el contexto gráfico necesario. Sería
sólo cuestión de adaptar para ellas una JVM y un sistema de comunicaciones acorde. La figura 2 muestra en
detalle las partes que constituyen el sistema desarrollado.
Captura y
Generador de
archivos JPG
Cámara
PC conectado a Internet
Máquina Virtual Java (JVM)
Procesamiento de imágenes
Recepción
Acción
Usuario
Comunicación vía
Protocolos
FTP – SMTP
Set de protocolos TCP/IP
Envío de
imágenes y
registros. Envío de
correo de alerta
Recepción y envío
de archivos de
estado, registro y
comando usuario
Recuperación
de archivo de
configuración.
INTERNET
INTRANET
Recuperación e-mail
alerta.
Sistema de
Servidor de WEB
Servicio FTP
Base de
datos
Imágenes
Servicio HTTP
Registros
de
estado y
Soporte Servlets
JVM
Front End
Páginas
Dinámicas
Recepción y
respuesta
requerimientos
web
Envío
requerimientos
vía página web
y recepción de
la respuesta.
Figura 2. Esquema general de funcionamiento.
Clientes Servicio
Reconocimiento y Detección.
El hecho de decodificar la imagen capturada tiene una serie de implicancias respecto de la interpretación
hecha: ¿Cuáles son los umbrales?; ¿Qué es lo que la cámara obtiene como información?; ¿Cómo se interpreta
dicha información?; ¿Qué procedimientos podemos establecer para determinar la exactitud de la
interpretación hecha en forma automática?. Estas son algunas de las preguntas que nos motivaron y para las
cuales se buscaron respuestas.
Cómo "ve" la cámara.
Cuando decimos cómo "ve" la cámara, evidentemente nos referimos a qué información obtiene la cámara y
cómo podemos interpretarla. Internamente, el sistema toma dos imágenes consecutivas y genera una matriz
de variación, que es la resta entre las componentes RGB de ambas imágenes. Si la resta de las componentes
de un píxel es mayor que cierto umbral se marca un 1, en caso contrario se marca un 0. La figura 3 muestra
un esquema de la situación.
Cámara
Imagen 2
Imagen 1
1111111111
111111111111111
1
111111111111111
111111
111111111111111
11111111
111111111111111
111111111
I
Figura 3. Generación de matriz de diferencia.
Respecto a este punto, es importante destacar que la decisión asociada a la detección depende mucho del
objetivo del muestreo. Para este procedimiento experimental se asumió que una inspección visual desde la
perspectiva humana sería aceptable. Esto es, se consideran aceptables aquellos cambios que fuesen relevantes
para la percepción humana, y con iluminación natural este umbral es de aproximadamente de 30 unidades.
Consideramos también que el tamaño de la porción que cambia era relevante. La calibración de este
parámetro afecta tanto al algoritmo de detección de movimientos, como al de conteo de objetos. Al primero
en el sentido de que se determinará si hubo un cambio relevante sólo si el número de puntos cambiados es
mayor o igual a dicho umbral. Al segundo en el sentido de que un objeto conexo (de acuerdo con el
algoritmo empleado) será considerado para el conteo sólo si el número de sus pixeles conectados sobrepasa o
iguala a este umbral. En este punto, es más evidente aún que hay que tomar en cuenta la apreciación humana,
es decir ¿de qué tamaño debe ser un objeto/región de la imagen para que se considere como un cambio
apreciable? En la figura 4 aparece una escena con un mueble que contiene libros. También aparece una
figurilla, la cuál fue destacada encerrándola en un círculo. Para visualizar las proporciones, esta figurilla es
un pingüino plástico de 11 cm de alto y 6 cm de ancho. La toma fue hecha desde aproximadamente 1.30 m.
En la imagen, la figurilla puede ser enmarcada en un cuadro de 12x18 pixeles (216 pixeles), lo cual
representa un 1,25% de la imagen total (160x120 pixeles). Para nuestro caso, el pensar en un umbral de 1%
del tamaño total de la imagen es aceptable. Sin embargo revisando este razonamiento llegaremos a la misma
conclusión: la determinación de este parámetro depende del uso y de los factores particulares involucrados en
el muestreo. Si por ejemplo se requiriera reconocer un cambio en la intensidad de luz de la imagen, el umbral
de tamaño podría ser ubicado en cualquier punto entre 1 y 100%.
Figura 4. Imagen parte de muestra de menor luminosidad.
Algoritmos de reconocimiento
Si bien el sistema fue probado con dos tipos de algoritmos de reconocimiento, éstos podrían ser
reemplazados con simplemente cambiar, o modificar, la clase JAVA respectiva. Los algoritmos que se
utilizaron fueron: a) detección de movimiento, y b) conteo de objetos. Ambos plantean una comparación
pixel a pixel de una imagen con la siguiente, esto es, hacer la diferencia aritmética de cada componente de
color (RGB), punto a punto, entre una imagen y la consecutiva. Sobre la base de lo anteriormente expuesto,
el vector de características propuesto (vector que servirá para interpretar el resultado del proceso de
reconocimiento) tendría las siguientes componentes:
x1 = Porcentaje de puntos que sufrieron un cambio (respecto del área total de la imagen
capturada). Esto equivale al tamaño de la región cambiada.
x2 = Promedio de variación de color de los puntos que cambiaron. Esto equivale a indicar qué tan
notorio (opaco o transparente) fue el cambio en la región detectada y cuantificada de tamaño
x1 .
Nuestro clasificador queda rápidamente especificado por este vector. Si ambas componentes pasan un umbral
determinado estamos en presencia de un evento (se detectó movimiento), en caso contrario no ha habido
cambio. Es decir, quedan determinadas nuestras dos clases, como lo ilustra la figura 5.
x2
Umbral
cambio de
color
Movimiento
Detectado
No se
detectó
Movimiento
Umbral
tamaño del
cambio
x1
El algoritmo de detección de objetos es una extensión del anterior, al cual se le incorpora un algoritmo de
componentes conexas modificado, el cuál permite evaluar si los cambios encontrados en la imagen son
continuos. En términos estrictos, el algoritmo de componentes conexas será evaluado considerando los
cambios entre una imagen y otra. Por tanto, detectará si las regiones de la imagen son conexas y cuántas son.
Interfaz de Cliente
Anteriormente se mencionó que el usuario podrá obtener mayor información acerca del evento detectado
revisando una serie de páginas Web dinámicas, que se denominan el Panel de Control. Estas páginas fueron
desarrolladas utilizando Java Servlets. Estas permiten al usuario ver la situación actual del sistema, la historia
de los eventos ocurridos y configurar los parámetros, tanto en la cámara remota como en el despliegue de la
información. (Ver Figura 6).
(a)
(b)
Figura 6. Ejemplos de la interfaz cliente. (a) Normal, (b) Alarma, (c) Histórica
Respuesta del Usuario
Como se mencionó anteriormente, el usuario podrá emitir un comando que será recibido por el Subsistema de
captura y reconocimiento (cámara). Esto es simplemente que, en la interfaz cliente, el usuario tiene una
opción que gatilla la ejecución de un Servlet en el servidor Web, más precisamente en el servidor de
aplicaciones instalado sobre el servidor web (Tomcat). Este Servlet escribe un archivo en el servidor. Este
archivo es periódicamente monitoreado por el sistema de captura y reconocimiento por medio de una
conexión FTP (este mismo principio se utiliza para la configuración del sistema). Cuando el sistema detecta
la presencia de este archivo, ejecuta una acción, que para nuestro caso de prueba era desplegar un mensaje en
pantalla.
Consideraciones de rendimiento
Por rendimiento nos referimos al tiempo de respuesta del sistema, tanto para enviar como para recibir
información. Nótese que cada uno de los subsistemas (captura, despliegue y clientes) trabajan entrelazados
por el envío de información de un sistema al otro, y, de acuerdo con lo observado experimentalmente, es el
tiempo asociado con el tráfico de información lo que pone la cota al proceso completo, más que los procesos
de análisis de información.
En ese subsistema existen básicamente dos áreas dónde poder analizar el comportamiento en torno al tiempo
de respuesta del sistema: análisis de las imágenes y envío de información hacia el sistema de despliegue
(incluyendo comandos de borrado y directorio).
Revisando el proceso de análisis y reconocimiento se observó que, dependiendo de las actividades que esté
realizando el procesador, el tiempo promedio requerido para ello es del orden de 700 ms. Se pudo apreciar
que el tiempo de comunicación (comandos FTP asociados al traspaso, listado y borrado de archivos), en
promedio, supera en aproximadamente 6 veces al tiempo de análisis de la imagen, sobre una red LAN que de
por sí es bastante rápida. Para el caso de una conexión telefónica de 45.333 kbps se obtuvieron similares
resultados. La mejora del tiempo de respuesta de esta parte del sistema tiene dos alternativas no excluyentes y
complementarias:
Instalar el sistema sobre un ancho de banda adecuado. En el caso de una LAN, el sistema funciona en
forma bastante fluida.
Manejar la cantidad de información transmitida y recibida. En total, la cantidad de información transmitida
para el caso de alarma es aproximadamente 13.7Kb y aproximadamente 4.7Kb para estado de no alarma.
Esta información incluye imágenes, registros de estado y marcas para sincronización. No se incluyen los
tiempos asociados a borrado y listado de archivos.
En nuestra operatoria experimental hicimos uso de ambas herramientas. En el caso del segundo punto se
enfatizó el minimizar el tamaño de las imágenes, que son los archivos más grandes (de 20 KB a 5KB),
obteniéndose una considerable mejora del rendimiento.
Conclusiones
Se ha presentado un sistema de reconocimiento de eventos vía Internet, desarrollado combinando varias
herramientas, tanto de hardware como de software. Las estadísticas de la percepción de inseguridad en la
ciudadanía y necesidad de monitoreo remoto, hacen de este sistema una proposición bastante oportuna para
nuestro medio. La implementación de este sistema tuvo como mayor costo el hardware involucrado, dado
que tanto la plataforma de sistema operativo (Linux), como de programación (Java) son de acceso gratuito en
Internet. Adicionalmente, este tipo de tecnologías se encuentra ampliamente difundida y su documentación
es, en gran parte, de libre acceso en Internet.
Agradecimientos
Los autores agradecen el apoyo del proyecto Dicyt - USACH 069913SS.
REFERENCIAS
1.
2.
3.
4.
M. Vera. "Sistema de reconocimiento de patrones usando tecnología de Internet". Memoria Ing. Civil
Eléctrica, Departamento de Ingeniería Eléctrica, USACH, 2001.
J. Durán, J. Villacorta y A. Izquierdo. "Modelado de un sistema de vigilancia video-acústico". IX
Congreso Intl. de Telecomunicaciones, Valdivia, Nov. 2000, pp. 155-161.
R. Navarro y R. Salinas. "Visualización de imágenes de alta resolución en Internet". IX Congreso Intl.
de Telecomunicaciones, Valdivia, Nov. 2000, pp. 49-54.
R. González y R. Woods. Tratamiento Digital de Imágenes. Addison-Wesley/Díaz de Santos, 1996.