我正在查看將多個JPEG圖像作爲單個較大圖像一起存儲時，減少存儲空間的問題。基本的直覺是，圖像往往有一些相似之處（如在同一地點或在同一時間點採取的），我們可以利用這種相似性來節省空間嗎？JPEG圖像壓縮
整個流程是：輸入圖像JPG - >每個圖像轉換成RGB圖像平鋪 - >重新組織相似RGB瓦片一起 - >再次變換到JPG格式。當然，在檢索圖像時，我們需要反向的過程。
使用Y分量的DC係數作爲瓷磚重組的相似度量，對於10幅圖像我獲得了〜8％的空間節省。當我爲100張圖片做這件事時，節省下降到〜3％。
如何在重新組織後得到儲蓄 - 即JPEG編碼過程的哪個部分利用了此圖像塊重組？
相反Y分量的DC係數，在那裏你能想到的，其他一些指標將通過JPEG編碼來更好地利用
修訂：
有一些其他除JPG以外的圖像格式可以利用這種相似性聚合多個圖像時更好嗎？比如像PNG？
你很可能使用JFIF進行編碼。
我不確定您希望這種方法如何工作。如果我理解正確，那麼您將圖像分解爲多個圖像，將它們聚合成一個超大圖像，並將「相似」的圖塊彼此靠近排列。AFAIK，JPEG實現在圖像中爲每個單獨的8x8瓦片執行單獨的DCT，稱爲宏塊。換句話說，JPEG不能利用相鄰宏塊之間的一致性（這似乎是壓縮技術的基本假設）。
如果你自己的圖塊大於宏塊，除了圖像頭部空間的節省之外，你不會看到任何改進。例如：將10個JPG圖像頭替換爲1會節省90％的空間，但只能在頭部。當您查看整個文件時，標題只是整個文件的一小部分，因此節省的空間很小。當將100個圖像標題替換爲1時，您節省了99％，但是僅在標題上再次提供。在這兩種情況下，所有的宏塊仍然被編碼和存儲，完全像以前一樣。
有兩個領域，你會看到好處：
首先，當你把相似的區域相鄰（特別是在圖像的邊緣匹配完美，沒有間斷 - 儘管這將是非常罕見），jpeg算法的DCT（頻率空間）部分通過逐漸逼近大區域（不確定最大大小是多少）來工作，然後查看大區域近似和多個較小區域之間的誤差，並製作更多的本地化修正。
我懷疑這種影響很小，除非你的圖像是很相似，或者很小（因此它們的邊緣與它們的面積成比例）。
其次，JPEG壓縮的Huffman coding部分將看到一個好處，因爲相同的比特模式將出現在多個子圖像，並用相同的（短）被壓縮令牌）。
這個方面將不取決於您壓縮圖像的方式 - 只要它們在相同的圖像。
感謝您的迴應！我不確定你的第一部分。但是，我認爲霍夫曼編碼可以利用這一點_some_ extent_if_我將最終輸出分割成多個圖像，每個圖像具有相似的圖塊。但是，我認爲這不能解釋我獲得的空間節省。我已經修改了我的問題 - 請看看。 – user655617 2013-03-08 00:09:47
謝謝，這很有道理！我使用libjpeg來進行編碼和解碼。由於JPEG在8x8宏塊內進行DCT，所以瓷磚之間的相似性（大於宏塊）可能沒有多大幫助。但是，我認爲相鄰宏塊的DCT係數是相對編碼的，這可能在一定程度上通過這種塊重組而得到改善。我修改了我的問題 - 請看看。 – user655617 2013-03-08 00:14:09
很高興我能幫助澄清事情。是的，libjpeg是IJG參考JPEG標準的JFIF實現。我不記得使用delta編碼的DCT係數（在相鄰的宏塊之間）。 AFAIR中，每個宏塊都變成一個單一的8x8係數矩陣，然後對其進行抽取（分割以減少存儲它們所需的位數 - 這是有損壓縮中的「損失」來自哪裏），並在zig中讀出時尚。這種排序產生長時間運行的0，它們通過運行長度編碼被有效地壓縮（而不是存儲17個零，我們存儲17,0）。 – 2013-03-08 06:14:10