安排路線的服務 Trail Router

Hacker News Daily 上看到的有趣服務,給起點與終點,以及想要有的長度,可以幫你拉一條差不多長度的路徑出來,可以提供給慢跑或是騎腳踏車的人規劃路線:「Trail Router」。

然後發現原來公司對面有 YouBike 站點... XD

這個服務的作者有在 Hacker News 上接受大家的詢問,可以到 Hacker News 上討論的頁面看一下作者的回應:「Show HN: Trail Router – generate running routes that prefer greenery and nature (trailrouter.com)」。

另外值得一提的是,這個服務用了 Mapbox 的圖資 (跟 OpenStreetMap 有關),看起來台北地區的呈現已經遠超過以前「堪用」的程度了,以後如果有需要用到的話可以考慮看看,就不一定要綁在 Google Maps 上了...

WebP 的檔案大小未必比 JPEG 小...

在「Is WebP really better than JPEG?」這邊發現在差不多的條件需求下,WebP 壓出來的檔案大小未必會比 JPEG 小。

先講結論:提供服務的人可以先確認自家的 JPEG 壓縮是不是有先用 MozJPEG (壓縮率更好),然後再考慮要不要支援 WebP。

Google 在推 WebP 這個格式的時候,宣稱失真壓縮的部份可以比 JPEG 小 25%~34%:(出自「A new image format for the Web」)

WebP lossless images are 26% smaller in size compared to PNGs. WebP lossy images are 25-34% smaller than comparable JPEG images at equivalent SSIM quality index.

但作者發現 Google 之所以可以達到 25%~34% 這個數字,是因為比較的對象是 Independent JPEG Group 所釋出的 cjpeg,而如果拿 MozJPEG 相比的話應該得不到這個結果,另外也把 AV1 的 AVIF 拉進來一起測試了:

I think Google’s result of 25-34% smaller files is mostly caused by the fact that they compared their WebP encoder to the JPEG reference implementation, Independent JPEG Group’s cjpeg, not Mozilla’s improved MozJPEG encoder. I decided to run some tests to see how cjpeg, MozJPEG and WebP compare. I also tested the new AVIF format, based on the open AV1 video codec. AVIF support is already in Firefox behind a flag and should be coming soon to Chrome if this ticket is to be believed.

這邊作者測試用的圖集是 Kodak Lossless True Color Image Suite,測試的結果發現 WebP 的確比 libjpeg (cjpeg) 好一些,但沒有像 Google 講的那麼多 (這邊就不知道是不是現在的 libjpeg 又有改善),而 WebP 與 MozJPEG 相比的話就沒有明顯優勢了:

WebP seems to have about 10% better compression compared to libjpeg in most cases, except with 1500px images where the compression is about equal.

However, when compared to MozJPEG, WebP only performs better with small 500px images. With other image sizes the compression is equal or worse.

I think MozJPEG is the clear winner here with consistently about 10% better compression than libjpeg.

另外也提到了 AVIF 的壓縮率很好,不過要注意演算法會把非重點部位的細節吃掉:

I think AVIF is a really exciting development and compared to WebP it seems like a true next-generation codec with about 30% better compression ratio compared to libjpeg. Only concern I have is the excessive blurring of low detail areas. It remains to be seen if this can be improved when more advanced tooling becomes available.

對網頁的應用來說,WebP 另外一個痛點是在 Safari 上的支援度,在 caniuse.com 的「WebP image format」這邊可以看到目前各瀏覽器都支援了,就剩下 Safari 還不支援,所以目前在 iOS 上得降回 JPEG:

不過這點之後也改變了,在 iOS 14 beta 裡的 Safari 可以看到支援 WebP 了:「Safari 14 Beta Release Notes」。

Media
New Features
Added WebP image support.

所以這個狀況變得有點微妙了...

tw.bbs.* 的轉信

看到 gugod 最近在玩 Usenet:「玩 Usenet Newsgroup」,把 tw.bbs.talk 的 innbbsd 設定給設起來,結果發現 subject 的部份 innbbsd 有把 UTF-8 轉成 BIG5 (記得是因為標題用 MIME-B 很普及,所以很早就支援了),但內文就沒有轉碼了,也許得 patch innbbsd 讓他過 iconv 轉碼?

spam 的部份如同 gugod 提到的也少很多了,看起來是個老人聊天的好地方...

另外在 debug 過程中因為直接讀 header & body,看到了 Cancel-Lock 這個 header,查了一下發現是個 2018 年通過的新標準 (RFC 8315):「Cancel-Locks in Netnews Articles」,不過從維基百科的說明,看起來沒有什麼人支援:

Cancel-lock is much simpler, but neither commonly accepted, nor implemented in popular news servers and newsreaders.

可能會先用其他方式去聊天 (tin?),長期的話再來看看要怎麼搭...

嘲笑某些大公司的技術文章...

看到「Why we at $FAMOUS_COMPANY Switched to $HYPED_TECHNOLOGY」這篇,建議一定要搭著看 Hacker News 上的各種評論 (或者叫做「導讀」):「We at $Famous_company switched to $Hyped_technology (saagarjha.com)」。

在「導讀」裡面的馬上就看到三篇文章,然後也有一些討論:

另外討論裡面還有用到大量的 $VARIABLE 在嗆來嗆去,還被拿來反諷 Hacker News 上的各種 comments XD

原作者提到的這些技術文章大多都是 workaround,代表只有在很特定的情況下帶來的優點會大於缺點。

這些大公司會選擇某種 workaround 通常跟他公司內的政治因素有關,但在這些文章裡面都不會描述出來 (無論是作者不知道,或者知道但不能寫)。在沒有說明「為什麼會這樣 workaround」的前提下,其實文章看過、知道技術上有這種解法就好。

而且在實務上,除非你處理的資料量有一定的規模 (通常是在這些大公司內),不然一般人手上的資料量,以現在硬體的發展情勢,「暴力」其實可以解決很多問題。

整個產業透過雲端改變了不少以前的思維:這是個可以在 AWS 上租 x1e.32xlarge 把資料全部放到記憶體裡面 random access (128 vCPU + 3904 GB RAM),就算是寫爛的 O(n^2) 演算法,先開個幾千台 EC2 instance 撐著,再花時間慢慢解。

這跟以前自己弄硬體的思維跟雲端的思維玩法不一樣,「等產品衝起來再說」(或者說「活下去再還技術債」) 的可行性變得更高。

AWS Elemental Link:直接把影音訊號丟到雲端的硬體

AWS 推出了 Live 用的硬體設備 AWS Elemental Link,可以直接將影音訊號轉完後丟到 AWS 自家的 AWS Elemental MediaLive 服務上:「New – AWS Elemental Link – Deliver Live Video to the Cloud for Events & Streams」。

機器很輕 (450g) 也不大 (32 立方英呎,大約 524 立方公分):

界面上吃 Live 領域常用的 SDI (3G-SDI) 或是 HDMI,規格上只能轉 1080p60 (剛好也是 3G-SDI 的上限),然後設備除了透過一般電力供電以外,也可以用 PoE 供電,可以少接一條電源線:

Link takes a single video input as a source and sends a single video output up to 1080p 60fps to AWS Elemental MediaLive. Set up requires three connections to begin streaming video to MediaLive: a power source, an IP network, and a 3G-SDI or an HDMI video source. Link also supports Power over Ethernet (PoE) so you can use as few as two cables.

價位上是賣 USD$995,但對於有 SDI 類的設備價錢不熟。看了一下旁邊棚子 Blackmagic Design 的產品,好像沒看到類似可以直接送到網路服務的產品...

用事實查核中心的 RSS feed 加上 IFTTT 自動通知到 Line/Telegram/... 內

事實查核中心的澄清內容其實很有趣,可以看到有哪些假消息在流傳,所以想找找看有沒有比較簡單的方法可以設通知...

事實查核中心的官網用的是 netiCRM 這個平台 (看起來底層是 Drupal),而在 HTML 頁面的開頭可以看到 RSS 1.0 的 xmlns 宣告:

  xmlns:content="http://purl.org/rss/1.0/modules/content/"

本來想說直接用 feed 接到 IFTTT 就好了,不過 HTML 頁面上沒有放 feed entry 讓閱讀器可以直接找到 feed 本身,也就是像這樣的標籤資訊:

<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Feed" href="https://blog.gslin.org/feed/" />
<link rel="alternate" type="application/rss+xml" title="Gea-Suan Lin&#039;s BLOG &raquo; Comments Feed" href="https://blog.gslin.org/comments/feed/" />

找了一下 Drupal 的設定慣例,發現 feed 可能會放在 /rss.xml 這個位置,測了一下發現順利在 https://tfc-taiwan.org.tw/rss.xml 這邊看到 feed,接下來就可以加進 IFTTT 了:

給有興趣想要用 feed 做些事情的人參考看看,像是加到 Line 或是 Telegram 的群組裡面,或是放到 Slack channel 裡面 (Slack 裡應該可以直接在某個 channel 裡用 /feed add https://tfc-taiwan.org.tw/rss.xml 把這個 feed 加進去)。

產生模糊縮圖的 BlurHash

先從一張圖片算出大約 20~30 bytes 的字串,就可以在 API response 時快速產生出一個很模糊但是有有代表性的縮圖 (或是在 HTML 裡面放,用 javascript 產生):「BlurHash」。

從官方給的範例比較快理解:

以及:

另外也提供了展現在 app 上的效果:

有支援一些程式語言,不過看起來行動平台上的支援都是比較新的語言 (Swift & Kotlin),如果不是用這些語言而想用 BlurHash 的話就得自己整了...

另外在 Hacker News 上有翻到先前的討論:「BlurHash: Algorithm to generate compact representation of an image placeholder」,開頭就看到其他軟體的作法:

For comparison, Instagram sends ~200 byte base64 thumbnails in its API responses. It's a low-res JPEG with a fixed header to save a bit more space. This is also used to blur sensitive images. You can get even better results with webp.

這個方法就避開另外再弄一包 library 進去,用現成的 library 就會動了...

在 EC2 上面跑 Lizzie + KataGo

我用 Packer 包了一個將 Lizzie (界面) + KataGo (引擎) 打包成 Amazon EC2 AMI 的設定:「packer-katago」。

這個組合應該是目前圍棋棋手最常拿來分析棋譜的工具,與之前常用的 Lizzie + Leela Zero 的差異在於 KataGo 可以分析勝率與目數,而 Leela Zero 則只能分析勝率。(參考之前寫的「用更少訓練時間的 KataGo」這篇)

早期的 KataGo 強度還沒有很強,一般還是會與 Leela Zero 交叉換著分析,但最近幾個版本的強度比之前好很多,目前看起來已經超過 Leela Zero 了 (可以參考 CGOS Whole Period Ratings for 19x19 Board 這邊列出來的排名),另外就 YouTube 上看起來,蠻多棋手應該都是改用 KataGo 了...

不過不管是 Leela Zero 還是 KataGo 都需要夠強的 GPU 運算,之前就算用 GTX 1080 Ti 也還是覺得不夠快,就丟到 AWS 上面用看看,順便練一下手,熟悉 Packer 怎麼用。

我是設計成用 IceWM + VNC,連進去後左下的選單裡面就會有 Lizzie 可以選:

第一次跑起來會比較久,我在 p3.2xlarge 的機器上大約要等個三四分鐘,然後就會出現數字了:

看了一下運算的速度還不錯,用 spot instance 開的話,成本上應該還可以接受 (剛剛的 p3.2xlarge 是 USD$0.918/hr)。

用 OpenCV 處理 webcam 的背景,再用 pyfakewebcam 接回給視訊軟體用...

最近武漢肺炎的關係,導致蠻多人會在家裡使用視訊會議,但背景一直是個問題... 然後就看到這篇文章:「Open Source Virtual Background」。

作者用 python-opencv 先處理 webcam 進來的影像 (看起來不只去背,還加上了 hologram 的效果 XDDD),然後再用 pyfakewebcamv4l2loopback 模擬成一個 webcam 餵回給視訊軟體,結果就惡搞成這樣了:

話說回來,最近各電商平台的 webcam 與視訊機都缺貨,還好之前有買個便宜的頂著,不然就得開筆電了...