libjpeg-turbo

libjpeg-turbo egy nyílt forráskódú, többplatformos és teljesen ingyenes szoftver tervezték, hogy a nagy sebességű változata az eredeti libjpeg könyvtári szoftver, kifejezetten erre a célra készített x86 és x86-64 processzorok, amelyek használata SIMD ( Single Instruction, Multiple Data) utasításokat, mint például a SSE2, MMX és NEON, hogy gyorsítsa fel a kiindulási JPEG dekompressziós és tömörítés.

A szoftver rendkívül gyors JPEG kép codec, ami általában 2-4x gyorsabb, mint a módosítatlan verziója libjpeg. A projekt eredetileg alapul libjpeg / SIMD projekt által létrehozott Miyasaka Masaru.

Ez turbó változata a libjpeg könyvtár is végrehajtja a hagyományos libjpeg API, valamint a bonyodalmaktól TurboJPEG API. Jellemzője színtér kiterjesztéseket, amely lehetővé teszi a felhasználók számára, hogy tömöríteni, vagy kibontására a big-endian és 32 bites pixel pufferek (XBGR, RGBX stb), és egy teljes funkcionalitású Java felület.

Az Ön kényelme érdekében a szoftver eloszlik, mint a natív telepítők számára DEB és RPM-alapú operációs rendszerek, mint például a Debian, Ubuntu, Linux Mint, Fedora, CentOS, Red Hat Enterprise Linux, openSUSE, Mageia stb egyaránt támogatja 64 és 32 bites hardver platformokon.

A libjpeg-turbo projekt könnyen telepíthető a fő szoftverforrásokat a GNU / Linux disztribúció. Azt is automatikusan együtt telepített olyan szoftver, amely megköveteli azt.

A telepítéséhez kézzel a forrás csomagot, ha meg szeretné optimalizálja azt a hardver architektúra / operációs rendszer, töltse le és mentse a legújabb archívumot Softoware, bontsa ki annak tartalmát használ archív kezelő segédprogram megnyitásához Terminal alkalmazást és megy a helyét a kibontott archív fájl (pl cd / home / softoware / libjpeg-turbo).

, majd futtassa a & lsquo; ./ configure && make-ezte parancs segítségével állítsa, és összeállítja a programot, majd a & lsquo; sudo make install-ezte commad hogy telepítse a rendszer egészére kiterjedő és hozzáférhetővé teszi az összes alkalmazást.

Mi az új ebben a kiadásban:

< li> Fix build kérdés OS X PowerPC platformokon (md5cmp sikerült építeni, mert az OS X nem biztosítja a le32toh () és htole32 () függvényt.).
• A nem-SIMD RGB565 szín konverziós kód nem működik helyesen big endian gépeken. Ez javításra került.
• Javítva egy probléma a tjPlaneSizeYUV (), amely azt tenné hibásan visszatér helyett 1 -1, ha ComponentId volt & gt; 0 és subsamp volt TJSAMP_GRAY.
• Javítva egy probléma a tjBufSizeYUV2 () wherby lenne hibásan return 0 helyett -1, ha a szélesség & lt; 1.
• A Huffman kódoló most használja ClZ és BSR utasítások bit számít ARM64 platformokon.
• A close () metódus a TJCompressor és TJDecompressor Java osztályok most idempotens. Korábban ez a módszer neveznék a natív tjDestroy () függvény akkor is, ha a TurboJPEG például már elpusztult. Ez kivételt okozott kell dobni lezárás közben, ha a close () metódus már hívott. A kivétel elfogták, de ez még mindig egy drága művelet.
• A TurboJPEG API korábban keletkezett hiba (& quot; Nem sikerült meghatározni lemintavételezés típus JPEG kép & quot;), amikor megpróbálja kibontani szürkeárnyalatos JPEG képek, amelyeket sűrített mintavételezési faktor 1-től eltérő (például a "cjpeg -grayscale - minta 2x2 '). Színfelbontás technikailag nincs értelme szürkeárnyalatos JPEG, így a vízszintes és függőleges mintavételi tényezők ilyen képeket nem veszi figyelembe a kicsomagoló. Azonban a TurboJPEG API volt, hogy túlságosan merev, és várta a mintavételi tényezők értéke 1, mielőtt kezelni a képet szürkeárnyalatos JPEG.
• cjpeg, djpeg és jpegtran most elfogadja egy érv az -version, amely kiírja a könyvtár verzió és kilép.
• Utalva 1.4 beta 1 [15], egy másik rendkívül ritka esetekben, fedezték fel, amelyek alapján a Huffman kódoló helyi puffer túllépése, ha a pufferelt cél menedzser veszik igénybe, és rendkívül magas frekvenciájú blokk (alapvetően junk képadatok) van kódolás. Annak ellenére, hogy a Huffman helyi puffert nőtt 128 bájt 136 bájt, hogy foglalkozzon az előző kérdés, az új kérdés okozott még a nagyobb puffer túllépése. További elemzés megmutatja, hogy a legrosszabb esetben (mint például a beállítás váltakozó AC együtthatók 32767 és -32768 JPEG szkennelés sorrendben), a Huffman kódoló képes kódolt blokkokat, melyek megközelítik kétszer akkora a kódolatlan blokk. Így a Huffman helyi puffer növeltük 256 bájt, amely megakadályozza az ilyen probléma újbóli előfordulásának a jövőben.
• Az új tjPlaneSizeYUV (), tjPlaneWidth (), és tjPlaneHeight () függvények valójában nem voltak használhatóak bármely platformon, kivéve OS X és Windows, mert ezek a funkciók nem szerepelnek a libturbojpeg MAPFÁJL. Ez javításra került.
• visszaállítottuk JPP (), JMETHOD (), és a FAR makrókat libjpeg-turbo header fájlokat. A JPP () és JMETHOD () makrót eredetileg végre libjpeg, mert így a támogató nem ANSI fordítóprogramok, amely nem rendelkezett támogatása prototípus paramétereket. libjpeg-turbo azonban soha nem támogatta az ilyen fordítókat, de néhány szoftvercsomagok is használhatja a makrók hogy meghatározzák a saját prototípusokat. Hasonlóképpen, a libjpeg-turbo azonban soha nem támogatta az MS-DOS és más platformokon, amelyek messze szimbólumok, de néhány szoftvercsomagok is használhatja a FAR makrót. Egy nagyon jó érv lehet, hogy ez egy rossz gyakorlat a részét a kérdéses szoftver, de mivel ez a beteg közül több mint egy csomagot, ez csak könnyebb kijavítani itt.
• Rögzített kérdés, hogy megakadályozták az ARM 64 bites SIMD kódot összeállítása az iOS, és benne egy ARMv8 architektúra mind a bináris telepítve a & quot; hivatalos & quot; libjpeg-turbo SDK for OS X.

Mi az új 1.4.2-es változatát:

• Fix build kérdés OS X PowerPC platformokon ( md5cmp sikerült építeni, mert az OS X nem biztosítja a le32toh () és htole32 () függvényt.).
• A nem-SIMD RGB565 szín konverziós kód nem működik helyesen big endian gépeken. Ez javításra került.
• Javítva egy probléma a tjPlaneSizeYUV (), amely azt tenné hibásan visszatér helyett 1 -1, ha ComponentId volt & gt; 0 és subsamp volt TJSAMP_GRAY.
• Javítva egy probléma a tjBufSizeYUV2 () wherby lenne hibásan return 0 helyett -1, ha a szélesség & lt; 1.
• A Huffman kódoló most használja ClZ és BSR utasítások bit számít ARM64 platformokon.
• A close () metódus a TJCompressor és TJDecompressor Java osztályok most idempotens. Korábban ez a módszer neveznék a natív tjDestroy () függvény akkor is, ha a TurboJPEG például már elpusztult. Ez kivételt okozott kell dobni lezárás közben, ha a close () metódus már hívott. A kivétel elfogták, de ez még mindig egy drága művelet.
• A TurboJPEG API korábban keletkezett hiba (& quot; Nem sikerült meghatározni lemintavételezés típus JPEG kép & quot;), amikor megpróbálja kibontani szürkeárnyalatos JPEG képek, amelyeket sűrített mintavételezési faktor 1-től eltérő (például a "cjpeg -grayscale - minta 2x2 '). Színfelbontás technikailag nincs értelme szürkeárnyalatos JPEG, így a vízszintes és függőleges mintavételi tényezők ilyen képeket nem veszi figyelembe a kicsomagoló. Azonban a TurboJPEG API volt, hogy túlságosan merev, és várta a mintavételi tényezők értéke 1, mielőtt kezelni a képet szürkeárnyalatos JPEG.
• cjpeg, djpeg és jpegtran most elfogadja egy érv az -version, amely kiírja a könyvtár verzió és kilép.
• Utalva 1.4 beta 1 [15], egy másik rendkívül ritka esetekben, fedezték fel, amelyek alapján a Huffman kódoló helyi puffer túllépése, ha a pufferelt cél menedzser veszik igénybe, és rendkívül magas frekvenciájú blokk (alapvetően junk képadatok) van kódolás. Annak ellenére, hogy a Huffman helyi puffert nőtt 128 bájt 136 bájt, hogy foglalkozzon az előző kérdés, az új kérdés okozott még a nagyobb puffer túllépése. További elemzés megmutatja, hogy a legrosszabb esetben (mint például a beállítás váltakozó AC együtthatók 32767 és -32768 JPEG szkennelés sorrendben), a Huffman kódoló képes kódolt blokkokat, melyek megközelítik kétszer akkora a kódolatlan blokk. Így a Huffman helyi puffer növeltük 256 bájt, amely megakadályozza az ilyen probléma újbóli előfordulásának a jövőben.
• Az új tjPlaneSizeYUV (), tjPlaneWidth (), és tjPlaneHeight () függvények valójában nem voltak használhatóak bármely platformon, kivéve OS X és Windows, mert ezek a funkciók nem szerepelnek a libturbojpeg MAPFÁJL. Ez javításra került.
• visszaállítottuk JPP (), JMETHOD (), és a FAR makrókat libjpeg-turbo header fájlokat. A JPP () és JMETHOD () makrót eredetileg végre libjpeg, mert így a támogató nem ANSI fordítóprogramok, amely nem rendelkezett támogatása prototípus paramétereket. libjpeg-turbo azonban soha nem támogatta az ilyen fordítókat, de néhány szoftvercsomagok is használhatja a makrók hogy meghatározzák a saját prototípusokat. Hasonlóképpen, a libjpeg-turbo azonban soha nem támogatta az MS-DOS és más platformokon, amelyek messze szimbólumok, de néhány szoftvercsomagok is használhatja a FAR makrót. Egy nagyon jó érv lehet, hogy ez egy rossz gyakorlat a részét a kérdéses szoftver, de mivel ez a beteg közül több mint egy csomagot, ez csak könnyebb kijavítani itt.
• Rögzített kérdés, hogy megakadályozták az ARM 64 bites SIMD kódot összeállítása az iOS, és benne egy ARMv8 architektúra mind a bináris telepítve a & quot; hivatalos & quot; libjpeg-turbo SDK for OS X.

Mi az új verzió 1.4.0:

• Fix build kérdés OS X PowerPC platformokon ( md5cmp sikerült építeni, mert az OS X nem biztosítja a le32toh () és htole32 () függvényt.).
• A nem-SIMD RGB565 szín konverziós kód nem működik helyesen big endian gépeken. Ez javításra került.
• Javítva egy probléma a tjPlaneSizeYUV (), amely azt tenné hibásan visszatér helyett 1 -1, ha ComponentId volt & gt; 0 és subsamp volt TJSAMP_GRAY.
• Javítva egy probléma a tjBufSizeYUV2 () wherby lenne hibásan return 0 helyett -1, ha a szélesség & lt; 1.
• A Huffman kódoló most használja ClZ és BSR utasítások bit számít ARM64 platformokon.
• A close () metódus a TJCompressor és TJDecompressor Java osztályok most idempotens. Korábban ez a módszer neveznék a natív tjDestroy () függvény akkor is, ha a TurboJPEG például már elpusztult. Ez kivételt okozott kell dobni lezárás közben, ha a close () metódus már hívott. A kivétel elfogták, de ez még mindig egy drága művelet.
• A TurboJPEG API korábban keletkezett hiba (& quot; Nem sikerült meghatározni lemintavételezés típus JPEG kép & quot;), amikor megpróbálja kibontani szürkeárnyalatos JPEG képek, amelyeket sűrített mintavételezési faktor 1-től eltérő (például a "cjpeg -grayscale - minta 2x2 '). Színfelbontás technikailag nincs értelme szürkeárnyalatos JPEG, így a vízszintes és függőleges mintavételi tényezők ilyen képeket nem veszi figyelembe a kicsomagoló. Azonban a TurboJPEG API volt, hogy túlságosan merev, és várta a mintavételi tényezők értéke 1, mielőtt kezelni a képet szürkeárnyalatos JPEG.
• cjpeg, djpeg és jpegtran most elfogadja egy érv az -version, amely kiírja a könyvtár verzió és kilép.
• Utalva 1.4 beta 1 [15], egy másik rendkívül ritka esetekben, fedezték fel, amelyek alapján a Huffman kódoló helyi puffer túllépése, ha a pufferelt cél menedzser veszik igénybe, és rendkívül magas frekvenciájú blokk (alapvetően junk képadatok) van kódolás. Annak ellenére, hogy a Huffman helyi puffert nőtt 128 bájt 136 bájt, hogy foglalkozzon az előző kérdés, az új kérdés okozott még a nagyobb puffer túllépése. További elemzés megmutatja, hogy a legrosszabb esetben (mint például a beállítás váltakozó AC együtthatók 32767 és -32768 JPEG szkennelés sorrendben), a Huffman kódoló képes kódolt blokkokat, melyek megközelítik kétszer akkora a kódolatlan blokk. Így a Huffman helyi puffer növeltük 256 bájt, amely megakadályozza az ilyen probléma újbóli előfordulásának a jövőben.
• Az új tjPlaneSizeYUV (), tjPlaneWidth (), és tjPlaneHeight () függvények valójában nem voltak használhatóak bármely platformon, kivéve OS X és Windows, mert ezek a funkciók nem szerepelnek a libturbojpeg MAPFÁJL. Ez javításra került.
• visszaállítottuk JPP (), JMETHOD (), és a FAR makrókat libjpeg-turbo header fájlokat. A JPP () és JMETHOD () makrót eredetileg végre libjpeg, mert így a támogató nem ANSI fordítóprogramok, amely nem rendelkezett támogatása prototípus paramétereket. libjpeg-turbo azonban soha nem támogatta az ilyen fordítókat, de néhány szoftvercsomagok is használhatja a makrók hogy meghatározzák a saját prototípusokat. Hasonlóképpen, a libjpeg-turbo azonban soha nem támogatta az MS-DOS és más platformokon, amelyek messze szimbólumok, de néhány szoftvercsomagok is használhatja a FAR makrót. Egy nagyon jó érv lehet, hogy ez egy rossz gyakorlat a részét a kérdéses szoftver, de mivel ez a beteg közül több mint egy csomagot, ez csak könnyebb kijavítani itt.
• Rögzített kérdés, hogy megakadályozták az ARM 64 bites SIMD kódot összeállítása az iOS, és benne egy ARMv8 architektúra mind a bináris telepítve a & quot; hivatalos & quot; libjpeg-turbo SDK for OS X.

Mi az új 1.3.0-s verzió:

• [1] "make test" most már megfelelően működik FreeBSD, és nem tart igényt a md5sum végrehajtható jelen lenni más Un * x platformokon.
• [2] megújul a csomagolási rendszer: - Hogy elkerülje a konfliktust gyártó által biztosított libjpeg turbó csomag, a hivatalos RPM és DEB- a libjpeg-turbo már átnevezték a & quot; libjpeg-turbo-hivatalos & quot ;. - A TurboJPEG könyvtárak most, a / opt / libjpeg-turbo a hivatalos Linux és Mac csomagok való ütközés elkerülése érdekében gyártó által biztosított csomagokat, valamint, hogy korszerűsítse a csomagolási rendszer. - Release csomagok most létre a könyvtár struktúrát által meghatározott configure változók & quot; előtag & quot ;, & quot; bindir & quot ;, & quot; libdir & quot ;, stb (Un * x) vagy a CMAKE_INSTALL_PREFIX változó (Windows). A kivétel hogy a docs mindig alatt található a rendszer alapértelmezett dokumentáció könyvtárban Un * x és Mac rendszerek, valamint a Windows, a TurboJPEG DLL mindig találhatók meg a Windows rendszer könyvtárába. - A félreértések elkerülése érdekében, a hivatalos libjpeg-turbo csomagok Linux / Unix platformon (kivéve Mac) mindig telepíteni a 32 bites könyvtárakat az / opt / libjpeg-turbo / lib32 és a 64 bites könyvtárakat az / opt / libjpeg- turbo / lib64. - Javítva egy probléma, amellyel bizonyos esetekben, a libjpeg-turbo futtatható a Un * x rendszerek nem voltak megfelelően összekapcsolja a megosztott könyvtárakat telepíteni ugyanazt a csomagot. - Javítva egy probléma, amellyel az épület a & quot; telepítő & quot; célozza a Windows, amikor WITH_JAVA = 1-nek sikerül, ha a TurboJPEG JAR korábban nem épült. - Épület a & quot; telepítés & quot; cél a Windows most telepíti a fájlokat, ugyanazokon a helyeken, hogy a telepítő nem.
• [3] rögzített egy Huffman kódoló hiba, amely megakadályozta I / O felfüggesztés működik megfelelően.

Mi az új verzió 1.2.0:

• A build probléma használata során felmerülő YASM Unix rendszereken rögzítették.
• Egy out-of-határokat olvassuk az SSE2 SIMD kód rögzítették.
• New színtér kiterjesztés állandók, amelyek lehetővé teszik az alkalmazások meghatározzák, hogy a fel nem használt byte egy 4 byte-os RGB puffer kell kezelni, mint egy alfa csatornát kicsomagoláskor adunk hozzá.
• A regressziós kérdés felmerült, amikor az épület ördög libjpeg-turbo rögzítették.
• iOS támogatást adunk a libjpeg-turbo SDK for Mac.

Mi az új 1.1 verziójában Beta 1:

• libjpeg-turbo épülhet versenyez a libjpeg v7 vagy v8b API / ABI.
• A Windows-build rendszer most használja CGyõzõdjön.
• TurboJPEG / OSS most tömöríteni tól / kibontására szürkeárnyalatos bitmap és konvertálni RGB vagy YUV JPEG képeket sík kimenet.
• jpgtest lehet használni, hogy teszteljék a dekompressziós teljesítmény meglévő JPEG képeket.
• Opcionális aritmetikai kódolás és dekódolás támogatása adunk hozzá.
• További védelem adunk az érvénytelen Huffman kód.

Mi az új 1.0.0:

• további kiépítése javulás FreeBSD.
• Unix / Linux csomagok már tartalmazzák libjpeg futásidejű programok (cjpeg, stb), és férfi oldalt.
• Van egy 32-bites kiegészítő csomag amd64 Debian rendszerek.
• Cygwin támogatása.
• Teljes mértékben támogatja az épület / tesztelés nem x86 architektúrára.
• 64 bites OS X bináris most visszafelé kompatibilis OS X 10.4.
• Vannak különböző Linux csomagolás csíp.

Mi az új verzió 0.0.91:

• Added dokumentáció .deb csomagok
• Rögzített adatok korrupciós ügyekről kicsomagoláskor nagyméretű JPEG és / vagy a pufferelt I / O a libjpeg-turbo kibontó