Quick image resizing and markdown image dimensions

I think the encoding difference is pretty obvious, it’s almost 2x as large using hex encoding vs. base64 encoding, for the same 128-bit GUID.

1 Like

Google Photos also switched to base64 (?) encoding some time ago for shared photos… Shorter URLs, but still as secure as the long ones.

6 Likes

I know the technical reasons so I’m not expecting an easy solution, but I do find it sad that in such forward-looking software as Discourse, computerese like this is visible to the user at all.

![fat-city-apple-ii|690x473](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png)

vs.

![fat-city-apple-ii|690x473](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/7v26IM9P2kmVepd7ZxuXyQ3.png)

is neither here nor there, really.

It is 80% file name though. So that is the reality. Count the chars!

The hostname is 41 chars, and the image ID 40 chars in the first example. The full URL from // to .png is 104 chars. I bet you could shorten that URL a lot with a suitable CNAME. Register a WX.YZ host and assign two or three character labels there:

//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/
//dm.cd.cs/

44 versus 11.
(Of course, Czechoslovakia doesn’t register hostnames anymore.)

I already mentioned I can make image:// work :lollipop:

4 Likes

![fat-city-apple-ii|690x473](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png)

is 134 characters, of which

//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png

is a whopping 105 characters. That means 78.3% of the string is the filename :exclamation: Without the filename altogether, the markup is

![fat-city-apple-ii|690x473]()

with the smallest possible URL path it would be 78 characters

![fat-city-apple-ii|690x473](//dm.cd.cs/o/3X/e/7/7v26IM9P2kmVepd7ZxuXyQ3.png)

which is a reduction of 57% in size!

That assumes, however, that:

  1. we can map to a tiny 2-char domain dm.cd.cs
  2. we can use o instead of original in the path
  3. we can switch to base64 encoding instead of hex encoding for the GUID in the filename

cc @zogstrip

1 Like

image://3/7v26IM9P2kmVepd7ZxuXyQ3.png

works without any changes to storage, and a fairly straight forward change to the md pipeline

No magic domains needed.

10 Likes

Nice, let’s make that so when you are back, then! :+1:

![fat-city-apple-ii|690x473](//dm.cd.cs/o/3X/e/7/7v26IM9P2kmVepd7ZxuXyQ3.png)

vs

![fat-city-apple-ii|690x473](image://3/7v26IM9P2kmVepd7ZxuXyQ3.png)

6 Likes

@sam is working on this now so we should be able to get

image://vaLFE+HaBPe06ZIwhR6iqv64zE4.png

vs

//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/d/8/d813b1138aa816ad87eeeebf55af33ebf3c66cf0.png

which I, at least, view as a substantial quality of life improvement for day to day image handling in posts.

(note that we’ll need to use base62, to avoid the / and + chars in URLs though)

6 Likes

Just use URL-safe base64 - uses - for 62 and _ for 63. https://tools.ietf.org/html/rfc4648#section-5 base64 - GoDoc

3 Likes

Cool up to @sam how he wants to handle it, then. Not a huge fan of - and _ both (potentially) being in URLs though.

This is now implemented, I opted for base62 cause it is super friendly on the eyes. I could have allowed $ and * or some other stuff in the URL to shorten it some more and bring it up to base64 but honestly I feel base62 is good enough ™

image

![image|67x72](upload://bBoAuGu6PSabiybDJjSllmiw7S7.png)
13 Likes

Very nice!

![image|690x268](upload://qZMlQclV27lpeoYyoj321BzTvvY.png)