Tema: DCRAW con compensación gamma pura y perfil H-RGB

Una de las virtudes de DCRAW es que es un revelador que puede realizar un revelado lineal, es decir, generar una imagen de salida a la que no ha sido aplicada la compensación gamma. Esto es muy útil para estudiar muchos aspectos del RAW y acometer procesados imposibles o muy complejos en gamma compensada.
Pero al mismo tiempo uno de los defectos de DCRAW es que en 16 bits solo admite dicha salida lineal, sin permitir aplicar compensación gamma aunque en un momento dado lo prefiríeramos.

En la mayoría de ocasiones esto no es problema alguno: PS abre la imagen con una versión lineal del perfil de color elegido que nosotros convertimos al habitual, de modo que PS nos deslinealiza la imagen aplicando la compensación gamma pertinente.

Sin embargo una codificación lineal, si se realiza a 16 bits (enteros) y no a 32 bits (coma flotante), implica una menor riqueza tonal de las sombras y un histograma en definitiva menos robusto en las mismas con menos niveles tonales; la gamma es un seguro ante problemas de cuantización. Entonces por qué no permitir una opción en DCRAW que aplique la gamma antes de redondear los niveles a enteros de 16 bits si es lo que el usuario quiere?

Lo he discutido varias veces con Coffin y no cae del burro, dice que ésa no es una forma legítima de obtener mayor riqueza tonal y la compara con el suavizado del histograma cuando desenfocamos una imagen o añadimos ruido. Pero no estoy en absoluto de acuerdo: si no redondeamos los niveles de la imagen a valores enteros hasta el final, aplicar la gamma antes de dicho redondeo nos da mayor riqueza tonal real y también mayor precisión real en los niveles codificados.


Hace un par de días me contactó un usuario de Oly (Manuel Llorens) que programa en C al que pedí que introdujera en DCRAW una nueva opción -g que permita especificar la compensación gamma a aplicar. Hacerlo es tan simple como "meter la zarpa" en los niveles de la imagen de salida justo antes de realizar el redondeo a enteros de 16 bits (lo marcado en rojo):

Donde en el programa original decía:
FORC3 img[c] = CLIP((int) out[c]);

ponemos:
FORC3 img[c] = CLIP((int) 65535.0*pow(out[c]/65535.0,1/user_gamma));

Esto aplica una gamma pura a la imagen que es algo distinta a la gamma normalizada de sRGB ya que ésta última tiene un tramo lineal inicial que levanta un poco menos las sombras que la gamma exacta. Si la imagen va destinada a ser editada, por ejemplo añadiendo cuvas de contraste posteriores, partir de unas sombras un poco más levantadas en el histograma (menos cercanas a 0) puede ser beneficioso para que no se nos empasten o se vayan a negro tan fácilmente.
Este mismo tipo de gamma pura la aplico en Zero Noise a la salida y ayuda bastante a levantar las sombras en imágenes HDR. Hugo Rodríguez también eligió una gamma pura para sus perfiles H-RGB. Así, como su perfil H-RGB 2.2 Generic PC es muy similar al sRGB salvo por la gamma que es pura, es un perfil ideal para asignar las imágenes reveladas con gamma pura 2.2 y sRGB en DCRAW.

Para los demás perfiles de color (Adobe RGB, ProPhoto) la gamma sí que es la misma por lo que podremos asignar directamente las imágenes reveladas con -g 2.2 en los perfiles habituales de PS.


Aquí una muestra de imagen revelada con DCRAW:

• primero en lineal sRGB y convertida a gamma 2.2 en PS
• y segundo revelado en sRGB gamma 2.2 (dcraw -g 2.2 ...) y asignado directamente al sRGB habitual de PS y al perfil H-RGB 2.2 Generic PC de Hugo (de libre distribución)

La única diferencia a primera vista es que las sombras del primero son más profundas y la imagen parte ya más contrastada que la 2ª. Lógicamente al asignar el perfil de Hugo (3ª imagen) veremos la misma como la 1ª, pero con el histograma en teoría más robusto de la segunda.

Veamos para constatarlo los histogramas finales al usar uno u otro revelado (arriba histogramas generales, abajo zoom 1:2, el máximo para las imágenes de 15 bits de PS):






La diferencia es patente, fijaos por ejemplo en como se "alejan del 0" las sombras en el segundo histograma gracias a usar una gamma pura en lugar de la estándar de sRGB, lo cual permite un manejo más fino de las mismas con menos riesgo de empastado. En realidad no hay que austarse demasiado por el primero; cualquier imagen revelada en lineal en DCRAW y deslinealizada después en PS tendrá un histograma similar y es una imagen de 16 bits muy potente y lista para ser editada. Pero si podemos aspirar a partir de lo segundo, por qué contentarnos con lo primero?
Editar la imagen revelada en DCRAW con gamma 2.2 asignando el perfil H-RGB permite tener la mejor de las opciones: un display similar al obtenido revelando en sRGB estándar, la manejabilidad en sombras de la gamma pura, y la robustez del histograma compensado en gamma antes del redondeo final.

A ver si se pasa por el hilo Manuel y pone el ejecutable de DCRAW con la opción gamma para descargar, por si alguien quiere experimentar con estas cosas.

Aparte tiene cosas interesantes que contar sobre la peculiaridad de los sensores de Olympus en la aparición de artefactos tipo laberintos.

Salu2

Interesante... pero GUI ... ¡¡NO ME EXTRAÑA QUE EN OCASIONES VEAS HALOS!!

Gracias por la información he aprendido algo más sobre lo que es la gamma en y su relación con los perfiles (en realidad yo no le voy a dar una aplicación práctica probablemente a lo descrito en este hilo pues mis fotos no merecen tanta delicadeza, pero me ha gustado leerlo)

Primero dar las gracias a _GUI_ por introducirme en OD, por compartir conmigo la idea de modificar dcraw para incorporar la compensación gamma y por presentarme en este hilo.

Deciros que independientemente de que mis fotos merezcan o no (más bien no) el revelado tan sutil por el que _GUI_ nos guía, soy cabezota y perfeccionista y el simple hecho de saber que podría hacerse mejor no me dejaría dormir por las noches . Si fuera de otro modo no estaría en este hilo, ¿no? (aunque de hecho llevo dos noches durmiendo poco para desempolvar mis conocimientos de C ).

Creo que no tengo opción de adjuntar archivos en el foro, así que compilaré varios ejecutables (optimizados para distintos procesadores) para plataforma Windows y se los pasaré a _GUI_ para que los suba él. Para ejecutarlos necesitaréis la librería cygwin1.dll, que debéis copiar a %WINDIR%\system32 (típicamente C:\WINDOWS\system32). A _GUI_ le han funcionado en Vista Premium, espero que os sirvan a todos los que uséis Vista porque no tengo opción (de momento) de compilar con Visual C++. Más adelante, intentaré compilar una versión para unix, lo de Mac tendrá que hacerlo otro que tenga acceso a un Mac y sepa hacerlo.

Para aquellos a los que no os gusta instalar cosas sin saber que son, deciros que a grandes rasgos cygwin es una librería de emulación de unix que permite que el código que fue diseñado para unix (y que por tanto hace llamadas a las librerías C de unix) crea que está corriendo en unix, aunque en realidad lo haga sobre windows. Es un modo de no tener que retocar el archivo fuente cambiando las llamadas a algunas funciones de la librería. Existe una alternativa más ligera que sea llama minGW, pero es bastante más lenta.

Para los que queráis compilarlo en casa (por enredar con el código, optimizar para otro procesador, etc.) y tengáis un Windows, os doy instrucciones paso a paso:

1. Descargar el instalador de Cygwin desde este enlace.
2. Obviamente, ejecutar el setup.exe que os habéis descargado.
3. Elegid todas las opciones por defecto (especialmente importante que el directorio donde instaléis cygwin no tenga espacios en el nombre y no supere 8 caracteres) y al llegar a Choose A Download Site buscáis uno que os pille cerca.
4. En la pantalla Select Packages marcáis (además de los que ya lo estén) los siguientes: Categoría Devel, binutils: The GNU assembler, linker and binary utilities, gcc-core: C compiler.
5. Termináis la instalación.
6. En Propiedades del Sistema (botón derecho en Mi PC en XP, no sé si habrá cambiado en Vista), pestaña de Opciones avanzadas, Variables de Entorno, Variables de Sistema, entrada Path, doble click para editar y añadís al final ;c:\cygwin\bin (u obviamente el directorio donde lo hayáis instalado si es otro).
7. En un directorio con el archivo dcraw.c (el modificado se lo paso también a _GUI_ para que lo suba al foro) creáis el archivo c.bat con el siguiente contenido:

gcc -o dcraw -O3 dcraw.c -lm -DNO_JPEG -DNO_LCMS

Y ya está. Debería funcionaros a la primera, si os da errores subidlos al foro y miraré qué puede estar pasando. Una vez probado que funciona podéis añadir opciones al compilador para que optimice más, por ejemplo:

-m3dnow -msse -msse2 -mmmx -mfpmath=sse -ffast-math... en este enlace tenéis todas las opciones de optimización que soporta el gcc (se consiguen mejoras en torno a un 15-20% en velocidad de ejecución).

Existe también la opción de compilar sobre MinGW, pero como ya he dicho el código generado es más lento. Además hay que modificar ligeramente el código fuente; si alguno está interesado a pesar de estas advertencias que me lo diga y le cuento los cambios que hay que hacer.

Sobre las modificaciones que hemos hecho entre _GUI_ y yo deciros simplemente que hemos añadido la opción -g, detrás de la cual hay que especificar la nueva gamma. -g 2.2, -g 1. En caso de no especificarse se entiende que es 1 y no se hace nada nuevo. De momento el código es un pelín lento, en mi máquina tarda unos 10 segundos más con la opción -g 2.2 que sin ella. Estoy trabajando para hacerlo un poco más rápido, ya subiré nuevas versiones si lo consigo.

Sobre los laberintos y demás artefactos extraños...

Parafraseado a _GUI_, yo en ocasiones veo laberintos

Con permiso de _GUI_ pongo esta imagen suya, que yo aún no ando muy ducho en este foro como para subir mi propio ejemplo. Fijáos en la pared a la izquierda del altavoz en la imagen de la derecha, y eso que es una Canon, si no me equivoco (no es efecto de la compresión jpeg, aunque puede parecerlo):


Algunos habréis observado que al revelar con -q 2 y -q 3 os aparecen laberintos en zonas de bajo contraste que no deberían estar ahí, otra cosa es que ocurran en zonas de patrones muy finos (muy cercanos a la resolución de la matriz Bayer de la cámara), lo cual sería normal y hasta cierto punto inevitable. En el modo -q 1 también aparecen artefactos como patrones de celdas 2x2. En ambos casos la opción -f los elimina, pero limita las opciones de interpolación al algoritmo VNG que no da la misma calidad que -q 3 y que tiene muchos artefactos de color (aunque que se pueden suavizar con varias pasadas de mediana, en dcraw opción -m 2, por ejemplo).

Los propietarios de cámaras 4/3 (Olympus y Panasonic fundamentalmente) veremos con más facilidad estos artefactos, por alguna característica especial de sus matrices de Bayer que se me escapa, pero pueden verse igualmente en otras cámaras.

La razón en todos los casos parece estar en que los algoritmos de interpolación implementados en dcraw (y por extensión en la mayoría de reveladores que han implementado los mimos algoritmos de interpolación, con la honrosa expepción de ACR y Lightroom, la verdad sea dicha, aunque lo hacen a costa de perder resolución) tratan los cuatro colores captados por el sensor (a través de la matriz Bayer) RGGB como si fueran tres, RGB. Al hacerlo aparecen estos artefactos. La solución está en tratarlos como cuatro colores distintos (precisamente lo que hace la opción -f de dcraw), pero desgraciadamente los algoritmos -q 2 (PPG) y -q 3 (AHD), los de más calidad, están diseñados específicamente para tres colores (AHD de entrada asume que hay más información verde que roja o azul y empieza interpolando ese canal como guía para interpolar luego los otros, por lo que modificarlo para cuatro colores no es en absoluto trivial). Otros reveladores (RAW Therapee, por ejemplo) han optado por soluciones similares y recomiendan directamente a los usuarios de Olympus y Panasonic que usen VNG-4, que viene a ser lo mismo que en dcraw -f (independientemente de la opción -q, como hemos visto), aunque a mí me da más calidad RAW Therapee en VNG-4 que dcraw con la opción -f.

No creo que Coffin vaya a resolver el problema y hay algunos usuarios de dcraw que nos resistimos a quedarnos con VNG en esa búsqueda del revelador perfecto. Así que la idea es rediseñar AHD para trabajar con 4 colores e incorporarlo a dcraw. Yo he empezado a investigar el tema, partiendo de los artículos originales de Keigo Hirakawa donde se describe el algoritmo, pero de momento estoy un poco pez. Primero quiero entender cómo exactamente se forman estos patrones por hacer RGGB -> RGB ¿Alguien tiene más información? ¿Alguien se apunta?

Saludos:
Manuel Llorens

Yo me puedo apuntar para servir el café mientras vosotros tecleáis como posesos. De programación: ná de ná. Me quedé en Fortran y gracias... Me encantan estos temas. Gui lo sabe, a veces no es que vea halos, es que no me entero de nada de lo que decís. Eso sí, me empapo de todo lo que escribe porque algo de lo que enseña se me quedará en la mollera.
Estaré al tanto del post, que parece que mola.
Saludos

He optimizado el cálculo de la función pow (_GUI_ sabe de lo que hablo, es la función que calcula x^y en C) mediante una tabla de valores entre los que interpolo linealmente, dado que los valores a elevar estaban normalizados entre 0 y 1 y el exponente es el mismo en todas las operaciones.

Utilizando una tabla de 65536*5, así por usar un valor redondo, el proceso tarda solo 3 segundos cuando antes tardaba 13. Con una tabla más pequeña se puede bajar a un segundo.

Apenas se pierde precisión (con 65536 valores de tabla empieza a fallar en el octavo decimal) según se observa el histograma. Mañana recompilo y le paso a _GUI_ código y ejecutables.

Un saludo:
Manuel Llorens

Bueno Manuel, como con lo que pones arriba se tengan los medios para poder compilar el fuente de DCRAW ya la hemos liado jeje, solo me faltaba eso.
Voy a ver si escribo un pequeño artículo sobre la gamma y toda esta historia y cuelgo los ejecutables para el DCRAW mejorado.

Una pregunta: si en la web de Pukkita hay ejecutables de DCRAW que funcionan directamenet en Windows (Vista y XP), por qué con estas compilaciones que muestras hace falta la librería intermedia cygwin?

He corregido un poco el post de arriba: solo sRGB tiene una gamma "especial" en las sombras. Como me has dicho que has empezado a usar una LUT para aproximar la función potencia, si quieres afinar más el código en sRGB la expresión exacta de la curva gamma para sRGB es la de abajo:

Aunque por otro lado da un poco de pena perder la posibilidad de usar la gamma exacta en sRGB. Quizá podrías hacer que -g srgb (si se puede meter texto) o -g 0 sino, aplique la fórmula sRGB de arriba. Y para el resto de valores se aplique 1/gamma.
_________________________________

Iniciado por ClinSbud

De programación: ná de ná. Me quedé en Fortran y gracias... Me encantan estos temas.

jeje, tú has visto que pongo 65535.0 en lugar de 65535 a secas? eso es una buena costumbre herencia del PFC que hice en Fortran; si no lo pones así da error de compilación.

He estado investigando el asunto y estas son las opciones (gratuitas) que tenemos para compilar dcraw en Windows. Pongo también la ventajas e inconvenientes de cada una:

1. DJGPP 2.04 beta: no requiere modificaciones en el código, no necesita dll, pero no funcionará en Vista.
2. cygwin: no requiere modificaciones, correrá en Vista pero requiere cygwin.dll.
3. MinGW: requiera unas pocas modificaciones en la cabecera del código, correrá en Vista y no requiere dll.
4. Visual C++ 2005 Express Edition: requiere modificaciones en la cabecera, correrá en Vista, no requiere dll.

Como versión de desarrollo yo recomendaría cygwin, dado que no requiere modificaciones y corre en Vista. Como versión definitiva yo recomendaría VC++2005SE, dado que añadir las cabeceras no cuesta casi nada y así se puede distribuir sin cygwin1.dll.

Las instrucciones de compilación que subí anteriormente hacían referencia a cygwin. En mi máquina he compilado con los cuatro sistemas y todos funcionan bien. Puedo crear guías para compilar en todos los sistemas, pero creo que lo ideal es limitarnos a los dos que he recomendado.

Instrucciones para VC++2005SE:

1. Descargarlo (desde aquí) si no se tiene la versión completa de Visual Studio, claro.
2. Abrir un nuevo proyecto de tipo Aplicación de consola Win32 con el nombre dcraw. Opciones por defecto, o sea, Finalizar.
3. Renombar el archivo dcraw.cpp a dcraw.c (en el Explorador de soluciones, arriba a la derecha).
4. Configurar el proyecto. Hay que hacer los siguientes cambios: Menú Proyecto, Propiedades de dcraw. Dentro de Propiedades de configuración, opción C/C++ hay que cambiar las siguientes cosas:
   1. Optimización -> Optimización -> Optimización completa (/Ox).
   2. Encabezados precompilados -> Crear o utilizar encabezado precompilado -> Crear encabezado precompilado (/Yc).
   3. Avanzadas -> Compilar como -> Compilar como código de C++ (/TP).
   4. Línea de comandos -> Opciones adicionales -> Tenéis que añadir: /DNO_JPEG /DNO_LCMS.
5. Abrir el archivo dcraw.c y borrar todo menos la línea #include "stdafx.h"
6. Por último, añadir el código en azul siguiente entre las líneas #end if y #ifdef __CYGWIN__:

OJO: en las directivas #include que siguen a continuación lo que viene después del #include (direct.h / io.h) debe ir encerrado entre caracteres de menor que / mayor que, pero el foro no me deja insertar estos caracteres.

#ifdef DJGPP
#define fseeko fseek
#define ftello ftell
#else
#define fgetc getc_unlocked
#endif
#ifdef _MSC_VER
#undef fgetc
#include direct.h
#include io.h
#define fseeko fseek
#define ftello ftell
#define getcwd _getcwd
#define isatty _isatty
#endif
#ifdef __CYGWIN__
#include io.h
#endif

Un poco más abajo debéis añadir el siguiente código en negrita:

#define ushort UshORt
#ifdef _MSC_VER
#define UshORt char
#endif
typedef unsigned char uchar;
typedef unsigned short ushort;

Finalmente hay que arreglar algunos problemas con funciones sobrecargadas (sqrt y pow) insertando un cast (double) antes del argumento de las funciones. Investigaré si es posible añadir todas estas modificaciones en un include. Y ya está. Cualquier problema me lo comentáis e intentaré solucionarlo.

En la web de Pukkita hay versiones con DJGPP y con VC++2005SE, si no me equivoco. Al menos las últimas las está compilando con VC++ para evitar el problema del Vista (que parece que es algo que ha hecho MS a mala idea ).

Voy a añadir las opciones nuevas sugeridas por _GUI_ en la entrada anterior para la gamma sRGB (de hecho es la que incorpora dcraw para 8 bits) y recompilaré en VC++. Mandaré los ejecutables definitivos a _GUI_.

Un saludo.
_________________________________

¡Laberintos solucionados!

Me vais a perdonar que esté exultante, contento y emocionado , ¡pero es que he seguido una corazonada y me ha dado un resultado increíble!

Creía que iba a ser mucho más difícil arreglarlo y, sin embargo, ¡he conseguido resolver los problemas de laberintos sin modificar los algoritmos de interpolación actuales y de un modo que será válido para cualquier otro algoritmo futuro! Y todo ello sin perder información ni calidad.

Entiendo que tal vez somos pocos los que estamos preocupados por este problema pero, tal y como yo lo veo, parcheando dcraw del modo que os voy a mostrar se convierte por fin en un revelador imbatible. Además, creo que TODAS las cámaras basadas en matriz Bayer están afectadas de este tipo de artefactos en mayor o menor medida, no solo las 4/3 (Olympus y Panasonic), y buena parte del software revelador de raw.

El diagnóstico, ¿por qué aparecen laberintos?

La pista la da obviamente el hecho de que al tratar RGGB como cuatro colores en lugar de tres se eliminen los artefactos. Desgraciadamente, como también explique en la entrada anterior, los algoritmos más avanzados (PPG y AHD) no están preparados para 4 colores y al usarlos aparecen estos artefactos.

La razón, evidentemente, solo puede ser que la matriz Bayer que se antepone al sensor no tiene la misma respuesta en los dos captadores verdes, GG, porque de no ser así no habría diferencia entre interpolar esos colores juntos o separados. La razón por la que los fabricantes hacen eso aún se me escapa, aunque se me ocurren dos:

1. Mejorar el rango dinámico incorporando dos captadores verdes con sensibilidad distinta (lo que no deja de ser una buena idea).
2. Dificultar la interpolación por software que no conozca sus especificaciones (o sea, todo el que no sea el suyo propio y tal vez Adobe).

Lo primero era comprobar este extremo y para eso he diseñado un pequeño programa que compara la respuesta de los cuatro elementos captadores. Lo que quería era comprobar primero cuánto de distinta tiene la señal y segundo, si la diferencia es siempre la misma independientemente de la imagen (lo que parece lógico, porque la distinta sensibilidad es de la matriz Bayer, no del captador que hay debajo, y la matriz Bayer es un elemento pasivo).

Aquí tenéis un resultado (a partir de un volcado de dcraw en modo documento, -d) de una flor de ibisco del jardín de mis padres (sin valor artístico):


Como se observa claramente la respuesta espectral (el histograma) de las dos capturas verdes es idéntica (teniendo en cuenta que los píxeles son diferentes porque aún no se ha interpolado, pequeñas diferencias en el histograma son esperables), pero cambia el nivel de la señal. En todas mis pruebas con varias imágenes el captador G2 da la misma respuesta espectral con un nivel de señal más alto que el G1. Además, si comparo la señal media de ambos captadores en otras imágenes: la relación de señal media entre ambos captadores se mantiene constante, como sería de esperar si se trata de la construcción física de la matriz Bayer.

Evidentemente, cuando el algoritmo de interpolación trata esas dos señales juntas tienen que aparecer artefactos, que dependerán del algoritmo: en VNG aparecen celdas 2x2 y en PPG y AHD laberintos.

La solución, ¿cómo nos libramos de los laberintos y celdas 2x2?

Creo muy probable que los fabricantes de cámaras, en sus propios reveladores tengan en cuenta el valor exacto de la diferencia de señal y compensen la señal de una de las salidas o bien renuncien a los algoritmos avanzados o bien sean tan chapuceros que den imágenes con laberintos... lo cual es el colmo de la chapuza (creo que Nikon lo hace, ¿no?).

Tenemos las siguientes opciones y subopciones:

1. Modificamos los algoritmos de interpolación PPG y AHD para trabajar con 4 colores. Esto es algo en lo que trabajaré más adelante pero que es muy complicado, o al menos a mí me lo parece. El VNG sí tiene una versión para 4 colores (dcraw -f y RawTherapee).
2. Modificamos la señal de uno de los captadores para igualar su nivel con la otra, (o mejor aún la de los dos para equilibrarlas, esto aún lo estoy trabajando). Para ello tenemos que conocer la diferencia de señales por alguno de estos métodos:
   1. Ingeniería inversa del software del fabricante. Tirar de SoftICE al estilo Coffin. Personalmente me aburre este método, aunque sería el ideal y se lo dejo a Coffin , que le gusta.
   2. Calculamos mediante un método empírico esa diferencia de señal para cada cámara. Podríamos fotografiar una imagen borrosa con diferentes niveles de verde y medir la diferencia de señal con el programa que os he mostrado arriba. Esto tiene mucho trabajo y no me apetece nada.
   3. Dejamos que dcraw calcule antes de interpolar la diferencia de señal mediante el cálculo de la señal media de cada captador. Este método debería funcionar en el 99,999% de los casos. Solo podría fallar si fotografiamos una textura con un patrón de distintos niveles de verdes que coincida con la matriz Bayer de la cámara en cada píxel de la imagen... vamos que el 99,999% se me queda corto. Una vez calculada la diferencia de señal las reequilibra.

Como podéis imaginar, me he lanzado a implementar en dcraw la opción 2.3. a ver qué pasaba, porque era la única forma de probar toda la teoría que os acabo de soltar. De momento lo que hago es bajar la señal alta (la del captador G2) por aquello de que es más probable que se haya quemado. Aunque tal vez sea mejor subir la G1 para mejorar la señal/ruido... o modificar las dos como decía arriba. Incluso puede que se pueda tomar el nivel de la señal G2 en las sombras y el de la G1 en las luces para exprimir al máximo el rango dinámico, aunque esa transformación no lineal en un solo canal imagino que generaría colores imposibles de eliminar con el balance de blancos. Espero que _GUI_, que tiene las ideas muy claras, me guíe al respecto. Lo que sí tengo claro es que esto hay que hacerlo antes del balance de blancos, para que al corregir el balance de blancos ya tenga en cuenta la diferencia de señal.

double m1,m3;
for (row=0; row < height; row++)
for (col=0; col < width; col++) {
c = fc(row,col);
if(c==1) m1+=(double)image[row*width+col][c];
if(c==3) m3+=(double)image[row*width+col][c];
}
m1=m1/(double)(width*height);
m3=m3/(double)(width*height);

for (row=0; row < height; row++)
for (col=0; col < width; col++) {
c = fc(row,col);
if(c==3) image[row*width+col][c]=(ushort)CLIPF((double)image[row*width+col][c]*(m1/m3));
}

Lo he pasado a esta imagen de mi salón que hice con mi Oly E-300 para probar el programa Zone Noise de _GUI_ (al ver su tutorial quiere uno ver su propio salón igual de limpio de ruido ). La imagen está revelada SIN balance de blancos, para que se vea bien la diferencia entre con y sin la corrección de laberintos en el histograma y no se ha procesado en modo alguno. Por tanto, es lógico que la imagen corregida sea un pelín más oscura y menos verde. Línea de comando de dcraw:

dcraw -v -q 3 -o 2 -g 2.2 -T -4 salon.orf, es decir interpolada con AHD sin la opción -f



CON LABERINTOS al 400%


SIN LABERINTOS al 400%


Histogramas (gracias al estupendo Histogrammar de _GUI_):

CON LABERINTOS


SIN LABERINTOS bajando el nivel de señal de G2


SIN LABERINTOS subiendo el nivel de señal de G1



Bueno, pues eso es todo. Creo que el método es eficaz y estoy seguro que al ser transformaciones lineales del nivel de señal de un solo canal se puede reequilibrar con el balance de blancos.

Voy a tomarme con calma lo de recompilar dcraw con todos los cambios y creo que sería interesante pasarle a Coffin (con esto sí tiene que estar de acuerdo, ¿no _GUI_?) los cambios y que los incorporara a la versión oficial de dcraw. Evidentemente lo pondré como una opción a especificar en la línea de comandos (quizás que se pueda elegir si subir G1 o bajar G2). También creo que sería interesante convertir esto en un artículo en inglés para darle máxima difusión y que otros reveladores raw se actualicen, espero que _GUI_ pueda echarme una mano con eso.

Me voy a descansar, que llevo cuatro días con la familia semiabandonada y durmiendo poco (podría haberme tomado todo el asunto con calma pero no suelo tener tanto tiempo libre y hasta que no acuesto a los niños no tengo horas seguidas para ponerme al PC).

Quiero dar las gracias a _GUI_ por haberme propuesto meterle mano al código de dcraw, gracias a eso he disfrutado estos días programando en C como hacía tiempo que no lo hacía delante de un ordenador. Y ahora de verdad podré usar dcraw sin sentir un cosquilleo desagradable en la espalda, como si me la recorrieran unos laberintos, y es que:

en ocasiones... digo... ¡ya no veo laberintos!

Un saludo:

Fenomenal exposicion de trabajo y funcionamiento.

Manel, sobre los laberintos es algo que se me hace intratable ultimamente, ya pasaba las tomas siempre con el parametro -f.

Seguiré pendiente vuestras evoluciones que tienen muy buena pinta

salu2

Manuel está fenomenal lo que has hecho, y sé que debes estar disfrutando como un enano aprendiendo cómo se procesa un RAW.

Respecto a la corrección de los niveles relativos G1 vs G2, hay un dilema: si reduces G2 para igualarlo a G1 obviamente preservas toda su información, pero en aquellos píxels saturados darás lugar a un nivel erróneo que ni se corresponderá con sus gemelos G1 (tanto si estos estaban saturados como si no llegaron a estarlo) ni será correcto, lo que con seguridad traerá problemas en las altas luces (tonos erróneos, más laberintos,...).
Así que mi consejo de todas todas es que, salvo que la diferencia de nivel sea muy grande (que viendo los histogramas lineales es despreciable), aumentes el nivel de G1 para igualarlo a los G2. Esto podrá quemar algún píxel pero serán poquísimos y no tendrás los problemas comentados.

Por cierto, no sé como estás calculando la diferencia de exposición entre G1 y G2, pero te diré cómo lo hago yo que es rapidísimo y muy robusto porque pondera al alza los niveles de mayor brillo, lo que conceptualmente es muy correcto:
1. Sumas todos los niveles G1 de la imagen que superen un cierto umbral inferior y no superen otro umbral superior -> S1
2. Haces lo propio con los niveles de G2 -> S2

El factor por el que has de multiplicar los niveles G1 es f=S2/S1>1, así a la siguiente etapa de revelado le llegarán los niveles: R, G1*f, G2, B.

Aunque en realidad no tienes ni que hacer dicha corrección porque una vez calculada la relación f es más sencillo, elegante y seguro introducirla en el propio balance de blancos; piensa que el ajuste de balance de blancos requiere 4 factores, solo que el 2º y 4º suelen* ser iguales. Imagina que el balance de blancos original a aplicar fuera:

-r m1 m2 m3 m2 (R G1 B G2)

bastaría interceptar esos valores en el código y realizarlo haciendo el equivalente a:

• -r m1 m2*f m3 m2 (aumentamos G1)
• -r m1 m2 m3 m2/f (reducimos G2)
• -r m1 (m2*f+m2)/2 m3 (m2/f+m2)/2 = -r m1 m2*(f+1)/2 m3 m2*(1/f+1)/2 (corrección compartida que preserva el balance de blancos original)

donde: m2*(f+1)/2 / m2*(1/f+1)/2 = f que es la relación buscada.

Esto traslada a DCRAW la responsabilidad de preocuparse con el tratamiento de altas luces (con -H) y te evita operaciones innecesarias y los problemas de altas luces comentados arriba.

*Y DIGO YO:
Como ves he asumido que en el balance de blancos los factores de G1 y G2 eran iguales (m2). No estará precisamente ahí el problema? Zero Noise fuerza (porque ni me planteé que hubiera cámaras con canales G de diferente exposición) multiplicadores iguales para los canales G1 y G2. Si cambio el cálculo del balance de bancos de ZN y desdoblo el canal verde en 2 de modo que se calculen 4 multiplicadores en lugar de 3 tan solo, quizá no sería necesario -f y podría usarse AHD sin aparecer laberintos.
Has probado a revelar RAWs de Oly con DCRAW con -a, para que el propio DCRAW calcule los multiplicadores, y ver si difieren notoriamente los factores de G1 y G2, y ver si desaparecen los laberintos aunque se use -q 3 y sin -f?

Me llama la atención no obstante en tu 3er histograma que el nivel del canal verde final no solo no es mayor que en el 1º, sino que es incluso un poco menor. El balance de blancos usado ha sido el mismo no?

Salu2
_________________________________

Bueno, confirmado. Para comprobar la influencia del correcto equilibrado de los dos canales G he el revelado 3 veces el mismo RAW:

1. Automático de DCRAW: los canales G tienen prácticamente los mismos multiplicadores, es decir, en mi Canon esos 2 canales son muy uniformes -> hay ruido pero apenas se generan laberintos al hacer el demosaicing (-f los elimina pero no compensa por la pérdida de calidad de interpolación VNG)
2. Fuerzo un 1% de error entre ambos multiplicadores -> empiezan a aparecer laberintos
3. Fuerzo un 5% de error entre ambos multiplicadores -> muuuuchos laberintos

Conclusión que saco: la Oly, por su diseño hardware o por lo que sea, tiene unos canales G más diferenciados que otras cámaras (lo puedes probar revelando algún RAW con -a como te decía) y por tanto en ella es crítico hacer un balance de blancos que compense tal cosa.
Nunca pensé que diferenciar los canales G pudiera tener tanta importancia; otra mejora para Zero Noise.

Por cierto que acabo de probar el dcraw.exe optimizado para mi AMD y va como un misil, apenas se nota que estemos aplicando la gamma. Si no he entendido mal usaste una LUT precalculada de 65536*5 valores e interpolas linealmente entre los extremos del intervalo en que se encuentre el argumento solicitado no?

Te contesto por puntos:

<!-- message -->

Iniciado por _GUI_

Manuel está fenomenal lo que has hecho, y sé que debes estar disfrutando como un enano aprendiendo cómo se procesa un RAW.

Muchas gracias, _GUI_. Efectivamene estoy disfrutando mucho, sobretodo porque en mi entorno personal hay muy poca gente con la que pueda compartir todo esto y hasta ahora no había metido cabeza en los foros.

Creo que ahora que dcraw se va a convertir en mi revelador principal (con los cambios que estamos planeando en este foro dcraw es casi perfecto), voy a crear un pequeño GUI al estilo del estupendo MeGui. UFraw no me gusta nada, es lentísimo y yo quiero algo mucho menos ambicioso. Apenas una opción para indicar el balance de blancos al estilo Zero Noise, otra para previsualizar la corrección de aberraciones cromáticas y poder poner las opciones y procesar por lotes. Creo que lo haré en C# para que se pueda usar en unix y en Windows. También quiero probar eso que te comenté por mail de revelar con dcraw y mantener los 32 bits, a ver qué pasa. También estoy deseando que Zero Noise coja cuerpo porque pienso usarlo en todos los casos en los que el rango dinámico de la escena supere el de la cámara. Con esas esos dos programas, y siempre pensando en tener un revelado lo más plano y limpio posible, y luego tratar un poco en Photoshop, creo que tendremos el sistema de revelado perfecto.

Iniciado por _GUI_

Así que mi consejo de todas todas es que, salvo que la diferencia de nivel sea muy grande (que viendo los histogramas lineales es despreciable), aumentes el nivel de G1 para igualarlo a los G2. Esto podrá quemar algún píxel pero serán poquísimos y no tendrás los problemas comentados.

Totalmente de acuerdo, lo dejaré calculando al alza, es verdad que existe el riesgo de crear colores extraños en la luces muy altas. Aún así creo que puede ser útil permitir las otras dos opciones (bajar G2 o equilibrarlos) para salvar casos puntuales.

Iniciado por _GUI_

1. Sumas todos los niveles G1 de la imagen que superen un cierto umbral inferior y no superen otro umbral superior -> S1

Salvo lo del umbral, que entiendo que es importante, estaba haciendo eso mismo. Pondré un umbral en el cálculo o dejaré a dcraw que lo haga.

Iniciado por _GUI_

Esto traslada a DCRAW la responsabilidad de preocuparse con el tratamiento de altas luces (con -H) y te evita operaciones innecesarias y los problemas de altas luces comentados arriba.

Creo que es mejor separar el balance de blanco del equilibrado de los dos canales de verde, porque aunque -a ayude a reducirlo son dos problemas distintos. Básicamente porque salvo que se haya especificado la opción -a (que efectivamente reduce mucho los laberintos en el 90% de las imágenes que he probado y cuyo uso se recomienda en algunos foros para ese uso), el balance se va a calcular en una zona y eso no vale para equilibrar los niveles. Otra cosa es que internamente podamos aprovechar la rutina de balance de blancos y llamarla dos veces, una para equilibrar los canales verde tipo -r 1 f 1 1 y otra la que se haya especificado en la línea de comandos. En caso contrario, si no se especifica ningún balance de blancos los laberintos aparecerán. Yo creo que dcraw no debería permitir que aparecieran independientemente de que haya un balance de blancos u otro.

A lo mejor te he entendido mal y lo que quieres decir es que si no se hace balance de blancos le llamamos con -r 1 f 1 1 y en caso contrario corregimos el balance que ha solicitado el usuario. Pero creo que eso complicaría más los cambios que hay que hacer al código. Otra opción, la mejor sin duda, sería contárselo a Coffin y que hiciera él los cambios como le pareciera más conveniente.

Iniciado por _GUI_

*Y DIGO YO:
Has probado a revelar RAWs de Oly con DCRAW con -a, para que el propio DCRAW calcule los multiplicadores, y ver si difieren notoriamente los factores de G1 y G2, y ver si desaparecen los laberintos aunque se use -q 3 y sin -f?

Como te digo ya había probado y no siempre funciona bien (en el ejemplo que tú has subido de la Canon con -a siguen apareciendo algunos, tengo ganas de que pruebes mis cambios a ver cómo queda), aunque ahora que entiendo el problema no sé por qué no lo hace. En Raw Therapee sí aparecen al usar el balance de blancos automático. Voy a echar un vistazo al cálculo que hace dcraw. El caso es que el resultado automático, como balance de blancos, es muy malo.

Iniciado por _GUI_

Me llama la atención no obstante en tu 3er histograma que el nivel del canal verde final no solo no es mayor que en el 1º, sino que es incluso un poco menor. El balance de blancos usado ha sido el mismo no?

No te entiendo, yo veo los niveles de verde del tercer histograma claramente mayores que los otros dos. ¿Estamos hablando de lo mismo? No he usado ningún balance de blancos en esas pruebas.

<!-- / message --><!-- sig -->

Iniciado por _GUI_

Por cierto que acabo de probar el dcraw.exe optimizado para mi AMD y va como un misil, apenas se nota que estemos aplicando la gamma. Si no he entendido mal usaste una LUT precalculada de 65536*5 valores e interpolas linealmente entre los extremos del intervalo en que se encuentre el argumento solicitado no?

Eso mismo. Consume un poco de memoria al calcular la LUT en double (65536*5*6 bytes, más o menos 2 megas), pero tarda muy poco en hacerlo. Con una tabla 5 veces más pequeña tarda bastante menos y apenas se pierde precisión. Tengo que revisar el código de VC++ porque no va igual de rápido. Creo que es un problema del compilador. Por cierto, ¿has conseguido compilarlo tú? Te recomiendo que empieces por la opción cygwin, que es la más fácil de configurar.

Esta noche intentaré compilar una versión para que puedas probar los cambios.

Un saludo:

Iniciado por ManuelLlorens

No te entiendo, yo veo los niveles de verde del tercer histograma claramente mayores que los otros dos. ¿Estamos hablando de lo mismo? No he usado ningún balance de blancos en esas pruebas.

A ver, si te fijas en los picos del histograma, el tercero está desplazado hacia la izquierda, es decir, los píxels de esa imagen tienen menor nivel de verde:

Ahora sí lo veo... pero no lo entiendo . Quiero decir que no sé por qué pasa eso. Voy a preparar una versión para que puedas hacer tus pruebas.

En cualquier caso, si yo entiendo el histograma, que puede que no, hay más píxeles verdes (los picos son más altos) pero de un verde más oscuro, ¿no?

Iniciado por ManuelLlorens

En cualquier caso, si yo entiendo el histograma, que puede que no, hay más píxeles verdes (los picos son más altos) pero de un verde más oscuro, ¿no?

No tomes como referencia la altura de los picos porque Histogrammar escala el eje Y para que el máximo del histograma caiga arriba del todo y ese máximo varía de unas imágenes a otras (Histogrammar lo indica donde dice Ymax).
Los 3 canales tienen siempre el mismo número de píxels, que son los de la imagen claro.

Eso es lo que pasa por no leer los manuales de los programas . Tampoco me leí el del friegaplatos y me deja los calcetines sucísimos .
_________________________________
_GUI_, puestos a redondear dcraw para adaptarlo a tu forma de trabajo (que como puedes entender pienso seguir devotamente hasta llegar a PS, a partir de ahí ya hablaremos en otro foro, aunque por el aspecto de las pocas fotos tuyas que he visto creo que no discutiremos precisamente), ¿por qué no incluir los perfiles de Hugo Rodríguez en dcraw?

A priori no tengo ni idea de lo que estoy diciendo, ¿sería posible/interesante?
_________________________________
He terminado de meter las nuevas opciones en dcraw. De momento he incorporado el equilibrado de los canales verdes totalmente separado del balance de blancos mientras sigo investigando. Sí que he metido unos umbrales en el cálculo de los valores medios de cada canal, como indica _GUI_. Queda del siguiente modo:

Opción -l con posibles valores 0, 1, 2 ó 3:
-l 0 no hace nada .
-l 1 sube G1 hasta el valor de G2, la opción más recomendable.
-l 2 baja G2 hasta el valor de G1, por si acaso es útil en alguna foto.
-l 3 sube G1 y baja G2 hasta el nivel medio, lo mismo.

En modo verbose (-v) informa de lo que está haciendo y de la diferencia de nivel entre los canales. En algunas imágenes en mi Oly E-300 da valores de cerca de 300 sobre 65535... no está mal.

Opción -g con valores sRGB, 0, 1 ó cualquier otro número:

-g sRGB aplica gamma sRGB (no distingue mayúsculas).
-g 0 aplica gamma sRGB.
-g 1 no hace nada , empieza a ser una costumbre.
-g <num> aplica el valor de gamma especificado en num.

Las fotos con gamma sRGB las veo un poco oscuras. Ya me diréis si lo he implementado bien.

He dejado configurada la LUT con 65535*5 valores. Creo que es un valor equilibrado entre velocidad y precisión.

Podéis bajar el código fuente y los ejecutables (deberían ir en Vista) desde estos enlaces. El código fuente no está del todo limpio ni preparado para compilar en VC++.</num>

• Código fuente modificado
• Ejecutable cygwin win32 genérico
• Ejecutable cygwin win32 AMDXP
• Ejecutable cygwin win32 AMD64
• Ejecutable cygwin win32 Pentium4
• Ejecutable cygwin win32 Pentium4m

Tal vez sería buena idea que _GUI_ los albergara en su página. Lo digo porque su página ya es una referencia para los que buscan información sobre dcraw y sería una forma de tenerlo todo junto.

bueno he conseguido compilar mi primer DCRAW. Tristemente no se como añadir variables de entorno en Vista así que lo he hecho en c:\cygwin\bin\ pero bueno el caso es que ha funcionado. Mañana más.

Muchas gracias Manuel por las indicaciones. Estoy acabando un artículo sobre la gamma y la gamma en DCRAW, lo ponemos allí todo junto.

No van los links Manuel

mis tremendas aportaciones:

Había un error en la anterior versión porque el equilibrado de los canales verdes se estaba haciendo después del balance de blancos y las medias se calculaban mal si la imagen estaba muy sobreexpuesta. Además, modificaba alguna variable global (dcraw usa variables globales a punta de pala), lo que estropeaba alguna cosilla.

Ahora ya está bien. He actualizado los ejecutables para que podéis descargarlos. Los he probado con Zero Noise y funcionan bien.
_________________________________

Iniciado por _GUI_

No van los links Manuel

Estaría actualizado... digo yo. Prueba dentro de un rato y me dices.

Iniciado por _GUI_

mis tremendas aportaciones:

Voy a añadirlas. Además voy a poner un número de versión de los cambios nuestros para no perdernos.
_________________________________
He estado investigando un poco con la opción -a de dcraw y los "restos de laberintos" que quedan eliminándolos mediante los dos métodos (-l o -a). Primero decir que estaba yo equivocado y que el parámetro -a sí quita los laberintos en todas las imágenes, tal vez lo probé con una versión más antigua de dcraw, porque estoy casi seguro de que antes no me había funcionado bien, de haberlo hecho habría empezado por ahí mi investigación.
En cualquier caso es más útil tener las dos correcciones por separado.

Esos restos no son achacables al equilibrio de los canales verdes porque están perfectamente equilibrados. Si vuelvo a intentar equilibrarlos después del balance de blancos siguen estando equilibrados y no hace nada (es decir que no se desequilibran una vez equilibrados, a menos que lo forcemos mediante un multiplicador distinto para cada canal G1 y G2 en la opción -r, claro).

Creo que los restos de laberintos son la forma en la que el algoritmo AHD ve el ruido. Si es así no mejoraría nada al usar un AHD-4, si alguna vez se crea y el esfuerzo no merecería la pena. Este algoritmo está diseñado para ver el mundo en forma de líneas horizontales o verticales y lleva esta filosofía al extremo. El algoritmo de eliminación de ruido por wavelets que incorpora dcraw quita en ruido de cada canal de forma independiente antes de la interpolación, por lo que debería eliminar los resto de laberintos... pero funciona regular, a ver qué resultados obtenéis vosotros, a mí me quita los laberintos pero los sustituye por unos patrones cuadrados . Creo que hay que mejorar ese algoritmo o yo lo estoy aplicando mal. También puede ser que alguno de los cambios que hemos hecho haya interferido con el funcionamiento de esta opción. Seguiré investigando.

Por otro lado la opción -m para aplicar un filtro mediana elimina muy eficazmente los restos de colores falsos de los laberintos (a mí con -m 1, un pase, ya me vale), dejando sólo un pequeño ruido de luminancia mucho menos molesto, aunque aún mantiene un ligero aspecto de líneas. Este proceso ocurre después de la interpolación.

Mientras _GUI_ elabora una guía de la gamma lineal con dcraw, yo voy a elaborar una comparativa actualizada con los cambios de los algoritmos de interpolación de dcraw con las distintas opciones.

Un saludo:

Está seguro que compensa la compilacion puesta mas arriba el tema del gamma??

He usado el parametro -g 2.2 y no noto nada en absoluto, como si fuese sin compensacion o -g 1.0

Para poder trabajar con ello he copiado al directorio d dcraw los archivos siguientes cygwin dlls:
http://www.lebsanft.org/files/cygwin.tar.gz

tal como se dice en este enlace:
http://www.lebsanft.org/blog/?tag=dcraw


He usado el ejecutable generico, puesto arriba:
Ejecutable cygwin win32 genérico

PD: añado:
He hecho pruebas con el parámetro -l 1, -l 2, -l 3. y los resultados t desastrosos. Tengo q selecionar color crudo -o 0, porque si selecciono espacio color (Srgb, Argb), casca y no hace nada.
Por si sirve de ayuda estas pruebas



salu2

Iniciado por meiker10

Está seguro que compensa la compilacion puesta mas arriba el tema del gamma??

He usado el parametro -g 2.2 y no noto nada en absoluto, como si fuese sin compensacion o -g 1.0

Solo tienes que comparar histogramas:



Quizá los ves igual porque ha de ser así: la versión con gamma 1.0 PS la reconoce como tal, y por lo tanto pese a ser lineal la muestra correctamente en la pantalla.
De hecho es cuando haces -g 2.2 cuando has de asignar tú el sRGB/Adobe RGB de toda la vida (gamma 2.2), o de lo contrario PS leerá en los metadatos de la imagen que es gamma 1.0 y la mostrará demasiado clara. Eso sería otra mejora Manuel jeje, localizar donde mete DCRAW en los datos EXIF (o en los datos que sea) la gamma bajo la cual va la imagen, para que se guarde la elegida por el usuario.

Manuel siguen sin funcionarme los links... será mi Vista? tendré Jazztel capado?

Salu2
_________________________________

Iniciado por ManuelLlorens

el parámetro -a sí quita los laberintos en todas las imágenes, tal vez lo probé con una versión más antigua de dcraw, porque estoy casi seguro de que antes no me había funcionado bien

Es lo que pensaba, porque en realidad no hay diferencia entre un equilibrado y el otro. Coffin me comentó que su -a realiza el cálculo del equilibrado en sub-grupos de píxels (no se si me dijo cuadrados NxN píxels), y además descarta los canales saturados en el cálculo.

Iniciado por ManuelLlorens

El algoritmo de eliminación de ruido por wavelets que incorpora dcraw quita en ruido de cada canal de forma independiente antes de la interpolación, por lo que debería eliminar los resto de laberintos... pero funciona regular

Por otro lado la opción -m para aplicar un filtro mediana elimina muy eficazmente los restos de colores falsos de los laberintos (a mí con -m 1, un pase, ya me vale), dejando sólo un pequeño ruido de luminancia

No he usado nunca las reducciones de ruido en DCRAW, en realidad solo quito el ruido de color y lo hago en PS. Crees que la mediana de DCRAW lo quitará mejor que PS? la mediana se aplica sobre datos RAW o interpolados? elimina textura?

Pues no se que habría hecho, que no me iba bien. Ahora si coge perfectamente el parametro -g 2.2

Gracias Gui, comprobado perfectamente en tu histogrammer
_________________________________
Manuel:

lo que me refería antes que era un desastre el parámetro -l 1 (y otras opciones), al menos en los raws de la E3.

En la E3, hay diferencias entre el multiplicador 2 y 4 cuando usamos balance blancos automatico - a)

Te paso primero el thunb incrustado y posteriormente la imagen tratada en dcraw con ese parámetro y ( -o 1, -l 1 -g 2.2)





salu2

meiker, ¿puedes mandarme el raw de la imagen que muestras por correo a manuelllorens@gmail.com?

¿Has probado con la última versión, la que te pone compilado por al ejecutarla sin parámetros? Porque ayer cambié algunas cosillas a última hora. En cualquier caso está claro que hay que probar los cambios con más imágenes de más cámaras a ver qué pasa.

Yo he probado con imágenes de Canon EOS 30D, Canon EOS 350D, Olympus E-300, Olympus E-3 y todas Ok. Por cierto, en la 30D y la E-3 el G2 tiene menos señal que el G1, al contrario que la E-300 y la 350D y efectivamente la 350D tiene una diferencia mínima entre canales (probablemente despreciable).

Un saludo:
_________________________________

Iniciado por _GUI_

Manuel siguen sin funcionarme los links... será mi Vista? tendré Jazztel capado?

¿A alguien le funciona?

Iniciado por _GUI_

sub-grupos de píxels (no se si me dijo cuadrados NxN píxels), y además descarta los canales saturados en el cálculo.

Voy a buscar desde qué valores descarta para usar los mismos, creo que es lo más coherente.

Iniciado por _GUI_

No he usado nunca las reducciones de ruido en DCRAW, en realidad solo quito el ruido de color y lo hago en PS. Crees que la mediana de DCRAW lo quitará mejor que PS? la mediana se aplica sobre datos RAW o interpolados? elimina textura?

Lo de la reducción de ruido me parece interesante porque lo hace antes de interpolar y eso no lo vamos a poder hacer después, lógicamente. Lo de la mediana lo hace después de interpolar, así que lo podemos hacer tranquilamente en PS. Era por probar rápidamente si era fácil quitar ese ruido. He probado con Noiseware/Neat Image/Noise Ninja y todos son bastante eficaces quitando los restos de laberintos sin eliminar textura. La mediana la aplica sobre el color no la luminancia, así que no se pierde textura, te pongo un ejemplo:

Imagenes de Canon 350D ISO 100 al 300%, reveladas con:

dcraw -v -q 3 -o 2 -g 2.2 -T -4 -l 1

De arriba a abajo y de izquierda a derecha son las siguientes:

• Sin mediana, con 1 paso de mediana (-m 1), con 10 pasos de mediana (-m 10).
• Las mismas tres contrastando para ver mejor el ruido.
• Noiseware, Noiseware contrastado, con 10 pasos de mediana + Noiseware y contrastado.

Un saludo:

Iniciado por ManuelLlorens

meiker, ¿puedes mandarme el raw de la imagen que muestras por correo a manuelllorens@gmail.com?

¿Has probado con la última versión, la que te pone compilado por al ejecutarla sin parámetros? Porque ayer cambié algunas cosillas a última hora. En cualquier caso está claro que hay que probar los cambios con más imágenes de más cámaras a ver qué pasa.

Un saludo:

Manuel te he enviado un correo, para que te puedas descargar el RAw-Orf. Mi foto anterior revelada con parametro:
-v -o 2 -q 3 -4 -T -t 270 -l 1 -g 2.2

Respecto a este comentario

" ¿Has probado con la última versión, la que te pone compilado por al ejecutarla sin parámetros?",

yo solo veo una version compilada de dcraw.exe, esta:
http://www.llorensvazquez.jazztel.es/dcraw.exe

y no se que me estas diciendo de eso de sin parámetros. no se muy bien a que te refieres?

salu2

Muchas gracias, ya te he contestado por mail... y te he vuelto a contestar. Lo siento ;-)

Un saludo:
_________________________________
He querido asegurarme que los restos de laberintos que se observan después de usar -a o -l para equilibrar los canales verdes son causa, como digo más arriba, de la interpretación que AHD realiza del ruido de la imagen.

Para ello he alimentado a dcraw con un gradiente sintético, generado dentro del propio dcraw. De ese modo podemos observar el resultado de las distintas opciones sobre una imagen pura. Cuando realice la comparativa de opciones de dcraw meteré imágenes reales y sintéticas.

Los resultados son los siguientes, de arriba a abajo y de izquierda a derecha (al 300%):

• Gradiente sin ruido y con G1=G2 interpolado con AHD.
• Gradiente sin ruido con G1>G2 sin compensar interpolado con AHD.
• Gradiente sin ruido con G1>G2 compensado con -l 1 interpolado con AHD.
• Gradiente con ruido y con G1=G2 interpolado con AHD.
• Gradiente con ruido y con G1>G2 compensado con -l 1 interpolado con AHD.
• Gradiente con ruido y con G1=G2 interpolado con VNG.

Es curioso lo extremadamente efectivo que es AHD detectando tendencias, como se ve en la segunda imagen de arriba.

Por otro lado, como yo suponía, los restos de laberintos son la interpretación que AHD realiza del ruido, por lo que en la tercera imagen de arriba no queda señal de laberintos y al añadir ruido vuelven a aparecer. Finalmente, en la tercera de abajo se ve como VNG realiza una interpretación del ruido sin laberintos. Por cierto, AHD crea un ligerísimo banding en imágenes con gradientes suaves, mientras que VNG no.

Por cierto, alguno de los cambios que he hecho se ha cargado la reducción de ruido de dcraw. Tendré que arreglarlo . Sigo pensando que lo ideal cuando usemos AHD en imágenes ruidosas será quitar un poco de ruido antes de la interpolación. De momento, si se especifica la opción -n o la opción -h se desactiva la opción -l.

He subido la versión 0.82 con estos cambios y ya funciona en la imagen de prueba de meiker10. Si os salen los gradientes lo he arreglado a las 12:35, descargad de nuevo.

Un saludo:

Manuel:


1. He probado el revelado con la v0.82 y el revelado con gamma sRGB no funciona, cuando se escoge -g srgb (ó -g 0), se anula la opción -o que hayamos escogido y la salida es siempre no interpolada y sin gamma alguna, o sea como si pusiéramos -o 0.
También lo que te he comentado: que -g es ignorado cuando se elige -o 0, no le veo mucha utilidad pero si se pudiera añadir pues mejor que mejor.


2. La opción -l 1 no me funciona bien:

altera al balance de blancos automático posterior arrojando un valor astronómico de ajuste de G1 que provoca los laberintos extremos de antes:

C:\>dcraw -v -a -l 1 -o 4 -q 3 -T -4 -g 1.8 chica.cr2
Loading Canon EOS 350D DIGITAL image from chica.cr2 ...
Equilibrating green channels with mode G1->G2. G2-G1 distance -646.703856
Scaling with darkness 256, saturation 4095, and
multipliers 1.967032 356.760651 1.304544 1.000000
AHD interpolation...
Converting to ProPhoto D65 colorspace using gamma 1.8 ...
Writing data to chica.tiff ...


3. La reducción de ruido de color con mediana tiene buena pinta, creo que voy a empezar a hacerla. Aunque no tengo clara la interpretación del parametro de -m, que son píxels alrededor del afectado? y como no afecta a la textura?


Por cierto tiene narices que no pueda acceder a los links en jazztel eh? por qué será?

La nueva versión es 0.83:

• He arreglado lo de la opción -l, que a mí sí me funcionaba y al resto no por las opciones que ponía al compilador.
• He arreglado la gamma sRGB, que no hacía prácticamente nada, de esos errores tontos por programar a las 2 de la mañana .
• Ya funciona la gamma con cualquier espacio de color de salida, es decir, se puede hacer -o 0 -g 2.2 perfectamente.
• He corregido los textos en modo verbose -v.
• Sigue sin funcionar la reducción de ruido -n si se especifica -l, por lo que se ignora la segunda opción en ese caso. Estoy con ello.

Cosas que quedan por hacer (más esas que están fermentando en vuestros cerebros):

• No veo la manera de meter la gamma en las cabeceras TIFF porque no se mete como un simple valor sino como una tabla LUT completa. Demasiado trabajo, aunque ahí está para el futuro.
• Sigo preguntando a _GUI_ sobre la posibilidad de incorporar directamente los perfiles de Hugo al programa. ¿Es posible? ¿Útil? ¿Habría que preguntarle a él?
• Os pregunto también si os parece interesante la opción de revelar solo un trozo para los previews de los GUI que creemos.
• Tengo pendiente la opción rara de que dcraw dé una opción de salida a 32 bits. Pero no es una prioridad en absoluto.
• Se me ocurre un algoritmo de interpolación adaptativo que consista en lo siguiente:
  • Se interpola en VNG y en AHD. Se crea un mapa de contraste del revelado VNG y en las zonas de bajo contraste se elige VNG y en las de contraste medio o alto AHD. De ese modo sin quitar ruido evitamos laberintos y posibles bandas en zonas suaves y mantenemos todo el detalle que obtiene AHD. ¿Qué tal suena?

Eso es todo de momento. Un saludo:

Macho eres un fenómeno, muchas gracias voy a probar esa gamma sRGB.
El perfil de Hugo en realidad es un sRGB con gamma exacta, o sea que ya está metido. Yo decía de usarlo al principio para asignar los revelados resultantes de usar -g 2.2 cuando aun no habías metido el -g srgb, pero ahora ya ni hace falta.

Lo de la gamma en el TIFF es una floritura, si no es obvio implementarlo da lo mismo.

Un saludo.

A ver, he probado el -g srgb, veo dos fallitos:

1. Los niveles saturados se van a cero (imagino que es terminación de la tabla): ver marco de ventana y luces del techo



2. Se forma como una discontinuidad, quizá en la zona de empalme entre el tramo recto y la parte final curva? es el pico de la parte inicial (el del origen no, el otro más ancho)



Por lo demás tiene buena pinta, aunque en la zona de luces no es 100% igual que cuando en PS convertimos a sRGB, lo que me hace pensar que PS hace alguna aproximación pasando de la expresión original. O si usaste la LUT de DCRAW entonces quizá fue Coffin quien hizo una aprox. rápida?

Utilicé mi propia LUT, la de Coffin es para 8 bits y prefiero no tocar su código. Hasta ahora, salvo por la función main() y la convert_rgb() no he tocado nada suyo. Voy a intentar separar su código y el mío al 100%.

Revisaré el código de sRGB porque ya había cometido algún fallo en él y seguro que hay alguno más. En cualquier caso la LUT sRGB de Coffin para 8 bits NO es igual a la que me pasaste, no sé si es por ser para 8 bits o porque la ha aproximado.

Este es el código de la gamma sRGB:

float factor = 1/65535.;
gammaexp = 1.0/2.4

FORC3 {
if(CLIPF(img[c])*factor<=0.0031308)
img[c]=CLIP((int) 65535.0*(CLIPF(img[c])*factor*12.92));
else img[c]=CLIP((int) 65535.0*(pow01(1.055*CLIPF(img[c])*factor,gammaexp)-0.055));

Acabo de ver el fallo al copiarlo aquí... lo que decía un error de 2 de la mañana.

FORC3 {
if(CLIPF(img[c])*factor<=0.0031308)
img[c]=CLIP((int) 65535.0*(CLIPF(img[c])*factor*12.92));
else img[c]=CLIP((int) 65535.0*(1.055*pow01(CLIPF(img[c])*factor,gammaexp)-0.055));

Lo demás parece que va bien, ¿verdad? Ya está subida la versión con sRGB corregida.

Un saludo:

Iniciado por ManuelLlorens

Utilicé mi propia LUT, la de Coffin es para 8 bits y prefiero no tocar su código. Hasta ahora, salvo por la función main() y la convert_rgb() no he tocado nada suyo. Voy a intentar separar su código y el mío al 100%.

Revisaré el código de sRGB porque ya había cometido algún fallo en él y seguro que hay alguno más. En cualquier caso la LUT sRGB de Coffin para 8 bits NO es igual a la que me pasaste, no sé si es por ser para 8 bits o porque la ha aproximado.

Lo demás parece que va bien, ¿verdad?

Está de pm.

El -l me di cuenta de que usado juntamente con -a hace que los multiplicadores del balance de blanco cambien muy ligeramente; cosa totalmente lógica pues el -a tendrá su propio algoritmo que se aplica sobre lo que le entregas con -l. Tal como lo veo -l con -a no aporta nada, pero con cualquier otro balance de blancos (donde finalmente m2=m4) -l es la única garantía de minimizar los laberintos del AHD.

Supongo que Coffin usó una aproximación, y que PS usa otra. Creo que lo suyo es ser académico y si somos los únicos que aplicamos la curva sRGB oficial pues bienvenido sea; yo me fío de lo que diga Bruce Lindbloom, vaya tipo.

Cuando tengas todo funcionando le insisto a Coffin a ver si se anima a poner la gamma por lo menos en el DCRAW oficial, aunque me da que no, el tío tiene muy claro que la gamma no pinta nada ahí de cara a incrementar la riqueza tonal: "Like having a lot of money, a full histogram is a good thing _if_ it's achieved by honest means. Adding random noise to the image would smooth out the histogram quite nicely", como comenté la compara a añadir ruido así que no le tiene mucha estima.

He aquí la respuesta (de la documentación del programa dng_validate del DNG SDK de Adobe):

The “-b4” option causes the demosaic algorithm to produce a four channel output rather than a three channel one. (The input DNG must be a three channel Bayer pattern image.) This option is only useful when used with the -3 switch. The extra channel is the result of doing two interpolations of the Bayer green channel such that the greens on the same row as the reds produces one channel and the greens on the same row with the blues produce another channel. The second green channel will be the highest numbered channel in the output. This option is used to gauge the difference between greens in each row to decide whether the DNG BayerGreenSplit tag should be used for a given source of image data (e.g. camera).

Es decir, que Adobe (como era de esperar) ya sabía que los dos canales verdes difieren en algunas cámaras y por eso sus programas nunca producen laberintos.

Un saludo:
_________________________________
Pues eso, en la última versión que he subido ya funciona la opción -l de quitar laberintos con las opciones -n para quitar ruido antes de interpolar y la opción -h, la de revelar a mitad de tamaño.

Para usar el parámetro -n hay que especificar valores bastante altos, 50, 100, 150, 200, 250, etc.

_GUI_ se preguntaba si el parámetro -m afectaba a la textura. Viendo el código es imposible deducirlo, yo diría que una poca. Es mejor probarlo empíricamente.

La primera imagen es la flor de antes revelada (vista al 250%) sin ninguno de estos parámetros. La segunda es revelada con -l 3, y a su lado la diferencia con la imagen original, diferencia muy amplificada. La tercera es con los parámetros -l 3 -m 3 y la diferencia con la segunda. La cuarta está revelada con -l 3 -m 3 -n 100 y su diferencia con la tecera.

Insisto en que las diferencias están muy exageradas y no necesariamente en la misma escala, lo que buscaba es ver si se elimina textura. Eso es todo por hoy.



Un saludo:

La ultima da la sensacion de estar mas lavada, lleva la reduccion de ruido -n 100. está tambien menos contrastrada.

La tercera que lleva el filtro de mediana 3 pasos -m 3, no me parece que pierda muchas texturas respecto a la segunda ,donde se le han eliminado los laberintos respecto a la original.

Gracias por el trabajo y salu2

La gamma sRGB impecable, ahora sí que sí:

dcraw -o 1 y convertido a sRGB gamma 2.2 en PS:


dcraw -o 1 -g 2.2 y asignado directamente a sRGB en PS:


Las imágenes a primera vista indistinguibles. Por cierto acabo de subir esa foto que es un retrato quemado aquí, la recuperación de altas luces de DCRAW para brillos en la piel simplemente genial.

Felicidades Manuel.

Muchas gracias _GUI_ y meiker10. Ahora voy a centrarme en las otras mejoras. He estado haciendo pruebas en PS con lo de la máscara de contraste para elegir entre AHD y VNG.

Mi conclusión es que merece la pena si la imagen tiene ruido porque es más fácil quitar la interpretación que VNG hace del ruido, que la que hace AHD, como he mostrado más arriba. Pero creo que lo ideal es hacerlo desde PS porque da mayor nivel de control. La propuesta sería algo así:

• Se revela con AHD.
• Se revela con VNG.
• Se cargan ambos archivos como capas, AHD debajo, VNG arriba.
• Se duplica la capa VNG. Se crea un mapa de contraste sobre la capa VNG mediante un paso alto o un filtro custom. Yo he utilizado uno de este tipo para una prueba rápida, pero hay que calcularlo mejor:

0 1 2 1 0
1 2 4 2 1
2 4 -40 4 2
1 2 4 2 1
0 1 2 1 0

• Se desatura el mapa, y se autoajustan niveles.
• Se puede pasar umbral sobre el mapa de contrate o dejar zonas de transición suaves.
• Se utiliza el resultado como máscara para la capa VNG.

Sé que es bastante obvio y un poco pedestre, pero creo que puede ayudar en algunos casos. Sigo creyendo que para que AHD funcione bien la imagen original no puede tener ruido... no ruido, cero ruido... ¿a qué me suena eso?

Un saludo:
_________________________________

Iniciado por meiker10

La tercera que lleva el filtro de mediana 3 pasos -m 3, no me parece que pierda muchas texturas respecto a la segunda ,donde se le han eliminado los laberintos respecto a la original.

Los resultados, yo creo que muy aconsejables, del filtro de mediana se observan mucho mejor en los bordes. La imagen que he subido no tenía bordes muy definidos. Si pruebas con la tú mismo me enviaste verás muchos menos colores raros.

Un saludo:

He estado haciendo pruebas similares a las de Gui, sobre el Gamma 2.2 en photoshop y dcraw -g 2.2 y espacio Argb1998, y al igual que a él, en la conversion de photoshop aparecen esas crestas especialmente en el canan verde en mi foto de prueba, mientras la conversion gamma 2.2 realizada por dcraw es mucho mas continua sin tantos altibajos.

Realmente me sorprendido bastante.

Probaré Manuel lo del filtro de mediana

ya veo que vamos por la version 0.85

salu2

El número de versión empezó en un valor tal que pudiera llegar a 1.0 cuando acabáramos de hacer los cambios, o sea, al revés de lo que sería lógico .

Si encuentro fallos los iré juntando para asegurarme que no me paso de 1 .

¿Cutre, eh?

Un saludo:

Iniciado por _GUI_

Sin embargo una codificación lineal, si se realiza a 16 bits (enteros) y no a 32 bits (coma flotante), implica una menor riqueza tonal de las sombras y un histograma en definitiva menos robusto en las mismas con menos niveles tonales; la gamma es un seguro ante problemas de cuantización. Entonces por qué no permitir una opción en DCRAW que aplique la gamma antes de redondear los niveles a enteros de 16 bits si es lo que el usuario quiere?

Allá vamos! Me he leído el artículo y el hilo entero para ver qué se comenta acerca de este tema. Me he dado cuenta de que no se comentan ciertas cosas que para mí me parecen básicas y por ello no consigo entender lo que comentais.

Entonces, para empezar, comentar que no tengo conocimientos de teleco, aunque me flipa vuestra profesión. Así que quiero entender y lo mejor es empezar por el principio.

Entiendo la base de que la cámara capta de modo lineal y los monitores siguen utilizando la compensación de gamma para producir la misma luminosidad de entrada que de salida.

Ahora bien, lo que comentas en la cita que pongo arriba, ya no lo sigo. La codificación lineal a 16 bits, a 32 bits, la gamma es un seguro ante problemas de cuantización, etc etc. Todo esto ni pa pa. Si es posible explicar de una manera más ordenada, es decir, todo el proceso por el cual pasa la imagen cuando llega a dcraw en forma de valores rgb desde la cámara. Qué es realmente codificar a 16 o 32 bits? Por qué lo de los enteros a 16 y coma flotante a 32? Etc

Iniciado por _GUI_

Lo he discutido varias veces con Coffin y no cae del burro, dice que ésa no es una forma legítima de obtener mayor riqueza tonal y la compara con el suavizado del histograma cuando desenfocamos una imagen o añadimos ruido. Pero no estoy en absoluto de acuerdo: si no redondeamos los niveles de la imagen a valores enteros hasta el final, aplicar la gamma antes de dicho redondeo nos da mayor riqueza tonal real y también mayor precisión real en los niveles codificados.

Aquí lo mismo, estaría bien saber el proceso por el que pasa la imagen. Porque no entiendo eso del redondeo, que si se aplica antes o después, a qué se refiere con el redondeo y por qué se realiza....
Como veis, un lío del copón el que tengo!!!

Tampoco entiendo la razón de Coffin, pero no desde el punto de vista de saber lo que está haciendo, sino por defender que eso no es legítimo? Eso quiere decir que no es correcto o que no debe hacerse así?

De todas formas, agradeceros este minituto y todos los demás que habeis escrito, que son geniales para aprender. Sobre todo porque para cualquier pregunta estais dando la respuesta en un ti ta!

Saludos!

Iniciado por poleteiep34

Ahora bien, lo que comentas en la cita que pongo arriba, ya no lo sigo. La codificación lineal a 16 bits, a 32 bits, la gamma es un seguro ante problemas de cuantización, etc etc. Todo esto ni pa pa. Si es posible explicar de una manera más ordenada, es decir, todo el proceso por el cual pasa la imagen cuando llega a dcraw en forma de valores rgb desde la cámara. Qué es realmente codificar a 16 o 32 bits? Por qué lo de los enteros a 16 y coma flotante a 32? Etc

Los RAW actuales que llamamos de 12 bits son capaces de codificar números que van desde el 0 al 4095 (4095 es 2 elevado a 12).
En 16 bits puedes codificar números del 0 al 65535 (65535 es 2 elevado a 16).

Pero se trata de números enteros, es decir que entre el 0 y el 1, no podemos asignar el nivel 0.5, o redondeamos a 0 o a 1.

En cambio nada impide con un ordenador representar los números con decimales, lo que permitiría discernir muchos más valores posibles entre cada 2 números enteros: entre el 0 y el 1 estarían 0.0001, 0.0002, 0.0003 y todos los que puedas imaginar. El único coste de hacerlo es usar más bits, por eso decía lo de los 32 bits.

Eso por un lado. Por otro lado tenemos que por linealidad del sensor, éste dedica menos definición a las sombras, las cuales si se codifican en números enteros tendrán una definición peligrosamente baja en los diafragmas más oscuros (fíjate como al diafragma más alto se dedican 2048 niveles, cuando el quinto por ejemplo ya solo tiene 128 y el octavo 16):

0EV: 2048 niveles, 2048..4095
-1EV: 1024 niveles, 1024..2047
-2EV: 512 niveles, 512..1023
-3EV: 256 niveles, 256..511
-4EV: 128 niveles, 128..255
-5EV: 64 niveles, 64..127
-6EV: 32 niveles, 32..63
-7EV: 16 niveles, 16..31
-8EV: 8 niveles, 8..15
-9EV: 4 niveles, 4..7
-10EV: 2 niveles, 2..3
-11EV: 1 nivel, 1

Lo anterior hace referencia al RAW, y no lo podemos cambiar.

Pero sí podemos elegir cómo editar la imagen, y ahí entra en juego la compensación gamma que expande las sombras haciendo que a los diafragmas bajos les correspondan muchos más niveles que si no se aplicara dicha compensación gamma, sustrayendo esos niveles de los diafragmas altos donde íbamos sobrados.
Así la compensación gamma es una medida que sirve para reducir el efecto que va a tener en la imagen codificada con enteros el redondeo de los niveles cuando hagamos operaciones sobre ésta.

Pero aplicar la gamma tiene un precio: la imagen pierde su condición lineal, que le confería ventajas.


Así usar números con decimales de 32 bits nos da lo mejor de los dos mundos: la imagen es robusta en las sombras frente a errores de redondeo (como lo es la imagen de 16 bits con gamma), pero no perdemos la linealidad de los datos.

___________


Coffin en su revelador genera una salida entera de 16 bits, pero los cálculos intermedios los hace con decimales de 32 bits. Su idea es darte la imagen lineal en 16 bits (sombras poco robustas si te pones a editarlas) y si tú quieres deslinealizarla lo has de hacer en PS.
Yo lo que digo es: ya que tenemos la imagen lineal en 32 bits, por qué antes de redondearla a enteros de 16 bits no aplico la gamma y así me evito la numerosa pérdida de niveles por redondeo? la iamgen resultante en enteros de 16 bits pero con la gamma aplicada debiera ser más robusta que si revelamos en enteros de 16 bits sin gamma y aplicamos la gamma en PS.

Es un poco lío, pero bueno ése es el motivo.

Iniciado por _GUI_

En cambio nada impide con un ordenador representar los números con decimales, lo que permitiría discernir muchos más valores posibles entre cada 2 números enteros: entre el 0 y el 1 estarían 0.0001, 0.0002, 0.0003 y todos los que puedas imaginar. El único coste de hacerlo es usar más bits, por eso decía lo de los 32 bits.

Pero si la cámara nos da los valores en 12 bits, esto quiere decir que da los valores en enteros? Digo porque si tienes valores enteros, qué mas da trabajar a más bits si un valor de 1 es lo mismo que 1.0000. Con esto quiero decir, que aunque utilices más bits el valor 1 sigue siendo 1, da igual cuantos decimales le pongas. Otra cosa quizás sería, a la hora de hacer los escalados u otras operaciones matemáticas en las que sí que se crean números de coma flotante a partir de estos los enteros. Es por esto?

Pero sí podemos elegir cómo editar la imagen, y ahí entra en juego la compensación gamma que expande las sombras haciendo que a los diafragmas bajos les correspondan muchos más niveles que si no se aplicara dicha compensación gamma, sustrayendo esos niveles de los diafragmas altos donde íbamos sobrados.

Cuando dices sustrayendo esos niveles de los diafragmas altos, te refieres a que por la forma que tiene la curva de compensación (esa zona no tan lineal que tiene sRGB standard frente al sRGB al principio de la curva) se consigue utilizar valores correspondientes a diafragmas más altos?

Otro asunto que no me queda claro:
Si las cámaras captan a 12bits, el utilizar 16bits (en caso de PS?) o 32bits (en caso de DCRAW) se hace automáticamente para realizar los cálculos?

Así la compensación gamma es una medida que sirve para reducir el efecto que va a tener en la imagen codificada con enteros el redondeo de los niveles cuando hagamos operaciones sobre ésta.

Es decir, cuando por ejemplo desde DCRAW, que realiza los cálculos a 32 bits pero la salida la da en gamma 1 (esto es lineal no?) a16 bits necesita redondear los valores. Es en este punto donde comentas que quizás se estén perdiendo los valores reales, que sobre todo afectan a las sombras por los pocos niveles presentes? Y que esto no sucedería si seguimos a 32 bits y después aplicamos la gamma compensada?

Yo lo que digo es: ya que tenemos la imagen lineal en 32 bits, por qué antes de redondearla a enteros de 16 bits no aplico la gamma y así me evito la numerosa pérdida de niveles por redondeo? la iamgen resultante en enteros de 16 bits pero con la gamma aplicada debiera ser más robusta que si revelamos en enteros de 16 bits sin gamma y aplicamos la gamma en PS.

Una pregunta quizás un poco tonta, pero que no acabdo de entender: ¿Por qué no trabajamos en imagenes de 32 bits y aplicamos la gamma? Así nos ahorraríamos el tema del redondeo y se utilizan los niveles más altos para los niveles bajos.

Iniciado por poleteiep34

Pero si la cámara nos da los valores en 12 bits, esto quiere decir que da los valores en enteros? Digo porque si tienes valores enteros, qué mas da trabajar a más bits si un valor de 1 es lo mismo que 1.0000. Con esto quiero decir, que aunque utilices más bits el valor 1 sigue siendo 1, da igual cuantos decimales le pongas. Otra cosa quizás sería, a la hora de hacer los escalados u otras operaciones matemáticas en las que sí que se crean números de coma flotante a partir de estos los enteros. Es por esto?

El RAW contiene enteros de 12 ó 14 bits, pero todo el proceso que se hace hasta obtener el revelado básico es en coma flotante de 32 bits (o más, dependerá de la aplicación), tanto en DCRAW como en cualquier revelador. No hacerlo sería una torpeza. Para que lo entiendas el esquema sería:

RAW enteros de 12/14 bits -> conversión a decimales de 32 bits -> proceso de revelado (balance de blancos, interpolación, conversión a un espacio de color,...) -> redondeo a enteros de 16 bits -> Compensación gamma (creando huecos en las sombras)

El esquema del DCRAW con gamma:
RAW enteros de 12/14 bits -> conversión a decimales de 32 bits -> proceso de revelado (balance de blancos, interpolación, conversión a un espacio de color, compensación gamma (no crea más huecos en las sombras de los inevitables)...) -> redondeo a enteros de 16 bits

Y el esquema que sería ideal, sin ninguna compensación gamma:
RAW enteros de 12/14 bits -> conversión a decimales de 32 bits -> proceso de revelado (balance de blancos, interpolación, conversión a un espacio de color,...) -> edición en decimales de 32 bis

Iniciado por poleteiep34

Cuando dices sustrayendo esos niveles de los diafragmas altos, te refieres a que por la forma que tiene la curva de compensación (esa zona no tan lineal que tiene sRGB standard frente al sRGB al principio de la curva) se consigue utilizar valores correspondientes a diafragmas más altos?

no, cualquier curva de compensación gamma va a hacer esto, no solo la sRGB. Al expandir las sombras y comprimir las luces (como toda curva con esa forma), tenemos más niveles para representar un determinado rango inicial de sombras, y menos niveles para representar un determinado rango inicial de luces.

Iniciado por poleteiep34

Si las cámaras captan a 12bits, el utilizar 16bits (en caso de PS?) o 32bits (en caso de DCRAW) se hace automáticamente para realizar los cálculos?

sí, es como están hechos ambos programas. De hecho PS trabaja a 15 bits, no a 16.

Iniciado por poleteiep34

Es decir, cuando por ejemplo desde DCRAW, que realiza los cálculos a 32 bits pero la salida la da en gamma 1 (esto es lineal no?) a16 bits necesita redondear los valores. Es en este punto donde comentas que quizás se estén perdiendo los valores reales, que sobre todo afectan a las sombras por los pocos niveles presentes? Y que esto no sucedería si seguimos a 32 bits y después aplicamos la gamma compensada?

Lineal es en realidad ausencia de gamma. Pero sí, se puede entender como gamma=1 claro.
Lo que hemos hecho es aplicar la gamma en DCRAW antes de hacer el redondeo final de decimales de 32 bits a enteros de 16 bits.

Iniciado por poleteiep34

Una pregunta quizás un poco tonta, pero que no acabdo de entender: ¿Por qué no trabajamos en imagenes de 32 bits y aplicamos la gamma? Así nos ahorraríamos el tema del redondeo y se utilizan los niveles más altos para los niveles bajos.

Trabajar en 32 bits con decimales sería lo ideal, precisamente es lo que una serie de gente quiere promover. PS y todos sus plugins están históricamente diseñados para trabajar con enteros de 16 bits, y cambiar eso no es fácil. Además que para un procesado medio la diferencia no se notaría.
Si tuviéramos una herramienta que trabaje con decimales de 32 bits, aplicar la gamma ya pierde su sentido; no nos haría ganar nada y perderíamos las cualidades lineales de la imagen.
P.ej. subir la exposición de un píxel RGB=(10.6, 22.0, 60.5) en un paso de diafragma sin que sufra ningún cambio de tono, saturación o contraste es tan sencillo como multiplicar sus niveles por 2: RGB=(21.2, 44.0, 121.0). Esto solo es así trabajando en lineal.

En el power point que puedes bajarte de REVELADO LINEAL CON DCRAW, se explica el proceso preciso que sigue el RAW en su revelado.

Salu2

Iniciado por ClinSbud

Yo me puedo apuntar para servir el café mientras vosotros tecleáis como posesos. De programación: ná de ná. Me quedé en Fortran y gracias... Me encantan estos temas. Gui lo sabe, a veces no es que vea halos, es que no me entero de nada de lo que decís. Eso sí, me empapo de todo lo que escribe porque algo de lo que enseña se me quedará en la mollera.
Estaré al tanto del post, que parece que mola.
Saludos

Fortran! eres de los míos

Gracias _GUI_, creo que con esto tengo suficiente para digerir por el momento. Con vosotros se aprende una pasada!!!

Una interesantísima exposición, GUI. Muy clara, como siempre.
La verdad es que yo ya me había planteado por qué se seguía utilizando la gamma para manejar las imágenes en PS.
Si la gamma era un tema del monitor (para ajustar la forma en que el monitor genera la luminosidad de los pixels a la forma de ver del ojo humano) pues lo lógico sería hacer esto en el momento de aplicar el perfil de color y no antes (igual que cambiamos los valores de color según la impresora o dispositivo de salida en el momento de imprimir).

Ahora me ha quedado claro que el aplicar la gamma en vez de trabajar con imágenes lineales permite que las sombras sean más robustas frente a las manipulaciones de los algoritmos de PS.

Claro que si se trabajara en coma flotante 32 bits, lo lógico sería trabajar con imágenes lineales.
¿Cuando dices que trabaja en decimales te refieres a coma flotante o a números reales con representación decimal en vez de coma flotante como el IEEE? Es mera curiosidad.

Iniciado por ariznaf

¿Cuando dices que trabaja en decimales te refieres a coma flotante o a números reales con representación decimal en vez de coma flotante como el IEEE? Es mera curiosidad.

me refiero a la coma flotante claro, es para que se entienda de qué va eso. pero bueno al fin y al cabo qué es la coma flotante sino números reales con representación decimal no?
_________________________________

Iniciado por ariznaf

Si la gamma era un tema del monitor (para ajustar la forma en que el monitor genera la luminosidad de los pixels a la forma de ver del ojo humano) pues lo lógico sería hacer esto en el momento de aplicar el perfil de color y no antes (igual que cambiamos los valores de color según la impresora o dispositivo de salida en el momento de imprimir).

Claro, la gamma con justificación en el comportamiento no lineal del monitor se puede aplicar en múltiples sitios: el software del sistema operativo, en la salida última de la tarjeta gráfica, en el programa de edición gráfica (en PS tú puedes entrar en los ajustes de color y especificar gamma 1.0 para que la imagen se vea con el brillo correcto),... en cualquier sitio menos en los propios datos de nuestra imagen? que no tiene porqué perder su linealidad.

Pero cuidado que la gamma no tiene su origen ni su razón de existir en la forma de ver del ojo humano, sino en la no linealidad de los dispositivos (monitores). Piensa que si una cámara capta imágenes lineales y los datos del RAW revelado fueran "inyectados" tal cual en un monitor que fuera lineal, la veríamos igual que veíamos la escena original; nosotros y un extraterrestre, independientemente de como funcionara su sistema visual porque cámara lineal + monitor lineal no haría sino producir una salida de luminosidad proporcional a la escena original: COMPENSACIÓN GAMMA. DCRAW CON GAMMA.

Lo de la coma flotante lo decía porque en C# hay otro tipo de numeros Decimal con una representación completamente diferente del IEEE del float y que se supone que tienen una mayor precisión a la hora de representar número en base 10 (ya que no es una representación binaria). La ventaja es que 1/10 es exactamente 1/10 que en representación binaria no se puede representar de forma exacta.
Claro que otros números no tendrán una respentación exacta en base 10.

Pero cuidado que la gamma no tiene su origen ni su razón de existir en la forma de ver del ojo humano, sino en la no linealidad de los dispositivos (monitores). Piensa que si una cámara capta imágenes lineales y los datos del RAW revelado fueran "inyectados" tal cual en un monitor que fuera lineal, la veríamos igual que veíamos la escena original; nosotros y un extraterrestre,

Como casi siempre (me niego a decir siempre ) tienes razón. Ya lo había leído, pero se me escapó lo de la forma de ver el ojo, pues es algo muy arraigado en los artículos de internet.

Como todo sabeis.. jejeje (qué iluso¡¡¡¡)

Estoy trabajando en la adaptación del programa Zero Noise pero nativo para linux.

He estado bicheando muchas cosas, y quería aprovechar para proponer una mejora:

Donde el código dice:

FORC3 img[c] = CLIP((int) 65535.0*pow(out[c]/65535.0,1/user_gamma));

probad a poner:

FORC3 img[c] = (int) floor( 65535.0*pow(out[c]/65535.0, 1/user_gamma)+ 0.5);

produce ["casi"] los mismos resultados pero es una rutina entre un 18% y un 20% más rápida.


En realidad, si quitamos el +0.5 de la formula propuesta, produce exactamente los mismos resultados menos para cuando out[c] contiene el valor 65535, entonces para la primera formula el resultado es 0 y para la segunda formula (la propuesta) es otra vez 65535.

Vamos, en realidad habría que quitar el +0.5 ese de la formula jejeje y encima sería algo más rápida.

resumiendo, probad con:

FORC3 img[c] = (int) floor( 65535.0 * pow( out[c]/65535.0, 1/user_gamma) );


Muac

Alguien tiene una idea de por que en ocasiones me aparecen las fotos así.

Leí con calma este post pero es muy avanzado para mi que soy aun aficionado. Me comentaron que podría ser la tarjeta pero aun con tarjeta nueva lo sigue haciendo.

Tengo una canon eos 1ds de las viejas de 11mpx.

Agradecería cualquier comentario.

">