Source: https://www.ojodigital.com/foro/archive/index.php/t-222840.html?s=a886b375594994c6e305646daa2a9557
Timestamp: 2019-11-21 06:21:10+00:00

Document:
Tratamiento del ruido en perfectRAW [Archivo] - OJODIGITAL
OJODIGITAL > OjoDigital > Antiguos apartados de OjoDigital > Proyectos OjoDigital > perfectRAW/perfectBLEND > Tratamiento del ruido en perfectRAW
Ver la versión completa : Tratamiento del ruido en perfectRAW
22/09/2008, 00:10
Utilizando una imagen RAW de la Canon 400D a ISO 1600 (http://raw.fotosite.pl/index-Canon_400D_EF50_1.8_PaPi.htm) que he bajado de raw.fotosite.pl (http://raw.fotosite.pl), he querido hacer una pequeña comparativa sobre el tratamiento del ruido en perfectRAW.
Como tal vez me hayáis leido, creo que el motor RAW de la última versión de DxO Optics (http://www.dxo.com/intl/photo/dxo_optics_pro/exclusive_features/powerful_denoising) es hoy por hoy el motor RAW a batir, independientemente de otras características de la aplicación con las que no vamos a competir directamente. Especialmente, a partir de la versión 5.2 han introducido un tratamiento del ruido a ISOs altas realmente efectivo que, a diferencia de otros reveladores RAW, filtra el ruido antes de la interpolación.
En otro momento discutiré porqué hay que hacerlo así (y cualquier otro enfoque entiendo que es erróneo), ahora sólo quiero mostraros que el nuevo algoritmo de interpolación que estoy añadiendo a perfectRAW, llamado AFD, además de obtener más detalle, ser más rápido que AHD y no interpretar el ruido como laberintos, posibilita hacer un tratamiento del ruido óptimo (el algoritmo no es mío, ya daré las referencias cuando esté completamente implementado). Tengo aún que hacer muchas más pruebas pero creo que he encontrado un camino prometedor.
Aquí tenéis resultados (es conveniente descargar y ampliar para apreciar bien las diferencias). La primera imagen es de DxO sin ningún tratamiento. Es obvio que algo de tratamiento sí que hace porque es lo más neutro que es posible obtener con esta aplicación y todos los controles desactivados, además de no aplicar gestión de color y usar el WB de la cámara (me sorprende la falta de rango dinámico de su revelado, tanto PS como perfectRAW sacan mucha más información de las sombras).
La siguiente es la misma imagen una vez procesada por DxO con el filtrado de ruido en sus parámetros por defecto. Es una gozada ver cómo quita ruido pero deja un grano fino y muy fotográfico (en mi opinión) en comparación con la primera imagen.
A continuación viene perfectRAW con AHD sin filtrar ruido. El ruido es muy evidente, pero no es tan malo como podría esperarse comparándolo con la primera imagen de DxO. Si se amplía aparece la horrible interpretación que AHD hace del ruido en forma de laberintos (porque se empeña en ver texturas allí donde no las hay). Finalmente viene el resultado preliminar de perfectRAW con la nueva interpolación AFD. Es evidente (mejor aún al ampliar) que es mucho mejor que AHD en la interpretación del ruido pues lo ve como grano fino en vez de laberintos y tiene una resolución infinitamente mayor, lo que se nota especialmente en imágenes con ruido, porque AHD difumina el ruido y emborrona la imagen (lo mismo que casi todos los algoritmos restantes de interpolación, fijaos en la diferencia de resolución entre las dos primeras imágenes):
http://img87.imageshack.us/img87/9875/noisegl7.jpg
Finalmente, os dejo la capa de luminancia del nuevo algoritmo (antes de mezclarla con la crominancia para obtener la imagen final) para que veáis hasta qué punto es bueno el nuevo algoritmo separando el ruido de luminancia (que parece grano fino y es mucho más fácil de limpiar) del ruido de crominancia (que se muestra como puntos gordos de color y es más difícil de eliminar, aunque al tenerlo separado de la luminancia durante la interpolación abre la puerta a tratamientos muy avanzados, que apostaría que es justo lo que hace DxO):
http://img444.imageshack.us/img444/5736/test4outlxl0.jpg
Por otra parte, es evidente que el nuevo algoritmo puede ofrecer muy buenos resultados para la fotografía BN, al permitir el uso de ISOs altas con mucha más tranquilidad que con otros programas, sin sacrificar resolución y con un ruido fino.
Para ampliar un poco la comparativa aquí va la misma luminancia AFD de arriba una vez pasada por Noise Ninja (quitando solo un poco de ruido de luminancia) y la luminosidad tras revelar con PS quitando ruido de crominancia y un poco de luminancia y pasar a modo LAB.
AFD + Noise Ninja:
http://img295.imageshack.us/img295/7306/test4outl2nk1.jpg
ACR (quitando ruido), solo luminancia LAB:
http://img81.imageshack.us/img81/3320/test4outpsau4.jpg
0. El único ruido que captan las cámaras es totalmente puntual: afecta a un sólo captador y no muestra correlación con los captadores adyacentes (esto es algo que aún tengo que demostrar, pero lo haré, y que se aprecia muy bien analizando RAWs de ISOs altas con el estupendo Rawnalyze (http://www.cryptobola.com/PhotoBola/Rawnalyze.htm)).
1. Los algoritmos de interpolación son los responsables de extender ese ruido entre varios píxeles (se ve muy bien comparando el resultado de AHD frente a AFD en las imágenes de arriba, especialmente en los píxeles rojos) lo que tiene tres efectos directos:
1.1. Se pierde resolución en la luminancia.
1.2. Se crean artefactos en la luminancia al intentar el algoritmo ver lo que no hay (laberintos, por ejemplo).
1.3. Se crean manchas de color al extenderse el ruido a la crominancia. Estas manchas de color (color blotches) son una creación exclusiva de la interpolación, no están presentes en el RAW antes de interpolar (de lo que se deduce que antes que mejorar los algoritmos de filtrado de ruido los fabricantes de cámaras deberían mejorar el algoritmo de interpolación de sus cámaras, lo que daría unos JPEGs muy superiores a los de la competencia, aunque puede que para eso hagan falta procesadores más rápidos... también podrían incluir un "modo lento" y un "modo rápido").
2. Antes de pensar en cómo quitar el ruido, perfectRAW tiene que interpolar bien el ruido para no estropear la imagen y el nuevo algoritmo de interpolación AFD parece cumplir con lo que podríamos pedirle:
2.1. El algoritmo de interpolación no debe extender el ruido de luminancia, sino mantenerlo. De ese modo el ruido queda en el captador correspondiente, aparece como un grano fino mucho más aceptable, no se pierde resolución y es mucho más fácil de eliminar con los programas de filtrado de ruido actuales (a posteriori del revelado).
2.2. El algoritmo de interpolación debe interpolar la crominancia sin extender a ella el ruido presente en la luminancia. Dado que la crominancia se calcula restando a la imagen original la luminancia, hay que intercalar el filtrado de ruido en esa fase de la interpolación y no al principio ni al final de la misma. Es decir, en vez de filtrar ruido una vez mezclada la luminancia y la crominancia hay que filtrar antes de haberlos mezclado. Estoy casi seguro que calcular la crominancia a partir de una versión suavizada de la imagen original (pudiendo el usuario controlar ese suavizado) y dejar la luminancia con el ruido original producirá un resultado casi perfecto.
2.3. Respecto al ruido de luminancia restante el objetivo no debería ser eliminar el ruido del todo, desde mi punto de vista el objetivo debe ser dejar un ruido de aspecto agradable: sin manchas de color, sin perder resolución, con un grano fino, de intensidad relativamente baja y distribución uniforme. De ahí que el algoritmo de reducción de ruido que tengo pensado diseñar trabajará cada punto captado (que no cada píxel) de forma independiente buscando suavizar el ruido en relación con su entorno, no eliminarlo del todo, lo que daría lugar a texturas patinadas, y no trabajará con el espacio de frecuencias (wavelets) como hacen actualmente todos los algoritmos de eliminación de ruido (incluido dcraw), dado que si no hay correlación entre el ruido de unos captadores y los adyacentes no hay ninguna frecuencia espacial de ruido que filtrar, es un tema de ir captador a captador... bueno que me emparanollo, ya programaré algo a ver qué pinta tiene.
¡Ale!, a opinar.
22/09/2008, 01:10
Excelente! Esa aproximación (realizar la reducción de ruido sobre los datos crudos) fue la que me hizo plantearme programar algo yo mismo.
Quizá deberíamos hacer alguna foto nosotros a ISO alto y mantenerla fija como benchmark (la típica foto de estudio con diferentes objetos y colores y detalle muy fino), para ver nuestros avances.
23/09/2008, 21:58
Me temo que no salen bien las imágenes que subí en el primer post, debe ser cosa del servidor que las aloja. Mientras lo miro, aquí tenéis otra comparativa igual de simple. La idea es la misma, comprobar hasta qué punto el ruido es altamente dependiente del algoritmo de interpolación utilizado y, en concreto, que el ruido de media y baja frecuencia es un produzco exclusivo de la interpolación y no una característica de la cámara.
Esta vez la imagen es de una Nikon D3 a ISO 12800 y tiene mucho más ruido que la anterior (aunque para un ISO tan alto es una pasada, todo hay que decirlo).
De nuevo creo que perfectRAW con AFD ofrece el mejor resultado (mucha resolución, no extiende el ruido, no crea artefactos). He comparado con AHD y VNG-4 y de paso con ACR. A la izquierda sin ningún filtrado de ruido, a la derecha con NoiseNinja (autoprofile y valores por defecto, pero sin enfoque).
Para verlo mejor descargad la imagen y ampliar con escalado nearest neighbour:
http://img77.imageshack.us/img77/6546/noise2df1.jpg
No me digáis que si en la imagen de AFD+NN le suavizáramos los puntos negros y blancos el resultado no sería muy bueno.
Aunque no esté directamente relacionado con el tema del ruido, tenía la curiosidad de ver cómo interpreta AFD la falta de equilibrado entre los canales verdes de mi E-300. Ya sabemos que VNG-4 crea celdas 2x2, AHD y PPG crean los horrorosos laberintos y AFD crea... ¡cruces! (o eso me parecen a mí). En cualquier caso se quitan con el equilibrado de canales verdes, como es lógico.
http://img155.imageshack.us/img155/3894/92025052pq7.jpg (http://imageshack.us)
23/09/2008, 22:35
Me encantan los resultados. Son MUY buenos! Podrías explicar en qué se basa tu algoritmo y alguna referencia para que pueda leer sobre los demás?
23/09/2008, 23:14
Muchas gracias, tenía muchas esperanzas y la intuición de que AFD iba a poner perfectRAW a un nivel casi sin competencia (tampoco la tendría sin AFD), pero las pruebas que voy haciendo me van gustando, a ver si me pongo a programar y lo termino de implementar bien, porque ahora está solo a medias.
Lo que me gusta de implementar un nuevo algoritmo de interpolación es que no es un tratamiento de la imagen sino que, en la línea de la filosofía de perfectRAW, es una forma de exprimir al máximo la información que reside en el RAW, de sacar una imagen lo más fiel posible a la realidad. Por eso no quiero que el algoritmo de reducción de ruido filtre nada, sólo que identifique aquellos píxeles que son el resultado del ruido y los disimule un poco. Lo mismo te diría de otros algoritmos que están en diseño. El enfoque por ejemplo no se basará en que la imagen parezca más enfocada (o sea, lo contrario de lo que hace USM y todos sus descendientes), sino en que realmente lo esté, y no procesará ni filtrará la imagen sino que la interpretará píxel a píxel. Yo soy de la teoría de que los algoritmos de filtrado de ruido y de enfoque basados en wavelets que actualmente son el state of the art, no son aplicables a un revelador RAW porque el revelador debe obtener la imagen lo menos procesada posible, para pasarla a PS y retocar en ella lo que se quiera; esa es la filosofía de perfectRAW.
Por otro lado, el algoritmo de interpolación no es mío, aunque sí diseñe un par de ellos antes de llegar a AFD (con resultados bastante decepcionantes, pero que me sirvieron para convencerme de que no era posible desarrollar un algoritmo de interpolación con la máxima resolución utilizando cuatro colores en vez de tres, lo que me decidió a meter el equilibrado de canales verdes a nivel local, que creo que fue una buena idea).
Cuando liberemos la versión 1.0 de perfectRAW daré todas las referencias y en el manual se compararán los métodos de interpolación valorando sus pros y contras. Obviamente, no quiero llevarme méritos de nadie, pero de momento me gustaría que perfectRAW fuera el primer revelador en utilizar este algoritmo (además del equilibrado de canales verdes), me ha costado bastante investigación (y algún dinero) llegar a él.
Una cosa es que no vayamos a hacernos ricos con perfectRAW y otra que vayamos a enseñar a los señores de Adobe a hacer las cosas bien para que se forren aún más ellos, ¿no crees?
Otro tema diferente es que te dé a ti esa información, claro ;), mándame un mail y te cuento.
Como ya te he dicho, hay unas cuantas cosa que tenemos que discutir en privado todo el equipo de desarrollo (para el futuro hay que definir cosas como el nuevo algoritmo de filtrado de ruido que he medio descrito más arriba, el nuevo algoritmo de recuperación de altas luces, el nuevo algoritmo de enfoque...). A ver si cuando venga GUI podemos montar una sesión de chat todos juntos.
25/09/2008, 17:20
manuel tus resultados de ese nuevo algoritmo son realmente explendidos, esperaremos vuestros avances
29/09/2008, 00:13
Gracias, meiker10 ;). Ese 7-14 me pone los dientes largos :drool2:, casi tanto como el 12-60 :D.
30/09/2008, 04:39
Me gusta como deja el ruido el alg. AFD, no lo propaga como bien dices. Tal como se define el AFD, qué celdas circundantes participan en la interpolación de un canal desconocido? Y a qué se deben esos puntos blancos y negros tan curiosos?
Es un análisis muy bueno. Por cierto le comenté a Coffin lo del AFD, pero este tío en general no muestra mucho interés por las ideas que vengan de fuera de él mismo (no es vanidad, es más bien frikismo o no sabría definirlo). En cambio me contó al milímetro como hace su vino casero y nos dio una botella.
Vaya, pues si el dcraw nos da problemas y no sale bien lo de PerfectRAW siempre podremos dedicarnos a la fabricación de vino :lol: :meparto:
30/09/2008, 13:34
Los puntos blancos y negros están en la imagen original, si comparas la primera imagen del primer análisis (DxO sin procesar) con la misma imagen con AFD verás los mismos puntos.
En breves palabras. AFD utiliza 5x5 captadores alrededor de cada captador para interpolar. La virguería está en su obtención de la luminancia, que es casi perfecta. El algoritmo "simula" que los tres captadores fueran captadores de BN y obtiene una luminancia muy buena con definición de píxel por captador, por eso el ruido sale en BN y muy enfocado (lo que da ese aspecto de puntos blancos y negros. Esto combinado con el balance de blancos es lo que comentábamos que nos permitiría obtener un BN buenísimo, sin competencia con otras interpolaciones que cuando quieren pasar a BN ya han perdido definición). Luego calcula la crominancia por sustracción de la luminancia obtenida en el primer paso del filtrado BL de la imagen original para cada canal. Estoy casi seguro que se podría mejorar esa parte, especialmente para impedir que el ruido de crominancia se extendiera como "color blotches", pero no he tenido tiempo de hacer pruebas. Lo que sí está claro es que si la imagen no tiene ruido, interpolar la luminancia con definición y la crominancia más suave no es problema porque el ojo capta mejor las variaciones en luminancia, el problema viene con el "ruido de color", que en cualquier caso es MUY fácil de filtrar a posteriori, lo que pasa es que respecto al ruido estoy en la línea de "no filtrar si puedo evitar que se extienda".
Gracias, GUI. Viniendo de ti es todo un halago. :D:D:D:D, bueno, si Coffin no fuera un personaje dcraw no existiría. El caso es que la idea de meter AHD en dcraw creo que no fue suya, y la implementación de PPG tampoco, aunque puede que me equivoque. En cualquier caso, espero mantener dcraw.exe con todo lo que podamos mantener en C de modo que todo el mundo pueda disfrutar de AFD, le interese o no a Coffin.
Lo de que no le interese lo que venga de fuera, sinceramente a veces lo entiendo. Creo que es uno de los motivos por los que no quiero tener móvil, para poder mantenerme aislado del resto del mundo (y no me vale con apagarlo, al final siempre encuentras un motivo para mantenerlo encendido ;)). A veces se siente uno invadido por lo que viene de fuera y se hace como un tapón que impide que uno saque lo que lleva dentro. Es el mismo mecanismo por el que se dice que la televisión anula la imaginación de los niños, no creo que sea cierto siempre, pero sí en muchos casos.
30/09/2008, 14:03
Le daremos la lata de nuevo, pero creo que lo suyo es que sea con alguna buena prueba comparativa (AFD vs AHD por ejemplo) irrefutable.
Más curiosidades de este hombre: como era de esperar él trabaja en Linux, tiene un teclado partido en dos con la disposición de teclas optimizada para taquigrafiar en inglés aunque también domina el QWERTY claro. Su mujer es rusa y con ella habla en esperanto (es la primera vez que oía hablar en ese idoma). Vive de los donativos a su web, casi todos de empresas.
Hablando de política y sociedad, criticó el outsourcing de bebés voluntario que hacemos en Europa con los inmigrantes (dejamos de tener hijos para que los tengan ellos por nosotros) y pronosticó una nueva guerra mexicano-americana, como la que ya hubiera, y que ganarán de nuevo los yankees. Lo de la guerra me pareció ciencia ficción, pero tras visitar NY y ver la masa social hispanohablante que hay allí dejé de verlo tan imposible.
Me hacía gracia que el tío cuando estuvo en España se fijó mucho en las señales de tráfico y criticó que no usemos línea amarilla a la izquierda para saber si una calle es de dirección única o no; yo le critiqué que allí los semáforos para coches estén al otro lado de la calle (como pasa aquí solo con los semáforos para peatones), lo que es un poco desconcertante para nosotros, y dijo que así no había que partirse el cuello mirando hacia arriba. Vamos que tenía respuesta pa to.
01/10/2008, 00:01
Otra forma de entender AFD:
Estaréis de acuerdo conmigo en que si no hubiera un filtro bayer delante del sensor, la cámara registraría en BN sin necesidad de interpolar, ¿verdad? Por eso AFD es el único algoritmo de interpolación lógico. Primero crea esa imagen (la luminancia) que ha registrado el sensor prescindiendo de la matriz bayer. Obviamente es BN, pero con la máxima resolución posible. A continuación estima el color a partir de los datos teniendo en cuenta la matriz de bayer. ¿A que es teoricamente perfecto? Es perfecto para perfectRAW.
01/10/2008, 00:44
Pues sí, suena bastante lógico.
La única pega que se me ocurre es que los filtros de color de cada pixel no "comerán" la misma intensidad de luz, por lo que el efecto sobre la luminacia en cada canal no será el mismo.
¿Compensa eso de alguna manera el algoritmo?
04/10/2008, 09:06
Claro, la luminancia se calcula en dos pasadas, en la primera no se compensa como dices tú, y en la segunda se ajusta teniendo en cuenta ese tema.
11/10/2008, 20:05
Una muestra que estuvimos comparando en mi casa Manuel y yo. Se trata de comparar el ruido que produce el algoritmo habitual de DCRAW, AHD, con el que está implementando Manuel, AFD.
Así como AHD es muy bueno cuando la imagen no es ruidosa, cuando hay píxels ruidosos ese ruido se propaga identificándose como tramos rectos. En AFD esto no pasa, los píxeles ruidosos aparentemente quedan aislados (ver puntitos negros y blancos), con lo que es más fácil identificarlos y corregirlos.
Las imágenes están en BN porque AFD funciona calculando primero al luminancia y luego añadiéndole la croma:
http://img369.imageshack.us/img369/5319/compcj1.jpg
La cosa promete, en recortes al 100% el ruido de AFD alcanza una textura mucho menos notoria y más agradable que la de AHD, más similar a grano que a ruido digital.
No he podido incluir la comparación anterior con ACR porque mi ACR no abre los RAW de la 50D así que he procesado otro RAW de manera neutra con ACR y con AFD:
http://img205.imageshack.us/img205/3656/comp2hj1.jpg
Pareciera que la salida de ACR sea como una versión con cierto desenfoque de la producida por AFD. Queda pantente que AFD es un algoritmo muy orientado al píxel, esto tiene como desventaja que no reconoce formas tan bien como otros, pero en casos de ruido éste queda más contenido en los píxeles ruidosos.
Felicidades Manuel y ánimo con el paso a color.
05/12/2008, 16:56
He estado jugando todo lo posible con DxO Optics y luego en PS he tratado de igualar el color de ambas imágenes para que fueran más comparables. He filtrado un poco el ruido de luminancia con Noiseware de la imagen de perfectRAW (AFD) para intentar igualar el grano de ambas imágenes y he quitado los píxeles sueltos (stray pixels) mediante un plugin específico para PS (Power Retouché). Este es el resultado:
http://img53.imageshack.us/img53/5387/afdvsdxohh9.gif
Otro resultado utilizando AFD adaptive noise attenuation + VCD interpolation en perfectRAW 0.65. Antes y después de aumentar contraste y saturación en PS para ver qué tal aguanta el ruido el postprocesado:
http://img114.imageshack.us/img114/931/vcdvsvcdqf3.gif
17/12/2008, 22:37
Aquí tenéis otra comparativa esta vez entre perfectRAW 0.65, DxO Optics 5.3 y CaptureNX 2.0.
El RAW es cortesía de solsticio, tomado con su Nikon D200 a ISO 1600. Salvando las diferencias de enfoque, color y contraste las imágenes son bastante comparables. He escogido los trozos que me parecen más significativos.
http://img394.imageshack.us/img394/1953/comp1st3.gif
http://img136.imageshack.us/img136/656/comp2hr0.gif
17/12/2008, 23:01
Se me habia olvidado comentarte que es con Nx2.0
17/12/2008, 23:06
Ya lo he cambiado, gracias. ¿Qué te parecen los resultados?
17/12/2008, 23:27
No se, me marea el cambio de una versión a la otra, a todas les encuentro un algo mejor que la otra. Comprendo que esto es como no decir nada, si me tuviera que decantar me parece que la más completa en detalle de perfilado de letras es DxO pero tiene algo más ruido que NX. Sin ánimo de molestar creo que PerfectRaw anda por detrás. Sin embargo la primera versión que colgaste de PerfectRaw me permitio arreglar alguna foto quemada que con el NX me era imposible.
El NX tiene además unos problemas tremendos con los balances de blancos nearUniWb u UniWB (1,1,1) ya que se cuelga y te saca del programa. Cuando te acepta una foto con ese 1balance y le pones el que te gusta no te permite hacer compensación de exposición.
Yo no os entiendo mucho de lo que comentais pero si la interface finalmente resulta cómoda y atractiva creo que lo utilizaré con frecuencia ya que opino que nos resolverá situaciones que el Nx noalcanza todavía.
De todas formas mi opinión negativa no debeis considerarla mucho que mi vista no es precisamente de lince y ya va para muy cansada.
18/12/2008, 12:26
Sobre el perfilado de las letras de DxO ten en cuenta que la imagen de PR no tiene ningún enfoque (al contrario que Capture NX que ha creado incluso algunos halos en las letras). Sobre el ruido, el objetivo no es quitarlo, sino dejarlo agradable, con aspecto "orgánico", más parecido al de fotografía analógica.
Si te fijas bien, en la primera imagen CaptureNX ha eliminado todo el ruido, pero también toda la textura (fíjate en la madera de arriba). El enfoque de PR es darte una imagen un grano fino y "trabajable" luego con tu programa favorito. Si luego tú quieres quitar todo el ruido pues lo haces, pero PR no te habrá eliminado nada que fuera importante para la imagen.
Entre PR y DxO lo cierto es que en esta imagen la diferencia es mínima y hay cosas que las hace uno mejor que otro y viceversa. Teniendo en cuenta que DxO Optics es el mejor revelador comercial para imágenes de ISOs altas, creo que nuestro resultado es muy bueno. En cualquier caso creo que podremos incorporar más tarde o más temprano mejoras aún mayores a PR en esta línea.
De todos modos estos GIF animados engañan bastante a la vista... los volveré a subir en JPEG cuando tenga un rato.
18/12/2008, 14:10
Yo como tú me dedico a la enseñanza y aunque está muy bien eso de que el alumno aprenda a buscar y a solucionar los problemas reivindico la función docente de enseñar conceptos y destriparlos para que el alumno puede diferenciar entre lo superfluo y lo importante. Ahora que me comentas cosas comprendo más y mejor lo que pretendeis. Hay que enseñar a comtemplar un cuadro en todas sus facetas y explicar los peros que a lo mejor no son tales. Muchas gracias por la explicación de los resultados; efectivamente ruido y textura me estaban "engañando" y me fijaba en lo fácil de ver.
Si necesitais más pruebas, en otras condiciones y creeis que os puedo ayudar, me lo comentais y de mil amores. Un saludo
¿Dónde enseñas? ;) Por lo que leo creo que estaríamos de acuerdo en muchas cosas si habláramos de enseñanza.
18/12/2008, 19:03
Te he enviado un privado. Hasta luego
20/12/2008, 16:14
Trasteando ayer con VCD decidí separar el refinamiento de píxeles que hace al final para probarlos con otras interpolaciones. Lo puse como opción -R dejando elegir cuántas pasadas quiere hacer el usuario. Pongo aquí unos ejemplos porque me parece impactante.
El primero es una comparación de interpolación bilinear sin hacer refinamiento y haciendo cuatro pasadas:
http://img56.imageshack.us/img56/4910/16693501mx9.gif
El tiempo de procesamiento es aceptable si no se eligen unos niveles muy altos, desde luego mucho menos que la función de mediana sensible a bordes y con mejor resultado. Cada pasada de refinamiento supone 2.5 segundos en mi patata de ordenador, a los que habría que sumar el tiempo que lleva calcular rgb_minmax() -8.2 segundos en mi caso-, que es independiente de hacer una o diez pasadas.
Perfeccionando hoy un poco el método hice una versión capada de VCD (más rápida, sin hacer uso de las varianzas), permití definir desde la línea de comando el tamaño de celda para rgb_minmax() y subí el filtro de mediana hasta ponerlo entre la interpolación y el refinamiento de píxeles. La idea es filtrar el ruido de color con pasos de mediana y recuperar el detalle aplicando el refinamiento, al que previamente se le puede aplicar el adaptive noise attenuation de Manuel para terminar de rizar el rizo.
Éste es el resultado (los parámetros están exagerados a propósito, bajándolos se tarda mucho menos y apenas hay diferencia de calidad), lo he hecho con afd para simplificar:
http://img135.imageshack.us/img135/7477/58949030yc7.gif
-Y es el umbral de adaptive noise attenuation
-m los pasos de mediana
-R los pasos de refinamiento
-G el tamaño en base al que se calcula rgb_minmax
El ruido de crominancia de alta frecuencia ha pasado a mejor vida y seguro que hay alguna manera de conseguirlo también con el de baja frecuencia. Quizá ampliando la mediana.
Por último con una pasada de Noise Ninja y un ajuste rápido de curvas para compararlo con una muestra que había subido Manuel:
http://img508.imageshack.us/img508/4459/26270435mh4.gif
El problema es que al hacer muchas pasadas se ralentiza el proceso y sólo es útil para casos muy concretos. Seguramente se pueda optimizar considerablemente y mejorar el filtro de mediana, pero aquí ya le paso el testigo a Manuel porque no yo tengo ni idea de cómo hacerlo.
21/12/2008, 00:36
Enhorabuena Lassus, tus resultados son espectaculares, pobre gente de DxO ;).
¿Puedes pasarme un TIFF de 16 bits de la imagen de las botellas revelada con AFD -Y1 -m2 -R6 -G21 sin más proceso?
Entiendo que con Noise Ninja sólo has filtrado la crominancia, ¿verdad?
¿Cuántos segundos tarda en generar esa imagen y cuánto en cada etapa?
¿Qué hace -R10 sobre una imagen sin ruido? ¿Enfoca los bordes?
¿Qué hace -R sobre los artefactos de AFD/VCD?
Sobre la mejor forma de aplicar un filtro mediana, el mejor algoritmo es éste (http://nomis80.org/ctmf.html)... si te animas...
Mi idea, como ya he contado en otro lado, es que el mejor modo de filtrar la crominancia de media/baja/muy baja frecuencia es aplicando un filtro gaussiano de radio grande sobre regiones conectadas de luminancia constante. Sobre cómo implementarlo le estoy dando vueltas y no me parece fácil. ¿Alguna idea?
21/12/2008, 12:03
Es cierto, no se me ocurrió compararlo con DxO, que es la referencia. Podría ser sería interesante.
En verdad son vuestros resultados (de Paul y tuyos). Yo he movido cuatro cosas de sitio, pero todas las funciones son prestadas. :silbando:
Te paso mejor el ejecutable para que lo reveles tú, que el TIFF ocupa casi 70 MB. Por cierto, ahora que lo veo, en el segundo GIF donde pongo -Y1 debería haber puesto -Y10.
Ésa era la intención, pero ahora mirando el gif dudo si habrá filtrado algo de crominancia. Si así fuera, la reducción parece mínima en cualquier caso.
Tarda lo suyo. No es funcional hacerlo para hacerlo con grandes lotes porque sería interminable. Con unos parámetros más modestos, digamos -m 1 -R 2 -G 7 tarda seis segundos más que el VCD de Paul Lee, para que te hagas una idea. Llegado un punto seguir subiendo los parámetros es redundante. En el ejemplo que puse -que como dije era exagerado- habrá tardado a ojímetro un par de minutos en mi ordenador, empleando la mitad del tiempo en las pasadas de mediana. El -G lo separé para hacer pruebas, pero no tengo muy claro que sea útil. Para VCD Paul usa el equivalente a -G 7, que parece el compromiso entre calidad y velocidad. Si pones -G 21 te saldrá una barba como la de tu avatar sin que el resultado cambie apenas.
Enfoca los bordes pero da lugar a artefactos en las diagonales complicadas y, especialmente mosqueante, amplifica las aberraciones cromáticas. Hasta -R2 o -R 3 hay que fijarse mucho para notarlo si se mira al 100% e incluso diría que la nitidez global mejora ligeramente, pero la verdad no creo que para ISOS bajos merezca la pena. Casi es mejor una máscara de enfoque y así te evitas los posibles artefactos y aberraciones.
-R los extiende algo, pero si antes se le pasa una mediana mejoran en global.
Le echaré un vistazo al código, pero por lo poco que he visto parece que para traducir a notación Coffin hace falta un diccionario avanzado... y yo todavía soy un novato absoluto en C. Vamos, que estoy escribiendo mensajitos en la consola y esas cosas.
Los tiempos que muestran en el gráfico son prometedores, y precisamente ahora la mediana es lo que más tarda.
Pues la verdad es que no. Lo único que se me ocurre es que mires el código de GREYCstoration o ImageMagick por si te sirven de inspiración.
22/12/2008, 02:20
He realizado una primera intentona de filtrado de ruido de crominancia que no extienda el color. Es todavía algo muy preliminar, poco más que una prueba de concepto.
El resultado es bastante lento y poco preciso en algunas zonas (que no salen en la imagen), sin embargo en otras es bastante bueno (las que sí salen en la imagen ;)). Queda aún mucho ruido de muy baja frecuencia, que creo que habrá que filtrar en el espacio de frecuencias porque si no será lentísimo.
Actualización: he añadido la comparación con DxO y ACR.
Las imágenes están interpoladas con AFD y he usado AFD adaptive noise attenuation al 60%. El filtrado de ruido de crominancia está hecho post interpolación en perfectRAW 0.65 (yo creo que en las imágenes de Lassus queda claro que también sabemos limitar el ruido de crominancia pre interpolación, combinando ambas cosas...). Si las hubiera obtenido con VCD y la técnica que ha descubierto Lassus (ver más arriba) habría partido de un menor ruido de crominancia, pero la gracia era tener una imagen en la que la reducción tuviera algo que hacer.
Tengo aún un par de ideas que probar para mejorarlo (una seguro que mejorará algunos de los artefactos que crea), ya os iré contando. Luego habrá que intentar que sea rápido.
http://img72.imageshack.us/img72/6826/sinttulo1xd9.jpg
He subido mucho la saturación para ver mejor el resultado (se nota mucho el filtrado, cómo el color no se extiende nada y cómo no se ha perdido nada de color - por ejemplo en las pequeñas letras rojas):
http://img212.imageshack.us/img212/6455/sinttulo2yl3.jpg
http://img57.imageshack.us/img57/3849/d700hsli25600ud4.jpghttp://img254.imageshack.us/img254/9034/d700hsli256002fa8.jpg
Comparar sólo el ruido de crominancia, no lo demás, que en este ejemplo no es comparable. Tampoco pretendo decir que estemos a la altura de los programas comparados (en este aspecto del filtrado de ruido de crominancia en lo demás estamos ya a años luz ;)), sólo ver si vamos por buen camino.
Creo que en estas imágenes se demuestra, y es algo muy importante, que reducir el ruido de crominancia es fundamental para mantener la resolución original de la imagen (fijaos que en las últimas dos imágenes de perfectRAW la de la derecha parece tener más resolución que la de la izquierda).
22/12/2008, 17:02
El resultado es muy muy notorio. Has metido ese RAW en ACR a ver qué tal? si algo me gusta de ACR es lo bien que elimina los manchurrones de color. No sé en qué dominio lo hará ni como, pero es rápido y funciona muy bien. Eso sí, me he dado cuenta últimamente que lo he usado un poco, que cuando se le ajusta la nitidez a cero, da imágenes un poco borrosas, como si poner nitidez a 0 implicara un ligero desenfoque en lugar de un enfoque 100% nulo.
Y Feliz Navidad jo jo joooo
(vaya avatar te has puesto nen xDD)
Tus deseos son órdenes. No había comparado antes con ACR porque me da el pobre un poco de pena últimamente :D:D:D, no quería hacer leña del árbol caído. Aunque llevas razón que quizás lo que mejor hace es filtrar la crominancia, no será rival para nosotros en el futuro. Otra cosa que ACR hace muy bien (yo creo que el que mejor) es quitar píxeles claramente ruidosos aislados (fíjate en el píxel negro de la letra r de Brewed).
Desde mi punto de vista, lo más triste de ACR es que, usando AHD como dcraw no consiga al menos igualar sus resultados. En cualquier caso no tengo ninguna duda de que Adobe tarde o temprano se pondrá las pilas con este tema.
Igualmente. Sobre el avatar, :silbando:, es que en vacaciones descanso del afeitado y en seguida me crece la barba :cunao:.
02/01/2009, 01:47
Después de este mesecito de aprendizaje ayer empecé a programas mis funciones desde cero. Pongo esto porque precisamente estoy trabajando en varios filtro para el tratamiento del ruido. En concreto son cuatro, que imagino terminaré fusionando en dos.
Uno de ellos es muy efectivo para el ruido de luminancia y otro para el de crominancia (es un desenfoque de color sensible a bordes con radio ajustable, muy lento todavía).
El caso es que no valen para lo contrario, el de luminancia se carga los colores y el de crominancia la nitidez. Ambos me dan dos arrays en la forma imgxxx[row*width+col][c], y me gustaría superponer imgchroma como si utilizara el filtro de fusión de color de Photoshop a imgluma, extrayendo previamente en CIE_L la luminancia si fuera necesario. ¿Es posible hacerlo?
Estaré fuera hasta el día 5, a ver cómo aguanto el mono de seguir adelante con ellos. Cuando estén un poco más avanzados pongo unas muestras.
04/01/2009, 15:35
Estoy deseando ver esos resultados ;).
Claro. Primero tenemos que convertir a modo LAB que viene a ser separar la luminancia de la crominancia, luego tratarlas por separado y volver a juntarlas al final. Tengo que preguntarle a Jacques Demis, que es nuestro experto en gestión de color, con qué algoritmo debemos hacerlo para que sea óptimo.
07/01/2009, 14:12
Aún queda bastante camino, son filtros muy sencillitos porque si los intento complicar más me termino perdiendo.
Había hecho cuatro:
-Uno que filtra en la matriz de bayer y que reduce algo la nitidez. De momento está abandonado.
-Otro que filtra la imagen antes de interpolar, que es efectivo a nivel de luminancia pero cambia la luminosidad de los rojos. :BangHead:
-Otro que elimina los píxeles aislados, de una sencillez ridícula pero bastante eficaz.
-El cuarto es el desenfoque sensible a bordes para eliminar el ruido de crominancia de media/baja frecuencia. Es lentísimo y patatero por el momento.
Si consigo algo decente pongo los resultados por aquí.
Investigaré esta tarde sobre el tema. El problema es que habría que interpolar dos veces, una para extraer la luminancia y otra para la crominancia ya que tal cual está ahora son incompatibles. Creo que lo que prentendo es un callejón sin salida.
Un último apunte: Manuel, cuanto más trabajo sobre ello, más me doy cuenta de lo buenos que son AFD respecto a otros algoritmos y tu filtro de ruido. Enhorabuena. :si:
08/01/2009, 20:39
Solamente agradecer y quedar maravillado por el trabajo que estais realizando.
08/01/2009, 20:54
10/01/2009, 13:09
Esta mañana he podido meterle un poco más de tiempo al asunto. Sigue estando muy verde, pero algo va saliendo:
http://img79.imageshack.us/img79/9676/afdnrkp3.gif
Que conste que este recorte no es en el que sale más favorecida, pero es ya el clásico que se utiliza en este foro.
Tras varias pruebas lo que mejor resultado dio es filtrar en la matriz de bayer. Es realmente el único punto en el que un revelador puede actuar con ventaja real respecto a los programas de reducción de ruido.
La luminancia está filtrada muy levemente antes de interpolar. Es una pasada muy rápida que no altera los colores ni un ápice. La crominancia se calcula después de interpolar (esto habría que cambiarlo) con una celda de 31x31 para cada píxel. Como podéis ver, la detección de bordes es absolutamente rudimentaria (parece Fractalius) y, esto lo digo yo, es un filtro muy lento. Posteriormente están unidos en Photoshop (no lo consigo con cielab en dcraw) con un pelín de saturación extra.
http://img66.imageshack.us/img66/6929/lumcromgx7.gif
¿Cuánto tarda DxO en revelar? Tal y como está no es funcional la parte del filtrado de color, era simplemente para dejar constancia de la idea por si a algún hacha de los que visitan este foro le apetece tomarla.
11/01/2009, 03:59
Lassus, tiene bastante buena pinta. Independientemente del ruido, la imagen que pones de la crominancia mola ;).
Extiende un poco el color porque hay ejes que no parece identificarlos, por ejemplo el verde encima de la 'S' de 'Samuel', pero es bastante efectivo.
11/01/2009, 20:06
A falta de un método más profesional, en ese filtro la detección de bordes es manual. Definí cuatro tipos (los dos planos y dos diagonales) por cuestiones de velocidad, pero tengo por ahí una versión con ocho mucho más efectiva. Sé que programar así es criminal, pero mi curiosidad es más grande que mis conocimientos de C. :cunao:
12/01/2009, 00:51
Lassus, voy a estar unos días fuera de línea por cuestión de trabajo. A la vuelta prometo explayarme explicando lo que tengo pensado (con importantes aportaciones de Egon) y cómo hacerlo para que puedas discutirlo y después implementarlo tú primero.
13/01/2009, 18:26
Ya explicarás con calma por aquí lo que tienes en mente, tengo mucho interés. No pongas deberes muy complicados, que aún estoy en la fase de C para novatos. De momento he dejado ese filtro en punto muerto y me he puesto a toquetear en la matriz de bayer, mucho más potente y productivo.
Por cierto, esos puntos negros que deja AFD (por ejemplo los de la imagen donde comparabas tu implementación y la de Paul) tienen dos causas: píxeles no captados en el propio sensor y otros creados en la función scale_color() al aplicar punto negro, saturación, WB, etcétera. Ambos son muy fácilmente detectables y promediables con su entorno. Este fin de semana echaré un vistazo detenido a ver en qué punto de la función se crean y si se puede cambiar algo para que dejen de aparecer.
14/01/2009, 20:24
este es mi primer comentario en este foro, aunque llevo tiempo siguiéndos. Seré breve por el momento. mi duda es la siguiente: ¿por qué no usais para el ruido un "bilateral filter" (en Photoshop "smart blur") o un NL-means, que es aún mejor? Con el estado actual de la investigación matemática al respecto, las soluciones ad-hoc suelen ser bastante subóptimas.
Subo un par de imágenes de ejemplo. Obviamente, se trata de un caso exageradamente extremo, con el fín de destacar el potencial de estas técnicas.
http://img232.imageshack.us/img232/2481/comparativanlmeanszy2.jpg (http://imageshack.us)
http://img232.imageshack.us/img232/comparativanlmeanszy2.jpg/1/w1487.png (http://g.imageshack.us/img232/comparativanlmeanszy2.jpg/1/)
Pues bienvenido, qwebeck, tus propuestas son asimismo bienvenidas. Te cuento mi opinión al respecto, que no es más que eso, una opinión.
Hasta donde yo entiendo el Smart Blur de PS es un selective gaussian filter y no un bilateral filter, pero puedo estar equivocado. Nuestra idea va por esa misma línea, por incorporar un filtro de ese tipo pero sólo para el ruido de crominancia que es el que nos molesta, la luminancia la queremos íntegra, con su ruido como grano fino monocromático de tipo fotográfico. Luego al que no le guste que la quite, para eso hay programas muy buenos (especialmente para el ruido de luminancia porque TODOS los que yo he utilizado extienden miserablemente el color, lo que llaman color smearing). El ruido de crominancia, por el contrario, no tiene aspecto fotográfico, al menos en el sentido más tradicional y analógico del concepto.
Por otro lado, dcraw ya incorpora un filtro de ruido basado en wavelets que, de nuevo hasta donde yo entiendo, es una versión más potente y más respetuosa con la textura que los filtros bilaterales. De hecho, dcraw tuvo un filtro de ese tipo hasta que Coffin decidió sustituirlo por el actual; por algo sería.
El filtrado mediante wavelets de Coffin es bueno para quitar ruido en imágenes poco ruidosas (limpiar el cielo por ejemplo al usar un ISO medio/bajo), etc. Pero para imágenes con ISOs altas, esos filtros ven el ruido como textura y no lo eliminan (sólo tienes que probar a usarlo en una imagen con ISO alta y verás que o no quita nada de nada o quita toda la textura) y suelen dejar ruido alrededor de los bordes. Además, como ya he dicho, en imágenes con ISOs altas queremos quitar los píxeles más ruidosos y el ruido de croma, pero dejar el ruido de luminancia. De ahí que hayamos incorporado una atenuación de ruido (que sirve para quitar hot pixels pero no filtra nada en espacio de frecuencias). Todo este procesado se realiza antes de interpolar, porque también entendemos que, si bien lo óptimo es que sea el propio algoritmo de interpolación el que tenga en cuenta el ruido, los actuales (aunque ya se va avanzando algo en esa línea) no lo hacen.
Respecto a NL-means: a mí personalmente me gusta mucho el resultado de este algoritmo (es lo que utiliza DxO Optics, como sabrás), pero es extremadamente lento y tiene cierta tendencia a "inventarse el resultado", lo que tiene toda la lógica del mundo teniendo en cuenta su origen como algoritmo generador de texturas. Es cierto que todos los algoritmos que quitan ruido se inventan algo (y los que interpolan), pero NL-means (lo mismo que NLD, non local demosaicing, la versión para interpolar del mismo algoritmo, también de Antoni Buades y también utilizada en DxO) tienen "demasiada imaginación", de hecho DxO Optics crea más ruido del que hay en la imagen, aunque luego lo quita muy eficazmente.
La familia de algoritmos non-local son lentos hasta el punto de que en DxO están implementado en la GPU porque de lo contrario son demasiado lentos, además estoy casi seguro de que su implementación en DxO está capada, vamos que no realiza todas las pasadas que serían óptimas (y desde luego no te deja especificarlo, lo que sería un plus para este programa).
Creo que podemos lograr resultados igual de eficaces y mucho más rápidos con nuestra propia aproximación basada en un selective gaussian blur + flood fill aplicado sólo a la crominancia. Pero ya veremos...
Respecto a tu ejemplo, completamente espectacular en muchos sentidos, lo cierto es que la imagen original apenas tiene textura de la misma frecuencia que el ruido, ¿no crees? Y donde la había se ha perdido totalmente. A nosotros nos gustaría más un resultado como este (con nosotros no sé muy bien a quién me refiero en realidad ;)):
http://img99.imageshack.us/img99/6391/comparativanlmeanszy2bfqj9.jpg
que, si bien sigue siendo notoriamente ruidoso, da un aspecto más natural y parece tener más detalle en las texturas (por todo aquello de la acutancia y el ruido). Lo malo de esta imagen (la he pasado por Noise Ninja quitando todo el ruido de crominancia y algo del de luminancia), y es en lo que estamos en este momento, es lo que se ve claramente en los dientes y el borde de la cara, que el color rojo ha invadido zonas que no le pertenecían. Parece sencillo (más en una imagen como esta) limitar con una detección de ejes ese problema (o con un gassiano selectivo, que viene a ser lo mismo).
14/01/2009, 21:57
Lassus no entiendo esto: cómo pueden "crearse" los puntos negros en scale_color()? el ajuste de punto negro por ejemplo, de acuerdo que llevará a negro valores ruidosos que quedaron por debajo del punto negro de la captura, pero estarán rodeados de otros píxeles o bien también negros o casi, porque lo que contendrán será ruido. Y los otros procesos que comentas tampoco veo que puedan crear negros. Yo creo que vienen del fotocaptor y ya está.
@quebeck:
Yo no puedo discutir sobre los mejores algoritmos para eliminación de ruido, pues la verdad es que conozco muy poco sobre el funcionamiento de estos algoritmos.
La imagen que pones da un resultado espectacular (como dice Manuel, en muchos sentidos ;) ).
Pero estoy de acuerdo con Manuel en que el aspecto es muy poco natural.
El aspecto de la imagen resultante es el de una imagen sintética, nada natural.
Más bien parecería un mural pintado con aerosol que una fotografía.
Además los bordes tienen un aspecto "con escalones" que restulta muy poco agradable.
La imagen que pone Manuel tiene mucho más ruido, evidentemente, pero se inventa menos cosas y resulta algo más natural.
Esto puede deberse a haber utilizado una imagen con un ruido excesivo. Habría que ver cómo trabaja ese algoritmo NL con imagenes un poco "más reales" con ruido alto, pero en donde en la imagen original el motivo fuera más reconocible, y hubiera algo de textura (en la que pones el ruido se ha comido las texturas casi por completo, por lo que la cara de la chica aparece "plana" en el resultado).
Bienvenido al foro y gracias por tus comentarios.
15/01/2009, 12:49
Da gusto verte por aquí, Fernando.
15/01/2009, 14:53
Manuel, aunque no participo mucho últimamente si que sigo todo lo que escribes.
No contesto mucho porque muchas veces a duras penas entiendo lo que decís, pues son cosas muy técnicas, y tengo poco que aportar.
Veo que las cosas las llevas a buen ritmo.
A ver si Egon puede acabar la versión con los wxWidgets y puedo ver el código, para poder empezar a hacer alguna cosilla (programar me refiero).
Aunque le tengo un poco de miedo a eso del C++, si te soy sincero :o
15/01/2009, 19:18
Muchas gracias, Manuel, por las aclaraciones. Si bien llevaba tiempo siguiendo el foro, es ahora cuando he entendido realmente la filosofía.
En cualquier caso, por el ejemplo que has subido, veo que no dejais intacta la luminancia (muestra tb un filtrado, ¿o es sólo apariencia?).
Respecto a que el ejemplo que subí carece de textura, y que allá donde la había, NL-means la ha eliminado y sustituido por cosas inventadas, os subo otro ejemplo. La pregunta es, ¿existe objetivamente en la imagen con ruido textura alguna que no se haya conservado en la imagen filtrada?
http://img80.imageshack.us/img80/7955/dibujoed0.jpg
Por último, aclarar que no es mi intención atacar perfectRAW, sólo que apenas dispongo de tiempo para darle a mis comentarios un tono más correcto. Disculpadme, por favor.
15/01/2009, 19:43
qwebeck, me he permitido editarte la entrada porque no se veía la imagen, espero que no te moleste. De imageshack, copia sólo la URL de la imagen y ponla a mano entre tags IMG.
Sí, he quitado un poco de ruido de luminancia usando Noise Ninja para simular el efecto de nuestra atenuación de ruido de luminancia (he actualizado la entrada de arriba para evitar confusiones). Como digo arriba, sí queremos filtrar un poco la luminancia y quitar los píxeles más ruidosos para dejar un ruido de luminancia monócromo y uniforme (agradable).
Es una buena pregunta. Si lo que buscamos es dejar la imagen limpia de todo aquello que muy probablemente no estaba en la imagen original, que sería un objetivo más científico, entonces efectivamente, quitaríamos todo el ruido posible con algún algoritmo tan potente como NL-means. Aunque ya puestos a usar algoritmos potentes y lentos, probablemente LPA-ICI (http://www.cs.tut.fi/~lasip/cfai/#dlmmse) da aún mejores resultados, aunque por supuesto se carga textura que, ojo, sí estaba en la imagen ruidosa (mira los carrillos de los loros):
http://www.cs.tut.fi/~lasip/cfai/gaussha/kodim23-gaussha.png
http://www.cs.tut.fi/~lasip/cfai/gausslpag1/kodim23-lag1.png
Pero nuestro objetivo es tener una imagen agradable que al mismo tiempo represente la realidad de un modo plausible, que tenga algo de grano no es un problema si el precio a pagar por no tenerlo es que la imagen no parezca real. Cuando el fotógrafo tira a ISOs altas asume que tendrá grano, lo que no quiere es una imagen llena de manchas de colores ni puntos blancos y negros que destaquen demasiado. Un grano fino (de 1 sólo pixel) y gris sí es aceptable.
Otro tema, no menos importante es que la imagen esté (a pesar del ruido) suficientemente saturada y aguante bien que se levanten las sombras. En eso un tratamiento correcto del ruido (y de la precisión en la interpolación) es fundamental. De ahí que en al algoritmo de atenuación de ruido lo llamara así, atenuación y no reducción, quería dejar claro que no pretende quitar el ruido, sino sólo hacerlo aceptable.
Por otro lado, al ojo la imagen parece que tiene más textura, más enfocada y con menos artefactos si se mantiene algo del ruido. Dado que el ojo necesita fijar detalles de la imagen, si le damos artefactos no camuflados tras el ruido los encontrará, mientras que, a través de un grano fino, el ojo (más bien el cerebro) reconstruye una imagen limpia (limpia en el sentido de natural, de "entendible" o interpretable) y, sin embargo, sin artefactos.
Mira esta página (http://www.cambridgeincolour.com/tutorials/sharpness.htm) de Cambridge in Colour: "[...]Image noise can be both very fine and have a very high acutance-- tricking the eye into thinking sharp detail is present."
Por cierto que en la frente de la segunda imagen que has puesto se nota mucho la invención de cosas a la que me refiero. Aparece una raya horizontal blanca y falta un mechón de pelo y sin embargo aparece más a la derecha otro que no estaba tan marcado en la imagen original.
No hay nada que disculpar. Aquí cada uno puede dar la opinión que quiera. Pero no te preocupes porque tus comentarios no resultan ofensivos en absoluto y todo lo que nos haga pensar es bueno para el proyecto.
De todos modos el ruido RAW no es exactamente igual que el ruido de color añadido a la imagen a posteriori.
15/01/2009, 20:03
Aunque se que tengo poco conociemiento os doy mi opinión.
Haciendo probaturas comparé hace poco DXO y PerfectRaw con un raw a 1600 iso de la nikon d90 creo recordar.
DXO se come la imagen, personalmente no me gusta nada.
No solo debemos ver lo que hace la interpolación en un recorte al 100%, creo que hay que verla tambien reducida, y ahí de un golpe de vista ví que se comía las texturas y se quedaba artificial.
En la imagen del loro idem.
Por cierto en el cine vemos un grano conseguido a propósito que da mayor sensación de realismo, que por cierto me gusta :)
15/01/2009, 20:12
De acuerdo contigo NaVaS, La reducción de ruido de DxO es muy potente y manejándola con cuidado es capaz de distinguir el ruido y la textura con sorprendente calidad. Pero es verdad que el resultado tiende a quedar poco realista, al menos para nuestro gusto.
Lo del cine es cierto. Los codecs de descompresión de div-x también suelen tener un ajuste para añadir ruido y camuflar los artefactos creados en el proceso de compresión/descompresión. Y lo cierto es que sin pasarse, añadir un poco de ruido mejora el aspecto de la imagen (de vídeo me refiero), especialmente en los degradados suaves en los que sin algo de ruido puede aparecer posterización. En fotografía con ISOs altas no vamos a añadir ruido a posta, pero tampoco conviene quitarlo del todo.
18/01/2009, 00:02
Bueno, claro, no se crean de la nada. Simplemente me refería a que al aplicar el punto negro y dar predominancia a unos canales sobre otros con el balance de blancos algunos píxeles se disparan, y es algo que podría controlarse desde la propia función.
12/03/2009, 21:32
Animado por los avances de Lassus, e impaciente por ver sus nuevos resultados, he implementado un nuevo algoritmo de atenuación de ruido para ISOs altas que tenía en mente desde hace un tiempo (en la línea que te comenté por mail, Guillermo). Creo que aún tiene mucho que mejorar (en parte se aprovechará de lo que Lassus mejore, porque ahora depende en parte de AFD. Esa es la razón por la que crea algunos píxeles más altos o más bajos que la imagen original) y dará los mejores resultados cuando lo combinemos con la reducción de ruido de crominancia (de momento la simulo con Noise Ninja).
El nuevo algoritmo funciona como una especie de preinterpolación de manera que actúa antes de interpolar y después de la interpolación mediante cualquier método de interpolación. Una de sus características es que reduce al máximo los "palitos" que producen PPG, VCD y, sobre todo AHD. Otra es que el ruido resultante es mucho más monocromático (una obsesión mía) y por último, está diseñado para ser extremadamente respetuoso con la textura de la imagen. La filosofía del algoritmo es ayudar al algoritmo de interpolación a no confundir textura con ruido.
Es bastante lento, pero no mucho más que la atenuación de ruido actual y, de hecho, puede combinarse con ella.
Mientras esperamos los resultados definitivos (resultados que por supuesto que incorporaremos en futuras versiones de perfectRAW) de Emil/Paul por un lado y Lassus por otro, nos sirve de entretenimiento :D.
El trozo de siempre (fijaos en la última que aplica el algoritmo al 90%. Está claro que no es una imagen muy presentable, pero si enfocáis esa imagen veréis que apenas se ha perdido textura y sí mucho ruido):
http://img211.imageshack.us/img211/9478/d700hsli25600nefa3.jpg
http://img211.imageshack.us/img211/5240/newh.gif
Y otra zona ampliada, donde se ve mucho mejor lo que hace el algoritmo:
http://img408.imageshack.us/img408/1544/newi.gif
14/03/2009, 03:01
He mejorado mucho el algoritmo de ayer. Descansar un tiempo aclara las ideas :D. Creo que el resultado es bastante bueno, aunque tal vez sea pasión de padre :rolleyes:.
El resultado me ha parecido tan bueno que me he arriesgado más de la cuenta y he aplicado el filtro con un valor muy alto, al 70% (que conste que yo no aplicaría tanto para una imagen real. A mí no me molesta el grano pero creo que el nuevo algoritmo es tan bueno quitando ruido sin apenas afectar a la textura ni a los ejes finos que se puede uno permitir valores más altos que antes).
El revelado está hecho con interpolación VCD (porque es la que mejor resultado da en las rallitas horizontales de las letras Pure Brewed) + 4 pasos de mediana + 4 pasos de EECI (pero sin ambos el resultado es muy similar). Juzgad por vosotros mismos si no quita una barbaridad de ruido manteniendo las texturas prácticamente intactas. Para mi gusto quedan unos puntitos blancos y negros de más, pero creo que podré controlarlos más adelante. La estructura de cuadraditos es culpa de EECI y el posterizado del GIF animado.
Después de perfectRAW he quitado el ruido de crominancia con Noise Ninja (que destroza un poco el color, pero ya lo haremos nosotros mejor) y he aumentado un poco la saturación, el contraste y el enfoque en PS CS4 para darle aspecto de imagen final. Teniendo en cuenta cómo es de ruidosa la imagen de partida...
Ya me diréis si os gusta:
VCD Original y luego procesada:
http://img6.imageshack.us/img6/9478/d700hsli25600nefa3.jpg
http://img12.imageshack.us/img12/5424/newq.gif
Además el nuevo algoritmo permite ver el ruido que perfectRAW ha quitado (fijaos en cómo el algoritmo se adapta a la luminosidad de la zona de manera que quita más ruido en las zonas oscuras y cómo no hay prácticamente correlación entre el ruido y la textura, se ve muy bien en el mosaico):
http://img12.imageshack.us/img12/2064/d700hsli25600nef3ryz.jpg
He ajustado aún más los parámetros del filtro y aquí tenéis otro ejemplo más conservador utilizando el filtro al 50% y AFD como interpolación. Me queda eliminar esos píxeles blancos y negros (es imposible enfocar la imagen sin quitarlos antes), que son pocos y aislados, así que será fácil quitarlos post-interpolación sin afectar a la imagen:
http://img12.imageshack.us/img12/8807/d700hsli25600neffiltere.jpg
Yo creo que el algoritmo aumenta la resolución del algoritmo de interpolación pues le permite concentrarse en la textura sin confundirse con el ruido.
15/03/2009, 02:40
Manuel, me quito el sombrero. Si ya me gustó tu primera versión, esta me ha dejado con la boca abierta. Eres un genio.
:o:rolleyes:, muchas gracias... ya sabes que una buena parte del mérito es tuya.
Lo que veo cada vez más claro (y creo que es en el fondo lo más importante del trabajo que estamos haciendo entre todos en este foro) es que hay muchísimo espacio para la mejora en este mundillo del tratamiento de la fotografía digital. A alguien que no meta la cabeza en todo esto le puede parecer que ACR ya da la mejor calidad que puede obtenerse y, sin embargo, partiendo de los mismos datos, pueden obtenerse resultados mucho mejores. Está claro que habrá muchos fotógrafos a los que la calidad a nivel de píxel de la imagen no les importe demasiado, y que tampoco les importe que la imagen haya sido procesada de un modo teóricamente correcto, siempre y cuando su aspecto sea bueno. Y, por supuesto, llevan razón. Si la imagen funciona y se vende y llegar a ella cuesta menos trabajo, lo perfecto es enemigo de lo bueno. Sin embargo, algún día todas estas mejoras se irán incorporando a los productos que ya usan para revelar y, sin que a ellos les suponga mayor esfuerzo, sus imágenes habrán mejorado sensiblemente.
Por otro lado, como ya he defendido en algún otro hilo, creo que las mejoras con los niveles de ruido en ISOs altas van más allá de lo puramente técnico. Desde mi punto de vista afectan a la capacidad del fotógrafo para expresarse. Seguro que muchos fotógrafos han renunciado a utilizar los ISOs más altos de sus cámaras porque les dan una calidad insuficiente. A mí por lo menos, como aficionado, me pasa (salvo en condiciones de luz perfectas, claro).
Creo que algún día se reconocerá que gracias al trabajo altruista, o al menos desinteresado, de unos pocos (Coffin, Guillermo, Paul, Emil, Jacques, Fernando y otros cuantos más) la fotografía digital llegó a ser lo que fue.
Por eso pienso también que es importante acabar describiendo bien nuestros algoritmos y dándoles difusión... incluso con el código fuente. Eso animará a otros muchos a mejorar aún más nuestros resultados.
Si nuestros productos no acabaran siendo competitivos en el mercado al menos espero forzar a las grandes empresas del sector a dedicar más esfuerzos a investigar para obtener la máxima calidad desde la imagen original y no a conformarse con sus resultados actuales.
my 2 cents...Por si sirve de ayuda.
No se si conocéis la aproximación reducción de ruido utilizado en GREYCstoration (http://cimg.sourceforge.net/greycstoration/index.shtml), pero lo mismo puede resultar de utilidad en este proyecto.
El algoritmo es meramente matemático, a base de ecuaciones diferenciales parciales, que queda super chuli :P, y se distribuye bajo licencia Open Source (sort of)
Y no solo sirve para reducción de ruido, fijaos en los ejemplos de "Image impainting".
15/03/2009, 14:38
Muchas gracias por la aportación, CarlosM. Lo cierto es que ya evaluamos en su día GREYCstoration, pero nuestra aproximación es completamente diferente, porque nuestro objetivo a la hora de eliminar el ruido también lo es.
Como algoritmo de inpainting es mucho más interesante para la recuperación de brillos especulares con los tres canales quemados, aunque hay mejores algoritmos de inpainting por ahí.
15/03/2009, 14:57
Manuel, a ver si subes la nueva reducción de ruido a perfectRAW. Tengo ganas de probarla.
Yo también he trabajado algo en el tema, aunque ahora la tengo un poco aparcada. Una de las cosas que me resulta curiosa es que, en mi opinión, no siempre es deseable eliminar el ruido de luminancia. Un ruido casi orgánico como el de AFD resulta agradable y visualmente añade nitidez a la toma. Al eliminarlo la imagen parece formada por manchurrones de color, así que prefiero usar umbrales muy bajitos. En las imágenes que has subido se ve el excelente trabajo de tu algoritmo, pero para mi gusto se usa un umbral muy alto (imagino que a propósito). Podría estar bien que filtrase con menor potencia los píxeles verdes en la matriz de bayer.
Sí me resulta mucho más molesto el ruido de crominancia. Tenemos que ponernos cuanto antes con ello... Se podría aplicar un filtro de mediana a los canales rojo y azul, pero en un radio de 7x7 o superior para incluir el ruido de baja frecuencia son leeentos.
Edito: he puesto un pantallazo de mis progresos en el hilo de WPG, pero con la fusión automática de posts no aparece como mensaje nuevo. Así que aprovecho para publicitarlo un poco por aquí y para preguntar si hay alguna manera de que no pase eso.
15/03/2009, 16:47
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 ;).
Sí claro, en esas imágenes filtro mucho a posta para que se vea que es capaz de quitar mucho ruido y poca textura. A mí personalmente también me gusta dejar un ruido más orgánico: grano fino, monocromático, sin manchurrones de color y sin píxeles calientes. Esa es mi definición de buen ruido.
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.
Bueno no me preocupa demasiado en el sentido de que sé que lo podremos filtrar muy bien. 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). Quiero también ver qué tal se comportan respecto a esos manchurrones tus algoritmos y el de Emil.
En cuanto Emil lo autorice colgaré ejemplos de su algoritmo, pero de momento no está suficientemente terminado.
Respecto al modo de quitar el ruido de crominancia, yo creo que hará falta un kernel de mínimo 25x25. Ese kernel tiene que ser adaptativo, eso está clarísimo, con lo que debería moverse entre no hacer nada, 3x3, 4x4..., empezando tal vez en 7x7 o algo así como dices tú o quizás empezando en 3x3. Hay varias alternativas para implementar eso pero está claro que rápido no va a resultar (aunque a Egon le encantará poder implementarlo en la GPU, sobre todo si utiliza convoluciones ;)). Un enfoque posible es un filtro de mediana híbrido con kernel adaptativo... será lentísimo pero muy eficaz. Otra aproximación es un filtro gaussiano de radio variable, y mi idea hasta ahora (hice una pruebecilla que puse por ahí arriba y me pareció que podía resultar) es un filtro gaussiano mezclado con detección de bordes y flood fill. Lo que es muy importante es que no se cargue el color en las esquinas. Prueba Noiseware, Noise Ninja o Neat Image en las imagen de las botellas y verás cómo dejan las esquinas de los cuadrados de color de la carta de colores. Todos (si subes las bajas frecuencias a tope y activas en NN y en NI el filtrado de frecuencias muy bajas, pues sino dejan aún manchas de color) se comen el color de las esquinas. Eso y que los colores se extiendan son las dos cosas que hay que evitas a toda costa. Luego, lograr un color uniforme es tan fácil como aplicar una gaussiana grande.
Si te animas y tienes tiempo (francamente no sé de dónde lo sacas :D) podrías probar esto (http://www.math.cuhk.edu.hk/~rchan/paper/impulse/impulse.pdf), que tiene muy buena pinta pero adaptándolo para trabajar sólo con la crominancia y radios muy grandes.
Ya lo había visto, gracias. Creo que la única manera de que no pase es ser moderador :P.
Bueno y ahora a corregir "una palá de exámenes" que tengo pendientes.
15/03/2009, 17:21
Pffff vuelvo a estar con modem y me es imposible ver los ejemplos de ruido, es insufrible. Cuando vuelva por Madrid le echo un ojo a todos los avances.
Salu2 ánimos!
16/03/2009, 09:52
Vuelves a ser un WANless :cunao::cunao::cunao:.
18/03/2009, 23:46
Manuel, creo que me he liado con los hilos. :silbando: Sigo la discusión por aquí.
¿Por qué no lo intentas mejor con histogramas? Es la única forma decentemente rápida de calcular medianas de kernels grandes.
En pricipio preguntaba por algún algoritmo que ordenase todos los valores, no que sólo calculase el central, pero eso ahora ya no me importa. :cunao:Miraré lo de la mediana de una vez por todas.
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).
Tengo una idea de interpolación de la crominancia para ISOs altos, pero no sé si funcionará. Precisamente después de escribirte lo de dos interpolaciones paralelas hice un filtro de prueba, que finalmente terminó siendo totalmente postinterpolación. Trabaja en el espacio de color YIQ, dejando inalterada la luminancia y aplicando un desenfoque sensible a bordes a la crominancia. Me interesan también dos cosas: que sea rápido y que no afecte a la saturación (NN y NW se cargan las letras rojas de la botella de la derecha). Pongo un resultado muy preliminar (aún tengo que ampliar el radio y mejorar la detección de bordes). Está hecho con FDD:
http://img16.imageshack.us/img16/4417/54293088.gif
La mejora en el canal azul es más evidente:
http://img208.imageshack.us/img208/6919/54199743.gif
Seguiré en ello. Un saludo.
19/03/2009, 10:56
:xxlmas: El resultado me gusta mucho, es justo lo que estamos buscando para la crominancia. ¿Los números 25 50 qué son? ¿Qué tamaño y tipo de kernel estás usando? ¿Gaussiano? ¿Es separable? ¿Usas un radio adaptativo o fijo? :D.
¿Puedes poner el resultado de filtrar la carta de colores? Me interesa sobre todo ver las esquinas de los rectángulos cuadrados y cómo detecta los bordes de las cajas. ¿Qué hace en una imagen sin ruido y con poco contraste?
¿La conversión RGB->YIQ->RGB no tiene pérdidas de ningún tipo? ¿La estás haciendo en double? Yo creo que la elección es acertada porque es una conversión matricial en vez de usar HSV o LAB... aunque me gustaría leer a Jacques al respecto.
Efectivamente que no afecte a la saturación y que no cambie el color es imprescindible. En ese sentido fallan todos los que yo he probado (Noise Ninja, Neat Image y Noiseware). DxO presume (http://www.dxo.com/intl/photo/dxo_optics_pro/raw_conversion/high_iso) precisamente de que respeta la saturación y el color en ISOs altas y en eso sí llevan razón. A mí me parece que nuestros resultados son mucho más naturales.
Desde luego lo que has hecho es exactamente lo que yo estaba pensado implementar. Creo que aún le falta una pizca de potencia (probablemente por tamaño o tipo de kernel, se ve más en las pared de fondo porque es muy lisa, pero así sería más de lo que puede esperarse lograr) y habrá que afinar la detección de bordes, especialmente en las zonas con poco contraste (en la carta de color se verá bien qué tal hace eso porque algunas cajas presentan muy poca diferencia de contraste con el fondo). Otra zona en la que fallan los programas de reducción de ruido de manera catastrófica (y que demuestra que su aproximación por frecuencias, wavelets casi todos) no es válida para imágenes con ISOs altas).
Como ya he dicho, tu resultado me gusta mucho.
Filosofía del tratamiento del ruido en perfectRAW 1.0
La aproximación actual de mi idea de cómo quitar ruido teniendo en cuenta los avances de Lassus es la siguiente (inicialmente iba a ser un algoritmo de interpolación propio específico para imágenes con ISOs altas, pero al final no veo motivo para no adaptar mi aproximación al resto de algoritmos de interpolación... mucho más en la línea de trabajo de perfectRAW de dar la máxima libertad al usuario. Por ejemplo, mi algoritmo aplicado al 0% elimina totalmente los palitos de AHD sin dejar la imagen suavizada):
Procesar la imagen antes de interpolar: quitar píxeles claramente ruidosos (mediante detección por desviación típica como ahora) y separar (con mucho cuidado y dejando antes que quitando si hay dudas) el ruido de fondo gaussiano de la señal (eso implica preinterpolar, de momento con AFD, pero ya veremos con qué al final). Ese procesado se hace atendiendo a la luminancia de cada zona.
Interpolar la señal con un buen algoritmo de interpolación, que saque las texturas finas perfectas y no se líe con el ruido que pueda quedar.
Quitar ruido de crominancia (post interpolación) con tu algoritmo del resultado de la interpolación. Yo creo que esto también debe ser un poco (pero menos) sensible a la luminancia de la zona en el sentido de filtrar menos en zonas claras y además de que un cambio de luminancia detenga el crecimiento del kernel (o al menos la comparación entre la luminancia 3x3 alrededor del píxel filtrado y la del píxel considerado afecte al cálculo, junto con la distancia entre ambos).
Volver a añadir el ruido de fondo gaussiano (pero reduciendo su intensidad a gusto del usuario) a la imagen final afectando por igual a los tres canales (para que sea monócromo).
Como ves, la idea fundamental detrás de mi algoritmo de reducción de ruido es que "el ruido gaussiano no debe ser interpolado, sino separado de la señal antes de interpolar y añadido después de la interpolación repartiéndolo entre los tres canales y aprovechando para reducirlo a gusto del usuario".
Creo que teóricamente es una idea perfecta porque el ruido gaussiano afecta por igual a los tres canales (Guillermo acaba de publicar un artículo (http://www.guillermoluijk.com/article/rawnoise/index.htm) a ese respecto que me sirvió para terminar de cocinar la idea en mi cabeza) y no forma parte de la señal, por lo que no es necesario ni conveniente interpolarlo. Hacerlo, por muy bueno que sea el algoritmo, siempre extiende el ruido y le da aspecto de manchas (color blotches) o de textura (palitos de AHD y demás). Sin embargo, si lo quitas del todo dejas las texturas demasiado patinadas y no puedes estar 100% seguro de que aquello que quitaste no fuera importante para la imagen así que hay que volver a añadirlo después sin interpolarlo y repartiéndolo bien entre los tres canales (porque su aspecto de ruido de color es culpa de la forma en la que las cámaras captan los canales por separado, pero en realidad el ruido gaussiano debe ser igual en los tres canales).
En la práctica, la separación del ruido (exclusivamente gaussiano) y la señal debe hacerse con sumo cuidado y nunca será perfecta. He estado probando varios algoritmos y al final el que estoy usando es rápido y preciso, no afecta a los bordes ni a las esquinas y no quita texturas finas, pero sí un montón de ruido (como se ve en el pantallazo con el ruido que subí).
Aún así quiero probar alguna técnica más y tengo que separar en el mapa de ruido que tengo calculado el gaussiano y los píxeles que se salen de valor, que es el motivo por el que al añadir el ruido de nuevo vuelvo va poner esos píxeles. Es sólo una cuestión de reordenar ciertas fases del algoritmo.
Para la parte de crominancia creo que tu algoritmo será perfecto y, efectivamente, debe ser postinterpolación, pero habiendo preprocesado la imagen antes de interpolar con algún método.
Resumiendo mis conclusiones sobre el ruido y la forma de tratarlo en perfectRAW en el futuro, para que me corrijáis si me equivoco (ver el fabuloso artículo de Emil Martinec (http://theory.uchicago.edu/~ejm/pix/20d/tests/noise/) al respecto):
El ruido de lectura (sensor read noise) se puede quitar con un black-frame o con la reducción de ruido de la propia cámara. Si no usamos estos métodos podemos quitar los píxeles más altos y más bajos con un algoritmo de comparación de cada píxel con el entorno mediante la desviación típica (esa idea también es de Emil). Eso es lo que hace mi algoritmo y entiendo que la parte de luminancia de Lassus. Lo que queda al quitar esos píxeles es ruido perfectamente gaussiano.
El ruido fotónico (photon shot noise) es puramente gaussiano (junto con el de lectura que quede restante). Si quitamos ese ruido antes de interpolar tendremos una señal bastante limpia. Por si acaso luego podemos devolver una parte de este ruido gaussiano para crear un grano fino (no se ha interpolado) y monócromo (porque se reparte por igual entre los tres canales). Eso asegura que las texturas no parezcan patinadas, mejora la acutancia y nos aseguramos de que no hemos quitado nada que fuera importante para la imagen.
El ruido de patrón (pattern noise) no se puede quitar con un algoritmo fijo. Una parte de él desaparecerá con el procesado anterior, pero quedarán las rayas como parte de la señal. Si es fijo de la cámara se quitará con un black-frame, en caso contrario habría que realizar un tratamiento como el descrito por Emil en su artículo. Quizás se pueda incorporar una función similar a pefectRAW en el futuro dentro de un módulo de calibración de la cámara (junto con el punto de saturación, el UniWB... podemos meter también píxeles muertos y esto, el ruido de patrón). Os recuerdo que dcraw ya incluye la funcionalidad de restar un black-frame de la imagen... perfectRAW también contempla esa funcionalidad en la versión 1.0.
El ruido termal (thermal noise) tiene aspecto de píxeles calientes y se quitará fácilmente con el tratamiento ya realizado para el ruido de lectura. Si la cámara presenta zonas calientes del sensor por proximidad a cables, etc. podría quizás calcularse también en el módulo de calibración de la cámara y sustraerse a la imagen (junto con el ruido de patrón... se deja la cámara calentarse bien, se disparan varias fotos, se promedian y el resultado se guarda y se resta de la imagen).
Falta de uniformidad de la respuesta de los sensores (pixel response non-uniformity) éste tiene difícil solución. Aunque los algoritmos ya diseñados pueden ayudar en zonas luminosas usando valores muy pequeños.
Error de digitalización (quantization error). Como dice Emil, de momento el ruido de sensor enmascara este problema completamente por lo que no hay que preocuparse.
Trayendo de nuevo a colación el artículo sobre el "grano digital" de Guillermo y su acertada conclusión de que el aspecto del grano depende fundamentalmente el algoritmo de interpolación y de la técnica de reducción de ruido aplicada, y que, como mucho con algoritmos tipo AFD (VCD, el de Emil, etc.) conseguirmos grano de 1 px de grosor pero no más grueso como ocurriría con la fotografía analógica y su grano grueso y contestando al respecto a una propuesta de Guillermo por mail sobre un algoritmo de interpolación que imite el grano grueso de la fotografía analógica.
Se me ocurre que sería fácil que en la última fase del algoritmo de reducción de ruido que describo arriba, al volver a añadir el ruido gaussiano a la imagen, además de reducir su intensidad a gusto de usuario, se podría simular un grano gordo con bastante facilidad. Es un efecto puramente artístico y poco en la línea de perfectRAW, pero puede gustar a los que busquen un aspecto más analógico a sus imágenes en ISOs altas. El algoritmo sería fácil de implementar y no tendría que añadir un ruido nuevo, sino el propio de la imagen. Sería lo más parecido a imitar con un sensor digital el comportamiento de la película.
19/03/2009, 22:50
Esto es lo que Jaques Desmis me cuenta de la conversión RGB -> YIQ -> RGB (traducido a capón con Google):
Yo prefiero escribir este texto en Inglés, porque incluso en Inglés es complicado a no ser lo suficientemente claro.
La conversión rgb => XXX XXX y luego => rgb plantea varios problemas cuya importancia depende de lo que quieres hacer.
1) ¿La pérdida de la gama? es esencial para examinar lo que ocurre cuando la conversión (y, a continuación, volver) conduce a valores superiores a 65.535 y menos de 0. Por supuesto pensamos que la primera de las luces altas y bajas luces, pero estos dos puntos son sólo la cara visible del iceberg ...
2) pérdida de precisión de cálculo es necesario para examinar lo que ocurre con una conversión rgb ==> XXX + funcionalidad de trabajo (accentaution contraste, interpolación, etc.) XXX entonces ==> rgb. Una forma de ver si el proceso no hace el error es examinar el proceso con un trabajo no hace nada. En este caso, todos los valores RGB antes de la transformación y después de la transformación debe ser igual a cerca de 1 o 2 sobre los valores RGB (por ejemplo, 52344 y 52345 antes después). Esto es para todos los colores percibidos por un sensor es sensiblemnt WidegamutRGB o Prophoto. Por supuesto, esto lleva a las precauciones de cálculo (el doble de precisión, etc ...) que retrasa el proceso y clutters la memoria ... pero como decimos en francés, "no es una tortilla sin romper los huevos!" .
3) las pérdidas debidas a errores de la transferencia de la función f (t): la única función que no es la teoría del error de conversión rgb => Laboratorio. De hecho, fue hecho para esto ... La función f (t) para el Laboratorio es la visión humana y se traduce en DeltaE ... colores que traen los mismos DeltaE pueden ser idénticos (o que sean idénticas). En el caso de otras conversiones como YIQ, debemos asegurarnos de que la función de los trabajos (por interpolación), junto con la función de transferencia (en este caso un cálculo de una matriz triplete) no da lugar a diferencias ... que no es fácil de encontrar ...
3 Es que estas pérdidas que he marcado antes de proponer la conversión rgb => Laboratorio => rgb. He hecho esta comparación con las fotos de la meta 468 colores (que he desarrollado ...), pero cualquier otro foco con una gran gama puede ser el caso.
Y les pido disculpas por el mensaje en francés porque no puedo hacerlo en español o Inglés.
Cuando tenga un rato probaré cuánto se pierde con una conversión de este tipo en double.
20/03/2009, 01:47
Lassus, estoy pensando pasarte todo el código de mi reducción de ruido para que la termines, mezcles con la parte de crominancia y limpies y optimices el código, ¿qué te parece?
Creo que tienes toda la información necesaria (y siempre me puedes preguntar) y el código está bastante afinado. Un pantallazo de la última versión (anoche volví a retocar los parámetros, siempre buscando respetar el máximo detalle quitando a la vez mucho ruido) sobre interpolación VCD, con el filtro al 40% y ya corregidos los píxeles que se salían de madre. Tal como está ahora el algoritmo va bien con todas las imágenes de ISOs altos que he probado, pero tiene unos 8 parámetros que podría ajustar el usuario con los que lograr todo tipo de reducciones de ruido (bajar su intensidad sin quitarlo, quitar sólo puntos calientes, filtrar más o menos según la luminancia, etc.):
http://img4.imageshack.us/img4/9205/22730533.jpg
Y quitando ruido de crominancia con Noise Ninja:
http://img23.imageshack.us/img23/8807/d700hsli25600neffiltere.jpg
Para los que quieren una imagen lo más limpia posible después de haber disparado a ISOs astronómicos sin perder detalle he cogido la imagen anterior y he quitado ruido de luminancia de media, baja y muy baja frecuencia en Noiseware, dejando el ruido de alta frecuencia intacto y no tocando más la crominancia. Luego he aumentado contraste y exposición para darle un aspecto más definitivo.
A mí personalmente me parece que así quedan demasiado plásticas las texturas, pero como perfectRAW deja un ruido agradable no termina de quedar mal. En cualquier caso demuestra la potencia del algoritmo a la hora de quitar ruido y preservar detalle.
A los que no les guste nada el grano probablemente les habría gustado filtrar más las zonas luminosas de la imagen (como hacen DxO y ACR más abajo) para que desapareciera todo el grano en ellas (la falta de saturación y los colores extendidos son "culpa" de Noise Ninja, cuando esté listo el filtrado de ruido de crominancia de Lassus no pasará eso):
http://img11.imageshack.us/img11/5067/d700hsli25600neffiltereq.jpg
Y el resultado que obtuve en su día con DxO, para comparar:
http://img11.imageshack.us/img11/1479/dxo.jpg
Y con ACR (última versión con su propio filtrado de ruido intentando no quitar demasiado detalle) y después con Noiseware (quitando ruido de luminancia de media, baja y muy baja frecuencia, como arriba). Como ya sabéis si habéis trabajo alguna vez con AHD en imágenes ruidosas es imposible quitar los palitos sin quitar todo el detalle:
http://img11.imageshack.us/img11/8106/d700hsli25600filtered.jpg
Sorprendentemente, ACR+Noiseware deja mejor las líneas horizontales de las letras Pure Brewed que DxO. Por supuesto perfectRAW las borda :D.
El último contendiente que he probado es Raw Therapee 2.4 RC usando HPHD con su propia reducción de ruido y luego Noiseware para equilibrar las tornas. Está claro que RT necesita un detector de píxeles calientes. Sería muy fácil que Gabor incorporase uno. Por otro lado HPHD es igual de bueno, si no mejor, que AFD y VCD para imágenes con ISOs altos. Sería interesante implementarlo, tenemos todo lo necesario... ¿alguien se anima?
http://img11.imageshack.us/img11/1112/d700hsli25600filteredp.jpg
Manuel, perdona la desaparición, por Galicia hemos tenido puente. :D
Estupendo tu compendio sobre los tipos de ruido. Hay hasta en la sopa... Creo que has explicado a la perfección el enfoque a seguir en la reducción de ruido, es la forma de que las imágenes no pierdan naturalidad.
Pásame tu filtro, el primer pantallazo que has puesto es el punto de partida perfecto para aplicar el suavizado de crominancia. Tengo poquito tiempo para ponerme a hacer pruebas en él, y al mío no le vendría mal un cambio de arriba a abajo para ganar potencia. De momento busca desde el píxel 0 hacia el norte hasta tocar con un borde y coge el valor inmediatamente anterior, y repite la operación con el este, sur y oeste. Se puede establecer un radio límite para la búsqueda del borde. Una vez tenemos esos cuatro puntos hago un ULIM con (N+S)/2 y (E+O)/2. Chapucero, ¿verdad? Lo bueno es que la relación resultado/tiempo es mejor que con medianas o desenfoques, y no es plan de que el filtrado nos lleve demasiado tiempo. Quiza con la mediana con histogramas cambie la cosa, pero me da pereza ponerme con ello. :silbando:
Quién iba a decir que algún día los resultados en el nivel de ruido iban a ser mejores que los de DxO. En cuanto se libere la nueva interfaz perfectRAW va a ser la referencia absoluta (de calidad ya lo es), y no habrá hecho nada más que empezar. La mayoría de los reveladores gratuitos los lleva una única persona (bueno, aquí casi :P), y en los comerciales hay más ganas de vender que de mejorar. Yo sigo diciendo que los de Adobe os van a lanzar una OPA cuando la gente les apriete las tuercas...
A ver si esta noche me pongo y subo algún pantallazo de la carta de colores.
A mí me parece que lo de simular el grano analógico sí tiene cabida en perfectRAW. VCD por ejemplo deja un grano más fino que AFD, pero es que el de éste último no resulta molesto en absoluto. Al fin y al cabo de lo que se trata es de conseguir un resultado visualmente natural, yo creo que encaja.
En cuanto a HPHD, la verdad es que me divierte más hacer los míos propios que portar otros. De él sólo me interesa el concepto, no los resultados. Me gustaría tener ya el código para meterle mano e intentar arreglar sus horribles diagonales, pero no ponerme a escribirlo. :D Pásame la referencia de todos modos, por favor, que yo la tenía pero no la encuentro y ahora no la veo en google.
¿No sería éste (http://faculty.csie.ntust.edu.tw/%7Eklchung/paper/Demosaicing%20of%20color%20filter%20array%20captur ed%20images%20using%20gradient%20edge%20detection% 20masks%20and%20adaptive%20Heterogeneity-projection.pdf) más interesante? Si te animas...
21/04/2009, 17:23
Lassus, ¿sigues ahí?
El interfaz nuevo va viento en popa y creo que en breve veremos los resultados por aquí. Respecto al motor de compilación faltan al menos tres cosas para ponerlo a punto para la versión 1.0 y son casi todo cosas medio diseñadas/implementadas (a menos que me deje algo):
Meter el filtrado/atenuación de ruido completo. Lo último mío con tu filtrado de crominancia completo.
Meter tus métodos de interpolación como opciones y el PPG por defecto y meter el algoritmo de interpolación de Emil/Paul, que cada vez tiene mejor pinta (y que está siendo reescrito de nuevo con mejores resultados y más velocidad, de ahí el retraso).
Meter el equilibrado de canales verdes nuevo (está listo como se ve en el tema con oluv, pero me falta depurarlo).
Lo demás son casi todo cosas de la interfaz, salvo quizás el balance de blancos que vaya a medias entre interfaz y motor de revelado. A partir de ahí ya podría salir la 1.0 con la funcionalidad diseñada inicialmente. Luego para la 1.5 ó 2.0, habría muchos más cambios en el motor de revelado, separándonos de lo que es código Coffin hacia nuestro propio motor (y manteniendo la parte de carga de los RAWs de Coffin, como hacen todos), optimizando a tope (¿OpenMP/SIMD/GPU?), aunque probablemente dejemos el código original de Coffin como plugin opcional.
Personalmente llevo una racha de mucho curro y la verdad es que los pocos ratos libres que tengo delante del ordenador apenas me quedan ganas de tirar hacia adelante con el proyecto. Eso y que ahora el momento está centrado en el interfaz y ahí los magos son Egon y ariznaf, hacen que me esté tomando unas pequeñas vacaciones del proyecto. Pero estoy cogiendo fuerzas para el tirón final hacia la 1.0... y muchas más ideas que van surgiendo por el camino :D.
25/04/2009, 22:04
Para versiones posteriores se podría incluso ayudarse de las GPU's con CUDA y CTM...
Estoy ansioso de usar la 1.0 como mi único revelador y "filtrador" de ruido :)
26/04/2009, 11:39
Gracias. En principio Egon programará la GPU sin usar ninguna librería intermedia. La versión 0.70 beta que andamos probando ya calcula la gamma en la GPU en lugar de en la CPU como hace la 0.65 alfa.
29/04/2009, 20:37
Manuel, perdona el retraso, últimamente ando apurado de un sitio a otro y tengo poco tiempo para caer por aquí. Deja que rebusque esta noche entre los archivos para mandarte exactamente el filtro que había utilizado en el pantallazo y los algoritmos de interpolación, para que incluyas los que quieras. Los últimos en los que estoy trabajando cuando saco algo de tiempo aún no están afinados, ya subiré una versión para que se puedan probar (por cierto, consumen memoria de lo lindo, pero no hay alternativa).
La forma más eficiente de suavizar la crominancia es integrando el filtrado dentro de un algoritmo de demosaico que separe espacios de frecuencias, como AFD, pero entiendo que en perfectRAW, por cuestiones de filosofía y de la gestión de memoria por etapas, debería poder usarse por separado y con cualquier otro algoritmo, ¿no? Había hecho un test para Jacques, que finalmente no le envié :o, que demostraba que las pérdidas en YIQ eran despreciables después de cincuenta pasadas, y nosotros haríamos sólo una, así que ahí no hay problema. También se pueden usar las diferencias de colores y dejarnos de historias.
Cada vez se antoja más crítico el disponer de un cálculo rápido de medianas, pero no tengo tiempo para ponerme con ello. Lo óptimo sería evaluar los valores de los bordes en una ventana de radio creciente, y en función de ellos aplicar una mediana más o menos fuerte. Tengo el pdf de un filtrado de mediana en la que tarda lo mismo una de 300x300 que una de 3x3, si alguien se animase se podría avanzar mucho en este punto... Éste también valdría (de hecho sería mejor pues no creo que necesitemos ir más allá de 11x11 y para medianas de radio pequeño es ligeramente más rápido): Shell & Slate - Fast Median and Bilateral Filtering (http://www.shellandslate.com/fastmedian.html)
Estoy deseando que liberéis ya el nuevo perfectRAW. Aunque a estas alturas estoy tan acostumbrado a la línea de comando que no sé si se me hará demasiado raro volver a tener una interfaz con curvas y esas cosas. :cunao:
13/12/2009, 04:17
Los últimos avances sobre la reducción de ruido, con las contribuciones de Emil Martinec, Jacques Desmis y Lassus están en las últimas entradas de este hilo (http://www.ojodigital.com/foro/perfectraw-perfectblend/265272-amaze-el-nuevo-algoritmo-de-interpolacion.html).
Mis últimos resultados son estos:
Imagen completa de las botellas original (http://dl.dropbox.com/u/602348/00.nef_INITIAL.jpg).
Imagen completa de las botellas filtrada (http://dl.dropbox.com/u/602348/00.nef_ABSOLUTE_FINAL.jpg).
Y un recorte:
http://img138.imageshack.us/img138/4163/00nef3.jpg
Para todo el que dude de la calidad del filtrado de ruido de Manuel, que pruebe a revelar, no ya la imagen a 25600 ISO de la D700 en Imaging Resource, sino la de 12800 con ACR y las compare: los resultados son muy parecidos tratándose además de un ISO forzado creo que con -3 EV; en ISOs reales la ganancia sería de más de un paso. (w00t)
13/12/2009, 22:31
:o Gracias. Cuando lo juntemos todo va a ser la caña. Aunque es tan lento mi algoritmo, de momento, que hoy mismo me he comprado una placa/CPU/RAM nueva :D:D:D. Es que es un suplicio compilar, ejecutar, revisar y comparar... vuelve a compilar... así, si no consigo optimizar demasiado el código, al menos a mí me tardará menos ^_^. Por cierto, el i7 es absoltamente impresionate, se ha comprado mi padre un DELL, de esos para jugones, y trazar panoramas con el Autopano Pro que en mi máquina (un AMD 64 3200, con un sólo núcleo y sin ni siquiera Hyperthreading) tardan unos 5/8 minutos en el suyo tardan apenas 20 segundos!!! Creo que también tira de GPU, aunque no sé si la usa en el trazado. Es alucinante. Como poco, compilando con el compilador de Intel el código irá mucho más rápido con varios núcleos sin tener que hacer nada.
Lo cierto es que sí tengo alguna idea para optimizar mucho el algoritmo principal de mi código (si quieres detalles o el último código no dudes en pedírmelos por mail) a base de usar mucha más memoria, claro. Eso me obligará a reescribir todo el algoritmo para que se ejecute en tiles (ahora va a saco y en la imagen de la D700 llega a utilizar unos 500 megas). Como el motor de revelado que diseñamos Egon y yo para la 2.0 va a procesar siempre en float por tiles y utilizará algunas optimizaciones en la estructura de la imagen respecto a cómo la codifica Coffin, creo que voy a implementar parte del motor de revelado nuevo sobre el antiguo, en plan:
imagen en motor 1.0 -> imagen en motor 2.0 -> procesado de ruido -> imagen en motor 1.0.
Eso ralentizará un poco más el código pero probablemente lo recupere al ir luego el algoritmo más rápido. En el peor de los casos como ya es tan lento de por sí mi algoritmo de reducción creo que se notará poco :D. De paso me evito tener que escribir código específico para los bordes (de eso se encargará el motor 2.0 él solito) y también reescribir todo el algoritmo el día de mañana. Además, una vez adaptado al motor 2.0 será mucho más fácil y directo portarlo a SIMD/GPU a mano.
14/12/2009, 22:50
Imagen completa de las botellas original.
Imagen completa de las botellas filtrada.
Si puedes, vuelve a subir la original. El enlace está roto.
14/12/2009, 22:55
Gracias por el aviso, pero debe haber sido algo temporal, a mí sí me funciona.
15/12/2009, 17:07
I have moved posts in English in this thread to another one: Noise reduction in perfectRAW (http://www.ojodigital.com/foro/perfectraw-perfectblend/299306-noise-reduction-perfectraw.html). Please keep this thread in Spanish.
He movido los mensajes en inglés de este hilo a otro: Noise reduction in perfectRAW (http://www.ojodigital.com/foro/perfectraw-perfectblend/299306-noise-reduction-perfectraw.html). Por favor, mantened este hilo en español.
yo tambien tengo un un AMD 64 3200 con 1Gb ¿será suficiente para correr el programa con agilidad? Saludos
pd. el xp es el 32bits
27/12/2009, 22:53
A ver, suficiente será, pero tendrás que armarte de paciencia :D:D. De todos modos la memoria es bastante barata y con otro Gb este y otros programas irían mucho mejor, ¿no?
De todos modos mi algoritmo no está preparado para ir a producción, está en plena fase de desarrollo y espero que sea más utilizable cuando llegue a la versión final.

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución