Pruebas del detector de coches

[jmbuena]

Se trata de:

• Probar a usar diferentes valores de nPerOct (menos imágenes entre cada dos octavas) y de árboles (no ejecutando todos los árboles que vienen en el clasificador).
• Ejecutar cada posible opción de implementación del detector en las imágenes de KITTI train (el 20% del final dado que el 80% inicial se usa para entrenar). Con las detecciones en disco se pueden generar las curvas para comparar diferentes opciones de implementación.
• El mejor detector (en cuanto a las diferentes opciones de implementación) en el 20% de train (validación) se prueba en KITTI test. Se suben las detecciones al servidor del benchmark de KITTI y vemos cómo queda.

[jmbuena]

En el caso de los coches de KITTI se trata de generar un script matlab parecido al de plot_paper_experiments_results.m para pintar la curva precision-recall original del paper junto con las curvas de diferentes opciones de ejecución de nuestra nueva implementación.

Para ello hay que:

• Procesar con cada detector (eligiendo una opción de implementación) las imágenes de KITTI training del grupo de validación: imagen 6733 a la 7480 (el 10% del final). Habrá que generar un fichero txt por cada imagen (p.ej. 006733.txt para la imagen 6733) con una detección por línea con el siguiente formato: Car -1 -1 -10 <x1> <y1> <x2> <y2> <score> <clase> -1 -1 -1 -1000 -1000 -1000 -10 <score>
• Bajarse el toolbox para procesar imágenes de KITTI y compilar lo que hay en el directorio kitti_cpp_evaluation_code. Para ello hacer cmake en el propio directorio y luego make.
• Después irse al directorio raíz del toolbox de KITTI y copiar el script plot_paper_experiments_results.m con otro nombre adecuado (plot_cpp_kitti_testing_results.m, por ejemplo). A continuación modificarlo para que use los directorios con ficheros .txt con las detecciones de nuestras ejecuciones. Habrá que añadir también un directorio con las detecciones del paper original de Badacost (esas las tengo yo).

[jorgevelap]

Ya he hecho el programa para poner el último 10% de las imagenes y que genere los .txt correspondientes.

He estado tratando de generar el script de matlab pero no lo consigo. Cada vez que lo trato de ejecutar me dice un error al cargar car_detection.txt , y no se que tipo de archivo se trata, cuando pongo uno con la estructura anterior me aparece un error que no reconoce el texto. No se si es por falta algún archivo además de estos nombrados (y detecciones de Badacost), ya que los archivos como SAMME_D_7_T_1024_N_5000_NA_20000 tampoco están en el repositorio.

No se si puedes ayudarme con esta parte.

Voy a ejecutarlo para subir una carpeta con los .txt obtenidos.

(Actualización) Carpeta en google drive con los .txt

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

Muchas gracias.

[jorgevelap]

Realizando pruebas modificando los parámetros del detector en distintas imágenes, cada nOctUp (+1) provoca que tarde 4 veces más en realizarse la detección. Bajar el número de nPerOct a la mitad hace que baje a la mitad el tiempo de ejecución, teniendo resultados muy similares. Esto ocurre con imágenes a varios tamaños de escala. Un ejemplo es el siguiente: La imagen es de 654 x 434 píxeles.

Imagen con parametros nOctUp = 1 , nPeroct = 10, nApprox = 9. Tiempo de ejecución = 4055.73 ms. Reduciendo nTrees (número de arboles) a la mitad, el resultado esta en torno a 3957ms, obteniendo resultados iguales(reduce el score).

Imagen con parametros nOctUp = 0 , nPeroct = 10, nApprox = 9. Tiempo de ejecución = 1183.2ms

Imagen con parametros nOctUp = 0 , nPeroct = 5, nApprox = 9. Tiempo de ejecución = 690.242ms

Realizando pruebas a distintas escalas, las proporciones entre los tiempos son iguales.

Una imagen 1242 x 375 píxeles con nOctUp = 1 ; nPerOct = 10 ; nApprox = 9, el tiempo es de 7154.51ms.

Una imagen 274 x 183 píxeles con nOctUp = 1 ; nPerOct = 10 ; nApprox = 9, el tiempo es de 733.724ms

[jmbuena]

Ya tenemos el código para generar las gráficas en matlab. Está en el directorio: matlab_files/kitti_plot_results_cpp

Para poder ejecutar el código tienes que:

• meterte en el directorio matlab_files/kitti_plot_results_cpp/kitti_cpp_evaluation_code/
• cmake .
• make (esto compila el programa de evaluación de KITTI).
• Salir al directorio matlab_files/kitti_plot_results_cpp desde Matlab.
• en matlab ejecutar el script: plot_results_cpp.m

Si queremos sacar la curva para el método "BAdaCost C++" en la gráfica pero que estará en el directorio BADACOST_CPP. En ese caso tienes que copiar todos los ficheros *.txt que tienes en el directorio matlab_files/kitti_plot_results_cpp/KITTI_CARS_DETECTION_EXPERIMENTS/BADACOST_CPP/LABELS_RESULTS/.

En cualquier caso, te conté mal el formato de las detecciones en el fichero txt. Este formato viene dado por el script writeKITTILabels.m y es el siguiente:

Car -1 -1 <alpha> <x1> <y1> <x2> <y2> -1 -1 -1 -1000 -1000 -1000 -10 <score>

Alpha es el ángulo de vista del objeto con respecto a la cámara. Se puede poner cualquier número para las curvas precisión/recall.

Sin embarto, alpha se puede calcular tal y como se hace en el script quantized2angleKITTI.m pasándole la clase - 1 estimada por el detector y el número de clases - 1 (quitándole la clase fondo). Es importante poder meter ese ángulo porque en KITTI también se estima y se compara la estimación del ángulo con otras curvas.

[jorgevelap]

Estoy intentando ejecutar el script de Matlab pero me sigue saliendo un error:

kitti_cpp_evaluation_code\evaluate_kitti_object KITTI_CARS_DETECTION_EXPERIMENTS\BADACOST_1_3_3_D_8_T_1024_N_7500_NA_30000 KITTI_TRAINING_DATA\CROSS_VAL_10_FOLD_SPLITS\fold_10_test_from_training\label_2 .\KITTI_CARS_DETECTION_EXPERIMENTS\BADACOST_1_3_3_D_8_T_1024_N_7500_NA_30000\LABELS_RESULTS 6733 7480 "kitti_cpp_evaluation_code\evaluate_kitti_object" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable. kitti_cpp_evaluation_code\evaluate_kitti_object KITTI_CARS_DETECTION_EXPERIMENTS\BADACOST_CPP KITTI_TRAINING_DATA\CROSS_VAL_10_FOLD_SPLITS\fold_10_test_from_training\label_2 .\KITTI_CARS_DETECTION_EXPERIMENTS\BADACOST_CPP\LABELS_RESULTS 6733 7480 "kitti_cpp_evaluation_code\evaluate_kitti_object" no se reconoce como un comando interno o externo, programa o archivo por lotes ejecutable. Error using load Unable to read file '.\results\KITTI_CARS_DETECTION_EXPERIMENTS\BADACOST_1_3_3_D_8_T_1024_N_7500_NA_30000\plot\car_detection.txt'. No such file or directory.

Error in plot_result_fig_kitti (line 78) curves = load(fullfile(KITTI_BENCH_OUTPUT_PATH, 'plot', 'car_detection.txt'));

Error in plot_results_cpp (line 23) plot_result_fig_kitti(PREPARED_DATA_PATH, OUTPUT_DATA_PATH, results_dirs, legend_text, fig_filename);

He compilado el programa de evaluación de KITTI. He modificado los archivos .txt para que tengan el mismo formato y los he puesto en la carpeta correspondiente, no se si me falta algun archivo o estoy haciendo algo mal en el proceso.

Muchas gracias.

[jorgevelap]

Estoy intentando realizar las modificaciones pero no lo consigo.

Desde Windows no puedo hacerlo, y lo estoy intentando desde un MAC con matlab pero me da también problemas. No tengo ningún PC con ubuntu y matlab. Voy a seguir a ver si consigo algo pero no lo veo muy claro.

He actualizado ya las etiquetas, aunque faltaría poner el ángulo del coche, como en ese valor se podía poner un int de momento he puesto la clase.

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

No se si puedes ayudarme con esto.

Gracias.

ACTUALIZACIÓN:

Desde una máquina virtual he lanzado Octave para ver si era capaz de ejecutarlo. Me sale este error: error: load: unable to find file ./results/KITTI_CARS_DETECTION_EXPERIMENTS/BADACOST_CPP/plot/car_detection.txt error: called from plot_result_fig_kitti at line 78 column 12 plot_results_cpp at line 23 column 1

Y me dibuja la siguiente gráfica:

Ahora si que me ejecuta los comandos unix ( he dejado sin hacer cmake . y make para que lo hiciera el script y ha salido correctamente)

Voy a seguir revisando a ver si encuentro el error.

[jorgevelap]

He seguido realizando pruebas y si pongo a la carpeta el nombre "BADACOST_CPP" es cuando da el error, si pongo otro nombre se obtienen unos resultados como la gráfica anterior previa de Easy results. No se si es que estoy añadiendo mal los archivos o algo pero no consigo detectar el error.

[jorgevelap]

He subido de nuevo una carpeta con las detecciones realizadas. En este caso tienen también el parámetro alpha:

Se ha utilizado la estrategia approxParallel:

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

[jmbuena]

Estos son los resultados con las detecciones que me has pasado con los canales aproximados y con varios threads:

Ahora mismo subo el script modificado para que lo veas.

Lo malo es que tenemos un resultado peor en C++ que en Matlab, con lo que la implementación no es equivalente del todo. Quizá habría que quitar "el arreglo" que hice al detector y ver si funciona igual.

[jorgevelap]

Acabo de subir la implementación también con allparallel, que ha tardado un rato en ejecutar y ha terminado hace 10 minutos

https://drive.google.com/drive/folders/1PmLfZTsJ0nPIKwj1y2cA-oIJeJnaRCUT?usp=sharing

Si me había fijado que había alguna detección distinta. Sino cuando este actualizado el script lo descargo y pruebo con la estrategia all a ver como funciona.

Muchas gracias.

[jorgevelap]

Acabo de ejecutar el código de github y me da el mismo problema, no se si estoy haciendo algo mal o hay algún parámetro a cambiar.

Me he descargado matlab para ubuntu y ejecutar en las mismas condiciones, y cuando ejecuto el código no me aparece el error, sin embargo las gráficas son las siguientes:

No se que puedo estar haciendo mal.

Siento las molestias.

[jmbuena]

Lo que te puede estar ocurriendo es que el ejecutable no funcione correctamente o que al cargar los resultados de fichero el script de matlab no lo haga correctamente. En ese caso lo que toca es depurar el script de Matlab y ver si la ejecución del .exe no da error así como que carga bien los datos.

[jmbuena]

El resultado de la siguiente curva es este:

No aproximar tiene un resultado un poco mejor que aproximar los canales (y el impacto en tiempo no es tan grande si se procesa en paralelo).

[jmbuena]

Mirando los resultados ... creo que estás ejecutando con la versión OpenCV de los canales (el gradHist todavía no funciona correctamente).

Mira en El ACF si el constructor toma "opencv" o "pdollar" por defecto. Si es "opencv" termina de hacer todos los experimentos de esa manera y luego cambias a "pdollar".

¡Lo malo es que en el último cambio que he hecho te lo he vuelto a poner a pdollar! Así que míralo antes de actualizar ahora tenemos un pequeño follón.

JM.

[jorgevelap]

Si, acabo de revisarlo y está en openCV, así que hago las pruebas de las dos formas, y lo dejo bien indicado.

Lo que me di cuenta es que en cuanto a resultados, las opciones "parallel" retornan los mismos resultados que las que no hacen paralelismo, lo que si hay es variación de tiempos.

Voy a realizar los cambios para obtener los datos de nuevo. Cuando he hecho otras pruebas a tardado en torno a 2 horas en ejecutar todas las imágenes. (nOctUp = 1).

[jorgevelap]

Ya he ejecutado la detección con "approxparallel" y ACF en pdollar.

https://drive.google.com/drive/folders/1VFJhLaxM2gjHY4zxVNod-WuF_zEKxLOa?usp=sharing

[jmbuena]

Tenemos más resultados:

A la vista de los resultados, la implemetación de canales P.Dollar sale mejor parada que la de OpenCV (sabemos que no está correcta del todo). Sin embargo no llega a la implementación en Matlab y eso no es razonable.

Hay que hacer tres cosas:

• Asegurarnos que la curva que pintamos como Matlab sea realmente la generada por el detector entrenado que estamos usando en C++. Eso voy a ver si puedo hacerlo yo.
• Comprobar con test que la parte de Non-Maximum-Supression que hay en C++ coincide con la salida de Matlab.
• También habrá que hacer los tests de squarify, issue #18, y resize, issue #19.

[jorgevelap]

Vale perfecto, me pongo ya con ello. Ahora mismo esta ejecutando todo con la estrategia "allparallel" para tener los resultados utilizando Pdollar y todos los cálculos.

Me pongo también a revisar las salidas con Matlab.

[jorgevelap]

Estoy realizando pruebas y en la ejecución de los tests, con el código que hay ahora en github me dice que me fallan 12, no se que puede estar pasando. Cambio la estrategia en gradMag, gradHist y ACF pero sigue fallando. Estoy buscando que puede estar pasando pero igual hay algo que esta afectando a los resultados finales.

[jmbuena]

No te preocupes por los test de momento. He metido los test de OpenCV para los canales y todas las de gradHist fallan de momento. Estoy intenando arreglarlo desde hace unos días.

[jorgevelap]

Vale, ya he arreglado lo que me estaba preocupando. He hecho unas pruebas y me salen unos resultados diferentes. Voy a comparar y hacer un ejemplo completo para poder ver los resultados.

Enlace allparallel con ACF opcion pdollar:

https://drive.google.com/drive/folders/1wW181-y0j4kCqhbCsZfZeCelWXNj1r1X?usp=sharing

He cambiado unas cosas del código que me podían estar llevando a error. Acabo de terminar de ejecutar allparallel, lo subo ya y estoy ejecutando en otra maquina aproxparallel de nuevo que he comparado y hay algún cambio en las detecciones.

[jorgevelap]

He realizado varias pruebas de Non-Maximum-Supressiony en las que he hecho si que retorna los mismos resultados. Las siguientes imagenes muestran un ejemplo la entrada y las salidas.

Ya actualizado también en github. Dos ejemplos que muestran que la salida es igual a la de matlab.

He vuelto a comprobar el resultado de squarify haciendo alguna prueba más y los resultados también parece que salen los mismos.

[jorgevelap]

Mientras realizaba las pruebas anteriores he dejado otra máquina corriendo para obtener resultados, habiendo cambiado todo a la estrategia PDollar, tanto ACF como gradMag y gradHist.

https://drive.google.com/drive/folders/1VFJhLaxM2gjHY4zxVNod-WuF_zEKxLOa?usp=sharing

[jorgevelap]

Ya he comentado la parte de badacost que cambia respecto a Matlab y lo estoy ejecutando con la estrategia aproxparallel a ver si mejora con respecto a lo que había.

Las líneas comentadas son: / // Otherwise we have a positive (object) class) double min_cost; double max_cost; int min_ind[2]; int max_ind[2]; cv::minMaxIdx(costs_vector.rowRange(1,m_num_classes), &min_cost, &max_cost, min_ind, max_ind, cv::Mat()); h = min_ind[0] + 2; // +1 because of 0 index, and +1 because of negative class is 1. // End of corrected code w.r.t. Matlab's implementatio /

[jorgevelap]

Se ha ejecutado con las líneas comentadas como se indica anteriormente, los resultados obtenidos están en:

Utilizando la estrategia aproxparallel: https://drive.google.com/drive/folders/1qmRnZ6vRCfOvVmG5GTFTrqAIpfh-0Zv3?usp=sharing

Utilizando la estrategia allparallel: https://drive.google.com/drive/folders/131UG-CDyu6j72MdWHFkcvJdG6kNZbqVp?usp=sharing

Utilizando la estrategia all: https://drive.google.com/drive/folders/1l41jT-TfjE8F3jZCJLSy5-ELz4t7gWGj?usp=sharing

Utilizando la estrategia aprox: https://drive.google.com/drive/folders/1qF1u0c1IoplCNPEXiihSQwzPSXJp-bEw?usp=sharing

[jmbuena]

No hacía falta hacerlas todas con el código comentado. Únicamente hace falta comparar la que debería de ser equivalente a la de Matlab: La de los canales aproximados y para que sea rápido la del cálculo en paralelo.

En cualquier caso, aunque este fin de semana hemos tenido que apagar la máquinas de la UPM por revisión eléctrica donde tengo el Matlab conseguí ver la gráfica antes. El comentar el código hace que sea mucho peor el resultado así que habrá que mirarlo con más detalle.

He estado mirando un poco lo que cargamos del detector entrenado en Matlab:

• No se si esta línea de código está bien o habría que tomar el valor de pChns.pColor.smooth de Matlab en lugar de dejarlo a 1. Si el valor es el mismo entonces no afecta en nada.
• Otra cosa que se me ocurre que puede ser diferente en la ejecución es que tengamos menos niveles en la pirámide entre cada dos octavas en la ejecución de ahora que lo que se hace en el detector de matlab. En cualquier caso tengo pendiente el ejecutar de nuevo el detector de Matlab para sacar su curva.

[jmbuena]

Por cierto, para las pruebas de tiempos deberías compilar el código en "Release" y no en "Debug". En una máquina bastante nueva eso me bajaba los tiempos un 30% dado que ya es código con optimización.

Yo uso QtCreator para compilar y es muy sencillo ese cambio dando a un botón. Si usas el cmake directamente hay que pasarle unos parámetros que no recuerdo ahora ...

JM

[jorgevelap]

He estado revisando lo que me has comentado. Por un lado configurandolo para la opción Release con cmake si que se nota un mejor rendimiento.

Por otro el smooth si que afecta. El valor de ese pChns.pColor.smooth del clasificador es 0 en lugar de 1. Haciendo diferentes pruebas, la imagen 6750 haciendo pruebas simples se ve la diferencia. Con las distintas estrategias no se detectaban coches o se detectaba 1. En este caso se detectan los dos coches.

Por último, al ver que con Release funcionaba más rápido, he probado a subir el valor de clfData.cascThr (está multiplicado por 0.1) y he visto que hay alguna variación también.

Ejecuciones realizadas con estos cambios:

Estrategia aproxparallel: https://drive.google.com/drive/folders/1vSpCmHKtTYpELL7ipaGbzCvBxcAxV6FT?usp=sharing

Estrategia allparallel: https://drive.google.com/drive/folders/1kTViMKcoMAmMiwKkOt8B3a5b4EOKsxHA?usp=sharing

[jorgevelap]

He estado trabajando en la generación de las curvas y al final ha salido. Los .txt de la carpeta CROSS_VAL_10_FOLD_SPLITS tenían un enlace a otros .txt. He cambiado esto por las etiquetas de KITTI.

Con el cambio del parámetro smooth , utilizando las estrategias allparallel y approxparallel se consiguen mejores resultados pero no se llega a la ejecución de Matlab. Ambas son la misma gráfica, una sin etiquetas para que se vea mejor la curva.

[jorgevelap]

He seguido haciendo pruebas con esto. En la siguiente prueba hecha, el valor de cascThr en lugar de multiplicarlo por 0.1 como estaba lo he multiplicado por 0.5. Los tiempos de ejecución con este valor son los mismos que se tenia sin la compilación en "Release". Los resultados han mejorado bastante. Las gráficas obtenidas son las siguientes:

[jorgevelap]

Para seguir con la prueba, he probado a utilizar el valor cascThr del detector. Es mucho mas lento, pero era para observar los resultados que se obtenían. En las gráficas 'Moderate' results and 'Hard' results los resultados obtenidos mejoran en algo a lo que retorna matlab.

[jmbuena]

Muy bien. Esto es otra cosa. Probablemente el detector que se utilicé en las pruebas de la revista se aplicó con el umbral de score predefinido sin multiplicarlo por ningún factor que lo hiciese más pequeño (lo que aumenta la velocidad de ejecución).

¿Estas pruebas las has hecho con el trozo de código de BadacostDetector comentado o sin comentar?

En cualquier caso parece que tenemos una implementación equivalente entre C++ y Matlab.

[jorgevelap]

Estas pruebas se han hecho con el trozo de código de BAdacostDetector sin comentar. Como comentaste que los resultados obtenidos habían sido peores descomenté esa parte y continué haciendo pruebas para ver la mejora.

El enlace con las ejecuciones es el siguiente:

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

El siguiente paso sería comparar resultados utilizando otra estrategia?

[jorgevelap]

Probando con la estrategia "approxparallel", los resultados salen un poco por debajo de los anteriores: Enlace con los resultados : https://drive.google.com/drive/folders/1s3np4kGMJEuJ60BoW5_OXoUILPjbXovo?usp=sharing