Habitual
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.Iniciado por Guillermo Luijk
Enganchad@ a los foros
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.
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):
Animado:
Y otra zona ampliada, donde se ve mucho mejor lo que hace el algoritmo:
Un saludo:
Última edición por ManuelLlorens; 12/03/2009 a las 21:52
Enganchad@ a los foros
He mejorado mucho el algoritmo de ayer. Descansar un tiempo aclara las ideas.
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:
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):
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:
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.
Un saludo:
Última edición por ManuelLlorens; 14/03/2009 a las 13:14
Lleva poco por aquí
Manuel, me quito el sombrero. Si ya me gustó tu primera versión, esta me ha dejado con la boca abierta. Eres un genio.
Enganchad@ a los foros
Manuel, me quito el sombrero. Si ya me gustó tu primera versión, esta me ha dejado con la boca abierta. Eres un genio.
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.
Un saludo:
Última edición por ManuelLlorens; 15/03/2009 a las 11:54
Vivo en los foros
Buenos días.
my 2 cents...Por si sirve de ayuda.
No se si conocéis la aproximación reducción de ruido utilizado en GREYCstoration, 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, 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".
____________________________________________
Enganchad@ a los foros
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í.
Un saludo:
Habitual
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.
Un saludo.
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.
Última edición por Lassus; 15/03/2009 a las 14:04
Enganchad@ a los foros
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
Si te animas y tienes tiempo (francamente no sé de dónde lo sacas
Ya lo había visto, gracias. Creo que la única manera de que no pase es ser moderador
Bueno y ahora a corregir "una palá de exámenes" que tengo pendientes.
Un saludo:
Última edición por ManuelLlorens; 15/03/2009 a las 15:53
RAW RAW la botella de RAW
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!
"En ocasiones veo halos."
http://www.guillermoluijk.com para suscribirte haz clic aquí
Último contenido: PARA QUÉ SIRVE EL RANGO DINÁMICO?
Enganchad@ a los foros
Vuelves a ser un WANless.
Un saludo:
Habitual
Manuel, creo que me he liado con los hilos.Sigo la discusión por aquí.
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.
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: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
La mejora en el canal azul es más evidente:
Seguiré en ello. Un saludo.
Última edición por Lassus; 18/03/2009 a las 22:48
Enganchad@ a los foros
¿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 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):
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".
- 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).
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 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 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.
Posibilidades futuras
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.
Un saludo:
Última edición por ManuelLlorens; 19/03/2009 a las 11:57
Enganchad@ a los foros
Esto es lo que Jaques Desmis me cuenta de la conversión RGB -> YIQ -> RGB (traducido a capón con Google):
Cuando tenga un rato probaré cuánto se pierde con una conversión de este tipo en double.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.
Atentamente
Un saludo:
Última edición por ManuelLlorens; 19/03/2009 a las 21:59
Enganchad@ a los foros
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.):
Y quitando ruido de crominancia con Noise Ninja:
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):
Y el resultado que obtuve en su día con DxO, para comparar:
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:
Sorprendentemente, ACR+Noiseware deja mejor las líneas horizontales de las letras Pure Brewed que DxO. Por supuesto perfectRAW las borda
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?
Un saludo:
Última edición por ManuelLlorens; 21/04/2009 a las 16:34
Habitual
Manuel, perdona la desaparición, por Galicia hemos tenido puente.
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.
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
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.
¿No sería éste más interesante? Si te animas...
Un saludo.
Última edición por Lassus; 24/03/2009 a las 19:26
Enganchad@ a los foros
Lassus, ¿sigues ahí?Manuel, perdona la desaparición, por Galicia hemos tenido puente.
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):
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.
- 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).
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
Un saludo:
Última edición por ManuelLlorens; 21/04/2009 a las 16:33
Habitual
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
Galería en:
http://hgonzag.deviantart.com
Enganchad@ a los foros
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.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
Un saludo:
Habitual
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é, 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
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.
Enganchad@ a los foros
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.
Mis últimos resultados son estos:
Imagen completa de las botellas original.
Imagen completa de las botellas filtrada.
Y un recorte:
Un saludo:
Habitual
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.
Enganchad@ a los foros
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.. 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
Un saludo:
Última edición por ManuelLlorens; 13/12/2009 a las 21:35
Habitual
Si puedes, vuelve a subir la original. El enlace está roto.Mis últimos resultados son estos:
Imagen completa de las botellas original.
Imagen completa de las botellas filtrada.
Enganchad@ a los foros
Gracias por el aviso, pero debe haber sido algo temporal, a mí sí me funciona.
Un saludo:
Enganchad@ a los foros
I have moved posts in English in this thread to another one: Noise reduction in perfectRAW. Please keep this thread in Spanish.
Thanks.
He movido los mensajes en inglés de este hilo a otro: Noise reduction in perfectRAW. Por favor, mantened este hilo en español.
Gracias.
Un saludo:
Última edición por ManuelLlorens; 15/12/2009 a las 16:14
Habitual
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
Última edición por adla; 16/12/2009 a las 13:14
Enganchad@ a los foros
A ver, suficiente será, pero tendrás que armarte de paciencia
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.
Un saludo:
Permisos de publicación
LinkBack URL
About LinkBacks
Citar
Marcadores