PCDVD數位科技討論區

PCDVD數位科技討論區 (https://www.pcdvd.com.tw/index.php)
-   七嘴八舌異言堂 (https://www.pcdvd.com.tw/forumdisplay.php?f=12)
-   -   JPEG XL, 圖像格式應該也要進入下一個世代了 (https://www.pcdvd.com.tw/showthread.php?t=1207037)

blueck 2024-03-05 05:00 PM

引用:
作者Adsmt
我目前手上的漫畫圖檔有 137GB, 如果轉成 jxl 可以少一半。目前正在想如何寫個程式去自動執行全部轉換。

可能很多人會說現在硬碟空間那麼大才一百多G的東西。但是為了保險,我是有備份到雲端的,對雲端而言,這空間就很重要了。

我測試僅省17~18%

是灰階的漫畫圖省比較多嗎?

Adsmt 2024-03-05 05:38 PM

引用:
作者blueck
我測試僅省17~18%
是灰階的漫畫圖省比較多嗎?

可以提高壓縮率。

我用我第一篇那樣的設定測試多次,不論什麼圖片,結果都差不多。

XnViewMP

1. jpeg, 品質 90, 最佳化哈夫曼表,最佳化取樣。

2. jxl, 品質 90, 壓縮率 9

放大比對,jxl 檔案只有一半,品質明顥更好。如果調到和 jpeg 一樣的品質,檔案還會小更多。不過我覺得小一半,品質更好就夠了。

oversky. 2024-03-05 06:25 PM

引用:
作者Adsmt
我目前手上的漫畫圖檔有 137GB, 如果轉成 jxl 可以少一半。目前正在想如何寫個程式去自動執行全部轉換。

可能很多人會說現在硬碟空間那麼大才一百多G的東西。但是為了保險,我是有備份到雲端的,對雲端而言,這空間就很重要了。


XnViewMP 可以批次轉,
也可以多核心,
我覺得很好用。

原來網友已經用了,這樣為何還要寫程式?
要建目錄?

a9607 2024-03-05 07:07 PM

引用:
作者oversky.
XnViewMP 可以批次轉,
也可以多核心,
我覺得很好用。

原來網友已經用了,這樣為何還要寫程式?
要建目錄?


記得XnView 可以轉整個目錄(含子目錄) 到一個新的目錄(含目錄完整結構)

:)

Adsmt 2024-03-05 11:55 PM

引用:
作者oversky.
XnViewMP 可以批次轉,
也可以多核心,
我覺得很好用。
原來網友已經用了,這樣為何還要寫程式?
要建目錄?

因為圖檔是rar封裝起來的,用多重子目錄分類,要全部解壓,轉檔,再封裝回去。

我也不清楚是不是用程式支援的功能就可以,有空再試試。

LeeMichael 2024-03-06 08:56 AM

引用:
作者Adsmt
這比喻錯了吧,mp3 早被淘汰了。你現在還看得到 mp3 都是舊的檔案。
現在各影音多媒體、串流,早已不使用 mp3.

就算是「謎之來源」的音樂,我也很久沒看到 mp3 了,大多是 flac 或 aac, 還有 wav 的.

jpeg 最後還是會在不知不覺中被淘汰的,如果各裝置、軟體都有支援新格式,那大家就不會去管取得的是什麼格式。且先進格式能以比 jpeg 小一半的檔案,壓出更好的畫質,就會趨使「內容提供者」去使用先進格式,以節省空間及流量。

就像大家有在意從 itune 購買的音樂是 aac 嗎?從 youtune 看或下載的影片,格式是 av1, 聲音是 opus 嗎?

過去經常看到有人在問怎麼把 aac 轉成 mp3, 但現在我已經很久沒看到這種文了。

但問題就是現在圖形交換格式JPG是最普遍的,會不會淘汰?大家等等看。

音樂檔使用別的格式就因為是內容提供者的原因,但你覺得圖形交換格式也有一樣的情境嗎?

同意這種格式應該比較好,但好格式等於注定普遍?再看看吧 ..... 過去太多的例子了。

ExtremeTech 2024-03-06 09:33 AM

引用:
作者Adsmt
我目前手上的漫畫圖檔有 137GB, 如果轉成 jxl 可以少一半。目前正在想如何寫個程式去自動執行全部轉換。

可能很多人會說現在硬碟空間那麼大才一百多G的東西。但是為了保險,我是有備份到雲端的,對雲端而言,這空間就很重要了。



很希望Google項目可以支援JXL

但是現在只支援到WEBP

但是要他們支援JXL的話
就更難頂到容量上限了
這樣能賺錢的機率又更少
感覺在砸自己腳

blueck 2024-03-06 11:01 AM

引用:
作者Adsmt
可以提高壓縮率。

我用我第一篇那樣的設定測試多次,不論什麼圖片,結果都差不多。

XnViewMP

1. jpeg, 品質 90, 最佳化哈夫曼表,最佳化取樣。

2. jxl, 品質 90, 壓縮率 9

放大比對,jxl 檔案只有一半,品質明顥更好。如果調到和 jpeg 一樣的品質,檔案還會小更多。不過我覺得小一半,品質更好就夠了。

你的source是什麼? 如果來源原本就是jpg, 不可能用jxl後還比較好,除非你是降解析度。

人肉插騷包 2024-03-06 11:40 AM

引用:
作者blueck
你的source是什麼? 如果來源原本就是jpg, 不可能用jxl後還比較好,除非你是降解析度。


我猜是自己掃描書本 :rolleyes:

a9607 2024-04-04 02:06 PM

GOOGLE的Jpegli 應該會讓JPEG格式再稱霸好一陣子

https://opensource.googleblog.com/2...ng-library.html (2024/04/03)

引用:
這是一種先進的JPEG 編碼庫,它保持了高度的向後相容性,同時提供增強的功能,並在高品質壓縮設定下將壓縮比提高了35%

Jpegli 是一個新的 JPEG 編碼庫,其設計比傳統 JPEG 更快、更有效率、更美觀。它使用了許多新技術來實現這些目標,包括:

它提供了完全可互通的編碼器和解碼器,符合原始 JPEG 標準及其最傳統的 8 位元形式,以及與 libjpeg-turbo 和 MozJPEG 的 API/ABI 相容性

◎ 高品質的結果

當透過 Jpegli 壓縮或解壓縮影像時,會執行更精確且心理視覺上有效的計算,並且影像將看起來更清晰且可觀察到的偽影更少。

◎ 速度快

在提高影像品質/壓縮密度比的同時,Jpegli 的編碼速度與 libjpeg-turbo 和 MozJPEG 等傳統方法相當。這意味著 Web 開發人員可以輕鬆地將 Jpegli 整合到他們現有的工作流程中,而無需犧牲編碼速度效能或記憶體使用。

◎ 10+位元色深

Jpegli 每個組件可以使用 10+ 位元進行編碼。傳統的 JPEG 編碼解決方案僅提供每個組件 8 位元動態,導致緩慢梯度中 出現可見的條帶偽影。 Jpegli 的 10+ 位元編碼以原始 8 位元形式進行,產生的影像可與 8 位元檢視器完全互通。 10+ 位元動態可作為 API 擴充功能使用,需要更改應用程式程式碼才能從中受益。

◎ 更密集

Jpegli 比傳統 JPEG 編解碼器更有效地壓縮影像,可節省頻寬和儲存空間,並加快網頁速度。

引用:
Jpegli 的工作原理

Jpegli 的工作原理是使用許多新技術來降低雜訊並提高影像品質;主要是來自JPEG XL參考實現的自適應量化啟發式、改進的量化矩陣選擇、精確計算中間結果,並有可能使用更高級的色彩空間。所有新方法都經過精心設計,以使用傳統的 8 位元 JPEG 形式,因此新壓縮的影像與現有的 JPEG 檢視器(例如瀏覽器、影像處理軟體等)相容。

◎ 自適應量化啟發法

Jpegli 使用自適應量化來降低雜訊並提高影像品質。這是透過基於心理視覺建模對量化死區進行空間調製來完成的。使用我們最初為 JPEG XL 開發的自適應量化啟發式方法,可以提高影像品質並減少檔案大小。這些啟發式方法比guetzli中最初使用的類似方法快得多。

◎ 改進的量化矩陣選擇

Jpegli 還使用一組量化矩陣,這些矩陣是透過優化心理視覺品質指標的組合而選擇的。 Jpegli 中的精確中間結果可提高影像質量,且編碼和解碼都會產生更高品質的結果。 Jpegli 可以使用 JPEG XL 的 XYB 色彩空間來進一步提高品質和密度。



這下JPEG格式真的可以再戰20年了


:laugh:


所有的時間均為GMT +8。 現在的時間是01:48 PM.

vBulletin Version 3.0.1
powered_by_vbulletin 2025。