Etapas del revelado con perfectRAW

Estás viendo el contenido archivado del viejo foro de Ojodigital. No podrás iniciar sesión ni crear nuevo contenido o comentarios.

El foro de ojodigital ha migrado a: https://foro.ojodigital.com, con un aspecto mucho más moderno, amigable y adaptado a dispositivos móviles.

¡¡PINCHA AQUÍ PARA ACCEDER AL NUEVO FORO!!

Resultados 1 al 17 de 17
  1. #1
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like

    Etapas del revelado con perfectRAW

    Aprovecho que _GUI_ ha puesto las etapas de revelado en un subforo para ampliar la información del flujo de revelado, ponerla aquí para todos y que quede como documentación del proyecto.

    He indicado en qué punto se escoge cada buffer (justo después del paso indicado). Falta separar los pasos 6 y 7 y que el buffer 2 se tome justo después del paso 4 y no del 5 para enviarlo a perfectBLEND y que perfectBLEND lo devuelva y se inserte en ese punto, porque los pasos 5, 6, 7 y 8 se hacen ahora dentro de la función scale_colors() de Coffin).

    He marcado en negrita los pasos que llevan más tiempo y en verde los que dependen de parámetros especificados por el usuario desde la aplicación. Obviamente algunos pasos se saltan en función de los parámetros de revelado especificados.
    1. Lectura del archivo RAW (buffer 0)
    2. Sustracción de black frame (buffer 1)
    3. Generación de patrones sintéticos (falta definirlos bien)
    4. Equilibrado de canales verdes (modo)
    5. Ajuste negro y sat. de cámara (por defecto de dcraw o de usuario)
    6. Balance de blancos (método)
    7. Eliminación de ruido (umbral)
    8. Aberraciones cromáticas (parámetros) (buffer 2, de momento)
    9. Interpolación Bayer (algoritmos) (buffer 3)
    10. Mezclado de canales verdes (hasta aquí RGGB, a partir de aquí RGB)
    11. Filtros mediana para eliminar artefactos de color (pasos)
    12. Recuperación de altas luces (método) (buffer 4) <- Buffer cambiado de posición a petición de _GUI_
    13. Corrección de exposición (modos)
    14. Conversión a RGB con dos posibles caminos (para la versión 1.0):
      • Si se pide salida a disco/clipboard:
      1. Conversión a perfil de color escogido por el usuario
      2. Gamma escogida por el usuario (en dcraw.dll)
      3. Salida a TIFF por disco/clipboard (buffer 5)
      • Si es para mostrar en pantalla:
      1. Conversión a perfil de color sRGB (buffer 5)
      2. Gamma sRGB (en perfectRAW.dll)
      3. Histograma total (hasta aquí se hace una sola vez en la imagen, a partir de aquí se hace en cada fotograma que muestra el GUI al desplazarnos o hacer zoom).
      4. Cálculo chivato zonas quemadas (solo porción de la imagen, si activo y si el reloj lo indica)
      5. Histograma parcial (sólo porción de la imagen si se pide mostrarlo)
      6. Conversión a 8 bits (sólo porción de la imagen)
      7. Salida por pantalla (sólo porción de la imagen)
    Aclaro algunos aspectos para el que pueda andar despistado:
    • dcraw NO convierte a float, trabaja internamente con ushort (16 bits), no en 32 bits. Pasa de ushort a float y de nuevo a ushort EN CADA OPERACIÓN en la que es necesaria la precisión de un float, es decir, acumula errores de redondeo en cada operación. Si la precisión es suficiente con este método es algo que hay que evaluar viendo la imagen resultante y el histograma, yo diría que sí, pero estoy seguro que los dientes de sierra que aparecen al ampliar lo histogramas con histogrammar se deben a esos errores de redondeo acumulados. Imposibles de detectar en la imagen final. No creo que otros reveladores trabajen realmente a 32 bits todo el rato porque TAMBIÉN producen esos dientes de sierra.
    • Todos los buffers indicados arriba son de 16 bits, porque así los entrega dcraw. perfectRAW trabaja a 16/32 bits hasta el momento final de presentación por pantalla. Todas las operaciones, salvo el redondeo a 8 bits que se hace con desplazamientos de bits, se calculan en float.
    • La gamma que se muestra en pantalla NO se aplica dentro de dcraw.dll, sino en perfectImage.dll y es una gamma sRGB exacta aplicada a 16 bits mediante una LUT completa, es decir, sin interpolación, e inmediatamente convertido el resultado a 8 bits (pero la gamma se aplica sobre 16). Aunque en perfectRAW se elija una gamma/espacio de color distintos a sRGB no se verá ninguna diferencia en la pantalla. Sólo al grabar en TIFF se verá el resultado y eso implicará volver a revelar el archivo antes de grabar pidiendo, esta vez sí, a dcraw.dll que revele con el espacio de color y gamma de salida (solo es la última etapa del revelado, por lo que tardará poco). En futuras versiones habrá que meter gestión de color al GUI para mostrar en pantalla la gamma real.
    • Cuando manejemos la escritura en DNG quitaré lo de la generación de patrones sintéticos, pues podremos generar DNGs sintéticos para evaluar los algoritmos de interpolación de distintos reveladores, de momento servirá para evaluar el propio perfectRAW.
    • Lo del histograma parcial (de lo que muestra la vista) se ha comentado alguna vez, pero no se ha definido.
    • Los buffers 0, 2 y 4 son susceptibles de no ser guardados si por los parámetros especificados recalcularlos es rápido y queremos ahorrar memoria. De hecho, el 0 no se está guardando ya.
    Sería bueno confirmar ahora que todo es correcto.

    Un saludo:
    Última edición por ManuelLlorens; 26/05/2008 a las 11:56
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  2. #2
    Ingreso
    07 mar, 06
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    9,426
    Post Thanks / Like
    Cita Iniciado por ManuelLlorens Ver mensaje
    [*]dcraw NO convierte a float, trabaja internamente con ushort (16 bits), no en 32 bits. Pasa de ushort a float y de nuevo a ushort EN CADA OPERACIÓN en la que es necesaria la precisión de un float, es decir, acumula errores de redondeo en cada operación.
    Creo que por desgracia (y por rapidez) así deben funcionar casi todos. Iliah Borg se vanagloria de haber convertido a float de 32 bits el código de DCRAW, y lo mismo hace Iris si no estoy equivocado.
    Lo que no entiendo entonces es porqué los clipf?

    En cualquier caso lo de convertirlo a 32 bits sería para futuras versiones, juguemos con lo que hay ahora mismo no?

    El buffer1 yo lo trasladaría al punto 3, porque lo vamos a necesitar para el balance de blancos por parches y más adelante en perfectBLEND. Estás seguro que vale la pena aplicar reducción de ruido en perfectBLEND? su filosofía es eliminar ruido mediante la sobreexposición, para NUNCA perder textura. Aunque bueno, si es opcional podria estar bien, reducción de ruido en RAW!
    "En ocasiones veo halos."

    http://www.guillermoluijk.com para suscribirte haz clic aquí
    Último contenido: EL MITO DEL TRÍPODE QUE ASESINÓ A UN ESTABILIZADOR

  3. #3
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por _GUI_ Ver mensaje
    Creo que por desgracia (y por rapidez) así deben funcionar casi todos. Iliah Borg se vanagloria de haber convertido a float de 32 bits el código de DCRAW, y lo mismo hace Iris si no estoy equivocado.
    Lo que no entiendo entonces es porqué los clipf?
    Porque había un punto en que había que hacer clip de un float para luego seguir trabajando con él y hacer al final otro clip normal. Te lo puse en exposure_correction() para tenerte contento , ya lo quitaré cuando no mires .

    Cita Iniciado por _GUI_ Ver mensaje
    En cualquier caso lo de convertirlo a 32 bits sería para futuras versiones, juguemos con lo que hay ahora mismo no?
    No creo que se note en la image. Pasar el código de Coffin a 32 bits no está en la filosofía del proyecto. Eso es viable en un revelador en etapas lineales (tipo dcraw.exe), nosotros saltamos de un lado a otro (dcraw.dll) y mantener buffers intermedios de 32 bits no es viable con la RAM que tenemos ahora, con facilidad se dispararía el consumo a varios gigas.

    Cita Iniciado por _GUI_ Ver mensaje
    El buffer1 yo lo trasladaría al punto 3, porque lo vamos a necesitar para el balance de blancos por parches y más adelante en perfectBLEND. Estás seguro que vale la pena aplicar reducción de ruido en perfectBLEND? su filosofía es eliminar ruido mediante la sobreexposición, para NUNCA perder textura. Aunque bueno, si es opcional podria estar bien, reducción de ruido en RAW!
    En realidad el buffer1 sale de DCRAW_Init() y el buffer2 de DCRAW_Process(). Si muevo el buffer1 entonces tengo que volver a activar el buffer0 para no volver a leer el archivo y no gano nada. Lo que haré será subir el buffer 2 y el buffer 3. Yo creo que tener la posibilidad de quitar ruido RAW no debe desestimarse, aunque efectivamente, en perfectBLEND se le pasará un dcraw.parameters.threshold=0 y no hará nada. Pero es una etapa muy lenta y necesitamos un buffer antes y otro después si se usa en perfectRAW, dcraw.c va a ser el mismo para dcraw.exe y dcraw.dll, tanto para perfectRAW como para perfectBLEND; no quiero duplicar código.

    perfectBLEND recibirá el buffer2 que saldrá de justo antes del WB y el resultado se reinsertará en ese mismo punto. A partir de ahí dcraw.dll continuará el revelado para poder ver el resultado en pantalla. Por su lado perfectBLEND grabará el DNG también a partir de ese mismo punto, sin pasar por dcraw.dll, claro.

    Un saludo:
    Última edición por ManuelLlorens; 21/05/2008 a las 12:59
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  4. #4
    Ingreso
    22 mar, 08
    Ubicación
    Oviedo
    Mensajes
    14,367
    Post Thanks / Like
    Gracias Manuel, lo de los 32 y 16 bits me ha quedado perfectamente claro: cálculos intermedios parciales durante el revelado en 32bits, convirtiendo de 16 a 32 y luego nuevamente a 16. Las salidas de cada etapa en 16 bits.
    Eso además no se puede cambiar por ahora, porque es como lo hace dcraw y supondría tener que hacer todas las etapas nosotros.

    Lo de la gamma también está clara. Cuando se muestra en pantalla se utiliza siempre sRGB y al almacenar la que escoja el usuario para la salida (normalmente la correspondiente al espacio de color seleccionado, aunque el usuario la podrá cambiar).
    ---------------------
    Ahora algún comentario administrativo:
    El hilo lo he puesto como destacado en este foro, porque será como nuestra "biblia" o guía de referencia, para que todos tengamos claro cómo se hace.
    Si en las discusiones se llega a decidir que hay que cambiar algo en el flujo de trabajo, os ruego que editéis el primer mensaje para reflejar el cambio en el flujo de trabajo, dejando una anotación de qué se ha cambiado:
    Algo así:

    Flujo de trabajo actual:
    1.-Demosaicing.
    2.-WB
    3.-Interpolación...
    4.-Eliminación de ruido
    .....

    Historial de flujo de trabajo:
    1.- Demosaicing
    2.- Interpolación.
    3.- WB
    Editado:
    La interpolación se ha decidido ponerla antes del WB para no crear artefactos (20-05-2008) (REFERENCIA AL HILO DONDE SE COMENTA EL CAMBIO).

    <_GUI_>: que nu, que es al revés, la imagen se balancea primero (scale_colors()) y luego se interpola.

    2.-WB
    3.-Interpolación
    FIN EDICIÓN
    4.-Eliminación de ruido
    .....

    Esto sólo pretende ser un ejemplo, nos permitirá ver en todo momento cómo se ha decidido hacer la implementación del revelado, qué cambios ha sufrido y por qué se ha cambiado algo.
    Última edición por Guillermo Luijk; 21/05/2008 a las 15:54

  5. #5
    Ingreso
    22 mar, 08
    Ubicación
    Oviedo
    Mensajes
    14,367
    Post Thanks / Like
    Si la etapa 2 no lleva mucho tiempo y además el usuario no la controla (es completamente automática no veo la necesidad del buffer 1 a su salida.
    En todo caso lo pondría después de la etapa 3, en el que el usuario puede cambiar algo y afectar a la salida. Así cuando cambie el balance de blancos, se empezaría desde la salida del buffer 1, evitando los pasos 1,2 y 3.
    En cualquier caso las etapas entre 1 y 5 parece que son rápidas, por lo que se podría eliminar el buffer 1 ¿no?

    Por otra parte el buffer2 debería de estar a la salida de la etapa 5 de eliminación de ruido (que pones que es lenta) y antes de la 6 que es ajustable. Así ante cambios en los parámetros de las aberraciones cromáticas (¿esto va a ser ajustable según pones no?) se empezaría desde la etapa 5 después del procesado de ruido.

    El buffer 3 no hace falt, pues el esuilibrio de canales verde es automático y muchos de los procesos de después también.

    No tengo muy claro sobre qué procesos actúa el usuario mediante la interface y cuáles son automáticos (sean más o menos lentos).
    Estaría muy bien que resaltaras con otro color aquéllas etapas sobre las que el usuario puede cambiar algo ajustando parámetros en la interface ("etapas ajustables").

    Creo que para optimizar el rendimiento y el consumo de memoria es crítico saber esto (sé que vosotros lo tenéis claro).

    Los únicos puntos en donde un buffer puede ayudar es justo antes de una etapa en la que el usuario pueda influir modificando algún parámetro (etapas ajustables).

    Cuando el usuario cambia algo en una etapa ajustable A, habrá que rehacer todos los procesos desde el buffer almacenado previo a la etapa A correspondiente.

    Para ahorrar buffers, si entre dos etapas A y B que sean ajustables los procesos a realizar son bastante rápidos, nos podemos ahorrar el buffer previo a la etapa B y empezar todo desde el buffer previo a la A cuando el usuario cambie algo que afecte a la etapa A o a la B.

    Si estás de acuerdo con esto, Manuel, habría que revisar si los buffer puesto siguen esta filosofía.
    Última edición por ariznaf; 21/05/2008 a las 14:24

  6. #6
    Ingreso
    22 mar, 08
    Ubicación
    Oviedo
    Mensajes
    14,367
    Post Thanks / Like
    Cuando manejemos la escritura en DNG quitaré lo de la generación de patrones sintéticos, pues podremos generar DNGs sintéticos para evaluar los algoritmos de interpolación de distintos reveladores, de momento servirá para evaluar el propio perfectRAW.
    Esto no lo entiendo. No entiendo cuál es la utilidad de grabar en DNG (un formato raw) en un revelador.
    Precisamente el revelador hará el demosaicing y ajustes de color de la cámara y demás, con lo cuál dejará de ser un RAW.
    El DNG también puede almacenar la imagen una vez hecho el demosaicing y demás, pero para eso también lo podemos guardar en TIFF o cualquier otro formato escogido por el usuario.

    El usar DNG para esto, puede provocar confusión, pues (al menos yo) el DNG lo asocio a un formato RAW y si guardamos lo hecho por PerfectRaw en un DNG lo que habrá en su interior no será para nada un archivo raw sino procesado.

    Además guardar en DNG supondrá un esfuerzo que no creo que por ahora merezca la pena y no se gana nada. Más bien introduce confusión, como dije. Claro que puede haber ventajas que yo no vea...

    Para PerfectBlender la historia cambia completamente, claro, ya que lo ideal en PerfectBlender es hacer la unión de las imágenes sin ningún procesado, incluso antes del demosaicing para que el procesado se haga posteriormetne con el revelador favorito (PerfectRaw u otro). Además descarga a PerfectBlender de tener que implementar tareas que ya están en PerfectRaw. Ahí grabar en DNG sí que es un plus claro.
    Mientras lo de grabar DNG no esté disponible, habrá que conformarse con procesar luego la imagen y ponerla en el portapapeles.

    Lo ideal podría ser que perfectblender fuera un submódulo de PerfectRaw.
    En vez de seleccionar abrir un archivo tener una opción "Componer imágenes sin ruido" o algo así. Abrir ahí PerfectBlender y que lo que salga de éste sea el Buffer0 para que PerfectRaw lo siga procesando.
    Última edición por ariznaf; 21/05/2008 a las 14:49

  7. #7
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por ariznaf Ver mensaje
    Esto no lo entiendo. No entiendo cuál es la utilidad de grabar en DNG (un formato raw) en un revelador.
    Yo no he dicho que sea dentro de perfectRAW... digo que cuando manejemos la escritura de DNG (no lineal) crearé un programa a parte que escriba DNGs no interpolados con patrones de líneas y colores para poder hacer comparativas de los distintos algoritmos de interpolación de los distintos reveladores, incluido perfectRAW. También generaré zonas quemadas controladas por parámetros para comprobar sus algoritmos de recuperación de luces altas... es decir, un programa de test de reveladores... nada que ver con perfectRAW... será un perfectTEST, es otro de los proyectos de mi lista.

    Un saludo:
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  8. #8
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por ariznaf Ver mensaje
    Si estás de acuerdo con esto, Manuel, habría que revisar si los buffer puesto siguen esta filosofía.
    Evidentemente, la siguen... ¿por qué otra razón los iba a haber puesto así, si esa filosofía la diseñé yo?

    Todos los buffers son necesarios, salvo el buffer 0, que de hecho no se está almacenando; aunque, según qué parámetros se modifiquen se usarán unos u otros. Eso ocurrirá automáticamente en la próxima versión.

    He retocado el flujo del revelado, lo había hecho esta mañana de cabeza y había alguna cosa cambiada, quizás de ahí la confusión.

    Un saludo:
    Última edición por ManuelLlorens; 21/05/2008 a las 17:49
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  9. #9
    Ingreso
    07 mar, 06
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    9,426
    Post Thanks / Like
    Cita Iniciado por ManuelLlorens Ver mensaje
    Porque había un punto en que había que hacer clip de un float para luego seguir trabajando con él y hacer al final otro clip normal. Te lo puse en exposure_correction() para tenerte contento , ya lo quitaré cuando no mires .
    Oye si cada paso se hace en 16 bits con redondeo, las curvas para la corrección de exposición pueden meterse en LUTs precalculadas en tiempo real para cada valor de exposición no? lo digo por el pow ése que se ha colado para las subexposiciones.
    "En ocasiones veo halos."

    http://www.guillermoluijk.com para suscribirte haz clic aquí
    Último contenido: EL MITO DEL TRÍPODE QUE ASESINÓ A UN ESTABILIZADOR

  10. #10
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por _GUI_ Ver mensaje
    Oye si cada paso se hace en 16 bits con redondeo, las curvas para la corrección de exposición pueden meterse en LUTs precalculadas en tiempo real para cada valor de exposición no? lo digo por el pow ése que se ha colado para las subexposiciones.
    Precisamente, estaba pensando en implementarlo así, y la gamma de dcraw también, que es como está ahora la de perfectImage.dll.

    Lo que hicimos al meter la gamma en dcraw es absurdo. ¿Recuerdas que al principio estaba mal porque creíamos que los valores estaban normalizados 0-1? En ese punto debimos darnos cuenta. En fin, de todo se aprende. En vez de calcular en float lo que hay que hace es una LUT ushort->ushort calculada en float, como la que he implementado ahora en perfectImage.dll para la sRGB en perfectRAW. Lo gracioso es que es exactamente igual de precisa pero infinitamente más rápida.

    Se tarda menos en calcular la LUT directamente porque son sólo 65536 valores y luego ir asignando en la imagen cada valor al que corresponde ya redondeado, se ahorran montones de operaciones. No hace falta ni siquiera el pow01 para tan pocos cálculos, basta con el powF que ya implementé.

    En cuanto pueda actualizo dcraw.dll (las LUTs, el cálculo de la gamma rápida en dcraw y el control de exposición nuevo, la gestión más inteligente de la memoria, vincularlo con LCMS y activar esas opciones... buff, cómo se acumula el trabajo).

    Cuando meta la gamma más rápida en dcraw cambiaré algún detalle del esquema de revelado de arriba y quitaré la gamma de perfectImage.dll

    Un saludo:
    Última edición por ManuelLlorens; 21/05/2008 a las 17:44
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  11. #11
    Ingreso
    22 mar, 08
    Ubicación
    Oviedo
    Mensajes
    14,367
    Post Thanks / Like
    Evidentemente, la siguen... ¿por qué otra razón los iba a haber puesto así, si esa filosofía la diseñé yo?
    Manuel, es que seguramente sea porque yo no entienda qúe etapas son afectadas por parámetros seleccionados por el usuario (por eso pedía que se resaltaran en color), pero yo no veo que el esquema que pusiste lo siga.

    El buffer0 lo veo bien para no tener que leer el fichero cada vez que algo se cambie (yo no lo quitaría, ademas es el buffer más pequeño, pues todavía no tiene hecho el demosaicing). También puede ser el punto de unión con PerfectBlender (que ha de devolver ese buffer0).

    Pero el 1 sobraría según lo anterior, pues todas las etapas son más o menos rápidas y automáticas hasta el 6, por lo menos. Debería de estar puesto a la salida del 5 ¿no?
    Bueno lo de los patrones no sé muy bien en qué consiste. En cualquier caso incluso la etapa 6 según tu esquema es más o menos rápida. Pero puede ser razonable poner ahí un buffer para no tener que irse al principio del todo cada vez que se toque un canal de Balance de blancos (además seguirá siendo un buffer pequeño, con los valores aún sin interpolar).

    El buffer 2 lo pones antes de la interpolación de Bayer... pero esta es automática ?no? el usuario no tiene nada que tocar ahí. Según lo dicho antes sobraría o en todo caso tendría que estar antes del 8 (ala salida del 7) si es que la corrección de aberraciones cromáticas va a ser controlada por el usuario.

    El paso 10 ¿no es automático? ¿o es para dejar que se mezclen los canales con relaciones diferentes entre sí.... eso sólo tendría sentido en blanco y negro, no?

  12. #12
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por ariznaf Ver mensaje
    Manuel, es que seguramente sea porque yo no entienda qúe etapas son afectadas por parámetros seleccionados por el usuario (por eso pedía que se resaltaran en color), pero yo no veo que el esquema que pusiste lo siga.
    En su día lo colgué en el tema principal y está documentado en el código de la DLL (en dcraw.h), pero será bueno que lo vuelva a poner aquí para completar el primer post:
    Código:
    // Struct for passing parameters to the development process
    typedef struct DCRAW_Parameters
    {       
           float    threshold;         // -n -> buffer 2
           double   aber[4];           // -r -> buffer 2
           int      use_auto_wb;       // -a -> buffer 2
           int      use_camera_wb;     // -w -> buffer 2
           unsigned greybox[4];        // -A -> buffer 2      
           int      user_black;        // -K -> buffer 2
           int      user_sat;          // -S -> buffer 2
           int      test_pattern;      //    -> buffer 2       
           int      level_greens;      // -l -> buffer 2       
           int      user_qual;         // -q -> buffer 3
           int      four_color_rgb;    // -f -> buffer 3
           int      med_passes;        // -m -> buffer 4
           int      highlight;         // -H -> buffer 4
           int      output_color;      // -o -> buffer 5                     
           int      use_fuji_rotate;   // -J -> buffer 5
           float    user_gamma;        // -g -> buffer 5       
           float    exposure;          //    -> buffer 3
           int      exposure_mode;     //    -> buffer 3
    }DLL_PARAMETERS;
    Cita Iniciado por ariznaf Ver mensaje
    El buffer0 lo veo bien para no tener que leer el fichero cada vez que algo se cambie (yo no lo quitaría, ademas es el buffer más pequeño, pues todavía no tiene hecho el demosaicing). También puede ser el punto de unión con PerfectBlender (que ha de devolver ese buffer0).
    perfectBLEND necesita el buffer2 sin balance de blancos, no el buffer0, por eso no guardo el buffer0, aunque guardarlo es quitar un cometario. Creo que lo que haremos en perfectBLEND será coger el buffer1 y aplicarle una función nuestra que haga lo mismo que scale_colors() sin el balance de blancos.

    Todos los buffers, salvo el de salida final tienen el mismo tamaño width*height*4*2 bytes, porque tienen cuatro canales (RGGB) de 16 bits. Antes del demosaicing tienen agujeros que ocuparán los valores interpolados, pero no ocupan menos. El de salida es RGB y ocupa, por tanto, un poco menos: width*height*3*2. No hay más tipos de buffers.

    Cita Iniciado por ariznaf Ver mensaje
    Pero el 1 sobraría según lo anterior, pues todas las etapas son más o menos rápidas y automáticas hasta el 6, por lo menos.
    El buffer1 es imprescindible porque no guardo el buffer0 y porque se guarda en dcraw_init() y no en dcraw_process(), es decir, no se puede volver a generar a partir del buffer 0. Lo único que afecta al buffer1 se pasa como parámetro a la función de inicialización, al leer el archivo, y es el black frame. Hasta ese punto no hay ningún parámetro. Si se cambia el black frame hay que volver a leer el archivo. No creo que haya problema con eso; de hecho, el black frame se pondrá en la zona de input, no en la de parámetros de revelado. Me parece más lógico así.

    A continuación vienen los siguientes parámetros: user_black, user_sat que controlan el punto negro y el de saturación respectivamente. Se aplican a la vez que el parámetro threshold, que controla la reducción de ruido RAW. Luego vienen los parámetros de balance de blancos y finalmente la eliminación de aberraciones cromáticas, la generación de patrones y el equilibrado de canales verde. Salvo la reducción de ruido, que es lenta, todo lo demás es rápido. Por eso se pone un buffer al terminar este punto y justo antes de interpolar. Si se cambia la interpolación, que ya de por sí es lenta, ¿no vamos a hacerla más lenta teniendo que revelar desde más atrás, no?

    Cita Iniciado por ariznaf Ver mensaje
    Bueno lo de los patrones no sé muy bien en qué consiste. En cualquier caso incluso la etapa 6 según tu esquema es más o menos rápida. Pero puede ser razonable poner ahí un buffer para no tener que irse al principio del todo cada vez que se toque un canal de Balance de blancos (además seguirá siendo un buffer pequeño, con los valores aún sin interpolar).
    Los de generar patrones consiste en poder sustituir la imagen de entrada por una imagen sintética generada de forma algorítmica antes de interpolar. De ese modo se pueden evaluar los algoritmos de interpolación y de recuperación de luces altas frente a situaciones límite (líneas en la frecuencia de Nyquist verticales, horizontales y diagonales, saturaciones de varios canales, transiciones muy suaves, etc.) sin tener que andar buscando esos patrones en imágenes reales. A mí me interesa para poder establecer comparativas y hacer experimentos.

    Cita Iniciado por ariznaf Ver mensaje
    El buffer 2 lo pones antes de la interpolación de Bayer... pero esta es automática ?no? el usuario no tiene nada que tocar ahí. Según lo dicho antes sobraría o en todo caso tendría que estar antes del 8 (ala salida del 7) si es que la corrección de aberraciones cromáticas va a ser controlada por el usuario.
    Desde el paso 5 al paso 8 ambos inclusive todos ocurren en la misma función de dcraw, scale_colors(). No puedo meter un buffer en medio sin tocar código de Coffin, y es una de las prioridades del proyecto. Como ves el buffer2 se toma justo a la salida de esa función, pero habrá que hacer algo para tomarlo entre la reducción de ruido y el balance de blancos para que lo use perfectRAW. Las aberraciones cromáticas se controlan con parámetros pero son rápidas, el algoritmo de interpolación se elije en el parámetro user_qual y puede ser más o menos lento. Como ya he puesto arriba, creo que es imprescindible tener un buffer justo antes y justo después de la interpolación.

    Cita Iniciado por ariznaf Ver mensaje
    El paso 10 ¿no es automático? ¿o es para dejar que se mezclen los canales con relaciones diferentes entre sí.... eso sólo tendría sentido en blanco y negro, no?
    El paso 10 es automático y lo que hace es convertir R G1 G2 B en R (G1+G2)/2 G2 B, luego se descarta G2 al pasar a RGB.

    Creo sinceramente que los buffers son los mínimos imprescindibles y que se toman en el punto adecuado. Si cuentas las etapas que están en negrita (las lentas, son 6) verás que coinciden con el número de buffers (del 0 al 5). Y están tan pronto después de las etapas lentas como es prudente ponerlos. Quizás en los puntos 11, 12 y 13 pueda ajustarse algo, como poner un buffer nuevo entre en 11 y el 12, o mover el buffer4 al justo después del 12, pero no veo que se gane nada y se desperdicia memoria. En la elección de los puntos para tomar los buffers también se ha tenido en cuenta el posible uso que futuras aplicaciones hagan de ellos. Mi idea es que la DLL permita a cualquier aplicación solicitar un buffer cualquiera y que la DLL revele hasta ese punto, la aplicación modifique el buffer, lo devuelva a la DLL y esta prosiga con el revelado. Es una especie de sistema de plugins para ampliar la funcionalidad de dcraw sin modificar nunca el código de Coffin. Es la versión más ambiciosa de la filosofía del proyecto: aprovechar el código de Coffin sin tocar una sola línea de él. Algunas de las cosas que están metidas ahora de otro modo (como la corrección gamma), irán más adelante implementadas de ese modo.

    Como ya he dicho antes, la DLL gestionará de manera transparente qué buffers utiliza y cuáles deja vacíos en función de los parámetros que se hayan especificado. Esto es así porque algunas etapas con los parámetros por defecto no hacen nada y pueden obviarse, pero hay otras que siempre hacen algo y esos buffers siempre habrá que llenarlos. También es importante aclarar que perfectRAW no tiene acceso a los buffers intermedios, solo al buffer final. Futuras versiones de perfectRAW o perfectBLEND serán otro cantar.

    Un saludo:
    Última edición por ManuelLlorens; 21/05/2008 a las 20:52
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  13. #13
    Ingreso
    22 mar, 08
    Ubicación
    Oviedo
    Mensajes
    14,367
    Post Thanks / Like
    Pues ha quedado bastante claro...
    En el esquema que habías puesto creía que había varios pasos no dependientes de selecciones del usuario, pero la verdad es que son muy pocos.
    Por tanto hay poco que rascar. Tampoco se va a poner un buffer en cada etapa, así que los que has puesto parecen muy razonables. Y salvo que el incremento en velocidad pudiera ser muy grane, no conviene poner buffers intermedios en aquéllas etapas en que dcraw lo haga en una sola función.
    Creo que la filosofía que tienes de tocar lo menos posible el código de Coffin es la que hay que seguir a toda costa, para evitar muchos futuros quebraderos de cabeza cuando se cambie la versión de dcraw.

    Lo que dices del buffer 0 me parece muy razonable, eso que nos ahorramos y el punto negro de la cámara no será algo con lo que uno quiera andar jugando cada dos por tres. Si se cambia no pasa nada por tener que leerlo.

    Me ha sorprendido lo que dices de que todos los buffers tienen el mismo tamaño del númerodepixels*8.
    Esperaba que antes del demosicing uno trabajara con una información "en escala de grises" y que fueran de numerodepixels*2. De hecho, en cada pixel sólo se capta la información del canal correspondiente al filtro de la matriz ¿no? por tanto los otros canales no tienen utilidad hasta el momento de hacer el demosicing en que se generan todos los canales.
    Me imagino que esto se debe a la forma de trabajo interna del dcraw. Pero ahí sí que se puede ganar mucha memoria:
    Para una cámara de N megapixels, el tamaño de un buffer con los cuatro colores sería de 8*N, mientras que si almacenamos únicamente un color sería de 2*N. como hay dos buffers antes del demosicing (interpolación de Bayer) serían 8*N frente a 4*N.
    para una imagen estandar de 10MP estaríamos hablando de 160MB frente a 40MB.

    Los buffers posteriores serán iguales para los dos métodos (6*N) y como hay tres hablamos de 18N, es decir ocuparán 180MB.
    Así con tal y como está hablamos de un total de 160MB + 180MB= 340MB.
    Si se almacenara solo el canal que se ha tomado en las primeras fases, hablaríamos de 220MB un 35% menos.

    Claro que si DCRaw espera el buffer como cuatro canales, hay que entregárselo así... lo único que se me ocurre es utilizar un sistema de codificación de canales para almacenar en el buffer solo el canal que interesa y decodificarlo antes de pasarlo a DCRaw (utilizando la matriz de Bayer para saber qué canal interesa).

    En cualquier caso no es nada que se haya de implementar en la primera versión, podría ser una mejora para el futuro para consumir menos memoria (siempre y cuando el algoritmo de codificación fuera muy rápido claro).

    La verdad es que da escalofríos la cantidad de memoria necesaria y la cantidad de información que se genera de una sola imagen.

  14. #14
    Ingreso
    07 mar, 06
    Ubicación
    Madrid (a ratos Alicante)
    Mensajes
    9,426
    Post Thanks / Like
    Manuel, la conversión a espacio de color + gamma sí se hace en float no? es decir que la gamma la aplicamos a un resultado aún no redondeado, y una vez aplicada se hace clipf. Es qeu si no es así no me explico que el histograma esté tan lleno de niveles en la parte baja.
    "En ocasiones veo halos."

    http://www.guillermoluijk.com para suscribirte haz clic aquí
    Último contenido: EL MITO DEL TRÍPODE QUE ASESINÓ A UN ESTABILIZADOR

  15. #15
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por _GUI_ Ver mensaje
    Manuel, la conversión a espacio de color + gamma sí se hace en float no? es decir que la gamma la aplicamos a un resultado aún no redondeado, y una vez aplicada se hace clipf. Es qeu si no es así no me explico que el histograma esté tan lleno de niveles en la parte baja.
    Sí, ahí si, pero no utiliza un buffer solo cuatro valores float (uno por canal).
    Última edición por ManuelLlorens; 22/05/2008 a las 12:14
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  16. #16
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por ariznaf Ver mensaje
    Lo que dices del buffer 0 me parece muy razonable, eso que nos ahorramos y el punto negro de la cámara no será algo con lo que uno quiera andar jugando cada dos por tres. Si se cambia no pasa nada por tener que leerlo.
    Sólo un matiz: el punto negro es el user_black, no el black_frame. El punto negro sí se podrá cambiar sin recargar la imagen, el black_frame es cuando tiras una foto de larga exposición con la tapa del objetivo puesta para captar el ruido y luego le restas esa foto a la tuya.

    Un saludo:
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es

  17. #17
    Ingreso
    30 abr, 08
    Ubicación
    Madrid
    Mensajes
    883
    Post Thanks / Like
    Cita Iniciado por ariznaf Ver mensaje
    Me ha sorprendido lo que dices de que todos los buffers tienen el mismo tamaño del númerodepixels*8.
    Esperaba que antes del demosicing uno trabajara con una información "en escala de grises" y que fueran de numerodepixels*2. De hecho, en cada pixel sólo se capta la información del canal correspondiente al filtro de la matriz ¿no? por tanto los otros canales no tienen utilidad hasta el momento de hacer el demosicing en que se generan todos los canales.
    Lo que ocurre es que, además del valor del captador, también tienes que respetar su "posición espacial" dentro de la matriz Bayer, es decir, la posición del captador en una matriz 2x2 que acabada dando lugar a un píxel de la imagen final, pues en la interpolación esa información es vital. Se podría crear un esquema más sofisticado que ocupara menos memoria, pero lo más complicado sería que funcionase en todos los tipos de matriz Bayer. dcraw tiene en cuenta eso.

    Internamente dcraw maneja una matriz 2x2 por cada píxel de la imagen, para ello define el buffer como ushort *image[4] = calloc(width*height, sizeof *image); es decir, una matrix de width*height*2 para los cuatro canales. Al principio algunos valores están vaciós y almacenan los valores RG1G2B, pero en un orden distinto en cada cámara. Cuando quieres un valor concreto, unas funciones tienen en cuenta el tipo de filtro de la cámara (variable filters) y te devuelven el valor del captador que tú solicitas. Según el algoritmo que vayas a aplicar te interesará tener en cuenta el captador o no y recorrerás el buffer de un modo u otro. Obviamente es un poco más rápido cuando no te importa el captador (por ejemplo para aplicar la gamma, aunque eso es otra historia porque se hace con RGB y no con RGGB), en otros algoritmos (como el balance de blancos o el equilibrado de los niveles de los captadores verdes) sí tienes que tener en cuenta el captador que estás modificando. Coffin tiene dos funciones (fc y FC) que te permiten encontrar en captador dentro del píxel 2x2.

    Cuando termine la parte que permitirá engancharse al revelado desde fuera (para perferctBLEND y similares), además del buffer se le pasarán unas funciones que permitirán recorrer el buffer de un modo u otro según el tipo de buffer (RG1G2B sin interpolar y por tanto con huecos, RG1G2B con los verdes equilibrados e interpolado y por tanto sin huecos, R(G1+G2)/2G2B con los verdes mezclados y finalmente, el que ocupa menos memoria, RGB) y la aplicación podrá recorrer el buffer que ha pedido sin conocer los entersijos de dcraw. perfectRAW usará el primer tipo de buffer, RG1G2B sin interpolar y por tanto con huecos.

    Un saludo:
    Manuel Llorens

    Olympus E-P1, E-510, E-300
    www.rawness.es


 

Marcadores

Marcadores

Permisos de publicación

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