Tema: Solicitar funcionalidad nueva

(Por ariznaf)
He cerrado este hilo. A partir de ahora, para solicitar nueva funcionalidad o debatir sobre mejoras en el programa que no haya sido debatido con anterioridad, abre un nuevo hilo en el foro Solicitudes de mejora y nueva funcionalidad.
Ello nos permitirá hacer un mejor seguimiento de los distintos temas, en vez de tenerlo todo mezclado en un único hilo.

En este tema acumularemos funciones que se nos ocurran para futuras versiones e ideas en general sobre perfectRAW y perfectBLEND que no estén relacionadas con el código que está en marcha en ese momento.

De momento tenemos para versiones superiores a la 1.0 de perfectRAW:

• El modo BN definido por _GUI_.
• Que actualice los thumbnails incluidos en los archivos RAW.
• Que actualice los DNGs con los thumbnails y los parámetros de revelado.
• Que compile en Unix/MacOS.
• Cambiar el interfaz por OpenGL.

Para la versión 1.0 de perfectBLEND solo hemos pensado, de momento, la funcionalidad básica.

Un saludo:

Antes de nada, felicitar vuestra iniciativa y proyecto, y desearos satisfacciones y éxito en la empresa.

Yo uso DCRAW desde que -como a muchos les ha ocurrido- _Gui_ me lo hizo descubrir. Yo, casi exclusivamente, fotografío pensando en blanco y negro, fruto de mis orígenes argénticos, cuando el blanco y negro era la única opción de sentirse libre en cuanto al control total de la copia. En DCRAW encontré un revelador nada intuitivo, austero y profundamente simple, en el que (igual que revelando haluros de plata) nada ocurría si tú no lo buscabas, en definitiva: control total y simplicidad.

Respecto a cualquier idea que pueda tener _Gui_ para el futuro modo b/n de PerfectRaw, me gustaría añadir un concepto que no he sabido encontrar en ningún revelador (tampoco en DCRAW, claro). El hecho mismo de que virtualmente no aparezca el menor rastro de color en la toma que presumimos sería en blanco y negro. Que gracias a que en mi cámara tengo un modo b/n, que el revelador no disipe ese "engaño" que me hacía creer que yo estuve disparando con un carrete de blanco y negro... más que una funcionalidad nueva, yo propongo una sutileza que sin embargo para mí es bastante importante, y que gracias a ella haría de PerfectRaw (sin ninguna duda) mi revelador habitual e insustituible.


Gracias por vuestro valioso tiempo.

P.S. Añado que, me gusta mucho el diseño sobre el que empezáis a trabajar... muy en la línea de las virtudes de DCRAW, muy coherente sí señor.

Quieres decir que pueda arrancarse la aplicación en modo BN y en ningún momento se llegue a mostrar la imagen en color, ¿no?

Supongo que se podría crear un perfectB&W tal cual.

Un saludo:

Iniciado por ManuelLlorens

Quieres decir que pueda arrancarse la aplicación en modo BN y en ningún momento se llegue a mostrar la imagen en color, ¿no?

Supongo que se podría crear un perfectB&W tal cual.

Un saludo:

Exactamente.

Si creéis que tendría "salida" una versión íntegramente en b/n, pues sería definitivamente genial. Aunque yo me conformaría con la posibilidad de que PerfectRAW pudiera configurarse para arrancar en el último modo (color/b&w) utilizado.

Saludos.

Nadie en concreto, comparto esa visión simple y pura de los procesos a la que como yo, parece te has acercado con DCRAW. Soy de la opinión de que si entre tanto bit y byte es todavía posible algo de romanticismo en el revelado digital, es precisamente embarcarse en revelar nuestros RAWs con un control total, de manera tan artesanal y precisa como sea posible, y eso solo lo he encontrado en DCRAW ya que en cualquier otro programa no tengo la misma certeza de saber lo que se le está haciendo a mi imagen.

Comparto además tu visión de una cámara exclusiva para obtener fotografías en BN. El sensor, ya no necesitado de obtener la terna RGB, tendría una mejor definición (sería en esencia un Foveon de BN) o como propuse en esta paja mental emulando el Fuji Super CCD, a costa de perder un poco de calidad por introducir interpolación (no tanta como un Bayer no obstante), dispondría de un gran rango dinámico.
La mezcla idonea de canales, o más bien habría que decir de longitudes de onda, se habría de obtener a la antigua usanza, con filtros de color colocados delante de la lente, idea que me parece más romántica aún si cabe.

Sin embargo, y dado que nuestros sensores son Bayer RGB, y eso hoy por hoy no lo podemos cambiar, me parece que tu planteamiento no es óptimo pues desperdicia la única ventaja que tiene un sensor Bayer en la formación de una imagen BN frente a un sensor BN puro: permitir al usuario elegir la mezcla idónea de los mismos en la composición de la luminosidad final, que no es sino elegir la mezcla de la parte del espectro luminoso que va a formar tu imagen.
Aprovechar este hecho es una de las ideas que tenía en mente precisamente para un hipotético módulo BN (sería la tercera opción):

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.

Posiblemente no podrá competir con los mezcladores de BN que están llevando los últimos reveladores RAW, pero es una cuestión de concepto en relación con lo que comentaba al principio: si uso mi propia rutina de mezcla en BN sabré el cómo y el porqué de mis BN. Si uso el mezclador de otro programa, el resultado podrá ser mejor pero su origen será un misterio para mí.


Además, incluso en edición de fotografia en BN puede ser útil disponer de una réplica en color (se colocaría en otra capa) para identificar elementos por su color, por ejemplo para hacer selecciones en la imagen por gama de color.

Un saludo.

Iniciado por _GUI_

Nadie en concreto, comparto esa visión simple y pura de los procesos a la que como yo, parece te has acercado con DCRAW. Soy de la opinión de que si entre tanto bit y byte es todavía posible algo de romanticismo en el revelado digital, es precisamente embarcarse en revelar nuestros RAWs con un control total, de manera tan artesanal y precisa como sea posible, y eso solo lo he encontrado en DCRAW ya que en cualquier otro programa no tengo la misma certeza de saber lo que se le está haciendo a mi imagen.

Comparto además tu visión de una cámara exclusiva para obtener fotografías en BN. El sensor, ya no necesitado de obtener la terna RGB, tendría una mejor definición (sería en esencia un Foveon de BN) o como propuse en esta paja mental emulando el Fuji Super CCD, a costa de perder un poco de calidad por introducir interpolación (no tanta como un Bayer no obstante), dispondría de un gran rango dinámico.
La mezcla idonea de canales, o más bien habría que decir de longitudes de onda, se habría de obtener a la antigua usanza, con filtros de color colocados delante de la lente, idea que me parece más romántica aún si cabe.

Sin embargo, y dado que nuestros sensores son Bayer RGB, y eso hoy por hoy no lo podemos cambiar, me parece que tu planteamiento no es óptimo pues desperdicia la única ventaja que tiene un sensor Bayer en la formación de una imagen BN frente a un sensor BN puro: permitir al usuario elegir la mezcla idónea de los mismos en la composición de la luminosidad final, que no es sino elegir la mezcla de la parte del espectro luminoso que va a formar tu imagen.
Aprovechar este hecho es una de las ideas que tenía en mente precisamente para un hipotético módulo BN (sería la tercera opción):

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.

Posiblemente no podrá competir con los mezcladores de BN que están llevando los últimos reveladores RAW, pero es una cuestión de concepto en relación con lo que comentaba al principio: si uso mi propia rutina de mezcla en BN sabré el cómo y el porqué de mis BN. Si uso el mezclador de otro programa, el resultado podrá ser mejor pero su origen será un misterio para mí.


Además, incluso en edición de fotografia en BN puede ser útil disponer de una réplica en color (se colocaría en otra capa) para identificar elementos por su color, por ejemplo para hacer selecciones en la imagen por gama de color.

Un saludo.

Es verdad, un sensor foveon de blanco y negro y sacarles polvo a los filtros de color sería apartar definitivamente todas las mentiras piadosas a que nos obliga lo digital (a los argénticos, claro).

Tienes razón, es necesario llevarnos al photoshop (o similar) un .tiff RGB para conseguir trabajarnos el b/n por canales y sacarle todo el partido. De hecho, por mi forma particular de trabajo, un mezclador de canales no me sirve y necesito trabajar canal por canal (opacidades, curvas, máscaras, etcétera). Me leí con atención lo que propusiste acerca de revelar para blanco y negro, y desde entonces lo sigo... cabe decir que al ver la fotografía con esa dominante verde tan acusada, resulta menos molesto en el sentido de seguir con el b/n imaginado.

Como dices, es una cuestión más romántica que pragmática, y he de rendirme un poco al pragmatismo. Me parece una buena garantía que ese modo b/n lo diseñes conceptualmente tú, por tu claridad de conceptos, en los que además coincido.

Os sigo.

Un saludo.

Yo también tengo mi petición.
Pensar cómo podemos hacer un sistema de plugins.
Supongo que no seria muy dificil pasar a una función la imagen, que esta la transforme y la devuelva para mostrarla otra vez.
Me imagino un plugin para mejorar la reducción de ruido, otro de sharpening, ...

Los plugins a veces son utiles para probar funciones sin tener que tocar nada de la aplicación.

Iniciado por vertex

Pensar cómo podemos hacer un sistema de plugins.
Supongo que no seria muy dificil pasar a una función la imagen, que esta la transforme y la devuelva para mostrarla otra vez.

Sí, es una buena idea. Veo más complejo el tema de la visualización de los controles del plugin, pero si se hiciera en ventana aparte no habría problema. Sería cuestión de meter una carpeta plugins. Por dentro tienen que ser DLLs, aunque se pueden renombrar como queramos.

No tengo claro cómo cargar en C# una DLL en tiempo de ejecución sin haberla definido antes, aunque seguro que con refactorización y/o código dinámico puede hacerse (de hecho alguien lo habrá hecho antes que nosotros).

Luego habría que definir una estructura interna homogénea para todos los plugins. Nombre de la función de entrada al plugin, buffers de entrada y salida. Además, el plugin debería devolver los parámetros para incluirlos en los parámetros de revelado. Si luego se intentara revelar en otro máquina sin el plugin puede dar un aviso y revelar si el plugin sin problemas.

Lo que no tengo claro es si merece desarrollar plugins de ruido, enfoque, etc. cuando PS ya tiene plugins que hacen eso mejor de lo que podamos hacerlo nosotros... pero se puede pensar en ello. Yo personalmente uso corrección de lente con PTLens, ruido con NeatImage y enfoque con una versión modificada por mí de dSRL Fractal Sharpen (para que funcione con la versión 5 de Genuine Fractals), sin duda alguna el enfocador más preciso y lento del mercado . Ninguno de ellos podríamos usarlo desde perfectRAW, así que no me resultaría tan interesante.

Otra opción que he comentado en un foro es crear nosotros nuestra propia versión de PS, pero a 32 bits lineal. No con toda la funcionalidad, claro, solo con los ajustes globales de la imagen: exposición, ajuste de curvas, saturación (por canales), reservas y quemados con máscaras de capa, etc.

Una vez hechos esos ajustes lineales se pasa a PS para los últimos retoques, que no modifican el histograma y por tanto no pierden tanta calidad si se hacen a 16 bits en vez de 32 bits: ruido, quitar defectos, enfocar, distorsión de lente (bueno este molaría hacerlo en 32 bits, se puede hablar con el autor de PTLens que podría estar interesado), etc. De ese modo tenemos lo mejor de los dos mundos. Yo creo que me pondré a ello después de perfectBLEND 1.0, espero que unos cuantos más os subáis al carro. Si cojemos soltura trabajando juntos en perfectRAW y perfectBLEND y hemos solucionado ya muchos problemas técnicos, cuyas soluciones reutilizaremos, creo que podemos hacerlo sin demasiadas complicaciones. Además, mientras _GUI_ siga dirigiéndonos en la dirección correcta, tenemos la obligación moral de tener un workflow de revelado teórica y conceptualmente perfecto. Ese es mi objetivo, ir haciendo realidad todas las teorías de _GUI_ de modo que en cada etapa del revelado tengamos algo conceptualmente perfecto, de ahí el nombre de los productos (si te fijas, en la lista de nombres que puse perfectRAW fue el primero, aunque a mí me sonaba mejor otro, era el primero que venía a la cabeza pensando en lo queremos hacer).

Un saludo:

No tengo claro cómo cargar en C# una DLL en tiempo de ejecución sin haberla definido antes, aunque seguro que con refactorización y/o código dinámico puede hacerse (de hecho alguien lo habrá hecho antes que nosotros).

Sí, es posible, hay funciones para cargar la DLL.
Utilizando Reflection se puede llamar a cualquier función de la librería, y si el nombre y parámetros de la función y/o clase son conocidos de antemano, era incluso más sencillo.

No me acuerdo muy bien en este momento, pero no tenía demasiada complejidad.
Una vez hechas un par de llamadas y cardada la DLL, se accedía a ella de manera transparente, como si se hubiese lincado estáticamente (de forma similar al DLLImport).

De todas formas creo que eso debería de ir para la versión 1.1. De momento tengamos el revelador funcionando que es lo prioritario. Añadir lo de los plugins para exponer los métodos y clases internas del revelador a una DLL cargada no debería de ser muy complicado. Sólo habría que definir una función de inicialización al que pasarle la estructura de datos de DCRAW (parámetros de revelado, buffer de la imagen, etc).
A partir de ahí la dll podría hacer lo que le parezca.

Iniciado por ariznaf

Sí, es posible, hay funciones para cargar la DLL.
Utilizando Reflection se puede llamar a cualquier función de la librería, y si el nombre y parámetros de la función y/o clase son conocidos de antemano, era incluso más sencillo.

Mola .

Iniciado por ariznaf

De todas formas creo que eso debería de ir para la versión 1.1. De momento tengamos el revelador funcionando que es lo prioritario.

Sí, claro. Este es el foro para funcionalidad nueva. Es bueno que en algún sitio vayamos recogiendo ideas que NO vayamos a implementar de momento.

Un saludo:

Sobre los plugins, un buen asunto seria invocarlos con el mismo protocolo que hace el PS así cualquier plugin que admitiera 16bits funcionaría (seria genial poder llamar al PTLens desde el rawelador). De hecho muchos programas de edición de imagen ya lo hacen por ejemplo lo de Corel que lo probé hace poco.

El protocolo no es horriblemente complicado. Habria que analizarlo todo para ver que partes no son necesarias....

UY Truji, la idea me parece magnífica, pero la implementación no me suena tan sencilla como tú lo planteas.

Lo difícil me imagino que será preparar la imagen almacenada en memoria con las estructuras de PS para pasárselo a el plugin, pero no hay imposibles (y en informática menos )

Desde luego habrá que probarlo cuando nos pongamos con lo de los plugins.

De hecho (con permiso de GUI y Manuel que sé que son algo puristas y esto no les va a gustar mucho ) yo, una vez que tuviéramos una versión lo suficientemente funcional del programa, ya pensaba crear una versión que funcionara como plugin de Photoshop (y si es posible de Lightroom, que creo que están poniéndole una interface de plugins y me imagino que será similar a la de PS) para que funcione similar al ACR.

Esto permitiría sustituir completamente al ACR en el flujo de trabajo a aquéllos que trabajamos todo con Lightroom o PS (no sería nada cómodo tener que andar saliendo a un programa externo para revelar cada foto y además no me gusta nada tener que crear archivos tiff intermedios).

Lo que tú propones viene a ser lo contrario: llamar a plugins de PS desde la aplicación, pero una vez creada una versión de PerfectRaw como plugin de PS me permitirá conocer bien cómo funcionan los plugins y seguramente no sea muy complicado lo contrario.

Yo empezaría por aquí.

Iniciado por ariznaf

UY Truji, la idea me parece magnífica, pero la implementación no me suena tan sencilla como tú lo planteas.

Lo difícil me imagino que será preparar la imagen almacenada en memoria con las estructuras de PS para pasárselo a el plugin, pero no hay imposibles (y en informática menos )

Desde luego habrá que probarlo cuando nos pongamos con lo de los plugins.

De hecho (con permiso de GUI y Manuel que sé que son algo puristas y esto no les va a gustar mucho ) yo, una vez que tuviéramos una versión lo suficientemente funcional del programa, ya pensaba crear una versión que funcionara como plugin de Photoshop (y si es posible de Lightroom, que creo que están poniéndole una interface de plugins y me imagino que será similar a la de PS) para que funcione similar al ACR.

Esto permitiría sustituir completamente al ACR en el flujo de trabajo a aquéllos que trabajamos todo con Lightroom o PS (no sería nada cómodo tener que andar saliendo a un programa externo para revelar cada foto y además no me gusta nada tener que crear archivos tiff intermedios).

Lo que tú propones viene a ser lo contrario: llamar a plugins de PS desde la aplicación, pero una vez creada una versión de PerfectRaw como plugin de PS me permitirá conocer bien cómo funcionan los plugins y seguramente no sea muy complicado lo contrario.

Desde luego que estas cosas son como meterse en un pantano de los de las películas que no sabes ni cuando ni como vas a salir pero para espiritus aventureros no hay barreras :-)

Me huele que programar el host debe ser igual de facil o igual de complicado que programar un plugin

Yo he programado uno (de plugin), bueno el 90% ya solo me falta el otro 90% jeje pero le he visto las tripas a la cosa, al menos en el lado del plugin y es cosa de ponerse, tiempo, concentración y paciencia.

La buena es pillar el SDK de Adobe, hay que hacer una solicitud pero en su tiempo la hize rellenando cuatro datos y sin mas preguntas me mandaron la autorización. No se si implementando el protocolo como host (no como plugin) pueda tener otras implicaciones en plan legalista pero creo que toda la información está ahi. En el mismo SDK ya te vienen proyectos de muestra que pueden ir la mar de bien para probar debugando.

Lo del host, técnicamente creo que seria cosa de:

- Inicializar el plugin (es una dll) con todos sus lios de saludos y protocolos y verificar las respuestas. también hay que leer recursos incrustados en la dll como nombre, capacidades y tal (de eso no tengo ni idea pero probablemente deben ser resources en Windows)
- Proporcionar un sistema de gestión de memoria (PS ofrece al plugin los equivalentes al malloc y free y los new y delete operators para que el plugin no se pelee por la memoria con el ps. Es opcional pero me imagino que la mayoría de plugins lo debe usar.
- Pasar la información, la struct no es pequeña pero establecer un único formato de 15bits lo simplificaría creo. Hay muchos campos para hacer cosas sofisticadas pero en este caso creo que con lo minimo tiraria

Lo que la puede liar grandemente es si ha de ser portable a Mac.

Bueno y seguro que me dejo cosas de aquellas que cuando te das cuenta te da un vuelco el corazón pero ahi está la aventura.

Una idea excitante.... en su momento (cuando ya tengamos un revelador bien pulidito y probado) habrá que probar.

En un post de GUI se dice esta inquietante frase acerca de ZeroNoise:

"[...] Cuando Manolo se recupere le propondré hacerlo en forma de plugin.
De todos modos del paso por DCRAW creo que no nos libra nadie. Estoy llegando a la conclusión de que es el único [...]".

No conozco a Manolo, pero parece la respuesta a vuestras plegarias. Sea, quien sea Manolo, espero yo también que se recupere.

Un saludo:

Pues esperemos que se recupere pronto sí...

Espero que lo que voy a decir no sea una estupidez, pero desde luego que es algo mucho más sencillo que las tremendas batallas informáticas en las que andais metidos. Digo yo que sería fácil implementar un "Guardar como... " para poder guardar el resultado de distintos revelados sin tener que andar renombrando o meneando archivos como hay que hacer con DCRaw.

Saludos.

Algo de eso habrá, por supuesto.

Iniciado por ManuelLlorens

Otra opción que he comentado en un foro es crear nosotros nuestra propia versión de PS, pero a 32 bits lineal. No con toda la funcionalidad, claro, solo con los ajustes globales de la imagen: exposición, ajuste de curvas, saturación (por canales), reservas y quemados con máscaras de capa, etc.

Manuel, conoces Cinepaint?, es de código abierto y trabaja a 32 bits seguro, es un fork que salió de Gimp hace unos años y como os veo tan lanzados igual le sacais vosotros un fork al fork de Gimp http://www.cinepaint.org



Saludos