search

RoboticsLabURJC / 2017-tfm-jorge_vela

1 stars 2 forks source link

Pruebas del detector en caras #24

Open jmbuena opened 3 years ago

jmbuena commented 3 years ago

Se trata de:

jorgevelap commented 3 years ago

Acabo de hacer la prueba de coger el detector de caras con las funciones utilizadas de matlab a yml, también los filtros y utilizarlo en el programa de ejemplo. No he encontrado las imágenes de AFW , pero poniendo una de internet se obtienen buenos resultados:

El enlace que hay en el repositorio https://github.com/jmbuena/toolbox.badacost.faces.public para AFW me dice que no está disponible. Por otro lado, tampoco encuentro el script fddb2PiotrFormatMulticlass.m.

imagenCaras

Ha tardado en esta detección 1771.05ms .

Gracias.

jorgevelap commented 3 years ago

Realizando diversas pruebas con el filtro de caras, se obtienen los siguientes resultados:

Con una imagen de 630 x 409 píxeles:

Con nOctUp = 0 ; nPerOct =10 ; nApprox = 9; tiempo = 1713.16ms
0_0_10_9

Con nOctUp = 1 ; nPerOct =10 ; nApprox = 9; tiempo = 3950.93ms
0_1_10_9

Con nOctUp = 2 ; nPerOct =10 ; nApprox = 9; tiempo = 12910.9ms 0_2_10_9

Los tiempos en cuanto a parámetros y tamaños de imagen son muy similares a los obtenidos con KITTI para detección de coches. La diferencia, en este caso utilizar el número de árboles si muestra una diferencia, pues con los parámetros nOctUp = 0 ; nPerOct =10 ; nApprox = 9, el tiempo de ejecucion es de 1365.99ms.

jorgevelap commented 3 years ago

Utilizando una de las imágenes del toolbox de faces, de la carpeta Oxford_Street_London_Walk, las imágenes son muy grandes y el algoritmo tarda mucho en ejecutar.

Con los parámetros nOctUp = 1 ; nPerOct =10 ; nApprox = 9, tarda aproximadamente 11918.4ms . 1_1_10_9

Con los parámetros nOctUp = 0 ; nPerOct =10 ; nApprox = 9, tarda aproximadamente 3188.5ms 1_0_10_9

Además, subiendo el número de octavas en este caso se obtiene un peor resultado. .

jmbuena commented 3 years ago

El detector de caras está entrenado con caras de 80x80 píxeles si recuerdo bien, así que si quieres detectar caras de 40x40 es cuando tienes que subir una octava (nOctUp = 1) y doblar el tamaño de la imagen de entrada. Eso está claro que multiplica el número de píxeles x4 y por tanto hace que la extracción de canales se mucho más lenta.

Si uno descarta las detecciónes con score < 10 entonces tienes un muy buen resultado.

Una cosa que nos hace falta es tratar de trabajar con menos árboles (la T del dector de badacost) y ver qué pasa. Obviamente ejecutando menos árboles de los entrenados tendremos mayor velocidad de ejecución. Habrá que ver hasta que punto compromete el resutlado de la detección.

jorgevelap commented 3 years ago

Vale, lo de subir el valor de nOctUp era sobre todo para tener un valor real de tiempos, para tener el valor medido.

Realicé también la prueba de trabajar con menos nTrees, dividí el valor entre 2 y entre tres. Los resultados que se obtenían eran muy parecidos. Y en tiempos, con una imagen que tardaba 7.1 segundos paso a tardar 6.9 reduciendo los árboles a la mitad. No había una gran diferencia.

jorgevelap commented 3 years ago

Estaba trabajando en la detección de caras y me surgen las siguientes dudas:

La base de datos AFW no consigo encontrarla. El enlace https://www.ics.uci.edu/~xzhu/face/ me da error al intentar acceder. Voy a seguir buscando a ver si la encuentro en otro sitio.

He descargado la base de datos FDDB, por lo que he leído el formato para poder comparar debe ser:

, pero esto aparece en el README.txt del archivo con la base de datos, no se si es el mismo formato que necesitamos. Además, el formato de los ficheros es igual que para el detector de coches KITTI? Como esta base de datos la dividen por fechas (carpetas de año, dentro una para cada mes y dentro una por día) no se que formato es el necesario para guardar las detecciones. Muchas gracias.
jmbuena commented 3 years ago

Hola Jorge,

Yo tengo disponibles todas las bases de datos en las máquinas de la UPM.

jmbuena commented 3 years ago

Para los resultados de detección a probar sobre las caras hay que generar un único fichero con todas las detecciones de todas las imágenes de una base de datos. Hay algunos ejemplos en el directorio del repo de badacost para detectar caras.

Básicamente se trata de poner en cada fila del fichero una detección:

<nombre imagen> <score> <x1> <y1> <x2> <y2>

El nombre de la imagen va sin la extensión.

jorgevelap commented 3 years ago

Enlace con algunos resultados de las ejecuciones del detector. EL formato que he intentado seguir es el del ejemplo del enlace anterior, con el formato :

https://drive.google.com/drive/folders/1iWuqNElLHkueX7j_a39YcEH3qztBJOd3?usp=sharing

jorgevelap commented 3 years ago

Buenas tardes,

He estado realizando algunas de las pruebas con el detector de caras. Lo primero, estas detecciones se realizan para los scores mayores de 10 como me comentas previamente.

Por otro lado, he intentado seguir el formato del ejemplo anterior, que sería: 2007_000272 28.002000 161.150000 126.310000 238.282000 217.868000

Entendiendo que 2007 es la carpeta de la que proviene la imagen y 272 el nombre de la imagen.

Para hacer estas pruebas, del directorio fddb\FDDB-folds, leo el fichero FDDB-fold-01.txt (por ejemplo), que contiene una imagen por línea, realizo la detección y guardo las detecciones en el fichero de salida, teniendo el formato:

2002_00591 38.704826 179 78 355 287,

No se si es esta la forma que se buscaba. Por otro lado, solo tengo las carpetas que comienzan por 2002 - 2003, sin embargo en el ejemplo que me enviaste y mirando esas carpetas, comienzan por 2007, 2008, 2009 , 2010 y 2011, no se si los resultados con los que comparar están en algún otro sitio.

Gracias.

jorgevelap commented 3 years ago

Añado un video de una prueba de tiempo realizada. Esta es una prueba realizada, con imágenes de 640x380 y teniendo unos parámetros nOctUp = 0, nApprox = 0 y nPerOct = 1. Es un entorno casi ideal, se consigue trabajar a 18fps

https://user-images.githubusercontent.com/16937271/107254089-41865400-6a37-11eb-8051-38b7f817537f.mp4

jorgevelap commented 3 years ago

A continuación subo dos gráficas precision-recall con las imágenes AFW. En ella se compara badacost en c++ con otros algoritmos. Al realizar las pruebas me he confundido y he puesto que el score tuviera un valor mínimo (score mínimo 6 y 10). En cuanto tenga los nuevos resultados subo la gráfica de nuevo. En una gráfica lo he comparado solo con BAdaCost para que se apreciara mejor la diferencia. En el otro caso lo comparo el resto de resultados obtenidos. La estrategia utilizada ha sido approx_parallel con la implementación pdollar.

Precision-recall_afw

Precision-recall_afw_2

jmbuena commented 3 years ago

Bien. Esto marcha. En breve tienes cerrado el TFM.

jmbuena commented 3 years ago

Hay que añadir los detectores que estás usando en tests/yaml del repo para que yo pueda usarlos también.

jorgevelap commented 3 years ago

Buenas tardes, He ejecutado de nuevo las detecciones para distintas estrategias de AFW. He utilizado las estrategias "all" (con y sin paralelización) y comparando Pdollar y OpenCV. Los resultados obtenidos están un poco por debajo de los previos (BAdaCost en Matlab):

Comparativa_all

La grafica anterior se corresponde con AFW Final, la siguiente con todo AFW: comparativa_all_total

Voy a continuar trabajando en la obtención de estas curvas. De momento no he conseguido como trabajar con los resultados de la base de datos FDDB, estoy también con ello.

Gracias.

jorgevelap commented 3 years ago

Hay que añadir los detectores que estás usando en tests/yaml del repo para que yo pueda usarlos también.

Si tienes razón, perdón, voy a subirlos ya.

jmbuena commented 3 years ago

En cuanto a las curvas date cuenta de que los parámetros del detector se ajustaron sin importar la velocidad de ejecución.

Echa un vistazo a los parámetros en el script de entrenamiento. Los parámetros fundamentales son estos:

Comprueba a ver si estos parámetros tienen estos valores en el detector entrenado que usas. A ver si es este el problema.

JM.

jorgevelap commented 3 years ago

Acabo de comprobar y los parámetros fundamentales que tiene el detector con el que se ha probado son:

Para la siguiente prueba modifico los parámetros de entrenamiento a ver si se nota el cambio.

jmbuena commented 3 years ago

Otro parámetro que puede ser crítico es el opts.stride. Parece que en los experimentos del paper estaba a 4 px (los de cuanto se mueve la ventana en vertical y en horizontal).

Me da la impresión en el vídeo que hiciste que el stride era mucho más grande.

jorgevelap commented 3 years ago

He mirado y el valor de opts.stride es 4 también para este caso.

jorgevelap commented 3 years ago

Buenas tardes,

Subo una nueva gráfica con una detección realizada habiendo modificado el parámetro nOctUp. El resultado obtenido no ha mejorado con respecto al anterior. He tenido un problema y solo he podido obtener los datos utilizando la estrategia "all" de OpenCV. Sigo obteniendo resultados, de momento subo los resultados de esta curva, en la cual el resultado de Badacost all OpenCV params son los últimos obtenidos:

Precision-recall_afw_2_param

jorgevelap commented 3 years ago

Buenas tardes, He continuado con las pruebas durante el fin de semana. En las pruebas realizadas cambie valores de los parámetros, aunque estaban prácticamente todos igual que en el script de entrenamiento que pusiste en el enlace (y variar nOctUp llevó a peores resultados) .

Haciendo ejemplos y revisando el código, vi que en algunos casos se producía superposición en las detecciones de salida. He probado a variar el parámetro "overlap" de la función "nonMaximumSuppression" y en las primeras pruebas, aunque poco pero si mejora algo el resultado con respecto a lo anterior.

En cuanto tenga una curva final con este parámetro la subiré, pero quería preguntar si este cambio puede ser válido, ya que estoy reduciendo el valor de overlap (de 0.3 a 0.1 en esta prueba) y he visto que su valor por defecto (en scripts de matlab) lo indica como 0.5.

Gracias.

A continuación se muestra una de las gráficas obtenidas cambiando el valor de "overlap":

Precision-recall_afw_overlap

Actualización: He probado con los parámetros anteriores aumentando el valor de nOctUp, pero el resultado obtenido es peor que para el caso anterior (AP = 93.76).

Al subir el tamaño de nOctUp me da la impresión de que aparecen muchos falsos positivos, y por eso empeora el resultado.

jorgevelap commented 3 years ago

Buenas tardes, He continuado con la realización de estas pruebas y no consigo mejorar los resultados obtenidos en las gráficas previas. De momento el mejor resultado obtenido es con la estrategia "all parallel" y OpenCV cambiando el valor de overlap. Voy a darle alguna vuelta mas a ver si consigo encontrar algo que lo haga mejorar pero por el momento no lo estoy consiguiendo.