Tema: Desarrollo de un GUI (Interface Gráfica) para DCRAW

Hola, estoy siguiendo el hilo con interés pero medio a trancas y barrancas y leyendo en diagonal por falta de tiempo y recursos mentales (uno que se va haciendo viejo :-)

Se me ocurren un par de comentario-sugerencias por lo que llevo leido, espero no estar meando fuera de tiesto:

- GDIPlus lento al pintar en pantalla. Es bastante cabrito en el sentido que toma decisiones por si mismo, por ejemplo si las zonas a copiar son de tamaños distintos -aunque sea un solo píxel de alto o ancho ya empieza a aplicar reescalados lentos que como no hayas inicializado con alguna llamada previa para establecer el tipo de interpolación aun son mas lentos.

De código que pinta en pantalla en plan quasi instantáneo con gdiplus:

graph.DrawImage(bmpFrom,xd,yd,rFrom.X(),rFrom.Y(), rFrom.SX(),rFrom.SY(),UnitPixel);

Pero asegurando antes que el bmpFrom tiene el mismo tamaño que el rFrom. El parámetro UnitPixel también es importante.

Innecesario pero como precaución antes del DrawImage.
graph.SetInterpolationMode(InterpolationModeNeares tNeighbor)

También un aspecto que puede sobrecargar el gdiplus es que los graphics origin y destino esten en formatos distintos (pantalla en 16 bits bmp 24bits etc).

Habria que probarlo pero seguramente si los tamaños son multiplos uno de otro y en modo NearestNeighbor sea igual o suficientemente rápido.

Dicho esto, quizá la buena es usar la librería mas cómoda y rápida (el viejo GDI?) pero con algo de cuidado en encapsularla para que sea fácil luego portarla a otros SOs . (Estoy pensando en algo así como una funcion PintarBitmapAPantalla(...) entre unos #ifdef PARAWINDOWS
BitBlt()
#elif PARAUNIX
LoQueToque()
Etc

Pues, eso, por si sirve de algo.
Saludos, ánimos y felicidades por la iniciativa.

Manuel:
bueno entonces lo entendí bien, solo que yo llamo imagen a lo que tú llamas vista, y llamaba crop a lo que tú llamas imagen. para mí el término imagen es el dato original, no lo que "va a salir por la pantalla". sí ya sé que soy muy retorcido.

truji (bienvenido, ya tardabas en aparecer a cacharrear jeje):
cómo recomendarías hacer la salida gráfica para que sea de verdad lo más rápida posible tanto en las llamadas a librería como en el display?
aunque me da que el cuello de botella van a ser los cálculos.

Gracias por tu aportación, truji.

Lo del g.DrawImage es lo que hacía antes y con imágenes grandes va muy muy lento, especialmente como tú dices si el formato de píxel no es el mismo, pero no sólo en ese caso. Además, su interpolación NN no es demasiado exacta, o eso me parecía a mí.

La idea es meter BitBlt cuando tenga un rato y encapsularlo de modo que pueda cambiarse por OpenGL, DirectX, o GDI+ según el caso. De momento, lo bueno de lo que he hecho es que es portable, tan rápido como es posible sin tirar de hardware específico y tenemos todo el control.

Un saludo:
_________________________________

Iniciado por _GUI_

Manuel:
bueno entonces lo entendí bien, solo que yo llamo imagen a lo que tú llamas vista, y llamaba crop a lo que tú llamas imagen. para mí el término imagen es el dato original, no lo que "va a salir por la pantalla". sí ya sé que soy muy retorcido.

Pero si eso es justo lo que yo digo

Imagen es la imagen original (buffer2) y vista es lo que sale por la pantalla (buffer).

¿Te funciona la prueba que he subido? ¿Va decentemente rápido?

Un saludo:

Iniciado por ManuelLlorens

Imagen es la imagen original (buffer2) y vista es lo que sale por la pantalla (buffer).

¿Te funciona la prueba que he subido? ¿Va decentemente rápido?

memcpy(buffer,buffer2+x,w);


ah pero entonces memcpy copia buffer 2 en buffer? pensé que era al revés, que por otro lado parece lo lógico no?

Cuando me expliqueis en qué y cómo tengo que compilar las pruebas que estáis haciendo te lo digo, yo ya me perdí hace tiempo entre el gcc, el VS del otro y el DEV C++

Iniciado por _GUI_

memcpy(buffer,buffer2+x,w);
ah pero entonces memcpy copia buffer 2 en buffer? pensé que era al revés, que por otro lado parece lo lógico no?

Eso mismo.

Iniciado por _GUI_

Cuando me expliqueis en qué y cómo tengo que compilar las pruebas que estáis haciendo te lo digo, yo ya me perdí hace tiempo entre el gcc, el VS del otro y el DEV C++

Lo que he subido es un ejecutable, ¡cacho vago!

Un saludo:
_________________________________

Iniciado por _GUI_

aunque me da que el cuello de botella van a ser los cálculos.

¡Qué va! no es porque los haya hecho yo, es que los cálculos son muy rápidos. Mira (tiempo de cálculo de 1000 iteraciones y un solo volcado a pantalla al final):

Partiendo de una imagen 2956x2504:

1000 fotogramas 644x782 zoom x8 -> aprox. 4 s = 250 fps
1000 fotogramas 644x782 zoom x4 -> aprox. 6 s = 170 fps
1000 fotogramas 644x782 zoom x2 -> aprox. 8 s = 125 fps
1000 fotogramas 644x782 zoom x1 -> aprox. 4 s = 250 fps
1000 fotogramas 644x782 zoom x1/2 -> aprox. 12 s = 83 fps
1000 fotogramas 644x782 zoom x1/4 -> aprox. 10 s = 100 fps
1000 fotogramas 644x782 zoom x1/8 -> aprox. 4,5 s = 222 fps
1000 fotogramas 644x782 zoom x1/16 -> aprox. 2,4 s = 420 fps
1000 fotogramas 644x782 zoom x1/32 -> aprox. 2 s = 500 fps

Como ves, el cálculo no es el cuello de botella. A las velocidades más lentas debería ir como un tiro, pues nunca baja de 83 fps. A pantalla completa en una máquina lenta dará algunos tirones, pero nada más.

Está claro además que la velocidad más lenta es x1/2, así que si la máquina es lenta habrá que trabajar poco con ese zoom. En máquinas lentísimas se pueden evitar también el x2 y el x1/4. Todo lo demás debería ir muy rápido. Como curiosidad, la máquina de mi trabajo va justo la mitad de rápida que la de casa, lo digo para que veáis que depende mucho del procesador de cada uno. Los que tengáis máquinas rápidas deberíais notar muy fluida la prueba que he subido.

Es posible que pueda optimizar con código específico los zooms x2 y x1/2. Tendré que pensar en ello. La historia que conté más arriba sobre usar punteros tipo int no vale porque no había tenido en cuenta que cada píxel ocupar tres bytes (BGR), pero es posible que haya un modo de optimizarlo más. Lo pensaré. ¿Alguna idea? Podéis ver el código más arriba.

Un saludo:
_________________________________
Para ariznaf:

Iniciado por ariznaf

Ahora he compilado el código para x86 y la librería la carga. En windows XP me funciona, pero en Vista 64 se la pega cuando accede al GetInfo dando un error de acceso a memoria protegida (Access Violation).

¿Con la misma imagen? Eso sí que es raro... de todos modos hasta que no depure bien bien la DLL de dcraw seguirán pasando cosas raras. A ver si la conseguimos compilar con VC++ para depurarla paso a paso. Como ya te dije hice una prueba llamando al main de Coffin directamente desde C# en vez de a mis funciones de la DLL y así no falla... así que es algo que he omitido y es importante. El caso es que no lo veo y sin depurar no hay forma.

Por cierto, no consigo que una DLL hecha en VC++ tire en C#, no encuentra los puntos de entrada a pesar de que están bien definidos en el .h, igual que hago con DEV-C++, ¿tú hiciste pruebas en ese sentido? Díme si la respuesta es sí y te paso el código de la DLL para las vistas que he hecho a ver si la puedes recompilar en VC++ y que tire desde C#, así la depuramos más cómodo, porque ahora me vuelvo un poco loco... intentaré crear un proyecto de prueba en C y depurar con DEV-C++, porque tiene pequeños fallos en los bordes de la imagen, pero yo no los veo mirando el código. Claro que la terminé de poner a punto ayer a las 2:30 y lo normal es que ya no viera nada .

Un saludo:

bueno va perfecto, como un misil. el visualizador de imágenes de Vista funciona exactamente así, zoom con la rueda, movernos por la imagen sin sliders, solo haciendo click+arrastrar, y tiene lo que comentas de hacer zoom relativo a la posición del cursor (es decir el pixel que hay bajo el cursor no altera su posición).

estaba pensando en las casuísticas que pueden darse en los modos de vistas partidas:

1. Imagen replicada: ambas vistas representan la misma porción con el mismo zoom de la imagen, solo que cada una viene de una imagen (revelado) diferente. Es el modo más fácil de implementar.
2. Imagen continua: mitad procedente de una imagen, la otra mitad de la otra, pero la imagen se ve como un todo (mi primer ejemplo del hipo).

____________

En 1 el arrastre del ratón se iniciaría en una de las dos vistas, y el efecto aplicaría a las dos (es decir, la vista sobre la que no se hizo click sigue a la otra en tiempo real). La forma de establecer los límites sería la que tienes implementada ahora mismo, una vez un borde de la imagen se ajusta a un borde del picturebox ya no sigue el desplazamiento. La otra vista se plotea en consecuencia.


El modo 2 es a mi juicio más puñetero. Entiendo que estás usando dos pixctureboxes, así que asumimos que la frontera entre vistas será fija (división vertical u horizontal en el punto medio de la zona de visualización, dos pictureboxes de las mismas dimensiones a izq./der. o arriba/abajo):

- Con grados de zoom pequeños (1/4, 1/8...) que no den para llenar los pictureboxes en el eje perpendicular al plano de división (esto suena más complicado de lo que representa, sería el eje X si usamos vistas IZQ/DER), no tendría sentido que deje de haber siempre una porción de la imagen en ambas vistas. De hecho lo lógico y sencillo en estos casos es forzar el centrado de la imagen en el eje de división. En el eje Y el comportamiento sería el habitual del modo 1 (se podrán arrastrar las vistas si hay porción de imagen suficiente sobre la que desplazarse, o se fijarán centradas como en el modo 1):

- Con grados de zoom mayores a 1x, se me plantea qué pasa si el usuario tiene ajustada la ventana del programa a un tamaño tal que los pictureboxes no resulten en unas dimensiones en píxels múltiplo del grado de zoom elegido. Por ejemplo, si estamos en 4x, cada píxel real de la imagen necesitará 4 pixels del picturebox para representarse. Si éste no tuviera un tamaño múltiplo de 4 sería imposible hacer casar correctamente la frontera de las vistas. Aunque bueno solo sería una fila o columna de píxels, ahora que lo pienso es asumible.

Ha mi me parece que va perfecto, el zoom es muy rapido y el movimiento es muy suave y rapido.

¿Afectara mucho a la velovidad cuando estemos con ficheros reales mucho mas grandes ?

Iniciado por ManuelLlorens

¡Qué va! no es porque los haya hecho yo, es que los cálculos son muy rápidos. Mira (tiempo de cálculo de 1000 iteraciones y un solo volcado a pantalla al final):

No no, si la parte de display ya veo que va como un misil; ya te comenté que el NN hasta el VB se hace rapidísimo.
Me refería al revelado DCRAW; el refresco de los buffers cuando cambiemos las opciones de revelado estará en otro orden de magnitud en cuanto a tiempo de cálculo que el display, así que por el lado gráfico (arrastre en t. real, zoom, modos de vistas,...) no veo problema de potencia de proceso.

Éste sería el problemilla en zooms mayores a 1x con modo de pantalla partida pero imagen única:

Estoy pensando que se solucionaría forzando que los pictureboxes sean siempre de un tamaño múltiplo entero del grado de zoom elegido. La diferencia máxima de tamaño respecto al picturebox ideal sería de 7px en modo 8x, y solo aplicaría:

<con los zooms 2x, 4x, 8x> AND <modo vista partida con imagen continua>

Evalúa si vale la pena la complicación de particularizar el código para evitar ese pequeño extraño.

Iniciado por _GUI_

Con grados de zoom mayores a 1x, se me plantea qué pasa si el usuario tiene ajustada la ventana del programa a un tamaño tal que los pictureboxes no resulten en unas dimensiones en píxels múltiplo del grado de zoom elegido. Por ejemplo, si estamos en 4x, cada píxel real de la imagen necesitará 4 pixels del picturebox para representarse. Si éste no tuviera un tamaño múltiplo de 4 sería imposible hacer casar correctamente la frontera de las vistas. Aunque bueno solo sería una fila o columna de píxels, ahora que lo pienso es asumible.

Dado que los factores de zoom son fijos, podemos hacer que la vista de la izquierda siempre tenga un ancho múltiplo de 8, independientemente de que la vista de la derecha sea un poco más pequeña. Ahora, si el ancho es impar la de la derecha ya es un píxel menor que la de la izquierda. No creo que se note mucho y nos evitamos hacer cálculos complicados.

¡Ah!, y en la versión 1.0 sólo se podrá dividir la pantalla en vertical.

Voy a dedicarme ahora depurar fallos (los de dcraw.dll y también los de ésta última DLL) y cuando todo lo que tengo separado funcione al 100% lo junto (prefiero no juntar cosas que dan fallos). Con eso creo que tenemos el 50% del revelador. Luego le pondré los parámetros usando controles por defecto, y tendremos el 75%. Luego lo ponemos bonito, ponemos la salida, los histogramas, la exposición y el balance de blanco desde temperaturas de color y... ¡listo! Versión 1.0 acabada.

Un saludo:

Iniciado por ManuelLlorens

Dado que los factores de zoom son fijos, podemos hacer que la vista de la izquierda siempre tenga un ancho múltiplo de 8, independientemente de que la vista de la derecha sea un poco más pequeña. Ahora, si el ancho es impar la de la derecha ya es un píxel menor que la de la izquierda. No creo que se note mucho y nos evitamos hacer cálculos complicados.

vaya me he cruzado contigo jeje. lo del impar no lo he entendido, pero no crees que es mejor que las dos vistas sean siempre simétricas en tamaño?
yo creo que forzar que los picturebox (ambos) sean siempre de un tamaño múltiplo entero al zoom elegido no debería ser complicado. Se podría incluso aplicar a la vista general de la imagen, es decir no solo en el modo de vistas partidas, así nunca saldrían píxels "cortados".

Lo de la división arriba/abajo una lástima (puede ser muy útil en imágenes con un patrón de variación dispuesto de izq. a der., por ejemplo un edificio con cielo a un lado donde queremos balancear el edificio y el cielo). Cuela? sino para la próxima

Yo también he probado la aplicación y la veo bastante aceptable de velocidad.

Iniciado por _GUI_

yo creo que forzar que los picturebox (ambos) sean siempre de un tamaño múltiplo entero al zoom elegido no debería ser complicado. Se podría incluso aplicar a la vista general de la imagen, es decir no solo en el modo de vistas partidas, así nunca saldrían píxels "cortados".

Si el ancho total de la ventana es de 101 píxeles, y queremos dividir eso entre dos vistas, una tiene que ser de 51 y la otra de 50, no queda más remedio. O eso, o dejas un píxel vacío en un lado (poco estético), o lo dejas vacío en medio (poco funcional), o, y esa es una posibilidad a tener en cuenta, sólo permitimos tamaños de ancho de ventana múltiplos de 8. Las resoluciones típicas son todas múltiplo de 8 si no me equivoco: 640, 800, 1024, 1280, 1600... Lo malo es que el ancho real disponible dentro de la aplicación no depende directamente de la resolución de la pantalla, sino también del tema aplicado al SO. Pero podemos, cuando se redimiensione la ventana, volver a dimensionarla nosotros a un tamaño que nos interese más. Quedará un poco raro no poder nunca maximizarla y que ella decida por sí misma que no le gusta el tamaño que la hemos dado, pero...

De todos modos, a mí no me molesta mucho lo de los píxeles cortados y para la vista partida, en la que podía notarse algo raro, ya tengo una solución. Es mucho más fácil (y elegante, como todas las buenas soluciones) de lo qué estábamos pensando. Lo que hay que hacer es crear un nuevo Bitmap sin escalar con media imagen de cada una de las imágenes originales. Luego se pone el modo de una sola imagen y se vuelca ese nuevo Bitmap escalado con la funciones que ya tenemos. Con eso lo solucionas sin ninguna complicación extra y nunca apacerán píxeles cortados ni líneas duplicadas en la zona de empalme. El sacrificio es un poco de memoria, pero no vamos a ser rácanos con eso.

Iniciado por _GUI_

Lo de la división arriba/abajo una lástima (puede ser muy útil en imágenes con un patrón de variación dispuesto de izq. a der., por ejemplo un edificio con cielo a un lado donde queremos balancear el edificio y el cielo). Cuela? sino para la próxima

Siempre puedes girar las imágenes 90º y luego torcer la cabeza . Tú lo que quieres es picarme... pues no lo vas a conseguir .

Bueno... está bien... lo haremos... en realidad solo hay que cambiar una función, la que empalma las dos medias imágenes para la vista partida, lo demás funciona exáctamente igual, así que lo haremos. Cuando esté limpito y encapsulado el código te lo pasaré para que lo hagas ... tienes que practicar con C#.

Un saludo:
_________________________________

Iniciado por vertex

Yo también he probado la aplicación y la veo bastante aceptable de velocidad.

Yo creo que añadiendo OpenGL/BitBlt/DirectX irá realmente bien.

Si he entendido bien, en este ejecutable sólo se trata de probar el scroll y el zoom. Si es así, en mi cacharro va como un tiro. Ánimo a todos.

Iniciado por Eduardo Cañadas

Ha mi me parece que va perfecto, el zoom es muy rapido y el movimiento es muy suave y rapido.

¿Afectara mucho a la velovidad cuando estemos con ficheros reales mucho mas grandes ?

Prácticamente nada, aunque consumirá más memoria y si llega al límite de la memoria física empezará a rascar, como todos sabemos. Lo que limita la velocidad es el tamaño de las vistas, en resoluciones muy altas será mejor no maximizar la apliación.

¿Alguien lo ha podido probar a 1600 de ancho o más? ¿Es usable? Ya sabéis que la velocidad más lenta es con zoom x1/2.

Un saludo:
_________________________________

Iniciado por Carcamal

Si he entendido bien, en este ejecutable sólo se trata de probar el scroll y el zoom. Si es así, en mi cacharro va como un tiro. Ánimo a todos.

Ahí esta... también sirve para crear expectación sobre la versión final . Por cierto, ¿en qué resolución lo has probado?

Un saludo:

Iniciado por ManuelLlorens

Es mucho más fácil (y elegante, como todas las buenas soluciones) de lo qué estábamos pensando. Lo que hay que hacer es crear un nuevo Bitmap sin escalar con media imagen de cada una de las imágenes originales. Luego se pone el modo de una sola imagen y se vuelca ese nuevo Bitmap escalado con la funciones que ya tenemos. Con eso lo solucionas sin ninguna complicación extra y nunca apacerán píxeles cortados ni líneas duplicadas en la zona de empalme. El sacrificio es un poco de memoria, pero no vamos a ser rácanos con eso.

genial, así el modo de trabajo normal (única vista) y el modo partido pero con imagen continua tendrán la misma filosofía de volcado al display y usarán la misma rutina. solo tienes que gestionar correctamente (en función de la porción de imagen total a visualizar) la frontera que definirá lo que se toma de un buffer o del otro.
y en modo partido con imágenes replicadas no nos afecta el problema.

Iniciado por ManuelLlorens

Siempre puedes girar las imágenes 90º y luego torcer la cabeza . Tú lo que quieres es picarme... pues no lo vas a conseguir .

Bueno... está bien... lo haremos... en realidad solo hay que cambiar una función

ya sabía yo que caías... si hecho izq./der., replicarlo arr./abajo es cuestión de donde decía X en tus rutinas poner Y y viceversa

Tienes que ir diciéndome qué tengo que instalarme exactamente para poder compilar lo que estás haciendo, si te soy sincero no sé ahora mismo con qué estás compilando los GUIs que subes. Son proyectos no de consola del DEV C++?

Iniciado por ManuelLlorens

Yo creo que añadiendo OpenGL/BitBlt/DirectX irá realmente bien.

El GUI tal cual está va como un tiro en mi portátil con Vista; como ya te decía está en otro orden de magnitud respecto al retardo que introducirá el refresco del revelado RAW, así que salvo que hacer lo del OpenGL... no suponga esfuerzo, pondría foco en seguir adelante.
Voy a empezar a dar la lata en Luminous con la curva de Planck para el balance de blancos, a ver si ésta se la saben. Te importa que les linke el ejecutable que llevas hecho para dar credibilidad a la cuestión?

Iniciado por _GUI_

genial, así el modo de trabajo normal (única vista) y el modo partido pero con imagen continua tendrán la misma filosofía de volcado al display y usarán la misma rutina. solo tienes que gestionar correctamente (en función de la porción de imagen total a visualizar) la frontera que definirá lo que se toma de un buffer o del otro.
y en modo partido con imágenes replicadas no nos afecta el problema.

Hmmmm... no era lo que yo estaba pensando... yo decía una imagen partida por la mitad, siempre por la misma mitad, e ir moviéndote por ella como tú quisieras, pero si te vas a la izquierda de la mitad solo ves un revelado y no el otro... eso era lo más sencillo.

Para que estés en la zona que estés de la imagen e independientemente del zoom se vea un lado y otro, hay que modificar la rutina de interpolación para recibir no dos, sino tres buffers y que coja mitad y mitad de cada línea. Eso también lo había pensado, pero lo había descartado por no ralentizar. Pero se hará así, no creo que ralentice mucho.

Iniciado por _GUI_

ya sabía yo que caías... si hecho izq./der., replicarlo arr./abajo es cuestión de donde decía X en tus rutinas poner Y y viceversa

No, si lo vas a hacer tú .

Iniciado por _GUI_

Tienes que ir diciéndome qué tengo que instalarme exactamente para poder compilar lo que estás haciendo, si te soy sincero no sé ahora mismo con qué estás compilando los GUIs que subes. Son proyectos no de consola del DEV C++?

El test que he subido lleva una DLL hecha en C con DEV-C++ y un ejecutable hecho en C# con VS2005. Tienes que bajarte e instalar DEV-C++ con MinGW, para hacerlo funcionar en Vista tienes que hacer algo a mano, está explicado en el foro de compilación. También tienes que instalar Visual Studio 2005 (si no lo tienes hay una versión gratuita) con C# y C++; del Visual Basic .NET es mejor que te olvides. Y nada más, de momento.

Un saludo:
_________________________________

Iniciado por _GUI_

El GUI tal cual está va como un tiro en mi portátil con Vista; como ya te decía está en otro orden de magnitud respecto al retardo que introducirá el refresco del revelado RAW, así que salvo que hacer lo del OpenGL... no suponga esfuerzo, pondría foco en seguir adelante.

Desde luego. Primero voy a consolidar lo que llevamos hecho reparando los bugs que ya sabemos que tiene y luego a tirar millas. En cuanto junte lo de hoy con el revelado y meta los parámetro en plan controles por defecto el proyecto tendrá pinta de algo útil (aún feo, pero útil).

Iniciado por _GUI_

Voy a empezar a dar la lata en Luminous con la curva de Planck para el balance de blancos, a ver si ésta se la saben. Te importa que les linke el ejecutable que llevas hecho para dar credibilidad a la cuestión?

Vale, estuve mirando cosas pero no avancé. ¿Cómo llevas lo de la exposición? Eso está en lista como lo próximo. Por mí puedes subir lo que tú quieras no es que sea gran cosa...

Un saludo:

Iniciado por ManuelLlorens

Hmmmm... no era lo que yo estaba pensando... yo decía una imagen partida por la mitad, siempre por la misma mitad, e ir moviéndote por ella como tú quisieras, pero si te vas a la izquierda de la mitad solo ves un revelado y no el otro... eso era lo más sencillo.

Para que estés en la zona que estés de la imagen e independientemente del zoom se vea un lado y otro, hay que modificar la rutina de interpolación para recibir no dos, sino tres buffers y que coja mitad y mitad de cada línea. Eso también lo había pensado, pero lo había descartado por no ralentizar. Pero se hará así, no creo que ralentice mucho.

Yo no veo que tenga que ralentizar, pensaba que ibas a añadir para ese modo de pantalla partida un buffer intermedio más del tamaño de toda la imagen (sí ya sé que no es muy eficiente recrear toda la imagen): o sea como buffer2 en FastDrawImage, pero formado en su parte izq. (hasta una columna de píxels que se ha de calcular) por el buffer de imagen "Antes", y a partir de dicha columna por el buffer de imagen "Después". Una vez volcado ese buffer intermedio al display con el FastDrawImage estándar se podría liberar el buffer intermedio.

Piensa que si no puedes situar la zona exacta donde comparar el antes/después, muchas veces la zona crítica de la imagen para balancear (una carta de gris o un trozo de pared blanco), o comparar nitidez de distintos algoritmos de interpolación, laberintos, ruido,... no va a caer justo en la frontera.

Otra cosa: los parches para el balance de blancos son "position dependant", así que independietemente del modo de display usado (normal, partida A, partida B) o nivel de zoom:
- Hemos de ser capaces de situar en la vista en pantalla los parches de balance empleados
- Así como leer del display el lugar donde los pintamos con el ratón sabiendo la posición de la imagen en que se traducen las coordenadas del display.

El otro día estuve ideando sobre el papel distintas estrategias de ajuste de exposición con preservación de altas luces, pero para un aumento de exposición tengo que probarlas, este finde lo avanzaré.
Empecé a husmear en el tema del código fuente de UFRAW para lo del balance de blancos, pero creo que lo mejor será reinventar la rueda por nosotros mismos; dándole un poco la lata a Coffin creo que saldrá.

OK si me estudio la rutina que hace el IZQ./DER. la replico para ARRIBA/ABAJO.

@ Manuel:
Perdona la tardanza en contestar, pero hoy y ayer por la noche no he podido dedicar mucho tiempo a esto.

¿Con la misma imagen? Eso sí que es raro... de todos modos hasta que no depure bien bien la DLL de dcraw seguirán pasando cosas raras. A ver si la conseguimos compilar con VC++ para depurarla paso a paso. Como ya te dije hice una prueba llamando al main de Coffin directamente desde C# en vez de a mis funciones de la DLL y así no falla... así que es algo que he omitido y es importante. El caso es que no lo veo y sin depurar no hay forma.

Sí, ha sido con la imagen que está distribuida con el código en el subdirectorio raws.
La aplicación se la pega haciendo un acceso a la memoria con un AccessViolation nada más llamar a GetInfo (en Vista 64 pero utilizando la máquina virtual de 32 bits para que pueda cargar la dll de 32 bits).
Para poder depurar dcraw sería imprescindible poder compilar en VS C++. Tú decías que lo habías conseguido... aunque tenías problemas al ejecutar.
¿Te acordaste de marcar la dll como Multibyte en vez de Unicode? Por defecto las dll creadas en VS C++ son UniCode.
Podría intentar retomar eso a ver si consigo un proyecto VS C++ si te parece importante.

La que pusiste para probar los zooms también, pero en ese caso es por lo del BadFormatException debido a que no la marcaste como para plataforma x86 para que se cargara en la máquina virtual de 32 bits.
¿Podrías volver a ponerla compilada para plataforma x86 a ver si por lo menos eso me funciona en Vista 64?

Por cierto, no consigo que una DLL hecha en VC++ tire en C#, no encuentra los puntos de entrada a pesar de que están bien definidos en el .h, igual que hago con DEV-C++, ¿tú hiciste pruebas en ese sentido? Díme si la respuesta es sí y te paso el código de la DLL para las vistas que he hecho a ver si la puedes recompilar en VC++ y que tire desde C#, así la depuramos más cómodo, porque ahora me vuelvo un poco loco... intentaré crear un proyecto de prueba en C y depurar con DEV-C++, porque tiene pequeños fallos en los bordes de la imagen, pero yo no los veo mirando el código. Claro que la terminé de poner a punto ayer a las 2:30 y lo normal es que ya no viera nada .

Efectivamente, tal y como están las cosas, creo que empieza a hacerse muy necesario portar dcrawdll a VS C++. Será la única forma de poder depurar.

Pero ahí estoy bastante pegado. Lo he estado intentando pero tengo diversos problemas.
Veo que tú has llegado el mismo problema. Yo creía que se debía a estar con Vista 64 pero tu dices que te pasa lo mismo.

He creado una dll de prueba con una función revelar muy sencilla.
He creado una aplicación C# para llamar a dicha dll de prueba.
La Dll la he compilado en 32 bits.
He marcado la aplicación C# como ejecutable en plataforma x86 (en vez de any CPU) para evitar el problema de los 64 bits.
La dll la carga, pero me dice que no encuentra la función revelar.
Por más que he revisado los dllimport no he encontrado el error.
¿Es algo similar lo que te pasa a ti?

He subido al svn en el subdirectorio PruebasConcepto/PruLoadDLL el proyecto para que lo podáis revisar.

Se me ocurrió que el problema podría ser con el CharSet de la dll y de la aplicación C#, que utilizaran diferentes charsets y no reconociera entonces el nombre de la función.
He estado jugueteando con cambiar el charset de la dll y con el atributo charset de dllimport pero no he conseguido nada.

Para poder seguir adelante con lo de los xmp y los dng es imprescindible poder cargar dll de C++ en C# ya que el xmp-sdk y el dng-sdk son clases C++ y traen proyectos para VS C++.

Bueno, dime qué ves más urgente para ir probando, porque estoy un poco en la estacada... entre mi problema con Vista 64 (estoy pensando en formatear el ordenador con Vista 32, pero tengo muchas cosas instaladas y no voy a poder hacerlo en los próximos días) y lo de que no puedo cargar las dll no estoy avanzando nada.
_________________________________
Por cierto Manuel:
Hay otra alternativa al uso de los DLLImport y el código unsafe en C#.
Consistiría en eliminar la librería de C# DCRaw que hace los DLLImport y hace de puente y convertirla en una clase C++ manejada.
El código C# accedería a la clase como si fuese una clase más de C# (por ser una clase manejada) y en ella en vez de los DLLImport bastaría con hacer un #include "dcrawdll.h" con las declaraciones de las funciones DCRAW_xxxxx
La Clase C++ puede mezclar código manejado y no manejado y en ella se podrían implementar las funciones de recorte y escalado (y la de dibujado en el contexto de dispositivo) que iría más rápido en C# y sin necesidad de andar poniendo instrucciones unsafe.
También te evitarías tener que andar copiando las variables de dcraw.c en las estructuras que creaste, pues podrían ponerse propiedades que accedieran directamente a las variables globales de dcraw.c.

El inconveniente es que crear clases manejadas en C++ es bastante más latoso que en C#, pero mientras no se ampliara mucho la clase....

No lo he probado, pero se podría hacer una prueba de concepto si lo consideras interesante.

Iniciado por _GUI_

Yo no veo que tenga que ralentizar, pensaba que ibas a añadir para ese modo de pantalla partida un buffer intermedio más del tamaño de toda la imagen (sí ya sé que no es muy eficiente recrear toda la imagen): o sea como buffer2 en FastDrawImage, pero formado en su parte izq. (hasta una columna de píxels que se ha de calcular) por el buffer de imagen "Antes", y a partir de dicha columna por el buffer de imagen "Después". Una vez volcado ese buffer intermedio al display con el FastDrawImage estándar se podría liberar el buffer intermedio.

Vaya taco que nos estamos montando , al final va a ser verdad que debemos quedar un día con pizarra. Yo ya sabéis que si encajamos fechas estoy dispuesto.

No podemos formar un buffer nuevo del tamaño de la imagen completa con media imagen de cada lado cada vez que se reescala y liberarlo después, porque eso sí que sería muy lento. Ten en cuenta que el reescalado se lanza innumerables veces cuando mueves la imagen. Podemos emplear dos estrategias distintas, pero en las dos llamaremos a la función que reescala con tres buffers: el destino y dos orígenes. Las alternativas (todo esto hecho dentro de la DLL):

1. Reservamos un buffer de tamaño w*h/z^2 (así grosso modo, luego hay que meter los "extras") y copiamos en él media imagen de cada lado teniendo en cuenta el trozo que se va a copiar: x+w/z,y+h/z. Interpolamos como antes y liberamos el buffer.
2. Modificamos el algoritmo para que hasta la mitad de la línea lea datos de un buffer y hasta el final del otro buffer. Esto, salvo en la interpolación de tamaño 1x, en la que se copian líneas enteras con memcpy, no ralentizará casi nada porque es solo meter una condición en los búcles.

Quizás implemente las dos y haga la prueba, a ver cuál va más rápido. ¿Hacemos una porra ? Lo que está claro es que será en una función a parte de la que ya hay.

Iniciado por _GUI_

Piensa que si no puedes situar la zona exacta donde comparar el antes/después, muchas veces la zona crítica de la imagen para balancear (una carta de gris o un trozo de pared blanco), o comparar nitidez de distintos algoritmos de interpolación, laberintos, ruido,... no va a caer justo en la frontera.

Esto no lo entiendo... ¡ah, ya! sí, que si tienes que andar haciendo scroll a ver si pillas la separación... no si está claro que hay que hacerlo del otro modo.

Iniciado por _GUI_

Otra cosa: los parches para el balance de blancos son "position dependant", así que independietemente del modo de display usado (normal, partida A, partida B) o nivel de zoom:
- Hemos de ser capaces de situar en la vista en pantalla los parches de balance empleados
- Así como leer del display el lugar donde los pintamos con el ratón sabiendo la posición de la imagen en que se traducen las coordenadas del display.

Sí, eso es un cálculo relativamente fácil. ¿La idea es obtener de ahí los multiplicadores o pasar el rectángulo a dcraw?

Iniciado por _GUI_

El otro día estuve ideando sobre el papel distintas estrategias de ajuste de exposición con preservación de altas luces, pero para un aumento de exposición tengo que probarlas, este finde lo avanzaré.
Empecé a husmear en el tema del código fuente de UFRAW para lo del balance de blancos, pero creo que lo mejor será reinventar la rueda por nosotros mismos; dándole un poco la lata a Coffin creo que saldrá.

Tú mismo. Ya sabes que esas cosas están confiadas a tus manos.

Iniciado por _GUI_

OK si me estudio la rutina que hace el IZQ./DER. la replico para ARRIBA/ABAJO.

Es una tontería, pero así te fuerzas a mirar el código C#.

Un saludo:
_________________________________

Iniciado por ariznaf

Perdona la tardanza en contestar, pero hoy y ayer por la noche no he podido dedicar mucho tiempo a esto.

Total, para lo que te voy a pagar . Hombre ariznaf, no pensarás que me tienes que dar explicaciones, ¿no?

Iniciado por ariznaf

Sí, ha sido con la imagen que está distribuida con el código en el subdirectorio raws.

Pues entonces claramente es que no rula. Eso me dices que es en 32 bits. Es bastante raro. Habrá que compilar con VC++ para poder depurar.

Iniciado por ariznaf

Para poder depurar dcraw sería imprescindible poder compilar en VS C++. Tú decías que lo habías conseguido... aunque tenías problemas al ejecutar. ¿Te acordaste de marcar la dll como Multibyte en vez de Unicode? Por defecto las dll creadas en VS C++ son UniCode.

Lo que yo había conseguido compilar con VC++ es dcraw.EXE, no dcraw.DLL. Ese compilará seguro y luego no nos funcionará llamarlo desde C#, pero es que además tampoco lee bien los RAWs por el mismo problema que tiene el EXE en VC++.

Iniciado por ariznaf

Podría intentar retomar eso a ver si consigo un proyecto VS C++ si te parece importante.

Más que importante, útil para depurar. Tarde o temprano lo arreglaremos sin depurar, pero puede ahorrarnos problemas en el futuro. Espera que haga alguna prueba más y si no lo consigo te paso el proyecto VC++ que compila el dcraw.exe, pero que no funciona luego, para ahorrarte trabajo. Si funcionara el exe ya meteríamos mano a la dll.

Iniciado por ariznaf

La que pusiste para probar los zooms también, pero en ese caso es por lo del BadFormatException debido a que no la marcaste como para plataforma x86 para que se cargara en la máquina virtual de 32 bits. ¿Podrías volver a ponerla compilada para plataforma x86 a ver si por lo menos eso me funciona en Vista 64?

Por supuesto, a ver si me apaño. Te mando un mail cuando esté.

Iniciado por ariznaf

He creado una dll de prueba con una función revelar muy sencilla. He creado una aplicación C# para llamar a dicha dll de prueba. La Dll la he compilado en 32 bits. He marcado la aplicación C# como ejecutable en plataforma x86 (en vez de any CPU) para evitar el problema de los 64 bits. La dll la carga, pero me dice que no encuentra la función revelar. Por más que he revisado los dllimport no he encontrado el error.
¿Es algo similar lo que te pasa a ti?

Es exactamente lo que me pasa cuando intento compilar la otra DLL (la de la prueba que he subido esta mañana) y llamarla desde C#. Lo otro que he compilado con VC++, como te pongo arriba, es dcraw.exe, no dcraw.dll.

Iniciado por ariznaf

Para poder seguir adelante con lo de los xmp y los dng

Bueno, se puede avanzar mirando como va para hacerse con él, aunque aún no podamos llamarle desde C#. Pero vamos, que lo de llamar a una DLL en VC++ desde C# tiene que ser de peroguyo. Es alguna chorrada que no vemos.

Iniciado por ariznaf

Bueno, dime qué ves más urgente para ir probando, porque estoy un poco en la estacada...

No te desanimes, hay cosas que puedes ir haciendo con Vista 64, además alguien tiene que probar las cosas en él. Te mandé un privado con la respuesta antes de que hicieras la pregunta... ¿no te llegó?

Iniciado por ariznaf

El inconveniente es que crear clases manejadas en C++ es bastante más latoso que en C#, pero mientras no se ampliara mucho la clase... No lo he probado, pero se podría hacer una prueba de concepto si lo consideras interesante.

Buff, a mí es que C++ me da repelús, como te dije. Prefiero usarlo lo menos posible. Me parece superimproductivo al lado de C# y C. Acabas escribiendo mogollón de líneas de código sólo para cumplir con las exigencias del lenguaje. Está claro que para proyectos complejos que requieran un alto rendimiento es insustituible, pero nuestro proyecto _quiere_ ser pequeño.

Un saludo:

He contestado a tu privado. Es que normalmente entro directo al foro y en la página del foro no aparece (por desgracia) si tienes privados o no.
Estoy encantado de tener algo concretito y sencillo para hacer, así tengo la sensación de ayudar en algó, ya que lo de las dll y Vista 64 resulta un poco frustrante.
Me vendrá bien centrarme en otra cosa y a lo mejor me vienen ideas nuevas.

No me desanimo, en realidad estoy disfrutando con retomar lo de programar, aunque me cueste.

Buff, a mí es que C++ me da repelús, como te dije. Prefiero usarlo lo menos posible. Me parece superimproductivo al lado de C# y C. Acabas escribiendo mogollón de líneas de código sólo para cumplir con las exigencias del lenguaje. Está claro que para proyectos complejos que requieran un alto rendimiento es insustituible, pero nuestro proyecto _quiere_ ser pequeño.

Completamente de acuerdo, C++ para desarrollar clases que interactúen con el escritorio o clases manejadas para poder llamarlas desde C# es un verdadero incordio.
De todas formas quería comentarlo para que lo tuvieras en mente por si en algún momento hay que decidir hacerlo por temas de compatibilidad o de rapidez.
No sé si de alguna manera ayudaría al problema de cargar las DLL ya que no hay que hacer el DLL import.
Es posible que lo intente usar para el tema del xmp-sdk y dng-sdk. Haciendo una clase manejada lo más pequeña posible, eso sí.

Iniciado por ManuelLlorens

Las alternativas (todo esto hecho dentro de la DLL):

1. Reservamos un buffer de tamaño w*h/z^2 (así grosso modo, luego hay que meter los "extras") y copiamos en él media imagen de cada lado teniendo en cuenta el trozo que se va a copiar: x+w/z,y+h/z. Interpolamos como antes y liberamos el buffer.
2. Modificamos el algoritmo para que hasta la mitad de la línea lea datos de un buffer y hasta el final del otro buffer. Esto, salvo en la interpolación de tamaño 1x, en la que se copian líneas enteras con memcpy, no ralentizará casi nada porque es solo meter una condición en los búcles.

Quizás implemente las dos y haga la prueba, a ver cuál va más rápido. ¿Hacemos una porra ? Lo que está claro es que será en una función a parte de la que ya hay.

A priori la segunda me parece que debería ir más rápido no? no se añaden pasos intermedios.

if modo=0 FastDrawImage(char *buffer, char *buffer2,...)
else FastDrawImage2(char *buffer, char *buffer2, char *buffer1,...)

y en FastDrawImage2 los bucles que tomen el dato de buffer1 (vista IZQ/SUP) en la primera mitad del rango del índice y de buffer2 (vista DER/INF) en la segunda mitad.

Estoy seguro que estas cuestiones del display van a ser con diferencia mucho más puñeteras de programar que todo lo demás.

Iniciado por ManuelLlorens

Sí, eso es un cálculo relativamente fácil. ¿La idea es obtener de ahí los multiplicadores o pasar el rectángulo a dcraw?

No no, el balance de blancos lo hacemos nosotros que DCRAW solo tiene parche rectangular y el parche circular es muy molón y útil en focos. Ya te comenté que la rutina de cálculo del balance de blancos es muy simple, solo hay que adaptarla a los datos RAW (RAW ya en un buffer float, reescalado por punto negro y de saturación, pero sin demosaicing ni balance de blancos).

Hay que reciclar scale_colors() en una nueva función que no haga el balance de blancos, de modo que la salida solo tenga:

• Sustracción del nivel negro: if ((val -= black) < 0) val = 0;
• Saturación: Coffin mezcla la corrección de saturación con los propios multiplicadores del balance de blancos: (pre_mul[c] /= dmax) * 65535.0 / maximum;. No sé qué es dmax, pero quitando ese factor por lo demás con hacer: scale_mul[c]=(1 / dmax) * 65535.0 / maximum; ya estaría.

image[row*iwidth+col][c] con c=0..3 contiene los 4 canales a recorrer en el parche para calcular los multiplicadores.

Iniciado por ManuelLlorens

Es una tontería, pero así te fuerzas a mirar el código C#.

Pero qué tiene este código C# que no sea C estándar?
Entonces Dev C++ es solo para las DLLs que estás haciendo en C puro y duro, y el entorno gráfico y llamadas a esas DLLs desde VS en C# no?
recomiéndame un libro de C# que lo busco este finde.

Lo he probado en dos máquinas y me parece excelente. Las dos estan un poco anticuadas y aún así la velocidad la veo mas que aceptable.

Una máquina es un Pentium Dual a 3.40Ghz 38545iit/s con pantalla 1600x1200 maximizada. Windows XP.

El otro un portatil con un pentium plano a 1.60Ghz 14742iit/s. La pantalla a 1280x768 Vista x32

(Lo de iit/s es lo que me da el SiSoft Sandra, un soft que hace "benchmarks", en el de "Processor MultiMedia". El soft se puede descargar en www.sisoftware.net, la versión gratuita "Lite". Si descargais ojo a qué clicais que enlazan a sitios liantes de esos que instala cosas raras en la barra del windows y tal)

Pues eso, aunque no es 100% suave (lo comparo con el scrolling del PS barra de espacio+click y desplazar) me parece que no hace falta más para la funcionalidad, al menos a estas alturas. Seguro que puede optmizarse luego.

Iniciado por _GUI_

truji (bienvenido, ya tardabas en aparecer a cacharrear jeje):
cómo recomendarías hacer la salida gráfica para que sea de verdad lo más rápida posible tanto en las llamadas a librería como en el display?
aunque me da que el cuello de botella van a ser los cálculos.

Lo mio es mas de chafardear :-) Lo que digo, que ¿para que preocuparse si lo que hay ya vale?. En plan óptimo creo que seria el DirectX pero yo no me liaria por el follón que conlleva: Aumentas las probabilidades de problemas, lias la programación (a no ser que el .NET lo esté recubriendo con llamadas simples), Y siempre se está a tiempo de implementar en la versión 1.ypico

Definitivamente el cuello de botella sera el procesado. Probablemente no será posible conseguir respuesta en tiempo real a variaciones de parámetros así que el problema que ocurrirá es que al tocar controles, sliders especialmente, habrá que reiniciar el procesado.

En estos casos creo que lo mas importante es que la respuesta de los controles sea suave y rápida y no ocurre así si al variar algun parametro se desencadena el cancelar el procesado activo en el momento y reiniciar uno, los desplazadores van a trompicones y aparte de dar mala sensación despistan y son incómodos.

Sugiero un mecanismo multithread con un hilo que esté solo para procesar. La clave está en como comunicar con el proceso que recibe los eventos de los controles (que no lo atranque, respuestas del orden de una decima de segundo ya crean la impresion de que el slider funciona mal). Ultimamente he trabajado en algo parecido y como he hecho unas cuantas cagadas algo he aprendido.

Manuel si te parece que puedo ayudar elaborando esto dímelo.

Otra cosa, en algun lado dices que no puedes llamar a las funciones el la DLL desde C#, te comento solo por si te da una idea. (Si la DLL es en C++) ¿Sabes lo de que hay envolver las funciones a exportar entre

extern "C"{

__declspec(dllexport) Funcion(...){

}

}
(si el módulo se está compliando como C++ los nombres de función llevan sufijos con información sobre los parametros y son un follón)

Iniciado por ManuelLlorens

Por cierto, ¿en qué resolución lo has probado?

Lo tengo a 1280x1024, maximizado y el desplazamiento me parece perfectamente funcional. No cuesta nada ser preciso con él. Y si le doy rápido a la rueda del ratón prácticamente no veo las imágenes de los zooms intermedios.
Si finalmente acaba funcionando así en las versiones definitivas, yo no pondría ninguna queja. Ánimo.

¡¡Gracias Truji!!
Ese era el problema. Ni CharSet ni nada.... el problema es que en la generación de los nombres de las funciones estaba usando la convención C++ en vez de la convención C.

Tenía que haberme dado cuenta, pues con esto ya me había peleado antes, pero como decía estoy muy oxidado en lo de la programación. Bueno espero "resucitar".

Simplemente es añadir extern "C" en la declaración de las funciones para indicar que genere nombre sin información de tipos.

Si todo el código generado es código C y no se mezcla con clases de C++ (como es el caso de Manuel en su librería dcraw) otra opción en vez de andar poniendo extern C es compilar el código como código C con la opción /TC (en las propiedades avanzadas de configuración de C/C++, opción compilar como). Por defecto se usa esa opción para los archivos con extensión .C pero los cpp se compilan como código C++.

He probado las dos cosas y ambas funcionan (salvo que en la segunda opción no se pueden declarar clases).
_________________________________
Bueno Manuel:

He actualizado el ejemplo pruLoadDLL y he puesto la nueva versión en el svn (PruebasConcepto/pruLoadDLL)
He preparado dos proyectos de librerías dll Win32: una usando el extern "C" (pruDLL2) y otra utilizando la opción de compilación como código C (pruDLL).

La aplicación C# de test está compilada para x86 de manera que se puedan cargar las librerías anteriores.

La aplicación muestra dos cuadros de texto con scroll: uno muestra el resultado devuelto por revelar de una librería y el otro por la otra.
Además los cuadros de texto están en un componente TableLayoutPanel para que conserven sus proporciones al ampliar o disminuir el formulario (tal y como se había comentado que se podía hacer para las dos vistas de pictureBox de la aplicación).

Cuando de damos a revelar, una librería aumenta el contador en 1 y la otra lo multiplica por 2.

¡¡Por fin he terminado algo y además incluye una DLL C++ y otra C!!

Soy un monstruo .... pero de las galletas, más de una semana para llegar a esto a este paso para el 2020 acabo algo interesante para la aplicación

Bueno y ahora pa la cama.

Son grandes noticias, ¡gracias truji y ariznaf! Ahora podemos compilar las DLLs en VC++ para depurar desde C#. Con eso avanzaremos más rápido. Además lo haremos funcionar en Vista 64, aunque sea corriendo en 32 bits.

Recapitulemos lo que llevamos hecho hasta ahora, qué bugs contiene y qué pasos debemos dar a continuación (y de paso quién puede darlos). Así todos estamos a lo mismo:

1. dcraw.exe: funciona al 100%. Podemos compilarlo con Cygwin, DJGPP y MinGW, todas funcionan y la última corre en todos los Windows sin necesidad de añadir ninguna DLL (tipo cygwin1.dll). Falta: poder compilarlo con VC++. Problema: hay que dedicar un rato a arreglar lo que falla, porque compila pero no funciona. Probablemente el cambio de ftello/fseeko por ftell/fseek, un tema con tipo de caracteres, etc. hace que el programa no identifique adecuadamente los RAWs. _Tiene_ que ser una chorrada. Me pongo yo con ello. Este exe no hace falta para el proyecto actual.
2. dcraw.dll: funciona. Fallos: casca con algunos RAWs concretos. Si arreglamos el punto 1 nos lleva a poder compilar dcraw.dll en VC++ y depurar desde allí los casques que da al llamar a la DLL desde C#. Falta: hay que añadirle (pero hasta que no funcione lo que hay al 100% no voy a meter nada más) el control de exposición de _GUI_, la función nueva scale_colors() con las modificaciones que _GUI_ propone, la nueva función que aparecerá como consecuencia white_balance(), que la DLL de salida casi completamente RAW para el futuro perfectBLEND y que permita volver a entrar el resultado de perfectBLEND con el fin de verlo en pantalla terminado de revelar. De momento me pondré yo con ello. Bien lo consiga compilar con VC++, bien lo depure a capón, pero lo acabaré arreglando. Más que nada para que no tengáis que empaparos del pupurrí de código de Coffin y mío. Lo bueno es que aunque casque con algunos RAWs, como con otros no, podemos seguir trabajando en el GUI sin que esto nos bloquee.
3. El GUI. Ahora mismo consta de dos piezas separadas:
   1. El revelador (la primera prueba ejecutable que subí). Funciona: la clase dcraw que lleva dentro. Es decir, revela, se pueden especificar los parámetros, muestra la salida por pantalla, etc. La llamada a revelar ya se hace en segundo plano, con lo que la pantalla no se congela. No podemos realizar dos revelados simultáneos, ni probablemente cancelar uno que se haya lanzado. Los sliders y controles responderán al 100% porque no lanzarán un revelado nuevo. Lo que harán será encender el botón de REVELADO para avisarnos de que se han cambiado parámetros y estamos pendientes de revelar con esos nuevos parámetros. Es decir, la aplicación no revelará (salvo al arrancarla) si no se lo pedimos nosotros. Puede que sea menos espectacular que en algunos reveladores, pero mantiene la filosofía del proyecto de darnos todo el control y además permite que los controles funcionen suavemente. Yo también odio que en algunos reveladores se muevan a trompicones. Quizás en el futuro (versión 2.0 o más) podamos crear una previsualización rapidísima de lo que hace el control y luego lanzar el revelado a más calidad. De momento simplemente no. Falta: añadir todos los controles de revelado. El único que aún no podemos implementar es el de balance de blancos a través de la temperatura de color, pero está _GUI_ en ello, así que todos sabemos que es un asunto vistualmente resuelto . Problema: afortunadamente este módulo no presenta problemas propios, así que podemos avanzar en él sin miedo. De momento voy a poner todos los controles de revelado usando los controles por defecto de .NET. En paralelo estaría bien que alguno cambiárais los controles por otros con un diseño personalizado. ¿Te animas con eso tú truji?
   2. La maqueta con las vistas (la segunda prueba ejecutable que subí el otro día). Funciona: lo más importante es que hemos visto que podemos sacar la versión 1.0 sin DirectX/BitBlt/OpenGL, con lo que podemos seguir avanzando sin miedo. Falta: poner el control de vistas, que van a ser 7 (una sola imagen, dos independientes H, dos enlazadas H, dos partidas H, dos independientes V, dos enlazadas V, dos partidas V); y encapsular todo en una clase View. Problemas: además, arreglar los pequeños errores que da en los bordes. De implementar lo que falta y de arreglar los bordes me encargo yo. De encapsularlo en una clase se encarga ariznaf. En cuanto funcione mi parte, aún sin encapsular, lo mezclaré con el revelador y tendremos ya un GUI semifuncional. Más adelante, cuando ariznaf termine de encapsular metemos la clase vista. Así no nos quedamos parados.
4. El SDK de DNG. En esto se ha puesto ariznaf. Sería ideal que alguno se pusiese con ello mientras ariznaf se dedica a encapsular las vistas. No corre prisa para perfectRAW 1.0, pero sí para perfectBLEND. ¿Alguien con soltura en C++ quiere ponerse con ello?
5. _GUI_ se dedica a instalarse el entorno de desarrollo (igual hasta lo consigue antes de que acabe el proyecto ) y terminar de definir la teoría de wb/exposición/perfectBLEND.

dgmaga, vertex y perroverd están colaborando también, pero no recuerdo en qué lenguajes de programación de manejaban. Cuando leáis este mensaje podéis definir vosotros mismos en qué podéis colaborar (a parte de mantener en svn, me refiero). Sé que vertex iba a mirar lo del OpenGL para futuras versiones, pero no recuerdo más.

También estaba interesado dsamper, pero hace tiempo que no se sabe nada de él. Cuando vuelva por aquí que se suba al tren en marcha.
Pues eso es todo. Espero que en una semana tengamos un revelador que sea merecedor de esa denominación (para arrancar podemos salvar un TIFF o un JPEG a capón desde .NET o guardar un archivo con los parámetros de revelado, todo eso es muy fácil de implementar). Y con ello podremos empezar a dar más difusión al proyecto.

Por cierto, los dominios perfectRAW.com y perfectBLEND.com están libres de momento y podemos contemplar la opción de comprarlos en el futuro. Podriamos sufragarlos a base de donativos PayPal. También podríamos pensar en algo más genérico que englobara a estos y otros productos futuros, pero tiene que ser un nombre corto y que suene moderno. perfectSoft me suena a años 80.

Un saludo:

Iniciado por ariznaf

¡¡Gracias Truji!!
Ese era el problema. Ni CharSet ni nada.... el problema es que en la generación de los nombres de las funciones estaba usando la convención C++ en vez de la convención C.

Vaya, me alegro, es que precisamente hace poco perdí media mañana hasta acordarme (por 5º o 6ª vez, a ver cuanto dura

Iniciado por ManuelLlorens

En paralelo estaría bien que alguno cambiárais los controles por otros con un diseño personalizado. ¿Te animas con eso tú truji?

Yo es que de .NET y C# ni flores solo toco el C++ y la api de Win32. Tengo un desarrollo entre manos que espero acabar pronto (aunque ya se sabe como va esto) En cuanto me sienta suelto me actualizo con lo que llevais y al menos hago de tester.... De fondo voy a investigar el DNG toolkit, no me comprometo de momento.

Iniciado por ManuelLlorens

La llamada a revelar ya se hace en segundo plano, con lo que la pantalla no se congela. No podemos realizar dos revelados simultáneos, ni probablemente cancelar uno que se haya lanzado. Los sliders y controles responderán al 100% porque no lanzarán un revelado nuevo.....

Bien! solo comentar que en alguna version futura querreis que el rawelado se dispare automaticamente al tocar cualquier control. Solo sugerir que a la hora de desarrollar el rawelador tener en cuenta la posibilidad de que al detectar cierta señal "usuario ha cambiado algo->hay que reniciar" las rutinas de rawelado prevean una cancelación limpia (sin dejar memoria ocupada) para volver a empezar

Oye, no he sido un usuario del DCRAW porque para lo que hago ya me vale lo que uso (C1) pero empiezo a oler unas posibilidades y mejoras en el flujo de trabajo muy prometedoras...

Animos,

Iniciado por truji

.... De fondo voy a investigar el DNG toolkit, no me comprometo de momento.

Eso es ya mucho decir .

Iniciado por truji

Bien! solo comentar que en alguna version futura querreis que el rawelado se dispare automaticamente al tocar cualquier control. Solo sugerir que a la hora de desarrollar el rawelador tener en cuenta la posibilidad de que al detectar cierta señal "usuario ha cambiado algo->hay que reniciar" las rutinas de rawelado prevean una cancelación limpia (sin dejar memoria ocupada) para volver a empezar

Bueno, como habrá que activar el botón de revelado cuando se detecten cambios eso ya estará implementado. Lo de cancelar el revelado no tengo ni idea de cómo va... ¿se lanza algún tipo de señal a la DLL? El problema es que no queremos tocar mucho código de Coffin. En cualquier caso haré pruebas a ver qué le pasa a la DLL cuando se cancela.

Iniciado por truji

Oye, no he sido un usuario del DCRAW porque para lo que hago ya me vale lo que uso (C1) pero empiezo a oler unas posibilidades y mejoras en el flujo de trabajo muy prometedoras...

De eso precisamente se trata. Yo desde luego tengo intención de convertirlo en mi revelador. No es sólo por divertirnos. Copio una frase que he puesto en el foro de Funcionalidad Nueva:

[...] mientras _GUI_ siga dirigiéndonos en la dirección correcta, tenemos la obligación moral de tener un workflow de revelado teórica y conceptualmente perfecto. Ese es mi objetivo, ir haciendo realidad todas las teorías de _GUI_ de modo que en cada etapa del revelado tengamos algo conceptualmente perfecto, de ahí el nombre de los productos [...]

Un saludo:

1. dcraw.exe: funciona al 100%. Podemos compilarlo con Cygwin, DJGPP y MinGW, todas funcionan y la última corre en todos los Windows sin necesidad de añadir ninguna DLL (tipo cygwin1.dll). Falta: poder compilarlo con VC++. Problema: hay que dedicar un rato a arreglar lo que falla, porque compila pero no funciona. Probablemente el cambio de ftello/fseeko por ftell/fseek, un tema con tipo de caracteres, etc. hace que el programa no identifique adecuadamente los RAWs. _Tiene_ que ser una chorrada. Me pongo yo con ello. Este exe no hace falta para el proyecto actual.

Manuel: comprueba que cuando compiles el ejecutable en el VS C++ no estés usando UniCode. Debes de seleccionar Multibyte y lincarlo con las librerías ANSI (no las unicode) correspondientes a stdio y demás, para que printf y resto de funciones (ftell, etc) utilicen char de un byte y no de dos. Creo que el problema pueda venir de ahí.

Quizás lo ideal sería usar las unicode, pero el problema es que el código de Coffin utiliza el char para referenciar a un byte. Si se compila con las opciones unicode, el char estará definido como dos bytes y por tanto habrá conflictos con ese código.

Si se fuerza el código para que el char sea un byte, las librerías estandar a utilizar para el printf y lectura de ficheros han de ser también las que utilizan char como un byte (las ANSI y generar código Multibyte en vez de Unicode).
_________________________________

Bueno, como habrá que activar el botón de revelado cuando se detecten cambios eso ya estará implementado. Lo de cancelar el revelado no tengo ni idea de cómo va... ¿se lanza algún tipo de señal a la DLL? El problema es que no queremos tocar mucho código de Coffin. En cualquier caso haré pruebas a ver qué le pasa a la DLL cuando se cancela.

Lo más fácil de implementar sería mediante una variable, llamémosla cancelar.
Cuando queremos que se cancele, en C# ponemos cancelar a 1.
La librería DCRaw, cada vez que sale de una función del código de Coffin y vuelve a estar en alguna de tus funciones DCRAW_xxx debería de comprobar esa variable y si está a 1, limpiar lo hecho desde el último paso de revelado (según en el paso en que esté) y regresar.

La granularidad obtenida no será muy grande, pero por lo menos evitaremos que se ponga a hacer un siguiente paso de revelado sin que lo hecho se vaya a utilizar para nada.

En código manejado, se podrían utilizar transacciones que permiten regresar a un estado anterior de la memoria (eso forma parte de la especificación COM+ que incorpora el Manejador de Transacciones y todos los componentes de .NET son COM+).
Pero creo que eso complicaría el código (yo no lo he llegado a manejar) y además no sirve para DCRAW porque no es código manejado.
_________________________________
Con la información que ha puesto Manuel de las tareas en curso he creado Issues en Google Code para hacer el seguimiento de su estado y evolución.
Permiten ir haciendo comentarios sobre la evolució y observaciones y cerrar cada tarea cuando se acabe.

Tiene buena pinta, podríamos ir probando su uso para ver si facilita el seguimiento de las tareas de cada uno.

Iniciado por ariznaf

Manuel: comprueba que cuando compiles el ejecutable en el VS C++ no estés usando UniCode. Debes de seleccionar Multibyte y lincarlo con las librerías ANSI (no las unicode) correspondientes a stdio y demás, para que printf y resto de funciones (ftell, etc) utilicen char de un byte y no de dos. Creo que el problema pueda venir de ahí.

Lo primero ya lo he hecho y sigue dando el mismo error. Lo segundo, lo de vincularlo con las librerías ANSI en vez de UNICODE, que tiene pinta de ser completamente necesario, ¿dónde se pone, que no lo encuentro?

Iniciado por ariznaf

Lo más fácil de implementar sería mediante una variable, llamémosla cancelar.

Pues sí, voy a intentarlo así. Además es imprescindible hacerlo porque si no, aunque se cierre el GUI, la DLL sigue corriendo en memoria haciendo un absurdo revelado : estaba haciendo unas pruebas para depurar dcraw.dll y le he puesto que saque unos MessageBox al llegar a un punto. He cerrardo el C#, he seguido haciendo otra cosa, y de pronto me ha saltado el MessageBox de la DLL. Yo pensaba que al salir de la aplicación se cancelarían los hilos. Lo que no sé es si es porque el Garbage Collector aún no ha destruido la clase Thread o porque la tarea sigue corriendo aunque se destruya la clase Thread que la creó. En cualquier caso, pondré una variable de cancelación tras cada STAGE del revelado y cortaré después de cada fase. Si se vuelve a revelar habrá que continuar desde el último buffer que esté lleno o antes, pero no después, claro; lo que no hace falta es liberar memoria. En el primer revelado no se dará la opción de cancelar, salvo que sea por cierre de la aplicación. La memoria solo se libera al llamar a dcraw_End() y de eso se encarga C#, porque está puesto en el destructor de la clase. Aunque estoy pensando que el destructor deberá lanzar la señal de cancelado, esperar a que termine el Thread y luego llamar a dcraw_End(), ¿no? ¡Qué lío me estoy armando yo solo! Bueno, da igual, lo haremos bien, cuando lo hagamos.

He progresado con dcraw.dll. Ya sólo me queda un error. Es un problema de reentrada. La primera ejecución va bien pero si vuelves a llamar casca. Será otra chorradilla. Hay alguna variable que no se reinicializa bien después del dcraw_End() y vuelta a dcraw_Init().

Un saludo:

Iniciado por ManuelLlorens

Por cierto, los dominios perfectRAW.com y perfectBLEND.com están libres de momento y podemos contemplar la opción de comprarlos en el futuro. Podriamos sufragarlos a base de donativos PayPal. También podríamos pensar en algo más genérico que englobara a estos y otros productos futuros, pero tiene que ser un nombre corto y que suene moderno. perfectSoft me suena a años 80.

más genérico y bonito (sin llegar a la cursilería) dando un toque aspiracional respecto a los nombres tecnificados de las aplicaciones:

Perfect Images

www.perfectimages.com

El dominio está pillado por un revendedor así que no hay prisa en decidirse . Si se suben a la parra con un toque español está libre:

Perfect Images

Perfect Images

www.perfectimag.es

Bueno son ideas para que los robadominios se gasten los duros. El bueno me lo tengo reservado. Voy a ver si logro compilar el GUI, ayer me instalé el VS 2005 gratuito, será suficiente Manuel o le faltará algún componente?

Iniciado por _GUI_

más genérico y bonito (sin llegar a la cursilería) dando un toque aspiracional respecto a los nombres tecnificados de las aplicaciones:

www.perfectimages.com

Esto suena más a portfolio o librería de fotos que a software, pero... como tú dices es mejor no revelar "el bueno".

Iniciado por _GUI_

será suficiente Manuel o le faltará algún componente?

Creo que seré suficiente ... lo que no sé bien es ¿para qué? Chistes malos a parte (es que estoy de buen humor últimamente) creo y espero que te sea suficiente, aunque a lo mejor podrías conseguir una versión más completa que lleve el C++ por si lo necesitamos. Ya sabes, lo venden en las tiendas .

Un saludo:
_________________________________
En otro orden de cosas. Para probar si los fallos de dcraw.dll eran míos o de Coffin (y resultaron ser míos) habilité una llamada al main() de Coffin desde C#. En realidad se llama _main().

Tengo intención de dejarlo así en el código final porque no cambia casi nada. Es decir, que el que quiera usar la librería para sus propios desarrollos tendrá la opción de hacer un revelado por etapas como el de perfectRAW o podrá llamar también a la DLL como si lo hiciera a la línea de comandos y dcraw grabará en el disco el archivo de salida.

Es un atajo para modificar aplicaciones como MeGUI y el actual ZeroNoise y que funcionen un poco mejor con poquísimos cambios; al menos se evita el problema del tamaño de la línea de comandos y puedes distribuir la DLL en el mismo directorio de la aplicación.

Tampoco es complicado llamar a dcraw_Init(), dcraw_Process(), dcraw_End(), pero es una forma de extender y facilitar el uso de dcraw por parte de otros desarrolladores.

Para declarar la DLL desde VB, se usa algo como:
Declare Function _main Init Lib "dcraw" (argc as Integer, argc() as String) As Integer

Y ya se puede tirar de la DLL. Vamos que está chupao.

Un saludo:

Iniciado por ManuelLlorens

aunque a lo mejor podrías conseguir una versión más completa que lleve el C++ por si lo necesitamos. Ya sabes, lo venden en las tiendas .

Tanto VS 2005 Express como VS 2008 Epxress (que son gratis) tienen VC++, no debería haber problemas.

Daniel

Es genial, el proyecto va a ser 100% OpenSource, hecho con herramientas OpenSource en Windows y multiplataforma, ¿se puede pedir más?

Un saludo:

El VS C++ Express 2005 si tiene limitaciones.
Lo instalé en mi portátil y creo recordar que no dejaba crear librerías DLL.
También creo que no deja crear versión Release (el C# por lo que vi tampoco, pues no aparece la opción de cambiar de configuració).

Además las solucionse de VS Express no permiten soluciones con proyectos mezclados de C++ y C#, lo que quiere decir que no puedes trabajar con los dos a la vez.
Si abres la solución con C++ no accederás al proyecto de C# y viceversa (te pregunta si quieres abrirlo con el VE C++ o el VE C#).
Se comportan como aplicaciones independientes, no integradas.

En cuanto a lo del dominio, me hizo gracia lo del juego de palabras perfectimag.es
Me gusta la idea de algo más genérico para poder integrar posibles futuros desarrollos y dar una plataforma común a los dos proyectos.
Yo había comentado algo previamente Perfect delante y depués Developer para jugar con lo de revelador y desarrolador de código.
El .com no me gusta porque el .com es dominio comercial con ánimo de lucro.
Prefiriría .org (organizaciones sin ánimo de lucro) o .net
.es tampoco estaría mal por lo de marcar el origen no americano, aunque no quiero levantar susceptibilidades.

Iniciado por ariznaf

En cuanto a lo del dominio, me hizo gracia lo del juego de palabras perfectimag.es
Me gusta la idea de algo más genérico para poder integrar posibles futuros desarrollos y dar una plataforma común a los dos proyectos.
Yo había comentado algo previamente Perfect delante y depués Developer para jugar con lo de revelador y desarrolador de código.
El .com no me gusta porque el .com es dominio comercial con ánimo de lucro.
Prefiriría .org (organizaciones sin ánimo de lucro) o .net
.es tampoco estaría mal por lo de marcar el origen no americano, aunque no quiero levantar susceptibilidades.

Yo creo que la palabra 'developer' suena demasiado a informático. Mi web es .com y lo único que he hecho con ella de momento ha sido pagarle a Sergio

Unas opciones más aspiracionales aún y que ya no parecen de una web de imágenes:

Perfect Imaging

www.perfectimaging.org

(.com está pillado)


Más abstracto, juego de palabras:

Perfect Imagine

www.perfectimagine.com

Hola, os doy mi más sincera enhorabuena por esta iniciativa, aunque hace muchos años programé algo en C y C++ no estoy en disposición de ayudaros en ello ahora pero como usuario de DCRAW y UFRAW sí que espero ansioso el desarrollo de esta herramienta y en lo que sí me ofrezco es a ser un betatester.

Para el tema del nombre y en plan romántico (que se note algo su origen) estaría bien que se incluyera la "ñ" aunque luego para el resto de usuarios con teclados no hispánicos no sé cómo se las arreglarían, algo así cono ÑAWxxxxxxx

Saludos

Iniciado por _GUI_

Unas opciones más aspiracionales aún y que ya no parecen de una web de imágenes:

Perfect Imaging

www.perfectimaging.org

(.com está pillado)


Más abstracto, juego de palabras:

Perfect Imagine

www.perfectimagine.com

Yo propongo www.perfecthalos.com...

Daniel

Lo de developer lo decía porque en inglés tiene las dos acepciones: desarrollo (informático) y revelado (de imagenes).
Pero bueno tampoco es un nombre demasiado imaginativo. Quizás demasiado largo (PerfectDeveloper).

Cuando digo que .com es comercial no quiere decir que nadie controle si en realidad es un negocio o no.

Me refiero a que es el espíritu con que se crearon los dominios. .com y .biz son para negocios .org para organizaciones sin animo de lucro de cualquier tipo.

Por supuesto hay muchos .com que en realidad no son negocios (y seguramente algún .org que sí lo sea) pero no es el espíritu del dominio tal cual lo definió el ICANN

Pero vamos que tampoco tiene ninguna importancia, hay montones de .com que son sede de desarrollos libres.

Lo de la Ñ tendría su gracia, pero no lo acabo de ver encajar bien en el nombre.
_________________________________
¿Qué tal perfectminds?

Se me acaba de ocurrir con lo de imagine... imaginación ... mente
Es más corto y suena mejor unido al no tener una vocal después de la t.

Bueno, pues aquí va el tercer test ejecutable del GUI. Ahora no casca en los bordes ni hace cosas raras y en la vista de la derecha se ve la pantalla partida, luego irá a pantalla completa. Es un pelín más lento con la pantalla partida que sin ella porque lleva una comparación más dentro de un búcle, pero queda bastante chulo.

http://www.ojodigital.com/prawpblender/test3.rar

Un saludo:

Funciona perfecto con Vista 64
Con resolucion 1280 X1024 el tiempo que da en el boton 2 es de 0,73 Seg.
Con resolucion 1600X 1200 el tiempo es de 0.906 Seg.

GUAYYYY....

Lo he probado y me funciona perfectamente.
a 1280x1024 el tiempo en mi equipo (AMD Athlon x64 DualCore 5400+ y memoria 2GB) da 0,65
_________________________________
OOOPS

Lo había ejecutado y me funcionó perfectamente, pero he vuelto a ejecutarlo y resulta que ahora al pinchar en el botón 2 me da un error de acceso a memoria protegida.
Parece que el error se produce en el interior de la DLL de C que hace el escalado y dibujado.

Este es el error:

Código:

 
Consulte el final de este mensaje para obtener más detalles sobre cómo invocar a la depuración 
Just-In-Time (JIT) en lugar de a este cuadro de diálogo.
************** Texto de la excepción **************
System.AccessViolationException: Intento de leer o escribir en la memoria protegida. A menudo, esto indica que hay otra memoria dañada.
en test.Form1.FastDrawBiImage(Byte* buffer, Byte* buffer1, Byte* buffer3, Int32 width, Int32 height, Int32 width2, Int32 heigh2, Int32 extra, Int32 extra2, Int32 x, Int32 y, Single z, Byte color)
en test.Form1.button2_Click(Object sender, EventArgs e)

Si que está guapa la pantalla partida. Buena idea el botón dos con el calculo del rendimiento, en mi caso me da: entre 0.85 y 0.9 segundos (maximizada en pantalla de 1600x1200). Quiza quieras desglosar los bucles y el volcado ya que pueden ser distintos en distintas máquinas (con mas de un solo volcado y hacer la media)

Detallitos: La mitad izquierda de la pantalla partida me posteriza pero supongo que no es nada (es que aun no me entero del todo de que estás haciendo)
El boton2, si el preview derecho no esta "zoomado" me casca (memoria protegida) y cuando no casca el preview izquierdo desaparece (reaparece si haces clic y arrastras)

Oye los 1000 bucles son para construir el buffer de preview llamando al FastDrawImage que ponias? Alucino del rendimiento

Saludos!

Iniciado por truji

Detallitos: La mitad izquierda de la pantalla partida me posteriza pero supongo que no es nada (es que aun no me entero del todo de que estás haciendo)

Sí, he hecho un cálculo cutre para que se vea la diferencia entre las imágenes, no pretende ser otra cosa. Bastante que he controlado que no salgan valores de más de 255 .

Iniciado por truji

El boton2, si el preview derecho no esta "zoomado" me casca (memoria protegida) y cuando no casca el preview izquierdo desaparece (reaparece si haces clic y arrastras)

Sí, también es normal, toqué código pero no actualicé ese botón.

Iniciado por truji

Oye los 1000 bucles son para construir el buffer de preview llamando al FastDrawImage que ponias? Alucino del rendimiento

Sí, pero sólo saca por pantalla una vez al final de esas mil. Es para medir el tiempo de cálculo, no el de representación. Cuando metamos otras rutinas de volcado a pantalla se notará la diferencia.

Un saludo:
_________________________________
Ahora ya compilo las pruebas con VC++ (el C) y en el C# pongo CPU x86.
_________________________________
Estoy chateando con ariznaf a través del Messenger. Me he creado un usuario igual a mi mail.

Estamos hablando de quedar el lunes 16 de junio a las 19:00. Se me ocurre en el McDonalds de la plaza de los cubos por poner algo céntrico y localizable. dsamper dijo que tenía disponible una oficina, pero no sabemos nada de él últimamente.

La fecha/hora no se puede cambiar porque es la única tarde que ariznaf está en Madrid, pero el sitio es completamente tentativo.

¿Cómo tenéis esa fecha? Con los demás de fuera de Madrid será complicado quedar si no les viene bien esa fecha, podemos organizar otra quedada si avisáis de fechas en las que vendréis a Madrid.

Un saludo:

A mí no me funciona el test3. He bajado el archivo dos veces pero nada. Al ejecutarlo me da el siguiente error:

En detalles aparece lo siguiente:
Consulte el final de este mensaje para obtener más detalles sobre cómo invocar a la depuración
Just-In-Time (JIT) en lugar de a este cuadro de diálogo.

************** Texto de la excepción **************
System.DllNotFoundException: No se puede cargar el archivo DLL 'DLLtest.dll': No se pudo iniciar la aplicación porque su configuración es incorrecta. Reinstalar la aplicación puede solucionar el problema. (Excepción de HRESULT: 0x800736B1)
en test.Form1.FastDrawImage(Byte* buffer, Byte* buffer2, Int32 width, Int32 height, Int32 width2, Int32 heigh2, Int32 extra, Int32 extra2, Int32 x, Int32 y, Single z, Byte color)
en test.Form1.Form1_OnPaint(Object sender, PaintEventArgs e)
en System.Windows.Forms.Control.OnPaint(PaintEventArg s e)
en System.Windows.Forms.Form.OnPaint(PaintEventArgs e)
en System.Windows.Forms.Control.PaintWithErrorHandlin g(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
en System.Windows.Forms.Control.WmPaint(Message& m)
en System.Windows.Forms.Control.WndProc(Message& m)
en System.Windows.Forms.ScrollableControl.WndProc(Mes sage& m)
en System.Windows.Forms.ContainerControl.WndProc(Mess age& m)
en System.Windows.Forms.Form.WndProc(Message& m)
en System.Windows.Forms.Control.ControlNativeWindow.O nMessage(Message& m)
en System.Windows.Forms.Control.ControlNativeWindow.W ndProc(Message& m)
en System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)


************** Ensamblados cargados **************
mscorlib
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.1433 (REDBITS.050727-1400)
Código base: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
test
Versión del ensamblado: 1.0.0.0
Versión Win32: 1.0.0.0
Código base: file:///D:/Carlos%20Documentos/Borrar/Borrame/PerfectRAW/test.exe
----------------------------------------
System.Windows.Forms
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.1433 (REDBITS.050727-1400)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll
----------------------------------------
System
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.1433 (REDBITS.050727-1400)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll
----------------------------------------
System.Drawing
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.1433 (REDBITS.050727-1400)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll
----------------------------------------
mscorlib.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.1433 (REDBITS.050727-1400)
Código base: file:///C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll
----------------------------------------
System.Windows.Forms.resources
Versión del ensamblado: 2.0.0.0
Versión Win32: 2.0.50727.42 (RTM.050727-4200)
Código base: file:///C:/WINDOWS/assembly/GAC_MSIL/System.Windows.Forms.resources/2.0.0.0_es_b77a5c561934e089/System.Windows.Forms.resources.dll
----------------------------------------

************** Depuración JIT **************
Para habilitar la depuración Just In Time (JIT), el archivo de configuración de esta
aplicación o equipo (machine.config) debe tener el
valor jitDebugging establecido en la sección system.windows.forms.
La aplicación también se debe compilar con la depuración
habilitada

Por ejemplo:

<configuration>
<system.windows.forms jitDebugging="true" />
</configuration>

Cuando esté habilitada la depuración JIT, cualquier excepción no controlada
se enviará al depurador JIT registrado en el equipo
en lugar de controlarlo mediante el cuadro de diálogo.
__________________________________________________ _____

Espero que no sea grave.

Iniciado por ManuelLlorens

Es para medir el tiempo de cálculo, no el de representación:

Sí, lo que me sorprende son las de cálculo por lo rapidísimo. ¿Significa que estas rellenado un buffer-preview de -en mi caso- 800x900 de 3 bytes cada punto con el contenido de otro buffer de memoria y esto 1000 veces?

Ojo que si al final vas a tener los datos de origen en float y va a tener que haber algo de aritmética para pasarlos al buffer de destino el tiempo se puede incrementar del orden de x7 veces.

Carcamal:
Para poder saber qué pasa necesitaríamos la versión de windows que corres y detalles sobre la máquina.
Por ejemplo XP 32 o 64 bits, con o sin service pack y procesador.

Cuando déis informes de error, por favor poned ese tipo de información para ver si es un problema general o de una configuración de software/hardware concreta.

Iniciado por ManuelLlorens

Bueno, pues aquí va el tercer test ejecutable del GUI. Ahora no casca en los bordes ni hace cosas raras y en la vista de la derecha se ve la pantalla partida, luego irá a pantalla completa. Es un pelín más lento con la pantalla partida que sin ella porque lleva una comparación más dentro de un búcle, pero queda bastante chulo.

http://www.ojodigital.com/prawpblender/test3.rar

Un comentario rápido para decir que a mí me va estupendamente...

Sois la monda...

Daniel

Aquí tenemos una duda que llevo planteándome un tiempo:

Iniciado por ariznaf

Manuel, en el Form1_Load, al hacer el LockBits, estableces un PixelFormat.Format24bppRgb... eso ¿es sólo en esta prueba porque la imagen es un jpeg o debe de quedar así? ¿No debería de ser de 16bits por color, es decir Format48bppRgb? ¿O es que la imagen que llega aquí ya va a estar siempre convertida a 8bits?

Yo creo que para mostrar en pantalla 24bpp son suficientes, en muchos sitios se dice que el ojo no distingue entre 24bpp y 32bpp y el cálculo es mucho más rápido. Mi idea es mantener un buffer de 16bits devuelto por dcraw y convertirlo (una sola vez) a 8bits para representar. Para cálculos de balance de blanco e histograma tiramos del buffer de 16 bits. No sé si con esto será suficiente, ¿tú crees que para visualizar son necesarios 32bpp?

¿Qué opináis al respecto?

Un saludo:
_________________________________
http://www.ojodigital.com/prawpblender/Test4.rar

He compilado otra prueba para ver qué tal iba lo de hacer parpadear zonas de la imagen. Se me ocurre (pero seguro que _GUI_ me corrije), que se puede hacer parpadear en los siguientes casos (elegibles en la aplicación):

• Un canal seleccionado saturado (1, 2 ó los 3).
• Un solo canal cualquiera saturado.
• Dos o más canales cualesquiera saturados a la vez simultáneamente en algún píxel, pero no con uno solo.
• Los tres canales saturados a la vez.

Lo mismo pero para canales "empastados". ¿Opiniones?

Un saludo:

Manuel: me había explicado mal. Yo también creo que para mostrar en pantalla es suficiente con 24 bits.
Lo que no sabía era si el buffer de imagen que se pasaba para dibujar era el obtenido del revelador directamente (con 48 bits por consiguiente) o convertido a 24bits y corregido en gamma. Por lo que comentas veo que es el de 24 bits.