Convertir imagen bmp a jpeg

[mar646]

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?

[jachguate]

¿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.

[roman]

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

[mar646]

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?

[jachguate]

¿Que hay del uso del procesador?

[mar646]

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.

[Alfredo]

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.

[mar646]

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.