Tamaño de Imagenes

[manuramos]

Pregunta: ¿Tiene algo que ver el tamaño de una imagen para que TIMAGE la lea o no la lea?.
Me explico. Estoy haciendo un módulo de presentación de fotografías, para poder visualizar diversos formatos de mapas de bits. Utilizo para ello la clase TIMAGE como es lógico (con NViewLib32), pero resulta que los ficheros JPG de más de un mega no los lee ( me da: nWidth=0 y nHeight=0 ). Sin embargo si la achico con un programa de edición de fotos hasta ocupe 700k o por ahí si la lee. Lo mismo ocurre con BMP de más de 5 megas.
¿Hay forma de solventar ese inconveniente (terrible para mi programa por cierto)?

[manuramos]

Por cierto, alguien tiene un ejemplo de cómo se utiliza la clase TIMAGLIST, o al menos que me diga que hace o que aspecto presenta en pantalla.

[manuramos]

Por último. ¿Es obligatorio el uso de PALBMPNEW?.
Pues lo utilize o no lo utilize, el resultado en pantalla es el mismo. Y PALBMPFREE no me da error.

[R.F.]

Efectivamente, el NViewlib tiene problemas con algunos tipos de ficheros JPG, lo mejor que puedes hacer es utilizar la clase FREEIMAGE, que utiliza el DLL del mismo nombre (FREEIMAGE) y que no requiere ningun cambio en tu codig fuente, solo agregar el PRG de la FREEIMAGE

[manuramos]

Gracias René, lo probaré.
¿Sirve para todo tipo de gráficos, o sólo para JPG?

Un saludo...

[manuramos]

No se si lo estroy haciendo mal, pero me da la impresión de que FreeImage está pensada para programar en 32 bits. O al menos, con el XP me da error.

Consigo abrir la librería "manualmente" pero después me da error en la librería GDI32.dll (.Por cierto, FreeImage tiene más de 8 carácteres y no se abre en XP con LoadLibrary ni a tiros. (A 16 bits con ese nombre).

El caso es que tengo un problema de cuidado. Pues con Windows 95,98 y WinMe se pueden abrir la mayoría de gráficos con nViewLib, pero en XP TImage utiliza nViewl16 (16 bits), en lugar de nViewlib (32 bits), pues pasa por la zona:

if ! ( IsWin95() )
::hBitmap = NViewLibLoad( AllTrim( cBmpFile ), ::nProgress )
else
::hBitmap = NViewLib32( AllTrim( cBmpFile ), ::nProgress )
endif

y como no es W95 pues abre nViewl16.

El problema es que con XP, si fuerzo la apertura de nViewlib, estás devuelve handles de más de 10 dígitos, algunos incluso, negativos. He intentado acortarlo con nLowWord(), nHiWord(), con una mezcla de ambos o restando 65536 antes o después de aplicar las funciones. Pero nada de nada. Por fortuna FreeImage me dió la idea de utilizar:
hBmp = nLoWord( WOWHandle16(hBmp, 8 ) ) ¡Y funciona!

El problema es que no lee ni la mitad de gráficos que con nViewl16. Utilizaría nViewl16, el problema es que con esa librería si un gráfico no lo puede leer te saca un mensaje de advertencia. Como mi programa ya tiene su propio sistema de mensajes (muy elaborado) y durante la lectura del albúm muestra un "Espere un momento, Por favor..." pues el programa se queda colgado hasta que se cierre el mensaje de la librería (que casualmente aparece por debajo del mío.).

Y si utilizo nViewlib, no da error si no lee un fichero, pero no lee tantos como con nViewl16. Por ahora he programado una solución de compromiso. Abro lo que puedo con nViewlib y lo demás si no es muy grande con nViewl16 rezando para que no se cuelgue. Será cuestión de advertir al cliente. No deja de ser una solución a medias.

Si alguién tiene alguna idea, le agradecería la ayuda.

Un saludo