Quick image resizing and markdown image dimensions

feature announcements
#1

As of today when you paste in images we no longer use IMG tags. So for example:

very good

Generates the Markdown

![very good|512x397](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/0/3/03741c9f3eafd7fc8ccd791a6971a2c0d52783e4.jpg)

I also added an Ninja :crossed_swords: feature that allows you to quickly scale images down

very good

![very good|512x397,20%](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/0/3/03741c9f3eafd7fc8ccd791a6971a2c0d52783e4.jpg)

So by adding ,20% you scale the image down to 20% size, this is particularly handy for people who paste in “retina” screenshots end end up having double sized images. A quick ,50% will make the image look just right.

36 Likes
Markdown for image resize by px, not percent
#2

This is so incredibly useful - I didn’t know I needed it until it existed! A very tiny issue I keep having is that I naturally edit it into

![very good|512x397, 20%](...)

which then doesn’t work because of the space… Any chance the whitespace could be ignored? Or is that gonna cause issues elsewhere?

2 Likes
#3

I do not think it will cause any issues, feel free to submit a PR for (and make sure there is a test) I would just add a \s* to the regex or something…

2 Likes
#4

nice feature :smiley:
is there any way to add alt tag to images in this Markdown?

#5

very good is the alt tag in very good|100x100

:sunglasses:

3 Likes
#6

thanks, easy and handy :star_struck:

#7

Another small suggestion, maybe the auto-generated markdown should include 100% to make this ninja feature more discoverable?

![very good|512x397,100%](//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/0/3/03741c9f3eafd7fc8ccd791a6971a2c0d52783e4.jpg)

(This might actually be an alternative, bot not mutually exclusive, help for the @david’s issue too, if the default text would be there without a space)

9 Likes
#8

I thought about this, I have mixed feelings about it. Maybe… @codinghorror what do you think?

We always wanted to allow people to “resize” using preview, this kind of unlocks that feature, but it is going to be a bit before markdown.it has proper source maps to support it.

#9

Here’s a PR for the whitespace thing

https://github.com/discourse/discourse/pull/5000

I agree with @mcwumbly that including the 100% automatically would be good for discovering the feature - happy to add it to the PR if the team agrees.

(Also, I got pull request #5000, yay :tada:)

10 Likes
#10

No, I don’t think adding more noise to every image is a good idea. Ideally srcset would work transparently to the user. Manually resizing images is very advanced user scenario, I can’t even recall a time I needed to do that here in the last 6-12 months?

1 Like
#11

So the old method inserted

<img src="//assets-meta-cdck-prod-meta.s3.dualstack.us-west-1.amazonaws.com/original/3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png" width="690" height="473">

the new method inserts

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

While this is definitely a nice quality of life improvement, our default filenames are pretty bad.

3X/e/7/e76d2a89947069f0ce624d5989fa20c47a13d383.png

Surely we don’t need that many characters to make each filename unique?

#12

Anything wrong with preserving original filename, appending digits for duplicates?

#13

I believe those long, random filenames are a security measure since uploaded files are accessible by everyone who knows the filename. Those long names are quite hard to guess…

1 Like
#14

Md5 would probably cut it here.

#15

I see that GitHub uses a similar strategy, so is the existing one that Discourse uses worth changing?

image
image.png798×260 16.8 KB

For the record, the 4970_1 was the original filename of the image I dragged/dropped, what is in parenthesizes is the filename GitHub created for storing the image.

#16

Probably not, but we could shorten to image://sha1.png quite easily, which helps

1 Like
#17

I’s say, it worth to use term “random bit length” instead of “algorythm”, because any good hash function will be ok. Usually, 128 bits should be ok, but very big hostings (like “yandex photos”) switched to 512 bits. Also, timestamp can be used to reduce random part (see mongodb algorythm for ObjectID).

Another way to save ~25% is use of base58 encoding or similar (base64 is not url-friendly).

Quick estimate: 128 bits + base64 => 128/6 => 22 characters.

4 Likes
#18

That is correct, base64 encoding of 128 bits GUID should produce 22 chars:

7v26IM9P2kmVepd7ZxuXyQ

You can do ASCII85 encoding to achieve 20 bytes but the characters used are no longer filesystem friendly and that does not seem worth the additonal pain:

[Rb*hlkkXVW+q4s(YSF0

Compare with what we currently have @sam …

e76d2a89947069f0ce624d5989fa20c47a13d383
7v26IM9P2kmVepd7ZxuXyQ

… quite the difference, we could lop off 16 chars there.

2 Likes
#19

8 posts were merged into an existing topic: Is using a GUID for an uploaded filename secure?

#20

So far, only @sam’s image://sha1.png sounds good to me. And I don’t feel any strong love for that. Why do you care how clean or ugly a filename a user doesn’t have to type in themselves is?

All the other ideas seem like more complexity for little gain. The whole idea of using a hash is that identical uploads can easily be optimized for disk space. Changing to some other ID doesn’t achieve that. You could store and save the SHA1 in the background and give out the same GUID for it, but there’s that complexity.

(And using MD5 is bad since there’s a non-zero chance someone will want to post deliberate collisions. But as easily forced SHA1 collisions will probably be upon us soon, too, maybe the complexity would be good?)

1 Like