Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Principal > Gráficos
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 29-03-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Post 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.
Responder Con Cita
  #2  
Antiguo 29-03-2005
Avatar de Neftali [Germán.Estévez]
Neftali [Germán.Estévez] Neftali [Germán.Estévez] is offline
[becario]
 
Registrado: Jul 2004
Ubicación: Barcelona - España
Posts: 15.608
Poder: 10
Neftali [Germán.Estévez] Tiene un aura espectacularNeftali [Germán.Estévez] Tiene un aura espectacular
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.
Responder Con Cita
  #3  
Antiguo 29-03-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
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.
Responder Con Cita
  #4  
Antiguo 05-04-2005
Avatar de torito
torito torito is offline
Miembro
 
Registrado: Jun 2003
Ubicación: Querétaro, Mex.
Posts: 349
Poder: 16
torito Va por buen camino
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
Responder Con Cita
  #5  
Antiguo 05-04-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: May 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 22
jachguate Va por buen camino
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
Responder Con Cita
  #6  
Antiguo 06-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
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?
Responder Con Cita
  #7  
Antiguo 06-04-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: May 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 22
jachguate Va por buen camino
¿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
Responder Con Cita
  #8  
Antiguo 06-04-2005
Avatar de roman
roman roman is offline
Moderador
 
Registrado: May 2003
Ubicación: Ciudad de México
Posts: 20.172
Poder: 10
roman Tiene un aura espectacularroman Tiene un aura espectacular
Cita:
Empezado por mar646
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.
Pero, a juzgar por esta descripción, el cuello de botella no está en la transformación de bmp a jpg sino en la forma en que se graba el jpg a disco.

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
Responder Con Cita
  #9  
Antiguo 06-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Vamos a ver. El equipo es un pentium 4 a 3,2 GHz con 1GB de memoria RAM y 256 de memoria de video. vamos que el equipo no es un carcamal. Los niveles de memoria se mantienen perfectamente estables sobre 30 megas. Los recursos del sistema pasan de estar entre 25-30 % a un 75-80% con 7 cámaras visualizando y sólo 5 grabando a 25.

Otra cosa. He hecho la prueba de no grabar a disco pero si comprimir y pasarlo a un TMemoryStream. El resultado el mismo que si lo grabo a disco. Vamos que el equipo se ve que no le preocupa el guardarlo a disco.

Así que sigo pensando en que el problema está en la compresión a jpeg.

¿Alguna otra idea?
Responder Con Cita
  #10  
Antiguo 06-04-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: May 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 22
jachguate Va por buen camino
¿Que hay del uso del procesador?
__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #11  
Antiguo 07-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Perdona por no explicarlo bien.

Los recursos del sistema pasan de estar entre 25-30 % a un 75-80% con 7 cámaras visualizando y sólo 5 grabando a 25

Con esto me refería al procesador.
Responder Con Cita
  #12  
Antiguo 07-04-2005
Alfredo Alfredo is offline
Miembro
 
Registrado: Nov 2003
Ubicación: Valencia, Venezuela
Posts: 234
Poder: 15
Alfredo Va por buen camino
Solo una pregunta, el monitoreo es permanente o tiene un tiempo limite? es por si acaso es posible que guardes temporalemte las imagenes en memoria o descomprimidas y luego hagas la conversion en lote durante un periodo X.
Por otra parte tienes que tomar en cuenta que los datos se mueven en memoria mucho pero mucho mas rapido que en el disco duro; desconosco la velicidad del tuyo, lo mas probable es que este en el promedio de 8.5 ms, y estamos hablando de 200 imagenes por segundo, es correcto como haz escrito que el sistema de guarde la data en disco sin comprimir, pero una cosa muy distinta en que le mandes a realizar un proceso de tal magnitud (quiza si fueran menos imagenes, haz la prueba)... en el mismo interbalo de tiempo. No es muy dificil darse cuenta que el pico de botella esta en la grabacion al disco, aunque no nos dices si usas un ATA o SCSI drive. Mira este recorte:
"Using Seagate’s full-featured 16-bit Ultra
160 SCSI Low Voltage Differential (LVD)
interface, the Cheetah 36 LPs boast a
10,000-RPM spindle speed and provide
bus rates of up to 160 Mbytes per second.
It’s no wonder that Afanasieff notices the
difference between analog and digital seek
time: the Cheetah 36 LP has an average
seek time of a mere 5.2 msec."


Lo tome de esta direccion: http://www.seagate.com/docs/pdf/succ...v_brochure.pdf.

Mi recomendacion seria, aun si consiguieras un procedimiento de conversion mas optimo ( Lo ideal seria que pudieras capturar directamente en Jpg ), es que actualices el disco duro a uno mas rapido, tal como un Seagate Cheetah Scsi, o similar, que cuentan con apoyo para A/V Streams.
mira este enlace: http://www.seagate.com/products/disc...tah/index.html

Bueno, en todo caso no estara nada mal si nos informas de tus progresos, es un tema muy interesante y actual.

Bye.
__________________
if Vivir = Vivir + Aprender then Aprender = ?
Alfredo Borges
Responder Con Cita
  #13  
Antiguo 07-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Hola Alfredo. Sólo decirte que no creo que sea problema del disco duro. Te explico: otra fuente de video son las cámaras IP, las cuales si me proporcionan la imagen en JPEG. Según tu teoría, el disco duro no sería capaz de grabar más de las que es capaz de grabar con la otra fuente (capturadoras que dan la imagen en bmp). Pues bien, con las cámaras IP soy capaz de visualizar y grabar hasta 200 imágenes por segundo, mientras que con las capturadoras si las visualizo pero si las comprimo a jpeg no me consigue ni 120. Si no las comprimo, se acerca bastante a 200 imágenes por segundo pero también comprendo que una imagen bmp es mucho más grande y pesada para guardarla en disco.

Asi que no se puede ser. Mi último intento es el de limitar las capturadoras para visualizar menos y que el sistema esté menos cargado y también estoy mirando el de comprimir la imagen en el hilo que recoge la imagen del componente. Vamos que no sé que hacer!!!!!!

De todas formas muchas gracias por vuestras sugerencias y a ver si entre todos sacamos algo en claro.
Responder Con Cita
  #14  
Antiguo 07-04-2005
Alfredo Alfredo is offline
Miembro
 
Registrado: Nov 2003
Ubicación: Valencia, Venezuela
Posts: 234
Poder: 15
Alfredo Va por buen camino
Ok. pero me referia a la carga en tiempo que representa tener que convertir y luego guardar, es lo de tener que sincronizar la velocidad de la camara, conversion y grabacion de 200 imagenes en 1 seg!) quiza el equipo memoria-procesador pueda hacer su parte al comprimirlas pero mientras se estan grabando unas.... al segundo siguiente le vienen otro grupo y asi sucesivamente... (no se mucho de camaras ip - si idicas un link, buenisimo) pero lo que queria enfatizar es que hablamos (escribimos) de rendimiento...

quiza deberias probar con menos imagenes por segundo.... (nose siquiera si eso se puede, osea desacelerar la camara o algo asi)

chevere pues...
__________________
if Vivir = Vivir + Aprender then Aprender = ?
Alfredo Borges
Responder Con Cita
  #15  
Antiguo 07-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Mi idea, que probablemente me equivoque, es que el proceso de compresión de un tbitmap a un tjpegimage que realiza el delphi no es el más rápido y no es capaz de pasar de bmp a jpeg más de un número de imágenes. Lo que a mi me gustaría es optimizar este proceso (ya sé que puedo limitar la transferencia de la cámras IP, de las capturadoras aún no tengo ni idea pero espero conseguirlo más o menos pronto).

En cuanto termine la prueba de comprimir en varios hilos a la vez ya os contaré como me ha ido.
Responder Con Cita
  #16  
Antiguo 08-04-2005
Avatar de jachguate
jachguate jachguate is offline
Miembro
 
Registrado: May 2003
Ubicación: Guatemala
Posts: 6.243
Poder: 22
jachguate Va por buen camino
Cool

Cita:
Empezado por mar646
En cuanto termine la prueba de comprimir en varios hilos a la vez ya os contaré como me ha ido.
Dado que el procesador no parece estar ocupado al 100%, creo que es una buena decisión. Luego de haber comprimido las imágenes en distintos hilos podes serializar la grabación y mantener estadísticas de la "cola de grabación". Esto nos permitirá saber a ciencia cierta por donde se encontrará el cuello de botella. Si siempre hay imágenes pendientes de guardar, pues evidentemente será el disco.

Por otro lado... ¿la máquina tiene habilitado el HyperThreading?

Un Saludo.

__________________
Juan Antonio Castillo Hernández (jachguate)
Guía de Estilo | Etiqueta CODE | Búsca antes de preguntar | blog de jachguate
Responder Con Cita
  #17  
Antiguo 08-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Sí, si lo tiene activado.
Responder Con Cita
  #18  
Antiguo 09-04-2005
Avatar de Crandel
[Crandel] Crandel is offline
Miembro Premium
 
Registrado: May 2003
Ubicación: Parana, Argentina
Posts: 1.475
Poder: 17
Crandel Va por buen camino
Exclamation Algunas ideas

Hola mar646.
Te tiro un par de ideas para que pruebes.

* realiza un programa que convierta una imagen bmp que tengas en memoria a jpg, sin guardar en disco, para diferenctes tasas de compresión.
Esto te va a dar una idea de la velocidad del proceso de conversión.

* Al igual que la mayoria (aunque puede ser que nos equivoquemos) creo que el llamado a grabar en el disco puede estar limitando tu proceso. Dado que estas haciendo 200 pedidos por segundo de guardado en disco. Lo que es muy ineficiente.
La idea es guardar las imagenes agrupadas para reducir el numero de llamadas. Por ejemplo, guardar un avi, no lo hice nunca, pero seguramente debes poder guardar las 25 imagenes de un segundo de cada capturadora y recien guardar en disco. con eso el número de llamadas se reduce a 8 por segundo.

Espero que te ayude

Suerte
__________________
[Crandel]
Responder Con Cita
  #19  
Antiguo 11-04-2005
mar646 mar646 is offline
Miembro
 
Registrado: Dec 2004
Posts: 46
Poder: 0
mar646 Va por buen camino
Hola Crandel. Gracias por tus sugerencias. No creo que sea el problema el grabar a disco porque como comenté anteriormente, con otra fuente de video (cámaras IP), el equipo es capaz de grabar hasta 175 imágenes en un segundo y el equipo no sube demasiado en recursos.

Por otro lado, el realizar el avi tiene varios problemas. En primer lugar tiene un proceso de inicialización (por lo menos el componente que yo utilizo) y otro de cierre que no son muy rápidos que digamos, por lo que entre uno y otro puede haber pérdida de información. Por otro lado, la idea de guardar un avi es buena si queremos ahorrar espacio comprimiendo las imágenes en MEPG-4 o divx, pero este proceso es bastante pesado y no me consigue más de 3 o 4 imágenes por segundo. Por último, y lo más importante, es que si grabas 1 avi y antes de cerrarlo se apaga el equipo, pierdes toda la información que tenías almacenada en ese avi.

Como comenté, estoy haciendo pruebas con hilos y puede ser, sólo puede ser , que haya mejoras.
Responder Con Cita
  #20  
Antiguo 12-04-2005
Avatar de Crandel
[Crandel] Crandel is offline
Miembro Premium
 
Registrado: May 2003
Ubicación: Parana, Argentina
Posts: 1.475
Poder: 17
Crandel Va por buen camino
otra idea

Hola mar646, te tiro otra sugerencia.

Posiblemente para convertir cada imagen estes llamando a la funcio BMP2JPG que anda dando vueltas por ahi.
En esa funcion, se crean dos variables ( TBitmap y TJpegImage ), esta creación y destrucción de las variables podria llevar tiempo, no lo se.

Podes definirlas como globales para ver como se porta.

Suerte

Crandel
__________________
[Crandel]
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 01:02:46.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi