Tema: WPG: nuevo algoritmo de interpolación

Abro este hilo para discutir cuestiones relacionadas con WPG, que hasta ahora se venía haciendo en este otro hilo y los mensajes cruzados complicaban su lectura. Si consideráis que está mejor en otro subforo movedlo de sitio.

Copio un extracto a modo de introducción:

Iniciado por Lassus

Describo un poco lo que llevo hasta ahora:

Todo partió de la referencia del algoritmo "pixel grouping" (Pixel Grouping for Color Filter Array Demosaicing), que como la vi tan sencilla me animé a implementar los verdes. La idea de los gradientes tan cercanos al píxel a interpolar me pareció buena, pero se equivocaba en las zonas más difíciles y tenía bastantes píxeles aislados fuera de tono y artefactos de color.

Pensando un poco, probé a ponderar cada gradiente por la inversa de su aportación a la suma de gradientes. Lo hice sin mucha fe por ser algo tan elemental, pero el resultado me sorprendió.

Ya profundizando un poco saqué unos multiplicadores para regular la nitidez al gusto. Ahora es el lo que estoy, para cada imagen funcionan mejor unos que otros y tengo que encontrar una fórmula para definirlos sin que haya que introducir nada. En esta imagen he usado los valores que considero por defecto. La idea es hacer diagonales claras sin que se disparen de píxeles aislados para que se pueda aprovechar que al interpolar no se crean halos como en Photoshop.

Todo es muy rudimentario todavía. De momento y hasta que encuentre algo mejor, el canal rojo y el azul se interpolan con VCD. La velocidad de proceso es buena, entre PPG y VCD, y el consumo de memoria ridículo

Y la imagen con los resultados (tarda en cargar):



_________________________________

Iniciado por ManuelLlorens

Yo lo que quiero es ver un ejemplo de tu algoritmo con ISOs altas y sin postprocesado, lo que he visto de momento me ha convencido a favor de tu algoritmo sobre AHD y AFD.

Aquí va, sin posprocesado, refinado ni nada que se le parezca. He usado los multiplicadores por defecto, cuando se optimice la elección de cada uno en función del píxel debería mejorar bastante la nitidez. De hecho tengo resultados mucho mejores que éste:

Iniciado por ManuelLlorens

Tus resultados son MUY buenos, fallan en Nyquist como AFD (se nota en el extremo derecho de la barandilla), pero no sacan píxeles raros como AFD, lo cual ya es un gran avance. Desde mi punto de vista AHD no es una opción en muchas imágenes con texturas finas.

Puse ese recorte precisamente por la barandilla, que AFD y WPG la hacen de forma sorprendentemente parecida. Consigo que salga bien a costa de estropear otras partes, y no encuentro el umbral que defina el acceso sólo esos píxeles.

A mí AHD no me parece un algoritmo de propósito general, de hecho no lo uso nunca. Supongo que será cuestión de gusto, pero para mí sus fallos no compensan nunca sus aciertos.

Iniciado por ManuelLlorens

¿Qué tal saca WPG la zona de debajo del cartel de Allianz? Con las ramitas superpuestas al azul y la textura de la cortina de debajo. Esa zona AHD la destroza y AFD destroza las ramitas:

Esa zona se las trae. La saca muy parecida a como lo hace AFD. Te mando el algoritmo por mail para que lo pruebes tú mismo, así me ahorro hacer el GIF.

Iniciado por ManuelLlorens

Ya sabes que ese algoritmo es el PPG de dcraw, ¿verdad?

El código de Coffin es difícil de entender, pero yo creo que tiene añadidos sobre la versión original.

Iniciado por ManuelLlorens

Aquí nos tienes a la espectativa de tus progresos. Si consigues sacar bien el trozo de la imagen de la Pentax que te sugiero más arriba te haces famoso.

Si alguien puede conseguir eso seguro que eres tú. Lo de que hacer pasadas de mediana y refinado y este algoritmo hayan funcionado lo considero más una cuestión de suerte o de oportunidad que de entender mínimamente del tema. Cuando veas la sencillez del algoritmo comparado con los otros te vas a reir, en serio.

Las bandas oblícuas de color que saca VNG RGGB intuyo que no son un problema del algoritmo utilizado, sino de la propia arquitectura de los sensores BAYER o los filtros que lleva delante.

Iniciado por ManuelLlorens

Una vez que tengas un algoritmo que interpole bien en función de un parámetro, debes encontrar la manera de deducir automáticamente el valor de ese parámetro para cada zona de la imagen en función de su contenido. Eso supongo que es lo estás intentando ahora.

En eso estoy, pero no hago progresos notables. A ver si a ti se te enciende la bombilla.

Iniciado por ManuelLlorens

El criterio post-interpolación que utiliza AHD (la homogeneidad de cada píxel) es bueno, de hecho es muy bueno. El problema es que AHD sólo puede elegir con ese criterio entre interpolar horizontalmente y verticalmente (cuando para sacar bien la imagen de la Pentax tendría que hacerlo en diagonal). Quiero decir con esto que también puedes interpolar (por zonas, en caso contrario no tendrás memoria) para ocho valores de tu parámetro (8 direcciones de interpolación por ejemplo o probar con los cuatro gradientes más fuertes) y luego elegir el que da una zona más homogénea. Eso es lo ideal si elegir el parámetro a priori es difícil y tienes todo el código en la implementación de AHD para copiar (yo en su día diseñé un AHD con diagonales, que se basaba en eso, pero no llegué a implementarlo).

Hice una prueba con gradientes diagonales pero no funcionó muy bien. Aunque ahora se me está ocurriendo otra forma, luego me pongo.

Iniciado por ManuelLlorens

El algoritmo debe tener además un control adicional del parámetro que haga que si ninguna dirección parece claramente privilegiada el píxel no se extienda, para las imágenes ruidosas. Eso es lo que me parece más difícil de lograr, que no deje de interpolar direcciones y al mismo tiempo no se pase haciéndolo. Pero también se podrían tener dos versiones del mismo algoritmo para con y sin ruido o un parámetro controlable por el usuario (el algoritmo de Emil tendrá varios de hecho).

En eso funciona como AFD con pattern matching, sin extender el ruido. ¿Es a lo que te refieres?

Iniciado por ManuelLlorens

Si el algoritmo quita ruido antes de interpolar, entonces el usuario debería poder controlar esa fase mediante algún parámetro.

Eso ya es para nota, de momento con todo lo que le queda de camino no veo necesario ponerse con ello.

Iniciado por ManuelLlorens

La diferencia entre los dos canales verdes es fundamental. Los algoritmos que interpolan considerando cuatro en vez de tres canales no cometen errores como los que usan tres (mira arriba el resultado de RGGB), pero sacan menos detalle, lógicamente. Es imprescindible, por tanto, tener en cuenta que son canales independientes por un lado pero extraer detalle de ambos a la vez en otras zonas. Del balance correcto de esa deducción dependen las diagonales y los bordes en zigzag (que sigue siendo el único problema del algoritmo de Emil, aunque ya ha avanzado bastante en ese sentido).

La verdad es que tiene mucho sentido, pero ¿cómo se hace? ¿Cómo se mezclan después los verdes?



Manuel, no pretendo pasarte el testigo, que ya bastante tienes con perfectRAW. Yo seguiré trabajando en ello, pero en el fondo sé que no podrás resistirte a hacer pruebas y que pondrás aquí los resultados.

¡Un saludo!

Lassus, estoy muy liado con el curro y otros temas, pero no pierdo de vista tus resultados con WPG.

Un saludo:

Manuel, sigo en ello con el tiempo que saco de aquí y de allá. He mejorado un poco los resultados con unos gradientes más precisos y un umbral adaptivo para hacer que el algoritmo se moje más a la hora de interpolar en una dirección u otra, pero tampoco hay un salto grande con respecto a como estaba.

También he hecho otros dos algoritmos, provisionalmente bautizados como FCD (Fast Conservative Demosaicing) y RGE (Reiterative Gradient Estimation). El objetivo del primero es ser lo más rápido posible (de momento es un 15% más veloz que PPG). Es conservador a propósito para que sea equilibrado y tenga menos falsos colores (el objetivo es que, si se equivoca, no lo haga demasiado para que no se note al 100%). A ISOs altos también va mejor. El resultado es bastante decente, creo. Si te interesa para ponerlo por defecto en perfectRAW dímelo y te lo paso.

El segundo se basa en hacer la mejor estimación posible de los gradientes e interpolar en función de ellos sólo en horizontal o en vertical. Creo que éste le va a gustar a Guillermo porque, sin cortar las líneas, tiene menos artefactos que AHD. Es un 60% más rápido que AHD y aún está sin optimizar (tengo una versión "capada" que, obteniendo un resultado muy parecido, tarda la mitad que RGE). A ISOs altos es enfocado, pero crea palitos.

Os pongo un pantallazo sobre la marcha de RGE. En esta zona en particular el que lo hace mejor es WPG, y yo diría que FCE, el que tarda menos que PPG, mejora incluso a AHD y AFD:



Muchas siglas juntas, ¿verdad?

Un saludo.

Pásame el código de los tres para probarlos como Dios manda y pongo por aquí una comparativa en distintas situaciones. Efectivamente puede que dejemos alguno de ellos como algoritmo por defecto.

Un saludo:

Manuel, te respondo por mail.

Para quien lo quiera probar: descarga. Es el dcraw de toda la vida (tutorial aquí) con las siguientes opciones añadidas:

-q 4: AFD (el mismo que aparece en perfectRAW).
-q 5: FCD (muy rápido, para máquinas viejas o procesar grandes lotes).
-q 6: WPG (tiene un pequeño bug, pero sigue siendo bastante válido para todo).
-q 7: RGE (para sustituir a AHD en ISOs bajos).

Muchas gracias, Lassus. En cuanto tenga un rato haré una comparativa completa de tus nuevos algoritmos.

Un saludo:

Duro con ellos, que para eso están.

Para ISOs altos iban mejor la primera versión de WPG que te pasé y, por supuesto, AFD. A ISOs bajos distan bastante de ser perfectos, pero sirven para el 98% de las fotos. Por ejemplo en el RAW de la Pentax RGE sigue fallando en las cortinas, pero hace la barandilla perfecta. Los detalles normales (fotos de edicicios, retratos, bodegones) debería hacerlos con bastante solvencia, y los bordes (tanto rectos como curvos) mejor que AHD.

Lassus, aver si este finde pruebo esos algoritmos. VCD lo he descartado totalmente, ví unos fallos graves ayer que solo hacía él.
Por ahora uso PPG y AFD.

¿Podrías pasarme el raw de la "botella"?

NaVaS, he estado unos días fuera, perdona el retraso.

El archivo para probar ISOs altos es éste. Para probar algoritmos también utilizo éste como muestra de una imagen de mundo real y éste otro para comprobar el comportamiento en casos extremos (la carta central).
Ya me comentarás si te resultan útiles los algoritmos que he subido.

Aprovecho para exponer mis últimos progresos brevemente:

-He escrito un filtro de mediana de radio ajustable y que si se quiere puede discriminar en función de la lejanía del valor respecto de los valores extremos (despeckle) o aplicarse a todos los valores (blur).
-He creado un par de nuevos algoritmos, uno de ellos es bastante más rápido incluso que FCD. Del otro ya daré detalles más adelante.
-He afinado VCD. Ahora es un algoritmo serio, con gradientes más homogéneos y menos píxeles disparados, y que puede utilizarse perfectamente para todo. Se lo tengo que enviar a Paul.
-He optimizado RGE. En verdad la imagen revelada no cambia, pero el proceso es un poco más rápido.

Y estoy con:
-Un algoritmo especialmente pensado para imágenes ruidosas.
-Un nuevo tipo de gradiente para elegir la dirección de interpolación que seguramente exporte a RGE, WPG, etc.

Creo que voy a hacer una web con una comparativa en condiciones y donde vaya subiendo las nuevas versiones del dcraw compilado. Mi objetivo es terminar sólo con tres algoritmos: el ultrarrápido, el de propósito general y el de imágenes ruidosas. De los otros también publicaré el código por si alguien lo quiere utilizar pero no los compilaré, que tantas siglas son un verdadero lío.

A ver si me pongo este fin de semana, que hasta entonces estoy justito de tiempo.

Un saludo.
_______________________________________________
_______________________________________________
He montado los nuevos gradientes y la interpolación del píxel por ratios en RGE y ésta es la diferencia (el archivo proviene de la página de Jacek Góźdź, LinuxPhoto.org):



Dirección más homogénea, menos artefactos, más detalle y más nitidez.

Lassus, puedes poner un ejemplo del nuevo RGE con ruido. Tiene una pinta genial.

Un saludo:

Manuel, por su diseño el algoritmo hace palitos, aunque parece que menos que antes y desde luego menos que AHD. Mi primera impresión es que da una imagen ligeramente más enfocada que afd, aunque el ruido sea más feo. No es la mejor opción pero al 100% es usable. Aún no pongo el pantallazo porque crea píxeles negros aislados y no sé muy bien por qué, imagino que es cosa de dividir entre los píxeles no captados. Cuando lo arregle la subo.

El gran problema es que trabajar con ratios en coma flotante ralentiza bastante los cálculos. El nuevo RGE es lento, aunque la diferencia creo que merece la pena.

Aprovecho y subo un nuevo dcraw compilado ya con versiones de dos de las tres líneas que quiero desarrollar. Este fin de semana tampoco pude, a ver si en el puente saco tiempo, hago la web con la comparativa, le pido permiso a Paul para publicar su VCD modificado y subo los códigos fuente pulidos.

Añadidos a dcraw (descarga):

-q 4 => Nuevo RGE por ratios. Está sin optimizar en cuanto a velocidad y consumo de recursos, pero creo que ya puede considerarse usable. Debería ser el plato fuerte de todos cuantos algoritmos he hecho, por favor, probadlo y comentad por aquí.

-q 5 => Interpolación FDD. Creo que mejora a PPG siendo incluso más rápido. La relación calidad de imagen / tiempo de revelado es muy buena, tardando sólo un 51% más de tiempo que la bilineal (por dar una referencia, en mi ordenador AHD tarda catorce más).

-N a b => Filtrado de ruido añadido a propósito para otro hilo. La "a" es el número de pasadas que hace el filtro, mientras que la "b" es el umbral. En principio valores entre 0.25 (más intensidad) y 1 (intensidad normal) son los más adecuados.

Cualquier fallo o pregunta comentado por aquí.

Un saludo.

En cuanto tenga un rato hago las pruebas.

Un saludo:

Comparando por partes. Primero FDD.

Entiendo que el algoritmo FDD de Lassus está diseñado para ser muy rápido y mejorar la calidad de PPG. Veamos si cumple con estos preceptos, en cuyo caso podría pasar a ser el algoritmo por defecto en perfectRAW por méritos propios.

Utilizando el ejecutable de Lassus tenemos los siguientes tiempos para el revelado completo:

• Bilinear ... 1.234 s
• PPG ........ 1.609 s
• FDD ........ 1.297 s

Como se ve es apenas más lento que la interpolación bilineal y considerablemente más rápido que PPG (habría que repetir el test con muchas imágenes y varias veces con cada una y hacer medias, pero nos vale con esto de momento).

Ahora vamos a ver si la calidad de la interpolación es igual, mejor o peor que la de PPG. El caso de interpolación más difícil que yo he encontrado hasta ahora es éste:


Como se ve FDD mejora sensiblemente a PPG en las ramitas. Quizás algún detalle lo haga mejor PPG pero en conjunto FDD es mejor.

Así que ya tenemos un ganador como nuevo algoritmo de interpolación por defecto en perfectRAW: el FDD de Lassus, ¡enhorabuena!

Un saludo:

En cuanto a RGE.

Por las pruebas que he hecho (no subiré pantallazos hasta que no arregles los puntos negros, como tú dices) me ha parecido bastante mejor que AHD para imágenes sin ruido (aunque comete el mismo tipo de errores que él cuando falla en la dirección de interpolación y saca peor alguna diagonal) e igual de malo que AHD para imágenes con ruido... bueno quizás un poco mejor que AHD porque sus palitos son más cortos.

De momento es bastante lento, pero eso se podrá optimizar. Además el algoritmo de Emil no será más rápido, eso seguro.

Lo que sí me ha sorprendido es lo bueno que es FDD comparado con AHD en imágenes sin ruido... sobretodo teniendo en cuenta lo rapidísimo que es. Cuando tenga un rato subo una comparación FDD vs AHD vs RGE en imágenes sin ruido incluyendo los tiempos de procesado.

Un saludo:

Gracias por los comentarios, Manuel. Lo de las diagonales de RGE me trae de cabeza. Son el motivo de los puntos negros a ISOs altos, así que ahí aún puede afinarse algo. El otro problema que tiene son unos puntitos blancos (quizá los equivalentes en ISOs bajos de los negros) que acompañan a las diagonales por el exterior. Seguiré con ello. Cualquier otro fallo coméntalo por aquí.

FDD está diseñado para interpolar en una sola dirección (horizontal o vertical), como PPG y como AHD, de ahí que los resultados se parezcan. AHD sigue siendo bastante mejor si se mira con lupa, pero para revelado rápido de lotes o en ordenadores lentos FDD va mejor en imágenes ruidosas y en las demás aguanta el tipo.

A ver si consigo interpolar la crominancia sin que haga cruces (ahí se gana mucha velocidad) para que no extienda el ruido.

Yo ya había hecho unas tablas de tiempo. Hice cinco revelados de cada serie con cada algoritmo y elegí el mejor tiempo en cada archivo (en verdad todos eran muy parecidos). Utilicé un dcraw compilado con DevC++ y el ordenador recién reiniciado.


AMD Athlon XP 1700+ con 1024 MB DDR RAM y Windows XP Proffesional SP3:



Como referencia AHD es 13.81 veces más lento que la bilineal.


Pentium 4 a 3 GHz con 512 MB DDR RAM y Windows XP Proffesional SP2:



Aquí FDD tarda menos que la bilineal. Tiene que ser cosa de la implementación de Coffin porque desde luego el algoritmo es más complejo.

¡Un saludo!

Iniciado por Lassus

Aquí FDD tarda menos que la bilineal. Tiene que ser cosa de la implementación de Coffin porque desde luego el algoritmo es más complejo.

Supongo que tiene que ver con las optimizaciones del compilador. ¿Porqué no te pasas a VC++ 2008 Express?

Un saludo:

Subo nueva versión (v.02) del ejecutable. La vieja puede seguir descargándose aquí: v.01.

Cambios:

• He acelerado RGE todo lo que he podido (más ya no creo que lo consiga). Ahora es un 35% más rápido que AHD.

• He arreglado un poco (no del todo) las diagonales de RGE.

• También he mejorado el rendimiento de RGE a ISOs altos. Sigue teniendo algún punto negro, pero son muchos menos que antes. Además ya no crea tantos palitos y da una imagen muy enfocada. Sigue sin ser óptimo para imágenes ruidosas pero ya no da el cante.

• He añadido una versión simplificada del viejo WPG con los últimos añadidos que hice a RGE. Sigue siendo tipo AFD en no mojarse a la hora de hacer las líneas rectas y en su buen rendimiento a ISOs altos. A partir de él desarrollaré mi algoritmo para imágenes ruidosas, seguramente adaptándolo para trabajar con frecuencias en lugar de secuencuencialmente como hasta ahora.

Así pues:

-q 4: RGE
-q 5: FDD
-q 6: WPG
-N a b: Reducción de ruido (a=pasadas, b=umbral). El filtro es el mío, no el de Manuel que se discute en otro hilo.

Iniciado por ManuelLlorens

Supongo que tiene que ver con las optimizaciones del compilador. ¿Porqué no te pasas a VC++ 2008 Express?

Sé que debería, especialmente para estos ejecutables que voy subiendo, pero hay dos cosas que me echan para atrás. La primera son los fallos de compilación allá donde yo veo líneas bien escritas, supongo que será cuestión de cogerle el truco. Y la segunda es que DevC++ tiene una versión portable que llevo en el pendrive y me viene de perlas para ponerme en donde sea si saco un ratito.

Saludos.

dear lassus. i wanted to ask how your work on the new demosaicing algorithms is progressing? i have tested all of your implemented algorithms, and i found that RGE gives me the best results with G1 files. i love the look of WPG, but overall there are too many artefacts like zipper noise. RGE manages to decode my files better. lines are rendered nicely. but some artefacts still remain, especially with diagonals. but everything is looking much better than HPHD for example. still regarding smooth lines, DCB from jacek gozdz is unbeatable, at the cost of sharpness and detail of course. i also found that DCB is not the best algorithm for microstructure and natural irregular patterns like foliage. i like RGE more in this case, WPG is even better. the only problem remains with straight diagonal lines, that tend to become staircase artefacts.

it also sems as if highlight recovery didn't work well with RGE yet. i have found some strange artefacts in recovered highlights that were not visible when using AHD.
i cannot provide any samples now, i need more time for this, i have had quite a lot to do for work lately.

is there any chance that we will see one of your algorithms integrated into perfect raw or somewhere else?
i really consider using RGE for all my raw conversion work, but without any GUI only using dcraw as tool it is not very inviting and intuitive.

btw. when can we have the first perfect raw 0.7 beta for tryout?

ps. btw i see that you were using one of my old LX3 files for testing.

Oluv, I'm very sorry for having used one of your files without asking for permission, it's not usual that I don't point the source. I cannot figure which file you are referring, could you point it so I can add your authorship?

I keep working on the algorithms, but I have little time now. Improving RGE is possible (in fact I have already done it). Basically it's a choice between speed and quality, and it's hard to guess which is the optimum combination for both things. I will always choose quality over speed, but probably most people don't want to wait more than five seconds in the demosaicing step. Just out of curiosity, as you said you may use RGE for your RAW conversion work, what would be your choice?

I'm aware of the highlight recovery problem but I thought the version I had uploaded had that issue solved. I will check the code again. Thanks for pointing this. As for the straight diagonals I can try to add some kind of support if you like.

FDD, RGE and WPG are open to perfectRAW or any other developer I trust. The only limitation is a part of RGE code I don't wish to be published because it's the base for another algorithm.

DCB output is too soft for me. It does not create zipper artifacts but produces false colors and deals poorly in noisy images. For example, in the well-known lighthouse photo from the Kodak CD, these are the results:



I will think about a way for combining accurate directions and smooth, artifact free pixel interpolation. Output image will be softer, but it may be prefereable for some cases.

Best regards.

[BTW, Egon, gracias por darle permiso a Paul para que me enviara el archivo del faro, no sabía que lo habías creado tú o de otra manera te lo hubiera pedido directamente. Y ya que estamos, ¿no tendrás por casualidad más DNGs del Kodak CD o que me puedan servir para tener referencias del PSNR de mi último algoritmo? O si has compilado una alpha de la aplicación para "bayerizar" jpgs, aunque sea sin interfaz y con limitaciones de tamaño, espacio de color, bordes, etc. te estaría eternamente agradecido si me la pasaras].

lassus, you missunderstood me, please don't worry because of the raw-file. i originally uploaded it because someone asked me for some LX3 files. this was btw one of my very first test-shots i took with the LX3:


yes i know DCB is quite soft, and i am aware of the false color artefacts, but these are usually very rare in most cased. on the other hand i have lots of files that suffer either from zipper noise or staircase artefacts.
jacek claimed that his latest DCB version is not that soft anymore. unfortunately i still haven't got it yet. hopefully i will be able to test it within the next days.

i attached an example where i see a definite improvement in RGE over HPHD. but DCB, although very soft, manages to render this scene much more naturally. it also sharpens up quite well, here is the original raw-file if you want to play with it:
http://dl.getdropbox.com/u/893528/P1000125.RW2


of course i am after quality. i don't care much about slowness, i would wait 1 minute if the quality was optimal. hopefully the raw conversion or demosaicing is managable as a batch-process, so waiting shouldn't be an issue.

btw, what is RPC? in your example it is nearly indistinguishable from the original. i think it looks even better

what is the other algorithm you are referring to?

some time ago in dpreview-forum a guy called "fujicoly" announced a new raw-converter he was working on and asked for some raw-files. in another thread he had showed some results and comparisons which looked very promising, unfortunately i couldn't find them now. i haven't heard anything from him again for several months, so i doubt i ever will...

but i am very interested in some high-quality demosaicing and i am willing to pay for it if it really works. ACR is quite crappy with G1 and LX3, C1 is not that bad, but also applies lens-distortion. raw therapee with HPHD is quite ugly with my G1 (besides i have to fight with labyrinth artefacts all the time, but this is another story).

so if you are up to something, i am very curious to test it and share the results.

Hahaha, I can't believe it! I was absolutely conviced that the photo you have posted was taken by me!! I even send the RAW as a LX3 file example to fujicoly. Probably I have downloaded it one or two days before buying the LX3 and just put the file among the rest of my own RAWs. The first days I did a lot of test shots and since then I believe it was my photo. Sorry for the misunderstanding!

The algorithm I referred is RPC. It is a theoretical approach, intended for reaching the best PSNR measure. It has a nearly-perfection color rendition and deals nice with false colors, but the final output may suffer from severe zipper artifacts and overshooted pixels, so do NOT use it with usual city shots like the last you have posted. It's also veeery slow. I'm currently using it for portraits, landscapes, macro, irregular lines architecture (cathedrals and similar) and any kind of photo in which demosaicing artifacts are visible at 100%.

It will be nice to see a new DCB version.

Wait a minute and I will compile a new dcraw with it.
_______________________________________________
_______________________________________________
Oluv, these are the options of the compiled dcraw:

-q 4 remains as RGE v2.
-q 5 is a new version of FDD, slightly faster and accurate.
-q 6 remains as WPG v2.

For testing purposes (for the last three be sure to have a huge amount of free RAM memory available):

-q 96: FDD_mod. Created two minutes ago. It's an old FDD version with diagonal gradients. Obviously I haven't had time for testing it yet. It's just an experiment for making comparisons with original FDD so we can decide which approach is better.

-q 97: RGE v3. Much slower, worse high ISO behaviour, but better straight line rendition. For me it doesn't pay the difference. It does not include any kind of diagonal support yet.

-q 98: JDDFD. An alpha version of the future high ISO algorithm that will replace WPG. There is a big room for improvement at each step as I haven't seriously started with this algorithm "in depth". The only up-to-date step is the refining part. Luminance and chrominance are extracted from old filters. It's just for having an idea of the powerful tool it could be. Usage "-q 98 -J a b c d e", where a is the number of luminance noise removal passes, b is luminance noise removal treshold, c is the number of chominance smoothing passes, d is edge sensing strength and e are the number of an improved EECI refinement passes. The current kernel is a 5x5 R-G, B-G median in the chrominance space, filter to come must be much faster. A good starting point is "-q 98 -J 1 0.75 2 200 1".

-q 99: RPC. Described above. There are three options for changing its behaviour: -R a b c, where a is the treshold where the algorithm decides to weight horizontal and vertical lines instead of choosing between them, b are the number of median passes performed to the gradients (should be lower for microstructures, higher for straight lines) and c are the refinement passes (lower leads to worse color rendition and high ISO performance but may avoid overshoted pixels). Default (-R 2.15 2 2 1) is already optimized for most cases. [Edited: "a" option seems to be unoperative, sorry].

I have included a batch encoder for processing a huge amount of files with one single click. It is not mine but from Speek website.

Iniciado por Lassus

The first days I did a lot of test shots and since then I believe it was my photo. Sorry for the misunderstanding!

so you either have been to vienna, or you must have the same building in spain . this is the natural history museum btw. i have taken hundrets of photos from there, as the place is near my work and seems perfect for camera-testing with lots of micro-structure:
Museums Photo Gallery by oluv at pbase.com

i also used the museum as motive to discover some assymetrical lens-softness with my G1-lens. the softness was hardly visible with "normal" photos.

Iniciado por Lassus

The algorithm I referred is RPC. It is a theoretical approach, intended for reaching the best PSNR measure. It has a nearly-perfection color rendition and deals nice with false colors, but the final output may suffer from severe zipper artifacts and overshooted pixels, so do NOT use it with usual city shots like the last you have posted. It's also veeery slow.

i am very curious to try it out as well. is RPC your algorithm?

Iniciado por Lassus

It will be nice to see a new DCB version.

jacek hasn't responded yet. but i assume the new version will be as sharp as the first versions, but with improved zipper-noise. i was able to achieve some nice results with older versions of DCB, like this, only foliage and the irregular stone-texture are looking "odd". but straight lines are decoded nicely:
bildercache - professionell kostenlos sofort und schnell Bilder hochladen und bearbeiten, drehen, spiegeln, verkleinern

later jacek decided to go for a stronger post processing, that blurred the images too much for my taste.

the best would be a kind of "intelligent" algorithm, that automatically manages to switch between regular and irregular textures, and decodes both differently. but this would be hard to achieve i guess.

Iniciado por Lassus

Wait a minute and I will compile a new dcraw with it.

thanks a lot for your effort. i will play with it during weekend, when i have finally a bit more time.

Iniciado por Lassus

I have included a batch encoder for processing a huge amount of files with one single click. It is not mine but from Speek website.

that's funny, it is a utitily for encoding music, but can also be used for dcraw

ps. you also mentioned fujicoly. any idea what happened to him? have you seen his results? he never ever responded again to my emails but i was really expecting a lot from the previews he posted.
_______________________________________________
_______________________________________________
a quick test, i think i still like RGE most, still haven't tried the latest DCB though.
with this G1-example RGE shows least artefacts and has only slightly lower detail rendition than RPC or WPG.
HPHD from gabor seems to be somewhere between RPC and WPG regarding artefacts. sometimes even RPC looks better than HPHD.



what is your favorite algorithm? you said that you use the LX3, and from my experience with LX3 images they have a very similar "look" to the G1 with the difference that they are slightly more noisy, about 1.5 - 2 stops. but otherwise they would be hard to distinguish one from each other.

haven't played with high-iso files yet. will have a look later and try the new JDDFD.

Oluv, I use RGE or RPC depending on the image. When I feel lazy (so most of the time) I also use a B/W algorithm that outputs an useable image without further post-processing.

I'm in Paris right now and I don't know if I will read the forum everyday. When I come back on wednesday I will answer your post in detail.

wow, paris! how nice

i played with some other of my raw files and did another interesting comparison. there are 3 points of interest in this crop.
- the roof in the upper half. only RPC and HPHD is able to decode it without false-color moiree.
- the umbrella to the right. in both RPC and HPHD it shows artefacts, not sure how you would call them, but this is typical for red colors and HPHD. it seems as if RPC does the same thing with reds.
- the fine diagonal structure to the bottom. only RPC manages to renders it, the other algorithms soften it too much.


i mean these are extreme examples. in most cases these differences wouldn't be even noticeable.
but what bothers me are the artefacts, that nearly all algorithms produce with "normal" structures like the following, any idea why this is happening? this is the edge bottom of the image, could it be that the algorithms get confused because of CAs, only DCB renders it without problems:


here is the original RAW-file if you want to have a look at it:
http://dl.getdropbox.com/u/893528/P1000498.RW2

finally here one full image converted with RGE. i am quite satisfied with it as i think it is looking quite sharp and natural, what do you think? (click for full-size):

Oluv, yes, Paris is nice, but it's about the tenth time I'm here this year... I'm a bit tired!

The fullres image you have posted is fully useable. It seems RGE has done a good job.

I've been thinking about the algorithm you are looking for and I have several ideas that could work. Let me try them on wednesday.

CAs are not a problem for RGE and RPC. If you take a look in detail RGE fails when interpolation direction is more or less 45º. I can add diagonal interpolation, but finding the optimal values will take me some time.

The problem with RPC is much more complex. I cannot solve that artifacts without changing the whole interpolation method. Simply it does not fit that kind of images. Have you tried it with noisy images or pictures where texture is important?

What are FDD_mod (-q 96) results with the branches of the last pictures?

interestingly FFD-Mod really does a better job on the branches:


so far i haven't tried it yet. but i played a bit with it now and it is slightly less detailed than RGE for example. it also has some problems with faint nearly horizontal lines, RGE resolves them better.

RPC would be indeed my favorite algorithm if detail extraction and texture was my main concern, i like how it renders fine distant foliage that are beyond the resolving frequency of the sensor. here an example (strongly sharpened) that shows how nice RPC looks with very fine texture, RGE starts to look blocky and pattern-like:


but the problem is that as soon as there are lots of straight lines, RPC starts to produce artefacts.

a combination of different algorithms or an "intelligent" algorithm would be best, that is able to distinguish between real edges and simple texture, but i have no idea if something like this is possible at all .

if i had the time to devolp an image for achieving the perfect look, i would probably convert it with different algorithms and then compose the best parts from each of them together...

I just will say that Emil and Paul have recently done great improvements in their interpolation algorithm and I think we will see some results soon.

BR,

manuel, any idea when we will see some results from emil and paul?
so far there is not a single raw-converter that is really able to handle G1-raw files well. i mean if one wants mushy blurred images, he could also use silkypix, but i think a new algorithm included into a new perfect raw which also has adjustable green equilibration would be a big hit.

Oluv, it took me two minutes to create FDD_mod from an old FDD version so do not expect serious results from it. It was just for showing that adding diagonal gradients can avoid zipper artifacts along diagonals.

It shouldn't be difficult to merge RPC for texture and RGE for edges. I will try it this weekend.

Jazek has released a new version of DCB. It's much better now but it continues to be soft. Gradient work is impressive (Manuel, try the Pentax file with it). A mix between his gradients and my interpolation method would be nice, I think.

I suppose the idea is to add Emil and Paul interpolation to perfectRAW, so you should be able to use it with green channel equilibratiton.

From tomorrow I will connect more often.

Best regards.

DCB is not perfect either. have a look at these crops:

at a particular angle DCB fails to decode edges, you can also see it well in the last crop with the window-arc.

funnily all these examples look much better with RGE for example. although you claimed before that 45° gradients are a problem for RGE. it is not always that RGE produces stairsteps with 45° angles. it seems to depend on the colors, on the position in the image and maybe something else. no idea...

i played a bit with the latest DCB, but i think that meanwhile i prefer RGE, because it renders a better texture while still not perfect.

but i am very curious to see what you guys will come up with.

slightly off-topic: may i ask how you did this famous lighthouse-example from the kodak-cd? is this a raw-file from some particular camera? how do you compare "original" to "converted" then, i mean what is "original"?
or is it some tiff, that you put through a virtual bayer-process and demosaic it afterwards?

The lighthouse image is a Kodak-CD image. For testing interpolation algorithms it is first "mosaiced" and later "demosaiced" by the interpolation algorithm, so you can compare the original image with de mosaiced/demosaiced one.

Of course, the mosaiced process simulates what a bayer sensor does.

The Kodak-CD images are not perfect (they are compressed and oversharpened for my taste) but they are a classic in the literature.

The lighthouse image is important becuase it shows how good is the interpolation algorithm reconstructing nyquist textures.

BR,

Iniciado por oluv

DCB is not perfect either. have a look at these crops:

at a particular angle DCB fails to decode edges, you can also see it well in the last crop with the window-arc.

Those were the faults I did not like from DCB. Too ugly for my taste!

BR,

here is another comparison that shows the difference well. RGE looks fine on the left side of the arc, but creates stairsteps on the right side. DCB is the other way round, it is smooth on the right, but doesn't manage to render the arc on the left side.

why does the left side look fine with RGE, but the right side not? is it the contrast of the edge?

Iniciado por oluv

DCB is not perfect either. have a look at these crops:

at a particular angle DCB fails to decode edges, you can also see it well in the last crop with the window-arc.

I don't know if Jacek reads this forum, but I guess the problem on those diagonals is the use of bilinear interpolation for estimating the green pixels at positions (row-1,col-1), (row-1,col+1), (row+1,col-1) and (row+1,col+1). A simply weighted estimation will solve the problem.

Iniciado por oluv

why does the left side look fine with RGE, but the right side not?

It a curious behaviour. I hope to improve that by adding diagonal interpolation (I'm doing some preliminary tests). I will try to have the finished version this weekend.

Best regards.

i already talked to jacek about the diagonal-problem. he said it is a limitation of his demosaicing method. as you mentioned correctly DCB is based on bilinear interpolation.
maybe you could suggest your idea to him. my mathematical knowledge is too low to give him advices.

of course i am still interested in seeing your progress with RGE