OJODIGITAL

Ok, es fácil de implementar.

Para calcular el diafragma al que pertenece un píxel supongo que habrá que tener en cuenta un entorno alrededor de él, ¿no? En caso contrario en imágenes con algo de ruido podría salir muy mezclada la cosa.

Se podría hacer un mapa con la luminosidad AFD luego emborronarlo con una mediana 3x3 (todo eso ya está implementado), ajustar la atenuación de ruido según esa luminosidad (eso es una chorrada que se puede controlar con un simple checkbox), y luego terminar de revelar con AFD (eso también está implementado en la atenuación de ruido), volver a revelar con AHD y mezclar según el mapa de luminancia, que al estar emborronado ya tendría cierta progresividad pero respetaría bien los bordes al haberlo hecho con una mediana. Se podría especificar el diafragma con un slider (habría que hacer un cálculo a ambos lados del valor especificado para usar la progresividad dentro de ese margen y no usarla fuera) y con un checkbox controlar si se hace la mediana del mapa de luminancia o no. El proceso sería bastante lento, pero no más lento que revelar con AHD con la atenuación de ruido actual activada, sería casi igual de rápido que eso.

Bueno, lo probaré cuando tenga un rato, se implementa en menos de media hora. Aunque luego habrá que hacer pruebas con muchas imágenes para ver el resultado, eso lleva más tiempo.

A ver si os animáis a revelar y colgar cosas, que las imágenes atraen más que tanta letra y el foro está un poco dormido.

Lo de DxO Mark sí lo había visto. Pero me da rabia que pongan datos de las Olys y luego no las soporten en sus programas.

Por cierto, voy poco a poco montando las fotos que hice de las instalaciones del colegio usando AFD + ZN (con antighosting cuando es necesario y progresividad siempre) + AutoPano. Están quedando muy bien, ya colgaré por aquí alguna cuando las tenga listas, aunque es verdad que con ZN tiene más sentido usar AHD pero me hacía ilusión probar. Lo siguiente que quiero probar es AFD en BN usando el balance de blancos de dcraw para calibrar los canales + ZN + AutoPano en algunas de ellas (aunque por desgracia las hice un poco rápido y no mantuve todos los diafragmas que me habría gustado mantener en la toma más oscura de alguna escena).

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sí claro, la distinción nunca sería a nivel de píxel sino mucho más bruta, por ejemplo calcular para cada píxel un booleano que indique si los píxeles circundantes en un radio R (este radio puede ser circular o incluso cuadrado para acelerar el cálculo) caen por encima o por debajo del umbral, y se tome para el píxel en cuestión el valor predominante en el radio (es decir la moda estadística): si predominan píxeles bajo el umbral -> AFD, si predominan píxeles por encima del umbral -> AHD.

__________________

Canon EOS 5D | EOS 350D | EOS 300 | 10-22 | TS-E 24 f3.5L II | 24-70 f2.8L | 70-200 f4L
http://www.guillermoluijk.com para suscribirte pulsa aquí

O sea que primero hacemos un umbral del mapa de luminosidad con valores 0/1 teniendo en cuenta la moda dentro de una celda n x n y comparándola con un diafragma de corte. Si está activada la mezcla progresiva lo emborronamos con una media gaussiana 3 x 3 para la progresividad con valores entre 0 y 1 y con eso mezclamos ambas interpolaciones, ¿no? En plan:


Y para acelerarlo, si no hay progresividad activada directamente elegimos el píxel en cuestión.

Yo creo que la progresividad no hace falta que sea demasiado exacta y podemos usar algo más rápido que un filtro gaussiano en coma flotante. O bien un kernel gaussiano en variable entera o bien un box blur o similar. Teniendo en cuenta que no va a notarse una diferencia de luminosidad entre una interpolación y otra no habrá ningún problema porque la progresividad no sea muy exacta. Tampoco creo que merezca la pena usar una progresividad mayor que 3 x 3. No usaría una mediana porque entonces no va a suavizar nada los bordes y en un mapa de unos y ceros no hará prácticamente nada... sí podría usarse directamente la media.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

yo creo que en la decisión de como fusionar es mejor contener el número de transiciones AFD/AHD que ser muy precisos, para que la imagen final no sea un Frankenstein de parches. cualquier método rápido y fácil de implementar que cree zonas amplias reveladas con uno u otro algoritmo estará bien.

__________________

Canon EOS 5D | EOS 350D | EOS 300 | 10-22 | TS-E 24 f3.5L II | 24-70 f2.8L | 70-200 f4L
http://www.guillermoluijk.com para suscribirte pulsa aquí

A ver si esta tarde tengo un rato después de comer e implemento estas mejoras. De paso tengo que cambiar mi avatar, que ya lleva fijo demasiado tiempo .

En otro orden de cosas, Gábor, autor de RAWTherapee está interesado (contacté yo con él por el tema) en implementar en su programa nuestra eliminación de laberintos. Eso hará de RT un producto mucho más interesante para los usuarios de Olympus y Panasonic y al mismo tiempo dará difusión a perfectRAW.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Estoy terminando la interpolación mixta AFD/AHD. Primero un ejemplo de qué hace mejor cada algoritmo. En este trozo de imagen se aprecia perfectamente (mejor descargadlas para comparar superponiendo las distintas imágenes):








Como se ve claramente AFD tiene mayor resolución, no solo trata mejor el ruido que AHD. Sin embargo en algunos puntos falla y crea puntos demasiado destacados que no quedan naturales, HPHD (RAWTherapee) hace algo muy similar, un poco menos evidente tal vez, aunque a cambio crea más palitos en las zonas ruidosas que AFD, que no crea ninguno. NLD (DxO Optics) no falla en nada evidente, pero junto con HPHD parece exagerar el ruido. En ambos programas no he sido capaz de obtener un resultado verdaderamente RAW a pesar de que ambos tienen ajustes que dicen ser neutrales. Yo diría que ambos aumentan un poco el contraste sin decir nada, a parte de las diferencias en el balance de blancos. En DxO desactivé la corrección de aberraciones cromáticas y la reducción de ruido (que la verdad es que mejora mucho el resultado sin quitar textura). HPHD sí tiene un paso de reducción de artefactos de color (el que viene por defecto en RT).

La versión mixta AFD/AHD es bastante correcta, aunque el umbral tendría que haberse situado un poco más alto pues algunas zonas de la sombra han salido de AHD y eso no es correcto. El caso es que jugando con el umbral puede dejarse una imagen casi perfecta.

Que me perdonen los dueños de los RAWs porque he olvidado de dónde he sacado cada uno, aunque probablemente sean de internet.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Este es el mapa AFD/AHD de otro RAW:


Aquí un detalle de la progresividad, calculada mediante una media simple (rápido y suficientemente progresivo):


Y este es el resultado final... descargad y superponer para ver las bastante sutiles diferencias.





Un saludo:

Personalmente, salvo por los "puntitos fuera de lugar" que genera de vez en cuando AFD, me quedo con AFD para todo. Extrae mucho más detalle en las texturas y no pierde nada en los bordes. Si consiguiera un modo de detectar esos puntos durante la interpolación y los promediase con el entorno quedaría absolutamente perfecto, desde mi punto de vista, aunque precisamente para eso puede usarse la atenuación de ruido que ya implementé.

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Si os resulta interesante lo limpio y lo dejo como método de interpolación en la próxima versión especificando el diafragma. Creo que la progresividad es bueno dejarla, dado que ha demostrado no afectar a la calidad de la imagen.

Voy a buscar algún ejemplo con formas más geométricas y zonas oscuras con más ruido.

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

He encontrado otro revelador RAW con algoritmos de interpolación propios y con resultados prometedores, pero no he sido capaz de hacerlo funcionar (me arranca pero no consigo que me revele una imagen completa). El interfaz es un poco pesado, se me parece al de DxO, también pesado y lento.

El nuevo competidor se llama RawHide y ha sido harto complicado de encontrar (¿será por lo de hide? ). Si a alguno le funciona que ponga por aquí resultados.

En otro orden de cosas, he implementado en plan experimental este algoritmo de interpolación como posible sustituto por defecto de la interpolación bi-lineal, pero no me ha convencido el resultado porque cambia el color de la imagen y la desplaza, aunque eso sí, es muy rápido y obtiene resultados mucho mejores que BL. Creo que no lo dejaré implementado.

De momento el campeón en el balance calidad/velocidad sigue siendo sin duda alguna PPG.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel, después de un rato trasteando con él he conseguido que me funcione con la opción "Send to editor" con un par de RAWs de la Canon G9 que había bajado de internet.

De entrada no diría que es mejor que AHD. Extrae más detalle (textura) y parece un poco más rápido que AHD pero a cambio de más artefactos.

Esa mejora en el detalle se nota sobre todo al usar la opción multipass, pero se ralentiza mucho el revelado.

Te dejo en breve (se esta subiendo) un enlace con uno de los RAW por si quieres probar AFD y los jpg a máxima calidad.

Un saludo.
_________________________________
Voilà: enlace

¿Puedes poner un ejemplo del cambio de color y desplazamiento del posible sustituto de la interpolación bi-lineal para hacernos una idea?
_________________________________
Edito de nuevo: no hace falta que te tomes la molestia de subir las muestras. Ya lo he probado.

Gracias Lassus, llevas razón, así sí funciona. He actualizado el artículo de arriba con los dos algoritmos interesantes de RawHide, ACC y ECW. Los resultados son muy parecidos a AFD, algo mejores tal vez, al menos en el interior de las letras, fuera de ellas es similar.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

¿En serio crees que supera a AFD? Fíjate en el bajo del zócalo de la primera imagen o en los puntos rojos de los conos de la tercera, yo creo que no compensa:













De todos modos creo que RawHide no es open source, así que no se podrá implementar ACC en PerfectRAW. Manuel, ¿¡para cuando tu algoritmo!?

Se parece mucho a AFD, pero parece cometer menos errores. Efectivamente RawHide no es open source y aunque lo fuera sus algoritmos no parecen merecer la pena.

Intentaba realizar una especie de catálogo (de hecho tengo en mente un proyecto similar más ambicioso) de los algoritmos actuales que se autoproclaman mejores que el resto para ver cómo quedaba AFD/AHD situado entre ellos.

En este momento yo creo que en imágenes con ruido AFD es superior al resto por cómo trata el ruido y lo rápido que es. En imágenes sin ruido NLD se lleva el gato al agua, aunque con ruido tampoco se comporta mal, aunque yo creo que lo replica, lo cuál tiene sentido teniendo en cuenta cómo funciona.

Lo bueno de NLD es que al estar basado en un algoritmo de generación de texturas cuando falla lo hace de un modo creíble, nunca aparecen colores raros y eso tiene su valor. Por contra, es con diferencia el algoritmo más lento de todos.

La combinación EAHD y HPHD de RawTherapee también es una elección adecuada porque uno lee muy bien las líneas (el que mejor de todos, incluido NLD) y el otro trata muy bien el ruido (yo creo que un poco peor que AFD pero prácticamente igual). Si hiciera Gábor implementara una mezcla de ambos al estilo AHD/AFD sería la caña.

En cualquier caso aún quedan montones de algoritmos por evaluar (unos 10 tengo identificados como interesantes). Lo mejor que he visto últimamente es uno que primero interpola a lo largo de los ejes de la imagen (lo cual deja las diagonales perfectas, como el Kolev Raw, y luego rellena los huecos respetando el ruido como AFD, pero aún no he visto sus resultados, solo una somera descripción.

La idea de interpolar primero en la dirección de los ejes es muy buena, de hecho estoy haciendo unas pruebas utilizando primero AHD (porque identifica muy bien los ejes), aplicando un kernel laplaciano de 9x9 y una reducción de ruido para sacar los bordes y luego la idea sería rellenar con AFD los huecos y mantener AHD en los ejes. Ese sería una primera aproximación, luego reinterpolaría en la dirección del eje con un algoritmo lineal a ver qué sale. Las primeras pruebas a base de PS no son demasiado esperanzadoras. Fundamentalmente porque el filtro laplaciano no detecta bien todos los bordes que sería interesante detectar sobre AHD:


Lo malo es hacerlo funcionar en imágenes superruidosas... aunque en esas imágenes se puede usar AFD tal cual y punto.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Ya que estáis mirando algoritmos de interpolación de-mosaico prometedores aunque poco conocidos, quizá os interese echar un vistazo a éste; está tó en ruso, pero afortunadamente han hecho una versión PDF en inglés, que además parece tener fórmulas y explicaciones detalladas.

Lo apunto, otro candidato más a probar el día de mañana. Por cierto tiene una versión ejecutable y descargable de su algoritmo de interpolación SmartEdge, supongo que lo has visto. La versión 2 del algoritmo no parece disponible.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Una pregunta tonta de recien llegado:

Si un sensor capta 1/3 de la información de la toma real en la matriz de bayer y luego interpolamos (inventamos información), ¿los pixeles que tendrá la imagen final dependerá de cuanto hallamos interpolado?.
¿Se podría obtener una imagen de menos píxeles interpolando menos, siendo más precisa?

Un saludo.

Hola,
Me alegra ver esa sinergia entre proyectos, creo que eso es muy positivo!
Un saludo

Efectivamente, de las 4 x RGB componentes que hay en cada cuatro píxeles sólo se obtienen 2 x G + 1 x B + 1 x R = 4 componentes, un tercio de las que había en la imagen real, pero distribuidos espacialmente con el mismo tamaño que la imagen original. Al interpolar añadimos las componentes RGB que faltan de cada píxel, pero no aumentamos de tamaño la imagen.

Sí, es posible si reducimos a la mitad horizontal y verticalmente la imagen obtener una imagen casi perfecta, al menos sin problema de aliasing (y supongo que se podría hacer mejor aún desplazando un poco los planos de color). Pero no sé si merece la pena (de hecho dcraw ya incluye esa opción como un revelado rápido).

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sí, yo también.

Creo además que en concreto RawTherapee y perfectRAW no compiten directamente porque tienen filosofías de trabajo muy diferentes y me gustaría poder usar RT para las fotos de mis Olys, porqué no.

RawTherapee es sin duda el revelador gratuíto (que no open source por razones que Gábor explica en su web y que me parecen totalmente loables) más maduro.

Por otro lado, el esfuerzo de Gábor por mantener RT como un revelador de primera línea es absolutamente loable.

También me he puesto en contacto con los autores de algunos algoritmos de interpolación que me han parecido interesantes, creo que es bueno que sepan que estamos interesados en implementarlos (los que aún no lo están en ningún producto) y que puedan contribuir si quieren. De momento no he obtenido respuesta de ninguno de ellos.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sobre el tema de la interpolación y la invención de información por parte de los algoritmos, creo que este ejemplo puede resultar esclarecedor:


Esta imagen de laboratorio, con el verde a tope y nada de rojo ni azul, puede ser vista de los modos indicados de forma completamente dependiente del algoritmo de interpolación. No hay uno bueno y uno malo, porque no es posible distinguir cuál es el correcto.

Eso pasa mucho con las imágenes de laboratorio que se usan para probar los algoritmos de interpolación, de hecho, algunos algoritmos dan muy buenos resultados con imágenes naturales y mucho peores en imágenes de laboratorio y viceversa. En la imágenes naturales suele haber alguna correlación entre los canales que guía al algoritmo a la hora de tomar decisiones, pero en casos extremos no existe información que utilizar y el algoritmo se la tiene que jugar. Los algoritmos locales tienen que inventarse la información cada vez que llegan a esa situación (píxel a píxel), los algoritmos no locales (DxO y alguno más) por el contrario toman la decisión en función de un entorno más amplio o incluso optimizan toda la imagen a la vez. Son más lentos, pero toman decisiones más coherentes, aunque no exentas de errores.

Al final, hay algoritmos de interpolación para demosaicización que son mejores en ciertas circunstancias y peores en otras. Los criterios clave para seleccionar un algoritmo de interpolación son:

• Reconoce los bordes e interpola a lo largo de ellos (lo que evita artefactos de color en los mismos, que se producen al interpolar un borde perpendicularmente).
• Alta resolución en las texturas.
• No extiende el ruido de un captador a los de alrededor.
• No produce artefactos en texturas cercanas a la frecuencia Nyquist.
• Es rápido (aunque eso dependerá de la implementación y el uso que le demos).

Según estos cuatro parámetros podemos clasificar cada algoritmo de interpolación como mejor o peor para determinado tipo de imágenes. Por ejemplo, AFD cumple los tres primeros puntos, pero falla estrepitosamente en el penúltimo si la textura es paralela a los bordes de la imagen, por lo que es muy bueno para imágenes naturales. AHD sin embargo cumple el primero y el último siempre que las texturas sean paralelas a los bordes de la imagen, pero falla horríblemente (produciendo artefactos muy visibles) en el resto (por ejemplo en telas, con ruido, etc.). Tened en cuenta que ACR utiliza una versión modificada de AHD.

Desde mi punto de vista, NLD (DxO) es uno de los más equilibrados, aunque según como sea el contenido de la imagen también fallará en frecuencias Nyquist. Además trata bien el ruido porque no lo extiende pero sí lo replica, creando más ruido del que tenía la imagen original (o eso me parece a mí). Artefactos produce muy pocos y suelen tener una apariencia agradable.

El ejemplo opuesto es el algoritmo de interpolación de SilkyPix (estoy investigando cuál es) que es buenísimo en frecuencias Nyquist, hasta el punto de que es muy preciso con lo difícil que es eso pero sin embargo en imágenes "no de laboratorio" produce bordes muy suavizados y falta de textura.

Yo creo que ahora mismo, el algoritmo perfecto sería una versión modificada de AFD para que detectara las texturas Nyquist y dentro de ellas operara con un algoritmo diferente del que usa ahora. Esa es la línea de trabajo para mi propio algoritmo de interpolación, pero aún es poco más que una idea en papel.

En cualquier caso ahora la prioridad es terminar pefectRAW 1.0, en el que dejaré AFD/AHD como alternativa. Además, en AFD se podrán elegir ciertos parámetros de la interpolación que lo harán más o menos nítido.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel, una cuestión.

Te pongo el ejemplo de una web que visité ayer.
La web trata sobre carreras populares y cuando se celebra una suben del orden de 100-200 fotos hechas con una EOS.

Me pregunto, si nuestra salida final va a ser úcamente para internet (1mega por ejemplo) ¿no sería más rápido y lógico obtener de esa matriz de bayer una imagen final con los píxeles que nosotros pretendamos?, ¿por qué interpolar una primera vez y a partir de una imagen ya interpolada volverlo a hacer?,
¿no seria más rápido hacer 1 proceso por imagen en vez de 2, además de obtener más calidad en la imagen final?

Perdoname por insistir, un saludo.

No hay nada que perdonar, hombre. Para eso estamos. Además, a base de preguntar van surgiendo necesidades para el programa.

Entiendo que te refieres a que perfectRAW, cuando tenga el modo de proceso por lotes, pueda sacar una salida reducida al 50% como hace dcraw con la opción -h en vez de revelar la imagen completa y luego reducirla, ¿no?

Es cuestión de estudiarlo, no es difícil de implementar porque de hecho ya está implementado en el código de Coffin. Otra cosa es que ese sea el modo óptimo de reducirlas, habrá que hacer alguna prueba. En principio supongo que en los bordes introducirá algún artefacto de color por el medio píxel (una vez reducido) de diferencia entre unos canales y otros, quizás habría que desplazar los planos de color ese medio píxel, aunque eso complicaría el procesado y quizás no merezca la pena. En cualquier caso me temo que es funcionalidad post versión 1.0.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel, aunque no lo diga continuamente por no ser cansino, te agradezco mucho todas y cada una de las explicaciones y comparativas que vas subiendo. Muchas veces me quedan grandes, pero poco a poco me voy enterando de algo y puedo afirmar que lo poco que sé de los RAW lo he aprendido en este hilo.

En otro orden de cosas, ayer, navegando por los foros de Luminous Landscapes, me encontré con un hilo de _GUI_ sobre PerfectRAW y en él un usuario reportaba el siguiente problema:

No da más información. No sé si es algo conocido o no, simplemente lo digo por si os queréis poner en contacto con él.

Perfect RAW - Luminous Landscape Forum

Un saludo.

Uno de los objetivos fundamentales de perfectRAW consiste en ser un revelador didáctico, como lo es dcraw. El control de todas las fases del revelado sirve para obtener exactamente lo que uno quiere, pero también para entender a fondo en qué consiste el paso del raw a la imagen final. Si alguna explicación no se entiende, no te cortes en preguntar.

Que le conteste _GUI_ si no le importa, yo no he querido darme de alta allí porque sinceramente con este foro, lo que llevo por mail, la página del grupo de desarrollo en Google Groups y nuestra propia página web ya tengo bastante. Aunque de vez en cuando sí que sigo el tema en Luminous Landscape y en Cambridge in Colour. En la "stage 4" se hace la recuperación de altas luces, prácticamente seguro que este usuario ha puesto el valor a tope, quizás también el filtro mediana y espera un resultado inmediato.

La otra posibilidad es que se le quede sin memoria la máquina, pero es poco probable porque la fase que más memoria consume con diferencia es la interpolación.

Gracias por el aviso.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Como dices, una cosa es la teoría y otra la práctica. Al fin y al cabo es la práctica la que nos dice qué hacer.

Con respecto a este tema me ha surgido otra duda "existencial" .

Si pretendemos por ejemplo revelar un raw corrigiendo la saturación,
¿los programas de revelado interpolan la matriz de bayer, luego editan y luego pasan a tiff?
¿Se podría interpolar, editar, guardar esos ajustes, volver a la matriz, aplicar los ajustes a la matriz e interpolar finalmente?
Parece más lento pero más lógico que la interpolación sea lo último.

Yo creo que cualquier ajuste que modifique los canales de forma diferente debe hacerse forzosamente después de la interpolación. El ruido, por ejemplo, sí tiene sentido limpiarlo antes de interpolar, pero guiados por una interpolación, como hacemos ahora.

Cualquier cambio de otro tipo te echará por tierra el balance de blancos. Seguro que _GUI_ lo puede explicar mejor que yo.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Gracias, así lo haré.

Y empiezo ya mismo con una preguntilla: ¿AFD lo programaste a partir de un modelo matemático? Lo digo porque ayer navegando (en realidad buscaba otra cosa, pero llegué a una página con el enlace) vi unos pdfs de profesores de universidad con varios algoritmos que no conocía, al menos con la denominación utilizada. Éste es uno de ellos:

http://dmi.uib.es/~abuades/publicacions/CMLA2007-15.pdf

El artículo es de hace un año escaso y habla de los estudios de Hirakawa o Gunturck, que también están en internet, y propone uno no local con muy buena pinta. Yo a ese nivel me pierdo, pero dejo el enlace porque si no los conocías ya quizá se pueda sacar algo útil de ellos.



Por otra parte, había pensado que sería interesante hacer una herramienta tipo raw2dng, que teniendo dcraw y el código de Egon una vez lo pula no debería dar mucho trabajo. Así se eliminarían de un plumazo las incompatibilidades de los reveladores con los raw propietarios. ¿Cómo lo veis?

Me has dado pié a soltarte toda la información actual que tengo al respecto (con unas pequeñas reservas que me guardo para el futuro). Espero que resulte interesante al resto.

El artículo que enlazas es la descripción de NLD ("Non Local Demosaicing"), el de DxO precisamente (muy bueno, pero extremadamente lento y con tendencia a amplificar el ruido y a "volverlo gris"). Hace unas semanas que se lo pasé a Egon para que lo implemente cuando tenga "un ratillo" en la GPU a ver qué tal va. También puedes encontrar código MATLAB en la página del autor principal del algoritmo (para el algoritmo de denoising, pero que en el fondo es el mismo). Si te fijas en el artículo se agradece a DxO las imágenes de prueba (yo creo que más bien la implementación del algoritmo en código mínimamente eficiente, porque la versión MATLAB es lentísima) y en los enlaces de la página web de Antoni se enlaza a DxO como: "leader image restauration company" .

• Gunturk es autor del algoritmo AP (Alternating Projections, descrito en "Color plane interpolation using alternating projections" y con código MATLAB) un algoritmo que da buenos resultados y es rápido, pero no está a la altura de los mejores. Es uno de los candidatos a ser implementado en el futuro en perfectRAW como sustituto de BL como algoritmo por defecto. Al menos aparecía como rápido en algún artículo que he leído, aunque viendo la descripción del mismo y el código nadie lo diría... ya lo probaremos.
  
• Hirakawa es el autor del bien conocido AHD (Adaptive homogeneity-directed demosaicing con artículo y código MATLAB en este enlace), se suele citar como comparativa en los artículos porque es el que usan dcraw y, sobre todo, ACR.

Por otro lado, AFD = Adaptive Filtering for Color Filter Array Demosaicking de Nai-Xiang Lian, Lanlan Chang, Yap-Peng Tan y Zagorodnov, V. No tiene acceso gratuito pero sí código MATLAB. En el código fuente de la DLL de dcraw aparecen citados estos autores, obviamente. Me he puesto en contacto con ellos para que sepan que lo hemos implementado en perfectRAW, por si les interesa. De momento sin respuesta.

AFD lo implementé a base de seguir el artículo y luego ir comparando numéricamente etapa por etapa de la interpolación mis resultados con los del código MATLAB hasta lograr que los resultados fueran idénticos (porque a simple vista no es fácil estar seguro). Desgraciadamente los artículos están escritos para el mundo académico y de ahí al código MATLAB hay un abismo, a veces incluso el código hace cosas distintas a lo que dice el artículo (con AFD pasaba eso y me tuvo un tiempo loco). Os adjunto un pantallazo de lo que fue la fase de depuración del algoritmo una vez lo tuve implementado.

Como estos tengo otros tres algoritmos identificados y muy prometedores y estoy en contacto con uno de los mayores expertos en la materia (a él también le parecen muy prometedores los tres). Desgraciadamente, algunos autores no publican toda la información en sus artículos y dejan algunos detalles en el aire de tal modo que implementando lo que su artículo dice textualmente no llegas a los mismos resultados que ellos, o bien llegas a punto en el que te falta información. Los más valientes sí publican código MATLAB, lo que da un buen punto de partida. Esta presentación en PPT, precisamente de Gunturk (aquí en versión PDF un poco más completa), da una idea muy precisa del actual "state of the art", comparando los mejores algoritmos de interpolación (AFD y AHD están incluidos, ojito a DLMMSE y sobre todo a LPA). Hoy mismo ha aparecido publicado un nuevo algoritmo de interpolación con resultados muy buenos (utiliza técnicas parciales de AP y HPHD); está claro que el tema está en pleno auge, como todo el mercado de fotografía digital.

Los últimos algoritmos, podríamos decir que son de "nueva generación" (con NLD siendo el primero implementado en un producto final), utilizan información "menos local", buscando información en un entorno que les permita ser más precisos a la hora de deducir el modo de interpolar cada píxel. Además empiezan a contar con modelos matemáticos del ruido RAW con lo que lo tienen en cuenta a la hora de interpolar para no extenderlo o, en varios casos, actúan al mismo tiempo como filtradores de ruido (de nuevo NLD). Son invariablemente más lentos que los algoritmos locales que se usan ahora, por eso creo, y seguro que Egon está de acuerdo conmigo, que la próxima hornada de reveladores raw hará uso extensivo de la GPU. Nuestro revelador no perderá ese tren. También pienso que faltan por aparecer con fuerza (hay algún tímido intento) algoritmos basados en redes neuronales, optimización genética y lógica difusa, que podrían producir resultados espectaculares, aunque muy lentos (sí he visto algún intento con fractales y con optimización estocástica, que viene a ser casi lo mismo que un algoritmo genético).

Por otra parte hay que decir que los últimos algoritmos de interpolación están rozando la perfección incluso en los casos más complicados o con ruido (el caso complicado más famoso y reiterado en la literatura específica es la valla de la imagen Kodak del faro; aunque varios autores con los que estoy de acuerdo dicen que el conjunto de imágenes de Kodak que se suele usar para probar los algoritmos de interpolación no es la mejor forma de comprobarlos, pero aún así esa imagen ha quedado como un icono del tema).

Eso es exactamente el DNG Converter de Adobe, ¿no? Suele estar bastante actualizado, ¿qué aportaría de nuevo?

Un saludo:

Miniatura de Adjuntos

 

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Cuando tenga un rato repetiré la prueba que hice arriba con filtros laplacianos pero esta vez con operadores de Sobel, creo que saldrá mejor (la idea me la ha dado un artículo de interpolación de los de arriba). La cosa consiste es interpolar con AHD en los bordes y con AFD fuera de ellos, ya veremos qué tal queda, porque con los laplacianos no quedó nada bien.

Esta es la prueba rápida con PS (me temo que bastante cutre porque yo al menos no sé cómo calcular en PS el gradiente total de la imagen a partir de un operador horizontal y otro vertical , por lo que he tenido que usar la aproximación cutre) y operadores de Sobel (primero con Sobel, después con Laplacianos, la misma de arriba):



Probablemente habría que "engrosar" los bordes del mapa de gradiente de la imagen mediante un filtro máxima antes de usarlo para hacer la mezcla. Todo eso es fácil y bastante rápido por código (sobretodo porque los operadores de Sobel son enteros y separables).

Bastante mejor, pero aún no suficiente.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

En contestación a NaVas (aunque un poco tarde).
Lo que comentas de utilizar interpolaciones a la baja que sean más precisa, llevas razón.

De hecho desde hace varias versiones (no recuerdo cuáles) ACR permite escoger abrir el RAW con tamaños reducidos (submúltiplos del tamaño original) en donde hace interpolaciones especiales, que no utilizan el demosacing para luego interpolar a la baja (y aseguran que da mejores resultados que interpolar a la baja con photoshop).

Si utilizar una imagen de la mitad de tamaño en cada dirección, entonces ya no sería necesario un demosaicing en el sentido estricto, en donde nos inventamos los canales que no existen, pues en cada pixel generado tenemos información procedente de pixels rojos verdes y azules que están a la misma distancia.

Creo que no sería difícil variar la parte de interpolación para permitir hacer eso, modificando los algoritmos de demosaicing.
Pero también creo que en este momento distraería del objetivo principal que está buscando Manuel de conseguir hacer un algoritmo que de la imagen con la resolución máxima y los mejores resultados.
Así que sería mejor dejarlo para un futuro.

__________________
Canon EOS 40D + Tamron SP AF 17-50mm f2.8 XR LD Aspherical (IF) + Tamron SP 90mm f/2.8 Di Macro + Canon EF 70-200mm f/4 L USM+ Yongnuo YN460

Manuel, interesantísimo de principio a fin. La verdad es que no había visto las referencias a DxO, simplemente eché un vistazo a las imágenes de varios pdfs, guardé los enlaces y seguí a lo mío. Los resultados medidos y las imágenes de LPA son muy prometedores, y sí tú dices que tienes localizados otros tres...

Desde MatLab sé que se podía llamar código de C, pero a la inversa muchas operaciones de MatLab no tienen un equivalente directo en C. ¿No habrá por ahí alguna librería que permita traducirlas para agilizar un poco?

Los problemas que le veo al Adobe DNG Converter son tres:

-Pesa 35.1 MB, a todas luces exagerado.
-Últimamente está tardando y unos tres meses más que Coffin en sacar la primera versión con compatibilidad beta.
-El soporte de algunos RAWs es deficiente. Por ejemplo con mi LX3 (según Adobe porque la compatibilidad aún no es total, pero también pasa con cámaras antiguas) solamente da la opción de guardar un DNG lineal con el demosaicing ya hecho, que ocupa el triple del RW2 original y tiene la distorsión de barril corregida.

En realidad no hay ninguna necesidad para hacer un raw2dng, pero ya que Zero Noise va a leer los RAWs propietarios que estén soportados por DCRaw y va a escribir un DNG seguro que apenas supone tiempo crear una utilidad paralela de línea de comandos que haga la conversión pura notablemente mejor que la de Adobe.

Un saludo.

Siguiendo en la linea de lassus, dng no me permite procesar mas de 30 imagenes de golpe.. lo mismo estoy haciendo algo mal, pero no deberia haber limite de imagenes ¿no?..

Bueno aunque no era la intención original, bastaría fusionar un RAW consigo mismo en el futuro ZN

__________________

Canon EOS 5D | EOS 350D | EOS 300 | 10-22 | TS-E 24 f3.5L II | 24-70 f2.8L | 70-200 f4L
http://www.guillermoluijk.com para suscribirte pulsa aquí

Parece el chiste famoso de cómo apaga un matemático una casa que no está en llamas.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Jajaja, qué malo.

Acabo de terminar de introducir los cambios de Coffin en la versión 8.89 de dcraw. Curiosamente ha retirado el soporte para algunas cámaras antiguas, no sé con qué fin pero quizás para preparar un próximo cambio más grande.

De paso he introducido el método de interpolación VCD ("Color Demosaicing Using Variance of Color Differences"), uno de los algoritmos modernos más prometedores, tal como lo acaba de implementar Paul Lee, autor de la implementación de AHD que lleva dcraw. También he metido el filtrado de mediana sensible a ejes (edge sensitive median filter) que ha creado Paul como acompañamiento a VCD.

Ambos algoritmos (VCD y es-median filter) son bastante lentos y aún estoy comprobando su calidad. Personalmente, a menos que Paul haya cometido algún error al implementar, no veo que VCD aporte nada a AFD. Los presultados se parecen mucho a AFD pero mucho más lento.

Sin embargo, en el artículo que lo describe los resultados son mucho más prometedores. El experto que os comentaba el otro día con el que hablo de estos temas ya me había advertido que él intentó implementar ese mismo algoritmo con resultados mucho peores que los del artículo, eso quiere decir que o bien los autores han falseado los resultados (poco probable), o bien se han guardado un as en la manga, o bien la implementación no es correcta (yo creo que es correcta, pero incompleta).

Respecto a es-median filter, es en sí mismo un algoritmo de interpolación (está basado en "Hybrid color filter array demosaicking for
effective artifact suppression"), es lento y consume mucha memoria. Es muy curioso cómo trabaja: si aplicas a una interpolación bilineal ese algoritmo, el resultado es una interpolación mucho mejor .

Lo más gracioso de todo este es que estos dos artículos que os cito estaban entre los tres que os decía el otro día que tenía identíficados pero cuyos datos no di porque estaba trabajando en ellos... ¡increíble la puntería de Lee!

Menos mal que aún me quedan dos balas en la recámara que pienso mantener en secreto... de momento .

En cuanto pueda arreglo algunos bugs más que he ido identificando y subo perfectRAW 0.65 con unos cuantos cambios para que probéis.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

He cambiado la atenuación de ruido AFD para que, como Egon quería (y llevaba razón, que conste que la idea es suya), tenga en cuenta la luminosidad del entorno de cada píxel, de modo que atenúe más en zonas oscuras y menos en zonas claras. El resultado, por eso de la pedantería, se llama: Adaptive Noise Attenuation y tiene en cuenta la luminosidad del entorno de cada píxel y la "pinta" de píxel ruidoso que tenga. La fórmula ha quedado así:

noise_attenuation=100/exp(10*(max+min)/maximum);

con max y min el máximo local y el mínimo local de la celda 3x3 alrededor de cada píxel (sin contar el propio píxel, claro) y maximum el valor de saturación de la cámara; noise_attenuation es lo que en el front-end se llama attenuation level, que ahora pasa a ser automático. Eso es el valor de atenuación de cada píxel, el valor de detección de píxeles ruidosos (en el front-end noise detection) sigue siendo configurable y funciona como antes.

El objetivo es reducir el ruido visible manteniendo la máxima textura y, además, que el ruido restante tenga un aspecto de grano fino fotográfico.

Además, debéis tener en cuenta que la atenuación de ruido de perfectRAW no pretende limpiar todo el ruido, sino sólo dejar una imagen agradable que luego, según el gusto de cada uno, podrá filtrar más en un programa adecuado, especialmente el horrible ruido de crominancia.

Yo creo que los resultados son muy buenos pero claro, puede que sea pasión de "padre". Mejor juzgáis por vosotros mismos.

La imagen de prueba, la de siempre, de una Nikon D700 a ISO 25600 (casi ná ), el resultado bueno es el penúltimo. Comparación con ACR de PS4 (con sus inconfundibles palítos AHD). Todas las muestras sin enfoque, la de PS4 reducido el contraste para igualar a las otras:


Desde mi punto de vista el resultado es perfecto, vamos, si lo comparáis con lo que da DxO, que se supone que es el no va más en cuanto a ISO altas, este resultado se lo lleva de calle. Fijaos cómo se ha mantenido perfectamente la textura en las letras que dice "Pure Brewed".

Quizás se podría mejorar pidiéndole a Noiseware que quitara menos ruido de crominancia de frecuencia alta y subiendo un poco la saturacion al final del proceso... voy a probar...

... he quitado menos ruido de crominancia de alta frecuencia (se nota mucho en las letras pequeñas rojas "SAMUEL SMITH'S...") y esta vez he quitado una pizca de ruido de luminancia sólo en frecuencias medias y bajas. No he tocado la saturación, pero sí he dejado una pizca del enfoque propio de Noiseware. Creo que el resultado es aún mejor que antes, incluso acepta un poco de enfoque sutil con el algoritmo adecuado (que no he aplicado):


Otro trozo de esta última imagen en el adjunto.

Lo importante de nuevo es demostrar que la atenuación de ruido de perfectRAW deja la imagen muy preparada para tratarla posteriormente sin perder nada.

Buff... qué tarde se me hace, pero es que se envicia uno de ver tan buenos resultados y no hay quien pare. Creo que este finde voy a aparcar el ordenador que mi familia me lo pide a gritos.

Un saludo:

Miniatura de Adjuntos

 

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Se me ocurre que quizás el parámetro noise detection también se pueda ajustar según la luminancia de la zona en lugar de especificarse manualmente, de modo que en las zonas luminosas un píxel tenga que "sobresalir" o "subsalir" mucho más para ser considerado ruido que en las zonas oscuras.

Lo probaré, porque en las imágenes de arriba aún quedan algunos píxeles oscuros llamativos. Pero creo que eso sí que acabará eliminando algo de textura y dejaría muy poco control manual, mientras que ahora se preserva la textura maravillosamente bien. Además, son tan poquitos que se podrían eliminar a mano (se ve un punto negro de ese tipo en la letra rde la palabra Brewed y otro a la izquierda de la O de Olive).

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Hazle caso a la familia, que un día de estos te cortan la luz en el momento de máxima inspiración.

Yo los resultados los veo estupendos.

He probado VCD y tampoco he notado ninguna mejoría. En algunas cosas supera a AHD pero me pareció que tenía más fallos que aciertos, al menos tal cual está implementado. Por cierto, algo he debido hacer mal con es_median_filter() porque me da unos halos espantosos. No os pasa, ¿no? Ya lo revisaré esta tarde.

Y una última cosa que ahora no puedo comprobar: me pareció notar que con AFD se notaba demasiado el paso de los bordes obtenidos con border_interpolate() a la imagen en sí, aunque a lo mejor lo he soñado, todo es posible.

Un saludo.

Sí, algo así me harán .

Estoy charlando del tema con Paul Lee por mail. Está ajustando ciertos parámetros del es-median filter. Esta tarde echaré un vistazo a ver cómo ha cambiado la cosa, pero en las imágenes que me ha mandado por mail tiene muy buena pinta el cambio. Por otro lado, su implementación de los canales rojo y azul es distinta a la del algoritmo VCD y los artefactos se producen sobre todo en esos canales. Le he pasado un pantallazo para que lo mire. Me temo que el artículo no contiene toda la información necesaria para implementarlo y Paul ha tenido que tirar por la tangente.

Si la imagen tiene ruido se nota una barbaridad, si no tiene ruido no se nota casi nada.

Al fin y al cabo la interpolación del borde que hace Coffin es lineal a secas. Una posibilidad que habrá que explorar algún día es la siguiente: en vez de interpolar el borde linealmente (como hacen ahora TODOS los algoritmos de interpolación de dcraw), se podría ampliar la imagen reflejándola hacia fuera por los cuatro lados y las cuatro esquinas, interpolar y luego recortar (es lo que suelen hacer los algoritmos en MATLAB). Obviamente sería más lento y, especialmente en las esquinas, podría producir algún artefacto. Habría que extender siempre un número par de píxeles para no tener que cambiar los filtros de Coffin, pero desde luego se notaría mucho menos la diferencia de interpolación.

Si te animas a probarlo tú, eso que me ahorro yo.

Un saludo.

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Una idea que podría ser la bomba pero que es ciencia ficción:

Si se pudiera modificar el firmware de las cámaras que tienen estabilizador mecánico en el sensor (como mi Oly 510 y si fuera posible hacer eso desde el firmware, claro) para que disparara dos fotos seguidas pero moviendo el sensor un píxel lateralmente entre ambas, tendríamos el canal verde completo y podríamos realizar una interpolación perfecta.

La versión cutre es tratar de mover la cámara un pelín entre foto y foto, pero dudo mucho que así a boleo se consiguiera mover la cámara justo un píxel, porque si no no vale.

¿Se os ocurre alguna técnica para lograr mover el sensor un píxel exacto entre foto y foto? ¿Tal vez un dispositivo electro-mecánico previamente calibrado y ajustado a la zapata del trípode?

Otra idea inspirada por alfaromeo1990. ¿Se os ocurre algún dispositivo/filtro que acoplado delante de la lente permita a la cámara obtener una imagen en B/N pero en frecuencias visibles y sin perder calidad de imagen? Con algo de ese tipo también obtendríamos una interpolación perfecta de la imagen (tirando una foto con y otra sin el chisme).

Todo esto para fotos tipo ZeroNoise, claro. Para escenas con movimiento no vale.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Pongo el último resultado con el ruido en el tema del tratamiento del ruido en perfectRAW:

Tratamiento del ruido en perfectRAW

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

mover un pixel, no seria mejor 3 sensores por pixel, una maquina de 21mp se quedaria en 7 que tampoco esta mal, si quieren eso esta a la vuelta de la esquina ¿no?

Eso es precisamente lo que hacen los captores Foveon X3. Echa un vistazo a las fotos de la Sigma DP1 a resolución completa y verás.
_________________________________
Estoo... Yo ayudaría encantado, pero hay un pequeño problema: la primera vez que vi un código de C fue esta semana... Me queda un poco grande todavía.

Efectivamente, eso es lo que hacen las Foveon. La idea era logar algo parecido con nuestras cámaras con sensores "estándar".

Disculpa Lassus, es que te vi muy suelto mencionando las funciones de Coffin que hacían cada parte .

De todos modos ponte con ello y pregunta, ¡te lo vas a pasar bomba!

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sí, me sé el nombre de algunas funciones porque me puse a revisar el código para irme enterando de algo. Pero voy muy lento, ¡aún estoy con la interpolación bi-lineal!

¿Tienes la versión 0.65 funcionando? Hay un chico en el foro Panasonic de dpreview que obtiene un montón de laberintos en la parte derecha de la imagen al revelar el RAW de la G1. He probado con AHD, VCD, VNG y PPG y se siguen notando. Como AFD precisamente va bien para el 4/3 quizá la G1 sea una buena fuente de usuarios.

El RAW es éste: P1000191.RW2 - File Shared from Box.net - Free Online File Storage

Y el hilo éste otro: G1- strange sensor mosaic problem - experts please have a look!

Leer el código de Coffin es harto complicado. Por eso te digo que preguntes si quieres. Entenderás mejor mi implementación de la interpolación bilineal de 4 canales que la de Coffin de 3 porque él escribe C alienígena.

El equilibrado de canales verdes funciona desde la versión 0.5 y elimina completamente los laberintos de esa y otras imágenes (lo acabo de probar con ese raw y lo deja niquelado). Yo no puedo postear en dpReview porque no admite mi cuenta de gmail y paso de crearme una nueva sólo porque a ellos les apetezca.

Así que por favor contéstale tú al sufrido comprador de la G1 que con perfectRAW no obtendrá ningún laberinto sin sacrificar ni un ápice de calidad y que probablemente RawTherapee acabe incorporando algo similar en el futuro. Súbele el ejemplo que pongo abajo revelado con perfectRAW y AHD para que lo flipe todo el mundo . Si quieres explicarle porqué se producen los laberintos dile que Panasonic y Olympus utilizan una matriz de bayer con diferente sensibilidad en los canales verdes para tener un rango de tonalidades verdes más extenso, pero que eso no se lleva bien con los algoritmos de interpolación de tres colores y es necesario equilibrar los canales verdes antes de la interpolación. Deja claro que perfectRAW es el primer revelador (y el único de momento) que soluciona completamente el problema. Deja claro también que además de los laberintos producidos por el desequilibrado de los canales verdes, AHD siempre interpretará el ruido como palitos, pero que eso no tiene ya nada que ver con los canales verdes ni con la cámara, para eso es para lo que sirve AFD.



Muchas gracias.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Le estoy escribiendo el mensaje (gracias por el pantallazo, jeje).

El soporte para los RAWs de la G1 debió añadirse en dcraw 8.88 u 8.89, por eso te decía lo de la versión 0.65 porque a mí con la 0.6 no me lo abre. Espero antes de publicar nada por si quieres subir una versión modificada para que le funcione.

Un saludo.

¡Ah, es verdad! Aún no puedo liberar la 0.65 porque tengo medio implementados los últimos cambios de Paul Lee y han aparecido algunos bugs nuevos (no sé si relacionados con haber metido el código de la última versión de Coffin o no). Si puedo esta noche limpio un poco el código y libero la versión 0.65 con VCD, es-median filter, el adaptive noise attenuation y finalmente el control completo de AFD.

Pero pon el post ya en dpreview y dile al chaval que espere un poco a que liberemos la siguiente versión que así creas más expectación.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Bueno, ya está puesto, con una traducción en inglés macarrónico y casi literal de tu anterior post.

Me acabo de pasar por la página de Paul Lee y ya tiene subida la versión 11 de VCD. Quizá solucione alguno de los problemas que te da.

Un saludo.