libjpeg-turbo

libjpeg-turbo es un código abierto, multiplataforma y de software completamente libre diseñado para proporcionar una versión de alta velocidad del software original biblioteca libjpeg, específicamente diseñada para los procesadores x86 y x86-64, que utilizan SIMD ( Single Instruction, Multiple Data instrucciones), tales como SSE2, MMX y neón, para acelerar la línea de base de descompresión y compresión JPEG.

El software es una imagen extremadamente rápido codec JPEG que es generalmente 2-4x más rápido que la versión no modificada de libjpeg. El proyecto se basó originalmente en el proyecto libjpeg / SIMD creado por Masaru Miyasaka.

Esta versión turbo de la biblioteca libjpeg también implementa el API libjpeg tradicional, así como la API TurboJPEG sencillo. Cuenta con extensiones colorspace, que permite a los usuarios para comprimir o descomprimir a partir de tampones big-endian y 32 bits de píxeles (XBGR, RGBX, etc.), y una interfaz con todas las funciones de Java.

Para su comodidad, el software se distribuye como instaladores nativos para DEB y sistemas operativos basados ​​en RPM, como Debian, Ubuntu, Linux Mint, Fedora, CentOS, Fedora, openSUSE, Mageia, etc., apoyando tanto 64 y 32 bits plataformas de hardware.

El proyecto libjpeg-turbo se puede instalar fácilmente desde los principales repositorios de software de una distribución de GNU / Linux. También se instalará automáticamente junto con cualquier software que lo requiera.

Para instalar de forma manual utilizando el paquete de origen, en caso de que desee para optimizarlo para su arquitectura de hardware / sistema operativo, descargar y guardar el último archivo de Softoware, extraer su contenido mediante una utilidad de gestor de archivos, abra una aplicación de terminal y vaya a la ubicación del archivo de almacenamiento extraído (por ejemplo cd / home / softoware / libjpeg-turbo).

A continuación, ejecute el y lsquo; ./ configure && make y rsquo; comando para configurar y compilar el programa, seguido de la etiqueta & lsquo; sudo make install y rsquo; commad instalarlo todo el sistema y ponerlo a disposición de todas las aplicaciones

¿Qué hay de nuevo en esta versión:.

< li> Se ha corregido un problema de acumulación en plataformas OS X para PowerPC (md5cmp fracasó en la construcción debido OS X no proporciona la le32toh () y htole32 () funciones.).
• El color RGB565 código de conversión no SIMD no funcionaba correctamente en máquinas big endian. Esto se ha solucionado.
• Se ha solucionado un problema en tjPlaneSizeYUV (), por lo que volvería erróneamente 1 en lugar de -1 en caso de componente de la era & gt; 0 y subsamp fue TJSAMP_GRAY.
• Se ha solucionado un problema en tjBufSizeYUV2 () wherby sería erróneamente devolver 0 en lugar de -1 si el ancho era & lt; 1.
• El codificador Huffman ahora utiliza instrucciones clz y BSR para contar bits en plataformas ARM64.
• El método close () en las clases y TJCompressor TJDecompressor Java está ahora idempotente. Anteriormente, ese método sería llamar a la función nativa tjDestroy () incluso si la instancia TurboJPEG ya había sido destruido. Esto provocó una excepción que se lance durante la finalización, si el método close () ya había sido llamado. La excepción fue capturado, pero seguía siendo una operación costosa.
• La API TurboJPEG generado previamente un error (& quot; No se pudo determinar el tipo de submuestreo de imagen JPEG & quot de;) al intentar descomprimir las imágenes JPEG en escala de grises que se comprimieron con un factor de muestreo diferente de 1 (por ejemplo, con 'cjpeg -grayscale - 2x2 muestra '). Submuestreo técnicamente no tiene sentido con archivos JPEG en escala de grises, y por lo tanto los factores de muestreo horizontal y vertical para este tipo de imágenes son ignorados por el descompresor. Sin embargo, la API TurboJPEG estaba siendo demasiado rígido y estaba esperando los factores de muestreo que es igual a 1 antes de que se trata la imagen como un archivo JPEG en escala de grises.
• cjpeg, djpeg, y jpegtran ahora aceptan un argumento de -versión, que imprimirá la versión de biblioteca y salir.
• Haciendo referencia a 1.4 beta1 [15], otra circunstancia extremadamente rara se descubrió en las que memoria intermedia local del codificador Huffman puede ser invadida cuando se está utilizando un gestor de destino tamponada y un bloque extremadamente alta frecuencia (básicamente datos de imagen deseado) es siendo codificada. A pesar de que la memoria intermedia local de Huffman se aumentó de 128 bytes a 136 bytes para abordar la cuestión anterior, el nuevo tema causó incluso el búfer mayor para ser invadido. Un análisis más detallado revela que, en el peor caso (como el establecimiento de coeficientes AC alternas a 32767 -32768 y en el orden de exploración JPEG), el codificador Huffman puede producir bloques codificados que se acercan a duplicar el tamaño de los bloques no codificados. De este modo, la memoria intermedia local de Huffman se aumentó a 256 bytes, que debe evitar que cualquier problema vuelva a ocurrir en el futuro.
• El nuevo tjPlaneSizeYUV (), tjPlaneWidth (), funciones y tjPlaneHeight () no eran realmente utilizable en cualquier plataforma excepto OS X y Windows, ya que esas funciones no fueron incluidos en el archivo de asignaciones libturbojpeg. Esto se ha solucionado.
• restauró la JPP (JMETHOD), (), y macros que va de los archivos de cabecera libjpeg-turbo. Las macros JPP () y JMETHOD () se llevaron a cabo originalmente en libjpeg como una forma de apoyar a los compiladores no ANSI que carecían de apoyo para los parámetros de prototipo. libjpeg-turbo nunca ha apoyado este tipo de compiladores, pero algunos paquetes de software todavía utilizar las macros para definir sus propios prototipos. Del mismo modo, libjpeg-turbo nunca ha apoyado MS-DOS y otras plataformas que tienen símbolos lejanos, pero algunos paquetes de software todavía utilizar la macro FAR. Un muy buen argumento se puede hacer que esta es una mala práctica por parte del software en cuestión, pero como esto afecta a más de un paquete, es simplemente más fácil de arreglar aquí.
• Se han corregido problemas que impedían el código ARM SIMD de 64 bits de compilación para iOS, y que se incluyen una arquitectura ARMv8 en todos los binarios instalados por el & quot; oficial & quot; SDK libjpeg-turbo para OS X.

¿Qué hay de nuevo en la versión 1.4.2:

• Se ha corregido un problema de acumulación en plataformas OS X para PowerPC ( md5cmp fracasó en la construcción debido OS X no proporciona la le32toh () y htole32 () funciones.).
• El color RGB565 código de conversión no SIMD no funcionaba correctamente en máquinas big endian. Esto se ha solucionado.
• Se ha solucionado un problema en tjPlaneSizeYUV (), por lo que volvería erróneamente 1 en lugar de -1 en caso de componente de la era & gt; 0 y subsamp fue TJSAMP_GRAY.
• Se ha solucionado un problema en tjBufSizeYUV2 () wherby sería erróneamente devolver 0 en lugar de -1 si el ancho era & lt; 1.
• El codificador Huffman ahora utiliza instrucciones clz y BSR para contar bits en plataformas ARM64.
• El método close () en las clases y TJCompressor TJDecompressor Java está ahora idempotente. Anteriormente, ese método sería llamar a la función nativa tjDestroy () incluso si la instancia TurboJPEG ya había sido destruido. Esto provocó una excepción que se lance durante la finalización, si el método close () ya había sido llamado. La excepción fue capturado, pero seguía siendo una operación costosa.
• La API TurboJPEG generado previamente un error (& quot; No se pudo determinar el tipo de submuestreo de imagen JPEG & quot de;) al intentar descomprimir las imágenes JPEG en escala de grises que se comprimieron con un factor de muestreo diferente de 1 (por ejemplo, con 'cjpeg -grayscale - 2x2 muestra '). Submuestreo técnicamente no tiene sentido con archivos JPEG en escala de grises, y por lo tanto los factores de muestreo horizontal y vertical para este tipo de imágenes son ignorados por el descompresor. Sin embargo, la API TurboJPEG estaba siendo demasiado rígido y estaba esperando los factores de muestreo que es igual a 1 antes de que se trata la imagen como un archivo JPEG en escala de grises.
• cjpeg, djpeg, y jpegtran ahora aceptan un argumento de -versión, que imprimirá la versión de biblioteca y salir.
• Haciendo referencia a 1.4 beta1 [15], otra circunstancia extremadamente rara se descubrió en las que memoria intermedia local del codificador Huffman puede ser invadida cuando se está utilizando un gestor de destino tamponada y un bloque extremadamente alta frecuencia (básicamente datos de imagen deseado) es siendo codificada. A pesar de que la memoria intermedia local de Huffman se aumentó de 128 bytes a 136 bytes para abordar la cuestión anterior, el nuevo tema causó incluso el búfer mayor para ser invadido. Un análisis más detallado revela que, en el peor caso (como el establecimiento de coeficientes AC alternas a 32767 -32768 y en el orden de exploración JPEG), el codificador Huffman puede producir bloques codificados que se acercan a duplicar el tamaño de los bloques no codificados. De este modo, la memoria intermedia local de Huffman se aumentó a 256 bytes, que debe evitar que cualquier problema vuelva a ocurrir en el futuro.
• El nuevo tjPlaneSizeYUV (), tjPlaneWidth (), funciones y tjPlaneHeight () no eran realmente utilizable en cualquier plataforma excepto OS X y Windows, ya que esas funciones no fueron incluidos en el archivo de asignaciones libturbojpeg. Esto se ha solucionado.
• restauró la JPP (JMETHOD), (), y macros que va de los archivos de cabecera libjpeg-turbo. Las macros JPP () y JMETHOD () se llevaron a cabo originalmente en libjpeg como una forma de apoyar a los compiladores no ANSI que carecían de apoyo para los parámetros de prototipo. libjpeg-turbo nunca ha apoyado este tipo de compiladores, pero algunos paquetes de software todavía utilizar las macros para definir sus propios prototipos. Del mismo modo, libjpeg-turbo nunca ha apoyado MS-DOS y otras plataformas que tienen símbolos lejanos, pero algunos paquetes de software todavía utilizar la macro FAR. Un muy buen argumento se puede hacer que esta es una mala práctica por parte del software en cuestión, pero como esto afecta a más de un paquete, es simplemente más fácil de arreglar aquí.
• Se han corregido problemas que impedían el código ARM SIMD de 64 bits de compilación para iOS, y que se incluyen una arquitectura ARMv8 en todos los binarios instalados por el & quot; oficial & quot; SDK libjpeg-turbo para OS X.

¿Qué hay de nuevo en la versión 1.4.0:

• Se ha corregido un problema de acumulación en plataformas OS X para PowerPC ( md5cmp fracasó en la construcción debido OS X no proporciona la le32toh () y htole32 () funciones.).
• El color RGB565 código de conversión no SIMD no funcionaba correctamente en máquinas big endian. Esto se ha solucionado.
• Se ha solucionado un problema en tjPlaneSizeYUV (), por lo que volvería erróneamente 1 en lugar de -1 en caso de componente de la era & gt; 0 y subsamp fue TJSAMP_GRAY.
• Se ha solucionado un problema en tjBufSizeYUV2 () wherby sería erróneamente devolver 0 en lugar de -1 si el ancho era & lt; 1.
• El codificador Huffman ahora utiliza instrucciones clz y BSR para contar bits en plataformas ARM64.
• El método close () en las clases y TJCompressor TJDecompressor Java está ahora idempotente. Anteriormente, ese método sería llamar a la función nativa tjDestroy () incluso si la instancia TurboJPEG ya había sido destruido. Esto provocó una excepción que se lance durante la finalización, si el método close () ya había sido llamado. La excepción fue capturado, pero seguía siendo una operación costosa.
• La API TurboJPEG generado previamente un error (& quot; No se pudo determinar el tipo de submuestreo de imagen JPEG & quot de;) al intentar descomprimir las imágenes JPEG en escala de grises que se comprimieron con un factor de muestreo diferente de 1 (por ejemplo, con 'cjpeg -grayscale - 2x2 muestra '). Submuestreo técnicamente no tiene sentido con archivos JPEG en escala de grises, y por lo tanto los factores de muestreo horizontal y vertical para este tipo de imágenes son ignorados por el descompresor. Sin embargo, la API TurboJPEG estaba siendo demasiado rígido y estaba esperando los factores de muestreo que es igual a 1 antes de que se trata la imagen como un archivo JPEG en escala de grises.
• cjpeg, djpeg, y jpegtran ahora aceptan un argumento de -versión, que imprimirá la versión de biblioteca y salir.
• Haciendo referencia a 1.4 beta1 [15], otra circunstancia extremadamente rara se descubrió en las que memoria intermedia local del codificador Huffman puede ser invadida cuando se está utilizando un gestor de destino tamponada y un bloque extremadamente alta frecuencia (básicamente datos de imagen deseado) es siendo codificada. A pesar de que la memoria intermedia local de Huffman se aumentó de 128 bytes a 136 bytes para abordar la cuestión anterior, el nuevo tema causó incluso el búfer mayor para ser invadido. Un análisis más detallado revela que, en el peor caso (como el establecimiento de coeficientes AC alternas a 32767 -32768 y en el orden de exploración JPEG), el codificador Huffman puede producir bloques codificados que se acercan a duplicar el tamaño de los bloques no codificados. De este modo, la memoria intermedia local de Huffman se aumentó a 256 bytes, que debe evitar que cualquier problema vuelva a ocurrir en el futuro.
• El nuevo tjPlaneSizeYUV (), tjPlaneWidth (), funciones y tjPlaneHeight () no eran realmente utilizable en cualquier plataforma excepto OS X y Windows, ya que esas funciones no fueron incluidos en el archivo de asignaciones libturbojpeg. Esto se ha solucionado.
• restauró la JPP (JMETHOD), (), y macros que va de los archivos de cabecera libjpeg-turbo. Las macros JPP () y JMETHOD () se llevaron a cabo originalmente en libjpeg como una forma de apoyar a los compiladores no ANSI que carecían de apoyo para los parámetros de prototipo. libjpeg-turbo nunca ha apoyado este tipo de compiladores, pero algunos paquetes de software todavía utilizar las macros para definir sus propios prototipos. Del mismo modo, libjpeg-turbo nunca ha apoyado MS-DOS y otras plataformas que tienen símbolos lejanos, pero algunos paquetes de software todavía utilizar la macro FAR. Un muy buen argumento se puede hacer que esta es una mala práctica por parte del software en cuestión, pero como esto afecta a más de un paquete, es simplemente más fácil de arreglar aquí.
• Se han corregido problemas que impedían el código ARM SIMD de 64 bits de compilación para iOS, y que se incluyen una arquitectura ARMv8 en todos los binarios instalados por el & quot; oficial & quot; SDK libjpeg-turbo para OS X.

¿Qué es la nueva en la versión 1.3.0:

• [1] 'make test' ahora funciona correctamente en FreeBSD, y ya no requiere el ejecutable md5sum estar presente en otros UN * x plataformas.
• [2] Overhauled el sistema de envasado: - Para evitar conflictos con los paquetes de libjpeg-turbo que ofrece el proveedor, los RPMs oficiales y DEBs para libjpeg-turbo han cambiado de nombre a & quot; libjpeg-turbo-oficial de & quot ;. - Las bibliotecas TurboJPEG se encuentran ahora en / opt / libjpeg-turbo en los paquetes oficiales de Linux y Mac, para evitar conflictos con los paquetes suministrados por el proveedor y también para agilizar el sistema de envasado. - paquetes de la versión ahora se crean con la estructura de directorios definida por las variables de configure & quot; prefijo & quot ;, & quot; bindir & quot ;, & quot; libdir & quot ;, etc. (Un * x) o por la variable CMAKE_INSTALL_PREFIX (Windows). La excepción es que los documentos siempre se encuentran en el directorio por defecto del sistema de documentación sobre Un * x y sistemas Mac y en Windows, el archivo DLL TurboJPEG siempre se encuentra en el directorio de sistema de Windows. - Para evitar confusiones, los paquetes oficiales libjpeg-turbo en plataformas Linux / Unix (excepto para Mac) siempre instalar las bibliotecas de 32 bits en / opt / libjpeg-turbo / lib32 y las bibliotecas de 64 bits en / opt / libjpeg- turbo / lib64. - Se ha corregido un problema por el que, en algunos casos, los ejecutables libjpeg-turbo de Un * x sistemas no se vinculan correctamente con las bibliotecas compartidas instaladas por el mismo paquete. - Se ha solucionado un problema por el que la construcción de la & quot; & quot instalador; objetivo en Windows cuando WITH_JAVA = 1 fallaría si el frasco TurboJPEG no había sido construido con anterioridad. - La construcción de la & quot; instalar & quot; objetivo en Windows ahora instala archivos en los mismos lugares que hace el programa de instalación.
• [3] Se ha corregido un error que impedía codificador Huffman suspensión de E / S funcione correctamente.

¿Qué hay de nuevo en la versión 1.2.0:

• Una cuestión acumulación encontró cuando se utiliza en los sistemas Unix YASM se fija.
• Se sale fuera de la lectura en el código SIMD SSE2 se fijó.
• Nuevos constantes de extensión espacio de color que permiten a las aplicaciones especifican que el byte sin utilizar en un buffer RGB de 4 bytes debe ser tratado como un canal alfa al descomprimir se han añadido.
• Una cuestión de regresión se encontró en la construcción de Diablo con libjpeg-turbo ha sido fijado.
• Soporte de iOS se añadió a la SDK libjpeg-turbo para Mac.

¿Qué hay de nuevo en la versión 1.1 Beta 1:

• libjpeg-turbo puede ser construido para emular el libjpeg API v7 o v8b / ABI.
• El sistema de compilación de Windows ahora utiliza CMake.
• TurboJPEG / OSS ahora puede comprimir desde / descomprimir los mapas de bits de escala de grises a RGB y convertir imágenes JPEG o de salida plana YUV.
• jpgtest se puede utilizar para probar el rendimiento de descompresión con imágenes JPEG existentes.
• Se añadió opcional aritmética de codificación y decodificación de apoyo.

Se añadieron
• Otras protecciones contra los códigos de Huffman no válidos.

¿Qué hay de nuevo en la versión 1.0.0:.

• Además construir mejoras en FreeBSD
• paquetes de Unix / Linux incluyen ahora libjpeg tiempo de ejecución de programas (cjpeg, etc.) y las páginas de manual.
• Hay un paquete adicional de 32 bits para sistemas Debian amd64.
• Soporte Cygwin.
• Soporte completo para la construcción / prueba en arquitecturas diferentes a x86.

binarios OS
• 64 bits X son ahora compatible con OS X 10.4.
• Hay varios ajustes de embalaje Linux.

¿Qué hay de nuevo en la versión 0.0.91:

• Añadido documentación para los paquetes .deb

problemas de corrupción
• Los datos fijos al descomprimir las imágenes JPEG grandes y / o el uso de búfer de E / S con el descompresor libjpeg-turbo