TESIS Preparada en el

Laboratorio de Técnicas y Aplicaciones para la Multimedia Distribuida Para la obtención del título de

LICENCIADO EN COMPUTACIÓN De la Universidad Autónoma Metropolitana Unidad Iztapalapa

Módulos software para la administración de cámaras IP

Por

Andrés Flores Sanz Moisés C . Marin Martinez Asesor: Dr. Luis Martin Rojas Cárdenas Octubre de 2004

Agradecimientos Escribir estas líneas me tomó un par de minutos, leerlas toma algunos segundos. Esta brevedad no refleja el tiempo que fue necesario para dar vida a la oportunidad de escribirlas. Agradezco a POE la inspiración que me ha dado su música desde el 2000, y a las personas que sin saberlo ayudaron a que este documento existiera, sin olvidar a las que voluntariamente lo hicieron. Gracias. Moisés Estas breves letras son un tributo a mis padres, a mi madre por creer en mi y no escuchar a los que le dijeron que no terminaría la secundaria y a mi padre que me enseñó que siempre hay un camino para llegar a lo deseado. Gracias a ti mis expectativas van mas allá de las fronteras y mi futuro me agrada cada día más, Gracias Mamá. No me rindo porque tú no lo hiciste y lograste tu independencia, Gracias Papá. Y algo extra. Gracias Moisés por enseñarme que un compañero de tesis puede convertirse en un amigo de por vida, eres listo y vales mas de lo que crees. Se que tendrás una gran vida y que la mereces. Lo aprendí trabajando en esta tesis. Gracias Amigo. Y gracias Ana por compartir y apoyarme en estos días en los que te he necesitado. No sabes lo importante que fue Gracias Amor.

Andrés

Conjuntamente extendemos un agradecimiento al profesor Luis Martín quien nos ofreció una oportunidad y nos permitió realizar este proyecto con él. Las oportunidades de demostrar lo que uno puede hacer no se encuentran a diario y a las personas que nos las brindan esperamos no fallarles, a usted profesor esperamos haberle mostrado un poco de lo que podemos hacer y no haberle fallado.

Andrés y Moisés

1

Indice Capítulo 1. Introducción General 1.1 Introducción . . . . . . 3 1.2 Objetivos del proyecto . . . . . . 3 1.3 Características de las Cámaras de red . . . . . . 4 1.4 Características de la Cámara Axis 2100 . . . . . 4 1.5 Software para realizar aplicaciones de Telemonitoreo . . . . 7 1.6 JAVA vs C/C++ . . . . . . 7 Capítulo 2 El Sistema de Telemonitoreo 2.1 Descripción del Sistema de Telemonitoreo . . . . . 8 2.2 Características del Diseño Descendente para la Aplicación del Sistema de Telemonitoreo. . . . . . 9 Capítulo 3 Despliegue de video por medio de Cambozola 3.1 Introducción . . . . . . 10 3.2 Problemática . . . . . . 12 3.3 Solución propuesta . . . . . . 12 3.4 Implementación de la solución propuesta . . . . . 13 3.5 Conclusiones . . . . . . 18 Capítulo 4 Soporte para el manejo de planos arquitectónicos: imágenes vectoriales 4.1 Introducción . . . . . . 19 4.2 Problemática . . . . . . 19 4.3 Solución propuesta . . . . . . 19 4.4 Implementación de la solución propuesta . . . . . 20 4.5 Conclusiones . . . . . . 24 Capítulo 5 Protocolo para la distribución de video 5.1 Introducción . . . . . . 25 5.2 Problemática . . . . . . 25 5.3 Solución propuesta . . . . . . 26 5.3.1 Definición del protocolo de transmisión . . . . . 26 5.3.2 Transferencia de una imagen fija . . . . . 26 5.3.3 Transmisión de un conjunto de imágenes fijas . . . . 27 5.4 Implementación de la solución propuesta . . . . . 27 5.5 Mejoras a la aplicación . . . . . . 30 5.6 Conclusiones . . . . . . 31

2

Capítulo 6 Conclusiones Generales y comentarios 6.1 Conclusiones Generales . . . . . . 32 6.2 Comentarios . . . . . . 32 Glosario . . . . . . 34 Bibliografía . . . . . . 35 Anexos . . . . . . 36

3

Capítulo 1 Introducción General 1.1 Introducción

El telemonitoreo es un área con muchas aplicaciones tanto en las actividades cotidianas como para el control de procesos industriales, comúnmente se utilizan dispositivos analógicos con capacidades limitadas. Las aplicaciones de sistemas digitales IP para el telemonitoreo abre un número de posibilidades tales como: monitoreo remoto sin limitaciones a nivel planetario, búsqueda de imágenes y aprovechamiento de los dispositivos de almacenamiento. En este documento se explica el desarrollo de elementos que van encaminados a formar una aplicación para telemonitoreo completa. Se plantea la problemática que presentan, la solución propuesta, su implementación y finalmente exponemos nuestras conclusiones y comentarios acerca de ese elemento y la información relacionada que encontramos en el proceso de realizar esa tarea. 1.2 Objetivos del proyecto

El presente proyecto de investigación, realizado bajo la coordinación y supervisión del Dr. Luis Martín Rojas Cárdenas del Depto. de Ingeniería Eléctrica, tiene los siguientes objetivos:

o Aprender la programación de aplicaciones multimedia en tiempo real.

o Crear funcionalidades sofisticadas para la vigilancia electrónica

o Diseñar un protocolo de transferencia para las necesidades del proyecto

4

1.3 Telemonitoreo vía cámaras IP Una cámara de red puede verse como una combinación de una cámara y una computadora. Cuenta con su propia dirección IP e integra funciones para comunicarse con una red, se conecta directamente a la red como cualquier otro dispositivo, tiene integrados un servidor http y ftp así como un cliente ftp y de correo. Algunas cámaras más sofisticadas integran funciones de detección de movimiento y salida de video analógico. Permiten acceder a video en tiempo real desde cualquier computadora, reduciendo tiempo y costos, el video puede almacenarse en locaciones distintas para mayor comodidad y seguridad. Pueden colocarse en cualquier lugar mediante distintos esquemas de conexión como LAN, DSL, MODEM, adaptador inalámbrico o incluso telefonía celular. A diferencia de una web-cam una cámara de red es más fácil de instalar, usar y administrar, ofrece más funcionalidades integradas y una mejor calidad de imagen y no necesita de una computadora para conectarse a una red. Una de las principales ventajas que una cámara de red tiene sobre una cámara analógica es la capacidad de acceder a video en tiempo real desde cualquier lugar en cualquier momento, además una cámara analógica depende de cableado coaxial y videograbadoras, lo cual se ve traducido en una mayor complejidad y costo. 1.4 Telemonitoreo con cámaras Axis 2100

Imagen 1. - Cámara axis 2100

Características Generales: o Integra un servidor Web (con soporte para PHP3) y una interfaz de red. o Utiliza como sistema operativo embedded Linux 2.0.33 o Soporta los protocolos TCP/IP, HTTP, FTP, SMTP, ARP, BOOTP, PPP, CHAP, PAP y DHCP. Características de la Cámara: o Cámara digital con color de 24 – bits

5

Sensor de imagen o ICX098AK Sony CCD con escaneo Progresivo RGB de ¼ de pulgada o HxV: 659x494. o Resolución: 640x480 (píxeles) Exposición o Compensación de luz o Control de ganancia automático (AGC) o Balance de blanco automático y visualización previa a la selección o Obturador electrónico: 1/30s - 1/30.000s (con adaptación automática) Sensibilidad o Iluminación máxima: 10.000 lux Lente: o Foco 0,5 mm a infinito o Lente estándar de 4,0 mm reemplazable con formato CS ( equivalente a una lente de una

cámara estándar de 35 mm con apertura de F2 . Es opcional una lente de 2,6 mm.) Características del Hardware: o Utiliza el Chip de compresión de imágenes JPEG ARTPEC-1 o Procesador ETRAX 100, 32 bits RISC, 100MIPS CPU o Memoria RAM de 8 MB o Memoria FLASH PROM de 2 MB Alimentación: o Toma exterior de alimentación 12V AC . Consumo máximo 7W. Entorno operativo: o Sólo para instalaciones en interiores. o Temperatura: 5°- 40° C o Humedad: 20-80%, no condensada. Dimensiones y peso: o Alto: 4,1 cm o Ancho: 10,2 cm o Fondo: 14,7 cm o Peso: 0,24 kg

6

Conexiones: o Cable par trenzado RJ45, conexión de red Ethernet 10/100 Mbit. o Conexión módem a través del puerto RS-232, para uso dial- in o dial-out. o Conector entrada/salida para activar la cámara en eventos externos. Imágenes: o Hasta 10 imágenes/seg. o Imágenes fijas JPEG y motion-JPEG. o Compresión de imágenes a alta velocidad mediante hardware o Disponibles en 5 niveles de compresión. o Control de ancho de banda, Entradas/Salidas: o Conector Input/Output para activar la cámara con eventos externos o Almacenamiento de imágenes en modo remoto vía e-mail y FTP

Imagen 2. – Componentes de la Cámara Axis 2100

Los componentes de la cámara capturan la imagen, que puede ser descrita como luz con diferentes longitudes de onda, y la transforma en señales eléctricas. Estas señales son transformadas a señales digitales y transfe ridas a las funciones que comprimen la imagen y la envían a la red. Cabe destacar que la cámara de red Axis 2100 utiliza el chip dedicado a la compresión de imágenes JPEG ARTPEC-1, de esta manera no interrumpe al procesador en el proceso de compresión, con esto se utiliza la misma cantidad de tiempo para comprimir una imagen sin importar que tan compleja es.

7

1.5 Software para realizar aplicaciones de Telemonitoreo

Las aplicaciones de Telemonitoreo pueden realizarse en cualquier lenguaje de programación que permita manejar conexiones bajo protocolos de Internet, desplegado de imágenes en distintos formatos y video. Algunos lenguajes contienen funciones que facilitan estas tareas, en algunos otros será necesario implementar algunas o utilizar otras ya definidas para obtener el funcionamiento deseado. 1.6 JAVA vs C/C++

Los sistemas operativos con los que tuvimos la posibilidad de trabajar durante este proyecto fueron: Linux (Red Hat 9, Suse 8.2 , Suse 9) y Windows XP. Para poder realizar pruebas simultaneas necesitábamos correr nuestras aplicaciones en distintos sistemas operativos, por esta razón escogimos el lenguaje de programación JAVA para desarrollarlas, ya que este lenguaje de programación permite ejecutar aplicaciones sobre distintas plataformas, esta es una característica que el lenguaje C/C++ no proporciona. En el caso de C/C++ sería necesario recompilar el código fuente del programa bajo el sistema operativo que se vaya a utilizar, lo cual crearía variaciones en el código fuente original para llevar a cabo una compilación exitosa bajo Windows y una bajo Linux. Para mantener una sola versión del código fuente decidimos aprovechar la independencia de Sistema Operativo del lenguaje JAVA. Existen muchos editores para programar en JAVA, escogimos el editor Jbuilder 8 Personal Edition porque nos pareció un buen punto de inicio para realizar aplicaciones en este lenguaje dada la facilidad que proporciona para el manejo de eventos y diseño de interfaces gráficas.

8

Capítulo 2 El Sistema de Telemonitoreo 1.0 Descripción del Sistema de Telemonitoreo

El término telemonitoreo no figura en el diccionario de la Real Academia Española, tampoco la palabra en inglés “telemonitoring” lo hace en su correspondiente de la lengua inglesa, por tal motivo es conveniente definir la manera en que utilizaremos este término. Para propósitos de este documento utilizamos telemonitoreo para referirnos a la vigilancia remota de un lugar mediante la transferencia de audio y/o video utilizando telecomunicaciones. El sistema de telemonitoreo que se consideró en este trabajo se ilustra a continuación::

Imagen 3. – Sistema de Telemonitoreo

En esta ilustración se aprecian las características del sistema, sus principales elementos son:

• el conjunto de cámaras para vigilar el lugar, las cuales pueden monitorearse desde cualquier punto de la red de área local o bien en cualquier lugar del mundo mediante la mayor red del mundo, Internet;

• la aplicación para administrar las cámaras, permitirá tener un monitoreo organizado

de éstas así como funcionalidades tales como:

- vistas miniatura de todas las cámaras que se estén monitoreando, - un panel con las vistas miniatura de las cámaras y un plano con la ubicación de

cada una de ellas, - detección de movimiento y - almacenamiento de imágenes y / o video en base a eventos

9

1.2 Características del Diseño Descendente para la Aplicación del Sistema de Telemonitoreo.

Una buena manera de planear proyectos de software grandes es utilizar un diseño descendente ( Top – Down ), bajo este esquema de programación cada tarea es descompuesta en acciones más simples para finalmente integrar los distintos módulos en el proyecto final. Bajo nuestro criterio, los módulos en los que puede descomponerse esta aplicación deben atacar las siguientes tareas:

1) Mostrar un flujo de video proveniente de una cámara, Entrada: La dirección IP de una cámara de red

Salida: Una ventana para cada dirección IP introducida

1) Mostrar una imagen vectorial en una ventana

Entrada: La ubicación en disco de una imagen en algún formato vectorial

Salida: Una ventana que despliegue la imagen vectorial.

1) Mostrar 2 paneles en una ventana y crear ventanas hijas.

Descripción: El panel derecho debe mostrar botones en posiciones introducidas por el usuario, al dar clic en algún botón del panel derecho, se debe abrir una nueva ventana hija en el panel izquierdo, cada botón del panel derecho debe tener solamente una ventana hija en el lado izquierdo.

1) Detección de movimiento en 2 imágenes

Entradas: La ubicación en disco de 2 imágenes similares, y un umbral de percepción de movimiento

Salida: Un mensaje que indique la existencia de movimiento. La descripción anterior de los módulos da un panorama más claro de cómo realizar la aplicación de administración de cámaras que se utiliza en este Sistema de Telemonitoreo. Una vez que se tienen los módulos funcionando, se continúa a la fase de comunicarlos para acercarse a una primera versión de la aplicación completa. En el Capítulo 2 se realiza el módulo que resuelve la tarea de “Mostrar un flujo de video proveniente de una cámara”, mientras que el Capítulo 3 resuelve la tarea de “Mostrar una imagen vectorial en una ventana” y se acerca a la problemática que plantea la tarea 3 en lo relacionado a ubicar botones en posiciones definidas por el usuario.

10

Capítulo 3 Despliegue de video por medio de Cambozola 3.1 Introducción

Cuando comenzamos a trabajar en esta área del proyecto, teníamos como objetivo continuar el trabajo hecho por un compañero cuyos esfuerzos estaban enfocados en la realización de un applet, en Java, que mostrara una imagen proveniente de la cámara de red Axis 2100 con la posibilidad de actualizarla. No utilizamos su investigación porque utilizamos una aproximación distinta para atacar el problema de base, sin embargo, es conveniente mencionar los problemas que se presentan bajo ese primer enfoque. Él se encontró con un problema: la dirección que utilizaba en el servidor http de la cámara para recuperar una imagen le enviaba siempre la misma., es decir; tenía un applet en Java que mostraba siempre la misma imagen. Este problema se debe a que la dirección http en la cámara ejecuta un script en CGI que se encarga de obtener una nueva imagen, este script no se ejecutaba cuando el applet pedía una nueva imagen, permitiéndole simplemente disfrutar de una y solo una imagen digital. Es posible utilizar una perspectiva diferente ya que la cámara Axis 2100 permite recuperar un flujo de tipo MJPEG, esto es: Motion JPEG, imágenes JPEG consecutivas con marcadores que indican dónde comienza y dónde termina cada una de ellas.

Imagen 4. – Marcadores MJPEG

Es fácil imaginar las características de una aplicación que pueda aprovechar un flujo de esta naturaleza para recuperar las imágenes que contiene, podemos describir su funcionamiento mediante el siguiente algoritmo:

0. Comenzar a recibir de la cámara el flujo MJPEG. Repetir: 0. Copiar la información de una imagen en un buffer. 0. Desplegar el buffer en pantalla. 0. Esperar. Hasta que se indique terminar.

El nivel de complejidad de una aplicación como la que describimos en las líneas anteriores radica principalmente en el uso eficiente del lenguaje de programación que se elija para desarrollarla.

11

Software Reutilizable

Por otra parte, existen muchos programas con una licencia del tipo GNU General Public License, un licencia que permite, en pocas palabras, utilizar el software que se cobija bajo ella, tomar partes de él, modificarlo e incluso redistribuirlo, siempre y cuando se proporcione el código fuente de todas las modificaciones realizadas para que otras personas tengan las mismas facilidades que quienes lo utilizaron y / o modificaron; así como el respeto de los autores originales.

La idea detrás de este tipo de licencias es precisamente ayudar a desarrolladores a

preocuparse en la problemática principal de sus proyectos y no por los detalles básicos que se repiten en muchas otras aplicaciones; es decir, encaminarse hacia la creación de chips de software que puedan integrarse permitiendo avanzar en el desarrollo de un proyecto sin detenerse a redescubrir el hilo negro ni resolver problemas ya resueltos de manera eficiente. Cambozola v0.34

Cambozola v0.34, es un software con una licencia del tipo GNU, General Public License. Su autor, Andy Wilcock, lo describe de la siguiente manera [13] :

“Cambozola es un visor de flujos de imágenes como los producidos por webcams. Netscape puede desplegarlos de manera correcta actualizando las imágenes como las va recibiendo, pero algunos exploradores, como el Internet Explorer, no pueden manejar este flujo y solo muestran la 1ra imagen. Cambozola es un elemento para utilizar en conjunción con las páginas web, puede utilizarse en páginas para el Internet Explorer así como para Nestcape. También permite tener acceso a los flujos desde la línea de comando.”

En otras palabras, Cambozola es un programa desarrollado en Java que muestra un flujo de imágenes JPEG, permitiendo observar el flujo sin importar el navegador que se utilice, puede funcionar como un applet en una página web o bien como una aplicación. A continuación presentamos la manera en que utilizamos este software, proporcionado de manera gratuita por su autor, para resolver el problema que se nos presentó en esta parte del proyecto de investigación, el código fuente de la aplicación se encuentra en los Anexos de este documento.

12

3.2 Problemática Construir una aplicación en Java para mostrar un flujo de video proveniente de una cámara de red. 3.3 Solución Propuesta

) Analizar el código fuente y funcionamiento de cambozola v0.34 ) Realizar un proyecto en JBuilder 8 Personal Edition, que integre las clases de

cambozola v0.34 útiles para satisfacer el problema planteado. ) Realizar pruebas con el proyecto obtenido para visualizar flujos de imágenes

provenientes de cámaras Axis ubicadas en distintos puntos geográficos.

13

3.4 Implementación de la solución propuesta a) Analizar el código fuente y funcionamiento de cambozola v0.34 En la siguiente imagen se aprecian los componentes de Cambozola v0.34

Imagen 5. - Componentes de Cambozola v0.34

Accesories

Contiene el código fuente de los accesorios que aparecen en la parte izquierda de la ventana así como una imagen asociada a cada una de ellas.

Server

Contiene el código fuente de un servidor de prueba que envía repetidamente un conjunto de imágenes que se encuentran en testImages.

Shared

Contiene el código fuente de las clases compartidas por el servidor y el cliente de este software.

14

Viewer.java

La clase principal que permite establecer una conexión con un flujo MJPEG y desplegarlo en una ventana.

Estableciendo la conexión Las clases que permiten realizar la función principal de este software son las siguientes:

Viewer.java StreamSplit.java CamStream.java

El siguiente diagrama indica la manera en que los objetos de estas clases interactúan.

Imagen 6. – Interacción de las clases

15

El funcionamiento es el siguiente, a un objeto de la clase Viewer se le indica una dirección IP de la cual recibirá el flujo, por ejemplo:

http://192.168.0.69/axis-cgi/mjpg/video.cgi?resolution=320x240 Este objeto inicializa las variables relacionadas con la dirección IP, configura los accesorios activos y si todo marcha bien, instancia un nuevo objeto de la clase CamStream. Un objeto de esta clase crea un socket con la dirección IP y el puerto 80, se auxilia además de un objeto de la clase StreamSplit para separar las imágenes del flujo mediante el método readToBoundary(String boundary), el resultado de este método es almacenado en una variable byte[] img para después desplegarlo en pantalla. b ) Realizar un proyecto en JBuilder 8 Personal Edition, que integre las clases de cambozola v0.34 útiles para satisfacer el problema planteado.

JBuilder 8 Personal Edition proporciona una interfaz gráfica que facilita la elaboración y control de proyectos realizados en Java, decidimos trabajar con esta versión porque es gratuita, de esta manera contamos con las funcionalidades limitadas de un software ‘legal’. Una vez entendido el funcionamiento de Cambozola, identificamos las modificaciones que debíamos realizar sobre la clase que realiza la conexión con el flujo MJPEG y lo despliega en pantalla, Viewer.java, estas fueron:

- Permitir recibir como parámetro la dirección IP del flujo MJPEG - Retirar el código dependiente de ejecución como applet - Habilitar los accesorios

Definimos una nueva clase dentro de package com.charliemouse.cambozola que incorpora estas modificaciones con el nombre winClass.java La aplicación resultante, Visor MJPEG , consta de los siguientes archivos además del package com.charliemouse.cambozola : Application1.java Clase principal de este programa.

Instancia un nuevo objeto de tipo Marco1. Marco1.java

Esta clase de interfaz crea un nuevo objeto de tipo winClass para cada dirección IP que se le indique.

winClass.java

Esta clase establece la conexión con el flujo MJPEG y lo despliega en una ventana, está basado en la clase Viewer.java

16

d ) Realizar pruebas con el proyecto obtenido para visualizar flujos de imágenes provenientes de cámaras Axis ubicadas en distintos puntos geográficos. Escalabilidad Al identificar las clases que participan en el funcionamiento de Cambozola, pudimos delegar la responsabilidad de invocar esta funcionalidad primaria a una clase en un nivel superior para poder tener una sola aplicación ejecutando detrás la tarea de muchos clientes de este software, por lo que la aplicación permite realizar conexiones con varias cámaras a la vez. Se realizaron pruebas sobre una conexión a 56KB con 6 cámaras y se obtenían intervalos de actualización de entre 3 y 8 segundos. Velocidad

Le toma a la aplicación algunos segundos establecer la conexión con el flujo, una vez realizada esta operación pueden monitorearse más cámaras que proporcionen un flujo de imágenes MJPEG. Es ta aplicación se probó sobre una conexión a 56KB y sobre la conexión del laboratorio de Técnicas y Aplicaciones para la Multimedia Distribuida, a manera cualitativa podemos mencionar que la diferencia de velocidad es bastante notoria, mientras que en una conexión casera de 56 KB las cámaras se refrescan en intervalos de tiempo más largo, una conexión más rápida permite un monitoreo más cercano al tiempo real. A continuación se muestran algunas imágenes del funcionamiento del Visor MJPEG.

Imagen 7. - Visor MJPEG

17

Imagen 8. - Ventana con accesorios

Imagen 9. – Muestra de cámara

Imagen 10. - Muestra de cámara

18

3.5 Conclusiones Sobre la planeación y desarrollo Ahora que nos encontramos redactando las tareas que realizamos en este proyecto, nos damos cuenta que el tiempo utilizado para desarrollar la aplicación que se describe en este capítulo fue excesivo. La razón de la divergencia entre el tiempo utilizado para la planeación - desarrollo y el tiempo, que ahora con la experiencia que nos dejó el proyecto estimamos necesario, se debe a los conocimientos mínimos que teníamos respecto a cámaras de red, al lenguaje de programación Java, al funcionamiento del esquema cliente - servidor y al formato MJPEG. Esta ignorancia, hasta entonces no culpable, tuvo que desaparecer para poder tener éxito en el objetivo de esta parte del proyecto de investigación. Sobre software libre y detección de movimiento

El software libre proporciona herramientas valiosas para el desarrollo, no solo rápido, sino eficiente de proyectos, esta posibilidad de encontrar e integrar elementos existentes y necesarios para problemáticas nuevas permite que la humanidad avance en conjunto, ya que ante nuestros conocimientos limitados sobre los temas de la naturaleza nuestra única posibilidad de tomar un poco de ella y obtener algo para beneficio general es brindarle un golpe colectivo gracias a las ideas que algunos ‘visionarios’ tienen.. Las cámaras de red integran aplicaciones que permiten distintas características de administración, sin embargo existen algunas otras aplicaciones desarrolladas por terceros que extienden las funcionalidades que una cámara de este tipo ofrece. Los ejemplos que conocemos son Cambozola [13] y Video Sensor 1.22 [15] [16], el primero ya lo describimos en este capítulo, el segundo ofrece la posibilidad de realizar detección de movimiento, utilizando los recursos del equipo del usuario que accede a la página http de la cámara. Esta aplicación es un primer paso en la incorporación de detección de movimiento para la aplicación encargada de la gestión de cámaras de red.

19

Capítulo 4 Soporte para el manejo de planos arquitectónicos: imágenes vectoriales 4.1 Introducción

Una de las funcionalidades que tendrá el gestor de cámaras de red es poder ubicar éstas en un mapa, ya sea de un estadio, de un hipódromo, de un edificio o de una alberca. Esta característica permitirá acceder a las cámaras de manera rápida mientras se está consciente de su ubicación en el entorno que se vigila.

El formato WMF (Windows Meta File) es un formato vectorial de imágenes creado por Microsoft para ser utilizado en las plataformas Windows. Se diferencia de otros formatos de imágenes como el JPEG porque cada elemento en la imagen es independiente de la imagen misma, vista como un solo elemento, permite además la posibilidad de modificar su tamaño sin perdida de definición y por lo regular el espacio que utiliza en disco es una fracción del espacio ocupado por la misma imagen en un formato no vectorial. Este formato de archivos se utiliza por lo regular en clipart y logos, es claro que este formato no puede utilizarse para fotos realistas con muchos detalles [12]. En relación al gestor de cámaras, utilizar el formato vectorial WMF para representar los mapas permite trabajar con archivos de tamaño optimizado y poder realizar zoom in / out sobre la imagen sin perder calidad. Una alternativa a las imágenes WMF es el formato SVG (Scalable Vector Graphics) [14]. SVG es un lenguaje para describir imágenes en dos dimensiones en el formato XML, fue creado por el World Wide Web Consortium (W3C), la industria sin fines de lucro con especificaciones públicas que creo HTML y XML. Más de 20 organizaciones han particiado en la definición de SVG, algunos ejemplos son : Sun Microsystems, Adobe, Apple, IBM, y Kodak. Este formato trabaja con la tecnología java y sus especificaciones son públicas.

4.2 Problemática Desarrollar una aplicación que permita:

a) Mostrar imágenes vectoriales del formato WMF b) Mostrar botones con posiciones específicas

4.3 Solución propuesta

a) Mostrar imágenes vectoriales del formato WMF Hay 2 opciones, la primera es desarrollar un visor para este tipo de imágenes, una tarea que exige un tiempo considerable, pues requiere estudiar y analizar la especificación del formato así como de un conocimiento en el lenguaje de programación bastante sólido para que puedan manipularse archivos a nivel de bytes con seguridad; la segunda opción es utilizar visores de licencia pública

20

Decidimos utilizar la 2da aproximación porque el tiempo con el que contamos es limitado, además de que nos permite dar una idea de la manera en que funcionará esta característica en el gestor de cámaras.

b) Mostrar botones con posiciones específicas Utilizaremos un archivo de texto que contendrá la ubicación de los botones (que representan a las cámaras), la ubicación se refiere a coordenadas dentro de una ventana, en esta aproximación los botones son independientes de la imagen que se utilizará como mapa. 4.4 Implementación de la solución propuesta

a) Mostrar imágenes vectoriales del formato WMF El visor que utilizamos es el WmfView 0.6 desarrollado por Albrecht Kleine [18], se distribuye en el archivo WmfView06.tgz y contiene los siguientes elementos:

Imagen 11. – Elementos de WmfView 0.6

Los archivos que permiten desplegar una imagen wmf en una ventana son WmfDecoder.java y WmfView.java. La clase WmfView tiene proporciona el siguiente método

public Image CreateWmfDecoder(String filename) { Image image; try { WmfDecoder WDec=new WmfDecoder(new FileInputStream(filename)); image = createImage(WDec); WDec=null; } catch (Exception ex) { ex.printStackTrace(); return null; } return image; }

el cual recibe como argumento el nombre de un archivo wmf, instancia un objeto de tipo WmfDecoder y crea una imagen a partir de él.

21

La clase WmfDecoder contiene los marcadores y elementos propios del formato wmf para poder recuperar una imagen a partir de la información contenida en una imagen con este formato. Utilizando solo los elementos necesarios, el “Visor de Imágenes WMF” tiene los siguientes archivos:

Imagen 12. – Elementos de Visor de Imágenes WMF

Y funciona de la siguiente manera: 1. Se introduce el nombre de la imagen Wmf en la ventana principal y se da click en abrir:

Imagen 13. – Ventana principal de Visor de Imágenes WMF

Al dar click en el boton “Abrir” se ejecuta el siguiente código;

void btn1_actionPerformed(ActionEvent e) { Image wmf; WmfView IMG; File f = new File(txtImagen.getText()); if(f.exists()){ lblStatus.setText("OK"); } else{ lblStatus.setText("ERROR: No existe"); return; } IMG=new WmfView(txtImagen.getText(),false,false); wmf=IMG.CreateWmfDecoder(txtImagen.getText()); TestBackgroundLayered T1=new TestBackgroundLayered(wmf); T1.main(wmf); }

El evento define un objeto de tipo Image y uno de tipo WmfView, después de verificar que el archivo existe instancia el objeto de tipo WmfView con el nombre del archivo, ejecuta el método .CreateWmfDecoder de este objeto para obtener la imagen que finalmente se utiliza

22

como argumento para instanciar un objeto de tipo TestBackgroundLayered, el cual es una ventana que utiliza como fondo la imagen que se le indica como argumento.

Imagen 14. – Visor de Imágenes WMF

Imagen 15. – Imagen WMF

Pueden continuar abriéndose más imágenes repitiendo el paso anterior.

23

b) Mostrar botones con posiciones específicas

La idea es simple, definimos un arreglo de objetos de tipo botón:

Name= new JButton[b]; de un archivo de configuración se obtiene el número de botones y la posición de cada uno de ellos. En el programa se utiliza un ciclo for para cargar cada botón en el arreglo y desplegarlo en una ventana. Por ejemplo, si en el archivo de configuración se introduce la cadena 5151Pñ5ñwñP, se indica que habrán 5 botones con las siguientes posiciones:

........b=5 49 53 0 49 80 1 241 53 2 241 119 3 241 80 4

El 1er elemento indica el número de botones, y el resto indica la posición de cada uno de ellos, es decir; se obtiene el equivalente en código ASCII y se le suma 49. El archivo de configuración se utiliza de esta manera porque estaba en fase de desarrollo, lamentablemente no pudimos continuar mejorando su diseño porque resulto más importante desarrollar el servidor-cliente que se describe en el siguiente capítulo. Con la cadena anterior se obtiene la siguiente distribución:

Imagen 16. – Ventana con arreglo de botones

24

4.5 Conclusiones

En esta parte de la tesis desarrollamos con éxito una aplicación que permite visualizar imágenes WMF. Lamentablemente el visor en el que se basa la aplicación sufre en desempeño y veracidad al trabajar con imágenes formadas por muchos elementos, en los archivos de ejemplo proporcionados con este documento, puede apreciarse que en algunos casos los colores se ven alterados y en el peor de los casos hay elementos que se unen a otros mediante trayectorias no planteadas originalmente. El archivo de prueba final, el mapa de la alberca olímpica, es un claro ejemplo de las deficiencias del visor.

Imagen 17. – Creditos de WMF2Viewer

Existe en visualizador de imágenes wmf en el mercado desarrollado por Piet Jonas, es desarrollado en Java por Piet Jonas, y su licencia tiene un costo de $250 USD [17]. Este visor no mostró ningún problema al desplegar imágenes con muchos elementos. El programa que permite crear botones en una ventana se detuvo en fase de desarrollo porque comenzamos a trabajar en el cliente-servidor de imágenes para una cámara de red Axis 2100 que se describe en el capítulo 4 de este documento. Una etapa posterior requiere unir estas 2 pequeñas aplicaciones en una sola para obtener la funcionalidad que se desea: mostrar las cámaras (representadas mediante botones) sobre una imagen wmf con posiciones definidas en un archivo de configuración.

25

Capítulo 5 Protocolo para la distribución de video 5.1 Introducción

Las capacidades de cómputo de la cámara de red Axis 2100 hacen posible ejecutar programas en ella, de esta manera no se utiliza tiempo del procesador en el cliente. La aplicación que se desea desarrollar para esta cámara es una que permita realizar detección de movimiento en las imágenes que observa, de esta manera solo envía al cliente la información relevante al entorno que se vigila, pues almacenar imágenes obtenidas en intervalos fijos requieren de una gran cantidad de espacio, aún siendo imágenes digitales. Si bien el almacenamiento digital requiere menos espacio físico que el almacenamiento analógico es necesario hacerlo de manera inteligente, si se almacenan solo las imágenes de un lugar en las que hubo movimiento, se ahorran recursos y tiempo. El primer paso para desarrollar esta aplicación es poder obtener 2 imágenes en cualquier momento. La aplicación servidor resuelve este punto al crear un directorio temporal en donde se almacena la última imagen enviada a un cliente, así se tiene una imagen de referencia a comparar con la nueva imagen que se pida. Pero las aplicaciones proporcionadas por el fabricante permiten obtener imágenes de la cámara, ¿por qué resulta importante hacer una aplicación para este mismo propósito? La respuesta es clara, para disponer de imágenes en la cámara que puedan compararse cuando la parte de detección de movimiento esté completa y para tener un control sobre quienes acceden a la cámara al utilizar un puerto específico y una validación diferente a la proporcionada por el fabricante. 5.2 Problemática

Realizar una aplicación cliente – servidor de tal manera que el servidor pueda ejecutarse en la cámara de red Axis 2100. El servidor debe implementar un método para validar al usuario que se conecta y utilizar un protocolo de transferencia de imágenes apropiado.

26

5.3 Solución propuesta

5.3.1 Definición del protocolo de transmisión El siguiente diagrama muestra el protocolo que decidimos utilizar:

Imagen 17. – Especificación del protocolo de transferencia.

El servidor puede enviar 2 tipos de mensajes: 0. Si la dirección IP está en la lista de direcciones válidas se envía una imagen

dividida en mensajes de tamaño fijo. El cliente recibirá estos mensajes y terminara cuando reciba un mensaje cuyo tamaño sea menor al fijado. Este criterio de paro se utiliza en otros protocolos de transferencia simple como TFTP.

0. Si la dirección IP no se encuentra en la lista, se envía el siguiente mensaje - error -

4.2.1 Transferencia de una imagen fija El cliente enviará un mensaje al servidor (su contenido no importa, pues solo se necesita para conocer la dirección IP), el servidor buscará en la lista de IPs válidas al cliente, si lo encuentra, comenzará a enviar fragmentos de imagen de tamaño fijo hasta terminar con la imagen. El cliente recibirá los fragmentos hasta que aparezca uno de tamaño menor al fijado y en ese momento termina la conexión. Cada mensaje que recibe lo desplegará en la salida estándar, esto permite dar más flexibilidad al momento de almacenar las imágenes. El servidor mantendrá abierto el puerto de peticiones desde que se inicia. Solo puede darle servicio a un cliente a la vez.

27

4.2.1 Transmisión de un conjunto de imágenes fijas El cliente esta diseñado para solicitar una imagen, si se desea solicitar más el cliente debe ejecutarse muchas veces. Un visor para este servidor deberá pasar por todo el protocolo cuando necesite la siguiente imagen.

5.4 Implementación de la solución propuesta Sobre las imágenes

El formato JFIF, es un formato JPEG con marcadores extra para permitir que tramas de bits de una imagen JPEG puedan enviarse a una gran variedad de plataformas y aplicaciones. El restart marker repite información que permite conocer las características de la imagen para poder reconstruirla, esta información no se encuentra repetida en una imagen JPEG. esta característica permite sobreponerse a pérdida de información al transferirla. La camara axis 2100 genera imágenes que cumplen con las especificaciones JFIF, pero no puede generar marcadores para utilizar una fragmentacion lógica. Véase anexo Support case no. 30047.

Los marcadores se generan al momento de codificar la imagen, por lo tanto para introducir nuestros propios marcadores es necesario decodificar y codificar una vez más la imagen, lo cual, dadas las características de la cámara, no es posible, pues deberíamos incluir un codificador JPEG en ella. Consideramos que una fragmentación en un punto intermedio entre la lógica y la que no toma en cuenta el formato de la imagen consistiría en dividir la foto utilizando los marcadores FF00, ya que estos marcadores en una primera examinación demostraron tener una aparición distribuida a lo largo de los datos, lamentablemente, al investigar el formato encontramos que la secuencia FF00 no es el marcador 00; se utiliza 00 para indicar que FF no es principio de marcador sino datos de la imagen. Y dado que la aparición de este pseudo-marcador FF00 depende de la información de la imagen, no es viable utilizarlo para fragmentar. Por estas razones nuestro protocolo no utiliza una fragmentacion lógica.

28

Sobre el cliente La implementación del cliente se realizo partiendo de un esquema cliente – servidor bastante simple hasta cumplir con las características descritas en la solución propuesta. A continuación se muestra el código fuente de cliente.c #include "net.c" //en net.c se especifica el tamaño de los paquetes en 10KB #define DIRECCION 1 #define PUERTO 2 struct sockaddr_in serv; int fd,len,i=0; FILE *f2=NULL; main (int argc, char *argv []) { char buffer [ETHSIZE]; //El buffer para almacenar la imagen if (argc != 3) { printf ("%s <IP address> <port>\n", argv [0]); exit (1); } fd = create_UDP (&serv, argv [DIRECCION], atoi (argv [PUERTO])); /* Se hace la qra petición, el contenida de esta es irrelevante */ strcpy (buffer, "esta es una peticion desde el cliente"); send_UDP (fd, buffer, strlen (buffer) + 1, &serv); while(1){ //Comienza a recibir la imagen len=recv_UDP (fd, NULL, buffer, ETHSIZE); for(i=0;i<len;i++) printf("%c",buffer[i]); //Escribe en la salida estándar los paquetes. if(len<ETHSIZE) exit(0); } } El cliente debe ejecutarse de la siguiente manera :

./cliente 148.206.49.71 7500 > img.g De esta manera redirige a un archivo los mensajes que recibe. Este modo de funcionamiento permite ser más eficiente al momento de almacenar imágenes consecutivas pues puede utilizarse un script que genere nombres consecutivos, basados en un contador de imagen o en el reloj. Asi el cliente solo se encarga de realizar su tarea, pedir una imagen.

29

Sobre el servidor Cuenta con 2 archivos de conviguracion iplist y task.list. El primero tiene el siguiente aspecto:

255.255.255.255 148.206.49.157 127.0.0.1 192.168.0.5 148.206.49.71 148.206.49.153 192.168.0.3 255.255.255.255

El segundo se necesita para poder ejecutar el servidor al iniciar la cámara, debe copiarse en el directorio /etc en la camara. A continuación se muestra su contenido: once immune % /bin/bufferd : -start -buffername snap -snapshot -format Foto.jpg -uri ftp://axis-cgi/jpg/640x480.jpg; once % /mnt/flash/servidor; Las instrucciones anteriores arrancan el buffer de imágenes en un directorio y ejecutan el servidor. El funcionamiento del archivo task.list se explica con más profundidad en nuestra guia “Axis 2100”. A continuación se muestra el codigo fuente de servidor.c #include "net.c" #define PUERTO 7500 int fd,i=0,j=0,atam=0,ipvalida=0; struct sockaddr_in cli, serv; FILE *f1=NULL,*lista=NULL; int main() { char buffer[ETHSIZE]; char *s1=NULL,*iplista; lista = fopen("/mnt/flash/iplist","r"); fd = create_UDP (&serv, NULL, PUERTO); ///El ciclo infinito del servidor ///Consiste en esperar peticiones, verificar la IP, obtener una nueva ////imagen y enviarla en pedazos de 10 KB while(1) { recv_UDP (fd, &cli, s1, ETHSIZE); printf("\nIP cliente:[%s]\n",iplista=(char *)inet_ntoa(cli.sin_addr)); while(fgets(buffer,20,lista) && !ipvalida ){ buffer[strlen(buffer)-1]='\0'; if(strcmp(buffer,iplista)==0){ ipvalida=1; printf("IP valida :[%s]\n",buffer); } } if(ipvalida){ system("/bin/rm -f /tmp/snap/Foto.jpg");

30

while(f1==NULL) f1 = fopen("/tmp/snap/Foto.jpg","r"); while((j=fgetc(f1))!=EOF){ buffer[i]=j;i++;atam++; if(i==ETHSIZE){ buffer[ETHSIZE]='\0'; send_UDP (fd, buffer, ETHSIZE, &cli); i=0; } } buffer[i]='\0'; send_UDP (fd, buffer, i, &cli); printf("\nEnviado: %d\n",atam); ipvalida=0; } ////En caso de tener una IP no valida, se envia el mensaje de error. else{ printf("\n[Conexion terminada]\n"); send_UDP (fd, "Error", 5 , &cli); } rewind(lista); fclose(f1); f1=NULL; j=0;i=0;atam=0; } return 0; } El tamaño de los paquetes se fijo en 10KB ya que con tamaños más grandes la cámara presentaba un comportamiento inestable. 5.5 Mejoras a la aplicación Observamos las siguientes características en el funcionamiento de nuestra aplicación:

o entre mas peticiones haya de clientes, éstos percibirán una mayor demora ya que deben esperar a que el servidor las atienda

Para esta situación podrían considerarse implementar los siguientes puntos: § Agregar cada usuario valido a una lista. § Cada nueva imagen podría enviarse a los usuarios en la lista. § Podría existir un proceso hijo que se encargue de verificar el estado de los

usuarios en la lista mientras el proceso padre los atiende.

Esta situación se presenta principalmente en clientes de tipo visor de flujo.

31

o las imágenes son únicas para cada petición, debido a que se solicitan imágenes en

tiempos diferentes.

Podrían considerarse: § Enviar cada paquete a todos los clientes en una lista de usuarios conectados.

Es claro que se esta restringido a las familias de protocolos soportados por la cámara; es decir, utilizar protocolos que distribuyan el flujo como IGMP no es posible.

5.6 Conclusiones Esta parte del proyecto de investigación fue la más interesante porque involucró un nivel teórico que exige una buena asimilación del material proporcionado por otros cursos. El paso de la solución propuesta a la implementación requirió un tiempo considerable pues no hay mucha información relacionada a aplicaciones sobre la cámara, por lo que era nuestra responsabilidad resolver los problemas que se nos presentaban. Este servidor permite controlar los accesos a la cámara, pero es importante considerar que tanto vale la pena dedicarle tiempo a tareas que en modelos más recientes ya están integradas.

32

Capítulo 6 Conclusiones Generales y comentarios 6.1 Conclusiones Generales A lo largo de este proyecto conocimos diferentes elementos que participan en una aplicación para telemonitoreo, los elementos que comenzamos a desarrollar en este documento pueden ser continuados para aumentar su funcionalidad y ayudar a dar vida a la aplicación que se contempló cuando comenzamos a trabajar en este proyecto. La parte relacionada con las aplicaciones en Java nos proporcionó conocimientos sobre este lenguaje de programación, nos dio una idea de las utilidades que se le da a las imágenes en formatos vectoriales, así como una visión de las alternativas no propietarias. Sin duda, la parte más interesante de este proyecto fue lo relacionado a la definición de un protocolo para transferir imágenes, el cual se implementamos en la aplicación cliente servidor que utilizamos en el capítulo 4. Esta parte del proyecto nos ayudó a consolidar nuestras bases en protocolos de internet (una palabra un tanto pretenciosa) , utilizamos programación en sockets y conocimos de qué manera funcionan, programamos en el intérprete de lenguajes para linux (un lenguaje de programación de 4ta generación), conocimos un poco sobre compiladores cruzados (cross-compilers) que permiten crear ejecutables para distintas plataformas, y del manejo, configuración, desarrollo y ejecución de aplicaciones en la cámara de red Axis 2100, conocimiento que nos permitió redactar el documento “Axis 2100” , una buena referencia que esperamos sea de gran utilidad a alumnos y profesores que estén interesados en realizar aplicaciones para esta cámara. Tal documento contiene toda la información que nos habría permitido reducir el tiempo de desarrollo de este proyecto considerablemente. El almacenamiento digital es un gran avance que sin duda adquirirá más seguidores a lo largo de los años hasta volverse parte imprescindible de la humanidad, las ventajas de este tipo de almacenamiento sobre el analógico en el monitoreo de locaciones son muchas y es solo cuestión de tiempo para que las empresas dedicadas a curir las necesidades de este tipo hagan su transición a los nuevos estándares mientras que se continúa desarrollando nuevos que permitan mejorar la transmisión, disminuir los requisitos de recursos de comunicación y hagan que el almacenamiento digital, las transmisiones multimedia, y funcionalidades extra sean más accesibles, eficientes y útiles. 6.2 Comentarios

¿Vale la pena desarrollar un software que permita detectar movimiento para la cámara Axis 2100 cuando el modelo 210, 211 y 2120 ya lo incorporan? Es importante considerar qué tan necesario es dedicarle esfuerzos a una tarea, tal vez podría obtenerse una mayor eficienc ia al desarrollar una funcionalidad como esa, y es claro que tiene una gran importancia académica pero desde el punto de vista del costo que se invierte en tiempo y esfuerzos ¿vale la pena? Creemos que los argumentos de las respuestas van encaminados en cierta manera a las razones por las que se están desarrollando chips de software, no tanto como para “ahorrarnos trabajo” o “darle la vuelta a un problema” sino para continuar trabajos ya hechos y no perder tiempo en rehacer algo ya estudiado.

33

Static Linking Es necesario incluir las bibliotecas que necesitará un ejecutable al compilarlo para la cámara, pues ésta solo cuenta con bibliotecas optimizadas, así que el parámetro –static es obligatorio [20]. Esta explicación tomó tres líneas pero descubrir el uso de ese parámetro nos tomó alrededor de 1 semana, principalmente porque nuestra experiencia no era la suficiente para darnos cuenta de la razón por la cual nuestros ejecutables no encontraban las bibliotecas que requerían. El soporte técnico de Axis nos menciono que no proporciona ayuda en el desarrollo de aplicaciones llevadas a cabo por terceros (ver anexos), la solución a este problema la encontramos en una pagina de soporte de Axis en Europa donde una persona tubo el mismo problema que nosotros, y al parecer en el 2002 el soporte técnico aun daba esa clase de ayuda. Ligar de manera estática un programa con las bibliotecas que utiliza produce un ejecutable de tamaño obsceno (varios MB), el compilador cruzado de Axis liga ejecutables para la cámara con bibliotecas optimizadas, de esta manera es posible desarrollar programas para ella dadas sus limitaciones de almacenamiento. devboard-R1_1_0.tgz La distribución del compilador para la cámara necesita un ; en el archivo boa_grammar.y en la línea 234, este error ya fue corregido en el cd que acompaña al manual de referencia “Axis 2100”.

34

Glosario LAN

Local Area Network , Una red de área local. DSL

Digital Subscriber Line, se refiere a un conjunto de tecnologías similares que permiten conexiones de alto rendimiento a través de líneas telefónicas convencionales para la transmisión de datos sin interrumpir el servicio telefónico.

MODEM

Modulador-DEmodulador, es un dispositivo que transforma las señales digitales de la computadora en señales analógicas para transmitirlas y recibirlas mediante la línea telefónica.

Embedded Linux.

Una distribución de Linux que integra los elementos necesarios para propósitos específicos, es decir; se toma una distribución de Linux a la cual se le retiran las partes que no se necesitan, de esta manera el usuario tiene exactamente lo que requiere y nada más. La cámara Axis 2100 utiliza como sistema operativo un embedded Linux que puede actualizarse en la memoria flash de 2MB integrada.

JPEG ARTPEC-1

Se utiliza compresión JPEG en las imágenes que genera la cámara Axis 2100. El chip de compresión desarrollado por Axis, ARTPEC – 1 , Axis Real Time Picture Encoder - 1 . Este chip permite 2 niveles de resoluci+on y 5 niveles de compresión.

MJPEG

La abreviación de Motion-JPEG, es un estándar de video creado por el Joint Photographic Experts Group, la organización que creo el formato de compresión JPEG. Utiliza compresión JPEG para cada imagen en el video.

WMF

Formato vectorial de imágenes creado por Microsoft.

35

Bibliografía [1] Paul Dubois, Using csh & tcsh. O’Reilly & Associates, Inc, 1995 [2] Jay Arthur Lowell, Ted Burns, Unix Shell Programming. Whiley Computer Publishing, 1997 [3] Tonny Espesset, Kick ass Java programming. Coriolis Group Books, 1996 [4] Siever, Spainhour, Figgins, Hekman, Built-in csh and tcsh Commands (Linux in a Nutshell, 3rd Edition). http://www.hk8.org/old_web/linux/lnut/ch08_09.htm , August, 2000 [5] Bill Rogers, Programming Language Generations. http://www.sxu.edu/~rogers/cs111/generations.html ,1999 [6] Evan Schaffer, Mike Wolf , The UNIX Shell As a Fourth Generation Language. http://www.rdb.com/lib/4gl.pdf , Febrero, 2001 [7] Christian Korner, Identify Sony chips.

http://www.plasma-online.de/index.html?content=http%3A//www.plasma-online.com/english/identify/picture/sony.html , 1999

[8] Jason Schumaker, Linux Journal: The Axis 2100 Network Camera [Review].

http://alllinuxdevices.com/news_story.php3?ltsn=2000-08-26-005-03-PS-HW , Agosto, 2000 [9] Cámaras de red Axis. http://www.axis.com.mx/productos/camaras/ , 2004 [10] Axis 2100. http://axis.com.mx/productos/camaras/2100.htm , 2004 [11] Network Camera benefits. http://www.axis.com/products/video/camera/benefits.htm , 2004 [12] Geoff Spencer, Imagenes WMF. http://www.shoal.net.au/~huntingcat/images.html , 2001 [13] Andy Wilcock, Cambozola Streaming Image Viewer http://www.charliemouse.com/code/cambozola/index.html , 2000 [14] Chris Lilley, Scalable Vector Graphics (SVG) http://www.w3.org/Graphics/SVG/Overview.html , 2004 [15] Video Sensor 1.22, Sensores de movimiento por software para la cámara AXIS 2100 http://www.gipro.de/download/ , Marzo , 2003 [16] SeeTec Motion Detection Software. http://www.seetec.de/eng/eng/software_index.html , Marzo, 2004 [17] Comprar WMF2Viewer, http://shareit1.ele ment5.com/programs.html?productid=106153 [18] Albrecht Kleine, WmfView . http://www.sax.de/~adlibit/ , Julio , 2004 [19] Street Tech Glossary. http://www.streettech.com/glossary.html , 1999 [20] Jonas Holmberg, Static Linking. http://mhonarc.axis.se/dev-etrax/msg00990.html , Septiembre, 2001

36

Anexos Conversacion con Andy Wilcock, Autor de Cambozola De: Andy Wilcock <andrew_wilcock@bigfoot.com> Enviado el: Viernes, 30 de Mayo de 2003 05:14:41 a.m.

Para: ----------- ----------- <marin_r_us@hotmail.com>

Asunto: Re: CAmbozola Vie.wer. ...i.nf.o.

Moses/Andrew, Apoligies for taking so long to reply. Unfortunately, I don't have a AXIS 2100, just a pathetic $10 IBM webcam (I kid you not). As for the proxy, I am able to use [all on one line]: java -jar cambozola.jar http://66.210.186.170/axis-cgi/mjpg/video.cgi?1054271499352 [- the image location from http://66.210.186.170/view/index.shtml ] The same should work from the web browser/applet IF you use the prebuilt jar file (as it is signed). Hope that helps, Andy. On Thu, 2003-05-22 at 07:04, ----------- ----------- wrote: > Dear Andrew, > > We apologize for our last mail, we hadn't tried enough and we hadn't > read the manual. Finally we could make your viewer work but we are > having some problems trying to access cameras outside of our local > network, we can see the video stream in the internet explorer (eg. > http://66.210.186.170/axis-cgi/axis-cgi/mjpg/video.cgi?resolution=320x240) but when we try to access that URL with cambozola viewer we get a "connection error timed out", We use a proxy server to connect to the outside, do we have to make some modifications in order for cambozola to use the proxy server too? > > > PS. We are still interested in buying some new or used axis 2100 > Thankful in advance > > Moses Marin > Andrew Sanz > > Computer Science > "Casa abierta al tiempo" > UAM-I >

37

Conversación con Juan David Luna, de Axis Mexico De: Juan David Luna <david.luna@axis.com.mx>

Enviado el: Jueves, 08 de Mayo de 2003 10:57:15 p.m.

Para: <marin_r_us@hotmail.com>

Asunto: RE: Informes Axis 2100

Estimado Moisés:

Que tal. El firmware de la cámara Axis 2100 no tiene la opción de detección de movimiento. Normalmente se hace por medio de una aplicación externa, o colocándole sensores físicos. Hace poco un desarrollador europeo saco una adición para las cámaras que nos permiten tener esta opción. No la hemos probado en México, pero en los laboratorios funcionó. Puede descargarla de:

Sensores de movimiento por software para la cámara AXIS 2100 http://www.gipro.de/download/sensor119.zip

Para las cámaras 2100 y 2110 (llenar formulario) http://www.seetec.de/eng/homepage_products/link_download.html

Espero que le funcionen, pero Axis no se responsabiliza de ello ya que es una aplicación desarrollada por terceros. Gracias.

Saludos, Juan David Luna Cruz AXISNet, S.A. de C.V. Soporte Técnico (+52) 52-73-84-74 Visite la página de Axis http://www.axis.com.mx en español.

-----Mensaje original----- De: ----------- ----------- [mailto:marin_r_us@hotmail.com] Enviado el: Jueves, 08 de Mayo de 2003 10:21 a.m. Para: soporte@axis.com.mx Asunto: Informes Axis 2100

Saludos ;

Estamos utilizando una camara axis 2100, y queremos incorporarle una aplicacion que detecte el movimiento, mi pregunta es: ¿Es posible agregarle está caracteristica a la camara mediante una actualizacion de su software interno, o esto debe hacerse en la aplicacion final?

Atte.

Moisés Marin.

Andres Flores

Lic en Computación

"Casa Abierta al Tiempo"

UAM Iztapalapa

38

Acerca de los autores

Moisés después de terminar sus estudios se volvió esclavo en la biblioteca de la UAM – I, donde voluntariamente acepto renunciar a sus fines de semana por una cantidad que se omite en este texto por temor a su seguridad. Actualmente radica en la biblioteca donde se le puede encontrar de 9am a 9 pm de Lunes a Domingo. A veces visita a su madre. Andrés, una vez concluida su tesis de licenciatura dedicó su tiempo a terminar la licenciatura. = | Ya con un nuevo corte de cabello para las últimas sesiones de la tesis, decidió dejar crecer el vello en otras áreas cutáneas para compensar la pérdida. Actualmente radica en Villacoapa donde pasa la mayor parte de su tiempo incrementando su ya en si gran colección de BangBus. Ambos continúan con buena salud, buen estado de ánimo y aun gozan recreando las conversaciones de cuando negociaron participar en este proyecto con el profesor Luis Martin.

39

Preguntas planteadas al Soporte Técnico de Axis y soluciones proporcionadas.

Support case no. 21461

Summary - Question Image buffer

Description - Details We are developping a motion detection applet that uses the PSNR algorithm but it works with uncompressed images, and so far we've only received jpeg images on the camera, my question is "Does the camera handles the uncompressed image at any point, or the camera receives the image after it has been compressed by hardware means?" We want to know where can we access the image before it is compressed.

Solution The image is compressed with a hardware JPEG compression chip on the board of the camera. Unfortunately, it is not possible to receive uncompressed images from the 2100 camera. Thanks.

Case Details Product family Camera Servers Product name Axis 2100 Problem area Question about configuration Submittance Date 2003-06-03

Support case no. 23131

Summary - Question Running an app in camera

Description - Details I installed the rpm distributionof the cris compiler cris-dist-1.25-1.i386.rpm and the developers board devboard-R1_1_0.tgz on my pc running SuSE 8.2, I got no errors when compiling the hello world example, i copied it via ftp to the camera and when i ran it in the camera via telnet i got the following message: /lib/libucc.a not found pid 318 killed (signal 9) Could this error be due to the version of the compiler that i used? I got the following errors at the end of the installation of devboard -R1_1_0.tgz flex boa_lexer.l bison -y -d boa_grammar.y boa_grammar.y:234.16: parse error, unexpected ":", expecting ";" or "|" make[2]: *** [y.tab.h] Error 1 make[2]: Leaving directory `/root/axis/devboard/apps/boa/src' make[1]: *** [install-recurse] Error 1 make[1]: Leaving directory `/root/axis/devboard/apps/boa' make: *** [install-recurse] Error 1 linux:~/axis/devboard # --- Solution commented Tue Jul 15 23:01:13 2003 --- Just for the record, I found in http://mhonarc.axis.se/dev-etrax/msg00990.html that : " The libs in your camera are optimized. You need to do static linking of your app. If you remove "-symbolic" or change it to "-static" in LDFLAGS in your Makefile (probably set in Rules.elinux) it should work."

40

I added "static" to the Makefile and it compiled and ran in the camera : ) (The boa_grammar.y needs a semi-colon ; in line 234) Greetings & Regards

Solution Unfortunatly custom application support is not available. Support options should be listed on developer.axis.com. Thank you.

Case Details Product family Camera Servers Product name Axis 2100 Problem area General Submittance Date 2003-07-09

Support case no. 27128

Summary - Question Changing JPEG Mode

Description - Details Can the JPEG mode of the Axis 2100 be changed to Progressive Mode? Greetings & Regards --- Solution commented Wed Oct 8 23:16:31 2003 --- I made a program based on the itu-t81, to find out in what mode the ARTPEC -1 JPEG COMPRESSION CHIP is coding the images , an image from the camera is coded in Baseline DCT Mode (xFFC0, symbol SOF0). How can the ARTPEC -1 JPEG COMPRESSION CHIP be changed to progressive coding? PS I attached the section of the hex dump that contains the jpeg compression mode.

Solution In providing JPEG images we follow the standards as much as it is compulsory. Changing on the level you are talking about is not something we can help with. For developer information there is a special site to go to: http://developer.axis.com/

Case Details Product family Camera Servers Product name Axis 2100 Problem area Question about configuration Submittance Date 2003-10-03

41

Support case no. 27385

Summary - Question Changing JPEG MODE

Description - Details I made a program based on the itu-t81, to find out in what mode the ARTPEC -1 JPEG COMPRESSION CHIP is coding the images , an image from the camera is coded in Baseline DCT Mode (xFFC0, symbol SOF0). How can the ARTPEC -1 JPEG COMPRESSION CHIP be changed to progressive coding? PS I attached the section of the hex dump that contains the jpeg compression mode.

Solution This is a duplicate incident and will be closed. Thanks.

Case Details Product family Camera Servers Product name AXIS 2100 Problem area General Submittance Date 2003-10-08

Support case no. 30047

Summary - Question Jpeg chip -restart markers

Description - Details Can the Jpeg compression chip emit restart markers?, Greetings

Solution No. that is not possible at this time. Perhaps at future firmware release.

Case Details Product family Camera Servers Product name Axis 2100 Problem area General Submittance Date 2003-11-29

42

SOCKETS

o Crear un socket

Un socket es una manera de comunicar procesos utilizando descriptores de archivos. Un descriptor de archivo es un entero asociado a un archivo, este puede ser una conexión de red, una terminal o cualquier otra cosa, ya que en Unix todos los dispositivos se consideran como archivos.

#include <sys/types.h> #include <sys/socket.h>

int socket (int dominio, int tipo, int protocolo);

dominio especifica un dominio de comunicaciones dentro del cual tendrá lugar la comunicación,

esto selecciona la fa milia de protocolo que deberá emplearse, estas familias están definidas en sys/socket.h

En este programa se utiliza del dominio AF_INET la familia de protocolos PF_INET, la cual utiliza TCP/IP v4 permitiendo al cliente y al servidor estar en cualquier lugar de internet.

tipo indica el tipo de socket a utilizar

Existen los siguientes tipos de sockets: - SOCK_STREAM

Define un servicio orientado a conexión confiable utilizando elprotocolo TCP, es decir; establece un circuito virtual entre el emisor y el receptor, de esta manera los mensajes viajan por el mismo camino y se preserva su orden.

-SOCK_DGRAM

Define un servicio no orienteado a conexión , no confiable utilizando el protocolo UDP. Los mensajes se envian de manera independiente, se pueden perder e incluso duplicar.

-SOCK_RAW

Permite a los programas accesar a los protocolos de bajo nivel o a las interfaces de red.

-SOCK_SEQPACKET

Provee un camino de transmisión, secuenciado, confiable, bidireccional, orientado a conexión para datagramas de tamaño fijo.

-SOCK_RDM

Provee una capa confiable para el envió de datagramas que no garantiza un orden de recepción.

En este programa se utilizan sockets del tipo SOCK_DGRAM.

protocolo es un conjunto de reglas que definen la forma en que deben efectuarse las comunicaciones en las redes. En net.c los sockets se crean mediante la función: int create_UDP (struct sockaddr_in *serv, char *address, int port) *serv contiene la información relacionada al servidor, tiene los siguientes campos:

43

struct sockaddr_in { short int sin_family; /* Familia de la Dirección */ unsigned short int sin_port; /* Puerto */ struct in_addr sin_addr; /* Dirección de Internet */ unsigned char sin_zero[8]; /* Del mismo tamaño que struct sockaddr */ }; *address contiene la dirección del servidor *port es el numero de puerto que se asociara con el socket creado. En esta función se crea el socket en la línea : fd = socket (PF_INET, SOCK_DGRAM, 17); Como se indica en /etc/protocols, el 17 se refiere a :

udp 17 UDP # user datagram protocol Una vez creado el socket se inicializa con 0 el área de memoria ocupada por serv mediante la instruction

memset (serv, sizeof (struct sockaddr_in),0); Y después se asignan los siguientes valores a los campos de serv: - se especifica el dominio de comunicaciones serv->sin_family = AF_INET; - si la función fue invocada por un servidor *address =NULL, por lo que se obtiene la dirección IP automáticamente serv->sin_addr.s_addr = htonl (INADDR_ANY); para después asociarla con un puerto local mediante bind,

bind (fd, (struct sockaddr *)serv, sizeof (struct sockaddr_in)); si se llama la función por el cliente calculadora se asigna a serv la IP del servidor,

serv->sin_addr.s_addr = inet_addr (address); - finalmente se asigna el puerto al campo correspondiente

serv->sin_port = htons (port); o Enviar un Mensaje Se utiliza el siguiente procedimiento para enviar un mensaje: void send_UDP (int fd, char *buff, int len, struct sockaddr_in *cli); Se envía el mensaje mediante la función: #include <sys/types.h> #include <sys/socket.h>

44

int sendto (int s, const void *msg, int len, unsigned int flags, const struct suckaddr *destino, int tolen); int s es el entero asociado al socket const void *msg es el mensaje a transmitir int len es el tamaño del mensaje a transmitir int flags bandera para condiciones const struct suckaddr *destino contiene la dirección del receptor int tolen indica el tamaño de la dirección del receptor Se invoca de la siguiente manera en el programa:

send_UDP (fdserv, buffer, strlen (buffer) + 1, &serv); Se regresa el número de caracteres enviados ó -1 si ha ocurrido un error. o Recibir un Mensaje Se utiliza la siguiente función para recibir un mensaje: int recv_UDP (int fd, struct sockaddr_in *cli, char *buff, int buf_len); Se recibe el mensaje mediante la función: #include <sys/types.h> #include <sys/socket.h> int recvfrom(int s, void *buf, int lon, unsigned int flags, struct sockaddr *desde, int *tamdesde); int s es el entero asociado al socket void *buf es donde se almacena el mensaje int len se inicializa con el tamaño de *buf flags bandera para condiciones struct sockaddr *desde información del emisor int *tamdesde un parámetro por referencia que se inicializa al tamaño del búfer

asociado con desde Se invoca de la siguiente manera en el programa:

recv_UDP (fdserv, NULL, buffer, ETHSIZE);