iljitsch.com - tech

→ Thoughts and Observations Regarding Apple Creator Studio (well, really the state of Apple software and design)

Sun, 18 Jan 2026 15:28:21 GMT

John Gruber wrote a long article on the current state of Apple's software, graphical and user interface design. The most salient part, quoted from somewhere else:

If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design.

Sick burn.

I saw some of this already happening with the iWork suite back in 2013...

MySQL Unicode weirdness

Thu, 21 Sep 2023 11:00:00 GMT

After looking at the SQLite Unicode behavior, it's now time to do the same for MySQL. Coincidentally, I'm currently migrating some old databases that were created in the very early 2000s to a more modern environment. I think those old databases were from the MySQL 3.x days, before MySQL gained any sort of Unicode support. Those old tables are thus still in the latin1 (ISO 8859-1) character set.

For a long time that worked fine for me as these tables contain data in English and Dutch, and Dutch only needs a few accents, which are all present in Latin 1. However... at some point it started becoming more convenient to use UTF-8 for the text in those databases. So I did. I just never told MySQL about the switch.

In hindsight, that was not a terrible decision, as it avoided complexities at a time when UTF-8 support was still immature. But these days, there's really no excuse to do anything other than make an entire workflow UTF-8 clean, barring any showstoppers.

So I migrated an old table to the test environment for the new system. And got some really weird results: on web pages "CO₂" showed up as "COâ‚‚", but in MySQL it showed up correct, be it that the number of characters is off (I only got 6 while I specified 8):

mysql> select substr(article, 1587, 8) from muart where id = 753;

+--------------------------+
| substr(article, 1587, 8) |
+--------------------------+
| CO₂ ui                 |
+--------------------------+

Further digging by looking at the raw data:

mysql> select hex(substr(article, 1587, 8)) from muart where id = 753;

+-------------------------------+
| hex(substr(article, 1587, 8)) |
+-------------------------------+
| 434FC3A2E2809AE2809A207569    |
+-------------------------------+

Fortunately, it's not necessary to decode this manually, there is an UTF-8 Decoder web tool for that. The decoder shows that COâ‚‚ is correct. So why is MySQL showing me CO₂? That's a problem I hadn't heard of before, but is apparently not uncommon:

Double-encoded UTF-8.

This happens when you take UTF-8, such as "CO₂", and then pretend it's another encoding (usually Latin 1) and convert that to UTF-8. So what had happened is that as I was importing my data in MySQL, the MySQL command line client would send UTF-8 to the MySQL server process, but the server would think that was Latin 1 and convert it to UTF-8. Then when I did a query, the server would convert the UTF-8 back to what it thought was Latin 1 for the convenience of the client, and the client then showed this as UTF-8 so everything looked good, but was actually stored in the database incorrectly.

Fortunately, the two related problems were both easy enough to fix. First, make sure the client and server agree on the character encoding. Let's first check what the server's original settings are:

mysql> SHOW SESSION VARIABLES LIKE 'character_set%';
+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | latin1                         |
| character_set_connection | latin1                         |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | latin1                         |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+

Wow. But fortunately we don't have to fix all of those individually. We can simply do:

mysql --default_character_set=utf8mb4

And then:

mysql> SHOW SESSION VARIABLES LIKE 'character_set%';

+--------------------------+--------------------------------+
| Variable_name            | Value                          |
+--------------------------+--------------------------------+
| character_set_client     | utf8mb4                        |
| character_set_connection | utf8mb4                        |
| character_set_database   | utf8mb4                        |
| character_set_filesystem | binary                         |
| character_set_results    | utf8mb4                        |
| character_set_server     | utf8mb4                        |
| character_set_system     | utf8mb3                        |
| character_sets_dir       | /usr/share/mysql-8.0/charsets/ |
+--------------------------+--------------------------------+

Much better.

And convert the double-encoded UTF-8 into something more readable:

mysql> UPDATE muart SET title=CONVERT(CAST(CONVERT(title USING latin1) AS binary) USING utf8mb4);

Keen-eyed observers may have noted that MySQL has two versions of UTF-8: utf8mb3 and utf8mb4. This goes back to the early days of Unicode, where the idea was that all characters would fit into 16 bits. That results in a maximum of 3 bytes of UTF-8. But it soon became clear that 16 bits wasn't enough. So now it's 21 bits. UTF-8 can handle that just fine, but those characters that need 17 - 21 bits result in 4-byte UTF-8 sequences. So when dealing with MySQL, when you think "UTF-8", type "utf8mb4".

Looking back on 50 years of Ethernet

Thu, 29 Jun 2023 12:37:00 GMT

On potaroo.net Geoff Huston wishes Happy 50th Birthday Ethernet.

Back in 2011 I wrote an Ars Technica feature about the history of Ethernet: Speed matters: How Ethernet went from 3Mbps to 100Gbps… and beyond.

Interesting to compare our different takes!

And of course Ethernet is still going strong. My oldest computers have the original 10 Mbps Ethernet adapters that I got almost 30 years ago, while my newest computer has 10 gigabit Ethernet, 1000 x faster.

Comparing digital and film resolution using MTF

Wed, 29 Mar 2023 10:44:35 GMT

I fell down a rabbit hole a while ago trying to come up with the definitive answer to the often-asked question "how can old movies be in HD/4K", which immediately leads to "how does film and digital resolution compare".

The answer to the first question is of course that film as a lot more resolution than standard definition TV, so just scanning the movies at a higher resolution will give you a sharper image than that old DVD or (shudder) VHS tape.

(Actually a good VHS tape on a good player (my last one (at some point I had three) definitely doesn't qualify anymore) can look pretty good as long as the ridiculously low chroma resolution doesn't create problems.)

Film: super high?

For reasons unknown, lots of people quote fairly ridiculous (to me) numbers, such as 20 megapixels for movies on 35 mm film. Between the advent of the 1.85:1 aspect ratio and that of Super35, a movie would effectively be shot at a ~ 22x12 frame size. That is not a lot of film to hold so much resolution.

Film: not so high?

This is where I planned to show damning evidence of film having much lower resolution than 20 megapixel digital using this photo, that I took both on film and digitally:

Nikon F65, Ilford Delta 100 film, camera-scanned with a Nikon Z fc and a 1:2 manual focus macro lens, resulting in a 12.5 megapixel image. Here resized to 3 megapixels, click here to see the original file.

This image certainly seems to make good use of those 12 megapixels. I later did a higher resolution scan of part of the image with a 1:1 reproduction ratio zoom lens, which does bring out a bit of extra detail, but only marginally so.

MTF!

The problem with reasoning about film grain vs pixels or eyeballing images is that it's very imprecise. But we actually do have a tool that lets us compare digital vs film: the optical transfer function.

This takes the form of a graph that plots the contrast of line pairs against their frequency in line pairs per mm or cycles per mm. It's often called modulation transfer function (MTF), but it's different from the MTF graphs we often see for lenses. Also note "line pairs" vs "lines". In TV/video the number of horizontal lines has always been an important number, but what we care about here is line pairs. So if the P is missing, you never know what people are talking about.

I'll use MTF in the optical transfer function-like meaning.

The nice thing about the MTF is that it lets us compare completely different optical pipelines, such as completely analog film, analog film digitized at some point, and start-to-finish digital images.

Each step, such as lens, sensor and display / print has its own MTF and you simply multiply these. (Which means that a great lens on a mediocre sensor is still better than a mediocre lens on a mediocre sensor!)

An easy way to compare different steps in the process is to have some MTF cutoff to get at a line pair / cycle per mm limit. I've seen various values suggested as the cutoff: 50%, 30%, 10% and 6%.

Norman Koren has an overview Film MTFs vary of course, with 50% at 40 lp/mm being a reasonable guess for film that doesn't compromise sharpness. Obviously at ISO 3200 all bets are off. So I'm going to assume film with MTF50 at 40 lp/mm for the rest of this discussion.

Koren states MTF curves behave as a Lorentzian function, which means that we should be able to convert between MTF line pair / contrast values easily. Rounded slightly:

MTF30 = 1.5 x MTF50
MTF20 = 2 x MTF50
MTF10 = 3 x MTF50
MTF06 = 4 x MTF50

The MTF for 80 lp/mm is 20% contrast. This means that with a lens at MTF50 or MTF30 we'll reach the lower limits for film image detail at MTF10 or MTF06. Even if we're generous and go to 120 lp/mm, most 35 mm movie formats top out soon after 4K. And that's only when scanning the original camera negatives. Scanning later copies easily halves your resolution.

Digital (pixel) encoding and display, it looks like the contrast in the MTF stays well above 50% until you closely approach the Nyquist frequency = 2 pixels per line pair.

Use the slider to see what digital resolution you'd need to fully capture different film sizes at a given number of line pairs per mm:

Type / aspect ratio		Size (mm)	Pixels wide	Megapixels
Academy 1930s		22.0 x 16.0
Second half 1900s		22.0 x 12.0
35 mm anamorphic		22.0 x 18.6
Super35 3-perf		24.9 x 13.9
Super35 2-perf		24.9 x 9.5
65/70 mm		48.5 x 22.1
IMAX 70 mm 15-perf		69.6 x 48.5
35 mm photos		36.0 x 24.0

Line pairs per millimeter: 80

Convert: MTF50 → MTF30 / MTF50 → MTF10 / MTF50 → MTF06

Conclusions: even 70 mm movies don't materially benefit from higher megapixel scans than about 30. For 35 mm photos, it's a struggle for film to hold up beyond12 MPX. (Which phone cameras have reached the better part of a decade ago.)

So it looks like 4k is a very good fit for 35 mm movies, except perhaps ones shot with high quality black and white film. 8k only possibly makes sense for 65/70 mm. But those tend to be old so I doubt there would be much of a difference in practice. And 8k is completely impractical because you need to sit very close to a very big screen to be able to see the extra sharpness anyway.

This post is based on a discussion thread on the soon to disappear DPReview forums, but saved on archive.org.

Review: Sigma BC 16.16 STS CAD fietscomputer

Sun, 01 Jan 2023 14:57:15 GMT

Zoals ik eerder schreef: ik ben weer een fietscomputer kwijtgeraakt dus ik had een nieuwe nodig. De keus viel op een meer recente versie van de Sigma BC-lijn die ik de laatste tien jaar ofzo al gebruikte: de Sigma BC 16.16. STS CAD. Deze lijken niet echt meer beschikbaar te zijn, maar zonder duidelijk alternatief dat niet aanzienlijk duurder en complexer is ben ik blij dat ik één van de laatste van deze op de kop kon tikken.

De eerste 16 geeft (ruwweg) aan hoeveel functies de fietscomputer heeft. De tweede 16, voorzover ik kan achterhalen, is een indicatie van wanneer het "platform" gelanceerd is. 2016 dus. STS is het digitale draadloze communicatiesysteem waarmee de "computer" met twee verschillende snelheidssensors kan communiceren plus een trapsnelheid-sensor. De snelheidssensor zit vast aan de voorvork met een magneetje aan één van de spaken waaraan de sensor kan zien hoe snel het wiel draait. De trapsnelheidssensor doet hetzelfde voor je pedalen. Ik heb het pakket dat ook de trapsnelheidssensor bevat aangeschaft. In alle gevallen krijg je ook een snelheidssensor. En je kan extra sensors aanschaffen voor je tweede fiets.

Hoe het werkt

Ik gebruikte mijn vorige Sigma BC met twee verschillende fietsen (tot één ervan gestolen werd), en dat werkte heel goed. Je moet één van de twee sensors instellen om het tweede kanaal te gebruiken. Je kan dan verschillende wieldiameters/omtrekken instellen voor de twee fietsen. Dit is belangrijk omdat de computer moet weten hoeveel afstand je aflegt (en dus hoe snel je gaat) bij iedere omwenteling van het wiel. In mijn geval was dit steeds 28 inch / 2200 mm.

De Sigma neemt plaats in een kleine houder op je stuur. Je draait hem een gedeeltelijke slag om hem uit de houder te halen wanneer je je fiets buiten laat staan. Mijn vorige Sigma BC 9.16 STS kon nogal wankel in zijn houder zitten, vandaar dat ik 'm kwijtgeraakt ben. Bij de BC 16.16 lijkt dit minder problematisch te zijn: je moet aardig je best doen om 'm vast te laten klikken. Hij werkt dan ook niet met oudere houders. Je maakt de houder aan je fiets in principe vast met een rubberband, maar met twee tie-wraps zie-ie steviger op z'n plaats. Ik kon mijn bestaande snelheidssensor en een oude trapsnelheidssensor die ik nog had liggen hergebruiken.

Wat heb je aan de BC 16.16 wanneer je fietst?

Allereerst zie je altijd je huidige snelheid. De kilometers per uur worden prominent weergegeven, met een extra cijfer achter de komma een stuk kleiner. Dit deel van het schermpje, waar zich ook een aantal ikonen voor bijvoorbeeld connectiviteit en eerste/tweede fiets bevinden, bestaat uit een gesegmenteerd LCD-scherm. Alles is dus mooi scherp. De onderste helft van het scherm gebruikt pixels en is dus flexibeler. Dit kan onder meer de volgende info laten zien:

Trip-afstand (niet zozeer dagelijks, zoals in het Nederlands gesuggereerd wordt)
Gemiddelde trapsnelheid
Trapsnelheid
Trip-tijd
Bespaarde benzine
Aftellende afstand / tijd / tijd van aankomst

Sommigen hiervan zijn minder interessant, maar je kan ze niet uit zetten.

Het apparaat houdt zowel statistieken als totalen bij. Statistieken zijn het aantal kilometers en gereden uren gedurende de huidige maand en de afgelopen elf maanden. Totalen zijn de totalen van dezelfde getallen, zolang je die laat lopen. Wat ik deed/doe is deze elk jaar op nul zetten zodat ik weet hoeveel afstand ik in een jaar afleg. (2022: 3000 km.) De maandelijkse statistieken worden bijgewerkt wanneer je een trip op 0 zet en de maanden worden verder automatisch bijgehouden.

De verlichting is slim geregeld: als je dit aanzet dan geef je de BC een start- en eindtijd. Tussen deze tijden werken de toetsen iets anders dan normaal: de eerste keer indrukken zorgt dat het licht een paar seconden aan gaat. De tweede keer indrukken geeft dan de normale functie. Buiten de ingestelde tijden blijft het licht uit en werken de toetsen normaal.

Ik weet niet wat voor effect dit zal hebben op de batterij. Met de oude BC moest ik de CR2032-batterij in de "computer" en de sensors ongeveer één keer per jaar vervangen. Daarbij verlies je soms wel en soms niet de statistieken en/of instellingen.

ETA / aftel-teller

Een interessante nieuwe functie van de BC 16.16 ten opzichte van de BC 9.16 is de "estimated time of arrival"-teller. Je stelt dan een afstand in en start het aftellen. De BC 16.16 laat je dan de resterende afstand zien en ofwel hoe lang tot je er bent ofwel hoe laat je zal arriveren. Die laatste vind ik nuttiger, en het lijkt best goed te werken zonder gelijk enorme sprongen in verwachte aankomsttijd als je even stilstaat voor een stoplicht.

NFC

Met een Android-telefoon kan je met NRF data uitlezen van de BC 16.16 met Sigma's app. Helaas werkt dit niet met de iPhone. Tot op zekere hoogte is dat te begrijpen vanwege Apple's beperkingen aan de NFC-functionaliteit. Maar simpelweg wat data uitlezen is wel mogelijk. Met een NFC-app krijg je van de BC 16.16 een URL. Dat is uiteraard niet genoeg om alle data te synchroniseren, maar het zou toch mogelijk moeten zijn om de info van de laatste paar trips uit te lezen in de vorm van een URL of een andere simpele datastructuur. Maar nee, iPhone-gebruikers krijgen helemaal niks.

Conclusies

Het is mooi dat Sigma Sport deze simpele fietscomputers blijft verbeteren. De ETA-functie lijkt een goede toevoeging te zijn, en de belangrijkste informatie wordt duidelijk weergegeven. De automatische maandelijkse statistieken zijn een goede manier om je doelen in de gaten te houden. Dus als je regelmatig al fietsend merkt dat je wilt weten hoe hard je gaat of hoeveel afstand je afgelegd hebt, maar je wilt niet met apps of complexe/dure GPS-gebaseerde fietscomputers aan de slag, dan kan ik één van deze BCs van harte aanbevelen.