Requested feature(s) overview description.

I. Posts should be able to be updated in-place with a new image.

II. Flash (and other media with all-white thumbnails) posts should be able to be given a custom thumbnail.

III. The post types affected by II should have a "type bubble" of their own.

Why would it be useful?

I. Games like Corruption of Champions would cause less of a moderation headache with only one version floating around.

II. As it stands, it's impossible to tell the difference between all the flash content without going in and loading it. Sure you could probably get an idea of what it is by looking at the artists, but I sure can't keep them straight. Poor UX IMO.

III. has actually already been implemented but only with "WEBM" and "ANIM" type content as far as I can tell.

What part(s) of the site page(s) are affected?

• Post lists
• Edit UI
• User Experience (UX)
• Moderation

It's safe to assume that the newest upload is the newest version, so having multiple versions is not that much of a headache. If someone tries to upload an older version of a flash game, it doesn't get approved... unless it slips past moderation.

In case of games such as CoC, older versions are usually kept for a while for reasons such as save compatibility. And in some cases (Crowjob, etc) the versions are so different that keeping the older ones is warranted.

Genjar said:
It's safe to assume that the newest upload is the newest version, so having multiple versions is not that much of a headache. If someone tries to upload an older version of a flash game, it doesn't get approved... unless it slips past moderation.

In case of games such as CoC, older versions are usually kept for a while for reasons such as save compatibility. And in some cases (Crowjob, etc) the versions are so different that keeping the older ones is warranted.

Version history would be a nice compromise, then. Keep it all in one post. And I know that sounds like a pool, but a single post with version history won't spam search results. /post/123456/2/tag-list would be the second version, while the normal /post/123456/tag-list urls would implicitly point to the latest version.

Granted, the change I want the most is II+III. Navigating a list of flash results is pure hell if only because you can't tell what it is without going in. A custom thumbnail or some way to otherwise tell them apart from the results page would help UX a lot.

1. Thanks to posts ID being tied to files MD5 hash, changing file will change the hash at which point everything breaks. People have been asking this feature for regular posts as well, but most likely not happening.

2. This has also been discussed, but considering that it's not too far off until flash cannot even be viewed in browser and considering that we aren't file hosting service, that would be extra work for something that's already half dead.

Luckily there's only couple flash uploads here and there nowdays anymore and most of those are also converted into webm or gif files almost immidiately.

Mairo said:
1. Thanks to posts ID being tied to files MD5 hash, changing file will change the hash at which point everything breaks. People have been asking this feature for regular posts as well, but most likely not happening.

2. This has also been discussed, but considering that it's not too far off until flash cannot even be viewed in browser and considering that we aren't file hosting service, that would be extra work for something that's already half dead.

Luckily there's only couple flash uploads here and there nowdays anymore and most of those are also converted into webm or gif files almost immidiately.

Fair point on #1, although not impossible. A submission could be tied to a list of hashes for version in history, though depending on the architecture behind the back end and what hashes are used for outside of file-naming (the versions could still be individually-downloadable and stored with their own hashes) and searching (md5 search logic would have to change from search == image.hash to search in image.hashes or search in map(lambda i: i.hash, image.versions)), that could possibly prove to be messy.

However, I'm going to have to disagree on #2 on the basis of two emerging projects:

A. WebAssembly (WASM) - a new and official W3C-drafted web technology, which is a JVM-alike ABI for running binary executables in the web browser in a safe and portable fashion. They plan to make it feature-compatible with that of a CPU instruction set, which means you could take an existing C/C++/Fortran codebase for a game, and change the compile target to .wasm to target web browsers (and they've already done successful tests of this concept with a unity game called 'tanks'). There's already an MVP out and the draft is coming along nicely. So it wouldn't be a stretch at all for someone to implement an open source flash player in webassembly, which a site like newgrounds or e621 could then deploy with flash content to be able to run it 100% in HTML5. You'd be serving the flash player and the flash content, and it's also not a stretch that this could happen before late 2020 when flash plugin support is to be removed from modern browsers.

B. open-source-flash - Since adobe has "given up" with flash the plugin, either they will be the ones to implement a free-to-use, proprietary wasm flash player, or they will be the ones to open source their technology so that an open source guy can make a FOSS wasm flash player.

This also raises the question of whether e621 will allow uploads of interactive WASM and JS+HTML5 content moving forward. NewGrounds, for instance, allows HTML5 games to be uploaded as a .zip containing an index.html and all the code+resources to run it.

I really wouldn't mind having file history ala something like mediawiki, because that would also allow users to compare earlier inferior versions themselves with deleted posts where reason hasn't been DNP related. But like said, as this isn't file hosting site and most of the stuff here will only ever have single version, it's not exactly top priority to recode huge portion of the software to accommodate this. Even derpibooru, the site which is using same base software, seems to have been build smartly from start and has tons of features we are missing, still has to delete older posts in favor of new ones as well.

I would really like this a lot as well as flash thumbnails. It would also get rid of the "my post was stolen" arguments because we have to delete inferior posts now. With flashes thumbnails would ease checking older content, webm thumbnails were godsend for this and we had to wait for those years already. But I'm also bit realistic with the situation and if I have understood correctly this is massive undertaking to fix and we do not have massive programming team.

So I almost feel like file file history should be completely seperate feature request as that touches more than just flash files and I feel like that has been already requested. I know flash thumbnails have been requested, forum #247587.

I'm also sure there has been talk about supporting interactive content outside flash content, but can't find anything right now. Biggest issues being security and non-standartized nature related talk.

Mairo said:
I would really like this a lot as well as flash thumbnails. It would also get rid of the "my post was stolen" arguments because we have to delete inferior posts now.

Well, at the very least, I'm glad I could shed a positive life on Flash's EOL status. I don't imagine deploying a WASM flash player would be an issue, either, as whoever makes it is probably going to include, on the project page, a wrapper, instructions and a demo for how to serve the player with an swf file.

With flashes thumbnails would ease checking older content, webm thumbnails were godsend for this and we had to wait for those years already. But I'm also bit realistic with the situation and if I have understood correctly this is massive undertaking to fix and we do not have massive programming team.

As a programmer, I certainly wouldn't recommend attempting to autogen a thumbnail for flash content. Not even steam and newgrounds attempt to do that, and they're big players in the interactive content game.

For webm and gif, it's easy, because you only have to process it once and pull out a frame, which goes something like frame_to_capture = frames[floor(total_frames / 2)]. But flash doesn't make things easy, because there is no way to tell, programmatically, when the swf will reach a point that is "screenshot-worthy". For example, you might get stuck behind a loading screen. This is an example of the halting problem, which is why I suggested letting human editors (or at the very least, volunteers/staff) upload a custom thumbnail, and otherwise defaulting to the default thumbnail (or http://static1.e621proxy.ru/images/download-preview.png when there is no thumbnail). The thumbnail wouldn't need an md5sum attached to it, and could be stored using the image's md5sum. In fact, I probed around and it turns out e621 already does this, ostensibly for the purpose of saving bandwidth, as the thumbnails are stored individually, and always in a compressed JPEG format.

Images are stored in...

.

While thumbnails are stored in...

preview/{md5[0:2]}/{md5[2:4]}/{md5}.jpg

Example: given the md5sum a57aa399b2a60a0c83ff4ddb5cc845ad and the knowledge that the associated image is a PNG, you can find the image here and the thumbnail here

I.e. implementing the ability to upload a custom thumbnail would be as simple as adding an "upload new thumbnail" field to the upload/edit forms that accepts either nothing or a {10-150}x150 JPEG, and using the submitted thumbnail image to overwrite the associated file in /data/preview/.

In other words, the plumbing is already there. Guys, this could actually work!

I know flash thumbnails have been requested, forum #247587.

Noted.

Such files don't exist for flash currently, though, eg. http://static1.e621proxy.ru/data/preview/8c/c4/8cc4b60ddee2cf89cd9149f60252fcef.jpg is an empty file, not a copy of generic 'Flash' image that would be assigned to http://static1.e621proxy.ru/data/8c/c4/8cc4b60ddee2cf89cd9149f60252fcef.swf

So a 2 stage deployment, where the first stage is "copy/symlink the generic 'Flash' image to the appropriate thumbnail location for each flash file, make sure this is also applied for new Flash uploads, and then treat Flash thumbnails the same as ordinary thumbnails (ie. actually point to the individual thumbnail image).".
That would increase bandwidth usage by a small amount, because this generic image would have to be downloaded N_THUMBNAILS times rather than once. (say your page size was 320 and the entire page was Flash, then it would be 2.7mb rather than 8.59k). But this is easily comparable to the amount of bandwidth custom thumbnails would use, or the situation with ordinary image thumbnails currently.

And the 2nd being allowing the thumbnail to be replaced when uploading (explicitly only for Flash files, IMO)

savageorange said:
Such files don't exist for flash currently, though, eg. http://static1.e621proxy.ru/data/preview/8c/c4/8cc4b60ddee2cf89cd9149f60252fcef.jpg is an empty file, not a copy of generic 'Flash' image that would be assigned to http://static1.e621proxy.ru/data/8c/c4/8cc4b60ddee2cf89cd9149f60252fcef.swf

So a 2 stage deployment, where the first stage is "copy/symlink the generic 'Flash' image to the appropriate thumbnail location for each flash file, make sure this is also applied for new Flash uploads, and then treat Flash thumbnails the same as ordinary thumbnails (ie. actually point to the individual thumbnail image).".
That would increase bandwidth usage by a small amount, because this generic image would have to be downloaded N_THUMBNAILS times rather than once. (say your page size was 320 and the entire page was Flash, then it would be 2.7mb rather than 8.59k). But this is easily comparable to the amount of bandwidth custom thumbnails would use, or the situation with ordinary image thumbnails currently.

And the 2nd being allowing the thumbnail to be replaced when uploading (explicitly only for Flash files, IMO)

I did figure that out, and edited my post to mention it, and with normal server-side best-practices in play, it wouldn't be a problem. For example (more pseudo-python): if http_get(preview_path).status == 404: return http_get(default_path) where default_path is http://static1.e621proxy.ru/images/download-preview.png and preview_path is the example that you showed.

So symlinking won't be necessary, because the server-side script that builds the post list pages needs only check that it exists and default to our default_path if no. Actually, it would probably be stored in a database record in the first place.

Also, if the thumbnails are required to be at most 150x150 JPEG files, then there's no way the size is going to get larger than a few KB in size. If each pixel contains 32 bits (RGBA) of information, then the upper bound for a 150x150 JPEG thumbnail's size should be (32 * 150^2) / 8 = 90KB. Bear in mind that JPEGs are compressed, so 90KB would be the upper limit. A more typical thumbnail would average at about 7-15KB. So I fail to see what you mean by custom thumbnails being comparable to several megabytes. If a size limit of 150x150 is enforced, it should be impossible for a single JPEG's data segment to exceed exactly 90,000 bytes in size, and there shouldn't be a size difference between a custom thumbnail and an auto-generated one.

So I'm not sure if you're arguing for or against custom thumbnails, but whatever the case, I hope I've satisfactorily addressed your concerns regarding bandwidth :)

And the 2nd being allowing the thumbnail to be replaced when uploading (explicitly only for Flash files, IMO)

Yes, I agree that custom thumbnails should be limited to flash files, since they are the only media type where generating a decent thumbnail is not feasible. Although I certainly wouldn't object to allowing the same for GIF and WEBM files. Perhaps those should be done like YouTube: generate a few preliminary thumbnails out of various frames at key points in the video, and have the uploader choose the best-looking one.

I don't find it acceptable to let Adobe, browser makers or anyone else dictate "end of life" for decades of artistic content on the web. No matter what those large tech companies say or do, that content remains valid and valuable and worth preservation and maintenance.

Arrow189 said:
I don't find it acceptable to let Adobe, browser makers or anyone else dictate "end of life" for decades of artistic content on the web. No matter what those large tech companies say or do, that content remains valid and valuable and worth preservation and maintenance.

You might find this to be of interest, then.

hungryman said:
I did figure that out, and edited my post to mention it, and with normal server-side best-practices in play, it wouldn't be a problem. For example (more pseudo-python)

I knew you were a Pythonista. The slice syntax gave it away ;)

So I'm not sure if you're arguing for or against custom thumbnails, but whatever the case, I hope I've satisfactorily addressed your concerns regarding bandwidth :)

I didn't have any concerns regarding bandwidth, nor did I intend to say that any one individual thumbnail would reach 2.7mb in size.
I pointed out that 320 copies of the default Flash thumbnail, which are 8.59k, would be downloaded individually and cached individually (320*8.59k ==2748k or 2.7mb), since they would have different URLs; the bandwidth (and client side cache space) used for 'having 1+ flash thumbnail on the page' would go from 8.59 to (N*8.59).

Within the context of that, your comments appear to say that the cache space and bandwidth could be made to only increase when a custom thumbnail is used (IOW, the generic thumbnail would only ever be downloaded once.. which is the current situation). Via special casing.

That's certainly technically better. I was focused on reducing the solution to something as simple as possible to do (so that there's a chance something actually gets done) -> intentionally no special casing, just throw duplicate files at it :) Or as you point out, there's a similar strategy you could do with duplicate database rows (the database isn't currently involved in thumbnail lookup, I think, and I suspect that is a good thing from admin's point of view.)

Perhaps those should be done like YouTube: generate a few preliminary thumbnails out of various frames at key points in the video, and have the uploader choose the best-looking one.

.. With some default selection, that sounds reasonable.

In saying 'only flash', I wanted to avoid creating unnecessary maintenance (eg. opening up the possibility that people would upload abusive or simply incorrect thumbnails), and also reduce the complexity of the task.

savageorange said:
I knew you were a Pythonista. The slice syntax gave it away ;)

The lambda, too, hehe.

Within the context of that, your comments appear to say that the cache space and bandwidth could be made to only increase when a custom thumbnail is used (IOW, the generic thumbnail would only ever be downloaded once.. which is the current situation).

Correct.

Via special casing.

That's certainly technically better. I was focused on reducing the solution to something as simple as possible to do (so that there's a chance something actually gets done) -> intentionally no special casing, just throw duplicate files at it :)

I see, but tbh I don't consider the following to be a special case:

def get_thing(address):
    result = {}
    
    ...
    
    if is_invalid(result):
        return DEFAULT_THING
    
    return result

Special casing--at least in the form you seem to be using it--is when you code yourself into a corner and decide to solve the problem by adding inline non-generic checks at the high level instead of fixing it at the lower level where the problem exists. Though it's possible the former is what you interpreted from the earlier pseudo-code, which, yeah, that would be grotesque. IMO, special casing is a code smell.

Do note that this is distinct from languages where a function can be defined multiple times with different types (or even values) of inputs, like in Erlang:

%% Courtesy of Wikipedia
 
-module(qsort).
-export([qsort/1]).
 
qsort([]) -> [];
qsort([Pivot|Rest]) ->
    qsort([Front || Front <- Rest, Front < Pivot]) ++ 
    [Pivot] ++
    qsort([Back || Back <- Rest, Back >= Pivot]).

or in Java, with function overloading:

public int something(int a, int b){
    return Math.pow(a, b + 1);
}
public double something(double a, double b){
    return Math.pow(a, b + 1.0);
}
...
something(2, 4); // 32
something(2.3, 4.7); // 115.31

Sorry, tangent.

In saying 'only flash', I wanted to avoid creating unnecessary maintenance (eg. opening up the possibility that people would upload abusive or simply incorrect thumbnails), and also reduce the complexity of the task.

Technically, the feature request does state "Flash (and other media with all-white thumbnails) posts should be able to be given a custom thumbnail.", so no argument here :)

hungryman said:

Special casing is when you code yourself into a corner and decide to solve the problem by adding inline non-generic checks at the high level instead of fixing it at the lower level where the problem exists.

Yeah, I probably should have just said 'a conditional'.

Technically, the feature request does state "Flash (and other media with all-white thumbnails) posts should be able to be given a custom thumbnail.", so no argument here :)

Are there any other media types with all-white thumbnails currently?

I think WebMs used to, but they have proper thumbnails now.

savageorange said:
Are there any other media types with all-white thumbnails currently?

I think WebMs used to, but they have proper thumbnails now.

Not that I know of, but you can never be too careful ;)

Adobe is dropping Flash at the end of 2020. What will happen to all the SWF files on e621.net? Browsers are already starting to block flash. - October 8, 2019
https://www.blog.google/products/chrome/saying-goodbye-flash-chrome/

At least there seem to be some SWF to WEBM converters available. https://convertio.co/swf-webm/
But the posters will need to convert their content so it can be viewed before downloading.

Firefox is blocking Flash. Chrome will block.
For now, Internet Explorer 11 is still supporting Flash... except that IE 11 is giving error messages about not supporting WEBM.

Zetazoop said:
What will happen to all the SWF files on e621.net? Browsers are already starting to block flash.

Good news! You don't have to use your browser to run Flash content!

Please at least bump the more recent thread rather than necro a thing from over a year ago.

Hey guys... Mankind here.

I know that a few of you, might unappreciate Flash. Favoring HTML5 content.

What I can't seem to figure out, is the will of anyone, to talk about how great something is one moment, then say something is complete trash the next.

EXAMPLE:

THEN:

GENESIS DOES WHAT NINTENDON'T

NOW:

FLASH DOES WHAT HTML5 DON'T

i.e.: The ability, to download Flash files, direct from the web page or website.

Some of us, seem to be transitioning, from Flash to Unity. Creating APK's. (Android Package Kits)
I, am in the middle, of such a transition.

I am also trying to understand, how the A.P.K. file Is able to achieve, Content, & HTML5 seperation, through layering.

EXAMPLE:

Top Layer: Unity Game.

Middle Layer: Downloadable Compatibility.

Bottom Layer HTML5 Code.

On that note, it seems like the A.P.K., wins by several miles over HTML5.