把文字檔壓成 PNG 跟 Gzip 比較壓縮率

Hacker News 上看到「Compressing Text into Images (shkspr.mobi)」這個奇怪的方法,是把文字轉成灰階的 PNG 檔案,然後跟 ZIP 比較壓縮率,居然是能打的。原文則是在「Compressing Text into Images」這邊。

這是屬於週末奇怪的 side project,作者也覺得這樣很白爛 XDDD

(This is, I think, a silly idea. But sometimes the silliest things lead to unexpected results.)

作者是拿羅密歐與茱麗葉的小說當資料 (Romeo and Juliet),這可以在 Project Gutenberg 的網站上下載到 txt 檔案。

基本的想法是把每個文字轉成灰階圖片的像素,然後用 PNG 無損輸出,最後再用 Squoosh 處理:

The English language and its punctuation are not very complicated, so the play only contains 77 unique symbols. The ASCII value of each character spans from 0 - 127. So let's create a greyscale image which each pixel has the same greyness as the ASCII value of the character.

結果居然是跟一般的壓縮軟體差不多:

That's down to 55KB! About 40% of the size of the original file. It is slightly smaller than ZIP, and about 9 bytes larger than Brotli compression.

我試著驗證作者的想法,用 Go 寫了個小程式輸出操作圖片,產稱一張寬度是小說的 byte 數,高度只有 1 的 PNG 檔輸出,最後再用 pngcrush 處理:「gslin/text-to-image-compression」。

另外我是與 gzip 比較 (原作者是與 ZIP 比較),結果是:

PNG: 64379
Gzip: 64563
Gzip (-9): 64331

的確是差不多的等級?

很多 MTurk 的接案者都用 LLM 在解決文字類的問題

剛剛在 Hacker News 上翻到的:「33-46% of workers on MTurk used LLMs in a text production task (arxiv.org)」,論文在「Artificial Artificial Artificial Intelligence: Crowd Workers Widely Use Large Language Models for Text Production Tasks」這邊,這個標題取的很故意... XD

Hacker News 上的標題主要是出自論文 abstract 的這段:

We reran an abstract summarization task from the literature on Amazon Mechanical Turk and, through a combination of keystroke detection and synthetic text classification, estimate that 33-46% of crowd workers used LLMs when completing the task.

想想還蠻正常的?能輕鬆賺當然就輕鬆賺... 但這也代表開發者可以思考 offload 給 LLM 的品質,以及如果需要外部的工人智慧,是不是可以搭配 LLM 再 offload 一些簡單的處理給人類就好?

話說好久沒聽到 MTurk 這個服務了,翻了 wiki 看起來是 2005 年就有的服務。

用 Automerge 處理 CRDT 問題

上個月看到 Automerge 出了 2.0 版的消息:「Automerge 2.0」,Automerge 這個套件可以幫你處理複雜的 CRDT 結構 (Conflict-free replicated data type)。

可以看到 Automerge 在 2.0 之後的效能改善不少,可以跟 yjs 比較了:

所以練了一下手測界面怎麼用,另外也看一下 conflict 時的處理方式。

這邊先產生 hello, world.,然後做了三個操作,第一個是把開頭的 h 改成 H;第二個是把 world 改成 test;第三個是把 world 改成 example

(() => {
  const Automerge = require('@automerge/automerge');

  let doc1 = Automerge.init();

  doc1 = Automerge.change(doc1, 'Init', doc => {
    doc.text = new Automerge.Text();
    doc.text.insertAt(0, 'h', 'e', 'l', 'l', 'o', ',', ' ', 'w', 'o', 'r', 'l', 'd', '.');
  });
  
  let doc2 = Automerge.clone(doc1);
  let doc3 = Automerge.clone(doc1);

  doc1 = Automerge.change(doc1, 'Capitalize', doc => {
    doc.text.deleteAt(0);
    doc.text.insertAt(0, 'H');
  });
  doc2 = Automerge.change(doc2, 'world => test', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'test');
  });
  doc3 = Automerge.change(doc3, 'world => example', doc => {
    delete doc.text.deleteAt(7, 5);
    doc.text.insertAt(7, 'example');
  });

  let finalDoc = Automerge.merge(doc1, doc2);
  finalDoc = Automerge.merge(finalDoc, doc3);
  console.log(finalDoc);
})();

這樣最後會產生出 Hello, testexample.

{
  text: Text {
    elems: [
      'H', 'e', 'l', 'l', 'o',
      ',', ' ', 't', 'e', 's',
      't', 'e', 'x', 'a', 'm',
      'p', 'l', 'e', '.'
    ]
  }
}

這結果看起來還行。

只能說以前要是有這些 library 就好了,當初在 KKBOX 做雲端歌單自己搞半天...

用 AI 模型判斷是否為 AI 產生的文字

OpenAI 放出了新的 model,可以用來判斷是否為 AI 產生的文字:「New AI classifier for indicating AI-written text」。

但目前的成效其實還是不太行,只以英文的成效來看,true positive 只有 26%,而 false positive 是 9%:

In our evaluations on a “challenge set” of English texts, our classifier correctly identifies 26% of AI-written text (true positives) as “likely AI-written,” while incorrectly labeling human-written text as AI-written 9% of the time (false positives).

另外也有提到弱點,像是比較短的內容機很難辨認:

The classifier is very unreliable on short texts (below 1,000 characters). Even longer texts are sometimes incorrectly labeled by the classifier.

然後就是有正確答案的內容也很難辨認,因為正確答案幾乎都是一樣的:

Text that is very predictable cannot be reliably identified. For example, it is impossible to predict whether a list of the first 1,000 prime numbers was written by AI or humans, because the correct answer is always the same.

另外題到了技術上的限制,現在的方法比較像是「辨認是不是從某些 corpus 訓練出來的 model,所產生的文字」,而非通用性的 AI 文字偵測:

Classifiers based on neural networks are known to be poorly calibrated outside of their training data. For inputs that are very different from text in our training set, the classifier is sometimes extremely confident in a wrong prediction.

看起來是還不到可以用的程度...

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

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 這邊,看起來已經有一陣子了...

用 GPT-3 產生 Hacker News 上熱門文章的摘要

看到「Autosummarized HN」這個工具,算是一個組合技的應用:

All summaries have been generated automatically by GPT-3. No responsibility is claimed for their contents nor its accuracy.

透過 GPT-3 解讀並產生出摘要,目前頁面上是沒有 RSS feed,但可以透過一些工具直接拉出來 (像是 PolitePol),然後就可以掛到 Slack 或是 RSS reader 裡面...

玩玩文字轉圖片的 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 首頁上看到「Pronunciation guide for UNIX」這個列表,裡面有各種特殊符號的英文。

裡面列的真的比較簡易,舉例來說,像是他對 - 的說明是:

但如果你查 Hyphen (連字號) 與 Dash (連接號) 的定義,都會指出者兩個東西是不一樣的東西:

The hyphen is sometimes confused with dashes (figure dash ‒, en dash –, em dash —, horizontal bar ―), which are longer and have different uses, or with the minus sign −, which is also longer and more vertically centred in some typefaces.

The dash is a punctuation mark consisting of a long horizontal line. It is similar in appearance to the hyphen but is longer and sometimes higher from the baseline.

裡面的說明用在口語上表達應該還行,但如果是真的在寫比較正式的資料的時候還是要去其他地方確認...

I have no capslock and I must scream

前幾天看到「I have no capslock and I must scream (marginalia.nu)」這個討論,原文的標題是致敬於「I Have No Mouth, and I Must Scream」這篇小說,所以就決定把原標題留起來好了...

原文在「I have no capslock and I must scream」這邊,在原文的後面提到了 Mozilla 的這張 ticket,應該就是寫這篇文章的「主因」了:「Replace the Text Encoding menu with a single override item Repair Text Encoding」。

這種行為也是為什麼即使 Chrome 愈來愈爛,也不打算跳去 Firefox 的原因...

Amazon Transcribe 支援台灣的中文辨識了

Amazon TranscribeAWS 的服務,可以把聲音轉成文字 (speech to text),先前最接近台灣用的中文應該是「Mandarin Chinese (Mainland China)」,兩年前曾經試著用過:「Amazon Transcribe (語音轉文字) 支援中文」,但效果不怎麼樣...

剛剛在「Amazon Transcribe now supports speech to text in 6 new languages - Afrikaans, Danish, Mandarin Chinese (Taiwan), Thai, New Zealand English, and South African English」這邊看到消息,Amazon Transcribe 支援台灣的中文辨識了,晚點可以用同一部影片測試看看...