Tracking de objetos utilizando información de distractores

UNIVERSIDADE DE SANTIAGO DE COMPOSTELA ESCOLA T´ ECNICA SUPERIOR DE ENXE ˜ NAR´ IA Tracking de objetos utilizando informaci´on de distractores Autor: Manuel Benda˜na G´omez Tutores: Manuel Mucientes Molina Lorenzo Vaquero Otal Grao en Enxe˜nar´ıa Inform´atica Junio 2022 Trabajo de Fin de Grado presentado en la Escola T´ecnica Superior de Enxe˜nar´ıa de la Universidade de Santiago de Compostela para la obtenci´on del Grado en Ingenier´ıa Inform´atica D. Manuel Mucientes Molina, Profesor del Departamento de Electr´onica y Computaci´on de la Universidade de Santiago de Compostela, y D. Lorenzo Vaquero Otal, Investigador predoctoral en el Centro Singular de Investigaci´on en Tecnolox´ıas Intelixentes (CiTIUS), INFORMAN: Que la presente memoria, titulada Tracking de objetos utilizando informaci´on de distractores, presentada por D. Manuel Benda˜na G´omez para superar los cr´editos correspondientes al Trabajo de Fin de Grado de la titulaci´on de Grado en Ingenier´ıa Inform´atica, se realiz´o bajo nuestra direcci´on en el Departamento de Electr´onica y Computaci´on de la Universidade de Santiago de Compostela. Y para que as´ı conste a los efectos oportunos, expiden el presente informe en Santiago de Compostela, a 15 de junio de 2022: Tutor, Cotutor, Alumno, Manuel Mucientes Molina Lorenzo Vaquero Otal Manuel Benda˜na G´omez i ii Agradecimientos Para empezar, me gustar´ıa darle las gracias a mi familia, que ha estado siempre a mi lado apoy´andome en todo lo que he hecho, y aguant´andome, que s´e que a veces no es f´acil. C´omo no, a los que est´an m´as cerca: mi madre Lourdes, mi padre Manuel y mi hermana Sonia. Me gustar´ıa tambi´en recordar aqu´ı a los que por desgracia, durante estos a˜nos de carrera, nos han dejado: muy especialmente a mis t´ıos Azu yTito, a los que les tengo un cari˜no enorme y siempre los llevar´e conmigo. Por supuesto, quiero agradecerle al CiTIUS las facilidades proporcionadas para realizar el TFG, como el acceso a los servidores de computaci´on, y a mis tutores del TFG toda la ayuda prestada durante todos estos meses: a Manuel Mucientes, al que debo agradecerle tambi´en la oportunidad que me dio, y a Lorenzo Vaquero, que ha tenido que aguantarme muchas veces para intentar resolver los problemas que aparec´ıan. Mencionar adem´as a Daniel Cores, que me estuvo ayudando en los ´ultimos d´ıas con problemas que tuve en los servidores. ¡Muchas gracias a todos! Para terminar, dedicar tambi´en unas palabras a mis compa˜neros y amigos, tanto a los que tengo desde antes de comenzar la carrera, como a todos los que conoc´ı durante estos cuatro a˜nos. Mencionar de manera especial, a Andr´e, con el que llevo coincidiendo ya much´ısimos a˜nos (y espero que muchos m´as), a Ainhoa, que siempre me ha estado apoyando y ayudando en muchos momentos dif´ıciles, a Mart´ın, a Miguel, a Pablo, a los monkos, y a mis amigos de siempre, gracias por estar ah´ı y por hacer estos a˜nos m´as amenos y divertidos. iii iv Resumen El problema del seguimiento de m´ultiples objetos en v´ıdeo supone un desaf´ıo hoy en d´ıa para el cual no dejan de aparecer numerosas propuestas de soluciones. Estos sistemas normalmente est´an formados por tres elementos: un detector, un tracker y un algoritmo de asociaci´on de datos que combina la informaci´on de los dos primeros. En este trabajo, se estudia la viabilidad de emplear, como tracker dentro de un sistema MOT, el sistema de seguimiento de un objeto en v´ıdeo SiamRPN++, para el cual se analiza c´omo influye la presencia de objetos cercanos al de inter´es que puedan actuar de distractores y confundir al sistema. Se ha observado que, en la mayor parte de casos, cuando hay un distractor muy cercano, el sistema tiende a producir predicciones err´oneas. As´ı, en este trabajo se proponen diversas mejoras para ayudar a resolver ese problema. Dichas mejoras pasan por integrar la informaci´on de dichos distractores en el algoritmo de seguimiento tratando de combinarlos en tiempo de inferencia o modificando la arquitectura de la red, lo que requiere de entrenar las partes modificadas. Los experimentos nos muestran que esta ´ultima alternativa nos permite mejorar en general los resultados con diferentes propuestas. v vi ´ Indice general 1. Introducci´on 1 1.1. Descripci´on del problema . . . . . . . . . . . . . . . . . . . . . . 1 1.2. Hip´otesis a probar . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Objetivos ............................... 3 1.4. Organizaci´on de la memoria . . . . . . . . . . . . . . . . . . . . . 4 2. Estado del conocimiento del problema 5 2.1. ElproblemadelMOT ........................ 5 2.1.1. Descripci´on .......................... 5 2.1.2. Sistemas MOT destacados . . . . . . . . . . . . . . . . . . 6 2.2. ElproblemadelSOT......................... 7 2.2.1. Descripci´on .......................... 7 2.2.2. Sistemas SOT destacados . . . . . . . . . . . . . . . . . . 8 3. Materiales 11 3.1. pySOT................................. 11 3.2. CUDA................................. 11 3.3. Servidores de computaci´on GPGPU . . . . . . . . . . . . . . . . . 12 3.4. Lenguaje de programaci´on . . . . . . . . . . . . . . . . . . . . . . 12 3.5. Docker................................. 13 3.6. Conda ................................. 13 3.7. Herramientas adicionales . . . . . . . . . . . . . . . . . . . . . . . 14 4. Metodolog´ıa 15 4.1. SiamRPN++ ............................. 15 4.1.1. Visi´on general de la arquitectura . . . . . . . . . . . . . . 15 4.1.2. Extractor de caracter´ısticas . . . . . . . . . . . . . . . . . 16 4.1.3. RPNsiamesa ......................... 17 4.2. Mejoras propuestas sobre SiamRPN++ . . . . . . . . . . . . . . . 20 4.2.1. Primera aproximaci´on: combinar mapas de calor de clasificaci´on durante las pruebas . . . . . . . . . . . . . . . . . 21 4.2.2. Segunda aproximaci´on: or´aculo a partir de las anotaciones 24 4.2.3. Tercera aproximaci´on: modificaci´on de la arquitectura . . 26 vii 2CAP´ ITULO 1. INTRODUCCI ´ ON desaf´ıos, destacando los del MOTChallenge, siendo el ´ultimo el propuesto en 2020 [6]. Dichos desaf´ıos suelen presentar elevada complejidad, dado que la identificaci´on del objeto en una escena puede verse limitada por la presencia de distractores que confundan al sistema. Por ejemplo, una escena de inter´es puede ser la de la figura 1.1, donde hay grandes grupos de personas (cada una con sus caracter´ısticas), desplaz´andose en direcciones diferentes. Figura 1.1: Fotograma de uno de los v´ıdeos del MOTChallenge de 2020. Cada rect´angulo representa a uno de los objetos que se deben detectar, acompa˜nado de una etiqueta identificativa. Son muchas las propuestas realizadas para la resoluci´on del problema del MOT, intentando mejorar las prestaciones del resto en relaci´on a una serie de m´etricas, aunque siempre existen limitaciones y posibles mejoras a aplicar, ya sea a nivel de rendimiento o de resultados. Estos sistemas suelen presentar una estructura b´asica similar a la de la figura 1.2. Figura 1.2: Estructura b´asica de un sistema dise˜nado para resolver el problema del MOT. 1.2. HIP ´ OTESIS A PROBAR 3 En dicha figura se puede observar que a la entrada se tiene la informaci´on de un fotograma Fpara el instante t+ 1 y la predicci´on realizada en el instante anterior Pt. Con ello, por un lado, se ejecuta un detector y por otro un sistema de seguimiento o tracker, cuyos resultados dettytrtse combinan mediante t´ecnicas de asociaci´on de datos, que llevan a obtener unas predicciones en forma de objetos y trayectorias asociadas a los mismos. Este trabajo se va a centrar en la parte del tracker, donde una opci´on muy habitual es tomar como referencia un sistema dise˜nado para resolver el problema del seguimiento de un ´unico objeto o SOT (que viene del ingl´es Single Object Tracking), e instanciarlo m´ultiples veces, una por cada objeto de inter´es. As´ı, se partir´a del sistema SOT SiamRPN++ [7], tratando de analizarlo y mejorarlo para un buen funcionamiento integrado en un sistema MOT, para lo que se usar´an como referencia desaf´ıos de este ´ultimo problema. 1.2. Hip´otesis a probar Se plantean las siguientes hip´otesis que son las que se quieren probar con la realizaci´on de este trabajo: H1: La ejecuci´on del sistema SiamRPN++ sobre conjuntos de datos preparados para desaf´ıos MOT ofrece resultados mejorables debido a la presencia de distractores cercanos a los objetos que se desean seguir. H2: Al incluir la informaci´on de otros objetos en SiamRPN++, se contribuye a realizar un mejor seguimiento del objeto, evitando perder precisi´on o reduciendo el n´umero de p´erdidas. 1.3. Objetivos De forma gen´erica, se plante´o desde el comienzo de este Trabajo de Fin de Grado como objetivo fundamental el estudio de sistemas para tratar de resolver el problema del seguimiento de m´ultiples objetos en un v´ıdeo, plante´andose para ello una evaluaci´on inicial de diferentes alternativas para seleccionar el sistema a usar como referencia, un an´alisis del sistema seleccionado para identificar problemas y ´areas de mejora y la introducci´on de esas mejoras mediante la modificaci´on del c´odigo. Adicionalmente, se han propuesto los siguientes subobjetivos u objetivos espec´ıficos: Obj. 1: Estudio de los desaf´ıos MOT y SOT, y los sistemas m´as destacados. Obj. 2: An´alisis detallado de SiamRPN++ y sus antecesores para comprender su estructura y funcionamiento. 4CAP´ ITULO 1. INTRODUCCI ´ ON Obj. 3: Dise˜no de posibles mejoras para SiamRPN++, prestando atenci´on a la influencia de los distractores. Obj. 4: Implementaci´on de las mejoras sobre SiamRPN++. Obj. 5: An´alisis comparativo de los resultados obtenidos antes y despu´es de las mejoras, y extracci´on de conclusiones. 1.4. Organizaci´on de la memoria Este Trabajo de Fin de Grado se puede ubicar dentro del Tipo A seg´un el Regulamento do Traballo de Fin de Grao del Grado en Ingenier´ıa Inform´atica por la USC, en su ´ultima modificaci´on aprobada por la Xunta de Escola de la ETSE en Febrero de 2022. Es decir, se desarrolla una idea de un sistema inform´atico buscando contribuir a las t´ecnicas de la inform´atica existentes, en este caso en el campo del seguimiento de objetos. De este modo, la estructura de cap´ıtulos que se podr´a encontrar a partir de esta introducci´on que supone el Cap´ıtulo 1 es la siguiente: El Cap´ıtulo 2 se centra en mostrar el estado del conocimiento del problema, es decir, se presentan con mayor detalle los problemas abordados y las soluciones existentes a d´ıa de hoy. En el Cap´ıtulo 3 se presentan los materiales empleados para desarrollar este trabajo. En el Cap´ıtulo 4 se dar´an m´as detalles acerca del sistema SiamRPN++ y de las diferentes mejoras propuestas. El Cap´ıtulo 5 incluye las pruebas realizadas: en primer lugar se presenta c´omo se realizan (m´etricas y conjuntos de datos usados), y en segundo lugar se incluyen los resultados obtenidos. El Cap´ıtulo 6 refleja una discusi´on acerca de los resultados que se han obtenido en las pruebas. El Cap´ıtulo 7 sirve para resumir lo que se ha conseguido en este trabajo y proponer v´ıas de mejora o posibles ampliaciones a partir del mismo. Anexo a esta memoria, se entregan dos ap´endices: el Ap´endice A con el manual t´ecnico, y el Ap´endice B con el manual de usuario. Estos incluir´an la informaci´on necesaria para replicar los experimentos. Cap´ıtulo 2 Estado del conocimiento del problema 2.1. El problema del MOT 2.1.1. Descripci´on Uno de los problemas en los que se est´an realizando grandes esfuerzos dentro de la visi´on por computador es el seguimiento de m´ultiples objetos. La idea del problema es, dado un v´ıdeo conformado por una secuencia de fotogramas, identificar a todos los objetos que se encuentran en dicho v´ıdeo y conservar su identidad a lo largo del tiempo, de manera que se definen trayectorias asociadas a cada uno de ellos [6]. Evidentemente, este problema viene acompa˜nado de una gran cantidad de dificultades que, al mismo tiempo, lo convierten en atractivo de resolver: Hay varios factores que pueden dificultar la mera identificaci´on de un objeto: desde el punto de vista desde el cual se muestra, posibles deformaciones,oclusiones parciales o totales, hasta la poca diferencia entre el objeto y el fondo de la imagen. Tambi´en cabe se˜nalar la influencia de la iluminaci´on de las escenas en la definici´on de los objetos [8]. Tambi´en puede producirse un cambio de identidad, esto es, que se asocie un objeto a una trayectoria correctamente hasta un fotograma y que a partir de dicho fotograma se empiece a asociar el mismo objeto a una trayectoria diferente [6]. Este cambio de identidad puede darse cuando dos objetos similares se encuentran demasiado cerca, o si ambos se cruzan [9]. Los cambios de direcci´on abruptos que se pueden producir en un objeto en movimiento (por ejemplo, que se d´e la vuelta) [9]. A lo largo de los ´ultimos a˜nos se han propuesto diferentes desaf´ıos para tratar de resolverlo. Normalmente, dichos desaf´ıos ofrecen un conjunto de datos, el cual 5 6CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA suele componerse de escenas especialmente complejas, y una serie de m´etricas con las cuales medir las prestaciones de los sistemas presentados para resolver el problema. Uno de los desaf´ıos m´as conocidos, que es el que se toma como referencia, es el MOTChallenge, que se centra adem´as en el seguimiento de m´ultiples personas. El ´ultimo desaf´ıo que se propuso fue el MOTChallenge de 2020, con un conjunto de datos cuya caracter´ıstica esencial es la presencia de escenas muy concurridas de gente [6]. 2.1.2. Sistemas MOT destacados Hay una gran cantidad de propuestas realizadas en lo que respecta a sistemas MOT que se prueban en los conjuntos de datos de los diferentes desaf´ıos disponibles. Por ejemplo, desde el sitio oficial del MOTChallenge, es posible consultar tablas con los nombres de los sistemas que mejores resultados obtienen en las diferentes m´etricas para el desaf´ıo de 2020 [10], as´ı como de a˜nos anteriores. SiamMOT SiamMOT [11] es un sistema MOT caracterizado por tener una red siamesa basada en regiones, inspirada en sistemas de seguimiento de un ´unico objeto. Las redes siamesas se caracterizan por tener varias redes id´enticas en su interior, de manera que se colocan diferentes entradas en cada una de esas subredes (en este caso, recortes de un fotograma del v´ıdeo), se computan los resultados para cada entrada, y luego se combinan mediante alguna operaci´on [12]. Este sistema incluye un detector de objetos Faster-RCNN [13], caracterizado por disponer de dos m´odulos: Una red de propuestas de regiones (conocida habitualmente por RPN, por el ingl´es Region Proposal Network), cuyo prop´osito es, a partir de una imagen de entrada, devolver una serie de propuestas para los objetos en forma de rect´angulos delimitadores, cada uno con una puntuaci´on asociada. Una red de detecci´on basada en regiones, que usa las propuestas de la RPN as´ı como las im´agenes de entrada para devolver un ´unico rect´angulo delimitador y una categor´ıa asociada a cada objeto. Adem´as del detector, en SiamMOT se proporciona un modelo de movimiento consistente en la asociaci´on de una instancia del objeto identificada en el fotograma del instante t, con la instancia en el fotograma del instante t+δ, utilizando como referencia una regi´on alrededor de su ubicaci´on en el fotograma del instante t. Se proponen dos modelos [11]: Uno impl´ıcito, caracterizado por estimar el movimiento mediante un perceptr´on multicapa. 2.2. EL PROBLEMA DEL SOT 7 Uno expl´ıcito, basado en los sistemas SOT, debido al uso de un operador de correlaci´on cruzada entre el mapa de b´usqueda en el instante t+δy el mapa de caracter´ısticas del instante t. Aqu´ı es donde se emplea la red siamesa. Los resultados mostrados en el art´ıculo de SiamMOT indican que resulta mejor el modelo expl´ıcito frente al impl´ıcito. As´ı mismo, se refleja que este sistema MOT proporciona resultados del estado del arte. ByteTrack Otro sistema MOT del cual se consult´o informaci´on fue ByteTrack [14], el cual tiene como principal caracter´ıstica el uso de un mecanismo de asociaci´on, que recibe el nombre de BYTE, y que tiene en cuenta no solo las detecciones que ofrecen mejores puntuaciones de confianza, sino tambi´en aquellas cuya confianza resulta baja. Adem´as de lo anterior, cabe destacar que el sistema emplea YOLOX [15], un detector de la familia YOLO que posee un gran rendimiento. En la publicaci´on de ByteTrack se muestra c´omo logra buenos resultados en los desaf´ıos del MOTChallenge tanto de 2017 como de 2020. 2.2. El problema del SOT 2.2.1. Descripci´on Un problema diferente al que tambi´en se le hace frente dentro del seguimiento de objetos es al SOT. Este consiste en el seguimiento de un ´unico objeto de inter´es a lo largo de los diferentes fotogramas de un v´ıdeo [11]. Para ello, es habitual especificar su posici´on en el primer fotograma como punto de partida. Muchas de las dificultades mencionadas antes para el problema del MOT se pueden extender a este caso. En particular, es posible perder la trayectoria del objeto de inter´es, para lo que puede ocurrir un cambio de identidad al estilo del caso mencionado en MOT, solo que en esta situaci´on simplemente se empieza a seguir un objeto diferente que no interesaba seguir. Tambi´en puede suceder que simplemente el sistema se confunda con el fondo del fotograma. As´ı mismo, los cambios de direcci´on y problemas como las deformaciones, las oclusiones y la iluminaci´on, pueden volver a afectar en este caso, incluso la inicializaci´on del objeto (es decir, la posici´on indicada en el primer fotograma) que puede no ser la apropiada. En relaci´on a este problema se han propuesto numerosos desaf´ıos. Una de las iniciativas a destacar es la del VOTChallenge (del ingl´es Visual Object Tracking Challenge), con la cual se establecen conjuntos de datos y una serie de m´etricas para resolver diferentes desaf´ıos [16]. As´ı mismo, se ofrece una plataforma en 8CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA la cual se dispone de documentaci´on relativa a los desaf´ıos y los resultados de aquellos algoritmos que han participado en las competiciones [17]. 2.2.2. Sistemas SOT destacados Se han propuesto numerosos sistemas que intentan obtener los mejores resultados posibles en los diferentes desaf´ıos existentes. Se presentan a continuaci´on algunos que tienen alguna relaci´on con el sistema SiamRPN++ (la referencia de este trabajo), al aplicarse algunas de sus ideas. SiamFC SiamFC [18] es un sistema SOT caracterizado por el uso de una arquitectura convolucional siamesa, cuya idea principal se refleja en la figura 2.1. Figura 2.1: Arquitectura de SiamFC [18]. El ejemplar y el candidato, as´ı como el resto de mapas que aparecen en la figura, vienen acompa˜nados de la resoluci´on que poseen, expresada en la forma ancho ×alto ×num canales. Dicha arquitectura se caracteriza por el uso de dos im´agenes: un ejemplar zy un candidato xque, tras la aplicaci´on de una serie de operaciones (id´enticas para ambos, de ah´ı que la red se defina como siamesa) para realizar la extracci´on de caracter´ısticas, se combinan mediante una capa de correlaci´on. El resultado obtenido es un mapa de calor, que permite determinar la probabilidad de que el ejemplar se encuentre en cada una de las posiciones posibles dentro de la imagen candidata. La idea de la correlaci´on propuesta para este sistema es en la que se inspira SiamMOT (ya presentado previamente) [11]. 2.2. EL PROBLEMA DEL SOT 9 SiamRPN SiamRPN [19] se puede considerar un punto intermedio entre SiamFC y SiamRPN++. Toma referencias del primero y sirvi´o de base para el segundo. Se muestra tambi´en para este caso la idea de arquitectura en la figura 2.2. Figura 2.2: Arquitectura de SiamRPN [19]. Se trata de un sistema que, partiendo de la arquitectura propuesta por SiamFC (al estilo de la figura 2.1), reemplaza la operaci´on de correlaci´on para la comparaci´on entre la imagen ejemplar y la candidata por una RPN con dos ramas: La primera conforma la rama de clasificaci´on: se toman a la entrada el ejemplar y el candidato, y se obtiene a la salida un mapa de calor que clasifica la probabilidad de que cada regi´on de la imagen pertenezca al objeto o al fondo. La salida de esta primera rama tendr´a por tanto 2·kcanales, siendo kel n´umero de plantillas (del ingl´es anchor, un hiperpar´ametro que define diferentes relaciones de aspecto y tama˜nos para las regiones en las que se dividir´a la imagen). La segunda conforma la rama de regresi´on: tambi´en tomar´a a la entrada el ejemplar y el candidato, para obtener a la salida un mapa de calor que permita ajustar el rect´angulo delimitador al objeto a seguir (x, y, ancho, alto). De este modo, la salida tendr´a 4 ·kcanales para ajustar cada dimensi´on. SiamRPN++ Finalmente, se comentan algunos detalles sobre el sistema que se toma como referencia para este trabajo, SiamRPN++ [7], y que est´a basado en ideas de los anteriores, SiamFC ySiamRPN. Principalmente, se hace referencia a las diferencias respecto a los otros sistemas presentados, si bien posteriormente se 10 CAP´ ITULO 2. ESTADO DEL CONOCIMIENTO DEL PROBLEMA entrar´a en detalles m´as concretos. Las diferencias se encuentran en los siguientes puntos: La capa convolucional para extracci´on de caracter´ısticas se modifica respecto a los sistemas anteriores. Estos usaban una arquitectura similar a la conocida como AlexNet [20], sin embargo, en este sistema se apuesta por el uso de una arquitectura ResNet [21], m´as reciente y avanzada. De dicha capa se extraen no uno, sino tres mapas de caracter´ısticas salidos de diferentes puntos de la red convolucional, que se usan como entradas posteriormente en la RPN. Adem´as, se propone el uso de convoluciones en profundidad (depthwise) para mejorar la operaci´on de correlaci´on realizada entre el ejemplar y el candidato dentro de las ramas de la RPN. Esta ser´a la referencia que se tome para la realizaci´on de los diferentes experimentos en los que se centra este trabajo. Cap´ıtulo 3 Materiales Para la realizaci´on de este trabajo se ha recurrido a m´ultiples utilidades que se ir´an detallando a lo largo de este cap´ıtulo. 3.1. pySOT El sistema SiamRPN++ presentado anteriormente se encuentra implementado en el software pySOT, disponible en GitHub [22]. Ha sido desarrollado por el Sense Time Video Intelligence Research Team con el prop´osito de dar cabida a diferentes sistemas. As´ı, pySOT funciona como una base para poder investigar sobre seguimiento de objetos [22], resultando de gran utilidad. El c´odigo disponible en ese repositorio de GitHub es el que se ha usado de base para poder implementar las modificaciones dise˜nadas, cambiando el c´odigo presente en algunos ficheros, as´ı como a˜nadiendo otros nuevos cuando fuese necesario. Adem´as, de la documentaci´on de ese repositorio se obtiene toda la informaci´on necesaria para la instalaci´on del sistema, as´ı como de su configuraci´on y las ejecuciones m´as b´asicas. 3.2. CUDA Como la realizaci´on de pruebas sobre pySOT puede suponer la ejecuci´on de evaluaciones y entrenamientos especialmente costosos, se recurre a CUDA [23], una plataforma de computaci´on paralela desarrollada por la compa˜n´ıa NVIDIA, con el prop´osito de realizar operaciones de prop´osito general en GPUs. De esta manera, gracias al uso de CUDA, las porciones de c´odigo que requieran de una computaci´on intensiva (como puede ser el entrenamiento de SiamRPN++), se pueden ejecutar en GPUs de forma paralela [23]. 11 18 CAP´ ITULO 4. METODOLOG´ IA Figura 4.3: Arquitectura de la rama de clasificaci´on de la RPN de SiamRPN++ [7]. Capas conv kernel yconv search El primer paso dentro de la rama de clasificaci´on consiste en aplicar un conjunto de operaciones diferentes para el ejemplar y el ´area de b´usqueda, bajo el nombre de conv kernel yconv search, respectivamente. La estructura de ambas es similar, y est´a formada por tres operaciones: Una convoluci´on bidimensional. El objetivo que tienen las convoluciones es extraer caracter´ısticas de las im´agenes, mediante la aplicaci´on de filtros de una determinada dimensi´on y con unos pesos asociados que se van multiplicando por los valores de la imagen de entrada. En este caso, se aplica un filtro de tama˜no 3 ×3 y paso 1×1 a la entrada, sin cambiar la profundidad de canales (es decir, siguen siendo 256). Una normalizaci´on por lotes, que consiste en una forma de regularizaci´on muy usada en las redes convolucionales al permitir mejorar el proceso de aprendizaje [49]. Una funci´on de activaci´on, habitual a la salida de una capa para transformar los resultados. En este caso, se emplea la unidad lineal rectificada, abreviada como ReLU por el ingl´es Rectified Linear Unit, y que devuelve el valor de entrada como salida siempre y cuando este sea positivo, en otro caso, directamente devolver´a un 0 [50]. Se ponen como capas separadas para ejemplar y b´usqueda dado que los pesos asociados a las mismas pueden variar, al tenerse entradas diferentes. Adem´as, las resoluciones de salida cambian en cada caso: El ejemplar, a la salida de conv kernel, tiene una resoluci´on de 5×5×256. Por su parte, la imagen de b´usqueda a la salida de conv search, tiene una resoluci´on de 29 ×29 ×256. 4.1. SIAMRPN++ 19 Esto viene causado por el filtro aplicado en la convoluci´on, que tiene resoluci´on 3×3 (ancho x alto), y se va aplicando sobre la entrada en todas las posiciones posibles. Esto, unido al hecho de que el salto es de una unidad siempre, lleva a que el resultado tenga dos unidades menos en ancho y en alto. La forma de aplicaci´on del filtro se puede observar en la figura 4.4, donde se pueden ver dos pasos para una entrada 7 ×7, filtro 3 ×3 y paso de 1. Figura 4.4: Proceso de aplicaci´on de un filtro 3 ×3 (en amarillo), con paso de 1, sobre un mapa de caracter´ısticas (en azul) de 7 ×7 en ancho y alto. Se obtiene (en rojo) un mapa resultante de dimensiones 5 ×5. Correlaci´on en profundidad Lo siguiente que se hace es una operaci´on de correlaci´on cruzada, para combinar la informaci´on de los dos mapas de caracter´ısticas salidos de las capas anteriores. La operaci´on que se propone en este sistema MOT para esta correlaci´on se llama DepthWise Cross Correlation, lo que se podr´ıa traducir como una correlaci´on cruzada en profundidad [7]. En ella se aplica la operaci´on de correlaci´on canal a canal. La idea es que los objetos de la misma categor´ıa pueden responder de la misma forma en los mismos canales, de forma que as´ı se consigue una asociaci´on de informaci´on m´as eficiente que permite reducir la memoria y el coste a nivel de computaci´on necesario [7]. Se puede consultar una descripci´on gr´afica de lo que se ha comentado en la figura 4.5. Figura 4.5: Proceso de correlaci´on cruzada en profundidad. Imagen obtenida de la figura 4c de [7] 20 CAP´ ITULO 4. METODOLOG´ IA Capa head Para terminar con la RPN, se ejecuta la llamada capa head, que se podr´ıa traducir como la cabecera de la red. Est´a conformada por varias operaciones diferentes: Una convoluci´on bidimensional, que no reduce el n´umero de canales (lo mantiene en 256), y aplica un filtro 1 ×1 con paso 1 ×1. Esto quiere decir que la salida sigue teniendo la misma resoluci´on, pero se combina la informaci´on de los canales. Una normalizaci´on por lotes. Una funci´on de activaci´on, una vez m´as, la funci´on ReLU. Finalmente, una nueva convoluci´on, pero que cambia el n´umero de canales de 256 a 2·k, aplic´andose un filtro 1 ×1 con paso 1 ×1. Conociendo las operaciones, se puede comprobar que en este caso la resoluci´on en lo que respecta a ancho y alto no var´ıa (sigue siendo 25 ×25, que fue lo que sali´o de la capa de correlaci´on cruzada en profundidad), sin embargo, cambia el n´umero de canales que, tras mezclar la informaci´on en una primera convoluci´on, pasa a 2 ·k. Diferencias entre la rama de clasificaci´on y la de regresi´on La rama de clasificaci´on y la de regresi´on de la RPN resultan realmente id´enticas en su estructura. Sin embargo, hay alguna diferencia que permite generar los resultados deseados en cada una de ellas. Esa diferencia se encuentra precisamente en la capa head, concretamente en la ´ultima operaci´on que se acaba de comentar: esa convoluci´on que pasa de 256 canales a 2 ·kpara clasificaci´on, pero que en la regresi´on se sustituye por una convoluci´on diferente que pasa de 256 a 4 ·k. Evidentemente, a la hora de entrenar la red, los pesos que se ir´an asociando a cada rama podr´an ser diferentes. En la figura 4.6 se muestra la estructura completa de la RPN, ya con las dos ramas, y con las diferencias en el tama˜no del resultado. 4.2. Mejoras propuestas sobre SiamRPN++ A continuaci´on, se detallan las mejoras sobre SiamRPN++, que se fueron dise˜nando e implementando usando una metodolog´ıa Scrum, la m´as apropiada al estar muchas veces condicionados por los resultados que se iban obteniendo. Lo que se quiere resolver en este trabajo es algo identificado como problem´atico al seguir objetos: la presencia de distractores que hacen que el sistema se 4.2. MEJORAS PROPUESTAS SOBRE SIAMRPN++ 21 Figura 4.6: Estructura completa de la RPN usada en SiamRPN++ [7], con la rama de clasificaci´on y regresi´on. confunda. Esto puede ocurrir, por ejemplo, cuando una persona se cruza con otra, y el sistema comienza a seguir a la otra. Tratando de ayudar en esos casos, se busca mejorar las prestaciones de la red. 4.2.1. Primera aproximaci´on: combinar mapas de calor de clasificaci´on durante las pruebas En el planteamiento de diferentes soluciones, la idea a priori m´as sencilla y directa, evitando realizar un entrenamiento diferente o una modificaci´on de la arquitectura, es modificar el c´odigo de inferencia (en el que se hace el seguimiento de objetos diferentes a los que se usaron en entrenamiento), tratando de incluir informaci´on relativa a los distractores. Como ya se indic´o, la red devuelve dos elementos: una clasificaci´on de los componentes de la imagen seg´un sean el objeto de inter´es o no, y una regresi´on para ajustar el rect´angulo delimitador del objeto a identificar. La clasificaci´on se puede considerar que devuelve un mapa de calor con la probabilidad de que el objeto se encuentre en una posici´on determinada. La primera propuesta de mejora se centra en actuar sobre esa parte, y se refleja en la figura 4.7. Esencialmente: 22 CAP´ ITULO 4. METODOLOG´ IA Figura 4.7: Propuesta de mejora sobre SiamRPN++ considerando la clasificaci´on otorgada a ejemplos negativos. El + hace referencia al ejemplo positivo, y −i, al ejemplo negativo i-´esimo. Se considera la clasificaci´on realizada para el objeto en seguimiento como el ejemplo positivo. Ese ejemplo positivo podr´ıa estar condicionado por la presencia de otros objetos, de manera que el mapa de calor correspondiente d´e alta probabilidad en las posiciones de ´estos (los distractores). El objetivo es penalizar esas posiciones para centrarse en el positivo. Para ello, se tiene en cuenta tambi´en la clasificaci´on sobre los N distractores m´as cercanos al objeto a seguir, de manera que se agreguen esos mapas de calor para intentar penalizar el mapa del ejemplo positivo en las posiciones que no corresponden con las del objeto de inter´es: se denominar´an ejemplos negativos. En la figura 4.8 se refleja la idea de considerar un ejemplo positivo y el resto negativos. 4.2. MEJORAS PROPUESTAS SOBRE SIAMRPN++ 23 Figura 4.8: Ejemplos de objetos marcados: en verde, se rodea el objeto de inter´es (ejemplo positivo), y en rojo, los distractores (ejemplos negativos). A la hora de agregar los mapas de calor, como se indica en la figura 4.7, hay un proceso al cual se ha llegado a partir de un an´alisis detallado del c´odigo disponible en [22], y dentro del cual hay alternativas que se pueden tomar en varios puntos: La primera parte aplicada a cada ejemplo (la ejecuci´on de SiamRPN++, etiquetada en la figura 4.7 como (1)) ya se ha comentado, conociendo por tanto el formato de las salidas. Adem´as, en el caso de las pruebas, se ejecutan una serie de operaciones adicionales: para cls, se aplica una funci´on convert score que, por un lado, convierte la profundidad de la resoluci´on de 2kak, y aplica un aplanamiento, de manera que nos queda un tensor de una ´unica dimensi´on con 25 ·25 ·kelementos. La realizaci´on de ese aplanamiento impide comprender correctamente los mapas de calor para cada una de las plantillas, de manera que es necesario transformar el resultado obtenido de convert score para que sea de nuevo multidimensional. Los ejemplos negativos pueden estar situados en diferentes posiciones del fotograma, que no tienen que corresponderse con las regiones asociadas al ejemplo positivo. Para interpretarlos correctamente, lo que se propone es colocar los mapas de calor correspondientes al recorte de cada ejemplo (sea positivo o negativo) sobre un mapa de calor que cubre la resoluci´on completa del fotograma (W×H). De ese modo, cada ejemplo negativo restar´a en la posici´on que realmente le corresponde dentro de la escena. As´ı es como se llega a tener un mapa de calor de tama˜no W×H×kpara cada ejemplo, que se etiqueta en la figura 4.7 como (2). Hecho todo lo anterior, primero se junta la informaci´on de los ejemplos negativos. Ello se puede hacer considerando el m´aximo o la media, por ejemplo. Con ello, se consigue un ejemplar ´unico negativo al que se le denomina cls−((3) en la figura 4.7). 24 CAP´ ITULO 4. METODOLOG´ IA Luego, se une la informaci´on del ejemplo positivo con la combinada de los negativos. Como la idea es penalizar los distractores del mapa positivo, la soluci´on m´as inmediata puede ser una resta, sin embargo, se puede ponderar por un valor el ejemplo positivo y por otro el negativo combinado, de manera que uno pese m´as que el otro. As´ı se llega al ejemplar identificado como (4). Para terminar, es necesario recuperar el formato apropiado del mapa de calor para poder continuar con las operaciones desde este punto. Para ello, hay que tener en cuenta que en convert score el resultado se hab´ıa aplanado a una dimensi´on, de manera que se aplica una transformaci´on equivalente, llegando al ejemplar (5) de la figura 4.7. Despu´es de las operaciones mostradas, se aplican una serie de penalizaciones seg´un la escala o la relaci´on de aspecto. Esas penalizaciones tambi´en se podr´ıan aplicar a los mapas de calor de ejemplos negativos antes de combinarlos. 4.2.2. Segunda aproximaci´on: or´aculo a partir de las anotaciones Se propone, a ra´ız de la prueba anterior, una alternativa ´util para conocer la eficacia de este tipo de aproximaciones. Se trata de directamente crear los mapas de calor de los ejemplos negativos, o ayudar en su definici´on, utilizando las anotaciones del conjunto de datos usado en inferencia (el or´aculo viene del ingl´es oracle y hace referencia al uso de esa informaci´on, que realmente no se deber´ıa conocer durante el test). Si con ello no se mejorase considerablemente, esta aproximaci´on no resultar´ıa de ayuda para el objetivo perseguido. Hay varias alternativas para crear el or´aculo, que se comentan seguidamente. Alternativa 1: creaci´on de mapas negativos Se puede considerar la posici´on de cada uno de los ejemplos negativos en cada uno de los fotogramas y crear un mapa de calor que tenga su punto m´as caliente alrededor del punto central del objeto (atendiendo a su rect´angulo). Tambi´en se pueden plantear distintas opciones: Colocar un rect´angulo que sea proporcional al rect´angulo delimitador, aunque en un ´area m´as peque˜na centrada en el punto medio del delimitador. Todo el rect´angulo tendr´ıa asociados los valores m´as altos posibles, dando alta probabilidad al objeto de situarse en esas posiciones. Colocar en todo el rect´angulo valores que sigan una funci´on gaussiana en dos dimensiones, siguiendo la f´ormula 4.1, tomada de [51]: f(x, y) = A·exp −(x−x0)2 2·σx +(y−y0)2 2·σy (4.1) 4.2. MEJORAS PROPUESTAS SOBRE SIAMRPN++ 25 En dicha funci´on, se toma como entrada el punto del rect´angulo (x, y) teniendo como origen la esquina superior izquierda. A partir de ah´ı: •Se define un valor Acomo la amplitud de la gaussiana. •(x0, y0) son las coordenadas del punto central, que es la referencia en la cual se establecer´an los valores m´as altos del mapa de calor. •(σx, σy) son la mitad del ancho y alto del rect´angulo, respectivamente. En ambos casos, la idea viene a ser la que se muestra en la figura 4.9, en la cual se reemplaza la ejecuci´on de SiamRPN++ para todos los negativos por un bloque de creaci´on de ese mapa de calor, el cual ya devolver´a directamente un mapa con el mismo formato obtenido en (2) a trav´es del ejemplo positivo (esto es, posicionado dentro de la imagen completa con ancho Wy alto H. Cabe se˜nalar tambi´en que las operaciones se repiten para completar las kplantillas definidas. Figura 4.9: Aplicaci´on del or´aculo generando directamente los mapas de calor negativos. Alternativa 2: recorte de los mapas negativos reales La otra opci´on planteada es aprovechar directamente los rect´angulos delimitadores de los ejemplos negativos y, una vez obtenido el mapa de calor negativo 26 CAP´ ITULO 4. METODOLOG´ IA como en la aproximaci´on del apartado 4.2.1, aplicar un recorte sobre el mismo, dejando ´unicamente valores no nulos en la parte encuadrada dentro del rect´angulo delimitador del objeto. As´ı, se intenta centrar el mapa de calor en el ejemplo negativo. La idea en cuesti´on a aplicar parte de la base de la figura 4.7, solo que ahora el mapa de calor que se obtiene en (2) se vuelve a modificar aplicando esta operaci´on de recorte que se ejemplifica en la figura 4.10, en la cual: En (1) se tiene un mapa de calor de un ejemplo negativo en una imagen aleatoria. En negro, se marca el rect´angulo delimitador de dicho ejemplo. La transformaci´on a aplicar permite llegar a (2), donde la ´unica parte del mapa de calor que se mantiene igual es la situada dentro del rect´angulo. Figura 4.10: Ejemplo de aplicaci´on de la transformaci´on del mapa de calor teniendo en cuenta el rect´angulo delimitador de un objeto. Los valores m´as altos se corresponden con los colores m´as c´alidos (rojo), mientras que los m´as bajos se asocian a los colores fr´ıos (azul). 4.2.3. Tercera aproximaci´on: modificaci´on de la arquitectura La propuesta m´as prometedora requiere modificar la arquitectura de SiamRPN++, y su idea de partida se refleja en la figura 4.11. Se busca que la propia red sea capaz de aprender las relaciones entre los distintos objetos en la escena. As´ı, los ejemplos negativos ser´an procesados en paralelo e influir´an en la predicci´on del positivo. Los negativos solamente se tendr´an en cuenta a nivel de ejemplares (es decir, el ´area de b´usqueda se extraer´a solamente para el ejemplo positivo, y el ejemplar para todos). Siguiendo el proceso de la figura 4.11, se tienen seleccionados Bejemplares y ´areas de b´usqueda positivos (B por el tama˜no de lote, ya descrito en el apartado 4.1.1). Esos Belementos se combinan en un ´unico tensor con cuatro dimensiones. 4.2. MEJORAS PROPUESTAS SOBRE SIAMRPN++ 27 Figura 4.11: Idea b´asica de la tercera aproximaci´on. Adem´as, se seleccionan aleatoriamente1N ejemplares negativos por cada positivo. Los ejemplos negativos se combinan junto al positivo por la dimensi´on del tama˜no del lote, de manera que la dimensi´on resulta en (N+1)B×7×7×256. Para todo ello ya se habr´a aplicado el extractor de caracter´ısticas. En la RPN seg´un la figura 4.11, para cada rama, se tienen todas las capas ya comentadas (lo que se denominar´a la parte base). La ´unica diferencia a priori est´a en la capa head, de la cual se quita la ´ultima operaci´on (de ah´ı que se denomine head 1). Una vez completadas esas capas, se a˜naden las modificaciones de la arquitectura (la parte nueva), donde se combinar´an los ejemplares. As´ı, se dejan las modificaciones para el final de la red, lo que permite dejar congelada la parte base durante el entrenamiento (es decir, no se modificar´an sus pesos, usando unos valores preentrenados). Esto permite acelerar los entrenamientos y conseguir antes resultados para ir extrayendo conclusiones. Un apunte sobre la correlaci´on en profundidad entre el ejemplar y el ´area de b´usqueda: al haber concatenado todos los ejemplos negativos con el positivo, la primera dimensi´on es diferente ((N+ 1)B×5×5×256 en el ejemplar y B×29 ×29 ×256 en el ´area de b´usqueda) y es necesario que sea igual. Para ello, se concatena consigo mismo el ´area de b´usqueda N+1 veces. 1S´olo al entrenar. En el test no se har´a as´ı: se tomar´an los m´as cercanos como en las otras aproximaciones. 34 CAP´ ITULO 5. PRUEBAS usar el conjunto de entrenamiento como conjunto de test. Los v´ıdeos presentes en este conjunto se muestran en la tabla 5.1. Nombre Resoluci´on N´umero de fotogramas Densidad MOT17-02 1920x1080 600 31.0 MOT17-04 1920x1080 1050 45.3 MOT17-05 640x480 837 8.3 MOT17-09 1920x1080 525 10.1 MOT17-10 1920x1080 654 19.6 MOT17-11 1920x1080 900 10.5 MOT17-13 1920x1080 750 15.5 Tabla 5.1: Descripci´on de los v´ıdeos disponibles en el conjunto de entrenamiento de MOT17 [55]. Se muestra la resoluci´on del v´ıdeo, la longitud en cuanto al n´umero de fotogramas y la densidad media de personas por fotograma. MOT2020 El conjunto de datos ofrecido como parte del desaf´ıo MOTChallenge del a˜no 2020 tiene ocho secuencias de v´ıdeo, a partir de tres escenas en las cuales hay una gran cantidad de personas (hasta 256 personas por fotograma). Tal y como ocurre en el conjunto de datos del MOTChallenge de 2017, se dispone de dos particiones, aunque no se usan todas las escenas en ambos: Un conjunto de entrenamiento, formado por cuatro v´ıdeos de dos de las tres escenas utilizadas en este desaf´ıo. Un conjunto de test, el cual tiene un v´ıdeo por cada una de las dos primeras escenas (que tambi´en forman parte del entrenamiento), y otros dos que se sit´uan en una escena completamente diferente, lo que se hace para evaluar la posibilidad de generalizaci´on de los sistemas. De nuevo, se vuelve a trabajar exclusivamente con el conjunto de entrenamien- to por el mismo motivo que en MOT17. Pero adem´as, con MOT20 tambi´en se quieren hacer entrenamientos, por lo que se hace algo habitual cuando se quieren hacer pruebas sin el conjunto de test, que es dividir el de entrenamiento en dos: una mitad de entrenamiento y otra de test. Se muestran detalles del conjunto completo que se emple´o en la tabla 5.2. Se puede observar el aumento en la densidad de personas comentado previamente: el v´ıdeo de MOT17 que m´as densidad presenta por fotograma es MOT17- 04 con 45.3, que es superado por todos los v´ıdeos usados en MOT20. Este 5.1. DISE ˜ NO DE LOS EXPERIMENTOS 35 Nombre Resoluci´on N´umero de fotogramas Densidad MOT20-01 1920x1080 429 46.32 MOT20-01 1920x1080 2782 55.62 MOT20-02 1173x880 2405 130.42 MOT20-03 1654x1080 3315 194.98 Tabla 5.2: Descripci´on de los cuatro v´ıdeos disponibles en el conjunto de entrenamiento de MOT20. tipo de diferencias hacen que este ´ultimo conjunto resulte especialmente atractivo para evaluar en ´el los resultados. Para hacer la partici´on del conjunto, se divide cada v´ıdeo en dos, tal y como se hace en la gran mayor´ıa de publicaciones que trabajan sobre el MOT20: La primera mitad de fotogramas se usa ´ıntegramente para el conjunto de entrenamiento. La segunda, se emplea para generar el conjunto de test. 5.1.2. Adaptaci´on de MOT a SOT Hay que tener en cuenta que los sistemas SOT como los incluidos en py- SOT est´an preparados para ser probados en conjuntos de datos completamente diferentes, admitiendo un formato de datos espec´ıfico. En el caso de los conjuntos de MOT, se dispone de dos ficheros de texto: un fichero de detecci´on con informaci´on que se refiere exclusivamente a los objetos presentes en cada fotograma del v´ıdeo, y un fichero de anotaciones (llamado tambi´en ground truth en ingl´es), en el cual ya se informa, adem´as de la posici´on de cada uno de los objetos en cada fotograma, de la trayectoria a la que pertenece (con un identificador ´unico) [6]. A la entrada de pySOT, se necesitan formatos diferentes que adem´as var´ıan para entrenamiento y test. A continuaci´on se proporcionan algunos detalles. Adaptaci´on de los conjuntos de datos para test En el caso de las inferencias se requiere un fichero que tenga un formato JSON, y que contenga la siguiente informaci´on para cada v´ıdeo del conjunto (se entiende que cada v´ıdeo incluye un ´unico objeto a seguir): video dir: es el nombre que caracteriza a cada v´ıdeo. init rect: son las coordenadas del rect´angulo delimitador en el que se encuentra el objeto durante el primer fotograma. En principio, hay dos 36 CAP´ ITULO 5. PRUEBAS formatos v´alidos: con 8 coordenadas (indicando todas las esquinas) y con 4 (indicando la esquina superior izquierda y el ancho y alto). img names: una lista de nombres de los ficheros de imagen del v´ıdeo. gt rect: es una lista con todos los rect´angulos delimitadores del objeto que se desea seguir durante todos los fotogramas del v´ıdeo. camera motion,illum change,motion change,size change y occlusion: son variables usadas a nivel estad´ıstico, relacionadas con movimientos de la c´amara, iluminaci´on, cambios de tama˜no u oclusiones. No son relevantes para las pruebas por lo que se pueden dejar a cero. Adem´as, se asocia una etiqueta que identifica al ejemplo (puede coincidir con video dir o no) como una secuencia espec´ıfica de fotogramas en las que se sigue un objeto. En MOT, hay varios objetos por fotograma simult´aneamente, por lo que se siguen estos pasos: 1. Seleccionar, de cada uno de los v´ıdeos del conjunto correspondiente, una serie de objetos presentes en ellos. 2. Elaborar un script que genere, a partir de los datos de cada conjunto de entrenamiento, el fichero JSON con la informaci´on comentada previamente para cada uno de los v´ıdeos. Cada ejemplo se etiquet´o como exA, donde Aes un n´umero que inicia en 1 y acaba en el n´umero de ejemplos seleccionados. 3. Cada entrada del fichero JSON tiene asociada un video dir que es el nombre del v´ıdeo, por lo que ser´a necesario crear la estructura de carpetas para que se pueda hacer referencia a ellos correctamente. Durante los primeros experimentos, result´o interesante recurrir a MOT17 y aMOT20, de manera que se hizo una adaptaci´on de algunas trayectorias de los v´ıdeos de cada conjunto para hacer pruebas variadas con ellos. En la tabla 5.3 se indica a partir de qu´e v´ıdeos y trayectorias se han formado los conjuntos. Adaptaci´on de los conjuntos de datos para entrenamiento En el caso del entrenamiento el formato de datos seguido es algo diferente. Tambi´en se tiene un fichero JSON pero ahora s´ı es posible colocar dentro de cada v´ıdeo varias trayectorias distintas. El formato a seguir ser´ıa el siguiente: Una entrada por cada uno de los v´ıdeos, que vendr´ıa etiquetada por el nombre asociado al v´ıdeo. Ej: MOT20-02. Dentro del anterior, una entrada por cada trayectoria considerada dentro del v´ıdeo, que ir´a etiquetada por un identificador. 5.1. DISE ˜ NO DE LOS EXPERIMENTOS 37 MOT17 MOT20 video dir Nombre v´ıdeo ID Trayectoria Nombre v´ıdeo ID Trayectoria ex1 MOT17-02-FRCNN 31 MOT20-01 49 ex2 MOT17-02-FRCNN 72 MOT20-01 64 ex3 MOT17-04-FRCNN 68 MOT20-02 187 ex4 MOT17-04-FRCNN 83 MOT20-02 100 ex5 MOT17-04-FRCNN 89 MOT20-02 68 ex6 MOT17-04-FRCNN 92 MOT20-03 586 ex7 MOT17-09-FRCNN 21 MOT20-03 617 ex8 MOT17-10-FRCNN 26 MOT20-03 143 ex9 MOT17-10-FRCNN 18 MOT20-05 469 ex10 MOT17-10-FRCNN 12 MOT20-05 514 Tabla 5.3: Selecci´on de v´ıdeos y trayectorias para los ejemplos que se emplean como test a partir de los conjuntos de entrenamiento de MOT17 y MOT20. Finalmente, dentro de cada trayectoria, una entrada por cada fotograma, etiquetada con el n´umero de fotograma en el que est´a presente y con el valor de las coordenadas del rect´angulo delimitador que las conforma. Por ejemplo: {"MOT20-02": {"1": {"000722": [546.0, 251.0, 614.0, 396.0]}implica que el v´ıdeo bajo el nombre de MOT20-02 tiene una trayectoria con identificador 1 que inicia en el fotograma 722 en la posici´on dada por el rect´angulo [546.0, 251.0, 614.0, 396.0]. Las coordenadas del rect´angulo vienen dadas por dos puntos, el de la esquina superior izquierda y el de la inferior derecha (as´ı se procesan en entrenamiento). A la hora de entrenar, las im´agenes de los conjuntos de datos son recortadas a tama˜no 511x511, de manera que en el centro de las mismas se sit´ue el objeto a seguir durante el entrenamiento. 5.1.3. M´etricas usadas Dado que SiamRPN++ es un sistema SOT, en nuestro caso integrado en un sistema MOT, las m´etricas a utilizar estar´an relacionadas con SOT, pudiendo calcularse adem´as a trav´es de pySOT. Precisi´on de seguimiento (accuracy) Es la medida en la que las posiciones del objeto proporcionadas por el sistema se corresponden con las posiciones reales en las que el objeto se sit´ua. Para ello, se mide el solape entre los rect´angulos delimitadores de las anotaciones (esto es, los que se deber´ıan detectar idealmente) y los que se predicen [56], emple´andose una medida llamada la intersecci´on sobre la uni´on (abreviada como IoU). 38 CAP´ ITULO 5. PRUEBAS Consideremos dos rect´angulos delimitadores para el instante t, el ideal RIy el predicho RP. La IoU entre estos dos rect´angulos Φ(RI, RP) se calcula como: Φ(RI, RP) = (ARI t∩ARP t ARI t∪ARP t)N t=1 (5.1) Siendo ARI tel ´area del rect´angulo real del objeto de inter´es en el instante ty ARP tel ´area del rect´angulo predicho en el instante t[56]. En la figura 5.1 se muestra cada uno de los elementos interesantes de la f´ormula anterior: el ´area de cada rect´angulo, la intersecci´on y la uni´on. Φ podr´a tomar un valor entre 0 y 1, de manera que si Φ = 0, el solape ser´a inexistente entre los dos rect´angulos, mientras que si Φ = 1 dicho solape ser´a perfecto, de manera que los dos rect´angulos coincidir´an (es decir, la predicci´on se ajusta perfectamente al caso ideal). Por lo tanto, interesa alcanzar un valor lo m´as alto posible. Figura 5.1: Descripci´on de la intersecci´on sobre la uni´on de dos rect´angulos delimitadores sobre un objeto de ejemplo. De izquierda a derecha: ´areas de cada uno de los rect´angulos por separado, ´area de la intersecci´on y ´area de la uni´on. Robustez (robustness) Es una medida de lo bien que se sigue el objeto, contando el n´umero de veces que el sistema fall´o y tuvo que ser reinicializado [56]. Un fallo hace referencia a una situaci´on en la cual el sistema deja de seguir correctamente al objeto. Para ello, se utiliza la f´ormula de la intersecci´on sobre la uni´on y un umbral ϵ, de manera que, si se cumple que Φ(RI, RP)< ϵ, se identifica un fallo. Al ocurrir, el sistema se reinicializa con las anotaciones del fotograma actual. En este caso, la m´etrica se hace mayor cuantas m´as veces se pierde la trayectoria, por lo que lo que interesa en este caso es que este valor sea lo m´as bajo posible. 5.1.4. Plan de pruebas Dado que tenemos tres propuestas de mejoras diferentes y un modelo de partida, se han preparado cuatro grandes experimentos o pruebas, cada uno 5.1. DISE ˜ NO DE LOS EXPERIMENTOS 39 de los cuales a su vez se compone de varios casos de prueba que se describen en los apartados posteriores. Los resultados se analizaron de varias formas: A nivel de las m´etricas comentadas, para comprobar la calidad obtenida por el modelo, y la comparativa, si procede, con otros resultados obtenidos. Tras un an´alisis gr´afico: para las pruebas m´as interesantes, se generaron im´agenes incluyendo informaci´on ´util como la de la figura 5.2. (a) (b) (c) (d) (e) (f) Figura 5.2: Ejemplos de visualizaciones. (a), (b) y (c) son mapas de calor del ejemplo positivo, negativos y la diferencia, respectivamente, sobre la imagen completa. (d), (e) y (f) representan lo mismo, recortado al ´area cercana al positivo. Comparando los resultados en una l´ınea temporal: obtenidos los resultados de dos pruebas diferentes, se hizo un script que permite generar l´ıneas temporales para compararlos. Se proporciona un ejemplo en la figura 5.3. Figura 5.3: Ejemplo de l´ınea temporal. Las dos primeras filas representan la preci- si´on de dos pruebas, usando colores para representar la precisi´on de mejor a peor: verde claro, verde oscuro, rojo, negro y blanco (p´erdida). La tercera fila muestra la diferencia de la primera prueba respecto de la segunda, usando los mismos colores pero asociando los verdes a mejoras, el rojo y el negro a empeoramiento y el blanco a igualdad. 40 CAP´ ITULO 5. PRUEBAS 5.2. Experimento 1: Prueba base y an´alisis de problemas En primer lugar, se realizaron unas pruebas sin hacer ninguna modificaci´on. As´ı se analizaron los resultados que son la referencia para el resto de experimentos y se visualizaron posibles problemas. Este experimento se ha compuesto de dos casos de prueba: uno tomando como referencia la adaptaci´on de MOT17 y otro con la adaptaci´on de MOT20 (ambas descritas en la tabla 5.3). En la tabla 5.4 se muestran los resultados. Precisi´on ↑Robustez ↓ MOT2017 0.743 0.586 MOT2020 0.611 0.971 Tabla 5.4: Resultados base para SiamRPN++ sin ninguna modificaci´on, usando las adaptaciones de conjuntos de datos de MOT2017 y MOT2020 a SOT. Se observa la diferencia de complejidad entre los dos desaf´ıos. Hay m´as de una d´ecima de diferencia en la precisi´on entre el conjunto seleccionado a partir de MOT2017 y a partir de MOT2020. En este ´ultimo, adem´as, se pierde m´as veces el objeto. Esto, evidentemente, permite comprobar que se hace m´as interesante tomar como referencia el segundo desaf´ıo. Para el caso de MOT17 ya se llega a 0.74 de precisi´on, habiendo mayor margen de mejora para MOT20. Una vez consultadas las m´etricas, se quiso profundizar procediendo a la visualizaci´on de los ejemplos, fotograma a fotograma, comparando el rect´angulo delimitador predicho con el que se deber´ıa de obtener. Con ello, se encuentra uno de los problemas que es en el que se enfoca este trabajo en mejorar: la p´erdida de la trayectoria de las personas al cruzarse con otras. Por ejemplo, en la figura 5.4 se muestra un fotograma en el cual el objeto de inter´es se va siguiendo mal porque hay otro cercano con el que el sistema se confunde. Este hecho en fotogramas posteriores acaba conduciendo a que se pierda la trayectoria del objeto, lo que se repite en muchas ocasiones. 5.3. Experimento 2: mapas de calor negativos Este segundo experimento aplica la primera mejora propuesta, es decir, penalizar durante el seguimiento del objeto su mapa de calor con los mapas de los distractores. Para ello, se han definido varios casos de prueba, haciendo peque˜nas variaciones sobre lo descrito en el apartado 4.2.1. Concretamente: La variaci´on b´asica: combinar los mapas negativos usando el m´aximo de referencia y penaliz´andolos sobre el positivo mediante una resta normal. 5.3. EXPERIMENTO 2: MAPAS DE CALOR NEGATIVOS 41 Figura 5.4: Ejemplo de mal seguimiento de la trayectoria de un objeto en el ejemplo ex10 para la adaptaci´on de MOT2020 seg´un la tabla 5.3. En verde aparece el rect´angulo que deber´ıa predecir el sistema, mientras que en amarillo aparece el que realmente est´a prediciendo. Igual que el caso anterior, pero normalizando el resultado. Se pretende comprobar si ayuda que se realice una normalizaci´on min-max llevando el valor m´ınimo a un 0 y el m´aximo a un 1, dado que se comprob´o que el mapa de calor positivo base tambi´en se mueve entre esos valores (y al hacer una resta puede ocurrir que no sea as´ı). Aplicar penalizaci´on sobre negativos: tras recuperar la clasificaci´on y la regresi´on, normalmente se aplica una penalizaci´on sobre ambas. En el caso del mapa de calor negativo (s´olo para la clasificaci´on), dicha penalizaci´on no se contemplaba, pero se prueba tambi´en a incluirla. Penalizaci´on y normalizaci´on: de forma similar al caso anterior, pero introduciendo tambi´en una normalizaci´on entre 0 y 1 tras la resta. En este experimento, se recurri´o al conjunto adaptado de MOT17. Por lo dem´as, se tuvo que decidir cu´antos ejemplos negativos considerar para la uni´on con el positivo: se escogi´o un total de 10, pues supone un buen equilibrio entre precisi´on y coste computacional. La tabla 5.5 muestra los resultados obtenidos, compar´andolos con la prueba base extra´ıda en el primer experimento. Se pueden extraer diferentes conclusiones de estos resultados. Para empezar, en lo que respecta a la precisi´on, ning´un modelo consigue mejorar. Todos quedan por debajo del valor obtenido en la prueba base, habiendo eso s´ı algunas 42 CAP´ ITULO 5. PRUEBAS Prueba Precisi´on ↑Robustez ↓ Base 0.743 0.586 Variaci´on b´asica 0.672 0.603 Normalizaci´on 0-1 0.683 0.519 Penalizaci´on sobre negativos 0.635 0.636 Penalizaci´on negativos y normalizaci´on 0.718 0.569 Tabla 5.5: Resultados de los casos de prueba del experimento 2. diferencias entre ellos: la normalizaci´on ayuda a mejorar la precisi´on las dos ocasiones en las que se aplica, teniendo el mejor resultado sin contar la prueba base en 0.718 cuando se penalizan los ejemplos negativos. En cuanto a la robustez, s´ı hay alguna mejora. El mejor resultado obtenido es en la prueba de la normalizaci´on 0-1 a partir de la variaci´on b´asica, bajando a 0.519 frente al 0.586 de la prueba base. Tambi´en en la otra prueba en la que se normaliza (en este caso con la penalizaci´on sobre los mapas negativos), se consigue bajar, algo menos, hasta 0.569. Con estas variantes no se ha logrado una mejora clara en la precisi´on y la robustez es variable, reduci´endose en alg´un caso pero tambi´en aumentando. 5.4. Experimento 3: or´aculos En el experimento anterior se consideraron e incluso se llegaron a implementar m´as variantes, pero antes de probarlas, se concluy´o que lo mejor es usar el or´aculo, dado que si con ´el no se consiguiese mejorar, ser´ıa indicador de que esta aproximaci´on no es suficiente. Se elaboran dos casos de prueba por cada opci´on planteada en el apartado 4.2.2: Creando mapas negativos con un rect´angulo proporcional al delimitador. Creando mapas negativos siguiendo una gaussiana bidimensional. Recortando los mapas negativos por el delimitador de cada ejemplo. Para cada opci´on de las anteriores, se prob´o a variar otro par´ametro que est´a relacionado con la forma de uni´on con el ejemplo positivo y el negativo. Se prob´o tanto una resta directa como a penalizar los negativos la mitad, de manera que mapa final =mapa positivo −0,5∗suma negativos, y se mantuvo el uso de 10 ejemplos negativos. La tabla 5.1 recoge los resultados para MOT17. Los resultados de dicha tabla no reflejan demasiadas mejoras en precisi´on. Solamente se consigue mejorar a la prueba base del primer experimento 5.4. EXPERIMENTO 3: OR ´ ACULOS 43 Prueba Precisi´on ↑Robustez ↓ Base 0.743 0.586 Creando mapas negativos como rect´angulos P - N 0.715 0.619 P - N/2 0.719 0.619 Creando mapas negativos siguiendo gaussiana P - N 0.722 0.586 P - N/2 0.750 0.619 Recortando negativos por rect´angulo delimitador P - N 0.721 0.870 P - N/2 0.736 0.552 Tabla 5.6: Resultados de los casos de prueba del experimento 3 sobre el conjunto de datos adaptado de MOT2017. P - N hace referencia a la prueba haciendo la resta directa del ejemplo positivo y la uni´on de negativos, mientras que P - N/2 hace referencia a la prueba haciendo que la uni´on de negativos penalice la mitad. en un caso: 0.750 para la prueba creando mapas negativos siguiendo una gaussiana y haciendo que penalicen los negativos la mitad. Pasa lo mismo con la robustez: solo mejora en una prueba, recortando negativos por el delimitador y penalizando la mitad. Tambi´en se han hecho las pruebas sobre el conjunto adaptado de MOT20. En la tabla 5.7 se recogen estos nuevos resultados. Prueba Precisi´on ↑Robustez ↓ Base 0.611 0.971 Creando mapas negativos como rect´angulos P - N 0.642 0.949 P - N/2 0.643 0.993 Creando mapas negativos siguiendo gaussiana P - N 0.633 0.949 P - N/2 0.582 0.927 Recortando negativos por rect´angulo delimitador P - N 0.622 1.545 P - N/2 0.635 1.015 Tabla 5.7: Resultados de los casos de prueba del experimento 3 sobre el conjunto de datos adaptado de MOT2020. En este caso, hay alguna mejora m´as respecto a la prueba base, tanto en precisi´on como a nivel de p´erdidas. Sin embargo, la mejora es peque˜na y se debe a que se est´a usando la mejor informaci´on posible, la de las anotaciones, que deber´ıan ser usadas solamente para verificar los resultados, no como entrada: en un caso realista, habr´ıa que recurrir a estrategias como las del experimento 2 y que, como ya se indic´o, no daban resultados del todo buenos. Adem´as, se prob´o a hacer comparativas con los modelos base usando l´ıneas temporales y visualizando los mapas de calor, para tratar de entender porqu´e se 50 CAP´ ITULO 7. CONCLUSIONES Y POSIBLES AMPLIACIONES conjuntos de datos del problema del MOT. Adem´as, dichos entrenamientos solo usaban como referencia 3 ejemplares negativos, pero se podr´ıa probar a aumentar ese n´umero. Finalmente, tambi´en se han identificado ´areas de mejora adicionales, como la inicializaci´on del objeto a seguir y situaciones en las que est´a entrando o saliendo de la escena, que podr´ıan mejorar a´un m´as los resultados. Un trabajo futuro podr´ıa estar encaminado precisamente a profundizar m´as en alguna de las cuestiones que se acaban de comentar. Adicionalmente, y tal y como se propuso en el apartado 1.1, este sistema SOT podr´ıa formar parte de un sistema MOT m´as completo, por lo que otra ampliaci´on podr´ıa consistir en tratar de lograr esa integraci´on que, con las posibles mejoras estudiadas en este TFG, es prometedora. Ap´endice A Manual T´ecnico Este manual t´ecnico se elabora con el prop´osito de presentar parte del c´odigo fuente usado y algunas modificaciones hechas, de modo que sirva de ayuda para comprender su estructura y facilitar a otra persona que quiera modificar el c´odigo su labor. A.1. C´odigo fuente Como ya se ha comentado en ocasiones anteriores, se ha partido del c´odigo disponible en el GitHub del software pySOT [22], realizando modificaciones para incluir la implementaci´on de todas las mejoras necesarias. Pero no s´olo se ha dedicado la implementaci´on a esa parte. Se han tenido que ir elaborando algunos scripts m´as, con el prop´osito de hacer algunas operaciones adicionales que, como se ha ido desarrollando a lo largo de esta memoria, se fueron haciendo necesarias. Como complemento a esta memoria, se entrega todo el c´odigo desarrollado en una carpeta compartida de la herramienta Microsoft OneDrive. Si se accede, se podr´an observar una serie de carpetas de inter´es, que tambi´en se muestran en forma de ´arbol de directorios en la figura A.1: Conversor MOT17 MOT20 VOT: en ella se incluyen scripts de Python creados manualmente en los cuales se hacen diversas operaciones de conversi´on de los conjuntos de datos MOT a formatos v´alidos en SOT para entrenamiento y test, al estilo de lo comentado en la memoria. Se han ido creando varios scripts: •drawGT.py: se cre´o con el prop´osito de, tomando como referencia un v´ıdeo o un conjunto de datos completo (lo que se cambia por par´ametros o ajustando la variable dataset folder dentro del c´odigo), dibujar sobre ´el todos los rect´angulos delimitadores acompa˜nados de los identificadores de trayectorias. De este modo, result´o ´util para 51 52 AP´ ENDICE A. MANUAL T ´ ECNICO Figura A.1: Estructura con las carpetas principales empleadas durante el desarrollo de este TFG. seleccionar las trayectorias que se iban a utilizar en el conjunto de pruebas. •convert MOT17 toVOT JSON.py y el convert MOT20 toVOT JSON.py: fueron los primeros scripts desarrollados para, a partir de MOT17 o MOT20, seleccionar una serie de trayectorias de cada v´ıdeo, y con ellas crear un fichero JSON adaptado para ser usado en pySOT. Esta aproximaci´on se mantuvo para MOT17, dado que solamente se emple´o el conjunto de entrenamiento en pruebas, pero en MOT20, dado que se dej´o una parte para entrenar y otra para probar, result´o insuficiente. •convert MOT20 toFullVOT json.py: es un script que hace una adaptaci´on del conjunto completo de MOT20 a un formato JSON para ser usado en un entrenamiento de pySOT. Adem´as, se aprovech´o para partir los v´ıdeos en dos mitades, cre´andose por tanto dos ficheros: uno con los datos de entrenamiento (MOT20 train.json), y otro con los que se pueden usar para test (MOT20 test.json) conforme a lo comentado en el apartado 5.1.2. •MOT20 items picker.py: este ´ultimo script permite, a partir del fichero que genera el script anterior llamado MOT20 test.json,crear un JSON para las pruebas del estilo de los generados por el script convert MOT17 toVOT JSON.py, pero usando como referencia ´unicamente la mitad del conjunto de entrenamiento de MOT20 que de- A.1. C ´ ODIGO FUENTE 53 dicamos a test. De aqu´ı s´ı salen las trayectorias definitivamente seleccionadas para inferencias con MOT20. Comparador: dentro de esta carpeta se tiene un script compara.py que permite, pasando dos carpetas de resultados de dos pruebas diferentes sobre el mismo conjunto, crear una comparativa visual en forma de l´ıneas temporales. Se obtiene como resultado una imagen por cada v´ıdeo, formada por tres componentes: •Una l´ınea temporal representando la precisi´on obtenida durante el seguimiento en la primera prueba. •Una l´ınea temporal representando la precisi´on obtenida durante el seguimiento en la segunda prueba. •Una l´ınea temporal en la que se muestra d´onde la primera prueba mejora o empeora respecto de la segunda. De este modo, lo habitual es que en la primera prueba se coloque un modelo en el que se propone alguna mejora, mientras que en la segunda se coloque el modelo base con ese conjunto de datos, as´ı se puede ver a qu´e ayudan las mejoras. Se han usado c´odigos de colores que sean simples de entender, asociando el verde a algo positivo (ya sea buen seguimiento o mejora respecto del modelo base), y colores rojos o m´as oscuros a algo negativo (mal seguimiento o empeoramiento respecto del modelo base). En la figura A.2, se puede comprobar el tipo de resultados que se obtienen: ese ejemplo concreto mejora justo al final los resultados respecto del modelo base, porque aguanta sin dejar de seguir al objeto y con una mejor precisi´on. Figura A.2: Ejemplo de salida del script de comparaci´on para uno de los ejemplos de pruebas de MOT20 (en este caso, el ex6, para la prueba del or´aculo con la gaussiana respecto del modelo base). pysot-master: es el directorio que contiene todo el c´odigo de pySOT, pero con las modificaciones que se han ido aplicando a lo largo de este 54 AP´ ENDICE A. MANUAL T ´ ECNICO TFG. Se puede comprobar que hay ficheros que tienen c´odigo diferente, as´ı como otros completamente nuevos. Adem´as, en la figura A.1, se observan una gran cantidad de directorios dentro de ´este. Hay algunos que conviene resaltar, dado que ser´a importante conocer su contenido de cara a posibles modificaciones: •demo: tiene un ejemplo de v´ıdeo para el cual se prob´o a hacer un seguimiento. •Docker: se cre´o para contener el Dockerfile que se us´o en los servidores de computaci´on para crear una imagen y, a partir de ella, contenedores Docker. •experiments: en ella se tendr´an tantas subcarpetas como se deseen (en la versi´on compartida se proporcionan dos carpetas que resultan suficientes para, a partir de ellas, replicar las pruebas). Cada una, se corresponder´a con un experimento. Dentro de cada experimento, resulta fundamental disponer de: ◦config.yaml: es un fichero de configuraci´on propio del experimento. En ´el se pueden establecer diferentes par´ametros de configuraci´on para ese experimento concreto. ◦Cuando se quieran hacer pruebas, adem´as, ser´a necesario disponer de todos los v´ıdeos cuyas etiquetas aparecen presentes en todos los campos video dir incluidos en el fichero JSON correspondiente al conjunto de datos que se vaya a usar. ◦Adicionalmente, cuando se quieran usar unos pesos ya entrenados, conviene almacenar en este directorio tambi´en el fichero con formato .pth que contenga dichos pesos. •pretrained models: contiene ficheros con pesos de modelos que se hayan preentrenado. En este caso, se incluye el modelo de ResNet que se usa en SiamRPN++. •pysot: dentro de ´el, hay varias subcarpetas con varios tipos de ficheros. ◦core: contiene, entre otros ficheros, config.py, que es muy importante al estar definidos en ´el todos los par´ametros que se pueden modificar a posteriori en los config.yaml dentro de cada experimento. ◦datasets: contiene ficheros de c´odigo fuente para la configuraci´on de los conjuntos de datos al cargarlos. ◦models: es un directorio importante, en el que hay subdirectorios con ficheros de c´odigo fuente en los que se define la arquitectura que usa la red por detr´as. A.2. MODIFICACI ´ ON SOBRE PYSOT 55 ◦tracker: contiene los ficheros de los diferentes sistemas de seguimiento implementados en pySOT (y variaciones a˜nadidas para las implementaciones hechas en este trabajo). •testing dataset: en este directorio van los conjuntos de datos usados para pruebas. Realmente, dado que, como se coment´o, es en la carpeta del experimento donde tienen que ir los v´ıdeos, en este directorio basta con tener una subcarpeta por cada conjunto de datos, conteniendo el fichero JSON que los describe. •toolkit: incluye el c´odigo fuente de diferentes utilidades usadas en otras clases. •tools: en su interior se encuentran tres ficheros muy importantes que nos permitir´an realizar ejecuciones diferentes: ◦test.py: permite ejecutar el seguimiento sobre un conjunto de test. ◦eval.py: a partir de la ejecuci´on de test.py, permite obtener las m´etricas para el seguimiento realizado. ◦train.py: permite la ejecuci´on de entrenamientos. •training dataset: es donde se guardan todos los datos de los conjuntos de entrenamiento. Para cada uno, se almacenan todos los v´ıdeos que lo conforman, as´ı como el fichero JSON que describe todas las trayectorias de todos los v´ıdeos, lo que ser´a ´util cargar al empezar el entrenamiento. •vot iter: contiene c´odigo fuente relativo a la integraci´on VOT en Python. Resultados: es un directorio que se ha dedicado a incluir algunos resultados interesantes en forma de ficheros excel o im´agenes generadas con los scripts o durante el seguimiento de algunos objetos. Datasets: es un directorio que contiene los conjuntos de datos de MOT17 y MOT20. En el caso de MOT17, se hizo una adaptaci´on de los videos para corresponderse con el JSON generado, mientras que para MOT20, no fue necesario (solamente est´an las carpetas para los v´ıdeos originales). Adem´as, en cada directorio hay una carpeta anns con las anotaciones, necesaria a la hora de ejecutar los tests. A.2. Modificaci´on sobre pySOT Como ya se ha comentado, a la hora de introducir las mejoras, se han: Modificado algunos ficheros, para a˜nadir la funcionalidad necesaria. 56 AP´ ENDICE A. MANUAL T ´ ECNICO A˜nadido ficheros nuevos, con funcionalidad nueva. A la hora de a˜nadir los ficheros, pod´ıa ser necesario para poderlos emplear desde otra parte del software importarlos de alguna manera. Por lo dem´as, muchas de las modificaciones a˜nadidas no se quer´ıa que funcionasen siempre, sino cuando se le indicase. Por ejemplo, cuando se a˜naden diferentes variantes, se quiere ejecutar espec´ıficamente alguna de ellas, y eso se le quiere indicar de alguna manera al sistema. Este problema tambi´en surgi´o con los desarrolladores de pySOT, que como soluci´on ofrecieron dos alternativas: La inclusi´on de par´ametros por l´ınea de comandos. Sin embargo, esto se usa para indicar rutas de determinados ficheros, como los pesos o el conjunto de datos con los que hacer una prueba, por lo que no parec´ıa lo m´as apropiado hacer ah´ı las configuraciones. El uso de par´ametros de configuraci´on. Mediante el uso de la clase CfgNode de la librer´ıa yacs.config se a˜nade el manejo de par´ametros. Hay dos ficheros importantes a tener en cuenta, ya introducidos previamente: •El fichero config.py, que est´a en pysot-master/pysot/core. En ´el, se definen todos los par´ametros que se van a poder ajustar, d´andoles un valor por defecto. Aqu´ı se han a˜nadido par´ametros propios para ejecutar trozos de c´odigo con nuestras modificaciones. •El fichero config.yaml, que es propio de cada ejecuci´on, y que de hecho se puede facilitar como par´ametro por l´ınea de comandos. En ´el, se pueden modificar los valores por defecto establecidos en config.py. As´ı, a la hora de aplicar las modificaciones, cuando dependiesen de una configuraci´on concreta, se aprovecharon par´ametros ya existentes y se crearon algunos nuevos. En el Manual de Usuario (Ap´endice B) se dar´an detalles sobre ellos, a la hora de describir las ejecuciones de las pruebas. A.3. Implementaci´on de arquitecturas con mejoras Un ejemplo de modificaci´on muy relevante, y sobre el que puede tener cierto inter´es hacer propuestas diferentes a las realizadas en este trabajo, se encuentra en la arquitectura de SiamRPN++. A la hora de implementar las arquitecturas alternativas que se usaron en el cuarto experimento, hubo que recurrir a funciones de la librer´ıa PyTorch. Por A.3. IMPLEMENTACI ´ ON DE ARQUITECTURAS CON MEJORAS 57 defecto, la arquitectura b´asica de la RPN, sin distinguir la rama de clasificaci´on y la de regresi´on, ni los tres mapas de caracter´ısticas que puede tener a la entrada, est´a definida en la clase DepthwiseXCorr: 1class DepthwiseXCorr(nn.Module): 2def __init__(self, in_channels, hidden, out_channels, 3kernel_size=3, hidden_kernel_size=5): 4super(DepthwiseXCorr, self).__init__() 5self.conv_kernel = nn.Sequential( 6nn.Conv2d(in_channels, hidden, 7kernel_size=kernel_size, bias=False), 8nn.BatchNorm2d(hidden), 9nn.ReLU(inplace=True), 10 ) 11 self.conv_search = nn.Sequential( 12 nn.Conv2d(in_channels, hidden, 13 kernel_size=kernel_size, bias=False), 14 nn.BatchNorm2d(hidden), 15 nn.ReLU(inplace=True), 16 ) 17 self.head = nn.Sequential( 18 nn.Conv2d(hidden, hidden, 19 kernel_size=1, bias=False), 20 nn.BatchNorm2d(hidden), 21 nn.ReLU(inplace=True), 22 nn.Conv2d(hidden, out_channels, kernel_size=1) 23 ) 24 25 26 def forward(self, kernel, search): 27 kernel = self.conv_kernel(kernel) 28 search = self.conv_search(search) 29 feature = xcorr_depthwise(search, kernel) 30 out = self.head(feature) 31 return out Como se puede comprobar, por un lado, se tiene la funci´on de inicializaci´on en la que se definen las capas y operaciones asociadas, mientras que por otro aparece una funci´on forward que es en la cual se van llamando a las capas creadas. Esta estructura se replica a la hora de crear las clases con las arquitecturas mejoradas, que se muestran a continuaci´on. A partir de esta clase, modificando los par´ametros de entrada de la funci´on de inicializaci´on, se crean las ramas de clasificaci´on y de regresi´on de la RPN. Dicha operaci´on de creaci´on tambi´en se debe revisar con las clases nuevas que se crean con las modificaciones de arquitectura. 58 AP´ ENDICE A. MANUAL T ´ ECNICO A.3.1. Arquitectura SiamRPN++ considerando negativos La primera de las variantes junta directamente todos los negativos (alternativa 1 del apartado 4.2.3). En el trozo de c´odigo siguiente, se pueden comprobar las capas y, en el forward, c´omo se hace para separar los ejemplos y combinarlos por la dimensi´on de profundidad. 1class DepthwiseXCorr_Neg(nn.Module): 2def __init__(self, in_channels, hidden, out_channels, 3kernel_size=3, hidden_kernel_size=5): 4super(DepthwiseXCorr_Neg, self).__init__() 5self.conv_kernel = nn.Sequential( 6nn.Conv2d(in_channels, hidden, 7kernel_size=kernel_size, bias=False), 8nn.BatchNorm2d(hidden), 9nn.ReLU(inplace=True), 10 ) 11 self.conv_search = nn.Sequential( 12 nn.Conv2d(in_channels, hidden, 13 kernel_size=kernel_size, bias=False), 14 nn.BatchNorm2d(hidden), 15 nn.ReLU(inplace=True), 16 ) 17 self.head_1 = nn.Sequential( 18 nn.Conv2d(hidden, hidden, 19 kernel_size=1, bias=False), 20 nn.BatchNorm2d(hidden), 21 nn.ReLU(inplace=True), 22 ) 23 if cfg.TRAIN.NEG_MODE == "1x1Conv": 24 self.head_2 = nn.Sequential( 25 # Metemos aqui la convoluci´ on fusionando 26 # todos los ejemplares 27 nn.Conv2d(hidden*(cfg.TRAIN.NUM_NEGATIVES+1), 28 hidden, kernel_size=1, bias=False), 29 # Aplicamos tambi´ en una batch normalization 30 # y una relu como funci´ on de activaci´ on 31 nn.BatchNorm2d(hidden), 32 nn.ReLU(inplace=True), 33 nn.Conv2d(hidden, out_channels, kernel_size=1) 34 ) 35 elif cfg.TRAIN.NEG_MODE == "groups": 36 self.head_2 = nn.Sequential( 37 # Metemos aqui la convoluci´ on fusionando todos 38 # los ejemplares (positivo y negativos) 39 # En este caso, el par´ ametro groups=hidden nos 40 # permite juntar solamente por cada canal los 41 # ejemplos y no todo junto. 42 nn.Conv2d(hidden*(cfg.TRAIN.NUM_NEGATIVES+1), 43 hidden, groups=hidden, kernel_size=1, A.3. IMPLEMENTACI ´ ON DE ARQUITECTURAS CON MEJORAS 59 44 bias=False), 45 # Aplicamos tambi´ en una batch normalization 46 # y una relu 47 nn.BatchNorm2d(hidden), 48 nn.ReLU(inplace=True), 49 nn.Conv2d(hidden, out_channels, kernel_size=1) 50 ) 51 else: 52 print("No se defini´ o un modo de juntar los mapas positivo y negativos v´ alido") 53 # Si se pide, congelamos solo la parte del modelo no 54 # nueva respecto la DepthWiseXCorr original. 55 if cfg.TRAIN.FREEZE_IN_NEG: 56 for (i, j, k) in zip(self.conv_kernel.parameters(), 57 self.conv_search.parameters(), 58 self.head_1.parameters()): 59 i.requires_grad = False 60 j.requires_grad = False 61 k.requires_grad = False 62 print(self) 63 64 # A˜ nadimos al forward el tama˜ no de la primera dimensi´ on 65 # para cambiarlo seg´ un entrenamiento y test: 66 def forward(self, kernel_comb, search, dim0size): 67 # Aplicamos convoluci´ on de kernel a la combinaci´ on 68 # de positivo+negativos por el batch: 69 kernel_comb = self.conv_kernel(kernel_comb) 70 # Aplicamos las convoluciones del search area: 71 search = self.conv_search(search) 72 s_sh = search.shape 73 # Combinamos varios search areas al estilo del kernel 74 # para aplicar la correlaci´ on: 75 search_cc = torch.stack([search]* 76 (cfg.TRAIN.NUM_NEGATIVES+1), dim = 1) 77 .view((cfg.TRAIN.NUM_NEGATIVES+1)*dim0size, 78 s_sh[1], s_sh[2], s_sh[3]) 79 # Correlaci´ on depthwise: 80 feature = xcorr_depthwise(search_cc, kernel_comb) 81 # Primera parte de la cabecera: 82 out = self.head_1(feature) 83 o_sh = out.shape 84 # Separamos ahora los tensores de nuevo, y los 85 # juntamos por la profundidad 86 samples = out.view(dim0size, cfg.TRAIN.NUM_NEGATIVES+1, 87 o_sh[1], o_sh[2], o_sh[3]).unbind(dim = 1) 88 out = torch.stack(samples, dim = 2) 89 .view(dim0size, 256*(cfg.TRAIN.NUM_NEGATIVES+1), 90 o_sh[2], o_sh[3]) 91 # Ejecutamos la segunda parte de la cabecera: 92 out = self.head_2(out) 93 # Devolvemos el resultado: 66 AP´ ENDICE B. MANUAL DE USUARIO 9# Zona horaria 10 ENV TZ=Europe/Madrid 11 12 # Establecimiento zona horaria 13 RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone 14 RUN apt-get update 15 # Instalaci´ on python, wget, git y herramientas compilaci´ on 16 RUN apt-get install -y python3 17 RUN apt-get install -y wget 18 RUN apt-get install -y git-all 19 RUN apt-get install -y build-essential 20 21 # Descarga de Conda (Miniconda) e instalaci´ on 22 RUN wget \ 23 https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux -x86_64.sh \ 24 && mkdir /root/.conda \ 25 && bash Miniconda3-latest-Linux-x86_64.sh -b \ 26 && rm -f Miniconda3-latest-Linux-x86_64.sh 27 28 # Se crea entorno llamado pysot 29 RUN conda create --name pysot python=3.7 30 RUN apt-get update && apt-get install -y git-all && apt-get install -y gcc 31 32 # Se entra en el entorno: 33 SHELL ["conda","run","-n","pysot","/bin/bash","-c"] 34 35 # Se instala dentro de conda numpy, torch, cuda 9.0 y otras librer´ ıas 36 RUN conda install numpy 37 RUN conda install pytorch=0.4.1 torchvision cuda90 -c pytorch 38 RUN pip install pyyaml yacs tqdm colorama matplotlib cython tensorboardX 39 RUN pip install opencv-python 40 RUN pip install motmetrics 41 42 # Actualizamos PYTHONPATH con ubicaci´ on de pysot 43 ENV PYTHONPATH=/workspace/TFG/pysot-master:$PYTHONPATH 44 45 # Se establece el directorio de trabajo: 46 WORKDIR ${WORKDIR} 47 48 # Lo primero que se ejecuta es un script: 49 ENTRYPOINT ["pysot-master/entrypoint.sh"] Con ENTRYPOINT ["pysot-master/entrypoint.sh"] lo que se hace es establecer que lo primero que se va a hacer nada m´as entrar es ejecutar el script entrypoint.sh situado dentro de la carpeta pysot-master. Dicho script, lo ´unico que hace es iniciar Conda y un nuevo terminal de bash desde el cual ya se B.1. INSTALACI ´ ON DEL SOFTWARE 67 podr´a comenzar a trabajar con esa herramienta: #!/bin/bash conda init exec bash Teniendo conocimiento ya del Dockerfile, lo primero que se va a hacer es crear la imagen. Para ello es necesario situarse en el directorio de dicho fichero y ejecutar el comando: docker build -t nombre_imagen Donde nombre imagen es el nombre que se le quiere otorgar a la imagen creada, para una identificaci´on m´as sencilla. Hecho esto, lo siguiente que hay que hacer es crear un contenedor. El comando usado normalmente para ello se presenta a continuaci´on, suponiendo que se est´a en el directorio ra´ız de la estructura de carpetas descargada: nvidia-docker run --name nombre-contenedor --user root -e NB_UID=$(id -u) -e NB_GID=$(id -g) -e CHOWN_HOME=yes -e CHOWN_HOME_OPTS=’-R’ -it --rm -v $PWD:/workspace/TFG -v /tmp/.X11-unix/:/tmp/.X11-unix:rw -v /mnt/nfs/:/mnt/nfs/ --device /dev/video0:/dev/video0:mwr --net=host --ipc=host -e XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR -e DISPLAY=$DISPLAY -e "CUDA_VISIBLE_DEVICES=0,1" -e "CUDA_DEVICE_ORDER=PCI_BUS_ID" --privileged nombre-imagen Este comando se compone de varias opciones. Algunas de ellas es necesario comentarlas con algo m´as de detalle para entender lo que se est´a haciendo, de hecho, se podr´ıan incluso variar si se desea: nvidia-docker se usa para poder hacer ejecuciones dentro del contenedor en las gr´aficas. Dependiendo de la versi´on de CUDA, puede ser necesario reemplazarlo por docker run --gpus all. --name es una opci´on que permite otorgarle un nombre al contenedor. --user root permite establecer la ejecuci´on como superusuario. -v $PWD:/workspace/TFG permite compartir el directorio actual, que es la ra´ız de la carpeta que contiene todo el c´odigo entregado. As´ı, se podr´a acceder a su contenido desde dentro del contenedor (por defecto no ser´ıa posible). -e ’CUDA VISIBLE DEVICES=0,1’ permite establecer las gpus visibles desde dentro del contenedor. Aqu´ı, por ejemplo, se est´an haciendo visibles dos: la n´umero 0 y la n´umero 1. 68 AP´ ENDICE B. MANUAL DE USUARIO nombre-imagen se corresponde con el nombre de la imagen a usar para lanzar el contenedor. En este caso, habr´ıa que usar la que se cre´o con el Dockerfile anterior. Pero la instalaci´on no termina en este punto. Para poder comenzar a realizar ejecuciones hace falta seguir unos pasos m´as. Cuando se inicia el contenedor, lo normal es que aparezca una secuencia como la de la figura B.1. Figura B.1: Salida por terminal al arrancar un contenedor Docker sobre la imagen propuesta. Como se puede comprobar, se tiene Conda activado (obs´ervese que aparece el entorno (base) en el prompt de la parte inferior). Lo que falta ahora es, para empezar, cambiar al entorno creado gracias al Dockerfile. Para ello, recurrimos al comando siguiente (si se ha usado el Dockerfile presentado antes, el entorno que hay que usar tendr´a el nombre de pysot): conda activate pysot Como ´ultima configuraci´on antes de poder comenzar a ejecutar experimentos libremente, es necesario ejecutar el script setup.py, que se encuentra dentro del directorio pysot-master. python setup.py build_ext --inplace Con esto se puede dar por finalizada la instalaci´on. A continuaci´on se explicar´a, en primer lugar, c´omo hacer entrenamientos y, posteriormente, c´omo hacer las pruebas. Tambi´en se har´a referencia a la ejecuci´on de comparativas entre dos resultados obtenidos y alguna utilidad adicional que no es indispensable. B.2. EJECUCI ´ ON DE ENTRENAMIENTOS 69 B.2. Ejecuci´on de entrenamientos Lo primero que se requiere para entrenar correctamente es tener dentro de experiments una carpeta dentro de la cual estar´a la informaci´on necesaria (y posteriormente los resultados obtenidos) del entrenamiento. Como se ha comentado previamente, dentro de esta carpeta es necesario tener definido el config.yaml con los par´ametros propios de este experimento, que se pueden personalizar. Por defecto, se proporciona en la carpeta compartida por OneDrive el directorio siamrpn r50 l234 dwxccorr TRAINMOT20. En la documentaci´on de pySOT, se proporciona un fichero de configuraci´on por defecto que permite ejecutar un entrenamiento sobre cuatro conjuntos de datos propios del SOT: ILSVRC2017 [57], Youtube Bounding Boxes [58] y COCO [59]. Dicho fichero tiene la siguiente forma: 1META_ARC: "siamrpn_r50_l234_dwxcorr" 2 3BACKBONE: 4TYPE: "resnet50" 5KWARGS: 6used_layers: [2, 3, 4] 7PRETRAINED: ’pretrained_models/resnet50.model’ 8TRAIN_LAYERS: [’layer2’,’layer3’,’layer4’] 9TRAIN_EPOCH: 10 10 LAYERS_LR: 0.1 11 12 ADJUST: 13 ADJUST: true 14 TYPE: "AdjustAllLayer" 15 KWARGS: 16 in_channels: [512, 1024, 2048] 17 out_channels: [256, 256, 256] 18 19 RPN: 20 TYPE: ’MultiRPN’ 21 KWARGS: 22 anchor_num: 5 23 in_channels: [256, 256, 256] 24 weighted: true 25 26 MASK: 27 MASK: false 28 29 ANCHOR: 30 STRIDE: 8 31 RATIOS: [0.33, 0.5, 1, 2, 3] 32 SCALES: [8] 33 ANCHOR_NUM: 5 34 35 TRACK: 70 AP´ ENDICE B. MANUAL DE USUARIO 36 TYPE: ’SiamRPNTracker’ 37 PENALTY_K: 0.04 38 WINDOW_INFLUENCE: 0.44 39 LR: 0.33 40 EXEMPLAR_SIZE: 127 41 INSTANCE_SIZE: 255 42 BASE_SIZE: 8 43 CONTEXT_AMOUNT: 0.5 44 45 TRAIN: 46 EPOCH: 20 47 START_EPOCH: 0 48 BATCH_SIZE: 28 49 BASE_LR: 0.005 50 CLS_WEIGHT: 1.0 51 LOC_WEIGHT: 1.2 52 RESUME: ’’ 53 54 LR: 55 TYPE: ’log’ 56 KWARGS: 57 start_lr: 0.005 58 end_lr: 0.0005 59 LR_WARMUP: 60 TYPE: ’step’ 61 EPOCH: 5 62 KWARGS: 63 start_lr: 0.001 64 end_lr: 0.005 65 step: 1 66 67 DATASET: 68 NAMES: 69 -’VID’ 70 -’YOUTUBEBB’ 71 -’COCO’ 72 -’DET’ 73 74 TEMPLATE: 75 SHIFT: 4 76 SCALE: 0.05 77 BLUR: 0.0 78 FLIP: 0.0 79 COLOR: 1.0 80 81 SEARCH: 82 SHIFT: 64 83 SCALE: 0.18 84 BLUR: 0.2 85 FLIP: 0.0 86 COLOR: 1.0 B.2. EJECUCI ´ ON DE ENTRENAMIENTOS 71 87 88 NEG: 0.2 89 GRAY: 0.0 Si se quisiese hacer la prueba con esos conjuntos de datos, se tendr´ıan que descargar y ejecutar una serie de scripts disponibles en el github de pySOT que permiten darle el formato apropiado a cada uno de los ejemplares de los v´ıdeos (lo que en este trabajo se hace en el propio c´odigo para MOT, en estos conjuntos se hace de forma separada, porque son algo m´as ligeros y as´ı se ahorra tiempo en la ejecuci´on del entrenamiento). Este ap´endice se centra en replicar los experimentos que se han hecho como parte del TFG, as´ı que el entrenamiento con otros conjuntos de datos se escapa del alcance del mismo. Centr´andose ya en el entrenamiento en MOT20, hay que tener en cuenta que en la carpeta compartida proporcionada ya se han generado todos los ficheros JSON necesarios, por lo que no es necesario ejecutar nuevamente los scripts de conversi´on. Los pasos a seguir son: Tener dentro del directorio pysot-master/training dataset todos los datos del conjunto de MOT20, as´ı como el fichero JSON MOT20 Train.json (que fue generado con el script convert MOT20 toFullVOT json.py). En la carpeta compartida v´ıa OneDrive, es necesario copiar el contenido de datasets/MOT20 en pysot-master/training dataset/MOT20VOT (salvo el directorio anns). Como se ha comentado en el desarrollo de la memoria, parte de la red neuronal se mantiene congelada durante el entrenamiento: esto quiere decir que se mantienen unos pesos fijos, pero no cualquier tipo de pesos. Se cargan los pesos definidos en el fichero model.pth (que son los que se usan en las evaluaciones de los tres primeros experimentos, adem´as). Luego, hay que modificar la configuraci´on definida en el config.yaml. Respecto del fichero que se mostr´o previamente en este apartado, cambia lo siguiente: •En el apartado RPN.TYPE, en lugar de MultiRPN, se tiene que indicar MultiRPNMod. •En el apartado TRAIN, se a˜nade: 1PRETRAINED: ’model.pth’ 2CONSIDER_NEG: True 3FREEZE_IN_NEG: True 4NEG_MODE: ’1x1Conv’ 5NUM_NEGATIVES: 3 Donde NEG MODE puede tomar diferentes valores seg´un la modalidad de uni´on que se aplique a los ejemplares: 72 AP´ ENDICE B. MANUAL DE USUARIO ◦’1x1Conv’: si se agregan directamente todos los ejemplares sin tener en cuenta el canal (alternativa 1 del apartado 4.2.3). ◦’groups’: si se usa una convoluci´on por grupos para argupar directamente todos los ejemplares (alternativa 2 del apartado 4.2.3). ◦’NegOnlyJoin’: si se combinan primero los negativos y luego con el positivo (alternativa 3 del apartado 4.2.3). ◦’NegOnlyJoin 2Pos’: si se combinan primero los negativos y luego con el positivo en dos ocasiones (alternativa 4 del apartado 4.2.3). Adem´as, NUM NEGATIVES valdr´a 3 por defecto, si bien se puede variar este valor indic´andolo. •Finalmente, en DATASET, se cambia el atributo NAMES: 1NAMES: 2-’MOT20VOT’ Con todo esto, se puede proceder a la ejecuci´on de los entrenamientos. Normalmente, en los servidores se ha aprovechado la capacidad disponible en las GPUs, y se han creado en paralelo m´ultiples procesos para acelerar la ejecuci´on (esto nos ha evitado esperas mucho m´as largas en muchos entrenamientos). De esta manera, el comando que se suele usar es el siguiente (suponiendo que estamos situados en el directorio de un experimento concreto): python3 -m torch.distributed.launch --nproc_per_node=N --master_port=2333 ../../tools/train.py --cfg config.yaml Donde Nes el n´umero de procesos que se quieren lanzar. Normalmente se han usado 8, que se distribu´ıan entre las GPUs disponibles. Evidentemente, todo depende de la capacidad que se tenga disponible en el momento de las pruebas y la memoria requerida por cada proceso. Al irse ejecutando el entrenamiento, se crean dos directorios: logs: contendr´a las salidas que aparecen por terminal, para que as´ı se pueda dejar el entrenamiento en segundo plano e ir consultando el progreso o posibles incidencias ocurridas. snapshot: contendr´a los diferentes puntos de control que aparecen tras cada ´epoca de ejecuci´on de las pruebas. Esto ser´a ´util si se quieren ir validando los diferentes pesos obtenidos. B.3. EJECUCI ´ ON DE PRUEBAS Y EVALUACIONES 73 B.3. Ejecuci´on de pruebas y evaluaciones Sabiendo c´omo entrenar, lo ´unico que resta por explicar es c´omo hacer las pruebas y, a partir de los resultados obtenidos, calcular las m´etricas de precisi´on y robustez. B.3.1. Ejecuci´on de pruebas Para ello, lo primero es disponer dentro de experiments de una carpeta en la que almacenar todo lo necesario. Se recomienda encarecidamente crear una carpeta separada a la que se use para el entrenamiento, para separar mejor cada parte, de hecho, en la carpeta compartida en OneDrive se proporciona el directorio siamrpn r50 l234 dwxccorr MOT. Como siempre, hay que tener el fichero config.yaml, para el cual un punto de partida ofrecido en el propio GitHub de pySOT ser´ıa el siguiente: 1META_ARC: "siamrpn_r50_l234_dwxcorr" 2 3BACKBONE: 4TYPE: "resnet50" 5KWARGS: 6used_layers: [2, 3, 4] 7 8ADJUST: 9ADJUST: true 10 TYPE: "AdjustAllLayer" 11 KWARGS: 12 in_channels: [512, 1024, 2048] 13 out_channels: [256, 256, 256] 14 15 RPN: 16 TYPE: ’MultiRPN’ 17 KWARGS: 18 anchor_num: 5 19 in_channels: [256, 256, 256] 20 weighted: true 21 22 MASK: 23 MASK: false 24 25 ANCHOR: 26 STRIDE: 8 27 RATIOS: [0.33, 0.5, 1, 2, 3] 28 SCALES: [8] 29 ANCHOR_NUM: 5 30 31 TRACK: 32 TYPE: ’SiamRPNTracker’ 33 PENALTY_K: 0.05 74 AP´ ENDICE B. MANUAL DE USUARIO 34 WINDOW_INFLUENCE: 0.42 35 LR: 0.38 36 EXEMPLAR_SIZE: 127 37 INSTANCE_SIZE: 255 38 BASE_SIZE: 8 39 CONTEXT_AMOUNT: 0.5 A partir de aqu´ı, ser´ıa conveniente distinguir las modificaciones a realizar para los experimentos que no parten de un cambio de la arquitectura y los que s´ı. Consideraciones propias de pruebas que no modifican la arquitectura Lo primero de todo es disponer en ese caso de unos pesos preentrenados. Para ello, se dispone del fichero model.pth ya mencionado en otras ocasiones. Con ese modelo es con el que se consiguen los resultados de las llamadas pruebas base. A partir de ah´ı, el contenido mostrado previamente se corresponde con el formato que debe tener el config.yaml para hacer las pruebas base. Las modificaciones que se indican a continuaci´on permiten ejecutar las dem´as variantes que no requieren cambios de arquitectura: Para empezar, es necesario modificar el par´ametro TRACK.TYPE, para que pase a tener el valor ’SiamRPNMOTTracker’. Esto se hace porque se ha definido una clase diferente para hacer el seguimiento considerando los mapas de calor negativos (con or´aculos o sin ellos). Con este cambio, seg´un la prueba a aplicar, hay que establecer determinadas combinaciones de otros par´ametros, todos ellos dentro de TRACK: •Para la variaci´on b´asica, hace falta mantener el par´ametro cuyo nombre es TRACK.NEGATIVES PENALIZATION con el valor False. Todo lo dem´as puede mantenerse. •Si se desea aplicar una normalizaci´on entre 0 y 1 de los mapas de calor adaptados, se puede dar al par´ametro TRACK.NORMALIZATION SCORES el valor zero one. •Si se desea hacer la penalizaci´on sobre los negativos, simplemente hay que darle al par´ametro TRACK.NEGATIVES PENALIZATION el valor True. •En los or´aculos, hay que ajustar el par´ametro TRACK.MODE: ◦Para el or´aculo colocando rect´angulos proporcionales al delimitador, darle el valor ’oracle sq crop’. ◦Para el or´aculo colocando gaussiana seg´un el rect´angulo delimitador, darle el valor ’oracle gauss’. B.3. EJECUCI ´ ON DE PRUEBAS Y EVALUACIONES 75 ◦Para el or´aculo aplicando recorte al mapa de calor seg´un el delimitador, darle el valor ’oracle bbox score’. •En caso de querer que los negativos penalicen la mitad (como se hizo en las pruebas del or´aculo), poner el par´ametro TRACK.NEGATIVES PX con valor 0.5. Consideraciones propias de pruebas que s´ı modifican la arquitectura En este caso se tiene no que pasar los pesos preentrenados, sino facilitar los pesos salientes del entrenamiento que se deseen. En la carpeta snapshot dentro de la del experimento en el que se realiz´o dicho entrenamiento, se incluyen los pesos otorgados a la red tras cada ´epoca, que seguir´an la convenci´on checkpoint eX.pth (con X un n´umero representando la ´epoca). Se deben mover o copiar desde esa carpeta los ficheros deseados a aquella en la que se vayan a ejecutar estas pruebas de seguimiento. A partir de ello, se debe modificar el fichero config.yaml (partiendo de la base mostrada previamente), teniendo en cuenta las siguientes consideraciones: Como suced´ıa en el entrenamiento, hay que cambiar el par´ametro RPN.TYPE por el valor ’MultiRPNMod’. Adem´as, es necesario modificar TRACK.TYPE. En este caso, se le dar´a el valor ’SiamRPNTrackerRPNMod’, que es el nombre que recibe la clase que se usa en este tipo de pruebas. Finalmente, hay que modificar tambi´en algunos par´ametros que se hab´ıan configurado para entrenamiento, pero que aqu´ı tienen repercusi´on en la arquitectura del sistema: •TRAIN.CONSIDER NEG: tiene que ponerse a True. •TRAIN.NEG MODE: tiene que tomar el valor que tuviese en el entrenamiento correspondiente. •TRAIN.NUM NEGATIVES: en caso de variarlo de 3 en el entrenamiento (que es el valor por defecto), tambi´en se debe modificar en este punto. Comando para ejecutar pruebas de seguimiento Conociendo todos estos supuestos, lo siguiente que se debe hacer es ejecutar las pruebas de seguimiento. En la carpeta del experimento correspondiente, se debe copiar el contenido del conjunto de datos de la carpeta datasets que se desee, y luego ejecutar el comando siguiente: python3 ../../tools/test.py --snapshot nombre_modelo.pth --dataset nombre_conjunto --config config.yaml 82 BIBLIOGRAF´ IA [34] Python. (21 de mayo de 2022). Wikipedia, La enciclopedia libre. Fecha de consulta: 22 de Mayo de 2022, desde https://es.wikipedia.org/w/index.php?title=Python [35] NumPy documentation (Versi´on 1.22, 2022). Fecha de consulta: 22 de Mayo de 2022, desde: https://numpy.org/doc/stable/. [36] PyTorch documentation (Versi´on 1.11.0, 2019). Fecha de consulta: 22 de Mayo de 2022, desde https://pytorch.org/docs/stable/index.html. [37] Pandas documentation (Versi´on 1.4.2, 6 de abril de 2022). Fecha de consulta: 24 de Mayo de 2022, desde: https://pandas.pydata.org/docs/. [38] OpenCV documentation (Versi´on 4.5.5-dev, 2022). Fecha de consulta: 24 de Mayo de 2022, desde: https://docs.opencv.org/4.x/index.html. [39] Matplotlib documentation (Versi´on 3.5.2, 2022). Fecha de consulta: 24 de Mayo de 2022, desde: https://matplotlib.org/stable/index.html. [40] C. Heindl: py-motmetrics. GitHub (24 de abril de 2022). Fecha de consulta: 24 de Mayo de 2022, desde: https://github.com/cheind/pymotmetrics. [41] Docker documentation (2022). Fecha de consulta: 26 de Mayo de 2022, desde: https://docs.docker.com/. [42] Conda documentation (Revisi´on 5812c98c, 2017). Fecha de consulta: 26 de Mayo de 2022, desde: https://docs.conda.io/en/latest/. [43] Documentation for Visual Studio Code (2022). Fecha de consulta: 27 de Mayo de 2022, desde: https://code.visualstudio.com/docs. [44] Documentation. Overleaf, Online Latex Editor. Fecha de consulta: 27 de Mayo de 2022, desde https://www.overleaf.com/learn. [45] Draw. LibreOffice en espa˜nol. Fecha de consulta, 27 de Mayo de 2022: desde https://es.libreoffice.org/descubre/draw/. [46] Almacenamiento personal en la nube: Microsoft OneDrive. Microsoft. Fecha de consulta: 27 de Mayo de 2022, desde https://www.microsoft.com/eses/microsoft-365/onedrive/online-cloud-storage. [47] GitHub Documentation. Fecha de consulta: 27 de Mayo de 2022, desde https://docs.github.com/es. BIBLIOGRAF´ IA 83 [48] J. Brownlee: Difference Between a Batch and an Epoch in a Neural Network. Machine Learning Mastery (20 de Julio de 2018). Fecha de consulta: 19 de Mayo de 2022, desde https://machinelearningmastery.com/difference-between-a-batch- and-an-epoch/. [49] Batch normalization (23 de Febrero de 2022). Wikipedia, The Free Encyclopedia. Fecha de consulta: 19 de Mayo de 2022, desde https://en.wikipedia.org/w/index.php?title=Batch normalization. [50] J. Brownlee: A Gentle Introduction to the Rectified Linear Unit (ReLU). Machine Learning Mastery (20 de Agosto de 2020). Fecha de consulta: 19 de Mayo de 2022, desde: https://machinelearningmastery.com/rectifiedlinear-activation-function-for-deep-learning-neural-networks/. [51] Funci´on gaussiana (29 de marzo de 2022). Wikipedia, La enciclopedia libre. Fecha de consulta: 30 de mayo de 2022, desde: https://es.wikipedia.org/w/index.php?title=Funci%C3%B3n gaussiana. [52] S. Sun, N. Akhtar, H. Song, A. Mian, M. Shah: Deep Affinity Network for Multiple Object Tracking. En IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 43: 104-119 (2021). [53] F. Yang, W. Choi, Y. Lin: Exploit All the Layers: Fast and Accurate CNN Object Detector with Scale Dependent Pooling and Cascaded Rejection Classifiers. En IEEE Conference on Computer Vision and Pattern Recognition: 2129-2137 (2016). [54] P. F. Felzenszwalb, R. B. Girshick, D. A. McAllester, D. Ramanan: Object Detection with Discriminatively Trained Part-Based Models. En IEEE Transactions on Pattern Analysis and Machine Intelligence, vol. 32: 1627- 1645 (2010). [55] MOT17 Challenge data. MOT Challenge. Fecha de consulta: 13 de junio de 2022, desde: https://motchallenge.net/data/MOT17/. [56] M. Kristan et. al: The Visual Object Tracking VOT2014: Challenge and results. VOTChallenge (6 de Septiembre de 2014). Fecha de consulta: 3 de junio de 2022, desde: https://www.votchallenge.net/vot2014/download/vot 2014 presentation.pdf [57] ImageNet Large Scale Visual Recognition Challenge 2017 (ILSVRC2017). ImageNet. Fecha de consulta: 7 de junio de 2022, desde: https://imagenet.org/challenges/LSVRC/2017/. 84 BIBLIOGRAF´ IA [58] YouTube-BoundingBoxes Dataset. Google Research. Fecha de consulta: 7 de junio de 2022, desde: https://research.google.com/youtube-bb/. [59] COCO - Common Objects in Context. Fecha de consulta: 7 de junio de 2022, desde: https://cocodataset.org/#home.