4.13. Formatos de píxel

La etapa final del pipeline del ISP empaqueta cada píxel en una disposición de bytes concreta en memoria. El formato elegido equilibra la calidad de la imagen, el tamaño en memoria y cómo el código posterior vuelve a leer los bytes. Un puñado de formatos predominan.

4.13.1. RAW (Bayer)

La salida predeterminada es Bayer en bruto: el mismo mosaico de un canal por píxel que produce el sensor. Un byte por píxel, dispuesto según el patrón Bayer: rojo y verde alternados en las filas pares, verde y azul alternados en las filas impares. No se ha aplicado ningún debayer, así que cada celda contiene solo el valor que dejó pasar su filtro de color.

El Bayer en bruto ocupa un tercio de la memoria de una imagen RGB de tres canales terminada (un byte por píxel frente a tres) y no se ha gastado ningún ciclo del ISP en debayerizarla o convertirla. El coste es que el código de usuario tiene que hacer el debayer él mismo antes de que pueda ejecutarse cualquier procesamiento que tenga en cuenta el color.

4.13.2. RGB888

RGB888 es el formato terminado natural para una imagen en color: tres bytes por píxel, uno para cada uno de los canales rojo, verde y azul a 8 bits por canal. Veinticuatro bits por píxel y algo menos de diecisiete millones de colores distintos.

RGB888 es la referencia conceptual para las imágenes en color terminadas y la mayoría del software externo lo entiende. En hardware embebido su principal inconveniente es el tamaño de píxel de 24 bits: no es múltiplo del tamaño de palabra del procesador, resulta incómodo para la alineación de memoria y es un 50 % más grande que el siguiente formato.

4.13.3. RGB565

RGB565 empaqueta cada píxel en dos bytes: cinco bits de rojo, seis bits de verde, cinco bits de azul. El bit de verde adicional refleja la mayor sensibilidad del ojo al verde, y coincide con el doble peso del canal verde en el patrón Bayer.

RGB565 es el formato de color predeterminado en la OpenMV Cam. Dos bytes por píxel están alineados a 16 bits, lo que encaja con los anchos de datos naturales del MCU: las cargas, los almacenamientos y la aritmética de píxeles se ejecutan a plena velocidad, y muchas operaciones pueden procesar un par de píxeles a la vez. Los píxeles de 24 bits de RGB888 no se alinean de esa forma y pagan un coste en cada acceso. El ahorro de memoria del 33 % frente a RGB888 también suma: QVGA (320 x 240) ocupa 150 KB en RGB565 frente a 225 KB en RGB888, y la diferencia crece con la resolución.

El compromiso es de 65 mil colores distintos en lugar de diecisiete millones. Para la mayoría de las tareas de visión artificial la diferencia es imperceptible, porque los algoritmos reducen el fotograma a representaciones umbralizadas o de detección de bordes que descartan de todos modos la mayor parte del detalle de color. Para la visualización humana, los bits que faltan aparecen como un leve bandeado en los degradados de color suaves, pero no como algo que el ojo detecte de inmediato.

4.13.4. YUV422

YUV422 divide el color de cada píxel en un valor de luminancia (Y) y dos valores de crominancia (U y V), y luego submuestrea la crominancia porque la visión humana es mucho menos sensible a la variación de color que a la de brillo. Cada píxel lleva su propia Y, pero pares de píxeles adyacentes comparten una U y una V. La disposición de bytes de cada par es de cuatro bytes (Y0, U, Y1, V), lo que resulta en dos bytes por píxel de media, idéntico a RGB565.

Sin embargo, los dos bytes significan cosas distintas que en RGB565. El canal Y por sí solo es una imagen en escala de grises de 8 bits lista para usar, que es lo que en realidad consumen la mayoría de los algoritmos clásicos de visión artificial (detección de bordes, coincidencia de plantillas, análisis de manchas (blobs)); los canales U y V llevan la información de color para el pequeño número de algoritmos que la necesitan.

YUV422 es la opción correcta cuando el pipeline necesita ambas cosas (un algoritmo de etapa temprana que lee solo Y seguido de una etapa posterior que usa la croma para decisiones de color más finas), porque los valores Y están ahí mismo listos para usar sin una conversión de espacio de color.

4.13.5. Escala de grises

La escala de grises es de un byte por píxel: solo el valor de luminancia, sin color alguno. Es el formato terminado más pequeño: la mitad del tamaño de RGB565 y YUV422, un tercio del tamaño de RGB888.

La mayoría de los algoritmos clásicos de visión artificial trabajan de todos modos en escala de grises, así que descartar el canal de color directamente a la salida del sensor es a menudo la opción más sencilla y eficiente en memoria. La detección de bordes, la búsqueda de líneas, el análisis de manchas (blobs), la decodificación de códigos QR, la coincidencia de plantillas y la detección de AprilTag se ejecutan todos en escala de grises y se benefician del búfer más pequeño.

4.13.6. Otros formatos

Algunos formatos que la OpenMV Cam puede producir no salen del pipeline del ISP como parte del flujo normal.

BINARY es de un bit por píxel: la representación más pequeña posible. Se usa para imágenes umbralizadas, búferes de máscara y la salida de cualquier operación que distinga únicamente entre coincidencia y no coincidencia en cada píxel.

JPEG es un formato de color comprimido. Algunos sensores incluyen un codificador JPEG en el chip y pueden entregar fotogramas comprimidos en JPEG directamente; para los sensores que no lo tienen, el MCU ejecuta un codificador JPEG sobre un fotograma RGB o en escala de grises terminado tras el ISP. En cualquier caso, la salida es un flujo de bits JPEG, útil para guardar fotogramas en almacenamiento o enviarlos por un enlace de ancho de banda limitado.

PNG es un formato comprimido sin pérdidas. Los sensores no producen PNG directamente; el MCU comprime un fotograma RGB o en escala de grises terminado bajo demanda. Resulta útil cuando el ancho de banda o el almacenamiento importan pero la compresión con pérdidas que aplica JPEG descartaría información que la aplicación necesita después.