2. Which disallowed characters? The dictionary appears to be "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz#$%*+,-.:;=?@[]^_{|}~". No slashes or null bytes, which are the common disallowed characters on server platforms. It does have characters your shell cares about, but that's only a problem if you're not quoting.
Point of order though: I don't think that's right for MacOS, though you're certainly right for Windows. HFS+ lets you use any Unicode symbol including NUL (because the filenames are encoded Pascal-style). I don't know the details how how APFS does it, but it also appears to support any Unicode code point, though it additionally mandates UTF-8. [0]
[0] https://developer.apple.com/library/archive/documentation/Fi... grep "filenames"
The name “:.:” can’t be used.
Try using a name with fewer characters, or with no punctuation marks.This is because classic MacOS used : as a directory separator instead of /, and this behaviour is preserved in the UI, but obviously not in the underlying layers.
With this charset: 0123456789ABCDEFGHIJKLMNOPQ RSTUVWXYZabcdefghijklmnopqr stuvwxyz#$%*+,-.:;=@[]^_{|}~.
I imagine you could tweak that to replace problematic chars with safe substitutes.
\ / : * ? " < > |
which means "*:|" would need to be removed if you want to support that use caseYou can't really use them as filenames because they won't be collision free, too. They're not meant to be an identifier, but instead a compact representation of the image that can be stored in a database.
Anyway, chances are you are already storing a filename in your database, so you would need a second field for the blurhash string.
assets/example.png/LEHV6nWB2yk8pyoJadR*.7kCMdnj
assets/example.jpg/LEHV6nWB2yk8pyoJadR*.7kCMdnj assets/example.png#LEHV6nWB2yk8pyoJadR*.7kCMdnj
assets/example.jpg#LEHV6nWB2yk8pyoJadR*.7kCMdnj
No need to send the extra data to the server for each request.Coincidentally, I've just finished some work on a project[1] that is in the same space (identifiers for images).
For the reasons you pointed out, I found Douglas Crockford's base32[2] encoding to be a good fit.
(83 is about as many safe characters as you can reasonably find, and it allows some nice ways of packing values together.)
I wonder how the efficiency compares to just encoding on the bit level.
https://github.com/woltapp/blurhash/blob/master/Algorithm.md
All but the first component of the Fourier transform. (The first component is the average of the data.) The term comes from electrical engineering, but Fourier transform has lots of applications also outside of electrical engineering.
Maybe that shouldn't be allowed, but it is :P
You could save a step by just sending which image to download and use the filename as the hash you use to render the result, but this algorithm requires you store the relationship between the hash and the image somewhere (unless I am missing something obvious).
[0] source code: https://github.com/woltapp/blurhash-python/blob/7469c813ea64...