OJODIGITAL

garedagmad · #21 (**permalink**) 18-abr-2007, 11:13

Cita:

Iniciado por manolowarr

...no utilizo la Liberia de Adobe sino de otra empresa independiente...

Ahí falta información ;-)

¿Cuál?

J Rey · #22 (**permalink**) 18-abr-2007, 11:57

Gui muchas gracias por tu explicaciones poco a poco no vamos enterando, no falta el resto del Salón los Dormitorios , El Baños y la terraza

dicosoft · #23 (**permalink**) 18-abr-2007, 12:53

Eres un crack _GUI_

Aprendo más de tí y cada una de las cosas que tratas lo haces de una forma tan clara que da gusto leerlo y practicarlo.

Estoy coleccionando todos tus post....

Cuando sea grande quiero ser como tú ......

No esta demas decirlo..... Uno mas de los excelentes trabajos que servirá de mucho a esta comunidad..... óle

Guillermo Luijk · #24 (**permalink**) 18-abr-2007, 14:12

Cita:

Iniciado por manolowarr

Desde que empecé a programa no utilizo la Liberia de Adobe sino de otra empresa independiente y mis plugin valen todos para: Photoshop, ImageReady, Photofiltre Studio, Corel Photo-Paint, CorelDraw, Paint Shop Pro, Macromedia Fireworks, Infarview, Adobe Illustrator, Macromedia Frenad, Gimp y mucho más.
Limitación que tendía si usara el sdk de Adobe

No me refería a tu trabajo que es cojonudo, sino a que parece que consideras PS la biblia para hayar la repuesta de todo. Como lo de la ayuda de antes, que te dice que uses Niveles y si no puedes recurras a Curvas. Y si un becario resentido edita la ayuda oficial y pone que te ahorques?

Recuerdo en un post donde guardábamos JPEGs, que me dijiste que debería guardarlos con PS. Pero si JPEG es un algoritmo totalmente estandar que tiene más años que Matusalén!!
A eso me refería.

manolowarr · #25 (**permalink**) 18-abr-2007, 14:57

te respondo acá he abierto otro hilo para el HISTOGRAMA

Histograma y 16bits

SALUDOS

Guillermo Luijk · #26 (**permalink**) 19-abr-2007, 03:08

Bueno con la rutina para calcular el histograma de 15 bits (resulta que PS trabaja las imágenes a 15 bits, no a 16) que nos ha pasado Manolo en su hilo he calculado los histogramas en busca de huecos con la esperanza de que fueran de menor anchura en la foto sobreexpuesta +2EV y posteriormente subexpuesta que en la 0EV.

Primera mala noticia: en la zona baja del histograma no hay huecos como ya apuntabas Manolo, todos los niveles están rellenos.

Buena noticia: sí hay al menos picos, que yo interpreto como los niveles no interpolados del RAW original, habiendo sido el demosaicing quien ha ido rellenando los huecos intermedios entre pico y pico (según la disposición de Bayer, 2 de cada 3 niveles es interpolado). Si PS no nos hubiera robado ese bit extra los podríamos ver mejor (ver abajo).

Los picos parecen ir un poco a su bola en cada canal, veo complejo interpretarlos al 100%. Los que mejor se ven son los del azul y parecen estar separados una media de 8,5 niveles en la foto +2EV antes de subexponer, lo que me descuadra un poco por no ser potencia de 2; pero claro a saber las correcciones que haga el DCRAW de brillo y balance de blancos y que pueda escalarlos un poco.

Os pongo el primer tramo (niveles 0-255) de 3 histogramas de 16... perdón de 15 bits de las fotos del salón.

Foto salón derecheada +2EV
(este histograma abarca el primer cuarto del siguiente)

Foto salón derecheada +2EV subexpuesta 2 diafragmas por programa (agregando niveles)

Foto salón exposición "correcta" 0EV

Mirad los últimos dos: pese a no tener nulos ninguno como decía Manolo, la foto derecheada y posteriormente subexpuesta ha reducido la distancia entre picos dando lugar a un histograma más uniforme y con menos peine. Si es cierto que esos picos vienen de los niveles no interpolados, y me cuadra así sea, creo que podemos decir que el histograma producto de derechear la toma y subexponer el revelado tiene más calidad. Qué opináis?

Ricardo Maciel · #27 (**permalink**) 19-abr-2007, 05:56

Hola Gui:

El histograma puede ser....... pero la foto?
Puede que el histograma te de muchos mas valores tonales pero que ninguno se acerque a la realidad.
Me quedan muchas dudas....
Saludos
Ricardo

Guillermo Luijk · #28 (**permalink**) 19-abr-2007, 10:19

En cuanto a número de valores tonales, los dos últimos histogramas los dan todos, es decir, están llenos a reventar. lo que yo defiendo es que en el primero de ellos gracias al derecheo y posterior subexposición hay más pixels cuyo nivel viene directamente del sensor y no es interpolado, y por lo tanto es detalle real de la escena no una aproximación. el detalle procedente de la escena aparece en el histograma en forma de picos equiespaciados, los niveles interpolados se distribuyen de forma continua a lo largo de todo el histograma.

En la foto con derecheo/subexposición, los picos están equiespaciados una distancia menor y tienen menor amplitud (en origen tenían la misma separación y amplitud que los del histograma de la foto expuesta a 0EV, pero la subexposición a que hemos sometido el histograma derecheado ha provocado que los picos se aproximen y pierdan amplitud relativa respecto a los niveles interpolados), lo que me hace pensar que reproducen más fielmente los tonos captados en la escena.

Piensa que la riqueza tonal es un poco engañosa. por ejemplo si yo tengo un histograma desastroso, en peine, totalmente empastado donde se ve solarización, y le aplico un filtrado gaussiano, el histograma se va a suavizar: se van a rellenar todos los niveles intermedios del peine y va a tener más riqueza tonal. pero ha sido gracias a perder todo el detalle de la escena; es una riqueza tonal ficticia.

Las fotos hay que analizarlas con lupa sí y ver si ese "mejor histograma" se traduce en algo palpable, por ejemplo en las sombras. eso está pendiente.

Sergio de la Torre · #29 (**permalink**) 19-abr-2007, 10:50

Cita:

Iniciado por _GUI_

Bueno con la rutina para calcular el histograma de 15 bits (resulta que PS trabaja las imágenes a 15 bits, no a 16)

http://www.sergiodelatorre.com/blog/falsos16bits/

Guillermo Luijk · #30 (**permalink**) 19-abr-2007, 11:09

Cita:

Iniciado por Sergio de la Torre

http://www.sergiodelatorre.com/blog/falsos16bits/

ayer se me olvidó lanzar la pregunta: PS trabaja con 15 bits, pero la salida a 16 bits de ACR o de otros reveladores RAW y programas gráficos en general, también pierden ese bit? si no fuera así estaríamos en disposición de hacer procesados (por ejempolo con curvas) con el doble de precisión que PS interesante, interesante...

manolowarr · #31 (**permalink**) 19-abr-2007, 13:49

Cita:

Iniciado por Sergio de la Torre

http://www.sergiodelatorre.com/blog/falsos16bits/

ehhhhh, que el descubrimiento es mío, jejeje
no es el ahorro de bits, es la transparencia, a ver si después lo explico con más tiempo

Saludos

Guillermo Luijk · #32 (**permalink**) 19-abr-2007, 13:54

Aquí hace un tío hizo una comparación de recuperación de detalle en sombras:

A la izquierda Revelado RAW: ACR 2.4 y edición en PS (15 bits)
vs
Revelado en Image Plus 2.5 y edición en coma flotante (no enteros) de 64 bits.

Aunque parezca mentira (por la de PS) las dos imágenes son en color:

http://www.clarkvision.com/imagedeta...shadow.detail/

manolo me harías lo que te he pedido en tu hilo?

manolowarr · #33 (**permalink**) 19-abr-2007, 14:43

Abrimos una imagen
Doble clic en capa fondo
En la paleta capa, crear máscara de capa
Aguantamos ALT y clic sobre la miniatura de la máscara (ojo de la máscara, no la imagen)
Tiramos un degradado de blanco a negro
Luego activamos el ojo para ver el resultado.
¿Cuantos niveles de transparencias tenemos?

Para quien no lo entienda con leer, un video
http://img135.imageshack.us/img135/5...arenciadq4.swf

Yo como sabéis fabrico plugins y la opacidad no va de 0 a 100 como nos dice el Photoshop en la paleta capa, yo también la pongo en mis plugins de 0 a 100 porque la escalo para que a la gente le sea más fácil de entender, en realidad va del valor mínimo al máxima del espacio de color, en RGB de 0 a 255 y en RGB 16bit (hay está el bit perdido, jeje) de 0 a 32768. El formato PSD necesita un canal extra, que los que programamos plugins le llamamos “A” y es la transparencia.
Como es lógico, la imagen acoplada pues podría utilizar ese bit y se en realidad 16, pero de lógica también no vamos a tener las imágenes con capa a 15 y las acopladas a 16bit
También en cierto modo es para ahorrar recurso, porque para cada imagen en 16bit, necesitaríamos 65536x4=262.144, los 3 canales más la trasparecía.

Saludos

Cita:

Iniciado por _GUI_

manolo me harías lo que te he pedido en tu hilo?

Te he respondido allá, el penúltimo mensaje

garedagmad · #34 (**permalink**) 19-abr-2007, 15:04

Manolo, como he puesto en el otro hilo, ese bit extra por canal (y digo "extra" respecto a los 15 que PS utiliza) no sirve para guardar el canal de transparencia, porque como tú bien explicas, es un canal independiente con la misma profundidad en bits que cada canal de color.

Guillermo Luijk · #35 (**permalink**) 21-abr-2007, 00:32

He colgado lista para bajarse una versión medianamente decente del programa para poder visualizar histogramas de 16 bits de PS (15 reales). En cuanto tenga un rato sigo con los análisis que tenía pendientes por aquí.

El que lo quiera probar se habrá de instalar el programilla y el plugin de manolowarr que me permite leer los 16 bits de las imágenes y volcarla a un fichero de texto. Yo no sé

Pasos:
1. Abrir en PS la imagen a analizar el histograma en detalle.
2. Abrir el plugin de Manolo sobre la imagen y darle a "Guardar" (sí, genera un .txt, no hay ningún error).
3. Leer desde el visualizador ese .txt y esperar a que genere el histograma (para una foto de 8Mpx me ha tardado 27s).

Hecho esto podremos:
- Movernos libremente por todo el histograma (el eje X ya no va de 0..255 sino que va de 0..32767 visualizando cada vez 768 niveles)
- Escalar el eje Y (por defecto en 1x, el máximo de todo el histograma se ajusta al máximo del display, lo que puede no ser suficiente en las zonas del histograma con pocos pixels en cada nivel)
- Subexponer (por software) el histograma diafragmas completos para ver el efecto en la riqueza tonal
- Guardar en un GIF la parte del histograma que se está visualizando.
- También se calcula la imagen analizada en 8 bits a efectos psicológicos, para tener delante lo que estamos analizando.

Espero que os guste y le sea útil a alguien para comprender un poco mejor lo que es el histograma.

Os lo podéis bajar de mi web como siempre (manolo he puesto también tu plugin asumiendo que no te importa, si no es así me lo dices):
http://perso.wanadoo.es/gluijk

Software->Histogrammar (la gramática del histograma

)

manolowarr · #36 (**permalink**) 21-abr-2007, 10:59

Lo he estado mirando, pero tendré que probar, lo que si te puedo decir por lo que vi anoche, que no me coincidía en el preview de tu programa con la gamma de la imagen, en tu programa se visualizaba más oscuro

Cita:

Iniciado por _GUI_

Os lo podéis bajar de mi web como siempre (manolo he puesto también tu plugin asumiendo que no te importa, si no es así me lo dices):
http://perso.wanadoo.es/gluijk

CENTER][/center]

No me importa, pero no me corra, quiero que lo reaplace por este
http://www.photoshop-scripts.com/pub...ad.php?id=3558

le ha cambiado el nombre a imgTotxt, como tu programa está en ingles pues lo he traducido y las variable son de 15bit, en el anterior es de 16bit y aunque no se llenen ni se imprima en el txt, pueden generar basuras de variable si lo ejecuta más de una vez, en este eso estás corregido.
Además le he puesto un contrato de licencia, que lo dé gratis no quiere decir que ceda el copyright, todo el rollo ese de no distribuir, no descompilar ni usa ingeniería inversa, tal….tal ……..tal.

Guillermo Luijk · #37 (**permalink**) 21-abr-2007, 13:55

ok ya he cambiado todo. no era un tema de gamma sino precisamente del bit ese que PS nos roba. para pasar a 8 bits dividía el nivel entre 256 y claro, partiendo de un rango truncado a 0..32767 hay que hacerlo entre 128 o el brillo de toda la imagen se reduce a la mitad. como he hecho las pruebas con imágenes lineales que ya de por sí son muy oscuras ni me he dado cuenta.

gracias.

PD: le he añadido un chivato de niveles completamente vacíos (dibujando en gris más oscuro el fondo).

manolowarr · #38 (**permalink**) 21-abr-2007, 15:13

Bueno, Las conclusiones, jeje
yo me he limitado la mayor parte del tiempo a hacer el plugin para guardar en txt,
pero tú ha analizado más que yo el histograma, así que para que me voy a poner yo ahora a analizar el histograma. Si tú ya tienes las repuestas, jeje
Pregunta; ¿Sirve o no el derecheo del histograma?

Guillermo Luijk · #39 (**permalink**) 21-abr-2007, 22:27

He calculado los histogramas de la foto del salón correctamente expuesta y de la derecheada haciendo un revelado lineal (con DCRAW) para ver la calidad del histograma antes de aplicar la corrección gamma, obteniendo los siguientes resultados:

Toma correctamente expuesta 0EV: calculamos histograma.

Toma derecheada +2EV: subexponemos +2EV y calculamos histograma.

Aunque ya se intuye qué histograma es mejor no se aprecia muy bien lo que se representa; he tomado el canal azul y he dibujado de nuevo los histogramas a la manera clásica con líneas verticales:

Toma correctamente expuesta 0EV: calculamos histograma lineal.

Toma derecheada +2EV: subexponemos +2EV y calculamos histograma lineal.

Como puede verse tienen ambas todos sus niveles llenos en este histograma lineal (gamma=1), por lo que tienen en principio la misma riqueza tonal así que concluimos que el derecheo no genera nuevos niveles como Manolo afirmaba. Entre otras cosas porque como se ve en la foto correctamente expuesta tampoco había huecos donde hacerlo.

Estoy convencido no obstante de que al pasar de 12 a 16 (o 15) bits necesariamente se crean huecos en el histograma, es pura matemática, y es la interpolación de Bayer la que los llena de manera ficticia en aquellos niveles-pixels para los que el sensor no ha recogido información. De ahí que el histograma final se presente igual de lleno en ambos casos.

Atribuyo precisamente la existencia de picos a los niveles no interpolados, mientras las zonas entre picos eran originalmente huecos que se rellenaron por interpolación.
Si esto fuera así, basta mirar los histogramas para darse cuenta de que al derechear y posteriormente subexponer la foto hemos aumentado la frecuencia de aparición de dichos picos (al subexponer los hemos acercado) con lo cual estamos obteniendo una imagen de mayor precisión y riqueza tonal para los niveles no interpolados (que son la tercera parte del total), y por extensión de mayor precisión (riqueza tonal ya no) para los niveles interpolados a partir de ellos, por lo cual creo correcto decir que la señal derecheada es de más calidad que la no derecheada.

Que esta mejor calidad se note en el resultado final, que al fin y al cabo es lo que importa, me atrevería a decir que no; pero no se me ocurre como comprobarlo ya que ya no estamos hablando de más riqueza tonal (que sí sería fácil de constatar) sino de unos niveles ligerísimamente más fieles a los encontrados en la escena en el caso de derechear. De hecho analizando el histograma obtenido de ACR que ya tiene la corrección gamma aplicada, se introducen huecos en la primera mitad del histograma que nos dan al traste con todos estos refinamientos, así que ya ni me molesto en seguir por ahí.

La mejora de sobreexponer consiste por tanto en una desviación de niveles que podría asimilarse a un menor ruido de cuantificación, que estaría en cualquier caso varios órdenes de magnitud por debajo del ruido térmico generado por el sensor (incluso del de la 5D de belibeli) o de cualquier mínima operación posterior que vaya a sufrir la imagen (gamma, curvas, perfiles). Es por esto por lo que, muy a mi pesar, me da que afinar por aquí con el derecheo no tenga ningún sentido

Respecto al ruido aquí sí que no cabe duda de que se consigue una gran mejora. Haciendo la aproximación (no del todo cierta) de que el ruido es independiente del tiempo de exposición, por cada diafragma de sobreexposición estaremos reduciendo a la mitad el nivel de ruido en el histograma lineal una vez la sobreexposición esté corregida. En las sombras, donde el nivel de señal es más bajo (en ocasiones inferior al ruido), esto representará una mejora muy grande de la relación S/N, que es la magnitud que en realidad percibimos y no el ruido en términos absolutos.

Dos recortes al 200% de un trozo del sillón (reveladas con ACR, parámetros idénticos: cero contraste, cero enfoque, cero reducción de ruido, etc.. etc.., y corrección de exposición -2EV en la segunda toma):

Toma correctamente expuesta 0EV: revelado en ACR. ISO400

Toma derecheada +2EV: revelado en ACR con exposición -2EV. ISO400

(juro que no ha pasado por el Ninja, es tan solo el efecto de la sobreexposición)

CONCLUSIONES (totalmente sujetas a debate de béisbol):

1. Una fotografía adquiere más riqueza tonal (niveles) cuando se derechea el histograma? no. Todos los niveles se llenan aunque no se derechee.

2. La señal captada derecheando el histograma, tiene más calidad? sí, pero no es una mejora de variedad tonal, sino de precisión tonal. Y no vamos a ser conscientes de ella al quedar enmascarada por las transformaciones mucho menos sutiles que va a sufrir la foto en el revelado RAW (interpolación Bayer, gamma) y el procesado posterior (perfiles, curvas, niveles).

3. Derechear el histograma, sirve para algo? a efectos prácticos, solo sirve para reducir el ruido.

qué decepción, en fin.

Salu2

manolowarr · #40 (**permalink**) 21-abr-2007, 23:09

Muy bueno el resumen _GUI_

Otra, acá tenemos un artículo de Paulo sobre el ruido, que es un complemento a este tema.
http://www.quesabesde.com/camdig/art...p?articulo=169

Pero, Ojo, como ya ha comentado _GUI_ , y también comente yo en su momento, el tener menos ruido no quiere decir tener una gamma tonal más amplia.

Esta mañana es que es respondido a un tema sobre ruido y para empezar me parece bien el articulo de Paulo, sería muy interesante investigar sobre el “dark” ¿te apuntas GUI?
Pienso que para mucha gente es complicado el Noiseware con tantos controles y variables a regular, además que abusan mucho de la mediana o los filtros espaciales no lineales, con lo cual se pierde enfoque.

saludos