c解壓縮jpg
❶ 如何 用 c語言 分析 JPG圖片
從網上下載JPEG工作組提供的LIBJPEG庫，按裡面的例子寫C語言程序。可以直接讀出JPG某點的RGB顏色，不須顯示圖片。
❷ JPG圖片的jpg壓縮原理
1．顏色模式轉換及采樣 RGB色彩系統是我們最常用的表示顏色的方式。JPEG採用的是YCbCr色彩系統。想要用JPEG基本壓縮法處理全彩色圖像，得先把RGB顏色模式圖像數據，轉換為YCbCr顏色模式的數據。Y代表亮度，Cb和Cr則代表色度、飽和度。通過下列計算公式可完成數據轉換。
Y=0.2990R+0.5870G+0.1140B
Cb=-0.1687R-0.3313G+0.5000B+128
Cr=0.5000R-0.4187G-0.0813B+128
人類的眼晴對低頻的數據比對高頻的數據具有更高的敏感度，事實上，人類的眼睛對亮度的改變也比對色彩的改變要敏感得多，也就是說Y成份的數據是比較重要的。既然Cb成份和Cr成份的數據比較相對不重要，就可以只取部分數據來處理。以增加壓縮的比例。JPEG通常有兩種采樣方式：YUV411和YUV422，它們所代表的意義是Y、Cb和Cr三個成份的數據取樣比例。 2.DCT變換 DCT變換的全稱是離散餘弦變換(Discrete Cosine Transform)，是指將一組光強數據轉換成頻率數據，以便得知強度變化的情形。若對高頻的數據做些修飾，再轉回原來形式的數據時，顯然與原始數據有些差異，但是人類的眼睛卻是不容易辨認出來。 壓縮時，將原始圖像數據分成8*8數據單元矩陣，例如亮度值的第一個矩陣內容如下：JPEG將整個亮度矩陣與色度Cb矩陣，飽和度Cr矩陣，視為一個基本單元稱作MCU。每個MCU所包含的矩陣數量不得超過10個。例如，行和列采樣的比例皆為4:2:2，則每個MCU將包含四個亮度矩陣，一個色度矩陣及一個飽和度矩陣。 當圖像數據分成一個8*8矩陣後，還必須將每個數值減去128，然後一一代入DCT變換公式中，即可達到DCT變換的目的。圖像數據值必須減去128，是因為DCT轉換公式所接受的數字范圍是在-128到+127之間。 DCT變換公式：x,y代表圖像數據矩陣內某個數值的坐標位置f(x,y)代表圖像數據矩陣內的數個數值u,v代表DCT變換後矩陣內某個數值的坐標位置F(u,v)代表DCT變換後矩陣內的某個數值 u=0 且 v=0 c(u)c(v)=1/1.414 u>0 或 v>0 c(u)c(v)=1 經過DCT變換後的矩陣數據自然數為頻率系數，這些系數以F（0，0）的值最大，稱為DC，其餘的63個頻率系數則多半是一些接近於0的正負浮點數，一概稱之為AC。 3、量化 圖像數據轉換為頻率系數後，還得接受一項量化程序，才能進入編碼階段。量化階段需要兩個8*8矩陣數據，一個是專門處理亮度的頻率系數，另一個則是針對色度的頻率系數，將頻率系數除以量化矩陣的值，取得與商數最近的整數，即完成量化。 當頻率系數經過量化後，將頻率系數由浮點數轉變為整數，這才便於執行最後的編碼。不過，經過量化階段後，所有數據只保留整數近似值，也就再度損失了一些數據內容，JPEG提供的量化表如下：4、編碼 Huffman編碼無專利權問題，成為JPEG最常用的編碼方式，Huffman編碼通常是以完整的MCU來進行的。編碼時，每個矩陣數據的DC值與63個AC值，將分別使用不同的Huffman編碼表，而亮度與色度也需要不同的Huffman編碼表，所以一共需要四個編碼表，才能順利地完成JPEG編碼工作。
DC編碼
DC是彩採用差值脈沖編碼調制的差值編碼法，也就是在同一個圖像分量中取得每個DC值與前一個DC值的差值來編碼。DC採用差值脈沖編碼的主要原因是由於在連續色調的圖像中，其差值多半比原值小，對差值進行編碼所需的位數，會比對原值進行編碼所需的位數少許多。例如差值為5，它的二進製表示值為101，如果差值為-5，則先改為正整數5，再將其二進制轉換成1的補數即可。所謂1的補數，就是將每個Bit若值為0，便改成1；Bit為1，則變成0。差值5應保留的位數為3，下表即列出差值所應保留的Bit數與差值內容的對照。在差值前端另外加入一些差值的霍夫曼碼值，例如亮度差值為5（101）的位數為3，則霍夫曼碼值應該是100，兩者連接在一起即為100101。下列兩份表格分別是亮度和色度DC差值的編碼表。根據這兩份表格內容，即可為DC差值加上霍夫曼碼值，完成DC的編碼工作。AC編碼
AC編碼方式與DC略有不同，在AC編碼之前，首先得將63個AC值按Zig-zag排序，即按照下圖箭頭所指示的順序串聯起來。63個AC值排列好的，將AC系數轉換成中間符號，中間符號表示為RRRR/SSSS，RRRR是指第非零的AC之前，其值為0的AC個數，SSSS是指AC值所需的位數，AC系數的范圍與SSSS的對應關系與DC差值Bits數與差值內容對照表相似。 如果連續為0的AC個數大於15，則用15/0來表示連續的16個0，15/0稱為ZRL（Zero Rum Length），而（0/0）稱為EOB（Enel of Block）用來表示其後所剩餘的AC系數皆等於0，以中間符號值作為索引值，從相應的AC編碼表中找出適當的霍夫曼碼值，再與AC值相連即可。
例如某一組亮度的中間符為5/3，AC值為4，首先以5/3為索引值，從亮度AC的Huffman編碼表中找到1111111110011110霍夫曼碼值，於是加上原來100（4）即是用來取[5，4]的Huffman編碼1111111110011110100，[5，4]表示AC值為4的前面有5個零。
由於亮度AC，色度AC霍夫曼編碼表比較長，在此省略去，有興趣者可參閱相關書籍。
實現上述四個步驟，即完成一幅圖像的JPEG壓縮。 [1] 林福宗 《圖像文件格式（上）——Windows 編程》，清華大學出版社， 1996年
[2] 李振輝、李仁各編著，《探索圖像文件的奧秘》，清華大學出版社，1996年
[3]黎洪松、成實譯《JPEG靜止數據壓縮標准》，學苑出版社，1996年
❸ C語言jpg解碼問題（文件讀取）
mgdecmp庫是WINCE 系統提供一個解碼BMP,GIF,PNG,JPG的文件的庫,這個庫的缺陷是不能解出MASK 圖片.具體用法如下:
1.把imgdecmp.h加入工程,imgdecmp.h文件內容如下:
/*---------------------------------------------------------------------------*/
*
* (c) Copyright Microsoft Corp. 1997-98 All Rights Reserved
*
* mole: imgdecmp.h
* date:
* author: jaym
*
* purpose:
*
/*---------------------------------------------------------------------------*/
#ifndef __IMGDECMP_H__
#define __IMGDECMP_H__
#ifdef __cplusplus
extern "C" {
#endif // __cplusplus
#include "imgrendr.h"
typedef void (CALLBACK *PROGRESSFUNC)(IImageRender *pRender, BOOL bComplete, LPARAM lParam);
typedef DWORD (CALLBACK *GETDATAFUNC)(LPSTR szBuffer, DWORD dwBufferMax, LPARAM lParam);
typedef struct tagDecompressImageInfo {
DWORD dwSize; // Size of this structure
LPBYTE pbBuffer; // Pointer to the buffer to use for data
DWORD dwBufferMax; // Size of the buffer
DWORD dwBufferCurrent; // The amount of data which is current in the buffer
HBITMAP * phBM; // Pointer to the bitmap returned (can be NULL)
IImageRender ** ppImageRender; // Pointer to an IImageRender object (can be NULL)
int iBitDepth; // Bit depth of the output image
LPARAM lParam; // User parameter for callback functions
HDC hdc; // HDC to use for retrieving palettes
int iScale; // Scale factor (1 - 100)
int iMaxWidth; // Maximum width of the output image
int iMaxHeight; // Maxumum height of the output image
GETDATAFUNC pfnGetData; // Callback function to get more data
PROGRESSFUNC pfnImageProgress; // Callback function to notify caller of progress decoding the image
COLORREF crTransparentOverride; // If this color is not (UINT)-1, it will override the
// transparent color in the image with this color. (GIF ONLY)
} DecompressImageInfo;
#define IMGDECOMP_E_NOIMAGE 0x800b0100
COLORREF *
GetHalftonePalette();
COLORREF *
Get332Palette();
HRESULT
DecompressImageIndirect(DecompressImageInfo *pParams);
#ifdef __cplusplus
};
#endif // __cplusplus
#endif // !__IMGDECMP_H__
2.按照下面的方法使用.
HDC hdc = CreateCompatibleDC(NULL);
DecompressImageInfo dii;
BYTE szBuffer[1024] = {0};
HANDLE hFile = INVALID_HANDLE_VALUE;
// Fill in the 'DecompressImageInfo' structure
dii.dwSize = sizeof( DecompressImageInfo ); // Size of this structure
dii.pbBuffer = szBuffer; // Pointer to the buffer to use for data
dii.dwBufferMax = 1024; // Size of the buffer
dii.dwBufferCurrent = 0; // The amount of data which is current in the buffer
dii.phBM = &hBitmap; // Pointer to the bitmap returned (can be NULL)
dii.ppImageRender = NULL; // Pointer to an IImageRender object (can be NULL)
dii.iBitDepth = GetDeviceCaps(hdc,BITSPIXEL); // Bit depth of the output image
dii.lParam = ( LPARAM ) &iCeBMPFile;//hFile; // User parameter for callback functions
dii.hdc = hdc; // HDC to use for retrieving palettes
dii.iScale = 100; // Scale factor (1 - 100)
dii.iMaxWidth = 10000; // Maximum width of the output image
dii.iMaxHeight = 10000; // Maxumum height of the output image
dii.pfnGetData = GetImageData; // Callback function to get image data
dii.pfnImageProgress = ImageProgress; // Callback function to notify caller of progress decoding the image
dii.crTransparentOverride = ( UINT ) -1; // If this color is not (UINT)-1, it will override the
// transparent color in the image with this color. (GIF ONLY)
// Process and decompress the image data
typedef HRESULT (CALLBACK* ULPRET)( DecompressImageInfo* pParams );
HINSTANCE hLib;
ULPRET lpfnDLLProc;
hLib = LoadLibrary ( L"Imgdecmp.dll" );
if ( hLib )
{
lpfnDLLProc = (ULPRET) GetProcAddress ( hLib, L"DecompressImageIndirect" );
hr = (*lpfnDLLProc) ( &dii );
FreeLibrary ( hLib );
}
// Clean up
DeleteDC( hdc );
❹ 如何用C語言編寫暴力破解壓縮文件解壓密碼的程序
由於有一個重要的Rar文件，極需解開，首先試用了ARPC，但是解壓的速度極慢，每秒只有30個左右，所以斷了窮舉破解的念頭，卻仍不死心，因為我從不崇尚窮舉破解的方法，除非每秒可以跑幾千萬次的，我或許可以一試，所以決定研究一下Winrar3.x密碼演算法，以期是否可以破解該密碼。查看了網路上的資料，包括看雪FAQ里的回答，都聲稱只能用窮舉法破解，起先並不理解，但通過研究，我理解了看雪前輩們在FAQ里所說的原因，不禁讓我佩服
Winrar加密思路的成熟。雖然研究的結果沒有什麼新意，但我還是決定把我的研究結果與大家一起分享，為那些仍然以為winrar密碼可以象破解注冊碼一樣的，通過修改winrar彈出框之類的更改文件流程指向可以達到跳過密碼檢驗的朋友，做一個簡要的說明。
一、Rar文件生成的流程。
Winrar加密文件時，總的分兩個步驟：
1：先把源文件壓縮，壓成一段數據段。
2：再將壓縮完的數據段加密。
對於同一個源文件來說，不進行加密，壓縮完，其rar文件中的數據段是一模一樣的。但是如果對同一個源文件來說，即使使用同一個密碼，加密完rar文件中的數據段是不一樣的，這是由於加密的密鑰是依賴於一個Salt(8個位元組的密鑰，用來加密時使用，存放在rar文件頭中里）
所以要解密rar加密文件關鍵在於數據解密這一步，那我們接下來研究一下如何加密的。
二、加密「壓縮完的數據段」的流程
1、獲取密鑰：
將明文的密碼與Salt一起，通過HASH演算法，生成兩個16位元組的密鑰。（一個是KEY(AES演算法的參數)，一個是initVector）
2、以Key和initVector來加密壓縮數據：
這里，是一個循環加密的結構，每16位元組作為一個塊，進行加密（這可能正是為什麼加密完的文件長度總為16倍數的原因）。加密採用AES演算法（RAR採用的是AES的rijndael的標准應用）。這里注意：AES加密前，有一個異或運算，是先將每16位元組塊與上一個16位元組塊加密結果進行異或，然後再進行AES演算法的。我用一個簡單的示意代碼看說明：
;===============================================
packblock[0]=packblock[i]^initVector
encryptBlock[0]=AES(packblock[0]) ；（KEY為AES的密鑰）
for i=1to 塊數量-1
packblock[i]=packblock[i]^encryptBlock[i-1]
encryptBlock[i]=AES(packblock[i])；（KEY為AES的密鑰）
next
;packblock[i]表示壓縮完的每16位元組數據
;encryptBlock[i]表示加密完的每16位元組數據
;===============================================
三、解密的過程
由於AES演算法是對稱的，所以解密的過程，是加密過程的逆運算。但解密時AES演算法過程與加密所用的不一樣（是因為解密過程中由KEY生成的子密鑰表不一樣）。仍然需要我們將密碼輸入，與salt一起生成兩個16位元組密鑰，KEY和initVector。
;===============================================
packblock[0]=AES1(encryptBlock[0]) ；（KEY為AES的密鑰）
packblock[0]=packblock[i]^initVector
for i=1to 塊數量-1
packblock[i]=AES1(encryptBlock[i]) ；（KEY為AES的密鑰）
packblock[i]=packblock[i]^encryptBlock[i-1]
next
;===============================================
那判斷密碼是否正確的在什麼地方呢？
解密的過程是解密後的數據塊進行解壓縮，然後解成源文件，對該文件進行CRC校驗，存在RAR文件中的源文件CRC校驗碼比較，相同則密碼正確，不相同則密碼錯誤。
四、無法秒破的原因
從上面，我們了解了RAR文件的整體思路。地球人都知道，解密時，肯定有個步驟是來判斷密碼的正確與否。而且，依據以往的經驗，我們也許可以將某些判斷的點移動，那樣可以縮減破解的流程思路。那RAR的這一步在哪裡？它把校驗放在了最後的一步。如果要秒破，我們該怎麼做泥？至少我認為目前是不可能的。
我們從解密過程逆反過來看看：
1、CRC檢驗這一塊修改跳轉？根本毫無意義，因為它已經是最後一步了。你可以修改RAR文件頭的CRC值，你可以將它改得和你用任意密碼解壓出來的文件CRC值一樣，但你的文件根本就不是原來的文件了。可能已經完全面目全非了。所以，對這一過程不可行。CRC校驗本身是不可逆的
2、那麼把判斷提前到壓縮完的數據？
解壓的時候，有沒有什麼來判斷壓縮數據是否正確？壓縮完的數據，有沒有固定的特徵，是否可以做為解壓的判斷，在這一步里，我們也無法找到有效的可用的固定特徵。因為這一步涉及到RAR的壓縮演算法。即使一個源文件，即使你的文件前一部分是完全相同的，只對後面的部分進行改過，那麼壓縮完，數據也是完全一樣的。因為壓縮完的數據首先是一個壓縮表，後面是編碼。文件不一樣，掃描完的壓縮表也不一樣，編碼又是依賴於壓縮表，所以，這里頭找不到壓縮完的數據有任何的固定特徵可以用來判斷的。
不管壓縮數據是什麼樣的，Winrar都一如既往地進行解壓，沒有進行壓縮數據是否有效的判斷。
3、那假如我們破解了AES了泥？
由於AES只依賴於KEY，如果AES演算法被破解了，我們知道了KEY，我們可以解出壓縮完的數據，但是這里有一個問題，還有一個initVector密鑰，用來第一個16位元組塊的異或，你沒有initVector參數，你第一個16位元組塊的數據便無法解得出來。
4、那就只能從第一步Hash的演算法入手
即使你能破解hash，但hash後的結果泥？沒有結果，你怎麼返推密碼。
所以綜上，我發現rar的加密是由hash和AES兩種演算法互相牽制，而兩種演算法當前都無法破解，至少目前還沒有辦法秒破，也理解了看雪高手講的道理。
五、對窮舉提高演算法效率的一些設想。
我用匯編寫完了RAR窮舉解密的演算法模塊，但是如何提高效率，優化窮舉的速度泥？我有如下的想法：
1、從壓縮數據里找尋特徵，省掉解壓縮、CRC檢驗代碼和生成initVector生成代碼。目前，通過多次實驗，我找到的一個特徵（不知道這個是否正確），即解密完的最後一個16位元組塊的最後一個位元組必須為0。因為經過多次的試驗，我發現有加密的數據段長度都會比未加密前的數據長，那麼，最後一個
16個位元組的數據塊解密完，多出的部分就都為0，但多出幾個位元組泥？多次實驗，長度不一，我試想著從加密數據段最後一個16個位元組塊著手，只解這一塊，看是否一個位元組為0，這樣，只解密16個位元組的數據，來大大提高效率？如果能進行到這一步了，再通過解全部數據，進行CRC校驗的判斷。
2、如果第一個特徵不成立的話，針對特定格式的壓縮文件，比如doc、jpg等，部分數據固定，壓縮完的數據是否存在相互牽制的數據？從而把判斷提前，這一步，我不知道如何找到壓縮完的數據是否存在相互牽制的數據。
❺ 怎麼操作能將圖片壓縮為jpg格式
a：壓縮圖片第一步我們將圖片添加到操作頁面上，壓縮工具中會這個個壓縮的輸出選項，點擊選擇文件將圖片放到頁面中去。
然後能壓縮輸出了，滑鼠點「開始壓縮」按鈕就好了，方法使用上有不懂的自己再去網路搜一下。
❻ 如何用c語言實現壓縮圖片內存大小
是(row,col,value)，這樣把所有不為零的值組成一個向量。這種存儲方式比二維數組節省了不少空間，當然還可以進一步節省，因為三元組裡面row或者col重復存儲了，一行或者一列存一次就行了，按這種思路走下去就是行壓縮存儲了。
那具體什麼是行壓縮存儲呢？行壓縮存儲的思想就是，把所有不為零的值按行訪問的順序組成一個向量，然後再把每一行值不為0的列的下標存下來，這個兩個向量的大小和稀疏矩陣中不為0的值得個數相同，當然要實現對行壓縮矩陣的訪問，還要把每一行的不為0的列的下標在第二個向量中開始的位置存下來，有人把這個叫做指針。有了這三個向量就可以實現對矩陣實現高效的按行訪問了。行壓縮存儲比三元組優秀的不僅是空間的壓縮，還有就是行訪問時的高效。三元組如果是有序的，可以二分查找來訪問一行，但是行壓縮存儲按行訪問時的時間復雜度是常數級的。 大家可以參考下面這個行壓縮矩陣示意圖：
❼ 如何壓縮JPG格式圖片大小
我們在進行圖片壓縮的時候，對於壓縮軟體的選擇以及壓縮的操作並不是很熟悉，電腦中的圖片需要進行壓縮，也不知道如何下手，下面教給大家使用電腦壓縮圖片的軟體進行壓縮圖片。
1：首先要將自己需要壓縮的圖片文件整理好放置在一個文件夾中，文件夾最好可以隨時找到。
如果不想下載軟體壓縮的話，也可以在網站直接壓縮
❽ C++怎麼實現解壓RAR或者ZIP文件
用Zlib庫，下載地址： http://download.chinaunix.net/download/0013000/12241.shtml
BOOL ZipCompress(LPCTSTR lpszSourceFiles, LPCTSTR lpszDestFile);
BOOL ZipExtract(LPCTSTR lpszSourceFile, LPCTSTR lpszDestFolder); 要引入的源文件 ZLib 主目錄下的代碼，除 minigzip.c、example.c 外； contrib\minizip 下的代碼，除 minizip.c、miniunz.c 外。壓縮相關： zipOpen64 zipClose zipOpenNewFileInZip zipCloseFileInZip zipWriteInFileInZip解壓相關： unzOpen64 unzClose unzGetGlobalInfo64 unzGoToNextFile unzGetCurrentFileInfo64 unzOpenCurrentFile unzCloseCurrentFile unzReadCurrentFile
❾ JPG圖片壓縮在線工具方法
壓縮工具有很多，離線安裝軟體，在線壓縮的都有；
在線壓縮工具個人推薦，如圖：
在線壓縮網站：http://yasuotu.com
❿ 怎麼用C語言處理圖片，比如jpg格式的，請舉例
C語言的話有個挺好用的庫jpeglib或者jpeglib2用來處理jpg，是開源，純C的