Windows 上的無損影像壓縮：「無損驗證」代表什麼
了解 Windows 上經驗證的無損影像壓縮，包括縮小 92% 的 GIF、完全複製的 PNG 備援結果、螢幕截圖，以及 LocalFlux 1.0.7 的實證。
本頁內容
如果您想在不改變影像內容的情況下縮小檔案，困難之處不在於選擇一個名為Lossless（無損）的設定，而在於證明新檔案仍然呈現相同內容，並且知道軟體無法證明時應該怎麼做。
LocalFlux 1.0.7 以預設拒絕的工作流程處理這種不確定性。它會在本機建立最佳化候選檔案、檢查各格式特有的內容與中繼資料不變條件，且只有在這些檢查通過時，才會發布變更後的候選檔案。如果候選檔案無法通過驗證或並未縮小，LocalFlux 便會改為將來源檔案完整複製一份，並採用新的 _optimized 名稱。
精確複製也需要可讀取的來源檔案及可寫入的目的地。解碼、驗證或寫入錯誤仍可能導致工作失敗，請先檢查每個檔案的狀態。
我使用存放於 C:\tmp 下的合成檔案測試了這兩種結果：
- 一個刻意以低效率方式製作的 12 幀 GIF，從 658,785 位元組縮小至 54,329 位元組，節省 604,456 位元組（91.8%）。LocalFlux 顯示無損驗證，而且全部 12 個算繪後的畫格及各畫格延遲時間都相符。
- 一個已經最佳化的 PNG 維持在 8,290 位元組。LocalFlux 顯示已最佳化，而來源與輸出具有相同的 SHA-256 雜湊值，因此輸出是逐位元組完全相同的副本。
這些範例說明此標籤要表達的含義：LocalFlux 不會把「轉換已完成」等同於「結果是無損的」，也不承諾每個輸入檔案都會變小。
這些是實測範例，不代表普遍都能達到相同的縮減幅度：無損最佳化取決於來源格式、容器結構、中繼資料、先前的編碼方式，以及影像或動畫內容。有效的結果可能大幅縮小、略微縮小，也可能是大小完全不變的完整副本。
簡短解答
若要在不刻意變更內容的情況下最佳化支援的影像：
- 開啟 LocalFlux，然後選取壓縮。
- 加入一個或多個支援的 JPEG、TIFF、靜態 PNG 或 WebP、GIF、APNG 或 SVG 檔案。
- 開啟選項並選擇Lossless（無損）。
- 選取最佳化。
- 檢查每項結果是否顯示無損驗證，以及檔案是否縮小或顯示已最佳化。
LocalFlux 會建立名稱中含有 _optimized 的新檔案。來源檔案會留在原處。處理程序在 Windows 電腦上執行；檔案不會上傳至線上轉換服務。
介面截圖於2026年10月使用依據已記錄的 LocalFlux 1.0.10.0 發佈原始碼重新建置的版本拍攝。下方歷史測量值與下載資料仍保留原始測試範圍。截圖記錄： 1
2026年10月複核：10種介面語言共產生20個輸出，皆與歷史 GIF、PNG 輸出逐位元組一致。GIF 包含12個畫格，每個100 ms，算繪結果與循環設定一致；GIF 延遲值10代表10/100秒。介面的 KB 數值使用1024位元組單位（KiB）。這些結果僅驗證兩個合成樣本，並不代表已驗證所有格式或中繼資料欄位。 2026-10
新截圖中的索引標籤仍顯示英文：Lossless（無損）、Preset（預設）、Target size（目標大小）。
「無損驗證」代表什麼
「無損」經常用來描述編碼器設定。「無損驗證」則描述了更嚴格的結果契約。
在這套 LocalFlux 工作流程中，變更後的候選檔案必須符合三項條件：
- 支援的內容檢查皆通過。視格式而定，這可能包括解碼後的像素、動畫中每一個算繪後的畫格、每一個 TIFF 頁面、時間、尺寸或幾何資訊。
- 支援的內嵌中繼資料檢查皆通過。確切欄位會依容器而異。LocalFlux 會比較它承諾在該處理路徑中保留的中繼資料，而不會假設編碼成功就代表一切都已保留。
- 候選檔案確實更小。如果經驗證的候選檔案沒有節省位元組，取代來源檔案的表示方式便沒有實際的最佳化效益。
如果其中任何條件未獲滿足，變更後的候選檔案就不會以最佳化結果發布。LocalFlux 會將來源檔案的位元組還原至新的輸出路徑，並顯示已最佳化。
最後這項行為非常重要。工具很容易產生一個在快速預覽時看起來相同、實際上卻不同的檔案。要證明像素、頁面、畫格、時間與中繼資料之間的差異皆無害，難度高得多。當證明不完整時，LocalFlux 的原則是選擇保守的結果。
LocalFlux 依格式驗證哪些項目
不同的影像容器需要不同的不變條件。單純採用「比較寬度與高度」的規則會遺漏太多資訊。
| 格式 | LocalFlux 1.0.7 的驗證重點 | 重要的備援行為 |
|---|---|---|
| JPEG | 解碼後的像素簽章，以及原始 APP 與 COM 中繼資料區段 | 編碼表最佳化可能會改變某些輸入的解碼值，因此無法證明等效時，預期會採用完整複製備援。 |
| 靜態 PNG | 解碼後的像素簽章，以及支援的色彩、EXIF、XMP、文字與實體中繼資料區塊 | 最終比較前會先保留必要的輔助中繼資料；無法驗證的候選檔案會被捨棄。 |
| 靜態 WebP | 解碼後的像素簽章，以及支援的內嵌中繼資料區塊 | 只有在內容與中繼資料比較皆通過且檔案更小時，才會發布候選檔案。 |
| TIFF | 每個解碼後的頁面、像素簽章、頁面幾何資訊與支援的中繼資料 | 若 TIFF 含有經驗證的像素儲存標籤集以外的標籤，便會原樣複製，以免冒著在未提示下遺失標籤的風險。 |
| GIF | 每個合成後的算繪畫格、畫格延遲、循環次數，以及保留的註解／應用程式／純文字延伸區塊 | 只有在算繪後的動畫與支援的延伸區塊仍然等效時，才會接受畫格最佳化。 |
| APNG | 正規化的逐畫格雜湊值、時間、畫格數、循環次數，以及保留的 PNG 輔助中繼資料 | 任何不相符或無法驗證的結果都會觸發完整來源檔案備援。 |
| SVG | 來源檔案的位元組本身 | 在無損模式中，SVG 會逐位元組複製。只有在可接受以保守方式移除註解與僅供編輯器使用的資料時，才使用獨立的安全向量最佳化預設。 |
這也正是為何不應把已驗證一詞延伸解讀成：每種檔案格式中的每一項可能屬性，都已經在數學上證明完全等效。它指的是 LocalFlux 1.0.7 為其支援的處理路徑所檢查之明確內容與中繼資料不變條件。
保護隱私的測試設定
本次測試在 Windows 上使用 當時 Microsoft Store 提供的 LocalFlux 1.0.7.0 應用程式。過程中未使用任何私人照片、客戶文件、使用者名稱或專案資料夾。原始1.0.7測試使用下列資料夾；新截圖使用 C:\tmp\LocalFluxBlogRefresh：
C:\tmp\LocalFlux-lossless-proof-v107\input
兩個實證案例均由合成的儀表板圖稿建立：
| 案例 | 輸入 | 用途 |
|---|---|---|
| 可縮減的動畫 | dashboard-animation-repeated-frames.gif | 十二個相同的完整尺寸畫格刻意製造畫格儲存冗餘，讓經驗證的動畫最佳化工具得以移除。 |
| 已最佳化的對照組 | already-optimized-icon.png | 精簡的 PNG 用來測試沒有節省空間與完整複製的分支。 |
這個 GIF 是刻意製作的人工檔案。它的用途在於預期內容毫無歧義：12 個畫格、每個畫格皆為相同的 1920 × 1080 算繪影像，而且每個畫格的延遲值均為 10。它測試的是驗證契約，並不佯稱這是一般動畫壓縮率的代表。
步驟 1：加入支援的影像
開啟 LocalFlux，選取壓縮，然後選擇新增檔案，或將檔案拖曳至佇列。
1.0.7 的無損模式適用於 JPEG、TIFF、靜態 PNG 與 WebP 影像、GIF 與 APNG 動畫，以及 SVG 檔案。之所以特別註明 PNG 與 WebP 必須是靜態內容，是因為動畫內容需要能感知動畫的驗證方式。APNG 與 GIF 各有其支援的處理路徑。
您可以將數個相容檔案一起加入佇列。在壓縮模式中，LocalFlux 會保留每個檔案的格式：PNG 仍是 PNG，GIF 仍是 GIF，依此類推。這與轉換模式不同；在轉換模式中，系統會為目前的批次選取一種輸出格式。
開始前，請確認佇列中包含預期的檔案，而且左下角的模式顯示為壓縮。
步驟 2：選擇無損
開啟選項並選取Lossless（無損）索引標籤。
介面會直接說明此契約：支援的檔案只有在內容與內嵌中繼資料通過驗證後才會進行最佳化，不支援的檔案則會略過。動作按鈕會從壓縮變為最佳化。
此測試請勿啟用安全共享。安全共享是另一套工作流程，其用途是從交付副本中移除私人中繼資料。無損最佳化則會嘗試保留支援的內嵌中繼資料。這兩者的目標刻意有所不同：
- 如果您希望檔案以更精簡的方式呈現，而不刻意變更支援的內容或中繼資料，請選擇Lossless（無損）。
- 如果您希望取得已清理的副本，並接受刻意移除中繼資料，請選擇安全共享。
步驟 3：在本機執行最佳化
選取最佳化，等候佇列完成。當輸出摘要顯示輸出：與原始檔相同時，LocalFlux 會將輸出寫入來源檔案旁。
例如：
dashboard-animation-repeated-frames.gif會變成dashboard-animation-repeated-frames_optimized.gif。already-optimized-icon.png會變成already-optimized-icon_optimized.png。
原始名稱的檔案會保留。這讓比較成為可能，但仍不能取代為重要工作妥善備份。
處理路徑完全在本機。安裝、Microsoft Store 授權或更新仍可能用到網路，但此操作不會將來源檔案傳送至遠端轉換伺服器。
結果 1：真正縮小且通過驗證的檔案
這個 12 幀 GIF 產生了明確的縮減結果：
| 測量項目 | 來源 | LocalFlux 輸出 |
|---|---|---|
| 確切大小 | 658,785 位元組 | 54,329 位元組 |
| 顯示大小 | 643.3 KB | 53.1 KB |
| 畫格 | 12 | 12 |
| 尺寸 | 1920 × 1080 | 1920 × 1080 |
| 逐畫格延遲序列 | 100 ms × 12 | 100 ms × 12 |
| 節省的位元組 | 不適用 | 604,456 位元組 |
| 縮減幅度 | 不適用 | 91.8% |
來源與輸出的 SHA-256 雜湊值不同；對於容器表示方式已有變更的檔案，這符合預期：
- 來源：
202D74DFBBEA150AE514BBE064602F73F150BAB438B39269371013D71F68B0D2 - 輸出：
BE4170949D86B8E0819A181A25DDD3718BF2AD79E7C1E80F8B9D4D60017B2C02
雜湊值不同並不違背無損驗證。這證明檔案的位元組發生了變化。真正要問的是，解碼後的動畫與支援的中繼資料是否仍然等效。LocalFlux 顯示內容與內嵌中繼資料均已保留，而另一項獨立的算繪畫格比較也確認前後的畫格簽章相同。
為何縮減幅度如此之大？來源檔案刻意儲存了 12 個完整且重複的畫格。最佳化後的 GIF 能以更有效率的方式呈現這種重複內容。若真實動畫中幾乎每個畫格的大部分區域都在移動，節省幅度可能小得多。
結果 2：完整複製備援
這個 8,290 位元組的 PNG 未能產生符合契約且更小的候選檔案。LocalFlux 顯示：
無損驗證 · 8.1 KB → 8.1 KB · 已最佳化
這項結果並非只是顯示大小四捨五入後相同。兩個檔案都恰好是 8,290 位元組，而且都具有以下 SHA-256 雜湊值：
F287BBCE8EB98A9F19416DCE1A74A759F3AC8DDA69ADB338022CB1B8F90BD937
相同的雜湊值證明輸出是與輸入逐位元組相同的副本。LocalFlux 仍會建立 _optimized 輸出，讓批次作業能以可預期的目的地完成，但不會宣稱不存在的空間節省。
「已最佳化」可能代表編碼器找不到更小的候選檔案，也可能代表變更後的候選檔案無法符合驗證契約。從使用者的角度來看，安全結果相同：來源檔案的位元組會成為輸出檔案的位元組。
為什麼有些看似沒有效率的檔案仍會變成完整副本
檔案看起來可能沒有效率，卻仍無法產生可發布且經過驗證的候選檔案。只看大小並不足夠。
例如，重新編碼器可能會：
- 使解碼後的某個像素值產生極小變化；
- 以不等效的方式改寫色彩資訊；
- 遺漏驗證器必須保留的中繼資料，或變更其順序；
- 改變 GIF 的時間或處置行為；
- 省略陌生的 TIFF 標籤；或
- 建立有效但更大的容器。
傳統的最佳化工具可能接受其中某些取捨。無損驗證模式不會如此。它寧可完整複製，也不接受未經證明的變更。
這也解釋了為何 JPEG 經常會進入備援分支。JPEG 通常與有損編碼相關。LocalFlux 的無損嘗試著重於編碼表最佳化，同時要求解碼後的像素簽章與原始 APP/COM 中繼資料維持等效。如果內建編碼器改變了解碼值，即使在一般縮放比例下看起來完全相同，候選檔案仍會遭到拒絕。
無損、預設與目標大小的比較
LocalFlux 提供三種不同的壓縮意圖。請勿將它們視為「縮小檔案」的同義標籤。
| 策略 | 主要目標 | 影像內容能否刻意變更？ | 是否保證結果更小？ |
|---|---|---|---|
| 預設 | 平衡視覺品質與大小 | 可以，視格式與預設而定 | 否 |
| 目標大小 | 嘗試將檔案控制在選定的位元組限制內 | 可以；在政策允許範圍內，可能降低品質，有時也可能縮小尺寸 | 否，目標可能無法達成 |
| 無損 | 保留經驗證的內容與支援的中繼資料 | 除非驗證通過，否則不會發布變更後的候選檔案 | 否，完整複製備援也是有效結果 |
若要製作網站交付副本，且可接受小幅、可控的視覺取捨，請使用預設。若要符合上傳表單或附件的大小上限，請使用目標大小。當維持經驗證的內容契約比盡量縮小更重要時，請使用無損。
可以批次執行經驗證的無損最佳化嗎？
可以。第一張螢幕截圖顯示一個佇列中有兩個不同格式的支援檔案。相同策略會套用至相容且待處理的項目，同時每個檔案都會保留目前的格式。
批次處理的價值不在於每個項目都獲得相同的縮減百分比，而在於每個項目都採用相同的決策原則：
- 嘗試適合該格式的最佳化；
- 驗證支援的不變條件；
- 只有在變更後的候選檔案更小時才予以保留；以及
- 否則便發布完整副本。
完成後請檢查每個檔案的資料列。同一個批次完全可能同時包含大幅縮減、小幅縮減，以及數個已最佳化的副本。
查看實證
發布套件包含本文使用的合成輸入檔案、LocalFlux 輸出、確切測量結果與雜湊值：
- 測試記錄
- 各檔案結果與 SHA-256 值
- 隱私審查
- 包含檔案大小與 SHA-256 值的媒體資訊清單
- 可縮減的合成 GIF 輸入
- 經驗證且更小的 GIF 輸出
- 已最佳化的 PNG 輸入
- 完整複製的 PNG 輸出
所有可見的路徑與檔案名稱都是合成的。螢幕截圖皆已經過審查，確認未包含使用者名稱、帳戶詳細資料、個人資料夾、客戶名稱或其他識別資訊。
常見問題
無損驗證是否代表每個檔案都會縮小？
否。這表示 LocalFlux 只有在支援的內容與中繼資料檢查通過後，才會發布變更後的候選檔案。如果候選檔案並未縮小或無法驗證，輸出便是完整副本。
為什麼無損結果的雜湊值可能不同？
無損描述的是解碼後的內容與支援的不變條件，而不是相同的容器位元組。成功的最佳化工具可以重新組織壓縮資料，而不改變解碼後的像素或畫格。相較之下，完整複製備援會具有相同的雜湊值，因為每個位元組都完全相同。
「已最佳化」結果是失敗嗎？
不是。作業已安全完成，只是找不到值得發布、經驗證且更小的表示方式。
原始檔案會遭到覆寫嗎？
在本次測試的工作流程中不會。LocalFlux 會建立 _optimized 同層檔案。無論如何，請務必為無法取代的來源檔案保留備份。
無損模式會移除 EXIF 或位置中繼資料嗎？
它的目標是保留，而非清除。若要 LocalFlux 建立並驗證已移除私人中繼資料的副本，請使用安全共享。請務必檢查您實際準備分享的檔案。
此工作流程完全離線嗎？
支援的最佳化會在電腦上執行，不會將來源檔案上傳至轉換伺服器。透過 Windows 或 Microsoft Store 進行安裝、授權與更新時，仍可能使用網路。
支援哪些格式？
LocalFlux 1.0.7 支援對 JPEG、TIFF、靜態 PNG 與 WebP、GIF、APNG 及 SVG 執行經驗證的無損最佳化。不支援的項目不會在未提示的情況下被視為已驗證。
實用檢查清單
最佳化前：
- 從已備份的來源檔案開始；
- 確認檔案受到支援；
- 選取壓縮，然後選取Lossless（無損）；
- 除非您的實際目標是移除中繼資料，否則請勿啟用安全共享；以及
- 處理整個封存檔案前，先測試一組具代表性的樣本。
最佳化後：
- 檢查每個已完成的資料列是否顯示無損驗證；
- 區分實際縮減與已最佳化；
- 對重要動畫比較畫格數與時間；
- 在實際的目的地應用程式中開啟結果；
- 在輸出經過審查前保留原始檔案；以及
- 記錄確切的位元組數，不要只依賴四捨五入後的 KB 標籤。
結果
經驗證的無損最佳化之所以有價值，是因為它讓不確定性清楚可見。在這次 LocalFlux 1.0.7 測試中，一個合成 GIF 在保留經驗證的動畫不變條件下縮小了 91.8%。另一個已經很精簡的 PNG 則節省 0%，改為產生逐位元組完全相同的副本。
兩者都是成功的結果。第一項移除了冗餘的儲存空間。第二項拒絕未經證明或毫無意義的改寫。它們共同展現了一項比「每張影像都會縮小」更實用的承諾：只有在支援的內容與中繼資料檢查通過時，才會發布變更後的檔案；若未通過，便以完整來源檔案作為備援。