Not sure if this can be encoded into the site or added to an application, but I request the option to save the file with some of the helpful tags (which ones set by the user if possible) or the original filename iff e621 retains it.

Does this already exist somewhere, or has it been denied?

How do others name images downloaded from here, if renamed?

a: I agree. Since the md5sum of the downloaded file will be the same regardless of how it is named, it's not particularly helpful to include the md5sum in the filename.
I believe that e6 does not retain the original filename.

b: I think this has been proposed before in the feature request thread, but I don't remember it being resolved one way or the other.

c: Since I don't save that much stuff, I tend to rename files with a descriptive, often humorous name, on the spot. Also automatically apply the tags from e6 using a simple tool I wrote using e6's md5 search option.

We could probably do a little better than tags for at least some posts. For example if the post is sourced from tumblr, DA, FA, or IB, there should be a readily available title string, given a little basic web-scraping.

Filename being MD5 does help it to compare to local content and instantly know if downloaded file is the same as it should be.

So I have absolutely zero problems for filename being MD5 hash, but do not oppose something else as long as the hash is then available on the page itself somewhere.

Personally, I believe it should be
"%artists% - %%characters%", or if the title can be ripped from the the source, use that

mrnotsosafeforwork said:
Personally, I believe it should be
"%artists% - %%characters%", or if the title can be ripped from the the source, use that

If that was done, some clipping of one/both lists would be needed, otherwise you could actually exceed your OSes filename length limits!
Consider absolutely_everyone, where you might find ~75 character tags on a single pic -> est. length of 601 just for character tags.

The file server doesn't know anything about the images being served, so this is more difficult than it sounds.

For the server's sake, keep the actual files and paths on the server as they are now. Client should handle how files are saved, both users of the API and site.
For the API, files can be saved programmically from information from the post info.
For the site, maybe offer a setting to add this attribute to the “download” button: <a href="{path}" download="{csv artists} - {csv characters}.{fmt}">Download</a>
This can very easily be done via element.setAttribute("download", string value); and is valid html5.

When I get up and not on my tablet I'll write a functional example code.

Nifty, yet another part of the ever expanding HTML spec I didn't know about.

Chaser said:
For the server's sake, keep the actual files and paths on the server as they are now. Client should handle how files are saved, both users of the API and site.
For the API, files can be saved programmically from information from the post info.
For the site, maybe offer a setting to add this attribute to the “download” button: <a href="{path}" download="{csv artists} - {csv characters}.{fmt}">Download</a>
This can very easily be done via element.setAttribute("download", string value); and is valid html5.

When I get up and not on my tablet I'll write a functional example code.

Actually bit related: forum #211039

This kind of approach I would actually like a lot, keeping stuff the same on server side, but making download button actually do something more than just linking to same thing you are already watching.

An alternative approach in case the above doesn't work out:

Configure the file server to serve [md5].[extension] when [md5]-[arbitrary string].[extension] is requested. On post pages, use the [md5]-[arbitrary string].[extension] form as the image/animation source, where [arbitrary string] is filled in with tags or whatever.

This approach would work well with right click -> "save as", which I don't think can be done in HTML alone.

boopity implementation example https://gist.github.com/FelixWolf/e3614fb5dae79c4aa0f0382be50ede6a
This is client side javascript.

Order of queue:

• If sources exist
• Process each source
• If source matches in regex
• Set filename to source's title
• If above didn't match AND artist and/or character tags exists
• If artist tags
• limit select to 4 and join by CSV
• else Unknown Artist
• If character tags
• limit select to 4 and join by CSV
• else Unknown Character
• If either of above matched
• Set download attribute

Code is licensed under public domain, so e621 is free to use it without restriction. If e621 doesn't add it, if someone wants to, feel free to make it into an extension.
SHOULD e621 implement it, probably a good idea to give user's a option to disable or enable this functionality, some still want the hashes(EG: me, I like hashes. :v )

@MaxPizzle:
I believe KiraNoot was saying that the file server doesn't know what post it's serving. Which makes implementing this directly on the file server problematic.

It seems to me that the main server (ie. of /post/12345 pages) should be able to return a correct "static" download attribute. In that case, it could be implemented using only HTML.

Instead of having things like the MD5 or the artist + characters, why not just the post ID number?

^ Why would you want that, given that post id can be determined using MD5 or tags? Do you want to look up the original post a lot?

savageorange said:
Do you want to look up the original post a lot?

Fun fact: that's the only thing I use file names for.

e6 is good because md5 leads to the post.
DA and FA are ok, both allow to guess the source url from the file name alone.
Tumblr is trash, it's easier to use reverse image search than to guess anything from the file name.

I used to do that, don't care now (or stick the source info in TMSU when I do care)

Just thought it was pretty weird to propose an alternative that would make the filename less useful than it already is (removing the error-checking aspect and only leaving the ability to find the post)

Chaser said:
boopity implementation example https://gist.github.com/FelixWolf/e3614fb5dae79c4aa0f0382be50ede6a
This is client side javascript.

Order of queue:

• If sources exist
• Process each source
• If source matches in regex
• Set filename to source's title
• If above didn't match AND artist and/or character tags exists
• If artist tags
• limit select to 4 and join by CSV
• else Unknown Artist
• If character tags
• limit select to 4 and join by CSV
• else Unknown Character
• If either of above matched
• Set download attribute

Code is licensed under public domain, so e621 is free to use it without restriction. If e621 doesn't add it, if someone wants to, feel free to make it into an extension.
SHOULD e621 implement it, probably a good idea to give user's a option to disable or enable this functionality, some still want the hashes(EG: me, I like hashes. :v )

So this being created (which sounds amazing, btw), is this something I could copy and paste into GreaseMonkey and be good to go, or would I have to wait for someone to come along and do it?

Faux-Pa said:
So this being created (which sounds amazing, btw), is this something I could copy and paste into GreaseMonkey and be good to go, or would I have to wait for someone to come along and do it?

Not initially, but it can now. I have modified it to have a tampermonkey/greasemonkey edition.
Only tested on tampermonkey, should work on greasemonkey though.
Colourized source: https://gist.github.com/FelixWolf/3421a76bb294b42209ba60334fcab0e4
Copy/pasta-able sauce: https://gist.githubusercontent.com/FelixWolf/3421a76bb294b42209ba60334fcab0e4/raw/

savageorange said:
@MaxPizzle:
I believe KiraNoot was saying that the file server doesn't know what post it's serving. Which makes implementing this directly on the file server problematic.

I know. The file server doesn't have to know what post it's serving for my suggestion to work. It just needs to serve https://static1.e621.net/data/97/08/970848328a9e1acabb315391648e750d.png when it's asked for https://static1.e621.net/data/97/08/970848328a9e1acabb315391648e750d-some-extra-text.png

Ah, never mind then, I didn't read carefully enough. So really you are suggesting to implement something that is analogous to the current post/show setup.
Seems fair enough, although I still regard an HTML-only approach as less hacky.

Maxpizzle said:
I know. The file server doesn't have to know what post it's serving for my suggestion to work. It just needs to serve https://static1.e621.net/data/97/08/970848328a9e1acabb315391648e750d.png when it's asked for https://static1.e621.net/data/97/08/970848328a9e1acabb315391648e750d-some-extra-text.png

I think the HTML attribute approach offers better flexibility and it doesn't require reconfiguring the caching system and the static server configuration. Changing the served filename(even if the filename it is loaded from is the same) dramatically reduces the caching effectiveness, which turns into a lot of extra waiting time for visitors. Having good cache effectiveness for new posts is important, they are the most visible and get requested the most often, but they also have the highest chance of having their tags change, which modifies the cached filename under that approach.

KiraNoot said:
I think the HTML attribute approach offers better flexibility and it doesn't require reconfiguring the caching system and the static server configuration. Changing the served filename(even if the filename it is loaded from is the same) dramatically reduces the caching effectiveness, which turns into a lot of extra waiting time for visitors. Having good cache effectiveness for new posts is important, they are the most visible and get requested the most often, but they also have the highest chance of having their tags change, which modifies the cached filename under that approach.

Good point. I hadn't considered caching.

Chaser said:
Not initially, but it can now. I have modified it to have a tampermonkey/greasemonkey edition.
Only tested on tampermonkey, should work on greasemonkey though.
Colourized source: https://gist.github.com/FelixWolf/3421a76bb294b42209ba60334fcab0e4
Copy/pasta-able sauce: https://gist.githubusercontent.com/FelixWolf/3421a76bb294b42209ba60334fcab0e4/raw/

Thank you! I installed the raw into Tampermonkey, but I'm not seeing a download filename change. What should I check or what might I be doing wrong?

@KiraNoot:
Is the HTML attribute approach being considered for install onto the site?

rataw said:
Thank you! I installed the raw into Tampermonkey, but I'm not seeing a download filename change. What should I check or what might I be doing wrong?

@KiraNoot:
Is the HTML attribute approach being considered for install onto the site?

Yes it is. The hesitation is finding a good default pattern. Adding things as options tends to be a big maintenance headache.

rataw said:
Not sure if this can be encoded into the site or added to an application, but I request the option to save the file with some of the helpful tags (which ones set by the user if possible) or the original filename iff e621 retains it.

Does this already exist somewhere, or has it been denied?

How do others name images downloaded from here, if renamed?

It'd probably be a lot easier for you to find (or make, if you're into coding) a browser extension that will allow you to change filenames en masse as you're saving them. Maybe something along the lines of Image Picker but with an added rename functionality. I don't know if such a thing exists, but it'd probably be a lot easier to implement than what you're suggesting.

Also, a quick way to rename lots of files in Windows (this doesn't always work, so back them up to a different folder before you try it) is to select all images in Windows Explorer and give them a one-word name, then press ENTER. This makes Windows Explorer add a number in parentheses at the end of the filename. So if you renamed all the files "e6pics" or something like that, the first would be named "e6pics," the second would be "e6pics (1)," the third "e6pics (2)," and so on. It's not exactly what you were looking for, but it might do in a pinch as a workaround until you figured something more elaborate out.

InannaEloah said:
It'd probably be a lot easier for you to find (or make, if you're into coding) a browser extension that will allow you to change filenames en masse as you're saving them. Maybe something along the lines of Image Picker but with an added rename functionality. I don't know if such a thing exists, but it'd probably be a lot easier to implement than what you're suggesting.

There are addons that add downloads to DownThemAll (eg. ThumbsDown). DownThemAll is quite flexible WRT naming. So that is one possibility.

The option I would choose if I wanted to do that, though, is to rename files automatically, en masse, after they have downloaded. This would require to check whether the filename already includes tags, and if it doesn't, ask E621 to look up the post by MD5; this will return a JSON record including the tags, which you can then reformat into a filename fragment and perform the actual rename.

It would also be possible to break that process into a two step batch-process: A program that generates a file specifying renames, and a program that processes that file (actually does the final renamings). That would allow you to review/change the names chosen before actually applying them.

Regarding 'a quick way to rename a lot of files' : There are actual applications just for customizable batch-renaming, as well as file managers that incorporate it. Depending on your needs, it may be worth researching. On Linux, I use Thunar -B

rataw said:
Thank you! I installed the raw into Tampermonkey, but I'm not seeing a download filename change. What should I check or what might I be doing wrong?

As far as I can tell, it's because browsers (rightfully) consider static.e621.net as cross-origin to e621.net and ignore the download attribute as per HTML5 spec. This would be a problem even if KiraNoot just set the download attribute.

There is may be a way around that in the userscript, but it involves downloading the file in the script to get its binary data and encode that in the link. Not sure I like scripts making AJAX requests like that, if the server even lets it do that. :\

Hm, would something like appending a page# to the 'pages' of Pool comics fall under this category of 'something more human-friendly when downloading'?

eg 1b030f5efbadcdcb71dc9fb05def3325.jpg might become

or
p1_1b030f5efbadcdcb71dc9fb05def3325_p1.jpg

titanmelon said:
Hm, would something like appending a page# to the 'pages' of Pool comics fall under this category of 'something more human-friendly when downloading'?

eg 1b030f5efbadcdcb71dc9fb05def3325.jpg might become

1b030f5efbadcdcb71dc9fb05def3325_p1.jpg

That wouldn't sort in any particularly sensible way, so I'd say no.

${POOLID}_p${PAGENUMBER}_${MD5}.${EXT} [1] would be more helpful IMO, since it would group images from a given pool together and also order them correctly if you are using the default alphanumeric sorting.

[1] eg. 12345_p1_1b030f5efbadcdcb71dc9fb05def3325.jpg

Any special-casing like this is potentially confusing and should be treated with caution, though.

But then what if it's in multiple pools?

I guess the pool id would be the numerically first (typically, this would equal oldest) pool, and the pagenumber would be its index inside that.

If you have any better suggestions feel free to make them. I really just wanted to point out that simply appending the page number wouldn't make it significantly more human-friendly. In a majority of cases, I believe the particular format I suggested -would- do so.

(though there is still the question of whether this particular piece of data (pool membership and ordering) is available at the time it would need to be used)

EDIT: Actually, who were you addressing? Since your question is equally valid in relation to Titanmelon's post or mine.

savageorange said:
Actually, who were you addressing? Since your question is equally valid in relation to Titanmelon's post or mine.

Both of you, actually.

Not sure if this is going to happen, based on the cross origin check failing on the static domain and so it ignores the download HTML attribute. I'll have to check if a 302 disables the renaming or not.

KiraNoot said:
I'll have to check if a 302 disables the renaming or not.

If not that, maybe you could send a Content-Disposition: attachment; filename="whatever" header when content is accessed via the download button?

^ Doesn't KiraNoot's first page response to MaxPizzles similar-but-inverted suggestion, "provide xyz.png when xyz-tags.png is requested", imply that would require reworking the file server setup, since it doesn't into posts or tags?

I personally am one of those who are for keeping the original file name, what's the problem with that exactly? keeping SOME character's names artists names in the tags would also be nice. There could be a limit on overall file name length though. Like not exceeding a 100 letters or something.

tabaluga said:
I personally am one of those who are for keeping the original file name, what's the problem with that exactly? keeping SOME character's names artists names in the tags would also be nice. There could be a limit on overall file name length though. Like not exceeding a 100 letters or something.

1. 3 years old thread
2. There could only be single file named Untitled.jpg, Output.webm or asdage.png

mairo said:
1. 3 years old thread
2. There could only be single file named Untitled.jpg, Output.webm or asdage.png

2. Do you mean on the disk of the person doing the downloading? On the server side, it's definitely possible to provide a 'save filename' that's different from the filename used on disk, so you could store with md5 filename, link using md5 filename, and when you save that, it saves with original filename.

Original filename is rarely meaningful though IME.

savageorange said:
2. Do you mean on the disk of the person doing the downloading? On the server side, it's definitely possible to provide a 'save filename' that's different from the filename used on disk, so you could store with md5 filename, link using md5 filename, and when you save that, it saves with original filename.

Original filename is rarely meaningful though IME.

Tabaluga was commenting on being one to keep original filenames of stuff, so my assumption was that they would like to have original filenames on files.
Artists and others original filenames are rarely useful, because they are mostly just single words without meaning, but if you do have file from for example furaffinity, now you have epoch timestamp, account name where it originated from and original filename, which is extremely helpful information with sourcing.