Iniciado por
ariznaf
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;
Iniciado por
ariznaf
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.
Iniciado por
ariznaf
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?
Iniciado por
ariznaf
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.
Iniciado por
ariznaf
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.
Iniciado por
ariznaf
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:
LinkBack URL
About LinkBacks
Citar
.
Marcadores