哈夫曼編碼圖片壓縮

⑴ 為什麼說哈夫曼編碼是壓縮率最高的編碼

假設用於通信的電文由字元集{a,b,c,d,e,f,g,h}中的字母構成，這8個字母在電文中出現的概率分別為{0.07,0.19,0.02,0.06,0.32,0.03,0.21,0.10}。

哈夫曼編碼 根據上面可得編碼表： a:1001 b:01 c:10111 d:1010 e:11 f:10110 g:00 h:1000

用三位二進行數進行的等長編碼平均長度為3，而根據哈夫曼樹編碼的平均碼長為：4*0.07+2*0.19+5*0.02+4*0.06+2*0.32+5*0.03+2*0.21+4*0.10=2.61 2.61/3=0.87=87%其平均碼長是等長碼的87%，所以平均壓縮率為13%。

因為定長編碼已經用相同的位數這個條件保證了任一個字元的編碼都不會成為其它編碼的前綴,所以這種情況只會出現在變長編碼當中，要想避免這種情況，

就必須用一個條件來制約定長編碼，這個條件就是要想成為壓縮編碼，變長編碼就必須是前綴編碼，所謂的前綴編碼就是任何一個字元的編碼都不能是另一個字元編碼的前綴。

(1)哈夫曼編碼圖片壓縮擴展閱讀：

實際應用中，除採用定時清洗以消除誤差擴散和採用緩沖存儲以解決速率匹配以外，主要問題是解決小符號集合的統計匹配，

例如黑（1）、白（0）傳真信源的統計匹配，採用0和1不同長度遊程組成擴大的符號集合信源。遊程，指相同碼元的長度（如二進碼中連續的一串0或一串1的長度或個數）。按照CCITT標准，需要統計2×1728種遊程（長度），

這樣，實現時的存儲量太大。事實上長遊程的概率很小，故CCITT還規定：若l表示遊程長度，則l=64q+r。其中q稱主碼，r為基碼。編碼時，不小於64的遊程長度由主碼和基碼組成。而當l為64的整數倍時，只用主碼的代碼，已不存在基碼的代碼。

⑵ 利用huffman編碼對文件進行壓縮，不同文件類型壓縮率有差別的原因

怎麼沒人回答呢 我來回答吧 我想從壓縮文件的原理能得到你這個問題的答案（有點長，請耐心看，絕對長知識）： 壓縮文件的運行原理 如果您從互聯網上下載了許多程序和文件，可能會遇到很多ZIP文件。這種壓縮機制是一種很方便的發明，尤其是對網路用戶，因為它可以減小文件中的比特和位元組總數，使文件能夠通過較慢的互聯網連接實現更快傳輸，此外還可以減少文件的磁碟佔用空間。在下載了文件後，計算機可使用WinZip或Stuffit這樣的程序來展開文件，將其復原到原始大小。如果一切正常，展開的文件與壓縮前的原始文件將完全相同。
乍一聽好像很神秘：您是怎樣減少比特和位元組的數量並將它們原封不動地還原回去的呢？等一切水落石出之後，您會發現這個過程背後的基本理念其實非常簡單明了。在本文中，我們將討論這種通過簡單壓縮來明顯減小文件的方法。
大多數計算機文件類型都包含相當多的冗餘內容——它們會反復列出一些相同的信息。文件壓縮程序就是要消除這種冗餘現象。與反復列出某一塊信息不同，文件壓縮程序只列出該信息一次，然後當它在原始程序中出現時再重新引用它。
以我們熟悉的信息類型——單詞——為例子。
肯尼迪（John F. Kennedy）在1961年的就職演說中曾說過下面這段著名的話：
Ask not what your country can do for you——ask what you can do for your country.（不要問國家能為你做些什麼，而應該問自己能為國家做些什麼。）
這段話有17個單詞，包含61個字母、16個空格、1個破折號和1個句點。如果每個字母、空格或標點都佔用1個內存單元，那麼文件的總大小為79個單元。為了減小文件的大小，我們需要找出冗餘的部分。
我們立刻發現：
如果忽略大小寫字母間的區別，這個句子幾乎有一半是冗餘的。九個單詞（ask、not、what、your、country、can、do、for、you）幾乎提供了組成整句話所需的所有東西。為了構造出另一半句子，我們只需要拿出前半段句子中的單詞，然後加上空格和標點就行了。
大多數壓縮程序使用基於自適應字典的LZ演算法來縮小文件。「LZ」指的是此演算法的發明者Lempel和Ziv，「字典」指的是對數據塊進行歸類的方法。
排列字典的機制有很多種，它也可以像編號列表那樣簡單。在我們檢查肯尼迪這句著名講話時，可以挑出重復的單詞，並將它們放到編號索引中。然後，我們直接寫入編號而不是寫入整個單詞。
因此，如果我們的字典是：
ask
what
your
country
can
do
for
you
我們的句子現在就應該是這樣的：
1 not 2 3 4 5 6 7 8-- 1 2 8 5 6 7 3 4
如果您了解這種機制，那麼只需使用該字典和編號模式即可輕松重新構造出原始句子。這就是在展開某個下載文件時，計算機中的解壓縮程序所做的工作。你可能還遇到過能夠自行解壓縮的壓縮文件。若要創建這種文件，編程人員需要在被壓縮的文件中設置一個簡單的解壓縮程序。在下載完畢後，它可以自動重新構造出原始文件。
但是使用這種機制究竟能夠節省多少空間呢？「1 not 2 3 4 5 6 7 8——1 2 8 5 6 7 3 4」當然短於「Ask not what your country can do for you-- ask what you can do for your country.」，但應注意的是，我們需要隨文件一起保存這個字典。
在實際壓縮方案中，計算出各種文件需求是一個相當復雜的過程。讓我們回過頭考慮一下上面的例子。每個字元和空格都佔用1個內存單元，整個原句要佔用79個單元。壓縮後的句子（包括空格）佔用了37個單元，而字典（單詞和編號）也佔用了37個單元。也就是說，文件的大小為74個單元，因此我們並沒有把文件大小減少很多。
但這只是一個句子的情況！可以想像的是，如果用該壓縮程序處理完肯尼迪講話的其餘部分，我們會發現這些單詞以及其他單詞重復了更多次。而且，正如下一節所言，為了得到盡可能高的組織效率，可以對字典進行重寫。
在上一個的例子中，我們挑出了所有重復的單詞並將它們放在一個字典中。對於我們來說，這是最顯而易見的字典編寫方法。但是壓縮程序卻不這樣認為：它對單詞沒有概念——它只會尋找各個模式。為了盡可能減小文件的大小，它會仔細挑選出最優模式。
如果從這個角度處理該句子，我們最終會得到一個完全不同的字典。
如果壓縮程序掃描肯尼迪的這句話，它遇到的第一個冗餘部分只有幾個字母長。在ask not what your中，出現了一個重復的模式，即字母t後面跟一個空格——在not和what中。如果壓縮程序將此模式寫入字典，則每次出現「t」後面跟一個空格的情況時，它會寫入一個「1」。但是在這個短句中，此模式的出現次數不夠多，不足以將其保留為字典中的一個條目，因此程序最終會覆蓋它。
程序接下來注意到的內容是ou，在your和country中都出現了它。如果這是一篇較長的文檔，將此模式寫入字典會節省大量空間——在英語中ou是一個十分常見的字母組合。但是在壓縮程序看完整個句子後，它立即發現了一個更好的字典條目選擇：不僅ou發生了重復，而且your和country整個單詞都發生了重復，並且它們實際上是作為一個短語your country一起發生重復的。在本例中，程序會用your country條目覆蓋掉字典中的ou條目。
短語can do for也發生了重復，一次後面跟著your，另一次跟著you，因此我們又發現can do for you也是一種重復模式。這樣，我們可以用一個數字來代替15個字元（包含空格），而your country只允許我們用一個數字代替13個字元（包含空格），所以程序會用r country條目覆蓋your country條目，然後再寫入一個單獨的can do for you條目。程序通過這種方式繼續工作，挑出所有重復的信息，然後計算應該將哪一種模式寫入字典。基於自適應字典的LZ演算法中的「自適應」部分指的就是這種重寫字典的能力。程序執行此工作的過程實際上非常復雜。
無論使用什麼方法，這種深入搜索機制都能比僅僅挑出單詞這種方法更有效率地對文件進行壓縮。如果使用我們上面提取出的模式，然後用「__」代替空格，最終將得到下面這個更大的字典：
ask__
what__­
you
r__country
__can__do__for__you
而句子則較短：
「1not__2345__--__12354」
句子現在佔用18個內存單元，字典佔用41個單元。所以，我們將文件總大小從79個單元壓縮到了59個單元！這僅僅是壓縮句子的一種方法，而且不一定是最高效的方法。（看看您能找到更好的方法嗎！）
那麼這種機制到底有多好呢？文件壓縮率取決於多種因素，包括文件類型、文件大小和壓縮方案。
在世界上的大多數語言中，某些字母和單詞經常以相同的模式一起出現。正是由於這種高冗餘性，而導致文本文件的壓縮率會很高。通常大小合適的文本文件的壓縮率可以達到50%或更高。大多數編程語言的冗餘度也很高，因為它們的命令相對較少，並且命令經常採用一種設定的模式。對於包含大量不重復信息的文件（例如圖像或MP3文件），則不能使用這種機制來獲得很高的壓縮率，因為它們不包含重復多次的模式。
如果文件有大量重復模式，那麼壓縮率通常會隨著文件大小的增加而增加。從我們的例子中就可以看出這一點——如果我們摘錄的肯尼迪講話再長一些，您會發現又多次出現了我們字典中的模式，因此能夠通過每個字典條目節省更多的文件空間。此外，對於更大的文件，還可能出現具有更大普遍性的模式，從而能夠創建出效率更高的字典。
此外，文件壓縮效率還取決於壓縮程序使用的具體演算法。有些程序能夠在某些類型的文件中更好地尋找到模式，因此能更有效地壓縮這些類型的文件。其他一些壓縮程序在字典中又使用了字典，這使它們在壓縮大文件時表現很好，但是在壓縮較小的文件時效率不高。盡管這一類的所有壓縮程序都基於同一個基本理念，但是它們的執行方式卻各不相同。程序開發人員始終在嘗試建立更好的壓縮機制。
有損壓縮和無損壓縮
我們在上文中討論的壓縮類型稱為無損壓縮，因為您重新創建的文件與原始文件完全相同。所有無損壓縮都基於這樣一種理念：將文件變為「較小」的形式以利於傳輸或存儲，並在另一方收到它後復原以便重新使用它。
有損壓縮則與此大不相同。這些程序直接去除「不必要」的信息，對文件進行剪裁以使它變得更小。這種類型的壓縮大量應用於減小點陣圖圖像的文件大小，因為點陣圖圖像的體積通常非常龐大。為了了解有損壓縮的工作原理，讓我們看看你的計算機如何對一張掃描的照片進行壓縮。
對於此類文件，無損壓縮程序的壓縮率通常不高。盡管圖片的大部分看起來都是相同的——例如，整個天空都是藍色的——但是大部分像素之間都存在微小的差異。為了使圖片變得更小同時不降低其解析度，您必須更改某些像素的顏色值。如果圖片中包含大量的藍色天空，程序會挑選一種能夠用於所有像素的藍色。然後，程序重寫該文件，所有天空像素的值都使用此信息。如果壓縮方案選擇得當，您不會注意到任何變化，但是文件大小會顯著減小。
當然，對於有損壓縮，在文件壓縮後您無法將其復原成原始文件的樣子。您必須接受壓縮程序對原始文件的重新解釋。因此，如果需要完全重現原來的內容（例如軟體應用程序、資料庫和總統就職演說），則不應該使用這種壓縮形式。

⑶ 利用哈夫曼編碼進行壓縮壓縮率一般達到多少

哈夫曼編碼進行壓縮的壓縮率是根據平均碼長來計算的，壓縮率比較低。

例如：用三位二進行數進行的等長編碼平均長度為3，而根據哈夫曼樹編碼的平均碼長為：

4*0.07+2*0.19+5*0.02+4*0.06+2*0.32+5*0.03+2*0.21+4*0.10=2.61

2.61/3=0.87=87%

其平均碼長是等長碼的87%，所以平均壓縮率為13%。

哈夫曼編碼，又稱霍夫曼編碼，是一種編碼方式，哈夫曼編碼是可變字長編碼(VLC)的一種。

Huffman於1952年提出一種編碼方法，該方法完全依據字元出現概率來構造異字頭的平均長度最短的碼字，有時稱之為最佳編碼，一般就叫做Huffman編碼（有時也稱為霍夫曼編碼）。

壓縮率，描述壓縮文件的效果名，是文件壓縮後的大小與壓縮前的大小之比，例如：把100m的文件壓縮後是90m，壓縮率為90/100*100%=90%，壓縮率一般是越小越好，但是壓得越小，解壓時間越長。

(3)哈夫曼編碼圖片壓縮擴展閱讀

哈夫曼編碼的具體方法：先按出現的概率大小排隊，把兩個最小的概率相加，作為新的概率 和剩餘的概率重新排隊，再把最小的兩個概率相加，再重新排隊，直到最後變成1。

每次相 加時都將「0」和「1」賦與相加的兩個概率，讀出時由該符號開始一直走到最後的「1」， 將路線上所遇到的「0」和「1」按最低位到最高位的順序排好，就是該符號的哈夫曼編碼。

⑷ 哈夫曼編碼（理論）

哈夫曼編碼是一種無損壓縮文件一種方法，他的思路很簡單，卻又十分經典，他利用的是無重復前綴這種思想，就是每個字元的前綴是唯一的，若a的編碼是001，那麼就不會存在另一個以001開頭的編碼了，因為，哈夫曼編碼是以二叉樹為基礎實現的，而二叉樹到每一個葉子節點的路徑是唯一的，那麼也就是說每一個字元的編碼也是唯一的。

哈夫曼編碼是一種變長編碼，比起定長編碼的ascii碼來說，哈夫曼編碼能節省很多的空間，因為每一個字元出現的頻率不是一致的，例如在英語中，『e』出現的次數是最高的，那麼如果我把『e』的編碼定義的短一點，那麼是不是比起定長編碼來說，空間就減少了？

基於這種思路，哈夫曼編碼的具體實現過程如下：
（1）首先統計文本中各字元出現的頻率（權重）。
（2）使用這些頻率（權重），構建出哈夫曼樹。
（3）規定從根節點開始，向葉子節點行走，經過左子樹，編碼為0，右子樹，編碼為1，這樣就能得到每一個葉子節點字元的編碼值了。

⑸ 哈夫曼編碼做壓縮軟體的問題c++

因為32個0、1是4個位元組。（因為8個0、1是一個位元組）
但是它這個東西算出來的是一個0、1佔一個位元組的那種
所以要變成32個0、1佔4位元組的那種

⑹ 如何用哈夫曼編碼對圖像進行壓縮

% 演示圖象的哈夫曼編解碼過程
% chenyong 2009.04.20

clear all;
close all;
clc;
Dimens = 256; % 矩陣維數，假設矩陣為方陣即256*256
src_size = Dimens^2; % 矩陣元素的個數
gray_level = 9; % 灰度級

src = randn(Dimens); %產生模擬圖像矩陣，滿足正態分布，零均值，方差為1
%src = randint(Dimens,Dimens,gray_level); % 產生隨機圖像矩陣，灰度值為0~63，滿足均勻分布
src_one = reshape(src,1,src_size);
src_max = max(src_one);
src_min = min(src_one);
quan = linspace(src_min,src_max,gray_level); % 產生均勻量化區間
src_d = []; % 數字矩陣
for row = 1:Dimens % 逐點量化
for vol = 1:Dimens
diff = abs(src(row,vol)-quan);
[min_diff,min_index] = min(diff);
quan_gray = min_index -1;
src_d(row,vol) = quan_gray;
end
end

%將數字圖像矩陣還原成模擬矩陣
src_a = [];
quan_space = quan(2)-quan(1);
for row = 1:Dimens
for vol = 1:Dimens
src_a(row,vol) = src_d(row,vol) * quan_space + src_min;
end
end

% prob數組保存圖像中各灰度出現的概率
prob = [];
for src_value=0:(gray_level-1)
index = find(src_d==src_value);
i = src_value + 1;
prob(i) = length(index)/src_size;
end

% 畫出直方圖
% stem(0:gray_level-1,prob);
% xlabel('灰度值');
% ylabel('概率');
% title('灰度直方圖');

% huffman編碼
p = prob;
n=length(p);
q=p;
m=zeros(n-1,n);
for i=1:n-1
[q,l]=sort(q);
m(i,:)=[l(1:n-i+1),zeros(1,i-1)];
q=[q(1)+q(2),q(3:n),1];
end
bre=zeros(n-1,n);
bre(n-1,1)=0+j; %虛部表示當前的二進制數的位數，以下類似
bre(n-1,2)=1+j;
for time=1:n-2
loc_1 = find(real(m(n-time,:))==1);
prebit = bre(n-time,loc_1);
bre(n-time-1,1) = (real(prebit)*2 + 0) + j*(imag(prebit)+1);
bre(n-time-1,2) = (real(prebit)*2 + 1) + j*(imag(prebit)+1);

loc_not1 = find(real(m(n-time,:))>1);
bre(n-time-1,3:3+time-1) = bre(n-time,loc_not1);
end
[m1,index] = sort(m(1,:));
code = bre(1,index);
code_data = real(code);
code_bits = imag(code);
disp(['gray level',' ', 'huffman code']);
for i = 1:length(code)
disp([num2str(i-1),' ' ,num2str(dec2bin(code_data(i)))]);
disp([num2str(i-1),' ' ,num2str(dec2bin(code_data(i),code_bits(i)))]);
end
code_binary = dec2bin(code_data);

%逐點編碼
out = [];
for row = 1:Dimens
for vol = 1:Dimens
now_gray = src_d(row,vol);
now_code = code_binary(now_gray+1,:);
now_bits = code_bits(now_gray+1);
now_code = now_code(end-now_bits+1:end);
out = [out, now_code];
end
end

%計算壓縮比
real_bitnum = length(out);
bitnum_no_huffman = src_size*nextpow2(gray_level);
comp_ratio =bitnum_no_huffman/real_bitnum;
Lavg = real_bitnum/src_size;
Hshannon = (-1)*prob*(log2(prob))';
disp(['Lavg = ',num2str(Lavg)]);
disp(['normal bit num = ',num2str(nextpow2(gray_level))]);
disp(['comp_ratio = ',num2str(comp_ratio)]);
disp(['Hshannon = ',num2str(Hshannon)]);

⑺ 數字圖像壓縮技術

⑻ 哈夫曼編碼的壓縮實現

壓縮代碼非常簡單，首先用ASCII值初始化511個哈夫曼節點：
CHuffmanNode nodes[511];
for(int nCount = 0; nCount < 256; nCount++)
nodes[nCount].byAscii = nCount;
其次，計算在輸入緩沖區數據中，每個ASCII碼出現的頻率：
for(nCount = 0; nCount < nSrcLen; nCount++)
nodes[pSrc[nCount]].nFrequency++;
然後，根據頻率進行排序：
qsort(nodes, 256, sizeof(CHuffmanNode), frequencyCompare);
哈夫曼樹，獲取每個ASCII碼對應的位序列：
int nNodeCount = GetHuffmanTree(nodes); 構造哈夫曼樹非常簡單，將所有的節點放到一個隊列中，用一個節點替換兩個頻率最低的節點，新節點的頻率就是這兩個節點的頻率之和。這樣，新節點就是兩個被替換節點的父節點了。如此循環，直到隊列中只剩一個節點（樹根）。
// parent node
pNode = &nodes[nParentNode++];
// pop first child
pNode->pLeft = PopNode(pNodes, nBackNode--, false);
// pop second child
pNode->pRight = PopNode(pNodes, nBackNode--, true);
// adjust parent of the two poped nodes
pNode->pLeft->pParent = pNode->pRight->pParent = pNode;
// adjust parent frequency
pNode->nFrequency = pNode->pLeft->nFrequency + pNode->pRight->nFrequency; 有一個好的訣竅來避免使用任何隊列組件。ASCII碼只有256個，但實際分配了511個(CHuffmanNode nodes[511])，前255個記錄ASCII碼，而用後255個記錄哈夫曼樹中的父節點。並且在構造樹的時候只使用一個指針數組(ChuffmanNode *pNodes[256])來指向這些節點。同樣使用兩個變數來操作隊列索引(int nParentNode = nNodeCount;nBackNode = nNodeCount –1)。
接著，壓縮的最後一步是將每個ASCII編碼寫入輸出緩沖區中：
int nDesIndex = 0;
// loop to write codes
for(nCount = 0; nCount < nSrcLen; nCount++)
{
*(DWORD*)(pDesPtr+(nDesIndex>>3)) |=
nodes[pSrc[nCount]].dwCode << (nDesIndex&7);
nDesIndex += nodes[pSrc[nCount]].nCodeLength;
}
(nDesIndex>>3): >>3 以8位為界限右移後到達右邊位元組的前面
(nDesIndex&7): &7 得到最高位.
此外，在壓縮緩沖區中，必須保存哈夫曼樹的節點以及位序列，這樣才能在解壓縮時重新構造哈夫曼樹（只需保存ASCII值和對應的位序列）。 解壓縮比構造哈夫曼樹要簡單的多，將輸入緩沖區中的每個編碼用對應的ASCII碼逐個替換就可以了。只要記住，這里的輸入緩沖區是一個包含每個ASCII值的編碼的位流。因此，為了用ASCII值替換編碼，我們必須用位流搜索哈夫曼樹，直到發現一個葉節點，然後將它的ASCII值添加到輸出緩沖區中：
int nDesIndex = 0;
DWORD nCode;
while(nDesIndex < nDesLen)
{
nCode = (*(DWORD*)(pSrc+(nSrcIndex>>3)))>>(nSrcIndex&7);
pNode = pRoot;
while(pNode->pLeft)
{
pNode = (nCode&1) ? pNode->pRight : pNode->pLeft;
nCode >>= 1;
nSrcIndex++;
}
pDes[nDesIndex++] = pNode->byAscii;
}