Mostrando resultados del 1 al 10 de 10

Tema: Apilado por media para simular filtro ND de larga exposición en RAW

  1. #1
    Fecha de Ingreso
    nov 2006
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    6.260

    Predeterminado Apilado por media para simular filtro ND de larga exposición en RAW



    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

  2. #2
    Fecha de Ingreso
    feb 2011
    Ubicación
    Riells i Viabrea (Girona)
    Mensajes
    2.524

    Predeterminado

    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

  3. #3
    Fecha de Ingreso
    nov 2006
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    6.260

    Predeterminado

    Cita Iniciado por XATRAC Ver Mensaje
    Esto es parecido a lo que hacen las OM System con el disparo "Live ND"?
    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!

  4. #4
    Fecha de Ingreso
    feb 2011
    Ubicación
    Riells i Viabrea (Girona)
    Mensajes
    2.524

    Predeterminado

    Cita Iniciado por Guillermo Luijk Ver Mensaje
    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.

  5. #5
    Fecha de Ingreso
    mar 2011
    Ubicación
    Barcelona
    Mensajes
    12.445

    Predeterminado

    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.

  6. #6
    Fecha de Ingreso
    mar 2011
    Ubicación
    Barcelona
    Mensajes
    12.445

    Predeterminado

    Vale, es porque aumenta el rango dinámico...pero solo en el caso que se tenga que levantar sombras, no?

  7. #7
    Fecha de Ingreso
    nov 2006
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    6.260

    Predeterminado

    Cita Iniciado por Dr. Mabuse Ver Mensaje
    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!

  8. #8
    Fecha de Ingreso
    ene 2012
    Ubicación
    A un clic de ti...
    Mensajes
    13.557

    Predeterminado

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

  9. #9
    Fecha de Ingreso
    nov 2006
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    6.260

    Predeterminado

    Cita Iniciado por NerveNet Ver Mensaje
    Qué código tan "cortito" y aparentemente eficiente te ha quedado.
    Es lo que tienen los lenguajes de muy alto nivel, que tienen código corto y sin distracciones de lo importante: el prototipado.

    Cita Iniciado por NerveNet Ver Mensaje
    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?
    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.

    Cita Iniciado por NerveNet Ver Mensaje
    Si el nivel de negro del sensor es 512. ¿Por qué obtienes valores negativos?
    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

    Cita Iniciado por NerveNet Ver Mensaje
    El último paso antes de grabar el resultado tampoco lo entiendo: img=img/(SAT-BLACK)
    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

  10. #10
    Fecha de Ingreso
    ene 2012
    Ubicación
    A un clic de ti...
    Mensajes
    13.557

    Predeterminado

    Cita Iniciado por Guillermo Luijk Ver Mensaje
    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!
    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

Normas de Publicación

  • No puedes crear nuevos temas
  • No puedes responder temas
  • No puedes subir archivos adjuntos
  • No puedes editar tus mensajes
  •