計算RMSE(Root Mean Square Error)

上週老師在上課最後提到MSE和PSNR，這兩個都是用來檢測兩張圖是否相似。
MSE的公式為：





PSNR的公式為：





MSE的值愈小，表示兩張圖愈相近。PSNR的愈大，表示兩張圖愈相近。
我試著寫了一個計算MSE和PSNR的小程式，計算方式是先分別將同座標的RGB值相減，
接著將相減後的值平方，累積所有平方後的值，最後累積值除以pixel數便是MSE。
片斷程式碼如下：
r = (point1[x*3+2]-point2[x*3+2])*(point1[x*3+2]-point2[x*3+2]);
g = (point1[x*3+1]-point2[x*3+1])*(point1[x*3+1]-point2[x*3+1]);
b = (point1[x*3]-point2[x*3])*(point1[x*3]-point2[x*3]);
sum = sum+r+g+b;
mse = sum/Hight*Width;
我不太確定這樣計算是否正確，希望其他人可以發表自己查到的結果，供大家討論。
程式執行圖片如下：

Week8

這次延續上週將調色盤排序之後,並將資訊隱藏在圖裡!!!
並且去分析有排序過的和梅排序過的的色差值為多少!!!!

原圖和原圖的調色盤==>
排序過後的調色盤==>
將資訊藏入圖片==>
此圖為未排序過調色盤所藏的圖==>
色差個數比例==>

結果可以看出有排序過的色差各數比例小於沒排序過的!!!!!!

身體狀況不太好
所以好幾週沒去上課了
最近希望能慢慢把進度追上
不過看來只能夠慢慢來了
暫時先慢慢看老師寫的教學日誌來補
可能需要花點時間吧
雖然有點久了，不過上次寫的那個s-tools的檢查工具之前才看到學長說想try看看
那我現在補上，雖然知道有點晚了
http://www.csie.mcu.edu.tw/~s3360256/IH.rar
至於最近在弄的程式，我看先慢慢把進度給追上在說，應該還是來得及
這禮拜只能這樣交代一下了

S-Tool的發現

嗯 感覺這門課很深奧 有種不簡單的感覺 哈
因為基礎不夠深 所以我現階段努力摸索著S-Tool
並且了解圖檔的基本相關資訊等等 如果我自認為有重大發現
而大家覺得沒什麼時......請別笑我 >"< 哈 謝謝 以下就是我所謂測試的重大發現 哈 :p

單看一個圖檔的大小其實是不能判定S-Tool可以將其隱藏滴~ 這該怎說呢?

以下是我的測試：

原始檔資訊：

圖1. JPG 檔

800*600 115KB

圖2. JPG 檔

800*600 129KB

檔名01 使用小畫家轉檔成GIF，檔案大小變成129KB。

檔名02. 使用小畫家轉檔成GIF，檔案大小變成140KB。

可將其隱藏成功！

Memory usage：481,064 bytes

檔名12 使用Photoimpact轉檔成GIF，最佳化128，檔案大小變成146KB。

檔名22 使用Photoimpact轉檔成GIF，最佳化128，檔案大小變成157KB。

可將其隱藏成功！

Memory usage：481,064 bytes

檔名31 使用Photoimpact轉檔成GIF，最佳化256，檔案大小變成184KB。

檔名32 使用Photoimpact轉檔成GIF，最佳化256，檔案大小變成203KB。

↑ 208,741 bytes is too much to fit in here, sorry.

無法隱藏成功！

檔名31小 使用Photoimpact轉檔成GIF，最佳化256，將檔案縮小為400*300，檔案大小變成52.8KB。

檔名32小 使用Photoimpact轉檔成GIF，最佳化256，將檔案縮小為400*300，檔案大小變成57.8KB。

↑ 59,230 bytes is too much to fit in here, sorry.

無法隱藏成功！

結論：

檔案大小並不是影響S-Tool可否隱藏資訊，圖形最佳化是主要影響來源。

◎ 最佳化256，圖檔是400*300，檔案大小是52.8KB，跟最佳化128，圖檔800*600，檔案是146KB，用到的記憶體誰大?

和同學的討論：

開啟時所吃的記憶體是圖越大就越大...400x300大小的全彩圖就是吃400x300x32bit的ram

存在硬碟裡的話，要看壓縮方法...

因為不知道最佳化256跟最佳化128的壓縮比例...所以不知道

但是用相同的壓縮方法的話...一定是圖越大越吃空間

※ 呼呼~ 以上就是我的結論與觀點

不知道是否有誤或不足處，請多指點，謝謝 ^^

Week8:灰階度排序後藏匿的圖

發燒了兩天,今天開始延續上禮拜的動作!
雖然上週回家就完成灰階度的排序!不過這次又再做了另一個小test不過應該是方法用錯吧!
先談談上次用的方法:
也就是灰階的方式排序後的調色盤:

以下是沒排序隱藏資訊的圖:

排序後隱藏資訊的圖:


最後則是謬論做的圖:

本想做成分群的效果,或許理論上可以讓加密的圖更清楚

.首先先從老師的blog下載S-Tools，執行後出現下圖畫面

再來將欲作為分享用圖片自桌面拖曳入S-Tools視窗中，然後如下圖所示 (附註:S-Tools圖片檔只吃.bmp跟.gif這兩種格式，音效檔則只吃.wav格式)

在來將欲隱藏在分享圖片中的資訊自桌面拖曳至分享圖片中，依此步驟執行將會出現如以下圖所示新對話窗要求你輸入加密密碼及隱藏格式

當步驟成立後，如下圖，Actions視窗將會出現正執行之編碼工作

編碼完成將開啟新的視窗，此視窗即為加密後的圖片影像

此時加密後的圖片在外觀上與原分享圖片無異，但在加密後的圖片上點右鍵在點取Rveal的選項會出現以下對話窗，此對話窗則是用來解密加密文件中的訊息所用，此時如果沒有正確的密碼或格式的話，將無法得到加密於其中的文件

如果解密正確則出現以下對話視窗，另存新檔後的檔案則為加密於其中的文件

結論:這軟體對於像我這種初學者來說藏文件是很方便沒錯，不過也如老師所說色盤會因為被修改後成為32個組群的色盤，對於竊取者或監視者而言很容易就被發現藏有額外文件的事實

Week 6: Index Embedded (I)

前言:
LSB的方法，需先將256色調色盤降為32色，
最後的調色盤可被分群為32個group，導致調色盤的不自然，使之容易被破解。

為了改善此缺點，於是有另外一派的研究希望嵌入資訊時，能夠不改變調色盤。
Index Embedded 就是其中一種不更改調色盤的方法。

以下文章描述Index Embedded 的方法，並在結尾提出結論與問題。

以圖一為例(下圖)



基於 GIF檔 有256種顏色，每張GIF 檔都有一個自己的調色盤。

換言之，不同的圖有不同的調色盤。

首先建立調色盤並且給予相對應的索引值。
第一個顏色給0，第二個顏色給1...依此類推。(圖二)



將調色盤，兩兩分組(Pair)。
Index 0 與 Index 1 為一組(Pair)
Index 2 與 Index 3 為一組(Pair)
並將原圖的像素對應到該像素的索引值(Index)(圖三)




接著嵌入訊息至原圖中:
假若嵌入的資訊為 1010110 1010110
第 1 個bit 1 嵌入第 1 個像素 0(Index值) , 1和0 (Index值)的LSB不相同，
該像素的 index 加1。(找該Index的Pair) 變成 : 0 + 1 = 1(index值為1的顏色)

剩餘嵌入的資訊為 010110 1010110
第 2 個bit 0 嵌入第 2 個像素 0(Index值) , 0和0(Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 10110 1010110
第 3 個bit 1 嵌入第 3 個像素 0(Index值) , 1和0 (Index值)的LSB不相同，
該像素的 index 加1。變成 : 0 + 1 = 1(index值為1的顏色)

剩餘嵌入的資訊為 0110 1010110
第 4 個bit 0 嵌入第 4 個像素 0(Index值) , 0和0(Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 110 1010110
第 5 個bit 1 嵌入第 5 個像素 0(Index值) , 1和0 (Index值)的LSB不相同，
該像素的 index 加1。變成 : 0 + 1 = 1(index值為1的顏色)

剩餘嵌入的資訊為 10 1010110
第 6 個bit 1 嵌入第 6 個像素 1(Index值) , 1和1(Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 0 1010110
第 7 個bit 0 嵌入第 7 個像素 1(Index值) , 0和1(Index值) 的LSB不相同，
該像素的 index 減1。(找該Index的Pair) 變成 : 0 + 1 = 1(index值為1的顏色)

剩餘嵌入的資訊為 1010110
第 8 個bit 1 嵌入第 8 個像素 1(Index值) , 1和1(Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 010110
第 9 個bit 0 嵌入第 9 個像素 1(Index值) , 0和1(Index值) 的LSB不相同，
該像素的 index 減1。(找該Index的Pair) 變成 : 0 + 1 = 1(index值為1的顏色)

剩餘嵌入的資訊為 10110
第 10 個bit 1 嵌入第 10 個像素 1(Index值) , 1和1(Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 0110
第 11 個bit 0 嵌入第 11 個像素 2(Index值) , 0 和 2 (Index值)的LSB相同，
該像素的 index 不變。

剩餘嵌入的資訊為 110
第 12 個bit 1 嵌入第 12 個像素 2(Index值) , 1 和 2 (Index值)的LSB不相同，
該像素的 index 加1。(找該Index的Pair)變成 : 2 + 1 = 3(index值為3的顏色)

剩餘嵌入的資訊為 10
第 13 個bit 1 嵌入第 13 個像素 2(Index值) , 1 和 2 (Index值)的LSB不相同，
該像素的 index 加1。(找該Index的Pair)變成 : 2 + 1 = 3(index值為3的顏色)

剩餘嵌入的資訊為 0
第 14 個bit 0 嵌入第 14 個像素 2(Index值) , 0 和 2 (Index值)的LSB相同，
該像素的 index 不變。

PS:上面的步驟是為了目前還不太懂的同學寫的，如果有疑問可以直接找我，
因為我有可能會有筆誤，或是哪裡觀念錯誤，請不吝指正，謝謝。

下圖為原圖與嵌入資訊後的圖片(偽裝媒體)



欲取出資訊時，直接取每個像素值的索引值的LSB即可得到隱藏訊息。

<<結論>>

與LSB比較起來，Index Embedded 的方式雖然不改變調色盤，

但是視覺(Visual)上容易察覺圖片可能會是偽裝媒體，

因為造成了顏色不協調的缺點。

在 week 6 看見鄭可欣同學的文章後，立刻與本泰討論顏色不協調的原因，

本泰認為調色盤應該需要經過排序，排序過後應該會使顏色看起來較為協調，

除此之外，Index Embedded 能夠嵌入的資訊量也比 LSB 方法 "少"。

LSB 的方法每個像素可以嵌入3bit，而Index Embedded 每個像素只能嵌入1 bit

除此之外，我提出一個問題是，當原本的圖片並非256色，而是255色時(或更少色時)，

原先256色將會有128組pair，但255色將會有127組pair和一個"落單的顏色"，

此時應該如何應對?

Week 7 將延續 Week 6 探討改進的方法