HW8

總結這一學期的學習過程，只能說一個字：混。

真的要感謝老師的講解，還有同學的不吝指導

從一開始學習BCB的過程

看著書本的理論，實在悟不出什麼想法來

原理我是知道的

不過要把理論轉成實作真的是我的一大死穴

整學期的前三分之二真的很混

混到連我老媽都認不出我來了

但是到最後發現要開始趕作業時

我卻感受到作業帶來的樂趣

比如之前在 S513 跟我的麻吉簡維煜研究第六次作業的時候

真的發現很多有趣的地方

像是：為什麼*3會這樣、加個迴圈為什麼就彩色了、改個變數就全部變黃色了.......等等

搞到晚上6~7點，學校幾乎都快沒人了

還嘗試去六樓看看老師在不在辦公室

想說問一下作業的東西

雖然最後都有找到答案

不過當時鑽研的過程當中

真的是莫名的激動 + 驚訝

BCB的確是很好玩，但我覺得鑽的太深時是會感到枯燥乏味的

我只能適時的停下腳步

我是個對程式敏感度不佳的學生

學得有點辛苦，但我還是有些許收獲

也感謝老師這一學期的不吝授與有關影像處理的基礎技能

謝謝老師<(_ _)>

HW5

這次位元平面著實有點太抽象

((bit1>>0)&0x1)?clWhite:clBlack

上面這一段還真是有夠噁心的= =

第一次看到這麼莫名其妙的東西




而且寫完之後(其實是問同學的)，很開心的要Run

結果開圖很OK，但是轉換過要丟到 Image2 到 Image9 的畫布之中

居然顯示不出來！！！！？

我在開圖的後面加上以下的程式碼

iImageWidth=Image1->Width;
iImageHeight=Image1->Height;

上面的動作是方便之後畫布的利用比較好拿取它的數值

然後下面的的程式碼是拿Image1 到 Image2 做示範

Image2->Width=iImageWidth;
Image2->Height=iImageHeight;

我看了....嗯....非常好

結果居然還是畫不出來！

問了好多人，最後突然想到...

老師好像有說過，開AutoSize的話

有時候會出現無法理解的錯誤

我就試試看把AutoSize關掉

然後就成功了...

所以，我...剛剛...到底在幹什呢？




以下是Run出來的結果：













(1-bit)

















(2-bit)

















(3-bit)

















(4-bit)

















(5-bit)

















(6-bit)

















(7-bit)

















(8-bit)

HW7

這次的作業利用到了兩個遮罩去做梯度銳化的工作

利用原本的數值去做梯度運算，公式如下

我們姑且令+1為 a ，+2為 b ，-1為 c ，-2為 d

這樣下面的過程會比較好解釋






原圖：






















經過初期1 , 2 , 1跟-1 , -2 , -1的設定下

Run出來的結果如下圖(1)所示：

















圖(1)









我將 a 群值跟 c 群值調整成 0.1 跟 -0.1

然後 b 群值跟 d 群值調整成 1 跟 -1

結果如下圖(2)所示：

















圖(2)











之後我嘗試將 a 群值跟 c 群值調整成 1 跟 -1

然後 b 群值跟 d 群值調整成 0.1 跟 -0.1

結果如下圖(3)所示：

















圖(3)







最後我再調整了圖(2)之中的 b 跟 d 群值，將它們改為 2 , -2

結果如下圖(4)所示：

















圖(4)






經過圖(2)跟圖(3)比較，我自己發現

a 跟 c的值越小，線條就越細且明顯

反之則是粗，但是細部條紋可以出來且不會過於誇張



而圖(2)跟(4)比較之下，圖(4)因為中間值 b 跟 d 的上升

線條有少部分的破壞，且整體圖片開始有些微雜點出現

雖然看起來好像跟(3)沒什麼差別

但是如果利用附屬應用程式之中的協助工具裡的放大鏡去看

就可以很明顯的看出圖(3)跟圖(4)的精緻度差別

所以最後我自己推測

中間值 b 跟 d 決定面積

四周值 a 跟 c 則是決定線條粗細

而且 b d 跟 a c 的對比不要小於0.5之內，感覺就會比較明顯




所以總結，彩圖的梯度銳化值越小越好

但是低於0.1太多圖片會幾乎全黑

雖然還是看的到，不過幾乎是要把LCD螢幕擺斜的看才看的到了

就像下圖所示：

















別跟我說：這明明就是全黑的啊！

請用力的仔細給它看清楚就會看到了

Hw04

(乘冪律：0.5)

(原圖)

這次作業是利用Power-law來做圖片對比度的增減

以下為乘冪律的公式

其實過程出乎意料的簡單

只要將公式套入RGB各個裡頭

pow(255,1-x)*pow(MR[i][j],x)

pow(255,1-x)*pow(MG[i][j],x)

pow(255,1-x)*pow(MB[i][j],x)

然後再走訪整個畫布，這樣就能呈現出其中的效果

想了想為何這麼簡短的公式卻有如此的效果

看了看網路上的講解才知道

公式的a和k是常數，而且o * (x ^ k)是x ^ k的一個漸進微小函數

在這裡，k通常被稱為是縮放指數

在詞語「縮放」意指：乘冪律函數滿足

而c是常數

因此縮放函數的參數變化會不斷地出現相對稱情形

但是卻保留了形狀函數本身的樣子

這就是乘冪律吸引人的地方

HW6

(已濾)

(未濾)

跟朋友討論了很久，一開始在灰階成功之後轉戰彩色的部分

卻出現問題，因為圖片只顯示1/3

看到灰階調色盤中的pf8bit

想說改成pf24bit，結果根本八竿子打不上關係(亂搞！)

個人覺得它既然只跑1/3，就乾脆幫它*3

bPtrResultImage [j] 改成 bPtrResultImage [i*j]

內部也些微改過一下

結果造成左邊灰褐色，中間出現黃線條，右邊整個就是黃色的

跟朋友討論過後才知道，原來一個像素點之中有一組RGB

所以假設4*4的圖加上RGB有12格

因為把一個Pixel之中的RGB忽略

原本橫列應該是(RGB,RGB,RGB,RGB)

導致掃描時候，只掃(RGB,R)

這等於只完成4/12

所以會變成圖片只呈現1/3

所以改成 bPtrResultImage[3*j+k]

內部也依次做調整，就可以了

只是之後發現還是跑1/3的原因是因為：沒有做專案的存儲。

導致明明是很正確的程式，結果Run出來還是錯誤的結果

還蠻令人好笑的....嗯。

HW3

Red直方圖

Green直方圖

Blue直方圖

「程式著作權非我之手，在寫不出來的當下，只能借作理解Code之用」

之前會遇到開檔開到發生錯誤

估狗到老師的無名，有說到：

「連續開檔，如果Image大小不同，陣列大小就會有問題

所以必須Delete掉原來的陣列

重新New一個陣列來用...」

程式碼的RGB前面都會加(TColor)，是做資料型態的強制轉換

以防傳值發生超值的問題，因為這好像沒辦法用Compile找出錯誤

算是一種保護措施嗎?? 而且在計算過程用指標處理會比較快嗎??

這次的Histogram很遺憾還是沒有寫出來

主要是對前置作業的空間分配不了解

問題一到就只是想這個怎麼寫，一股腦的去估狗亂抓程式碼亂塞

心裡是一種亂槍打鳥的心態，到最後一隻鳥都沒打到，還把自己爆頭了

連最開始的陣列配置都不清楚了，後面還妄想要做有的沒的，沒救！

的確是有很多疑問，但是問不出來，因為......就是問不出來，看來我再問同學好了。

hw2 (修正版)

示意圖

由於先前的不是課程上所要求的

所以就重做了一下

不過還是看得出來旋轉後的圖失真了

我自己在想

會不會是因為原圖的Pixel都是int值

旋轉到目標角的點上時發生float問題

新像素的初始值原本都是整數點

所以旋轉的過程當中

一出現小數點就Null

導致圖片失真了

所以我在想，是不是需要使用反鋸齒來修飾失真的問題

不過一提到反鋸齒好像又把問題搞大了不少

但是新的像素原本就是一個一個像素點構成

就像

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

口口口口口口口口口口口

所以如果像素點一轉到口跟口的中間

就只能被Null掉

畢竟新創的畫布也是一個一個整數點構成的

旋轉成傾斜的不太可能不會失真

我也不知道我說的對不對

不過個人感覺是如此啦

hw1 96360652諶德軒

聽說題目是：秀一張影像到二維陣列中

應該是這樣沒錯吧?

由於沒修過BCB

導致一開始就陷入發呆的情況

看著範例跟學長作業的參考下

結果還是卡在開影像視窗

原來是我沒有加"開圖檔的元件"

總算能開影像了

結語就是：我的第一份作業搞得像殘障一樣。