Esto es parecido a lo que hacen las OM System con el disparo "Live ND"?
He hecho el ejercicio que tenía pendiente hace tiempo de promediar en RAW varias capturas RAW con el fin de obtener un único archivo RAW de salida de larga exposición.
Artículo completo: https://www.overfitting.net/2024/03/...mular-iso.html
Salu2!
Última edición por Guillermo Luijk; 04/03/24 a las 00:36:36
Esto es parecido a lo que hacen las OM System con el disparo "Live ND"?
Última edición por XATRAC; 04/03/24 a las 18:41:58
Es exactamente eso. Y es lo mismo que hacen las Sigma fp con su ISO6 (que es como deberían haberlo llamado los de Olympus porque se entendería mucho mejor qué es y para qué se puede usar), y lo que debieran hacer todas las cámaras si sus fabricantes no fueran unos torpes en cualquier cosa que implique software, porque mira que es fácil de implementar esto:
Salu2!
Muchas gracias.
No conozco ese tipo de código pero como tu apuntas no parece nada complejo. Hay marcas que ofrecen montones de utilidades basadas en software y en cambio otras poca cosa. Esto lo he podido comprovar tanto en OM System como en Fuji, Canon no ofrece tanto. Supongo que son estrategias comerciales o el "target" de clientes que pretenden tener, unas más encaradas a fotos terminadas en la máquina (.jpg) y otras más encaradas a la edición (RAW).
Un saludo.
Lo que no me queda claro es porque con filtro tendría más ruido. Si se usa un trípode se puede dejar entrar en el sensor tanta luz como necesite y usar ISO 100 lo que producirá el mínimo ruido posible.
Vale, es porque aumenta el rango dinámico...pero solo en el caso que se tenga que levantar sombras, no?
El ruido se va a reducir en la misma medida numérica en cada píxel de toda la imagen, sea de sombras, medios o luces. Otra cosa es que sea más o menos útil tener esa mejora en unas zonas o en otras. Si en las altas luces por ejemplo con una sola toma el ruido fuera imperceptible, reducirlo más aún ya no sirve de nada. Esta escena en concreto como tiene reflejos especulares en el agua que debían preservarse, requería una subexposición importante para lograrlo, lo que hace que en casi toda ella hubiera luego que levantar bastante las sombras así que la diferencia es notoria casi en todas partes (esto son recortes al 100%):
.
Salu2!
Hola Guillermo.
Qué código tan "cortito" y aparentemente eficiente te ha quedado.
Por entenderlo mejor, img es un objeto con la imagen y le vas "sumando otras imagenes". ¿No declaráis el tipo de objeto en R? Si img no es un objeto. ¿Qué es?
Si el nivel de negro del sensor es 512. ¿Por qué obtienes valores negativos?
El último paso antes de grabar el resultado tampoco lo entiendo: img=img/(SAT-BLACK)
Clic, clic, clic...
Es lo que tienen los lenguajes de muy alto nivel, que tienen código corto y sin distracciones de lo importante: el prototipado.
En R no hay que declarar nada, y no hay objetos (llegó tarde a esa moda). Las variables y sus tipos vienen y van. Cuando hago img=0, img contiene un número de valor 0. El objetivo es que "tenga algo" para que luego al sumarle las imágenes que vamos a ir leyendo no de error porque img no existe.
Cuando hago img=img+readTIFF(...) lo que hago es sumarle a 0 lo que devuelve la función readTIFF(), que es una matriz con los datos del TIFF leídos (cada TIFF, que proviene de DCRAW, contiene los datos brutos de un RAW). Al sumar un número a una matriz, el resultado es una nueva matriz donde a cada uno de sus elementos se ha sumado el número. Como el número es 0, en el primer paso del bucle lo que tenemos en img es la matriz que constituye el primer TIFF. Luego le vamos sumando todos los demás TIFF con lo que al terminar de ejecutar el bucle en img tengo una matriz donde en cada píxel se han sumado los 14 valores RAW. Para promediarlos hacemos luego: img=img/14, más simple imposibe.
Si te fijas ir sumando una por una las imágenes hace que solo gastemos memoria para almacenar una imagen; podríamos promediar miles y nunca tendríamos en memoria más que lo equivalente a una imagen. En Photoshop las cargaríamos todas a lo bruto, se agotaría la memoria con unas pocas decenas.
No hay valores negativos en el RAW, pero sí los puede haber después de sustraer 512 (img=img-BLACK) a todos ellos debido al ruido. Es decir, en los RAW originales vamos a encontrar valores menores a 512. Por ejemplo cuando haces una foto con el objetivo tapado los valores RAW son una distr. gaussiana entorno al nivel de negro, así que si le restas ese nivel de negro te pueden salir valores negativos. Ejemplo histograma RAW de una Canon 350D con el objetivo tapado, esa gaussiana que sale es el ruido de lectura del sensor (nivel de negro=256): http://www.guillermoluijk.com/articl.../histodark.gif
Los datos RAW van desde BLACK (512) hasta SAT (16383). Si les resto BLACK, lo que antes caía en SAT ahora cae en SAT-BLACK. Por la forma en que writeTIFF() guarda los TIFF, los datos de la matriz deben estar en el rango 0..1 donde 0 se guardará como negro y 1 como blanco (65535 para un TIFF de 16 bits). Por lo tanto para que lo que en el RAW original caía en SAT, en la matriz con la que voy a guardar el TIFF caiga en 1, tras haber restado BLACK tengo que dividir entre (SAT-BLACK). En algunas cámara (Nikon) ese BLACK se sustrae en la propia cámara y te devuelve RAWs cuyos niveles parten de 0. Esto es peor porque estás truncando la parte izquierda de la gaussiana del ruido, lo que estropea algunos procesados estadísticos como por ejemplo la media que estamos haciendo.
Puede sonar lioso pero es una pura chorrada, hago estas restas y divisiones tontas todas las veces que manipulo un RAW.
Salu2!
Última edición por Guillermo Luijk; 05/03/24 a las 14:31:33
Gracias por la explicación, el código se entiende perfectamente pero me faltaba algo, ten presente que he vivido bastante habiendo empezado a programar en código máquina, ensamblador y BASIC. Y esto del lenguaje R requería una breve aclaración, y aclarado ha quedado.
Yo diría que tu código es minimalista y que roza la elegancia.
Clic, clic, clic...
Marcadores