[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 