OJODIGITAL

SALUDA · #**201** (**permalink**) 05-feb-2009, 19:47

Gracias por tu respuesta. No es que sea lioso, es cuestión de ir conociendo el funcionamiento e ir probando.
Salud@s y que la fuerza os siga acompañando.

Franky's eye · #**202** (**permalink**) 06-feb-2009, 23:10

Impresionante el trabajo que estais haciendo.
Acabo de descubrirlo y es realmente interesante.

Una pregunta:
¿Cuales serían los requerimientos mínimos de los que hay que disponer para poder correr el programa?

Lo acabo de instalar en un pc bastante tranquilo y no me lanza la aplicación, me dice que "la configuración no es correcta, la reinstalación de la aplicación podría resolver el problema"... supongo que será culpa del ordenador, pero por si acaso...

Saludos, y enhorabuena por vuestro trabajo.

ManuelLlorens · #**203** (**permalink**) 07-feb-2009, 00:23

Cita:

Iniciado por Franky's eye

Impresionante el trabajo que estais haciendo.
Acabo de descubrirlo y es realmente interesante.

Una pregunta:
¿Cuales serían los requerimientos mínimos de los que hay que disponer para poder correr el programa?

Lo acabo de instalar en un pc bastante tranquilo y no me lanza la aplicación, me dice que "la configuración no es correcta, la reinstalación de la aplicación podría resolver el problema"... supongo que será culpa del ordenador, pero por si acaso...

Saludos, y enhorabuena por vuestro trabajo.

Muchas gracias. ¿Has instalado el runtime de VC++? ¿Has probado las dos versiones (SSE/SSE2)?

Un saludo:

Franky's eye · #**204** (**permalink**) 07-feb-2009, 16:44

Cita:

Iniciado por ManuelLlorens

Muchas gracias. ¿Has instalado el runtime de VC++? ¿Has probado las dos versiones (SSE/SSE2)?

Un saludo:

Acabo de probar esto y me da el mismo error... literalmente "No se pudo iniciar la aplicación porque su configuración es incorrecta. La reinstalación de la aplicación puede solucionar el problema"

Que extraño... ¿la carpeta con el ejecutable tiene que estar en algun directorio especifico? al igual que ocurre con el zeronoise del amigo Guillermo...

De todos modos tampoco quiero molestar demasiado, que bastante trabajo haceis con el desarrollo...

Un saludo.

ManuelLlorens · #**205** (**permalink**) 13-feb-2009, 00:43

Cita:

Iniciado por Franky's eye

Acabo de probar esto y me da el mismo error... literalmente "No se pudo iniciar la aplicación porque su configuración es incorrecta. La reinstalación de la aplicación puede solucionar el problema"

Que extraño... ¿la carpeta con el ejecutable tiene que estar en algun directorio especifico? al igual que ocurre con el zeronoise del amigo Guillermo...

De todos modos tampoco quiero molestar demasiado, que bastante trabajo haceis con el desarrollo...

Un saludo.

Disculpa la tardanza en la respuesta. Debes instalar el .NET Framework 3.5. En la versión final no hará falta.

Un saludo:

saipan · #**206** (**permalink**) 17-feb-2009, 18:59

He descargado vuestro programa y no abre los ficheros raw de la Sigma DP1. Imagino que es lo de siempre: cada fabricante tiene su mundo.

Gracias por vuestra generosidad (lo digo genuinamente), es un ejemplo de la ética relacionada con los retos personales (intelectuales, en este caso).

ManuelLlorens · #**207** (**permalink**) 17-feb-2009, 19:13

Cita:

Iniciado por saipan

He descargado vuestro programa y no abre los ficheros raw de la Sigma DP1. Imagino que es lo de siempre: cada fabricante tiene su mundo.

perfectRAW soporta los mismos RAWs que dcraw. En tu caso, efectivamente, parece que dcraw no soporta los RAWs de la Sigma DP1. Sin embargo, sí soporta la SD9, SD10 y SD14, aunque no he verificado que perfectRAW funcione bien con ellos.

Ponte en contacto con Coffin y pídele que dé soporte para tu cámara a dcraw. Cuando intentas revelar un RAW de las DP1 en dcraw obtienes esto:

Código:

Loading SIGMA DP1 image from Sigma DP1.X3F ...
Foveon interpolation...
Sigma DP1.X3F: "DarkShieldColRange" matrix not found!
Sigma DP1.X3F: "PostPolyMatrix" matrix not found!
Sigma DP1.X3F: "SaturationLevel" matrix not found!
Sigma DP1.X3F: "KeepImageArea" matrix not found!
Sigma DP1.X3F: "ActiveImageArea" matrix not found!
Sigma DP1.X3F: "ChromaDQ" matrix not found!
Sigma DP1.X3F: "ColorDQCamRGB" matrix not found!
Sigma DP1.X3F: "DarkShieldTop" matrix not found!
Sigma DP1.X3F: "DarkShieldBottom" matrix not found!
Sigma DP1.X3F: Invalid white balance "Sunlight"
Converting to sRGB colorspace...
Writing data to Sigma DP1.ppm ...

Y el resultado es inservible.

Cita:

Iniciado por saipan

Gracias por vuestra generosidad (lo digo genuinamente), es un ejemplo de la ética relacionada con los retos personales (intelectuales, en este caso).

Pues muchas gracias, hombre.

Un saludo:

ManuelLlorens · #**208** (**permalink**) 24-feb-2009, 21:49

Hacía tiempo que buscaba una herramienta para poder confirmar de un modo más gráfico todo el tema del uso de memoria en Win32. Ahora he encontrado la aplicación VMMap de SysInternals que hace justo lo que yo quería, la verdad es que es una gozada de herramienta.

En este pantallazo he ordenado los bloques de memoria (los blancos son libres) por tamaño y se ve claramente como, a pesar de que perfectRAW aún no ha utilizado algo más de 800 megas de los 2 Gb que le corresponden como proceso (aunque sí ha agotado la memoria física, aún le queda virtual), el bloque de memoria libre contiguo más grande no llega a 170 megas. Se ve también el primer bloque ocupado con el RAW entero decodificado y cargado en memoria y cómo, la última versión 0.65, sólo necesita uno de esos para funcionar.

También es muy interesante verlo ordenado por dirección en la memoria para ver la distribución de los huecos. Sería enormemente interesante poder correr una herramienta similar en Linux y comparar visualmente la gestión de la memoria que hacen ambos SOs (¿alguno conocéis algo similar para Linux?). De verdad que no entiendo porqué funciona tan mal la gestión de memoria de Windows.

Se ven perfectamente mis bloques dispersos más abajo, que permiten exprimir al máximo los huecos libres (todos del mismo tamaño, menos el último):

Como suele decirse, una imagen vale más que mil palabras.

Un saludo:

placido_p · #**209** (**permalink**) 25-feb-2009, 23:38

He visto que todavía falta por arreglar algún problemilla con las fuji. Los usuarios de esta marca te estaríamos eternamente agradecidos si pudiéramos dejar de utilizar HU3 y obtener mejores resultados que con ACR, perfectRAW tiene pinta de poder conseguirlo.

ManuelLlorens · #**210** (**permalink**) 25-feb-2009, 23:57

En principio funciona bien con la Fuji, pero no exprime todo su potencial. Es posible que algún día creemos un revelador específico para estas cámaras. Ya veremos qué pasa cuando acabemos con los dos proyectos que ahora tenemos entre manos.

Un saludo:

ManuelLlorens · #**211** (**permalink**) 04-mar-2009, 22:52

Coffin ha liberado hoy la versión 8.92 de dcraw con soporte para gamma de 16 bits. Su implementación es muy diferente de la nuestra y no va a ser más rápida, eso seguro. Tengo que estudiar bien la forma de compatibilizar ambas versiones del cálculo de gamma porque quiero mantener el código de Coffin lo más intacto posible.

Esos cambios irán en la próxima versión que subamos, con el interfaz nuevo.

Un saludo:

Guillermo Luijk · #**212** (**permalink**) 05-mar-2009, 00:32

Me dijo Coffin que no, que la opción -g es solo para 8 bits (realmente ya existía en la versión de 2005, la ha rescatado vete a saber porqué).

Yo en Vista no puedo probar la compilación que ha subido Paco, tú has confirmado que funciona en 16 bits?

ManuelLlorens · #**213** (**permalink**) 05-mar-2009, 10:00

El código nuevo ya no hace la distinción que hacía antes entre 8 y 16 bits, es decir, que está preparado para hace gamma de 16 bits.

El problema es que, aunque no lo usemos habrá que duplicar la función convert_to_rgb() porque sus cambios estropean los nuestros y viceversa. (En realidad no es un tema demasiado importante, pero quería poner alguna entrada para mantener el interés)

.

Un saludo:

Guillermo Luijk · #**214** (**permalink**) 05-mar-2009, 13:09

Pues no lo entiendo, entonces por qué me ha mandado el patch para poder usar -g con salida 16 bits? os lo he reenviado, lo has visto?

ManuelLlorens · #**215** (**permalink**) 05-mar-2009, 13:17

Es que Coffin ha hecho un pupurrí bastante chapucero. La versión normal calcula la gamma de 16 bits si lo fuerzas, pero no la saca en el TIFF.

Además, la gamma que va en el TIFF la calcula mediante una LUT cutre (con valores de 16 bits) que dará valores poco precisos en las sombras (peores aún que aquellos míos de los que se quejaba con razón Jacques). Su forma de codificar la gamma en el TIFF es diferente a la mía, tendré que estudiar qué ventajas pueda tener.

A mí personalmente no me gusta su aproximación en este tema. Luego te compilo una versión con el patch para 16 bits que te funcione en Vista y pruebas tú mismo (lo subiré aquí por si alguien más quiere probar).

Ahora te dejo que estoy hasta arriba de exámenes por corregir... entre otras cosas

.

Un saludo:

Guillermo Luijk · #**216** (**permalink**) 05-mar-2009, 13:48

Cita:

Iniciado por ManuelLlorens

Ahora te dejo que estoy hasta arriba de exámenes por corregir... entre otras cosas

No seas demasiado duro, que nunca se sabe cuál de esos cachorrillos llegará un día a alcalde o ministro...

ManuelLlorens · #**217** (**permalink**) 05-mar-2009, 14:41

O peor aún... ¡a cirujano!

Lo malo es que a base de suspenderlos puedo llegar a asegurarme de que no llegarán a cirujanos, pero les empujo directamente a ser políticos

.

Un saludo:

ManuelLlorens · #**218** (**permalink**) 05-mar-2009, 16:20

Para el que quiera hacer pruebas, aquí tenéis dcraw v8.92 código de Coffin (que incluye el patch para activar la gamma de 16 bits que Coffin ha pasado a Guillermo) compilada con VC++ y SSE (correrá en todas las versiones de Windows que soporten procesadores con SSE, que deberían ser casi todos).

No pasaré el código del patch ni el código parcheado porque Coffin prefiere no hacerlo.

Si no me equivoco, Coffin ha mejorado el soporte para la Pentax K-m/Pentax K2000 y ha hecho algunos cambios en el soporte de Canon.

Ya sabéis que para compilar dcraw con VC++ (podéis usar Visual C++ Express 2008, que es gratuito) sólo hace falta cambiar una línea:

Código:

#ifdef DJGPP

por

Código:

#if defined (DJGPP) || (_MSC_VER)

Para comparar aquí está nuestro dcraw (con nuestra gamma de 16 bits y AFD entre otras cosas) actualizado al código 8.92 de Coffin.

He realizado estos dos revelados, ambos con gamma sRGB:

Código:

dcraw.exe -v -a -o 1 -T -4 -q 3 -W -g 2.4 12.92 test.orf
dcraw_bd.exe -v -a -o 1 -T -4 -q 3 -g sRGB test.orf

De mis propias pruebas (con una imagen bien oscura para que tenga muchas sombras, que es donde más se notará la diferencia) diría que, como ya os había adelantado, la precisión de la gamma de Coffin en las sombras no es la ideal, aunque visualmente sea imposible notar las diferencias (tal vez levantando mucho las sombras y procesando se llegue a notar un pelín), en el histograma (y en sus estadísticas) son muy evidentes. Os dejo un par de pantallazos del estupendo Histogrammar de Guillermo (por cierto Guillermo, tienes pendiente un par de detalles con el programa, ¿los recuerdas?):

Con la gamma de Coffin:

Con nuestra gamma:

Un saludo:

mfg · #**219** (**permalink**) 06-mar-2009, 10:38

Os odio, estaba yo tan contento con mi ACR, tan sencillo de manejar y tan visual y me encuentro con esto. Lo voy a probar, me digo, y me lo descargo. Pasada la primera impresión me leo las instrucciones, trasteo un poco y de repente una foto que tenia abandonada por imposible cobra vida. Pruebo con otras y comparo los resultados con mis revelados con ACR y veo mejoras visibles a simple vista (sin necesidad de ampliar). Así que lo dicho, os odio, otra vez a aprender a manejar un programa nuevo.

Lo que me cuesta más es lo del balance de blancos, ¿hay algun tutorial que lo trate un poco? es que he mirado un articulo de G. Luijk sobre el dcraw en el que da unos números correspondientes a los balnces prefijados de la canon 350, pero ni esa es mi cámara ni se como aplicar eso al perfect raw.

Muchas gracias por vuestro trabajo y seguire este hilo.

Guillermo Luijk · #**220** (**permalink**) 06-mar-2009, 14:53

Manuel puedes pasar el patch tranquilamente, Coffin me ha dicho que lo cuelgue en mi web.

Respecto a Histogrammar tienes ya la versión 1.2, con gamma arbitraria y soporte para plotear histogramas RAW obtenidos con dcraw -d/-D, persona que no os lo pasé por email. Solo falta lo del chorizo-histograma de 65536 píxeles de ancho, pero es que ni Photoshop soporta GIFs tan largos así que he desistido. También queda separar G1 y G2 en los histogramas RAW, eso para la 1.3.

Te pongo aquí explicaciones de Coffin sobre la gamma (entiendo que sin el parche está solo disponible en 8 bits no?):

Código:

Gamma correction in dcraw converts linear raw data to
match the non-linear response of computer monitors and the
human eye. This is best illustrated by running Gnuplot
with the following commands:

set samples 1000
set xrange [0:1]
set yrange [0:1]
set size ratio 1
set key at 0.9,0.2
plot x**0.5, x*4, x <= 0.01795 ? x*4 : (x**0.5)*1.0718-0.0718

or just opening the attached GIF. The red and blue
curves represent "dcraw -g 2 0" and "dcraw -g 2 4" respec-
tively. The problem with any simple power function is that
the slope becomes infinite as x approaches zero, filling
image shadows with noisy fog.

The toe slope (shown in green) solves this problem.
For any toe slope, dcraw adjusts the "0.01795" and "0.0718"
values so that the power curve falls tangent to this line.

"dcraw -g 2 4" has an effective gamma of 1.8, because
its curve encloses the same area as "dcraw -g 1.8 0". You
can see this by appending ", x**0.555333" to the "plot"
command above. To generate a correct ICC profile, dcraw
must calculate the effective gamma value.

I've attached a source patch in case you want to experi-
ment with raw photos, but please send the translation first!

Y aquí más explicaciones de porqué elige la gamma como la elige:

Código:

> I think DCRAW with gamma is good news.

You mean dcraw with _setable_ gamma. Dcraw has
defaulted to BT.709 gamma since Jan 2005, and that is
not going to change. As before, "dcraw -4" is always
linear.

I don't default to sRGB gamma because the toe
slope is much too high, turning black into foggy grey.
BT.709 works fine for television (it's the standard
for both low-def and high-def), and it looks good on
a monitor too.

Parece que elige pasar de la gamma de sRGB para usar una más adecuada a los monitores habituales. Lo que no sé es hasta qué punto su gamma de la norma BT.709 ésa viene informada en los TIFF que genera DCRAW, porque está claro que si directamente asignas sRGB en un programa con gestión de color como Photoshop, las sombras se oscurecerán.

Salu2

ManuelLlorens · #**221** (**permalink**) 06-mar-2009, 15:44

No me termina de convencer.

Desde luego para perfectRAW no es una opción sacar los 16 bits sin gamma siempre (será una opción), aunque sí podemos poner como opción de salida su gamma BT.709, "informándola" en el TIFF incluso si hace falta.

Al final los "defectos de diseño" de PS acaban condicionando en parte el diseño de otros productos cuya salida acabará en PS, ¡qué cosas!

Un saludo:

ManuelLlorens · #**222** (**permalink**) 06-mar-2009, 18:44

Cita:

Iniciado por mfg

Pasada la primera impresión me leo las instrucciones, trasteo un poco y de repente una foto que tenia abandonada por imposible cobra vida. Pruebo con otras y comparo los resultados con mis revelados con ACR y veo mejoras visibles a simple vista (sin necesidad de ampliar). Así que lo dicho, os odio, otra vez a aprender a manejar un programa nuevo.

Ten en cuenta que el interfaz actual es provisional y que el definitivo que se verá por aquí de un día a otro será mucho mas fácil de manejar. Eso sí los conceptos habrá que tenerlos igual de claros.

Puedes poner algún ejemplo en el hilo de revelados con perfectRAW.

Cita:

Iniciado por mfg

Lo que me cuesta más es lo del balance de blancos, ¿hay algun tutorial que lo trate un poco? es que he mirado un articulo de G. Luijk sobre el dcraw en el que da unos números correspondientes a los balnces prefijados de la canon 350, pero ni esa es mi cámara ni se como aplicar eso al perfect raw.

La versión final llevará un control a base de parches y cuentagotas, además de los típicos deslizadores con tono y matiz, así que no te preocupes demasiado por ese tema. Incluso puede que incorporemos algún día (no en la 1.0 que tiene la funcionalidad bastante cerrada) la opción de tomar varias muestras y cambiar el balance de blancos mediante un degradado entre ellas.

Cita:

Iniciado por mfg

Muchas gracias por vuestro trabajo y seguire este hilo.

Pues bienvenido al hilo y gracias.

Un saludo:

ManuelLlorens · #**223** (**permalink**) 07-mar-2009, 11:19

Guillermo, viendo la forma en la que Coffin ha implementado la gamma (por dos vías, mediante una LUT que va en la cabecera del TIFF para informar al programa que lo abre) y mediante la modificación real de los datos y el modo de especificar el valor de la gamma, y mezclando eso con las gammas de Jacques... ¿dejamos la nuestra como está? ¿será sRGB la gamma por defecto en perfectRAW?

Ilústranos un poco porque yo ando algo perdido.

Un saludo:

Guillermo Luijk · #**224** (**permalink**) 07-mar-2009, 23:54

Yo elegiría lo que haga más fácil mantener el código cuando Coffin saque nuevas versiones.

Si es igual de fácil, la nuestra: sRGB de Bruce Lindblom, y gamma pura en todos los demás casos.

Coffin lo orienta todo a que se vea bien la imagen tal cual sale de DCRAW, que en 8 bits tiene sentido. A nosotros nos interesa la salida en 16 bis y tenemos que orientarlo a que la imagen sea lo más apta posible para editarla. Y a esto ayuda un histograma suave con las sombras más alejadas del origen.

A ver qué opinas tú.

PD: por cierto que hace ya tiempo vi una discusión larguísima de Bruce Lindblom con otro tío, que de hecho está documentada en la web de Bruce. Pues el otro día me enteré que ese otro tío era Dan Margulis (el gurú del modo Lab), y Bruce lo pone en entredicho en algunas afirmaciones sobre 8 bits vs 16 bits y el modo Lab. Tengo que leerme la discusión, y es que estaba pensando en comprarme el libro de Margulis sobre Lab.

VALGAR · #**225** (**permalink**) 08-mar-2009, 22:08

Cita:

Iniciado por Guillermo Luijk

PD: por cierto que hace ya tiempo vi una discusión larguísima de Bruce Lindblom con otro tío, que de hecho está documentada en la web de Bruce. Pues el otro día me enteré que ese otro tío era Dan Margulis (el gurú del modo Lab), y Bruce lo pone en entredicho en algunas afirmaciones sobre 8 bits vs 16 bits y el modo Lab. Tengo que leerme la discusión, y es que estaba pensando en comprarme el libro de Margulis sobre Lab.

Perdón por el Off-topic. Quizás te interese esto.

A Manuel y compañia, ¡ÁNIMOS!

Saludos.

Guillermo Luijk · #**226** (**permalink**) 08-mar-2009, 23:15

Cita:

Iniciado por VALGAR

Perdón por el Off-topic. Quizás te interese esto.

A Manuel y compañia, ¡ÁNIMOS!

Saludos.

Que buena lista de enlaces, muchas gracias. Con el modo Lab siempre me he encontrado con zancadillas, pero creo que al final me haré adicto.

El caso es que cuando lo empecé a trasterar, vi que usando el motor de conversión de MS me ocurrían cambios de color bestiales, aquí. Hugo Rodríguez me dice que eso es inexplicable y que el motor de MS es mejor que los de Adobe y Apple

El otro día, ya desechado el motor de MS y usando el motor de Adobe (ACM), vuelvo a la carga y me encuentro con que cada conversión a Lab y vuelta me trastocaba el histograma así, cosa que no hace el motor de MS, pero claro aquél me jodía los colores:

Bueno pues resulta que por lo visto CS4 no es ni de lejos tan agresivo, así que algo debe tener CS2 (el que yo tengo) que corregieron después.

Suelo usarlo para enfocar a sabiendas de que me deja los histogramas hechos trizas. A ver si me instalo el CS4 y empiezo a sacarle partido de verdad.

Salu2

VALGAR · #**227** (**permalink**) 09-mar-2009, 01:42

Tengo la siguiente versión a la tuya y desde luego no hace eso. Los histogramas permanecen invariables. Sorprendente lo que te ocurre.

La edición del libro deja bastante que desear para mi gusto. Tienes los capítulos 2 y 9 aqui para que te hagas una idea.

Por mi parte lo dejo en este punto, que si no Manuel nos va a correr a gorrazos por desviarle el tema.

Saludos.

ManuelLlorens · #**228** (**permalink**) 10-mar-2009, 21:47

Cita:

Iniciado por VALGAR

Tengo la siguiente versión a la tuya y desde luego no hace eso. Los histogramas permanecen invariables. Sorprendente lo que te ocurre.

La edición del libro deja bastante que desear para mi gusto. Tienes los capítulos 2 y 9 aqui para que te hagas una idea.

Por mi parte lo dejo en este punto, que si no Manuel nos va a correr a gorrazos por desviarle el tema.

Saludos.

Hombre, el subforo no es mío... y de hecho Guillermo es moderador del mismo ;-). Por otro lado para que el tema no sea off-topic del todo:

¿Sería interesante que perfectRAW pudiera dar una salida en TIFF de 16 bits en modo LAB con nuestra propia conversión RGB->LAB (obviamente con el experto asesoramiento de Jacques en estos temas) como alternativa a la salida RGB y la conversión posterior en PS? ¿Ganaríamos algo con eso? El tema no está exento de sus consideraciones técnicas complejas, porque la conversión RGB->LAB no está del todo bien definida y creo que hay que tomar ciertos compromisos.

Me temo que CS4 no destroza tanto el histograma, pero sí lo cambia considerablemente (se notan cambios de tonalidad y sorprendentemente lo ¿desplaza/comprime? hacia la izquierda). Partiendo un RAW de la mi E-510 revelada en espacio de color sRGB con la última versión del nuestro ejecutable dcraw con gamma sRGB:
RGB:

RGB->LAB->RGB con PS CS4 (motor ADOBE):

RGB->LAB->RGB con PS CS4 (motor Microsoft):

Mi conclusión es que la conversión destroza las tonalidades de las sombras, pero no soy ni mucho menos un experto en colorimetría.

Un saludo:

Guillermo Luijk · #**229** (**permalink**) 10-mar-2009, 23:01

Manuel, ante esa compresión de sombras me da que partías de una imagen en Adobe RGB o similar, y tienes configurado por defecto en tu PS el perfil sRGB.

Para asegurarte tienes que hacer: Edición -> Convertir en perfil en todos los cambios que hagas, no usar nunca el comando Imagen -> Modo porque éste al volver a RGB convierte al perfil por defecto.

Salu2

VALGAR · #**230** (**permalink**) 11-mar-2009, 00:41

Mi caso con CS3.
Imagen original.

Primera conversión RGB > Lab > RGB

Segunda conversión RGB > Lab > RGB

Hay pequeñas variaciones, normales por otro lado, ya que no hay una correlación exacta entre Lab y RGB. Por mi parte no se hace necesario una salida en Lab. Trabajar en Lab es útil para ciertas cosas pero no te permite utilizar otras funciones de Photoshop. Prefiero empezar en RGB y luego si se tercia cambiar a Lab.
¿Como anda de avanzado el tema, Manuel?

Saludos.

ManuelLlorens · #**231** (**permalink**) 11-mar-2009, 10:51

Cita:

Iniciado por Guillermo Luijk

Manuel, ante esa compresión de sombras me da que partías de una imagen en Adobe RGB o similar, y tienes configurado por defecto en tu PS el perfil sRGB.

Para asegurarte tienes que hacer: Edición -> Convertir en perfil en todos los cambios que hagas, no usar nunca el comando Imagen -> Modo porque éste al volver a RGB convierte al perfil por defecto.

Sí, ahora que lo dices debe ser algo de eso. Creo que tengo el PS en AdobeRGB y que cargué un sRGB.

Un saludo:

ManuelLlorens · #**232** (**permalink**) 11-mar-2009, 10:59

Cita:

Iniciado por VALGAR

¿Como anda de avanzado el tema, Manuel?

Pues estamos trabajando en tres líneas:

Emil Martinec y Paul Lee siguen afinando el nuevo algoritmo de interpolación de Emil, así como su implementación en C. De momento el algoritmo está sin optimizar y corre con OpenMP (parelelizado) en unas 5 veces el tiempo de AHD. Una vez terminada la afinación y optimización Egon lo portará a la GPU. El algoritmo es la bomba, superando a todos los algoritmos actuales de calle, salvo en un detalle en el que Emil está trabajando en este momento.
Por otro lado Egon sigue desarrollando el interfaz wxWidgets/OpenGL, que ya corre en Windows/Linux y en breve correrá en MacOS y además en 32/64 bits nativos. Falta integrarle la DLL de revelado. El caso es que lo mejor es que él mismo nos cuente cómo va. En principio planeábamos liberar una versión lo antes posible con el nuevo interfaz.
Yo por mi parte estoy en dique seco... descansando. Pendiente tengo un nuevo algoritmo de interpolación especial para imágenes ruidosas que estoy diseñando (pero que puede resultar un fiasco total, es un experimento), migrar nuestra DLL de dcraw a C++ para poder lanzar varias instancias en paralelo, probarla en 64 bits, etc.
Por otro lado tengo pendiente diseñar la plantilla Drupal de nuestra web, vamos diseñarla está diseñada, falta hacerla... ¿algún alma caritativa quiere echar una mano con eso?

Un saludo:

VALGAR · #**233** (**permalink**) 11-mar-2009, 20:57

Detallada explicación. Gracias.

Respecto a la petición de ayuda, no tengo ni idea del tema.

Seguro que hay algún experto en la materia dentro del foro que os pueda echar una mano.
Ánimos para todos.

Saludos.

ManuelLlorens · #**234** (**permalink**) 11-mar-2009, 23:57

Cita:

Iniciado por Guillermo Luijk

Manuel, ante esa compresión de sombras me da que partías de una imagen en Adobe RGB o similar, y tienes configurado por defecto en tu PS el perfil sRGB.

Para asegurarte tienes que hacer: Edición -> Convertir en perfil en todos los cambios que hagas, no usar nunca el comando Imagen -> Modo porque éste al volver a RGB convierte al perfil por defecto.

Pues lo acabo de mirar y sí que tenía el PS en sRGB y la imagen está revelada con -o 1 -g sRGB en dcraw. Además he realizado la conversión como tú me propones (mediante convertir al perfil en vez de por el Imagen -> Modo) y el resultado es idéntico a los histogramas que puse

.

Un saludo:

Guillermo Luijk · #**235** (**permalink**) 12-mar-2009, 00:30

Cita:

Iniciado por ManuelLlorens

Pues lo acabo de mirar y sí que tenía el PS en sRGB y la imagen está revelada con -o 1 -g sRGB en dcraw. Además he realizado la conversión como tú me propones (mediante convertir al perfil en vez de por el Imagen -> Modo) y el resultado es idéntico a los histogramas que puse

no me fío un pelo del sRGB de Coffin. Por qué no coges la imagen (revelada como sea, en Adobe RGB por ejemplo), la conviertes a Adobe RGB en PS -> histograma A.
Vas a Lab y vuelves a Adobe RGB de PS -> histograma B.

Esto del Lab me tiene negro.

miguelkm · #**236** (**permalink**) 15-mar-2009, 23:33

Hola
Ante todo felicitaros y agradeceros vuestro genial trabajo. He probado ya a hacer unos cuantos revelado y estoy impresionado de la calidad que se puede obtener en la mayoría de los casos.
Lo que vengo observando en algunas fotos es que perfectRAW interpreta las luces quemadas con una tonalidad rosa.
Una imagen y recorte de ejemplo:

No sé si será un problema de calibración de mi monitor, pero creo que está bien, y yo lo veo rosa claro.
La imagen está revelado con el equilibrio de blancos en auto y ahd.
Con el equilibrio de blancos de cámara pasa lo mismo.
Os ocurre a vosotros o es un problema de los .CR2 de canon...?
Gracias de nuevo,
saludos.

ManuelLlorens · #**237** (**permalink**) 16-mar-2009, 00:12

Gracias miguelkm por tus comentarios.

Cita:

Iniciado por miguelkm

Lo que vengo observando en algunas fotos es que perfectRAW interpreta las luces quemadas con una tonalidad rosa.

Es un problema del punto de saturación que dcraw tiene prefijado para tu cámara. Prueba modificando el control "saturation" y se arreglará, aunque Guillermo te explicará cómo calcular el punto exacto.

¿Qué cámara usas?

Un saludo:

miguelkm · #**238** (**permalink**) 16-mar-2009, 09:25

Cita:

Iniciado por ManuelLlorens

¿Qué cámara usas?

Una EOS 30D.
Gracias y saludos.

ManuelLlorens · #**239** (**permalink**) 16-mar-2009, 16:38

Cita:

Iniciado por miguelkm

Una EOS 30D.
Gracias y saludos.

Ok, revela con el punto de saturación en 3398. Con eso se arreglarán los magentas de las altas luces.

Supongo, a ver qué opina Guillermo, que perfectRAW 1.0 saldrá con los niveles de saturación de dcraw corregidos.

Un saludo:

Guillermo Luijk · #**240** (**permalink**) 16-mar-2009, 17:01

Cita:

Iniciado por ManuelLlorens

Supongo, a ver qué opina Guillermo, que perfectRAW 1.0 saldrá con los niveles de saturación de dcraw corregidos.

Pues sí, aunque lo ideal sería que Coffin lo corrigiera en la fuente, pero sino es tontería dejarlos mal. De momento yo solo sé dos incorrectos la 30D (3398) y la 40D (13823).

A la v2.0 le añadiría una función de cálculo del punto de saturación: el usuario suministra un RAW quemado y Perfect RAW se autocalibra.

miguelkm · #**241** (**permalink**) 16-mar-2009, 19:58

Gracias a los dos. La verdad es que con 3398 sigue viéndose claramente rosa... He he estado probando y hasta 3198 no llega verse blanco de verdad.
Saludos.

Guillermo Luijk · #**242** (**permalink**) 16-mar-2009, 20:25

Cita:

Iniciado por miguelkm

Gracias a los dos. La verdad es que con 3398 sigue viéndose claramente rosa... He he estado probando y hasta 3198 no llega verse blanco de verdad.
Saludos.

Por qué no haces una cosa? calcula el histograma RAW de ese archivo y sales de dudas. Es facilísimo, con dcraw.exe o con dcrawMS.exe si tienes Vista, haces:

dcraw -v -D -T -4 -t 0 archivo.cr2

Y el tiff que te sale, lo abres en Histogrammar (instala la v1.1 y sustituye su ejecutable por el que viene en el enlace de la actualización v1.2 que aunque se llama igual tiene mejoras) y pasas a modo RAW. Haciendo zoom podrás ver exactamente dónde y cómo satura cada canal.

Salu2

ManuelLlorens · #**243** (**permalink**) 16-mar-2009, 22:02

Cita:

Iniciado por Guillermo Luijk

Pues sí, aunque lo ideal sería que Coffin lo corrigiera en la fuente, pero sino es tontería dejarlos mal. De momento yo solo sé dos incorrectos la 30D (3398) y la 40D (13823).

A la v2.0 le añadiría una función de cálculo del punto de saturación: el usuario suministra un RAW quemado y Perfect RAW se autocalibra.

Sí, eso y el semi auto UniWB, ¿no?

Un saludo:

ManuelLlorens · #**244** (**permalink**) 16-mar-2009, 22:04

3398 -> 3198 parece mucha casualidad ¿no te bailaría un dígito cuando lo calculaste, Guillermo?

Un saludo:

miguelkm · #**245** (**permalink**) 16-mar-2009, 22:56

Cita:

Iniciado por Guillermo Luijk

Por qué no haces una cosa? calcula el histograma RAW de ese archivo y sales de dudas. Es facilísimo, con dcraw.exe o con dcrawMS.exe si tienes Vista, haces:

dcraw -v -D -T -4 -t 0 archivo.cr2

Y el tiff que te sale, lo abres en Histogrammar (instala la v1.1 y sustituye su ejecutable por el que viene en el enlace de la actualización v1.2 que aunque se llama igual tiene mejoras) y pasas a modo RAW. Haciendo zoom podrás ver exactamente dónde y cómo satura cada canal.

Salu2

Gracias de nuevo.
He hecho lo que me dices y obtengo esto:
Total pixels: 8269656 (3522x2348 image)
Black levels: {0;0;0} -> {0%;0%;0%}
Burnt levels: {0;0;0} -> {0%;0%;0%}
Histogram maximum: 34858 pixels in level G=3168

Filled levels:
R: 2314 (3,5% of available)
G: 3048 (4,7% of available)
B: 2965 (4,5% of available)
Dynamic range:
RGB: 3052 (5% of available), range [117..3168]
R: 2337 (4% of available), range [117..2453]
G: 3048 (5% of available), range [121..3168]
B: 3051 (5% of available), range [118..3168]
Tonal quality:
R: 3,5% levels, 17,1% gap std dev, 81,7% ampl std dev
G: 4,6% levels, 0% gap std dev, 78,6% ampl std dev
B: 4,5% levels, 74,1% gap std dev, 85,7% ampl std dev

..y

Sólo parece que se satura el verde en 3168, aunque no sé si es eso lo que quieres que vea (cuánto ignorante con cámara

).

Saludos.
===========
EDITO
===========

He estado haciendo pruebas con otras imágenes y éstas sí le dan la razón al gui:

Total pixels: 8269656 (3522x2348 image)
Black levels: {0;0;0} -> {0%;0%;0%}
Burnt levels: {0;0;0} -> {0%;0%;0%}
Histogram maximum: 2284503 pixels in level G=3398

Filled levels:
R: 3258 (5% of available)
G: 3238 (4,9% of available)
B: 3242 (4,9% of available)
Dynamic range:
RGB: 3258 (5% of available), range [141..3398]
R: 3258 (5% of available), range [141..3398]
G: 3238 (5% of available), range [161..3398]
B: 3242 (5% of available), range [157..3398]
Tonal quality:
R: 5% levels, 0% gap std dev, 583,3% ampl std dev
G: 4,9% levels, 0% gap std dev, 1573,2% ampl std dev
B: 4,9% levels, 0% gap std dev, 766,8% ampl std dev

No sé lo que le pasaría a la imagen esa...

Saludos y gracias de nuevo

Guillermo Luijk · #**246** (**permalink**) 17-mar-2009, 00:34

A qué ISO estaba hecha la que te dio el valor 3168? he rescatado (aún lo tenía) el RAW del usuario de la 30D con el que calculé el 3398 y estaba bien calculado (eran a ISO100):

Sí que es rara esa fluctuación, porque está claro que tu 3168 es una saturación. Por cierto que con ese 3168 la foto ya te sale perfecta no?

miguelkm · #**247** (**permalink**) 17-mar-2009, 00:40

Pues sí, la imagen es a 640 ISO, debe ser por eso, en las otras que he probado a 100 ISO el valor era el que tú dabas, 3398.
Y sí, sale bastante bien con 3168, pero sólo esa foto. Cuando le he querido aplicar ese nivel de saturación a otras he visto que no funcionaba, por lo que me he puesto a probar a pasar otras imágenes por el histogrammar y ahí es cuando he visto que realmente el nivel era 3398. Sin embargo en todos los casos, desaparece el color rosa, pero los blancos que no se han saturado a tope aparecen azules... fundamentalmente con el balance de blancos en "auto". Cuando pongo el de cámara el color azul casi desaparece. De momento lo soluciono aumentando la exposición un poquitín para que se terminen de reventar (para fotos con fondo blanco puro) y quedan bien.
Oye, un lujazo el programa, el día que admita AdobeRGB y modo batch (eso último, por pedir que no quede...) me doy de baja de los demás

Es una delicia como trabaja las texturas finas como el pelo, sobre todo con AHD.
Saludos y enhorabuena.

Guillermo Luijk · #**248** (**permalink**) 17-mar-2009, 01:08

ISO640 es un ISO falso, seguramente es un ISO800 subexpuesto -1/3 por software, posiblemente de ahí la disminución del punto de saturación (aunque no me cuadran del todo las cifras pero bueno).

Los ISO software no aportan nada, y está visto que no dan más que quebraderos de cabeza. No deben usarse nunca disparando en RAW.

Cuando uses Perfect RAW asegúrate de que nunca usas la opción de recuperación de luces a 1 porque puede crear dominantes en altas luces total o parcialmente saturadas. Ponle 0 (para imágenes ligeramente subexpuestas) ó valores >=2 (para imágenes derecheadas).

De todos modos los tonos azules que dices pueden ser normales, son saturaciones parciales seguramente, y el culpable de que aparezcan fuiste tú

Salu2

Lassus · #**249** (**permalink**) 17-mar-2009, 03:10

Cita:

Iniciado por ManuelLlorens

Aún me queda mucho trabajo con ella. Puede parecer que está avanzada pero no es más que una prueba de concepto. Tenía una idea que sonaba bien en teoría y necesitaba ponerla a prueba. Lo que pasa es que el resultado me ha gustado tanto que no he podido evitar subir estos ejemplos. Pero es muy chapucera la forma de hacerlo. Ahora que sé que va a funcionar bien tengo que rehacerla desde cero e hilar más fino.

Además, la idea era no subir más versiones de perfectRAW con el interfaz antiguo así que ya veremos .

No te preocupes, esperaré

, que de momento con lo mío tengo ya bastante para ir probando.

Me ha entrado la curiosidad y rebuscando entre los archivos viejos he recuperado mi filtro de reducción de ruido. Tendría que tener el tuyo para hacer pruebas, pero a simple vista el mío parece menos potente. Lo añado al dcraw compilado que he puesto en el hilo de WPG por si te interesa probarlo.

Cita:

Iniciado por ManuelLlorens

Por otro lado, ¿por qué dices de filtar con menor potencia los píxeles verdes de la matriz? En principio el ruido afecta por igual a los tres canales y encima en los verdes es donde mejor se detecta. Lo que sí haría yo es filtrar menos el ruido verde de crominancia cuando lo hagamos porque produce muchos menos manchurrones de color (debido a su mejor distribución espacial). El ruido de crominancia rojo y azul tiene una frecuencia más baja.

Mmm... no tiene ningún sentido. El caso es que lo escribí convencido, jaja, supongo que pensando en cómo funciona el filtro de mediana (que no es exactamente una mediana) en el que estaba trabajando, que filtra después y no antes de interpolar.

Estoy intentado mejorarlo con un buen algoritmo para ordenar kernels grandes, tipo quicksort o heapsort. ¿Se ha usado ya un algoritmo de éstos en dcraw, que así me ahorro escribirlo? Necesito que ordene todos, no me vale con que me dé sólo el valor central.

Cita:

Iniciado por ManuelLlorens

No me he puesto todavía con ello porque primero quiero probar (para eso he diseñado este nuevo algoritmo) hasta dónde podemos evitar que se produzcan los manchurrones de color (color blotches).

Pues salvo en un algoritmo pensado especialmente para ello, yo creo que no hay ni habrá demasiada diferencia entre los demás en este punto. Son medidas tan distantes del píxel que no se tienen en cuenta a la hora de interpolar. Lo que sí se podría hacer son dos interpolaciones paralelas, una de ellas prefiltrada a tope, y mezclarlas después en modo LAB.

Cita:

Iniciado por ManuelLlorens

En cuanto Emil lo autorice colgaré ejemplos de su algoritmo, pero de momento no está suficientemente terminado.

Tengo curiosidad infinita por verlos.

Cita:

Iniciado por ManuelLlorens

Si te animas y tienes tiempo (francamente no sé de dónde lo sacas ) podrías probar esto, que tiene muy buena pinta pero adaptándolo para trabajar sólo con la crominancia y radios muy grandes.

Le echaré un vistazo, desde luego la imagen de muestra es espectacular (tanto que no sé si creérmelo). Jeje, pues llevo un montón de fines de semana en que no he podido ponerme por unas cosas u otras, y todo lo que avanzo es robando horas al sueño como ahora. En verdad delante del ordenador paso poquito tiempo, lo más normal es que en el bus o comiendo me venga la idea a la cabeza y luego la pruebe en casa.

Me voy a la cama corriendo. Un saludo.

ManuelLlorens · #**250** (**permalink**) 17-mar-2009, 11:01

Cita:

Iniciado por Lassus

No te preocupes, esperaré

, que de momento con lo mío tengo ya bastante para ir probando.

Me ha entrado la curiosidad y rebuscando entre los archivos viejos he recuperado mi filtro de reducción de ruido. Tendría que tener el tuyo para hacer pruebas, pero a simple vista el mío parece menos potente. Lo añado al dcraw compilado que he puesto en el hilo de WPG por si te interesa probarlo.

Claro. A ver si acabo hoy de corregir y puedo hacer alguna prueba.

Cita:

Iniciado por Lassus

Estoy intentado mejorarlo con un buen algoritmo para ordenar kernels grandes, tipo quicksort o heapsort. ¿Se ha usado ya un algoritmo de éstos en dcraw, que así me ahorro escribirlo? Necesito que ordene todos, no me vale con que me dé sólo el valor central.

¿Por qué no lo intentas mejor con histogramas? Es la única forma decentemente rápida de calcular medianas de kernels grandes.

Cita:

Iniciado por Lassus

Pues salvo en un algoritmo pensado especialmente para ello, yo creo que no hay ni habrá demasiada diferencia entre los demás en este punto. Son medidas tan distantes del píxel que no se tienen en cuenta a la hora de interpolar. Lo que sí se podría hacer son dos interpolaciones paralelas, una de ellas prefiltrada a tope, y mezclarlas después en modo LAB.

No creas, sí se tienen en cuenta a la hora de interpolar la crominancia porque tiene mucha menos resolución que la luminancia. El propio AFD original utiliza solo un filtrado bilineal para la crominancia. De hecho, el problema con los manchurrones de color es precisamente ese, que el algoritmo trata de encontrar algo donde no lo hay y confunde un grupo de píxeles rojos anormalmente altos con una mancha roja. Prueba en PS y modo LAB a filtrar los manchurrones de color aplicando un filtrado gaussiano a los canales a y b a ver qué tamaño de kernel necesitas para que desaparezcan (yo creo que con menos de 25 no se consigue un resultado aceptable). Eso evidentemente destroza el color en los ejes. Ahora hace falta algo similar pero con un tamaño del kernel adaptativo o bien un kernel fijo con una máscara (el método más complejo pero el más preciso y hace falta precisión a tope). Yo creo que ambas cosas funcionarán mejor que una mediana, pero hay que probarlo. Ambas cosas funcionarán muy bien. En zonas con mucha variedad de color y poca variedad de luminancia (es raro, pero puede pasar) suavizará demasiado el color, pero al fin y al cabo los manchurrones de color habrían "borrado" la información original... en un caso así... no uses ISOs altas

(esa debería ser una norma fija: si la precisión en el color y su resolución es crítica, entonces no se debe usar nunca ISOs altas).

Cita:

Iniciado por Lassus

Tengo curiosidad infinita por verlos.

Yo también

. No, en serio, tienen muy buena pinta. Sólo queda por que deje perfectas las diagonales saturadas, pero he visto algunas pruebas de Emil y la cosa promete.

Cita:

Iniciado por Lassus

Le echaré un vistazo, desde luego la imagen de muestra es espectacular (tanto que no sé si creérmelo). Jeje, pues llevo un montón de fines de semana en que no he podido ponerme por unas cosas u otras, y todo lo que avanzo es robando horas al sueño como ahora. En verdad delante del ordenador paso poquito tiempo, lo más normal es que en el bus o comiendo me venga la idea a la cabeza y luego la pruebe en casa.

Sí, la imagen del artículo es tramposa, eso está claro. Pero si navegas por su página tienen ejemplos "más reales" y siguen estando muy bien. La idea del filtro gaussiano de radio variable me gusta.

Cita:

Iniciado por Lassus

Me voy a la cama corriendo. Un saludo.

¡Ten cuidado que correr cansado es muy peligroso!

.

Un saludo: