Software Cinema

在找某種 Tool 的過程中發現這個有趣的工具: Segmentation Graph Cut

它事實上是這篇 Paper 內容的實作:

Olga Veksler, "Star Shape Prior for Graph-Cut Image Segmentation," European Conference on Computer Vision, pp.454-467, 2008

雖然 Google Code 頁面上沒有明寫, 不過猜 Project Owner 就是作者本人. 因為 Tool 裡面包含的 Samples 跟 Paper 內容的範例圖都一樣, 同時如果你從 SVN 上 Check-out, 而不是只抓 Binary 的話, 會發現 Repository 裡面還有兩篇相關的 Paper PDF, 如果不是自己有版權, 應該不至於敢直接放到 Repository 裡面吧.

Anyway, 這篇 Paper 跟這個 Tool 的重點很單純, 就是要把所謂的 Star Shape 加到利用 Graph Cut 作 Image Segmentation 的方法中. 至於所謂的 Star Shape, 採用 Paper 中的定義:

A star shape is defined with respect to a center point c. An object has a star shape if for any point p inside the object, all points on the straight line between the center c and p also lie inside the object.

如果用圖來舉例解釋的話, 大概是像下面的 (a) 不管怎樣裡面的任一點都可以做為 Center C, (b) 只有部分的點可以做為 Center C, 因為有些點無法讓 P 的條件符合, (c) 不管哪裡都不存在 Center C 可以讓 P 的條件符合.

其中 (a) (b) 的情況都符合 Star Shape 的定義.

工具的 Binary Release 本身需要 Visual Studio 2008 的一些 Libraries, 我在 Windows 7 沒法安裝, 直接從 SVN 抓下來 SRC, 裡面有 C++ Code ( 尚不清楚實際用途 ) 跟作為 GUI 的 Python Code. 直接利用 GUI.py 執行極可.

請注意會需要 wxPython 跟 Psyco, 沒有的話會要安裝才能繼續執行.

工具目的單純所以容易操作. 載入圖片後利用滑鼠在圖片上指定 C 跟 P. 左鍵 Click 兩下會出現藍色點是 C, 一下的話會出現黃色點是 P.

我本來以為會以 P 作為切割邊線的決定條件的, 但看來不是這樣, 像上圖那樣標記, 最後還是會抓到整朵花 (右下的紅框是結果, 是我額外貼上去的, 工具本身是會呼叫你的看圖程式去開結果圖). 但是如果舉個極端一點的例子, 像是這樣:

基本上還是會割到 Boundary 為止, 我猜跟裡面用到的 Graph Cut 演算法有關. 不過我的 Image Processing 只有到基本的傅立葉程度 = = , 這個就沒法猜了.

當然 Title 寫 With A Center 是有理由的...

在一般的情況下, 只要標記上 C, 不用 P 也是可以抓到, 像是這樣:

而且運算時間算是蠻快的, 扣掉開啟看圖程式的時間, 可以直接把結果接到工具畫面輸出的話, 應該是幾乎到無感的程度吧.

很有趣, 改天有空再來從 Python GUI 研究看看是不是可以直接使用裡面的 Kernel Function, 接到別的程式上.

其實這是上週的事情了, 只是很忙沒空寫下來.

上週在忙的事情, 其中一件是要開始電機系網站, 教授資料部分的 Data Migration. 因為目前的網站在教師資料部分, 超過 90% 的資料比例是用 HTML 網頁方式保存的, 不是用 Database 保存資料. 加上新網站是計算機中心統一跟外面的公司購買, 資料庫系統跟格式都大不相同, 對方也沒有 Migration 的服務 ( 就算有計中應該也不會想付這錢 ), 變成要人工去做. 不過這不是重點啦~

因為資料量太多了, 而且每個教授的資料維護本來就不是我們負責的工作, 所以就乾脆提前開放教師帳號, 給每個教師的工讀學生去處理 Data Migration.

開放帳號, 當然就是要寄出帳號跟密碼啦~ 這時候就發生了此篇的重點事件, 有位同學 ( 幫某教授更新資料的, 簡單說就是新網頁系統的一般使用者之一 ) 打了分機電話過來詢問:信件裡面的密碼有一部分變成笑臉男了, 怎麼辦 ?


沒有啦, 怎麼可能真的變成笑臉男, 這樣就變成 Security 的問題了. 其實只是變成一個驚訝臉的表情符號 ( 找不到完全一樣的, 用類似的替代 ).


沒記錯的話, 該同學用的 Mail Client 是 Outlook 的樣子. 然後他不知道原來 8o 會變成表情符號, 所以也無法自行 Decode 回去 ( 其實我也不知道 @@ ), 原本的密碼應該是 8#fdt8o

這問題有趣在於,

1. 這不是因為 Security Leak 產生的問題
2. Software 沒有錯, 也提供了調整或關閉的方法
3. 收信者不知道其實他有能力讓 Software 呈現正確的訊息
4. 收信者無法自行在腦中作 Decoding
5. 寄信者在收信者沒有 Feedback 前, 完全不會知道這問題的發生. 當然, 也無法預知會有這個問題.

不知道如果從 Sender 端跟 Receiver 端分別考量這個問題, 是不是可以解決. 這樣的問題應該不只存在於 Mail System 中. 更加極端地說, 這是系統中不同 Components 之間的 Trustworthiness 問題. (下圖大小很難調, 不管了, 請將就)


在 Receiver 端要提供更加 User Friendly 的 Active Configuration Notification, 而不是倚賴 Receiver 的使用能力. 而在 Sender 端則是提供 Active Warning 的服務, 類似 Automatic Spelling Check. 不過要做到這些, 其實有許多附加的問題要解決, 不知道是否有更簡單的解決方法呢 ?

為了取這個標題, 還特地去查某句成語的英文一般都怎麼說 XD

昨天在處理實驗室 MoinMoin Wiki 出現的一個奇怪的問題. 某個特定頁面只要進行瀏覽, 就會導致 MoinMoin 整個 Crash, 一點 Process 也不留. 自然, 直覺就是該頁面內容有什麼奇怪的東西, 或是內容在磁碟上有毀損, 導致 MoinMoin 讀到該頁面內容就會出現 Exception 而掛掉.

但是在想要近一步去檢視該頁內容是, 猛然發現, 其實我不知道 MoinMoin 是怎樣處理 Page Data 的. 我既不知道 Page Data I/O 的部份在哪, 也不知道 Page Data 平常是保存在哪.

本來, 閉著眼睛也可以大概畫出一般 Wiki System 的 Architectural Design Abstraction, 主要的 Components 有哪些, 各自的責任也清楚. 但是單知道這些對我現在要解決問題幫助卻不是很大.

作為一個在唸 Ph.D. Program 的 Programmer, 這樣的事情真的是很不應該的, 但是還是發生了, 因此特別寫下這個標題--雖然別人看來可以摸不著頭緒--來警惕一下自己.

幸好簡單查一下 MoinMoin 的資料, 馬上就看到 MoinMoin 在 Data 的保存上十分簡單, 直接利用現成的 File System 作儲存而已. 這樣一來馬上補足了在 Data Repository 部份的一些細節, 也就一下子找到 Page Data.

MoinMoin 的 Page Data 存放在 /data/pages/ 中 ( 實驗室的資料比較敏感, 以下用電機系網路服務使用手冊 Wiki 作例子 ),


每個頁面直接用 Relative Page Path 作為 Directory Name, 其中 "/" 以及 "-" 之類的就用特殊符號取代, 像是 (2f) 跟 (2d).

在每個頁面的 Directory 之下, 有幾個主要的檔案跟資料夾, 名稱一看就很清楚, 不一一加註, 只舉頁面內容來說, current 檔案紀錄目前的版本, 而 revisions 資料夾裡面存有所有的歷史頁面資料. 因此實際的頁面資料是存在 revisions 資料夾裡的, 把每個頁面 cat 出來就很清楚了.


從這點也可以看出來, 其實大量頻繁的網頁修改, 在 MoinMoin 系統中是很吃硬碟資源的.

知道 MoinMoin 資料存放的細節後就更有趣了.

目前手上有些給實驗室用的小東西, 過去不是很清楚要怎樣把其輸出直接送到實驗室的 MoinMoin Wiki, 這樣一來其實可以直接在 File System Level 作手腳. 繞過 MoinMoin 本身, 直接輸出到 Data Repository 中, 只要內容格式符合 MoinMoin 語法, 跟 Revision History 等 Meta-data 有正確的填寫, 就能夠被 MoinMoin 讀取, 出現在 Wiki 頁面系統上了.


Know both Design Abstraction and Implementation Detail ever Resourceful.

我要把這句印出來貼在座位旁 :p

其實主要步驟只要照著 Compdigitec Labs 的這篇 Virtual MIDI Keyboard In Ubuntu 作即可.

不過實際上在我的系統上有些微的不同. 因為對整個 Sound System 不熟悉, 沒有辦法理解是怎麼回事, 姑且記下來當作 "這樣設定也可以" 看吧.

先記一下安裝的部份, 共需要 ( Package Name 以 Mandriva 2010.1 上的為準 ) :

1. qjackctl ( JACK Audio Connection Kit )
2. zynaddsubfx ( ZynAddSubFx )
3. vmpk ( Virtual MIDI Piano Keyboard )

其中 vmpk 是要作為虛擬 MIDI 鍵盤的主介面. 雖然後來發現 ZynAddSubFx 也有虛擬鍵盤介面, 但是變更 Keyboard Map 設定跟其他各種設定上, 感覺 vmpk 比 ZynAddSubFx 來的方便.

而 qjackctl 是 Connection 控制器, 負責把 vmpk 作為前端介面, 輸出的 MIDI 資料導引到 ZynAddSubFx, 再到實體的音效硬體/音效卡作播出. 因為 vmpk 本身其實就是單純的虛擬鍵盤子系統, 因此到實際播出前需要 Synthesizer 幫忙處理合成. ZynAddSubFx 在這裡就當作 Synthesizer 使用.

接著作 limits.conf 設定,

sudo su -c 'echo @audio - rtprio 99 >> /etc/security/limits.conf'
sudo su -c 'echo @audio - memlock 250000 >> /etc/security/limits.conf'
sudo su -c 'echo @audio - nice -10 >> /etc/security/limits.conf'

把系統 reboot 後重新開啟 qjackctl, 並利用 "Start" 按鈕開啟 JACK server ( jackd ). 這時候如果遇到開啟失敗的訊息, 請利用 Messages 按鈕看錯誤訊息. 如果是 server 啟動失敗, 請把 ALSA 重新啟動試試看. ( alsa command 的位置可能根據系統有所不同 )

sudo su -c '/etc/init.d/alsa force-reload'

啟動沒問題的話, 開啟 ZynaddSubFx 以及 vmpk, 然後利用 Connect 按鈕設定上面說的, 從 vmpk 到 ZynaddSubFx 再到音效裝置的 Connections.

照 Compdigitec Labs 的文章中之示範, 音效卡代號應該會出現在 ALSA 分頁中, 但是我的沒有 ^^b, 所以先只有把 vmpk 的 Output 接到 ZynaddSubFx. 接上的方法很簡單, 用滑鼠把 vmpk Output 拉到 ZynaddSubFx 上放開即可.


而 ZynaddSubFx 到音效裝置間的連結, 則是改在 Audio 頁面中搞定. 其中 playback 1 是左聲道, playback2 是右聲道, 其他的在我系統中無作用.


這樣設定完就 OK 了~, 把視窗 Focus 移到 vmpk 上面, 對應的鍵盤按下去就可以看到琴鍵變化, 以及發出 MIDI 音效. 在 ZynaddSubFx 視窗中也會有對應的變化.


其實當焦點移到 ZynaddSubFx 上也是可以有同樣的反應. 不過如上所述 vmpk 較占優勢的理由, 本篇還是以 vmpk 作為 Front-End 為主.

正在看一篇跟 Code Readability 相關的 Paper, 不知怎忽然想起大一剛進成大電機時, 學 Programming 的作業...

當然, 當時我學 Programming 與其說是上計概課學的, 不如說是自己學 + 認識的資工學長作榜樣居多, 但是書本上的練習跟上課的練習還是有差, 特別是你不想端出去的作業比別人差, 而且我們的計概課也不是一般呼嚨用的計概課.

我印象深刻的是一個 Hanoi Tower 的作業. 說到 Hanoi Tower, 其實我國中的時候就用數學的角度解過這個問題了, 但是寫程式是另外一回事. 稍微熟悉的人應該都知道, Hanoi Tower 是練習 Recursion 的基本入門題之一. 但是該作業有趣的是, 附帶了一個額外的加分題: 請用 Non-Recursive 的方式寫出解 Hanoi Tower 的程式 (當然, 要 step-by-step 輸出).

* 其實這題目有些書在 Recursive 章節後面也會加. 只是小大一是不會主動去看後面的練習作業題的 XD


那時候其實還不太會用 Search Engine, 而且 Google 在台灣也還沒有知名度, 很"傻"地就一頭鑽下去想解法, 以及怎樣寫成 Program, 還附帶要寫成 Document.

最後當然是有寫出來 ( 還上台介紹 = = 我大學生涯中第一次上台 ), 利用某些規律可以知道在三個 Towers 處在特定的 State 時, 就應該怎樣做 Transition 來到達下一個 State, 並且達到 Optimization. 也當然啦, 當時小大一是不會知道其實我在畫 State Transition Diagram 的 XD

其實在寫成 Program 以前, 我在找規律以及推導的過程, 本身就是 Programming 最重要的邏輯觀念之一. 可以在憑空找以及運算這些邏輯之中得到樂趣, 是後來可以成為一個積極的 Programmer 最重要的條件之一.

後來的作業印象中就比較偏向 Application 導向, 例如寫簡單的火車訂票系統之類的. 雖然其中也有很重要且複雜的 Scheduling 問題存在, 但是因為整個系統要考慮的 Functions 變多, 反而重要的 Scheduling 問題對於當時只是程式初學者的人來說, 變得不是那麼重要與有趣.

直到現在, 可能因為我們 Lab. 的大家習慣以系統角度通盤思考事情, 因此也反映到出給學生的作業上. 現在的作業寫滿整整兩頁 A4 的說明是基本 ( 一次作業一題而已歐 ), 前兩年甚至出現了高達六頁的說明 ( 印象中, 一樣是一次作業而已 ). 而看這作業說明的學生, 大多只是剛上大學, 剛要開始認真接觸 Programming 而已...

我們不禁應該思考, 這樣的作業美其名可以讓學生提早從整個系統角度思考 Programming, 可以更加貼近真實生活中的應用系統, 但是效果真的有比當初的 Hanoi Tower 好嗎 ? 如果我們並不期許計概課裡的所有學生最後都是一個好的 Software Engineer, 或是都要走 Pure CS 路線, 或許多些 Hanoi Tower 的題目能更引起學生自發的思考, 也更加容易傳遞 Programming 課程每次的教學重點.