Sinespejo

A un usuario se le ha escacharrado el sensor de su Canon 7D. Los archivos RAW presentan niveles bajísimos (casi negro) en una de cada 8 columnas de fotositos (en concreto de valores G-B de la matriz de Bayer), lo que hace pensar que algo ha fallado en la electrónica responsable de realizar la lectura de esas columnas. Seguramente la solución sea un cambio de sensor.

He tratado de hacer un apaño con una simple sustitución en el RAW de las columnas defectuosas por el promedio de los valores de sus columnas G-B vecinas. El resultado no es perfecto ya que aparecen artefactos en zonas de cambios bruscos de luminosidad en horizontal, pero al menos salva la aparición de las líneas que inutilizaban por completo la imagen original.

El archivo RAW restaurado se puede bajar de:
http://guillermoluijk.com/download/rayasrestaurado.dng

Matriz de Bayer del RAW original donde puede verse que la electrónica de lectura tiene un fallo en 1 de cada 8 columnas:


Comparación revelado del RAW original vs RAW "restaurado":
http://guillermoluijk.com/misc/antesdespues.jpg

Aspecto general del revelado del RAW "restaurado":
http://guillermoluijk.com/misc/rayasrestaurado.jpg

Recorte al 400% poniendo de manifiesto los artefactos del método tan simplón usado:
http://guillermoluijk.com/misc/rayasrestauradocrop.jpg

Las 3 líneas de código que hacen el procesado:

Código: Seleccionar todo

i=which(!col(img)%%8)  # affected pixels (1 out of each 8 columns)
NROW=nrow(img)
img[i]=(img[i-2*NROW]+img[i+2*NROW])/2  # replace averaging both sides


Salu2!

Para un pobre ignorante como yo, eso es pura magia
Además de saber programar la rutina, lo que me parece más difícil es saber dónde encontrar los datos a tratar (conocer la estructura de la base de datos)

Y una cuestión que se me ocurre:

Hace años se decía que un Raw era inviolable. Dicho de otra manera, que no se podía manipular un raw dentro del raw y que quedase como tal raw.

¿Eso ha cambiado o ya era falso entonces?

Rafa Buscaret escribió:¿Eso ha cambiado o ya era falso entonces?

Eso ha sido una trola desde que existen los archivos RAW
Un archivo RAW no es más que un fichero que tiene números dentro. Solo tienes que cambiar esos números y ya has cambiado el RAW. Lo que ocurre es que editar un RAW es algo bastante inútil ya que es más fácil editar la imagen ya revelada. Aquí hago algunos RAW sintéticos:

https://www.overfitting.net/2021/04/gen ... artir.html

He probado una mejora, ahora el canal G lo tomo de los 4 fotositos G más cercanos. El B lo sigo tomando como promedio de las columnas a 2 fotositos por la izquierda y por la derecha:



Salu2!

Sobre las columnas defectuosas, son píxeles casi apagados. Digo casi porque aunque en la imagen que puse se ven casi negros, aún tienen señal útil, pero difícil de recuperar (luego comento más). Es como si la amplificación que debía hacerse sobre esas columnas se hubiera venido abajo; en términos fotográficos podemos verlo como que esas columnas se hubieran leído con un ISO3 (me invento la cifra, pero puede estimarse).

Lo que hace el código es simplemente sustituir el valor numérico de los fotositos defectuosos por un cálculo promedio de valores cercanos. En concreto para la segunda versión del apaño he hecho esto:



Es decir los valores G defectuosos se sustituyen por el promedio de los valores de los 4 fotositos G que los rodean, y con los B promedio sus dos vecinos a izquierda y derecha pero a 2 columnas de distancia claro.
Éste es el código que implementa esas operaciones (está en R por si alguien conoce el lenguaje, hace muy fácil manipular zonas selectivas de una imagen sin necesidad de hacer ningún bucle como pasa en casi todos los lenguajes):

Código: Seleccionar todo

# METHOD 2

# B photosites
i=which(!col(img)%%8 & !row(img)%%2)
img[i]=(img[i-2*NROW]+img[i+2*NROW])/2

# G photosites
i=which(!col(img)%%8 & row(img)%%2)
img[i]=(img[i-NROW-1]+img[i-NROW+1]+img[i+NROW-1]+img[i+NROW+1])/4


Esto se puede mejorar todavía más. Un paso fácil estaría en los valores G donde es fácil tratar de detectar gradientes (es decir cambios de tonalidad bruscos) en dirección horizontal y vertical, y combinar esos 4 valores que ahora promedio de forma más elaborada para emular la continuidad del gradiente. Pero ahora mismo el eslabón débil son los valores de B, que se basan en valores correctos muy alejados de la columna defectuosa, lo que ocasiona los artefactos.

Sobre las columnas defectuosas, comparo aquí exactamente lo que hay en ellas vs el valor correcto (son imágenes de 650px de lado porque vienen de reducir sin interpolación a 1/8 el tamaño original de 5202 píxeles de ancho):

https://i.ibb.co/tsDJ7J2/defectivegdata.png

Lo de arriba son valores RAW, es decir son directamente los números que hay en el canal G en las tripas del archivo RAW, sin ningún revelado ni interpolación. Puede verse que en las columnas defectuosas hay información, pero muy subexpuesta y además imposible de rescatar (no es uniforme y tiene una especie de efectos blooming que invaden columnas hacia la derecha). Esto da algunas pistas de cómo está implementada la circuitería de la cámara, parece que la lectura del sensor la llevasen a cabo 8 circuitos separados, cada uno de ellos haciéndose cargo de una de cada 8 columnas de fotositos, y a Cosme se le ha jodido uno de esos 8 circuitos.

Salu2!

Quizá funcionara mejor sustituir cada columna que falta por la inmediata anterior sin mediar con la siguiente, para evitar ese efecto de vidrio grabado. Aunque habría que verlo.

JMLA escribió:Quizá funcionara mejor sustituir cada columna que falta por la inmediata anterior sin mediar con la siguiente, para evitar ese efecto de vidrio grabado. Aunque habría que verlo.

Piensa que en la columna inmediata anterior no hay fotositos azules sino claro que lo habría hecho así.
Dependiendo del contenido de la escena, los canales RGB del RAW pueden correlar desde mucho hasta nada, así que no es sustituible un valor B por un R o G.

Aquí precisamente estudiaba estas correlaciones:
https://www.overfitting.net/2018/06/dec ... con-r.html

Salu2!