OJODIGITAL

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:
15. 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:
16. 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:

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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!

__________________

Canon EOS 350D | EOS 300 | 10-22 | 24-70 f2.8L | 70-200 f4L | 300 f4L IS
http://www.guillermoluijk.com para suscribirte pulsa aquí

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 .

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.

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:

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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.

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.

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.

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-510, E-300
Mis fotos

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:

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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.

__________________

Canon EOS 350D | EOS 300 | 10-22 | 24-70 f2.8L | 70-200 f4L | 300 f4L IS
http://www.guillermoluijk.com para suscribirte pulsa aquí

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:

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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?

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

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?

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.

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.

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:

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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.

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.

__________________

Canon EOS 350D | EOS 300 | 10-22 | 24-70 f2.8L | 70-200 f4L | 300 f4L IS
http://www.guillermoluijk.com para suscribirte pulsa aquí

Sí, ahí si, pero no utiliza un buffer solo cuatro valores float (uno por canal).

__________________
Manuel Llorens
Olympus E-510, E-300
Mis fotos

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-510, E-300
Mis fotos

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 ac