Does anyone know the exact file size limit here on e621?

Somewhat odd that it's not expressed in the file upload page or the upload wikis (1) (2)

_
At least 76.1 MB, said to be up to 100 MB. Supposedly there are plans to increase to 300 MB for WebMs and the like. But I could not find anything as far as an exact number.

edidaf said:
This one is 75 mb post #624780

treos said:
that reminds me, i asked NMNY about this last week when i uploaded that dick souls video and he said:

"Videos are only allowed to be in the .webm format (basically a different mp4 version) and have a theoretical file limit of 300mb, but that seems to not work right now, but anything under 100mb should work without a problem."

so yeah, it's fairly high currently but may be up to 300mb at some point.

parasprite said:
We'd still like to increase it (at least for videos) since we have plenty of disk space and bandwidth to spare, it just hasn't been done yet. I don't have a timeframe to give you but the figure I keep hearing is around 300 MB (note that the exact number is still subject to change ;) ).

Source: https://e621.net/forum/show/162203

I've done testing and verified that the limit is actually 80MB (OS X, some Linux distros) or 76.29MiB (Windows, OS X before 10.6). The difference in number here is whether the OS defines "1 kilobyte" as "1024 bytes" or "1000 bytes", but the absolute size is still the same (it just depends on which one you see).

Where this number comes from... I haven't quite been able to figure out yet. I've been working to make values like this more accessible to us as well as update the help pages (some of which have outdated info) to automatically reflect these values, but it's been a slow process as some of it has gotten pretty obfuscated over the years. :/

parasprite said:
I've done testing and verified that the limit is actually 80MB (OS X, some Linux distros) or 76.29MiB (Windows, OS X before 10.6). The difference in number here is whether the OS defines "1 kilobyte" as "1024 bytes" or "1000 bytes", but the absolute size is still the same (it just depends on which one you see).

Where this number comes from... I haven't quite been able to figure out yet. I've been working to make values like this more accessible to us as well as update the help pages (some of which have outdated info) to automatically reflect these values, but it's been a slow process as some of it has gotten pretty obfuscated over the years. :/

Alright then, keep at it.

don't know the file size but i know i've gone past the resolution limit before (bvats > certain comics NEED to be chopped up to be posted here). it's beyond absurd res.

parasprite said:
The difference in number here is whether the OS defines "1 kilobyte" as "1024 bytes" or "1000 bytes"

1024 über alles.

Someday, e621 will let us upload this 12 gb GIF:
http://tech.slashdot.org/story/15/10/03/1429237/artists-create-a-1000-year-gif-loop

"The 12 gigabyte GIF is made of 48,140,288 numbered frames, that change about every 10 minutes"

so once every 10 minutes it'd change to the next frame or something? not sure why it'd have to be so super slow.

oh well, this seems like something someone could only really get any enjoyment out of if they had a spare computer that they could keep running forever and dedicate it solely to this gif. that or just like that nyan cat gif, it could simply be hosted as an eternal webpage or something. one that doesn't reset/refresh the entire loop if you leave or refresh the page that is.

treos said:

so once every 10 minutes it'd change to the next frame or something? not sure why it'd have to be so super slow.

Because a 1.6[o]66[/o]-year gif loop doesn't sound nearly as impressive.

parasprite said:
I've done testing and verified that the limit is actually 80MB (OS X, some Linux distros) or 76.29MiB (Windows, OS X before 10.6). The difference in number here is whether the OS defines "1 kilobyte" as "1024 bytes" or "1000 bytes", but the absolute size is still the same (it just depends on which one you see).

Where this number comes from... I haven't quite been able to figure out yet. I've been working to make values like this more accessible to us as well as update the help pages (some of which have outdated info) to automatically reflect these values, but it's been a slow process as some of it has gotten pretty obfuscated over the years. :/

Ugh, damn SI screwing up the definition of a kilo/mega/giga/tera/petabyte. Life was good back when a megabyte was 2^20 bytes, instead of this crap 1,000,000 bytes definition we have these days. And the so-called "binary prefixes"? Yeah, those sound ridiculous. Mebibyte? Doesn't exactly roll off the tongue, there.

ShylokVakarian said:
Ugh, damn SI screwing up the definition of a kilo/mega/giga/tera/petabyte. Life was good back when a megabyte was 2^20 bytes, instead of this crap 1,000,000 bytes definition we have these days. And the so-called "binary prefixes"? Yeah, those sound ridiculous. Mebibyte? Doesn't exactly roll off the tongue, there.

The SI has nothing to do with the fact that manufacturers prefer to pick whatever makes the numbers on their products look bigger, as well as the fact that the SI prefixes are approximately 200 years older than the use of them for a binary system.
It's also the fault of the IEC in conjunction with the ISO that you have mibibyte and megabyte, the SI convention stays far, far away from anything concerning computers, as they only care about natural forces and the measurement/description of those, not about mathematical units used in computer sciences.

Past that it's technically a good thing that the differences between the traditional base 10 and base 2 prefixes is established by the IEC/ISO, it's a bad thing that software and hardware creators think it's funny to do whatever the fuck they please and to ignore both or either based on a damn coin throw. Really hilarious is it if they change what they use inside their own distro or from one program to another, while not labeling it properly.

NotMeNotYou said:
The SI has nothing to do with the fact that manufacturers prefer to pick whatever makes the numbers on their products look bigger, as well as the fact that the SI prefixes are approximately 200 years older than the use of them for a binary system.
It's also the fault of the IEC in conjunction with the ISO that you have mibibyte and megabyte, the SI convention stays far, far away from anything concerning computers, as they only care about natural forces and the measurement/description of those, not about mathematical units used in computer sciences.

Past that it's technically a good thing that the differences between the traditional base 10 and base 2 prefixes is established by the IEC/ISO, it's a bad thing that software and hardware creators think it's funny to do whatever the fuck they please and to ignore both or either based on a damn coin throw. Really hilarious is it if they change what they use inside their own distro or from one program to another, while not labeling it properly.

Computers do not run in decimal. It doesn't make sense to report the amount of data they store in decimal. And back before any of this decimal vs binary crap, it was widely accepted that a kilobyte was 2^10 or 1024 bytes. Megabyte was more controversial, but at least you had good sounding names for everything, not this artificial XXbi- crap. It doesn't even sound remotely good enough.

Not to mention the fact that the decimal system itself sucks in comparison to the dozenal system. Sure, it's a bit confusing at first, but I can definitely see the benefits of using it.

ShylokVakarian said:
Computers do not run in decimal. It doesn't make sense to report the amount of data they store in decimal. And back before any of this decimal vs binary crap, it was widely accepted that a kilobyte was 2^10 or 1024 bytes. Megabyte was more controversial, but at least you had good sounding names for everything, not this artificial XXbi- crap. It doesn't even sound remotely good enough.

Not to mention the fact that the decimal system itself sucks in comparison to the dozenal system. Sure, it's a bit confusing at first, but I can definitely see the benefits of using it.

I never said computers run in decimal, I said the programmers use base 10 or base 2 notations how they please, converting them is trivial for a computer, it's just that the choice which is to be displayed is widely random.
And as I said, it's a marketing ploy, go complain to the CEOs and marketing departments of HDD creators. The software engineers generally tend to only follow instructions in those matters.

Also, there are pros and cons for any system from base 2 to base 24, base 10 has the big advantage that people tend to have 10 fingers, so it stuck around and will continue to stick around. The other options have specific uses and advantages as well, so we aren't going to see any of them go away anytime soon.

Also, there are pros and cons for any system from base 2 to base 24, base 10 has the big advantage that people tend to have 10 fingers, so it stuck around and will continue to stick around. The other options have specific uses and advantages as well, so we aren't going to see any of them go away anytime soon.

http://io9.com/5977095/why-we-should-switch-to-a-base-12-counting-system

Hmm, count to 10, or count to 144...

ShylokVakarian said:
http://io9.com/5977095/why-we-should-switch-to-a-base-12-counting-system

Hmm, count to 10, or count to 144...

Or count to 1023. Base 2 wins by the power of exponential growth (a digit in dozenal can go higher than a digit in binary, but you get one dozenal digit per hand and one binary digit per finger).

ShylokVakarian said:
http://io9.com/5977095/why-we-should-switch-to-a-base-12-counting-system

Hmm, count to 10, or count to 144...

I can count up to 1023 already using binary, and I don't even have to rely on counting phalanges.

Snowy said:
Or count to 1023. Base 2 wins by the power of exponential growth (a digit in dozenal can go higher than a digit in binary, but you get one dozenal digit per hand and one binary digit per finger).

Yeah, I decided not to mention that, as it might blow his mind. :P

ShylokVakarian said:
Yeah, I decided not to mention that, as it might blow his mind. :P

The only way you could blow my mind is if you'd start seeing past the application of a numbering system in a mathematical void. You'd need to rewrite almost all code to display the proper numbers, at the same time teach that to a couple billion people (we aren't even adhering to simple standards for things like temperature yet), only to realise that it only makes a difference to less than 3% people, all of them strictly mathematicians.

I'm full well aware of the advantages, but I'm also realistic about real world applications of a) a wide change in anything for the entire western world b) what most people need on the job.
Literally every working person on this planet that uses math for a living uses a calculator because you're outside of integer numbers and need floating point operations, or the numbers are too large/small for average Joe anyway. The only people who will see an improvement or any change are theoretical mathematicians who can just do their own thing at that point.

There may be a small improvement for garage sales but past that? Calculators and computers. And these don't give a shit how they convert the binary.

NotMeNotYou said:
The only way you could blow my mind is if you'd start seeing past the application of a numbering system in a mathematical void. You'd need to rewrite almost all code to display the proper numbers, at the same time teach that to a couple billion people (we aren't even adhering to simple standards for things like temperature yet), only to realise that it only makes a difference to less than 3% people, all of them strictly mathematicians.

I'm full well aware of the advantages, but I'm also realistic about real world applications of a) a wide change in anything for the entire western world b) what most people need on the job.
Literally every working person on this planet that uses math for a living uses a calculator because you're outside of integer numbers and need floating point operations, or the numbers are too large/small for average Joe anyway. The only people who will see an improvement or any change are theoretical mathematicians who can just do their own thing at that point.

There may be a small improvement for garage sales but past that? Calculators and computers. And these don't give a shit how they convert the binary.

I was joking, I did not mean what I said about it possibly blowing your mind.

Still, I very much prefer the binary definition of *byte. There is one thing you must admit, though: The so-called binary prefixes they "created" sound incredibly stupid.

ShylokVakarian said:
I was joking, I did not mean what I said about it possibly blowing your mind.

Still, I very much prefer the binary definition of *byte. There is one thing you must admit, though: The so-called binary prefixes they "created" sound incredibly stupid.

They do sound stupid. But you can improve them by yelling them with a fake German accent.

NotMeNotYou said:
They do sound stupid. But you can improve them by yelling them with a fake German accent.

...What can't Germany solve?

Yeah, let's go ask Germany what they think. :D

ShylokVakarian said:
http://io9.com/5977095/why-we-should-switch-to-a-base-12-counting-system

Hmm, count to 10, or count to 144...

That article wasn't particularly compelling, I hate to say. Most of the advantages it offered were either essentially insignificant, stupid, or cherry-picked.

"Look, 1/3rd no longer results in a repeating decimal!"

Yeah okay. What about 1/5th?

"Children can do more fun things with 12 sticks than 10!"

Okay, give them twelve sticks then. It's not like the number 12 doesn't exist in the base ten system.

"Mathematicians can make use of the base 12 system!"

What's stopping them?

"You can count higher on your fingers!"

We can already do that much more effectively with binary.

Can we just go back to the times where we reported the exact number of bytes? For example, the upload size limit would be 80,000,000 bytes? Then there's no confusion on whether we mean 1000 bytes or 1024 bytes. And we don't have to screw around with prefixes, making it much less likely for debates on whether a kilobyte should mean 1000 bytes or 1024 bytes to happen.

The only time I would say it's completely fine to use binary is when it actually has a natural reason, e.g. when dealing with CPUs, memory addressing (e.g. RAM, due to connection with CPU), and other low level hardware. In all other cases decimal should work just fine. Disk and file sizes do not naturally come in a base 2 format, they take on arbitrary sizes. Using base 10 there also has an added bonus of adhering to hard disk manufacturer standards which use base 10 for disk sizes.

By the way, is someone up for using the floppy drive 1.44 "MB" aka 1.44*1000*1024 bytes format?

ShylokVakarian said:
Can we just go back to the times where we reported the exact number of bytes? For example, the upload size limit would be 80,000,000 bytes? Then there's no confusion on whether we mean 1000 bytes or 1024 bytes. And we don't have to screw around with prefixes, making it much less likely for debates on whether a kilobyte should mean 1000 bytes or 1024 bytes to happen.

I see your point but I would not really find that much better, the whole point of prefixes is to easily determine order of magnitude. That in combination with rounding gives one an easy overview of one's file sizes at a glance. If one want more detailed information than that, open up a CLI.

In addition, for me, coming from a country using metric units, I would never call a 1024 prefix "kilo" without somehow specifying that it is a binary prefix. It just wouldn't happen, it would be like calling 1 kilogram 1024 grams. When I say 1 kilobyte I mean 1000 bytes, always have always will. Call me stubborn but I won't change my mind when it comes to that and I know very well that a lot of people disagree with me.

Chessax said:
By the way, is someone up for using the floppy drive 1.44 "MB" aka 1.44*1000*1024 bytes format?

Not the hybrid megabyte, god no. That was a total blunder.

parasprite said:
I've done testing and verified that the limit is actually 80MB (OS X, some Linux distros) or 76.29MiB (Windows, OS X before 10.6). The difference in number here is whether the OS defines "1 kilobyte" as "1024 bytes" or "1000 bytes", but the absolute size is still the same (it just depends on which one you see).

Where this number comes from... I haven't quite been able to figure out yet. I've been working to make values like this more accessible to us as well as update the help pages (some of which have outdated info) to automatically reflect these values, but it's been a slow process as some of it has gotten pretty obfuscated over the years. :/

I just wanted to give an update related to this.

It turns out that the site doesn't actually limit file sizes (for the most part*), the file size limit we've been seeing was what happened to be set on Cloudflare. I've reworked it to actually take file size into account. This includes separate settings for Flash and Webm. ;)

Also, since the current behavior of "time out and/or display a vague server error page if you try to upload something too big" is not only confusing, but actually extremely unhelpful, I've replaced it with a more friendly message letting you know why the upload failed as well as what the max size is currently set at (it works for both file size and resolution).

Hopefully this should help clear things up. :)

I tried to upload an image that is 4MB in size and it says "Error: File dimensions too big" :(

cowboy_brony said:
I tried to upload an image that is 4MB in size and it says "Error: File dimensions too big" :(

That means the width or length is higher than 15000px.