So we’ve had a couple of internal complaints about the fact that the image download name is the sha1 representation and not the actual name of the image (which is available, because you see it in the lightbox). It seems the “actual” name is stored in the metadata of the image.
Is the team open to a PR that retrieves that name and uses it for the download?
This has been brought up before, as I recall, it is a difficult change. @zogstrip can you comment? But maybe if it is only inserted when you attempt to download, that will be easier.
Looking at the way images are handled here on meta.
Images are served via CDN. There is no way you can change the downloaded file name for downloads without routing it via rails first to change the “content-disposition” header.
That might be ok if the rails routing is only triggered on explicit download, e.g. clicking the download link on the expanded, lightboxed images.
This will not work for right click save as, but then, that might not be the full size image but a thumbnail anyway.
On both Firefox and Chromium on Ubuntu Gnome, clicking the download link on the expanded image opens the full-size image in a new tab; it doesn’t open a download dialogue. The only way to download the image is by right-clicking.
The download link of the lightbox will now return the original filename 
(requires a rebake for old images)
No repro on Windows, in Firefox when I click the download link (on expanded lightbox) I get a download dialog with the filename thanks to @zogstrip’s latest change:
@zogstrip, we’ve uncovered that this works correctly for images that get “resized” when uploaded due to their large dimensions, but it doesn’t work for images that are below the dimensions requiring the photo to be resized.
Examples;
Works for:
Doesn’t work for:
I suspect because it doesn’t use the lightbox for the download. You have to right click to download the image and that is simply downloading the embeded image (which happens for the larger images too).
@zogstrip do you think we should light box all images?
This might get weird for tiny images @cpradio think 100 x 100.
Yeah, I’m aware of that. I just can’t think of an easier solution. As the only other solution I can think of is changing how images get rendered and that doesn’t seem like a good idea (and let me be honest, I don’t expect you to do that! – and I wouldn’t ask you to).
Granted what I will say, is I think our instance primarily has images that are “near” the resize threshold but don’t quite meet it, so they are still “large” images, just not large enough to be resized.
Have you considered reducing the threshold?
Before I ask for the wrong setting info, we are talking about the following right?
Yes these are the settings you’re looking for
The only downside to this suggestion is it would effectively make all thumbnails smaller from now on, right?
Yes, that’s the downside of changing these settings…
So I think the majority of SP are not sold on smaller thumbnails. If we get it on our To Do List to
And if we tie it to a site setting, would Core accept the PR?
Absolutely. Make sure it’s off by default though 
Okay, consider this in our court then. As I don’t see a lot of people requesting this. Also, I can’t guarantee it will get done (SP gets the final say on what our devs work on … who knows, maybe I’ll try this at some point)
@purldator and @BerryBlue, SP hasn’t done anything with this primarily because it is way low on our list. We’ve been spending time on other things for the time being. I can’t even promise this is a priority for us anymore.
The same issue applies not only for images but for all kind of files to download. I wish I could rename them. Even deleting them and re-uploading them with a new filename won’t work since they will have the same hash, discourse will rename them to the old filename you wanted to get rid of.
Example:
I want consistency in the filenames of the different versions in the firmware archive:
