Captación, análisis y tratamiento de imágenes orientado a la videovigilancia

PROYECTO FIN DE CARRERA “Captación, Análisis y Tratamiento de Imágenes Orientado a la Videovigilancia”

Autor: Juan Diego Mures Trujillo

Tutor: José Ramón Cerquides Bueno

Departamento de Ingeniería Electrónica Universidad de Sevilla Escuela Superior de Ingenieros

Proyecto Fin de Carrera

Indice Página 2

INDICE 1.- Introducción 6

2.- Tecnología ActiveX 10

2.1.- VideoOCX 12

2.2.-Métodos utilizados de VideoOCX 13

2.2.1.- Selección del driver para VideoOCX 13 2.2.2 .- Inicialización del control VideoOCX 14 2.2.3.- Cierre del control VideoOCX 14

2.2.4.- Llamada al método Start del control VideoOCX 14 2.2.5.-Llamada al método Stop del control VideoOCX 15 2.2.6.-Activar el modo de captura del control VideoOCX 15 2.2.7.-Obtención del Handle de la imagen 16 2.2.8.-Liberación del Handle de la imagen 16 2.2.9.-Llamada al método Capture del control VideoOCX 17 2.2.10.- Obtención del puntero a la imagen capturada 18 2.2.11.-Visualización de la imagen del manejador 19 2.2.12.-Obtención del tamaño del fotograma 19 3.- División Funcional 20 3.1.- Bloque funcional de adquisición o captura de la imagen 20 3.2.- Bloque funcional de calculo de estadísticos para el nivel de disparo 21 3.3.- Bloque funcional de procesamiento de la imagen 23 3.4.- Bloque funcional de aplicación para Windows 24 3.5.- Bloque funcional de disparo de la alarma 25


Indice Página 3

4.-Fundamentos del Sistema de Vigilancia 26

4.1.- Análisis por igualdad 28 4.2.- Análisis por similitud 29

5.- Diagrama de Flujo del Sistema 32 6.- Cálculo Estadístico para el Nivel de Disparo 33 6.1.- Fundamentos 33 6.2.- Funciones de densidad de probabilidad 35 6.3.- Probabilidad de falsa alarma y nivel de disparo 41 6.4.- Obtención del nivel de disparo 44 6.5.- Representación de datos frente a nivel de disparo 48 7.- Algoritmo de detección por igualdad 50 7.1.- Diagrama de flujo 51 7.2.- Diagrama de flujo. Calculo de la media 53 7.3.- Diagrama de flujo. Diferencia de fotogramas 54 8.- Algoritmo de Detección por Similitud 56 8.1.- Diagrama de flujo 57 8.2.- Diagrama de flujo. Cálculo de correlaciones 59 9.- Desarrollo de la Aplicación Software 64 9.1.-Introducción 64 9.1.1.- Programación Orientada a Objetos 64 9.1.2.- Gestión de eventos 67 9.1.3.- Programación de una interfaz gráfica 69 9.2.- Consola de la aplicación de vigilancia 70 9.3.- Diagrama de Objetos de la Aplicación 72 9.4.- Menú de la aplicación 74


Indice Página 4

9.4.1.- Menú Inicio 74

9.4.1.1.- Iniciar Control Actives 75 9.4.1.2.- Comenzar procesamiento 75

9.4.1.3.- Finalizar procesamiento 76 9.4.1.4.- Finalizar control ActiveX y salir. 77

9.4.2.- Menú Vigilancia 78

9.4.2.1.- Detección por igualdad 78

9.4.2.2.- Detección por similitud 79

9.4.2.3.- Nivel de disparo 79

9.4.3.- Menú Configuración 81

9.4.3.1- Resolución 82

9.4.3.2- Zona de detección 84

9.4.3.3- Tiempo de preprocesamiento 88

9.4.3.4.-Probabilidad de falsa alarma 90

9.4.3.5.- Seleccionar driver 92

9.4.3.6.- Mostrar ventana de información 93

9.4.4.- Menú Guardar 95

9.4.4.1.- Guardar estadísticos en ficheros 96 9.4.4.2.- Guardar imagen de intruso 97

9.4.4.3.- Guardar config. en archivo de texto 99

9.4.5.- Menú Acerca de ... 100 10.- Carga Computacional Del Sistema 101

10.1.- Descripción de la prueba 101


Indice Página 5

10.2.- Gráfico de CPU para detección por igualdad 102 10.3.- Gráfico de CPU para detección por similitud 103

11.- Simulaciones 105

11.1.- Escenario de Simulación 1 105 11.1.1.- Escenario de Simulación 1. Detección por igualdad 105 11.1.2.-Escenario de Simulación 1. Detección por similitud 108 11.2.- Escenario de simulación 2 111

11.2.1.- Escenario de simulación 2. Detección por igualdad 111

11.2.2.- Escenario de simulación 2. Detección por similitud 113

11.3.- Escenario de simulación 3 117




11.4.1-. Escenario de simulación 4. Detección por igualdad 122




11.5.2.- Escenario de simulación 5. Detección por similitud. 129

11.6.- Conclusiones de las simulaciones 132

12.- Multicámara 133

13.- Conclusiones 135


Introducción Página 6

1.- INTRODUCCIÓN

Estamos presenciando una autentica revolución tecnológica, este avance de la tecnología se nos presenta en todos los aspectos de nuestra vida cotidiana y ya no podemos concebir nuestra labor diaria sin que en ella intervengan todos los aspectos de esta revolución. Cada vez menos nos extrañamos de que las maquinas nos ayuden en tareas de nuestro trabajo, en labores domésticas, en los momentos que dedicamos al ocio.

Ponemos en manos de ordenadores nuestra seguridad en la conducción, en los largos viajes de aviación y en las peligrosas travesías de navegación; pero esta implantación de la tecnología, hasta fechas muy recientes, no ha tenido la misma relevancia en la seguridad del hogar.

Parece que los fabricantes de cámaras y los diseñadores de software han tenido

la misma reflexión anterior , y a día de hoy si ponemos la palabra SEGURIDAD en cualquier buscador web se nos llena la pantalla de multitud de entradas sobre páginas relacionadas con la seguridad domestica. También hay que decir en esta línea que cada vez más los bancos y las empresas de seguridad muestran mayor interés en confiar su seguridad a sofisticados sistemas que requieren menor número de personas para su monitorización.

Es en este mundo donde podemos incluir este proyecto que tiene como finalidad

la elaboración de una aplicación de videovigilancia mediante herramientas de software genérico y software específico para el tratamiento de imágenes para así completar en cierto modo las materias impartidas en los cursos de mi titulación.

Este proyecto viene a avanzar en la misma línea en la que ya se han

desarrollados otros proyectos del departamento pero intentando siempre mejorar aquellos aspectos que consideramos importantes e interesantes para estas herramientas de vigilancia.

La línea de trabajo seguida fue en un principio plantearnos cual era la necesidad

que los programas de vigilancia necesitan, y se llegaron a las siguientes conclusiones:

A.- Un sistema de vigilancia tiene que poder trabajar en tiempo real. Esta condición que se planteo como fundamental al comienzo del proyecto, ha hecho necesaria la búsqueda de soluciones que han pasado desde abordar la programación en ensamblador del micro BT878 , cerebro de la placa de captura y digitalización de AVERMEDIA; hasta el uso de controles Actives en entorno de Visual C++, pasando por el intento de realización de la captura de la imagen atacando las dll’s del sistema por medio driver de la placa de captura.



Al final por facilidad en la programación se optó por la realización del proyecto en el entorno de desarrollo de VISUAL STUDIO 6.0, con el lenguaje de programación Visual C++, y se usó la versión estudiante de un ActiveX soportado por dicha plataforma de programación para la captura del frame de la imagen. Con esta elección se dio solución a la necesidad prioritaria de que nuestro sistema funcione en tiempo real, y se dotó al sistema de una gran funcionalidad. Parte de esta funcionalidad se ha explotado en esta versión del proyecto pero espero que al igual que yo otro compañero retome mi trabajo y pueda aún exprimir más todas las capacidades y posibilidades que nos ofrece esta combinación de componentes de software tanto para la videovigilancia como para cualquier otro campo del tratamiento de imagen. B.- Relacionado con lo anterior la aplicación debe de ser capaz de no acaparar toda la capacidad de procesamiento de la CPU, para ello he hecho especial hincapié en la optimización de los algoritmo de procesamiento a nivel de píxel. Esto se ha hecho con la idea de que pueda ser posible lanzar diversos procesos de videovigilancia de forma concurrente, y ello sea posible desde un PC como el que todo tenemos en nuestra casa que ahora hará la veces de consola de videovigilancia.

No hay que entender que la versión que se presentará en la defensa del proyecto pueda ser una aplicación comercial, sino que con ella sentamos las bases de cómo realizar el tratamiento de la imagen de forma rigurosa de igual forma que se hace en las aplicaciones comerciales, pero que carezco de la experiencia en la programación de la API como para considerar que dicha aplicación se pueda presentar a concurso o comercializar de algún otro modo.

No obstante, no cierro la puerta a la posibilidad de dedicarme a la programación

de aplicaciones en mi inminente futuro profesional, para el cual considero este proyecto un primer contacto con la programación de forma rigurosa y con la filosofía existente en el campo de los programadores de software.

C.- En ultimo lugar pero no menos importante se concluye que hemos de dotar a nuestro programa de no poca fiabilidad. Toda empresa que decide implantar un sistema de videovigilancia basado en detección de intrusismo mediante software ha de confiar que en un muy elevado porcentaje de las alarmas lanzadas por dicho software haya la presencia de riesgo para la integridad de sus bienes o se ponga en peligro la propia seguridad de las personas. Es por esto que el sistema ha de ser extremadamente fiable y no se debe escatimar trabajo en conseguir dicha finalidad.

Esta última característica se convierte en especialmente importante en aquellos sistemas de seguridad donde la alarma de este primer sistema de detección activa todo un dispositivos de seguridad en el cual pueden estar inmersos los cuerpos de protección civil, bomberos, hospitales, etc. Este proyecto ha dado lugar a una herramienta sencilla diseñada a partir de una cámara digital con conexión al PC mediante puerto USB, un PC que en principio tiene como únicos requerimientos una frecuencia de CPU igual o superior a 200 MHz y una RAM igual o superior a 32 MB, y un software de observación personal que permita,



aparte de una cierta auto-configuración propia de diversos parámetros dependientes del escenario, también la elección de distintos parámetros por parte del usuario o persona encargada de la supervisión del sistema. La idea que subyace detrás de la vigilancia o detección de intrusismo a nivel de software es captar que es lo que le ocurre a una imagen a nivel estadístico de píxel cuando en la secuencia de imágenes hay movimiento o cierta variación en los fotogramas. Esto nos permite introducir un elevado grado de automatización en la elección de lo que realmente puede ser considerado una amenaza de lo que no lo es; no obstante siempre es aconsejable que una persona supervise estos disparos de alarmas, y es que estos sistemas no pretenden, al menos en la fase en la que nos encontramos, sustituir a la persona encargada de la vigilancia pero si liberarla de trabajo y de que tenga que pasar toda su jornada laboral observando unos monitores sin quitar la vista de ellos. A parte de las ya mencionadas existen otras ventajas de este sistema en comparación con los ya antiguos sistemas de vigilancias basados en cámara analógicas que volcaban su imagen en multitud de monitores para que la persona encargada de la seguridad pudiese monitorizar el sistema mediante la observación de dichos monitores. A continuación se muestran algunas de estas ventajas:

• Posibilidad de trabajo en segundo plano o background, al ser reducidos los

recursos que el PC emplea por cada uno de los hilos de videovigilancia de la aplicación. Este número de hilos de procesamiento depende de diversos parámetros que como ya se verá son entre otros el tamaño de la imagen a procesar.

• La aplicación de técnicas de fotogramas por segmentos que nos proporciona la

misma eficacia de vigilancia que el análisis de la imagen completa pero con un considerable ahorro de recursos y la libertad que nos da definir expresamente la zona, objeto o lugar que vigilar. Este es un aspecto muy importante de nuestro sistema de videovigilancia pues en muchas ocasiones no es necesario vigilar todo el escenario captado en el fotograma sino que solo son importantes determinados puntos de ese escenario, como por ejemplo si vigilamos un pasillo sólo nos podría interesar si hay movimiento en las puertas o si monitorizamos la planta de un edificio si hay entrada y salida de gente en las puertas de los ascensores. Esto anterior, aparte de suponer un considerable ahorro de tiempo en comparación con el procesamiento completo de la imagen, dota a los algoritmos de detección de mayor eficacia pues los cambios en los estados de los píxeles son más significativos (tienen un mayor peso estadístico) cuando el número total de estos píxeles es más reducido.

• Los sistemas convencionales basados en cámara y grabador de VHS necesitan

almacenar imágenes durante todo el tiempo en que se realiza la vigilancia, es decir, se necesita almacenar en VHS las 24 horas del día ( tomando fotogramas cada cierto tiempo en torno a los 4 segundos ) durantes semanas, meses e incluso años. En contraposición a esto podemos configura nuestro sistema para que sólo almacenes en una base de datos la secuencia de frames donde se detecta intrusismo o incluso un único fotograma que nos permita identificar al culpable de la infracción. Por tanto la



aplicación de técnicas digitales a la vigilancia también avanza en la dirección de ahorro de soporte para el almacenamiento de información por diversos métodos, reduciendo el número de fotogramas a almacenar solamente a aquellos en los que se detecto intrusismo como anteriormente ya se ha dicho o aplicando técnicas de compresión ya que estamos tratando con información digital.

• Una ventaja que puede ser resumen de las anteriores es que mediante la técnica

de procesamiento digital se obtiene un sistema de vigilancia dotado de una mayor funcionalidad a un menor coste. Este conjunto de características es lo que hace que estos sistemas se estén imponiendo a los anteriores y que cada vez más empresas sustituyan sus antiguos sistemas de VHS por sistemas de vigilancia de nueva generación.

A continuación se explicará la realización del proyecto y el resultado obtenido de forma muy técnica; si en algún momento el lector se pierde en consideración sobre la tecnología usada para la programación no debe olvidar cual es la finalidad de todo este trabajo, captura o mapeado de la imagen en memoria del sistema y posterior procesamiento para vigilancia; teniendo esto como finalidad de todas las operaciones que se realizan, la línea de trabajo seguida se muestra como el única natural y rigurosa.


Tecnología ActiveX Página 10

2.-TECNOLOGÍA ACTIVEX

Para la realización del proyecto y dar solución a la necesidad de que nuestro

sistema funcionase en tiempo real se adoptó como solución la combinación de un lenguaje de programación rápido, como Visual C++, con la tecnología ActiveX.

A grandes rasgos, ActiveX es una tecnología de desarrollo creada por Microsoft, la cual consiste en guardar el código binario en un formato tal que programas ajenos al creador del mismo puedan reconocer, permitiendo llamar con una interfase similar la misma función desde varios entornos de desarrollo diferentes, por ejemplo, un mismo ActiveX puede ser usado con la misma interfaz en el entorno Visual C++, Visual Basic, FOXPRO...

Los antecedentes de la tecnología ActiveX se remontan a la tecnología Object Linking and Embedding (OLE versión 1.0 y 2.0), que se puede traducir por Objetos Vinculados e Incrustados. Nació a partir de lo que se denominaba DDE, Dynamic Data Exchange o Intercambio dinámico de Datos, la cual se implemento en aplicaciones de Microsoft (Excel, Access, etc).

El principal beneficio de ActiveX es encapsular de una manera efectiva, procesos, objetos, o clases, creando un modo simple de reutilizar los conocimientos de otros lenguajes, de manera transparente al usuario. Para un programador de C++, ActiveX es el nombre de un nuevo tipo de clase que soporta encapsulamiento, funciones de tipo friend o public, metodos constructores de objetos, así como llamadas a punteros (de manera relativa) . Un objeto ACTIVEX es un archivo, que tiene una interfase determinada que puede obtenerse por procedimientos standard.

Suelen ser de tres tipos:

Tipo Características Extensión

InProcess Se ejecutan dentro del área de proceso del programa que los llama. Por su naturaleza y extensión, son los más fáciles de ocultar.

*.DLL

OutProcess

Se ejecutan en un área diferente de memoria, y suelen tener una finalidad en si mismos. Ejemplo, WORD y EXCEL versiones Office 97. Por su naturaleza, son los primeros que busca un usuario promedio.

*.EXE

Control

Su finalidad solo es aparente a un programador, y son procesos que no pueden ejecutarse a menos que se incluyan en un programa que instruya sobre las formas de proceso. Son los más fáciles de copiar, porque rara vez requieren instalación

*.OCX



La idea básica de todas estas tecnologías es diseñar aplicaciones que puedan intercambiar datos y compartir código, de forma que sean accesibles unas desde dentro de otras. En concreto los controles ActiveX actúan en forma de pequeños módulos de aplicaciones, listos para ser incluidos por los programadores en aplicaciones finales, de los cuales sabemos como utilizarlos pero no sabemos como realizan su trabajo, internamente. En resumen, si un código compila con un lenguaje ActiveX, puede enlazarse con cualquier otro lenguaje que permita integrar objetos ActiveX.

En modo de resumen veamos en que se centran las características de trabajo de los ActiveX:

• Se centran en un módulo de código programado en un lenguaje, normalmente de bajo nivel, como C/C++. Se implementan propiedades (algo así como variables, bien referentes a su apariencia externa o de conjuntos de datos) y métodos de acceso, definición y procesamiento de esas propiedades.

• Los módulos tienen unas características de autonomía propia. Con ello, deben ser código binario (compilado) que sea capaz de definir cuando iniciar y cuando terminar su ejecución.

• El código generado ha de tener la capacidad de interactuar con otros módulos ActiveX y/o ejecutables finales. Esto es, recibirá entradas de ellos y podrá enviar datos de salida hacia ellos. En la relación de la aplicación contenedora y el ActiveX existen dos niveles: servidor y cliente. El servidor, en nuestro caso el modulo ActiveX, es aquel que recibe peticiones de la aplicación contenedora del control, ejecuta las operaciones pertinentes y devuelve datos procesados. La aplicación contenedora que actúa como cliente puede acceder a los datos de la aplicación servidora y gestionar su información como si de datos propios se trataran.

• La actualización del código de un control ActiveX no debe suponer una reprogramación de las aplicaciones clientes (aquellas que lo utilicen), debe mantenerse una compatibilidad con versiones anteriores, de forma que las mejoras afecten al cómo se procesa la información, pero no al método de acceder a ella ni cómo se devuelve a los clientes.

• Una diferencia sustancial entre los controles OCX (controles OLE) tradicionales y los nuevos controles ActiveX se refiere a la seguridad para el usuario. Los controles ActiveX deben ser oficialmente certificados por Microsoft (Authenticode) o mediante algún método de autentificación, del que el usuario final sea consciente del nivel de seguridad (o riesgo, como quiera verlo) que asume al utilizarlo, o permitir que lo utilicen aplicaciones que ejecuten.



2.1.- VideoOCX

En este proyecto, como ya se ha dicho antes, se usa la combinación de Visual C++ con la versión estudiante de un control ActiveX denominado VideoOCX. Este control contiene implementado en su núcleo ( en código ya compilado) las funciones que se comunican con el driver de la cámara para realizar la captura del fotograma y su posterior transferencia a nuestra aplicación cliente. El diver que se utilizó para control de la cámara fue: Microsoft WDM Image Capture (Win32), Versión: 5.0.2195.2672

Este driver es genérico y normalmente el que se usa para las webcam, por lo que para utilizar nuestra aplicación de vigilancia en cualquier PC únicamente tenemos que tener este driver instalado (o en caso de tener otro driver, seleccionar este como driver activo para VideoOCX, esto es un cuadro de elección en la aplicación) y hacer correr la aplicación de videovigilancia.

VideoOCX es un control ActiveX que permite a los programadores la fácil integración de funcionalidades de captura de video y procesamiento de imagen dentro de su software de aplicación. El control utilizado es la versión estudiante que se puede conseguir en la web www.videoocx.de , que pertenece a la casa alemana de desarrollo de software Marvelsoft ( para más información sobre la empresa se puede remitir a la dirección web www.videoocx.de/company.htm ).

El control es compatible con la mayoría de los dispositivos Video-for-Windows (VFW), tanto del tipo de cámaras USB (webcams) como del conjunto formado por la conexión de tarjeta capturadora (digitalizadoras de video) con cámaras CCD.

A parte de los ya mencionados VideoOCX tiene los siguientes rasgos funcionales:

• Soporta la mayoría de los dispositivos de captura de Video-for-Windows con formato PAL/NTSC.

• Captura a elevada velocidad fotogramas de video y los mapéa en memoria del sistema (puede alcanzar velocidades de 25 fps de 768x576 píxeles) y conversión al vuelo de los fotograma a escala de grises.

• Completa libertad de acceso a la imagen RGB a nivel de píxel.

• Soporta secuencias AVI.

Aunque el control presenta multitud de métodos, aquí sólo se comentarán los que han sido más importantes para la realización de este proyecto.



2.2.-Métodos utilizados de VideoOCX

Veamos cuales han sido los métodos de VideoOCX más importantes que se han utilizado para la realización del proyecto.

Como primer paso había que realizar la captura del flujo de fotogramas en tiempo real y para ello se utilizaron varios de los métodos del control ActiveX que posteriormente comentaremos; pero como ya se ha dicho antes, estos métodos sólo pueden ser utilizados si hemos incluido en nuestra aplicación un objetos de VideoOCX. Para el resto de esta memoria, la instancia que hace referencia al control es m_VideoOCX ; el nombre de la clase es CVideoOCX y el identificador del control ActiveX en la aplicación es IDC_VIDEOOCXCTRL.

2.2.1.- Selección del driver para VideoOCX

Obedece a la siguiente sintaxis: m_VideoOCX.ShowDriverDlg()

Esta función se ejecuta cuando se pulsa el botón de selección de driver. Construye un dialogo de titulo ‘Driver Selection’, en el que podemos seleccionar cual es el driver del dispositivo que será fuente de nuestras imágenes digitales, y con el que el ActiveX realizará la conexión si este no se encuentra ya en funcionamiento.

En el manual de funcionamiento del ActiveX VideoOCX el lector puede observar la existencia de otros métodos relacionados con la selección del driver, que en esta versión del proyecto no ha sido necesario su utilización.

Estos métodos son: m_VideoOCX.GetDriverCount()

Que se usa para obtener el numero del driver que se está usando n ese momento cuando en el sistema hay varios drivers con los que podría conectar el ActiveX.

String str = m_VideoOCX.GetDriverName(long drivernum)

Recibe como parámetro del entrada en número identificativo del driver utilizado en el sistema y nos devuelve en una cadena cual es el nombre de ese driver.



2.2.2 .- Inicialización del control VideoOCX

Obedece a la siguiente sintaxis : m_VideoOCX.Init()

Inicializa y conecta el control a la fuente de imagen especificada. Es imprescindible inicializar el control antes de llamar a cualquier otro método, ya que este no se encuentra cargado en memoria antes de la inicialización, es como si aún no existiera el objeto y se llame a su constructor.

Esta función de inicialización devuelve un valor lógico de true si la inicialización ha concluido con éxito, o false si ha habido algún problema en la conexión con el dispositivo o si este estaba ya en uso. Intenta conectarse al driver especificado como activo en el dialogo a tal efecto, este driver puede ser la conexión a cámaras (como es nuestro caso), pero también ha tarjetas capturadoras, o cualquier dispositivo que sea la fuente de imágenes digitales para nuestra aplicación.

2.2.3.- Cierre del control VideoOCX

Obedece a la siguiente sintaxis: m_VideoOCX.Close()

Sólo tiene sentido llamar a esta función una vez que se haya inicializado el control mediante la llamada a Init(). Cierra la conexión con el driver del dispositivo fuente de fotogramas o de la secuencia de imágenes. Esta función de inicialización devuelve un valor lógico de true si el cierre del flujo de imágenes se lleva a cabo con éxito, y devuelve false en caso contrario, es decir si ha habido algún problema al intentar cerrar la conexión con el driver o con el flujo de imágenes.

2.2.4.- Llamada al método Start del control VideoOCX

Obedece a la siguiente sintaxis: m_VideoOCX.Start()

La llamada al método Start se utiliza para activar el inicio del lazo de captura. Este lazo de captura será llevado a cabo en background mediante un hilo que se dedique a capturar y procesar la secuencia de fotogramas. Este método devuelve un valor lógico de true si no hay ningún tipo de problema para inicializar el lazo de captura y devuelve false en caso contrario.

De modo que la forma de usar este método es introducirlo como condición en un if, de tal modo que si no hay ningún tipo de problema se pueda comenzar el lazo de captura y



si lo hay aparezca un mensaje de error y se corte la ejecución de la aplicación. El lazo se captura se define dentro de una función de C++ que hace arrancar un nuevo hilo de ejecución, esta función es : UINT CaptureThread(LPVOID pParam) que se explicará entrando en mayor grado de detalle más adelante, de momento hasta este punto sólo quiero hacer notar que sólo una vez que el método Start devuelva true comenzará la captura y procesamiento de los fotogramas.

2.2.5.-Llamada al método Stop del control VideoOCX

Obedece a la siguiente sintaxis: m_VideoOCX.Stop()

La llamada a este método sólo tiene sentido una vez que antes se haya ejecutado Start(). Es el que hace finalizar el proceso de captura interna, y al igual que muchos de los anteriores devuelve un valor lógico de true cuando el proceso de captura interno se finalizó con éxito, y false en otro caso.

Tengo que hacer notar aquí que la llamada a este método no es el que termina con el lazo de captura implementado por un bucle dentro de la función CaptureThread(), sino que para finalizar este lazo tenemos que actuar de forma externa al control haciendo mediante una variable lógica que se salga del lazo de captura. Lo que sí finaliza el método Stop es el proceso de captura interno al control, es decir, el proceso arrancado por el método Capture (que se explica más adelante).

2.2.6.-Activar el modo de captura del control VideoOCX

Obecede a la siguiente sintaxis: m_VideoOCX.SetMode(bool mode)

Donde el parámetro mode de entrada puede ser 0 si queremos activar el modo VFW (Video-For-Windows) o 1 si activamos el modo AVI que es cuando el flujo de entrada está formado por imágenes en formato AVI. Para la realización del proyecto se usó el modo 0.

En relación con la propiedad mode tenemos también el método m_VideoOCX.GetMode() que devuelve el modo que está activado en el control en ese momento.



2.2.7.-Obtención del Handle de la imagen

El handle o manejador de la imagen es donde el ActiveX guarda la referencia de donde ha alojado la imagen capturada, en realidad es la referencia del contenedor donde se va a ir almacenando los distintos fotogramas que se vayan capturando, tiene relación con la cantidad de memoria necesaria para almacenar un fotograma. Debido a que el control VideoOCX nos permite la captura de la imagen tanto en color como en escala de grises existen diferentes manejadores para estos distintos formatos de imágenes, y estos

Obedecen a las siguientes sintaxis:

long m_Image = m_VideoOCX.GetGrayImageHandle()

long m_Image = m_VideoOCX.GetColorImageHandle()

También existen métodos para construir un manejador de la imagen a nuestro gusto, es decir podemos obtener un contenedor para una imagen que no tenga las medidas estándar de ancho y largo sino las medidas que nos haga falta en cada momento; para ello usamos los siguientes métodos:

long m_Image = m_VideoOCX.CreateGrayImageHandle(long width, long height)

long m_Image = m_VideoOCX.CreateColorImageHandle(long width, long height)

Estos métodos permiten alojar una imagen con distintas dimensiones que aquellas que llegan de la fuente de video.

2.2.8.-Liberación del Handle de la imagen

Obedece a la siguiente sintaxis:

m_VideoOCX.ReleaseImageHandle(long imagehandle)

Este método libera la zona de memoria donde se alojan las imágenes y que se ha creado con los métodos del punto 2.2.7.

En nuestra aplicación el manejador es reutilizando en cada pasada del bucle de captura y cuando ya ha concluido el proceso de captura y procesamiento se libera para no acaparar memoria del sistema que no volverá a usar de no ser liberada, ya que una nueva inicialización del sistema obtendrá otro manejador distinto.



2.2.9.-Llamada al método Capture del control VideoOCX


m_VideoOCX.Capture(long imagehandle)

Se usa este método para capturar una imagen de la fuente de video. Hay que pasarle un “imagehandle” o manejador de la imagen que ha tenido que ser inicializado con los métodos GetGrayImageHandle() o GetColorImageHandle() antes de la primera llamada al método capture. En cada llamada se capturará una imagen en color o en escala de grises dependiendo de que tipo de manejador se le este pasando, también, dependiendo del tamaño del manejador de la imagen, se capturará uno u otro tamaño de la imagen.

La conversión de una imagen en color a escala de grises relentiza al método capture en tiempo de ejecución en la mayoría de los hardware aptos para trabajar con imagen en color en los que VideoOCX tiene que convertir cada imagen de color a escala de grises de forma separada.

Este método se utilizará dentro de un bucle de captura y procesamiento de la imagen que será el que se ejecute en nuestra aplicación en régimen permanente; además este bucle estará dentro del hilo lanzado para la captura y eso hace que la sintaxis usada dentro de este hilo no se corresponda exactamente con la anteriormente mostrada sino que, hay que acceder a la variable m_VideoOCX y imagehandle por medio de un puntero al dialogo contenedor de ambas variables.

Por la estructura con la que se ha construido el bucle de captura la velocidad con la que se captura fotogramas (fotogramas por segundo) está definida por el número de veces que en un segundo pase el bucle por el método Capture; quiero decir con esto que no podemos considerar como un dato de partida para la aplicación que todos los fotogramas que la cámara sea capaz de transferir van a ser adquiridos por la aplicación ya que hay un tiempo en el bucle, que será dependiente tanto del tipo de procesamiento como de la zona a procesar de la imagen, que pondrá un limite al número de fotogramas que se capturaran. Lo que si limita la cámara es el número máximo que en el mejor caso pueda adquirir la aplicación, es decir el hilo de captura capturará como máximo la máxima tasa de fotogramas que sea capaz de dar la cámara.

El método Capture aloja una imagen en un manejador, pero esta imagen aún no está accesible a nivel de píxel, sino que sobre este manejador hay que aplicar otra función para que sea accesible mediante un puntero clásico de C. Esta forma de acceder sólo es necesaria cuando queremos ver, comparar, modificar o realizar cualquier otra operación con el nivel que toma el píxel, si nuestra intención es solamente mostrar lo que se captura no es necesario el acceso a los píxeles.

A continuación se muestra el método que me hace accesible con un puntero la imagen.



2.2.10.- Obtención del puntero a la imagen capturada.

Como ya se ha mencionado en el punto anterior mediante el manejador de la imagen no podemos realizar un procesado de los fotogramas porque estos no permite ser accedidos a nivel de píxel; para ello es necesario obtener un puntero a lo almacenado en el manejador es decir obtener un puntero a la imagen capturada. Para realizar esto usa un método del control VideoOCX.

Este obedece a la siguiente sintaxis:

(BYTE *)data = (BYTE *)m_VideoOCX.GetDataPointer(long m_Image)

Donde m_Image en el manejador que acoge la imagen a la que se quiere hacer apuntar el puntero y data es el puntero que se hace apuntar a dicha imagen.

Ahora usando el puntero data si tenemos acceso a los píxeles y podemos realizar operaciones con el valor que estos toman en cada uno de los fotogramas. En esto se basa la detección de movimiento en la secuencia de imágenes, en que se detecte diferencia en el valor que toman los píxeles de fotogramas consecutivos. Esto será explicado más adelante cuando se muestren los distintos algoritmos que se han utilizado para dicha detección de movimiento.

Notar que la llamada de este método devuelve un puntero a BYTE, pues una variable de tipo BYTE tomo los valores de un unsigned char es decir cada uno de los píxeles de la imagen van a estar comprendidos entre los valores 0 – 255, donde 0 es ausencia total de luminosidad (negro) y 255 es saturación total de luminosidad (blanco).

Pero este método también devuelve un puntero a una imagen de color si el manejador utilizado se inicializó con el método GetColorImageHandle(), en ese caso el manejador contendrá una imagen en color y el puntero accederá a una imagen cuyos píxeles estarán definidos por tres bytes (B,G,R); cada uno de estos bytes define el valor de cada uno de los tres colores del píxel (B: Nivel de color azul; G: Nivel de color verde; R: Nivel de color rojo).

Al igual que capture, este método aparece dentro del bucle de captura y hay que invocarlo por medio del puntero al dialogo que lo contiene, de forma que la sintaxis que el lector podrá encontrarse en el código fuente no es exactamente la mostrada anteriormente sino que usa ese puntero al dialogo antes mencionado.



2.2.11.-Visualización de la imagen del manejador.


m_VideoOCX.Show(long m_Image)

Donde m_Image es el manejador de la imagen que se quiere visualizar en el control. Notar que si accedemos a la imagen a nivel de píxel y modificamos el nivel de estos, los cambios se van a reflejar en la imagen almacenada en el manejador de modo que cuando queramos visualizar dicha imagen modificada tenemos que pasarle al método Show() el manejador de la imagen que es como el contenedor dentro del cual se le han realizado las modificaciones a la imagen.

De igual modo que en los métodos anteriores también se accede a Show() mediante un puntero al dialogo contenedor ya que la invocación a este método se encuentra dentro del hilo de captura.

2.2.12.-Obtención del tamaño del fotograma.

Para realizar operaciones de procesamiento sobre los píxeles de la imagen, en muchas ocasiones, es necesario conocer cual es la dimensión de la imagen. Esto se obtiene mediante la invocación a la siguiente función:

int size = m_VideoOCX.GetImageDataSize(m_Image)

Toma como parámetros el manejador de la imagen de la cual se quiere conocer su dimensión y devuelve un entero que es el número de píxeles de la imagen. El mismo resultado puede ser obtenido mediante la invocación de métodos que devuelven por separado el alto y el ancho de la imagen.

Al igual que los anteriores es accedida mediante un puntero al dialogo contenedor al encontrarse dentro del hilo de captura.

Se han explicado con brevedad algunos datos de interés sobre los controles ActiveX, y se han introducido características del control OCX utilizado para la realización de este proyecto.

VideoOCX tiene mucha más funcionalidad de la que aquí se ha considerado; no obstante se ha introducido aquí este resumen de sus métodos con vistas a que el lector pueda entender con mayor facilidad como se ha realizado en el proyecto las labores de captura y procesado de la imagen.


División Funcional Página 20

3.- DIVISIÓN FUNCIONAL

La forma de abarcar los proyectos software es, al igual que con otro tipo de

proyectos de ingeniería, hacer una previa planificación para que el programa cumpla toda la funcionalidad para la que es diseñado, pero en el caso de este tipo de proyectos, en ocasiones “los árboles no nos dejan ver el bosque” y es conveniente hacer una división conceptual de las funciones que se intentan cubrir y adjudicar dichas funciones a distintos bloques funcionales que cumplen una misión diferenciada en el código. De este modo se consigue tener una visión más clara de aquello que realiza el código, y que es difícil de obtener con sólo una ojeada al código fuente. Los bloques funcionales no explican más que aquello que se ha implementado en código fuente pero a nivel conceptual si entrar en aquellos detalles que son secundarios para entender sus partes por separado. Aunque otra división, usando otro tipo de criterio y agrupando distintas funcionalidades en distintos bloques, sería igualmente valida incluso dando un número distintos de bloques funcionales. En la división que aquí presentaré existen bloque con un elevado número de líneas de código y en contra posición otros bloque funcionales cuyo tamaño en código es muy reducido pero cuya funcionalidad es tan importante como los anteriores de modo que no se puede considerar integrados en ellos. Aquí considero que el proyecto podría dividirse en 5 bloques de funcionalidad claramente diferenciada, estos bloques se presentan a continuación:

3.1.- Bloque funcional de adquisición o captura de la imagen

Este bloque tiene una funcionalidad clara y muy importante para el buen funcionamiento de los siguientes bloques, su función es presentar a los siguientes bloques una interfaz de acceso fácil y rápida hacia los datos, es decir este bloque dará como resultado de salida una imagen en escala de grises ubicada en un contenedor que responde al nombre de un determinado manejador ( imagehandle ) y es accesible a nivel de píxel por un puntero a BYTE.

También se considera dentro de este bloque la funcionalidad llevada a cabo por el driver que es el que se encarga de solucionar los problemas de comunicación entre la cámara y la aplicación. Parte de la funcionalidad interna del control VideoOCX puede considerarse que está inmersa en este bloque funcional de adquisición de la imagen pues este ActiveX presenta la opción de elegir cualquier driver instalado en el sistema compatible con Video for Windows (VFW) y hacer que este driver sea la fuente de



adquisición de fotogramas para la aplicación en la que el control VideoOCX está “encajado” o hace uso de él. Es esto mencionado anteriormente unos de los aspectos que dotan de gran funcionalidad al sistema, ya que si hacemos correr hilos distintos de la misma aplicación y seleccionamos en cada uno de estos hilos fuente distintas de imágenes ( tanto drivers distintos como dispositivos distintos que pueden ser distintas cámaras digitales, tarjetas digitalizadoras o cualquier periférico de adquisición de imágenes compatible con VFW ) podemos tener varios procesos de videovigilancia concurrentes en la misma máquina cuyos problemas de comunicación con los distintos dispositivos de adquisición vienen solventados por los distintos drivers.

Dependiendo del ruido adquirido en este bloque se condicionaran los valores

estimados por los siguientes bloques para el nivel a partir del cual disparar la alarma. Puede ser este un factor muy importante a la hora de llevar a cabo un diseño de una aplicaciones de vigilancia, pues un ruido extremadamente elevado puede reducir de forma considerable la resolución de un sistemas de estas características. Esto anterior describiría la situación por la que un nivel elevado de ruido elevaría también el nivel de disparo de la alarma estimado y lo dejaría por encima de aquellos valores que ciertas acciones de intrusismo pueden producir, las cuales pasarían por el sistema sin ser detectadas por los bloques diseñados a tal efecto. En contraposición si hacemos una estimación optimista del nivel de ruido de nuestro sistema nos podemos encontrar que en el régimen permanente de nuestra aplicación existan alarmas provocadas porque el nivel de ruido supera el umbral estimado para el lanzamiento de la alarma, en este caso estaríamos ante un sistema con un elevado número de falsas alarmas (elevada Pfa.-Probabilidad de falsa alarma ) y por tanto dotado de poca fiabilidad. La solución de la problemática mostrada en este párrafo no es competencia de este bloque funcional pero el nivel de ruido, origen del problema anterior, si viene fijado por este bloque y poco podemos hacer para disminuirlo una vez tomada la elección de los componentes del sistema.

Relacionado con lo anterior se ha de decir que el valor del ruido que se captura

con la imagen está sujeto a múltiples factores como pueden ser la calidad de la lente de la cámara utilizada en este sistema, el cable utilizado para la transferencia de los datos de la cámara a la aplicación, los conectores del cable a la cámara y al puerto USB; además de estos, que pueden ser considerados factores hardware, existen otros factores que podemos denominar factores software que son tales como el número de píxeles total de la imagen, el número de píxeles de segmento del fotograma a procesar, si el segmento de vigilancia es horizontal o si por el contrario es un segmento vertical...

Además de este ruido existe otro más peligroso que es aquel en entornos donde

los vigilado se encuentra inmerso entre movimientos uniformes, un ejemplo de esto sería realizar la vigilancia de un objeto en zona arbolada donde los arbustos y árboles son balanceados por el viento. Estos entornos son especialmente complicados porque pueden dar lugar a niveles de disparos de la alarma que pueden enmascarar alertas reales.



3.2.- Bloque funcional de calculo de estadísticos para el nivel de disparo. Este es el bloque encargado de solucionar la problemática mostrada en la sección 3.1 sobre el efecto dañino de una mala estimación del nivel de ruido del sistema. Tiene como misión dar una referencia para el nivel a partir del cual podemos considerar que tenemos una alerta, tiene por lo tanto, a diferencia del bloque anterior, formas distintas para la detección por igualdad y la detección por similitud. No obstante, se ha empleado en ambos casos calculo de parámetros estadísticos d de las magnitudes a vigilar para la detección, como medias muestrales o desviaciones típicas muestrales, estas medias y desviaciones serán sobre los datos adquiridos durante el periodo que dedica la aplicación al análisis del entorno a vigilar en condiciones de no movilidad y determinarán en gran medida las estimaciones de los niveles de detección del sistema, así como, derivado de esto, el comportamiento de fiabilidad del sistema: El sistema será tanto más robusto en fiabilidad cuanto mejor sea la estimación del nivel del ruido. No obstante no se debe pensar que la mayor o menor fiabilidad del sistema sólo está sujeta o es dependiente de la estimación en tiempo real de la media o desviación típica muestral; sino que mucha importancia en la estimación de los niveles de vigilancia la tiene el dimensionamiento de las funciones de densidad de probabilidad de las muestras adquiridas por el sistema de vigilancia. Es decir, las muestras adquiridas en nuestro sistema están inmersas en un cierto ruido, este ruido dota de cierta importancia al azar a la hora de captura de estas muestras, pero este azar está sujeto a las leyes de la estadística y probabilidad las cuales nos permiten tener un cierto grado de conocimiento del ruido. En términos matemáticos estas leyes de la estadística viene enunciada por la función de densidad de probabilidad y su mejor o peor dimensionamiento en tiempo de diseño de esta aplicación ( no en tiempo real ) es lo que nos permitirá hacer un ajuste más o menos fino del nivel de disparo de la alarma. Como se verá más adelante se observa que estos valores son distintos dependiendo del número de píxeles que forma el segmento a vigilancia, de si esta zona es una franja horizontal en la imagen o si es una franja vertical y de si se ha tomado una zona donde el nivel medio de los píxeles es bajo ( baja luminosidad ) o si es alto ( elevada luminosidad ). Puesto que este nivel de la alarma es muy dependiente no sólo del entorno que se está vigilando sino también dentro de las distintas partes con diferente luminosidad dentro de la misma imagen es muy importante este bloque funcional. Pero también tiene una dependencia con un parámetro que se explicará más adelante (probabilidad de falsa alarma) y que viene a estimar cual será la seguridad que nos proporcional el sistema ante posibles falsas alarmas, es decir, mediante la introducción de este parámetro podemos dar cierta robustez al sistema frente a incursiones peligrosas del ruido por encima de su nivel medio estimado en el periodo de observación y sujeto a las funciones de densidad de probabilidad dimensionadas. El bloque funcional del calculo de estadísticos para el nivel de disparo está sujeto al tiempo que dediquemos a la observación de las magnitudes que se usarán para dicho calculo, este parámetro será configurable por el usuario antes de la inicialización



de la captura de fotogramas en el sistema, queremos decir con esto que dependerá por tanto de la elección de usuario que tendrá que llegar a un compromiso entre la eficiencia que quiera para estos valores de disparo y el tiempo que quiera dedicar a su estimación. No obstante no será una decisión crítica puesto que éste será un proceso que se realizará fuera del régimen permanente para el que está diseñada la aplicación. Aunque las líneas de código que se dedican a este bloque no son muy numerosas, he considerado diferenciar éstas en un bloque funcional porque detrás de ellas subsiste un elaborado calculo estadístico que merece ser mencionado. Esto que se ha esbozado en este punto se desarrollará con más detalle en otra sección dedicada expresamente a justificar las elecciones tomadas a la hora del dimensionamiento de las funciones de densidad de probabilidad, no obstante sirva este punto de introducción y destaque la importancia que la estadística ha tenido en la realización de este proyecto.

3.3.- Bloque funcional de procesamiento de la imagen.

Este bloque funcional puede ser considerado como el corazón de nuestro sistema de detección de movimiento pues se dedica a medir mediante la estimación de estadísticos el movimiento de un objeto en la imagen. Este movimiento captado en un fotograma se traduce a nivel matemático en el cambio de estado de los valores de los píxeles que componen la matriz de la imagen. Por tanto este bloque pretende determinar cual es la variación matemática / estadística en el estado de los píxeles cuando hay una variación en el escenario vigilado.

Es el encargado de realizar los cálculos sobre la zona de vigilancia de los

fotogramas capturados en tiempo real. Los cálculos realizados sobre estos fotogramas son la media de las diferencias entre las zonas de detección de fotogramas consecutivos y la correlación de la zona de detección de fotogramas consecutivos.

Estos bloques los componen ciertos algoritmos que incluyen bucles de

procesamiento de la imagen accediéndola a nivel de píxel. Se ha intentado realizar la optimización del código para minimizar el tiempo de calculo de estos algoritmos mediante varios métodos:

La primera optimización, fundamental en cualquier proyecto software, es

minimizar el número de bucles aprovechando al máximo la utilización de aquellos que son realmente necesarios. Esta optimización nos lleva a concentrar la funcionalidad de este bloque en aquellos bucles que la optimización no puede eliminar; es por esto que el código concentra el mayor número de llamadas a las funciones dentro de estos bucles y así traslada la realización de esta funcionalidad a las distintas funciones.

En segundo lugar se ha llevado otra optimización que nos permite la idea de

detección que se está implementando. Esta idea consiste en que no es necesario procesar todo el área de la imagen que se está capturando sino que dentro de esta imagen sólo procesar aquel rectángulo o segmento en el que estamos interesados en detectar movimiento. Este rectángulo será en el que se encuentre el objeto a vigilancia. Con esta



segunda optimización no reducimos el número de bucles sino el número de iteraciones dentro del bucle, ahora este número de iteraciones es dependiente del tamaño del formato de captura pero también del tamaño del segmento donde se encuentra el objeto que hemos de vigilar o aquella zona que estamos interesados en controlar.

Todo esto de la zona rectangular de detección se explicará con más detalle más

adelante, en este apartado únicamente quiero que se entienda que funcionalmente se ha de diferencial todo un bloque que accede a la imagen para detectar que cambia a nivel estadístico en el valor de los píxeles cuando hay un movimiento recogido por la cámara en la zona de detección.

Los algoritmos que se implementan para dar su funcionalidad a este bloque están

inspirados en técnicas de tratamiento digital de señales y de imágenes cuyo buen comportamiento está comprobado, y es su trasfondo matemático lo que le da fiabilidad a su uso.

3.4.- Bloque funcional de aplicación para Windows Este bloque es el encargado de dotar de la “forma” a nuestra aplicación, es decir de dotar a nuestra aplicación de una interfaz de usuario similar a las interfaces que usar todos los programas que corren sobre un sistema operativo visual como es Windows.

Recordemos que una de las finalidades de la elaboración de este proyecto era la de la realización de una aplicación para Windows de un sistema de vigilancia, la particularidad de que sea para Windows implica la programación de lo que es llamado la API de Windows ( Interfaz de programación de aplicaciones para Windows ). Para la realización de este proyecto se ha usado la API Win32 y el resultado ha sido una aplicación que corre sobre Windows y que en la plataforma de desarrollo de Visual Studio 6.0 pertenece a la modalidad de aplicaciones denominadas: “Aplicaciones basadas en diálogos”. Quiere esto decir que la interfaz visual de salida y entrada de datos está constituida por un conjunto de diálogos cuyo diseño y funcionalidad internas están incluidas dentro de este bloque funcional. Estos diálogos actúan como consola de videovigilancia sustituyendo en los sistema analógicos a un elevado número de monitores de televisión. Ahora el sistema lo constituye una ventana donde aparece la imagen de aquello que se está vigilancia y un conjunto de diálogos o ventanas que sirven para la configuración de los parámetros del sistema de vigilancia.

Se ha intentado que el diseño del entorno gráfico de la aplicación sea lo más

parecido posible al de todos los programas diseñados para Windows y así obtener una ventana, que a su vez hace las veces de consola de videovigilancia, que sea familiar para el usuario de la aplicación.



3.5.- Bloque funcional de disparo de la alarma

Para la concesión de la existencia de este bloque funcional para el disparo de la alarma hay que entender que este sistema de videovigilancia estaría al principio de todo ese proceso que se pondría en marcha para conseguir la seguridad de una determinada zona o cosa, y que en caso de que este sistema diese la alarma se tendría que disparar unos sistemas para conseguir la seguridad. Se ha considerado todo un bloque funcional para el disparo de la alarma puesto que sería en este bloque la conexión con otros sistemas encargados de la seguridad y que su diseño no estaría contemplado en este proyecto sino que habría que entenderlos como posibles ampliaciones, cuya realización sería objeto de trabajo de otro proyecto completo.

Este bloque es el encargado de detectar si los niveles de alarma calculados por el

bloque de calculo estadístico son sobrepasados por los niveles de medias de diferencias o nivel de correlación de fotogramas consecutivos. En este caso anterior se considera alarma y se activa el mecanismos de aviso a la persona que monitoriza el sistema de vigilancia o mediante una interfaz automatizada lanzar los eventos necesarios para que se lleve a cabo el plan de prevención diseñado para activar en estos casos.

Con relación a lo anterior si se muestran en este proyecto ciertas ideas de cuales

serían las líneas de trabajo que habrían de seguir aquellas personas encargadas de diseñar los sistemas de seguridad basados en este sistema de detección. No obstante, estas líneas de trabajo no se cierran con las que se mencionarán en esta memoria sino que están abiertas a todas aquellas que la tecnología vaya haciendo viable y la imaginación de aquellas personas contemple.

Espero que al lector le haya servido este punto para tomar una idea, de lo que se

va a encontrar desarrollado en los siguientes apartados de esta memoria, también espero que haya sido una división conceptual de utilidad para aquellas personas encargadas de realizar algo similar en el futuro o quienes estén interesados en ampliar este proyecto. Ahora lo que nos queda es el desglose de estos bloques funcionales en líneas de código y toda la casuística posible que nos podamos encontrar y para la cual se pueda usar este proyecto.


Fundamentos del Sistema de Vigilancia Página 26

4.- FUNDAMENTOS DEL SISTEMA DE VIGILANCIA

En primer lugar partiremos desde cero para explicar los fundamentos teóricos necesarios y que hacen posible la videovigilancia de forma automatizada por cámaras digitales. No olvidemos que el concepto de intrusismo, vigilancia, movimiento son ideas de fácil entendimiento para el ser humano, pero que la concepción de estas por máquinas no dejan de ser la simulación mediante software de las mismas, es por esto la razón que la detección de un simple movimiento para una persona se convierte en un problema no exento de dificultad para una maquina. En relación con lo anterior cabría realizarse las siguientes preguntas: ¿Qué cambia en la memoria de la computadora cuando se realiza un cambio de la imagen a nivel visual? ¿Qué “ve” un ordenador cuando nosotros estamos visualizando una fotografía, una película o en definitiva una secuencia de imágenes? En la respuesta a estas preguntas se encuentra también el fundamento de nuestro sistema de vigilancia. Para entender las respuestas a las preguntas anteriores hay que entender como se realiza el almacenamiento de la imagen en la computadora; este almacenamiento se lleva a cabo dividiendo la imagen en unidades fundamentales denominadas píxeles. Estos píxeles representan cada uno de los puntos de la imagen y su almacenamiento en la memoria del ordenador son de forma independiente. Por lo tanto a la pregunta de qué es lo que “ve” un ordenador cuando tenemos una imagen tiene como respuesta que es un conjunto de píxeles que en conjunto constituyen la imagen. Si la imagen es en color el píxel ha de guardar información sobre tres niveles de color ( Rojo, Verde, Äzul ). Hay distintos formatos para la representación del color en los píxeles, uno de los más utilizados es el formato conocido como RGB24, este formato utiliza 8 bits para cada uno de los colores que en ingles son Red, Green y Blue; si juntamos la primera letra de cada uno de los colores en inglés y sumamos el número de bits utilizados en total en cada píxel obtenemos el nombre del formato. Puesto que cada uno de los colores utiliza un Byte para ser representado, en cada píxel se puede tener por lo tanto 256 niveles de luminosidad (de 0 a 255) por cada uno de los colores. Si la imagen no es en color se denomina en escala de grises, estas utilizan un Byte por cada píxel y en el se representa la luminosidad que va desde 0 ( negro o falta total de luminosidad ) hasta 255 ( blanco o máximo de luminosidad ). También está relacionado con los píxeles lo que se denomina la resolución de la imagen; la resolución de la imagen es el número de píxeles que constituyen una imagen y se suele dar como el ancho por el largo del fotograma en número de píxeles; por ejemplo una resolución con la que he trabajado en el proyecto ha sido 320x240, que significa que el fotograma tiene un ancho de 320 píxeles y 240 píxeles de alto, en total la imagen ocupa en memoria 76800 píxeles. Estos son datos que hay que tener en cuenta cuando se quieren hacer capturas y transferencias de imágenes puesto que constituyen elevadas cargas de datos que limitan la captura en tiempo real de fotogramas y ocupan mucho ancho de banda al ser transferidas. El número de píxeles también constituyen una limitación considerable a la hora de procesar la imagen en



tiempo real, por lo que la resolución también es un parámetro importante en el diseño de una aplicación que se han de ejecutar en tiempo real. Por lo antes mencionado se debe deducir que para una misma resolución una imagen en escala de grises ocupa tres veces menos memoria que una imagen en RGB24, además si estamos interesados en procesar la imagen, como es el caso en este proyecto, también resulta más rápido las imágenes en escala de grises que en color. A veces, cuando es necesario procesar imágenes y disponemos de estas en formato RGB24, se suele realizar un preprocesado de la imagen que extraiga un byte por cada píxel y se obtenga una imagen en una sola tonalidad ( rojo, verde o azul según sea el byte que se extraiga de la imagen original ). Llegados a este punto ya disponemos de los conocimientos para responder a la pregunta de qué cambia en la memoria de la computadora cuando se realiza un cambio de la imagen a nivel visual; la respuesta es que cambia el estado de los píxeles. Centrémonos en el caso de las imágenes en escala de grises, en este caso cada píxel se almacena en un byte en memoria cuyo estado puede estar comprendido entre 0 y 255; cuando hay un cambio en la imagen, los píxeles situados en la zona de la imagen donde se ha realizado dicho cambio sufren una variación en su estado, es decir, almacenan otro valor comprendido entre los límites. Si el píxel pasa de almacenar un valor a almacenar un valor más elevado, este píxel se ilumina y si por el contrario pasa a almacenar un valor más bajo entonces este píxel se oscurece; de este modo es como el cambio en una imagen, que en definitiva es un cambio en la luminosidad de los puntos que la constituyen se traducen en cambios de los píxeles que codifican dichos puntos. El movimiento no deja de ser un cambio en el valor de luminosidad almacenado en los píxeles, quiere esto decir que cuando hay un movimiento en una imagen este se produce porque el cuerpo que experimenta el movimiento se va desplazando sobre los píxeles que constituyen la imagen provocando sobre estos píxeles un cambio de estado. Llegados a este punto ya se puede entender como se procesa una imagen digital para detectar movimiento, lo único que tenemos que hacer es detectar cambios en el nivel de los píxeles y cuantificar este cambio para discriminar si es debido a un movimiento captado en la imagen o a oscilaciones del nivel del píxel debidas al ruido introducido por el sistema. Por lo tanto a modo de resumen de este apartado podemos decir que: para una computadora la imagen constituye un número más o menos elevado de bytes almacenados en memoria, cada byte se corresponde en escala de grises con un píxel y este número de píxeles es lo que se denomina la resolución de la imagen. Cuanto mejor sea la resolución mayor es este número de píxeles y mejor es la calidad visual de la imagen. Los píxeles almacenan un valor comprendido entre 0 y 255 que se corresponde con los valores de menor y mayor luminosidad respectivamente. Los cambios en la imagen constituyen cambios en los niveles de los píxeles y son más acentuados cuanto mayor sea el cambio en la imagen. Este nivel de cambio ha de ser detectado por la aplicación que a su vez ha de discriminar si dicho cambio es consecuencia de movimiento debido a intrusismo o debido al ruido introducido por el sistema. Del tamaño de la imagen y de la zona de esta sobre la que actúan los algoritmos de



detección dependen otros parámetros de la aplicación como es, por ejemplo, el número de fotogramas capturados por segundo. No obstante, estas limitaciones se han intentado minimizar con la optimización del código. A continuación se explicará cual es el fundamento teórico de los métodos de detección de movimiento que se codificarán en algoritmos.

4.1.- Análisis por igualdad Se ha denominado método por igualdad a aquel que lleva a cabo la detección del movimiento comparando píxel a píxel fotogramas consecutivos de la imagen. La comparación de estos fotogramas se lleva a cabo a través de la resta de los valores de los píxeles, es decir, calculando la diferencia natural del valor de los píxeles, por tanto cuanto más próxima a cero sea esta diferencia más igualdad existe entre fotogramas consecutivos. El algoritmo no distingue la diferencia de los píxeles por exceso o por defecto, sino que se queda con el valor absoluto de esta diferencia y sobre esta realiza la media que será el parámetro de comparación. Previamente al inicio de la simulación se realiza un cálculo estadístico para la estimación del umbral de disparo, en él se hacen observaciones en ausencia de ruido y se aplica el mismo algoritmo descrito anteriormente con el que estimar en cuanto repercute el ruido en la media de la diferencia de los píxeles. Durante el proceso de diseño de los algoritmos que implementan este método se barajó la posibilidad de realizar la comparación de los píxeles mediante un ‘XOR’ de cada unos de los bits que componen el byte que almacena el valor de los píxeles que ocupan la misma posición en fotogramas consecutivos de la imagen; este método se descartó porque la operación binaria del OR Exclusivo no devuelve la diferencia natural entre los píxeles que ocupan la misma posición en fotogramas consecutivos, sino que devuelven el error binario entre los bytes que almacenan el valor de los píxeles. Puesto que el calculo de los niveles de detección se realizan partiendo de la diferencia natural de los píxeles el método de XOR se descarta por si sólo. Posteriormente en esta memoria se llevará a cabo la explicación de los algoritmos que implementan este método de análisis entrando en detalles de diseño de dichos algoritmos, también se mostrarán ejemplos de videovigilancia llevadas a cabo por medio de este método de análisis y se mostrarán las conclusiones comparativas entre los dos método implementados. Es necesario por lo tanto especificar en que consiste este segundo método de calculo de movimiento como a continuación se muestra.



4.2.- Análisis por similitud Se ha denominado método o análisis por similitud a aquel que lleva a cabo el cálculo de movimiento mediante la correlación de fotogramas consecutivos. Siempre que se pretende buscar un grado de similitud entre dos funciones unas de las opciones siempre a considerar es la correlación . En la definición de correlación se indica que es el grado de similitud que presentan dos funciones, este es el motivo por el que usaré este método para analizar en que medida un fotograma se ha diferenciado del fotograma que le antecede.

El grado de similitud o en su defecto el grado de diferenciación de dos

fotogramas consecutivos se mostrará en la diferencia que exista entre la correlación que se vaya calculando frente a uno, siempre por defecto. Para que esto quede más claro veamos de forma detallada cuales son los fundamentos matemáticos que describen la operación de correlación. La operación de correlación se define matemáticamente para dos señales X e Y de la siguiente forma:

∑∑∑∞

−∞=

∞

−∞=

∞

−∞=

⋅+=−⋅−=−⋅=−∗=KKK

XYkYklXkYklXlkYkXlYlXlr )()()()()()()()()(

Si se realiza la operación de operación sobre la misma señal X se denomina autocorrelación y se define:

∑∑∑∞

−∞=

∞

−∞=

∞

−∞=

⋅+=−⋅−=−⋅=−∗=KKK

XXkXklXkXklXlkXkXlXlXlr )()()()()()()()()(

La correlación tiene las siguientes propiedades: 1.- )()( ll rr YXXY

−= 2.- )()( ll rr XXXX

−= 3.- ErEnergía XXXX

== )0(

4.- )0()( rEr XXXXX

l =≤

5.- )0()0()( rrEEr YYXXYXXY

l ⋅=⋅≤

Es especialmente interesante la propiedad 4 donde se dice que la autocorrelación de una función X siempre es menor o igual que la energía de dicha función X. La igualdad se alcanza en el origen, es decir que la autocorrelación de una señal X coincide con su energía en el origen.



Er XK

XXkXkX∑

∞

−∞=

=⋅= )()()0(

Pero anterior es para el caso de que tengamos señales deterministas, cosa que no

ocurre con las señales con las que se trabaja en este proyecto. Supongamos que estamos procesando una secuencia de fotogramas que no recogen ningún tipo de movimiento aparente (quiere esto decir que no se muestra un movimiento apreciable por el ojo humano), aún en este caso dos fotogramas consecutivos no constituyen señales deterministas pues tienen una componente de ruido aditivo que hacen que cada uno de los píxeles de un fotograma no coincida exactamente con el fotograma que le antecede.

Es por esta razón anterior que nos vemos obligado a definir la correlación de

otra forma diferente para señales aleatorias. Vamos a considerar que el ruido en nuestros fotogramas introduce una aleatoriedad de forma que el valor exacto de los píxeles en cada instante un número aleatorio y que por lo tanto cada imagen capturada puede ser considerada una realización de cierto proceso estocástico que viene caracterizado por cierta función de densidad de probabilidad.

En estas condiciones anteriores no es descabellado pensar que en ausencia de

movimiento los píxeles pueden mantener un cierto valor medio. Además si consideramos que en distintas realizaciones de este proceso, o lo que es lo mismo, en distintos fotogramas los píxeles situados en las mismas posiciones pueden mantener el mismo valor (o muy parecido dependiendo de la actuación del ruido sobre ellos) ya que estarán iluminando una zona de la pantalla cuya tonalidad debe ser la misma pues es factible considerar que el objeto que se encuentra ocupando esa posición no cambiará demasiado en fotogramas consecutivos; sino que la variación del valor de los píxeles será más dependiente de la posición relativa que ocupen estos píxeles en la imagen, es decir será más dependiente de la “distancias” entre esos píxeles que de la posición que estos ocupan. Esto anterior nos lleva a considerar que se trata de un proceso aleatorio estacionario.

En estos casos se define la autocorrelación como sigue:

)())()((),( mmnXnXEmnXYXY

φφ =+⋅=

Por ultimo definamos cual será la expresión que usemos para el calculo de la correlación en el proyecto. Esta será la correlación normalizada o coeficiente de correlación normalizado y su expresión matemática se muestra a continuación:

∑ ∑

∑

= =

=

−⋅⋅−⋅

−⋅=

M

K

M

K

M

KXY

lkYkYlkXkX

lkYkXlC

0 0

0

)()()()(

)()()(



Puesto que solo estamos interesados en detectar el movimiento que ha tenido

lugar en la imagen, no nos interesa calcular estos coeficientes de correlación para los distintos valores de l ya que sería un calculo imposible de hacer en tiempo real debido al tamaño de la imagen que estamos manejando. Sólo nos interesa el valor de Cxy cuando no exista desplazamiento de un fotograma sobre el anterior y así poder medir cual es la diferencia de las dos imágenes en aquel punto ( l=0 ) donde la correlación tendría que dar un máximo por similitud entre ambas, esta diferencia con el máximo es debida al movimiento captado entre ambos fotogramas.

Llegados a este punto se entenderá mejor porque se han utilizado estos

coeficientes de correlación y no el valor de la correlación de ambos fotogramas. La razón es que este coeficiente esta normalizado a 1, es decir que su máximo valor será 1 cuando ambas imágenes capturadas coincidan exactamente. De este modo si podemos conocer cual es el valor máximo de estos coeficientes también podemos conocer la diferencia que estos van teniendo con respecto al máximo, cosa que no sería posible con el valor de la correlación pues no sabemos cual es el máximo y por lo tanto no se podría calcular la diferencia hasta él.

Como se ha justificado anteriormente se calcula el valor para l=0:

1)0()0(

)0(

)()()()(

)()()0(

0 0

0 ≤⋅

=⋅⋅⋅

⋅=

∑ ∑

∑

= =

=

rrrC

YYXX

XYM

K

M

K

M

KXY

kYkYkXkX

kYkX

De este modo si las imágenes X e Y coinciden exactamente se obtiene el valor

máximo para Cxy=1


Diagrama de Flujo del Sistema de Vigilancia Página 32

5.- DIAGRAMA DE FLUJO DEL SISTEMA

NO SI

APLICACIÓN DE

VIDEOVIGILANCIA

INICIAR VENTANA

CONFIGURACIÓN DE LOS PARAMETROS

INICIALIZACIÓN DEL CONTROL VideoOCX

¿ VideoOCX INICIALIZADO ?

CAPTURAR SECUENCIA LIBRE DE MOVIMIENTO

DATOS PARA EL CALCULO DE ESTADÍSTICO

CALCULO DEL NIVEL DE DISPARO DE LA ALARMA

ALGORITMO IGUALDAD o SIMILITUD

DATOS A FICHEROS

ALGORITMO IGUALDAD o SIMILITUD EN REGIMEN PERMANENTE

BLOQUE DE DETECCIÓN DE LA ALARMA


Cálculo Estadístico para el Nivel de Disparo Página 33

6.- CALCULO ESTADÍSTICO PARA EL NIVEL DE DISPARO

6.1.- Fundamentos

Como ya se ha mencionado en otros apartados anteriores el nivel de disparo constituye el umbral a partir del cual se considera que existe suficiente movimiento en la imagen como para hacer lanzar una alarma. Es por lo tanto unos de los parámetros mas importante en un sistema de vigilancia y no debemos escatimar esfuerzos en que su calculo sea todo lo fiable que por nuestros medios podamos conseguir. La herramienta que usemos para la determinación de este nivel de disparo será la estadística y nos apoyaremos en Matlab para la realización de cálculos que puedan verifican si nuestras hipótesis de partida son validas.

Veamos el abanico de posibilidades que nos podamos encontrar en un sistema de vigilancia como el que pretendemos diseñar:

En primer lugar llamaremos movimiento a todo aquello que produzca una variación del estado de los píxeles suficiente como para que en caso de un buen comportamiento del sistema sea detectado y de lugar a una alarma. Y en segundo lugar, claro está, existen dos posibilidades: que se detecte movimiento en nuestro sistema o que no se detecte movimiento en nuestro sistema. Con la combinación de los hechos que puedan tener lugar se llega a que existen 4 casos posibles, asignaremos una probabilidad a cada uno de los casos y luego explicaremos cual es el significado de esa probabilidad:

Lo detecto: Pd Existe movimiento No lo detecto: Pm Existen 4 posibilidades: Lo detecto: Pfa No existe movimiento No lo detecto: ---- Donde: Pd.- Probabilidad de detección. Pm.- Probabilidad de perdida. Pfa.- Probabilidad de falsa alarma.



Se denomina probabilidad de detección o Pd a la probabilidad de que realmente se den las circunstancias para hacer lazar la alarma y esta se lance, sería el caso del funcionamiento correcto del sistema de detección, que cuando se de un nivel de movimiento lo suficiente como para superar el nivel de detección realmente este nivel esté bien dimensionado y efectivamente se supere, y se de esta detección. Además éste sería el único caso para el que debería saltar la alarma, cuando existe suficiente movimiento para que esto se dé.

Se denomina probabilidad de perdida o Pm a la probabilidad de que dándose

el suficiente movimiento en la imagen como para hacer saltar la alarma, el nivel de disparo esté lo suficientemente elevado como para que este movimiento no lo supere y quede enmascarado como ruido por debajo del nivel de detección. Este caso se da cuando se ha estimado un nivel de alarma muy elevado.

Existe una relación ente la probabilidad de detección y la probabilidad de

perdida:

md PP −= 1 Es decir ambas probabilidades son complementarias. Por último se denomina probabilidad de falsa alarma o Pfa a la que se da en

caso de que sin existir el suficiente movimiento en la imagen se haga saltar la alarma como si efectivamente existe el movimiento suficiente. Este caso se da en aquellos sistemas en los que el nivel de detección es accesible por el nivel de ruido de modo que sin existir un movimiento en la imagen el ruido es capaz de hacer saltar la alarma.

En último lugar también se daría el caso complementario de la probabilidad de

falsa alarma, que sería el caso de que el sistema no diese alarma cuando efectivamente no la hay, sería un caso de buen funcionamiento de nuestro sistema que no tiene mayor interés para el cálculo que pretendemos llevar a cabo.

Definidas las probabilidades y los distintos casos que nos podemos encontrar es

el momento de determinar cuales van a ser esas magnitudes sobre las que hagamos los cálculos estadísticos y midamos las probabilidades anteriormente mencionadas. Estas magnitudes han de cumplen ciertas condiciones:

En primer lugar han de poder ser calculadas por cada fotograma capturado en

régimen permanente de nuestra aplicación, es decir, han de poder ser calculadas en tiempo real y por lo tanto deben de ser magnitudes cuyo computo no requiera mucho tiempo de CPU ya que la aplicación ha de correr en tiempo real y el tiempo de CPU ha de ser repartido en diversas funciones como captura de la imagen, procesamiento, calculo de estadísticos...

En segundo lugar estas magnitudes deben ser un reflejo matemático de la

imagen de forma que si tenemos un cambio a nivel de los píxeles de la imagen esta variable sea fiel reflejo matemático de este cambio y nos permita un análisis para la determinación de un nivel de disparo adecuado.



Definidas las probabilidades y dadas las características que han de cumplir las magnitudes a usar, solamente nos queda definir cuales va a ser estas magnitudes: Las magnitudes que se usarán para medir el movimiento en las imágenes serán la media de las diferencias entre las zonas de detección de fotogramas consecutivos y la correlación de la zona de detección de fotogramas consecutivos y el dimensionamiento del nivel de disparo se llevará a cabo mediante el uso de la Pfa y no mediante el uso de Pd y Pm ya que es más fácil el tratamiento experimental de la primera que el de las otras dos.

A partir de este momento denominaremos al procesamiento a través de la media

de las diferencias entre zonas de detección de fotogramas consecutivos como análisis por igualdad y al método de correlación de la zona de detección de fotogramas consecutivos como análisis por similitud. La razón de estos nombres es que cuando estamos midiendo la diferencia entre fotogramas consecutivos y a esta diferencia le calculamos la media, estamos midiendo cuanto de iguales son estos fotogramas y sin embargo cuando realizamos la correlación entre fotogramas consecutivos lo que medimos es cuanto de similares son.

Como ya se verá más adelante el calculo del nivel de detección de movimiento

se realiza de formas distintas para la detección por igualdad y la detección por similitud. No obstante, se van a emplear en ambos casos cálculos de parámetros estadísticos de las magnitudes a controlar para la detección, como medias o desviaciones típicas. Estas medias y desviaciones serán sobre los datos adquiridos durante el periodo que dedica la aplicación al análisis del escenario a vigilar en condiciones de no movilidad y determinarán en gran medida las estimaciones de los niveles de detección del sistema, así como, derivado de esto, el comportamiento de fiabilidad del sistema que vendrá caracterizado por el parámetro de probabilidad de falsa alarma.

6.2.- Funciones de densidad de probabilidad Por lo anteriormente expuesto no se debe pensar que la mayor o menor fiabilidad del sistema sólo está sujeta o es dependiente de la estimación en tiempo real de la media o desviación típica muestral tanto en el caso de igualdad como de similitud; sino que mucha importancia en la estimación de los niveles de vigilancia la tiene una elección acertada de las funciones de densidad de probabilidad que se usarán para la estimación de la probabilidad de falsa alarma y que modelan acertadamente la población de muestras adquiridas por el sistema. Es decir, igual de importante para la elección de un adecuado nivel de disparo es la estimación en tiempo real de los parámetros de la media y desviación típica muestral como la elección en tiempo de diseño de una función de densidad de probabilidad que modele al sistema adecuadamente. Para la elección de la función de densidad de probabilidad es necesario hacer un estudio de las muestras capturadas por el sistema. Con ayuda del Matlab visualizamos las muestras volcadas por el sistema en ficheros de datos que servirán de entrada para que con Matlab realizar las operaciones pertinentes.



A continuación se muestran dos gráficos que representan las muestras tomadas por el sistema; se capturan los fotogramas y se calcula la medias de las diferencias y las correlaciones, estos datos se vuelcan en un fichero y visualizándolos obtenemos:

Fig. 6.1.

Fig. 6.2.



Vista las figuras anteriores, comentémoslas: La figura 6.1 es el resultado de una simulación en que se han capturado 500 fotogramas, el algoritmo de igualdad procesa estos fotogramas capturados calculando la diferencia entre píxeles que ocupan la misma posición en la sección de vigilancia en fotogramas consecutivos y haciendo su media, de modo que lo que esta gráfica representa es la media de la diferencia de los píxeles de la sección de vigilancia de un fotograma y su consecutivo en una secuencia de 500 fotogramas.

Estas capturas anteriormente mostradas se han realizado en un escenario donde

no existía ningún tipo de movilidad, quiere esto decir que en condiciones ideales se debería haber obtenido una gráfica constante en el 0 ya que idealmente al no existir ningún movimiento captado por la cámara un fotograma debería tener en idénticas posiciones idéntico valor de sus píxeles y por tanto la diferencia entre los píxeles de fotogramas consecutivos sería 0 y de mismo modo su media sería 0. Por tanto podemos afirmar que en las condiciones de no movilidad lo captado por nuestro sistema se corresponde al ruido introducido en el sistema por imperfecciones en la lente de la cámara, por el cable de transferencia de la cámara al PC, por la conexiones del cable, etc. Este ruido se puede estudiar como un proceso aleatorio pues la figura 6.1 no se volverá a repetir, sino que en cada realización del proceso se obtendrá una gráfica diferente, pero en lo que si coincidirán ambas será en la función de densidad de probabilidad.

En el caso de la figura 6.2 se representa el resultado de una captura también de

500 fotogramas pero a los que esta vez se les ha aplicado el algoritmo de similitud. En este caso lo que se hace es calcular la correlación entre un fotograma y su consecutivo, y esto se usa como una medida del parecido entre fotogramas consecutivos.

Por las propiedades de la correlación se tiene, que en condiciones ideales y

cuando no existe movimiento captado, si dos fotogramas consecutivos son exactamente idénticos su correlación es 1 que es el máximo valor que puede tomar la correlación. Si observamos la figura 6.3, como no podía ser de otro modo, vemos que la correlación está siempre por debajo de la unidad y además muy cercana a ésta. Por tanto concluimos que esta desviación que presenta la gráfica respecto de la unidad es debida al ruido introducido por el sistema y que este ruido al igual que en el caso de igualdad tiene un comportamiento aleatorio que ha de obedecer a una función de densidad de probabilidad. El resultado que se obtiene al visualizar el ruido es distinto en cada realización de este al tratarse como ya se ha comentado de un proceso aleatorio de modo que la forma que tenemos de estudiarlo es mediante la estadística.

A continuación capturaremos una realización del proceso aleatorio y veremos su

histograma. Para el histograma que aquí se va a presentar se ha obtenido mediante una función en Matlab que nos permite ajustan el intervalo de resolución del histograma con lo que vamos a obtener gráficas con mayor nivel de detalle y nos permitirá observar el parecido de estos histogramas resultados de la realización con la representación de funciones de densidad de probabilidad muy usadas en la estadística

Para estas gráficas se han capturado 5000 fotogramas, los resultados que se

obtiene son los siguientes:



Fig. 6.3.

Fig. 6.4. En la figura 6.3 se observa la realización de 5000 muestras captadas en un escenario en ausencia de movilidad procesadas por el algoritmo de igualdad. Si hacemos un calculo de la media y la desviación típica muestral se obtiene que:



6779.1=µ 0904.0=σ

Veamos ahora para una realización del proceso de 5000 muestras procesadas con el algoritmo de similitud; los datos obtenidos son los siguientes:

Fig. 6.5.

Fig. 6.6.



En la figura 6.5 se muestras las 5000 correlaciones de los 5000 fotogramas capturados en un escenario en ausencia de movilidad, vemos que en algunos casos se ha dado que dos fotogramas consecutivos son totalmente similares y se dan los picos en los que la correlación alcanza el 1. Para esta realización del proceso tenemos que se han obtenido:

999028.0=µ 510724169.7 −⋅=σ En la figura 6.4. se muestra el histograma para los datos de la captura de 5000 fotogramas a los que se les aplicó el algoritmo de igualdad y en la figura 6.6 se tiene ese mismo histograma para el caso de aplicar el algoritmo de similitud. Como vemos en ambos casos obtenemos una concentración de muestras que resultan dar una envolvente con forma muy parecida a la de la campana de Gauss, de forma que aprovechando esta similitud aproximaremos los datos extraídos de las secuencias de imágenes con ausencia de movilidad y los aproximaremos por una normal. Como en estos casos en los que capturamos secuencias sin movimiento ya hemos explicado que las observaciones obtenidas, que difieren de 0 en el caso de igualdad y de 1 en caso de similitud, son debidas al ruido, lo que se está haciendo es tomar una aproximación normal para el modelo de ruido. De esta forma ya tenemos caracterizado el modelo de ruido por una función de densidad de probabilidad como la que sigue:

),( 2σµNX ≈

2

21

21

)(

−⋅−

⋅⋅⋅

= σµ

πσ

x

X exf

Donde: [ ] µ=XE

[ ] 2σ=XVar Cuya representación gráfica es la siguiente:

Fig. 6.7.



En este caso para la construcción de la campana de Gauss en Matlab se le ha dado una media µ = 0 varianza σ2 = 1 y esta será la forma que tome nuestro modelo de ruido. Con todo lo expuesto anteriormente se ha demostrado que las muestras capturas por nuestro sistema se corresponden a las de un proceso aleatorio de distribución normal, de modo que demostrado esto veamos como sería el calculo de la probabilidad de falsa alarma que, como ya se ha explicado, será el parámetro que se usará para el cálculo del nivel de disparo.

6.3.- Probabilidad de falsa alarma y nivel de disparo.

Como ya se ha definido en el apartado 6.1 la probabilidad de falsa o Pfa es la que se da en caso de que sin existir el suficiente movimiento en la imagen se haga saltar la alarma como si efectivamente existe el movimiento suficiente. Este caso se da en aquellos sistemas en los que el nivel de detección es accesible por el nivel de ruido de modo que sin existir un movimiento en la imagen el ruido es capaz de hacer saltar la alarma.

. Veamos ahora cual es la relación entre la probabilidad de falsa alarma y el nivel de ruido caracterizado por su función de densidad de probabilidad antes descrita. Para ello se presentan una gráficas donde de dibuja cual sería la probabilidad de falsa alarma para unos determinados niveles de detección. En estas gráficas sólo se han tenido en cuenta los valores de µ y σ calculados en el apartado anterior pero las muestras no son las capturadas por la cámara sino las de una realización del proceso aleatorio gaussiano en Matlab, de este modo la explicación queda más clara y no es necesario hacer una captura con la cámara excesivamente larga.

Fig. 6.8.



Para el caso de un procesamiento por el algoritmo de igualdad (que es al que corresponde la situación que se da en la figura 6.8) resultará que habrá más movimiento entre fotogramas consecutivos cuanto mayor sea la diferencia entre ellos; como en este caso lo que usamos como variable aleatoria es la media de esta diferencia, esta media será tanto más elevada cuanto mayor sea la diferencia; es por esta razón, que en el caso de igualdad, la integral de la función de densidad de probabilidad a partir de lo que en la gráfica se ha denominado Vp es la Pfa pues es la probabilidad de que el ruido sea lo suficientemente alto para rebasar por exceso el umbral Vp. A continuación se describirá analíticamente lo que en la figura 6.8 se describe gráficamente: Nuestra función de densidad de probabilidad es:

),( 2σµNX ≈ 2

21

21

)(

−⋅−

⋅⋅⋅

= σµ

πσ

x

X exf Donde: [ ] µ=XE y [ ] 2σ=XVar

⋅−

⋅=⋅⋅⋅

−=<−=>=

−⋅−

∫ σµ

πσσ

µ

221

21

1)(1)(

2

21

0

VperfceVpXPVpXPPfa

xVp

Donde erfc(x) es la función complementaria del error. Veamos ahora la gráfica para el caso de detección por similitud:

Fig.6.9



Ahora en el caso de la detección de movimiento por el algoritmo de similitud se tiene que estamos usando como variable aleatoria la correlación entre fotogramas consecutivos; de modo que cuanto más movimiento haya entre un fotograma y su consecutivo más descenderá esta variable aleatoria frente a 1. Si este descenso de la correlación es debida al ruido entonces se producirá una falsa alarma, es por esta razón que ahora el cálculo de la probabilidad de falsa alarma relacionada con el nivel de disparo sería la integral de la función de densidad de probabilidad hasta el valor Vp, pues en caso de no movilidad obtener valores que rebasen por defecto el umbral Vp serían debidos a incursiones del ruido que darían lugar a falsas alarmas. La figura 6.9 viene a describir esta situación, el análisis matemático sería: Nuestra función de densidad de probabilidad es:

),( 2σµNX ≈ 2

21

21

)(

−⋅−

⋅⋅⋅

= σµ

πσ

x

X exf Donde: [ ] µ=XE y [ ] 2σ=XVar

⋅−

⋅−=⋅⋅⋅

=<=

−⋅−

∫ σµ

πσσ

µ

221

12

1)(

2

21

0

VperfcdxeVpXPPfa

xVp

Nuevamente se obtiene una expresión de la probabilidad de falsa alarma en

función de la función complementaria del error. A continuación se demuestran las expresiones para la Pfa tanto para el caso de

igualdad como para el caso de similitud: Partiendo de la función de densidad de probabilidad normal ),( 2σµNX ≈ se

tiene que para calcular la probabilidad acumulada se ha de resolver:

dxeVpXPVp x

∫

−⋅−

⋅=<

0

21 2

21

)( σµ

πσ

Realizando el cambio de variable:

−

⋅=σ

µxt

21

dxdtσ⋅

=21

Nos queda como sigue:

∫ ∫∫⋅

−

∞

⋅

−

−⋅

−

−− =−==⋅⋅⋅⋅

=<2

02

2

0

222 11

12

21

)(σ

µ

σ

µ

σ

µ

ππσ

πσ

Vp

Vp

t

Vp

tt dtedtedteVpXP

⋅−

⋅−=22

11

σµVp

erfc

Esto sería para el caso de similitud donde la expresión anterior daría lugar a la

probabilidad de falsa alarma:

⋅−

⋅−=22

11

σµVp

erfcPfa



Para obtener la expresión en el caso de igualdad solo debemos tener en cuenta que:

( )

⋅−

⋅=<−=>22

1)(1

σµVp

erfcVpXPVpXP

Y por lo tanto la probabilidad de falsa alarma es:

⋅−

⋅=σµ

221 Vp

erfcPfa

6.4.- Obtención del nivel de disparo En el apartado anterior se ha llegado a las expresiones para la obtención de la

probabilidad de falsa alarma ( Pfa ) en función del nivel de disparo Vp. El cálculo de la función erfc(x) se lleva a cabo por medio de un algoritmo de ajuste pues esta función no tiene una expresión analítica que se pueda evaluar. Pero el verdadero problema no está en el cálculo de la función complementaria del error ni por extensión en el cálculo de la Pfa, sino que se encuentra en el cálculo de la función inversa de la erfc(x); es decir, estamos interesados en el cálculo de Vp que es el nivel de disparo a partir del cual se hará saltar la alarma, es preciso por lo tanto buscar la forma de invertir la función complementaria del error; es decir:

En caso de igualdad: ( ) µσ +⋅⋅⋅= − PfaerfcVp 22 1 En caso de similitud: ( )( ) µσ +−⋅⋅⋅= − PfaerfcVp 122 1

Para la resolución de las expresiones anteriores se ha optado por el diseño de una subrutina que converge al valor de Vp hasta obtener un error con la Pfa menor de Pfa*0.001 . Esta rutina converge siempre al valor de Vp que da lugar a la Pfa introducida (o muy próxima a ella) como parámetro a la aplicación, gracias a que la función acumulativa de probabilidad es monótona. Lo que se describe en este párrafo quedará más claro una vez que se explique el diagrama de flujo para el cálculo de Vp:

Inicio

iter = 0 cond = true xinf = 0 xsup = 1 xmed = 0 pmed=0

1



SI NO NO SI SI NO SI NO SI SI NO NO

1

modo=igualdad xsup=xsup*255

cond=true AND iter < 10000

iter=iter+1 xmed=(xsup+xinf)/2

pmed=intpdf(xmed,vmedia,vdesv)

Abs(pmed-pfa)<pfa*0.001

Pmed<Pfa

modo=igualdad

xinf=xmed xsup=xmed

modo=igualdad

xsup=xmed xinf=xmed

cond=false

Devuelve(xmed)

Fin



El algoritmo descrito por el diagrama de flujo anterior nos devuelve un valor de

Vp tal que se aproxima a la Pfa introducida por parámetro con un error que está comprendido entre ±Pfa*0.001, es decir:

⋅−

⋅≅⋅±σµ

221

001.0Vp

erfcPfaPfa En caso de igualdad

⋅−

⋅−≅⋅±22

11001.0

σµVp

erfcPfaPfa En caso de similitud

Este algoritmo va calculando la media de dos valores extremos entre los cuales

se encuentra el valor de Vp para el que se obtiene la probabilidad de falsa alarma introducida como parámetro a la aplicación. El método de convergencia es muy simple y se fundamenta en el hecho de que la función acumulativa de la probabilidad es monótona; cuando se calcula xmed y se evalúa para obtener pmed, dependiendo del modo de detección y comparando con el valor que tiene pfa, sabemos si el valor de Vp está a la derecha o izquierda de xmed y de este modo vamos actualizando los valores de xinf o xsup con xmed según corresponda.

Veámoslo gráficamente para el caso de igualdad:

Fig. 6.10.

En la gráfica se muestra dos iteraciones para calcular el valor de Vp. En este

caso Vp coincide con xmed2, resultado de la segunda iteración del algoritmo. El valor de xmed se obtiene con la media de los valores extremos xinf y xsup ; se evalua la probabilidad de falsa alarma perteneciente a este valor de xmed y se compara con la Pfa introducida como parámetro a la aplicación. En este caso se ha obtenido en la primera



iteración de la grafica una pmed mayor que pfa y además pmed – pfa >pfa*0.001, por lo tanto no se dan las circunstancias para detener el algoritmo. Se asigna a xinf el valor de xmed y se realiza una nueva iteración del algoritmo, se calcula de nuevo la media de xinf y xsup y se obtiene xmed2 que evaluando su probabilidad y comparada con la pfa introducida en la aplicación resulta que pmed-pfa<pfa*0.001; con lo que se detiene el algoritmo y se devuelve el valor de xmed2 como valor de Vp. Para el caso del algoritmo de igualdad se inicializan del siguiente modo xinf=0 y xsup=255.

Veamos una representación del proceso del algoritmo de cálculo de Vp en el

caso de procesamiento por similitud. La función del algoritmo y su funcionamiento son idénticos a la del caso de igualdad, la única diferencia radica en la inicialización de xinf y xsup que en este caso es xinf=0 y xsup=1 puesto que la correlación está acotada a 1.

Fig. 6.11.

En la gráfica se ve como converge xmed hacia Vp, la ejecución de la última iteración del bucle nos da una xmed cuya probabilidad se acerca a la Pfa con un error menor de 0.001*Pfa que es condición para que se acabe de ejecutar la rutina de cálculo de Vp, de hecho, el valor de xmed2 es lo que se devuelve como valor umbral. A simple vista puede parecer que este algoritmo tiene una convergencia lenta hacia el valor Vp, de hecho sería así si tenemos que ajustarnos al verdadero valor de Vp que da la Pfa que se introduce como parámetro a la aplicación; pero dando como condición para salir del bucle que nos aproximemos a la Pfa con un error valido de 0.001*Pfa el número de iteraciones del bucle se reduce considerablemente.



Para demostrar esto anterior se presenta a continuación una tabla donde se muestran el número de iteraciones necesarias para distintos valores de Pfa y para los dos modos distintos de detección, igualdad y similitud:

Pfa

Nº de iteraciones IGUALDAD

Nº de iteraciones

SIMILITUD

10-1 16 20

10-2 21 23

10-3 23 21

10-4 23 24

10-5 20 25

10-6 23 25

10-7 23 25

10-8 22 22

10-9 22 20

Vemos que para ambos casos de detección se obtienen un número aproximado

de iteraciones, además la diferencia de iteraciones para distintas Pfa es reducido. No obstante este tiempo no relentiza la aplicación de videovigilancia ya que el cálculo de Vp se realiza antes de que la aplicación entre en régimen permanente.

6.5.- Representación de datos frente a nivel de disparo En es apartado nos hemos dedicado a desarrollar el fundamento matemático y

estadístico que se ha utilizado para calcular el nivel de disparo Vp a partir del cual se hará saltar la alarma del sistema de vigilancia. Pienso que puede ser interesante realizar una representación gráfica de los datos sacados del sistema y los distintos niveles de detección Vp para distintas Pfa y ver en la gráfica cual es la distancia existente entre los datos y los niveles que hacen saltar la alarma.



A continuación se muestra la gráfica para la detección por igualdad de las muestras y los distintos niveles de detección en función de Pfa:

Fig. 6.12. Y por último la gráfica para la detección por similitud que representa las

muestras de correlación y los distintos niveles de detección en función de Pfa:

Fig. 6.13.


Algoritmo de Detección por Igualdad Página 50

7.- ALGORITMO DE DETECCIÓN POR IGUALDAD

Este algoritmo de detección por igualdad pertenece al bloque funcional de

procesamiento de la imagen que se explicó en el apartado denominado como división funcional.

El método de análisis denominado por igualdad es aquel que lleva a cabo la

detección del movimiento comparando píxel a píxel fotogramas consecutivos de la imagen calculando la diferencia natural del valor de los píxeles de dichos fotogramas. El algoritmo no distingue la diferencia de los píxeles por exceso o por defecto, sino que se queda con el valor absoluto de esta diferencia y sobre esta realiza la media que será el parámetro de comparación y que va siendo calculado por este algoritmo en tiempo real.

Cámara

Captura ........ T

Fotograma n Fotograma n+1 +

Alarma

Media ( Fotograma n+1 - Fotograma n )

Comparación ( Nivel de disparo , Media )



A continuación se muestra el diagrama de flujo detallado que describe el algoritmo de la detección por igualdad en condiciones de régimen permanente. Estas condiciones de régimen permanente se refieren al hecho de que ya se han realizado las labores del algoritmo del calculo estadístico para el nivel de disparo y se está procesando los fotogramas y calculando la diferencia de los píxeles de dos consecutivos y su media para compararla en tiempo real con el nivel de disparo.

7.1.- Diagrama de flujo

NO SI NO SI

Inicio régimen permanente

m_Running = Verdadero

Captura (fotograma1)

C = 0

Captura (fotograma2) diferencia(fotograma1,fotograma2)

c_media( media, fotograma1 )

med=media[1499]

med = 0

1 2 3



SI

NO

Este diagrama de flujo implementa un bucle que se realiza hasta que con un evento de botón se hace que m_Running = false, cuando este evento tiene lugar se finaliza el proceso de detección por igualdad. Mientras m_Running = true se van capturando fotogramas y se va calculando la media de la diferencia de los píxeles de dos fotogramas capturados consecutivamente. Existe una diferencia entre la primera pasada del bucle y el resto de ellas, esta primera iteración viene determinada por el valor de C = 0 y la diferencia consiste que en la primera pasada se capturan dos fotogramas, el que se captura en todas las iteraciones ( Fotograma1 ) y un segundo fotograma que sólo se calcula en la primera ( Fotograma2 ) y que sirve para realizar el primer cálculo de la diferencia entre fotograma y dar condiciones iniciales al régimen permanente. El valor de la media en cada iteración se almacena en el índice 1499 de la tabla que almacena las medias en el periodo de cálculo de estadísticos y es devuelto por la función “c_media”. La función que devuelve la resta de dos fotogramas consecutivos se denomina en el diagrama de flujo “diferencia” y actualiza el fotograma n con el fotograma n+1 y de este modo en régimen permanente siempre se calcula la diferencia de dos fotogramas consecutivos. Por último, se realiza la comparación en cada iteración del bucle del nivel de disparo con la media que se ha calculado en esa iteración y dependiendo si el valor de la media supera o no el valor del umbral de disparo se hace o no saltar la alarma. Como ya se ha mencionado, en este diagrama no se ha representado el código que da la funcionalidad de cálculo de estadísticos y de nivel de disparo a la aplicación puesto que en este apartado se explica el régimen permanente del algoritmo de detección por igualdad. A continuación se muestran los diagramas de flujo de las subrutinas encargadas del cálculo de las diferencias de los píxeles de dos fotogramas consecutivos y la de cálculo de la media de las diferencias:

1

med > nivel disparo

ALARMA

2 3

Fin régimen permanente



7.2.- Diagrama de flujo. Calculo de la media NO SI NO SI

Inicio c_media

sum = 0 i = x_super j = y_infer

i <=x_infer

i = i+1

j <=y_super

j = j+1 sum = sum + data[ ancho*j+i ]

media[n_init-1] = sum / tam

Fin c_media



Esta función calcula la media del valor de los píxeles del fotograma al que apunta el puntero data. A la altura de la llamada a esta función el puntero data contiene un fotograma diferencia del fotograma que tenía almacenado y del capturado en la iteración anterior del hilo de captura, de modo que esta función devuelve la media del valor de los píxeles de la diferencia que nos da idea del movimiento en la imagen. Esta función no devuelve ningún valor sino que modifica el índice 1499 de la tabla de medias pues este es el lugar de la tabla donde se va almacenando la media calculada en tiempo real, por lo tanto a esta función también se le pasa como parámetro el valor n_init = 1500. También se le pasa como parámetro el tamaño en número de píxeles de la zona de vigilancia. A continuación se muestra diagrama de flujo de la función diferencia.

7.3.- Diagrama de flujo. Diferencia de fotogramas NO SI NO SI

Inicio diferencia

dif = 0 i = x_super j = y_infer

i <= x_infer

i = i+1

j <=y_super

1 2 3



NO SI

En la función “diferencia” como su propio nombre indica se calcula la diferencia de los píxeles de dos fotogramas capturados consecutivamente que son pasados a la función mediante dos punteros: “data” y “data2”. En el puntero “data” se tiene el fotograma de la captura posterior al que está contenido en el puntero “data2” y esta misma función, además de realizar la diferencia, carga el fotograma de “data” en “data2” para que esta función se comporte igual en la próxima iteración cuando ya se haya calculado un nuevo fotograma para “data”.

1

j = j+1 dif = data[ancho*j+i]-data2[ancho*j+i] data2[ancho*j+i]=data[ancho*j+i]

dif > 0

data[ancho*j+i]=dif data[ancho*j+i]=-dif

2 3

Devuelve ( data )

Fin diferencia


Algoritmo de Detección por Similitud Página 56

8.-ALGORITMO DE DETECCIÓN POR SIMILITUD

Este algoritmo de detección por similitud, al igual que el algoritmo de detección por igualdad, pertenece al bloque funcional de procesamiento de la imagen que se explicó en el apartado denominado como división funcional.

Este método de análisis lleva a cabo la detección de movimiento realizando la

correlación de dos fotogramas capturados de forma consecutiva. En este algoritmo, a diferencia del algoritmo de detección por igualdad, no es necesario calcular la media pues la correlación es un parámetro que ya en si mide cuanto de similares son dos fotogramas consecutivos y no es un parámetro que se calcule para cada píxel como sería la diferencia para la cual si es necesario realizar una media de todas las diferencias calculadas, una por cada píxel de la imagen.

Para este algoritmo la medida del movimiento capturado se refleja en el valor de

correlación que es el que se compara con el valor umbral de disparo para determinar si hay suficiente movimiento para hacer saltar la alarma o por el contrario el movimiento capturado es sólo perteneciente al ruido en tal caso no se sobrepasaría el umbral y por lo tanto no se haría saltar la alarma.

Cámara Captura ....... T

Fotograma n Fotograma n+1 Alarma

Correlar (Fotograma n+1,Fotograma n)

Comparación( Nivel de disparo,Correlacion )



A continuación se muestra el diagrama de flujo detallado que describe el

algoritmo de la detección por similitud en condiciones de régimen permanente. Estas condiciones de régimen permanente se refieren al hecho de que ya se han realizado las labores del algoritmo del cálculo estadístico para el nivel de disparo y se está procesando los fotogramas, calculando la correlación para dos fotogramas capturados consecutivamente y comparando el resultado de dicha operación con el nivel de disparo.

8.1.- Diagrama de flujo

NO SI

Inicio régimen permanente

p1= Memoria(tam)

m_Running = Verdadero

Captura (fotograma1)

P2= Memoria(tam)

p1=correlar (fotograma1, p1, p2,correlacion)

corr = correlacion[1499]

1 3 2



SI NO El bucle implementado en el diagrama de flujo del régimen permanente para el algoritmo de similitud termina cuando m_Running = false y esto ocurre cuando se pulsa el botón de fin de aplicación. Mientras m_Running = true se van capturando fotogramas y se va calculando la correlación de dos fotogramas capturados consecutivamente. Existe también para este algoritmo de detección una diferencia con la primera pasada del bucle y las siguientes: La diferencia consiste que al igual que en el caso del algoritmo de detección por igualdad en la primera pasada se han de capturar dos fotogramas mientras que en el resto de iteraciones del bucle sólo se calcula un fotograma. Pero esto anteriormente mencionado se realiza de forma distinta que para el caso de detección por igualdad ya que ahora la discriminación de la primera iteración se lleva a cabo en la función “correlar” y no se tiene en cuenta en el bucle principal; esto es necesario porque inicialmente necesito dos fotogramas para realizar la primera correlación de dos fotogramas consecutivos y dar condiciones iniciales al algoritmo de detección. El valor de la correlación calculado en cada iteración se almacena en el índice 1499 de la tabla que almacena las correlaciones en el periodo de cálculo de estadísticos y es devuelto por la función “correlar”. Además esta función tiene como parámetro de retorno el puntero p1 que apunta a uno de los fotogramas que en la próxima iteración se correlará con el que se capture en esa iteración. Como última instrucción del bucle se realiza la comparación en cada iteración del nivel de disparo con la correlación que se ha calculado en esa iteración y dependiendo si el valor de la media supera o no el valor del umbral de disparo se puede o no hacer saltar la alarma. Como ya se ha mencionado en esta memoria, en este caso de

1 3

corr < nivel disparo

2

ALARMA

Fin régimen permanente



detección por similitud la alarma salta cuando la correlación es menor que el nivel de disparo ya que cuanta más diferencia exista entre fotogramas consecutivos más descorrelados estarán estos fotogramas y menor será el resultado de su correlación. En este diagrama no se ha representado el código que da la funcionalidad de cálculo de estadísticos y de nivel de disparo a la aplicación puesto que en este apartado se explica el régimen permanente del algoritmo de detección por similitud; y el cálculo estadístico y del nivel de disparo se explican en otros apartados de esta memoria. A continuación se muestra el diagrama de flujo de la función “correlar” que realiza la correlación de dos fotogramas consecutivos y devuelve el valor de esta correlación en un elemento de una tabla.

8.2.- Diagrama de flujo. Cálculo de correlaciones.

NO SI

NO SI

Inicio correlar

corr = 0 corr_p2 = 0

n_init = 1

[ paux ] = 0 i = x_super j = y_infer

i <= x_infer

i = i + 1

1 2 3 4



NO SI NO

SI NO

SI

1

j <= y_super

j = j + 1 p1[ancho_rect*(j-y_infer)+(i-x_super)]=data[ancho*j+i]

2 3 4

p = 0

p < tam

p = p + 1 [ paux ] = [ paux ]+(p1[p]*p1[p])

corr = [ paux ] /sqrt( [paux]*[paux] ) correlacion[n_init-1] = corr

Devuelve ( p1 )

n_init > 1

corr = 0 corr_p2 = 0 i = x_super j = y_infer

1 2



NO SI NO SI NO SI

1

i <= x_infer

2

i = i +1

j <= y_super

j = j + 1 p2[ancho_rect*(j-y_infer)+(i-x_super)] = data[ancho*j+i]

p = 0

p < tam

p = p + 1 corr = corr +(p1[p]*p2[p]) corr_p2 = corr_p2+(p2[p]*p2[p])

corr = corr / sqrt( [ paux ]*corr_p2) correlacion[n_init-1] = corr Liberar ( p1 ) [ paux ] = corr_p2

Devuelve ( p2 )

Fin correlar



Observando el diagrama de flujo de la función encargada de realizar la correlación se observa, como ya se ha dicho anteriormente, que la discriminación entre la primera pasada y las siguientes se realiza dentro de esta función y no en el bucle de captura principal. Esto se debe a que dependiendo de si es el primer fotograma u otro consecutivo la correlación que se ha de calcular es diferente: Para el primer fotograma, como no tenemos otro con quien correlarlo solamente se realiza la autocorrelación con si mismo ( que como no puede ser de otro modo dará como resultado la unidad ) y se almacena en una variable puntero ( que en el diagrama se flujo se ha representado como [ paux ] = contenido del puntero paux ) la suma acumulativa del producto de todos los píxeles, que será un dato a usar en la próxima iteración. Para el caso de cualquier otro fotograma la correlación que se calcula es la correlación cruzada entre el fotograma capturado en esa iteración y el capturado en la iteración anterior, y también se calcula, puesto que es necesario para esta iteración y la posterior, la suma acumulativa del producto de todos los píxeles del fotograma calculado en esta iteración que se vuelve asignar al contenido del puntero paux. Hay que tener claro que la operación que este algoritmo esta realizando en la que obedece a la expresión matemática:

∑ ∑

∑

= =

=

−⋅⋅−⋅

−⋅=

M

K

M

K

M

KXY

lkYkYlkXkX

lkYkXlC

0 0

0

)()()()(

)()()(

De modo que hay que arrastrar de una iteración a otra el valor de la suma acumulativa del producto de los píxeles del fotograma captado en esa iteración pues si seguimos la nomenclatura de la formula X e Y serían fotogramas capturados en distintas pasadas del bucle que correspondería a distintas llamadas a la función correlar y por esta razón es necesario guardar el valor de los parámetros en variables puntero para que al acabar la función no se pierdan los resultados calculados y que se han de usar en la iteración siguiente. También relacionado con lo anterior se explica el tipo de parámetro devuelto por la función correlar: Devuelve como parámetro en la primera iteración el puntero p1 que almacena el fotograma capturado en esa iteración y servirá para que en la siguiente iteración se le pase a la función correlar como puntero que almacena al fotograma antiguo ya que en la segunda iteración y sucesivas se devolverá el puntero p2 que es el capturado en esta iteración y que se almacenará en puntero p1 para ser el fotograma antiguo se la siguiente iteración. Esto es necesario hacerlo así porque estos fotogramas son usados en dos iteraciones consecutivas y no podemos perderlos de una a otra, es necesario por lo tanto que esta función devuelva un puntero como parámetro de salida.



También es interesante comentar que al tratarse de una función compleja que realiza varias operaciones, es necesario que almacene valores en tablas que sean pasadas por referencia ya que es necesario que de una iteración a otra pasen más de un dato. Este diagrama de flujo se ha pretendido hacer lo más claro posible y es por esa razón que se han omitido una serie de parámetros de estrada a la función sin los cuales sería imposible su funcionamiento. Uno de estos parámetros importantes es por ejemplo de número de iteración del bucle de captura que aparece con el nombre de n_init o el tamaño de la zona a correlar que aparece con el nombre de tam, sin tener en cuenta los parámetros globales de la aplicación de los que también hace uso la función.


Desarrollo de la Aplicación Software Página 64

9.-DESARROLLO DE LA APLICACIÓN SOFTWARE

9.1.-Introducción Como ya se ha mencionado en apartados anteriores de esta memoria, el producto final que se obtendrá en el desarrollo de este proyecto fin de carrera será una aplicación software de videovigilancia. Todo el fundamento matemático, estadístico y técnico que se han explicado en apartados anteriores tienen como finalidad fundamentar el trasfondo de los algoritmos que de desarrollaran en un determinado lenguaje de programación con el que se obtendrá una aplicación encargada de realizar la videovigilancia de una determinada zona de un escenario. Por lo tanto, en el desarrollo de este proyecto no sólo se me han presentado los problemas derivados del análisis de señal, para los cuales he empleado técnicas de tratamiento de señal y los conocimientos de matemática y estadística adquiridos en la carrera; sino que me he visto obligado a profundizar en el siempre complicado tema de la programación y más concretamente en la Programación Orientada a Objeto (POO). Pero no sólo en la POO he tenido que indagar para la realización de este proyecto software sino que también he tenido que adquirir conocimientos y ponerlos en prácticas en otros aspecto fundamentales de la programación actual como son: La gestión de eventos y la programación de una interfaz gráfica para mi aplicación. A continuación dentro de esta introducción se llevará a cabo una pequeña explicación de estos tres aspectos enunciados anteriormente y que cuyas características van a definir en gran medidas muchos de los aspectos de la aplicación desarrollada en este proyecto tan o en su vertiente estructura como de representación gráfica:

9.1.1.- Programación Orientada a Objetos El paradigma de la POO contempla tanto el análisis del problema a solucionar así como el diseño y la implementación del programa encargado de solucionar dicho problema; esto es un aspecto nuevo introducido por la POO ya que otros paradigmas de programación ( como son el funcional, el imperativo,...) solamente tiene en cuenta el aspecto de programación de los algoritmos sin entrar en diseño ni implementación de los mismos. En la POO el sistema se va a construir a partir de componentes individuales conocidos como objetos. Un objeto se define como “Encapsulación abstracta de información ( atributos ) junto con los métodos o procedimientos diseñados y



encargados de la manipulación de esta información”. Relacionado con el tema de este proyecto, un objeto podría ser un contendor para una imagen y sus atributos serían el ancho y el alto en número de píxeles y uno de sus métodos podría ser una determinada función encargada de devolver cual es su tamaño o modificarlo en tiempo de ejecución según no haga falta más o menos resolución ( esto que se ha definido aquí como un ejemplo esta recogido en la aplicación como un objeto real que se utilizará para el desarrollo del proyecto ). También existe en la POO el concepto de clase que está íntimamente relacionado con el concepto de objeto y que se define como “la generalización de un tipo específico de objetos”. Es en las clases donde se generaliza las características propias del tipo de objeto; es decir , siguiendo con el ejemplo anterior si en mi programa necesito utilizar distintos contenedores para fotogramas con distintas características de resolución en mi clase defino esta característica como un atributo de la clase y en cada instancia de ella la particularizo para una u otro resolución. La instancia se define como “la concreción de una clase”, es cuando se da un nombre y se reserva memoria para un objeto de una determinada clase en el espacio de memoria de la aplicación se dice que ese objeto es una instancia o ejemplar de la clase o también que dicho objeto se ha instanciado. En nuestro ejemplo una instancia de un objeto de la clase contenedor podría ser un contendor llamado “frame1” que ocupase en memoria 320x240 bytes, estaría instanciado pues en el podríamos almacenar un fotograma capturado por la aplicación y con resolución 320x240 píxeles en escala de grises. La comunicación entre una aplicación y un objeto se lleva a cabo mediante mensajes y métodos: Un mensaje se envía a un objeto para solicitar que haga algo, los métodos serían los mecanismos por los que ese determinado objeto puede llevar a cabo lo solicitado en el mensaje; este es el mecanismo que se ha de llevar a cabo para la comunicación con los objetos de una clase. mensaje Resp=metodo(mensaje) mens Resp=metodo(mens) Fig. 9.1

APLICACIÓN

Instancia del Objeto A Otra Instancia

del objeto A

Instancia del Objeto B



Este sistema de comunicación mediante mensajes y métodos es debido unas de las características más importantes de la POO como es la encapsulación de los objetos: Consiste en “encerrar” dentro de una clase sus métodos y sus propiedades de forma que sólo sean accesibles mediante la interfaz definida por los mensajes que puedan procesar sus métodos. Otras de las características de la POO son la abstracción que consiste en la generalización conceptual de un determinado conjunto de objetos y de sus atributos y metodos; se despreocupa de las características particulares de cada objeto y se abstrae las propiedades comunes de todos los objetos de una clase. Por ultimo la herencia consiste en unas de las propiedades que dota de más potencia a la POO ya que nos permite reutilizar el código y obtener una estructura jerárquica de las clases: Fig. 9.2.

En la figura anterior se muestra una estructura de clases donde la Clase A es la

superclase de la que derivan el resto de clases: Se dice que son subclases de la Clase A. Las clases B, C y D son hijas de la clase A que es padre de ellas. La Clase F es subclase de D y entre ellas existe el mismo parentesco que el existente entre A y D.

La herencia nos va a permitir la reutilización del código, pues todos los métodos

que utiliza la clase A si se deriva convenientemente se pueden usar en sus clases hijas o en sus clases nietas, y esto es la herencia que dejan las superclases a las subclases de estas.

Aunque hay otros factores interesantes en la POO se consideran que estos han

sido los más significativos y los que siempre vamos a tener que considerar cuando se está programando una aplicación orientada a objeto como ha sido el caso en este proyecto.

CLASE F

CLASE B CLASE C CLASE D

CLASE E CLASE G

CLASE A



9.1.2.- Gestión de eventos Tradicionalmente la programación ha sido secuencial, es decir, los programa

estaban compuestos por una sucesión de instrucciones en memoria que se ejecutaban según el orden secuencial que marcaba el hilo de ejecución principal de dicho programa. En estos programas secuenciales, cuando era necesario la interacción de varios procesos o del proceso con el usuario para salida o entrada de datos era necesario que el programa permaneciese en un bucle infinito esperando que esta interacción tuviese lugar esto hacía que se consumiese tiempo de CPU dentro de bucles de espera y por lo tanto que un programa esperando que se diese dicha interacción consumiese recursos de CPU sin darles ninguna utilidad.

La gestión de eventos ha venido a solucionar el problema que se ha planteado

anteriormente y consiste en que cierta parte de código sólo se ejecuta si ha tenido lugar cierto evento que el sistema es capaz de reconocer y gestionar por dicha parte de código. Esto soluciona el problema de consumo de tiempo de CPU esperando que se de un evento en el sistema ya que ahora solo se emplean recursos de la CPU cuando este evento ha tenido lugar y no se consumen esperando que ocurra.

Un ejemplo de lo anterior sacado del proyecto que se ha desarrollado es que no

se comienza la captura de fotogramas hasta que el usuario del sistema no pulsa el botón encargado de inicial la captura, en un programa secuencia esto consumiría tiempo de CPU pues tendríamos al programa esperando en un bucle infinito a que el usuario pulsase el botón; esto ahora no ocurre ya que el propio Sistema Operativo es el encargado de recoger los eventos y dar cuenta de que estos han ocurrido y nos facilita a los programadores dicha información para que con ella decidir que hacer. Por ejemplo, se ha definido que cuando se pulse ese botón el programa pase a ejecutar la rutina de captura de fotogramas; queda de esta forma gestionado el evento de pulsar el botón de inicio de captura.

Veamos como Windows lleva a cabo el proceso de gestión de evento sin que

ello supongo consumo de tiempo de CPU: Cuando un usuario trabaja con una aplicación Windows interactúa con ella mediante el teclado o el ratón; desplazando una barra de desplazamiento, seleccionando alguna opción del menú, arrastrando la ventana, redimensionando su tamaño, etc. La ventana recibe todas estas entradas de usuario en forma de mensaje ( recuerdese lo mencionado anteriormente sobre los mensajes y la forma de comunicación entre aplicación e instancias de una clase, cabe pensar que las ventanas de nuestra aplicación o la misma aplicación en si son objetos de una clase ...) que son enviados por Windows.

Cuando decimos que Windows envía un mensaje a nuestra aplicación queremos

decir que llama a una función dentro de nuestra aplicación y los parámetros de esta función describen dicho mensaje. Esta función se conoce como procedimiento de ventana y tiene que estar presente en cada aplicación Windows para poder gestionar los mensajes que nos envía el Sistema Operativo.

En contra de la metodología de programación MS-DOS, en que era el

programador el que realizaba llamadas al sistema operativo, en caso de Windows ocurre precisamente lo contrario, es el Sistema Operativo el que hace llamadas a nuestro



programa. Cada ventana que crea un programa tiene asociado un procedimiento de ventana. Windows envía mensajes a una ventana a través de una llamada al procedimiento de ventana. El procedimiento de ventana gestiona los mensajes que interesa capturar y luego devuelve el control a Windows. La forma en que Windows reúne todos los mensajes de entrada y lo coloca en la cola de mensajes del sistema es FIFO (el primero en entrar es el primero en ser procesado). El Sistema Operativo elimina entonces cada mensaje de la cola de mensajes del sistema, examina el mensaje para determinar la ventana a la que va destinado y finalmente lo coloca en la cola de mensajes de la aplicación. La aplicación recupera entonces los mensajes que le llega en su cola de mensajes y ha de determinar a cual de todas sus ventanas abierta va destinado este mensaje de Windows. Una vez determinada esta ventana se despacha ( o dirige ) este mensaje al procedimiento de ventana adecuando; despachar este mensaje no es más que una llamada al procedimiento de ventana de la ventana asociada al mensaje pasando el contenido del mensaje en forma de argumentos que será procesado por este procedimiento de ventana. Cuando ya se haya procesado este mensaje se devolverá el control al bucle de mensajes de la función principal de Windows para poder extraer el siguiente mensaje de la cola.

Se ha intentando explicar como Windows lleva a cabo el procesamiento de

eventos de forma sencilla sin entrar en un nivel de detalle de programación, no obstante es un procesamiento complicado que se intentará dejar más claro mediante el siguiente diagrama:

Pulsar evento

Cola de mensajes del sistema Despacha los mens. Cola de mensajes de aplicación A Proc_Ventana_A2(mens) Despacha los mens. Cola de mensajes de aplicación B Proc_Ventana_B2(mens) Fig. 9.3.

Botón de mi aplicación

S.O. Windows

Aplicación B

Aplicación A

Ventana A1

Ventana A2

Ventana B1

Ventana B2



9.1.3.- Programación de una interfaz gráfica Para la realización de este proyecto no sólo se ha tenido que diseñar los algoritmos encargados de medir el movimiento captado por la cámara sino que también, como ya se ha dicho antes, se ha pretendido construir una interfaz gráfica para el usuario del sistema lo más sencilla posible para su uso. Para el diseño de esta interfaz así como para la construcción de las estructuras de objetos se ha hecho uso del MFC AppWizard (exe) que es el asistente para la construcción de aplicaciones basadas en Microsoft Foundation Class (MFC) que es una biblioteca de clases predefinidas de C++ que se suministran junto con Visual C++ y su entorno de desarrollo en el paquete Visual Studio 6.0 que es el usado en el desarrollo de la aplicación. El asistente de aplicaciones de MFC nos creará un armazón de programa que después habrá que adecuar, pero para este armazón inicial hay que configurar que tipo de aplicación queremos crear: Una aplicación de Windows puede ser (Single Document Interface), MDI( Multiple Document Interface) o basada en dialogos ( Dialog Based ). Single Document es muy similar a Dialog Based, salvo que por defecto Visual C++ le agrega menús y MDI es una aplicación como por ejemplo Word, con una ventana principal que puede contener a muchas otras en su interior ( como un contenedor ). Para mi proyecto he seleccionado una aplicación basada en diálogos por lo que por defecto viene huérfana de menús que tendrán que ser diseñados a parte y adecuados para mi aplicación. Otra característica configurable por AppWizard es el uso que debe hacer mi aplicación de la librería MFC, configuraremos está opción para que el uso de esta librería sea como DLL, es decir como librería de enlace dinámico que es lo habitual de las aplicaciones que corren bajo Windows, además si elegimos un uso de la MFC como la librería estática obtenemos un ejecutable más grande. A continuación, en próximos apartados de este punto se explicará como se diseñó el entorno gráfico y la forma de usarlo.



9.2.- Consola de la aplicación de vigilancia Como producto final de este proyecto se pretende presentar un software de vigilancia que trabaje de forma muy eficiente pero que su uso sea también lo simple posible. Para conseguir esto se ha diseñado una interfaz de usuario a modo de consola de control para que una persona puede manejar este software sacando todo el provecho y para ello no sea necesario que disponga de los conocimientos de tratamiento de imagen, de estadística o de programación que se han empleado para su desarrollo. La consola de control de la aplicación de vigilancia se ha diseñado con la idea de que sea lo más parecida posible a las interfaces de usuario de cualquier aplicación diseñada para Windows; para ello ha sido necesario, como ya se ha mencionado en el punto anterior, la programación usando la API de Windows de una aplicación basada en dialogo a la que hemos tenido que añadir un menú cuyo diseño se ha programado para adecuarlo al contexto de videovigilancia sin perder la apariencia de cualquier menú al más estilo Windows. A continuación se presenta la consola de vigilancia:

Fig. 9.4. Como vemos en la imagen la consola de control para el software que se ha diseñado tiene la apariencia de cualquier ventana de las que aparece en cualquiera de los



múltiples programas que usamos a diario y que corren bajo el sistema operativo Windows; con esto se ha pretendido hacer una interfaz de usuario con la que cualquier persona que usase el sistema estuviese familiarizada. Esta aplicación es de la familia de aplicaciones de Windows denominadas aplicaciones basadas en diálogos y tiene la particularidad de que al ser arrancadas dibujan un dialogo en la pantalla; en principio el AppWizard únicamente dota a la aplicación de un sólo dialogo y si barra de menú. El menú que aparece en la imagen se ha diseñado aparte del AppWizard y se ha asociado a la aplicación para dotar a ésta de la posibilidad de configuración de los parámetros del sistema de vigilancia. Vemos que en el dialogo se va mostrando la imagen del escenario que se está vigilando; la imagen es vista en un contenedor que nos ofrece el control VideoOCX y que se encaja en el dialogo de nuestra aplicación y dota a esta de toda la funcionalidad de este control OCX. Como vemos la tecnología de controles OCX y en general de controles ActiveX de Microsoft son una herramienta muy potente para el desarrollo de aplicaciones para la plataforma Windows y hace que el trabajo de programación sea mucho más rápido y eficiente. Esto es debido a que en esta tecnología se hace uso de toda la funcionalidad que pone a nuestro servicio las características de POO que nos permite la reutilización del código de determinados objetos con solo añadir éstos a la nueva aplicación. Otra característica importante de la consola de control de la aplicación es que se puede abrir una por videovigilancia o por escenario a vigilar y queda en manos del sistema operativo llevar el paralelismo de estas dos aplicaciones abiertas a buen termino. Es decir es posible vigilar mas de un escenario distintos al mismo tiempo; pero existe además de la limitación que nos marcará el tiempo de CPU asignado a cada proceso de vigilancia, otra limitación: es necesario disponer de un driver distinto por cada dispositivo de adquisición de datos. Si disponemos de varias cámaras y tarjetas capturadoras / digitalizadoras conectadas al PC y queremos procesar todos los flujos de datos provenientes de ellas de forma concurrente se ha de disponer de un driver por cada una de ellas ya que el driver es un recurso asignado a cada proceso de vigilancia que no permite ser compartido por varios dispositivos. Hemos de decir que en la imagen de la ventana de aplicación no se ha mostrado todos los menús que dotan de funcionalidad al sistema y que serán explicados en puntos posteriores de esta memoria junto a su funcionamiento.



9.3.- Diagrama de Objetos de la Aplicación Para el desarrollo de este proyecto en su parte software se ha hecho uso de las características y funcionalidades que pone a nuestro servicio la POO. Por tanto nuestro sistema consta de un conjunto de objetos que interaccionan entre sí para lograr la vigilancia. A continuación se muestra un diagrama que representa al conjunto de objeto que se han utilizado en el desarrollo del proyecto: Fig. 9.5

CProyectoDlg

CProyectoApp

CVideoOCX

CPicture

CDialogoAutor

CDialogoNivel

CDialogoPfa

CDialogoTiempo

CProyectoZona

CDialogoResolucion



En la figura anterior se muestras los objetos que constituyen la aplicación. Las líneas que se han dibujado entre ellos no representan las líneas de parentesco ellos, sino las dependencias de unos objetos con otros. Es decir que muchos objetos cuelguen del objeto CProyectoDlg significa que el este objeto hace uso de los demás, o que los demás forman parte de ese objeto, ya que el objeto CProyectoDlg hace uso de otros objetos para la configuración de los parámetros o para mostrar la imagen capturada. A continuación se expresa muy brevemente la funcionalidad que son estos objetos; una explicación más detallada se llevará a cabo un poco más adelante en este mismo punto.

CProyectoDlg.- Es el objeto principal al que la aplicación llama cuando se empieza a ejecutar. Visualmente es lo que hasta ahora hemos llamado la consola de la aplicación.

CProyectoApp.- Es el objeto de la aplicación, que inicializa la instancia de la

aplicación cuando se empieza a ejecutar. CVideoOCX.- Es la clase que se encaja en nuestra aplicación debido a incluir el

control VideoOCX, dota a la aplicación de la funcionalidad de este control.

CPicture.- Es una clase de la que hace uso el control VideoOCX, viene a ser

visualmente el marco donde se encaja la imagen. Viene también de incorporar el control VideoOCX.

CDialogoAutor.- Es un dialogo que muestra información sobre el autor del

proyecto. CDialogoNivel.- Es el dialogo donde se muestra las opciones para determinar el

modo de fijar el nivel de disparo. CDialogoPfa.- Es el dialogo donde se fija cual es la probabilidad de falsa alarma

con la que el sistema va a trabajar. CDialogoResolución.- Es el dialogo donde se configura la resolución en píxeles con las

que va a trabajar el sistema. CDialogoTiempo.- Es el dialogo donde se va a configurar el tiempo de captura en

ausencia de movimiento cuyos datos servirán al sistema para la obtención de estadísticos de ruido.

CDialogoZona.- Es el dialogo donde se determinará el segmento de la imagen

donde se aplicarán los algoritmos de vigilancia, en caso de determinarse por coordenadas en este mismo dialogo se hará la introducción de los datos.



9.4.- Menú de la aplicación Como ya se ha mencionado se ha pretendido diseñar para la aplicación objeto de este proyecto un entorno para usuario lo más parecido posible al de todas las aplicaciones que corren bajo Windows. Para ello se ha insertado un menú con diversas entradas que se use para la configuración de los distintos parámetros de la aplicación. Realmente es este menú el que dota de funcionalidad al entorno de usuario de la aplicación permitiendo configurar tiempos de detección, probabilidades de falsa alarma, etc... A continuación se pasará a explicar cada una de estas entradas de este menú y en aquellos casos en los que corresponda se explicará la funcionalidad del dialogo al que esta entrada del menú llame.

9.4.1.- Menú Inicio Inicio constituye la primera entrada del menú de la aplicación; a continuación se muestra esté menú y cuales son sus entradas:

Fig. 9.6.



Como se aprecia en la Figura 9.6. el menú Inicio se despliega en cuatro opciones más que tienen que ver con el Inicio de la actividad del control VideoOCX y del procesamiento de la imagen para llevar a cabo la función de vigilancia. Son por lo tanto opciones muy importante para el correcto flujo del hilo de la aplicación. Se han programado sus eventos para que cualquier incidencia en este o en otro menú no pueda producir estados en las variables de control y flags de la aplicación puedan llevar al sistema a un estado inestable, es decir para que no se produzca lo que vulgarmente se conoce como cuelgue de la aplicación y que no es más que el resultado de no haber tenido en cuenta todos las posibles secuencias de eventos que pudiesen darse en el sistema en manos de un usuario que desconozca el funcionamiento interno de la aplicación. Esto anterior no sólo se ha tenido en cuenta en el menú inicio sino en el diseño de todos los eventos o secuencia de eventos de la aplicación. A continuación se muestra una explicación de cada una de las entradas del menú Inicio:

9.4.1.1.- Iniciar Control ActiveX Para esta entrada del menú Inicio se ha programado el mensaje command de Windows que es el se da cuando hacemos un clic sobre una entrada de un menú. Se ha programado que este mensaje sea gestionado por la función OnInit del objeto ProyectoDlg ( void CPruebaDlg::OnInit ) cuya misión en inicializar el control VideoOCX para posteriormente comenzar la captura y procesamiento de los fotogramas. Esta función aparte de inicializar el control VideoOCX para su uso también inicializa los manejadores de la imagen y el modo de funcionamiento del control; para el caso de este proyecto el modo de funcionamiento será modo 0 que se corresponde con VFW ( Video For Windows ). También se activa una variable de estado global del sistema para que desde cualquier punto del programa sea posible leer si el control está inicializado o no lo está si ellos fuese necesario para el sistema.

9.4.1.2.- Comenzar procesamiento Esta es la segunda entrada del menú Inicio, se ha programado en su mensaje command la función OnStart del objeto ProyectoDlg ( void CPruebaDlg::OnStart ). En esta función se llama a una función global de Visual C++ :



AfxBeginThread(AFX_THREADPROC pfnThreadProc, LPVOID pParam ) Esta es la función que arranca un hilo, en este caso arranca el hilo de captura y procesamiento de la aplicación. Es necesario pasarle dos parámetros:

pfnThreadProc.- Es el primer parámetro de la función y representa el proceso del hilo que se quiere iniciar; es decir, estamos interesados en arrancar un hilo que lleve a cabo una labor en nuestro programa pues este parámetro es el nombre del algoritmo que ha de realizar el hilo, en nuestro caso es la función donde se engloba todo el trabajo de captura y procesamiento de la imagen. La documentación de Visual C++ nos aconseja definir esta función de hilo antes del trozo de código donde se haga la llamada a la función AfxBeginThread. En nuestro proyecto a esta función se le ha llamado CaptureThread. pParam.- Es el parámetro que hay que pasar a la función pfnThreadProc y

representa el objeto que da el control al objeto Thread ( hilo ) creado e inicializado por la función AfxBeginThread y cuya labor se describe por la susodicha rutina pfnThreadProc. En nuestro caso es el puntero this, que apunta al objeto aplicación que hasta el momento de crear el hilo tenía el control de la aplicación.

Además de arrancar el hilo de captura y procesamiento en la función CProyectoDlg::OnStart se calcula el ancho y el alto en número de píxeles del fotograma que se va a capturar, y que previamente a inicializar el procesamiento se ha tenido que configurar en uno de los menús de configuración del sistema como ya se verá más adelante. También se da en esta función el valor true a la variable global del sistema que controla que se ejecute el bucle de captura dentro del proceso que ejecuta el hilo ( en nuestro caso el lazo de captura en CaptureThread ). Es decir para iniciar la captura no sólo es necesario arrancar el hilo de captura sino también activar la variable m_Running a true ;y todo esto se hace en esta entrada del menú Inicio.

9.4.1.3.- Finalizar procesamiento Finalizar procesamiento es la tercera entrada del menú Inicio de la aplicación y como su nombre indica tiene como finalidad acabar con el procesamiento de la aplicación. En su mensaje command se ha programado la función CProyectoDlg::OnStop, en ella se le da el valor false a la variable global que controla que se ejecute el bucle de procesamiento en el hilo de captura ( esta es la misma variable que se activa a true en la entrada de comenzar procesamiento de este mismo menú Inicio ). También mediante esta entrada se finaliza el proceso de captura interno de VideoOCX, es necesaria esta acción de finalizar la captura interna si queremos cambiar la resolución de los fotogramas que estamos capturando sin desactivar el control de la



aplicación. Es decir, en esta entrada del menú se finaliza el proceso de captura interno del control VideoOCX pero no se desactiva dicho control, esta acción de parar la captura interna es necesaria cuando queremos cambiar algunos de los parámetros de los fotogramas siendo para ello necesario que el control esté activo en la aplicación. 9.4.1.4.- Finalizar control ActiveX y salir. En el command de esta entrada del menú se programa la función CProyectoDlg::OnClose(). En esta función al contrario del caso anterior se desactiva el control VideoOCX de la aplicación, pero también antes de desactivar el control se finaliza el proceso de captura interno: Esto es necesario para que la aplicación no entre en un estado inestable si el usuario desactiva el control VideoOCX de la aplicación antes de finalizar el proceso interno de captura; es por ello necesario cambiar el valor a false de la variable global que controla el lazo de captura dentro del hilo y desactivar el proceso interno de captura para que si en caso de no haberse hecho antes al ejecutar la orden de desactivar el control no se “cuelgue” la aplicación. Además si se pulsa primero la entrada Finalizar procesamiento y luego se pulsa esta entrada del menú de Inicio ( que sería el orden natural a seguir ) funciona correctamente a pesar de repetir diversas instrucciones en ambas entradas ya que la repetición de estas instrucciones no llevan al sistema a un estado de inestabilidad. También en esta función se liberan los manejadores de la imagen que se usaron para la captura de esta en tiempo de procesamiento y se cierra el dialogo de la aplicación de la misma forma que si se pulsase al X de la esquina superior izquierda. No obstante por todo lo dicho anteriormente se desaconseja el uso de la X y se recomienda finalizar la aplicación primero pulsando Finalizar procesamiento y luego pulsando Finalizar control ActiveX y salir.



9.4.2.- Menú Vigilancia Como se puede apreciar en la siguiente imagen el menú Vigilancia es un menú que tiene a su vez tres entradas estas son : “Detección por igualdad”, “Detección por similitud” y “Nivel de disparo”.

Fig. 9.7. Este menú es de configuración de los parámetros del modo de vigilancia; a continuación se muestra la descripción de las acciones de cada una de las entradas de este menú:

9.4.2.1.- Detección por igualdad El command asociado a esta entrada del menú hace una llamada a la función CProyectoDlg::OnIgual() en la que se activa una variable global del sistema que indica al hilo de captura y procesamiento que se ejecute en el bucle de captura la parte del código correspondiente al algoritmo de detección por igualdad, es decir el algoritmo que emplea la técnica de diferencia de fotogramas para la obtención del movimiento. Esta función sólo comprueba que el lazo de captura y procesamiento dentro del hilo no se esté ejecutando mediante el test de la variable global que controla esto y si es así está en disposición de activar el nuevo modo de procesamiento o dejarlo igual; pero en caso de que se esté ejecutando el lazo de captura la aplicación no deja cambiar el modo de detección ya que esto podría llevar al sistema a un estado inestable. Si se



intentase llevar a cabo esta acción se presentaría un mensaje de advertencia indicando que no posible tal acción.

9.4.2.2.- Detección por similitud El command asociado a esta entrada hace una llamada a la función CProyectoDlg::OnSimil() que implementa un código similar al de la función de la detección por igualdad salvo que ahora en la variable donde se guarda el modo de procesamiento que se llevará a cabo se activa el modo de procesamiento por similitud o el que emplea técnicas de correlación de fotogramas para la obtención del movimiento en la imagen. Al igual que en el caso anterior para mantener la estabilidad del sistema no se permite el cambio de modo de procesamiento una vez inicializado el lazo de captura.

9.4.2.3.- Nivel de disparo Esta entrada del menú despliega un dialogo de configuración para las opciones del calculo del nivel de disparo; este menú se muestra a continuación:

Fig. 9.8.



El dialogo de nivel de detección presenta dos opciones para el cálculo del nivel de detección configurable por el usuario del sistema, estas opciones son: Fijación directa del nivel.- Como su nombre indica se hace una asignación directa del

nivel de disparo y no se tiene en cuenta el parámetro de probabilidad de falsa alarma. En este caso el nivel de disparo se ajusta a partir de los estadísticos calculados por el sistema durante el tiempo de cálculo de estadísticos de forma estática; es decir lo que se hace es disparar la alarma cuando se supera un cierto nivel cuantificado por el valor de la media y varios valores de la desviación típica. En concreto 9 valores de la desviación típica, por lo tanto para el caso de igualdad se usará el nivel estático igual a la media más 9 desviaciones típicas, y en el caso de similitud se usará el nivel estático igual a la media menos 9 desviaciones típicas

Fijación de Pfa. calculo iterativo del nivel.- En este caso es necesario asignar al

sistema una probabilidad de falsa alarma para que a partir de esta se calcule, usando el algoritmo iterativo, el nivel de disparo que más se aproxime a esa Pfa.

En el momento en que se pulsa el botón aceptar de este dialogo la variable local del dialogo que guarda la forma de calculo del nivel de detección se carga en la variable global para que sea interpretada en el programa y se proceda a realizar el calculo del nivel de disparo del modo configurado por el usuario. También cuando se pulsa el botón de la X de la esquina superior derecha del dialogo se ejecuta un código que activa un temporizador para eliminar de la memoria dicho dialogo, esto se explicará con más detalle más adelante.



9.4.3.- Menú Configuración La configuración constituye la tercera entrada del menú de la aplicación y despliega seis opciones que como su nombre indica sirven para la configuración de diversos parámetros de la aplicación. A continuación se muestra una imagen donde se puede apreciar estas opciones del menú de Configuración:

Fig. 9.9. La configuración constituye uno de los puntos fuertes de la aplicación ya que permite al usuario de la misma cambiar diversos parámetros para detectar con más exactitud o centrar el procesamiento y la detección en determinadas zonas consideradas de más interés; así de esta forma se consigue aumentar la potencia de vigilancia usando los mismo algoritmos. Relacionado con esto también se ha de decir que la aplicación se ha programado de forma que cada una de estas opciones de configuración toma un valor por defecto si no se quiere entrar en la configuración del sistema de esta forma se agiliza su uso para pruebas y en los casos en que no se esté interesado en ninguna configuración específica. A continuación se muestra con más detalle la explicación de cada una de las entradas de este menú de configuración:



9.4.3.1- Resolución Como su propio nombre indica esta entrada del menú de configuración se utiliza para cambiar la resolución de los fotogramas que la aplicación captura y utiliza para la realización de la videovigilancia. Si pulsamos en la resolución la aplicación nos despliega el siguiente dialogo de configuración con diversas opciones para el tamaño de la imagen:

Fig. 9.10. En el dialogo se muestra cinco opciones para el tamaño de la imagen que podemos capturar y mostrar con la aplicación pero como este tamaño se refiere al número de píxeles que puede mostrar el contenedor para las imágenes se podrían obtener otros tamaños realizando llamadas al método del objeto VideoOCX de la aplicación:

long m_VideoOCX.CreateGrayImageHandle(long width, long height)

Con la llamada a este método se obtendría un contenedor para la imagen con un tamaño que se pase como parámetros expresando el ancho y el alto del nuevo contenedor en número de píxeles. En el caso del proyecto no se ha empleado este método sino que hemos hecho uso del método:



BOOL m_VideoOCX.SetResolution(long width, long height)

Con el cual sólo podemos activa resoluciones estándar como son las que se muestran en el dialogo de Resolución de la Imagen. Dependiendo de cual sea la opción que se elija en este dialogo tenemos una carga diferente en el sistema pues las opciones varían de 19200 píxeles ( que es la opción de menor resolución: 160x120 píxeles ) hasta 307200 píxeles ( que es la opción de máxima resolución que se contempla en el sistema: 640x480 píxeles ); lo que supone un incremento de 291000 píxeles que se han de capturar y procesar en tiempo real. En realidad la afirmación del párrafo anterior sólo es cierta si el segmento de procesamiento de la aplicación se configura para que coincida con todo los píxeles del fotograma sólo en este caso el número de píxeles a procesar coincide con el número de píxeles capturados. La posibilidad de introducir un segmento de procesamiento en vez de obligar a la aplicación a procesar todos los píxeles de la imagen fue introducida en el sistema para liberar de carga de procesamiento a la aplicación y que de esta forma sea posible la ejecución en paralelo de varios procesos de videovigilancia cada uno con su “fuente” de fotogramas. Relacionado con el dialogo de Resolución de la Imagen también hemos de decir que la aplicación no permite que sea abierto antes de la inicialización del control VideoOCX ya que tiene que acceder a métodos de este objeto y para ello el objeto tiene que estar inicializado; si se intenta acceder al dialogo sin inicializar dicho control se nos muestra un mensaje de aviso que nos advierte de ello.

Fig. 9.11 También se nos muestra un mensaje de aviso se pretendemos cambiar la resolución y se está procesando, es necesario detener el procesamiento para cambiar el tamaño de la imagen.

Fig. 9.12.



9.4.3.2- Zona de detección Esta es la segunda entrada del menú de configuración, en el menú se ha llamado a este parámetro “Zona de detección” pero también en esta memoria se ha hecho alusiones al él como segmento de detección. Este parámetro no es más que la zona dentro del escenario captado por la cámara donde quiero que se apliquen los algoritmos de detección y esta formada por un subconjunto de píxeles del número total de píxeles capturados por la aplicación. Si pulsamos en esta entrada del menú de Configuración nos aparece el siguiente dialogo:

Fig. 9.13. Como se puede apreciar en la imagen tenemos un cuadro de selección mediante el cual podemos configurar si la zona o segmento de detección se introduce en la aplicación mediante el ratón o introduciendo coordenadas. Si se selecciona la opción de zona de detección determinada mediante un “rectángulo dibujado por el puntero del ratón” la aplicación pasa a mostrar la imagen que en ese momento está captando la cámara y el usuario debe dibujar el segmento en la imagen donde quiere aplicar los algoritmos de vigilancia. La forma de dibujar estos segmentos mediante el ratón es la usual en cualquier aplicación que corra bajo Windows, es decir, mediante eventos del ratón: Se pulsa el botón izquierdo del ratón en un lugar de la imagen y se arrastra el puntero con el botón izquierdo pulsado hasta llegar al lugar que consideramos la esquina opuesta del rectángulo de píxeles a los cuales aplicaremos los algoritmos de vigilancia, en ese lugar soltamos el botón del ratón que



manteníamos pulsado; de esta forma el sistema capta los evento de pulsar y soltar el botón del ratón sobre la imagen y guarda las coordenadas de la imagen donde estos eventos se producen haciendo coincidir estas coordenadas con esquinas opuestas del rectángulo. La idea de usar el método de dibujo mediante el puntero del ratón es que se enfoque la cámara al lugar de vigilancia y luego con el ratón dibujemos cual sea la zona que realmente estamos interesados en vigilar de todo el escenario captado por la cámara: Un ejemplo de esto sería enfocar la cámara a la fachada de una vivienda y luego con el puntero hacer que el segmento de vigilancia sea solamente la puerta de dicha vivienda; otro ejemplo sería que si la cámara enfoca a un conjunto de cosas con el ratón selecciones para vigilar solo unos de esos objetos. A continuación se muestra una pantalla a modo de ejemplo de una definición de segmento de vigilancia utilizando el puntero:

Fig. 9.14. En el ejemplo aparece una grapadora y una taza; si estamos interesados en vigilar que la grapadora no sufra ningún desplazamiento definimos la zona de vigilancia con el ratón de forma que esta zona englobe con su área a la grapadora y a esa área será donde realmente apliquemos los algoritmos de vigilancia; es necesario decir aquí que si en cualquier otro lugar del escenario captado por la cámara hay algún tipo de movimiento este será filtrado por los algoritmos si el movimiento no cambia el estado de ninguno de los píxeles del rectángulo de detección .



Por el contrario si se selecciona la opción de determinar la zona de detección mediante coordenadas tenemos que introducir en el mismo dialogo las coordenadas de la esquina superior izquierda y la esquina superior derecha del rectángulo de vigilancia. Con esta forma de determinar la zona de vigilancia es bastante más complicado ajustarse al objeto o zona del escenario que queremos monitorizar pero es una opción muy útil para la realización de pruebas comparativas entre los dos algoritmos de detección ( igualdad y similitud ) pues nos permite introduciendo las coordenadas del segmento que los distintos rectángulos de vigilancia sean idénticos para distintas pruebas. Por el método de dibujo con el ratón es muy difícil ajustar segmentos idénticos de una realización a otra sin embargo mediante este método es muy sencillo con sólo introducir las mismas coordenadas y cuidar que la cámara no sufra ningún movimiento. A continuación se muestra el segmento de vigilancia obtenido en la aplicación con la introducción de las siguientes coordenadas: Esquina superior derecha: X1 = 0 Y1 = 0 Esquina inferior izquierda: X2 = 100 Y2 = 100

Fig. 9.15. Como se puede apreciar en la imagen y dadas las coordenadas introducidas vemos que el origen de coordenadas se sitúa en la esquina superior izquierda y que el valor máximo que podemos poner en cada una de las coordenadas es la resolución activada en cada momento para esa coordenada; es decir, que en el caso del ejemplo, que se ha configurado la resolución por defecto de 320x240, las coordenadas de las esquina inferior derecha son para la X = 319 y para la Y = 239, es decir la resolución



menos uno para cada eje de coordenadas. Es necesario, si queremos usar este método para la definición del segmento de vigilancia que tengamos presente en cada momento cual es la resolución que se está usando. También para este caso, al igual que en el caso de resolución, se han diseñado unos menús de aviso para orientar al usuario de cuales son los pasos a seguir en cada momento: Por ejemplo el siguiente dialogo se muestra si el usuario quiere determinar el segmento de detección y aún no se ha inicializado el control VideoOCX o no se ha comenzado el procesamiento ( ambas son entradas del menú Inicio):

Fig. 9.16. Y el siguiente dialogo se muestra cuando ya se ha definido la zona de detección y se pulsa para definir de nuevo:

Fig. 9.17. Este parámetro de la zona de detección es de los más importantes de la aplicación pues dependen del él factores como el rendimiento, ya que cuanto mayor número de píxeles tenga la zona de detección más tiempo se llevará para su procesamiento, o la estimación adecuada de los niveles de detección ya que se están realizando cálculos de medias en el conjunto del números de píxeles del segmento de detección; esto da lugar a que variaciones pequeñas sean significativas en segmentos pequeños y no lo sean en segmentos de un gran número de píxeles.



9.4.3.3- Tiempo de preprocesamiento Bajo este nombre se engloba el parámetro de la aplicación que define el tiempo dedicado por esta a la adquisición de fotogramas para procesamiento de los niveles de detección. A continuación se muestra el dialogo de elección del intervalo que dedicará la aplicación a dicho cálculo:

Fig. 9.18. Este también es un parámetro muy importante para un correcto funcionamiento de la aplicación ya que dependiendo del intervalo de observación para el cálculo de estadísticos podemos obtener una estimación más o menos adecuada a la realidad. En relación con esto es muy importante decir que una mejor o peor estimación del nivel de detección depende no sólo del tiempo que nos dediquemos a la observación de fotogramas para tal efecto sino también de la resolución: La idea es dedicar el mayor tiempo posible para el cálculo del nivel para así ser capaz de obtener el mayor número posible de fotogramas pero aún dedicando mucho tiempo a esta observación si los tamaños de fotogramas son muy elevados de forma que la aplicación es capaz de captar pocos fotogramas en ese tiempo de observación la estimación se hace con pocos datos.



Por lo tanto la conclusión que se saca de lo anteriormente mostrado es que si queremos una buena estimación del parámetro del nivel de detección no sólo hemos de tener en cuenta el dedicarle tiempo a esta observación sino también en la medida en que sea posible que dicha observación se haga con fotogramas pequeños para que en el mismo tiempo poder captar un mayor número de estos.

También para este dialogo si queremos configurar en tiempo cuando ya está

procesando la aplicación obtenemos el siguiente mensaje de la aplicación a modo de dialogo:

Fig. 9.19. El hecho de no poder modificar este parámetro cuando la aplicación está

corriendo en su fase de vigilancia no es restrictivo ya que si estamos procesando es porque ya se ha efectuado la elección de este parámetro y ya se está calculando el nivel de detección o la aplicación ya está procesando fotogramas para videovigilancia.



9.4.3.4.-Probabilidad de falsa alarma Como su propio nombre indica este es el parámetro de la aplicación que

determina cual va a ser la probabilidad de falsa alarma con la que va a trabajar la aplicación.

Es al igual que los anteriores un parámetro de gran importancia para la

aplicación y se usa para el calculo del nivel de disparo. A continuación se muestra el dialogo donde se tiene lugar su configuración:

Fig. 9.20. Como se puede ver en la aplicación anterior se ha diseñado el dialogo con cuatro

entradas correspondientes a las probabilidades de falsa alarma de: 0.01 = 10-2

0.0001 = 10-4 0.000001 = 10-6 0.00000001 = 10-8



Se ha optado por expresar en el diálogo la forma no exponencial porque la aplicación está programada para que al darse el evento de pulsar en el botón “Aceptar” los campos “Caption” se carguen en las variables y para estos campos el asistente no permitía la notación científica.

Este parámetro es importante para el correcto funcionamiento de la aplicación de vigilancia y describe con que probabilidad el sistema puede hacer saltar la alarma debido a que el ruido alcanza el nivel de detección; es decir es la probabilidad con que el sistema de una alarma sin que esta se produzca debida a una acción de intrusismo.

Concretamente este parámetro puede también tener otro significado debido a la

naturaleza digital de las capturas que se hacen en este proyecto: La probabilidad de falsa alarma puede considerarse como el número de fotogramas ruidosos de todos los fotogramas capturados, es decir, si consideramos la probabilidad de falsa alarma de 10-6

esto quiere decir que de 1 millón de fotogramas capturados uno de ellos tiene un nivel de ruido comparado con el anteriormente capturado que puede producir un disparo de la alarma sin que este fotograma refleje una variación debida a intrusismo.

Al igual que en la configuración de otros parámetros la aplicación no nos

permite en determinados estados la modificación de dicho parámetro; en este caso la probabilidad de falsa alarma no se puede modificar cuando ya se está procesando para así conservar la consistencia de la aplicación y el buen funcionamiento de esta. Cuando se intenta modificar la probabilidad de falsa alarma la aplicación lanza el siguiente aviso:

Fig. 9.21. Es conveniente tener lo anteriormente claro cuando se vaya a configurar dicho

parámetro pues para determinadas aplicaciones de este proyecto puede ser muy crítico tener un elevado número de fotogramas que produzcan falsas alarmas.



9.4.3.5.- Seleccionar driver Esta opción nos permite seleccionar cual será el driver al que se conecte la aplicación y que será la fuente de fotogramas a procesar. El dialogo de selección de driver se muestra a continuación:

Fig. 9.22. En este caso tenemos seleccionamos el driver de la cámara USB que es fuente de fotogramas de la aplicación pero también podría haber sido el driver de una tarjeta digitalizadora u otro dispositivo capaz de suministrar fotogramas que procesar a la aplicación. Por cada dispositivo que sea capaz de proporcionar a la aplicación un flujo de fotogramas a procesar tendremos una entrada diferente en este dialogo. Esto nos permite poner a procesar varios procesos concurrentes de vigilancia con la única limitación de que han de conectar con drivers distintos. Por supuesto también existe un número limitado de procesos concurrentes debido a que todos hacen uso de la misma CPU y todos consumen tiempo de procesamiento.



9.4.3.6.- Mostrar ventana de información Esta entrada del menú muestra un dialogo donde presentan datos y propiedades de la captura que se está llevando a cabo. A continuación se muestra una imagen de este dialogo donde podemos apreciar cuales son los datos que muestra:

Fig. 9.23. Para este ejemplo en concreto los parámetros que nos muestra este dialogo de información son:

Device: Es el dispositivo que en este caso es el encargado de realizar la captura de los fotogramas. Como sólo tenemos uno instalado es el dispositivo 0.

Mode: Es una propiedad de la imagen que se esta usando, en este caso aparece activada

con Video y se refiere al tipo de imágenes usadas en Video For Windows (VFW); la otra opción sería trata con secuencias AVI.

Width.- Se corresponde con el ancho del fotograma en número de píxeles. Height.- Se corresponde con el alto del fotograma en número de píxeles.



Preview, Overlay, Capture: Tenemos activado el modo de captura por el cual se capturan los fotogramas en formato BMP.

Captured Frames.- Fotogramas capturados por la aplicación. Streamed Frames.- Fotogramas capturados por la cámara, son todos los fotogramas del

flujo de datos de la cámara a la aplicación. Ratio.- Es el porcentaje de fotogramas capturados de todos los que es capaz de enviar la

cámara. Su calculo es fácil a partir de “Captured Frames” y “Streamed Frames” y se realiza de la siguiente manera:

100⋅=amesStreamedFramesCapturedFr

Ratio



9.4.4.- Menú Guardar

El menú Guardar constituye la cuarta entrada del menú de la aplicación, y tiene las opciones relacionadas con guardar algún ficheros de datos, de imagen o de configuración del sistema.

Este menú se ha implementado para darle la posibilidad al usuario de

almacenar todo lo relacionado con la aplicación en ficheros de texto y así, de este modo, poder examinar el funcionamiento de la aplicación conforme a la configuración guardada en un fichero en memoria.

Veamos las opciones que nos permite este menú Guardar, y como se despliega

en pantalla:

Fig. 9.24.

En cualquier aplicación configurable por el usuario de la misma siempre es interesante tener la posibilidad de poder almacenar en ficheros de texto la información que usa la aplicación para trabajar en dicho proceso de detección, y de este modo el usuario tiene la posibilidad de mirar detenidamente la configuración para cada proceso así como usar estos ficheros como entrada de datos para otra aplicación. Un ejemplo de esto anteriormente descrito es lo que he hecho para la elaboración de las graficas de representación de medias y correlaciones: los ficheros de estadísticos se usaron como entradas para Matlab y se usó sus funciones de representación de gráficos. A continuación se muestra con más detalle la explicación de cada una de las entradas de este menú Guardar:



9.4.4.1.- Guardar estadísticos en ficheros Esta opción de guardar estadísticos en ficheros se refiere a la creación de un archivo de texto donde se almacenen los valores de medias o correlaciones ( según se active la detección por igualdad o similitud ) que almacena la aplicación para un estudio de estos datos por otra aplicación, por ejemplo Matlab. Veamos un ejemplo de archivo guardado y abierto por el WordPad:

Fig. 9.25. Este archivo tiene impresa las correlaciones capturadas por la aplicación en tiempo real, se ha programado que se guarde una correlación por fila; de modo que el fichero tiene una sola columna y tantas filas en esa columna como correlaciones entre un fotograma y su consecutivo. La idea con lo que se ha dado esta estructura al fichero de datos es que se puede cargar en una variable vector de Matlab que tenga una sola columna y tantas componentes como correlaciones realice la aplicación para el proceso de detección. Se desaconseja activar esta opción cuando la aplicación se pone a funcionar durante un tiempo indefinido puesto que en cada captura almacenará un dato en memoria y durante un tiempo indefinido esto puede saturar la memoria del disco.



9.4.4.2.- Guardar imagen de intruso Esta posibilidad se le da al usuario si este quiere guardar una fotografía del intruso que ha provocado que se supere el nivel de detección de la aplicación. Es una opción útil pues nos permite identificar cual ha sido la razón por la que ha saltado la alarma con sólo observar la instantánea tomada en dicho momento. Veamos las opciones que nos da el menú guardar imagen de intruso para el tipo fichero en que se guarde la instantánea del intruso:

Fig. 9.26. Al pulsar la opción de Guardar imagen de intruso se da la posibilidad de elegir entre tres formatos distintos: Formato BMP: Se captura la imagen en formato BMP o mapa de bit, en este caso

realizar la captura es simplemente un volcado de los bits del contenedor de la imagen donde se ha detectado el movimiento al fichero de la fotografía sin ningún tipo de compresión. Es de los tres el que nos da un fichero de mayor peso en memoria de disco.

Formato JPEG (100%): Con este formato a la imagen se le aplica el algoritmo de

compresión JPEG en su versión de mayor calidad y por lo tanto de menor compresión antes de ser volcado al fichero de la fotografía.

Formato JPEG (50%): En este caso se aplica también el algoritmo de compresión

JPEG con una calidad del 50% con lo que se obtienen ficheros de imagen con menor peso en memoria a consta de una peor resolución.



Vemos un ejemplo donde se toma la instantánea cuando se ha detectado que se que ha habido movimiento en el escenario de vigilancia: Imagen con Formato BMP:

Fig. 9.27. Imagen con Formato JPEG (100%):

Fig. 9.28. Imagen con Formato JPEG (50%):

Fig. 9.29. Vemos que para los dos primeros casos la diferencia es inapreciable para el ojo humano pero en el tercero ya se nota los efectos de la compresión de la imagen.



9.4.4.3.- Guardar configuración en archivo de texto Con esta opción se almacena en memoria un fichero de texto que guarda toda la configuración del sistema para un proceso de detección. Un ejemplo para este fichero de detección es el que a continuación se muestra:

Fig. 9.27. Como se ve en el ejemplo, en el fichero de configuración se guardan datos tales como el tipo de detección usada en la realización que puede ser detección por IGUALDAD o por SIMILITUD según el algoritmo de detección empleado para la detección de movimiento. Se guarda también el nivel detección a partir del cual se hace saltar la alarma; la resolución del fotograma de captura dando el ancho y el alto de este fotograma en número de píxeles; la forma de determinar el segmento de detección que puede ser dibujándolo con el ratón o introducido por coordenadas; el tiempo dedicado por la aplicación a la captura para el cálculo de estadísticos; la probabilidad de falsa alarma utilizada para el nivel de detección; y en último lugar el driver con el que conecta la aplicación para la obtención de las imágenes y referencias al autor del proyecto. Es conveniente tener en cuenta que el fichero de configuración guarda la configuración que tenga el sistema en el momento de pulsar la opción de guardar, de modo que si se pulsa antes de realizar la configuración guardará en el fichero la configuración por defecto que tiene el sistema al inicializarse.



9.4.5.- Menú Acerca de... . Pulsando la única entrada de este menú se presenta un dialogo con información sobre el autor del proyecto y sobre en proyecto en si. A continuación se muestra este dialogo:

Fig. 9.28.


Carga Computacional Página 101

10.- CARGA COMPUTACIONAL DEL SISTEMA

En todo momento mientras se ha desarrollado la aplicación se ha hecho especial

hincapié en desarrollar unos algoritmos de vigilancia que consuman el menor número de recursos del sistema. Como búsqueda de esta finalidad se determinó el lenguaje C++ como plataforma para la programación por ser el lenguaje más rápido y el que nos permitía la posibilidad de acceder a recursos del sistema de forma más eficaz y mayor libertad; la elección de este lenguaje para la programación de la aplicación trajo ventajas como las anteriormente mencionadas pero también el inconveniente de la dificultad presente en la programación con C añadido esto a que me enfrenté al proyecto con escasas nociones de la programación de la API de Windows.

En este apartado se realizarán unas pruebas para comprobar la carga de CPU que

el sistema soporta debido a la aplicación.

10.1.- Descripción de la prueba La prueba consistirá en la realización de un proceso de vigilancia mediante los dos algoritmos de detección de movimiento creados implementados en esta aplicación con ciertas características de carga como pueden ser un elevado número de píxeles para el formato del fotograma y también un elevado número de píxeles para el segmento de detección; con esto tendremos la certeza de realizar las pruebas de carga computacional para detecciones críticas donde la aplicación tenga que procesar una elevada carga de datos en tiempo real.

Para la obtención de resultados de la prueba se realizará mediante la visualización de la carga computacional del administrados del sistema de Windows, para los casos de detección por igualdad y por similitud; esto nos permitirá observar una comparativa de cargas computacionales entre los dos métodos de detección de intrusismo implementados en el proyecto.

La característica más crítica en una detección es el número de píxeles que

capturar y procesar, para estas pruebas se configurará para una captura de fotogramas de dimensiones de 640x480 y la misma carga de píxeles que procesar.

Los datos obtenidos de esta simulación será en % de tiempo que la CPU usa para

el procesamiento en esta aplicación, es necesario por tanto no tener ninguna otra aplicación procesándose a la vez que la detección pues esto haría que los datos ofrecidos por el administrador fuesen menos precisos ya que habría que considerar la existencias también de tiempos en los que se pasan el hilo principal de una a otra aplicación.



Los datos obtenidos son siempre intuitivos ya que el propio sistema necesita tiempo de CPU para contabilizar este tanto por cierto dedicado a la aplicación; no obstante los datos obtenidos se usarán para realizar una estimación del número de procesos de vigilancia concurrentes que podemos ejecutar en la misma máquina siendo este cálculo también aproximado:

10.2.- Gráfico de CPU para detección por igualdad

Veamos en primer lugar la gráfica de % de CPU que se obtiene cuando hacemos correr la aplicación con el algoritmo de detección por igualdad y las características antes mencionadas sobre el tamaño del fotograma y del segmento de vigilancia:

Fig. 10.1. La figura 10.1. es una captura de pantalla del administrador de Windows, se

observa que para ese instante la carga de la CPU debida a la aplicación de detección de intrusismo era del 15%, durante este periodo estuve observando los valores de carga de CPU y se alcanzó como máximo el 19%.

Para hacer un cálculo aproximado del número de procesos de vigilancia

similares al anteriormente mostrado que se podrían ejecutar de forma concurrente no tenemos más que suponer que todos cargasen al sistema de forma similar al anterior y obtendríamos:

Nº de procesos = 519

100≅ procesos con detección por igualdad.



Hay que siempre presente que estos cálculos de carga de CPU y número

concurrente de procesos son siempre aproximados ya que cuando en un sistema monoprocesador se tienen varias procesos ejecutándose existen unas pequeñas fracciones de tiempo que el sistema operativo dedica a la transacción de la ejecución de un proceso a la ejecución de otro proceso, y esta tiempo no puede ser atribuido a ningún proceso en concreto.

10.3.- Gráfico de CPU para detección por similitud También se realizó el mismo experimento pero con el algoritmo de detección

por similitud; los grafica obtenida mediante el administrador de Windows es la que a continuación se muestra:

Fig. 10.2. En el instante de captura de la pantalla el proceso acaparaba el 18% del tiempo

de la CPU, comento este dato porque ha sido significativo del resto de la evolución de la carga del procesador.

Mientras se observó la evolución de la carga del procesador se alcanzaron

porcentajes de CPU de hasta el 24%, lo que supone un aumento en comparación a la carga del procesador cuando se usó el algoritmo por igualdad.

Veamos en este caso cuantos procesos concurrentes similares al observado

podríamos ejecutar en la misma máquina:

Nº de procesos = 424

100=≅ procesos con detección por similitud



Luego, al menos a la vista de los datos obtenidos mediante el administrador de

Windows, parece ser la detección por igualdad más eficiente en carga del procesador que la detección por similitud ya que con los datos obtenidos para proceso de detección con la mayor carga de datos posible por la aplicación, se obtienen que para igualdad se puede procesar 5 concurrentemente y para similitud 4. No obstante se ha de tener en cuenta que son datos aproximados.


Simulaciones Página 105

11.- SIMULACIONES

En este apartado realizaremos múltiples simulaciones y estudiaremos sus resultados para poder determinar cuales son las ventajas e inconvenientes de un método de detección frente a otro y cual tiene un mejor comportamiento dependiendo de la características del escenario donde se esté realizando la simulación.

En cada una de las simulaciones que a continuación se muestran se describirán

cuales han sido los valores que se han adoptado en la configuración de los distintos parámetros de la aplicación, para así poder determinar, si existiese, una relación entre estos parámetros configurables y los resultados obtenidos de la simulación.

También se intentará incluir en cada una de las simulaciones imágenes que nos

ayuden a hacernos una idea física del escenario de la simulación así como de los datos de medias y correlaciones que la aplicación guarda en el fichero de estadísticos.

11.1.- Escenario de Simulación 1

En este caso se realizará la simulación en un escenario luminoso, con un periodo de detección de estadísticos de 10 segundos, con fotogramas cuyo ancho y alto en número de píxeles es 320x240 y tomando un segmento de vigilancia que coincida con todo el escenario captado por la cámara. La aplicación eleva el nivel de luminosidad del segmento de vigilancia durante el periodo de toma de estadísticos pero en este experimento no es apreciable al ser todo el escenario segmento de vigilancia Cada escenario de simulación se analizará mediante los dos algoritmos de detección: Detección de igualdad o detección por similitud; en ambos casos yo tomaré el papel de intruso atravesando el escenario para provocar un salto de la alarma de detección.

Los resultados obtenidos se presentan en los siguientes apartados:

11.1.1.- Escenario de Simulación 1. Detección por igualdad

En este caso realizaremos la detección en el escenario descrito anteriormente

mediante el algoritmo de detección por igualdad; a continuación se muestra el fichero de configuración captado por la aplicación para este experimento :



>>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por IGUALDAD El nivel de detección para esta realización: 3.437287 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

Veamos también el escenario donde tiene lugar el experimento:

Fig. 11.1.



Como ya se ha mencionado antes es un escenario con luminosidad pero además en la Fig 11.1. la imagen está aún más luminosa debido a que la aplicación aplica un aclarado de 30 sobre el nivel de todos los píxeles para determinar durante el periodo de toma de estadísticos cual es el segmento donde vamos a aplicar los algoritmos de detección. El experimento consistió en que yo atravesaba el escenario y veía cual era el comportamiento de la aplicación. El programa detectó intrusismo cuando incidí en el segmento de vigilancia o capturó la siguiente fotografía:

Fig. 11.2.

A continuación se muestra una gráfica con los datos guardados por la aplicación en este proceso de vigilancia, esta gráfica es obtenida mediante la representación del fichero de estadísticos que la aplicación ha guardado:

Fig. 11.3.



En la gráfica de la figura 11.3. se representa las medias de las diferencias entre fotogramas consecutivos. Vemos que todas las medias están por debajo del valor de 3.437287 que es, para esta realización, el nivel de disparo de la alarma ( representado en la gráfica en color verde ) excepto varios fotogramas en los que se supera este valor de alarma y que coinciden con los fotogramas en los que realizo la intrusión en el segmento de detección. Como consecuencia la aplicación hace saltar la alarma y realiza una instantánea del intruso, esta instantánea es la que se representa en la figura 11.2.

Para hacernos una idea de lo sensible que ha sido la aplicación a la acción de

intrusismo calculamos el siguiente parámetro:

71.271002569428.70

100max_

_=⋅=⋅=

imorangoalarmanivel

S %

Este parámetro nos puede servir para comparar realizaciones del mismo proceso,

nosotros también lo emplearemos para comparar sensibilidades entre los procesos que usan el algoritmo de igualdad y otros que usan el de similitud.

11.1.2.-Escenario de Simulación 1. Detección por similitud. Realizaremos ahora el proceso de vigilancia para el mismo escenario de la simulación anterior con la diferencia de que ahora emplearemos el algoritmo de detección por similitud. A continuación se muestra el archivo de configuración para esta realización: >>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por SIMILITUD El nivel de detección para esta realización: 0.993377 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************



Veamos como el escenario y el segmento de detección son exactamente el mismo que para el experimento anterior, la única diferencia es que esta pantalla se ha capturado cuando la aplicación estaba calculando correlaciones para determinar estadísticos:

Fig. 11.4.

Pasé atravesando el segmento de vigilancia y la instantánea capturada por la aplicación fue:

Fig.11.5.



A continuación se muestra una gráfica con los datos guardados por la aplicación en este proceso de vigilancia, esta gráfica es obtenida mediante la representación del fichero de estadísticos en el que la aplicación guarda las correlaciones entre los segmentos de vigilancia de fotogramas consecutivos:

Fig. 11.6. Para el caso de simulación por similitud la sensibilidad la podemos definir

como:

678.21001973219.01

100max__1

=⋅−

=⋅−

=imorango

alarmanivelS %

Vemos que en el caso de la detección por similitud es del orden de 10 tantos por

cientos menos sensible que la detección por igualdad. No obstante esta diferencia en la sensibilidad está muy vinculada a la realización del experimento en si.



11.2.- Escenario de simulación 2

En esta simulación el escenario estará igualmente iluminado que en la prueba de simulación anterior pero ahora el experimento se realizará aplicando los algoritmos de detección sólo en segmentos rectangulares perpendiculares en la imagen; debido a que la captura para esta simulación se realizará con un fotograma de 320x240, podemos definir como rectángulo o segmento de detección aquel cuyas coordenadas de sus ángulos opuestos son: Esquina superior izquierda (150,0) y esquina inferior derecha (160,239).

Los resultados obtenidos se presentan en los siguientes apartados:

11.2.1.- Escenario de simulación 2. Detección por igualdad.

Veamos a continuación el resultado obtenido de aplicar al escenario

anteriormente descrito el algoritmo de detección de movimiento por igualdad. Para este experimento el fichero de configuración obtenido es el siguiente:

>>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por IGUALDAD El nivel de detección para esta realización: 2.732239 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

En la descripción que se ha dado anteriormente sobre el escenario de simulación

se dice que ahora el algoritmos de detección de movimiento se aplica solamente sobre un segmento rectangular de la imagen; a continuación vemos este segmento iluminado sobre el escenario. En el código se implementó una función que realiza este aclarado



sobre el segmento de vigilancia. Este aclarado no pudo ser apreciado en el escenario de simulación 1 puesto que en este experimento el segmento era todo el escenario.

Fig. 11.7.

De nuevo el experimento consistía en atravesar el segmento de vigilancia y

observar los datos captados por la aplicación. Veamos la instantánea capturada en el momento de producirse la alarma:

Fig. 11.8.

A continuación se muestra una gráfica con los datos guardados por la aplicación

en este proceso de vigilancia. También se ha representado como en los casos anteriores el nivel del detección de alarma para dicho experimento:



Fig. 11.9.

Veamos ahora para este experimento cual es la sensibilidad obtenida, para ello realizamos el siguiente calculo teniendo en cuenta que el nivel máximo de las medias fue de 2.732239 para esta realización del experimento; este nivel máximo por supuesto coincidió con la acción de intrusismo en el escenario:

23.60100256

1980.154100

max__

=⋅=⋅=imorango

alarmanivelS %

En este caso la sensibilidad de la aplicación frente al intrusismo ha sido del 60.23%, muy superior a la obtenida en caso de que el segmento de vigilancia sea todo el escenario. Es importante hacer notar que ahora el algoritmo de detección se aplica a un segmento rectangular vertical de 10x240 píxeles, cuyo número total de píxeles es muy inferior al de la pantalla completa.

11.2.2.- Escenario de simulación 2. Detección por similitud. Para el mismo escenario descrito anteriormente ahora aplicamos el algoritmo de detección por similitud. Veamos el archivo de configuración guardado para esta realización del experimento:



>>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por SIMILITUD El nivel de detección para esta realización: 0.999398 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** *************************************** Para el segmento de detección se utilizó la definición por coordenadas y se introdujo las mismas coordenadas que en el caso de detección por igualdad. El resultado de estas coordenadas fue el segmento de la siguiente figura que es exactamente el mismo que el de la figura 11.7.

Fig. 11.10.



Veamos la instantánea captada en el momento de la intrusión:

Fig. 11.11.

La representación gráfica del fichero de correlaciones capturadas mediante el

proceso de vigilancia tiene la siguiente forma:

Fig.11.12. En la gráfica se observa el pico de detección captado por la aplicación en

el momento de capturar el fotograma en el cual tiene lugar la acción de intrusismo.



También en la gráfica de la figura 11.12 se ha representado, junto con los niveles de correlación, el valor umbral a partir del cual la aplicación haría saltar la alarma de intrusismo. Vemos que en ningún momento, excepto en el fotograma donde se detecta intrusión, el nivel de la correlación supera al nivel umbral, eso es debido a que los niveles de ruido en ningún caso pueden superar el nivel de detección con una probabilidad que exceda a la probabilidad de falsa alarma, puesto que así ha sido diseñado el calculo del nivel de detección.

Calculemos para esta realización del experimento la sensibilidad obtenida;

teniendo en cuenta que se ha aplicado el algoritmo de detección por similitud la definición que se hizo de la sensibilidad fue:

63.61001933731.01

100max__1

=⋅−

=⋅−

=imorango

alarmanivelS %

Vemos que en este caso se ha aumentado considerablemente la sensibilidad con

respecto al caso en que el segmento de detección lo constituía todo el escenario. Por tanto se observa un aumento de la sensibilidad conforme se reduce el

número de píxeles del segmento de detección; notar que este incremento de la sensibilidad se ha obtenido también en el caso de la aplicación del algoritmo de igualdad, luego es una característica común de ambos algoritmos de detección de movimiento el convertirse en más sensibles conformes se disminuye el número de píxeles del segmento de detección.




Para el tercer escenario de simulación se toma una zona iluminada, al igual que en el caso de las pruebas anteriores y se aplica la detección a este escenario en un segmento rectangular horizontal a la imagen. Las configuración de captura es la misma que para la simulación 2 de modo que el fotograma tiene unas dimensiones de 320x240, de este modo vamos a tomar el segmento de detección horizontal como aquel cuyo dos ángulos opuestos son: Esquina superior izquierda (0,115) y esquina inferior derecha (319,125).

Los resultados obtenidos se muestran a continuación:

11.3.1.- Escenario de simulación 3. Detección por igualdad. Para este caso el fichero de configuración obtenido fue el que a continuación se muestra: >>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por IGUALDAD El nivel de detección para esta realización: 2.82258 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

Para este caso el segmento es rectangular horizontal, veamos como se comporta los algoritmos con este tipo de segmento de detección.

En la siguiente imagen se observa el segmento horizontal de detección:



Fig.11.13

Veamos también la imagen captada por la aplicación en el momento de detectar el intrusismo:

Fig.11.14. Al igual que en las pruebas de simulación anteriores representamos la gráfica de los estadísticos captados por la aplicación, y observamos el pico que esta representación presenta en el fotograma donde tiene lugar la acción de intrusismo, para posteriormente utilizar este pico para el cálculo de la sensibilidad obtenida por la aplicación en esta realización del proceso de vigilancia.



Fig. 11.15.

Calculemos la sensibilidad para esta realización del experimento:

88.81002567426.22

100max_

_=⋅=⋅=

imorangoalarmanivel

S %

Se aprecia un notable decremento de la sensibilidad con respecto al caso de

cuando el segmento ocupa todo el escenario y aún más respecto de la simulación con segmento perpendicular.

11.3.2.- Escenario de simulación 3. Detección por similitud. Veamos cual ha sido en este caso el segmento de configuración: >>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por SIMILITUD El nivel de detección para esta realización: 0.999709 Resolución: 320x240 píxeles Zona de detección determinada mediante: Coordenadas del segmento. Tiempo de preprocesamiento empleado para calculo de estadísticos: 10 segundos.



Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

También se muestra el escenario de la simulación, vemos que coincide exactamente con el de la figura 11.13.

Fig. 11.15.

La instantánea captada por la aplicación fue:



Fig. 11.16. Como en el resto de experimentos anteriores, veamos cual ha sido la gráfica en

el que se representa las correlaciones captadas por la aplicación:

Fig. 11.17. Vemos que la correlación presenta un pico muy pronunciado en un segmento

rectangular horizontal, veamos cual es la sensibilidad obtenida en este fotograma y comprobemos si efectivamente es más sensible en este caso:

12.101001898793.01

100max__1

=⋅−

=⋅−

=imorango

alarmanivelS %

Efectivamente como se sospechaba viendo el efecto de la intrusión en la gráfica

ha resultado que se ha aumentado la sensibilidad para el caso del segmento rectangular en comparación con el caso en que el segmento sea todo el escenario o el segmento sea un rectángulo vertical.

Vemos que ha resultado un efecto opuesto al observado en el caso de aplicar el

algoritmo de igualdad: En el caso de igualdad observamos un decremento considerable de la sensibilidad y en el caso de similitud se observa un incremento considerable.




Este escenario de simulación consistirá en una zona iluminada donde tendremos

un objeto oscuro sobre fondo claro y aplicaremos los algoritmos de vigilancia en un segmento reducido en tamaño comparado con el escenario completo. Se tendrá la misma configuración del sistema que en los experimentos anteriores como se verá en los ficheros de configuración de la aplicación, salvo en la particularidad que el segmento de detección donde aplicaremos los algoritmos de detección será determinado por el ratón.

Veamos el comportamiento de ambos algoritmos:

11.4.1. Escenario de simulación 4. Detección por igualdad.

Como en los casos anteriores veamos el fichero de configuración, veremos la variante de que ahora el segmento de detección fue definido con el ratón: >>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por IGUALDAD El nivel de detección para esta realización: 3.602862 Resolución: 320x240 píxeles Zona de detección determinada mediante: Puntero del ratón. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

Veamos como hemos hechos en otros ejercicios de simulación el escenario en el

que se ha realizado la prueba; como ya se ha dicho se trata de una prueba de simulación



con un segmento de reducidas dimensiones que englobará aun objeto oscuro sobre fondo blanco:

Fig. 11.18. La aplicación realizó la captura en el fotograma en el que detectó la acción de

intrusismo y, el resultado de esta instantánea es el que se muestra a continuación:

Fig. 11.19.

Como vemos en la fotografía la aplicación detectó intrusismo en el momento en que atravesé con mi mano el segmento de detección sin que sin que aún realizase ningún



movimiento del objeto; veamos en la siguiente gráfica en que nivel se ha traducido esta acción de intrusismo:

Fig. 11.20. Si realizamos el calculo de la sensibilidad:

58.151002568750.39

100max_

_=⋅=⋅=

imorangoalarmanivel

S %

11.4.2. Escenario de simulación 4. Detección por similitud Para el mismo escenario anterior observemos como se comporta con respecto el

algoritmo de similitud. El fichero de configuración fue el siguiente:

>>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por SIMILITUD El nivel de detección para esta realización: 0.998424 Resolución: 320x240 píxeles Zona de detección determinada mediante: Puntero del ratón. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos.



Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

El escenario de detección coincide con el de la misma prueba para igualdad:

Fig. 11.21.

Y la instantánea captada en el momento de darse la alarma fue:

Fig.11.21.



Para esta realización el gráfico de correlaciones obtenidos fue el que se muestra

a continuación junto con el nivel de disparo:

Fig. 11.22. Si calculamos la sensibilidad teniendo en cuenta que en este caso estamos

procesando correlaciones:

39.31001

9660938.01100

max__1

=⋅−

=⋅−

=imorango

alarmanivelS %

Vemos que en este cuarto experimento cuando hemos usado un segmento de

detección reducido la sensibilidad de la detección por igualdad ha disminuido considerablemente con respecto al caso del segmento que incluía todo el escenario y sin embargo en el caso de similitud hemos notado una mejoría.




Será un escenario complicado para la aplicación según se han diseñado los algoritmos de detección. La prueba consistirá en la detección de movimiento de un objeto oscuro en un entorno oscuro de modo que no exista mucho contraste entre el objeto y el resto del escenario; hechos dicho que su detección es complicada pues los algoritmos que se han implementado detectan el movimiento a partir de los cambios de los estados de los píxeles, y un escenario de esta característica no existe mucho cambio cuando el objeto se mueve pues el fondo tiene unos estados de los píxeles muy parecidos al del objeto en sí.

Se probará en este escenario tanto el algoritmo de igualdad como el de similitud:

11.5.1. Escenario de simulación 5. Detección por igualdad.

Veamos cual es el fichero de configuración captado por la aplicación para este proceso de vigilancia: >>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por IGUALDAD El nivel de detección para esta realización: 2.634582 Resolución: 320x240 píxeles Zona de detección determinada mediante: Puntero del ratón. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************



El escenario donde se aplicará la vigilancia se muestra en la figura siguiente donde podemos observar que el escenario y el objeto son oscuros, y que hay dificultad incluso para el ojo humano para distinguir el objeto del fondo:

Fig. 11.23. También apreciamos dificultad para la aplicación a la hora de captar la

instantánea del intruso en el momento en el que se supera el nivel de la alarma; esto se puede apreciar en la siguiente fotografía captada por la aplicación:

Fig. 11.24.



Como se ve en la fotografía el nivel de los píxeles que constituyen el objeto así como el fondo o el intruso son muy parecido por lo cual plantea dificultades a la aplicación al no existir mucha variación del segmento sin movimiento de cuando si tiene movimiento; esto descrito en este párrafo se entenderá mejor observando la siguiente gráfica donde el pico provocado por el intrusismo es muy pequeño:

Fig. 11.25.

Para esta realización la sensibilidad obtenida ha sido:

01.310025670701.7

100max_

_=⋅=⋅=

imorangoalarmanivel

S %

Se obtiene una sensibilidad muy baja como era de esperar dadas las características del escenario de simulación.

11.5.1. Escenario de simulación 5. Detección por similitud. Realizaremos la prueba de detección en el mismo escenario ahora usando el

algoritmo de detección por similitud; el fichero de configuración de la prueba es:

>>>> **************************************** <<<< >>>> ARCHIVO DONDE SE GUARDA LA CONFIGURACIÓN <<<< >>>> **************************************** <<<< Forma de detección usada: Detección por SIMILITUD



El nivel de detección para esta realización: 0.997084 Resolución: 320x240 píxeles Zona de detección determinada mediante: Puntero del ratón. Tiempo de prepocesamiento empleado para calculo de estadísticos: 10 segundos. Probabilidad de falsa alarma: 0.000001 DRIVER: Microsoft WDM Image Capture (Win32),Version:5.0.2195.2672 Autor: JUAN DIEGO MURES TRUJILLO. *************************************** *** FIN DE ARCHIVO DE CONFIGURACIÓN *** ***************************************

El escenario y el segmento de detección fueron similares al de la figura 11.23.:

Fig. 11.26.

Y la instantánea captada fue:



Fig. 11.27. Veamos la gráfica de la correlación captada por la aplicación:

Fig. 11.28. Veamos ahora la sensibilidad para el caso de la correlación:

%82.01001991895.01

100max__1

=⋅−

=⋅−

=imorango

alarmanivelS

De modo que también para la similitud hay una disminución muy considerable

de la sensibilidad de la aplicación. De modo que también en este caso la vigilancia se ve muy diezmada debido al nivel de oscuridad de la imagen.



11.6.- Conclusiones de las simulaciones. Las conclusiones que podemos sacar de las pruebas anteriormente realizadas se

infieren directamente del parámetro sensibilidad definido a tal efecto y que nos va a permitir obtener una idea de la robustez del sistema antes acciones de intrusismo.

La primera conclusión directa que se obtiene de la observación directa del

parámetro S es que la vigilancia mediante el algoritmo de detección por igualdad es bastante más sensible a acciones de intrusismo que la vigilancia mediante el algoritmo de detección por similitud cuando consideramos segmentos de un gran número de píxeles.

Por lo general es siempre mas sensible el algoritmo de igualdad que el algoritmo

de similitud; sólo he obtenido el caso contrario ( sensibilidad mayor en similitud que en igualdad ) cuando se procesaba un segmento horizontal a la escena; en este caso en todos los experimentos realizados se obtenía un sistema más sensible con igualdad que con similitud.

También se observa en estas pruebas que ambos métodos aumentan su

sensibilidad con los segmentos verticales pero sin embargo con los segmentos horizontales solo aumenta la sensibilidad en el caso de similitud; para el caso de igualdad, lejos de aumentar disminuye de forma considerable comparado con el caso del segmento coincidente con toda la escena.

De forma general se puede afirmar que el parámetro S, pese a ser inferior en el

caso de similitud frente al caso de igualdad, es mucho más robusto para la similitud frente a variaciones del segmento; es decir el valor de S para vigilancia con detección por similitud permanece en un rango más reducido cuando se varia el segmento que en caso de igualdad.

Ambos métodos de detección pierden bastante sensibilidad en escenarios

oscuros donde los movimientos en el segmento vigilado no implican una variación considerable en el estado de los píxeles; esto se traduce en que las detecciones provocan picos no muy elevados en los estadísticos captados y por tanto disminución de la sensibilidad.

Podemos también concluir de las pruebas que los algoritmos de detección

funcionan de forma correcta en cuando que cumplen su misión de detección en todos los escenarios probados; además según se observó durante la realización de las pruebas también el dimensionamiento de los niveles de detección ha sido adecuado puesto que no obtenemos falsas alarmas durante el desarrollo de las simulaciones.

Dada la característica de los experimentos, hemos de tener en cuenta que estas

conclusiones sacadas de los mismos están muy sujetas al experimento en sí y que es imposible la realización de simulaciones idénticas para la comparación de los distintos algoritmos frente a procesos de detección idénticos.


Multicámara Página 133

12.-MULTICÁMARA

El resultado obtenido con la realización de este proyecto ha sido un sistema de vigilancia basado en una cámara digital conectada a un PC por el puerto USB. Como ya se ha mencionado en diferentes apartados de esta memoria los resultados obtenidos son realmente satisfactorios :

La aplicación de vigilancia no supone una carga considerable para un sistema procesador como el que se está empleando en este proyecto para ninguno de los algoritmos que se están usando para la detección.

En esta línea de trabajo, el siguiente paso que se nos puede ocurrir es aumentar

el número de cámaras del sistema de vigilancia y que esta siga siendo soportado sobre el mismo PC; es decir sin aumentar la capacidad de procesamiento del sistema sobrecargarlo aumentando el número de fuentes de datos ( cámaras conectadas a los distintos puertos USB del PC y que son las encargadas de captar las imágenes monitorizadas por el sistema microprocesador )

Aunque el funcionamiento con múltiples cámaras no era uno de los objetivos

que se fijaron al comienzo de este proyecto, se han realizado pruebas conectando varias cámaras USB al PC y realizando el procesamiento de sus imágenes de forma concurrente, los resultados obtenidos han sido satisfactorios.

Cam 2 Cam 1 Cam 3

Figura 12.1

Como ya se dicho antes la aplicación y por lo tanto la interfaz del usuario no ha

sido diseñada para un funcionamiento con múltiple fuente de datos, es decir no se ha programado la interfaz con varios objetos VideoOCX. Esta ampliación del proyecto es

PC

Driver 1 Driver 2

Driver 3


Multicámara Página 134

sumamente sencilla con sólo embeber estos objetos en la interfaz de la aplicación y hacer lanzar un hilo por cada fuente de datos a procesar.

Las pruebas que se han realizado con varias cámaras han sido abriendo una

nueva ejecución de la aplicación por cada una de las cámaras que se han conectado al sistema y en cada unas de estas versiones de la aplicación se visualiza la imagen de una de las cámaras .

La única limitación que se ha encontrado al uso concurrente de varias cámaras es

que estas no puede compartir driver ya que este supone un recurso exclusivo de la aplicación que se está ejecutando; de este modo cuando estamos ejecutando la aplicación con varias cámaras ha de estar trabajando un driver por cada una de las cámaras de forma exclusiva. La carga a la que es sometida el sistema no es excesiva pues la capacidad de computo del micro no es el cuello de botella del sistema sino que este está en la velocidad de captura que tienen las cámaras, por tanto el sistema funciona de forma satisfactoria al conectarse con varias cámaras.


Conclusiones Página 135

13.-CONCLUSIONES El objetivo de este proyecto fin de carrera ha sido conseguir un sistema de videovigilancia mediante la realización de un software que permita realizar esta función de forma eficiente y fácil para aquella persona encargada de monitorizarlo. El resultado obtenido, a vista de las pruebas, no podía ser mas alentador pues se han conseguido obtener todos aquellos objetivos que se esbozaron al comienzo de la realización del proyecto y que han ido tomando forma a medida que se iba analizando y entendiendo el problema a resolver. El sistema funciona de la forma prevista realizando en todo momento la detección en aquellos escenarios en los que se ha probado y respetando los requisitos de falsas alarmas impuestos en su diseño; por tanto se ha obtenido una aplicación que podría ser considerado el corazón de un software comercial eficiente dedicado a la detección de movimiento para fines tanto de vigilancia como cualquier otro que lleve implícito la detección de movimiento en una imagen. No hay que olvidar que el análisis realizado en este proyecto se ha orientado a la vigilancia pero que los resultados obtenidos son igualmente validos en todos aquellos campos de aplicación que lleven implícito el análisis de imágenes digitales. Llegados a este punto cabría preguntarse cuales son los logros conseguidos con la realización de este proyecto. La respuesta a esta pregunta es que se ha obtenidos un sistema de vigilancia basado en el análisis de fotogramas digitales en tiempo real; una primera versión de este proyecto perseguía la realización de un sistema de vigilancia basado en el análisis de fotogramas pero no consiguió realizar esta labor sin hacer uso del disco del sistema para depositar los datos temporales previamente a ser analizados. Con esta versión se ha conseguido la finalidad buscada sin tener que acceder a disco para depositar los datos a espera de ser analizados, esto se consiguió almacenando los fotogramas en “contenedores” de memoria RAM del sistema lo que evitaba los elevados tiempos de acceso al disco para escribir y leer los datos. También es interesante mencionar al respecto que el uso del lenguaje de programación C++ ha hecho posible el poder acceder a memoria de forma más rápida y eficiente que lo hubiese hecho otro lenguaje de programación. Otro logro importante conseguido y que me gustaría hacer hincapié en él ha sido la presentación de la aplicación mediante una consola de uso y configuración. Considero también que esta es un punto importante del proyecto y que no debe pasar desapercibida puesto que he dedicado especial atención a su software para que en ningún momento pueda dejar al sistema en un punto inestable, y para ellos he dedicado muchas horas al análisis del hilo principal de la aplicación. No debemos olvidar que la interfaz con el usuario es de vital importancia para un buen programa pues es en definitiva el usuario el que evalúa la aplicación y esta evaluación suele ser en gran medida mediante el manejo de la interfaz de la misma: “De nada sirve tener un software de análisis eficiente si no somos capaces de configurarlo o que debido a un orden erróneo en la configuración nos cuelge el sistema”.


Conclusiones Página 136

Otro logro conseguido con la realización de este proyecto ha sido a nivel personal, pues me ha permitido enfrentarme y resolver un problema que en principio me desbordaba. Considero la conclusión con éxito de este proyecto un reto personal superado pues confieso que el tratamiento de imágenes usando la plataforma de programación de Visual C++, con la experiencia de programación que me avalaba en su comienzo, era un objetivo francamente difícil. A día de hoy me considero capacitado de resolver un problema mediante la programación con lenguajes avanzados, cosa que me ha permitido la realización de este proyecto. Por lo mencionado en el párrafo anterior animo, pero siempre advirtiendo de la dificultad que ello conlleva, a quien esté interesado en el tratamiento de imagen y sistema de detección mediante software siga esta línea de trabajo que considero únicamente en sus inicios en este proyecto.

Pese a su dificultad considero una experiencia grata la realización del proyecto y pongo mis conocimientos a disposición de quién este interesado en realizar una ampliación del mismo. Puede contactar conmigo mediante la dirección de correo [email protected] o añadirme al messenger si quiere dialogar, [email protected]; será un placer para mi poder aclarar cualquier duda que tenga dentro de mis conocimientos sobre el tema.

Documents

Captación, análisis y tratamiento de imágenes orientado a la videovigilancia