[生活]放假!![2007寒假]

噗

我現在已經變成一個容易滿足的阿宅了

在桃園度過了大半個苦悶的寒假

每個禮拜都掛在禮拜二禮拜四早餐會報的腰斬下

我今天終於鼓起勇氣打電話給BOSS~

BOSS很爽快的跟我說放我假耶...

真開心~~~

我已經悶在桃園好久了耶...

除了大家現在都在準備考研究所

我不敢亂去吵他們之外...

也許我現在已經是個老人的關係了吧

只要想到要出去台北玩 = 三個小時去+三個小時回來的時間

怎麼想那個CP值都不高

而且又被莫名奇妙的罪惡感給綁住

完全的不敢玩樂

偶而回家

也活在打掃房間的世界中
　　喔 我搬家了...
　　我房間什麼沒有...
　　就是床大和衣櫃多...
　　當旅館蠻適合的...
　　想來的可以向我登記XDD

其實是非常苦悶的日子...

寒假搬到三舍...

跟外國人室友都不認識...

這是我第一次跟外國人住...

雖然是個帥氣的經驗...

但是我這個閉俗人...

其實是很害怕的...

不過我遇到的外國人室友(一黑兩咖啡)

倒是出乎我意外的和善耶...

今年過年還要來我家吃年夜飯~

難道說...

我跟黑色的人比較有緣分嗎...XDD

有請小黑大人回應XDD

aaa

Here is the beginning of my post.

And here is the rest of it.

目的變更...

雖然在很久以前的那篇中有說過這個部落格是學校用的...

可是呢...

反正wretch那邊的都是學校用的了

幹麻還多一個給學校用ㄚ...

而且黑鬼又一直叫我用blog...
(其實我覺得他是想要來鬧版...)

反正這個blog沒幾個人知道...

重要的是老師也不知道耶!!
(謎之聲:你確定嗎... cosine:不管!!老師知道也要假裝不知道!!)

我在這邊可以不用ㄍㄧㄥ吧XDD

在老師的認知世界裡我也是要形象的阿!!
(謎之聲:你沒有啦!! cosine)

就讓老師活在無名的那個blog中好了...

這個blog嘛...就讓爾等小輩胡搞瞎搞好了...

在這是不需要注意形象的啦!!

向左邊,向右邊

上次meeting的時候老師說在遇到叉路的時候要可以選擇哪路


我原本的想法是

因為我們存地圖是用資料庫

原本是(格子編號,x座標,y座標,格子的內容)

那只要再增加上下左右四個欄位

變成這樣(格子編號,x座標,y座標,格子的內容,上面的格子編號,下面的格子編號,左邊的格子編號,右邊的格子編號)


如果沒有上下左右的話

相對的欄位就填100這個值就好了

這個要存從哪邊來的

(有點像老鼠走迷宮...)

在跟阿梅討論它的想法時

他提出了以檔案的方式存路線

如下圖

"/album/show.php?i=iamcosine&b=2&f=1961576178.jpg">src=
"http://pic7.pic.wretch.cc/photos/20/i/iamcosine/2/1961576178.jpg" />


但是

這樣子就沒有方向性

也是要紀錄從哪邊來的

後來我想了很久

乾脆用以下的方法

每條路都有方向性

像這樣"/album/show.php?i=iamcosine&b=2&f=1961576179.jpg">src=
"http://pic7.pic.wretch.cc/photos/20/i/iamcosine/2/1961576179.jpg" />


一個箭頭就是一條路

當遇到叉路的時候

載去讀取對應的檔案(也是上下左右)

例如像這樣的檔案(0,1,2,0)

就是下面跟左邊有路

對應的路徑是存在是file1.txt和file2.txt

就可以知道可以選擇哪邊的路了

不過這只是我初步的想法

要等程式寫出來才知道對不對

[JPEG]4.1Elements specified in this Specification

天ㄚ...


我還以為我會被前面的名詞定義給淹沒...


還好boss跟我說可以從4.1開始看...


終於可以先skip guideline了....好感動...

 


唔...看來是我疏忽了...我還以為只有boss會看...


趕快把原文補上...(逃~~)





There are three elements specified in this Specification:





a) An encoder is an embodiment of an encoding process. As shown in  Figure 1, an encoder takes as input digital source image data and table specifications, and by means of a specified set of procedures generates as output compressed image data.





b) A decoder is an embodiment of a decoding process. As shown in Figure 2, a decoder takes as input compressed image data and table specifications, and by means of a specified set of procedures generates as output digital reconstructed image data.





c) The interchange format, shown in Figure 3, is a compressed image data representation which includes all table specifications used in the encoding process. The interchange format is for exchange between


application environments.





Figures 1 and 2 illustrate the general case for which the continuous-tone source and reconstructed image data consist of multiple components. (A colour image consists of multiple components; a grayscale image consists only of a single component.) A significant portion of this Specification is concerned with how to handle multiple-component images in a flexible, application-independent way.





These figures are also meant to show that the same tables specified for an encoder to use to compress a particular image must be provided to a decoder to reconstruct that image. However, this Specification does not specify how applications should associate tables with compressed image data, nor how they should represent source image data generally within their specific environments.





Consequently, this Specification also specifies the interchange format shown in Figure 3, in which table specifications are included within compressed image data. An image compressed with a specified encoding process within one application environment, A, is passed to a different environment, B, by means of the interchange format.


The interchange format does not specify a complete coded image representation. Application-dependent information,e.g. colour space, is outside the scope of this Specification.