Tema: Ajuste de niveles

Uso DCRAW (como no, inducido por _GUI_) y lo hago mediante un script que he desarrollado en 4NT (vamos un batch un poco mas currado) para convertir todos mis NEF según acabo de descargarlos a JPG. A continuación, con las fotos que valen la pena, tomo de decisión de si vuelvo a empezar sobre el NEF con Capture NX o tomo como base ese JPG y sigo con Photoshop. Tanto en un caso como en otro, lo primero que hago es un ajuste de niveles, funcionalidad de echo muchísimo de menos en DCRAW, ya que es casi lo único que hago al 90% de las fotos. ¿Habeis valorado la posibilidad de incluir un ajuste de niveles automático en PerfectRaw?

Aún hago otro apunte. A mi me gustan los entornos de ventanas, pero para los trabajos rutinarios creo que la linea de comandos aporta muchas ventajas. ¿Teneis en mente que PerfectRaw pueda funcionar desde línea de comandos?

Se baraja la posibilidad de añadirle curvas, pero hay que pensar sobre esto. De momento estamos peleándonos sobre si va a ser para Windows, para Linux, para Mac, para todos o para ninguno.

Iniciado por _GUI_

Se baraja la posibilidad de añadirle curvas, pero hay que pensar sobre esto. De momento estamos peleándonos sobre si va a ser para Windows, para Linux, para Mac, para todos o para ninguno.

Un saludo:

He hecho unas cuantas simulaciones con ACR para ver qué hacen exactamente sus herramientas de:

• Exposición: corrige la exposición (escalado en lineal por la potencia de 2 correspondiente) + preserva altas luces si la corrección es a la baja (si es al alza satura niveles). La preservación en PR se puede desactivar y además funciona tanto al aumentar como el reducir la exposición.
• Brillo: es una curva tipo gamma, pero lineal en el primer tramo (o sea equivalente a un ajuste de exposición en él). La parte final tipo gamma preserva altas luces.
• Contraste: curva de contraste típica, pasando por (128,128).
• Sombras: un recorte del punto negro. No vale la pena meter esto.

Las funciones que nos faltan (todas menos la de exposición) son triviales de fusilar. Las pongo aquí para cuando surja el tema no reinventar la rueda ni perdernos haciendo pruebas interminables:

Cerca del origen ACR hace un sospechoso ajuste. He usado en todo momendo Adobe RGB que usa una gamma pura, así que me da que ACR hace "trampillas" en las sombras para mejorar el resultado final.

Como el ajuste de exposición ya lo tenemos, para comparar he replicado con PR un ajuste de exposición a la baja de -3EV en ACR:

Salu2

Pues las diferencias son más que notables, sí señor.

Buen trabajo. Gracias por compartirlo.

Un saludo.

Iniciado por Guillermo Luijk

• Sombras: un recorte del punto negro. No vale la pena meter esto.

Un poco tarde, ese ajuste ya está metido . Solo tienes que subir el black point.

Buen trabajo de análisis, aquí queda como documentación.

Un saludo:

Iniciado por ManuelLlorens

Un poco tarde, ese ajuste ya está metido . Solo tienes que subir el black point.

Sí pero no El punto negro aparentemente logrará lo buscado, pero por otro lado hará que los datos que tenemos de la imagen dejen de ser lineales.

Eso quiere decir que todo proceso que se base en la linealidad de la imagen se hará de manera errónea, más cuanto más desplacemos el punto negro del correcto. Y esto incluye el propio balance de blancos, demosaicing, cualquier técnica reductora de ruido que se base en una distribución simétrica (gaussiana) del mismo, los ajustes de exposición (que provocarán cambios en la proporción RGB de cada píxel, o sea de su color), etc...

Todo eso debe hacerse antes del ajuste de punto negro. El pipeline sería:

Revelado (como está ahora mismo en DCRAW) -> ajuste de exposición -> ajuste de punto negro -> brillo, contraste,...

En cambio el punto de saturación (-S), usado con cuidado y sabiendo muy bien qué se hace, sí que puede usarse como ajuste del punto blanco sin alterar la corrección de los resultados. Hasta sirve como ajuste de la exposición en DCRAW, si bien nunca fue ese su cometido con lo que en realidad es un poco chapuza usarlo con ese fin.

Por supuesto, maestro. ¿Quiere eso decir que el actual ajuste exposición está mal donde está (después de la interpolación)? ¿Hacemos por tanto el cambio propuesto por Emil a ver qué sale? En principio creo recordar que tal como está, tal vez con un mínimo cambio en el código, puede cambiarse de sitio sin problema.

La única pena es que cada vez que se cambie la exposición habrá que volver a interpolar. Cada vez será más lento el uso de la aplicación (de hecho ya he tenido que mover cosas hacia atrás como el EECI, minmax, etc. Además, desde que arreglé lo de las aberraciones cromáticas, si cambias de un método de interpolación RGB a uno RGGB vuelves hasta el paso 2 en vez de el 3, pero no queda más remedio que hacerlo así). Cuando migremos todo a la GPU la cosa cambiará sustancialmente, eso sí. Estoy seguro de que la implementación de Paul de AFD puede ejecutarse en tiempo real en la GPU sin problema.

Un saludo:

No no, el ajuste de exposición no rompe la linealidad de la imagen, por eso es el primer ajuste que ha de hacerse tras el revelado; le veo más pegas hacerlo antes de interpolar que después, por el tema de preservar las altas luces.
Si te fijas la misma curva de ajuste de punto negro, que intuyo que es lo primero que aplica ACR tras revelar y ajustar la exposición, es prácticamente una curva y=x que superado ese tramo inicial de sombras donde actúa preserva la linealidad.

Lo que decía Emil es la gamma antes de interpolar, pero yo no entiendo como puede decir que aplicar la gamma antes de interpolar puede ser conveniente, si precisamente la gamma se carga la linealidad de los datos.

He repetido las gráficas, ahora se ven más chulas:


En LL dicen que ese tramo inicial donde las curvas hacen un extraño puede deberse a la limitación de pendiente máxima impuesta en la gamma de AdobeRGB por el motor de conversión de color. En cualquier caso no veo la necesidad pero bueno.

Gracias por el documento, Guillermo, muy instructivo. Sólo paso por aquí para apuntar que UFRaw, de código abierto y basado en dcraw, tiene curvas para la exposición y la saturación. Podéis probar estas cosas aprovechando su código en plan provisional.