[Jde-dev] calculo de fondo

Mar Jul 13 16:31:54 CEST 2010

Hola a todos,

Estoy de acuerdo con David en que el uso de los static hace que el código
sea menos potable. Mi opinión al respecto del uso de variables static en
funciones es la siguiente:

Las variables *static* son para guardar estado interno. Estoy de acuerdo en
que no es una buena solución. Para guardar el estado generalmente hay
 varias formas que menciono en seguida de peor a mejor según mi forma
personal de ver las cosas:

1. Usar una variable global: es la peor manera, ya que añade más confusión
más todos los problemas conocidos relacionados con las variables globales.

2.  Usar una variable *static *dentro de la función que hace uso de este
"estado interno": mejor lo anterior ya que el ámbito de uso de la variable
es más reducido, el código es más legible, pero tiene el problema de que el
comportamiento de la función que llamamos no depende sólo de
sus parámetros de entrada sino también de variables "ocultas" que el usuario
de la función no ve y que podrían afectar al comportamiento/resultado de la
función.

3. Usar una variable que guarde el estado del algoritmo y que cada función
de nuestro algoritmo la reciba como parámetro
de entrada. Tiene la ventaja de que no hay que guardar nada internamente, el
comportamiento de las funciones sera determinado
únicamente con las variables que esta recibe. Esta solución es más limpia
que las dos anteriores, pero tiene la desventaja de dejar expuesto el estado
interior al exterior. Quiero decir el usuario tiene usar esta variable
aunque aveces no le hace falta saber detalles del estado, ni de como esta
almacenado.

4. Modelar las cosas usando POO. Para ello dependiendo del lenguaje que se
esta haciendo se hará de una manera o otro. Si se esta usando C la forma más
limpia es declarar un "struct" que almacena todo el estado interior del
objeto que queremos modelar,  declarar un puntero a este struct. Para
utilizar el "objeto/struct" el usuario tiene que llamar a la función que
maneja el objeto pasando el puntero hacia el objeto (obtenido con alguna
llamada tipo crear_objeto que devuelve este puntero). De esta manera desde
fuera sólo se ve el puntero al objeto, que es un tipo opaco para el usuario.
Este sólo ve los métodos para crearlo/manejarlo.

Si queréis más información sobre lo último podéis investigar un poco más
sobre POO en C. En el siguiente link se puede ver un ejemplo sencillo de
como hacerlo:

http://accu.informika.ru/acornsig/public/articles/oop_c.html

Saludos,
Redo.

2010/7/12 David Lobato <dav.lobato en gmail.com>

> 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/20100713/67b7ddb7/attachment-0001.htm 