Sobre los algoritmos de debayerización (revelado RAW)

[jwackito]

Hola gente. Desde que emprendí el viaje de escribir mi propio driver, he llegado a costas insospechadas. Uno de los notables paisajes que pude observar tiene que ver con como se transforman las imágenes capturadas por nuestros sensores color a verdaderas imágenes en colores.

Como la mayoría de ustedes sabrá, los sensores color de las cámaras digitales que estamos acostumbrados a ver por ahí están compuestos de una matriz de foto receptores de 3 colores (rojo®, verde (G) y azul (B)) pero cada uno de estos receptores solo puede capturar uno de los colores. Las matrices tienen una línea de sensores rojos y verdes, la siguiente de verdes y azules, la siguiente de rojos y verdes y así, es decir que por cada foto, hay el doble de información para el canal verde que para los otros dos. Esta matriz se llama filtro de Bayer en honor a Bryce Bayer, quien desarrollo este tipo de filtros para Kodak allá por el año 1976.

Los algoritmos de captura de las cámaras comerciales generalmente incluyen los siguientes pasos

1)adquisición de la señal

2)debayerización

3)reducción de ruido

4)compresión (a jpeg, por ejemplo)

Cuando en fotografía decimos que es mejor sacar en RAW, es por que podemos interrumpir este algoritmo luego de la parte de adquisición. Amén de que el proceso de reducción de ruido (ni hablar de la compresión) eliminan datos a veces muy valiosos, durante el proceso de debayerizado también se pierde cierta información. La ventaja de tener los datos crudos es que no dependemos del algoritmo de debayerización de la cámara, el cual dependiendo de la calidad de la cámara, puede no ser muy bueno.

Existen varios algoritmos de debayerización, pero entre los más importantes quería comentar estos cuatro:

Nearest Neighbor (los vecinos más cercanos):

Es de los algoritmos más sencillos pero el que peores resultados visuales arroja. Resulta sumamente fácil de implementar, ya que por ejemplo, si quiero saber el valor de rojo pero para un pixel verde o azul, simplemente me copio el valor de el pixel rojo más cercano que tenga (generalmente el de la derecha o el de arriba. Este método produce todo tipo de artefactos en imágenes con bordes muy marcados (en frecuencias altas). Una estrella blanca sobre el fondo negro tendrá en los bordes pixeles rojos, azules y verdes.

Bilinear interpolation (interpolación bilineal):

Este algoritmo es levemente más complicado que el anterior. Se basa en que una propiedad que cumplen casi todos los pixeles y es que todo pixel de valor desconocido, tiene 4 vecinos con valores para ese canal que sí se conocen. Lo que hacemos para calcular el valor de un pixel rojo para el cual no tenemos información es promediar el valor de sus 4 vecinos rojos más próximos. Este algoritmo produce imágenes con bordes suaves, tantos artefactos como con el método anterior, a costa de que se ven afectadas las frecuencias altas. En el caso de una estrella blanca sobre fondo negro, se verá rodeada por un halo suave multicolor, ya que los pixeles que no se conocen en el borde de la estrella se promedian con información de la estrella e información del fondo.

Smooth hue transition interpolation (Interpolación por transición de tonos suaves o algo por el estilo):

Este algoritmo se basa en un argumento que dice que el color (tono) de una imagen cambian mucho más lentamente que el brillo (luminosidad). Por lo tanto se trata de reproducir imágenes con cambios graduales en el tono (hue). Esto se logra haciendo una interpolación similar a la bilineal pero interpretando la información como luminancia y crominancia en lugar de como colores en si. Primero se interpola el canal verde ya que hay mucha más información para este canal respecto de los anteriores. Luego se calcula la cantidad de tonos rojos para un pixel desconocido como R/G, es decir al relación entre el rojo y el verde. La interpolación es similar al método anterior, es decir que en caso de no conocer la cantidad de rojo para un pixel dado, se interpola con dos o cuatro vecinos. Si bien no se producen artefactos de colores como el los dos casos anteriores, las frecuencias altas se ven degradas y los bordes filosos en la imagen original se verán difuminados.

Variable number of gradients (Número de gradientes variable):

Por lejos, la mejor técnica de las cuatro y también por lejos, la más demandante en cálculos (ya volveremos sobre este tema). Este algoritmo trata de mejorar la respuesta a las zonas de altas frecuencias, es decir donde hay bordes muy marcados. En tratamiento de imágenes se suele ver a una imagen como una función de dos variables. Quienes recuerdan sus clases de álgebra lineal, recordarán que el gradiente es un vector de derivadas que indican la dirección y velocidad de cambio en una función y de ahí el nombre del método. Y es que en los bordes de una estrella, la intensidad varía abruptamente pero no en cualquier dirección. Si estamos interpolando en cercanías de un borde vertical, podemos no interpolar respecto a los vecinos horizontales y así evitar que se degraden las altas frecuencias.

Estas descripciones no son ni por asomo exhaustivas, por el contrario, este es un campo de estudio en permanente crecimiento y en cada simposio de tratamiento de imágenes aparecen algoritmos nuevos que mejoran o estudian tal o cual aspecto. Sin embargo es una buena introducción acerca de que podemos esperar de estos algoritmos y acerca de por que algunos son mejores que otros.

A modo de resumen, si bien los algoritmos Nearest Neighbor y Bilinear interpolation son sencillos, no arrojan buenos resultados aunque en la práctica (sobre todo la interpolación bilineal) se utilizan a menudo cuando hay que hacer una previsualización rápida del resultado ya que no son demandantes en cuanto a tiempos de cómputo. Por otra parte, sobre todo el método de VNG, donde hay que calcular varias derivadas por cada pixel, a veces no pueden ser utilizados en los procesadores gráficos de las cámaras digitales y por ello se prefiere trabajar en RAW para hacer el procesado en una computadora y así aplicar algoritmos mejores.

Para aquellos que este artículo haya despertado la curiosidad y no se sientan satisfechos, no duden en pedirme material (tengo pilas de pdfs, lamentablemente todos en inglés) o alguna explicación extra donde quieren que profundice. Actualmente estoy trabajando en implementar el método de VNG como paso previo a procesar con otros programas.

Saludos cordiales y buenos cielos.

[Nachit]

Muy buena la informacion. La verdad que entendi todo muy por arriba pero muy interesante. Muchas gracias por la info!!

[ricardo]

Excelente explicación a un tema que todos los que hacen fotografía deberían considerar leer tu post. Por esta razón software como el pixinsight, nebulosity y otros traen rutinas de debayerizado (o bayerizado) para las imágenes de cámaras color.

Si bien es un tema técnico, te agradezco por traer estos temas al foro, son muy interesantes para sacarnos muchas dudas y entender todos los porque al momento de procesar una imagen. Gracias por compartir.

Saludos y buenos cielos!

[Astroman]

Hola:

Gracias por publicar este excelente trabajo. Pretigia a EP...

Veré como lo puedo ir atacando, de a poco, para tratar de entender algo...

Saludos RGF

[Jorge Di Tata]

Gracias por la info Juaquito

Muy bien explicada, muy claro todo

saludos

[claudio022]

Muy buena información y además bien explicada. Aunque no hago fotos, me parece muy interesante para ir comprendiendo de a poco este apasionante mundo de la fotografía.

Saludos.

[carlosdn]

Muy buena explicacion amigo, realmente interesante!

Saludos

[jwackito]

Hola a todos. Gracias por comentar. La intensión del post no era que salgan entendiendo como funcionan los algoritmos sino más bien introducir el tema como para saber que esperar de cada método, saber que existen y sobre todo para ver si despertaba el interés de los foreros por saber.

Como veo que hay interés, voy a ver si armo alguna explicación más detallada de los métodos particulares, de nuevo, a modo introductorio. Muchas de las cosas que vi durante mis lecturas me pasaron por arriba ya que van mucho más allá de mis conocimientos de álgebra lineal.

Si bien son temas técnicos como dice Ricardo, también me parece muy importante saberlos (aunque sea saber que existen) para aquellos que hacemos astrofotografía.

Saludos y buenos cielos.

[Alejandro]

Excelente post!!

Lo pongo en sticky.

Saludos

[matitoma]

Muy interesante joaquin!

[ignacio_db]

Que bueno Juaquito, que compartiste esta info, ya que es un tema muy relevante para los que hacemos fotos con cámara color. En su momento los investigué, y coincido que el método VNG pueda ser el más adecuado para lo nuestro, aunque existen un montón más (algunos muy sofisticados/complejos), por ejemplo AHD (incluido en DSS) que también da buenos resultados.

El tema es que todos éstos métodos son desarrollados y evaluados para fotografía diurna normal, donde se hace una sola toma con buen nivel de señal. En astrofotografía, hacemos muchas tomas, que por lo general están algo desplazadas unas de otras (por dithering, flexión diferencial, etc.), por lo que es probable que cada color RGB sea muestreado una cantidad de veces en cada punto espacial, y que en principio no haga faltar interpolar.

Esto es lo que hace el Bayer Drizzle de DSS (ver http://www3.asiaa.sinica.edu.tw/~whwang ... index.html ), aunque por lo general no obtengo buenos resultados con el DSS (comparado con Pixinsight, en lo que hace a calibración y apilado).

Hace rato que estoy en contacto con los desarrolladores de Pixinsight, tratando de convencerlos que incluyan un método de éste tipo, que evita la interpolación. Dicen estar trabajando en eso, en una forma todavía más amplia, llamada genéricamente "super resolución".

saludos

Ignacio

[jwackito]

Que bueno que sacaste el tema de superresolución Ignacio. Ahora escribo algo sobre eso. Hay un método mejor que el Adaptive Homogeneity-Directed, desarrollado por Lanlan Chang y Yap-Peng Tan (indonesios) y que lleva su nombre (Chang Tan). Se trata de un método híbrido que mejora la relación señal ruido (más precisamente la Peak Signal-to-Noise Ratio) a pesar que tiene más o menos la misma complejidad computacional en cuanto a operaciones por pixel. No encontré el paper en el quilombo de carpetas que tengo, pero si te interesa lo busco y te lo paso o lo subo al foro.

Abrazo y gracias por comentar.

[ignacio_db]

Creo haber leído de ese método. Subilo.

La idea de debayerizar y apilar al mismo tiempo, optimizando la reconstrucción de la imagen (superresolución), esta bien explicada en éste paper (en inglés y bien técnico): http://people.duke.edu/~sf59/TIP_Demos_Final_Color.pdf

Entiendo que los de PI están trabajando con esa idea.

slds

Ignacio

[jwackito]

Si, lo tengo estudiado a ese paper. Pero todavía no termino de entender como escribir algunos de los operadores. Acá se ataca el problema de la debayerización y de la superresolución como dos instancias particulares de un mismo problema que se venia atacando por separado, ya que en métodos anteriores, primero se debayerizaba y luego se aplicaban técnicas de superresolución a los canales por separado.

Este algoritmo interesante para imágenes astronómicas ya que en general no tenés rotación de campo u otras transformaciones en las imágenes, sino que solo están trasladadas en x o y, unas respecto de las otras. De otra forma, el método así descripto no podría aplicarse. Aunque sospecho que se puede generalizar para otras transformaciones además de la traslación.

[norbertolec]

Muy buena información , excelente trabajo...

[Pablo-Salvatore]

Hola @jwackito, te felicito por la dedicación para aclarar este tema. Mencionás que desarrollaste un driver, supongo que para parsear archivos RAW. Por favor, me interesa recibir la información que dispongas para poder extraer el valor de nivel de señal crudo de cada pixel.

 

Saludos! 

[jwackito]

Hola @Pablo-Salvatore. Al nivel que estuve laburando yo, la cámara no te devuelve archivos RAW (con formato, como los de Canon), te devuelve un stream de bytes. Parte del trabajo de tesis fue darle sentido a esos bytes. Lo que hice después para no meterme en el tema de crear un RAW con formato es utilizar un formato sin compresión que se llama NetPBM (http://netpbm.sourceforge.net/doc/index.html), muy sencillo que en linux se puede abrir con cualquier cosa. Además de eso usé FITs, que también me resultó bastante fácil de usar. En todos los casos, los pixels se escriben en el archivo sin compresión y sin información de debayerización, es decir, se escribe solo la intensidad de cada pixel en el archivo como un número entre 0 y 255 si es una imagen de 8 bits o de 0 a 65535 si es de 16 bits. Pero justamente eso es lo que me devolvía la cámara, un array de intensidades de pixels al cual yo tenía que darle la dimensión que correspondiera de acuerdo a la resolución configurada en ese momento. No se si me expliqué bien...

En cualquier caso, podes leer la tesina que lejos de ser una sarta de tecnicismos (si bien los tiene) creo que es bastante accesible.

 

El archivo lo deberías pode encontrar en el repositorio de la Universidad Nacional de La Plata (http://sedici.unlp.edu.ar) con el rimbombante título de "Driver para GNU/Linux en espacio de usuario para la cámara QHY5T", pero recién en unos días, por que lo subí hoy y lo están revisando. Si no mandame por privado un email y te forwaredeo el pdf.

 

Saludos cordiales,

JJ.

[Pablo-Salvatore]

Genial lo tuyo, desarrollaste entonces un driver de comunicaciones con la qhy5t! En mi caso tendría que hacer lo mismo pero con una Sony Alpha lamentablemente no encontré info sobre su protocolo por eso pretendo trabajar al menos con el archivo Raw. Muchas gracias por tu ayuda! 

[fsr]

Muy interesante!

DSS también tiene un método que en vez de pretender interpolar la información para tratar de adivinar el valor de los colores que faltan, simplemente reduce la resolución a la mitad y usa los valores reales de los 4 colores registrados por el sensor. Muy sencillo, pero tenés la mitad de la resolución horizontal y vertical.

[Pablo-Salvatore]

1 hour ago, fsr dijo:

Muy interesante!

DSS también tiene un método que en vez de pretender interpolar la información para tratar de adivinar el valor de los colores que faltan, simplemente reduce la resolución a la mitad y usa los valores reales de los 4 colores registrados por el sensor. Muy sencillo, pero tenés la mitad de la resolución horizontal y vertical.

Exactamente. Por eso quisiera obtener los valores reales e intentar compensar solamente las curvas de los filtros R y B respecto de G a costa de obtener una imágen en escala de grises. Estimo que de esta forma la información captada será más representativa.

[jwackito]

@Pablo-Salvatore

Mmmm, nop. No funciona así. En una cámara color, un pixel rojo (R) es solamente rojo, uno verde (G) es solamente verde y así. Cuando capturas información de una fuente de luz blanca (como cuando haces flats) el pixel R solo va a juntar información acerca de la cantidad de luz roja emitida por la fuente blanca, el G acerca de la verde y así. Pero si extrapolamos esto a una fuente de luz roja (imaginate una estrella muy vieja, o una estrella de carbón, como estas estrellas no emiten casi luz verde o azul, en todos los pixels G y B no vas a tener información. Por ejemplo, si el perfil sin filtrar de una estrella de carbon arroja estos valores (en una cámara mono, por ejemplo)

 

000 010 015 040 200 210 205 208 200 045 010 000

000 010 015 040 200 210 205 208 200 045 010 000

 

en una cárama con una martriz de bayes RGGB donde los pixels están ordenados

RGRGRGRG

GBGBGBGB

la misma estrella probablemente se vea en esa cámara de esta manera

 

000 000 015 000 200 000 205 000 200 000 010 000

000 000 000 000 000 000 000 000 000 000 000 000

 

Es decir, no podes reconstruir el valor de rojo en los pixels que no son rojos, salvo interpolando los valores de los vecinos.

Saludos.

 

[jwackito]

Ahí me aceptaron la tesis en el repositorio. Está disponible en http://hdl.handle.net/10915/65379.

Saludos.

JJ.

[Pablo-Salvatore]

hace 44 minutos, jwackito dijo:

Es decir, no podes reconstruir el valor de rojo en los pixels que no son rojos, salvo interpolando los valores de los vecinos.

Lo entiendo, pero también es cierto que los filtros tienen cortes con bandas de frecuencias solapadas entre sí y el canal verde, tal como lo mencionas, que toma la mitad de la superficie del sensor recibe también fotones de las bandas laterales azul y rojo aunque en menor porcentaje ayudarían a resolver una imágen útil en resolución nativa por supuesto restringida a un ancho de banda determinado. Me interesa tu opinión.

[jwackito]

Entiendo lo que decis. Fijáte este paper en la página 17. http://www.inf.fu-berlin.de/lehre/WS02/robotik/Vorlesungen/Vorlesung2/ComputerVision-2.pdf

Supongo que si tenés los datos específicos para tu sensor (o podés medirlos de alguna manera) podrías corregir respecto al verde, con lo que te quedaría una muestra corregida para la cantidad de verde del objeto. Igual no se si entiendo bien lo que querés hacer. Si queres que la cámara color se comporte como la monocromo, esto no va a alcanzar, ya que solo estarías reconstruyendo la intensidad del verde para este objeto... Además, como harías con un objeto violeta (rojo y azul y no sin verde)?

Podrías explicar mejor que querés hacer?

 

Saludos,

JJ.

[fsr]

hace 6 horas, Pablo-Salvatore dijo:

Exactamente. Por eso quisiera obtener los valores reales e intentar compensar solamente las curvas de los filtros R y B respecto de G a costa de obtener una imágen en escala de grises. Estimo que de esta forma la información captada será más representativa.

Si querés obtener una imagen en escala de grises tal como la captó el sensor, el programa dcraw te puede devolver eso en distintos formatos de imagen.

 

DSS tiene algunos detalles sobre los métodos que usa acá: http://deepskystacker.free.fr/english/technical.htm#rawdecod

(Notar que también usaron dcraw, hay muchas aplicaciones que lo usan)

Editado 8 de Marzo del 2018 por fsr