Tema: Novedades

En este tema iremos poniendo las novedades de las que queramos informaros a la espera de que nuestra página esté 100% funcional.

De momento comparto con vosotros lo que nos mantiene ocupados estos días:

• _GUI_ y Egon han estado ocupados con el RAW Virtual que tan espectacular resultado ha dado y que ha puesto los cimientos de lo que será en breve la versión 1.0 de Zero Noise RAW, perfectBLEND o como quiera que lo llamemos llegado el momento.
• ariznaf sigue ocupado mejorando nuestra página web, instalando módulos y servicios (foros, foros para desarrolladores, SVN, etc.).
• Egon por su parte tiene casi lista la nueva demo del control OpenGL que es una auténtica pasada. Funcionará en cualquier gráfica con OpenGL 1.0. Esperamos que en breve podamos colgar una demo más completa que la anterior aquí.
• Estamos discutiendo (a eso se refiere _GUI_ en otra entrada) sobre la posibilidad de migrar de .NET a C++/wxWidgets como plataforma para el interfaz. La principal razón para migrar sería dar mejor soporte a la funcionalidad futura (plugins entre otras cosas), una mejor integración del código y el entorno de desarrollo (todo con C++, lo que permitirá la depuración cruzada que ahora no es posible entre C# y C y dificulta bastante encontrar y arreglar errores) y finalmente, aunque no es nuestra prioridad, mejorar la portabilidad (al menos hacerla más sencilla al no depender de Mono). Parece que la opción C++/wxWidgets nos va convenciendo, aunque aún no hemos decidido si saldrá así la versión 1.0 o saldrá como estaba en C#. Eso sí, si cambiamos de plataforma de desarrollo mantendríamos la filosofía de la aplicación intacta.
• Yo por mi parte he pasado el testigo a Egon y ariznaf del entorno gráfico para que lo junten con el OpenGL. Mientras seguiré trabajando en el código de revelado para arreglar bugs e incorporar alguna nueva funcionalidad (como la versión definitiva de la interpolación VCD de Paul Lee).
• Estamos diseñando nuestro logo y página web propias. De momento está todo aún muy verde (el diseño que podéis ver en byte d'light es provisional obviamente). El logo definitivo es éste (madre mía lo que nos ha costado dar con algo que nos gustara a todos , primero con el nombre y luego con el logo).
  
  
  
  
  Y en torno a él estamos diseñando la página en este momento. Cuando tengamos algo os avisaremos.

Gracias por todo vuestro trabajo! Si vale mi opinión, abandonar .NET, me parece que es condicionar todo el trabajo al capricho de una compañía que no destaca precisamente en pensar en los demás.

Iniciado por garmayen

Gracias por todo vuestro trabajo! Si vale mi opinión, abandonar .NET, me parece que es condicionar todo el trabajo al capricho de una compañía que no destaca precisamente en pensar en los demás.

¿Te refieres a Microsoft? ¿Quieres decir que te parece bien que abandonemos .NET o todo lo contrario?

Un saludo:

Gracias por el trabajo que estais realizando, seguro que en breve todos os lo agradeceremos.

Iniciado por ManuelLlorens

¿Te refieres a Microsoft? ¿Quieres decir que te parece bien que abandonemos .NET o todo lo contrario?

Un saludo:

Me parece bien que abandonéis a Microsoft (que dejéis .NET) . Puede que esté condicionado por mis experiencias pero es una empresa que no respeta estándares que no sean los suyo y te arriesgas a que la próxima versión de su software hagan borrón y cuenta nueva y vuelve a trabajar.

Te entiendo garmayen, aunque en el caso del .NET es altamente improbable que MS vaya a darse media vuelta. De algún modo viví la llegada de .NET en primera fila y era algo que todos deseábamos. Es verdad que en algunos aspectos resulta decepcionante, pero no deja de ser una oferta más que tiene sus ventajas sobre lo que había.

El problema con nuestro proyecto es que .NET está diseñado para el mundo empresarial, desarrollar rápido aunque renunciando a la eficiencia del código. Nosotros aspiramos a tener un producto muy optimizado (perfection is the limit!) y ahí .NET es un poco una piedra en el zapato, un tanto conceptualmente hablando, pero también en la práctica.

Un saludo:

Hola,
Muy buena labor estáis realizando
Un saludo!

Por cierto, ¿no seréis ninguno un experto en desarrollar templates para Drupal verdad? Porque eso que nos podríamos ahorrar nosotros. Creo que nos apañaremos solos.

Un saludo:

Me voy a tomar 15 días de vacaciones incluyendo desconexión total del proyecto y del ordenador. Además aprovecharé para reflexionar sobre el estado y el futuro del proyecto porque me está llevando demasiado tiempo tanto real como mental y no puedo mantener este ritmo, estoy agotado.

Un saludo:

Se entiende perfectamente. Como te descuides estas cosas te absorben más de la cuenta y después es difícil desintoxicarse.

Si se me permite un humilde consejo para tu vuelta, quizá se pueda (y se deba) bajar el ritmo y sacar las nuevas versiones más espaciadas en el tiempo y con sólo uno o dos nuevos añadidos por vez. Yo creo que pretender sacar de golpe la versión 0.65 con todo lo que se ha hablado tiene que resultar abrumador. Si lo piensas casi todas las actualizaciones de ACR y demás reveladores comerciales son para soportar nuevas cámaras, y son muy pocas las mejoras que se añaden a lo largo del año. Y ellos son un equipo grande y que cobra por ello, no cuatro gatos desienteresados...

Lo dicho, felices fiestas y nos vemos por aquí a la vuelta.

Sin perjuicio de lo anteriormente dicho (que estoy de vacaciones ), he liberado la versión 0.65 de perfectRAW para que trasteéis con ella.

Un saludo:

Hola,

Iniciado por ManuelLlorens

Sin perjuicio de lo anteriormente dicho (que estoy de vacaciones ), he liberado la versión 0.65 de perfectRAW para que trasteéis con ella.

Un saludo:

Hombreee eso si que es un buen regalito de papa noel, muchas gracias y un saludo voy a probarla

Bueno, no he llegado a los 15 días pero ha sido suficiente.

He actualizado de nuevo la versión 0.65.

Un saludo:

Soy de los que pongo pocos post en los foros, sobretodo por la falta de tiempo para ver foros pero quiero agradeceros a todos el enorme trabajo que estais haciendo y que depues terminaremos utilizando todos.

Gracias.

Gracias, buen hombre.

Un saludo:

Situación actual del proyecto:

• Tenemos la versión 0.65 (que voy actualizando semanalmente con pequeños cambios y el último código de Paul y de Coffin), con una estabilidad muy alta y muy rápida. Los últimos cambios (que aún no he subido) permiten abrir imágenes grandes en ordenadores con poca memoria.
• Egon dice que para mediados de febrero tendremos el interfaz OpenGL/C++/wxWidgets incorporado a esta versión. Os recuerdo que mucha funcionalidad del interfaz no se ha incorporado a la versión 0.65 por no tener que repetirla luego, pero que la versión OpenGL llevará vistas partidas, chivatos, histogramas completos, etc.
• Emil Martinec está terminando de afinar su propio algoritmo de interpolación, cuyos resultados son mucho mejores que todo lo visto hasta ahora en imágenes con y sin ruido. En breve empezaremos a portarlo a C tanto Paul Lee como yo. Dado que su implementación, la de Paul, estará terminada antes, será más rápida, consumirá menos memoria y tendrá un código más compacto y al estilo de Coffin... pues os podéis imaginar qué versión acabará implementada en perfectRAW .
• Además tenemos la implementación de Paul de AFD (que acaba de mejorar con cálculos en coma flotante, será algo más lenta pero numéricamente exacta, cosa especialmente importante en las sombras) como alternativa rápida y la interpolación mixta AHD/VCD de Paul.
• Prácticamente el 100% de la funcionalidad de dcraw ya está incorporada a perfectRAW y lo poco que queda es más cuestión de añadir controles que de picar código.
• Estamos en disposición de actualizar nuestro código a las pocas horas de haberlo hecho Coffin, y eso es algo de lo que pocos reveladores pueden presumir (y uno de nuestros objetivos fundamentales).
• Jacques Desmis ha realizado una estupenda comparativa (enlace a la traducción de Google Translate) en la que queda claro que dcraw con los cambios que hemos introducido para perfectRAW y los que él mismo ha realizado, es imbatible en cuanto a la calidad de la imagen resultante. La única cosa en la que es superado por algún revelador es en la calidad de las diagonales (que con los actuales algoritmos de interpolación de dcraw/perfectRAW salen demasiado dentadas, pero es algo en lo que está trabajando Emil para su propio algoritmo).

Por todo ello, creo que queda claro que el proyecto está alcanzando un alto grado de madurez, y que en un par de meses (D.M. ) tendremos algo con aspecto de RC, o eso espero y deseo fervientemente.

Por otro lado, como también sabéis, Guillermo y Egon han avanzado mucho en la obtención de un raw, en formato DNG, virtual de cero ruido, que es el primer paso para Zero Noise RAW, perfectBLEND o como quiera que finalmente lo llamemos. Dado que reutilizaremos buena parte del código de perfectRAW para ese proyecto, en realidad queda poco más que mezclarlo todo para tener también ese proyecto muy avanzado.

Desde el punto de vista técnico sólo nos quedan tres escollos.

De paso he hecho un poco de limpieza en el foro cerrando los temas obsoletos y moviéndolos a un subforo específico que amablemente ha creado Mauro para nosotros.

Un saludo a todos:

Como se "ha caído" el tema de la versión 0.65 os cuento alguna novedad aquí. Ayer probé perfectRAW 0.65 sobre un Windows 7 x64 y funciona al 100%.

Además Egon compiló un dcraw con LCMS en Linux de 64 bits y también funciona al 100%.

Por tanto, parece que la versión de 64 bits desde la 1.0 no es una utopía.

Un saludo:

Con personas como vosotros, pocas cosas se quedan en utopía.
Suerte.

Iniciado por Náyade

Con personas como vosotros, pocas cosas se quedan en utopía.
Suerte.

Pues, ¡muchas gracias! Espero que estés en lo cierto .

Por cierto, ¿soy el único al que no le funciona este tema?

Un saludo:

Iniciado por ManuelLlorens

Pues, ¡muchas gracias! Espero que estés en lo cierto .

Por cierto, ¿soy el único al que no le funciona este tema?

Un saludo:

Has excedido el límite de mensajes en un mismo hilo.
Ya en serio, a mí me funciona y por lo que se ve a Guillermo también.
Saludos.

Pues no te digo yo que no... el caso es que se ha arreglado limitando el número de mensajes por página.

Un saludo:

Era una broma pero...
Aunque sea un off-topic, animo con lo vuestro que esta muy interesante. PerfectRAW ha pasado a ser el revelador de las fotos de mi Panasonic LX3. No hay nada mejor como punto de partida. Ahora mismo y en la fase en la que estáis solo le echo en falta el poder elegir donde guardo los Tiff resultantes. Por pedir que no quede. Quizás para la versión 0.66.
Lo dicho, animo que esto ya tiene una pinta estupenda y promete todavía más.
Saludos.

Iniciado por VALGAR

PerfectRAW ha pasado a ser el revelador de las fotos de mi Panasonic LX3.

Tu cámara en JPEG es un poco lladre



haces bien en tirar en RAW.

Seguimos en activo, aunque pueda no parecerlo. Egon tiene casi acabado el código OpenGL y estamos preparándonos para pegar la DLL de dcraw con su código. Luego habrá que ir incorporando al nuevo interfaz todos los controles, aunque eso será bastante rápido.

En cuanto podamos liberaremos una versión de prueba con el nuevo interfaz que revele, aunque sea con los parámetros de revelado por defecto.

Un saludo:

Se me pasó referenciaros esta comparativa entre reveladores RAW, primera en la que aparece nuestro perfectRAW.

Ya hablan bien de él y eso que aún no hemos implementado el nuevo interfaz, ni el algoritmo de Emil y ni la reducción de ruido completa.

Un saludo:

Para los que quieren ir viendo algo de la versión 0.70 alfa que tendremos lista en breve, un pantallazo (de Windows 32 bits):


Podéis ver los controles nativos desacoplables y la ventana principal con el DNG virtual revelado.

Os recuerdo que corre de manera nativa en Windows de 32 y 64 bits, Linux de 32 y 64 bits y MacOS, que está desarrollada en C++ y que utiliza OpenGL para la visualización de la imagen (además de algunos cálculos en la GPU si la gráfica lo soporta).

Para que os hagáis una idea, en mi netbook LG 110 (un Intel Atom a 1.6 GHz, con gráfica Intel 945M integrada y 1 Gb de RAM) sobre XP de 32 bits va suave y rápido. Cuando le pongamos todos los controles de revelado tendremos una versión bastante parecida a la versión final.

Un saludo:

Enlaces:

• dcraw win32 SSE + rawzor
• dcraw win32 SSE2 + rawzor

He compilado una versión de dcraw con soporte para archivos comprimidos con RAWZOR para que podáis probarlo. Necesita una DLL que está incluida en el ZIP (la versión para Windows 32 bits). Si os interesa usarlo sin tener que ir copiando la DLL a dónde copiéis el ejecutable, solo tenéis que copiar la DLL en %windows%\system32 (típicamente C:\windows\system32).

Si el archivo es un .rwz (se comprueba la extensión y el formato interno del archivo RAWZOR) se descomprimirá (en un archivo temporal en la misma carpeta que se elimina automáticamente al terminar dcraw) y se revelará normalmente sin tener que especificar ninguna opción especial. Si es cualquier otro tipo de raw se revelará como siempre.

El proceso total de revelado se retarda algo así como un par de segundos (en mi máquina), pero el ahorro de espacio es muy considerable (quizás en el futuro pueda idear el modo de descomprimirlo en memoria en vez de en un archivo temporal sin cambiar mucho código de Coffin para ganar algo de tiempo, pero de momento no lo veo posible). He comprobado que el resultado de revelar un .rwz es byte a byte idéntico a haber revelado el raw original y lo cierto es que los raws de mi Olympus-510 se reducen un 50% (otros ejemplos en la tabla adjunta).

Ya me diréis lo que os parece y si merece la pena incorporar estos cambios a perfectRAW (como ha hecho Gabor a su RawTherapee).

Desgraciadamente el soporte para MacOS aún no está listo, aunque en la página dicen que llegará pronto.
____________________________________________

Actualización (10 de mayo de 2009):

Se me ha ocurrido una manera de no usar un archivo intermedio para la descompresión RAWZOR sin tener que modificar el código de Coffin. La idea sería sobreescribir (con unos #define al inicio del archivo) las funciones fread, fseek, ftell y fgetc que usa el código de Coffin por unas nuevas que leyeran sobre un buffer de memoria. De esa manera el archivo raw siempre estaría cargado en memoria con independencia de que fuera normal o comprimido. Ventajas: que iría más rápido siempre; inconvenientes: más uso de memoria (tanta como el archivo descomprimido como mucho).

Si se quiere hacer mejor aún (y más fácil de leer el código) se pueden también redefinir fopen y fclose y dejar que todo el proceso sea transparente para la aplicación. En ese caso fopen si la extensión del archivo es rwz comprobaría si es verdaderamente un archivo rawzor y lo descomprimiría en memoria devolviendo el puntero a esa zona de memoria y fclose liberaría la memoria.

¿Qué os parece? ¿Creéis que merece la pena? En su día hice algo similar con las funciones de gestión de memoria para comprobar que no hubiera memory leaks y funcionó muy bien.

Para que todo esto merezca la pena hace falta que mi navegador de imágenes favorito, ACDSee Pro, soporte directamente archivos comprimidos con rawzor, pero dado que ACDSee utiliza dcraw para cargar los raws, si lo dejo limpito el código y lo subo a Internet, lo mismo los señores de ACDSee lo aprovechan .

La otra opción, que acabará por caer tarde o temprano, es hacer nuestro propio navegador/catalogador de imágenes. Ahora que tenemos, gracias a Egon, una infraestructura multiplaforma nativa en cada SO y súper rápida, podríamos en el futuro crear algo novedoso. Aunque para ello tendríamos que definir un producto nuevo con características no existentes en el mercado, no se trata de reinventar la rueda.

Un saludo:

Mientras Egon y Fernando siguen avanzando en el nuevo interfaz, yo he comenzado a desarrollar el motor de revelado que irá con la versión siguiente de perfectRAW.

Es un proyecto ambicioso que me va a llevar bastante tiempo, por lo que no hay fechas de salida.

De momento he comenzado a revisar todo el código de Coffin y a desarrollar una nueva DLL desde cero. Creo que ahora tengo las ideas mucho más claras que cuando comenzamos y se nota.

Para empezar he implementado el caché de archivos que comento en el post anterior. Lo he hecho añadiendo literalmente una sola línea al código original de Coffin (hace tiempo que tenía ganas de implementar mis cambios de ese modo, como propuso en su día Fernando).

El nuevo caché de disco consume memoria solo durante la carga del RAW, por lo que no afectará al consumo de memoria en los RAWs grandes. Los tiempos de revelado rápido (las pruebas las he hecho con dcraw -T -4 -h porque de ese modo casi todo el tiempo del revelado corresponde a la carga del raw) se han reducido apreciablemente, en mis RAWs de la Olympus E-510 y E-300, pasan de 2,0 a 0,6 y 0,7 segundos respectivamente. Es un tiempo impresionante para logar un preview al 50%, ¿no creéis?

Además ahora el soporte para Rawzor no modifica el código de Coffin (sólo esa línea añadida que he comentado antes), no necesita un archivo temporal y es algo más rápido.

Os dejo una tabla con los tiempos en segundos para varios RAWs con la versión original de Coffin, la nueva con el caché, la última que compilé con soporte Rawzor (la del post de arriba) y la nueva con caché y soporte Rawzor.



Sin lugar a duda en las Olympus, un ahorro de espacio del 50% en disco por medio segundo de retardo en la carga del RAW es algo que puede merecer la pena. Por otro lado ahora los archivos de las Olympus son los más rápidos en relevarse de toda mi colección (ya lo eran antes) porque los tiempos de carga son mínimos en comparación con otros RAWs. Ahora sólo falta un visor de archivos Rawzor y me animaría a comprimir todos mis ORFs.

Un saludo:

Gracias por los comentarios Manuel

Lo que comentas es algo que ya había pensado, porque ya había visto que la lectura de los ficheros raw es bastante lenta desde disco. Enhorabuena por tus resultados, son mejores incluso de lo que esperaba.

Cuando puedas comentamos detalles de la nueva implementación de la librería de dcraw, me gustaría que me contaras ciertas cosas de cómo la vas a implementar para tener claro cómo estructurar ciertas partes de la aplicación.

Últimamente estoy teniendo una carga de trabajo anormalmente alta, cosa que me deja poco tiempo para actualizar la alpha 0.70. En cuanto pueda subiré algunos cambios dirigidos a mejorar la compatibilidad con distintos "hardwares".

Un saludo!

Mientras Egon va pasando su racha de mucho curro y prepara la próxima versión de pR alpha 0.70, yo sigo haciendo pruebas de velocidad, calidad... para el que será el motor de revelado que usará perfectRAW 2.0.

A las pruebas del otro día con el caché de disco para la carga del RAW y el soporte para Rawzor he añadido pruebas con el compilador de Intel, OpenMP, SSE2, GPGPU, etc...

Por ejemplo, mezclando el caché de imágenes con OpenMP y SSE2 y compilando con Intel he conseguido mejoras sobre los mejores tiempos de la tabla del post anterior de hasta un 50%. Eso quiere decir que cuando el nuevo motor esté listo (dentro de uno o dos años) será mucho más rápido que el que tenemos ahora, además de mucho más flexible.

Cuando pueda iré sacando versiones ejecutables de dcraw con las mejoras que vaya incorporando al código para hacerlo más rápido.

Otra cosa que estoy haciendo es controlar la calidad de la imagen para determinar en qué pasos del revelado es necesario extremar la precisión y en cuáles no es tan importante. Una duda que he tenido en al cabeza desde hace tiempo es la referente a los histogramas con la gamma aplicada. Tanto Guillermo, como Jacques como yo hemos querido siempre que los histogramas tuvieran un buen aspecto, aún a sabiendas de que apenas podía repercutir en la calidad final; otros, entre los que se encuentra Coffin, piensan que la diferencia es poco menos que ruido y que es imposible que se note en la imagen final.

La cuestión no es trivial por dos razones:

1. Photoshop calcula la gamma aún peor que Coffin, por lo que sacar la imagen lineal de dcraw y aplicarle la gamma en PS al aplicar el perfil de color puede no ser una buena opción.
2. Calcular la gamma con una LUT entera es muchísimo más rápido que hacerlo con valores exactos en coma flotante.

Por tanto, me ha parecido un buen momento para hacer una prueba definitiva de cuánto puede repercutir en la imagen final este asunto.

Para ello he generado un RAW virtual que presenta un gradiente muy suave (tanto como es posible en 16 bits) desde negro total a blanco total. Está claro que no es una imagen que uno encuentre habitualmente, pero la calidad de los casos extremos es importante.

A continuación le he aplicado una gamma 2.2 al estilo Coffin y al estilo nuestro. El resultado son las dos imágenes que os pongo a continuación (zoom x6) con sus correspondientes histogramas sacados con Histogrammar 1.2... como podéis ver las imágenes son idénticas a simple vista:
Gamma pR:

Gamma Coffin:

Histograma de gamma pR:

Histograma de gamma Coffin:


Sin embargo, ambas imágenes aparecen posterizadas. Es lógico dado que se trata de imágenes de 12 bits sin ruido... la única forma de eliminar la posterización es añadir un poco de ruido monócromo, lo que mejora el aspecto y el histograma:

Gamma Coffin con ruido:

Histograma de gamma Coffin con ruido:


Por tanto, parece que Coffin lleva razón. El mejor aspecto del histograma es equivalente a tener un poco de ruido en la imagen y, de hecho, añadir un poco de ruido a la imagen con la gamma aplicada a su estilo mejora la posterización y el histograma, incluso lo deja mejor que el de gamma en punto flotante.

Hasta ahora era aquí donde se quedaba la discusión... sin embargo, en el histograma (y también si uno compara muy de cerca las dos primeras imágenes, por ejemplo más o menos en el centro la imagen con la gamma de Coffin tiene una línea vertical que tira a magenta) es evidente una desalineación de los tres canales de color. Esto quiere decir que si aumentamos la saturación de estas imágenes en PS es posible que esas diferencias se exageren (he aumentado la saturación de manera exagerada, obviamente):

Gamma pR saturada:

Gamma Coffin saturada:

Gamma Coffin con ruido saturada:

Histograma de gamma pR satudara:

Histograma de gamma Coffin saturada:

Histograma de gamma Coffin con ruido saturada:


MIS CONCLUSIONES:

• En imágenes sin ruido a 12/14 bits la posterización en gradientes suaves es un problema que sólo puede mejorarse añadiendo algo de ruido monócromo. Esto se pone de manifiesto al usar Zero Noise en zonas de gradientes muy suaves, la falta total de ruido revela las limitaciones de la conversión A/D del sensor.
• La aplicación de una gamma entera usando una LUT es mucho más rápida y no afecta apenas al contenido de la imagen a simple vista pero sí (y bastante) a la fidelidad del color, por lo que en imágenes que se vayan a saturar puede producir colores falsos, especialmente en zonas de gradientes suaves.
• Para garantizar la máxima calidad es necesario usar una gamma en coma flotante, y habrá que acelerarla utilizando otras técnicas diferentes a usar una LUT (OpenMP, SSE2...).
• La gamma se tiene que calcular justo después de la conversión al espacio de color de salida y sin pasar por entero, directamente en coma flotante. Luego se convierte a entero para la salida definitiva.

Me queda por probar una LUT entera con interpolación bicúbica (algo parecido a lo que propone Guillermo en el post de debajo), pero creo que las librerías de funciones matemáticas para SIMD que estoy usando en las pruebas ya hacen aproximaciones polinómicas de las funciones exponenciales y logarítmicas, por lo que es posible que no se gane nada de velocidad ni en precisión. La gamma de Jacques también utiliza una LUT de más de 16 bits.

Un saludo:

No se ven las imágenes Manuel

Una opción intermedia entre la LUT con enteros de 16 bits y la interpolación es una LUT con enteros pero de más de 16 bits de precisión.

[]: índices enteros de la LUT
(): valores en coma flotante a los que refiere cada índice

P.ej.:

LUT de 16 bits (array entero de 65536 valores):
{
[0 1 2 3 4 5 6 ... 65535]
(0.0 1.0 2.0 3.0 4.0 5.0 6.0 ... 65535.0)
}

LUT de 18 bits (array entero de 65536*4 valores, 4 veces más precisión)
{
[0 1 2 3 4 5 6 ... 65535*4]
(0.0 0.25 0.5 0.75 1.0 1.25 1.5 ... 65535.0)
}

Para llamarla el índice sale de redondear el valor de entrada en coma flotante a un entero de 18 bits (o de los que sean) directamente usable como índice de la LUT precalculada:

Output = LUT[ Round(Input*4) ]

Salu2

Iniciado por Guillermo Luijk

No se ven las imágenes Manuel

Una opción intermedia entre la LUT con enteros de 16 bits y la interpolación es una LUT con enteros pero de más de 16 bits de precisión.

[]: índices enteros de la LUT
(): valores en coma flotante a los que refiere cada índice

P.ej.:

LUT de 16 bits (array entero de 65536 valores):
{
[0 1 2 3 4 5 6 ... 65535]
(0.0 1.0 2.0 3.0 4.0 5.0 6.0 ... 65535.0)
}

LUT de 18 bits (array entero de 65536*4 valores, 4 veces más precisión)
{
[0 1 2 3 4 5 6 ... 65535*4]
(0.0 0.25 0.5 0.75 1.0 1.25 1.5 ... 65535.0)
}

Para llamarla el índice sale de redondear el valor de entrada en coma flotante a un entero de 18 bits (o de los que sean) directamente usable como índice de la LUT precalculada:

Output = LUT[ Round(Input*4) ]

Salu2

Ya he arreglado las imágenes. La idea era hacer algo así y luego además interpolar el valor entre los dos entre los que está comprendidos. Pero puede que todo eso se más lento que la versión SSE2 que tengo preparada y que no merezca la pena.

Tengo que contarte el diseño que estoy haciendo del motor de revelado (con las inestimables opiniones de Egon) a ver qué te parece a ti.

Un saludo:

Iniciado por ManuelLlorens

[*]En imágenes sin ruido a 12/14 bits la posterización en gradientes suaves es un problema que sólo puede mejorarse añadiendo algo de ruido monócromo. Esto se pone de manifiesto al usar Zero Noise en zonas de gradientes muy suaves, la falta total de ruido revela las limitaciones de la conversión A/D del sensor.

Una puntualización: las limitaciones del conversor A/D de la cámara nunca se ponen de manifiesto en forma de posterización, y no lo hacen precisamente gracias al ruido del propio sensor que enmascara y con mucho cualquier posible cuantización debida a la conversión A/D. El ruido de cuantización en un sensor digital de imagen a día de hoy simplemente no es un problema.

Si aparece posterización en las imágenes de Zero Noise, o en imágenes sintéticas como las que has creado, o en los degradados creados en PS sin dithering, se debe exclusivamente a la limitación de 8 bits del display (tarjeta gráfica), al propio formato usado (JPEG), a una mala calibración del monitor, o a una mezcla de todos ellos.
Pero nunca tienen su origen en el conversor A/D de la cámara (donde Zero Noise elimina ruido, genera también una riqueza tonal muy grande que nunca daría posterización si no hubiera una limitación en los dispositivos de representación, pues es información que ha sido subexpuesta y por lo tanto los niveles originales fueron comprimidos en paralelo a la mejora de S/N generando un aumento acorde de la riqueza tonal).

Ya me enseñarás tu idea, que me parece titánica!. Le voy a comentar a Coffin lo de las inconsistencias de color en su gamma, pero no entiendo cómo se le pueden generar esas desviaciones, es que no aplica la misma LUT o la misma lo que sea a los 3 canales?

Salu2

PD: cuando dices que has creado el RAW sintético con todos los valores de 16 bits, querías decir 16 ó 12 bits?

Iniciado por Guillermo Luijk

Una puntualización: las limitaciones del conversor A/D de la cámara nunca se ponen de manifiesto en forma de posterización, y no lo hacen precisamente gracias al ruido del propio sensor que enmascara y con mucho cualquier posible cuantización debida a la conversión A/D. El ruido de cuantización en un sensor digital de imagen a día de hoy simplemente no es un problema.

Como siempre, llevas razón. En realidad no quería expresar que fuera una limitación del propio conversor, sino de el hecho de que los datos habían sido convertidos a digital, pero aún así es cierto que las bandas que se observan en las imágenes de arriba son limitaciones de los dispositivos que utilizamos para verlas y no de la imagen misma.

Ya me enseñarás tu idea, que me parece titánica!

Cuando tenga un rato te lo cuento, yo creo que te gustará.

Le voy a comentar a Coffin lo de las inconsistencias de color en su gamma, pero no entiendo cómo se le pueden generar esas desviaciones, es que no aplica la misma LUT o la misma lo que sea a los 3 canales?

Corrijo lo anteriormente escrito tras leer la respuesta de Coffin... me reitero en lo dicho en el post de más arriba, aunque creo que Coffin cree que si hubiera inyectado la "imagen falsa" antes del balance de blancos no habría pasado eso... lo probaré.

Un saludo:

En las pruebas de arriba he inyectado la "imagen falsa" en el código de dcraw después de la interpolación. Coffin me confirma que todos los métodos de interpolación que trae dcraw nativamente, salvo PPG, presentan el mismo problema, y así es, según he podido comprobar. El problema es mucho más acusado en 16 bits que en 8 bits.

Eso quiere decir que revelando con AHD, que es el más común, en 16 bits (apliquéis o no gamma en dcraw) puede que aparezcan colores extraños en zonas donde inicialmente no había ningún color al subir mucho la saturación... es fácil comprobarlo si insertáis un bloque (así en plan cutre) :

Código PHP:

  //(*load_raw)();
  for (i=0; i < iheight; i++)
    for  (j=0; j < iwidth; j++)
      image[i * iwidth + j][FC(i,j)] = j; 


En la función main() de Coffin, también tendréis que definir j con un int j; al comienzo de la función main. Luego reveláis cualquier cualquier RAW con -q 3 para que use AHD. El código de arriba sustituye la imagen original por un gradiente horizontal de negro a blanco antes de la interpolación (blanco hasta donde llegue el ancho de la imagen y que sin gamma parecerá muy oscuro, como todas las imágenes lineales). La imagen resultante revelada en un TIFF sin gamma en 16 bits (-T -4) la pasáis a PS, GIMP o lo que más os guste y subís la saturación a tope y veréis aparecer artefactos de color que no deberían estar ahí:

Código:

   dcraw -v -r 1 1 1 1 -T -4 -q 3 -o 0 dummy.raw

Podéis comprobar lo mismo de la gamma revelando con PPG (-q 2) que no introduce errores de redondeo (en los bordes sí por la interpolación lineal que hace Coffin en ellos) y le metéis gamma con -g 2.222 4.5, por ejemplo:

Código:

   dcraw -v -r 1 1 1 1 -T -4 -g 2.222 4.5 -q 2 -o 1 dummy.raw

Hacéis lo mismo con PS y veréis líneas multicolores (el efecto es mucho más acusado que con AHD).

Si alguno quiere probar todo esto y no quiere tener que recompilar dcraw (y se fía de mí lo suficiente como para creer que el ejecutable que os pongo contiene sólo los cambios que indico), aquí tiene un dcraw 1.423 original de Coffin con la modificación de arriba (puede que necesitéis el runtime de MSVC++ 2008 para hacerlo funcionar).

Me gustaría ver lo que hace Camera RAW utilizando un DNG virtual con un degradado negro a blanco sin interpolar. En cualquier caso espero que AFD y AMaZE no hagan lo mismo porque ambos están implementados en float de principio a fin.

En principio usando un ejecutable de dcraw con la gamma exacta (no el original de Coffin, pero sí los de Jacques Desmis, por ejemplo) y utilizando PPG, AFD, o en el futuro AMaZE, no debería haber problemas.

Un saludo:

Considero que he terminado la fase de pruebas preliminares antes de fijar el diseño del nuevo motor de revelado.

Además de los conceptos del caché y la integración con Rawzor en memoria y las comprobaciones de precisión del revelado de Coffin he hecho pruebas de compilación en Linux 32 y 64 bits con GCC y en Windows XP 32 y Windows 7 x64 con MSVC++ 2008 y con Intel C++ Compiler 11 ambos en 32 y 64 bits. También he realizado pruebas con OpenMP y SSE2 (programado "a mano" usando intrinsics) y he hecho algunos pinitos con la GPU mediante GLSL (desgraciadamente muy preliminares pero era para hacerme una idea de lo que implica de cara al diseño).

La conclusión es que en 32 bits la combinación ganadora es compilar con Intel y usar OpenMP/SSE2 por un lado y la GPU por otro y en 64 bits la combinación ganadora es MSVC++ con OpenMP/SSE2 (curiosamente el compilador de Intel se queda muy atrás en 64 bits, pero es posible que sea porque mi CPU es AMD). Por otro lado mis pruebas con OpenMP en Linux han resultado desacorazonadoras pues apenas se ha ganado nada, aunque funciona y ocupa los dos procesadores, supongo que debe ser fallo mío (aunque no se me ocurre cuál o puede que Ubuntu no saque tanto partido del hyperthreading de mi Atom como Windows).

Por otro lado, es imprescindible desde mi punto de vista mejorar la precisión del revelado de Coffin en un par de puntos (ved el post de más arriba): el cálculo de la gamma y la interpolación AHD, ambos deben hacerse en float y ahora se hacen en enteros (no en pR 0.65, que sí calcula la gamma en float y bastante rápido, pero creo que lo podrá hacer mucho más rápido en el nuevo motor de revelado sin renunciar a nada de precisión... lo de AHD lo tengo que estudiar con más detenimiento porque el consumo de memoria podría dispararse, tendré que pasar a procesar por tiles, pero eso iba a tener que hacerlo de todos modos porque, como ya os contaré, todo el motor de revelado nuevo va a procesar por tiles).

Con esto concluye desde mi punto de vista la fase de pruebas de concepto iniciales y voy a cerrar el diseño del motor de revelado. Ya os contaré algo cuando esté acabado el diseño.
___________________________

No sé cuántos me seguiréis estos rollos a parte de Egon y Guillermo, me da la sensación de que muy pocos , pero es normal.

Un saludo:

El pasado martes mantuvimos Egon y yo una reunión de trabajo (en persona por una vez) y cerramos el diseño del nuevo motor de revelado, que se llamará RL = RawLicatessen (que son las siglas de LightRoom al revés ).

Una de las cosas más importantes que hemos establecido es que todo el proceso de revelado irá en punto flotante (32 bits) sin conversiones constantes, como ocurre actualmente en dcraw (de 32 a 16 bits y de vuelta a 32 bits). Además hemos definido una nueva forma de representar en memoria la imagen que consideramos que será más rápida y compacta que el sistema que utiliza Coffin.

Con estos dos últimos ingredientes y otra serie de detalles técnicos (especialmente con el uso de la GPU) ahora sí que está definido RL 1.0, que no tiene fecha de salida, pero que debería estar acabado en un par de años... creo que cuando llegue el momento la espera habrá merecido la pena.

Mientras tanto, espero que tengamos acabado pR 1.0 con el interfaz nuevo y el motor de revelado antiguo... con un poco de suerte antes de las próximas navidades.

Un saludo:

Sirva este post para daros ánimo a que continueis, a ver si vemos esa versión 1.0 en breve.

Salut y buenas vacaciones para el que las pueda disfrutar.

Me voy de vacaciones. Nos leemos en septiembre. ¡Buen verano a todos!

Espero que después del verano, con fuerzas renovadas, demos el empujón definitivo a pR.

Un saludo:

mmm no sé por qué últimamente no recibo notificaciones de actualizaciones es este subforo.
Veo que habéis puesto más noticias, toca leerlas con detalle...

Buenas vacaciones

Buenas a todos. Creo que no podré estar por aquí a tope hasta octubre, una vez haya arrancado bien el curso.

He hablado con Egon y la intención es sacar pR 1.0 con el nuevo interfaz lo antes posible y luego trabajar en la 2.0.

Un saludo:

Estamos deseando verla.
Un saludo, Manuel

Yo el primero ... ¡me alegro de leerte, Fernando! Sueles estar más activo en el foro cuando menos lo estoy yo

Un saludo: