OJODIGITAL

En imágenes con ruido no, pero en imágenes sin ruido sí hay bastante diferencia. Además es un método efectivo de reducir los píxeles sobreinterpolados de AFD/VCD (prueba a revelar con recuperación de altas luces y estos algoritmos y busca píxeles raros en las zonas sobreexpuestas).

Lo de lin4_interpolate era un bug que arreglé hace un par de versiones, tal vez se me pasó ponerlo en los cambios, aquí tienes el código correcto:

Falta reescribirla en "formato Coffin", pero como no va a ser más rápida ya habrá tiempo.

Por otro lado, lin4 (bilinear RGGB para los que no ven el código) lo metí como forma rápida de ver una imagen de mis Olympus sin los laberintos (o las celdas 2x2 que produce con 3 colores. Es más rápido que el equilibrado de canales verdes+lin3 y me gusta mantenerlo como referencia.

Respecto al algoritmo por defecto tiene que ser un rápido y de buenos resultados. Yo optaría por PPG, a menos que finalmente saquemos una imagen previa mientras el programa interpola con algo mejor, en cuyo caso el algoritmo por defecto será el de Emil Martinec cuando lo implementemos que será, sin lugar a dudas, el mejor del mercado.

De todos modos se le puede dar una pensada a todo el tema.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Es una cosa un poco rara, la verdad. No termino de entender qué se gana con ello, especialmente porque no tienes apenas control sobre el proceso de revelado. Si exportas a TIFF interpola con AHD sin ninguna opción.

Lo de los 72 bits suena a guasa cuando la imagen de partida tendrá como mucho 14. ¿De dónde sacan los demás bits? ¿Para qué sirve la exportación a HDR?

Tampoco me queda muy claro (aunque reconozco que no me he leído ni el manual ni las FAQ de su página más que un poco por encima) si su proceso de compresión compatible con JPEG es con o sin pérdida porque en realidad me da la sensación de que quiere decir que a un JPEG de mitad de tamaño (porque eso es lo que se ve al abrirlo con un visor de imágenes) le pegan los datos RAW comprimidos al final. Si es con pérdida la idea es demencial.

No sé, supongo que tiene su gracia aunque yo no se la vea. Me gustaría ver qué tiene que decir Guillermo del tema.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

gracias Manuel, yo solo he podido entender la parte en Español que es el unico idioma que conozco, con la -demo- tampoco se llegar mucho mas lejos.

Sí, claro, tiene sentido que lo de quitar el min/max vaya peor en imágenes con ISOs bajos. Yo sólo lo había probado con el RAW de la D700, que entre tanto ruido todo eso se camufla.

¿Cuál es el algoritmo de Emil Martinec? Lo vi alguna vez escribiendo en dpreview. Lo de lin4 lo decía porque estaba buscando la función para empezar a trabajar con una interpolación desde cero y quería basarme en ella, que estaba todo muy clarito. Al final no me hizo falta, el experimento funcionó aunque el resultado haya sido muy malo.

Yo creía que xDepthRAW era un formato y no un revelador, con vistas a almacenar datos de hasta 72 bits en un tamaño reducido. Lo del jpg estaba pensado para que pudiera abrirse como jpg normal conteniendo información adicional del RAW en los metadatos o algo así. Ya nos sacará Guillermo de dudas.

Un saludo.

Cachis, se me ha reiniciado el PC mientras escribía esta respuesta. En fin...

El de Emil lo está afinando, lo tiene casi acabado, probablemente lo publicará cuando lo acabe. Sus resultados son MUY superiores a todo lo visto hasta ahora. Cuando lo termine lo implementaremos en dcraw/perfectRAW (tiene algo que ver con el cambio .NET -> wxWidgets ya que Emil sólo usa MacOS y ahora compilaremos nativamente para todos los SOs) y será la bomba.

Respecto a desarrollar tu propio algoritmo de interpolación, sigue probando y no te desanimes, mis primeras pruebas también fueron un desastre. Ahora, dado lo bueno que es el de Emil, me lo tomo con más calma. Mi objetivo es desarrollar un algoritmo compañero del de Emil que conjugue suficiente calidad en imágenes con y sin ruido y mucha velocidad. Para hacer las cosas bien y despacio ya está el suyo, pero nos hará falta algo tan bueno con AFD con ruido y como AHD sin él.

Paul sigue trabajando en un algoritmo mixto AHD/VCD y tiene más ideas que probar al respecto. Yo por mi parte tengo un diseño de mi propio algoritmo que creo que tiene una buena base, pero me faltan rellenar muchos detalles importantes. En el código que te pasé, Lassus, había una parte, la que sirve para identificar en qué zonas de la imagen aparecen texturas en frecuencia Nyquist (las zonas más delicadas desde mi punto de vista). Para ello interpola bilinealmente los canales G1 y G2 por separado. En un píxel rojo o azul, si la diferencia entre el valor interpolado de ambos canales es grande, entonces estás en un píxel en medio de una textura Nyquist (es decir, con la máxima frecuencia que registra la cámara), en caso contrario (con un valor threshold apropiado) estás en una zona más suave y puedes interpolar "sin miedo".

Te explico un poco en qué consiste mi idea y qué características quiero que tenga mi algoritmo:

• Quiero que sea al menos tan rápido como AFD (con la esperanza de que Egon pueda implementarlo en la GPU en tiempo real). De momento (lo mío no son más que pruebas parciales que algún día tomarán forma) extraigo la luminancia en los píxeles verdes (utilizando el filtro paso bajo de AFD). Luego distingo entre píxeles fáciles y píxeles difíciles en los huecos de la luminancia (donde hay píxeles rojos y azules). Los fáciles son aquellos en los que con el valor de luminancia ya calculado se puede estimar con suficiente precisión el valor que falta sin posibilidad de error. Hay un valor threshold que regula cuánto de seguro es el algoritmo (más seguro, más lento, menos seguro más rápido), por defecto tan rápido como sea posible sin que el ojo lo distinga. De ese modo tenemos ya más de un 60% de la luminancia calculada a la velocidad del rayo. Esa es mi primera idea para tener algo rápido: no inviertas demasiado tiempo en zonas (como un degradado suave) en las que el valor es muy fácil de calcular y, aunque fallaras, lo harías por poco y encima el ojo no lo distinguiría. En imágenes con mucha textura saldrán menos "píxeles rápidos" en imágenes suaves saldrán muchos más, pero de cualquier modo será más rápido que no hacer esto (luego existe la posibilidad en una fase final de refinamiento de volver a visitar esos píxeles y ajustar su valor para dar más precisión al algoritmo).
• Debe crear gradientes muy suaves. Esto ya funciona, gracias al punto anterior.
• Mi algoritmo no debe extender el ruido RAW en absoluto. De momento estas primeras cosas ya las tengo implementadas y funcionan muy bien, de hecho, mi algoritmo interpola la luminancia de la imagen de las botellas con mucho menos ruido que todos los otros que he probado y es rapidísimo... pero deja píxeles huecos aún por interpolar, los más chungos.
• No debe crear diagonales dentadas. Esto ya está logrado también en las zonas fáciles, ahora me quedan las difíciles.
• Debe dar ejes de luminancia muy enfocados. Eso está garantizado por el algoritmo.
• Me queda interpolar la luminancia en los píxeles difíciles: ejes y texturas en frecuencia Nyquist (que las fases anteriores de la interpolación han dejado sin interpolar). Para ello primero aplico un cálculo diferente pero parecido al de los píxeles fáciles a los ejes y con una gran velocidad deben salir perfectos (eso lo tengo en la cabeza pero aún no he podido probarlo), sólo me quedan las texturas en frecuencia Nyquist, la auténtica madre del cordero de los algoritmos de interpolación. Pero fíjate que salvo esos puntos ya tengo todo lo demás con buena calidad y rápido.
• Para los píxeles que me quedan calculo un pixel signature de 64 bits (ese cálculo ya lo tengo diseñado, lo que aún no sé es si me valdrá también con 32 bits para ahorrar memoria o no) que me identifica la relación entre el píxel y su entorno (teniendo en cuenta las 8 direcciones) de tal modo que pueda comparar el píxel en cuestión con el resto de píxeles difíciles que tienen la misma relación con su entorno dentro de un determinado radio con una simple comparación de sus firmas (aquí no hace falta threshold porque ya va incluido en el cálculo del pixel signature, por eso no sé si me valdrá con 32 bits, y se compara con un simple ==, eso hace mi idea mucho más rápida que, por ejemplo, NLD donde la comparación necesita de un filtro de Gauss que hay que recalcular en cada comparación entre píxeles, mientras que yo puedo precalcular las firmas de los píxeles y guardarlas para comparar luego).
• Y hasta ahí he llegado de momento. Me queda definir cómo voy a obtener el valor de esos píxeles (sigo sólo hablando de luminancia). Sé que o bien cojo en esos píxeles la luminancia de los G1 o bien la de los G2 (porque en esas zonas, por narices o tengo un patrón vertical, o uno horizontal, o da igual que lo vea como uno de ambos). Sé que debo tomar la misma decisión en todos los que tengan las misma firma. Sé qué relación quiero que tenga la decisión que tomo en los rojos con la que tomo en los azules (tengo una restricción definida para eso). Pero no sé cómo decidir hacia qué valor voy en cada píxel (si G1 o G2, he hecho pruebas siguiendo mi intuición pero aún ninguna demasiado buena). Probablemente con una función de coste y una optimización en varios pasos, pero eso sería muy lento. Así que quiero algo aproximado y potente... tengo aún mucho que pensar.
• Si consigo una buena luminancia, entonces la crominancia la interpolaría como hacemos ahora con AFD con pattern matching, que es bastante buena y ya veríamos en el futuro.

Un ejemplo de cómo va mi algoritmo (repito: ¡superpreliminar! , más que nada por si alguno piensa que me he terminado de volver loco tras lo de arriba ). Sólo luminancia para que veáis que la idea funciona. Amplias zonas se interpolan muy rápido y los ejes salen perfectos, incluso las diagonales que no tienen bordes dentados, tan bien como en AHD de hecho. Pero quedan los píxeles difíciles (los negros):


La gracia es que hasta ahí llega en muy poco tiempo y sólo he usado información del canal verde (mi intención es guiar con este resultado la interpolación de los otros dos canales. De hecho, creo que tengo un método para sacar en un sólo paso, muy rápido y de manera perfecta los otros dos canales a partir del verde, incluso en ejes saturados. Pero ya veremos), pero es cierto que aún queda mucho.

Pues sí, pero el programa que te puedes descargar lo que hace es convertir un RAW a ese formato (o a TIFF, etc. o sea que sí es un revelador), así que los 72 bits, ¿con qué los llenas?

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Lo de los 72 bits supongo que a modo de "contenedor". Vamos que sí, el nuevo formato estará listo para imágenes de más rango dinámico (por la mayor profundidad de bits), pero no quiere decir que con un RAW o captura normal de una cámara, el rango dinámico va a aparecer por sí solo solo por convertir a ese nuevo formato.

Imagino que la clave de este formato nuevo está en que es capaz de comprimir mucho con calidad; en realidad cualquiera que logre eso revolucionará cualquier formato de almacenamiento de datos (imagen, sonido, video,...).

__________________

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

¿Alguno con mucha RAM en el PC (yo con 2 Gb no puedo) ha sido capaz de abrir un RAW de la 1Ds Mark III?

Frustrado por no poder abrir esos RAWs he arreglado el problema definitivamente. Ahora (en la próxima versión que suba junto con los últimos cambios de Coffin y de Paul) el programa usará la memoria disponible y, si no la hay, no guardará más buffers intermedios automáticamente en vez de cascar. Es decir, que podréis abrir sin problema cualquier RAW por grande que sea con independencia del vuestra RAM. Si hay más los revelados posteriores irán más rápidos, si hay menos pues irán más lentos.

De todos modos tengo que optimizar el uso de memoria del programa tarde o temprano. Algunas cosas sí pueden mejorarse.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Hola a todos,

yo también he estado unos días desconectado (viajes, navidades,..) , y todavía lo estaré un poco más (más viajes, etc.), pero os continuo siguiendo tanto como puedo.

Hoy os quería escribir porque vi una noticia que igual os interesa: las librerías Qt por fin son libres. Nokia compró Trolltech y las ha liberado bajo LGPL.
LGPL License Option Added to Qt — Qt Software - Code Less. Create More. Deploy Everywhere.
Creo que tienen bastantes ventajas, entre ellas que son multiplataforma (com wxwidgets), y parecen bastante optimizadas a juzgar por la cantidad de programas interesantes que están hechas con ellas, pero evidentemente los que estáis trabajando en el código sois los únicos que podéis juzgarlo.

Espero que os sirva de ayuda!

Muchas felicidades por todo el trabajazo que lleváis, y la genialidad que tenéis para empujar semejante proyecto.
Saludos!

Gracias por el aviso henryk. Sé que alguien de Nokia se puso en contacto con Egon por ese tema, pero no sé en qué acabó la cosa.

Creo que, de todos modos, wxWidgets tenía alguna ventaja sobre Qt (por ejemplo los cuadros de diálogo nativos), pero que sea Egon el que nos informe (y si él considera positivo el cambio a Qt pues bienvenido sea).

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Yo también tengo en el portátil 2 GB de RAM en Vista 32 bits y lo he probado con los RAW de la Nikon D3X y las Canon de 21 Mp y se me colgaba, hasta que fuí a la gestión de memoria virtual y se la aumenté a 4 GB, pero sólo deja hacer el primer revelado, parece que la memoria quede ''ocupada'' y si cambias algún parámetro y vuelves a revelar se cuelga .

saludos

A ver si puedo subir en breve la versión corregida. Me interesa mucho que la pruebes y nos cuentes si se ha arreglado el problema .

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Acabo de actualizar.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Y otra vez más .

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Pues con los raw de más de 20 Mp me sigue pasando lo mismo, al primer intento revela y si cambias algo y vuelves a probar ya no, con los raw de 12 Mp funciona bien.

Para ponerlo mucho más difícil también lo probé en un PC con Windows XP de hace 4 años con sólo 1 GB de RAM, pero con el raw de una Hasselblad de 39 Mp que encontré en una página y a la primera lo reveló , aunque tardó ¡5 minutos! y las rascadas del disco duro eran tremendas, espero que te sirva para encontrar el problema.
Pongo el enlace a la página de raws: http://www.rawsamples.ch/index_en.php


saludos

Lo cierto es que los resultados son espectaculares, más aun con las nuevas funcionalidades.
En particular, me parece genial la posibilidad de comparar dos revelados, pero si al final decides retornar a la versión guardada, de momento no te queda otra que recordar los parámetros que utilizaste en su revelado ¿cierto?
Un abrazo y ánimo.

Hmmm... sigue siendo porque se queda sin memoria.
Voy a afinar un poco el uso de memoria a ver si se arregla...
Definitivamente voy a tener que implementar el modo memoria baja.

Voy a tener que rehacer todo el soporte de los buffers para que no guarde más cuando no tiene memoria. Debería funcionar bien y es lo ideal, pues de ese modo la aplicación se autoajustaría siempre a cada máquina e imagen. Lo subiré en el próximo cambio, de momento no abráis imágenes tan grandes si no tenéis memoria .

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sí claro. Pero vamos que todo eso son cosas que se implementan en el interfaz y pueden hacerse todas las que se quieran. En el diseño original (el que habrá en la 1.0 con OpenGL) habrá dos revelados simultáneos con dos conjuntos de parámetros y podrás cambiar de uno a otro según quieras. Lo que sí es cierto es que pocas máquinas tendrán memoria para guardar dos revelados completos con sus buffers intermedios por lo que uno de los dos revelados será el activo (con buffers) y el otro no.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Hola, ya probe la ultima actualizacion y es fantastica, la opcion snapshot es magnifica, poder comparar los diferentes revelados es muy util. Tambien he notado que este es el revelador que mas fidelidad da en los colores. Asi que muchas gracias y seguire acompañandolos en este proceso asi no sepa ni pio de programacion.
Saludos

Está genial lo del antes/después, te has adelantado a Egon no?
Me he dado cuenta de que, como es posible toquitear bastantes parámetros, además de preservar la imagen con el "antes" habrá que preservar el conjunto de ajustes (es decir los valores de todos los parámetros que llevaron a ese "antes") para en un momento dado poder volver a él, o como poco ver qué es lo que ha cambiado para llegar al "después".

Sería guardar los juegos A y B de settings junto a las imágenes reveladas.

jeje yo pidiendo y no me digno a ponerme con el balance de blancos...
este domingo voy a Madrid a ver si allí con el ADSL puedo ir mirando documentación.

__________________

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

Aunque no os lo creáis hoy por primera vez me he puesto a configurar el proyecto para poder depurar la DLL en C desde el interfaz en C#. Hasta ahora cuando tenía que depurar alguna de mis funciones en la DLL era a base de insertar MessageBoxes aquí y allá. Las funciones de dcraw que puedo ejecutar en modo EXE sí que las depuraba.

El caso es que va lento como una patata pero al menos sé dónde cascan las cosas y puedo depurar mucho más cómodamente. Estoy depurando el casque de los archivos grandes porque, no es falta de memoria, es otra cosa.

De todos modos ya he arreglado el tema de la memoria, ahora va como la seda , no hay mal que por bien no venga.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Bueno, no ha sido por adelantarme, es que era una chorrada implementarlo como lo he hecho pero no se me había ocurrido antes.

Lo de los dos juegos de parámetros iba en la definición original, en realidad se pueden guardar todos los que se quieran, incluso ponerles nombres. Pero sólo se verán dos a la vez. Pero eso no lo voy a implementar de momento, a menos que me dé otra vena .

Pues sí, a ver si te pones las pilas . Aunque los tres últimos artículos de tu web son la bomba, así que no me quejo .

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Bueno, creo que esta vez sí que está arreglado. Lo que he subido sólo tiene ese cambio pero además lleva control de errores, una mejora importante.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Gracias Sipa. Para usar el programa no hacen falta conocimientos de programación. Aquí compartimos información sobre el proceso de programación porque hay algunos interesados, pero no pretendemos que todos lo entiendan ni les interese.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

quim7, he visto el enlace que has puesto. Muy útil gracias... voy a probar con un Hasselblad de 50 megas, cruzo los dedos.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel solamente as actualizado los ficheros compilados para sse, los ss2 siguen teniendo fecha del 16, ¿es correcto ?

Saludos

Es muy probable. En breve subiré una nueva versión y tendré más cuidado . A ver si tengo un rato para crear un procedimiento automático que lo haga todo: compile, comprima, haga copia de seguridad del código y suba.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Llevo toda la noche y toda la mañana intentando solucionar definitivamente los problemas con las imágenes grandes sin grandes resultados. Después de mucho depurar he llegado a la conclusión, creo que acertada, de que el problema está en la fragmentación de la memoria RAM debida a coger y soltar buffers constantemente. Estoy 99% seguro de que el programa no tiene memory leaks, así que no hay otra causa para pedir 200 megas con un malloc, habiendo 400 libres y que dé un Out of memory.

El problema es que, a pesar de que hay RAM disponible, no la puede utilizar porque malloc/calloc necesitan bloques de memoria contiguos.

He probado a reemplazar la gestión de memoria de MSVC por una mejor. He cambiado MSVCRT por the Hoard Memory Allocator, y debo decir que entre eso y los demás cambios que he hecho, ahora perfectRAW es mucho más rápido, ya veréis como sí... pero los problemas de memoria siguen siendo los mismos .

He probado con un modo low_memory=1, en el que no guardo nunca más que los buffers imprescindibles (dos) a ver si con eso mejora la cosa pero pasa lo mismo, si no hay memoria casca (bueno ahora sale una ventanita que dice que no hay memoria, al menos en eso sí hemos ganado).

Además, a veces sí carga la imagen y después no es capaz de volver a procesarla y funciona mucho mejor con el PC recién arrancado (por eso de la fragmentación de la memoria). Los programas "desfragmentadores de RAM" tampoco ayudan nada.

Con imágenes de tamaños normales todo funciona como antes, eso sí, pero en mi máquina (2 Gb de RAM) imágenes de más de 20 megas no se revelan más de una vez.

La única solución que se me ocurre es crearme mi propio gestor de memoria que llame a Hoard y si Hoard no devuelve memoria que pida directamente memoria virtual al SO y luego sepa devolver la memoria según de dónde venga, pero no sé cómo hacerlo para que sea multiplataforma (más bien sé hacerlo en Windows, pero no en otros SOs). Supongo que es lo que hacen todos los programas que consume RAM a tutiplén, como Photoshop, gestionarse ellos mismos la RAM para evitar estos problemas.

¿Alguna idea brillante?

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Cuantos posts en tan pocos días, esto es un buen síntoma.

Estoy deseando ver algún resultado preliminar del algoritmo de Emil. Hoy me han pasado una imagen revelada en Huelight y mejora en algunas cosas a AFD (algunas diagonales, casi ningún artefacto), aunque el resultado global del segundo me sigue gustando más. Si el de Emil coge lo mejor de los dos sería la bomba.

Al VCD y VCD/AHD de Paul lo veo un poco en la vía muerta. No sé exactamente qué ha portado de la idea original, pero después de 45 versiones que lleva no ha conseguido afinarlo lo suficiente como para competir con los mejores.

Por cierto, hablando de la necesidad de un algoritmo rápido para el primer revelado de perfectRAW el otro día probé a mezclar VCD y PPG, dejando el primero para los verdes y PPG para azul y rojo. Es igual de rápido que PPG pero algo mejor en el tratamiento de zonas complicadas. Podría ser interesante, aunque yo sigo prefiriendo que al cargar se muestre AFD, sobre todo si la implementación de Paul es tan rápida como dices.

Lo que comentas de las frecuencias nyquist más o menos es lo que venía aplicando en el refinado de la matriz de bayer para no quitar detalle en las zonas más complicadas. Le echaré un vistazo a tu código porque será más rápido y preciso que el mío. Hacer un algoritmo me queda muy grande, aún tengo muchísimo que aprender de teoría y de C.

Gracias por la instructiva la explicación de cómo funciona tu algoritmo. Ánimo con ello, que seguro que dejas a los demás en la estacada.

Siento no poder ayudarte con la gestión de la memoria. ¿Por qué no pruebas con el AFD de Paul? Quizás sea menos voraz... Una última opción, en contra de toda la filosofía de perfectRAW, es que cuando se usen archivos muy grandes se calcule con antelación cuánta memoria aproximadamente se necesita. Si es mucha más de la disponible, se podría revelar con -h y sólo hacer el definitivo al guardar. Es una chapuza, pero mejor que el que no funcione.

¡Un saludo!

Excelente programa!!! existe algun tutorial sobre su manejo?

Muchas Gracias!!!


Salu2

Juan

Photoshop también funciona mejor con el "PC recién arrancado". Cuando has abierto y cerrado varias imágenes grandes y con muchas capas, vuelves al estado inicial (o sea done a lo mejor solo tenías 2 imágenes abiertas) y va mucho más lento, hasta sale la barra de progreso a veces. Esto solo me ha pasado con el portátil Vista, pero me ha pasado más de una vez, lo tengo asumido.

Respecto a soluciones brillantes... mucho me temo que el fantasma del "revelado por zonas" como hace ACR se acerca peligrosamente. Creo que es rehacer un montón de trabajo por tu parte, así que probablemente lo inteligente es un buen modo "mínimos buffers" para cuando se tiene poca memoria o el PC ya anda perezoso.

Salu2

PD: y el que tenga una Hasselblad de 49Mpx que se compre el DxO por el precio de la gomita que rodea el visor

__________________

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

Si el DxO cuesta lo que les ha costado a casi el 100% de usuarios el Photoshop esa gomita del visor te sale gratis

Tendrás que disculpar mi ironía, el DxO se debe comprar pero el Photoshop no???

Es que me sale urticaria con tanto Photoshop comprado barato, ayer mismo una sobrina me enseña su portátil y veo que se abre Ps CS2, le pregunto ¿qué haces con eso ahí?, y me contesta "ah, no se, nunca lo he usado y tampoco se si me servirá, me lo bajé el otro día, me han dicho que me irá bien para crear los cuentos infantiles que quiero hacer, es que el paint del windows no me va bien".

Coño, alguien le diría de buenas a primeras que se dejara de historias de paint y que usara photoshop, si es que estamos en un pais de sinverguenzas.

Bueno, ya me he desahogado. Animo y a seguir con lo vuestro (y también un poco nuestro, porque aunque no escribamos una sola línea de código los que estamos ya utilizando vuestra creación, somos parte importante de vuestra motivación, esto lo se por experiencia propia por otras aventuras donde me he puesto a tirar yo del carro).

Salut

__________________
[U]ToniLupi[/U]

Mis imágenes en [URL="http://www.pbase.com/tonilupi"]http://www.pbase.com/tonilupi[/URL]

Eos 400D + 100mm macro f2.8 USM

Bueno, después de un fin de semana agotador tratando de identificar las causas exactas del problema con la memoria (en el que he rehecho varias veces el código de los buffers intermedios y probado varias aproximaciones, como dice Lassus más arriba, intentando reservar la memoria que voy a necesitar por anticipado) he llegado a las siguientes conclusiones (luego las posibles soluciones):

Diagnóstico:

• Nuestra dcraw.dll no tiene fugas de memoria (memory leaks, que se llaman) (era a priori la causa más probable para el problema que estaba experimentando, una corrupción del heap). He tenido que crear mi propio detector de fugas, que coteja en tiempo de ejecución cada malloc/calloc/realloc con cada free para ver si existe correspondencia y he revisado todas las escrituras en buffers. Resultado: no hay fugas. De paso he aprendido lo fácil que es sustituir las funciones propias de la librería de C o del propio dcraw desde un archivo de inclusión. Eso es una buena noticia porque hace tiempo que tengo intención de separar todo el código añadido por mí a un archivo a parte y sólo poner un include en el archivo original de Coffin.
• El gestor de memoria, Hoard, que he incluido se va a quedar porque es muy rápido y evita la fragmentación hasta donde se puede, forma parte de mi solución (más abajo).
• El problema es precisamente el que comentaba en un post anterior: un problema de fragmentación de la memoria disponible. 2 Gb pueden parecer mucho, pero de ahí se van casi la mitad para el interfaz (que contiene dos buffers de la imagen) + el runtime de .NET. Los RAWs muy grandes dan problemas porque hay que reservar para ellos buffers enormes "de una sola pieza" y encontrar varios de esos dentro de los 2 Gb no es tan fácil, por lo que se ve.
• En Windows de 32 bits, cada proceso tiene un máximo de 2 Gb de RAM disponibles entre memoria virtual y física. Las únicas maneras de superar ese límite son: 1) modificar la información de arranque de Windows en el boot.ini y llevar ese límite a 3 Gb, limitando a 1 Gb para el kernel; obviamente no es una opción válida. 2) separando la DLL en varios procesos independientes que se comuniquen entre sí; lo descarto porque requeríría muchas modificaciones y ralentizaría el procesado. 3) utilizar características propias de Windows (tiene un sistema diseñado para esos casos); lo descarto porque haría la aplicación difícilmente portable. 4) usar el HD cuando se superen los 2 Gb al estilo PS; es la única opción viable, aunque tal y como lo voy a implementar (más abajo) no llegará nunca a usarse con las imágenes actuales (ni siquiera con la Hasselblad), pero permitirá que la aplicación funcione en el futuro con imágenes aún más grandes (hay que tener en cuenta que el límite de 2 Gb seguirá presente en el futuro hasta que la aplicación sea de 64 bits nativa, cosa que no va a ser precisamente mañana).

Soluciones (hay que aplicar todas a la vez):

• Pasarlo todo a C++ con wxWidgets+OpenGL y olvidarnos de .NET . Eso dejará mucho de los 2 Gb disponibles. Es una parte de la solución, pero no toda, obviamente. ¡Qué casualidad que vamos justo por esa línea! . Aunque no habrá que esperar a tener el nuevo interfaz para poder cargar imágenes enormes gracias al resto de soluciones.
• Mantener el gestor de memoria Hoard (licencia Open Source), que es mucho más rápido que MSVCRT (Microsoft Visual C Runtime). De verdad que con los últimos cambios va todo volao.
• Ir reservando los buffers intermedios de memoria y si no hay pues no hay (que es como está la última compilación), aunque con los cambios que propongo abajo, se reservarán todos los buffers intermedios casi siempre. Esto no se aplica a los tres buffers imprescindibles que comento en el punto siguiente.
• Son necesarios al menos 3 copias íntegras de la imagen tal y como está ahora dcraw (Coffin necesita dos, yo tres para poder volver a revelar sin recargar la imagen). El primero es sobre el que se va procesando la imagen. Es un buffer que se va liberando y reservando a lo largo del código según lo que haya que hacer con él, lo que aumenta obviamente la fragmentación. Eso no se puede cambiar, pero hasta la imagen más grande cabrá en los 2 Gb una sola vez. El segundo buffer necesario por narices (a menos que vayamos a leer la imagen del disco tras cada cambio, cosa absurda) es una copia del buffer de la imagen tal cual está nada más leerlo. Ese sirve para poder revelar de nuevo sin volver a leer del disco (y descomprimir/decodificar el RAW) al cambiar los parámetros de revelado. Para este (y para el resto de buffers intermedios tengo una idea que explico más abajo). El último imprescindible tal y como está ahora la cosa es uno que se usa para grabar el TIFF o mandar la salida a la pantalla. Ese buffer creo que puedo soslayarlo reescribiendo el código para realizar ese proceso a cachitos (vamos tengo que conseguirlo sí o sí). De modo que puedo dejarlo en dos copias íntegras de la imagen, una de una pieza y la otra, aquí viene el truco, en varias (con lo que revelaría cualquier imagen que revele dcraw.exe). Tened en cuenta que una sola copia del RAW de la Hasselblad en memoria son 316.000.000 bytes así por las buenas (¡imaginad lo que es mantener todos los buffers para esa imagen y que tengan que ser todos de memoria contigua dentro de los 2 Gb!, incluso los tres buffers completos imprescindibles de ahora son un giga entero en tres trozos contiguos. Es una barbaridad. En comparación los de mi Oly E-300 ocupan 50.000.000 bytes en memoria cada uno, lo que es mucho más encajable dentro de los 2 Gb).
• Entonces, la idea es crear un gestor de memoria para usarlo sobre los buffers intermedios (incluida la copia de la imagen recién cargada que comento en el punto anterior) y no sobre los demás buffers de dcraw, que pedirían la memoria a Hoard sin más (con un malloc/calloc/realloc, es transparente para la aplicación). Ese gestor de memoria crearía esos buffers intermedios a base de cachitos de un tamaño moderado (yo diría que 10 megas estaría bien) pedidos a Hoard (y los crearía múltiplos de 16 en frontera de 16 para usar SSE más tarde). Es decir, que en vez de un buffer de una pieza crea un buffer compuesto de varios cachitos más pequeños, lo que hará que encajen mejor en la memoria y evitarán la fragmentación. Para copiar desde y hacia esos buffers mi gestor de memoria copiaría cacho a cacho (con un memcpy propio), lo que ralentizaría una pizca el proceso pero prácticamente nada (se podría sobreescribir la función memcpy para que el código no tuviera que cambiar ni una línea, pero no lo hará así por no ralentizar ni una pizca el resto de memcpys de Coffin). Además, intentaría programar esos memcpy utilizando SSE para acelerar las cosas al máximo. De ese modo se aprovecharán mucho más los 2 Gb y se podrían cargar imágenes mucho más grandes. Además, esos buffers sólo se usan de almacén, no se calcula nada sobre ellos así que el código ni se enteraría.
• En una versión posterior, podría ampliar el gestor de memoria para usar el disco duro y crear con él los buffers imprescindibles para máquinas con poquísima memoria o para imágenes descomunales (¡tan grandes como el espacio en disco disponible!). Ayer probé a revelar un raw de 10 mpx en una máquina con 224 megas de RAM de los que obviamente tenía libre mucho menos, 100 megas, y tiraba de memoria virtual (con lo que iba super lenta), pero no cascaba. Eso es lógico porque independientemente de la RAM la aplicación tenía sus 2 Gb disponibles y, a base de buffers más pequeños la cosa encaja bien.

Creo que no me costará mucho hacer algo así y lo veo imprescindible. Tened en cuenta que tal como está ahora no sólo no carga los RAWs de la Hasselblad, sino que los de la Canon 1Ds Mark III cascan como máximo al tercer revelado (en el que la fragmentación ha limitado las opciones de crear nuevos buffers contiguos de los imprescindibles), así que no podemos decir que nuestro programa es sólo para RAWs pequeños. Vamos que no queda más remedio que currarme algo así, al estilo de Photoshop.

Lo que queda obsoleto con estos cambios es el "contador de memoria física libre" que tiene ahora el programa. Sin embargó habrá que informar de la memoria total ocupada por los buffers y del estado general del programa.

Bueno, me he quitado un gran peso de encima soltándoos este rollo porque me he tirado todo el fin de semana dando vueltas a la cabeza sobre las causas y posibles soluciones al asunto. A cambio he aprendido muchas cosas sobre la gestión de memoria de Windows (que es un 95% idéntica a la de Linux, no os vayáis a creer) y de paso pR es ahora más rápido. Debí haberme imaginado que si PS tiene su propio gestor de memoria (que pre-reserva al arrancar un porcentaje de la memoria física, como todos sabemos, que utiliza un archivo de swap propio en disco, y que obliga a los plugins a reservar memoria a través de sus propio gestor de memoria) era por algo y que no nos íbamos a librar nosotros, que trabajamos con imágenes grandes en varias copias.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel, estás seguro que te apetecía dejar tu anterior trabajo? vaya curro te estás pegando. Esta semana tómatela con tranquilidad. Mi admiración por todo lo que haces, sobre todo en temas escabrosos y desagradables como la gestión de memoria qeu ahora te ocupa.

SAlu2

__________________

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

Buff, Manuel, menudo curro.
Windows 32 bits está empezando a tener problemas de gestión de memoria, como ocurrió con win 16 y que forzó el paso a windows NT/XP.
2GB parecen muchos, como dices, pero empiezan a quedarse cortos con las necesidades de hoy en día de algunas aplicaciones (como la nuestra). La memoria contigua en grandes bloques puede escasear, como dices.

Creo que eso forzará en poco tiempo (1 año o a lo sumo 2) el salto a Vista 64 bits.

¿Cómo ves el tema de portar en un futuro la aplicación a 64 bits?
Con Wxwidgets y con nuestro paso a C++ no debería de ser un problema muy grande.
El problema real creo que es el código de Coffin y el código de C si no se han utilizado una definición de tipos y se han empleado los int y long tradicionales que en 64 bits cambian de tamaño.

¿Cómo se plantea eso Coffin? ¿Sabéis si está haciendo algún movimiento en la dirección de portar dcraw a 64 bits?

Me llama la atención que haya Photoshopy y Lightroom de 64 bits.
Si como he leido en alguno ocasión, Adobe también hace uso del código de DCRAW, algo tiene que haber por parte de Coffin, aunque no lo haya implementado en DCraw.

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

Bueno la solución al problema es simple: usar el código de Coffin en 32 bits para obtener el raw, y luego revelarlo en nuestro propio motor de revelado en 64 bits. Como es el camino por el que vamos no habrá problema en pasar a 64 bits cuando llegue el momento. Además, el problema fundamental que es la memoria estará solucionado desde ya y también beneficiará al motor siguiente (aunque cuando pasemos a C++ reharé toda la gestión de memoria orientándola a objetos y será aún más cómoda de usar). Para leer del disco el RAW y decodificarlo 32 bits son suficientes y para un sólo buffer la memoria de 2 Gb también. El problema viene luego, cuando empiezas a hacer cosas con ese buffer y a copiarlo, etc. Entiendo que es lo mismo que hacen ya PS y LR en 64 bits porque el código de Coffin en algunos puntos no es portable a 64 bits sin grandes modificaciones y dudo mucho que Coffin, con su admirable sentido pragmático, vaya a cambiar algo que no es necesario cambiar.

De todos modos, desconozco el tema, ¿los Linux corren en 64 bits? ¿Hay versiones de 32 y de 64 bits? ¿Y los MacOSs?

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Nunca lo he tenido más claro. A mí me gusta mucho programar, pero prefiero hacerlo sin presión. Pregúntale a Egon.

En mi trabajo anterior programaba cada vez menos, hacía trabajo de consultoría en programación, dirección de proyectos y gestión de equipos. Cada vez iba a hacer más trabajo de eso y menos de programación, que es lo que más me gusta.

En cualquier caso mi experiencia programando tiene grandes lagunas, que poco a poco se van cubriendo con marrones como el de este fin de semana.

Respecto a la admiración te lo agradezco profundamente, especialmente viniendo de ti, que eres una referencia para todos los que estamos en este foro. Aunque bajando al nivel más metafísico, considero (y/o me esfuerzo pro considerar) que cuando programo (y en cualquier otra cosa que requiera un esfuerzo intelectual) soy sólo un vehículo a través del cual se manifiesta la inteligencia universal y colectiva, a la que algunos llamamos Dios; así que el mérito mío no es mayor que el de un receptor de radio que sintoniza una emisora concreta.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Sí, la cosa se va animando. Supongo que cuando Egon suba el nuevo interfaz habrá una auténtica explosión de entradas.

Te alegrará saber que Emil ya nos ha pasado su código a Paul Lee y a mí y que Paul lleva implementado, yo diría que el 50% del algoritmo. Yo ni he tenido tiempo de mirarlo, ese tío es una máquina. Respecto a los resultados preliminares tendrá que ser el propio Emil el que decida cuándo dar publicidad a su algoritmo. Demasiado estamos comentando ya sobre el tema, me parece a mí.

Los ha superado en el caso concreto de la imagen de los pilares que es la principal motivación de Paul para es tema (puedes ver las imágenes en su web). El algoritmo de Emil los saca 100% perfectos, mucho mejor que RawTherapee (la imagen de los pilares viene muy bien comparada en la página de RT).

La idea era que en la versión final el usuario pueda configurar los parámetros por defecto . En cuanto a las mezclas de algoritmos, una buena posibilidad es usar mi algoritmo de detección de zonas complicadas (descrito arriba), que es preciso y rápido, y usar AFD/VCD fuera de ellas y AHD dentro. Es una prueba que tengo que probar. Te adelanto que funcionará perfecto en imágenes sin ruido (aunque será lento por tener que interpolar dos veces), pero no irá nada bien en imágenes con ruido porque tomará píxeles ruidosos interpolados por AHD. En cualquier caso AHD con ruido no solo interpreta mal el ruido, es que además se despista de la dirección de interpolación correcta.

No creo que estés tan lejos .

No lo creo. Pero es divertido intentarlo.

El problema es con los buffers, pero creo que lo que comento arriba lo solucionará definitivamente (si mi diagnóstico es correcto, seguro que sí).

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Coffin evaluará si a él le afecta lo de los 64 bits. Si con su Linux y su lenguaje C-offin sigue pudiendo decodificar los archivos RAW del futuro, ten por seguro que el problema de adaptar las cosas a 64 bits será del resto de los mortales. Es un tío al que le importa un pimiento el 99% de lo que le cuentan (no por orgullo o vanidad, sino porque de manera sincera lo evalúa y lo considera uninteresting).
Mi opinión personal es que cada mes hay un tío de Adobe que le echa "algo" en el botón de Donate. En realidad para ellos es un chollo, se cubren las espaldas con un consultor experto del que pueden echar mano en un momento dado si se les atranca algún formato RAW. Pero Coffin no se va a adaptar al resto del mundo, es al revés.

__________________

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

Lo triste es que el mérito de un programador está muy por encima de lo que la mayoría de la gente se piensa. La de discusiones que he tenido en el trabajo con "genios" del marketing que desprecian todo lo que venga de un informático sentado frente a un PC ("pobrecito, no vale para otra cosa" dejaban entrever). Las discusiones acabaron cuando empecé a trabajar codo con codo con ellos en el departamento de marketing, y me di cuenta de que su desprecio no era sino una coraza para protegerse de algo que son conscientes está totalmente fuera de su alcance intelectual.
Desde ese momento dejé de discutir y les dejé vivir en su mundo feliz, aunque no por ello me dejó de parecer injusta la valoración que se hace en la empresa del que pica código respecto del que idea un nuevo producto (generalmente réplica con precio a la baja del que ya tiene la competencia).
Pocos Steve Jobs hay en el mundo me parece a mí, y encima se va a morir.

__________________

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

No creas, Manuel, no creo que sea tan simple la solución: una aplicación de 64 bits no puede ni siquiera cargar otra librería de 32 bits (en modo kernel creo que sí, porque sino no funcionarían los programas de 32 bits en windows 64).
Así pues, si la librería de Coffin se compila como de 32 bits no se podrá llamar desde PerfectRaw compilado como de 64 bits.
La solución pasa necesariamente entonces por dos caminos:
-Recompilar dcraw como de 64 bits. Difícil como dices, porque el código de Coffin está bastante liado y usa ints a tutiplen.
-Utilizar dcraw como un ejecutable externo compilado a 32 bits y obtener el resultado a través de una pipe en memoria. Viable y fácil de hacer, pero muy lento en comparación con lo actual. Además consumirá mucha más memoria.

Por supuesto está la alternativa actual de compilar todo en 32 bits, pero eso tiene fecha de caducidad, porque a corto/medio plazo, todos tendremos que migrar a Vista 64 queramos o no, pues los ordenadores van a traer cada vez más memoria y las aplicaciones requerir cada vez más, por lo que el límite de 4GB para el sistema operativo y de 2GB para cada aplicación se va a quedar corto.

Por supuesto algún quedan algunas versiones de PerfectRaw por sacar hasta entonces, no será inmediato.

Sí que deberíamos tener cuidado (para facilitar el port a 64 bits) en las declaraciones de variables y no usar ints o longs sino int16, int32 o lo que corresponda en cada caso.

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

En Linux el problema del límite de memoria es más o menos el mismo que en Windows.
La limitación de 4GB de direccionamiento de memoria es a nivel de procesador e intrínseca a los 32 bits, no algo de Microsoft.
Lo que sí que es posible es que en Linux cada aplicación tenga disponibles más de 2GB de memoria, porque el límite de 2GB (en vez de 4GB) disponible para las aplicaciones está relacionado con el modelo de drivers de dispositivo de Windows y la compatibilidad con las aplicaciones MSDOS que escribían directamente en la tarjeta gráfica y demás, en vez de utilizar funciones del sistema operativo.

Coffin a la larga también se verá afectado por el problema, lo que pasa es que va a tardar más que nosotros en encontrarse con las limitaciones, porque dcraw usa menos memoria y porque en linux posiblemente tenga más memoria disponible para la aplicación.

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

Que razón tienes, en el mundo actual un vendedor de coches se encuentra con derecho a ganar un montón de dinero y más que un investigador o un profesional con muchos años de dedicación.

La idea es que sólo produce y es importante el que se dedica a ventas, marketing o "producción" que es lo "difícil" y "productivo".

El que diseña las cosas y el que se devana los sesos para dar solución a los problemas de diseño o funcionamiento ( o el programador con sus profundos conocimientos de muchos aspectos de la informática) es un pobrecito que no sabe hacer otra cosa, y por eso es lógico que gane menos.

Qué le vamos a hacer, estamos en un mundo donde sólo cuenta el dinero y la ganancia inmediata.

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

Solo a titulo de curiosidad, bajado el ultimo 0.65 y probado en windows 7 beta, funciona correctamente.
Un saludo.
Junenago.

pues si hablamos de futbolistas, cantantes, etc.. y encima esta la sgae, esa, por mucho pirateo que dicen que hay todos tienen chorrocientos deportivos, mansiones, incluso aviones, barcos, vamos que no malviven con 800e.

Nosotros si valoramos y admiramos vuestro trabajo. Saludos

Ah, estupendo, me alegro de que el nuevo algoritmo esté ya terminado (si prefieres editamos los mensajes).

El problema de VCD quizá sea una buena fase de refinado o la combinación con otro algoritmo por zonas. Funciona muy bien en casi todo pero crea zipper effects en líneas finas. Para probar a ISOs bajos siempre uso la misma imagen, bastante exigente, en la que hay un edificio con diagonales a tutiplén y hojas de pino de uno o dos píxeles de grosor y algunos fallos de VCD se ven incluso al visualizar al 50%.

Manuel, ¿cómo puedo hacer para que dcraw añada la línea de revelado en el EXIF, pongamos en las secciones "software" o "comments"? No consigo recuperarla entera sin tener que parsearla y cargarla en arrays globales (y ni aún así me funciona siempre), y me interesaba por ser una especie de equivalente de los archivo sidecar de ACR y otros reveladores. Seguro que es algo muy básico pero se me escapa.

¿No habías hecho ya una prueba parecida con AFD/AHD hace tiempo? En su web Emil mencionaba por ahí acerca de un AFD/AHD/VCD o algo parecido. Podría funcionar muy bien, aunque a mí AFD ya me parezca la caña él solito.

Perdona que estos días entre poco al foro y tarde en responder, pero necesitaba echar el freno porque también me quitaba bastante tiempo y necesito dormir algo.

Un saludo.

Es una buena noticia, una preocupación menos. Muchas gracias junenago.

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

En realidad Emil lo sigue ajustando, pero serán pequeños cambios que también podrán migrarse a la versión C. Ahora lo más importante es ver cuánto de rápida es esa implementación... cruzaremos los dedos.

Sí, a AFD le pasa algo parecido porque usan la segunda derivada para detectar la dirección de interpolación. Tiene difícil solución sin modificar profundamente el algoritmo, aunque podría usarse la segunda en zonas fáciles y la primera en zonas difíciles + algo que unifique la dirección de interpolación dentro de zonas difíciles contiguas.

No entiendo la pregunta. ¿Qué quieres decir con 'la línea de revelado en el EXIF'? ¿Los parámetros con los que se ha llamado a dcraw, no? ¿Lo que tú quieres es sacar la cadena args entera en vez de en un array?

Si es eso tendrás primero que sumar el tamaño de todo el array, luego reservar memoria dinámica de ese tamaño, y por último copiar cada trocito dentro del nuevo array metiendo un espacio. Algo así en ANSI-C (no lo he probado):

Sí, aunque lo ideal es un método perfecto desde el principio. Pero es una línea de investigación interesante como paso previo a crear un nuevo algoritmo desde cero.

Pues yo ni te cuento, ¡que te voy a perdonar?

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Que sea rápido siempre es lo deseable, pero el objetivo principal en este caso es conseguir un revelado casi perfecto, aunque sea lento como una patata...

¿Coffin está al tanto de todos estos avances? Sé que por sistema no hace ni caso, pero hay algunas cosas, como tu equilibrado de verdes, que creo que son fundamentales en dcraw. Ésa en particular es casi el equivalente al revelado aparte de los foveon o de las Fuji.

Yo lo más complejo que he conseguido hacer con algo de sentido fue una raíz cuadrada. Con AFD también pasa, pero apenas se nota en comparción. A ver si más tarde puedo subir un recorte de la imagen.

Exactamente eso, ¡muchas gracias! Es algo que echaba mucho de menos. Luego lo pruebo y te comento si funciona.

Como siempre respondes con todo lujo de detalles considero que lo mínimo es agradecértelo, aunque sea dos días después, y no dejar que caiga en saco roto.

¡Un saludo!

Yo más bien creo que la idea (y me temo que es cierta) es que es más fácil vender un mal producto con mucho marketing que uno bueno con poco, de ahí que se valore más al comercial que al técnico. Además, el talento para vender es más fácil de encontrar que el talento para crear... como empresario está claro qué inversión es más productiva, ¿no? (al menos mirado superficialmente). Además las personas con verdadero talento para crear funcionan por fases y necesitan tiempo, ambas cosas que no se quiere permitir un empresario.

Por otro lado, en el mercado actual todo cambia tan rápido que para cuando el cliente se da cuenta de que el producto que le vendiste es peor que el de la competencia, tú ya has hundido a la competencia para que tu producto sea el único (mira cómo Adobe compró la única competencia que creía tener LR), o has puesto una novedad (igual de mala por supuesto que la anterior) en el mercado. La volatilidad del mercado beneficia al marketing frente a la calidad del producto.

Las pocas compañías en este mercado que aúnan un buen producto con un buen marketing son las que se llevan el gato al agua de manera perdurable y obligan a las malas compañías a mantener un producto decente, limpiando el mercado de basura.

Desgraciadamente, en este mundo apenas queda espacio para la artesanía, salvo como alternativa de consumo y gratis o a precios bajos. Ese es nuestro actual nicho en el mercado de los reveladores, qué duda cabe que perfectRAW es un producto manufacturado artesanalmente .

Un saludo:

__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Manuel, he añadido la línea, definiendo command_line y pos (que he renombrado como pos_cl por existir ya) como globales para recuperar su contenido en la función que escribe el EXIF y cambiando "args" por "argv", que es como lo tiene puesto Coffin, y lo que obtengo es esto:

Cuando debería ser así:

¿Alguna idea de por qué sucede? El número de opciones las cuenta bien (son 16) pero escribe sólo la mitad añadiéndoles caracteres que no tengo ni idea de dónde salen.

No te comas mucho la cabeza si te quita tiempo, podré vivir sin ello.

Subo las imágenes que decía antes por separado en png, que el gif se cargaba el detalle por completo. Están al 300% y VCD es la versión 47:







AFD para mi gusto es el mejor. Es posible que AHD consiga mejor luminancia, pero tiene artefactos de color en la barandilla y confunde la dirección de las hojas. VCD no sale muy bien parado en nada.

Un saludo.