Reporte de Proyecto: Control de Calidad en Esmaltes de Azulejos

Repositorio : https://github.com/alexgzz/Vision-Computacional

Propósito:
La idea es desarrollar un sistema de control de calidad de tonos para el esmaltado de piezas cerámicas(azulejos, mosaicos, piso, etc), que pueda apoyar directamente en la línea de producción sin la necesidad de hacer pruebas en otros lados alejados a esta.

Basandose en la comparación de un master(color de referencia) con otras muestras(las piezas a evaluar en la línea de producción), esta información es procesada individualmente para cada valor RGB de la pieza y la información es mostrada de la misma forma, para facilitar la corrección de los tonos, con la posibilidad de corregir solo uno de los tres valores.

Alcance:
En este momento sería una mera demostración del proyecto y las funciones que se puedan llevar a cabo, pero sería buena idea que sistemas como este llegaran al mercado y que tal vez en un futuro, después de ya aprobados sus alcances, se pueda convertir en el estándar y sustituir a las actuales herramientas.

Justificación:
La principal ventaja de este sistema es la comparación del tiempo que tarda este en analizar las variaciones de tono contra el tiempo invertido en realizar esta operación como se realiza actualmente con un instrumento llamado colorímetro.

Colorímetro 
tomada de http://www.discaf.com/colorimetro.jpg

El tiempo que se invierte con el colorímetro es aproximado a los 5min, y si se estima que cada segundo sale una pieza en la linea de producción, se estarían pasando 300 piezas antes de regresar y tomar una decisión, mientras que con el sistema que se propone que tarda entre .1 y .3 segundos, por lo que se podría decir que se estaría analizando el cien por ciento de la producción.

Herramientas:

• Python 2.6.6
• OpenCV 2.1
• PIL 1.7
• Numpy (última versión)

Es importante las versiones de las librerías, ya que OpenCV 2.1 solo trabaja bien con Python 2.6.6 en sus versiones para Windows.

De todas las librerías se hizo uso de sus versiones de 32 bits.

Descripción:

§El programa se ejecuta tomando como argumentos el color de referencia(master) y una tolerancia de variación con respecto al master(en porcentaje).

§Las imágenes se obtienen desde una cámara web(externa), donde se dibuja un recuadro rojo que cambiará a verde si se posiciona el mosaico en frente.
Las imágenes que procesan son muy cercanas a las siguientes, solo que se capturan en tiempo real:

§Con el mosaico posicionado en frente, se procesan los valores de cada pixel del mosaico obteniendo sus promedios por cada valor RGB. 
Para validar que la pieza se encuentra frente a la cámara (la idea inicial era detectar el polígono, pero más adelante se explica porque se cambio) se toma una muestra de color de los cuatro puntos de las esquinas y uno del centro, y se comparan que tan diferentes son y en base a un filtro de tolerancia de variación se evalúa si son "iguales" o "diferentes", si se supera la prueba se procede a al análisis de colores de lo contrario no ocurre nada.
Se optó por este procedimiento para validar que el mosaico cubra totalmente el área de análisis(recuadro rojo) y el resultado sea más confiable.

§Estos valores se comparan con la referencia dada al inicio y se analizan los resultados para validarlos respecto a la tolerancia de variación.
El procedimiento de analizar los colores, lo que hace en esencia es obtener un porcentaje de color para cada valor de RGB en la imagen, recorriendo píxel a píxel el área de análisis, que posteriormente se compara con el master (referencia) para saber cuál es su porcentaje de variación con respecto a este.

§Se notifica si el mosaico superó o no la prueba, y se muestran las variaciones por cada valor RGB del mosaico para sus posteriores ajustes individuales.
Esto debido a que es más fácil rectificar un tono variando de un valor(RGB) en un valor, todo lo contrario si solo decimos no es igual y se modifican de 3 en 3.

Evaluación de Desempeño:

Como ya se mencionó, el tiempo es la principal métrica en este proyecto que al compararlo con el tiempo del uso del instrumento lo supera indudablemente.

Tiempo del Proyecto: Aproximadamente .1 a .2 segundo
Tiempo del Instrumento: Aproximadamente 5 minutos

Esto también se vería reflejado directamente en la línea de producción al reducir considerablemente la cantidad de piezas rechazadas o desperdiciadas.

A continuación se muestran gráficas con tiempos de procesamiento que se tomaron durante una ejecución del programa:

En esta gráfica, los 0 ceros indican que no se detecto ningún objeto

Se modificó el código para que solo se incluyeran tiempos en los que se detectaban objetos

Durante el desarrollo siempre se buscó obtener buenos tiempos de procesamiento esto con el fin de mejorar la cantidad de piezas que se analizan y tratando de acercar lo más posible los tiempos de procesamiento a los tiempos de transportación de los mosaicos en la banda que son de aproximadamente 1 segundo, por lo que constantemente se estuvieron tomando decisiones para ayudar a mejorar esto:

• Cambiar la manera en la que se detectan las piezas cerámicas, ya que de esta manera el tiempo de procesamiento era aproximadamente un minuto, siempre y cuando fuera detectada la pieza(se habla más de esto en la parte de "Pendientes"). El procedimiento era "Detección de Polígonos por Esquinas".
• Cambios en los manejos de colores, ya que OpenCV maneja el esquema BGR y PIL usaba RGB, había que hacer un procedimiento para hacer esa conversión. Primero la imagen obtenida de la cámara se convertía de BGR a RGB, después se procesaba y al final se convertía de nuevo de RGB a BGR para poder ser mostrada correctamente en la ventana.
  Pero esto hacia lenta la ejecución, propiciaba retrasos entre las imágenes capturadas y las mostradas, además de que el tiempo de procesamiento era más elevado.

Lo que sucedía si la imagen no se convertía a RGB(se omitió la conversión) o no se procesaba como BGR(se implementó este manejo), era que los valores de rojo y azul intercambiaban posiciones por lo que la imagen se tornaba en tonos raros:

La primera imagen se manejan los valores (rojo, verde y azul) normales y en la segunda se intercambian (rojo y azul)

La primera imagen se manejan los valores (rojo, verde y azul) normales y en la segunda se intercambian (rojo y azul)

A continuación una gráfica de tiempos de procesamiento, involucrando la conversión de BGR a RGB y viceversa:

Tiempos de procesamiento incluyendo conversiones de BGR a RGB y viceversa.

Al final para mejorar los tiempos de ejecución se hicieron ligeras modificaciones en el código para que los esquemas de colores de manejaran en formato BGR y así evitar el proceso de conversión.

Todo el desarrollo y las pruebas de rendimiento se llevaron a cabo en una laptop con las siguientes características:

Y como ya se mencionó, la cámara que se usa es una webcam externa(para mejorar la calidad de las imágenes a procesar debido a que la integrada en la laptop producía imágenes de muy baja calidad y afectaban el rendimiento de la aplicación) conectada por USB a la computadora, el modelo es FaceCam 1000 de la marca Genius y aquí dejo las especificaciones de la cámara para más referencia:

Cámara utilizada en el proyecto
tomada de http://www.geniusnet.com/wSite/public/Data/f1289813424739.jpg

Especificaciones de la cámara
tomadas de http://www.geniusnet.com/wSite/ct?xItem=46781&ctNode=161

Pendientes:

• Como se menciona en las diapositivas, es necesario mejorar el programa en el apartado de la detección de las piezas cerámicas, ya que en un principio todo el desarrollo se centraba en detectar las piezas mediante la técnicas de "Esquinas", haciendo uso de "Filtro Medio", "Escala de Grises", etcétera, pero todo esto se tuvo que sustituir aproximadamente a 2 días de la entrega, ya que como se estuvo construyendo todos los componentes por separado, todos funcionaban bien, pero al momento de ensamblarlos todos y hacer pruebas con las imágenes capturadas desde la cámara, no funcionaba correctamente, ya que los altos niveles de ruido hacían que al detectar las esquinas no solo se detectaran cuatro, sino cientos de "esquinas", por lo que no se podía proceder como si fuera un polígono. Una muestra de esto a continuación:

  

  Muestra de la imagen en la que deberían resaltar las esquinas del mosaico, es decir  4 putntos.

                        

Trabajo a Futuro:

• Mejor los procedimientos en la obtención de las imágenes, ya sea implementando funciones propias en base a software (filtros, pre-procesamientos, etc.) o en base a la inclusión de hardware de más calidad (la cámara). 
• Establecer un cierto orden en las condiciones necesarias para garantizar buena calidad en las imágenes que se capturan, como lo pueden ser: controlar la iluminación (muy importante) y la temperatura(ciertos componentes que afectan en los colores de las piezas cerámicas pueden variar con la temperatura por lo tanto podrían hacer que variara el tono.) del espacio donde se trabajará.
• Lo anterior se podría traducir en una pequeñas cabinas o cubiertas que ayuden al aseguramiento de esos factores.
• La implementación de un sistema embebido que en base a la información obtenida por la aplicación ayude a tomar decisiones a los empleados en la línea de producción.

Otras aplicaciones:

• Sistemas de Igualación de Tonos: Son usados en empresas dedicadas a la comercialización de pinturas. Se basan en el mismo proceso que este proyecto.
• Anomalías en Tejidos(detectables por análisis de colores), por ejemplo: inflamaciones, tejidos necrosados, enfermedades de la piel, etcétera.

Presentación:

VIDEOS, (también dejo los enlaces por que blogger me dice que no existe ningún video cargado en mi cuenta):

http://www.youtube.com/watch?v=Wscqqfq5mLU
http://www.youtube.com/watch?v=hqVArhmJT5w
http://www.youtube.com/watch?v=NUjqECo-IoQ


________________________________________________________________________
Referencias:

"OpenCV 2.1  Python Reference", http://opencv.willowgarage.com/documentation/python/
**La información relacionada con las piezas cerámicas y sus procesos fue proporcionada por empleados de una empresa dedicada a ese ramo.

Actividad #10 Lab - Detección de Movimiento

Lo único que hace el código es obtener los centros de dos imágenes con figuras, lo hace mediante la detección de figuras y centros de éstas con bfs.

Después de encontrar los centros los compara y en base a condiciones arroja si ocurrió o no movimiento.

Usé dos imágenes con la misma figura en diferente posición, (la webcam integrada de mi laptop aparece como desconectada).

Las imágenes pasaron por el proceso de escala de grises, convolución y binarización.


Aquí el código:

Las imágenes que arroja solo se marcan los centros de cada figura:

Y una captura de la ejecución del script donde muestra la información del movimiento:

Actividad #9 Lab - Detección de Esquinas

Para esta actividad de detectar esquinas, (para posteriormente identificar polígonos) se utilizó el método del filtro mediano, que consiste en tomar uno a uno los píxeles (sus valores) y ordenarlos de mayor a menor, para posteriormente tomar el del centro y ese valor va a sustituir el valor del píxel original.

Aquí la imagen con que inicie(escala de grises) y el resultado después del filtro:

Escala de Grises

Con Filtro Mediano

Si prestamos un poco de atención, después de aplicar el filtro, la imagen se ve casi igual a excepción de las esquinas que están un poco borrosas.

Posterior a esto, se comparan los valores de la imagen original con la que se le aplico el filtro, este proceso hará que se resalten las esquinas borrosas del proceso anterior y también se irán obteniendo sus coordenadas, además se pone un filtro para tratar de eliminar la mayor parte de ruido, sin afectar los puntos de las esquinas.

Aquí el código de todos los procesos:


Ya con los puntos de las esquinas localizadas, solo se dibujan las líneas de punto a punto, el resultado es el siguiente:

Como se puede observar en la imagen aún tiene ruido y es por eso que además del cuadrado, las líneas forman otra figura, resultado de un par de puntos indeseables que superaron el filtro.

Link a mi Git

Act #8 Lab - Detección de Poligonos

En esta tarea el objetivo era crear un script capaz de detectar polígonos regulares en imágenes, el procedimiento que seguí es el descrito en las diapositivas de clase.

El código es el siguiente:


No jala como debería, ya que colorea todo el polígono de color rojo y solo deberían ser los contornos.
Los resultados:

_________________________________________________________________________________
Referencias:
http://elisa.dyndns-web.com/~elisa/teaching/comp/vision/poligonos.pdf

Actividad #7 Lab - Pre-procesamiento para detección de agujeros

La tarea de laboratorio de este semana era hacer una especie de pre-procesamiento para la actividad de clase de detección de agujeros. Ya que se usaría el método de histogramas para encontrar los agujeros, en esta parte lo que se haría era precisamente eso, hallar la forma de crear los histogramas y la forma de interpretarlos para la detección de agujeros.

El código es una parte del que se mostró para la tarea de clase, solo con los agregados de imprimir los resultados de los histogramas directamente en un archivo .txt con cierto formato para su posterior interpretación de gnuplot(crear las gráficas).

El procedimiento es, se va recorriendo por filas o columnas la imagen y se van sumando las intensidades de los píxeles (la suma de los valores rgb dividido entre 3), estas sumas se van agregando a los archivos .txt, después los valores pasas por filtros(mínimos locales) para obtener solo los de menor intensidad (se acercan mas a color negro).

Ya con los valores obtenidos, solo se busca su posición en los histogramas y esta posición se usa para pintar  las líneas en la imagen y este es el resultados:

Los valores de los histogramas almacenados en los archivos .txt se usan junto con un script de gnuplot para crear las gráficas, el código para esto es el siguiente:

Y la gráfica que resulta de la imagen anterior es la siguiente:

Ejemplos con otras imágenes:

La siguiente es la misma que la anteior, pero recortada y con el color de los hoyos más marcado:

Tarea 6 - Deteccion de Agujeros

La tarea de esta semana es detectar agujeros en imágenes, para esto lo primero que se hizo(la parte del lab) fue checar las intensidades de la imagen sumándolas horizontal y verticalmente, posterior a esto se analizaron los puntos en los que marcaban diferencia en estas sumas y se procedió a pintar lineas que pasaran por estos puntos (independientes verticales y horizontales) y en el punto en el que se cruzaran ahí estaría el agujero.

Esta es la imagen con la líneas(el código esta más abajo):

Posterior para poder identificar correctamente el agujero, se aplico bfs a la imagen donde la misma función de bfs devuelve posibles centros de las figuras que analiza, estos centros se filtraron para quitar centros falsos y se procedió a comparar con los valores por los que cruzaban las lineas de la imagen anterior, si el centro se encontraba en las intersecciones con estos puntos, ese centro era el centro de un agujero.

El código completo:



Al final solo se agregaron las líneas para dar el color morado al agujero, añadir la etiqueta y su centro, además de su área en proporciones de la imagen completa:

El resultado final con centro, color y etiqueta es éste:

_________________________________________________________________________________
Referencias
http://elisa.dyndns-web.com/~elisa/teaching/comp/vision/agujeros.pdf

Actividad #6 Lab - Relleno de elipses/circulos

La meta de esta actividad es rellenar solamente lo que se encuentre dentro de la figura con un color "x" y arrojar la información acerca de su área en proporciones del tamaño de la imágen.

Primero es necesario obtener de la imagen sus bordes y colorear aleatoriamente su contenido (solo el interior), para esto es necesario partir de una imagen binarizada como esta:

y aquí esta el código:



esta es la imagen que arroja el código anterior:

Posterior a esto, la imagen que arroja el script anterior hay que procesarla para que podamos obtener los datos sobre las áreas e incrustar las etiquetas en la imágen, y se hace con el siguiente código:



y esta es la imagen final, ya con los datos y etiquetas:

y una captura de la información que se arroja en el terminal: