Tema: Desarrollo de un GUI (Interface Gráfica) para DCRAW

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.

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?

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.

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:

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

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.

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.

El resto de módulos, como el que graba DNG, sí los hacemos como tú dices, en C++ y stub para C#.

¿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í:

_________________________________

Iniciado por ariznaf

¿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?

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.

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

@_GUI_:

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

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.

Iniciado por ariznaf

¿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).

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.

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.

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:

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

Saludos.

Iniciado por dsamper

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

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

Iniciado por ManuelLlorens

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

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.

Un saludo.

Iniciado por dsamper

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.

Yo me apunto, aunque habría que afinar mucho la fecha. ¿Qué dicen el resto?

Un saludo:

Bueno ahora me leo los posts, pero unas reflexiones. Recordando la época en que se pusieron de moda los paquetes integrados (hoja de calculo+procesador de textos+base de datos), recuerdo una cita que leí en una revista a un comentarista del paquete que sacó Amstrad por aquel entonces (ni recuerdo el nombre), dijo algo así como: "paquetes integrados, hacen de todo y todo lo hacen mal".

Por organización, y por no liar el código, creo que es mejor dividir el desarrollo en bloques independientes. Por un lado el revelador. Por otro el fusionador de imágenes en DNG.
Y es que en realidad nada de uno es aprovechable para el otro (recuerda Manuel como de los comandos que tendría el fusionador, ni uno era de revelado) porque el fusionador no va a revelar, sino producir un RAW. Y el revelador persigue revelar RAWs a piñón, pero no fusionarlos.
Por supuesto si se va a hacer con DLLs, cada uno usará las funciones que necesite de las librerías, que podrán coincidir o no (tienen necesidades muy distintas).

Respecto al revelador, el GUI que propongo (me da lo mismo que sea reescalable o no) pero creo que debe centrarse en el detalle (zoom) de la imagen en ratios enteros, y en la comparación antes/después.

El histograma existe, pero se saca a ratitos y desaparece igual que vino para no molestar. Está en ejes de potencias de 2 y es totalmente "zoomable" hasta hacer zoom 1:1 en rango de 16 bits, pero es secundario porque no vamos a actuar sobre él.

Las dos versiones del hipo solo difieren en el balance de blancosm y os aseguro que vistas por separado ninguna de las dos canta por estar demasiado mal. En cambio es ponerlas juntas y se toma conciencia clara de lo que estamos ajustando:

Bueno releyendo lo que dice Manuel, yo sigo pensando que lo suyo es que ZN vaya aparte por modularidad. Tú ves como una ventaja que vayan juntos; yo ya tengo la experiencia de lo rehacia que es la gente a abandonar sus reveladores del alma. Si enfocamos el modo de trabajo a que el fusionador es utilizable de manera externa intercambiando el DNG de manera ágil con cualquier revelador (incluido el nuestro, por cierto necesita un nombre), creo que no solo no se perderá interés sino que interesará a más gente. El GUI de ZN serán de risa y no asustará a nadie. Lo bueno será lo que lleva por dentro.

En cambio juntos se convertiría en un paquete más complejo, y sin verdaderas sinergias entre una parte y la otra.

Yo encantado de juntarnos a hablar de programar cosas claro.

De acuerdo en todo con _GUI_. Dos programas independientes y centrado en el detalle. El histograma se oculta o muestra según haga falta, pero que no se oculten más cosas, que eso complica y no me mola .

Esto ya es hacer cuento de la lechera, y es para más adelante si todo esto sale, pero tengo unas cuantas ideas para añadir al revelador un módulo de salida en BN que funcionaría de un modo diferente y en mi opinión óptimo para BN:

1. Revelado sin balance de blancos: evita problemas de saturación o distorsión en altas luces. No tiene sentido balancear canales si el fin es un BN.
2. Gestión de color desactivada: es absurdo realizar conversión alguna a un espacio de color si el final será en BN.
3. Mezclador de canales inteligente: para formar la luminosidad a partir de los canales RGB, empecé a idear un algoritmo detector de microcontraste, que haga que dicha mezcla sea adaptativa zonalmente para sacar de cada rincón de la imagen el máximo de información de la combinación de los 3 canales.

_________________________________

Iniciado por ManuelLlorens

El histograma se oculta o muestra según haga falta, pero que no se oculten más cosas, que eso complica y no me mola .

Si es fácil hacer qeu el histograma se abra en una ventana propia (eso se llama MDI no?), ésta sí de dimensiones 100% estáticas y potencias de 2: p.ej. 512 x 256 o 768 x 256.
Sería lo ideal.

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?

1.- De acuerdo. Yo ya instalé VS 2005. Si te he entendido bien, podemos hacer el desarrollo inicial en VS y luego compilar con MigWin y utilizar Mono para las partes en C# y .NET (siempre que utilizemos .NET 1.2). Así que, de momento, nos centraremos en windows (intentando mantener la compatibilidad con Linux). Yo además uso Vista 64, por lo que podré detectar problemas de compatibilidad con este SO.
He estado mirando un poquito el dng_sdk y el xmp_sdk. La verdad es que a primera vista es un lio tremendo, pero hay bastantes ejemplos. A ver si consigo crear un DNG y meterle unos datos xmp (no es mucho pedir para empezar, pero estoy bastante oxidado). No está de más que me mandes los módulos que faltan para poder compilarlo todo (lo del Quick Time y el expat xmlparser). Si es ya compilados mejor y así no me como el tarro.

2.- Me parece bien, aunque GUI tiene seguramente razón (y eso que yo lo propuse) que el ZN debería de ser externo y convertir únicamente a DNG para usar luego el revelador. Facilitará el desarrollo y si genera un RAW (si somos capaces de escribir el DNG) quizás no tiene mucho sentido en el revelador. Aunque debería de haber una cierta coordinación entre ambos programas.

3.- Me parece bien, aunque tengo miedo de no estar a la altura (ya digo que hace unos cuatro años que no programo casi nada y en C++ quizás 5 o 6). Pero me peleará con ello. Para facilitar la tarea de enlazar el GUI con el código en C++ para escribir el xmp y DNG te pediría que crearas una clase C# que almacene internamente los parámetros de revelado en curso (y en un futuro los presets para poder tener distintas colecciones de parámetros de revelado almacenadas para una imagen). Estos parámetros deberían almacenarse en variables protegidas y ser establecidas y obtenidas con métodos GET y Set, y reflejar en todo momento los parámetros almacenados en la interface. Luego habría que crear un método para hacer el revelado en sí (llamando a dcraw.dll) y para crear los datos xmp.

4.- Podemos

Un par de cosas más:
¿Nombre de la aplicación? No se me ocurre uno adecuado. ¿Quizás URawDev (de ultimate raw developer) o KRawDev (killer raw developer)? Mejor proponéis algo.

¿Dónde vamos a centralizar el código generado? ¿Cómo vamos a intercambiar las versiones?
Sourceforge no parece un buen sitio de momento porque lleva su tiempo crear un proyecto y a mi me marea todas las herramientas de mantenimiento de código y demás.
Nos bastaría (al menos de momento) con un servidor ftp en que que dejar los zip del código.
_________________________________
dsamper, estupendo si tú te apuntas y colaboras en lo del DNG o XMP (además yo no soy programador profesional).

Por cierto lo de reunirse estaría muy bien,pero... ¿dónde?
No todos somos de Madrid (yo de Oviedo). En junio es posible que me acerque a Madrid un día a impartir un curso. Si voy os lo comentaré.

Bueno, ahí va la prueba de concepto. No os extrañéis si falla con algunos RAWs, porque aún no he pasado todo el código del main() de Coffin a las funciones de la DLL.

http://www.llorensvazquez.jazztel.es/GUI.zip

Como dije arriba, la DLL está hecha en C y compilada con MinGW, el EXE está hecho en VS 2005, por lo que puede que pida .NET 2.0.

Salvo por eso debería correr en cualquier Windows.

Lo importante es que comprobéis que os funciona y veáis la velocidad que se consigue en cargar el raw/interpolarlo con bilineal y nada más/mostrarlo en pantalla.

A _GUI_ se lo paso por mail, como de costumbre.

Un saludo:
_________________________________
Nombres, todos me parecen un poco cutres:

PerfectRAW
ExpertsRAW
RAWexpert
RAWpixel
TURP = The Ultimate Raw Project
PixelUltimate
DCRgui
pixelExpert
RAWphoton
photon2pixel
theRAWexpert
theRAWpower
ODRAW (por Ojo Digital)
DigitalEye
theRAWeye
RAWeye
PhotonCatcher
RAWimage
RAWconverter
RAWmagic
TEOTP = The Eye Of The Photographer
PHEYE = Photographic Eye
TRE = The RAW Eye
...

PerfectRAW

y el otro módulo podría ser PerfectBlend

Está bien lo de Perfect, pues el revelador busca la perfección técnica en los revelados.

Aunque debería de explicitarse que es un revelador. Creo que es más descriptivo
Perfect Raw Developer (abreviado a PerfectRAW cuando se requiera un nombre corto) y Perfect Raw Blender (para hacer énfasis en que maneja archivos RAW y GENERA Raws, si lo conseguimos, claro).
_________________________________
Gracias Manuel por la demo.
La probaré.

¿Sería quizás el momento de abrir un blog en blogspot para poner los comentarios del programa y bugs encontrados, etc?

Si queréis me encargo de crearlo (algo sencillito) y os mando las invitaciones como autores.
Quizás luego sería necesario un wiki y foro o algo así, pero de momento con un blog bastaría y es mucho más rápido de crear y sencillo de mantener ¿no creéis?
_________________________________
El enlace no me funciona, me devuelve el siguiente error:

While trying to retrieve the URL: http://www.llorensvazquez.jazztel.es/GUI.zip
The following error was encountered:

Unable to determine IP address from host name for www.llorensvazquez.jazztel.es

The dnsserver returned:

DNS Domain 'www.llorensvazquez.jazztel.es' is invalid: Valid name, no data record of requested type.

Parece que no existe ese subdominio en jazztel.es

Puede que sea problema de tu proveedor de internet, porque a mi si me funciona

Iniciado por ariznaf

¿Sería quizás el momento de abrir un blog en blogspot para poner los comentarios del programa y bugs encontrados, etc?

Si queréis me encargo de crearlo (algo sencillito) y os mando las invitaciones como autores.

Ya puestos, es más práctico crear un proyecto en sourceforge, gforge o la versión española en forja.rediris.es
Aquí tienes integrado el blog para anuncios, listas de correo, descargas, bugs, control de versiones, etc...

Lo de los links a jazztel de verdad que no lo entiendo, a mí me funcionan bien en casa y en el trabajo. A algunos no os van, pero no puedo hacer nada para solucionarlo. ¿Tenéis alguno un servidor FTP disponible? No sería necesario mucho espacio. De momento lo mandaré a ariznaf por mail.

Yo tengo otro FTP montado en casa (con un mega de ancho de banda e IP fija), pero apago por las noches con lo que no es demasiado útil para este uso.

Más cosas. He estado definiendo más funcionalidad y mejorando el diseño del GUI. Al mediodía reharé la maqueta del GUI y la subo para que veáis los cambios. Creo que quedará al gusto de todos.

Respecto a la funcionalidad, he pensado lo siguiente. Al cambiar de una imagen grande y otra pequeña con zoom perdemos mucha velocidad, pues ahora hay que revelar toda la imagen. Lo de revelar un trozo carece de utilidad, porque de usar esa técnica, cada vez que arrastráramos la imagen para ver otra zona se tendría que poner a revelar el nuevo trozo. Eso antes con una ventana mínima de zoom podía ir bien, pero ahora ni de coña.

Para eso hay que acelerar lo máximo posible el cálculo y eso solo puede hacerse a costa de usar más memoria. Creo que sería útil que la DLL de dcraw devolviese a nuestra aplicación los siguientes buffers con la imagen en distintas etapas del revelado:

• Buffer 0 RAW1 -> Imagen sin procesar, solo girado y escalado.
• Buffer 1 RAW2 -> RAW1 + Hot pixels + Dark Frame.
• Buffer 2 PRED -> RAW2 + Test Patterns + Eq. Greens + White Balance + Black Point + Saturation Point + Wavelet Denoise + Chromatic Aberrations.
• Buffer 3 DEMS -> PRED + Demosaicing + Mix Greens.
• Buffer 4 POST -> DEMS + Median Filter + Hightligths + Exposure.
• Buffer 5 OUTP -> POST + Colorspace + Gamma.

El buffer 0 es común a todas las vistas y se mantiene siempre en memoria, de ese modo no hay que volver a acceder al HD. El resto es propio de cada vista según los parámetros especificados. La DLL tendrá una función que toma como entrada el buffer anterior y los parámetros de esa etapa del revelado y devuelve el buffer siguiente.

Las vistas (yo creo que 4 está bien, pudiendo seleccionar 1, 2, 3 ó 4) tienen dos modos: LIVE y SNAPSHOT, y se pueden conmutar (incluso autoconmutar si llevan tiempo sin cambiarse sus parámetros). En modo L guardan sus 5 buffers, en modo S solo guardan el último. De ese modo podemos ahorrar memoria de las vistas que no vayamos a tocar, si en un momento queremos cambiarlas cambiamos a modo L y se recalculan los buffers que faltan.

La idea es que se muestra la pantalla dividida según las vistas que estén activadas (pudiendo elegir cómo se divide la pantalla entre esas vistas según unos cuadrantes predefinidos). Según pinches en una se cargan en la parte de abajo sus parámetros, si está en modo L puedes cambiarlos, si está en modo S no. Si pasas a modo L se reactivan.

Con todas las vistas activadas en modo L la aplicación consumirá 1 Gb de RAM, con solo una activada 300 Mg. Existe la posibilidad de configurar un modo especial para máquinas con poca memoria (en el futuro) en el que todas las vistas sean modo S y se recalcule cada imagen desde el principio tras cada cambio. Creo que en la maqueta que subiré luego se observarán bien todos estos cambios.

Las vistas se moverán arrastrando (tipo Space + ratón en PS) sin barras de scroll y harán zoom con la rueda del ratón y con alguna tecla, tipo +/-. Se podrá activar o desactivar el histograma para cada vista de manera individual.

También tendrá un modo de salida (en el futuro) en el que se haga una especie de collage con lo que hay en pantalla, las cuatro vistas con sus parámetros y sus histogramas en un solo gif. Muy útil para subir comparativas a foros.

El nombre de perfectRAW y perfectBLEND me gusta, quizás con la ampliación que propone ariznaf también estaría bien.

Un saludo:

Iniciado por ariznaf

El enlace no me funciona, me devuelve el siguiente error:

Parece que no existe ese subdominio en jazztel.es

A mí también me pasa, tienes Orange como yo? o algo anda mal con nuestro servidor DNS, o el dominio jazztel.es no está bien anunciado o no sé, pero es una lata

Respecto al nombre (aunque es lo de menos), creo que se solucionaría con:

• RAW Perfect, abreviado RPerfect
• RAW Blender, abreviado RBlender

Aunque me gusta más Perfect RAW
_________________________________

Iniciado por ManuelLlorens

Al cambiar de una imagen grande y otra pequeña con zoom perdemos mucha velocidad, pues ahora hay que revelar toda la imagen. Lo de revelar un trozo carece de utilidad, porque de usar esa técnica, cada vez que arrastráramos la imagen para ver otra zona se tendría que poner a revelar el nuevo trozo. Eso antes con una ventana mínima de zoom podía ir bien, pero ahora ni de coña.

Para eso hay que acelerar lo máximo posible el cálculo y eso solo puede hacerse a costa de usar más memoria. Creo que sería útil que la DLL de dcraw devolviese a nuestra aplicación los siguientes buffers con la imagen en distintas etapas del revelado:

• Buffer 0 RAW1 -> Imagen sin procesar, solo girado y escalado.
• Buffer 1 RAW2 -> RAW1 + Hot pixels + Dark Frame.
• Buffer 2 PRED -> RAW2 + Test Patterns + Eq. Greens + White Balance + Black Point + Saturation Point + Wavelet Denoise.
• Buffer 3 DEMS -> PRED + Demosaicing + Mix Greens.
• Buffer 4 POST -> DEMS + Median Filter + Hightligths + Exposure.
• Buffer 5 OUTP -> POST + Colorspace + Gamma.

El buffer 0 es común a todas las vistas y se mantiene siempre en memoria, de ese modo no hay que volver a acceder al HD. El resto es propio de cada vista según los parámetros especificados. La DLL tendrá una función que toma como entrada el buffer anterior y los parámetros de esa etapa del revelado y devuelve el buffer siguiente.

Las vistas (yo creo que 4 está bien, pudiendo seleccionar 1, 2, 3 ó 4) tienen dos modos: LIVE y SNAPSHOT, y se pueden conmutar (incluso autoconmutar si llevan tiempo sin cambiarse sus parámetros). En modo L guardan sus 5 buffers, en modo S solo guardan el último. De ese modo podemos ahorrar memoria de las vistas que no vayamos a tocar, si en un momento queremos cambiarlas cambiamos a modo L y se recalculan los buffers que faltan.

La idea de las vistas como concepto de "puntos de ruptura" para ahorrar tiempo de procesado me parece genial (hasta imprescindible), pero no como vistas visualizables en sí, porque en realidad no nos importa mucho el "aspecto" que pueda tener un estado intermedio dado, sino el final de todo el proceso. Creo más idóneo hablar de puntos de ruptura internos, y transparentes al usuario; él no tiene que preocuparse de acelerar el funcionamiento del programa, sino de usarlo.

Además hay que ver si vale la pena tener tantos puntos de ruptura de este tipo para agilizar el refresco. No solo por la complejidad de desmembrar DCRAW en tantas etapas y la memoria extra requerida, sino porque el paso de una a otra quizá implica un % muy pequeño del procesado (eso lo sabrás mejor que nadie), con lo que el ahorro por desglosar en tantos puntos de ruptura es poco.

Quizá lo suyo sea detectar (cronometrar) que partes del proceso total llevan más tiempo, y establecer el límite de los puntos de ruptura justo tras cada una de ellas.

Por ejemplo así a priori, de mi percepción viendo el verbose de DCRAW cuando revelo fotillos, solo el proceso de interpolación, y sobre todo el de reconstrucción de altas luces (cuando se usan valores de -H 3 para arriba) se lleva casi todo el tiempo de procesado:

ORF con amplísimas zonas quemadas:
-H 0: tiempo total revelado: 7s, interpolación AHD: 5s, altas luces: 0s (71% de proceso dedicado a demosaicing y altas luces)
-H 3: tiempo total revelado: 9s, interpolación AHD: 5s, altas luces: 2s (78% de proceso dedicado a demosaicing y altas luces)
-H 9: tiempo total revelado: 26s, interpolación AHD: 5s, altas luces: 19s (92% de proceso dedicado a demosaicing y altas luces)


Está claro que la interpolación y la recup. de altas luces son las partes críticas, así que quizá es suficiente crear solo 3 "imágenes" intermedias, una de ellas incluso sacrificable si no se usa la recuperación de altas luces:

• Buffer 0 DEM -> Hasta el demosaicing inclusive: se actualizará cada vez que el usuario toque algo desde el algoritmo de interpolación o anterior.
• Buffer 1 REC -> Hasta la recuperación de altas luces inclusive: se actualizará cada vez que el usuario toque algo desde el grado de recuperación de altas luces o anterior.
• Buffer 2 OUT -> Tras la recuperación de altas luces: se actualizará cada vez que el usuario toque algo posterior a la recuperación de altas luces.

Por supuesto que se podría optimizar más, pero creo que con esto atacamos al cuello de botella y simplificamos tu curro de destripar DCRAW de arriba abajo (yo no sé como voy a poder ayudarte aquí tío). Las 3 vistas (que no son tantas) podrían estar en memoria siempre. La vista 2 de hecho, en los modos -H 0 y -H 2 (no recuperación de luces) se puede sacrificar de modo que solo tendríamos una vista extra respecto al mínimo de memoria ocupada. Solo cuando el usuario metiera -H 3 o más se crearía esa imagen adicional. Que existan 3 o solo 2 puntos de ruptura en memoria podría ser totalmente transparente al usuario solo dependiendo del valor de H que elija.

Todo esto es quizá ir muy a remolque del código de Coffin adaptándonos a su implementación particular de DCRAW, pero es que me parecen claros esos dos procesos críticos: demosaicing y recup. de luces como para dejarnos de adaptar a lo que es un hecho.

Hay que volver a pensar además en el concepto de lo que pretendemos: no es un revelador al uso, lleno de sliders en tiempo real para que el usuario toque aquí y allá sin orden ni concierto, es un revelador de precisión donde vamos a estar dispuesto a tener un pequeño retardo mayor en las operaciones porque no se trata de ir probando al tuntún, sino de ir eligiendo los parámetros de manera pausada para llegar al mejor resultado posible.


Esto es mi opinión solo eh? no quiero imponer nada jeje.

PD: ah me parece genial obviar las barras de desplazamiento y que el movimiento a través de la imagen sea solo arrastrando ratón, y el zoom sea la rueda.

Iniciado por PerroVerd

Ya puestos, es más práctico crear un proyecto en sourceforge, gforge o la versión española en forja.rediris.es
Aquí tienes integrado el blog para anuncios, listas de correo, descargas, bugs, control de versiones, etc...

Sí, totalmente de acuerdo... :-)

Ya que estamos, una par de cuestiones lingüisticas:

- Creo que sería útil que lo desarrollárais todo en inglés, incluyendo los nombres de las variables, de las funciones, los comentarios del código.

Cuando lo publiquéis como código abierto, será mucho más fácil para mucha más gente leer el código.

- Internacionalización: Intentad que sea fácil traducir el programa. Sería útil que las cadenas de texto estuvieran todas juntas en un archivo (si es XML mejor) con comentarios de dónde y cuándo aparecen.

Intentad evitar concatenar textos y, cuando diseñéis el interfaz, asegurados de dejar espacio en los controles porque otros idiomas necesitarán más espacio.

¿Y para qué os váis a preocupar de esto ahora? Pues porque si se hacen bien las cosas ahora, no cuesta mucho trabajo mientras que si dentro de un año alguien quiere traducir el software le va a costar mucho más esfuerzo.

Daniel

PS. ¡Y muchas gracias por el curro que os estáis pegando!

Iniciado por _GUI_

Aunque me gusta más Perfect RAW

A mí también, la verdad.

Iniciado por _GUI_

La idea de las vistas como concepto de "puntos de ruptura" para ahorrar tiempo de procesado me parece genial (hasta imprescindible), pero no como vistas visualizables en sí, porque en realidad no nos importa mucho el "aspecto" que pueda tener un estado intermedio dado, sino el final de todo el proceso.

No he me explicado bien. Hay cuatro posibles vistas (lo podemos dejar en 2, pero no cuesta mucho más hacerlo para 4) que se muestran en pantalla a la vez, que son la misma imagen revelada con distintos parámetros. Para que cada una de esas vistas vaya rápido, guardamos 1 buffer común a toda y 5 particulares, o sólo 1 si no se van a actualizar.

Iniciado por _GUI_

Creo más idóneo hablar de puntos de ruptura internos, y transparentes al usuario; él no tiene que preocuparse de acelerar el funcionamiento del programa, sino de usarlo.

A eso me refería, pero eso cada una de las cuatro vistas. A ver si me da tiempo a subir la maqueta nueva.

Iniciado por _GUI_

Además hay que ver si vale la pena tener tantos puntos de ruptura de este tipo para agilizar el refresco. No solo por la complejidad de desmembrar DCRAW en tantas etapas y la memoria extra requerida, sino porque el paso de una a otra quizá implica un % muy pequeño del procesado (eso lo sabrás mejor que nadie), con lo que el ahorro por desglosar en tantos puntos de ruptura es poco.

Desmembrarlo ya lo tengo casi hecho. La memoria se soluciona con las vistas en modo S y el % extra de procesado es mucho menor que lo que tarda en calcularse cada etapa. Aún así, ya había tenido en cuenta lo que tardaba cada etapa:

• El buffer 0 es inevitable si no queremos repetir el procesado cada vez, tal vez pueda fundirse con el buffer 1 y no poder ver la imagen sin la sustracción de Dark Frame.
• El buffer 2 se necesita porque el Wavelet Denoise tarda bastante.
• El buffer 3 se necesita por lo que tarda la interpolación.
• El buffer 4 se necesita por lo que tarda la recuperación de luces y el Median Filter.
• El buffer 5 es inevitable.

Tal vez el código pueda elegir saltarse algún buffer si se han dejado los parámetros por defecto de esa etapa para ahorrar memoria. Creo que sí se podría hacer.

Iniciado por _GUI_

Hay que volver a pensar además en el concepto de lo que pretendemos: no es un revelador al uso, lleno de sliders en tiempo real para que el usuario toque aquí y allá sin orden ni concierto, es un revelador de precisión donde vamos a estar dispuesto a tener un pequeño retardo mayor en las operaciones porque no se trata de ir probando al tuntún, sino de ir eligiendo los parámetros de manera pausada para llegar al mejor resultado posible.

Este párrafo irá en la presentación de la aplicación.

Iniciado por _GUI_

PD: ah me parece genial obviar las barras de desplazamiento y que el movimiento a través de la imagen sea solo arrastrando ratón, y el zoom sea la rueda.

Sabía que te encantaría.

Un saludo:
_________________________________

Iniciado por dgmaga

Ya que estamos, una par de cuestiones lingüisticas:

Totalmente de acuerdo, un XML.

Iniciado por dgmaga

PS. ¡Y muchas gracias por el curro que os estáis pegando!

Lo que hace falta es que llegue a buen puerto.

Un saludo:
_________________________________
Bueno, aquí está la segunda maqueta.

Como veís en la parte superior izquierda se configura el formato de Viewport según las imágenes que queramos ver. Si están activas cuatro, como en el ejemplo, solo hay una opción disponible. Si se desactivan vistas se reconfigura a otra opción, tal vez de un modo inteligente mantenga la última vista que se ha actualizado en más grande si es a 3. A la derecha viene la configuración de cada View, podemos activar/desactivar la vista, ponerla en modo LIVE o SNAPSHOT (sin actualización) y mostrar/ocultar su histograma. Faltaría que mostrara el nivel de zoom de la vista (se me ha olvidado meterlo) y que se pudiera poner el modo en AUTO (en función del tiempo que hace que no se actualiza y la memoria disponible).

De momento el histograma se superpondría a la vista, pero puede también meterse en una ventana flotante, aunque a mí me parece un poco molesto. ¿Quizás que aparezca al pinchar un botón un histograma ampliado flotante con más información?

Luego viene a la derecha (sigo en la barra de arriba) información del estado de la aplicación, de ese modo podemos ver si queda memoria para mantener vistas en modo LIVE o no. Las vistas vienen justo debajo, pudiendo cambiar de vista activa pinchando en ella y moverla haciendo click y arrastrando. Para hacer zoom la rueda, aunque sólo en factores predeterminados.

Debajo muestra en la parte central los parámetros de revelado de la vista que está activa, si la vista está en modo S aparecerán en gris. Si cambiamos a modo L se activan de nuevo. La aplicación elegirá desde qué buffer de la vista tiene que actualizar la imagen en función de qué parámetros se hayan tocado, es posible que pueda saltarse algún buffer intermedio entre el 0 y el 3 y el 3 y el 5, o sea, el 1, 2 ó 4.

En la información de la derecha aparece la información de la toma (tal vez con una foto en pequeño de la cámara que se ha utilizado, eso solo por hacer el pijo) y la estadística del histograma.

Ya diréis lo que os parece, he adoptado PerfectRAW como nombre provisional, pero puede discutirse.



Un saludo:
_________________________________
Más cosas.

A nivel de código cada buffer lleva asociada una estructura de datos con la siguiente información:

• Identificación del buffer.
• Variables globales de dcraw que hay que restaurar cada vez.
• Parámetros de la etapa siguiente. O quizás en cada paso se manden mejor todos los parámetros, hace el código más sencillo y permite opciones de saltarse etapas.

Ya tengo hecha la lista de variables que hay que restaurar cada vez. Se recogerán al llamar a DCRAW_Init() y se pasarán y volverán a recoger a cada llamada. También tengo una lista de los parámetros que se pasarán a cada etapa de revelado. Se quedan fuera del programa las siguientes opciones de DCRAW:

-v ... no tiene sentido, ¿o sí? Ver más abajo
-c ... no tiene sentido
-e ... no tiene sentido
-i ... no tiene sentido
-z ... más adelante
-s ... más adelante, se podrá rodear con DNG_Converter
-4 ... no tiene sentido
-T ... no tiene sentido
-h ... no tiene sentido
-d ... más adelante
-D ... más adelante
-b ... para 8 bits
-W ... para 8 bits

(Aquí vuelco la ayuda)
Raw photo decoder "dcraw" v8.86
by Dave Coffin, dcoffin a cybercom o net
_GUI_ - Llorens 16 bit gamma version v0.85
Compiled with Cygwin by M. Llorens

Usage: dcraw [OPTION]... [FILE]...

-v Print verbose messages
-c Write image data to standard output
-e Extract embedded thumbnail image
-i Identify files without decoding them
-i -v Identify files and show metadata
-z Change file dates to camera timestamp
-w Use camera white balance, if possible
-a Average the whole image for white balance
-A <x y w h> Average a grey box for white balance
-r <r g b g> Set custom white balance
+M/-M Use/don't use an embedded color matrix
-C <r b> Correct chromatic aberration
-P <file> Fix the dead pixels listed in this file
-K <file> Subtract dark frame (16-bit raw PGM)
-k <num> Set the darkness level
-S <num> Set the saturation level
-n <num> Set threshold for wavelet denoising
-H [0-9] Highlight mode (0=clip, 1=unclip, 2=blend, 3+=rebuild)
-t [0-7] Flip image (0=none, 3=180, 5=90CCW, 6=90CW)
-o [0-5] Output colorspace (raw,sRGB,Adobe,Wide,ProPhoto,XYZ)
-g <num> Set gamma for 16-bit instead of linear. If 0 or sRGB sets sRGB gamma (default = 1.0)
-d Document mode (no color, no interpolation)
-D Document mode without scaling (totally raw)
-j Don't stretch or rotate raw pixels
-W Don't automatically brighten the image
-b <num> Adjust brightness (default = 1.0)
-q [0-3] Set the interpolation quality
-h Half-size color image (twice as fast as "-q 0")
-f Interpolate RGGB as four colors
-l [0-3] Equilibrate green channels (0=none, 1=G1->G2, 2=G2->G1, 3=G1-><-G2)
-m <num> Apply a 3x3 median filter to R-G and B-G
-s [0..N-1] Select one raw image or "all" from each file
-4 Write 16-bit linear instead of 8-bit with gamma
-T Write TIFF instead of PPM

Mirad a ver si con esto me dejo algo importante fuera.

Para los maestros del C/C++/C#, una pregunta. Cuando compilo y ejecuto el GUI (en C#), la salida de DCRAW que va a la salida estándar (printf y demás) aparece en la consola de VS. Creo que ariznaf sabe como capturarla. Lo digo porque entonces sí puede tener sentido poner el parámetro -v internamente y tener una consola de debugging en la que vuelque DCRAW su información y también nosotros. ¿Es posible?

Cuando tenga la DLL con el destripe de DCRAW documentaré lo que he hecho y os distribuyo el código fuente. Yo no me manejo nada con cosas como SourceForge, pero no me parece mal subirlo. Aunque tal vez aún es un poco pronto.

Un saludo:
_________________________________
Trabajo que podéis ir adelantando:

1. Desarrollar en C#, con unos bitmaps estáticos la parte de las cuatro vistas. Lo de arrastrar y hacer zoom con la rueda, lo de cambiar la configuración del viewport, activar y desactivar vistas, etc. Eso se puede ir haciendo ya independientemente del resto.
2. Desarrollar controles en C# en gris claro con un fondo gris oscuro. Hacen falta botones, botones de dos estados, textboxes con up/down, checkboxes, comboboxes y sliders (aunque no actualicen en tiempo real la imagen). Tal vez también una barra de progreso. Tiene que ser muy compactos y sencillos.
3. Lo del DNG, que ya está dicho.
4. _GUI_ se puede ir instalando VS2005 si lo tiene.
5. Instalaros DEV C++ si queréis compilar la DLL.
6. Engañar a un buen diseñador gráfico para que colabore.
7. Preparar SourceForge/blog/wiki, etc. Pero antes de nada un FTP que nos funcione a todos.
8. Probar distintas opciones para manejar bitmaps en C#: GDI+, GDI a secas (puede que sea más rápido), OpenGL, otras librerías. Por cierto, _GUI_, ¿qué librería estás usando para los TIFFs en VB? Si no contestas me daré por contestado.

Yo voy a terminar la DLL como prioridad para que la comunicación con DCRAW esté resuelta. ¡Ánimo a todos, que esto va que se las pela!

Un saludo:

Buff, uno se despega del ordenadro un par de horas y cuando vuelve ... ¡¡Se encuentra todo el programa hecho!!
Chicos voy a ser incapaz de seguir vuestro ritmo... vosotros ¿dormís, coméis y trabajáis como el resto de los mortales o sóis vampiros?

El problema del DNS debe de ser algo de jazztel. Yo estoy accediendo desde una universidad y detrás de un proxy.
En casa tento jazztel, así que me imagino que no tendré problema en acceder (sino tendría gracia).

Bueno, a lo que vamos sobre el tema de los buffers...
Efectivamente habría que buscar un equilibrio entre el número de buffers almacenado (que ralentizaría el ordenador por consumo de memoria) y el tiempo que tarda en procesado DCRaw. Pero parece que Manuel ya lo tiene claro y lo ha analizado.

Entiendo que la idea es que cada vez que un usuario toque un parámetro, se reconstruyan los buffers correspondientes a cada etapa de procesado afectada a partir de la aplicación de ese parámetro y mostrar siempre el último buffer (con todos los procesados activos) al usuario.

Me parece buena idea.
Otra mejora sería reducir el número de pixels de la imagen a procesar, es decir: no sive de nada procesar y aplicar todos las etapas a la imagen completa si sólo se está mostrando un cacho de la imagen y a un tamaño menor.
Por tanto, al primer buffer habría que aplicarle un escalado y recorte previo a todo lo demás para dejarlo exactamente en el tamaño y número de pixels que se está mostrando en ese momento.
Así si tengo una imagen de 12 MP pero en la pantalla estoy viendo un recorte a 800x600, si recorto y convierto la imagen a 800x600, el proceso de las etapas posteriores será mucho más rápido.
No tengo claro en qué etapa se puede aplicar ese escalado y recorte. Lo ideal sería hacerlo ya justo después de el demosaicing (antes no creo que se pueda) ¿no?

Por otra parte, el refresco de la imagen debería de ser en segundo plano, lanzando un hilo que se encarge del refresco para que la aplicación siga respondiendo bien. Además ese hilo de refresco debería de ser abortable, por si el usuario modifica otra vez los parámetros antes de que hayamos acabado de refrescarla por completo.

Por lo que he visto en ACR, parece emplear un método similar al descrito. Incluso parece que hace un revelado rápido sobre una imagen a menor resolución y luego lo hace con precisión (pues muchas veces muestra una imagen no del todo correcta durante unos segundos y luego la actualiza).
Manuel, sé que esto puede ser más complicado y a lo mejor hay que dejarlo para una segunda vuelta, pero creo que sería importante para que la aplicación responda con soltura.

Iniciado por ManuelLlorens

No he me explicado bien. Hay cuatro posibles vistas (lo podemos dejar en 2, pero no cuesta mucho más hacerlo para 4) que se muestran en pantalla a la vez, que son la misma imagen revelada con distintos parámetros. Para que cada una de esas vistas vaya rápido, guardamos 1 buffer común a toda y 5 particulares, o sólo 1 si no se van a actualizar.

(...)

¿Quizás que aparezca al pinchar un botón un histograma ampliado flotante con más información?

(...)

Por cierto, _GUI_, ¿qué librería estás usando para los TIFFs en VB?

Yo creo Manuel que por complejidad añadida de implementación, del número de opciones (botones) en el GUI, del consumo de memoria y sobre todo porque creo que más de 2 vistas no aportan demasiado, es mejor dejarlo en 2; pero tú mandas. Además con más de 2 vistas sería complejo implementar el modo en que la imagen aparece en pantalla sin réplicas, pero la mitad procesada con los ajustes "antes" y la otra mitad "después", como el primer hipopótamo. Creo que es un modo de comparación muy adaptado para suplir las carencias de nuestro sistema visual.

El histograma superpuesto mola, solo le veo el problema de que si la imagen es escalable el histograma necesita un eje X en potencias de 2 (256,512,...). Una ventana dedicada, que puede no tenerse abierta, proporcionaría un histograma potente (con 512 píxels se tiene un señor histograma).

Cuando pase lo del taller del sábado me pondré manos a la obra a instalarme los entornos que me estáis diciendo. También voy a pedir a Sergio que me habilite un espacio FTP dentro del que ya tenemos, os paso las PWD.

Uso las librerías de 16 bits de Xnview aunque para los histogramas con la versión de 8 bits me bastó. Adaptarlas a cualquier otra librería es trivial, basta que me instale el entorno y aprender a dibujar píxels y líneas de un color dado, y leerlos de la imagen original. Una cosa sobre el histograma: estaría bien poder representarlo del total de la imagen o de la porción sobre la que hacemos zoom (para ver el clip por espacio de color insuficiente y cosas así). Con saber las matrices y objetos de donde leer los colores no necesito más.
_________________________________

Iniciado por ariznaf

Otra mejora sería reducir el número de pixels de la imagen a procesar, es decir: no sive de nada procesar y aplicar todos las etapas a la imagen completa si sólo se está mostrando un cacho de la imagen y a un tamaño menor.

Por lo que he visto en ACR, parece emplear un método similar al descrito. Incluso parece que hace un revelado rápido sobre una imagen a menor resolución y luego lo hace con precisión (pues muchas veces muestra una imagen no del todo correcta durante unos segundos y luego la actualiza).
Manuel, sé que esto puede ser más complicado y a lo mejor hay que dejarlo para una segunda vuelta, pero creo que sería importante para que la aplicación responda con soltura.

El problema es lo que decía Manuel, si te pones a moverte por la imagen ya pierdes la ventaja de revelar solo un trozo. Aparte hay procesos que probablemente tienen un "efecto de bordes"; seguro que la recuperación de altas luces no da el mismo resultado en un área dada si se aplica sobre toda la imagen que solo en ese trozo (porque precisamente es un procesado que toma datos de zonas adyacentes).
Yo creo que la velocidad no va a ser un problema, DCRAW es bastante rápido y los ajustes que vamos a hacer son casi todos de tocar y mirar un ratito para opinas sobre el cambio. No es como una curva donde la agilidad sí es una necesidad. Yo creo que la prioridad es precisión + simplicidad (tanto de implementación como de uso), frente a velocidad.

@Manuel:

Para los maestros del C/C++/C#, una pregunta. Cuando compilo y ejecuto el GUI (en C#), la salida de DCRAW que va a la salida estándar (printf y demás) aparece en la consola de VS. Creo que ariznaf sabe como capturarla. Lo digo porque entonces sí puede tener sentido poner el parámetro -v internamente y tener una consola de debugging en la que vuelque DCRAW su información y también nosotros. ¿Es posible?

A ver si me explico: lo de capturar la salida stdout de un programa es sencillo. Hay do métodos:
1.- Lanzar el programa utilizando la función fpipe (es una función de la librería stdio y por tanto debería funcionar también en Linux). La función fpipe devuelve un descriptor de fichero FILE * enlazado a la salida stdout del programa (si se abre en modo lectura, si se abre para escritura estaría enlazado con la entrada estandar). A partir de ahí podemos ir leyendo del FILE como si fuera un fichero de texto normal.
2.- Para el caso de programas que escriben directamente en fichero y no dan la opción de escribir su salida en stdout, se puede usar una pipe con nombre (no recuerdo las funciones exactamente). El problema en este caso es que las funciones de creación de pipes con nombre son propias de Windows y no funcionarían en Linux. Aunque creo que hay también una librería Posix para windows que seguramente soporte la creación de pipes con nombre y que funcione en windows y linux.

En tu caso creo que esto no te sirve, porque tu programa ya no es un programa externo, es una DLL que funciona dentro del programa general.
En este caso también hay soluciones. Una sería recompilar la librería DLL habiendo definido stdout con otro número de fichero (si miras stdio stdout es simplemente un #define stdout 1 creo recordar. Se podría hacer #undef stdout y #define stdout 4 por ejemplo, y abrir el fichero 4 antes de llamar a la dll de DCRaw).

Déjame mirar todo esto un poco más esta noche y te comento con más detalle, pues lo tengo un poco olvidado y ahora no tengo el VS a mano.
_________________________________

El problema es lo que decía Manuel, si te pones a moverte por la imagen ya pierdes la ventaja de revelar solo un trozo. Aparte hay procesos que probablemente tienen un "efecto de bordes"; seguro que la recuperación de altas luces no da el mismo resultado en un área dada si se aplica sobre toda la imagen que solo en ese trozo (porque precisamente es un procesado que toma datos de zonas adyacentes).
Yo creo que la velocidad no va a ser un problema, DCRAW es bastante rápido y los ajustes que vamos a hacer son casi todos de tocar y mirar un ratito para opinas sobre el cambio. No es como una curva donde la agilidad sí es una necesidad. Yo creo que la prioridad es precisión + simplicidad (tanto de implementación como de uso), frente a velocidad.

Efectivamente, es cuestión de probar. Si en mi portátil a 1,6 GH funciona con suficiente soltura revelando toda la imagen, creo que funcionará en cualquier ordenador
Pero tened en cuenta que las cámaras tienen ya muchos megapixels.
La solución que se suele emplear para el tema de moverse es recortar una zona mayor que la que se está mostrando (como hace google maps) y así cuando el usuario mueve la imagen tenemos un margen alrededor y podemos ir preparando el siguiente revelado que se mostrará cuando esté preparado.

En cualquier caso hay que tener en cuenta que el número de pixels máximo que mostraremos de una imagen con un zoom determinado será el del monitor, que en muchas ocasiones será bastante menor que el de la imagen.

Para resolver lo del zoom, la imagen se puede preparar con 2 veces más pixels de los necesarios y así podremos dejarle hacer zooms hasta 100% del acutal sin necesidad de revelar nuevamente y mientras aumenta el zoom, podremos ir preparando la siguiente.

De todas formas, creo que posiblemente sea algo a afinar a posteriori, no será prioritario a no ser que el refresco fuera muy lento.

Más cosas, no hace falta reinventar la rueda muchas veces.
Hay una libreria de dcraw programada en C++ estándar usando librerias bastante estables como libjpeg y alguna otra.

http://libopenraw.freedesktop.org/wiki/

Creo que es más práctico mirar si esto funciona en Windows (los desarrolladores dicen que debería pero que no lo han probado) y ver que carencias tiene respecto a lo que necesitamos.

Otra cosa, aunque se ha comentado lo de comentar el programa en inglés yo tiraría por un nombre de programa en español, aunque ninguno de la lista lo parezca.

Voy a echar un vistazo a Xnview.

Lo de las vistas: está bien, lo dejamos en dos vistas y nos evitamos problemas de memoria y reducimos la complejidad de implementación, más adelante no debería costar mucho ampliar a más vistas. Habría entonces 3 configuraciones del viewport: una vista, una vista mitad y mitad y dos vistas. ¿OK?

Voy a hacer una prueba de revelado con 5 buffers a ver qué tal va de velocidad. Si puedo subo un ejecutable para que probéis. De momento estoy intentado pasar una estructura desde C a C# sin que me funcione (es raro, la paso bien pero la recibo vacía en C#, desde C la recibo bien). Ya lo hará.

Una cuestión a ver si yo lo entiendo bien. Estamos obteniendo una imagen de 16 bits por canal desde DCRAW, lo que hacen 16*3=48 bits por pixel (bpp). En C# cargo un bitmap de 48bpp, pero al visualizarlo aparece mal si no reduzco de 48 a 32 bpp, supongo que esto es porque las tarjetas de vídeo no reproducen más de 32bpp, ¿no?

Otra cosa más, estoy casi seguro de que en modo unsafe podemos usar llamadas al API de Win32 para copiar trozos de memoria más rápido de lo que yo lo hago, al menos si paso el buffer ya preparado a 32bpp desde C, mirad el código actual y tratad de optimizarlo:

BitmapData data = img.LockBits(new Rectangle(0, 0, img.Width, img.Height), ImageLockMode.ReadWrite, PixelFormat.Format48bppRgb);
unsafe
{
ushort *image = DCRAW_Process();

byte* ptr = (byte*)(data.Scan0);
for (int i = 0; i < data.Height; i++)
{
for (int j = 0; j < data.Width; j++)
{
ptr[0] = (byte)(image[2] >> 2 & 0xff);
ptr[1] = (byte)(image[2] >> 10);
ptr[2] = (byte)(image[1] >> 2 & 0xff);
ptr[3] = (byte)(image[1] >> 10);
ptr[4] = (byte)(image[0] >> 2 & 0xff);
ptr[5] = (byte)(image[0] >> 10);
image += 3;
ptr += 6;
}
ptr += data.Stride - data.Width * 6;
}
}
img.UnlockBits(data); Un saludo:

@ManuelLlorens:

Voy a hacer una prueba de revelado con 5 buffers a ver qué tal va de velocidad. Si puedo subo un ejecutable para que probéis. De momento estoy intentado pasar una estructura desde C a C# sin que me funcione (es raro, la paso bien pero la recibo vacía en C#, desde C la recibo bien). Ya lo hará.

Eso creo que se debe a que las estructuras o clases en C# no se almacenan como en C. En C# almacenan tablas al inicio y punteros para acceder a los elementos virtuales y cosas por el estilo. Recuerdo haber tenido problemas con este tipo de cosas. ¿Podrías poner el ejemplo de cómo la declaras en C y en C# y así podría intentar ver si localizo el problema? ¿Lo devuelves desde C como puntero?

Una cuestión a ver si yo lo entiendo bien. Estamos obteniendo una imagen de 16 bits por canal desde DCRAW, lo que hacen 16*3=48 bits por pixel (bpp). En C# cargo un bitmap de 48bpp, pero al visualizarlo aparece mal si no reduzco de 48 a 32 bpp, supongo que esto es porque las tarjetas de vídeo no reproducen más de 32bpp, ¿no?

Efectivamente, Manuel, las pantallas pueden trabajar a 32BPP pero creo que son 8 bits por canal (24 bits) y los otros 8 son para el canal alfa de transparencias.
Si no vas a manejar transparencias, ahorrarás memoria si los bitmaps los pasas de 48 a 24 bits. Me imagino que las opciones de BitmapData permitirán preparar los bitmaps en 24 bits y no utilizar 32. Quizás para la ventana en que superpones el histograma, el histograma lo tendrás que poner en 32 bpp para poder darle un grado de transparencia al histograma superpuesto.

La función que pides para la copia de bloques de memoria existe en la librería estandar de C. Se llamaba memcpy sino recuerdo mal y se le pasaba un puntero (void) al origen, al destino y el número de bytes a copiar.
Más información en : http://msdn.microsoft.com/en-us/library/aa246468.aspx

En cuanto a lo de capturar la salida de stdout, lo he estado pensando y creo que es mucho más fácil de lo que planteábamos.
Podrías poner una opción -v en el programa del revelador. Cuando se lanza con -v, el revelador podría utilizar stdout o stderr para mostrar mensajes de depuración (al igual que DCRaw.dll).
Si lanzas el programa desde linea de comandos y con -v aparecerían los mensajes de Debug que es lo que querías. Si quieres que aparezcan en una ventana, bastaría con hacer un programita windows que lea desde stdin y todo lo que lea lo vaya escribiendo en la ventana (como el Debugger). Lanzando el revelador con -v y haciendo un pipe al programa, verías la salida en la ventana.

Si quieres dar la opción desde dentro del programa, también se podría hacer lanzando dicho programita desde el propio programa y activando la opción de verbose a partir de ese momento.

Vaya, he quedado impresionado con esta iniciativa. Llevaba semanas sin mirarme demasiado el foro y me he sorprendido gratamente. Es una lástima no poder ayudaros ya que mis conocimientos de programación son nulos. Aunque cuando esté más o menos operativo para un usuario normal, me encantaría ser betatester o como se llame.

Sólo una cosa (que no sé si ha sido contestada ya porque solo he tenido tiempo de leer el hilo por encima): creo que sería muy interesante que el programa en cuestión fuera multiplataforma: los usuarios de linux andamos como locos buscando el revelador definitivo, y seguro que encontrareis adeptos en este "mercado".

Lo que se ha comentado por ahí de abrir un proyecto en sourceforge me parece una idea excelente.

Bueno, sólo daros muchos ánimos. Estáre atento al hilo.

Manual:
No me funciona la versión del programa de prueba que pusiste esta mañana.
Descomprimí el fichero y copie la dll y el exe directamente en el escritorio.

Lancé el programa y utilicé el browse para abrir un dng.
Al dar al botón de revelado me aparece el siguiente error:

Consulte el final de este mensaje para obtener más detalles sobre cómo invocar a la depuración
Just-In-Time (JIT) en lugar de a este cuadro de diálogo.
************** Texto de la excepción **************
System.BadImageFormatException: Se ha intentado cargar un programa con un formato incorrecto. (Excepción de HRESULT: 0x8007000B)
en DCRAwGUI.Form1.DCRAW_Init(String rawfile, Int32* Width, Int32* Height)
en DCRAwGUI.Form1.button1_Click(Object sender, EventArgs e)
en System.Windows.Forms.Control.OnClick(EventArgs e)
en System.Windows.Forms.Button.OnMouseUp(MouseEventAr gs mevent)
en System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
en System.Windows.Forms.Control.WndProc(Message& m)
en System.Windows.Forms.ButtonBase.WndProc(Message& m)
en System.Windows.Forms.Button.WndProc(Message& m)
en System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

.........

Parece que el formato de la DLL no es apropiado.
Ten en cuenta que yo estoy utilizando Vista 64.
De todas formas no entiendo muy bien el error, porque el programa se supone que es de 32 bits y la librería también, por tanto al cargar la librería dinámica debería de tratarla como una de 32 bits (que es lo que es).
Los programas de 32 bits funcionan perfectamente en Vista, no sé por qué este ha de dar un error.
_________________________________
Puedes mirar más información sobre la excepdión en MSDN: http://msdn.microsoft.com/es-es/libr...on(VS.80).aspx

Parece que el error se produce al cargar con Load código no administrado.
Efectivamente la dll es código no administrado, pero para eso habías puesto las declaraciones y el import de la librería ¿no?
Si en win32 te funciona, no sé por qué ha de dar un problema en win64

La verdad es que no doy abasto para contestaros a todos, y si lo hago, entonces no programo .

Intento contestas a todos, pero voy rápido:

• La struct debería funcionar, muchas funciones del API de Windows reciben/pasan estructuras por referencia, es algo que no estoy haciendo bien. Lo miraré, si no lo corrijo subo el código y lo miráis.
• Puede que la DLL no te funcione por estar compilada con MinGW, en principio sí debería. Probaré a compilar con cygwin, que ya hemos comprobado que funciona con el dcraw.exe. La última opción es pasarlo directamente a VC++, no lo he hecho antes porque aún no he solucionado un problema con VC++ que me compila dcraw.exe pero luego no funciona. Creo que es porque hago un #define ftello ftell, y no son exactament iguales, pero no he tenido tiempo de probarlo, por eso tiré por la calle de enmedio con MinGW. Te paso el código por mail para que pruebes tú, pero no te asustes, que está lleno de pruebas raras.
• De momento, dado que ninguno de los que estamos implicados usamos linux habitualmente no vamos a compilar para linux. Tendremos cuidado de no hacer nada que no sea portable más tarde, pero tendrán que ser otros los que se encarguen. La elección C/C++/C# está basada en eso. Por eso también me resisto a pasar de MinGW a VC++.
• El nombre es provisional, se aceptan propuestas en cualquier idioma .
• La opción de revelar por partes un trozo más grande del que se ve en pantalla es lo ideal, pero complicaría mucho el código. Vamos a probar qué tal va con toda la imagen. Como dice _GUI_ en algún sitio, el objetivo no es tener un revelador chulo y rápido, sino uno que extraiga la máxima calidad de cada píxel y lo haga aportando información más técnica que la competencia. Si es un poco lento, es parte del proceso... aunque obviamente intentaremos que vaya lo más rápido posible. Desde luego el revelado se hará en segundo plano, pero tiene que ser con un solo hilo, porque la DLL no aguanta multitarea.
• No usamos el código dcraw.c de Coffin, sino el modificado por nosotros (DCRAW con compensación gamma pura y perfil H-RGB), queremos mantener el código de Coffin intacto (bueno, con nuestros cambios que ya se han hecho pensando en respetar su código lo máximo posible), es una de las prioridades del proyecto. Además queremos poder introducir los cambios que haga Coffin con el mínimo esfuerzo posible, si usamos una DLL de Internet perdemos esa capacidad. Soy consciente de que estamos haciendo una chapuza de DLL, acorde al estilo de programación de Coffin. Llena de variables globales, código espagueti, etc., pero queremos exprimir el código de Coffin sin cambiarlo.
• ariznaf, si puedes realizar un pequeño ejemplo en código de lo que cuentas de stdout te lo agradeceremos todos.

Un saludo:
_________________________________
Bueno, la struct está funcionando, era una chorrada de esas de aupa. Os la voy a contar para que os suba la moral a los que dudáis de que no estéis a la altura del proyecto:

[DllImport(@"DCRAW_DLL.dll")]
static extern void DCRAW_GetInfo(ref IMAGE_INFO info);

[DllImport(@"C:\dcraw\dlls\DCRAW_DLL.dll")]
static extern void DCRAW_GetInfo(ref IMAGE_INFO info);

Ayer cambié la ubicación de la DLL para subir el ejemplo y que buscara la DLL en el mismo directorio que el EXE, pero en mi máquina está en carpetas distintas .

Un saludo:
_________________________________
He probado a revelar en segundo plano y va perfecto . Ahora ya tengo una clase dcraw en C# que se puede llamar en segundo plano.

Un saludo:

De momento, dado que ninguno de los que estamos implicados usamos linux habitualmente no vamos a compilar para linux. Tendremos cuidado de no hacer nada que no sea portable más tarde, pero tendrán que ser otros los que se encarguen. La elección C/C++/C# está basada en eso. Por eso también me resisto a pasar de MinGW a VC++.

Yo de hecho, estoy usando VS C++ (2005). Si no usamos extensiones específicas y usamos librerías comunes a linux y windows, no tendría por qué no funcionar al utilizar otro compilador, pero siempre aparece algún problemilla. Si te parece, de momento seguimos con VS C++ y luego habrá que probar a compilar con un compilador de linux (como los que comentas) de vez en cuando. Cuando reciba el código, intentaré compilarlo en el VS C++ y te contaré.

ariznaf, si puedes realizar un pequeño ejemplo en código de lo que cuentas de stdout te lo agradeceremos todos.

Lo que yo había comentado a GUI sobre el uso de popen era para lleer la salida de DCRaw desde zero noise, cuando dcraw era un ejecutable externo.

Aclárame que quieres exactamente. Si te entiendo bien, quieres poder activar la opción de -v y que todo lo que el programa (o la DLL de DCRaw) escriba en stdout se muestre en una ventana para debugear ¿no?
¿Pero necesitas dar la opción de activarlo o no desde el propio programa?
¿Te valdría hacer algo como esto?:

Lanzar el programa utilizando la siguiente linea de comandos:
PerfectRaw.exe -v | stdoutEnVentana.exe

Sería entonces suficiente crear un programa stdoutEnVentana.exe que fuera un simple formulario con un cuadro de texto, lea todo lo que llega de stdin y lo escriba en el cuadro de texto.

La opción de revelar por partes un trozo más grande del que se ve en pantalla es lo ideal, pero complicaría mucho el código. Vamos a probar qué tal va con toda la imagen. Como dice _GUI_ en algún sitio, el objetivo no es tener un revelador chulo y rápido, sino uno que extraiga la máxima calidad de cada píxel y lo haga aportando información más técnica que la competencia. Si es un poco lento, es parte del proceso... aunque obviamente intentaremos que vaya lo más rápido posible. Desde luego el revelado se hará en segundo plano, pero tiene que ser con un solo hilo, porque la DLL no aguanta multitarea.

No es imprescindible que sea un solo hilo (aunque la dll no sea thread safe). Ten encuenta que las llamadas a la dll van a ser escasas. Para evitar la posibilidad de que se llame dos veces a la dll antes de que acabe el procesamiento anterior, bastaría con utilizar un semáforo y antes de llamar cualquier función, asegurarse de que se puede obtener el semáforo. Si no se puede obtener es que la llamada anterior todavía no acabó (y está todavía revelando). Es un poco cutre, pero funcionaría. Y creo que puede ser más fácil lanzar un hilo para revelar utilizando dcraw que tener que hacer una falsa multitarea para simular el segundo plano, pues entonces el revelado tendría que ir haciéndose a trocitos y devolviendo el control a la aplicación.
Pero eso también sería algo para más adelante (si el revelado se hace un poco pesado y lento).
_________________________________
¿Dices que ya revelas en segundo plano?
¿Lanzas un hilo para el revelado y has asegurado la dll?
Si no, la única forma que se me ocurría es haciéndolo en el OnIdle un poquito de cada vez, y la verdad creo que habría que cambiar mucho en el código de la dll para que vuelva y luego continue donde lo dejó.
¿Cómo lo has hecho en pocas palabras? (es pura curiosidad)
_________________________________
Por cierto hoy ya he compilado y probado los ejemplos de xmp-sdk.
Lo he estado mirando un poquito para ver de qué va la historia. Parece un poco farragoso pero bueno, no imposible.

dng-sdk me da algunos errores y no lo he podido compilar bien.
He mirado el ejemplo de crear un DNG.
Lo más lioso va a ser preparar la imagen utilizando las herramientas de dng-sdk para establecer todos los parámetros adecuados (y que estaban presentes en la imagen original) y los almacenados por la cámara, porque hay un montón: balance de blancos, modelo de cámara, datos de la toma, etc, etc.

De momento, así:

textBox1.Text contiene el nombre del archivo a revelar

DCRAW_Thread dcraw= new DCRAW_Thread(textBox1.Text);
Thread thread=new Thread(new ThreadStart(dcraw.Process));
thread.Priority = ThreadPriority.Lowest;
thread.Start();
do{
Console.Write(".");
Thread.Sleep(50);
}while (thread.IsAlive);
camera.Text = dcraw.info.camera_make + " " + dcraw.info.camera_model;
pictureBox1.Image = (Image)dcraw.img;

Siendo DCRAW_Thread la clase que hace todas las llamadas a DCRAW, no he implementado semáforos, aunque estoy pensando en un ThreadPool, ¿cómo lo ves? Por cierto, aunque lo lanzo en segundo plano, el Thread.Sleep me deja la aplicación muerta. Creo que tendré que tener otro hilo que llame al hilo de revelado y sea ese el que espere a que termine o algo así... ¿cómo me entero de que ha terminado de revelar sin dejar la aplicación muerta?

Un saludo:

_________________________________
He cambiado el búcle que vuelca el bitmap por, es decir que paso a 24bps, como decía ariznaf. Ahora se ve bien, creo, tal vez se me está escapando algo.

for (int j = 0; j < data.Width; j++)
{
ptr[0] = (byte)(image[2] >> 4 & 0xff);
ptr[1] = (byte)(image[2] >> 12);
ptr[2] = (byte)(image[1] >> 4 & 0xff);
ptr[3] = (byte)(image[1] >> 12);
ptr[4] = (byte)(image[0] >> 4 & 0xff);
ptr[5] = (byte)(image[0] >> 12);
image += 3;
ptr += 6;
}
_________________________________
He estado pensando que debe ser dcraw.dll y no el GUI el que decida desde que buffer hay que actualizar en cada caso. Así que no habrá una única estructura con los cinco buffers y todos los parámetros y variables. También habrá una sola función de revelado en la DLL a la que le llegará y devolverá esa estructura. Un miembro de la estructura indicará el parámetro que ha lanzado el nuevo revelado y dentro de la DLL se decidirá qué es lo que hay que hacer.

De ese modo el GUI no sabrá nada del funcionamiento interno de DCRAW, solo le pide que revele porque ha cambiado tal parámetro. Otra ventaja de este método es que la DLL puede dejar en NULL algunos de los buffers si sabe que no los necesita, con lo que ahorramos memoria. También, si se le pide que revele algo para lo que no tiene buffers, sabrá lo que tiene que hacer.

Creo que es el modo más lógico de proceder. ¿Opiniones?

AH! eso me parecía que sin hilos la cosa estaba complicada...

Jo, que rabia hace tanto que no programo que me cuesta mucho acordarme de estas cosas. Yo esto antes lo controlaba (más o menos).

Creo que los más fácil sería lanzar un mensaje desde DCRaw que diga "He acabado".
La cola de proceso de la aplicación recibirá el mensaje y lo procesará. Atendiendo entonces ese mensaje, puedes simplemente dibujar la nueva imagen.

Pero claro, eso era antes de .NET ahora los mensajes de windows en .NET están muy escondidos, pero tiene que haber un equivalente... como se llamaban ¿eventos?

Yo creo que sería algo así:

Crear una función en C# (dentro de la app principal) para lanzar el revelado (te lo pongo en pseudocodigo porque no me acuerdo de los nombres de todas las funciones
Revelar()
{
esperarEnSemaforo() //Esperar a que acabe el revelado anterior antes de proseguir.
dcraw.Process()
generarEvento("He acabado")
}


luego lanzas un hilo llamando a Revelar()
Thread thread=new Thread(new ThreadStart(Revelar));
thread.Priority = ThreadPriority.Lowest;
thread.Start();
y simplemente regresas.

Tienes que haber preparado un manejador de eventos para el evento generado:

OnEventoUsuario()
{
camera.Text = dcraw.info.camera_make + " " + dcraw.info.camera_model;
pictureBox1.Image = (Image)dcraw.img;

}

De los detalles no me acuerdo, pero creo que podría ser algo así.

Lo de los threadPools no lo conozco bien, per me imagino que no inicia un thread hasta que acabe el anterior.

Sin embargo no lo creo necesario. Me explico: en realidad en cada momento sólo interesa un revelado. Si antes de acabar uno lanzamos otro, será porque el usuario cambió los parámetros antes de acabar el anterior. Entonces, lo revelado en ese momento no resulta ya de interés, y tampoco interesa esperar a que acabe. Lo suyo sería abortar el thread anterior y lanzar uno nuevo.

Si lo hacemos así, no necesitaríamos ni los semáforos, únicamente la variable thread inicializada a null.
Si no vale null es porque hay un hilo de revelado anterior, por tanto abortamos el hilo anterior y lanzamos uno nuevo. En el receptor del evento, inicializamos la variable thread a null otra vez (pues es que ya acabó).
_________________________________

He estado pensando que debe ser dcraw.dll y no el GUI el que decida desde que buffer hay que actualizar en cada caso. Así que no habrá una única estructura con los cinco buffers y todos los parámetros y variables. También habrá una sola función de revelado en la DLL a la que le llegará y devolverá esa estructura. Un miembro de la estructura indicará el parámetro que ha lanzado el nuevo revelado y dentro de la DLL se decidirá qué es lo que hay que hacer.

De ese modo el GUI no sabrá nada del funcionamiento interno de DCRAW, solo le pide que revele porque ha cambiado tal parámetro. Otra ventaja de este método es que la DLL puede dejar en NULL algunos de los buffers si sabe que no los necesita, con lo que ahorramos memoria. También, si se le pide que revele algo para lo que no tiene buffers, sabrá lo que tiene que hacer.

Creo que es el modo más lógico de proceder. ¿Opiniones?

Me parece buena idea, pero ten encuenta que estás complicando el código de DCRaw y pasando más carga de programación a C, y será por tanto algo más difícil de mantener en versiones futuras de DCRaw.

Por ello te propongo otra opción: crear una clase C# en la que encierres todo el acceso al revelado y demás, que se encarge de las variables internas y los buffers.

La desventaja sería que sólo se podría utilizar de manera trasparente desde .NET.
Si lo quieres hacer en C (para evitar esto) creo que sería mejor que aislaras todo el tema de manejo de buffers y demás en otra librería dll diferente, con funciones a las que pasaras el struct que mantiene el estado del revelado y que desde C# nos limitaríamos a almacenar y pasar a las funciones como primer parámetro (para emular en C el comportamiento de un objeto de una clase).
Esas funciones de librería se encargarían de llamar a las funciones que ahora tienes ya en DCRaw.dll. Con ello evitas seguir tocando más el código de Coffin.

Suena bien, ariznaf, voy a consultarlo con la almohada, llevo un cuarto de hora sin atinar una línea de código.

Un saludo:

Teniendo en cuenta que ahora mismo muchos procesadores tienen más de un núcleo, y para evitar el uso del semáforo con la dll no reentrante, ¿No se podrían usar procesos en vez de threads? Así se quita el problema de que la librería no sea reentrante (Que supongo que viene de todas las variables globales que tiene), y se puede procesar más de un raw a la vez.

Iniciado por Razov

Teniendo en cuenta que ahora mismo muchos procesadores tienen más de un núcleo, y para evitar el uso del semáforo con la dll no reentrante, ¿No se podrían usar procesos en vez de threads? Así se quita el problema de que la librería no sea reentrante (Que supongo que viene de todas las variables globales que tiene), y se puede procesar más de un raw a la vez.

Pues sí, seguramente llevas razón. ¿Será igual de fácil comunicar con un proceso que con un thread? Lanzar eventos, pasar parámetros, etc. Te atreves con un ejemplo en código fuente.

Por lo que yo entiendo para lanzar un proceso nuevo tengo que ejecutar un .EXE... ¿cómo me comunico con el EXE, mediante mensajes win32? ¿Será eso portable a linux?

Un saludo:

Aparezco sólo para dar ánimos, ya que de programación ni jota. Eso sí, me comprometo a hacer pruebas de las versiones si queréis.
Por cierto, estoy seguro que muchos, como yo, están atentos al hilo pero no participan porque no podemos aportar mucho.
Tiene una pinta alucinante.
Además, me alegro que _GUI_ haya encontrado compis que hablen su mismo idioma.
Ánimo.

Álex.

Iniciado por ÁlexG

Por cierto, estoy seguro que muchos, como yo, están atentos al hilo pero no participan porque no podemos aportar mucho.

Hombre, si no sabéis programar no podéis participar de esa fase, pero sí de la de diseño, en la que estamos ahora, y como tú dices en la de pruebas.

Podéis mirar las maquetas y la funcionalidad que vamos definiendo y decir si os parece que es lo que necesitáis.

Un saludo:

Hola chicos,
la verdad es que el proyecto parece muy interesante.

Me gustaria ayudar, pero como no deje de dormir lo tengo mal. Aunque si hay alguna tarea puntual se puede mirar.

El C++ y yo somos como hermanos, así que con eso no habrá ningún problema. Tengo conocimientos de OpenGL, aunque nunca se me habia ocurrido hacer una aplicación 2D con OpenGL.

A mi me gustaria que la herramienta fuera multiplataforma y que funcionará con Linux, que lo que hay no me termina de convencer.

Nadie de vosotros tiene conocimientos de Qt? Yo no lo he usado nunca, pero si se hace el GUI con Qt el programa es compatible con Linux. Para proyectos Open Source es gratuita.

Y sobre dónde colgar el código. Yo realmente propongo que sea en SourceForge o similar, para un proyecto dónde participa diferente gente de diferentes sitios hay que tener un control de versiones.
Que os parece poner el proyecto en Google Code. Usan subversion (lo usamos en el trabajo y va muy, pero que muy bien) y crear un proyecto es muy rápido.

Hola, yo también estoy siguiendo el hilo. Hace años que no programo con fluidez así que en la fase de codificación no puedo aportar pero si en algún momento veo o veis que podría colaborar, contar conmigo.

Ah bueno SQL si que domino. No se si es el caso usarlo para este proyecto al menos en esta primera versión pero bueno ahí lo dejo caer.

Iniciado por ManuelLlorens

Hombre, si no sabéis programar no podéis participar de esa fase, pero sí de la de diseño, en la que estamos ahora, y como tú dices en la de pruebas.

Podéis mirar las maquetas y la funcionalidad que vamos definiendo y decir si os parece que es lo que necesitáis.

Un saludo:

En cuanto a la funcionalidad, me parece muy bueno lo que estoy viendo. Por lo menos la parte que entiendo.
Seguirá avidamente el hilo.
Por cierto, en cuanto al nombre, no soy yo quién para darle nombre a un hijo vuestro , pero creo que sería mejor un nombre en inglés pero que se entendiera en spanish para que tenga mayor difusion. PerfectRaw se entiende perfectamente en ambos idiomas. Pero es sólo una opinión.

Un saludo.

Álex.

Enhorabuena por la currada que os estáis dando, sigo con atención éste y casi todos los hilos de _GUI_, me parecen cojonudos, aunque a decir verdad entienda la mitad de la mitad, por supuesto de programación ni pajolera idea pero bueno si os puedo ayudar en alguna prueba o en algo que esté a mi nivel os echaré un capote.

Los resultados que se adivinan son estupendos pero ... será fácil hacerse con él?.

_GUI_, me alegro que hayas encontrados compinches y de los buenos para tus proyectos. Si hay un Efraimweb también se podría crear un _GUI_´s corner and Co. y agrupar todo lo que debatís para tenerlo a mano.

Ánimo .......

De momento voy a concentrar todos mis esfuerzos en terminar la DLL de DCRAW con todo lo que vamos a necesitar. La DLL es compatible 100% con unix, espero. De momento compilo con MinGW pero tengo intención de pasar a cygwin lo antes posible. DJGPP queda descartado porque sus librerías no corren en Vista (al menos sin SP1). ¿Alguien me puede confirmar si desde unix con Mono C# se puede llamar a una DLL (o como se llamen las librerías dinámicas en unix) compilada con gcc sobre unix? Supongo que sí, aunque haya que adaptar algo, ¿no? En caso contrario en unix se compilaría como una librería estática y listos.
El GUI de momento se va a desarrollar con C# sobre VS2005 utilizando GDI+, que ES COMPATIBLE con GDK# y por tanto correrá en unix. Evitaremos usar .NET 2.0, porque no es 100% compatible con Mono, aunque Mono acabará actualizándose y tampoco habría problemas. En el futuro se portará a OpenGL y seguirá siendo compatible con unix.

La comunicación con el SDK de DNG de momento irá en C++, pero me gustaría que utilizáramos lo mínimo imprescindible y que compilara en unix, eso lo dejamos para los que controláis (y os gusta) C++ más que a mí, que no me gusta. Esa parte es para más adelante y sobre todo para el perfectBlend, o como se llame en el futuro.

Sé que puede haber opciones mejores, pero si nos complicamos con otra cosas no sale nada. Prefiero tener algo funcionando en Win32 y capaz de correr en unix si alguien lo adapta que no tener nada.

Una vez tengamos algo funcionando en estas plataformas de desarrollo el código estará a vuestra disposición para probar y portar a Win64, unix y demás.

Todas vuestras aportaciones son buenas y quedan registradas aquí en el foro. Se tendrán en cuenta cuando llegue el momento, pero insisto en que de momento el entorno de trabajo está definido y que ya estamos avanzando con él, que es compatible con unix y Win64 aunque requiera un pequeño esfuerzo (en teoría ninguno).

También aclaro que la DLL es _muy_ cutre. No soporta multitarea. El programa será lento, no esperéis un Lightroom para unix, no es esa la idea. Copio el párrafo de _GUI_ que mejor sintetiza la idea detrás de esta aplicación:

Hay que volver a pensar además en el concepto de lo que pretendemos: no es un revelador al uso, lleno de sliders en tiempo real para que el usuario toque aquí y allá sin orden ni concierto, es un revelador de precisión donde vamos a estar dispuesto a tener un pequeño retardo mayor en las operaciones porque no se trata de ir probando al tuntún, sino de ir eligiendo los parámetros de manera pausada para llegar al mejor resultado posible.

Un saludo:

@Razov:
El uso de procesos sería equivalente a utilizar un ejecutable externo, pero entonces se pierde el acceso a las variables y buffers de imágenes, etc, debiendo hacerse la comunicación a través de stdin, stdout o ficheros.

Eso resulta muchísimo más lento y consume más memoria, pues hay que serializar todos los bitmaps, para luego volver a leerlos.