Detailed explanation of JPEG decoding--example

According to the jpeg decoding knowledge learned earlier, write the jpeg decoding code. Here, the actual decoding process is used to explain the jpeg

As shown in Figure 1, it is the actual jpg image data, and the corresponding identifier and corresponding data information are analyzed according to the JPEG format.

FF D8 : SOI file header

FF E0 : APP0 image information recognition

FF DB : DQT quantization table

FF C0 : SOF0 frame start

FF C4 : DHT Huffman table

FF DA : SOS scan line starts

encode data

FF D9 : SOI end of file

Scan the file header to obtain valid DQT quantization table information, as shown in Figure 1:

SOF recognizes the basic information of the image, as shown in Figure 2:

 Image resolution: 1920*1080, decoding 4:1:1 image, y component is 4 times of Cb, Cr;

MCU size is 8*8, in 4:1:1 mode, 1920/(8*2)=120, 1080/(2*8)=67.5, at this time need to compensate an integer number of MCUs, so the actual width is 68*16 =1088, a total of 120 rows and 68 columns of MCUs.

Therefore, the actual processed image size is 1920*1088, 120*68 MCUs, each MCU size is 8*8, and the Y component is decoded according to 2*2 MCUs.

DHT Huffman table information, and based on the Huffman decoding example in JPEG  , reconstruct the Huffman tree and obtain the Huffman code and size table, as shown in Figure 3, 00 -> Y-DC, tablenum=0:

图4,10 -> Y-AC,tablenum=1:

Figure 5, 01 -> CbCr-DC, tablenum=2:

Figure 6, 11 -> CbCr-AC, tablenum=3:

After SOS, the 3byte data is omitted (used for other purposes), and the valid 32bit data can be read later. The decoding is as follows:

Get 32bit data: 0xe2e8a28a --> 1110 0010 1110 1000 1010 0010 1000 1010

Huffman looked up the table and got the DHT codeword: 0x06. The high 4 bits represent zero reserved digits, and the low 4 bits represent the data bit length, that is, the next 6 bits of data are taken;

Get 6bit data: 0010 11 ==>0xb

Calculate the actual data value: (0xb+1)-(1<<6) = -52, the cumulative number of bits used is 10 bits

DC data is DPCM encoded. That is, the result of subtracting the previous DC value from the current DC value. The first DC value of the MCU must be 0, so the DC value is the obtained data + DC data. At this time, the actual value after DC quantization is -52; (AC data does not DPCM encoding is required)

Quantization: The result obtained by using the pixel value ÷ the corresponding value of the quantization table

Therefore, the inverse quantized data value = DQT*(-52), at this time we get -416;

Perform anti-Zig-Zag on the inverse quantized data and get -416;

 Anti-Zig-Zag table:

0 1 8 16 9 2 3 10
17 24 32 25 18 11 4 5
12 19 26 33 40 48 41 34
27 20 13 6 7 14 21 28
35 42 49 56 57 50 43 36
29 22 15 23 30 37 44 51
58 59 52 45 38 31 39 46
53 60 61 54 47 55 62

The original image is divided into 8*8 MCU blocks and encoded separately, so the decoding is also decoded according to one MCU.

When an MCU decodes:

1. When the DC component encounters a data bit length of 0, the data is also 0;

2. When the AC component encounters the EOB end symbol, the MCU decoding ends: the number of reserved zeros is 0, and the data bit length is also 0;

3. When the AC component encounters the ZRL code, it is 15 zero data: the number of reserved zeros is 0xF, and the data bit length is 0;

The final decoded DCT data of the MCU is:

Perform inverse DCT changes on the DCT data to obtain the actual YUV pixel data:

Convert YUV data to RGB format and save it in visual bmp format.

 R = (u8_t)(Y+ 1.4075*(Cr - 128));  
 G = (u8_t)(Y-0.7169*(Cr - 128)-0.3455*(Cb - 128));  
 B = (u8_t)(Y+1.779*(Cb- 128)); 

 

Guess you like

Origin blog.csdn.net/u010192735/article/details/120869528