none
Whoa there I’ve been active on these old, archived Village Pump discussions and am not aware of a “decision” that said animated GIFs over the 12.5 MP limit “will no longer be allowed”. It is a convoluted thread there and a “decision” might be buried in there, but I can’t find it.
As far as I know, this is a temporary bug being worked on. This technical issue with animations is a complex matter pertaining to the way Wikipedia’s server engines scale animations. This particular animation is only 260,560 bytes and has only 42 frames. Note that I didn’t make it, but am expert on animations and see that the author A) did a magnificent job making it compact, and B) had the misfortune of making it higher resolution than would ever be used on a page and, thus, it always needs scaling.
This need for scaling never used to be a problem. However, a developer recently “threw a software switch” to handle this scaling on Wikipedia (instead of offloading the task to browsers). This was because of our category pages, some of which have hundreds of thumbnails. Offloading such a huge number of animations to scale to browsers was burdening them and increasing their RAM requirements. Unfortunately, because of the current (very simplistic) software sever tools being used after the change, scaled versions of otherwise exceedingly compact animations are causing problems for Wikipedia’s servers. We need better software and this sort of stuff comes from volunteer programmers; big updates don’t come fast.
It seems that this Commons category (titled “Animated gifs violating 12.5MP rule”) was created by the nominator here (Esemono). Note the “violating” and “rule” in the title. But, as far as I can tell, the developers working on this problem would call this issue an active “bug”; something they are trying to fix.
I’ve gone to Village Pump, ( here, where the issue is still being worked), to clarify this. In the mean time, Esemono, please provide a more specific link or quote a relevant passage from the Village Pump archive that looks like a “ruling”, “decree”, and “will no longer be allowed” and doesn’t instead look like a bunch of efforts to develop a long-term solution. For that matter, would you mind pointing out where, on the current Village Pump discussions, it appears to you that developers are not working hard on this bug. If there was to be a “ruling”, “decision”, or “decree”, I should think there would have been a wider RfC on this issue and I’m not seeing it yet.
In the mean time, I would certainly suggest that the FP community not be voting to delist these otherwise fine animations just because they currently don’t work; not until it is clear that the developers have thrown up their hands and declared defeat. As far as I know, they are actively working hard at a solution to this. Greg L ( talk) 13:37, 8 May 2010 (UTC)
P.S. I can always take this animation, shrink it to the size it is typically used in articles, and create a version that requires no scaling. We can then have a vote here to replace it with the updated version—not delist it as an FP. Before we do that though, I suggest we throttle back, allow our jets to cool, and see where the developers think they are going. Very recently, I suggested they consider biting the bullet and adding the capability of doing what I described here on-the-fly by the server software.
Greg L (
talk)
14:36, 8 May 2010 (UTC)
EDITED CONVERSATION OF THIS THREAD [1]: The changes were explicitly made to avoid the crashing of the scale routines of the servers. I doubt the deployment of GIF scaling will be reverted yet again. We don't allow PNG images of 12 million pixels, and now we don't allow GIF images of over 12 million pixels either. I suggest we focus on finding ways to better deal with these large GIFs, but honestly, any animated GIF of this size, should probably never be presented to users. (And never have been). — TheDJ ( talk • contribs) 19:14, 6 April 2010 (UTC)
- Never have been? According to whom? My large animated images have been featured for years, and have been located in articles. There is a use, sometimes, for making a large animated image. -- Golbez ( talk) 03:52, 9 May 2010 (UTC)
- For the origin of the 12.5 megapixel limit, see http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019681.html -- I guess it's a tradition by now... -- AnonMoos ( talk) 20:46, 6 April 2010 (UTC)
- Wow. That's 4.5 years ago. From the Moore's Law article it's unclear to me whether that is two or three doublings of RAM memory storage, but that would mean an equivalent limit today should be 50 million to 100 million pixels. This would allow an animation 1.6 to 3.2 times larger than the one in the example above. Wnt ( talk) 20:58, 6 April 2010 (UTC)
- I doubt my Sony Ericsson phone browser is that smart. And Safari 3 and earlier was terrible with larger animated GIFs. In general, it is good to assume the worst, because browsers have behaved like that. And especially if you have 200 of those full sized images in a Category page, safeguards are probably wise. Hell, ImageMagick doesn't even work frame by frame apparently, so if the problem exists there, it is likely to occur in client implementations. — TheDJ ( talk • contribs) 17:04, 7 April 2010 (UTC)
Update Here is what Happy-melon stated (∆ here), on Village Pump:
This has nothing to do with any discussion, "ruling", "decree" or anything else on this pump or this community. It also has little to do with the developers; this is a sysadmin-level action. Developers are working on improving both the quality and size of the finished thumbnails, and the efficiency of the thumbnailing process. Allowing larger images to be thumbnailed will be a side-effect of that latter work. Happy‑ melon 15:47, 8 May 2010 (UTC)
In short, patience. Note that the software changes originally froze all scaled animations, including this animation of mine. I had created it at 280 pixels but found that the dithering in the 256-color pallet looked better if I scaled it slightly to 266 pixels to blend the dithering. Others who later used the animation in their articles simply copied my practice and placed it at 266 pixels. After finding out what was going on and it wasn’t gonna be a one or two-day fix, I went back and re-specified all placed instances to the native, 280-pixel width. When I later saw that it was again functioning on this usertalk page (where these animation issues were also being discussed), I restored the size to the smoother-looking 266-pixel width.
Clearly, not everything is yet working; there is still a subset class of animations that remain frozen: scaled ones in excess of 12.5 MP. But effort is being made in the background to slowly put everything back into order. Programmers and developers don’t expect us to start throwing stuff away. Just be patient, please.
Any content creator who wants to create smaller versions of their animations that require no scaling in articles—as a temporary, interim measure—is perfectly free to do so. That will have the added benefit of having Wikipedia better function as it was intended for our I.P. readership, who are, after all, the individuals we’re really creating content for in the first place. Greg L ( talk) 17:02, 8 May 2010 (UTC)
Right now there are Bugzillas (I just e-mailed everyone on that one) and Village Pump conversations and individual discussions on usertalk pages and cluster-pooches like this thread. Right now, we have boat-loads of content creators who are feeling like mushrooms: in the dark and fed the not-so-good stuff. I think it’s time that whoever thinks they have a handle the status quo to step up to the plate and get the pointers automatically being created on the affected animations pointing to a central venue where every confused person can go to. A central repository will be a welcome relief from the current state of affairs and, perhaps more importantly, may also bring more resources (developer-types) to the fold. Greg L ( talk) 22:28, 8 May 2010 (UTC)
(*sound of crickets chirping*)
Just a note Golbez, but you added a comment on a quote from a discussion from this Village pump disscusion I just added the relevant conversation to this article for the benefit of, Greg L. I doubt TheDJ will respond to it unless you move the below and add it to the this Village pump disscusion:
Never have been? According to whom? My large animated images have been featured for years, and have been located in articles. There is a use, sometimes, for making a large animated image. -- Golbez ( talk) 03:52, 9 May 2010 (UTC)
PS: sorry for the overlook about not notifying you about the delisting, my bad. -- Esemono ( talk) 04:45, 9 May 2010 (UTC)
My opinion here, I'd like to throw in, is that the developer that brought up the 12.5mp limit for png/gif, this was 5 years ago, and even in his example a 200MP image only takes "800 megabytes of working space" in RAM. By today's standards even on home pc's thats trivial. No pc bought within the last couple years should even have to page that out and can easily accommodate 800mb in RAM for a quick operation like creating a thumbnail. As for servers in 2010, they should have up to 20x that much memory (16+gb) so 200MP should CLEARLY not be an issue anymore. Is there any MODERN response from the developers about these limits? Is these limits still in place? Because the reasoning behind them is a bit silly now given we're not in 2005 anymore. Likewise why should we capitulate to some technological limitation/roadblock. Delisting because some developer 5 years ago had an issue with file sizes is hardly something I think we should be doing. While I don't agree with the use of animated gif's anymore (simply because theres FAR better methods now a days for animation, like Flash and eventually HTML5) I think they're still a necessary evil until we're allowed to embed flash... It seems to me a bit crazy we're talking about this, when this shouldn't even be an issue for under 200MP png/gif's now a days. — raeky ( talk | edits) 17:02, 9 May 2010 (UTC)
When the animations were first frozen, many more were affected than currently are. The proper thing to have done was have an automated banner display in place of an animation frozen in its tracks. It could have been one of those little “dust broom”’ icons saying “work in progress for a few days.” Instead, we had editors re-uploading their animations in a vain attempt to get them working again. After several days, may of the animations suddenly started working. I was unusual in that I was already registered for Bugzilla. So I posted an alert, and had someone point out that there was already a Bugzilla case being worked on it. Only then did I know to wait a few more days. So I rushed around and took care of a few, easy-to-fix, stop-gap repairs in the mean time. But few other wikipedians have such facility with Wikipedia and were nothing but confused. This whole affair has the hallmarks of a cluster-f***. It has been handled like the right foot doesn’t know what the left foot is doing in the rumpus room of a kindergarden.
It appears to me that what we now have is a volunteer developer (thanks for volunteering) pretending to speak authoritatively on behalf of precious few people on an issue by opining what he intends to do and when. There has been a galactically poor level of discussion where some developers semi-coordinate on a Bugzilla, and semi-coordinate on the Village Pump, and coordinate with each other via e-mail, and the whole time leave content providers in the dark by not doing something as simple as creating a WP-space page that frozen animations could automatically point people to. Such a central venue (a WP-space page with its associated talk page) could likely bring more volunteer developers to bear on this matter. Such simple, common-sense moves. Bafflingly, no decent and proper effort was made to alert the wikipedian community as to why our animations stopped working (as if the typical wikipedian is supposed to figure out on their own to go to Village Pump). It makes me wonder if some developers here prefer not having more chefs in the digital kitchen. That is the worse possible thing; we need to pull out the stops to highlight this issue and bring more volunteer developers into the fold. Greg L ( talk) 22:33, 9 May 2010 (UTC)
Delisted -- Makeemlighter ( talk) 19:17, 16 May 2010 (UTC)
none
Whoa there I’ve been active on these old, archived Village Pump discussions and am not aware of a “decision” that said animated GIFs over the 12.5 MP limit “will no longer be allowed”. It is a convoluted thread there and a “decision” might be buried in there, but I can’t find it.
As far as I know, this is a temporary bug being worked on. This technical issue with animations is a complex matter pertaining to the way Wikipedia’s server engines scale animations. This particular animation is only 260,560 bytes and has only 42 frames. Note that I didn’t make it, but am expert on animations and see that the author A) did a magnificent job making it compact, and B) had the misfortune of making it higher resolution than would ever be used on a page and, thus, it always needs scaling.
This need for scaling never used to be a problem. However, a developer recently “threw a software switch” to handle this scaling on Wikipedia (instead of offloading the task to browsers). This was because of our category pages, some of which have hundreds of thumbnails. Offloading such a huge number of animations to scale to browsers was burdening them and increasing their RAM requirements. Unfortunately, because of the current (very simplistic) software sever tools being used after the change, scaled versions of otherwise exceedingly compact animations are causing problems for Wikipedia’s servers. We need better software and this sort of stuff comes from volunteer programmers; big updates don’t come fast.
It seems that this Commons category (titled “Animated gifs violating 12.5MP rule”) was created by the nominator here (Esemono). Note the “violating” and “rule” in the title. But, as far as I can tell, the developers working on this problem would call this issue an active “bug”; something they are trying to fix.
I’ve gone to Village Pump, ( here, where the issue is still being worked), to clarify this. In the mean time, Esemono, please provide a more specific link or quote a relevant passage from the Village Pump archive that looks like a “ruling”, “decree”, and “will no longer be allowed” and doesn’t instead look like a bunch of efforts to develop a long-term solution. For that matter, would you mind pointing out where, on the current Village Pump discussions, it appears to you that developers are not working hard on this bug. If there was to be a “ruling”, “decision”, or “decree”, I should think there would have been a wider RfC on this issue and I’m not seeing it yet.
In the mean time, I would certainly suggest that the FP community not be voting to delist these otherwise fine animations just because they currently don’t work; not until it is clear that the developers have thrown up their hands and declared defeat. As far as I know, they are actively working hard at a solution to this. Greg L ( talk) 13:37, 8 May 2010 (UTC)
P.S. I can always take this animation, shrink it to the size it is typically used in articles, and create a version that requires no scaling. We can then have a vote here to replace it with the updated version—not delist it as an FP. Before we do that though, I suggest we throttle back, allow our jets to cool, and see where the developers think they are going. Very recently, I suggested they consider biting the bullet and adding the capability of doing what I described here on-the-fly by the server software.
Greg L (
talk)
14:36, 8 May 2010 (UTC)
EDITED CONVERSATION OF THIS THREAD [1]: The changes were explicitly made to avoid the crashing of the scale routines of the servers. I doubt the deployment of GIF scaling will be reverted yet again. We don't allow PNG images of 12 million pixels, and now we don't allow GIF images of over 12 million pixels either. I suggest we focus on finding ways to better deal with these large GIFs, but honestly, any animated GIF of this size, should probably never be presented to users. (And never have been). — TheDJ ( talk • contribs) 19:14, 6 April 2010 (UTC)
- Never have been? According to whom? My large animated images have been featured for years, and have been located in articles. There is a use, sometimes, for making a large animated image. -- Golbez ( talk) 03:52, 9 May 2010 (UTC)
- For the origin of the 12.5 megapixel limit, see http://lists.wikimedia.org/pipermail/wikitech-l/2005-October/019681.html -- I guess it's a tradition by now... -- AnonMoos ( talk) 20:46, 6 April 2010 (UTC)
- Wow. That's 4.5 years ago. From the Moore's Law article it's unclear to me whether that is two or three doublings of RAM memory storage, but that would mean an equivalent limit today should be 50 million to 100 million pixels. This would allow an animation 1.6 to 3.2 times larger than the one in the example above. Wnt ( talk) 20:58, 6 April 2010 (UTC)
- I doubt my Sony Ericsson phone browser is that smart. And Safari 3 and earlier was terrible with larger animated GIFs. In general, it is good to assume the worst, because browsers have behaved like that. And especially if you have 200 of those full sized images in a Category page, safeguards are probably wise. Hell, ImageMagick doesn't even work frame by frame apparently, so if the problem exists there, it is likely to occur in client implementations. — TheDJ ( talk • contribs) 17:04, 7 April 2010 (UTC)
Update Here is what Happy-melon stated (∆ here), on Village Pump:
This has nothing to do with any discussion, "ruling", "decree" or anything else on this pump or this community. It also has little to do with the developers; this is a sysadmin-level action. Developers are working on improving both the quality and size of the finished thumbnails, and the efficiency of the thumbnailing process. Allowing larger images to be thumbnailed will be a side-effect of that latter work. Happy‑ melon 15:47, 8 May 2010 (UTC)
In short, patience. Note that the software changes originally froze all scaled animations, including this animation of mine. I had created it at 280 pixels but found that the dithering in the 256-color pallet looked better if I scaled it slightly to 266 pixels to blend the dithering. Others who later used the animation in their articles simply copied my practice and placed it at 266 pixels. After finding out what was going on and it wasn’t gonna be a one or two-day fix, I went back and re-specified all placed instances to the native, 280-pixel width. When I later saw that it was again functioning on this usertalk page (where these animation issues were also being discussed), I restored the size to the smoother-looking 266-pixel width.
Clearly, not everything is yet working; there is still a subset class of animations that remain frozen: scaled ones in excess of 12.5 MP. But effort is being made in the background to slowly put everything back into order. Programmers and developers don’t expect us to start throwing stuff away. Just be patient, please.
Any content creator who wants to create smaller versions of their animations that require no scaling in articles—as a temporary, interim measure—is perfectly free to do so. That will have the added benefit of having Wikipedia better function as it was intended for our I.P. readership, who are, after all, the individuals we’re really creating content for in the first place. Greg L ( talk) 17:02, 8 May 2010 (UTC)
Right now there are Bugzillas (I just e-mailed everyone on that one) and Village Pump conversations and individual discussions on usertalk pages and cluster-pooches like this thread. Right now, we have boat-loads of content creators who are feeling like mushrooms: in the dark and fed the not-so-good stuff. I think it’s time that whoever thinks they have a handle the status quo to step up to the plate and get the pointers automatically being created on the affected animations pointing to a central venue where every confused person can go to. A central repository will be a welcome relief from the current state of affairs and, perhaps more importantly, may also bring more resources (developer-types) to the fold. Greg L ( talk) 22:28, 8 May 2010 (UTC)
(*sound of crickets chirping*)
Just a note Golbez, but you added a comment on a quote from a discussion from this Village pump disscusion I just added the relevant conversation to this article for the benefit of, Greg L. I doubt TheDJ will respond to it unless you move the below and add it to the this Village pump disscusion:
Never have been? According to whom? My large animated images have been featured for years, and have been located in articles. There is a use, sometimes, for making a large animated image. -- Golbez ( talk) 03:52, 9 May 2010 (UTC)
PS: sorry for the overlook about not notifying you about the delisting, my bad. -- Esemono ( talk) 04:45, 9 May 2010 (UTC)
My opinion here, I'd like to throw in, is that the developer that brought up the 12.5mp limit for png/gif, this was 5 years ago, and even in his example a 200MP image only takes "800 megabytes of working space" in RAM. By today's standards even on home pc's thats trivial. No pc bought within the last couple years should even have to page that out and can easily accommodate 800mb in RAM for a quick operation like creating a thumbnail. As for servers in 2010, they should have up to 20x that much memory (16+gb) so 200MP should CLEARLY not be an issue anymore. Is there any MODERN response from the developers about these limits? Is these limits still in place? Because the reasoning behind them is a bit silly now given we're not in 2005 anymore. Likewise why should we capitulate to some technological limitation/roadblock. Delisting because some developer 5 years ago had an issue with file sizes is hardly something I think we should be doing. While I don't agree with the use of animated gif's anymore (simply because theres FAR better methods now a days for animation, like Flash and eventually HTML5) I think they're still a necessary evil until we're allowed to embed flash... It seems to me a bit crazy we're talking about this, when this shouldn't even be an issue for under 200MP png/gif's now a days. — raeky ( talk | edits) 17:02, 9 May 2010 (UTC)
When the animations were first frozen, many more were affected than currently are. The proper thing to have done was have an automated banner display in place of an animation frozen in its tracks. It could have been one of those little “dust broom”’ icons saying “work in progress for a few days.” Instead, we had editors re-uploading their animations in a vain attempt to get them working again. After several days, may of the animations suddenly started working. I was unusual in that I was already registered for Bugzilla. So I posted an alert, and had someone point out that there was already a Bugzilla case being worked on it. Only then did I know to wait a few more days. So I rushed around and took care of a few, easy-to-fix, stop-gap repairs in the mean time. But few other wikipedians have such facility with Wikipedia and were nothing but confused. This whole affair has the hallmarks of a cluster-f***. It has been handled like the right foot doesn’t know what the left foot is doing in the rumpus room of a kindergarden.
It appears to me that what we now have is a volunteer developer (thanks for volunteering) pretending to speak authoritatively on behalf of precious few people on an issue by opining what he intends to do and when. There has been a galactically poor level of discussion where some developers semi-coordinate on a Bugzilla, and semi-coordinate on the Village Pump, and coordinate with each other via e-mail, and the whole time leave content providers in the dark by not doing something as simple as creating a WP-space page that frozen animations could automatically point people to. Such a central venue (a WP-space page with its associated talk page) could likely bring more volunteer developers to bear on this matter. Such simple, common-sense moves. Bafflingly, no decent and proper effort was made to alert the wikipedian community as to why our animations stopped working (as if the typical wikipedian is supposed to figure out on their own to go to Village Pump). It makes me wonder if some developers here prefer not having more chefs in the digital kitchen. That is the worse possible thing; we need to pull out the stops to highlight this issue and bring more volunteer developers into the fold. Greg L ( talk) 22:33, 9 May 2010 (UTC)
Delisted -- Makeemlighter ( talk) 19:17, 16 May 2010 (UTC)