可以自己調整的黑白照片上色服務

Hacker News Daily 上看到 Palette 這個服務,作者在 Hacker News 上有提到你可以提供一些句子調整顏色:「Show HN: I made a new AI colorizer (palette.fm)」。

Hi HN, I’m Emil, the maker behind Palette. I’ve been tinkering with AI and colorization for about five years. This is my latest colorization model. It’s a text-based AI colorizer, so you can edit the colorizations with natural language. To make it easier to use, I also automatically create captions and generate filters.

作者有把一些作品貼在 Reddit 上面,可以參考 https://www.reddit.com/user/emilwallner/?sort=top 這邊,看起來已經有一陣子了...

在圖片裡面放入圖片本身的 MD5 值

Hacker News Daily 上看到「The image in this post displays its own MD5 hash (retr0.id)」這篇,作者想要產生一張 PNG 圖,這張圖的 MD5 值就在圖片上呈現。然後作者本人有出現在 Hacker News 討論串上面,提到流量撐不住,所以丟到 Twitter 上面 (而很幸運的,Twitter 沒有壓這張圖,是保留原圖,所以可以驗證 MD5):

另外一個有趣的主題是同時撞出一樣的 MD5 與 CRC32 的方式,其中 CRC32 的部份還可以直接指定值,在「MD5 Collision with CRC32 Preimage (gist.github.com)」這邊。

算是很趣味的玩法啦,畢竟 MD5 已經被大家知道是個 broken cryptographic hash function...

這兩個禮拜爆紅的 Stable Diffusion

Stable DiffusionStability AI 訓練出來的 model,跟之前提到的 DALL-E 最大的差異就是產生出的圖的限制少很多:

Unlike competing models like DALL-E, Stable Diffusion is open source and does not artificially limit the images it produces, though the license prohibits certain harmful use cases.

這也造就了這兩個禮拜整個 Stable Diffusion 的各種應用急速成長。

Simon Willison 的「Stable Diffusion is a really big deal」這篇來當作總覽還不錯。

除了授權使用上的限制以外,在技術上的限制也比較少 (有很大一部分會歸功於社群的各種 porting),包括了:

除了先前大家已經熟悉的 txt2img 功能以外,Stable Diffusion 另外提供了 img2img 的能力,也就是先給一張圖,然後再給對應的句子要求 Stable Diffusion 去改這張圖,所以就會有像是把這張圖:

加上「A distant futuristic city full of tall buildings inside a huge transparent glass dome, In the middle of a barren desert full of large dunes, Sun rays, Artstation, Dark sky full of stars with a shiny sun, Massive scale, Fog, Highly detailed, Cinematic, Colorful」的句子後,提供了這張圖:

以及這張圖:

這樣可玩性又多了不少...

用 DALL·E 2 的圖當作網誌文章的圖片

Hacker News 上看到「I replaced all our blog thumbnails using DALL·E 2 (deephaven.io)」這個點子,原文在「I replaced all our blog thumbnails using DALL·E 2 for $45: here’s what I learned」這邊。

網誌文章如果包含好的圖片時,曝光度與互動都會比較多。所以作者就想到用 OpenAIDALL·E 2 來搞事了:給個描述,請 DALL·E 2 生成圖片。

文章裡面有很多產生出來的圖都蠻有趣的,像是「a cute blue colored gopher with blue fur programming on multiple monitors displaying many spreadsheets, digital art」這個描述生出來的圖:

不過不算便宜,他花了 US$45 生成大約一百篇文章的圖:

I spent the weekend and $45 in OpenAi credits generating new thumbnails that better represent the content of all 100+ posts from our blog.

如果用先前「玩玩文字轉圖片的 min(DALL·E)」這邊提到的方法自己搞不知道可不可行?

玩玩文字轉圖片的 min(DALL·E)

幾個禮拜前看到「Show HN: I stripped DALL·E Mini to its bare essentials and converted it to Torch (github.com/kuprel)」這個東西,有訓練好的 model 可以直接玩文字轉圖片,GitHub 專案在「min(DALL·E) is a fast, minimal port of DALL·E Mini to PyTorch」這邊可以取得。

因為這是包裝過的版本,裝起來 & 跑起來都很簡單,但沒想到桌機的 1080 Ti 還是跑不動,只能用 CPU 硬扛了,速度上當然是比官網上面列出來用 GPU 的那些慢很多,但至少能跑起來玩看看。

首先是拿官方的句子來玩看看,第一次跑會需要下載 model (會放到我們指定的 pretrained 目錄下):

#!/usr/bin/env python3

from min_dalle import MinDalle
import torch

model = MinDalle(
    models_root='./pretrained',
    dtype=torch.float32,
    device='cpu',
    is_mega=True,
    is_reusable=False,
)

images = model.generate_image(
    text='Nuclear explosion broccoli',
    seed=-1,
    grid_size=2,
    is_seamless=False,
    temperature=1,
    top_k=256,
    supercondition_factor=32,
    is_verbose=False,
)

images = images.save('test.png')

我自己在下載過後,跑每個生成大概都需要十分鐘左右 (參數就像上面列的,CPU 是 AMD 的 5800X,定頻跑在 4.5GHz),出來的結果是這樣:

接著是一些比較普通的描述,這是 sleeping fat cats

然後來測試看看一些比較偏門的詞,像是 Lolicon,這個就差蠻多了:

但感覺有蠻多應用可以掛上去,這樣有點想買張 3090 了...

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

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.

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