libjpeg-turbo

libjpeg-turbo je open source, multiplatformní a zcela zdarma software navržen tak, aby poskytnout vysokorychlostní verzi původního libjpeg knihovny softwaru, speciálně vytvořený pro x86 a x86-64 procesory, které používají SIMD ( Single Instruction, Multiple dat) instrukce, jako SSE2, MMX a NEON, aby urychlily základním formátu JPEG dekompresi a kompresi.

Tento software je extrémně rychlá kodek JPEG obrázek, který je obecně 2-4x rychlejší než nemodifikované verzi knihovny libjpeg. Projekt byl původně založen na libjpeg projektu / SIMD vytvořený Miyasaka Masaru.

Tento turbo verze knihovny libjpeg také realizuje tradiční Libjpeg API, stejně jako přímý TurboJPEG API. To představuje rozšíření barevný prostor, který umožňuje uživatelům pro kompresi z nebo dekompresi do big-endian a 32bitové obrazových bodů vyrovnávacích pamětí (XBGR, RGBX, atd.), A plnohodnotné rozhraní Java.

Pro vaše pohodlí, tento software je distribuován jako nativní instalátory pro DEB a operačních systémů založených na RPM, jako je například Debian, Ubuntu, Linux Mint, Fedora, CentOS, Red Hat Enterprise Linux, openSUSE, Mageia atd podporují jak 64 a 32-bitové hardwarové platformy.

libjpeg-turbo projekt lze snadno instalovat z hlavních softwarových zásobárny distribucí GNU / Linux. To bude také automaticky nainstaluje společně s produktem softwaru, který to vyžaduje.

Chcete-li jej nainstalovat ručně pomocí zdrojového balíku, v případě, že chcete optimalizovat pro váš hardware architektury / operačního systému, stáhnout a uložit nejnovější archiv ze Softoware, extrahujte jeho obsah pomocí správce archivů nástroj, otevřete terminál aplikaci a přejít na umístění extrahovaného archivního souboru (např cd / home / softoware / libjpeg-turbo).

Poté spusťte & lsquo; ./ configure && make & rsquo; Příkaz ke konfiguraci a sestavit program, po němž následuje & lsquo; sudo make install & rsquo; commad ji nainstalovat systém široká a dát je k dispozici pro všechny aplikace

Co je nového v této verzi:.

< li> Opraven problém stavět na platformě OS X PowerPC (md5cmp nepodařilo vytvořit, protože OS X neposkytuje le32toh () a htole32 () funkce.).
• Non-SIMD RGB565 barevný konverzní kód nefunguje správně na big endian strojích. Tento problém byl opraven.
• Opravena chyba v tjPlaneSizeYUV (doklad), jimiž by nesprávně vrátí 1 namísto -1, pokud ComponentId Byl & gt; 0 a subsamp byl TJSAMP_GRAY.
• Opravena chyba v tjBufSizeYUV2 () wherby že by nesprávně vrátí 0 místo -1, pokud šířka byla & lt; 1.
• Snímač Huffman nyní používá CLZ a BSR instrukce pro bitové spoléhají na platformách ARM64.
• Metoda close () ve třídách TJCompressor a TJDecompressor Java je nyní idempotentních. Dříve, že metoda by volání funkce nativní tjDestroy (), i když je instance TurboJPEG už byla zničena. To způsobilo výjimku být vyvolána během finalizace, pokud byl již volána metoda close (). Výjimkou byl chycen, ale to bylo ještě nákladné operace.
• TurboJPEG API dříve generovány chyby (& quot; Nemohu zjistit typ subsamplingových pro obrázek JPEG & quot;) při pokusu o dekompresi ve stupních šedi obrázky ve formátu JPEG, které byly komprimovány pomocí vzorkovací faktor jiný než 1 (například s 'cjpeg -grayscale - vzorek 2x2 "). Podvzorků technicky nemá žádný význam, se ve stupních šedi JPEG, a tím i horizontální a vertikální odběr vzorků faktory pro takové obrazy jsou ignorovány dekompresoru. Nicméně, TurboJPEG API byl příliš rigidní a čekal faktory pro odběr vzorků, aby se rovnala 1 před tím, než zachází obraz jako ve stupních šedi JPEG.
• cjpeg, djpeg a jpegtran nyní přijímá argument -version, který bude tisknout verzi knihovny a výstupu.
• S odvoláním na 1,4 beta1 [15], další extrémně vzácný okolnost bylo objeveno, za kterých místní vyrovnávací paměti Huffman kodéru může být překročen, pokud je pufrovaný cíl manažer používat a extrémně vysoká frekvence bloku (v podstatě nezdravé obrazová data) je zakódovaný. I přesto, že místní vyrovnávací paměti Huffman byl zvýšen z 128 bajtů na 136 bajtů řešit předchozí vydání, nový problém způsoben i větší vyrovnávací paměť má být přetečení. Další analýza ukazuje, že v absolutním nejhorším případě (například nastavení střídající střídavé koeficienty, 32767 -32768 a v pořadí snímání JPEG), kodér Huffman může produkovat kódovaných bloků, které přístupem ve dvou velikost nekódované bloků. To znamená, že lokální vyrovnávací paměti Huffman byla zvýšena na 256 bajtů, což by mělo zabránit jakékoli takové otázky z re-vyskytující se v budoucnu.
• Nový tjPlaneSizeYUV (), tjPlaneWidth () a funkce tjPlaneHeight () nebyly ve skutečnosti použitelné na libovolné platformě kromě OS X a Windows, protože tyto funkce nebyly zahrnuty v libturbojpeg mapfile. Tento problém byl opraven.
• Obnoveny JPP () JMETHOD () a daleko makra v souborech libjpeg-turbo záhlaví. V JPP () a JMETHOD () makra byly původně realizován v knihovny libjpeg jako způsob, jak podporovat non-ANSI kompilátory, které chyběla podpora pro parametry prototypu. libjpeg-turbo nikdy nepodporovala takové překladače, ale některé softwarové balíky i nadále používat makra definovat své vlastní prototypy. Podobně, libjpeg-turbo nikdy nepodporovala MS-DOS a další platformy, které mají mnohem symboly, ale některé softwarové balíčky stále používají na Dálném makro. Docela dobrý argument může být dělán že to je špatná praxe ze strany daného softwaru, ale protože to má vliv na více než jeden balík, je to prostě jednodušší opravit zde.
• Pevné problémy, které byly brání ARM 64-bitový kód SIMD z kompilace pro iOS a zahrnoval ARMv8 architekturu všechny binární soubory nainstalované & quot; oficiální & quot; libjpeg-turbo SDK pro OS X.

Co je nového ve verzi 1.4.2:

• Opraven problém stavět na platformě OS X PowerPC ( md5cmp nepodařilo vytvořit, protože OS X neposkytuje le32toh () a htole32 () funkce.).
• Non-SIMD RGB565 barevný konverzní kód nefunguje správně na big endian strojích. Tento problém byl opraven.
• Opravena chyba v tjPlaneSizeYUV (doklad), jimiž by nesprávně vrátí 1 namísto -1, pokud ComponentId Byl & gt; 0 a subsamp byl TJSAMP_GRAY.
• Opravena chyba v tjBufSizeYUV2 () wherby že by nesprávně vrátí 0 místo -1, pokud šířka byla & lt; 1.
• Snímač Huffman nyní používá CLZ a BSR instrukce pro bitové spoléhají na platformách ARM64.
• Metoda close () ve třídách TJCompressor a TJDecompressor Java je nyní idempotentních. Dříve, že metoda by volání funkce nativní tjDestroy (), i když je instance TurboJPEG už byla zničena. To způsobilo výjimku být vyvolána během finalizace, pokud byl již volána metoda close (). Výjimkou byl chycen, ale to bylo ještě nákladné operace.
• TurboJPEG API dříve generovány chyby (& quot; Nemohu zjistit typ subsamplingových pro obrázek JPEG & quot;) při pokusu o dekompresi ve stupních šedi obrázky ve formátu JPEG, které byly komprimovány pomocí vzorkovací faktor jiný než 1 (například s 'cjpeg -grayscale - vzorek 2x2 "). Podvzorků technicky nemá žádný význam, se ve stupních šedi JPEG, a tím i horizontální a vertikální odběr vzorků faktory pro takové obrazy jsou ignorovány dekompresoru. Nicméně, TurboJPEG API byl příliš rigidní a čekal faktory pro odběr vzorků, aby se rovnala 1 před tím, než zachází obraz jako ve stupních šedi JPEG.
• cjpeg, djpeg a jpegtran nyní přijímá argument -version, který bude tisknout verzi knihovny a výstupu.
• S odvoláním na 1,4 beta1 [15], další extrémně vzácný okolnost bylo objeveno, za kterých místní vyrovnávací paměti Huffman kodéru může být překročen, pokud je pufrovaný cíl manažer používat a extrémně vysoká frekvence bloku (v podstatě nezdravé obrazová data) je zakódovaný. I přesto, že místní vyrovnávací paměti Huffman byl zvýšen z 128 bajtů na 136 bajtů řešit předchozí vydání, nový problém způsoben i větší vyrovnávací paměť má být přetečení. Další analýza ukazuje, že v absolutním nejhorším případě (například nastavení střídající střídavé koeficienty, 32767 -32768 a v pořadí snímání JPEG), kodér Huffman může produkovat kódovaných bloků, které přístupem ve dvou velikost nekódované bloků. To znamená, že lokální vyrovnávací paměti Huffman byla zvýšena na 256 bajtů, což by mělo zabránit jakékoli takové otázky z re-vyskytující se v budoucnu.
• Nový tjPlaneSizeYUV (), tjPlaneWidth () a funkce tjPlaneHeight () nebyly ve skutečnosti použitelné na libovolné platformě kromě OS X a Windows, protože tyto funkce nebyly zahrnuty v libturbojpeg mapfile. Tento problém byl opraven.
• Obnoveny JPP () JMETHOD () a daleko makra v souborech libjpeg-turbo záhlaví. V JPP () a JMETHOD () makra byly původně realizován v knihovny libjpeg jako způsob, jak podporovat non-ANSI kompilátory, které chyběla podpora pro parametry prototypu. libjpeg-turbo nikdy nepodporovala takové překladače, ale některé softwarové balíky i nadále používat makra definovat své vlastní prototypy. Podobně, libjpeg-turbo nikdy nepodporovala MS-DOS a další platformy, které mají mnohem symboly, ale některé softwarové balíčky stále používají na Dálném makro. Docela dobrý argument může být dělán že to je špatná praxe ze strany daného softwaru, ale protože to má vliv na více než jeden balík, je to prostě jednodušší opravit zde.
• Pevné problémy, které byly brání ARM 64-bitový kód SIMD z kompilace pro iOS a zahrnoval ARMv8 architekturu všechny binární soubory nainstalované & quot; oficiální & quot; libjpeg-turbo SDK pro OS X.

Co je nového ve verzi 1.4.0:

• Opraven problém stavět na platformě OS X PowerPC ( md5cmp nepodařilo vytvořit, protože OS X neposkytuje le32toh () a htole32 () funkce.).
• Non-SIMD RGB565 barevný konverzní kód nefunguje správně na big endian strojích. Tento problém byl opraven.
• Opravena chyba v tjPlaneSizeYUV (doklad), jimiž by nesprávně vrátí 1 namísto -1, pokud ComponentId Byl & gt; 0 a subsamp byl TJSAMP_GRAY.
• Opravena chyba v tjBufSizeYUV2 () wherby že by nesprávně vrátí 0 místo -1, pokud šířka byla & lt; 1.
• Snímač Huffman nyní používá CLZ a BSR instrukce pro bitové spoléhají na platformách ARM64.
• Metoda close () ve třídách TJCompressor a TJDecompressor Java je nyní idempotentních. Dříve, že metoda by volání funkce nativní tjDestroy (), i když je instance TurboJPEG už byla zničena. To způsobilo výjimku být vyvolána během finalizace, pokud byl již volána metoda close (). Výjimkou byl chycen, ale to bylo ještě nákladné operace.
• TurboJPEG API dříve generovány chyby (& quot; Nemohu zjistit typ subsamplingových pro obrázek JPEG & quot;) při pokusu o dekompresi ve stupních šedi obrázky ve formátu JPEG, které byly komprimovány pomocí vzorkovací faktor jiný než 1 (například s 'cjpeg -grayscale - vzorek 2x2 "). Podvzorků technicky nemá žádný význam, se ve stupních šedi JPEG, a tím i horizontální a vertikální odběr vzorků faktory pro takové obrazy jsou ignorovány dekompresoru. Nicméně, TurboJPEG API byl příliš rigidní a čekal faktory pro odběr vzorků, aby se rovnala 1 před tím, než zachází obraz jako ve stupních šedi JPEG.
• cjpeg, djpeg a jpegtran nyní přijímá argument -version, který bude tisknout verzi knihovny a výstupu.
• S odvoláním na 1,4 beta1 [15], další extrémně vzácný okolnost bylo objeveno, za kterých místní vyrovnávací paměti Huffman kodéru může být překročen, pokud je pufrovaný cíl manažer používat a extrémně vysoká frekvence bloku (v podstatě nezdravé obrazová data) je zakódovaný. I přesto, že místní vyrovnávací paměti Huffman byl zvýšen z 128 bajtů na 136 bajtů řešit předchozí vydání, nový problém způsoben i větší vyrovnávací paměť má být přetečení. Další analýza ukazuje, že v absolutním nejhorším případě (například nastavení střídající střídavé koeficienty, 32767 -32768 a v pořadí snímání JPEG), kodér Huffman může produkovat kódovaných bloků, které přístupem ve dvou velikost nekódované bloků. To znamená, že lokální vyrovnávací paměti Huffman byla zvýšena na 256 bajtů, což by mělo zabránit jakékoli takové otázky z re-vyskytující se v budoucnu.
• Nový tjPlaneSizeYUV (), tjPlaneWidth () a funkce tjPlaneHeight () nebyly ve skutečnosti použitelné na libovolné platformě kromě OS X a Windows, protože tyto funkce nebyly zahrnuty v libturbojpeg mapfile. Tento problém byl opraven.
• Obnoveny JPP () JMETHOD () a daleko makra v souborech libjpeg-turbo záhlaví. V JPP () a JMETHOD () makra byly původně realizován v knihovny libjpeg jako způsob, jak podporovat non-ANSI kompilátory, které chyběla podpora pro parametry prototypu. libjpeg-turbo nikdy nepodporovala takové překladače, ale některé softwarové balíky i nadále používat makra definovat své vlastní prototypy. Podobně, libjpeg-turbo nikdy nepodporovala MS-DOS a další platformy, které mají mnohem symboly, ale některé softwarové balíčky stále používají na Dálném makro. Docela dobrý argument může být dělán že to je špatná praxe ze strany daného softwaru, ale protože to má vliv na více než jeden balík, je to prostě jednodušší opravit zde.
• Pevné problémy, které byly brání ARM 64-bitový kód SIMD z kompilace pro iOS a zahrnoval ARMv8 architekturu všechny binární soubory nainstalované & quot; oficiální & quot; libjpeg-turbo SDK pro OS X.

Co je nového ve verzi 1.3.0:

• [1] 'make test "nyní pracuje správně FreeBSD, a to již nevyžaduje md5sum spustitelný být přítomný na jiných Un * x platformách.
• [2] přepracován na systém balení: - vyhnout se konfliktu s libjpeg-turbo balíčků od dodavatele, oficiální RPM a debs pro libjpeg-turbo byly přejmenovány na & quot; libjpeg-turbo-oficiální & quot ;. - Knihovny TurboJPEG jsou nyní umístěny v adresáři / opt / libjpeg-turbo v oficiálních Linux a Mac balíčky, vyhnout se konfliktu s balíky od dodavatele a také zefektivnit systém balení. - Uvolnit balíčky jsou nyní vytvořeny s adresářové struktury definované configure proměnných & quot; předpona quot ;, & quot; bindir & quot ;, & quot; libdir & quot ;, atd. (Un * x) nebo proměnnou CMAKE_INSTALL_PREFIX (Windows). Výjimkou je že dokumenty jsou vždy umístěny v rámci systému výchozí dokumentace adresáře na Un * x a systémy Mac a Windows je TurboJPEG DLL je vždy umístěn v adresáři systému Windows. - Aby nedošlo k záměně, oficiální libjpeg-turbo balíčky na platformách Linux / Unix (s výjimkou pro Mac) bude vždy nainstalovat 32bitové knihovny v adresáři / opt / libjpeg-turbo / lib32 a 64-bitové knihovny v / opt / libjpeg- turbo / lib64. - Byl opraven problém, kdy v některých případech libjpeg-turbo spustitelné soubory na UN * x systémech nebyly řádně propojení s sdílených knihoven nainstalovány ve stejném obalu. - Opraven problém, kdy budování & quot; instalatéra & quot; zaměřit na Windows při WITH_JAVA = 1 by selhat, pokud TurboJPEG JAR nebyl dosud postaven. - Budování & quot; instalovat & quot; terč na Windows nyní nainstaluje soubory do stejných míst, která dělá instalační program.
• [3] Opravena chyba kodéru Huffman, která bránila I O pozastavení / z pracuje správně.

Co je nového ve verzi 1.2.0:

• A problém build při použití YASM na unixových systémech se setkal byla opravena.
• out-of-hranice číst v kódu SSE2 SIMD byla opravena.
• Nové rozšíření barevného konstanty, které umožňují aplikacím určit, že nepoužité byte v 4bajtové RGB vyrovnávací paměti by se mělo zacházet jako alfa kanál při dekompresi byly přidány.
• regresní problém při stavbě čert s libjpeg-turbo byla stanovena setkal.
• Podpora iOS byla přidána do libjpeg-turbo SDK for Mac.

Co je nového ve verzi 1.1 Beta 1:

• libjpeg-turbo může být postavena tak, aby napodobit libjpeg v7 nebo v8b API / ABI.
• build systém Windows nyní používá CMake.
• TurboJPEG / OSS lze nyní komprimovat z / dekompresi na stupních šedi bitmapy a konvertovat RGB nebo JPEG obrázků na YUV planární výstup.
• jpgtest mohou být použity k testování dekompresní výkon s existujícími JPEG.
• byl přidán Volitelné aritmetické kódování a dekódování podporu.
• Další ochrana byly přidány proti neplatným Huffman kódů.

Co je nového ve verzi 1.0.0:.

• Dále budovat zlepšení na FreeBSD
• Unix / Linux balíčky nyní zahrnují libjpeg run-time programy (cjpeg, atd) a manuálových stránek.
• K dispozici je doplňkový balíček 32-bit pro amd64 Debianu.
• Podpora Cygwin.
• Plná podpora pro stavbu / testování na non-x86 architektury.
• 64-bit OS X binární soubory jsou nyní zpětně kompatibilní s OS X 10.4.
• Existují různé Linux obalová technika vylepší.

Co je nového ve verzi 0.0.91:

• Přidána dokumentace .deb balíčky

problémy s poškozením
• Pevná údajů při dekompresi velké obrázky ve formátu JPEG a / nebo používání ve vyrovnávací paměti I / O s libjpeg-turbo dekomprimačního