2010 的九月，第二次想不開，回母校修起了博士學位（或是應該說成挑戰，似乎來得合適些~）。重新回歸學生生活，其實並沒有想像中的那麼困難，尤其可以同時身兼太極影音研發團隊的一員這點來看：既有了維持生計的收入，又得以用有別於職場上的方式來充電，算是再好不過了。唯一的問題，就是寫作業…

High dynamic range (HDR) images have much larger dynamic ranges than traditional images' 256 levels. In addition, they correspond linearly to physical irradiance values of the scene. Hence, they are useful for many graphics and vision applications. In this assignment, you are asked to finish the following tasks to assemble an HDR image in a group of two.

上述就是我修 VFX 這門課的第一個作業：拍些照片；寫些程式；作些實驗；挑出張照片出來競標。

在想怎麼處理這門作業的同時，其實並不希望它只是一個家庭作業。對於一個年過三十，就業六年再度回學校唸書的帥氣男人來說，成績的高低顯得不那麼重要了；有沒有獲得其它同學（女同學?!）的稱讚或是羨慕，也一點兒都沒來得吸引人了。倒不如想想，怎麼從中得到其它的東西，來得有趣一些。

如果，把作業也整個 open source 出去，是不是會有趣些? 我的意思是，假如，整個寫作業的過程被記錄下來，然後以某種形式“開源“出去，想看的人，就可以得知我是怎麼面對這個家庭作業的：他（她）可以找到我寫的一堆 bug；有機會就拍的照片給個評論；或甚至是拿程式碼去加工也行。這也許是件有趣的事，於是試著條列下了幾個理由，在正式執行之前。

• 整個過程得被盡量地、完整地記錄下來。從一開始的幾行程式碼；過程中的測試碼；debug 的過程；到最終的說明文件…等，都能公開出去。
• 確實可以重覆執行的程式碼。程式碼公開後，只代表有些資訊供人參考，不代表每個人都有機會重現一樣的結果。如果能確保程式的結果可以被重現，同時提供一定的參數供人把玩與實驗，會是有意義多的 open source，不然只是一堆無用的程式碼。
• 符合作業的規範，包括報告。大學裏頭，進階的課程，都會要求有份報告，陳述你實作的過程，發現了些什麼，實驗了些什麼，即使只是片面的想法。如果能讓撰寫這份報告的氣力，同時可以以不同的形式出現，或是寫的方式可以很容易，不需要打開 Office 的 Word 或是 Powerpoint/Keynote，我想會是個很好的作法。DRY (Don’t Repeat Yourself）
• 藉著寫這個作業的同時，練習一下以另一種思維方式來處理 implementation 這件事。使用 python + numpy + scipy + matplotlib + ipython 是個不錯的組合。但也許，試試 matlab 會來得更好，更有啟發性與實驗性。

大略就是這樣。為此，我決定以 github 搭配 matlab 來執行這個作業。整個過程放出來。

The Power of Matlab

在 Matlab 裏頭，似乎所有關心的事物（資料），就只有 matrix 與 floating point 這種組合（至少大部分是）。一個單一個變數（ex, scale = 1.0;），其實是一個 1x1 的 matrix；一維的陣列，不管是垂直或是水平的，其實是一種 1xN 或是 Nx1 的 matrix；一個字串，其實是一個 1xN 的一維陣列，一樣是 matrix。這點實在很讓人嘖嘖稱奇。

一來，把所有 array, vector, string, list 等，統統一 matrix 代表，於是只要學一套，就可以整個套到其它資料結構上頭。這感覺有點像是 STL 裏的 generalized data structure templates，但又只關心 matrix 而已 :)

另一方面，因為 matrix 是 primitive data type，於是原來複雜的公式裏頭，一堆變數乘來乘去，一寫可能要四五個 nested loop 的程式碼，也許根本不用 for-loop 了!

另一方面，Matlab 的 plot 實在很驚人，可以說是學術研究者的萬能鑰匙，只要你能準備出一個 matrix 出來，大抵就可以畫出一張圖來了。

上圖是一張算出來的 HDR，它的 histogram。先不論裏頭的資訊正確與否，但從圖中可以直接得知 HDR 的 exposures 分佈於 -4 ~ 12 之間，且絕大多數都在 -4 ~ 4 之間，就是個很棒的資訊。可以只要幾行程式碼就做出這張圖來，則是個棒到不行的經驗。

Professional Camera: Canon EOS 5D

Canon EOS 5D 是隻約 10 萬台幣的數位單眼攝影機，老實說，我並不曉得它真正厲害在哪，但我可以確定的是，它握在手裏的感覺很好，有些沉重，有些溫和。另一方面，因為貴重，使用起來讓人戰戰兢兢的。

為求整個相機在拍攝過程中，不會因為人為的接觸而動到，我在電腦上安裝了 DSLR Remote Pro 來操作它。DSLR Remote 很不賴，所有的數值都可以調整，於是只要讓 5D 處於如下的預設狀況，其餘的，就交由 DSLR Remote 來調整 shutter speed 就行了。

• 先用 auto-focus 調整好 focus 後，就固定下來，同時從自動對焦改為手動對焦，讓之後的拍照都處於定焦模式。
• ISO 值調低一點，愈低愈好，省卻掉因為高 ISO 值所造成的 film grain-like noise。
• 固定白平衡。
• 相機調到 M 模式（manual mode），全權交由 DSLR Remote 來決定。

有機會的話，希望可以自己拼個 NDSL 的作法：OCC 出來，我想這樣會更輕便一些，不需要帶一台 laptop 或是一整個 iPad 到處跑。

Practical Workflow: Git Flow

使用 git，是件讓人相當開心的事：

• local commit 非常的快，省卻掉 svn 遇上不順的網路或是複雜的 commiting tree 所造成的 lag。
• local branch 更是讓人開心，沒事就 branch 一下，改錯或是寫失敗了，就在切回去，完全不用理會這個只寫到一半的 branch。
• 更棒的是，它的 stash 允許你把只寫到一半的程式或文件給藏起來，等你處理好 commit/fetch/push/pull/… 等與 repository 有直接交涉的事後，再 unstash 回來繼續完成你只做了一半的事。

git 的使用經驗與觀感，大致就是這樣。這些特色中，最重要的就是 branch 了。Git Flow 的提出，在於給出一個使用 branch 的哲學。

它有幾個中心思想：

• 整個開發過程中，有兩個開發支線同時並存：master (release) 與 develop。前者是正式版，後者是開發過程的最新版。亦即把 development 與 deployment 分隔開來，彼此相關，且又直接納入 git 的管理。
• 所有的開發，一律始於 develop，終於 develop。不直接更動 master。
• deploy 到 master 的單位叫作一個 release，可以想成是一個 milestone。每個 milestone 有明確的功能/目標列表最好，只專心完成這些事，其餘的都不用理會。
• 一個 release（milestone），可以拆成好幾個 features，於是每個 feature 都來自於 develop，待一開發完，就匯整回 develop 裏頭，等待最終的 release 完成。

We Love github, the social coding!

github 非常的…華麗，整個就是給 programmer 用的 facebook，就像 linkedin 是專門給就職人用的 facebook 一樣，是種特化的 social networking tool。它只專注在一件事上：讓寫程式的 programmers 可以彼此間協同合作，盡情地寫程式，亂寫想法，亂給意見，沒有任何的限制。

我在 github 上開了個 vfx11spring_project1，透過 git 將整個作業撰寫過程記錄下來，再透過 github 來 open 出去。

PS. 我實在太客氣了，加上以為只有 final project 才會需要兩人小組，所以壓根兒沒有找同學合夥搞定作業的想法。整個浪費了一個實驗 git 的 distributed 特性的機會，看來得等下一次的機會了。

PS2. 駭客任務（The Matrix）這部電影，裏頭應該要秀一些 Matlab 的 XD