58 karma · joined March 28, 2021
Living in Weimar, Thüringen, Germany. Working at novomind.com, coding at https://github.com/bittorf.

...and easy session sharing
Your dithered "truedinner.webp" has 189.166 bytes. The original image has 34.682 bytes with JPEG.
https://show.quicky.club/results/b5/30/12/16f36013492e06b658...
Everything above 153x153 pixels is too small (!) to count as LQIP (lighthouse).
The "normal" way would be to use a 0.05+ bpp WEBP-image as LQIP,
which has ~600 bytes, but looks MUCH better and is widely supported:
https://show.quicky.club/results/cb/1f/a5/ddbacee070083ac5f7...
$ echo "(8*147)/(154*154)" | bc -l
.04958677685950413223
@dmit - please check your HTML (w3c validator is unhappy):
https://nigeltao.github.io/blog/2026/wasm-handsum-example/
This is just invalid: '... width="128px" height="128px" ...'*It needs to download 50 megabytes to show a single startpage.
https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...
I tried to compare it with other encoders for the sample (girl/face painting): https://show.quicky.club/results/14/f8/f1/d8db84d57222d32db6...
The PICO-result claim to achieve 0.268 bpp (bit-per-pixel): Even webp (version 1) can do that good enough.
I understand, that one needs really advanced hardware to decode this. Not sure if this is worth the hassle.
Typically 13-14% - my own statistics says ~17%
user@NAS:~$ curl -fsSl https://www.purl.dev/install.sh | bash
...
purl: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.38' not found (required by purl)
user@NAS:~$ uname -a
Linux NAS 6.1.0-43-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.162-1 (2026-02-08) x86_64 GNU/LinuxWhat seems missing: I can not see the answer from the different models. One have to rely on the "correctness" score.
Another minor thing: the scoring seems hardcoded to: 50% correctness, 30% cost, 20% latency - which is OK, but in my case i care more about correctness and latency I don't care.
Wow! This was my testprompt:
You are an expert linguist and translator engine.
Task: Translate the input text from English into the languages listed below.
Output Format: Return ONLY a valid, raw JSON object.
Do not use Markdown formatting (no ```json code blocks).
Do not add any conversational text.
Keys: Use the specified ISO 639-1 codes as keys.
Target Languages and Codes:
- English: "en" (Keep original or refine slightly)
- Mandarin Chinese (Simplified): "zh"
- Hindi: "hi"
- Spanish: "es"
- French: "fr"
- Arabic: "ar"
- Bengali: "bn"
- Portuguese: "pt"
- Russian: "ru"
- German: "de"
- Urdu: "ur"
Input text to translate:
"A smiling boy holds a cup as three colorful lorikeets perch on his arms and shoulder in an outdoor aviary."* add an correct HTML image alt information
* compress your HTML and CSS with brotli (or gzip)
thanks!
$ time target/release/fetch_and_render "https://www.lauf-goethe-lauf.de/"
real 0m0,685s
user 0m0,548s
sys 0m0,070s
$ time chromium --headless --disable-gpu --screenshot=out.png --window-size=1200,800 https://www.lauf-goethe-lauf.de/
real 0m1,099s
user 0m0,927s
sys 0m0,692s
# edit: with a hot-standby chrome and a running node instance a can reach 0,369s seconds here GET / HTTP/1HTTP/1.0 404 Not Found
Server: BareMetal
Content-type: text/html
<!DOCTYPE html>
<html>
<head>
<title>404</title>
</head>
<body>
<p>404 - Not found</p>
</boGET / HTTP/1Obligatorische Pastete: "16GB Ram sind Flischt, ohne wenn und aber. ECC ist nicht Flischt aber ZFS ist dafür ausgelegt. Wenn in Strandnähe Daten gelesen werden und es kommt irgendwie was in den Arbeitsspeicher, könnte eine eigentlich intakte Datei auf der Festplatte mit einem Fehler "korrigiert" werden. Also ECC ja. Das Problem bei ECC ist nicht der ECC-Speicher an sich, der nur wenig mehr als konventioneller Speicher kostet, es sind die Mutterbretter, die ECC unterstützen. Aufpassen bei AMD: Oft steht dabei, dass ECC unterstützt wird. Gemeint ist aber, dass ECC-Speicher läuft, aber die ECC-Funktion nicht genutzt wird. LOL. Die meisten MBs mit ECC sind Serverboards. Wer nichts gegen gebrauchte Hardware hat, kann z.B. mit einem alten Sockel 1155-Xeon mit Asus-Brett ein Schnäppchen machen. Ansonsten ist die Asrock Rack-Reihe zu empfehlen. Teuer, aber stromsparend. Generell Nachteil bei Serverboards: Die Bootzeit dauert eine Ewigkeit. Von Consumerboards wird man mit kurzen Bootzeiten verwöhnt, Server brauchen da oft mal 2 Minuten, bis der eigentliche Bootvorgang beginnt. Bernds Server besteht also aus einem alten Xeon, einem Asus Brett, 16GB 1333Mhz ECC-Ram und 6x 2TB-Platten in einem RaidZ2 (Raid6).6TB sind Netto nutzbar. Ich mag alte Hardware irgendwie. Ich reize Hardware gerne bis zum Gehtnichtmehr aus. Die Platten sind auch schon 5 Jahre alt, machen aber keine Mucken. Geschwindigkeit ist super, 80-100MB/s über Samba und FTP. Ich lasse den Server übrigens nicht laufen, sondern schalte ihn aus, wenn ich ihn nicht brauche. Was noch? Komression ist super. Obwohl ich haupsächlich nicht weiter komprimierbare Daten speichere (Musik, Videos), hat mir die interne Kompression 1% Speicherplatz beschert. Bei 4TB sind das ca. 40GB Platz gespart. Der Xeon langweilt sich trotzdem ein bisschen. Testweise habe ich gzip-9-Komprimierung getestet, da kam er dann schon ins Schwitzen."
COLOR='#000000' # Okabe-Ito: 1 black
COLOR='#e69f00' # Okabe-Ito: 2 orange
COLOR='#56b4e9' # Okabe-Ito: 3 skyblue
COLOR='#009e73' # Okabe-Ito: 4 bluish-green
COLOR='#f0e442' # Okabe-Ito: 5 yellow
COLOR='#0072b2' # Okabe-Ito: 6 blue/darkerblue
COLOR='#d55e00' # Okabe-Ito: 7 vermilion/red
COLOR='#cc79a7' # Okabe-Ito: 8 reddish-purple"Cachet created the word «usability» for that, meaning «start it and be able to use it right away.»"
#!/bin/sh
# originally from https://jpegxl.info/images/precision-machinery-shapes-golden-substance-with-robotic-exactitude.jpg
# URL1="http://intercity-vpn.de/files/2025-10-04/upload/precision-machinery-shapes-golden-substance-with-robotic-exactitude.png"
# URL2="http://intercity-vpn.de/files/2025-10-04/upload/image-png-all-pngquant-q13.png"
curl "$URL1" -so test.png
curl "$URL2" -so distorted.png
# https://github.com/cloudinary/ssimulacra2/tree/main
ssimulacra2 test.png distorted.png
5.90462597
# https://github.com/gianni-rosato/fssimu2
fssimu2 test.png distorted.png
2.17616860A starter is here: https://intercity-vpn.de/files/openwrt/wrt54gtest/minimal/
$ URL=https://herman.bearblog.dev/
$ curl -v -H 'Accept-Encoding: deflate, gzip, br, zstd' $URL 2>&1 | grep --text ^'< Content-Encoding:\|< Content-Length:\|> Accept-Encoding:'
> Accept-Encoding: deflate, gzip, br, zstd
...It seems, the computational overhead is not worth it?
https://nigeltao.github.io/blog/2021/fastest-safest-png-deco...
PNG decoding seems to be fast enough:
tree1 - PEP = 0.412 ms PNG = 0.25 ms
font - PEP = 0.602 ms PNG = 0.663 ms
nz_scene - PEP = 32.121 ms PNG = 3.069 ms
Anyway, PEP is interesting! nz_scene - PEP = 73.542 bytes,
lossy-PNG = 43.557 bytes,
lossy-WEBP = 26.654 bytes,
lossy-mozcjpeg = 15.716 bytes
So it's not about filesize here, it must be decompression speed. {
"request_id": "9622a21f-37bf-4404-ac84-8728977a5272",
"status": "ANALYZING",
"score": null,
"models": [
{
"name": "rd-context-img",
"status": "ANALYZING",
"score": null
},
{
"name": "rd-pine-img",
"status": "ANALYZING",
"score": null
},
{
"name": "rd-oak-img",
"status": "ANALYZING",
"score": null
},
{
"name": "rd-elm-img",
"status": "ANALYZING",
"score": null
},
{
"name": "rd-img-ensemble",
"status": "ANALYZING",
"score": null
},
{
"name": "rd-cedar-img",
"status": "ANALYZING",
"score": null
}
]
} $ curl --location --silent "https://unpkg.com/htmx.org@2.0.4" | wc -c
50917
$ curl --location --silent "https://unpkg.com/htmx.org@2.0.4" | gzip --best --stdout | wc -c
16314