OJODIGITAL

Abro este Hilo a petición de Manuel Llorens para continuar con el tema iniciado en el hilo Recuperación altas luces distintos reveladores RAW
En él se había iniciado una serie de mensajes que no tenían mucho que ver con el post original en la dirección de desarrollar un nuevo GUI para DCRaw en C# que integrara DCRaw como una librería.
A continuación copiaré los mensajes del post original relacionados con este tema.
_________________________________
Por ariznaf en el hilo original:
Pues la verdad es que hay una diferencia notable. Es impresionante que un revelador gratuito y sin ningún apoyo de las marcas pueda conseguir esos resultados.

¡¡Cuánto me gustaría que DCRAW tuviera una interface mucho más amigable e integrada en Lightroom o Photoshop al estilo del ACR!!

Con una interface así le haría el revelador ideal para todas las fotos. Con la interface actual (aún con las interfaces visuales), la verdad es que al flujo de trabajo se me hace mucho más complejo y sólo lo utilizo de manera muy puntual (por tus recomendaciones).

Pero eso no creo que llegue, porque por lo que he leido sobre Coffin es un purista y seguro que usa la interface de Linux de linea de comandos

Por cierto, la imagen de DCRAW -h 9 ¿la has corregido en rojos o es un resultado de la recuperación de altas luces? Veo los ojos un poco más rojizos que en la otra y también en los brillos de la frente parece tener un ligerísimo tono rojizo, aunque los resultados son muy buenos.
_________________________________
Por _GUI_ en el post original:

Cita:
Empezado por ariznaf
Pues la verdad es que hay una diferencia notable. Es impresionante que un revelador gratuito y sin ningún apoyo de las marcas pueda conseguir esos resultados.

¡¡Cuánto me gustaría que DCRAW tuviera una interface mucho más amigable e integrada en Lightroom o Photoshop al estilo del ACR!!


Coffin no tiene ninguna intención de generalizar DCRAW como revelador. De hecho, usarlo en modo línea de comandos es un mal uso del mismo. Lo verdaderametne valioso de DCRAW y de lo que se benefician un montón de programas (algunos se están haciendo muy populares pese a no ser comerciales como UFRAW y RAW Therapee) es su código fuente, y en particular la parte de decodificación de formatos RAW.

Cuando miras el código de DCRAW te das cuenta de lo sumamente puñeteros que son los fabricantes de cámaras, con formatos RAW totalmente distintos unos de otros, llenos de "trampas", de modo que prácticamente hay que tratar la decodificación de cada modelo, o como poco de cada marca, de manera individualizada. DCRAW es la única manera que tienen muchos otros de hacer aplicaciones capaces de leer RAWs de cualquier cámara, sin él, esto estaría vetado a los programas comerciales y los no comerciales leerían 2 o 3 formatos populares y el DNG a lo sumo.

Lo que pasa es que además DCRAW cuenta con alguna lindeza peculiar que en determinados casos funciona bien, como lo de la recuperación de altas luces. Pero en otros no, dando resultados horribles (sin ir más lejos en el ejemplo de arriba, las zonas quemadas de la camisa se ven invadidas de tonos procedentes de la piel), y esto es algo que no puede permitirse un revelador comercial el cual debe dar un resultado correcto con solo pulsar un botón o de lo contrario el usuario medio directamente diría que funciona mal.

Por eso creo que aquí DCRAW juega con ventaja ya que puede permitirse el lujo de hacer cosas ("experimentos") que en ocasiones funcionan, y en otras no; pero es que el usuario de DCRAW ya está acostumbrado y sabe que tiene que aportar más que el usuario de ACR, a cambio en ocasiones de un beneficio extra que ACR no te puede dar. Si la imagen del chico anterior la revelamos 2 veces: una como he mostrado para salvar los brillos de la piel, y otra en tonos neutros para la camisa, el resultado simplemente no se puede mejorar con ningún revelador comercial actual. Pero claro, tienes que saberlo manejar, y conocer sus limitaciones y cómo trampearlas.
_________________________________
Por ManuelLlorens en el post original:
_GUI_ el resultado es increíble, algún fanático de ACR podría pensar que lo has retocado a mano . Creo que DCRAW tiene otra ventaja clara, además de las ya comentadas, y es que nos sirve de plataforma para experimentar con él. Podemos modificar el código fuente y adaptarlo a nuestras necesidades.

Como dice _GUI_, Adobe no va a realizar añadir una función que no siempre funcione bien, pero tampoco va a añadir una funcionalidad que solo demanden unos pocos usuarios.

Además, crear un interfaz gráfico en condiciones es mucho más fácil que hacer un revelador. La mayoría de funciones que añaden los reveladores no se usan casi nunca o pueden hacerse con más calidad en PS. No hace falta que sea tan completo como alguno de los que ya hay, basta con que tenga las opciones básicas que más se utilizan. Al final, si vas a acabar retoncando en PS, puedes dejar que dcraw haga el revelado y poco más y para eso no hace falta un interfaz gráfico complejo.

Yo lo que veo primordial, es que DCRAW haga todo aquello que de hacerse a posteriori haga perder calidad a la imagen, aunque sea muy poca. Esa es la filosofía que entiendo que trata de extender _GUI_ y yo me he suscrito a ella.

La lista de funciones que yo necesitaría en un interfez gráfico es corta. Yo usaría ACDSee Pro o Adobe Bridge como catalogador/navegador. Con una orden se manda el archivo al GUI de DCRAW. Previsualización, poder marcar la zona de medición para el balance de blancos. Ajustar exposición y previsualizar con un histograma. Ver detalles ampliados de una zona para ver la recuperación de luces, el ruido, el enfoque y la corrección de aberraciones cromáticas y grabar. También es fácil crear un archivo con los parámetros de revelado para procesar un lote de fotos. Yo diría que si fusionamos el DCRAW modificado por nosotros (y las modificaciones que quedan por hacerle), el MEGUI, el Histogrammar y cuatro cosas más tenemos todo lo que necesitamos o mejor.

El resultado final estoy seguro que se convertiría en mi revelador principal.

Un saludo:
_________________________________
Por ariznaf en el post original:
@Manuel:
sí, estoy bastante de acuerdo con lo que dices de que no necesitamos en el GUI del revelador demasiadas cosas.

A tu lista yo añadiría almacenar los parámetros utilizados de revelado en el archivo xmp (o dentro del DNG en el caso de los DNG) asociado, para poder repetir el revelado.
Con ello, no necesitaríamos conservar los TIFF generados por el revelador, pues siempre podríamos repetir el proceso (a mi me gusta conservar los RAW intactos y no los TIFF porque ocupan mucho menos y son "el original").
Otra cosa que le pediría para poder sustituir a reveladores como el ACR es una cierta integración con Lightroom, o PS. No hace falta que vaya muy allá, únicamente que se pueda lanzar el revelador del DCRaw desde los programas de catalogación pasándoles la lista de las imágenes actualmente seleccionadas para trabajar sobre ellas (al estilo del ACR con Bridge).
Una última cosa que sería muy deseable es que el revelador actualizara las imágenes de previsualización de los RAW, para que los catalogadores mostraran los resultados de los ajustes realizados y no se quedaran con sus propios parámetros de revelado únicamente.
Sé que esto puede ser algo más difícil, pues habría que actualizar esos valores en los RAW. En los DNG se podría utilizar el API de Adobe, pero en los otros no tengo ni idea.

Muchos usamos un catalogador para manejar las imágenes, y para poder integrar el revelador en el flujo de trabajo (y que DCRAW sustituya a ACR por ejemplo), resulta imprescindible poder lanzar el revelador desde el programa de catalogación y ver los resultados en las previsualizaciones.

Si os decidís a lanzaros con eso, yo podría colaborar algo en la interface del programa´. Hace tiempo que no programo, pero tengo experiencia en C# (y también en C++, aunque para la interface creo que sería preferible C#).
También podría intentar pelearme con el API de Adobe para escribir los xmp, si os parece de interés.
Eso sí me tendríais que indicar cuál sería el compilador a utilizar (y por favor que no sea de linea de comandos exclusivamente muchos hace tiempo que manejamos entornos de programación tipo a Visual Studio).
Un entorno de este tipo sería SharpDevelop (la desventaja es que sólo admite C#) que utilizando Mono y .NET podría generar ejecutables para Linus. Otra alternativa Eclipse (con C# y C++ pero un entorno mucho más complejo) o Mono Develop. ¿Tíenes experiencia con ellos?
No dispongo de un tiempo grande o que pueda dedicar todos los días, por lo que creo que podría ayudar mejor en tareas que fueran muy concretas e independientes del resto (por ejemplo lo de los xmp).
_________________________________
Por ManuelLlorens en el post original:
Cita:
Empezado por ariznaf
A tu lista yo añadiría almacenar los parámetros utilizados de revelado en el archivo xmp (o dentro del DNG en el caso de los DNG) asociado, para poder repetir el revelado.

Sí a algo así me refería en mi lista. Es un "por supuesto" clarísimo.

Cita:
Empezado por ariznaf
Con ello, no necesitaríamos conservar los TIFF generados por el revelador, pues siempre podríamos repetir el proceso (a mi me gusta conservar los RAW intactos y no los TIFF porque ocupan mucho menos y son "el original").

Yo actualmente solo relevo las que voy a procesar después en PS, con lo que solo guardo esos TIFFs, el resto se quedan en RAW o en DNG (esa es otra discusión sobra la que aún no tengo formada un opinión definitiva).

Cita:
Empezado por ariznaf
una cierta integración con Lightroom, o PS. No hace falta que vaya muy allá, únicamente que se pueda lanzar el revelador del DCRaw desde los programas de catalogación pasándoles la lista de las imágenes actualmente seleccionadas para trabajar sobre ellas (al estilo del ACR con Bridge).

Yo uso ACDSee Pro 2 y sí se puede hacer eso. A mí me parece más cómodo que Bridge o Lightroom. Bueno que Lightroom seguro porque para mí es bastante incómodo.

Cita:
Empezado por ariznaf
Una última cosa que sería muy deseable es que el revelador actualizara las imágenes de previsualización de los RAW, para que los catalogadores mostraran los resultados de los ajustes realizados y no se quedaran con sus propios parámetros de revelado únicamente.

Totalmente de acuerdo. En eso habría que hacer ingeniería inversa de DCRAW que extrae esos thumbnails y hacer "lo contrario".

Cita:
Empezado por ariznaf
Si os decidís a lanzaros con eso, yo podría colaborar algo en la interface del programa´. Hace tiempo que no programo, pero tengo experiencia en C# (y también en C++, aunque para la interface creo que sería preferible C#).

Yo ya me había decantado por C#, en el que tengo experiencia. Lo malo es que _muy_ lento trabajando con TIFF, incluso con secciones unsafe. Estaba empezando un GUI con C# y direct-x, pero me echa para atrás que al usar direct-x me quedo sin poder portar a Linux. Así que la alternativa es usar una librería de código abierto para TIFF en C/C++ e integrarla en C#. Lo tengo en la lista de cosas a mirar.

Cita:
Empezado por ariznaf
También podría intentar pelearme con el API de Adobe para escribir los xmp, si os parece de interés.

Buff. Yo he estado mirando y es tremendamente compleja, al menos para mi oxidado C++. La verdad es que el C++ y yo nunca nos hemos gustado, a mí él me cae mal, y yo a él le caigo peor. En serio, me parece super improductivo trabajar en C++. Yo en los tiempos pre .NET trabajaba mucho en VB6/ASP los GUIs y tiraba de COM/ATLs en C++. Sin duda alguna el GUI en C#.

Cita:
Empezado por ariznaf
Un entorno de este tipo sería SharpDevelop (la desventaja es que sólo admite C#) que utilizando Mono y .NET podría generar ejecutables para Linus. Otra alternativa Eclipse (con C# y C++ pero un entorno mucho más complejo) o Mono Develop. ¿Tíenes experiencia con ellos?

Para C# sólo con VS, pero echo un vistazo ahora.

Cita:
Empezado por ariznaf
No dispongo de un tiempo grande o que pueda dedicar todos los días, por lo que creo que podría ayudar mejor en tareas que fueran muy concretas e independientes del resto (por ejemplo lo de los xmp).

Me parece perfecto. Cuando tenga un rato voy a diseñar una maqueta del GUI en PS y un mínimo análisis funcional. En paralelo haré un primer intento.

En cualquier caso creo que lo ideal es tener algo funcionando en un plazo mínimo y luego ir añadiendo cosas. Si nos embarcamos en algo muy ambicioso nos hundimos antes de acabar.

Lo que no tengo claro y me anda dando vueltas en la cabeza es si integrar DCRAW en una DLL (o utilizar alguna que ya hay) o dejarlo en un EXE. Lo malo de lo primero es que habría que estar programando cada vez que Coffin actualice (aunque ya habrá que actualizar la versión que hemos modificado de DCRAW, pero los cambios son mucho menores) y eso puede matar el proyecto. La segunda opción nos da un resultado más lento, pero más versátil. Para ello voy a añadir a DCRAW la opción de revelar solo un trozo de la imagen. Aún así también quiero mirar si puedo crear una cutre librería (aunque sea estática) con DCRAW sin tocar el código de Coffin, solo añadiendo algunas funciones.

Un saludo:
_________________________________
Por ariznaf en el post original:
Cita:
Buff. Yo he estado mirando y es tremendamente compleja, al menos para mi oxidado C++. La verdad es que el C++ y yo nunca nos hemos gustado, a mí él me cae mal, y yo a él le caigo peor. En serio, me parece super improductivo trabajar en C++. Yo en los tiempos pre .NET trabajaba mucho en VB6/ASP los GUIs y tiraba de COM/ATLs en C++. Sin duda alguna el GUI en C#.
Sí, la verdad es que C++ es muy tiquismiquis con el acceso a la memoria y la liberación de memoria. Pero si queremos reaprovechar librerías (como la de Adobe) no quedara más remedio que hacer un "stub" en C++ y que presente una interface C# para hacer justo lo que se necesite (como pasarle al "stub" los parámetros de revelado y que éste los guarde en los metadatos xmp).
Yo también creo que es mejor huir lo más posible de C++.

Cita:
Yo ya me había decantado por C#, en el que tengo experiencia. Lo malo es que _muy_ lento trabajando con TIFF, incluso con secciones unsafe. Estaba empezando un GUI con C# y direct-x, pero me echa para atrás que al usar direct-x me quedo sin poder portar a Linux. Así que la alternativa es usar una librería de código abierto para TIFF en C/C++ e integrarla en C#. Lo tengo en la lista de cosas a mirar.
Sí, si queremos que pite en Linux (y creo que se le debe a Coffin y la comunidad Linux, aunque yo no lo uso) no se podrá usar direct-x.
¿Qué ótras alternativas hay como librería para manejo de bitmaps? ¿OpenGL podría servir? Está más orientada a representación 3D, pero maneja texturas y por tanto bitmaps. No sé si la funcionalidad de Open GL puede ser suficiente.
Cita:
Para C# sólo con VS, pero echo un vistazo ahora.
Yo también utilizé sólo VS. Pero buscando alternativas gratuitas encontré lo de #Develop. El problema está en que sólo compila C# y por tanto no se podría utilizar para compilar el código C++ ni C.
Sé de otras alternativas como MonoDevelop y Eclipse con un plugin para C# y Mono, pero no los he utilizado.
Cita:
Lo que no tengo claro y me anda dando vueltas en la cabeza es si integrar DCRAW en una DLL (o utilizar alguna que ya hay) o dejarlo en un EXE. Lo malo de lo primero es que habría que estar programando cada vez que Coffin actualice (aunque ya habrá que actualizar la versión que hemos modificado de DCRAW, pero los cambios son mucho menores) y eso puede matar el proyecto. La segunda opción nos da un resultado más lento, pero más versátil. Para ello voy a añadir a DCRAW la opción de revelar solo un trozo de la imagen. Aún así también quiero mirar si puedo crear una cutre librería (aunque sea estática) con DCRAW sin tocar el código de Coffin, solo añadiendo algunas funciones.
Eso habrá que analizarlo con detenimiento, pues creo que será crucial para el éxito del proyecto y también lo puede complicar bastante (por el tema de mantenimiento del código que mencionas).

• Opción DLL: más que una DLL creo que lo suyo sería crear un componente .NET en C++ que exponga los métodos de acceso a los parámetros de revelado y los métodos para revelar el fichero y devolver un bitmap con la imagen revelada. Primero se llama a las funciones para establecer los parámetros de revelado y el fichero RAW a procesar y luego se llama al método revelar que devolvería el bitmap.

De esta forma el código se aislaría lo más posible en ese componente que sería lo único a tocar (o casi) de cara a desarrollos futuros de DCRAW.

• Inconvenientes: está claro, hay que retocar algo cada vez que aparezca una versión de DCRaw (aunque esto ya sucede ahora con las modificaciones hechas a DCRaw).
• Ventajas: integración en el código del programa. Además no sería necesario crear ficheros TIFF externos y los resultados de tocar un valor del revelador se podrían ver de forma inmediata, y no habría que esperar a que el usuario le de al botón revelar para generar el TIFF, leerlo y presentarlo en pantalla.

• Opción Ejecutble externo: eso sería como está ahora.
  • Inconvenientes: hay que lanzar un ejecutable externo, pasarle los parámetros (con la limitación de caracteres de la linea de comandos) esperar a que genere el TIFF y volver a cargarlo. Mayor gasto de memoria y recursos y mucho más lento (no se podrían apreciar los efectos de los parámetros de revelado en tiempo real).
  • Ventajas: más fácil de mantener el código, al no tener que retocar nada cada vez que aparezca una versión nueva (bueno, algo sí para incorporar los cambios que hicistéis).

Para no tener que generar un fichero TIFF en el disco y volver a leerlo, se pueden crear pipes para leer la salida estándar del programa (que tiene una opción para escribir en stdout) o bien utilizar pipes con nombre.

Bueno ya nos dirás a qué conclusiones llegas...
Saludos
_________________________________
Por ManuelLlorens en el post original:
Cita:
Empezado por ariznaf
Pero si queremos reaprovechar librerías (como la de Adobe) no quedara más remedio que hacer un "stub" en C++ y que presente una interface C# para hacer justo lo que se necesite

Exactamente, justo y solo lo que se necesita en C++, por ejemplo la parte del SDK de DNG que se limitaría a insertar en el DNG los parámetros de revelado y actualizar sus thumbnails, ¿no? Eso te lo dejamos a ti, que te veo muy animado. Yo empecé a mirar el código de Adobe y me quedé dormido . En serio, ¿no te parece super engorrosa?



Sin embargo, DCRAW está en C, no vamos a portarlo a C++. Basta con compilarlo como un DLL y añadirle unas pocas funciones con la funcionalidad que necesitamos para comunicarnos con él (te la detallo más abajo). Tengo un ejemplo funcionando en el que no toco nada de DCRAW, solo le añado al final del archivo las funciones que necesito. En realidad lo que hacemos es descomponer su main() en varias funciones a nuestra conveniencia (En eso es una ventaja el código lineal de Coffin). Luego podemos tirar de esa DLL en el lenguaje que queramos, por ejemplo en C# con solo hacer:

[DllImport("DCRAW_DLL.dll")]

static extern void DCRAW_End();

[DllImport("DCRAW_DLL.dll")]

static extern int DCRAW_Init(String rawfile);

[DllImport("DCRAW_DLL.dll")]

static extern String DCRAW_GetCamera();

(Esto de arriba es código que ya tengo funcionando, con dcraw compilado con MinGW y C# con VS2003. Con esto tan simple perdemos la opción de ejecutar dcraw en multitarea, pero es que si no sí que hay que modificar mucho código de Coffin).

Cita:
Empezado por ariznaf
Sí, si queremos que pite en Linux (y creo que se le debe a Coffin y la comunidad Linux, aunque yo no lo uso) no se podrá usar direct-x. ¿Qué ótras alternativas hay como librería para manejo de bitmaps? ¿OpenGL podría servir? Está más orientada a representación 3D, pero maneja texturas y por tanto bitmaps. No sé si la funcionalidad de Open GL puede ser suficiente.

Nunca he hecho nada en OpenGL pero desde luego sí sería portable. En realidad el único problema que tenemos con GDI+ es que el volcado a pantalla de los TIFFs es lento. Solo necesitamos arreglar eso, porque lo demás lo va a hacer DCRAW. No pretendemos procesar en C# nada más, y si queremos lo añadiremos a nuestra versión de DCRAW, en C y a toda
pastilla.

Cita:
Empezado por ariznaf
Opción DLL: más que una DLL creo que lo suyo sería crear un componente .NET en C++ que exponga los métodos de acceso a los parámetros de revelado y los métodos para revelar el fichero yBueno ya nos dirás a qué conclusiones llegas...
Saludos

Ya me he decidido por esta opción, pero sin C++ para dcraw. Creo que lo ideal es lo siguiente:

• Con unas pocas líneas de código añadidas a nuestro dcraw.c podemos compilarlo como .exe o .dll. De hecho cada cambio lo recompilaremos en ambas versiones. Evidentemente, también hay un archivo de cabecera con las funciones que exporta la dll, pero eso es lo de menos porque no toca código de Coffin. Además, hay que posibilitar al máximo que esa DLL se pueda llamar también desde VB, porque meiker 10 y _GUI_ trabajan en VB y puede que estén interesados en tirar de la DLL en lugar del ejecutable para sus MeGUI y ZeroNoise respectivos .
• Las funciones añadidas son:
  • DCRAW_Init(fichero_a_revelar); // Hecho
  • DCRAW_End(); // Hecho
  • DCRAW_GetInfo(); // Falta definir el struct
  • DCRAW_Process(parámetros_de_procesado); // Falta pasar los parámetros
  • DCRAW_Save(fichero_a_guardar,formato); // Sin hacer
• Luego importamos esa DLL en C# como te he puesto arriba y listo. La función DCRAW_Process devuelve un puntero a la imagen revelada en formato RGB, hay que convertirla a formato GDI+ y cargarla en un bitmap, ahí es donde está el cuello de botella que te comentaba. Podemos convetirlo dentro del DCRAW_Process, no tengo claro ahora mismo el formato de Bitmap que usa GDI+ y si podremos generalo fuera; lo que no quiero es trabajar pixel a pixel en C# para no perder velocidad.
• El resto de módulos, como el que graba DNG, sí los hacemos como tú dices, en C++ y stub para C#.

¿Qué te parece? Insisto en que tengo ya un ejemplo en C# que tira de DCRAW modificado de este modo y que no he tocado un sola línea de Coffin, que es lo fundamental tal y como yo lo veo. La idea es que se trate de un GUI minimalista al máximo:

• En cuanto al código que haya que escribir.
• En cuanto a las modificaciones que haya que hace a dcraw.c para actualizar sus cambios.
• En cuanto al diseño del interfaz, esto me parece muy importante. Yo me aburro de lo lentos que van algunos y de lo absurdo que son algunas cosas en otros (RAWTherapee y Lightroom tienen interfaces lentos para mi gusto). Cuando ponga la maqueta espero que los contertulios aporten sus sugerencias para hacerlo al gusto de todos.
• En cuanto a no pretender ir añadiendo más y más funciones.
• En cuanto al tiempo que nos exija dedicarle.
• En cuanto a lo que vamos a ganar con ello, ¡minimalista del todo!

Por cierto, de verdad que no es por escurrir el bulto, pero estoy muy pez aún en los foros. Creo que deberíamos sacar esta conversación a otro nuevo, ¿verdad? ¿Cómo se hace? Quiero decir sin perder estos primeros mensajes, claro. A lo mejor _GUI_, que seguro que está interesado en el tema, o tú Ariznaz, podéis hacerlo y explicarme como se hace para la siguiente ocasión.

Otra cosa, hay que buscarle un nombre.

Un saludo:
_________________________________
Por _GUI_ en el post original:
Por pedir que no quede:

• Yo echo en falta poder obtener los multiplicadores del balance de blancos de la cámara de alguna manera (lo que se aplica al usar -w vamos)
• Y la opción que hablabas de revelar solo una porción {x y w h} del RAW
• Por lo demás con eso y la conversión de multiplicadores a Temperatura/matiz (no es tan complejo, ya he llegado a la curva de Planck y no debe ser muy difícil obtener una curva que modele la conversión, creo que lo tendré en breve) estoy totalmente servido. Cualquier interacción con otros reveladores o facilidades de clasificación o visualización rápida de RAWs creo que sería un poco reinventar la rueda.

_________________________________
Por ManuelLlorens en el mensaje original:
Maqueta del GUI de DCRAW - Hoy, 14:47




Bueno, pues aquí va la maqueta para que opinéis y la afinemos. En vez de ordenar los parámetros como suelen hacer los reveladores, he partido de la idea (que me parece bueno mantener) de separar el proceso en los siguientes pasos:

1. INPUT
2. PRE DEMOSAICING:
   1. Black Point
   2. White Balance
   3. ...
3. DEMOSAICING
4. POST DEMOSAICING
   1. Highlight Recovery
   2. Median Filter
   3. ...
5. OUTPUT
   1. Colorspace
   2. Gamma
   3. Bps
   4. ...
   5. Abrir en PS

De esta manera, uno sabe en todo momento si el parámetro que está tocando afecta a antes o a después de la interpolación, así es más técnico el revelado. A todos los parámetros se accede desde una única pantalla, sin pestañas ni barras que suben y bajan. Es la misma filosofía que MeGUI, pero con el estilo de un revelador. Si luego algún diseñador gráfico (seguro que hay alguno por aquí) le mete un poco de estilo, pues puede quedar bastante funcional y a la vez vistoso. Algunos parámetros actualizarían la previsualización de las dos ventanas (por ejemplo, balance de blancos) y otros solo la de detalle (ruido, aberraciones, etc), de ese modo iría más rápido.

En IMAGE INFO ponemos los multiplicadores de la cámara y todo lo que nos guste. La imagen principal NO se puede ver a distintos tamaños, ni redimiensionar, girar, cortar, etc... solo se puede ver ampliada en la ventana de detalle de la derecha.

De definir la funcionalidad del histograma se encargaría evidentemente _GUI_, que es el experto.



Un saludo:
_________________________________
Bueno y esos son todos los mensajes del post original.
A partir de ahora seguiremos aquí.
_________________________________
A ver Manuel, te intentaré contestar a todo lo que comentas. Es un post muy denso y no sé si te seguí bien.

Sí ese es un apartado claro en el que se necesita recompilar el SDK de Adobe en C++. Efectivamente parece una tarea bastante engorrosa. No sé si yo podré llevarla a cabo, pero por suerte no es lo más necesario en un primer momento, por lo que tendré tiempo para ir avanzando en esa dirección.
La actualización de las previsualizaciones incrustadas y lo de los datos guardar los datos de revelado en xmp son dos tareas separadas y en el SDK traen dos ejemplos distintos: uno para leer los parámetros xmp (que pueden estar en un DNG o en un archivo xmp separado) y otro para acceder a los ficheros DNG y leer datos EXIF y acceder a la imagen.
La parte de leer los DNG no la necesitamos porque eso ya lo hace DCRAW en el revelado (tanto para los DNG como para los demás ficheros RAW).
En cuanto a lo de escribir la imagen de previsualización en el archivo una vez revelada (para que los catalogadores puedan actualizar su propia imagen), aquí el SDK de Adobe no ayudará mucho, pues efectivamente es posible que se pueda hacer analizando el código del SDK, pero no sería de mucha ayuda, pues el SDK sólo maneja archivos DNG y no archivos en otros formatos RAW. Creo que el tema no es tan sencillo si queremos actualizar dichas imágenes en cualquier formato de fichero y no sé si el análisis del código de DCRaw ayudaría.
Bueno, esté en C o en C++ tendremos que utilizar el compilador de C++ seleccionado para generar la DLL (efectivamente no hace falta portarlo a C++ en el sentido de crear una clase para hacer de wrapper de DCRaw). Al estar en C puede ser algo más fácil y como dices, se puede generar simplemente una DLL e importar las funciones necesarias desde C#.
Esto evita al máximo el tocar el código de DCRaw, haciendo las menos modificiaciones posibles. Además posibilita acceder a las funciones desde otros lenguajes que no sean .NET (tal y como comentas, desde VB 6 por ejemplo).

Aun así yo haría una clase de C# que se encargara de gestionar los parámetros de revelado seleccionados por el usuario, almacenándolos internamente. Esta clase debería presentar métodos para proceder al revelado (utilizando la DLL que accede a DCRaw) y devolver el bitmap generado por DCRaw para poder mostrarlo en la pantalla. Luego sería también la encargada de llamar a las funciones de escribir dichos parámetros en los datos xmp de la imagen generada (utilizando el SDK de Adobe).
La interface gráfica simplemente tendría que almacenar los cambios en los parámetros de revelado utilizando los métodos expuestos por dicha clase y luego llamar al método de revelado para obtener el bitmap.

Esto aisla al máximo posible el acceso a la librería de DCRaw dentro de esta clase y facilita las modificaciones futuras y el añadir nuevas funcionalidades (o la conversión entre formatos de bitmaps, etc).
De acuerdo.
Hay un problema y es que el acceso directo a memoria desde C# utilizando punteros no es posible (bueno quizas con el unsafe y haciendo filigranas sí, no recuerdo muy bien).
Por ello creo que para manejar el puntero devuelto habría que utilizar un componente de .NET programado en C++ que aislara esa parte y expusiera los métodos necesarios para manipular dicho bitmap en RGB, convertirlo a GDI+, etc.

Quizás el crear un componente en C++ (que haga la traslación entre código no manejado utilizado internamente y código manejado de cara al exterior) pueda resultar complicado (creo recordar que la mezcla de código manejado y no manejado en C++ no era una tarea evidente).
En ese caso una alternativa es crear una DLL con funciones públicas en C++ que reciban el puntero devuelto por DCRaw y se encargen de todas las manipulaciones de imagen.
Después se importarían dichas funciones desde C# (al estilo de la DLL de DCRaw) y crearíamos una clase (que almacenaría el puntero como una variable privada) para exponer los métodos necesarios para la gestión de la imagen y que se encargaría de llamar a las funciones de la DLL necesarias.
¿Grabar DNG? No veo la necesidad de ello, si es un revelador y no un conversor no necesitaría convertir el formato original de fichero. Los ficheros Raw los lee DCRaw. La conversión a DNG ya la hace la herramienta de Adobe. No veo la necesidad de otro conversor ¿no te parece?
Lo que sí quedaría pendiente es el tema de la actualización de las imágenes de previsualización (que si es un DNG se podría hacer en teoría con el SDK de Adobe pero si es otro formato, no lo tengo tan claro).

A ver, voy a ser un poco más radical. Pero primero daré mis razones: lo que se pretende es hacer un revelador RAW milimétrico, que nos permita a nivel de píxel obtener el mejor resultado posible. En esa tesitura mostrar una imagen completa ocupando la mayor parte del interface, tiene un precio muy alto (en cuanto a espacio ocupado) y no demasiada utilidad. No vamos a aplicar curvas, ni cambios de saturación, ni nada que tenga un efecto global en la imagen que valga la pena observar en conjunto.

Por eso propongo hacer lo que hace Gabor en su RAWnalyze:

- Único display de imagen, y SIEMPRE en relaciones de zoom enteras: 1:1, 1:2, 1:3, 1:4. Tamaño estático (1024 píxels de ancho me parecería una buena opción).
- Si se quiere observar la imagen en conjunto también se puede hacer zoom out con diezmado entero de píxels: 2:1, 3:1,...
- El modo por defecto sería zoom 1:1, o sea recorte al 100%. Para movernos sobre la imagen bastaría pinchar en ella y desplazar. El zoom con la rueda de desplazamiento sería la bomba de cómodo (yo lo uso en PS).

Este display se concentra en ajustar los parámetros que se van a aplicar en DCRAW y que SÍ afectan a la imagen, y son mejor observados con este alto grado de detalle. Son:
- Algoritmo de demosaicing
- Balance de blancos
- Aberración cromática
- Reducción de ruido (wavelet, mediana)
- y chimpún, no hay más.

Veo mucho más útil la posibilidad de, en un momento dado, congelar la pantalla principal y que ésta se divida en mitad y mitad para comparar el antes/después de la aplicación de los parámetros.
Se guarda el antes en una imagen temporal (toda la imagen, para poder movernos a cualquier parte del "después"), y el después se va actualizando con los cambios que haga el usuario. Puede haber un modo que muestre la misma porción de ambas imágenes, o que muestre una imagen a tamaño normal solo que la mitad izquierda (o superior) pertenezca al antes y la derecha (o inferior) al después.
Muchas veces una imagen nos parece bien ajustada, y basta compararla con otra versión de sí misma para desecharla.

El histograma será útil visualizarlo (siempre en escala X de potencias de 2, y dando la posibilidad de logarítmico como Histogrammar), pero más útil aún es tener:
- Distintos modos de representar la imagen:
* Normal (demosaicing con todos los params. introducidos)
* Normal + superpuestas saturaciones parciales y zonas a negro del RAW (pueden parpadear)
* Solo saturaciones parciales (para detectarlas rápidamente y probar en ellas <> estrategias de recuperación). No sé como de complejo será hacer un revelado de solo una zona de la imagen cuando activamos -H 2-9, esto puede tener tela.
- Conteos absolutos y en % de píxels quemados en cada canal

Manuel, te invito a que juegues con algún RAW en RAWnalyze y veas la filosofía que propongo, y lo pronto que tomas conciencia de tener la certeza de estar controlando al máximo tu RAW. Es un concepto diferente al de los reveladores RAW al uso, pero es que no buscamos un revelador RAW al uso.

El ajuste de exposición, si se quiere hacer con preservación de altas luces y de tono, ha de ser posterior al demosaicing.

Sería una idea algo así:

_________________________________
Vale, para un solo RAW no, pero y si la salida en DNG de 16 bits proviene de la fusión de N RAWs de partida, pero eliminando el ruido y expandiendo el rango dinámico hasta la friolera de 16 diafragmas? (más de lo que nadie necesita). Así cada uno podría revelar ese DNG con su revelador preferido. Le comenté a Manuel la idea de hacer un Zero Noise con salida DNG sin revelar en lugar de TIFF revelado.

__________________

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í

Quien esté interesado en el ´codigo fuente de MEGUI 3.0 lo tiene completamente a su dispoción.
está escrito en Visual Basic, y yo tampoco soy programador por lo que tengo muchas lagunas, es una aficción que de vez encuando retomo.

lo dicho a vuestra dispocisión, sin ningún problema, por si os sirve de ayuda en algo.

salu2

__________________
Actual E-3 y SLHD-4, EX- E-300, E-330 y E-1 y E-510.
12-60SWD, 50-200SWD, 7-14mm FL-50R y SB28

Utilidad Mejorada MEGUI V3.1: G.U.I. para el revelador DCRAW:
http://es.geocities.com/meiker10/
Galerías: Galería Flickr

@_GUI_:
Absolutamente de acuerdo, para el revelador no le veo mucho sentido, pero para el Zero Noise, desde luego "sería una obligación"
Lo que pasa que lo de escribir DNG no parece demasiado sencillo. Además un DNG tiene sentido sobre todo para almacenar imágenes en mosaico (como los RAW) es decir, donde en cada pixel se guarda un sólo canal de información y los otros se derivan por interpolación. En este caso el RAW tiene grandes ventajas sobre el TIFF porque se reduce mucho el tamaño, pero ¿Zero Noise entregaría imágenes con el demosaicing hecho o son imágenes previas al democising?
En el último caso, si la fusión se hace con la imagen todavía en RAW, desde luego generar un DNG sería lo ideal. Zero Noise generaría el DNG y luego se revelaría con el que quisiéramos (ACR, el nuevo revelador de Manuel, u otro).

Creo que antes de pelearme con escribir DNG, tendría que controlar primero lo de los xmp (parece más fácil).
Otro problema está en que si hago cosas en C#, tú no lo podrías aprovechar en VB (a no ser que te cambiaras a VB .NET lo cuál sería ideal).

@ManuelLlorens:

Manuel, quedó algo por definir: el entorno de programación.
¿Estás decidido a hacerlo en VS? ¿Sería compatible en ese caso con Linux con sólo instalar Mono? ¿Tiene mono implementadas todas las funciones de GDI+?

Según he leido, Mono es compatible con .NET v1.2 y no con la 2.0. Habría que asegurarse en VS de no utilizar nada de la 2.0.

Como te comenté hay otras dos alternativas: #Develop y MonoDevelop.
El primero sólo puede compilar C# (en realidad usa un compilador de C# distribuido gratuitamente por MS). Por tanto creo que debemos de rechazarlo porque tendremos código C++ y C.

MonoDevelop me han comentado que tiene compilador C# y C++ por lo menos.
Conozco un compañero que lo utilizó y habla bien de él.
También me ha hablado de una librería de gráficos llamada QT.
Por lo que he visto es un sustituto de winforms y creo que también tiene manejo de bitmaps y es multiplataforma. Existe para Java y C++. Habría que ver si existe para C#. Tampoco tengo claro que sea gratuita.
Otra alternativa sería openGL (es lo más portable). Incluso hay frameworks tipo winforms sobre openGL (aunque si Mono funciona bien, yo soy partidario de winforms, por serme más conocido).
Hay además dos librerías de openGL para C#:

• CsGL
• SharpGP

La verdad es que a mi me da mucha pereza usar VS. Yo la última versión que usé creo que fue la 2003. El otro día vi el nuevo VS y era un mamotreto inmenso con infinidad de opciones de instalación y una interface llena de montones de cosas que seguro que no usaremos.
Mi portátil no creo ni que lo pueda mover con mínima soltura (el de casa sí).
Por ello preferiría un entorno más reducido, pero tú me dirás si te decides a VS creo que yo también tendría que usar VS (y misma versión) por no tener problemas de compatibilidad.

Cuando digo "Zero Noise", más que a ningún programa me refiero a la idea de ZN. Claro que la salida sería sin demosaicing, de hecho es más sencillo hacerlo así: sería mezclar 4 imágenes independientes, sin problemas de balances de blancos, propagación de ruido, saturaciones, algoritmos de interpolación ni espacios de color.
A mí dadme los nombres de las matrices que contienen los 4 canales RAW RGBG en float, que yo escribo en C el código para fusionarlas; con antighosting, fusión progresiva y ajuste de exposición inclusive. Con que luego sepáis embutir eso en un DNG de 16 bits, estaría hecho.

__________________

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í

De acuerdo GUI, pero vas demasiado deprisa para mí.

Yo todavía estoy aterrizando (como dije hace unos pocos años que no programo prácticamente, aunque antes programé bastante).

Empezaré por instalar el entorno de compilación y recompilar el SDK de Adobe a ver cómo va la cosa y si los programas de ejemplo funcionan.
Luego intentaré añadir datos xmp a una imagen y escribir una imagen inventada (una imagen gris plana por ejemplo) en un DNG.
A ver cómo va el tema.

Yo no he utilizado (en programación me refiero) imágenes RAW todavía.
Cuando dices que te den los nombres de las matrices RAW, no sé muy bien a qué te refieres.
La extracción de los datos RAW tendría que hacerse desde DCRaw, entiendo. Por lo que decía Manual, había una función que devolvía un puntero al bitmap pero era en RGB.
Habría que pedir a Manuel que hiciera otra función para que devuelva un puntero a la imagen en RAW (antes de cualquier operación o procesado sobre ella).
Por lo que dices, ¿se almacenan float en los RAW? yo creí que eran enteros de 16 bits, uno por cada pixel de la imagen, almacenados en forma de matriz (de filas) y haría falta la información de la máscara utilizada (qué pixel es R, G y B).
¿Es que hay una función de DCRaw que separe eso en cuatro matrices R,G,B,G con los valores convertidos a float de 32 bits?
Si es así, bastaría con pedirle a Manuel que exportara esa función en la librería DLL ¿no?
_________________________________
Ah por cierto sería estupendo convertir ZN en una librería e integrarlo de alguna manera en el revelador, de manera que hubiera una opción para fusionar imágenes.
_________________________________
@ManuelLlorens:

Manuel, he estado mirando MonoDevelop y tiene algunas limitaciones. Parece que funciona con Mono pero como framework de ventanas utiliza gTk# (versión C# de la librería Gtk de Linux). No parece que se pueda utilizar GDI+ ni WinForms (aunque no estoy seguro).
Además parece que hay alguna dificultad para que funcione en Windows, está más orientado a Linux. No hay un instalador para Windows (aunque sí hay instrucciones de cómo instalar MonoDevelop, Gtk# y Mono en windows para que funcione).
Ello me hace pensar que la plataforma windows está un poco dejada de lado en MonoDevelop y por tanto puede haber dificultades en el uso de ese entorno de programación en Windows.

Eso nos dejaría sólo con Eclipse (bastante complejo y también bastante mamotrético) o con Visual Studio.

Creo que no va a quedar más tu tía que usar VS.

No a ver, los RAW son enteros claro que sí, pero yo tengo que operar con ellos en float. Habría que reutilizar DCRAW para que solo hiciera estas dos cosas:
1. Coger los datos RAW y convertirlos a float.
2. Sustraer el punto negro, ajustar al punto de saturación y escalar al rango 0..65535 (pero en float)

Si no recuerdo mal la función scale_colors() hace esto y además el balance de blancos, eso habría que quitárselo.

Con los nombres de las matrices me refiero que me digáis como acceder a los datos RAW tras los procesos 1 y 2. Digo yo que serán matrices del tipo:
float nivel[i][x][y]
donde i es el canal: 0..3 y x,y las coordenadas.

Bueno o quizá se accedan como array lineal: nivel[i][x+y*width], pero eso es pura nomenclatura.

__________________

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í

Un hilo interesante que merece la pena leer con más detalle.
Aporto dos cositas que tal vez puedan ayudar un poco, ambos son programas que ya ofrecen un interfaz gráfico para dcraw aunque tal vez les falte algun detalle. Estan disponibles para gnu/linux con el código fuente disponible (supongo que c y c++) y desconozco si estan disponibles para otras plataformas.

ufraw. Muy completo, permite modificar muchos de los parámetros, aplicar curvas, perfiles de color, recortes, etc...
http://ufraw.sourceforge.net/

digikam. Es bastante más recargado que el anterior, es un sistema de gestión fotográfico que incluye una "mesa de luz" donde podemos trabajar con el fichero raw. Usa una versión de dcraw que ha sido portada a una librería.
http://www.digikam.org

Ninguno llega a un control absoluto pero pueden ser buenas aproximaciones

Me desconecto una tarde y casi no tengo tiempo de leer los posts. Esto se está animando muy rápido. Me encanta.

Vayamos por partes. Os doy mis opiniones, a ver si vamos definiendo algo definitivo.

Sobre el/los entornos de desarrollo y el código:

1. Yo, a menos que se incorpore alguien que controle bastante de programación sobre Linux, haría algo que pudiera ser portado a Linux más tarde, pero sin complicarme la vida. Todos los interesados, de momento, usamos Windows, para qué liarnos más. El mismo SDK de DNG no está compilado para Unix, solo par Windows y Mac. Ya habrá alguien capaz de portar GDI+ a GTK# si el resultado merece la pena, de hecho estoy casi seguro que las librerías de Mono ya lo hacen con cambiar dos cosas.
2. Como entornos de desarrollo propongo (que nadie se asuste) DEV C++ para la parte en C sobre MinGW, que funcionará en Windows y en Linux y es gratis. De ahí salen dos librerías dcraw.dll y znoise.dll. A esas librerías se accede desde código C# desarrollado sobre VS 2003. De momento los dos únicos que controlamos C# solo hemos desarrollado en VS, y el SDK de DNG, si llega el momento, no creo que se pueda compilar en otra cosa. Yo tengo instalado en casa VS 2005, pero me comprometo a no usar .NET 2.0. Una vez terminadas las DLLs podemos compilar con cygwin o con VC++, eso ya da igual.
3. El código nuevo de Zero Noise debe estar hecho en C, porque C# es lento trabajando a nivel de píxeles. Además así será portable. Por supuesto se comunicará con dcraw.dll sin problemas.
4. El SDK de DNG compila en mi máquina. No he tenido que modificar nada, pero sí instalar unas cuantas cosas que no vienen con el SDK. Las tengo empaquetaditas, así que se las mando por mail a ariznaf y eso que se ahorra. La idea, creo yo, sería mediante ingeniería inversa (a base de tracear código, no el exe, ya que tenemos la fuente) del SDK sacar lo mínimo para construir un DNG sin muchas virguerías. Si ese código puede compilar con MinGW (seguro que sí) pues para delante.
5. Salvando el DNG, que lo vamos a dejar para más adelante a ver si ariznaf va haciéndose con él (también te paso algún ejemplo rápido que he encontrado por ahí), no vamos a necesitar ni una línea de C++. Utilizando bloques unsafe (para los que no sepáis del tema, C# usa código interpretado/compilado al vuelo y un gestor de memoria tipo Java, no usa punteros. Unsafe le dice que vamos a hacer aquello que no querían que hiciéramos cuando se diseño, manejar punteros a memoria no gestionada, pero funciona) es perfectamente posible acceder a punteros de las DLLs desde C#, ya lo he probado. Espero subir en breve una maqueta funcional con un ejecutable en C# que revela con dcraw.dll y muestra en pantalla el resultado.
6. A ver qué os parece este reparto de tareas: gracias a lo que he aprendido trabajando estos días con _GUI_ creo que tengo dominado el tema de dcraw, por tanto de las DLLs en C me encargo yo, salvo rellenar las funciones de znoise.dll, que dejaré a _GUI_, dándole el esqueleto y un ejemplo de búcle. ariznaf se encarga de DNG (que no será tan chungo, tranquilo) y a medias conmigo del GUI. meiker podría adaptar su MeGUI para tirar de dcraw.dll. Ya pondré ejemplos de cómo llamar desde VB a las DLLs.

Sobre el GUI en sí mismo:

1. Entiendo la utilidad de un revelador como el propone _GUI_, más que nada porque de los otros ya hay en el mercado. Creo que no costaría mucho meter la opción de que el programa reconfigure la ventana y las opciones que muestra en tres modos (y ni uno más ): modo revelado, modo Zero Noise y modo análisis o algo así. Es decir, tener las tres opciones en un solo programa. Eso atraería a un público mucho mayor. El modo Zero Noise hace un revelado para enseñarnos el resultado, pero luego nos da la opción de guardar un DNG no interpolado para darnos la opción de revelar con otro software. Ese es el único punto que aún no dominamos, pero caerá, seguro que caerá. A mí, me gustaría ver el balance de blancos en toda la imagen a la vez, el resto me da más igual, pero estoy seguro que mucha gente no se adaptaría a ese modo de funcionamiento.
2. No hay que preocuparse demasiado por los zooms, eso lo hace GDI+, se lo toma con calma, con mucha calma, pero lo hace . Tampoco sobre que la ventana se pueda redimensionar, eso no complicará mucho.
3. El histograma, como ya dije lo dejamos en manos de _GUI_, probablemente aprendas C# sobre la marcha. Si sabes C y VB y en su día programaste en ensamblador, sabes C# porque es casi una fusión de los C y VB, nada que ver con C++, afortunadamente.
4. Si nos parece demasiado lento, una vez hecho con GDI+, pensamos en la opción de portarlo a OpenGL. Pero si ahora nos ponemos a aprender OpenGL no arrancamos nunca. La idea, como ya dije, es tener algo funcionando lo antes posible. Si se hace en OpenGL será bastante portable, así que tampoco por eso nos preocupamos.

Por último, creo que no debemos descartar la opción de tener dos versiones free y pro y que la pro incluya Zero Noise y/u otras funcionalidades con las que no puedan competir otros reveladores. Lo digo porque ahora mola hacerlo gratis y todo eso, pero luego hay que mantenerlo y actualizarlo cuando ya no molará tanto y para eso hacen falta incentivos.

Ahora pregunto para ver cómo de acuerdo estamos:

1. ¿Los entornos y el código están OK?
2. ¿El diseño del GUI con los tres modos de funcionamiento vale?
3. ¿El reparto de tareas os parece justo y adecuado a las capacidades de cada uno? ariznaf, no es un marrón lo del DNG, pero tú controlas más C++ que el resto. Yo te ayudaré todo lo que pueda.
4. ¿Podemos cerra el cutre análisis funcional?

Un saludo:

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

Podéis contar conmigo, soy consultor y desarrollador de C/C++ y C#.
Me da igual VS 2003, VS 2005 o VS 2008.

Saludos.

__________________
Avatar por Rafa Díez

Galería: http://www.flickr.com/photos/domingoyberta/

¡Genial! ¿qué opinión te merece lo que llevamos definido? Encajas como un guante, sobre todo para la parte más difícil, el DNG.

Un saludo:

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

Tiene buena pinta y estáis haciendo un curro bestial. No estaría mal quedar un día y rellenar unas cuantas pizarras. Yo puedo poner la oficina y la pizarra y una biblioteca de libros de .net.
Vosotros las birras.