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.