[Jde-dev] calculo de fondo
David Lobato
dav.lobato en gmail.com
Mie Jul 14 09:26:46 CEST 2010
Hola,
Estoy de acuerdo con Redo en que la mejor solución es encapsular el estado,
ya sea con un objeto en C++ o un struct en C.
Sólo un último detalle. A la hora de programar nuestro algoritmo, debemos
tener en cuenta si tiene sentido que se ejecuten múltiples instancias de
manera concurrente. En este escenario, muy típico en las aplicaciones que
desarrollamos, la solución de variables globales o variables static no es
válida.
David.
2010/7/13 Sara Marugan <smarugan en gsyc.es>
> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: http://gsyc.escet.urjc.es/pipermail/jde-developers/attachments/20100714/9d46d82b/attachment-0001.htm
More information about the Jde-developers
mailing list