[Jde-dev] calculo de fondo
Sara Marugan
smarugan en gsyc.es
Mar Jul 13 20:43:43 CEST 2010
Me parece bien lo que dice David. Creo que guardar el "estado" de los
algoritmos en variables globales era muy c�modo para el tipo de
programaci�n que ven�amos utilizando pero a la hora de reutilizar el
c�digo es un problema. La soluci�n, como ha comentado Redo, creo que es
acercarse m�s a la POO, que primero obliga a pensar el estado de los
objetos y despu�s los m�todos que operan con ellos.
Un saludo!
redouane kachach escribi�:
> 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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
> <mailto: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
>
>
>
>
>
>
>
>
>
>
>
>
>
More information about the Jde-developers
mailing list