ULANI 電子紙桌曆的遮騰筆記 (5)

既然dither程式完成了，那只要把色盤換成規格書中的實測值，就可以結束遮騰了？事情可沒有這麼簡單。

如果直接把L*a*b*轉成RGB後帶入，這樣子的「白色」不夠「亮」，隨之dither出來的圖案，高亮度的部份就會類似過曝的情況，暗部也無法表現出來。

於是嘗試把全部七個基本色掐一下，讓「黑色」接近全黑，「白色」接近全白，其餘的按照比例平移縮放調整一下，這樣子一來就會像是這樣，算是相當堪用了。

再來就是得想辦法塞進app中。如果直接當照片放進去的話，應該又會被再dither一次，因此要把dither好的圖，填成原先色盤的顏色值，這樣子取最接近色就會是dither好的顏色。把未dither跟dither好的圖p在一起，就可以同時比較ULANI app轉的跟改色盤後的效果。

ULANI 電子紙桌曆的遮騰筆記 (4)

想要改用規格書中實測顏色來作為dither的色盤，第一步當然就是得先實作一個dither演算法。這類的演算法百百種，比較廣為人知的應該就屬 Floyd–Steinberg 了(後面簡稱FS)，畢竟從開始有彩色噴墨印表機，就常常看到這個名字，只是一直沒有去看過是怎麼做的。其實FS演算法很簡單，是一種誤差擴散的方式，維基百科上就可以找到說明了，還有偽程式碼的範例。基本上，FS是先找到「色盤中最接近這個圖素的顏色」，然後計算差值分散到鄰近的像素上。

由於擴散的方向都是往前不往後，所以實際只要掃過一遍整張圖，就可以計算完成。只是要分散運算的話直接是沒辦法切開，可能還得另外處理。

有了範例程式，就先試試看灰階的圖片，看起來沒有什麼問題。於是開始改成RGB的彩色，也就是原先的PIL傳回單一數值改成[R, G, B]，然後使用numpy來處理。只是算出來的都是黑畫面，不曉得問題出在哪裡。後來看了另一篇文章，才猛然想起因為python沒有明確的型別，[R, G, B]非 primitive type 會是個指標 reference，所以運算之前得使用 .copy() 複製一份數值，才不會是 [0, 0, 0] 全黑。然後FS演算法中要找「色盤中最接近這個圖素的顏色」，就用RGB三個數值的幾何距離(RGB差值的平方和再取平方根)來計算，以最笨的方式依序比較七個基本色的距離就可以得到最接近色了。先求有再求快，到這邊算是完成了第一步。

ULANI 電子紙桌曆的遮騰筆記 (3)

這裡我們來談談色差的問題。回到之前微x電子所提供的面板規格書，裡面其實有使用儀器測定出來實際的顏色表現。所使用的單位不是平常熟知的RGB或CMYK，而是由國際照明委員會在1976年訂出的一種表示方式。其中L*代表亮度，範圍是0到100，也就是全黑到全白。而a*跟b*則是分別描述在紅綠之間跟藍黃之間的兩個座標軸，範圍是-128到127。而後面dE2000_Max這項色差數值到底是差多大，個人非相關領域還有請專業人士補充說明。

雖然維基百科上寫L*a*b*到RGB的轉換與設備相關，不過網路上可以找到轉換工具，順手就把轉換過的數值用顏色圖片的方式表示出來：

這裡很明顯就可以看到，先不考慮亮度的影響，黑色偏紫，紅色其實偏橘色，藍色偏藏青色，綠色是暗綠，反而是黃色跟橘色比較沒有偏差。跟ULANI電子曆面板實際看到的效果算是相當的吻合，合理推測應該兩者就是同一個規格的吧？(廢話，目前ACeP唯一的生產商就是台灣的元太科技e-ink)

在ULANI選擇主題的頁面中，應該已經有套用了某種轉換，所以看起來的效果與電子紙呈現的相符。假使說我們用這個實測的顏色來做dither(抖色)的話，是不是就可以減少色差呢？個人遮疼的結果的確原理就這麼簡單，但是實作上也遇到了不少的問題並不簡單。(待續)

ULANI 電子紙桌曆的遮騰筆記 (2)

前面提到，Gallery Palette 是使用彩色粉體來顯示，但是每個像素一次只能顯示七個基本色中的一個，沒有中間過度的灰度色階。難道說這樣就只能顯示色塊了嗎？其實也不盡然。e-ink原廠將這個面板定位在電子標籤、宣傳標示... 等等的用途，除了色差之外，使用的驅動晶片也比較平價，沒有局部更新的方式，畫面全部更新需要約30秒，不建議用在全彩顯示的應用。

當然還是有一些 work around 的方式。像以前只有單色顯示的年代，灰階是可以靠網點(dither，對岸譯作「抖色」算是蠻生動)的方式來欺騙眼睛，用犧牲空間來模擬出灰階來。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

要看出dither的最好效果，得在眼睛分不太出網點的情況，也就是說兩個像素形成的視角，得在眼睛的解析極限之下。我們可以透過 瑞利角度分辨條件 (Rayleigh's criterion) 公式來簡單的推算一下：

sin(視角) = 1.22 波長 / 圓孔，考慮到人眼瞳孔大概是 1.5mm，7.3"電子紙的解析度127dpi，兩個像素的間隔大概是0.2mm，兩個像素形成的張角~0.2mm/觀測距離L

我們可以大致算出至少要距離 L = (0.2mm)(1.5mm)/(1.22*400nm) ~ 61.5cm

不過我實際看起來，大概要70-80公分以上，才比較看不出網點。這個除了環境光線影響瞳孔大小外，要組出接近的顏色也是要兩三個像素。理論值在這邊已經是相當接近了。

很可惜ULANI桌曆所提供的不同主題，都有共同的問題就是文字很小，再經過dither處理之後近看幾乎就是單一筆劃只有一個像素寬，要再拉到一公尺遠的話，就很難看的清楚了。尤其是年曆的部份，為了要塞進十二個月並沒有太大的空間，也因此有不少網友建議，改成週曆的型式會相對比較實用。

ULANI 電子紙桌曆的遮騰筆記 (1)

話說在幾個月前腦波弱，看到了國內募資網站上，出現了一個使用彩色電子紙的電子桌曆。(https://www.zeczec.com/projects/ulani)當時沒有多想，自認對電子紙產品還算熟悉，應該不至於有太大雷，於是覺得價位還可以就投了$$進去。

募資結束後，募得金額是預計的8xxx%，相當驚人。不過這也是考驗的開始，隨著預定出貨日的接近，我也開始擔心發起人會不會出不了貨，甚至捲款潛逃一走了之。還好在少許延遲之後，於預定出貨日兩週內收到商品。不過這也就是一整個遮騰的開始。

首先是這個電子桌曆的設計，用的是e-ink Gallery Palette 7.3吋的面板。根據網友提供的資料，跟對岸微x電子在販售的開發板是相同的硬體。微x電子提供的資料相當齊全，還有這塊面板的硬體規格書，在ULANI規格中沒有寫清楚的都可找到需要的資料。(https://www.waveshare.com/wiki/7.3inch_e-Paper_HAT_(F))

 

 首先是顏色跟解析度，Gallery Palette是採用ACeP的技術，藉由調控色粉在微杯(micro cup，當年併購sixpix來的技術)中的位置，來讓每個像素呈現需要的顏色，這裡是固定的紅橙黃綠藍黑白七個顏色跟Kaleido使用彩色濾光片(CFA)的作法不同。後者是傳統黑白電子紙16灰階技術，蓋上RGB三個顏色來達到4096色。而Gallery的每個像素都可以顯示七個顏色中的一種，優點是白色可以很白(反射率高達~70%，會是濾色片兩倍)，色彩也不需要為了提升反射率而使用降低飽和度的「淡彩」。但是因為是比較平價的控制晶片，只有全畫面刷新，還沒有灰階的能力。因此要表現出色階，就需要靠網點dither的方式，這個在硬體解析度只有 800x480 的情況下(127dpi，略遜於初代彩色噴墨印表機~150dpi)，基本就是一個硬傷。另一個注意的點是，更新畫面需要30秒。雖然原本就有預期會比較慢，ULANI很隱誨的寫說要「數十秒」，但是30秒=0.5分對物理人來說，就是分鐘的尺度了。也難怪公車站牌雖然開始有使用電子紙顯示，到目前還沒有看到有用彩色的。

 

 

參加 Salomon 玩跑俱樂部 攀登小百岳 大棟山賞桐花

剛好也是從某跑友那邊看到，就自己跳坑的活動。由樹林火車站後站出發，經過大同山、青龍嶺，到大棟山一等三角點折返，來回大約是12.5公里的距離，總爬升大約是600公尺，算是相當親民的健行路線。只是天氣實在是太熱了，大家都走得有點不要不要的。

路線跟照片就直接看relive的影片。

Relive 'Salomon 攀登小百岳 賞桐花'

       

然後是試鞋部份，我自己本來就是有一雙低階的短筒入門款，這次活動廠商提供了gotex的高階版本。大致心得整理在這邊：

• 抽繩式的綁帶是在單板內靴常用的設計，還蠻順手的
• 相對於傳統登山鞋較輕量，但仍然比跑鞋略重
• 前端有相當的保護，不怕踢到岩石
• 鞋底的緩衝力足，也有相當的減震效果，可以放心跨步落地，下坡也可以跑起來
• 大底刻劃的抓地力很足夠，即時大理石台階面也有一定抓地力
• 雖然偏登山鞋中低筒包覆性優良，不過跑起來也是有一定的彈性
• GTX有一定的透氣性，但是不能跟非防水鞋比，會略熱但不至於流汗，這次沒測到防水
• 覺得歐洲的鞋型相對比較適合亞洲人，我腳略寬穿bogoto的跑襪(厚襪)
• 新鞋的關係，鞋口與腳趾略有壓迫摩擦感(也許不該拉太緊)還好沒起水泡
• 外觀設計與顏色算是中規中矩，配色也是相當耐髒，無接縫設計可以避免摩擦

Garmin VivoActive HR

最近也入手了 Garmin Vivoactive HR，剛好就被背光的問題搞到。天氣熱了，只會在晚上出去跑步，自動背光怎麼都不會亮。研究了一下發現，如果設定了睡眠時間，在這段期間內就會自動變成 Do not disturb，抬手點亮背光的功能也會失效。所以有網友發現抬手不會亮，但是手放下會熄滅應該就是這個原因。
因為入手的是歐版，沒有中文字形只會出方塊。基本上通知的功能也就廢了。更好笑的是關閉通知的螢幕按鈕「清除」居然也是豆腐方塊字。 XD
至於睡眠偵測，就都不準，也不確定跟這個睡眠時間設定有沒有關係。所以這塊就還是交給Pebble了，GARMIN加油...

My Zaurus...

有效減少 Firefox 瀏覽器的磁碟寫入量

自從上次 Acer REVO 小主機的硬碟壞掉，就臨時拿了個隨身碟當作硬碟使用。雖然使用上少了傳統硬碟的發熱跟噪音，但是跟 SSD 比起來，寫入速度還是相當的杯具。很明顯的，一起動 Firefox 就有很明顯的頓挫感。當然，Ubuntu 上 SSD 相關的最佳化都用上了，主要的問題，在執行 iotop 之後就明瞭了：Firefox 每分鐘會寫入數十 MB 的資料。

經過一陣子 google 之後，知道問題是出在 crash recovery 的紀錄，竟然預設每 15 秒會回寫一次。再加上我習慣同時開的 tab 數量很大，每次都有幾 MB 的紀錄。如果有使用 session-saver 這個 addon，使用的也是同一個參數：browser.sessionstore.interval。個人可以視自己對瀏覽記錄損失的容忍度來調整這個參數，甚至不需要的話可以完全關閉。

Since the hard drive of my small form-factor desktop crashed, I'm using a flash USB drive as the storage. The is similar to people using SSD nowadays, but with a slower performance and lower price.

The same issues arise, the disk writes are lethal as the flash blocks have limited lifetime. One should move all disk caches to ram drives. Under linux, you can easily done with tmpfs:

tmpfs           1.6G  197M  1.4G  13% /tmp

tmpfs           316M  364K  315M   1% /run

tmpfs           1.6G  676K  1.6G   1% /var/log

tmpfs           2.0G   36K  2.0G   1% /var/tmp

One can move the cache directory to tmpfs:

key	value
browser.cache.memory.enable	false
browser.cache.offline.enable	false
browser.cache.disk.enable	true
browser.cache.disk.capacity	262144
browser.cache.disk.parent_directory	/dev/shm/firefox

Another one is the browser that I would use heavily on this machine. People notice that Firefox could cause huge writes due to the crash recovery:

http://superuser.com/questions/399473/firefox-writes-megabytes-of-data-per-minute-to-disk-why

The frequency of backing up session can be tuned:

key	value
browser.sessionstore.interval	30000

For people do not want to use crash recovery at all, he or she can set:

key	value
browser.sessionstore.enabled	false