[Jde-dev] calculo de fondo

Lun Jul 12 18:25:50 CEST 2010

Hola,

En este mensaje discutíamos sobre el estilo con el que es deseable que
programemos nuestros algoritmos, al hilo de la implementación del cálculo de
fondo que redo hizo para su clasificador, aunque en general son extensibles
a cualquier tipo de código.

Hoy revisando la implementación para apañarla y hacerla más genérica, de
modo que podamos usar dichos algoritmos en otros proyectos, me he encontrado
con algunas otras cosas que no me gustan. Así, que para poder discutirlas
las indico.

Ya habíamos hablado de las variables globales, y sobre todo del uso que se
le dan: estado del algoritmo. Conclusión: la implementación no puede usarse
para calcular N fondos.

Otro caso de abuso que lleva a poca reutilización de código son las
variables static en funciones. De nuevo, nos llevan a que la implementación
no escala. La solución es igual de simple que antes, usar una variable que
guarde el estado del algoritmo y que cada función de nuestro algoritmo la
reciba como parámetro de entrada.

Tenemos que poner un poco mas de cuidado cuando programemos algoritmos, y
pensar que lo que hacemos podría ser reutilizado por otros, ahorrando mucho
tiempo y pudiendo hacer cosas más complejas.

¿Comentarios?

David.

2010/7/2 redouane kachach <redo.robot en gmail.com>

> BTW: GMM es la técnica más famoso para la actualización de fondo, si
> quieres echar un vistazo, tienes artículos que hablan del tema en:
>
> https://svn.jde.gsyc.es/users/redo/tfm/trunk/lecturas/gmm
>
> Por si tienes que pelear con los parámetros que usa el algoritmo.
>
> 2010/7/2 redouane kachach <redo.robot en gmail.com>
>
>> Ok, genial. En principio como te dije antes la GMM es una técnica más
>> "avanzada" que las que tenemos implementadas. Creo que tiene en cuanta casos
>> por ejemplo como árboles en el escenario (movimiento periódicos en la
>> escena). Así que si funciona bien mejor usarla.
>>
>> Por lo de re-enviar la conversación a la lista me parece buena idea :) ..
>> sobre todo lo de POO en C creo que estaría bien mandar algún ejemplo a la
>> lista. Vendría bien si alguien lo quiere utilizar.
>>
>> Saludos,
>> Redo.
>>
>>
>> 2010/7/2 David Lobato <dav.lobato en gmail.com>
>>
>>> Por el momento estamos probando los dos algoritmos que tiene opencv. Sin
>>> menospreciar tu trabajo, dado que ya están hechos y usamos opencv para todo,
>>> vamos a darle un intento.
>>>
>>> Vamos a empezar con el Mixture of Gaussians, que parece estar cerca de lo
>>> que tu has hecho. El primer intento que hemos hecho tiene muy buena pinta,
>>> aunque hay que ver que hace cada parámetro de los que tiene.
>>>
>>> Si vemos que opencv no hace lo que necesitamos, nos ponemos a apañar tu
>>> código, ok?
>>>
>>> David.
>>>
>>> PD: La conversación me parece muy interesante, os parece si la reenvío a
>>> la lista de desarrolladores de jderobot?
>>>
>>> 2010/7/2 redouane kachach <redo.robot en gmail.com>
>>>
>>>> Ya, eso es programar en C con el paradigma de POO, que es la mejor
>>>> opción como has dicho:
>>>>
>>>> En la cabecera ofreces un puntero a un struct opaco hacia fuera y
>>>> metodos para usarlo a los cuales tienes que pasar el puntero.
>>>>
>>>> En mi caso como solo me hacia falta un sólo fondo la verdad no he
>>>> planteado esta opción, aunque en realidad hubiese sido lo idóneo. Si ves que
>>>> te hace mucha falta que sea así podría invertir un poco de tiempo en
>>>> convertirlo.
>>>>
>>>> En todos los casos, yo creo que es mejor llevarlo a C++ que
>>>> seria todavía más rápido.
>>>>
>>>> Como lo ves?
>>>>
>>>> 2010/7/2 David Lobato <dav.lobato en gmail.com>
>>>>
>>>>> La opción realmente buena es meter todo lo relacionado con el estado
>>>>> del algoritmo en una estructura que se pasa a las funciones del API del
>>>>> algoritmo.
>>>>> Eso requiere darle un repaso completo a tu código, que no digo que sea
>>>>> difícil, pero implica un esfuerzo para entenderlo.
>>>>>
>>>>> Mira el API que usa opencv:
>>>>>
>>>>> bg_model = cvCreateFGDStatModel(image,0);
>>>>> ...
>>>>> cvUpdateBGStatModel(image,bg_model);
>>>>> ...
>>>>> cvReleaseBGStatModel( &bg_model );
>>>>>
>>>>> Todo va en bg_model. Si quiero tener X cámaras pues bg_model1,
>>>>> bg_model2,...
>>>>>
>>>>> 2010/7/2 redouane kachach <redo.robot en gmail.com>
>>>>>
>>>>>> Buena pregunta :-)
>>>>>>
>>>>>> Tal y como esta el modulo no se puede. Pero no por el hecho de que el
>>>>>> fondo sea una variable global, es porque el propio modulo internamente tiene
>>>>>> un solo fondo. De hecho lo de exportar el modulo hacia fuera como variable
>>>>>> global fui más bien para pintarlo no para usarlo. Si ves la cabecera, el
>>>>>> metodo que se usa para comprobar si un pixel de un frame se ha movido o no,
>>>>>> es:
>>>>>>
>>>>>> int movement_on_pixel(char* image, int pos);
>>>>>>
>>>>>> Si quieres usarlo para varias tienes que cambiar el modulo para
>>>>>> añadirle este soporte. En este caso como ya sabes tienes dos opciones:
>>>>>>
>>>>>> 1) Modificar el codigo C que ya existe para crear más de un fondo --
>>>>>> no creo que sea díficil pero requiere trabajo --
>>>>>> 2) Envolver el código existente en una clase C++  y luego instanciarla
>>>>>> cada vez que necesitas un fondo.
>>>>>>
>>>>>> Yo creo que la opción 2) es la mejor y la más rápida en tiempo.
>>>>>>
>>>>>> 2010/7/2 David Lobato <dav.lobato en gmail.com>
>>>>>>
>>>>>>> En ElderCare usamos N cámaras, como calculas el fondo de cada una con
>>>>>>> una variable global?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2010/7/2 redouane kachach <redo.robot en gmail.com>
>>>>>>>
>>>>>>> No creo que sea muy difícil de reutilizar :-)  -- aunque quizás lo
>>>>>>>> digo porque fui el creador --
>>>>>>>>
>>>>>>>> Si ves el header de background_model.h tienes los tres siguiente
>>>>>>>> metodos de actualizan el fondo. Como entrada reciben el fotograma
>>>>>>>> actual.  El mejor es el "update_background_mode_based"  que
>>>>>>>> actualiza el fondo basandose en la moda:
>>>>>>>>
>>>>>>>> int update_background_mean_based(char* input_image);
>>>>>>>> void update_background_mode_based(char* input_image);
>>>>>>>> int update_background_exp(char* input_image);
>>>>>>>> *
>>>>>>>> *
>>>>>>>> En cada momento puede acceder al fondo estimado que no deja de ser
>>>>>>>> una imagen y  que se exporta como variable global hacia el exterior:
>>>>>>>>
>>>>>>>> extern unsigned char
>>>>>>>> background_image[MY_SIFNTSC_ROWS*MY_SIFNTSC_COLUMNS*3];
>>>>>>>>
>>>>>>>> En serio, no creo que es tan difícil de reutilizar ..
>>>>>>>>
>>>>>>>> 2010/7/2 David Lobato <dav.lobato en gmail.com>
>>>>>>>>
>>>>>>>>> Estoy probando el otro método que implementan, que según la
>>>>>>>>> documentación que hay en cvaux.h parece ser mas potente. Voy a hacer un
>>>>>>>>> ejemplo y lo vemos.
>>>>>>>>>
>>>>>>>>> En cuanto a reutilizar el módulo que has hecho para carclassifier,
>>>>>>>>> me temo que no va a ser tan fácil de reutilizar. De nuevo se abusa de
>>>>>>>>> variables globales... Tenemos que salir de ahí de una vez por todas.
>>>>>>>>>
>>>>>>>>> David.
>>>>>>>>>
>>>>>>>>> 2010/7/1 redouane kachach <redo.robot en gmail.com>
>>>>>>>>>
>>>>>>>>> Hola David,
>>>>>>>>>>
>>>>>>>>>> Pues sin entrar en mucho detalles si de verdad implementan la GMM
>>>>>>>>>> (Gaussian Mixture Model) entonces deberia dar mejor resultados que el modelo
>>>>>>>>>> de background que tenemos en el clasificador. Yo creo que lo mejor es
>>>>>>>>>> intentar compilar un ejemplo y compraralo contra los resultados obtenidos
>>>>>>>>>> por el clasificador. El submodulo de background debe ser fácil de
>>>>>>>>>> reutilizar.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2010/7/1 David Lobato <dav.lobato en gmail.com>
>>>>>>>>>>
>>>>>>>>>> Buscando cosas en opencv he encontrado esto [1]. Cómo de cerca
>>>>>>>>>>> está de la solución implementada en el carclassifier?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> David.
>>>>>>>>>>>
>>>>>>>>>>> [1] http://opencv.willowgarage.com/wiki/VideoSurveillance
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100712/99fe2139/attachment.htm 