實驗原理：
01.JPEG的編解碼原理：
輸入圖像的YUV數據先進行偏置，再將圖片按8x8的塊進行DCT變換編程8x8的係數塊，接着再根據8x8的量化表對係數塊進行量化，量化後的8x8的係數塊需要對其進行不同的操作，其中左上角的直流係數進行，交流係數先之字形掃描，再根據對應的AC霍夫曼碼錶進行可變長編碼（VLC編碼），得到編碼輸出。
而JPEG的解碼過程就是編碼的逆過程，要想從一張.jpg格式的文件得到圖像的原始yuv數據，則在熟悉解碼過程的基礎上還要了解.jpg文件的數據組織格式
02.JPEG文件格式分析：
文件以segment的方式組織。每一個segment的特點如下：
1.由0xFF(一字節)、marker(一字節)、segment length(兩字節，用來表示該segment的長度，包括segment length的兩字節，不包括0xFF和marker的兩字節)；
2.採用Motorola序（相對於Intel序），即高位在前，低位在後；
3.Data部分中，若FF後爲00，則跳過這字節不處理。
以本次實驗所用的文件爲例進行分析（僅截取部分圖像數據），按順序依次有一下的標識符：
FFD8：SOI，圖像的開始，所有jpeg文件都必須以這個開頭；
FFE0：應用程序保留標記0；
FFDB：定義量化表，每個文件最多有四張量化表，此次實驗所用圖片中共有2個FFDB，因此共有2張量化表；
FFC0：SOF0，幀圖像開始；
FFC4：定義霍夫曼表，本文件中共有4個FFC4，因此共有4張霍夫曼碼錶；
FFDA：SOS，掃描開始；
FFD9：圖像結束。
實驗程序分析：
本次實驗的程序中共有三個結構體用來存儲數據：huffman_table,component,jdec_private，這三個結構體之間是依次被包含的關係，對應了圖像數據的三個層次。
huffman_table：
component:
jdec_private:
解碼流程如下：
1.在主函數中打開文件，將圖像數據讀入到緩存區中；
2.按順序依次解析segment marker，在解析的過程中得到圖像相關的參數並生成霍夫曼碼錶和量化表，爲之後的解碼做準備；
3.根據每個分量的水平、垂直採樣分子計算MCU的大小，計算每個MCU中有多少8x8的塊；
4.對每個MCU進行解碼，
5.解析到EOI，解析結束；
6.將解析生成的Y、Cb、Cr照要求轉換爲需要的彩色空間並輸出。
在解析的過程中會同時輸出trace文件，輸出一些圖像相關的參數及信息幫助理解解碼過程及文件的結構，若想關閉只需要將tinyjpeg.h中的TRACE變量設爲1。
實驗結果分析：
第一步：將.jpg圖像轉換爲.yuv文件並查看，代碼如下：
輸出的yuv文件如下：
第二步：將該文件中所有的霍夫曼碼錶輸出到一個txt文件中，代碼如下：
01.先聲明文件指針變量，這一步最開始我考慮的是將文件指針變量聲明在main函數中，但是之後發現這樣就得在很多函數中加入文件指針的形參，很容易就混淆造成程序有bug，因此這種方法不可行，最後仿照trace文件指針聲明方法將其聲明在頭文件中，作爲全局變量：
02.在主函數中打開文件：
03.在主函數末尾關閉文件：
04.輸出霍夫曼碼錶（包括符號值、對應碼字、對應碼長，代碼添加在build_huffman_table和parse_DHT中）：
05.最終輸出的碼錶結果如下：
可以看到這張圖片包含了四張霍夫曼碼錶，與上面分析文件數據時的結論相同。
第三步：輸出文件中所有的量化表，代碼如下：
（文件相關操作已包含在第二步）
添加在make_quantization_table中的代碼，其中的zz是一個表示位置的8x8的數組，由於在圖片編碼時對DCT變換後的數據要進行之字形掃描，因此在解碼時需要將數據恢復到其原來的位置，因此用一個表示位置的數組來將ref_table中的數重新排列放在q_table中：
添加在parse_DQT函數中的代碼：
最終得到的量化表是：
可以看到該文件只有兩張量化表，與文件分析的結論相同。
第四步：輸出每個塊的直流係數和一個交流係數，並分析其數據的概率分佈：
輸出的DC圖像和AC圖像如下，原始圖像的尺寸爲1024x1024，該圖像中的塊是16x16的，因此AC圖像和DC圖像的尺寸爲64x64。DC圖像能看清楚圖像的大概輪廓，說明圖像的直流分量包含了圖像的大部分信息。AC圖像隨着頻率的增高其輪廓越不明顯，說明了DCT變換的能量集中的特性，高頻部分的值很小。
將DC和AC圖像的數據進行概率分佈的統計，結果如下：
DC：
AC:
