Every once in a while there's an image posted that is excessively, inexcusably large.
I don't mean in a superabsurd_res sense, but in terms of file size per megapixel.
This popped up the other day as an example;
post #1184040
It's effectively a bitmap at 49MB.
This one even adds insult to injury since the artist left an unused alpha channel in there that automatically increased the file size by 30%.
We do have a 'View reduced sample' option, though it's useless here due to the panorama aspect ratio.
Running it through PNGGauntlet reduced the size from 50984kb to 8594kb. That is SIX TIMES SMALLER, or 41 EFFIN' MEGABYTES less bandwidth consumed.
TL;DR We could really use some kind of standardized guidelines for dealing with poorly-optimized images, and a way of archiving the original MD5 hash after compressing.
What's considered 'Large'
The easiest way I could think to judge is just dividing the number of Megapixels by the size in MB.
Width * height / 1,000,000 / files size
With .PNG files this results in a number usually between 0.26 and 5
0.26 -bitmap equivalent w/ alpha channel
0.35 -bitmap equivalent
~0.5 -unoptimized png
~0.75-1.0 typical optimized photo or detailed paintings
~1.5 Typical 'generic' furry art
3.0+ efficiently compressed line/gradient/pixel/glitch art
This could easily be calculated with a script.
Some examples
post #348816 Evalion's mascot
Before 37198kB After 1660 kB
22 times smaller or 35 MB less bandwidth
post #318592 Old mlp comic, again the reduced sample is useless due to the aspect ratio
Before 35217kB After 4128kB
8 times smaller or 35 MB less bandwidth
post #690023 seriously wtf is up with ponies and massive PNGs they're like half the search results
Before 81000kB After 73460kB
This is actually a *GOOD* example of one that's fairly well compressed despite being the largest image on e6. I cut the file size by 10% or "only" 7 MB and it took all day.
Updated by Mairo
