Tema: Librería para salvar DNG

Bueno, ya tengo practicamente finalizada la librería. El único método exportado es:

Código:

    DNG_SAVE_API int DNG_Save(unsigned char * raw_image, int width, int height, tDNG_Parameters & dng_params, tExif & exif, unsigned char * XMP_Buffer, unsigned int XMP_Size)

y la estructura que emplea es tal que así:

Código:

struct tDNG_Parameters
    {
        ////////////////////////////////////////////////////
        //Camera profile: needed to develop correct colors /
        ////////////////////////////////////////////////////
        char * stCameraProfileName;
        // Colorimetric matrix for illuminant 1
        double dCameraMatrix1[9];
        unsigned int uiCameraIluminant1;
        // Colorimetric matrix for illuminant 2
        double dCameraMatrix2[9];
        unsigned int uiCameraIluminant2;
        ////////////////////////////////////////////////////

        ////////////////////////////////////////////////////
        //Bayer Mosaic: colors used and distribution ///////
        ////////////////////////////////////////////////////
        unsigned int uiBayerColorkeys[4];
        unsigned int uiBayerPattern;
        ////////////////////////////////////////////////////

        ////////////////////////////////////////////////////
        // Maximum/minimum levels to use in 16bit data /////
        ////////////////////////////////////////////////////
        unsigned int uiWhiteSaturation;
        unsigned int uiBlackLevel;
        ////////////////////////////////////////////////////

        // Exposure correction
        double dBaselineExposure;
        // Noise index
        double dBaselineNoise;
        // Sharpness needed
        double dBaselineSharpness;
        /// "AsShot" white balance
        double dWhiteBalance[3];
        // Green Split (how far away are green pixels, usually zero)
        unsigned int uiGreenSplit;
        // Camera name
        char * stModelName;
        char * stLocalModelName;
        // Image orientation
        unsigned int uiOrientation;
        //// Final image size
        //   Crop Origin (from top-left)
        unsigned int uiCropOriginX;
        unsigned int uiCropOriginY;
        //   Crop Size
        unsigned int uiCropWidth;
        unsigned int uiCropHeight;
        // Active area (same as image, modify it if there's some masked pixels)
        //   Active Origin (from top-left)
        unsigned int uiActiveOriginX;
        unsigned int uiActiveOriginY;
        //   Active Size
        unsigned int uiActiveWidth;
        unsigned int uiActiveHeight;  
}

la del exif es eterna... vamos a implementar todo o sólo los importantes? De momento implementados están: apertura, tiempo de exposición, ISO y focal. La estructura es (he quitado los parametros de GPS):

Código:

struct tExif
    {
        char * fImageDescription;
        char * fMake;
        char * fModel;
        char * fSoftware;
        char * fArtist;
        char * fCopyright;
        char * fCopyright2;
        char * fUserComment;

        tDateTime    fDateTime;
        tDateTime    fDateTimeStorageInfo;
        tDateTime    fDateTimeOriginal;
        tDateTime    fDateTimeOriginalStorageInfo;
        tDateTime     fDateTimeDigitized;
        tDateTime    fDateTimeDigitizedStorageInfo;

        unsigned int fTIFF_EP_StandardID;
        unsigned int fExifVersion;
        unsigned int fFlashPixVersion;

        tRational fExposureTime;
        tRational fFNumber;
        tRational fShutterSpeedValue;
        tRational fApertureValue;
        tRational fBrightnessValue;
        tRational fExposureBiasValue;
        tRational fMaxApertureValue;
        tRational fFocalLength;
        tRational fDigitalZoomRatio;
        tRational fExposureIndex;
        tRational fSubjectDistance;
        tRational fGamma;

        tRational fBatteryLevelR;
        char *    fBatteryLevelA;

        unsigned int fExposureProgram;
        unsigned int fMeteringMode;
        unsigned int fLightSource;
        unsigned int fFlash;
        unsigned int fFlashMask;
        unsigned int fSensingMethod;
        unsigned int fColorSpace;
        unsigned int fFileSource;
        unsigned int fSceneType;
        unsigned int fCustomRendered;
        unsigned int fExposureMode;
        unsigned int fWhiteBalance;
        unsigned int fSceneCaptureType;
        unsigned int fGainControl;
        unsigned int fContrast;
        unsigned int fSaturation;
        unsigned int fSharpness;
        unsigned int fSubjectDistanceRange;
        unsigned int fSelfTimerMode;
        unsigned int fImageNumber;

        unsigned int fFocalLengthIn35mmFilm;

        unsigned int fISOSpeedRating;

        unsigned int fSubjectAreaCount;
        unsigned int fSubjectArea [4];

        unsigned int fComponentsConfiguration;

        tRational fCompresssedBitsPerPixel;

        unsigned int fPixelXDimension;
        unsigned int fPixelYDimension;

        tRational fFocalPlaneXResolution;
        tRational fFocalPlaneYResolution;

        unsigned int fFocalPlaneResolutionUnit;

        unsigned int fCFARepeatPatternRows;
        unsigned int fCFARepeatPatternCols;

        unsigned int fRelatedImageWidth;    
        unsigned int fRelatedImageLength;

        char * fCameraSerialNumber;

        tRational fLensInfo [4];

        char * fLensID;
        char * fLensName;
        char * fLensSerialNumber;

        tRational fFlashCompensation;

        char * fOwnerName;
        char * fFirmware;
    };

Como veis, es un monstruo. ¿Qué hacemos con ella?

A nivel de funcionalidad sólo me queda calcular el preview correcto. Había pensado por no tener problemas de copyright hacer un diezmado al 50% en ambos ejes, con lo que queda una imagen de width/2 x height/2 que no necesita interpolación, un R de bayer es un R de la imagen final, un B de bayer es un B en la imagen final, y dos G de bayer se promedian para ser un G en la imagen final. Luego aplico el calibrado de cámara y el balance de blancos y guardo el resultado como preview.

Dudas, opiniones, sugerencias...?

Lo veo todo perfecto.

Los datos EXIF hay que pasarlos íntegros porque nadie va a querer renunciar a perder ni un solo dato. Ya hay puristas que dicen que DNG no es perfecto porque no mantiene el 100% de la información que recoge la cámara, de ahí que la iniciativa OpenRAW aún tenga camino por delante. Si encima al pasar por nuestros programas se pierden algunos datos, tarde o temprano nos iban a pedir que los pusiéramos y, si no cuesta demasiado hacerlo bien desde el principio...

El preview que comentas es el único posible que es independiente del interpolado (en principio si interpolaras por cualquier método y luego redujeras al 50% en ambos ejes el resultado debería ser prácticamente idéntico) y encima es lo más rápido de calcular, por tanto, creo que es el preview perfecto.

Un saludo:

Lo que es cierto es que la mayor parte de los datos EXIF no los necesitamos para nada en el programa, sólo para guardarlos en el DNG.

Por tanto a lo mejor no es necesario leerlos y almacenarlos en una estructura, sino simplemente trasvasarlos del buffer exif del raw de entrada al dng de salida.

Tal y como está ahora ¿cómo se leen los datos exif? ¿Los lee dcraw?
¿Se podrían ller con el adobe dng sdk y guardarlos directamente (sin procesar) en el dng de salida?

Hacerlo así nos evitaría problemas con datos exif propietarios, campos no documentados....

Nosotros sólo necesitaríamos los datos de disparo, ajuste de blancos o similares.

Otra cosa que te propongo Egon, es no hacerlo todo en una sola función.

Hay que pasarle un montón de estructuras y será más difícil de mantener.

Se podría dividir en:
-dng_open_file para pasar el nombre de fichero a crear. Devolvería una ID del fichero (o podría ser el constructor de una clase DNGFile)
-dng_save_parameters guardar la información de la matriz de Bayer, balance automático, etc.
-dng_save_exif
_dng_save_rawdata guardar los datos de la imagen en sí.
-dng_save_xmp
-dng_close

¿No os parece que sería más flexible, fácil de implementar y sobre todo de mantener?

Implementado como una clase C++ que se pueda usar desde C# ya quedaría de miedo, pero no sé si esto lo habéis hecho alguna vez, ya que tiene su historia (hay que encargarse de mantener el contador de uso y liberar memoria, etc).

Implementado como una clase C++ que se pueda usar desde C# ya quedaría de miedo, pero no sé si esto lo habéis hecho alguna vez, ya que tiene su historia (hay que encargarse de mantener el contador de uso y liberar memoria, etc).

Lo iba a hacer así, pero como os daba tanto miedo el C++ al final opté por una función suelta... Si me dais carta blanca lo hago como clase todo ordenadito
_________________________________
Bueno, tengo un problema con la construcción del preview:

Construyo la imagen de Width/2 x Height/2 tomando un R, un B y la media de los dos G de un quad de 2x2 (RGGB) para cada pixel, y funciona ok. La imagen que tengo hasta ahora es correcta, en lineal, y sin perfil de cámara ni balance de blancos: tal cual sale del sensor. Aquí viene mi problema:

Tengo la matriz de calibrado de cámara, y el vector de balance de blancos. Lo aplique como lo aplique, el color se va mucho. He probado lo siguiente:

Dado un pixel (R,G,B) lo multiplico por el balance de blancos, elemento a elemento. Es decir:

siendo el vector balance de blancos: (wbR, wbG, wbB) = (0.4746,1.0,0.51)

obtengo el pixel corregido con balance de blancos:

(cR, cG, cB) = (R*wbR, G*wbG, B*wbB);

Obviamente la imagen se tinta de verde, puesto que el valor es casi el doble que el de los otros dos canales. Pienso "ok, eso es porque aún no he calibrado el color de cámara", así que hago:

siendo la matriz de calibración de camara:
c0 c1 c2 0.9437 -0.2811 -0.0774
C = c3 c4 c5 = -0.8405 1.92515 0.2290
c6 c7 c8 -0.0710 0.0596 0.7181

(fR,fG,fB) = (cR,cG,cB)*Ct =

= cR*c0 - cG*c1 - cB*c2, cR*c3 - cG*c4 - cB*c5, cR*C6 - cG*c7 - cB*c8

Transpongo la matriz C por la fila del medio, tiene un 1.92 en el verde y un -0,84 en el rojo, y asumo que pertenecen a la misma operación. De todas maneras he probado sin transponer y tampoco queda bien. De hecho el color que mejor queda es no tocar nada, directo del sensor aplicar gamma y ya. Pero no son los colores correctos del todo.

¿Alguien me puede iluminar?
_________________________________
Acabo de descubrir el error aplicando el balance de blancos... No es multiplicador, es DIVISOR! Si aplico el balance de blancos sobre la imagen dividiendo se me queda el mismo color que con el ACR, pero un poco menos saturado. Tengo que probar con más imágenes a ver si es cierto.

Por otro lado, sigo sin encontrar la manera de aplicar el perfil de cámara. Si no se lo paso al ACR la imagen sale un poco peor de color (más saturada y con clipping) y si se lo paso el color sale clavado. Si yo no lo aplico casi clavo al ACR pero con menos saturación, y no he encontrado la manera de aplicarlo correctamente...

Egon: me he perdido...
No entiendo por qué tienes que hacer nada de balance de blancos ni calibración de color.
Se supone que tú lo que almacenas es el RAW SIN PROCESAR, únicamente almacenarás los parámetros de calibrado y balance de blancos que vienen del RAW original y los escribirás en el DNG. Luego el formato de la matriz de BAYER, datos EXIF y xmp y los datos en bruto tal cuál estaban en el RAW original.

¿Por qué dices que el balance no te funciona? Tú no tendrías que hacer balance.
¿Me he perdido algo?

En cuanto a lo de la librería de clases en C++, yo tendría miedo a tener que pelearme yo con crear una clase que se pueda manejar desde .NET, pero si lo haces tú, no hay problema, pues en .NET lo usaremos de forma transparente, como si fuera una clase nativa.

Una solución intermedia (que a veces se usa) sería programar en C usando funciones (no clases) y luego hacer un wrapper en C# para que se vea como una clase. Pero si tú tienes claro cómo se programa una clase manejada (.NET) en C++, no hay problema, al menos por mi parte.

En el curro trabajo diariamente con clases hechas por nosotros en C++ e importadas a C# sin el mayor problema. Por eso no te preocupes.

Lo del balance de blancos, lo hago para guardar el preview. En el DNG es obligatorio guardar un preview, y lo estoy sacando desde el negativo, tal como os comenté, diezmando en lugar de interpolando. Pero para que el preview quede decente, tengo que aplicarle calibración de cámara y balance de blancos... En eso estoy. De momento ya lo tengo decente, pero bastante menos saturado que como lo interpreta el ACR, he conseguido aplicar el WB pero no el perfil de cámara.

AH! vale, no había entendido lo del preview.

Eso creo que GUI lo tendrá más que superado, así que habrá que esperar a que se pase por aquí.

De todas formas en el raw original ¿no hay un preview también?
DCraw tenía una opción para extraer el preview del raw.

Iniciado por Egon

Lo del balance de blancos, lo hago para guardar el preview. En el DNG es obligatorio guardar un preview, y lo estoy sacando desde el negativo, tal como os comenté, diezmando en lugar de interpolando. Pero para que el preview quede decente, tengo que aplicarle calibración de cámara y balance de blancos... En eso estoy. De momento ya lo tengo decente, pero bastante menos saturado que como lo interpreta el ACR, he conseguido aplicar el WB pero no el perfil de cámara.

Si lo estás haciendo bien el preview debería parecer poco contrastado y algo oscuro. No esperes que quede como sale del ACR por defecto porque ACR por defecto aumenta el brillo un 50% y el contraste un 25%, es una de las cosas que no nos gusta de ACR, que procese la imagen sin "pedirnos permiso". Por otro lado, ¿no estás aplicando ninguna gamma, no? Entonces es gamma 1.0 y tiene que parecer definitivamente oscuro, aplica una sRGB por defecto y no te preocupes demasiado del resultado.

Y yo también estoy de acuerdo en que lo suyo es que hagas una clase, si no te cuesta mucho, la alergia es a programar C++ nosotros, no a que lo hagan otros .

Un saludo:

Sí aplico gamma, así que oscuro no queda. Lo haré así y lo salvaré tal cual, total, al fin y al cabo es un preview... Durante esta semana lo convertiré en una clase. ¿Dónde dejo el código? ¿Google code? ¿Otro sitio?

En google code mejor ¿no?
Pero crear un directorio separado de lo de perfectraw.

Para lo del preview ¿no creéis que sería mejor extraerlo del raw original directamente, utilizando dcraw?
Evita el tener que hacer nada y tendrás un preview "de alta calidad" como el sacado por la cámara.

Buenas, he leido este hilo y me he dado cuenta de que acondicionar los datos de entrada antes de empezar a fusionarlos va a requerir algo de trabajo previo. Por partes:

PREVIEW

Para el preview, creo que es mejor no reinventar la rueda y reutilizar lo que se precise de DCRAW (su opción -h lleva a una parte de código que realiza todos los pasos menos la interpolación, produciendo muy rápido una imagen Width/2, Height/2 lista para aplicarle la gamma y mostrarla). Lo suyo sería usar ese código para generar un bitmap visualizable. El GUI de Perfect RAW debería ser reutilizable para la parte gráfica en pantalla.


FUSIÓN

Lo que habrá que currarse un poco más, y ahora no hablo del preview sino de la fusión en sí, es el acondicionamiento previo de los datos de los RAW originales antes de proceder a la fusión, y para esto propongo de nuevo fusilar las partes de DCRAW requeridas.

La salida final perseguida es un DNG lineal de 16 bits, pero con los datos en el espacio de qué cámara? DCRAW tiene matrices Camara->XYZ y XYZ->Salida, para todas las cámaras.

Una opción es dejar los datos de salida en el espacio de la cámara origen, pero esto dudo que sea compatible con una salida de 16 bits si la cámara usada es de menos bits ya que el DNG debe poder revelarse en cualquier revelador (ACR, PerfectRAW,...), el cual "esperará" un RAW en el formato de esas cámaras con todas sus peculiaridades. Por eso esta opción limitaría la salida al mismo número de bits que tenga la cámara usada, lo cual es una lástima pues no llegaríamos a más de 12 pasos de rango dinámico en cámaras de 12 bits (hoy por hoy aún casi todas), cuando se pueden alcanzar virtualmente 16 pasos con 16 bits.

Otra opción es convertir a un formato de DNG de 16 bits con unos datos EXIF de plantilla que conozcamos, pero entonces deberán aplicarse conversiones de perfil de cámara con la dificultad colorimétrica que esto tenga y con posibles saturaciones y follón. Yo casi lo descartaría.

No sé, tenemos que pensar sobre esto, no veo una solución clara.


Lo que no es eludible como paso previo a hacer la fusión es el acondicionamiento de los datos de entrada (por ejemplo las Canon no sustraen en el RAW su nivel de negro, esto tenemos que hacerlo nosotros a pelo).

Para ello, Egon, la función scale_colors() de DCRAW (comentada aquí) hace la mayoría de estas cosas de las que como poco tenemos que fusilar:
- Sustracción del nivel negro
- Escalado del máximo al punto de saturación
- Paso de la escala de 10/12/14 bits a 16 (si no renunciamos a la salida en 16 bits)

La salida debe ser un DNG de 16 bits, lineal, sin ruido y con el mismo nivel de exposición (escalado por 1.0) que el RAW menos expuesto participante. Pero antes de tener datos lineales en 16 bits hay que hacer esas operaciones.

Bueno me estoy dando cuenta que la cosa tiene un poquillo de tela, a ver si el martes cuando nos juntemos Manuel hablamos un poco de todo esto, hay que darle más vueltas.

Lo que sí os digo es que estoy viendo la necesidad de parar y planificar un poco los pasos a seguir y herramientas a usar. Como empecemos a hacer cosas sueltas: Perfect RAW, Perfect Blend, OpenGL sí, OpenGL no, etc... nos vamos a liar pero bien y será mucho tiempo perdido.

Como lo del DNG veo que va a tener más tela de la prevista, quizá lo inteligente sea no dispersarnos ahora (primer culpable yo que le comenté lo del DNG a Egon), y centrarnos en Perfect RAW hasta acabarlo (muchas partes serán reutilizables para el preview del programa de fusión):
- Yo ponerme al día de C que ni he abierto el libro aún
- Manuel seguir afinando el AFD y la gestión de color
- Fernando evolucionar el GUI
- Egon empaparse de todo lo que han hecho Fernando y Manuel, o evolucionar en lo del DNG de manera individual

Qué os parece? el martes Manuel y yo nos veremos para hablar un poco de todo el tinglado.

Salu2

Hey hey hey... No te me aceleres con respecto al DNG. Creo que estás incluyendo cosas en la librería de DNG que corresponderían a perfectBLEND. Yo lo único que hago es guardar el negativo que me pasas, no me corresponde hacerle nada al los datos crudos. Yo sólo "informo" al DNG de los niveles de black y saturation y perfil de cámara, y es el revelador el que tendrá que interpretarlos. Es decir, todo lo que has dicho se puede hacer pero fuera de la librería. Si me pasas datos de 12bits, yo los guardo como 12 bits en el DNG, y lo documento en el fichero. Si tú esos 12bits los quieres procesar, extenderlos a 16, o lo que sea necesario, hazlo y modifícame los parámetros del DNG para indicarlo. Es decir, si tenemos un RAW de 12 bits con un nivel de negro 64, saturación a 4095, y tu lo procesas de alguna manera para que el nivel de negro sea 0 y la saturación 65535, simplemente cuando guardes el raw, me dices esos valores y yo lo guardo. Y si preaplicas algún espacio de color dependiente de la cámara, en lugar de pasarme el perfil de la cámara me pasas una matriz identidad para que posteriormente el revelador no haga ninguna transformación más. Yo sigo viendo la librería de DNG como una clase "tonta" que solo se encarga de transcribir el negativo a disco en formato DNG, y como mucho, crea un preview si no se lo has pasado tu antes (porque el preview es necesario para poder guardar el DNG). Yo no le metería más inteligencia en absoluto, todo lo que haya que hacer de acondicionamiento del DNG iría fuera de esta clase.

Qué opinas?

Iniciado por Egon

Hey hey hey... No te me aceleres con respecto al DNG. Creo que estás incluyendo cosas en la librería de DNG que corresponderían a perfectBLEND. Yo lo único que hago es guardar el negativo que me pasas, no me corresponde hacerle nada al los datos crudos. Yo sólo "informo" al DNG de los niveles de black y saturation y perfil de cámara, y es el revelador el que tendrá que interpretarlos. Es decir, todo lo que has dicho se puede hacer pero fuera de la librería. Si me pasas datos de 12bits, yo los guardo como 12 bits en el DNG, y lo documento en el fichero. Si tú esos 12bits los quieres procesar, extenderlos a 16, o lo que sea necesario, hazlo y modifícame los parámetros del DNG para indicarlo. Es decir, si tenemos un RAW de 12 bits con un nivel de negro 64, saturación a 4095, y tu lo procesas de alguna manera para que el nivel de negro sea 0 y la saturación 65535, simplemente cuando guardes el raw, me dices esos valores y yo lo guardo. Y si preaplicas algún espacio de color dependiente de la cámara, en lugar de pasarme el perfil de la cámara me pasas una matriz identidad para que posteriormente el revelador no haga ninguna transformación más. Yo sigo viendo la librería de DNG como una clase "tonta" que solo se encarga de transcribir el negativo a disco en formato DNG, y como mucho, crea un preview si no se lo has pasado tu antes (porque el preview es necesario para poder guardar el DNG). Yo no le metería más inteligencia en absoluto, todo lo que haya que hacer de acondicionamiento del DNG iría fuera de esta clase.

Qué opinas?

Ya te entiendo, pero yo ya estaba pensando en global, en el objetivo final de la conversión a DNG y en los problemas que vamos a encontrarnos (fuera o dentro de la clase tonta que genera ese DNG) tarde o temprano, porque el objetivo de escribir el DNG es hacerlo con los datos fusionados de varios RAW. Es decir que una librería que solo empaqueta un RAW marca ACME en un DNG no sirve porque el objetivo es:

N RAWs marca ACME -> Fusión (lo que requiere acomodar negro, sat, perfil de cámara y escala de bits como poco) -> generación de 1 DNG de salida.

Cómo se haría esa preaplicación del espacio de color dependiente de la cámara? es una matriz que llevan los propios RAW y que en el DNG de salida, hecha la conversión puede indicarse como una matriz unidad, o estamos hablando de las matrices de conversión Cámara->XYZ que lleva DCRAW por ejemplo?

Yo estoy con Egon en eso.
Está claro que para perfectBlend la salida ha de ser de 16 bits y no de 12, aunque la cámara sea de 12 bits.
Por lo que he visto del DNG, la información del número de bits y formato empleado está en el propio DNG y no se basa en el modelo de la cámara. El DNG está pensado para ser un formato autodescriptivo, sin necesidad de una base de datos de cámaras. Lo único que sería dependiente de la cámara serían los campos propietarios.

Entiendo que el utilizar 16 bits implica modificar los niveles de negro a 0 y de saturación a 65535.
Los colores creo que si es posible deberían de guardarse sin interpretar, en el perfil de la cámara y no en XYZ o AdobeRGB.
Claro que para eso habrá que modificar los multiplicadores de la matriz y escalarlos adecuadamente ¿no?

Entiendo que los reveladores sólo usan esa información para la interpretación del color y no la información del modelo de la cámara.
El guardarlo así, permitirá que el revelador emplee la información de la cámara para corregir aberraciones cromáticas, de lente, etc.

Sino fuera así y esto no funcionara, habría que crear una cámara virual perfectblend cambiando los datos exif correspondientes, pero espero que no sea necesario.

Un problema puede ser con lo de sustración del nivel de negro. Dices que Canon no lo sustrae, por lo que almacenará esa información en alguna parte.
Si nosotros lo guardamos ya sustraido (parece lo lógico) habría que cambiar esa información para poner un nivel de negro a sustraer 0.
Si esa información no estuviera y dependiera del modelo de cámara (no creo) tendríamos que volver a sumar ese nivel de negro, para que el revelador lo volviera a sustraer basado enel modelo de cámara.

En cuanto a lo que comentas respecto a Perfect RAW estamos de acuerdo.
De hecho, para la primera versión (1.0) seguimos pensando en utilizar .NET. OpenGL sólo sería para mostrar la imagen y hacer el escalado, que estaba dando algún problema.
Sólo queda que Egon haga un ejemplo y entonces adaptar lo que había.
El resto seguiremos en .NET y poniendo unos controles simples (desplegables, y deslizadores).
Creo que en eso estábamos todos de acuerdo, para no retrasar la cosa.

Una vez tengamos eso y hallamos cogido confianza con el OpenGL, sería el momento de plantearse en serio la migración de toda la aplicación a OpenGL con SDL u otra librería. Parece que se tendrían muchos menos problemas de portabilidad y más rapidez y flexibilidad en la interface.

Iniciado por ariznaf

Entiendo que el utilizar 16 bits implica modificar los niveles de negro a 0 y de saturación a 65535.
Los colores creo que si es posible deberían de guardarse sin interpretar, en el perfil de la cámara y no en XYZ o AdobeRGB.
Claro que para eso habrá que modificar los multiplicadores de la matriz y escalarlos adecuadamente ¿no?

Entiendo que los reveladores sólo usan esa información para la interpretación del color y no la información del modelo de la cámara.
El guardarlo así, permitirá que el revelador emplee la información de la cámara para corregir aberraciones cromáticas, de lente, etc.

Si se puede pasar a 16 bits, sustraer el nivel de negro y ajustar el de saturación, y luego guardar el resultado en un DNG de 16 bits que los reveladores estándar interpreten correctamente (para lo cual en algún sitio debe participar o como poco ha de ir metida la información relativa a la respuesta colorimétrica de la cámara concreta que generó ese RAW), entonces todo OK no habría problema.

Yo me pierdo con esto, no sé si en cada RAW viene incrustada una matriz que identifica la respuesta de color de la cámara o qué, porque pensaba que eran los reveladores RAW los que debían adaptarse a cada cámara para realizar la conversión Cámara->XYZ (de hecho DCRAW incluye la matriz de conversión que Adobe le pasó a Coffin para cada cámara. Pensaba que simplemente DCRAW detectaba en los EXIF el modelo de cámara que generó el RAW, y usaba la matriz correspondiente. Lo que buscamos es precisamente lo que hace DCRAW cuando se revela con -o 0, esto Manuel se lo tiene que saber, pero el revelador RAW destino ha de saber interpretar correctamente los niveles generados y para eso hay que pasarle la información de algún modo).

A ver que dice Egon, pero el objetivo es éste: poder meter en un DNG de 16 bits la información fusionada de N RAWs de cualquier cámara, y que ese DNG sea interpretado (colorimétricamente) de manera correcta por cualquier revelador.

Para poder llevar a cabo la fusión, la sustracción del nivel de negro (se calcula de los píxeles ocultos) y el ajuste de la saturación a 65535 debemos hacerlos nosotros previamente.

Salu2

Iniciado por _GUI_

Para poder llevar a cabo la fusión, la sustracción del nivel de negro (se calcula de los píxeles ocultos) y el ajuste de la saturación a 65535 debemos hacerlos nosotros previamente.

No hay ningún problema porque, como dice ariznaf, el DNG es autocontenido y lleva toda la información necesaria para revelarse, aunque el revelador no conozca la cámara, cosa que no le pasa a dcraw/perfectRAW con los demás RAWs (de hecho, y que me corrija Egon si me equivoco, de momento la salida de la DLL de Egon sale negra en perfectRAW).

Tendremos que meter unas matrices de nuestra "cámara virtual" que "no hagan nada" y meter en el DNG esos datos (junto a punto negro y saturación a 0-65535), pero NO deberíamos retocar el EXIF, porque algunos plugins de PS (como PTLENS, por ejemplo) para arreglar el enfoque o la distorsión de la lente necesitan saber el modelo de cámara real que hizo al foto. Si ponemos "cámara ACME" nos cargamos eso.

Yo pondría los datos EXIF de la toma menos expuesta, incluyendo el tiempo de exposición de esa toma (que será la última que cargue perfectBLEND).

Un saludo:

¿Y si Egon deja la DLL de DNG como está y la encapsula en una clase a parte? Lo digo porque se pueda llamar desde más lenguajes, no solo los OO, ¿no?

Un saludo:

Mucho que leer en poco tiempo, cuando llegue a casa del curro os contesto...

Iniciado por ManuelLlorens

No hay ningún problema porque, como dice ariznaf, el DNG es autocontenido y lleva toda la información necesaria para revelarse, aunque el revelador no conozca la cámara, cosa que no le pasa a dcraw/perfectRAW con los demás RAWs (de hecho, y que me corrija Egon si me equivoco, de momento la salida de la DLL de Egon sale negra en perfectRAW).

Tendremos que meter unas matrices de nuestra "cámara virtual" que "no hagan nada" y meter en el DNG esos datos (junto a punto negro y saturación a 0-65535), pero NO deberíamos retocar el EXIF, porque algunos plugins de PS (como PTLENS, por ejemplo) para arreglar el enfoque o la distorsión de la lente necesitan saber el modelo de cámara real que hizo al foto. Si ponemos "cámara ACME" nos cargamos eso.

Yo pondría los datos EXIF de la toma menos expuesta, incluyendo el tiempo de exposición de esa toma (que será la última que cargue perfectBLEND).

Eso es, Manuel, así es como yo lo veo: el DNG se supone que es autocontenido y tiene toda la información del revelado.

Los EXIF no deberían de cambiarse, para que el revelador sepa la cámara de que proviene. Incluso los campos propietarios han de estar ahí por si el revelador sabe hacer algo con ellos.

Una forma de ver el camino correcto es analizar los dng que genera el convertidor a dng de Adobe. Creo que él meterá la información colorimétrica correspondiente a la cámara en la matriz de la que Egon habla.

Lo que sí puede ser necesario cambiar serán los exif correspondientes al punto negro y de saturación y de nivel de negros (si es que se guardan en los exif, que no lo sé).

En cuanto a lo de la matriz que no haga nada, creo que sería mejor (si es posible) no cambiar la información de color, no procesarla, y guardar la matriz colorimétrica de la cámara. Cuanto menos se modifique la información original, mejor.
PerfectBlend debería limitarse a seleccionar la información del pixel de la foto adecuada, sin tocar para nada (en la medida de lo posible) la información existente.
Interpretar el color y demás es cosa del revelador.

Claro que no sé si eso es posible en el algoritmo de GUI.

Iniciado por ManuelLlorens

¿Y si Egon deja la DLL de DNG como está y la encapsula en una clase a parte? Lo digo porque se pueda llamar desde más lenguajes, no solo los OO, ¿no?

Egon tal y como lo implementa, creo que prepara una clase C++ y luego la encapsula desde C#.

Si es necesario poder llamarla desde C o VisualBasic 6, sólo se podrían usar funciones globales, y no métodos de clase en la librería C++.
Veamos cómo lo implementa Egon y luego si es necesario se convierte en una librería de C en vez de C++, no creo que fuera difícil.

Iniciado por ariznaf

PerfectBlend debería limitarse a seleccionar la información del pixel de la foto adecuada, sin tocar para nada (en la medida de lo posible) la información existente.
Interpretar el color y demás es cosa del revelador.

Claro que no sé si eso es posible en el algoritmo de GUI.

Eso es lo que me parece que nos está queriendo decir GUI, que la matriz de color hay que aplicarla previamente para sus algoritmos. Si es así, habrá que poner una matriz que no haga nada, no creo que eso importune a los reveladores.

Iniciado por ariznaf

Egon tal y como lo implementa, creo que prepara una clase C++ y luego la encapsula desde C#.

Si es necesario poder llamarla desde C o VisualBasic 6, sólo se podrían usar funciones globales, y no métodos de clase en la librería C++.
Veamos cómo lo implementa Egon y luego si es necesario se convierte en una librería de C en vez de C++, no creo que fuera difícil.

Pero primero ya la había implementado para llamarla desde C como una DLL, así que es mejor dejarla así y encapsularla desde los distintos lenguajes, da menos trabajo y permite que la use más gente cuando la liberemos, ¿no? Es lo que suele hacerse.

Un saludo:

No tengo mucho tiempo porque estoy de nuevo en el trabajo, pero os comento:

- Como dice Ariznaf, el DNG es autocontenido. El revelador no necesita saber para nada de qué cámara proviene.

- El punto negro y saturación son parámetros del negativo propiamente dicho. No están en el exif que yo sepa.

- El DNG lleva incrustado el perfil de cámara (en total son cuatro matrices). Lo que no sé es si esas matrices salen del fichero raw original o las pone el convertidor de adobe al hacer el DNG. Esto lo sé porque para probar el conversor, cojo un raw de mi cámara (.ARW) lo convierto a DNG con el de adobe, y luego extraigo el negativo puro y duro (ellos lo llaman stage1) con dng_validate.exe. Esa es la única entrada que tiene el DNG, la matriz de Bayer. Del DNG que convirtió adobe extraigo los perfiles de cámara, saturación, punto negro... (apuntándolos en un folio leyendo de la salida verbose de dng_validate) y luego se los paso a mi negativo como parámetros. De hecho, ahora que GUI a comentado que hay dos matrices (Camara->XYZ y XYZ->RGB) entiendo que el DNG lleve también dos matrices, pero tengo que hacer pruebas a ver qué es cada una.

- Lo que _GUI_ dice de los 16 bit fue la primera prueba que hice. Cogí el buffer de bayer de mi cámara, y lo escalé a [0-65535], y guardé así el negativo. El ACR lo pilló sin mayor problema.

- El mecanismo por el que paso una clase de C++ en DLL a C# permite que también se usen desde un lenguaje no OO. En cuanto tenga el ejemplo os lo enseño.

Un saludo!

Iniciado por ManuelLlorens

Eso es lo que me parece que nos está queriendo decir GUI, que la matriz de color hay que aplicarla previamente para sus algoritmos. Si es así, habrá que poner una matriz que no haga nada, no creo que eso importune a los reveladores.

No no, los algoritmos solo necesitan linealizar la imagen al rango 0..65535 (es decir restar el punto negro, que no va en los EXIF sino que se calcula de los píxels ocultos (esto se puede fusilar de DCRAW), y ajustar la saturación (que al menos DCRAW tampoco la saca de los EXIF, sino que la tiene informada en el código para cada cámara; algunas incorrectas por cierto).

Los algoritmos de fusión no me preocupan nada, lo que me preocupa es que la información de color del DNG resultante sea correctamente interpretada por los reveladores RAW independientemente de la cámara origen. Por eso digo que el DNG final debe incluir de algún modo la información necesaria para que sea así, pero claro aquí me pierdo no tengo ni idea de como funciona la conversión a DNG.

Por lo que yo sé DCRAW lee de los EXIF el modelo de cámara (pero solo qué modelo de cámara es, no ninguna matriz), y es el propio código de DCRAW el que lleva para cada cámara las matrices Camara->XYZ y XYZ->RGB de Adobe a aplicar. Sí que hay en los EXIF unos multiplicadores de balance de blancos Daylight informados en cada cámara (pueden verse con -v -i), pero no sé dónde entran en juego:

Código:

C:\>dcraw -v -i chica.cr2

Filename: chica.cr2
Timestamp: Mon Sep 18 17:46:49 2006
Camera: Canon EOS 350D DIGITAL
Owner: unknown
ISO speed: 100
Shutter: 1/100.9 sec
Aperture: f/4.0
Focal length: 200.0 mm
Embedded ICC profile: no
Number of raw images: 1
Thumb size:  1536 x 1024
Full size:   3516 x 2328
Image size:  3474 x 2314
Output size: 3474 x 2314
Raw colors: 3
Filter pattern: RGGBRGGBRGGBRGGB
Daylight multipliers: 2.467797 0.917149 1.164814
Camera multipliers: 2178.000000 1019.000000 1397.000000 1019.000000

Por eso digo que nos falta saber dónde y cómo meter en el DNG de salida la información que necesitará el revelador usado para interpretar correctamente la colorimetría de los datos. Para saberlo sería bueno rastrear qué hace DCRAW cuando lo pones a revelar un DNG.

Te lo investigaré, yo sé que el DNG me pide el perfil de cámara (una matriz 3x3) y el "forward matrix" que es otra 3x3. Miraré a ver que ocurre con el ACR tocándole esas matrices... Creo que he tenido una idea

Pues como esas matrices no sean las mismas que usa el dcraw para procesar las imágenes, nos veo haciendo una base de datos con los parámetros a utilizar para cada cámara.

_GUI_, me he estado pegando con el tratamiento de color en el DNG y más o menos lo entiendo, pero es algo que se me escapa un poco. Supongo que tú que estás más acostumbrado a esos temas lo llevarás mejor. Bájate el SDK de DNG, y en la carpeta "documents" tienes "DNG_spec_1_2_0_0.pdf". Ahí, en la página 65, te explica cómo trata el color el DNG. Léete ese capítulo y comentamos, y así me guías con qué parámetros debo guardar dentro del DNG para el calibrado de cámara.

Un saludo!

He preguntado a Gabor de LL por el DNG con salida no lineal, fundamental para tener un rango dinámico de escándalo en la salida:

Hi Gabor, since you program DNG files maybe you have a good understanding on this: is it possible to enconde data in a DNG file in a non-linear way? e.g. on a gamma 2.2 curve.
I know that for instance the Leica M8 DNG files are 8-bit non-linearly encoded, but I wonder if this is set in some tag into DNG (gamma tag for instance), or Leica just encodes its data non-linearly, and knowing that the RAW developers perform the appropiate corrections to it.

We are mixing several RAW files into one output 16-bit DNG, and being able to encode data non-linearly would help to expand DR a lot.



Guillermo,

the lossily compressed raw data, like Leica M8, Sony and Nikon is regarded linear; before working with the data, a linearization step has to be carried out. There is a DNG specific tag for that, LinearisationTable. If you generate this table, you can convert "backwards" any previous non-linear conversion, as it is not a formula but a value array indexed with the pixel values stored in the file.

HOWEVER, the linearized data still has to be 16bit. I seriously doubt, that is insufficient for any non-scientific application.

Btw, neither the Leica, nor the Sony, nor the Nikon lossy encoding follows exactly an RGB mapping. Anyway, the mapping formulas are different for sRGB, aRGB, ProPhoto, etc.

Cheers
Gabor


Me comenta qeu se puede codificar no linealmente la info, pero que en el revelador se realizará una linearización en 16 bits antes del demosaicing, con lo que perderíamos todo lo ganado con la gamma 2,2.
Conclusión: a efectos de potencia tonal, Zero Noise con salida TIFF será siempre más potente que con salida DNG

PD: por qué este hilo es obsoleto che?

Iniciado por Guillermo Luijk

PD: por qué este hilo es obsoleto che?

Hombre, Guillermo, me imagino que Manuel creyó (en su afán de limpiar un poco el foro) que, dada su antiguedad, y que lo de escribir DNG "ya parecía estar superado", el hilo debía de cerrarse.

Como veo que no es así, lo he vuelto a abrir y a mover al foro principal para que no pase desapercibido (Guillermo, tú también lo puedes hacer, que eres moderador , o al menos eso creo recordar )

Interesante lo que apuntas sobre los DNG y su codificación no lineal.
Es una verdadera pena que los programas que manejan RAW no están preparados para trabajar con imágenes no lineales y que sea necesaria su linearización previa con datos de salida de 16 bits.

Como bien dices eso hace que la salida TIFF no lineal sea superior a la de DNG lineal, pues podrá cubrir un mayor rango dinámico tal y como expones en el magnífico artículo de tu web.
Me ha parecido muy interesante y es una pena que no podamos hacer lo mismo con un archivo DNG, lo que impondrá una limitación "seria" a Zero noise y nos exigirá decidir si preferimos salvar en DNG teniendo un menor rango dinámico para luego poder procesar la imagen con perfectRaw o nuestro revelador favorito, o bien como TIFF, con lo que no tendremos la ventaja de los superiores algoritmos de interpolación de nuestro revelador y habrá que conformarse con lo que haga ZeroNoise, pero tendremos una imagen con mayor número de niveles en las sombras.

Quizás esto sea un motivo para replantearse Zero noise e integrarlo en un futuro en PerfectRaw ¿no crees?
Aunque no estoy seguro de que eso sea una ventaja, pues PerfectRaw asume que los Raws son lineales y que las imágenes están codificadas en 16 bits, por lo que (de no cambiar cosas en PerfectRaw) no habría ventajas a la hora de integrar Zero noise.

¿Cómo verías de complicado el que PerfectRaw pudiera manejar imágenes raw con una gamma no lineal?

Iniciado por Guillermo Luijk

He preguntado a Gabor de LL por el DNG con salida no lineal, fundamental para tener un rango dinámico de escándalo en la salida:

Gabor es el autor de RawTherapee .

Iniciado por Guillermo Luijk

Me comenta qeu se puede codificar no linealmente la info, pero que en el revelador se realizará una linearización en 16 bits antes del demosaicing, con lo que perderíamos todo lo ganado con la gamma 2,2. Conclusión: a efectos de potencia tonal, Zero Noise con salida TIFF será siempre más potente que con salida DNG

No entiendo el problema, Guillermo. Tú puedes meter los datos de 16 bits con o sin la gamma aplicada, ¿no? El DNG no sabe cómo son los datos. Las matrices de color son lineales, como la gamma, no debería haber problema, ¿no? Más complejo es el tema del punto negro. Al fin y al cabo un DNG no es más que un TIFF sin interpolar.

Iniciado por Guillermo Luijk

PD: por qué este hilo es obsoleto che?

Este no debía serlo, se me fue la pinza .