well, mostly it helps with loading pages or images on slower connections. also it helps anyone who wants to save an image from the wiki by ensuring that it's not unnecessarily bloated, as most pngs are, especially screenshots taken directly from minecraft. all of this is done losslessly btw, so there isn't any downgrade in quality whatsoever. looking at some of the images i've come across, i'm not the first person to do this, and i'm not even the first person to use fileoptimizer to do it. also, a lot of what i've been doing has been editing pictures by cropping them down to the image itself (as some have extra white space or transparent space on them for no reason), making or remaking images transparent (as some of them have been done poorly and have blur around the edges), cropping pictures down to the relevant part of it (especially with gui elements) and cleaning up and properly formatting references (which is something i'll focus on when i've finished up optimizing more images, alongside trying to track down missing version of minecraft and/or screenshots & footage of it).
if you wanna do the same thing, feel free to do so! c:
also, i will say that if people want me to stop optimizing images, or to stop optimizing certain images, i'll be fine with doing so, i just wanna help cleanup a wiki that i've been using for around 8 or so years lol
Well, in my opinion, all people browsing here should not have like 128 Kbps connections any more. A difference of some tens of kilobytes is not that significant unless you want to cram a large number of images on one page, which is rare, at least on this wiki. If that was an issue, then everything should have employed ways to shrink the size down on export/receive already.
Another thing to note is that MediaWiki stores all past revisions of all pages/files. That means when you upload an optimized image, you are taking more storage space in the server rather than saving it. So you should make sure that the size difference between the old image and the new one is reasonable before deciding to upload.
Those are just my few thoughts, if you feel doing this is good then you are perfectly fine to keep doing so.
>cram a large number of images on one page, which is rare, at least on this wiki
No, its not rare at all, look at pages like Spawn egg or Villager. I can just feel my data count getting smaller whenever I'm viewing pages like this when not on wifi, so optimizing is a good idea, especially if its like 3MB→500kB.
Those images found on the pages you mentioned are really small, "optimizing" them will save only very few kilobytes at most, thus in total the size decrease for the whole page still falls under 100 KB. The page that is worth optimizing here is Far lands, full of high-resolution screenshots.
On the other hand, you can count the number of pages with many images on this wiki, including ones with small images like Spawn egg, and divide the number by total pages, I believe the result will be under 2%, or eventually 1%.
I wonder what are the benefits of optimizing the images on this wiki that you are currently doing...
well, mostly it helps with loading pages or images on slower connections. also it helps anyone who wants to save an image from the wiki by ensuring that it's not unnecessarily bloated, as most pngs are, especially screenshots taken directly from minecraft. all of this is done losslessly btw, so there isn't any downgrade in quality whatsoever. looking at some of the images i've come across, i'm not the first person to do this, and i'm not even the first person to use fileoptimizer to do it. also, a lot of what i've been doing has been editing pictures by cropping them down to the image itself (as some have extra white space or transparent space on them for no reason), making or remaking images transparent (as some of them have been done poorly and have blur around the edges), cropping pictures down to the relevant part of it (especially with gui elements) and cleaning up and properly formatting references (which is something i'll focus on when i've finished up optimizing more images, alongside trying to track down missing version of minecraft and/or screenshots & footage of it).
if you wanna do the same thing, feel free to do so! c:
also, i will say that if people want me to stop optimizing images, or to stop optimizing certain images, i'll be fine with doing so, i just wanna help cleanup a wiki that i've been using for around 8 or so years lol
Well, in my opinion, all people browsing here should not have like 128 Kbps connections any more. A difference of some tens of kilobytes is not that significant unless you want to cram a large number of images on one page, which is rare, at least on this wiki. If that was an issue, then everything should have employed ways to shrink the size down on export/receive already.
Another thing to note is that MediaWiki stores all past revisions of all pages/files. That means when you upload an optimized image, you are taking more storage space in the server rather than saving it. So you should make sure that the size difference between the old image and the new one is reasonable before deciding to upload.
Those are just my few thoughts, if you feel doing this is good then you are perfectly fine to keep doing so.
>cram a large number of images on one page, which is rare, at least on this wiki No, its not rare at all, look at pages like Spawn egg or Villager. I can just feel my data count getting smaller whenever I'm viewing pages like this when not on wifi, so optimizing is a good idea, especially if its like 3MB→500kB.
(In response to Nixiova...)
Those images found on the pages you mentioned are really small, "optimizing" them will save only very few kilobytes at most, thus in total the size decrease for the whole page still falls under 100 KB. The page that is worth optimizing here is Far lands, full of high-resolution screenshots.
On the other hand, you can count the number of pages with many images on this wiki, including ones with small images like Spawn egg, and divide the number by total pages, I believe the result will be under 2%, or eventually 1%.