圖像編碼庫

Question

有無損圖像編碼/解碼的好庫，它的壓縮率或多或少與PNG類似，但是解碼爲原始RGB位圖數據會比PNG快得多？

也需要alpha透明度，但不是必需的，因爲alpha通道可以從單獨的圖像中獲取。

原始問題在於使用標準庫在iPhone上閱讀和解碼PNG文件的速度緩慢。顯而易見的是，簡單的解決方案將存儲原始RGB位圖數據，但解壓後的ipa的大小太大 - 比PNG文件大4倍。所以，我試圖找到一些折中解決方案。

Answer 1

只要您不需要在iPhone上壓縮，Lempel-Ziv解碼速度相當快。然而，你是否會得到良好的壓縮是另一個問題。您的第一步應該是將原始ppm格式的圖像轉儲並使用gzip進行壓縮。我已經在幾個SO屏幕截圖上嘗試了這一點，並且因爲顏色數量相對較少，所生成的文件大小與PNG相同（略小）。該測試是

pngtopnm so.png | gzip -v9 | wc -c 

如果這個測試會產生一些對您的應用程序足夠小，你是好去對原始位圖—只是運行gzip和在你的iPhone應用程序中使用的微小，其實libz進行解碼。如果速度不夠快，您可以嘗試更快速的基於Lempel-Ziv的解碼器。

如果您的圖像有很多顏色，但效果不佳，您可能需要考慮某種形式的有損壓縮。

Answer 2

爲什麼不使用原始的原始RGB（A）數據並使用zip，RLE，huffman等進行壓縮和解壓縮？

Answer 3

除非你的圖片被限制在特定的問題領域（例如計算機生成的截圖），其中定製的解決方案可能能夠同時滿足解碼目標的壓縮比和速度，這些通常是必須權衡的，你必須在非此即彼。

PNG壓縮在封面下使用熵編碼技術，所以重新實現，你自己不可能提供幫助。

您可能會採用某種程序化解決方案，通過在單獨的線程中延遲加載圖像來「隱藏」來自用戶的慢度。

Answer 4

PNG壓縮是一個基本預測（鄰居像素），然後是Zip壓縮。如果你真的需要低內存CPU需求的無損壓縮，那麼這個策略很難打敗......你有一個像樣的PNG創建庫。編碼瓶頸是壓縮壓縮。 （另外一個人已經指出，記住解碼比編碼要快得多）。 只壓縮原始圖像只會稍微快一些，並且（除非特定圖像）壓縮效率要低得多。

Answer 5

你最好的快速和骯髒的結果將來自使用7zip SDK解碼已被格式化爲ABGR（小端）的原始圖像數據。然後，您可以使用UIKit API將此圖像數據粘貼到屏幕上。如果您想查看示例iOS代碼，請在「AVAnimator iOS」上執行谷歌搜索，您將找到一個實現此方法的開源庫。您需要做的主要事情是確保圖形數據的每個像素已經以iOS的最佳方式格式化，這基本上是xcode在準備用於iOS項目中的PNG文件時所做的。