圖片無損壓縮下的演算法比較

Hacker News 上看到「What’s the best lossless image format? Comparing PNG, WebP, AVIF, and JPEG XL」這篇,在講圖片的無損壓縮演算法。在 Hacker News 上的討論也可以看看:「What’s the best lossless image format? (siipo.la)」。

文章有點舊 (2021 年七月),但應該還行... 另外作者看起來是以 service bandwidth 考量為主,在這種情境下,自然圖片一般都會以非無損的方式提供 (像是 JPEG),而人造圖片則是以無損的方式提供 (像是 PNG),所以在這邊討論無損的時候會以人造圖片的 dataset 來挑選,於是作者是跑去 Dribbble 上翻圖片當 dataset:

What I ended up with was downloading a set of images from Dribbble, a portfolio site for designers.

最後的結果就是:

考慮到目前各家瀏覽器的支援性,可以看到 Lossless WebP 其實是個很好的選擇,檔案算蠻小的,而且 Apple ecosystem 的支援性也已經出來了:

如果不用考慮到瀏覽器的話,JPEG XL 也可以考慮,不過本來宣稱 royalty-free 的部份蒙上了陰影:「Alarm raised after Microsoft wins data-encoding patent」,用的人反而要注意到 patent 問題...

V7Labs 提供的 Chrome Extension,偵測圖片是否為人工智慧生成的

寫完上一篇「可以看 Chrome Extension 程式碼的 Chrome extension source viewer」後就可以來提「Fake Profile Detector tells you if people are real or fake online」這個了,文章裡面在介紹 V7Labs 所提供的 Chrome Extension:「Fake Profile Detector (Deepfake, GAN)」。

從套件的名字可以看出來他主要是偵測 GAN (Generative adversarial network) 類的類神經網路,這點在套件裡面說明也可以看到:

Right-click on a profile picture, our model will detect if that image contains a GAN generated or real person!

實際上測試時要注意要儘量抓夠大的圖片丟進去測,像是 Generative adversarial network 維基百科這頁裡面「Concerns about malicious applications」這個章節右邊兩張 GAN 生成的圖,如果你用維基百科預設的縮圖大小 (220x220),上面這張會猜測是真人,下面那張會猜測是假人。

但如果到大一點的圖 (600x600) 的話就都會猜測是假人:「File:Woman 1.jpg」、「File:GAN deepfake white girl.jpg」,原圖 1024x1024 的話也可以偵測出來。

然後 source code 就在那邊可以看 API 怎麼打,大家可以自己研究...

Apple 對 PNG 解碼的 bug

前幾天的 Hacker News Daily 上看到「PNG Parser Differential」這個,對應的討論在「PNG Parser Differential (vidbuchanan.co.uk)」這邊可以看到。

作者想要利用 threading 加速處理 PNG 格式,結果寫出了 bug,但意外發現 Apple 的 PNG decoder 也犯了一樣的問題:「Ambiguous Decodes #3」。

作者做了一個特別的 PNG 放在網站上,在非 Safari 的情況下會是:

而拿 iPhone 的 Safari 讀的話,可以看到:

應該是 implementation bug,還蠻有趣的 bug...

QOI 圖片無損壓縮演算法

Hacker News Daily 上看到「Lossless Image Compression in O(n) Time」這篇,作者丟出了一個圖片的無損壓縮演算法,壓縮與解壓縮的速度超快,但壓縮率又不輸 PNG 太多,在 Hacker News 上的討論也可以看一下:「QOI: Lossless Image Compression in O(n) Time (phoboslab.org)」。

裡面有提到在遊戲產業常用到的 stb_image.h

Yes, stb_image saved us all from the pains of dealing with libpng and is therefore used in countless games and apps. A while ago I aimed to do the same for video with pl_mpeg, with some success.

作者的簡介也可以看到他的主業也在遊戲這塊:

My name is Dominic Szablewski. I build games, experiment with JavaScript and occasionally tinker with low-level C.

圖片的無損壓縮與解壓縮算是遊戲創作者蠻常用到的功能,所以他想要看看這塊有沒有機會有更好的工具,於是他就用了四個很簡單的演算法幹完了 QOI (然後發現效果很讚):

  • A run of the previous pixel
  • An index into a previously seen pixel
  • The difference to the previous pixel
  • Full rgba values

其實從 Hacker News 的討論也可以看到這組演算法也常被拿出來在現代的壓縮演算法使用,所以雖然作者自稱不是 compression guy,但他用的演算法其實蠻專業的...

然後挑 single thread 主要是可以避免 threading 的複雜度以及 overhead,在「QOI Benchmark Results」這頁可以看到,無論是什麼類型的檔案,壓縮與解壓縮的速度都相當漂亮,而且壓縮率又沒有差 libpng 太多。

而且作者自己有提到,還沒用到 SIMD 指令集加速,這樣猜測應該還有不少空間...

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.

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

產生模糊縮圖的 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 與類神經網路放大圖片

在「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 很快?

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

Flickr 限縮免費帳號的容量

Flickr 在今年四月的時候放出消息被 SmugMug 收購後 (參考先前的文章「SmugMug 買下 Flickr」),過了半年總算是有新的動作了,跟 SmugMug 完全走使用者付費的想法類似,這次將免費帳號的容量大幅限縮,從本來的 1TB 空間變成 1000 張照片,在 2019/01/08 將會生效:「Why we’re changing Flickr free accounts」。

Beginning January 8, 2019, Free accounts will be limited to 1,000 photos and videos. If you need unlimited storage, you’ll need to upgrade to Flickr Pro.

現在點進去看 Flickr Pro 的費用是 USD$35/year。我在 2005 年以 USD$59.95/year 買過當時的 Flickr Pro... 特別有印象是因為剛好是宣佈被 Yahoo! 收購的前幾天買的訂閱,在被收購後 Flickr 宣佈降價,而先前買的人直接多一年。

參考當年的「http://www.flickr.com/help.gne」頁面):

We are currently offering an introductory Pro Account special -- Buy yourself (or a friend) an annual Pro Account for US$41.77 and save yourself around 30% from the anticipated annual price of $59.95. That's less than $3.50 a month!

不過現在好像也用不到這個平台了... 反正都公開的資料,也許資料拉一拉丟到其他地方吧,或是想看看要怎麼放。

SmugMug 買下 Flickr

SmugMug 買下 Flickr,這應該算是好消息 (吧):「Exclusive: Flickr bought by SmugMug, which vows to revitalize the photo service」。

雙方的新聞稿是:「SmugMug acquires Flickr: Two passionate communities together at last.」與「Together is where photographers belong!」。

時代的眼淚啊... 還在交大的時候買了 Pro,後來被併進 Y! 後沒續約了。丟著直到 Instagram 可以同步上去時又有更新,然後 Instagram 停止分享到 Flickr 的功能後又改找 IFTTT 同步。

而本來做 Flickr 的那群人後來跑去做 Slack... (包括 Stewart ButterfieldCal Henderson XD)

來看看後續會有什麼改變... 第一波應該是帳號系統的轉移?然後再來是 pricing model 的改變?

Seam Carving (接縫裁剪)

看到有人實做 Seam Carving (接縫裁剪) 了,用 Golang 寫的,放在 GitHubesimov/caire 這邊,副標題「Content aware image resize library」。實做了「Seam Carving for Content-Aware Image Resizing」這篇論文。

Seam Carving 指的是知道內容的 resize,像是把上面這張變成下面這張:

或是變大:

馬上可以想到的應用是需要保留資訊內容,但又想要大量提供資訊的地方,像是 Nuzzle 的縮圖 (或是以前的 Zite),或是網路新聞媒體的首頁所用的縮圖。不知道還有沒有其他地方可以用...