¿Hay un algoritmo de compresión que sea más rápido que JPEG pero bien soportado? Conozco jpeg2000 pero, por lo que he escuchado, no es mucho más rápido.¿Hay una compresión con pérdida más rápida que JPEG?
Edición: para comprimir.
Edit2: Debería ejecutarse en Linux de 32 bits e idealmente debería estar en C o C++.
La codificación Jpeg y la decodificación deben ser extremadamente rápido. Te resultará difícil encontrar un algoritmo más rápido. Si es lento, su problema probablemente no sea el formato sino una mala implementación del codificador. Pruebe el codificador desde libavcodec en el proyecto ffmpeg.
La codificación JPEG está diseñada para una decodificación rápida. Esto no siempre significa que también tiene una codificación rápida (de hecho, muchas veces es mucho más lento codificar). –
Ambos son extremadamente rápidos si no se esfuerza por la codificación óptima. Un x86 de gama baja de los últimos años debería ser capaz de codificar jpeg a una velocidad de 30 megapíxeles por segundo o mejor (estimación aproximada de la parte superior de mi cabeza). –
Un codificador destinado a la codificación de video está destinado a ser optimizado para la velocidad. Sé que MJPEG ha sido bastante rápido durante años, aunque siempre pensé que se necesitaba hardware especializado para lograrlo. –
¿En qué contexto? En una PC o un dispositivo portátil?
Desde mi experiencia que tienes JPEG, JPEG2000, PNG, y ... uh, eso es todo para este tipo de "bien apoyado" imagen en un contexto amplio (con pérdidas o no!)
(Hooray ese GIF está a punto de desaparecer.)
Me atrevería a decir que JPEG2000 no es universal, por lo que la lista es solo JPEG y PNG. –
Las patentes de LZW han expirado al menos en partes de Europa, por lo que no hay una razón real para evitar GIF, excepto por su espacio de color limitado. Y eso se puede eludir (aunque bastante feo). – onemasse
Es para un robot embebido de Linux. –
JPEG2000 no es más rápido en absoluto. ¿Es codificación o decodificación que no es lo suficientemente rápido con jpeg? Probablemente puedas ser mucho más rápido haciendo solo 4x4 FDCT e IDCT en jpeg.
Es difícil encontrar documentación sobre IJG libjpeg, pero si usa eso, intente bajar la configuración de calidad, podría hacerlo más rápido, también parece que hay una opción rápida de FDCT.
Alguien mencionó libjpeg-turbo que usa instrucciones SIMD y es compatible con el libjpeg regular. Si esa es una opción para ti, creo que deberías intentarlo.
Es la codificación de imágenes binarias a JPEG que es demasiado lenta en mi robot embebido de Linux. –
@Richard Knop: ¿Binario? Como en negro/blanco sin gris y sin color? Eso cambia las cosas considerablemente. –
@Mark Ransom. Fui imágenes binarias como imágenes "en bruto". Ellos son coloridos. –
Creo que los algoritmos de compresión basados en wavelets son en general más lentos que los que usan DCT. Tal vez deberías echar un vistazo a los formatos JPEG XR y WebP.
¿Tiene instrucciones MMX/SSE2 disponibles en su arquitectura de destino? Si es así, puede intentar libjpeg-turbo. Alternativamente, ¿puede comprimir las imágenes con algo como zlib y luego descargar la reducción real a otra máquina? ¿Es imperativo que la compresión con pérdida real de las imágenes tenga lugar en el propio dispositivo integrado?
la licencia para libjpeg-turbo es lgpl = no correcta para proyectos de fuente abierta comercial o verdadera/real. –
La compresión 'zlib' es varias veces más lenta que la compresión jpeg. –
png utiliza compresión zlib. zlib es doloroso con incrustado, el código no está realmente limpio 32/64 y las compilaciones cruzadas son deficientes y requieren mucha RAM en su configuración predeterminada. Depende de qué tan incrustado estés. –
Simplemente puede cambiar el tamaño de la imagen a una más pequeña si no requiere la fidelidad de la imagen completa. Promediar cada bloque de 2x2 en un solo píxel reducirá el tamaño a 1/4 muy rápidamente.
A menos que escriba algún código extremadamente optimizado para realizar la reducción a escala, realizar la compresión jpeg con 'libavcodec' probablemente demorará menos tiempo que su código de reducción a escala. –
@R, ¿no es el algoritmo que sugerí capaz de ser extremadamente optimizado con mucha facilidad? –
Sí, si lo escribe en asm, pero dudo que una implementación pura de C de ese algoritmo de reducción de escala pueda vencer al codificador jpeg de libavcodec, al menos no con la tecnología de compilación actual. –
para descomprimir o comprimir? – tenfour
Simplemente curioso, ¿por qué las imágenes deben ser comprimidas? ¿Y por cuánto? –
@Mark Ransom: Bueno, los necesito comprimidos para enviarlos desde un pequeño robot humanoide con CPU de 500Mhz y 256MB de RAM a una PC para su procesamiento. Necesito llegar a al menos 20 imágenes por segundo y el wifi stick no es lo suficientemente rápido para enviar esa cantidad de datos durante 1 segundo, así que estoy usando JPEG para disminuir el ancho de banda. –