Jump to content

Sobre los algoritmos de debayerización (revelado RAW)


jwackito

Publicaciones recomendadas

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!

iOptron CEM70AG
Askar ACL200, Duoptic ED Pro 60, APO 90, Photo 90 5 elementos
QHY600M, QHY294M Pro, QHY268C, QHY183M, QHY5III462C

Garin - Buenos Aires - Argentina

Duoptic - Espacio Profundo
Mi Galeria de Fotos IG: @rfcontrerasb

Enlace al comentario

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

Enlace al comentario

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.

Enlace al comentario

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.

  • Like 1
Enlace al comentario

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

  • Like 1
Enlace al comentario

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.

  • Like 1
Enlace al comentario

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

Enlace al comentario

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.

Enlace al comentario

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! 

Pablo Salvatore

SW 130-650 / EQ2

SW Star Adventurer

Sony A3500

Enlace al comentario

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.

Enlace al comentario

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! 

Pablo Salvatore

SW 130-650 / EQ2

SW Star Adventurer

Sony A3500

Enlace al comentario

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.

Fernando

Enlace al comentario
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.

Pablo Salvatore

SW 130-650 / EQ2

SW Star Adventurer

Sony A3500

Enlace al comentario

@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.

 

  • Like 1
Enlace al comentario
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.

Pablo Salvatore

SW 130-650 / EQ2

SW Star Adventurer

Sony A3500

Enlace al comentario

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.

Enlace al comentario
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 por fsr
  • Thanks 2

Fernando

Enlace al comentario

Crear una cuenta o conéctate para comentar

Tienes que ser miembro para dejar un comentario

Crear una cuenta

Regístrese para obtener una cuenta nueva en nuestra comunidad. ¡Es fácil!

Registrar una nueva cuenta

Conectar

¿Ya tienes una cuenta? Conéctate aquí.

Conectar ahora
×
×
  • Crear nuevo...