Tag: image

Google 推出 Jpegli：JPEG 的 encoder 以及 decoder

在 Hacker News 上看到「Jpegli: A new JPEG coding library (googleblog.com)」，原文是「Introducing Jpegli: A New JPEG Coding Library」。

裡面是有提到檔案大小可以更小：

Our results show that Jpegli can compress high quality images 35% more than traditional JPEG codecs.

但這邊沒有講壓縮率的部分是哪個「traditional JPEG codec」比較，大概就是「WebP 的檔案大小未必比 JPEG 小...」這邊的老招了，應該是跟 cjpeg 比，如果跟 MozJPEG 比的話就未必有那麼高了。

想要寫起來的是 Hacker News 留言有提到命名的邏輯，這個 -li 結尾的用法可以看出來是 Google 蘇黎世團隊的產品：

The suffix -li is used in Swiss German dialects. It forms a diminutive of the root word, by adding -li to the end of the root word to convey the smallness of the object and to convey a sense of intimacy or endearment.

This obviously comes out of Google Zürich.

這點還可以從其他的產品看到類似的命名，比較熟的是 Zopfli 以及 Brotli。

IEEE 也宣佈禁用 Lenna 圖了

Lenna (Lena) 是個經典的標準測試圖片，一方面是因為有很多細節可以觀察 image-related algorithm 的情況，另外一方面也是因為這張圖是取自 1972 年的 Playboy 雜誌：

Lenna (or Lena) is a standard test image used in the field of digital image processing starting in 1973, but it is no longer considered appropriate by some authors.

To explain why the image became a standard in the field, David C. Munson, editor-in-chief of IEEE Transactions on Image Processing, stated that it was a good test image because of its detail, flat regions, shading, and texture. He also noted that "the Lena image is a picture of an attractive woman. It is not surprising that the (mostly male) image processing research community gravitated toward an image that they found attractive."

也因為後者的原因，後來也有愈來愈多其他的圖片可以達到類似的效果 (甚至更好)，就有替代的聲音出現了。

另外一方面，Lena 本人在 2019 年也提到希望淡出的想法：「How a Nude “Playboy” Photo Became a Fixture in the Tech World」。

But I retired from modeling a long time ago. It’s time I retired from tech, too.

而最新的消息就是 2024/04/01 開始，IEEE 不再接受使用 Lenna 圖的投稿：「Institute bans use of Playboy test image in engineering journals」。

之後大概只會在歷史回顧的時候會引用提到了...

把文字檔壓成 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

的確是差不多的等級？

用 shebang 掛起 Docker instance

週末偶而會看到一些奇怪的 side project，像是用 shebang (#!) 直接跑起一個 Docker instance 的方式：「Show HN: #!/usr/bin/env docker run (gist.github.com)」，程式碼在 gist 上：「adtac/595b5823ef73b329167b815757bbce9f」。

可以看到裡面主要的內容都是 Dockerfile，然後重點在開頭的 shebang command，把這些 Dockerfile 的指令倒進去跑 docker build：

#!/usr/bin/env -S bash -c "docker run -p 8080:8080 -it --rm \$(docker build --progress plain -f \$0 . 2>&1 | tee /dev/stderr | grep -oP 'sha256:[0-9a-f]*')"

記得這邊處理後面參數的部分有 undefined behavior，在 id=38989173 這邊也有人提到了：

Beware of portability: it relies on a non-standard behavior from some operating systems. It only works on OSs that treat all the text after the first space as argument(s) to the shebanged executable; rather than just treating the whole string as an executable path (that can happen to contain spaces).

但這主要是好玩，也就還好了...

觀察 Docker image 每一層變化的 dive，以及操作的 crane

在「Dive: A tool for exploring a Docker image, layer contents and more (github.com/wagoodman)」這邊看到的工具，官網在 GitHub 上：「wagoodman/dive」。

Docker image 是一層一層疊起來的，而 dive 可以翻出每一層的變化：

A tool for exploring a docker image, layer contents, and discovering ways to shrink the size of your Docker/OCI image.

馬上想得到的用途是拿來分析空間的使用情況，另外可以拿來確認 container 裡面的內容 (就不用 /bin/bash 進去看了)。

在留言 id=38915336 這邊另外提到了 crane 這個有趣的的東西，可以操作 Docker image。

這邊看到的說明包括了合併不同的 layer，以及類似 Git 的 rebase 功能 (re-apply diff)：

For image and layer manipulation, crane is awesome - as is the underlying go-containerregistry library.

It lets you add new layers, or edit any metadata (env vars, labels, entrypoint, etc) in existing images. You can also "flatten" an image with multiple layers into a single layer. Additionally you can "rebase" an image (re-apply your changes onto a new/updated base image). It does all this directly in the registry, so no docker needed (though it's still useful for creating the original image).

https://github.com/google/go-containerregistry/blob/main/cmd/crane/recipes.md

(updated: better link)

兩個剛好搭在一起...

Brave Search 實作了自己的 Image Search

Hacker News 上看到 Brave Search 時作了自己的 Image Search，不再依靠 Bing 的資訊：「Brave Search launches own image and video search (brave.com)」。Brave 原始文章的標題比較長：「With our own image and video search, Brave Search now offers comprehensive independent results, giving users a fully-fledged, privacy-preserving choice outside of Big Tech」。

在 id=36990055 這邊有提到，這樣有五家搜尋引擎業者有自己的 image search infrastructure 了，包括了 Baidu、Bing、這次的 Brave、Google 以及 Yandex。

另外一個在討論裡面有提到的是以圖找圖的功能 (像是 id=36989140 這邊)，其他幾家都有提供，而 Brave 目前剛出還沒有，不過看下面的回應是有這樣的計畫在跑，但也許優先權不高...

Rocky Linux 提出兩個方法取得 RHEL 的 source code

在「AlmaLinux 與 Rocky Linux 看起來都暫時無解」這邊提到了檯面上目前沒有好方法穩定取得 source code 後，Rocky Linux 提出了兩個方法，在不需要同意 RHEL 的條款下取得 RHEL 的 source code：「Keeping Open Source Open」。

中間還有一些小插曲可以提一下，在社群不少抗議聲後，IBM & Red Hat 的 VP 出來直接說他們認為 RHEL rebuild 沒有任何價值，而且是故意讓 rebuilder 更難實作 RHEL rebuild：「Red Hat’s commitment to open source: A response to the git.centos.org changes」。

Ultimately, we do not find value in a RHEL rebuild and we are not under any obligation to make things easier for rebuilders; this is our call to make.

回到 Rocky Linux 的文章，他們提出來的兩個方法都是基於 GPL 的重要性質：如果你可以合法拿到 binary，那麼散佈者就有義務要提供 source code。

第一個方法是透過 RHEL 目前公開提供的 container image：

One option is through the usage of UBI container images which are based on RHEL and available from multiple online sources (including Docker Hub). Using the UBI image, it is easily possible to obtain Red Hat sources reliably and unencumbered. We have validated this through OCI (Open Container Initiative) containers and it works exactly as expected.

另外一種方式是透過雲端服務的 cloud instance 跑 RHEL：

Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.

這兩個方法都不需要同意 RHEL 目前在網站上的 TOS 與 EULA，而且短時間內應該不好防堵：前者要關掉的話，應該有一堆既有 RHEL 客戶在用會直接抱怨，真的要硬幹的話得給這些客戶時間從 public repository 轉移到要認證的 repository 上；而後者要堵的話，除非 IBM & Red Hat 決定直接不做雲端生意？

看起來 Rocky Linux 與 AlmaLinux 用這套方法可以撐一陣子，直到 IBM & Red Hat 想出新方法來搞？

透過 ControlNet 產生出來的 QR code

Hacker News Daily 上看到「Redditor creates working anime QR codes using Stable Diffusion」這個，Reddit 的原討論串在「ControlNet for QR Code」這邊。

透過 ControlNet 產生出來的 QR code 超出一般對客製化 QR code 的想像... 這邊就不解釋直接上圖了：

拿 JupyterLab 生一些圖

先前看到「Python Data Visualisation」這篇就在研究要怎麼在 Linux 桌面環境下用 Python 搭配 Altair 生圖，在寫一些文件的時候會方便一些。

但先前一直卡住 (不是生不出來，而是流程不順)，所以就放在 browser tab 上面一直沒動。直到前幾天看到 JupyterLab Desktop 改版，想說來看看改得如何：「Introducing the new JupyterLab Desktop!」。

先講一下結論，安裝不算太困難，界面也不差 (畢竟是重點)，但 interface bug 很多，常常按下去沒反應 XD

第一次跑的時候我先把 Python 的環境指到 pyenv 的 ~/.shim/python3。

先拿文章裡的範例丟進去跑：

import altair as alt
from vega_datasets import data

source = data.stocks()

alt.Chart(source).mark_line().encode(
    x='date',
    y='price',
    color='symbol',
    strokeDash='symbol',
)

會長這樣：

然後輸出圖表的右邊的 menu icon 展開後可以選 Save as PNG 存成圖片。

雖然不能直接存到 clipboard 方便我直接貼到 Imgur，但至少可以先打磨出想要的圖，再輸出成檔案處理...

Amazon EC2 AMI 的 root volume 可以直接抽換了

這個功能等了十年以上總算是出現了，Amazon EC2 的 AMI 總算是能直接抽換 root volume，不用先停掉機器：「Amazon EC2 enables easier patching of guest operating system and applications with Replace Root Volume」。

Starting today, Amazon EC2 supports the replacement of instance root volume using an updated AMI without requiring customers to stop their instance. This allows customers to easily update their applications and guest operating system, while retaining the instance store data, networking and IAM configuration.

算是 pre-container 時代會遇到的問題，後來大家都把 workaround 變成 practice 了：每次需要時候都是直接整包重新打包 (像是 Packer 這類的工具)，然後用工具更新 AMI id 改開新的機器，這樣就能夠避開需要先停掉現有機器的問題...

怎麼會突然想到要回來支援這個功能 XD