libjpeg-turbo

libjpeg-turbo est une open source, multi-plateforme et un logiciel entièrement gratuit conçu pour fournir une version à haute vitesse du logiciel de bibliothèque libjpeg original, spécialement conçu pour x86 et x86-64 processeurs, qui utilisent SIMD ( Single Instruction, multiple Data) des instructions, comme SSE2, MMX et NEON, pour accélérer la décompression JPEG de base et la compression.

Le logiciel est une image JPEG codec extrêmement rapide qui est généralement 2-4x plus rapide que la version non modifiée de libjpeg. Le projet était initialement basée sur le libjpeg / projet SIMD créé par Miyasaka Masaru.

Cette version turbo de la bibliothèque libjpeg met également en œuvre l'API libjpeg traditionnelle, ainsi que l'API TurboJPEG simple. Il dispose d'extensions de ColorSpace, ce qui permet aux utilisateurs de compresser ou à décompresser au big-endian et 32 ​​bits des tampons de pixels (XBGR, RGBX, etc.), et une interface Java complet.

Pour votre commodité, le logiciel est distribué en tant installateurs natifs pour DEB et systèmes d'exploitation basés sur RPM, comme Debian, Ubuntu, Linux Mint, Fedora, CentOS, Red Hat Enterprise Linux, openSUSE, Mageia, etc., supportant à la fois 64 et 32 ​​bits plates-formes matérielles.

Le projet libjpeg-turbo peut être facilement installé à partir des principaux dépôts de logiciels d'une distribution GNU / Linux. Il sera également installé automatiquement en même temps avec tous les logiciels qui l'exige.

Pour l'installer manuellement à l'aide du paquet source, dans le cas où vous souhaitez optimiser pour votre architecture matérielle / système d'exploitation, télécharger et enregistrer la dernière archive à partir de Softoware, extraire son contenu en utilisant un utilitaire de gestion d'archives, ouvrez une application Terminal et aller à l'emplacement du fichier archive extraite (par exemple cd / home / softoware / libjpeg-turbo).

Ensuite, exécutez le & lsquo; ./ configure && make & rsquo; commande pour configurer et compiler le programme, suivi par le & lsquo; sudo make install & rsquo; commad à installer l'ensemble du système et de le rendre disponible à toutes les applications

Ce qui est nouveau dans cette version:.

< li> Correction d'un problème de construction sur les plates-formes OS X PowerPC (md5cmp n'a pas réussi à construire parce que OS X ne fournit pas la le32toh () et htole32 () fonctions.).
• La couleur RGB565 code de conversion non-SIMD ne fonctionnait pas correctement sur les grosses machines endian. Ceci a été corrigé.
• Correction d'un problème dans tjPlaneSizeYUV () par laquelle il serait à tort revenir 1 au lieu de -1 si ComponentID était & gt; 0 et subsamp était TJSAMP_GRAY.
• Correction d'un problème dans tjBufSizeYUV2 () wherby il serait à tort retourner 0 au lieu de -1 si la largeur était & lt; 1.
• Le codeur Huffman utilise maintenant CLZ et bsr instructions pour le bit de comptage sur les plates-formes ARM64.
• La méthode close () dans les classes TJCompressor et TJDecompressor Java est maintenant idempotent. Auparavant, cette méthode serait d'appeler la fonction tjDestroy native () même si l'instance TurboJPEG avait déjà été détruite. Cela a provoqué une levée de l'exception lors de la finalisation, si la méthode close () avait déjà été appelé. L'exception a été capturé, mais il était encore une opération coûteuse.
• L'API TurboJPEG précédemment généré une erreur (& quot; Impossible de déterminer le type de sous-échantillonnage pour les images JPEG & quot;) lors d'une tentative pour décompresser les images JPEG en niveaux de gris qui ont été compressés avec un facteur d'échantillonnage autre que 1 (par exemple, avec 'cjpeg -grayscale - 2x2 échantillon »). Sous-échantillonnage technique n'a pas de sens avec les fichiers JPEG en niveaux de gris, et donc les facteurs horizontaux et verticaux échantillonnage pour ces images sont ignorées par le décompresseur. Cependant, l'API TurboJPEG fit preuve de trop rigide et attendait les facteurs d'échantillonnage égal à 1 avant qu'il ne traite l'image en format JPEG en niveaux de gris.
• cjpeg, djpeg et jpegtran acceptent maintenant un argument de -version, qui permet d'imprimer la version de la bibliothèque et la sortie.
• En se référant à 1.4 beta1 [15], une autre circonstance extrêmement rare a été découvert en vertu de laquelle un tampon local du codeur de Huffman peut être envahie quand un gestionnaire de destination tamponnée est utilisé et un bloc-très-haute fréquence (essentiellement des données d'image d'ordure) est en cours de codage. Même si le tampon local Huffman a été augmentée de 128 octets à 136 octets pour régler la question précédente, la nouvelle émission a causé même le tampon plus grand à être envahie. Une analyse plus poussée révèle que, dans le pire des cas, absolue (comme la mise en alternant coefficients AC à 32767 et -32768 dans l'ordre de balayage JPEG), le codeur de Huffman peut produire des blocs codés qui approchent le double de la taille des blocs non codés. Ainsi, le tampon local Huffman a été augmentée à 256 octets, ce qui devrait empêcher une telle question ne se reproduise à l'avenir.
• Le nouveau tjPlaneSizeYUV (), tjPlaneWidth (), et tjPlaneHeight () fonctions ne sont pas réellement utilisable sur toute plate-forme, sauf OS X et Windows, parce que ces fonctions ne sont pas inclus dans le libturbojpeg mapfile. Ceci a été corrigé.
• Restored les JPP (), JMETHOD () et les macros FAR dans les fichiers d'en-tête libjpeg-turbo. Les JPP () et JMETHOD () macros ont été initialement mis en œuvre dans libjpeg comme un moyen de soutenir les compilateurs non-ANSI qui ne disposaient pas de soutien pour les paramètres de prototypes. libjpeg-turbo n'a jamais soutenu ces compilateurs, mais certains logiciels utilisent encore les macros pour définir leurs propres prototypes. De même, libjpeg-turbo n'a jamais soutenu MS-DOS et d'autres plates-formes qui ont des symboles loin, mais certains logiciels utilisent encore la macro FAR. Un très bon argument peut être fait que ce soit une mauvaise pratique de la part du logiciel en question, mais puisque cela affecte plus d'un paquet, il est juste plus facile de fixer ici.
• Correction de problèmes qui empêchaient l'ARM 64-bit de code SIMD de compilation pour iOS, et inclus une architecture ARMv8 dans tous les binaires installés par le & quot; & quot officielle; SDK libjpeg-turbo pour OS X.

Ce qui est nouveau dans la version 1.4.2:

• Correction d'un problème de construction sur les plates-formes OS X PowerPC ( md5cmp n'a pas réussi à construire parce que OS X ne fournit pas la le32toh () et htole32 () fonctions.).
• La couleur RGB565 code de conversion non-SIMD ne fonctionnait pas correctement sur les grosses machines endian. Ceci a été corrigé.
• Correction d'un problème dans tjPlaneSizeYUV () par laquelle il serait à tort revenir 1 au lieu de -1 si ComponentID était & gt; 0 et subsamp était TJSAMP_GRAY.
• Correction d'un problème dans tjBufSizeYUV2 () wherby il serait à tort retourner 0 au lieu de -1 si la largeur était & lt; 1.
• Le codeur Huffman utilise maintenant CLZ et bsr instructions pour le bit de comptage sur les plates-formes ARM64.
• La méthode close () dans les classes TJCompressor et TJDecompressor Java est maintenant idempotent. Auparavant, cette méthode serait d'appeler la fonction tjDestroy native () même si l'instance TurboJPEG avait déjà été détruite. Cela a provoqué une levée de l'exception lors de la finalisation, si la méthode close () avait déjà été appelé. L'exception a été capturé, mais il était encore une opération coûteuse.
• L'API TurboJPEG précédemment généré une erreur (& quot; Impossible de déterminer le type de sous-échantillonnage pour les images JPEG & quot;) lors d'une tentative pour décompresser les images JPEG en niveaux de gris qui ont été compressés avec un facteur d'échantillonnage autre que 1 (par exemple, avec 'cjpeg -grayscale - 2x2 échantillon »). Sous-échantillonnage technique n'a pas de sens avec les fichiers JPEG en niveaux de gris, et donc les facteurs horizontaux et verticaux échantillonnage pour ces images sont ignorées par le décompresseur. Cependant, l'API TurboJPEG fit preuve de trop rigide et attendait les facteurs d'échantillonnage égal à 1 avant qu'il ne traite l'image en format JPEG en niveaux de gris.
• cjpeg, djpeg et jpegtran acceptent maintenant un argument de -version, qui permet d'imprimer la version de la bibliothèque et la sortie.
• En se référant à 1.4 beta1 [15], une autre circonstance extrêmement rare a été découvert en vertu de laquelle un tampon local du codeur de Huffman peut être envahie quand un gestionnaire de destination tamponnée est utilisé et un bloc-très-haute fréquence (essentiellement des données d'image d'ordure) est en cours de codage. Même si le tampon local Huffman a été augmentée de 128 octets à 136 octets pour régler la question précédente, la nouvelle émission a causé même le tampon plus grand à être envahie. Une analyse plus poussée révèle que, dans le pire des cas, absolue (comme la mise en alternant coefficients AC à 32767 et -32768 dans l'ordre de balayage JPEG), le codeur de Huffman peut produire des blocs codés qui approchent le double de la taille des blocs non codés. Ainsi, le tampon local Huffman a été augmentée à 256 octets, ce qui devrait empêcher une telle question ne se reproduise à l'avenir.
• Le nouveau tjPlaneSizeYUV (), tjPlaneWidth (), et tjPlaneHeight () fonctions ne sont pas réellement utilisable sur toute plate-forme, sauf OS X et Windows, parce que ces fonctions ne sont pas inclus dans le libturbojpeg mapfile. Ceci a été corrigé.
• Restored les JPP (), JMETHOD () et les macros FAR dans les fichiers d'en-tête libjpeg-turbo. Les JPP () et JMETHOD () macros ont été initialement mis en œuvre dans libjpeg comme un moyen de soutenir les compilateurs non-ANSI qui ne disposaient pas de soutien pour les paramètres de prototypes. libjpeg-turbo n'a jamais soutenu ces compilateurs, mais certains logiciels utilisent encore les macros pour définir leurs propres prototypes. De même, libjpeg-turbo n'a jamais soutenu MS-DOS et d'autres plates-formes qui ont des symboles loin, mais certains logiciels utilisent encore la macro FAR. Un très bon argument peut être fait que ce soit une mauvaise pratique de la part du logiciel en question, mais puisque cela affecte plus d'un paquet, il est juste plus facile de fixer ici.
• Correction de problèmes qui empêchaient l'ARM 64-bit de code SIMD de compilation pour iOS, et inclus une architecture ARMv8 dans tous les binaires installés par le & quot; & quot officielle; SDK libjpeg-turbo pour OS X.

Ce qui est nouveau dans la version 1.4.0:

• Correction d'un problème de construction sur les plates-formes OS X PowerPC ( md5cmp n'a pas réussi à construire parce que OS X ne fournit pas la le32toh () et htole32 () fonctions.).
• La couleur RGB565 code de conversion non-SIMD ne fonctionnait pas correctement sur les grosses machines endian. Ceci a été corrigé.
• Correction d'un problème dans tjPlaneSizeYUV () par laquelle il serait à tort revenir 1 au lieu de -1 si ComponentID était & gt; 0 et subsamp était TJSAMP_GRAY.
• Correction d'un problème dans tjBufSizeYUV2 () wherby il serait à tort retourner 0 au lieu de -1 si la largeur était & lt; 1.
• Le codeur Huffman utilise maintenant CLZ et bsr instructions pour le bit de comptage sur les plates-formes ARM64.
• La méthode close () dans les classes TJCompressor et TJDecompressor Java est maintenant idempotent. Auparavant, cette méthode serait d'appeler la fonction tjDestroy native () même si l'instance TurboJPEG avait déjà été détruite. Cela a provoqué une levée de l'exception lors de la finalisation, si la méthode close () avait déjà été appelé. L'exception a été capturé, mais il était encore une opération coûteuse.
• L'API TurboJPEG précédemment généré une erreur (& quot; Impossible de déterminer le type de sous-échantillonnage pour les images JPEG & quot;) lors d'une tentative pour décompresser les images JPEG en niveaux de gris qui ont été compressés avec un facteur d'échantillonnage autre que 1 (par exemple, avec 'cjpeg -grayscale - 2x2 échantillon »). Sous-échantillonnage technique n'a pas de sens avec les fichiers JPEG en niveaux de gris, et donc les facteurs horizontaux et verticaux échantillonnage pour ces images sont ignorées par le décompresseur. Cependant, l'API TurboJPEG fit preuve de trop rigide et attendait les facteurs d'échantillonnage égal à 1 avant qu'il ne traite l'image en format JPEG en niveaux de gris.
• cjpeg, djpeg et jpegtran acceptent maintenant un argument de -version, qui permet d'imprimer la version de la bibliothèque et la sortie.
• En se référant à 1.4 beta1 [15], une autre circonstance extrêmement rare a été découvert en vertu de laquelle un tampon local du codeur de Huffman peut être envahie quand un gestionnaire de destination tamponnée est utilisé et un bloc-très-haute fréquence (essentiellement des données d'image d'ordure) est en cours de codage. Même si le tampon local Huffman a été augmentée de 128 octets à 136 octets pour régler la question précédente, la nouvelle émission a causé même le tampon plus grand à être envahie. Une analyse plus poussée révèle que, dans le pire des cas, absolue (comme la mise en alternant coefficients AC à 32767 et -32768 dans l'ordre de balayage JPEG), le codeur de Huffman peut produire des blocs codés qui approchent le double de la taille des blocs non codés. Ainsi, le tampon local Huffman a été augmentée à 256 octets, ce qui devrait empêcher une telle question ne se reproduise à l'avenir.
• Le nouveau tjPlaneSizeYUV (), tjPlaneWidth (), et tjPlaneHeight () fonctions ne sont pas réellement utilisable sur toute plate-forme, sauf OS X et Windows, parce que ces fonctions ne sont pas inclus dans le libturbojpeg mapfile. Ceci a été corrigé.
• Restored les JPP (), JMETHOD () et les macros FAR dans les fichiers d'en-tête libjpeg-turbo. Les JPP () et JMETHOD () macros ont été initialement mis en œuvre dans libjpeg comme un moyen de soutenir les compilateurs non-ANSI qui ne disposaient pas de soutien pour les paramètres de prototypes. libjpeg-turbo n'a jamais soutenu ces compilateurs, mais certains logiciels utilisent encore les macros pour définir leurs propres prototypes. De même, libjpeg-turbo n'a jamais soutenu MS-DOS et d'autres plates-formes qui ont des symboles loin, mais certains logiciels utilisent encore la macro FAR. Un très bon argument peut être fait que ce soit une mauvaise pratique de la part du logiciel en question, mais puisque cela affecte plus d'un paquet, il est juste plus facile de fixer ici.
• Correction de problèmes qui empêchaient l'ARM 64-bit de code SIMD de compilation pour iOS, et inclus une architecture ARMv8 dans tous les binaires installés par le & quot; & quot officielle; SDK libjpeg-turbo pour OS X.

Ce qui est nouveau dans la version 1.3.0:

• [1] 'make test' fonctionne maintenant correctement sur FreeBSD, et il ne nécessite plus l'exécutable md5sum d'être présent sur d'autres plates-formes Un * x.
• [2] Révisée le système d'emballage: - Pour éviter les conflits avec les paquets libjpeg-turbo fournisseur fourni, les RPM officiels et DEB pour libjpeg-turbo été renommé & quot; libjpeg-turbo-officielle & quot ;. - Les bibliothèques TurboJPEG sont maintenant situés sous / opt / libjpeg-turbo dans les paquets officiels Linux et Mac, pour éviter les conflits avec les paquets fournis par le fabricant et aussi de rationaliser le système d'emballage. - les paquets de sortie sont maintenant créés avec la structure de répertoire défini par les variables de configure & quot; préfixe & quot ;, & quot; bindir & quot ;, & quot; libdir & quot ;, etc. (Un * x) ou par la variable CMAKE_INSTALL_PREFIX (Windows). L'exception est que les documents sont toujours situés dans le répertoire de documentation par défaut du système sur Un * x et les systèmes Mac et sous Windows, le TurboJPEG DLL est toujours situé dans le répertoire système de Windows. - Pour éviter toute confusion, les paquets officiels libjpeg-turbo sur les plateformes Linux / Unix (sauf pour Mac) sera toujours installer les bibliothèques 32 bits dans / opt / libjpeg-turbo / lib32 et les bibliothèques 64 bits dans / opt / libjpeg- turbo / lib64. - Correction d'un problème où, dans certains cas, les executables libjpeg-turbo sur Un * x systèmes ne sont pas correctement la liaison avec les bibliothèques partagées installées par le même paquet. - Correction d'un problème où la construction de la & quot; installateur & quot; cible sur Windows lorsque WITH_JAVA = 1 échouerait si le JAR TurboJPEG avait pas été préalablement construite. - Construire le & quot; installer & quot; cible sur Windows installe maintenant des fichiers dans les mêmes endroits que l'installateur fait.
• [3] Correction d'un bug codeur Huffman qui a empêché / O suspension I de fonctionner correctement.

Ce qui est nouveau dans la version 1.2.0:

• Un problème de construction rencontré lors de l'utilisation yasm sur les systèmes Unix a été fixé.
• Une limite hors-lu dans le code SSE2 SIMD a été fixé.
• Les nouvelles constantes d'extension colorspace qui permettent aux applications de spécifier que l'octet utilisé dans un tampon RVB 4 octets doit être traité comme un canal alpha lors de la décompression ont été ajoutés.
• Un problème de régression rencontré lors de la construction DevIL avec libjpeg-turbo a été fixé.
• support iOS a été ajouté au SDK libjpeg-turbo pour Mac.

Ce qui est nouveau dans la version 1.1 Beta 1:

• libjpeg-turbo peut être construit pour émuler le libjpeg API v7 ou V8B / ABI.
• Le système de construction Windows utilise maintenant CMake.
• TurboJPEG / OSS peut maintenant compresser de / décomprimer à bitmaps en niveaux de gris et de convertir des images RVB ou JPEG à la sortie plane YUV.
• jpgtest peut être utilisé pour tester les performances de décompression avec des images JPEG existantes.
• arithmétique encodage et le décodage de soutien facultatif a été ajouté.
• D'autres protections ont été ajoutées par rapport aux codes de Huffman non valides.

Ce qui est nouveau dans la version 1.0.0:.

• construire de nouvelles améliorations sur FreeBSD
• packages Unix / Linux incluent maintenant libjpeg exécution des programmes (cjpeg, etc.) et les pages de manuel.
• Il existe un paquet supplémentaire de 32 bits pour les systèmes Debian amd64.
• Support Cygwin.
• Support complet pour la construction / tests sur des architectures non-x86.
• 64-bit OS X binaires sont maintenant rétro-compatible avec OS X 10.4.
• Il existe différents réglages d'emballage Linux.

Ce qui est nouveau dans la version 0.0.91:

• Documentation Ajouté à .deb packages

les problèmes de corruption
• données fixes lors de la décompression de grandes images JPEG et / ou en utilisant tamponnée I / O avec le décompresseur libjpeg-turbo