5D : rango dinamico y bits

[Guillermo Luijk]

y aquí hablaría de la nueva Leica FF, que sólo tiene 18 megapíxles, creo: si alguien me presta 6.000 euros para probarla..

De los RAW que me han pasado, te diré que el sensor Kodak no es para tirar cohetes en cuanto al ruido; cualquiera de las >20Mpx (Sony, Canon, Nikon) tiene menos ruido. Lo que pasa es que al no llevar filtro AA y encima con las lentes que se gasta la gente que tiene esas cámaras, la necesidad de enfoque se reduce drásticamente por lo que el ruido no se realza tanto compensando lo uno por lo otro.

[camacu]

Vere si puedo obtener un conversor de Raw de 14 a 12 de alguna manera sino tratare de programarmelo yo mismo cuando tenga tiempo. Me da mucha curiosidad que 2 bits extras que al final alentizan el procesado, y hacen ocupar mas espacio, realmente no sirvan de nada en niguna imagen ni combinacion de fstop/iso/shutter ni oscuros/claros. No tiene mucho sentido ( ni siquiera por marketting ).

De todas formas entiendo las explicaciones que dais, no es que no las crea, tienen sentido pero me queda la duda.

[Aod8181]

Vere si puedo obtener un conversor de Raw de 14 a 12 de alguna manera sino tratare de programarmelo yo mismo cuando tenga tiempo. Me da mucha curiosidad que 2 bits extras que al final alentizan el procesado, y hacen ocupar mas espacio, realmente no sirvan de nada en niguna imagen ni combinacion de fstop/iso/shutter ni oscuros/claros. No tiene mucho sentido ( ni siquiera por marketting ).

De todas formas entiendo las explicaciones que dais, no es que no las crea, tienen sentido pero me queda la duda.

Si por lo que yo tengo entendido no es que no sirvan, sino que lo que generan son dos bits "no reales" o efectivos. Por tanto es como cuando se añaden otros dos bits al PS, para procesarlo.

Lo del marketing es simplemente que el sensor si soporta 14 bits, pero no puede llegar a procesar los 14 bits efectivos, sino 12 (aprox) porque el captor no le da esos 14 bits efectivos. Por tanto, tampoco mienten al decir que su sensor es de 14 bits, lo que no dicen es que no es capaz de captarlos, debido al ruido producido. Ni mas ni menos. Y en eso se centra el marketing sin mas. Por poner un ejemplo, es como la letra pequeña de algunos articulos que ponen en la tele o en publicidad.

[garjor]

Aparte de que los datos signifcativos sean 12 o 14 bits, se almacenen en "unidades" de 16 bits porque es mas rapido trabajar con ellas, es un tema del hardware de los procesadores etc.

[Guillermo Luijk]

Si por lo que yo tengo entendido no es que no sirvan, sino que lo que generan son dos bits "no reales" o efectivos. Por tanto es como cuando se añaden otros dos bits al PS, para procesarlo.

No, sí que son bits reales. Es un valor del conversor A/D, es decir el conversor A/D realmente filetea la señal analógica que le llega en 2^14 niveles. Otra cosa es que la distancia entre 2 niveles contiguos sea menor que el ruido que lleva la propia señal a muestrear, lo que le resta utilidad práctica a hacer un fileteo tan fino.

Es como si tienes un reloj que es una castaña y da la hora con un error aleatorio de entre -5 y +5 min, pero tú te empeñas en informar a quien te pregunta de los segundos que da tu reloj. Puedes hacerlo, pero esos segundos no le van a servir de nada porque el error es de minutos.

Salu2

[Aod8181]

No, sí que son bits reales. Es un valor del conversor A/D, es decir el conversor A/D realmente filetea la señal analógica que le llega en 2^14 niveles. Otra cosa es que la distancia entre 2 niveles contiguos sea menor que el ruido que lleva la propia señal a muestrear, lo que le resta utilidad práctica a hacer un fileteo tan fino.

Es como si tienes un reloj que es una castaña y da la hora con un error aleatorio de entre -5 y +5 min, pero tú te empeñas en informar a quien te pregunta de los segundos que da tu reloj. Puedes hacerlo, pero esos segundos no le van a servir de nada porque el error es de minutos.

Salu2

Ya ya si por eso puse "no reales" entre comillas, y despues lo de efectivos, porque por mucho que se quiera, la propia camara no sabe con exactitud cuales son.

[camacu]

Hacerlo con el código fuente de DCRAW por ejemplo no es muy complicado.

Ok, he leido tu tutorial sobre el DCRAW, aunque va orientado a la usabilidad no a la programacion.

He conseguido el dcraw.c, lo he ojeado.
A simple vista parece que tengo que llamar a esta funcion

void CLASS canon_compressed_load_raw()

Esto con la macro BAYER( ) me rellena un buffer de 16 bits ushort llamado "image"

Ahora entiendo que cada pixel contendra valores que van de 0 a 16383 ( por los 14 bits ), si me cargo los 2 de menos significativos es decir a cada valor aplico... value &= 0xFFFC; y los reseteo a 0, estare convirtiendo la señal a una equivalente a 12 bits?

O tal vez en lugar de eso aplico un desplazamiento a la derecha value >>= 2 con lo que me cargo tambien los 2 bits. llevando el valor de 0 a 4093. Pero entonces en algun otro lugar, debere de cambiar algo indicando que el formato ya no es de 14 bits sino de 12.

Alguna pista al respecto?

Saludos

[Guillermo Luijk]

Ahora entiendo que cada pixel contendra valores que van de 0 a 16383 ( por los 14 bits ), si me cargo los 2 de menos significativos es decir a cada valor aplico... value &= 0xFFFC; y los reseteo a 0, estare convirtiendo la señal a una equivalente a 12 bits?

O tal vez en lugar de eso aplico un desplazamiento a la derecha value >>= 2 con lo que me cargo tambien los 2 bits. llevando el valor de 0 a 4093. Pero entonces en algun otro lugar, debere de cambiar algo indicando que el formato ya no es de 14 bits sino de 12.

Alguna pista al respecto?

Tu idea es correcta, pero con los RAW de Canon quizá no funcione dando resultados impredecibles porque no tienen el nivel de negro en el 0. Es decir, que si una parte de la escena no produce luz (por ejemplo si haces una foto con el objetivo tapado), en el RAW no tienes valores a 0 ó cercanos, sino que estarán entorno a 1024. Los RAW de Canon estrictamente hablando no son lineales hasta que no se les sustrae ese offset de negro.

Yo veo 2 soluciones:
- Usar un NEF de Nikon de 14 bits, que sí tiene el nivel de negro en el 0, y hacer el desplazamiento de 2 bits que sugieres. Luego basta desplazar de nuevo por 2 bits hacia la izq. (es decir, multiplicar por 4), creando los huecos pertinentes.
- Si quieres hacerlo más genérico y que sirva para cualquier cámara, deja que sea DCRAW el que corrija ese nivel de negro y también el punto de saturación, y escale la imagen a 16 bits. Es entonces cuando llegas tú y metes la zarpa: para simular un RAW de 12 bits haces 4 desplazamientos respecto a esos 16 bits.

Esto te recomiendo hacerlo en la función scale_colors(), justo tras aplicar el balance de blancos y la corrección por los valores de negro y saturación:

Código original:

void CLASS scale_colors()
...
for (i=0; i < size*4; i++) {
val = image[0][i];
if (!val) continue;
val -= black;
val *= scale_mul[i & 3];
image[0][i] = CLIP(val);
}

Código trampeado:

void CLASS scale_colors()
...
for (i=0; i < size*4; i++) {
val = image[0][i];
if (!val) continue;
val -= black; (eso es la sustracción del nivel de negro, black>0 en Canon)
val *= scale_mul[i & 3]; (eso es el balance de blancos, incluyendo el ajuste al punto de sat.)
val=Int(val/(2^NBITS))*(2^NBITS)
image[0][i] = CLIP(val);
}

Donde NBITS es el número de bits a diezmar:

NBITS=0: revelado original sin diezmado
NBITS=1: revelado simulando RAW de 15 bits (sin efecto en RAWs de 14 bits)
NBITS=2: revelado simulando RAW de 14 bits (sin efecto en RAWs de 14 bits)
NBITS=3: revelado simulando RAW de 13 bits
NBITS=4: revelado simulando RAW de 12 bits
NBITS=5: revelado simulando RAW de 11 bits
...

No sé si el Int es así en C, pero ya entiendes lo que se pretende hacer: desechar NBITS bits del número entero pero devolviéndolo a su escala de 16 bits.

Venga a ver si te sale.

Salu2

[camacu]

He conseguido generar el EXE de dcraw ( sin ninguna modificacion aun ).

siguiendo tu tutorial ejecuto con estas opciones, que entiendo son las mas adecuadas para lo que intentamos hacer:

-v -w -H 1 -d -r 1 1 1 1 -o 0 -q 3 -4 -T c:\test.cr2

si no me he equivocado, obtengo un TIFF 16 bits sin correccion de gamma, respuesta lineal y practicamente sin haber modificado el raw original.

Ahora he abierto ese tiff 16 bits en PS CS3 extended y sale muy oscuro, como era de esperar, pero aqui vienen 2 problemas:

1.- aplico el custom RGB con gamma 1 y no hay ningun cambio en intensidad, en cambio si lo pruebo con un jpg lo hay, si convierto ese tiff a 8 bits y lo abro con PS tambien hay cambio de intensidad. Esto es normal?

2.- En el tiff parece que he perdido toda informacion de la cromaticidad, es decir, no tengo color, solo tonos de grises. Es normal?

Saludos.

[Guillermo Luijk]

siguiendo tu tutorial ejecuto con estas opciones, que entiendo son las mas adecuadas para lo que intentamos hacer:

-v -w -H 1 -d -r 1 1 1 1 -o 0 -q 3 -4 -T c:\test.cr2

No no, -d hace una extracción RAW escalada (si haces zoom al 100% verás la matriz de Bayer).

Si has logrado compilar y obtener el dcraw.exe, ya lo tienes todo. Haz un dcraw.exe normal (sin la trampa), y otro con la trampa, y aplica al mismo RAW de 14 bits un revelado completo:

dcraw -v -w -o 2 -4 -g 2.2 0 -T c:\test.cr2

(-w: balance de blancos del RAW, -o 2: salida Adobe RGB, -4 -g 2.2 0: salida con gamma estándar 2.2)

Te saldrán dos TIFF con su perfil correctamente incrustado así que solo necesitarás abrirlos en PS reconociendo el perfil que llevan, y para levantar adecuadamante las sombras usar curvas totalmente neutras de exposición como éstas:



Y comparar sombras con sombras a ver si hay diferencias apreciables.

Salu2

[camacu]

Tengo resultados... pongo los pasos que he ido siguiendo...

Raw Original: test.cr2

a ) Abriendola en cualquier visor obtengo:





b) Con el DCRAW he creado 3 ejecutables, uno sin modificar que exporta a 14 bits, otro a 12 bits y finalmente otro a 8 bits, para asegurarme en las pruebas y poder comparar. Ejecuto los 3 ejecutables con los siguientes parametros ( los recomendados por Guillermo ):

DCRAW -v -w -o 2 -4 -g 2.2 0 -T c:\test.cr2

me generan los 3 tiff... con mostrar uno basta por que a simple vista los 3 son iguales:





c) Aplico en el Photoshop con las curvas neutras de exposicion ( entrada 127 salida 255 ) para las 3 imagenes:




d ) Ahora los siguientes pasos son comparar en parejas con la de 14 bits tanto la de 8 como la de 12 bits, aplicando en PS la operacion "differencia" de capas y intensificando los resultados hasta ser visibles:

los CROPs pesan un poco. He guardado a detalle maximo para poder ver el "ruido" sin disimular debido a los artefactos que provoca la compresion JPG:

Resultado (differencia ) de 8bits vs 14bits ( exposicion ligeramente aumentada para ser visible ):





Resultado (differencia ) de 12bits vs 14 bits ( aumentando muchisimo la exposicion ):






Bueno pues despues de ver esto parece razonable concluir que en la differencia de 8bits vs 12bits hay informacion util aparte del ruido, y en la de 12bits vs 14bits es totalmente ruido y por tanto esos 2 ultimos bits son despreciables.

En este punto no se porque pero viendo esos resultados, me he preguntado. ¿ como puedo saber que PS este calculando todo con suficiente precision ?, es mas, yo recuerdo hace tiempo haber visto como las imagenes de 16 bits ( por ejemplo un TIFF ) abriendolas y visualizando los valores, los trata de de 0 a 32767 (15 bits) en lugar de 0 a 65535 (16 bits) y nadie sabe porque. Photoshop es mas un programa de tratamiento de imagen que de laboratorio o de precision. Entonces, de nuevo la duda.... es todo esto fiable?

Pues tras un rato, veo que NO. Segun un compañero de trabajo, especialista en PS, me ha confirmado esta misma tarde que Photoshop trabaja con una precision no muy buena para imagenes de mas de 8 bits.

Asi que solo me queda una opcion, testearlo yo mismo. Consigo en C++ el codigo de un lector de TIFFS, cargo en memoria los 3 tiffs generados por DCRAW ( 8, 12 y 14 bits ) y vuelvo a operar en parejas con la maxima precision que el compilador me permite, aplico la diferencia de ambas, me quedo con el valor absoluto ( no quiero negativos ), amplifico el resultado hasta ser visible y guardo las imagenes.

Estos son los nuevos resultados con la maxima precision en las operaciones:

Diferencia 8vs14:





Diferencia 12vs14:




Crops Respectivos:

8vs14: ( comparado con el de PS es bastante parecido )



12vs14: ( nada que ver con el de Photoshop )





Despues de ver esto, y si no he cometido ningun error, puedo afirmar que al menos con la Canon 5D mkII y con esta imagen, la informacion desde el bit12 al 14 es, como minimo, parcialmente util y el descartarla implica perdida.

Visualmente yo en Photoshop no veo diferencia alguna cuando comparo la imagen original de 12 con la de 14. Es decir, que para la mayoria posiblemente 12 bits son suficientes. Aunque tambien hay que tener en cuenta que nuestros monitores, salvo excepciones, nos muestran en 8 bits por canal y con una luminancia y contraste limitados. Podriamos llegar a visualizar esas diferencias con nuestros ojos si los displays pudieran emitir en un rango dinamico parecido al del ojo?




Saludos.

[Western]

Creo que en este post se están mezclando demasiados conceptos: ruido, sensibilidad, sample, digitalización, dinámica, umbrales... hay quien habla de "casi" 14 bits, cuando este concepto sólo acepta números enteros y pares.

Y para más inri, todo se mezcla con la forma en que los programas de edición manejan los datos digitales, cosa que no tiene nada que ver con los sensores. Pero absolutamente nada que ver.

Todo es mucho más sencillo: nuestro sensor entrega una determinada señal ante la presencia de luz, que a través de un circuito analógico/digital se transforma en datos digitales de una determinada arquitectura, según "palabras" de 12 ó 14 bits, y ya esos números son muchos bits para un sample de imagen, considero yo. De la calidad del sensor dependerá que este circuito D/A capte más o menos información, y ahí ya nos referimos a la dinámica de nuestra cámara.

Si Canon especifica que su conversor trabaja a 14 bits, pues ea, trabaja a 14 bits, y punto. Otra cosa es que no haya datos suficientes para completar tanto flujo de información, porque el sensor se queda cortito.

Que luego metamos esa gran cantidad de datos digitales en nuestro ordenador, y que tratemos de organizarla en una imagen, eso es otro cantar. Nuestro PC, según algunos algoritmos, hará un resample con los datos que le llegan, y siempre según leyes sencillas que han de usarse para conformar una imagen RGB, utilizando 8 bits, o bien múltiplos o submúltiplos.