Animation

你有聽過由一隻兔子來向你介紹什麼是 render farm，又它與 cloud computing 有什麼關係的嗎? 沒有的話，那你真的應該繼續看下去，因為真的很好笑… 在 Amazon, Google, Salesforce, Microsoft, IBM 等“人“這樣努力不懈地告訴世人，什麼是雲端計算（cloud computing）之後，接著是一群網路先知（Internet Pioneer）這邊 blog, 那邊撰寫短文，加上偶爾還發表了一些論文（Above the Clouds: A Berkeley View of Cloud Computing ），連台灣的教授們也一路下海宣傳了，像佈道大會似的，這是場科技業都會想參一腳的世界趨勢。 那雲端運算與電腦動畫/電影產業有什麼關係呢? 可以 google 一下如下的一些關鍵字：cloud computing, render farm, hollywood, animation, … 但實在不是我感興趣而寫這一篇 blog 的目的，不高不低的。我在想的是，有什麼有趣，讓人看了會心一笑的 cloud computing in animation industry 的東西的? Render Farm.Fi 是個奇怪而有趣的計畫，它邀請所有有電腦的人，當你的電腦沒在做什麼複雜的事的時候（上 FB 就是一個很好的例子），貢獻你的一點點機器出來，供別人在你的電腦上算圖。還取了個有趣的名稱：Volunteer computing。 重點是，上頭這段宣傳影片實在太可愛了，加上不是美國腔，反而比較容易聽懂（因為說得比較慢?）。看完後，就算你對雲端運算與 render farm 沒啥興趣，也有某種大概個印象了 :) 另有一個與 render farm + cloud computing 有關的網站叫 bevyRender 。 bev·y A large group of people or things of a particular kind A group of birds, particularly when closely gathered on the ground 底層是透過 erlang 的平行運算平台來執行 bucket rendering，概念與那隻大白免介紹的差不多。就是網站遜多了點就是。

I just suddenly discovered an app from App Store, Alfred . Really funny. It looks like Quicksilver from it’s description. But most interesting is, it reminds me of the render farm management tool, Alfred .

修了門 VFX 課程，作業之一是透過製作一小段 CG + live shooting 的片段來了解 matchmoving 與 camera tracking 的過程與細節。我挑選了 NukeX，使用裏頭的 CameraTracker 來處理這件事。 CameraTracker 本身建議的 feature points 個數不多，只要 100~200 就差不多了，它預覽用的 feature points 品質就挺不錯的了，而且非常的快，對於一個 VFX toolset 來說，這方面的表現非常的好。 VFX 裏頭，有非常多的方法與演算法，都足以耗去你數十分鐘，有日甚至要數小時，這對於工作排得滿滿的，一路到天花板的工作人員來說，無疑是一種災難。有非常多的 studio 花了很多的力氣在處理的技術問題中，「時間/效能」這部分佔了很高的比例。（整合是另一大塊，不過不在這篇 blog 的範圍）Nuke 能在 compositing 勝出的原因之一，我想重點就是「效能」。 上頭的四張截圖，純脆是覺得有趣好玩的，並沒有任何技術意義。不管是 tracking 或是 camera/features 的 exporting to Maya，只要花些許時間，都能一一執行過去。問題就在於，當你手上拿到一組 tracking camera，還有一堆 feature point cloud 後，匯入 Maya，與裏頭的 CG element 混在一起，就算是比較麻煩的事了。我的經驗尚且不足，只完成了如下的小片段。 附記： pzman 有篇 [NukeX 6 : 從NUKE追蹤資料到MAYA&修Marker流程](http://NukeX 6 : 從NUKE追蹤資料到MAYA&修Marker流程)，是個好的開始。

在像 Pixar 這樣的 animation studio，或是像 ILM 這樣大規模的 VFX studio 裏頭，OpenEXR 扮演了一個非常重要的角色：工作過程中，可以用來預覽或是再製的圖片檔。我們就如同其它的 studio 一樣，也是使用 EXR 作為內部的圖檔使用。公司裏頭，絕大部分的 exr 檔，都是 renderer 的產物。OpenEXR 是個可以用來乘載 HDR 的圖檔格式，在 ILM 的推波助瀾，加上其它 studio 的跟進，動畫軟體的支援下，幾乎成了某種 de facto 標票。然後，它終究只是一個“夠開放“的圖檔格式，如何有效且正確的善用它，才是更重要的事。 以下幾點，是我們在太極影音的工作過程中，發展出來的一些經驗： EXR 檔案裏頭沒有任何標頭或 tag 指出它存的 color space 是線性（linear）、gamma 2.2（1.8, 2.6, …）等，而是由使用的人或是軟體自行解釋。 EXR 鼓勵以 linear color space 的方式來存內容 (scene-referred)。這樣不管是人、機器或是軟體，都不用去猜測別的可能性，而且對於後製來說，既不用對拿到的影像想太多就直接操作，也不需要先做個轉換，是比較省事且安全有效率的 pipeline。但這點不是強制性的，只能說是大家約定成俗的一種習慣性用法。就像我們現在都認為相機出來的 JPEG 一般是 sRGB (~ gamma2.2) 或 Adobe RGB，但其實 JPEG spec 並沒有定義這個。 EXR 以 linear 儲存後，在呈現時才去根據不同的 display device，使用不同的 transformation 或是 LUT 來轉換。要求比較嚴苛的工作環境，會就每個 display device 有一組 LUT (1D? 2D? 3D? 這部分我還沒有作完研究各種 LUT 表示法的適用狀況，只能說，理論上 3D LUT 比較厲害。），且會定時根據 device 的狀況來更新那組 LUT。這種作法是非常非常嚴苛的要求下的作法。 EXR 可以有任意的 metadata，所以是可以在裏頭存個 ‘colorspace’ 的 meta 來用，不過這樣得確認所有接觸到此 exr 的程式，都有去“尊重“這個 meta 才有用，不然反而會落得不三不四的。 EXR 儲存的數值，只有 16-bit 或是 32-bit 的這兩種，並沒有 8-bit, 10-bit, 12-bit, 24-bit, … 等此說法。當有人這樣說時，可以假設是只用了比較少的 bit（ex, 16 bits 中，只用了 14 bits，另外兩個 bits 為零），但存在檔案裏時，一樣是 16 或是 32 bits。 同樣的圖片，以 linear 與 log 的方式來存的話（這邊指的是單純的 log，並非 REDlog 或是 panalog 這類特定的 preset），log 存的檔案的確是會小一點點，約節省了 10%~20%。但它仍舊是以 16 bits 或是 32 bits 來存。 壓縮方法中，有 loseless 與 lossy 兩種。PIZ, ZIP, ZIP (16 scanline), RLE 屬於 loseless。其中 ZIP (16 scanline) 對於 CG image 的壓縮率最大；而 PIZ 對於有 film grain 的 image 有最好的表現（因為使用了 wavelet）。B44 或是 B44A 為 lossy，我們現有的工作環境不會使用到，也不應該使用到才是。 像素(pixel) 存的方式，又分為 scanline 與 tiled。後者適合以一張 .exr 來存一整個 mipmaps，就像 .tex 一樣（.tex 是 .tif 的一種小變型）。prman（Pixar’s RenderMan）的 texture 這個 shader op，也許已經有支援 .tiff 或 .exr 了（我沒去確認），但我相信對於 .tex 的支援應該仍舊是最好的。 further reading: ...

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 來執行這個作業。整個過程放出來 。 ...

如果你和我一樣，不小心把 iTunes 的板型也變成如上圖這樣（其實很容易就做到 XD），你是該慶幸，還好之前有遠見，買了個寬螢幕呢? 還是應該咒罵這個奇怪的板型，把你的眼睛搞得很累，不曉得究竟要看哪呢? 即使它是 iTunes，是 Apple 的產品，是 Steve Jobs 的重量級軟體~ 這是最早之一，也是最常見的 layouts 之一：三欄式。只是稍稍做了點變型，讓原來分屬左右的 sidebar/sides 全數擠到同一邊去了，然後再稍稍調整一下兩個 sidebars 的寬度比，製作出一種不等寬，輕重不一的視覺效果來，讓我們可以一眼就得知，即使把兩個 sidebars 放在同一邊，還是有熟輕熟重之分。 作法與這個網站的版型設計 的想法有點像~ 這是另一個，最最常見的版型之一：thumb view。想盡辦法把要原本要條列式的東西，改以一個一個代表的縮圖來，就成了這個樣子了。這樣的設計，總是讓我想到拼圖，看著散佈在整個桌面上的小拼圖，只能一點一點從中找出一些線索來。雖然說，散開來的小拼圖，一般是不會排列得這麼整齊的 :D iTunes 最讓我感到驚豔的，就屬這個了。整個唱片好像活起來了似的。 最後，就是這個有點有趣又帶點奇怪的版型了，如果它把想成是 list view 與 thumb view 的結合的話，取其各自的優點，大概，就有機會長成這個樣子的吧。 版型設計真的是件有趣而神祕的事，拿 Drupal 的 Panels 這個模組來說好了，它預設就有一些如上圖的版型供你選，說實在的，真的會有人把網站弄得像是磚塊牆那樣的嗎 :D PS. 我最愛的網站版型，大概就長得如下圖 吧。

What would you expect from the design of 3D UI in the future smart phones? Google it !