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.

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

原來 Fully Homomorphic Encryption 已經被解啦...

Hacker News Daily 上看到「IBM Releases Fully Homomorphic Encryption Toolkit for MacOS and iOS; Linux and Android Coming Soon」這個消息,主要是 IBM Research 要放出一些跟 Fully Homomorphic Encryption (FHE) 的 library。

Homomorphic encryption 講的是直接對密文操作:(這邊的 \cdot 是操作,可能是加法,也可能是乘法,或是其他類型)

C_1 = enc(P_1)
C_2 = enc(P_2)

enc(P_1 \cdot P_2) = enc(P_1) \cdot enc(P_2) = C_1 \cdot C_2

也就是說,不需要把 Ciphertext 解成 Plaintext 處理完後再加密回去 (這有安全性與隱私的問題),而是直接對兩個 Ciphertext 計算就可以了。

之前還在學校學密碼學的時候 (大概 2005 與 2006),有翻到 Homomorphic encryption 中的 Fully Homomorphic Encryption (FHE) 是尚未被解決的問題,當時的解法都是特殊解。

剛剛因為看到上面那篇文章,查了一下發現原來在 2009 的時候 Craig Gentry 提出了一套方法,用 Lattice-based cryptogtaphy 建構出加法與乘法的操作,也就達成了 FHE 的低標。

查資料的時候發現 1) 他論文只用了十頁 2) 這是他的博班論文,解掉這個 open problem,不過看到他的博班指導教授是 Dan Boneh 好像不意外... XD

(雖然只用了十頁主要還是因為 STOC 篇幅的關係,但扣掉 circuit privacy 的部份,前面在說明建構與證明的過程只用了九頁也是很驚人)

然後接下來的幾年他又跟其他幾位學者改進了不少效能上的問題,在英文版維基百科上可以翻到有好幾個不同世代的 FHE。

PHP 8 將會移除 XML-RPC,改放到 PECL 內

Twitter 上看到「PHP RFC: Unbundle ext/xmlrpc」這則消息,PHP 官方打算把 XML-RPC (也就是 git repository 裡面的 ext/xmlrpc) 拆出去,移到 PECL

Unbundle ext/xmlrpc (i.e. move it to PECL) without any explicit deprecation.

主要的考慮是在於目前的 library 已經年久失修:

ext/xmlrpc relies on on libxmlrpc-epi, which is abandoned. Even worse, we are bundling a modified 0.51, while the latest version is 0.54.1. This is exacerbated by the fact that the system library is usually built against libexpat, but the bundled library is likely to be built against libxml2 using our compatibility layer.

另外應該也是因為 XML-RPC 用的人不多吧,投票是沒什麼玄念的 50:0,而且在 Packagist 上面也可以翻到一些用 PHP 實做的替代品,拿 xmlrpc 這個關鍵字搜了一下可以看到一些...

Microsoft 推出的 React Native for Windows + Mac

看到「React Native for Windows + Mac」這個,微軟推出了自己的 porting,以桌面環境的 Windows 與 macOS 為主,另外因為 Windows 10 的關係,也順便把平板與 Xbox 拉進來:

React Native for Windows + Mac brings React Native support for the Windows 10 SDK as well as the MacOS 10.12 SDK. With this, you can use Javascript to build native Windows apps for all devices supported by Windows 10 including PCs, tablets, 2-in-1s, Xbox, Mixed reality devices, etc., as well as the MacOS desktop and laptop ecosystems.

macOS 的 10.12 是 macOS Sierra,已經是 unsupported 的版本 (到 2019 年九月),所以目前蘋果官方有支援的作業系統都有在這包的範圍內。

Windows 10 SDK 的部份就不知道現在還有在支援的 Windows 8.1 能不能裝了。(看「Windows 10 SDK」這頁有列出 Win32 程式可以,但就不知道這次這包是不是用 UWP 技術...)

本來 javascript 開發 desktop 程式比較常見的是 GitHub 放出來的 Electron,現在等於是微軟多提供了一個選項讓...

PHP 8 的提案,將 JSON library 放入必須項目

Twitter 上看到的通知,這個提案將 PHPJSON 列為語言的必須項目,目前的狀態是 Under Discussion:「PHP RFC: Always available JSON extension」。

以前沒有引入的一個原因是因為底層使用的 library 的授權 JSON license 不是 open-source license,這對於要打包出 binary 散佈時的問題很大 (跟其他 license 衝突):

The Software shall be used for Good, not Evil.

在 PHP 7 之後,JSON 的實做決定改用 jsond (參考「PHP RFC: Replacing current json extension with jsond」),這邊用的是 PHP License 授權:「LICENSE」,這個因素就緩解了。

而這個提案提議拔掉 ./configure –-disable-json 關閉 JSON library 的能力,把 JSON library 變成 PHP language 的一部份:

Make it impossible to disable the JSON extension through configuration or build options. Require that JSON be built statically instead of as a shared library.

這個提案如果通過的話,對大多數人應該還是沒什麼影響,因為一般在用的版本都會裝 JSON library。而且現在會透過 Composor 管理套件,很容易就會有 dependency 會用到 JSON 而需要安裝 JSON library,問題不太大...

產生模糊縮圖的 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 就會動了...

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

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

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

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

jQuery 3.5.0 的修正,補 XSS 漏洞

這次 jQuery 3.5.0 修正了一個安全性漏洞:「jQuery 3.5.0 Released!」,不過實測了一下,不完全算是 jQuery 的自己出的問題,比較像是幫使用者擦屁股。

jQuery 的說明如果看不懂,可以交叉參考「XSS Game」這篇的說明,搜尋 htmlPrefilter 應該就可以看到了。

這次修正的函數是被 html() 用到的 htmlPrefilter(),這個函數會在 3.5.0 之前會把 <tag/> 這樣的元素轉成 <tag></tag>,而 3.5.0 之後會保留本來的形式。

利用這個特性,就可以用這樣的字串來打穿 WAF:

<style><style/><script>alert(1)<\/script>

原因是 WAF 在看到時會以為 <script><style> 內部的 data 而認為不是 XSS 攻擊而穿過 WAF 的檢查,但實際上被 jQuery 展開後變成:

<style><style></style><script>alert(1)<\/script>

而最前面的 <style><style></style> 被當作是一包,後面的 <script> 就成功被拉出來執行了。

這是相同程式碼使用 jQuery 3.4.1 與 jQuery 3.5.0 的差異,我把 alert(1) 改成 document.write(1),比較容易在 JSFiddle 上看出差異:

不過回過來分析,會發現一開始用 html() 才是問題的起點,要修正問題應該要從這邊下手,而不是用 WAF 擋...

Bootstrap v5 將會拔掉對 IE 的支援

如同標題所說的,Bootstrap 打算拔掉對 IE 的支援,在 GitHub 上的 Pull Request:「v5: drop Internet Explorer support」。

當然下面可以看到有反對意見,不過基本上還是尊重 Bootstrap 團隊做的決定,另外一方面也是現在的選擇多了很多,市場自由競爭總是會看出結果的。

測了一下先前提到的「MVP.css」,本來以為只做 semantic html 的設計,純 css 應該是有機會往下支援到蠻早的版本,結果拿 IE11 一開官網,看起來還是不少東西掛掉了 XD

看起來還得再找找... 也許繼續龜在 v4?

用 OpenCV 與類神經網路放大圖片

在「Deep Learning based Super Resolution with OpenCV」這邊看到 OpenCV 支援這些類神經網路的演算法了,而且有預先訓練好的模型資料可以下載來用。

傳統放大的方法包括 bicubic 與 nearest neighbor,速度很快但是效果就普普通通,而 NN 類的方法的效果遠超過傳統方式,不過速度慢不少。

文章裡面有提到可以指定不同的 NN 模型:

The first parameter is the name of the model. You can choose between: “edsr”, “fsrcnn”, “lapsrn”, “espcn”. It is very important that this model is the correct one for the model you specified in ‘sr.readModel()’. See the Model section on the bottom of the page for the specifications of each model.

拿這些模型名字搜了一下資料,在「Super-resolution benchmarking」這邊可以看到比較,主要是在講 EDSR 很棒,然後 ESPCN 很快?

不過看起來可以直接拿來用在不少地方了...