FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Convertir imagen bmp a jpeg
Hola. Necesito convertir una imagen en formato bmp (almacenada en memoria) a una imagen jpeg (también almacenada en memoria).
Uso delphi5 y windows xp. Ya se que se puede usar el método assign, pero mi aplicación obtiene un número elevado de imágenes bmp y necesito comprimirlas para enviarlas por la red y el método assign es demasiado lento. He podido comprobar que el cuello de botella de la aplicación se produce ahí. Si alguien conoce o sabe de algún componente o función que pueda aligerar este proceso le agredecería que me lo indicase. Gracias. |
#2
|
||||
|
||||
Es un tema que ya se ha tratado en los foros. Si haces una simple búsqueda encontrarás los mensajes.
Puedes empezar por éste: http://www.clubdelphi.com/foros/showthread.php?t=19613
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#3
|
|||
|
|||
Gracias por tu información, pero en todos los hilos que he encontrado, la única forma que indican de hacer la conversión de bmp a jpeg es mediante el método assign. Incluso en alguna página de borland he visto un ejemplo sobre esto. Funcionar funcionna perfectamente, pero mi pregunta es si algún componente, método o forma de hacer esto mismo pero de forma más rápida y eficiente de lo que lo hace el método assign.
|
#4
|
||||
|
||||
pues a mi me funciona perfectamente el método y muy rápido, y mira que yo trabajo con fotos satelitales y de vuelos... tengo un sistema que se maneja mediante una fila de espera via web y trabaja de maravilla el assign
|
#5
|
||||
|
||||
Hola.
Presumo que lo que hace el método assign es aplicar el algoritmo de compresión JPEG sobre la imagen. Supongo que usas el componente TJpegImage, que tendrá una implementación particular de este algoritmo; quizas esta implementación no sea muy buena, lamentablemente no tengo la experiencia suficiente como para juzgarlo, pero podes investigar por ese lado. Entonces queda la opción que encontres un componente con una implementación mas eficiente o que hagas la tuya propia. Ahora, siguiendo la idea de que quizas lo inapropiado aqui es la pregunta, en cuanto al planteamiento del problema que se hace, si lo que se pretende es mejorar el rendimiento del sistema, es probable que abriendo varios hilos de ejecución, que comprimirán varias imagenes en paralelo se tenga una ganancia considerable en el rendimiento. Tiene lógica ¿no?: Una aplicación comprimiendo 10 imagenes al mismo tiempo tendrá mejor rendimiento que una que comprime imagenes de una en una. Esto puede ser drámatico sobre todo con máquinas SMP. Tampoco es aconsejable desmedir el número de hilos... creo que será una buena fase de pruebas la que podrá arrojar luz sobre cual es el número ideal. Si el sistema es realmente crítico, también es aconsejable subir la prioridad de estos hilos a algun valor como tpHighest o tpTimeCritical, tomando en cuenta que esto tendrá gran impacto en el desempeño de otras aplicaciones, y claro, por último, tener lo mejor en hardware, en general: buen mainboard, memoria rápida, buenos procesadores y tanta memoria como sea posible. Podrias hacer un análisis detallado para determinar también cual es el hardware mas adecuado. Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#6
|
|||
|
|||
Gracias por vuestras respuestas. Os explico más detalladamente mi problema. Tengo una aplicación que captura 25 imágenes por segundo de una capturadora de 4 bocas, es decir 100 imágenes por segundo. Para colmo tengo 2 capturadoras, o sea 200 imágenes por segundo. Las capturadoras dan la imagen en bitmap y he podido comprobar lo siguiente: si grabo la imagen bmp directamente a disco me consigue grabar las 200 imágenes;si paso de tbitmap a tjpegimage pero no grabo, también me consigue las 200 imágenes por segundo; sin embargo, si paso de tbitmap a tjpegimage y luego grabo, no me consigue las 200 y el sistema se vuelve un poco "loco", no funciona del todo bien la aplicación.
La idea de los hilos no me parece adecuada ya que la aplicación ya dispone de bastantes hilos y no creo que se consiga un mayor rendimiento por la cantidad de hilos que hay ya corriendo. Quizás lo único que me quede por probar (porque ya pienso que a lo mejor lo que pretendo hacer es imposible, aunque los recursos del sistema no pasan del 70%) es encontrar un algoritmo (o algún componente) que pase de bmp a jpeg, es decir, tomar un tmemorystream con un bmp y pasarlo a un tmemorystream pero que contenga un jpeg. ¿Alguna idea? |
#7
|
||||
|
||||
¿cual es el porcentaje promedio de uso del procesador y de memoria? ¿los picos de memoria? ¿la cantidad de memoria física?
¿que tipo de hardware (procesadores, mainboard, etc?) Hasta luego.
__________________
Juan Antonio Castillo Hernández (jachguate) Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate |
#8
|
||||
|
||||
Cita:
Yo de capturadoras no sé nada pero se me ocurre que quizá almacene en archivos temporales las imágenes de manera que al grabarlas, la cachè del disco hace que sea casi inmediato mientras que al grabarlas ya con el nuevo formato no entra la cachè y se tiene en realidad dos grabaciones por imagen. // Saludos |
|
|
|