Google 新近推出 Jpegli 擴展庫,這是一個用于JPEG圖像編碼的庫。
2022 年,Google Chrome 中放棄了對 JPEG-XL 的支持,此舉引起了業界轟動,旨在加強其自有格式 WebP 的使用。隨著 JPEG 在互聯網上的持續重要性,他們現在推出了另一種替代方案。
新的Jpegli擴展庫目標比傳統 JPEG 更快、更美觀、更高效。該技術的支持者表示,它有潛力讓互聯網變得更快、更美好。
Google表示,Jpegli于 4 月 3 日發布并可從GitHub訪問,它保持了高度的向后兼容性,同時提供增強的功能和高質量壓縮設置下高達 35% 壓縮比。
據Google稱,在提高圖像質量和壓縮密度比的同時,Jpegli 的編碼速度與 MozJPEG 等傳統方法相當。因此,Web 開發人員可以將 Jpegli 集成到現有工作流程中,而無需犧牲編碼速度、性能或內存使用。
Jpegli(在德語-奧地利語中意為“小 Jpeg”)與原始 JPEG 標準完全兼容,仍然忠實于更傳統的 8 位設置。這確保了與 libjpeg-turbo 和 MozJPEG 等流行庫中的 API 和 ABI 的互操作性。
確保 Jpegli 卓越性能的一些先進技術包括:
此外,Jpegli 比傳統 JPEG 編解碼器更有效地壓縮圖像。Google表示,這是這個非常有前途的技術,可以節省帶寬和存儲空間,并使網頁打開速度更快。
Jpegli 的工作原理是使用新技術來減少噪聲并提高圖像質量。新的或改進的功能包括來自JPEG XL參考實現的自適應量化啟發式、改進的量化矩陣選擇、中間結果的計算以及使用更高級色彩空間的可能性。
該庫提供了一個可互操作的編碼器和解碼器,符合原始 JPEG 標準及其最方便的 8 位形式以及與libjeg-turboMozJPEG 的 API/ABI 兼容性。
當通過 Jpegli 壓縮或解壓縮圖像時,還會執行更精確且心理視覺上有效的計算;圖像看起來會更清晰,并且可觀察到的偽影更少。
新格式能否取代廣泛使用的傳統 JPEG?當然,與傳統 JPEG 解碼器的互操作性是其潛在流行的一個重要因素。
參考:
https://github.com/libjxl/libjxl/tree/main/lib/jpegli
https://opensource.googleblog.com/2024/04/introducing-jpegli-new-jpeg-coding-library.html
https://www.infoworld.com/article/3715021/google-rolls-out-a-new-jpeg-coding-library.html
英文翻譯:https://github.com/libjpeg-turbo/libjpeg-turbo/blob/master/usage.txt
請注意:該文件被libjpeg-turbo項目修改為僅包含與libjpeg-turbo相關的信息和某些部分的文字。
JPEG軟件的使用說明
=================================================================
該文件描述了JPEG轉換程序cjpeg和djpeg以及工具程序jpegtran,rdjpgcom和wrjpgcom的使用。(如果你希望在自己的程序中使用JPEG庫,請參閱其他文檔文件。)
如果你使用的是Unix機器,你可能更喜歡閱讀文件cjpeg.1,djpeg.1,jpegtran.1,rdjpgcom.1,wrjpgcom.1的Unix樣式手冊頁。
INTRODUCTION
這些程序實現JPEG圖像編碼,解碼和轉碼。JPEG(發音為“jay-peg”)用于全色和灰度圖像的標準化壓縮方法。
GENERAL USAGE
我們提供兩個程序,cjpeg將圖像文件壓縮成JPEG格式,djpeg將JPEG文件壓縮成傳統的圖像格式。
在Unix-like系統上,指令為:
cjpeg [switches] [imagefile] > jpegfile 或 djpeg [switches] [jpegfile] > imagefile
程序讀取指定的輸入文件,如果沒有命名,則讀取標準輸入。它們總是寫入標準輸出(跟蹤/錯誤消息到標準錯誤)。這些慣例適用于程序之間的管道圖像。
在大多數non-Unix系統上,指令為:
cjpeg [switches] imagefile jpegfile 或 djpeg [switches] imagefile jpegfile
輸入和輸出文件都在命令行中命名。這種風格有點愚蠢,如果沒有pipes,它就不會失去功能。(如果你愿意,你可以在Unix上獲得此樣式,通過在編譯程序時定義TWO_FILE_COMMANDLINE,請參閱install.txt。)
指令也可以這樣:
cjpeg [switches] -outfile jpegfile imagefile 或 djpeg [switches] -outfile imagefile jpegfile
此語法適用于所有系統,因此對腳本很有用。
目前支持的圖像格式有:PPM(PBMPLUS顏色格式),PGM(PBMPLUS灰度圖格式),BMP,Targa和RLE(Utah Raster Toolkit format)。(只有在URT庫可用時才支持RLE,大多數非Unix系統都不支持RLE。)cjpeg會自動識別輸入圖像格式,但某些Targa文件除外。你必須告訴djpeg要生成的格式。
JPEG文件采用標準的JFIF文件格式。還有其他不太廣泛使用的基于JPEG的文件格式,但是我們不支持。
所有開關名稱都可以縮寫。例如,-grayscale可以寫成-gray或-gr。大多數“基礎”開關可以縮寫為一個字母。大寫和小寫是等效的(-BMP和-bmp相同)。英式拼寫也被接受(例如,-greyscale),但是為了簡潔起見,下面沒有提及這些。
CJPEG DETAILS
cjpeg的基礎命令行開關:
-quality N[,...] 縮放量化表調節圖像質量。質量數值從0(最差)到100(最佳);默認是75。(下面有更多信息。)
-grayscale 從多色輸入創建單色JPEG文件。壓縮灰度圖時請務必使用此開關。對于BMP文件,因為cjpeg不夠聰明,無法注意到BMP文件是否只使用灰度。通過-grayscale,你可以得到一個更小的JPEG文件,并且花費更少的時間。
-rgb 創建RGB JPEG文件。使用此開關禁止,從RGB顏色空間輸入到默認的YCbCr JPEG顏色空間的,轉換。
-optimize 執行熵編碼參數優化。沒有這個選項,將使用默認的編碼參數。-optimize通常使JPEG文件更小一些,但cjpeg運行速度稍慢,并需要更多的內存。圖像質量和解壓縮速度不會受到該選項影響。
-progressive 創建progressive JPEG文件。(詳細見下文。)
-targa 輸入文件時Targa格式。包含“identification”字段的Targa文件不會被cjpeg自動識別。對于這樣的文件,您必須指定-targa以使cjpeg將輸入視為Targa格式。對于大多數Targa文件,你不需要此開關。
-quality開關可以令你在壓縮文件的大小和重建圖像的質量間做折中:質量設置越高,JPEG文件越大,輸出圖像越接近原始輸入。通常你希望使用盡可能低的質量設置(盡可能小的文件),但要求解壓縮后的重建圖像與原始圖像看不出區別。為此,攝影圖像的質量設置通常應在50至95之間(默認值為75)。如果你在-quality 75看到缺陷,則一次上升5或10,直到你對輸出圖像感到滿意。(最佳設置會因圖像而異。)
-quality 100將會產生都是1的量化表,對于大多數圖像,量化步驟的損失會最小(但是在下采樣中仍存在信息損失以及四舍五入誤差),指定高于約95的質量值將極大增加壓縮文件的大小,并且雖然這些更高質量的數值是可測量的(使用諸如PSNR或SSIM等指標),但人類的視覺卻很少能感知到。
另一方面,低于50的質量值將產生非常小的低質量圖像文件。例如大約5-10的設置可能對準備大型圖像庫的索引很有用。對于一些有趣的立體效果,可以嘗試-quality 2。(注意:低于25的質量值將產生2字節量化表,這在JPEG標準中是可選地。當你提供這樣的質量值時,cjpeg會發出警告消息,因為其他一些JPEG程序可能無法解碼生成的文件。如果你需要確保低質量值的兼容性,請使用-baseline。)
該版本cjpeg已經擴展了-quality選項,以支持亮度和色度的單獨的質量設置(或者每個量化表單獨設置)。原理與色度下采樣相同:人眼對于亮度的空間變化比顏色上的空間變化更敏感,色度分量可以比亮度分量更多的量化,而不會引起任何可見的圖像質量損失。然而,與下采樣不同,此特征能減少頻域中的數據,而不是空間域,從而允許進行更細粒度的控制。此選項在質量敏感的應用程序中非常有用,通過二次下采樣生成的人工制品可能不被接受。
-quality選項接受一個逗號分隔的參數列表,它們分別代表著不同量化表的質量級別。如果量化表數量比參數多,則最后一個參數會不斷重復應用于剩下的量化表。如果只有一個質量參數,則將其用于亮度和色度(槽0或1),保留cjpeg v6b和之前的遺留行為。-qtables選項可以用來設置更多的(自定義的)量化表,并使用-qslots選項分配給顏色成分。(請參閱下面的“wizard”開關。)
以獨立亮度和色度質量生成的JPEG文件,完全符合標準JPEG解碼器。
注意:為使此設置有用,請務必將-sample 1x1的參數傳遞給cjpeg以禁用色度子采樣。否則,將使用默認的子采樣級別(2x2,AKA“4:2:0”)。
-progressive開關創建一個“progressive JPEG”文件。在這種類型的JPEG文件中,數據被存儲在質量不斷提高的多次掃描中。如果文件通過慢速通信鏈路傳輸,則解碼器可以使用第一次掃描非常快速地來顯示低質量的圖像,并且隨后可以隨著每次掃描而改善。最終圖像完全等同于相同質量設置的標準JPEG文件,并且總文件大小大致相同,通常稍微小一些。
高階用戶的開關:
-airthmetic 使用airthmetic編碼。請注意:arithmetic編碼的JPEG并沒有廣泛地實現,所以很多解碼器不能將airthmetic編碼的JPEG文件可視化。
-dct int 使用整型的DCT方法(默認)。
-dct fast 使用快速整型的DCT(不準確一點)。在libjpeg-turbo中,當使用x86/x86-64 SIMD擴展時,快速方法通常比整型方法快5-15%(結果可能隨其他SIMD實現而異,或者使用沒有SIMD擴展的libjpeg-turbo)。對于質量值90及以下的,兩種算法之間應該只有很少或根本沒有可觀察的差異。然后,對于90以上的質量值,快速方法和整型方法之間的差異會變得更加顯著。例如,以質量97來說,快速方法相對于整型方法通常會損失1-3dB(在PSNR中),但對于某些圖像而言,這損失可能更大。不要使用質量值大于97的快速方法。該算法在質量值98時經常退化,并且實際上可以產生比使用較低質量水平更有損的圖像。此外,在libjpeg-turbo中,快速的方法并沒有完全達到97以上的質量水平,所以它將比整型方法滿。
-dct float 使用浮點型DCT方法。浮點法主要是遺留特征。它不會產生比整型方法更顯著地產生更準確的結果,而且要慢得多。由于不同的舍入行為,float方法也可能會在不同的機器上產生不同的結果,而整數法應在所有機器上給出相同的結果。
-restart N 每N個MCU行或塊(如果"B"連接到該數字)發出一個JPEG重新啟動標記。-restart 0(默認值)表示無重新啟動標記。
-smooth N 平滑輸入圖像以消除抖動噪聲。N,范圍從1到100,表示平滑的強度。0(默認值)表示無平滑。
-maxmemory N 設置用于處理大圖像的內存大小的限制。值為數千字節,如果“M”附加到數字,則為數百萬字節。例如,-max 4m選擇4000000字節。如果需要更多空間,則會發生錯誤。
-verbose 或 -debug 啟用調試打印信息。更多的-v's產生更多的打印輸出。版本信息在啟動時打印。
-restart選項插入允許JPEG解碼器在傳輸錯誤后重新同步的額外標記。沒有重新啟動標記,對壓縮文件的任何損失通常會從錯誤點到圖像結尾破壞圖像;使用重新啟動標記,損壞通常限于圖像的部分直到下一個重新啟動標記。當然,重啟標記占用額外的空間。我們建議對于將通過不可靠網絡(如Usent)傳輸的圖像,設置為-restart 1。
-smooth選項對輸入進行濾波以消除細微噪聲。將抖動圖像轉換為JPEG時,通常很有用:10-50的中等平滑因子可以消除輸入文件中的抖動模式,從而產生較小的JPEG文件和更好的圖像。然而,太大的平滑因子會明顯地模糊圖像。
wizards開關:
-baseline 強制生成baseline-compatible量化表。即使在低質量設置下,也將量化值降到8比特。(這個開關命名不佳,因為它們不能確保輸出實際上是基本JPEG。例如,可以一起使用-baseline和-progressive。)
-qtables file 使用指定文本文件作為量化表。
-qslots N[,...] 為每個顏色分量選擇量化表
-sample HxV[,...] 為每個顏色分量設置采樣系數
-scans file 使用指定的文本文件作為掃描文本
“wizard”開關用于實驗JPEG。如果你不知道自己在做什么,不要使用它們。這些開關在wizard.txt中有進一步記錄。
DJPEG DETAILS
djpeg的基礎命令行開關:
-color N 或 - quantize N 將圖像減少到最多N種顏色。這減少了輸出圖像中使用的顏色數量,從而可以將其顯示在彩色顯示器上或以分色文件格式存儲。例如,如果您有一個8位顯示器,則需要減少到256個或更少的顏色。(-color是推薦的名稱,-quantize僅提供向后兼容性。)
-fast 為快速,低質量的輸出選擇推薦的處理選項。(為最高質量輸出選擇默認選項。)目前,這相當于"-dct -nosmooth -onepass -dither ordered"。
-grayscale 即使是JPEG文件是彩色圖也強制輸出灰度圖。用于在單色顯示器上查看;此外,JPEG在此模式下運行速度明顯更快。
-rgb 即使JPEG文件是灰度圖也強制輸出RGB彩色圖。
-scale M/N 通過因子M/N將輸出圖像縮放。目前比例因子必須是M/8,其中M是1和16之間的整數,或者其約分后的分數(如1/2,3/4等)。如果圖像大于屏幕,則適應屏幕縮放;djpeg在縮小輸出時運行得更快。
-bmp 選擇BMP輸出格式(Windows flavor)。如果指定了-color或-grayscale,或者JPEG文件是灰度圖,則發送8位色彩格式,;否則,將發出24位全色格式。
-gif 選擇GIF輸出格式。由于GIF不支持超過256種顏色,因此假設為256(除非指定更少數量的顏色)。如果指定-fast,默認顏色數為256。
-os2 選擇BMP輸出格式(OS/2.1x flavor)。如果指定了-color或-grayscale,或者JPEG文件是灰度圖,則發送8位色彩格式,;否則,將發出24位全色格式。
-pnm 選擇PBMPLUS(PPN/PGM)輸出格式(這是默認格式)。如果JPEG文件是灰度圖或者指定了-grayscale,則會輸出PGM;否則會發輸出PPM。
-rle 選擇RLE輸出格式。(需要URT庫。)
-targa 選擇Targa輸出模式。如果JPEG文件為灰度圖或者如果指定了-grayscale,則會產生灰度格式;否則,如果指定了-colors,則發送colormapped 格式;否則,將會發送24-bit全色格式。
高級用戶的開關:
-dct int 使用整型的DCT方法(默認)。
-dct fast 使用快速整型的DCT(不準確一點)。在libjpeg-turbo中,當使用x86/x86-64 SIMD擴展時,快速方法通常比整型方法快5-15%(結果可能隨其他SIMD實現而異,或者使用沒有SIMD擴展的libjpeg-turbo)。對于質量值90及以下的,兩種算法之間應該只有很少或根本沒有可觀察的差異。然后,對于90以上的質量值,快速方法和整型方法之間的差異會變得更加顯著。例如,以質量97來說,快速方法相對于整型方法通常會損失1-3dB(在PSNR中),但對于某些圖像而言,這損失可能更大。不要使用質量值大于97的快速方法。該算法在質量值98時經常退化,并且實際上可以產生比使用較低質量水平更有損的圖像。此外,在libjpeg-turbo中,快速的方法并沒有完全達到97以上的質量水平,所以它將比整型方法滿。
-dct float 使用浮點型DCT方法。浮點法主要是遺留特征。它不會產生比整型方法更顯著地產生更準確的結果,而且要慢得多。由于不同的舍入行為,float方法也可能會在不同的機器上產生不同的結果,而整數法應在所有機器上給出相同的結果。
-dither fs 在色彩量化中使用Floyd-Steinberg dithering。
-dither ordered 在色彩量化中使用ordered dithering。
-dither none 不要在色彩量化中使用dithering。默認情況下,在量化顏色時應用Floyd-Steinberg dithering;這很慢,但通常會產生最好的結果。Ordered dither是速度和質量之間的妥協;沒有dithering是快速的,但通常看起來很糟糕。注意,除非進行顏色量化,否則這些開關不起作用。Ordered dither只能在-onepass模式下可用。
-map FILE 量化到指定圖像文件中使用的顏色。這對于生成具有相同顏色圖的多個文件,或強制使用預定義的一組顏色非常有用。FILE必須是GIF或PPM文件。此選項覆蓋-colors和-onepass。
-nosmooth 使用更快,更低質量的上采樣程序。
-onepass 使用one-pass代替two-pass色彩量化。one-pass方法更快,需要更少的內存,但會產生較低質量的圖像。-onepass被忽略,除非你指定-color N。此外,one-pass方法總是用于灰度輸出(two-pass方法沒有改進。)
-maxmemory N 設置用于處理大圖像的內存大小的限制。值為數千字節,如果“M”附加到數字,則為數百萬字節。例如,-max 4m選擇4000000字節。如果需要更多空間,則會發生錯誤。
-verbose 或 -debug 啟用調試打印信息。更多的-v's產生更多的打印輸出。版本信息在啟動時打印。
HINTS FOR CJPEG
彩色GIF文件不是JPEG的理想輸入;JPEG真正用于壓縮全色(24位)圖像。特別是,不要嘗試轉換漫畫,線條圖和少量不同顏色的其他圖像。GIF在這些素材上工作很好,但JPEG并不是。如果要將GIF轉換為JPEG,你應該嘗試使用cjpeg的-quality和-smooth選項來獲得令人滿意的轉換。-smooth 10左右,通常很有幫助。
避免使同張圖像通過一系列JPEG壓縮/解壓縮循環。圖像質量地損失將會累積;在10個左右的周期后,圖像可能比一個周期后明顯更糟。最好在操作圖像時使用無損格式,然后在準備將圖像提取后轉換為JPEG格式。
當你制作最終版本的圖像做發布或歸檔時,cjpeg的-optimize選項是值得使用的。當你使用低質量的設置制作非常小的JPEG文件時,這也是一種選擇;小文件所帶來的優勢很可能比高精度的大文件多。(目前,在生成progressive JPEG文件時始終選擇最優化模式。)
由于對Unisys LZW專利的關注,支持GIF輸入文件在cjpeg v6b中被刪除。雖然該專利在2006年到期,但由于這些歷史原因,cjpeg仍然缺乏GIF支持。(無論如何,將GIF文件轉換為JPEG文件通常都是一個壞主意。)
HINTS FOR DJPEG
要快速預覽圖像,請使用-grayscale和/或-scale。"-grayscale -scale 1/8"是最快的。
有幾個選項可用于降低圖像質量以獲得速度。"-fast"能夠打開推薦設置。
“-dct fast”和/或“-nosmooth”能夠在犧牲一點圖像質量的情況下加快速度。當產生color-quantized圖像時,“-onepass -dither ordered”會很快,但比默認設置的質量低很多。“-dither none”可以在two-pass模式下給出可接受的結果,但是在one-pass模式下通常很難接受。
為了避免Unisys LZW專利(現已過期),djpeg生成未壓縮的GIF文件。這會比它們的壓縮版本更大,但是可以被標準的GIF解碼器讀取。
HINTS FOR BOTH PROGRAMS
如果cjpeg或djpeg所需的內存超過-maxmemory指定的限制,則會發生錯誤。你可以省略-optimize(對于cjpeg)或指定-onepass(對于djpeg)來減少內存使用量。
在具有“environment”變量的機器上,你可以定義JPEGMEM這個環境變量來設置默認內存限制。該值按照-maxmemory開關所述設定。JPEGMEM覆蓋編譯程序時指定的默認值,并且自身被顯示的-maxmemory開關覆蓋。
JPEGTRAN
jpegtran執行JPEG文件的各種有用的轉換。它可以將編碼表示從JPEG的一個變體轉換為另一個,例如從baseline JPEG到progressive JPEG,反之亦然。它還可以執行一些數據圖像的重新排列,例如通過旋轉將圖像從橫向轉換為縱向格式。對于包含Exit數據的EXIF文件和JPEG文件,您可能更喜歡使用exiftran。
JPEG通過重新排列壓縮數據(DCT系數),而不會完全解碼圖像。因此,它的變換是無損的:根本沒有圖像劣質化,和你使用djpeg,然后用cjpeg完成相同的轉換是不同的。但是,同樣的道理,jpegtran不能執行諸如改變圖像質量的有損操作。然而,當圖像數據被無損轉換時,可以去除元數據。請參閱JOspecifics的-copy選項。
jpegtran使用和cjpeg,djpeg類似的命令行
在Unix-like系統上,指令為 jpegtran [switches] [inputfile] > outputfile
在大多數non-Unix系統上,指令為jpegtran [switches] inputfile outputfile
輸入和輸出文件都是JPEG文件
為了指定在輸出文件中使用的編碼JPEG方式,jpegtran接受由cjpeg識別的開關的子集:
-optimize 執行熵編碼參數優化。
-progressive 創建progressive JPEG文件。
-arithmetic 使用arithmetic編碼。
-restart N 每N個MCU行或塊(如果"B"連接到該數字)發出一個JPEG重新啟動標記。-restart 0(默認值)表示無重新啟動標記。
-scans file 使用指定的文本文件作為掃描文本、
有關這些開關的更多詳細,請參閱之前cjpeg的討論。如果你不指定這些開關,你將獲得一個簡單的baseline-JPEG輸出文件。質量設置等由輸入文件決定。
以下開關對于轉換來說是無損的:
-flip horizontal 水平鏡像(左右)。
-flip vertical 垂直鏡像(上下)。
-rotate 90 順時針旋轉圖像90度。
-rotate 180 旋轉圖像180度。
-rotate 270 順時針旋轉圖像270度
-transpose
-transverse
transpose變換對圖像尺寸沒有限制。如果圖像尺寸不是iMCU大小的倍數(通常為8或16像素),則其他變換操作相當奇怪,因為它們只能以所需的方式轉換DCT系數數據的完整塊。
當轉換奇數尺寸圖像時,jpegtran的默認行為旨在保留轉換集的精確可逆性和數學一致性。如上所述,transpose可以翻轉整個圖像區域。水平鏡像使右邊緣的任何iMCU列保持原樣,但能夠翻轉圖像的所有行。類似地,垂直鏡像使底部邊緣處的任何iMCU行保持不變,但能夠翻轉所有列。其他變換可以被構建為轉置和翻轉操作的順序;為了一致性,它們對邊緣像素的動作被定義為與相應的轉置和翻轉序列的最終結果相同。