iljitsch.com - tech (en)

→ 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 cycling computer

Sun, 01 Jan 2023 14:51:27 GMT

As I wrote earlier: recently, I lost another bike computer so I needed a new one. I decided to get a more recent version of the Sigma BC line that I've been using for the past decade: the Sigma BC 16.16 STS CAD. These seem to be on the way out now, being sold out almost everywhere. But no obvious replacement that isn't more expensive and more complex, so I'm glad I got to get one of the last ones.

The first 16 (roughly) indicates the number of functions. The second 16 is, as far as I can tell, the platform year: 2016. STS is the digital wireless communication system that allows the "computer" to talk to two different bike speed sensor as well as a cadence sensor. The speed sensor sits on the bike's front fork where a magnet on a wheel spoke tells the sensors how fast the wheel is turning. The cadence sensor does the same for your pedals. I got the package that includes a speed sensor and a cadence (CAD) sensor. You can also get just the speed sensor. Or get an extra speed sensor for a second bike.

How it works

I actually did use my previous Sigma BC with two different bikes, and that worked very well. You need to tell one of the sensors to be on the second channel. You then get to set different wheel diameters for the first and second bikes. This is important, as the computer needs to know that wheel diameter / circumference to determine how fast you're going and how much distance you're covering. (In my case it was always 28" / 2200 mm.)

The Sigma sits in a little holder. You twist it to release it so you can take it indoors if you leave your bike outside, that way it won't get stolen. My previous Sigma BC 9.16 STS wouldn't necessarily sit very secure in its holder, hence me losing it. For the 16.16 this seems less of a problem: you really have to put in some effort to make it click into place. It's also not compatible with most earlier cradles. The default way to secure the holder is with a rubber band. But with a couple of tie wraps the holder is locked down more tightly. I reused my previous speed sensor and an older cadence sensor that I still had lying around.

So what do you get out of the BC 16.16 when cycling?

First of all, the current speed is displayed at all times. The whole kilometer per hour numbers are displayed prominently, with fractions of a km/h shown with a much smaller single digit. This part of the display, which also has some status icons, such as connectivity and first/second speed sensor, use a segmented LCD. However, the lower part of the relatively tall display is a pixel LCD. This shows all kinds of information, such as:

Trip distance
Average cadence
Cadence
Ride time
Fuel save
ETA distance / time / clock

Some of these are not so interesting, but you can't turn them off.

The device maintains both statistics and totals. Statistics are numbers of kilometers and hours of activity during the current month and past eleven months. Totals are just the totals of the same for as long as you care to keep them running. On my previous BC I kept a running total of the number of kilometers I rode during the year. So I had to reset that number to zero at the beginning of the year. The monthly statistics are updated whenever you reset a trip distance, and roll over at the start of the next month automatically.

The backlight is pretty clever: if you turn it on, you tell the BC a start and end time. Between those times, whenever you push either of the buttons, this will turn on the green backlight for a few seconds. A second press will let you control the device as normal. Outside the configured dark hours, first presses are handled as normal and the backlight doesn't come on.

Not sure what impact all of this will have on battery life. With the old one, I had to replace the CR2032s in the "computer" and the sensors about once a year. You may or many not lose your statistics and/or settings when changing batteries.

ETA counter

One nice new feature over my previous Sigma BC is that this one supports an ETA (estimated time of arrival) counter. You set a distance, start the count down and the BC 16.16 will show you the distance to your goal and either the time to reach it or the clock time when you will reach it. You have to choose between the latter two options. I find the clock time when you are expected to reach your goal more useful. The time estimation seems to work quite well, not immediately jumping all over the place when you've stopped at a traffic light.

NFC

With an Android phone you can use NFC to read data from the BC 16.16 using Sigma's app. Unfortunately, this doesn't work with the iPhone. To some degree this makes sense due to Apple's limitations. But a simple read action to collect some data is still possible. With an NFC reading app I get a URL from the BC 16.16. Obviously that wouldn't be enough to completely sync all data, but it would/should work for reading cycling trip data from the last few days in the form of a URL or other simple data format. But no, iPhone users get nothing here.

Conclusions

I really like how Sigma Sport keeps improving these simple bicycle computers. The ETA feature seems like a good addition, and the most important information is displayed nice and clear. The automatic monthly statistics are a good way to keep track of any goals you've set for yourself. So if you find yourself wondering how fast you're going or how far you've cycled fairly regularly, but you don't want to mess with smartphone apps or complex/expensive GPS-based bike computers, one of these BCs is highly recommended.