Sat 18 April 2026

Background

I've been catching up on one of my favorite podcasts, recently: Tuxjam, and I just finished listening to Episode 120: Tunnels & Texts.

In this episode, they were reviewing a FOSS app called Deku SMS which initially seemed to promise the ability to send photos by SMS (not MMS!), but that seemed to have been a theoretical/experimental feature that never got implemented. The guys (Kevie, Andrew, Dave, and Al) were excited by that possibility, but it was sadly a non-starter.

Now, I'm no Claude Shannon, but I thought I would give it a go at mocking up a potential system for sending photos and other data via SMS. Now, don't get too excited: when I say mocking-up, I mean just laying out some theoretical groundwork. There's no app or even screenshots of this. There will, however, be a some sample images of what might be possible.

Methodology

Digging into the SMS Specifications as summarized by Wikipedia, it seems that SMS messages can be sent in one of several different text encodings, the most common being 7-bit GSM Encoding, which affords 160 7-bit characters per message.

Looking at the character set*, there doesn't seem to be any special or prohibited characters (like an end-of-file or end-of-message marker), and since the length of SMS messages is fixed, I am going to assume that I can use any of the 128 GSM characters anywhere in the message, without having to resort so something like base64 encoding for "ASCII Armor."

* The following is the 127-character GSM alphabet: @ Δ <Space> ¡ P ¿ p £ _ ! 1 A Q a q $ Φ " 2 B R b r ¥ Γ # 3 C S c s è Λ ¤ 4 D T d t é Ω % 5 E U e u ù Π & 6 F V f v ì Ψ ' 7 G W g w ò Σ ( 8 H X h x Ç Θ ) 9 I Y i y <LF> Ξ * : J Z j z Ø <ESC> + ; K Ä k ä ø Æ , < L Ö l ö <CR> æ - = M Ñ m ñ Å ß . > N Ü n ü å É / ? O § o à

So, 160*7/8 gives us us 140 bytes per SMS message.
How many SMS messages can a phone realistically send in a row without things going awry? I don't know for certain, but I'm going to guess that 100 messages is theoretically feasible, especially if some kind of throttling delay is applied per message sent. That gives us 14,000 bytes per "SMS Picture," but we haven't added any kind of signaling that a theoretical SMS photo app would need to know that it's receiving a photo, or how to reconstruct it.

Here is where the "I'm no Claude Shannon" part seriously comes in. Whatever I come up with here is probably incredibly clunky and inefficient, but I'm going to present my best guess at a potential protocol/scheme.
I think it's reasonable to say that reserving three characters out of every 160-character message for identification and sequencing would probably be enough to prevent the SMS clients from getting confused. Each picture-fragment message would need to convey the following:

1. That it is a picture message, and not mere text,
2. Which picture message it is,
3. Which message/sequence it is among the 100, and optionally,
4. Some kind of rudimentary error detection.

My idea for accomplishing all of these with only three characters is to pick one character at random out of the 128 possible GSM characters to denote a picture ID, and begin and end every picture-"packet" message with that character. In addition, the second character in the very first message would be a repeat of that character-id. The second character of the second message for that same picture would be the value of that character-id plus one, so a hypothetical grouping of messages would look something like this:

Legend

{photo ID character} {message sequence character} {157 data characters} {photo ID character}

Example with random characters omitted

uu{157 data characters}u
uù{157 data characters}u
uΠ{157 data characters}u
u&{157 data characters}u

So, the first message begins with the (randomly-picked) picture identifier, u, then repeats the same character u, and then ends with the picture identifier, u.
The second message repeats the same, except that it increments the second character. After u in the GSM 7-bit character set comes ù, then Π, &, and so on.

Example with sample random data included

uu2KBΨeÇ#VTÜE5"8a¿!4ΩHØ$Ih&gv@zQbÉ=+'Φ.wñPqG%cæ<6tü¡£èXÅø9kY1åjyip3Wò(CJm)äU\ìNö;lD/M:dÆ,uAZΠù*oLnÑéFÖ_Oxßr?>fÄSs-ΣàΘR7jlL6C1ßÑq8@hOBò$¡QtøG&Ié,è*M4ΣcrbDØΩUz()u

uùTy:5-9>2kN+JùV£eÜES7ZXÇÄ<mÅYv¿/sn3_öàHΘ"üä?Fwìæioå%KÖΦΨuΠg!'fP#W;=aAd.RÉ\ÆpñxKäÄNΨx<1YΣ$g2\ìteΩciq?9åÆ@E)L>l*7rJéÜMΠwò6sÇF%,CI!-ùÖPfT=BVRvUpk;öyøZàHæbÉÅÑQAñ_u

uΠ£h'ßΦaXOèΘ¿¡dD.:3nS4uWüGj+"#8&5z/mo(Øs1!¿2w'Æ#ö*%ò-oæLäΩ$S£èurΨpm_Xx8<)fùAå+\Ñü>?/øQÅß":zOk¡ØRZqcÉdé@E;jFbì(UPNaTCJ.6WàÖ5ΠnÇ3yvYGBKIi7ΦDhHMlg=Ü&t9eΣ,ΘÄ4Vñèßéu

u&Y3pC)-ü£à¿ÑcØ4ΨSU<Gm7DΩò"vΣ,Xj$gÉVnÜO9øH&_tl5dq(a*sR.wæJ8ÅÖ6'ìfMA#LQIÄñuÇTÆPie@%=WrN?!ù¡\EäoΠΦKx1>:byåF2/zöZΘB;+khY7Çùß2QÅ"òl!ÆtjÜVüR\öZx'èXAåLDf+u_c<kS);5pøu

...

Again, that's "u" as the identifier for this picture series (at the very beginning and end of each sequence), then u+n as the second character for each of the messages, where n is the message sequence number, from 0 to 99. Of course, when the character reaches number 127 ("à"), it wraps back around to number 0 ("@"). (Remember, this is the 7-bit GSM character set, not regular ASCII.)

With this encoding scheme, we get a picture ID (one of 128, at which point they'd have to be re-used), a message id (one of 100, although you could theoretically do as many as 128 or as few as 1), and just a smidge of error correction (and the ability to weed out non-picture-messages).

You could also send out a header message at the very start that looks something like "PHOTO MESSAGE INCOMING IDENTIFIER u 97 MESSAGES TO FOLLOW" to help mark the beginning of a picture message.

157 7-bit characters per message gives us 137 usable bytes per message. That gives us a maximum total of 13,700 bytes per photo (for 100 messages). You could theoretically push that up to a maximum of 17,536 bytes pr photo if you sent the maximum 128 messages per photo according to this scheme.

What would a 13 to 17 kilobyte photo look like? What could you realistically represent with those few bytes?

Well, let's talk about compression. We're probably not going to use PNG, unless we're dealing with small screenshots, monochrome line-art, or pixel art. JPEG is doable, but it gets kind of ugly once you crank up the compression really high. WebP is better, but in my experience, AVIF is the reigning champion when it comes to representing photos in as few bytes as possible. You can compress decently large images like crazy with AVIF, and rather than get blocky like JPEGs, the images just tend to get a little blurry, but the general impression is intact.

So, enough write-up, let's have at some sample photos!

Sample Photos

Steve McCurry's 1984 "Afghan Girl" photo of Sharbat Gula
10,003 bytes (74 SMS messages) AVIF file at 1000x1500 resolution
Original was a 1,402,408 byte JPEG file at 2000x3000 resolution

Apollo 11 photo of Neil Armstrong
13,001 bytes (95 SMS messages) AVIF file at 384x389 resolution
Original was a 3,822,654 byte JPEG file at 3840x3885 resolution

Apollo 8 "Earthrise" photo
13,110 bytes (96 SMS messages) AVIF file at 1536x960 resolution
Original was a 311,263 byte JPEG file at 2400x2400 resolution

The Golden Gate Bridge, 2017
12,876 bytes (94 SMS messages) AVIF file at 1800x1800 resolution
Original was a 1,812,751 byte JPEG file at 3840x2400 resolution

Conclusions

Some photos did amazingly well, and some really just couldn't cope with the amount of detail. In each example, I played with the resolution and quantization/quality factor a great deal to get the best result as possible within my byte-budget. The "Afghan girl" photo is the most impressive, with vibrant colors and detail where it's needed most (the eyes, the face), and detail spared where it isn't really needed (the clothing, the background).

The classic "Earthrise" photo is absolutely breathtaking for only 12.8 KiB, but the large patch of black space spares a lot of data for the other parts that need it most: the detail on the earth and the moon.

The Golden Gate image suffers a little at the hands of AVIF compression, but is still extremely impressive, giving us 3.24 megapixels for only 12.6 KiB of data, although the detail in the distant background suffers greatly, the mountains being badly smudged.

The poorest performer was the Apollo 11 Neil Armstrong picture, weighing in at a measly 149 kilopixels at 12.7 KiB. I played with this image a ton, trying so many different scaling and quantization factors. There's just too much detail in the picture, and AVIF either yielded a high-resolution blotchy mess, or a low resolution caricature of the original. This is the best result I was able to get for this image.

In closing, I think that sending photos via SMS is theoretically possible, but at this point, there are very few people (from what I understand) that have unlimited SMS but not MMS (that's not a thing in the U.S., as far as I know, but it might be in other parts of the world). In addition, given the time and effort required to send even the smallest attachments through such SMS jiggerypokery, it would be so much easier to just send it through even a very limited data plan, so I don't really see the point. But there are always edge cases, and for those, yes, it's possible. But I have no idea what your carrier might say to see so many SMSes flying in such rapid succession. ;)

Category: Tech Tagged: Computing FOSS (Free and Open Source Software) Hobbies Non-religious post Personal favorites Productivity