Meeting - Jiayu 05

次序：12
時間：2008.02.26
地點：教師休息室
備註：完整度與分類不盡理想，僅供參考

內容：
　　　①評估目前找到的N隻JPEG encoder/decoder的可行性ˋ實用
　　　　性...等。
　　　　－四包程式暫時存放處：網路硬碟分享名JPEG或jpeg。
　　　　－討論將做不同事的程式分開撰寫並以引進標頭檔的方式使用
　　　　　的好壞。
　　　　－最後由IJG撰寫的library勝出!!作為往後研究的主要參考。

　　　②JPEG header。
　　　　－以檔案總管的檢視縮圖為例。小巧的縮圖檔就是存放在
　　　　　header裡。
　　　　－(「8*8block => YCbCr => ░░░░」那段解說，記憶模糊
　　　　　Orz)

　　　③小冬的憂鬱
　　　　－延伸閱讀EXIF。
　　　　－小常識：經過影像軟體編修過儲存的圖片，header裡原本記
　　　　　　　　　錄的部分資訊不復存在。
　　　　　(這裡我尚未確認是哪些資訊不會被影像軟體儲存。)

　　　④意義的思考
　　　　⒜開放原始碼：以別人的開放原始碼為基礎所撰寫出的程式也
　　　　　必須是開放的。
　　　　⒝縮圖：快速預覽用的原始圖片縮小版。
　　　　⒞component：
　　　　　例：灰階圖片有一個component；彩色圖片有三個
　　　　　　　component：RˋGˋB。


工作：研究各自找到的程式，3/04(二)報告。
心得：
　　　只在日本CM看過的TOSHIBA筆電(是紅色的XD)，今日親眼目
　　　睹，白色看起來也很不錯呢。
　　　近兩次meeting忘得一乾二淨的地方應該就是我有疑問的地方，
　　　往後會確實想好問題是什麼並提問。

關於JPEG的一些問題與思維

將Bitmap圖檔使用JPEG個壓縮步驟如下：
RGB -> YCbCr -> DCT -> QDCT -> Zig-Zag -> Huffman -> JPEG

Question:
根據老師的講解以及網路上的資料，目前已知JPEG壓縮技術是
一張未經壓縮(尚未失真)的影像，經過DCT,QDCT,ZigZag,Huffman後
所編成的資料流(stream)，就是JPEG影像的資料(已經失真)。
那麼，我們眼睛所見的影像，到底是如何從資料流轉變成影像的？

或許這個問題問起來有點不知所云，但這的確是我苦思不解，
畢竟有些圖檔即使副檔名是.jpg的圖片，看起來就跟.bmp沒啥兩樣。

ANSWER 1 :
關於這件事情，我試圖在網路上尋找資料，還有找人詢問
目前有得到的一個說法是
「副檔名是.jpg的意義在於程式在解碼時，需要找到對應的decoder，
　也就是知名的影像軟體，其實是充滿了圖片壓縮的解碼器(?)；
　而我們所看到的影像，則是被機器或是軟體decode後的成像，
　也就是解回bitmap那樣，等處理結束才又再度編碼成jpeg儲存。」

我覺得這算是我能理解的說辭之一，但不知正確性如何...

Meeting

※時間：2008.02.19 (14:20~15:00)
※地點：教師研究室
※缺席：王世昭

《討論重點與內容》
1.QDCT→JPEG, JPEG→QDCT的編碼與解碼
2.Paper
3.待補上(??)

下次Meeting時間預估2008.02.26 (?)

Meeting - Jiayu 04

次序：11
時間：2008.02.19
地點：教師休息室
備註：此記錄未完整

內容：
　　　①嵌入資料的時機。
　　　　－ 在整個JPEG邊碼過程中，選擇在量化這個步驟做完後才做
　　　　　　嵌入資料的動作，而不是量化前。(註:這裡只討論以量化
　　　　　　為分界，不特別指哪個步驟。)
　　　　－ 假設我們整個JPEG邊碼過程中挑選量化前的其中一個步
　　　　　　驟:DCT，將其DCT係數做嵌入資料的動作:將DCT係數2修
　　　　　　改為3，接著繼續進行整個JPEG編碼，DCT的下一步驟是
　　　　　　量化，於是拿這個3做量化:3/2=2(四捨五入。假設的量化
　　　　　　做法)，量化後得到的值是2，但當我們解碼回去時
　　　　　　2*2=4，卻不是原本的3了，由於量化這個步驟會造成這
　　　　　　樣的失真效果，所以我們選擇在量化後才嵌入資料。

　　　②(一個禮拜過去，我的記憶還是組織不起來的其他事。)

工作：尋找C語言撰寫而成的JPEG encoder/decoder。

Team Discussion

※Date：2008.01.25
※Place：S building @ MCU
※Member：All

※也許還會修改....
※有錯誤或是不明之處~請提出討論~

※主旨：
討論於Facebook介面上實作JPEG Information Hiding的可行性。

[Note：本次討論，Base on 對於"Facebook可提供資源"仍不熟悉的狀況來模擬]
※可行的實際方案有二：
1.使用PHP(facebook所支援的語言)架構一個介面，
　該介面可連線到一台主Server，主Server使用BCB程式處理，
　關於圖片的處理，全部交由Server處理；
　PHP僅處理資料(圖片、Message)傳遞。

2.不使用Server，參照Google ToolBar
　讓使用者下載一應用程式，將資訊處理過後
　透過PHP所架構的介面傳送。

※相關問題與討論，以下針對方案一做討論：
1.圖片→管理者設定 (可以一開始就知道 容量大小,但圖片選擇性低)
　　　　使用者設定 (必須另外判定圖片可藏的資料量)

2.Server→電源(機器該放哪邊?)
　　　　　網路(網路的流量可以達到快速不delay嗎?)

　目前facebook提供的空間不明，資源不明。

　且機器設置位置為一大考量，首先必須要找到一位置提供全天候電源服務；
　由於在Information Hiding的過程中，圖片與訊息的傳遞，為一大考量
　倘若要做到即時的服務，恐怕不像(fluff)friend那樣簡單....
　1.國內網路v.s.國外網路
　2.自己所在網域的下載/上傳的速度

想法與心得：
如果要做到方案一 (使用Server的評估)
1.PHP是否能夠做到藉由圖片大小來判斷容量大小

2.承上，倘若PHP辦不到
　a.丟給server判斷(較費時,費工,費資源)
　b.思索一套演算法，藉由圖片大小來計算 "可能" 的容量 (不一定準確)

3.網路的問題，因為facebook目前的使用者以國外為大宗
　但國內連國外網路的速度會很慢..(必須想出改進方案)
　經由圖片的Information Hiding deliver....可能無法達到即時效果

4.機器是有(學校發的那台)，但是全天候的網路與電源供應...
　可能較難以達成。