Cuando afoto me selen líneas verticales paralelas en toda la toma.

[rotsenx9]

Magnífico trabajo Guillermo. Aquí debes ser el único capaz de resolver este problema.

Muchas gracias por la explicación, de lo que le ha pasado a la imagen, la avería del sensor que lo ha ocasionado y como lo has resuelto.

Cualquiera que tenga este problema y lea este hilo buscando información, ya sabe la avería que tiene y que tiene que sustituir el sensor.

Cosme, si estás pensando en cambiar el sensor, considera si ésta cámara ha tenido mucho uso y que puedan salir más averías, por ejemplo el obturador, o si ha sido algo fortuito, como que el sensor hubiera tenido algún problema de fabricación y haya cascado cuando no le tocaba.

[JorgeVLC]

Guillermo. Muchas gracias por compartir tus conocimientos.

Impresionante trabajo y todavía más cuando dices que lo que has hecho tiene poco misterio. Yo también me quito el sombrero.

Te leo siempre con atención y agradezco tus aportaciones, que siempre son muy interesantes.

Tienes además una excelente capacidad de comunicación. Una vez más, mi agradecimiento y mi aplauso por esta intervención y también por las que haces habitualmente.

Saludos.

[Guillermo Luijk]

Bonito trabajo Guillermo. Solo para vulgarizar esto un poco ¿Esas líneas verticales, son pixeles apagados?

Entiendo que lo has arreglado reemplazándolos por información que generas con el código.

Gracias por tu información

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):

# 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):


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!

[Cosme de Armas]

Pues quitándome el sombrero por lo que ha hecho con la foto de prueba para que se vieran las rayas, voy a quedarme quieto. seguro que la reparación me costará más que comprar otra 7D en el mercadillo, pero aconsejado por alguien que sabe muchísimo más que yo, no compraré cámara alguna, desempolvaré mi 450, y "tiraré con lo que tengo porque tiempo de gastar dinero sin saber realmente lo que quiero y lo que necesito, siempre hay.
Tú me comprendes.
Muchas gracias compañero y maestro.

[Vampy]

Yo creo que la solución es que te compres otra cámara y ya esta arreglarla puede ser mas caro que busscar una nueva del estilo y hacerte con un arduino y procesar cada RAW con el programa de guillermo no es algo que merezca la pena salvo para investigación y curiosidad como la que nos ha deleitado nuestro amigo.

[NerveNet]

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):

# 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):


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!

Excelente trabajo Guillermo. No conozco el lenguaje R (vengo programando en C, Perl, Python,...) me parece muy interesante el comentario que haces sobre la facilidad de usar R para trabajar sin bucles sobre zonas de la imagen, tendré que echarle un vistazo a R.

¿Recomendarías algún para echarle el diente al lenguaje R?

[Guillermo Luijk]

Excelente trabajo Guillermo. No conozco el lenguaje R (vengo programando en C, Perl, Python,...) me parece muy interesante el comentario que haces sobre la facilidad de usar R para trabajar sin bucles sobre zonas de la imagen, tendré que echarle un vistazo a R.

¿Recomendarías algún para echarle el diente al lenguaje R?

Yo hice un curso presencial y luego Stackoverflow para cualquier duda. En realidad usar R para tratar imágenes me da que es una rareza mía, es un lenguaje estadístico imbatible para analizar datos en línea de comandos pero no lo veo tanto para grandes proyectos en producción, ni está especializado en imágenes.

Lo que ocurre es que es muy bueno manejando arrays, con funciones nativas no encontradas en otros lenguajes. Por ejemplo si img es una matriz que contiene una imagen, haciendo h=hist(img) te dibuja su histograma y lo guarda numéricamente en h, con img[img<0]=0 recortas a 0 cualquier valor negativo, si haces i=which(img>=0.4 & img<=0.6) tienes en i un vector con los índices de todos los píxeles de valores entre 0.4 y 0.6, y puedes hacer lo que quieras con ellos, p.ej. aplicar a esos píxeles y solo a ellos una curva gamma: img[i]=img[i]^(1/2.2), etc...

Es muy bueno en todo lo que sea vectorizar para evitar bucles. Pude programar la Ecuación del calor en 2D por diferencias finitas, que son procesos iterativos muy pesados, sin usar bucles. Para conseguir esa velocidad con bucles anidados hay que acudir a lenguajes compilados.

Por cierto he pasado a limpio el artículo: https://www.overfitting.net/2022/02/...chivo-raw.html

Salu2!

[NerveNet]

Yo hice un curso presencial y luego Stackoverflow para cualquier duda. En realidad usar R para tratar imágenes me da que es una rareza mía, es un lenguaje estadístico imbatible para analizar datos en línea de comandos pero no lo veo tanto para grandes proyectos en producción, ni está especializado en imágenes.

Lo que ocurre es que es muy bueno manejando arrays, con funciones nativas no encontradas en otros lenguajes. Por ejemplo si img es una matriz que contiene una imagen, haciendo h=hist(img) te dibuja su histograma y lo guarda numéricamente en h, con img[img<0]=0 recortas a 0 cualquier valor negativo, si haces i=which(img>=0.4 & img<=0.6) tienes en i un vector con los índices de todos los píxeles de valores entre 0.4 y 0.6, y puedes hacer lo que quieras con ellos, p.ej. aplicar a esos píxeles y solo a ellos una curva gamma: img[i]=img[i]^(1/2.2), etc...

Es muy bueno en todo lo que sea vectorizar para evitar bucles. Pude programar la Ecuación del calor en 2D por diferencias finitas, que son procesos iterativos muy pesados, sin usar bucles. Para conseguir esa velocidad con bucles anidados hay que acudir a lenguajes compilados.

Por cierto he pasado a limpio el artículo: https://www.overfitting.net/2022/02/...chivo-raw.html

Salu2!

Gracias, a ver que puede ofrecerme R.

[Trevenque]

He leído atentamente todo lo publicado en el hilo y celebro que se puedan encontrar en Canonistas estas publicaciones. Es todo un lujo poder contar con compañeros que publiquen y compartan sus conocimientos,... abiertamente y sin tapujos.

Mis sinceras felicitaciones, Guillermo.