Tema: Recuperación altas luces distintos reveladores RAW

Sin tocar nada más que los ajustes necesarios para recuperar las luces en el panel básico (parecido a lo que habéis hecho en DCRAW). He marcado la zona donde más diferencias hay. Se consigue algo más de información de color tocando el balance de blancos y con curvas específicas, pero lleva más curro .

Bueno, yo la he abierto don Camera Raw 4.4.1 y he ajustado lo siguiente:
-Reducido la exposición en -2,27 puntos.
-Aumentado la recuperación de altas luces hasta 70.

Con esto la imagen me quedaba obscura, por tanto he aumentado brillo y reducido contraste:
-Brillo ajustado a +7
-Contraste en +23

Creo que se podrían consguir mejores resultados utilizando las opciones de luz de relleno en vez de aumentar brillo y reducir contraste.
Pero esto equivaldría a andar con las curvas, por lo que quise seguir lo más fielmente posible lo que tú exponías en el post.

Creo que está claro que las nubes las convierte en algo grisáceo. En este caso no quedan del todo mal, pero el DCRaw obtiene unos tonos mejores, a partir del canal azul que no se ha quemado.
Pero los tonos que le quedan salen violáceos, debido a que no tiene información del rojo y el verde (el verde sería el primero en quemarse).
Creo que está claro que DCRaw recupera más información de los canales no quemados. ACR cuando se quema un canal tiende a convertirlo todo en tonos de gris.

¿Es así no?

En este caso concreto no sé cuál de los dos sistemas proporciona un aspecto más natural al cielo. ¿Qué os parece?

Iniciado por ariznaf

Creo que está claro que DCRaw recupera más información de los canales no quemados. ACR cuando se quema un canal tiende a convertirlo todo en tonos de gris.

¿Es así no?

En este caso concreto no sé cuál de los dos sistemas proporciona un aspecto más natural al cielo. ¿Qué os parece?

Yo me quedo sin duda con la de DCRAW: requiere ajuste en esas zonas violáceas para igualarlas al tono original de cielo, pero partes de una imagen mucho más aprovechable. La de ACR habría de pintarse literalmente de color desde cero para obtener algo aprovechable.

Es una foto muy exigente, nada menos que dos canales (el verde y el azul) están quemados en áreas amplísimas.
ACR se limita a recuperar los canales quemados replicando el canal rojo que es el único que no acaba quemado. Éstas son las zonas del RAW donde el canal verde está quemado, coinciden exactamente con las zonas grises de la recuperación de ACR:

En otro foro me confirman que LR y LR beta hacen lo mismo, llevan a gris las zonas quemadas. No creo que tarden en mejorar esto.

Sí, yo tengo instalado el Lightroom Beta 2.0 que sino me equivoco usa el ACR 4.4.1 que es el que he utilizado para hacer el revelado con Photoshop (pues yo no instalé el 4.4.1).

Tienes razón, creo que sería mucho más fácil ajustar el verde de las zonas violáceas del DCRaw.

En este caso particular de la imagen propuesta, a mi me gusta más el cielo del ACR porque imita más el cielo con nubes extensas y parece más natural que el violáceo (aunque en la realidad fuera un cielo azul y con nubes pequeñas u no amplias zonas de nubes de poco espesor).

Está claro que una vez quemado el verde no parece aprovechar la información del rojo.

Recuperación de altas luces de Capture One que me ha pasado un forero, no es la mejor que digamos, no sé si verdaderamente es todo lo que puede sacarse con ese programa, se me hace raro:

Usando el Camera Raw 4, centrándome solo en el cielo y jugando con el balance de blancos (y la corrección selectiva de colores), he conseguido esto:




No entiendo muy bien porque el balance de blancos afecta tanto a la recuperación de las altas luces, quizá Guillermo nos puede iluminar , lo que queda claro es que CR "ve" esas nubes pero con un balance de blancos "normal" no no las deja recuperar....

Saludos!

El resultado es el mejor de todos, lo que hace pensar porqué a los otros usuarios les aparecían las zonas quemadas en tono gris, no lo entiendo. Quizá es algo que decide ACR: para cierto rango de valores de ajuste del balance de blancos trabaja en modo "altas luces neutras", pero para otros ajustes del mismo sí que trata de recuperar tonos. Porqué no lo hace así siempre se me escapa.

El balance de blancos es una corrección de la exposición de los canales, en la mayoría de ocasiones aumenta la exposición de los canales rojo y azul frente al verde, por eso es crucial en todos estos procesos donde entran en juego zonas quemadas. Si se ajusta un balance de blancos sin compensar el aumento de exposición parcial de canales que éste supone con una corrección a la baja de la exposición global, el propio balance de blancos quemará información en los canales sobreexpuestos.

Un ejemplo muy rápido: el balance de blancos de tungsteno de la 350D implica multiplicar los canales por los factores:
R 1.392498
G 1.000000
B 2.375114

Estos factores lineales traducidos a una exposición en diafragmas serían equivalentes a ajustar:
R log2(1.392498) = +0.48 EV
G log2(1.000000) = 0.0 EV
B log2(2.375114) = +1.25 EV

Si aplicado ese balance de blancos dejásemos el control global de exposición del revelador a 0.0EV, estaríamos perdiendo la información que hubiera en el último medio diafragma del canal rojo, y la que hubiera en los 1,25 diafragmas superiores del canal azul. Haciendo un ajuste global por -1.25 EV se compensarían ambos efectos y balancearíamos la imagen sin quemar nada.

Hay que entender esto, que el balance de blancos se logra a través de un ajuste (generalmente al alza) de la exposición, solo que afecta a cada canal en una cantidad diferente.

Gracias por la explicación _GUI_.


Creo que lo que está pasando es que ACR solo recupera altas luces cuando tiene 2 canales con información. Al cambiar el balance de blancos (temperatura y matiz) y alterar los factores de multiplicación de los canales hemos conseguido que dos canales no estén saturados y la recuperación de ACR se ha puesto a trabajar.... si dos canales están saturados lo único que hace es empastarlos.....


Lo malo de esto es que al final la foto queda inservible!!!! Pero con un cielo cojonudo...

Iniciado por dudu307

Creo que lo que está pasando es que ACR solo recupera altas luces cuando tiene 2 canales con información. Al cambiar el balance de blancos (temperatura y matiz) y alterar los factores de multiplicación de los canales hemos conseguido que dos canales no estén saturados y la recuperación de ACR se ha puesto a trabajar.... si dos canales están saturados lo único que hace es empastarlos.....

te garantizo que en ese RAW, el único canal no quemado es el rojo. Tanto el verde como el azul están hechos carbonilla. Bueno al revés, están reventados, totalmente blancos.

Iniciado por _GUI_

te garantizo que en ese RAW, el único canal no quemado es el rojo. Tanto el verde como el azul están hechos carbonilla. Bueno al revés, están reventados, totalmente blancos.

Pues nada, ya me he quedado sin teoría...

Solo me queda recomendar a la gente que trabaje con ACR que cuando quiera recuperar textura de algún detalle quemado juegue con el balance de blancos, de hecho es casi más importante que el propio de "recuperación", y si el color queda raro, pues nada, un poco de photoshop!

Me da la sensación de que lo que ha hecho dudu no es realmente una recuperación de los canales quemados... a ver si me explico.

Creo que lo que ha hecho ha sido ajustar el balance de blancos a una temperatura MUY baja, convirtiendo el canal rojo en azul, y después ajustar el tono de azul para que parezca el del cielo real. Además, me da la sensación de que ha sido con un tratamiento por zona, dejando el barco fuera de esa transformación...

Bueno, es la sensación que me ha dado, y en ese caso no hablaríamos de una recuperación de canales quemados, sino de una "recreación" del color azul, que aquí funciona bien porque el cielo es azul, pero si se tratase de una zona "multicolor" la cosa se complicaría.

dudu, nos puedes dar los valores exactos que has modificado en ACR, y confirmar si el tratamiento está aplicado sólo a una zona o a la imagen completa por igual?

Abrazos.

Edito: me he puesto a probar con LR, y no es necesario hacer nada por zonas, pero el tratamiento que necesito hacer para llegar a ese resultado es el que comentaba, enfriar muchísimo los colores de la imagen, de forma que convierto el gris en azul (lógico), y después arreglar el tono de azul. Pero sigo sin considerarlo una recuperación de nada, simplemente transformo el gris en otro color, al gusto.

A ver GUI, claro que sale ese resultado, pero como dije en el primer post hace falta jugar con el balance de blancos, curvas y corección de color para lograr esto otro:



Me limité en el primer revelado a recrear en ACR lo que querías, según tus propias palabras:

La foto no está procesada, es un revelado neutro con la recuperación de altas luces y el balance de blancos que lleva el propio RAW.
No se trata de obtener la mejor imagen final sino de ver cómo queda el cielo en bruto tras la recuperación de altas luces en cada revelador y un balance de blancos equivalente:

Así que creo que no nos entendimos

Y según eso lo único que obtiene el ACR es esa masa de grises en la zona marcada, resultado claramente inferior a DCRAW.

Un saludo.


EDITO: Acabo de leerte Pegaso y efectivamente ese proceso no es una recuperación de la altas luces. Es exactamente el proceso que he seguido para la imagen en ACR.

Iniciado por Pegaso

Edito: me he puesto a probar con LR, y no es necesario hacer nada por zonas, pero el tratamiento que necesito hacer para llegar a ese resultado es el que comentaba, enfriar muchísimo los colores de la imagen, de forma que convierto el gris en azul (lógico), y después arreglar el tono de azul. Pero sigo sin considerarlo una recuperación de nada, simplemente transformo el gris en otro color, al gusto.

No estoy de acuerdo, si solo hubiéramos "teñido" de azul la masa gris que conseguian antes con ACR tendriamos una masa azul, y no es el caso, aparecen nubes y claros que antes no estaban....

Al modificar la temperatura de color se recupera más texturas que solo reduciendo la exposición, no tiene nada que ver con azular la imagen... lo que no se es por qué!

dudu... esa "masa gris" tiene texturas, porque el canal rojo no estaba cepillado.
Lo que estás haciendo al enfriar los tonos es convertir esas texturas en canal azul, sin más.
Pero lo puedes convertir en el color que quieras (en ese caso necesitarías zonas).

Aquí es más fácil, porque coincide que al enfriar te vas a azul, y los cielos son azules...

Iniciado por Pegaso

dudu... esa "masa gris" tiene texturas, porque el canal rojo no estaba cepillado.
Lo que estás haciendo al enfriar los tonos es convertir esas texturas en canal azul, sin más.
Pero lo puedes convertir en el color que quieras (en ese caso necesitarías zonas).

Aquí es más fácil, porque coincide que al enfriar te vas a azul, y los cielos son azules...

Ok! Ya lo veo.

De todas maneras algo pasa, al cambiar el balance de blancos aumenta la separación de tonos en la masa gris recuperada y es más fácil reproducir el cielo, aunque en realidad no sea una recuperación "real".

Y otra cosa, si solo hay un canal con información, tanto dcraw como CR no tienen ni idea del color original, no?

Así que no es conceptualmente más "correcto" dejarlo gris como hace CR que no "teñirlo" como hace dcRAW, o como hice yo con el balance de blancos? Después de todo en realidad el cielo podría haber sido naranja, no?

Saludos!

OK, ya veo entonces que no es una recuperación del color.

He probado con Aperture, parece que recupera un poco más que ACR y menos que DCRAW.

Está vez pa no liarla, no he tocado balance de blancos, solo exposición y recuperación, incluyo los controles en la captura.

Iniciado por dudu307

Y otra cosa, si solo hay un canal con información, tanto dcraw como CR no tienen ni idea del color original, no?

En cuanto se quema un canal, es imposible que el programa sepa el color exacto que tenía la escena. Si se queman dos como en este caso, pues peor todavía. Si se queman los tres, no se puede sacar nada más que gris, y planito

Sin embargo, mientras exista un solo canal con información (si son dos, mejor) se puede "deducir" la gama de colores dentro de la que estaba la escena.

Por ejemplo, en esta foto, el cielo no podría ser naranja como dices. Si fuese naranja, el canal rojo se habría quemado antes que el azul, y sin embargo el rojo es justo el que no se quemó...

Cualquier programa "inteligente" podría deducir de ese dato que el color original de la escena debía moverse entre tonos azules y verdes, o al menos dominancia de esos tonos sobre el rojo.
En ese aspecto dcraw tampoco se comporta como debería, ya que le da una cierta dominante roja al cielo, volviéndolo casi violeta (pero por lo menos lo intenta).

Así que no es conceptualmente más "correcto" dejarlo gris como hace CR que no "teñirlo" como hace dcRAW, o como hice yo con el balance de blancos?

No lo creo.
Aunque no se sepa el tono "real" de la escena, mientras uno de los canales tenga información, lo óptimo para mí sería que "rellene" justo con los colores que están quemados.
Por una sencilla razón: para hacer corrección de color necesitas que exista color. Si no hay color (gris) la única forma de conseguir variaciones de colores es inventártelos (pintar) o cambiar el balance de blancos de toda la escena para desnivelar los canales y que aparezca una dominante en el gris.

Me parece mejor opción modificar un color "inventado" a partir de los que se sabe que se ha quemado y lo que no se ha quemado, que tener que sacarlo "de la nada" (del gris).

Abrazos.

Según GUI:

Estos factores lineales traducidos a una exposición en diafragmas serían equivalentes a ajustar:
R log2(1.392498) = +0.48 EV
G log2(1.000000) = 0.0 EV
B log2(2.375114) = +1.25 EV

Y digo yo, ¿en vez de aumentar en esos valores el rojo y azul, no se tendría el mismo efecto con los siguientes?
R= -0,77EV
G= -1.25EV
B=0.0EV

Con eso se mantendría la relación entre los canales (y por consiguiente el balance de blanco) y no se quemaría ningún canal.
Claro que entonces nos quedarían negras las zonas muy oscuras, pero recuperaríamos mejor las luces sin quemar nada.
En la mayor parte de las ocasiones creo que daría mejor resultado, pues convertiríamos en negro zonas muy oscuras en las que normalmente (debido al ruido) tampoco tendríamos mucha confianza en su verdadero color.

En cualquier caso sería buena cosa que se diera la opción de hacer el balance dando prioridad a las altas luces o a las sombras.

Por otra parte, también se me ocurre (y es una elucubración, puesto que no tengo muy claro cómo va lo de la recuperación de las altas luces) que la recuperación de altas luces debería de ser aplicada por el revelador antes de hacer el balance de blancos, ¿no? así se tendría los valores interpolados de los canales realmente perdidos antes de perder la información del canal o canales que se queman al hacer el balance.

¿Cómo podría probar esto con el ACR o el DCRaw?

Iniciado por ariznaf

Por otra parte, también se me ocurre (y es una elucubración, puesto que no tengo muy claro cómo va lo de la recuperación de las altas luces) que la recuperación de altas luces debería de ser aplicada por el revelador antes de hacer el balance de blancos, ¿no? así se tendría los valores interpolados de los canales realmente perdidos antes de perder la información del canal o canales que se queman al hacer el balance.

¿Cómo podría probar esto con el ACR o el DCRaw?

No te líes, ariznaf

En el revelador raw, da exactamente igual que apliques primero el balance de blancos y después ajustes la exposición, o que lo hagas al revés, o que lo hagas todo a la vez...
Mientras estás trabajando con el raw, en ningún momento pierdes ninguna información, sigue estando toda ahí.
Por tanto, te da igual si te "cepillas" un canal variando el WB del raw. Cuando bajes la exposición, ese canal seguirá teniendo la misma información que tenía

Abrazos.

Iniciado por ariznaf

Y digo yo, ¿en vez de aumentar en esos valores el rojo y azul, no se tendría el mismo efecto con los siguientes?
R= -0,77EV
G= -1.25EV
B=0.0EV

(...)

¿Cómo podría probar esto con el ACR o el DCRaw?

Es que hacer:
R = +0.48 EV
G = 0.0 EV
B = +1.25 EV

más un ajuste de exp. global de -1.25 EV es lo mismito que hacer:

R = -0,77 EV
G = -1.25 EV
B = 0.0 EV

Unir ambos efectos matemáticamente es trivial, son factores que se multiplican y ya está, y estoy convencido de que los reveladores lo primero que hacen es juntarlos.
El problema es que utilizar multiplicadores menores de 1 sin más, si bien es lo que nos permite no quemar nada, tiene sus consecuencias, y es que si el RAW tenía zonas parcial o totalmente quemadas se crean tonos magenta en las altas luces por desalineación de canales. Esto se ve muy bien aquí:

y sus histogramas respectivos:

La imagen de la izq. ha sido revelada con el esquema que quema canales (multiplicadores >=1) pero no da problemas de tonos en altas luces (-H 0 en DCRAW) por lo que la lámpara es blanca pura. La de la derecha en cambio ha sido revelada con el esquema que no quema nada que no lo estuviera en el RAW original (multiplicadores <=1), pero crea el cast magenta incorrecto (-H 1 en DCRAW).

Si te fijas en la lámpara de la derecha tiene un tono magenta, y se ve en el histograma porqué: hemos dejado fijo el canal azul y rebajado los canales verde y rojo, en lugar de aumentar los canales rojo y azul dejando fijo el verde como se hizo en la imagen izquierda. Así en la toma de la derecha, las zonas quemadas que en origen estaban R=G=B=255, adquieren al aplicar ese balance de blancos un tono incorrecto.

La solución? lo que hacen todos los reveladores cuando se usa un esquema de presevación de altas luces (DCRAW con -H 2-9 o ACR por defecto siempre que reducimos la exposición): realizar transformaciones no lineales en esas zonas de altas luces para que aquellos píxels donde en origen los 3 canales eran neutros (R=G=B), lo sigan siendo en el resultado.

Las siguientes imágenes no provienen exactamente de ese problema, pero los histogramas son similares a lo que estamos hablando:

Revelado preservando altas luces pero sin preservar el tono original en ellas (-H 1 en DCRAW):

Revelado preservando altas luces y además preservando su tono original (-H 2 en DCRAW):

La segunda imagen no tiene nada quemado que no lo estuviera en la primera, pero DCRAW ha garantizado el tono neutro de las zonas de altas luces.

_________________________________

Iniciado por Pegaso

En el revelador raw, da exactamente igual que apliques primero el balance de blancos y después ajustes la exposición, o que lo hagas al revés, o que lo hagas todo a la vez.

Como comentaba arriba, estoy convencido (nadie me lo ha dicho, puedo equivocarme), que el ajuste de exposición del revelador RAW es simultáneo al balance de blancos. De hecho no hacerlo así sería complicarse la vida.

Gracias, GUI y Pegaso por vuestras explicaciones.

Claro, no se me podía haber ocurrido a mi el primero
Aunque Pegaso, no me refería al orden en que nosotros hacemos los ajustes en ACR u otro revelador, sino al orden en que el revelador los aplicaba internamente: balance + ajuste exposición y luces o ajuste exposición y luces + balance.
Si aplican las dos cosas a la vez, no importa el orden en que lo hagamos.

La explicación sobre el cast magenta ha sido muy clara, GUI. Yo pensé que se podía recuperar (si había algún canal no quemado) a partir de dicho canal, pero veo que no, y que la recuperación del tono al realizar el balance no es trivial.
Nuevamente el DCRaw parece tener opciones potentes al respecto.
Es una pena que no tenga una interface amigable y esté integrado en PS y Lightroom

Para el uso día a día se hace muy pesado utilizarlo, pero evidentemente para imágenes concretas y problemáticas en las que en ACR no de buenos resultados, dispone de opciones muy interesantes.

Por cierto que se me quedó el otro día por comentar que este RAW del cielo quemado en los canales G y B, y no quemado en el canal R, es un ejemplo muy bueno de lo que comentábamos en el super hilo de Fotografía analógica vs digital, de que la saturación parcial es mucho más dañina cuando se hace fotografía en color que cuando se hace fotografía en BN.
El RAW del cielo quemado para hacer una foto en color nos da muchos quebraderos de cabeza porque hemos perdido 2 canales con lo que se hace imposible rescatar el color original del cielo sin artificios y trabajo extra. En cambio si la foto final fuera en BN, nos basta el canal R para tener perfectamente definida la textura del cielo en toda la imagen.

La conclusión es que si hacemos fotografía en BN:

• Tenemos un mayor margen en la exposición: podremos cometer más error o apurar más el derecheo siempre y cuando haya algún canal no quemado que nos proporcione la textura. Esto hace que en fotografía en BN pueda no solo ser posible, sino quizá en ocasiones hasta recomendable, sacrificar deliberadamente algún canal para mejorar el ruido en las sombras.
• De lo anterior se deduce que tendremos un mayor rango dinámico útil en cuanto a latitud del sensor, es decir la cámara es capaz de captar con definición un rango de luminosidades más grande que si estamos hablando de fotografía en color donde esta exigencia se aplica a cada canal individualmente.

En la curva negra de este GIF animado que representa la respuesta del sensor (no tiene nada que ver con la imagen del barco) tendríamos la respuesta útil para el fotógrafo BN, que sobrepasa los 5 diafragmas más allá de la medición del fotómetro (0 EV).
En las curvas RGB tenemos la respuesta útil para el fotógrafo color. Si deseamos preservar todos los tonos de las altas luces el primer canal que se quema (el G en este caso) es el que nos limita, y habría impuesto un rango dinámico por encima de la medición del fotómetro de menos de 4 diafragmas.
Es decir el fotógrafo BN gana en este ejemplo aprox. 1,5 diafragmas de rango dinámico en las altas luces útiles respecto al fotógrafo color, para una misma exposición y por lo tanto definición en las sombras.

Fig. 5 Curva de respuesta en luminosidad de sensor digital. Ejes Log-Gamma.

Creo que es la primera vez que se habla en el foro de diferentes formas de abordar la captura en función de si el objetivo en mente va a ser fotografía en BN o en color, y me parece algo de bastante interés sobre todo para los que hacen exclusivamente fotografía en BN.

Bueno, la verdad es que la imagen es todo un reto...y me tarde 45 minutos intentando recuperar la informacion del unico canal que conservaba detalles del cielo. Lo cierto es que no fue facil pero quedé convencido de que el ACR y en general todos los reveladores raw tienen que mejorar, porque sin duda hay muchos detalles de la imagen que se pierden.
En fin, para resumir, concentre mi esfuerzo no solo en el balance de blanco sino en la calibracion de camara y fue en este ultimo apartado donde mas logre recueprar.

Saludos

Retomando esta imagen para unas historias, no me ha costado nada igualar el tono de la zona magenta que generó DCRAW -H 7 con una simple curva con máscara de capa que subiera un poco el canal G en la zona:

_________________________________
Y un ejemplo más de recuperación de altas luces en DCRAW. A la izquierda el acabado neutro -H 2 (más o menos lo que lograríamos con ACR). A la derecha con recuperación de color a tope -H 9.
No lleva nada de postproceso solo un punto de saturación:

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.

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

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

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

Si quieres contestar algo relacionado con el desarrollo del revelador RAW para DCRaw, no lo hagas en este hilo, ese tema fue movido a: Desarrollo de un GUI (Interface Gráfica) para DCRAW

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

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

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

Iniciado 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".

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

Iniciado 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#.

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

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

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

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.

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.

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

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

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

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

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: