Wikipedia:Bots/Requests for approval/ImageResizeBot: Difference between revisions

Revision as of 23:40, 17 March 2008

Revision as of 23:53, 17 March 2008

Line 41:

**There is probably some marginal difference in size where the costs exceed the minimal benefits. That particular example would shrink 1 pixel in each dimension, and that is a 0.33% change in total pixel count. If the images are to be reviewed for deletion of older revisions, that marginal difference that is appropriate is higher than otherwise. Does the software to be used indicate any level of noise/deterioration that it might produce by resizing? I'll be shocked if it does (certainly not in the marketing materials) but if so that could inform a benchmark. What are the other costs - data storage of additional versions (deleted versions presumably remaining in the deleted history), download/upload bandwith, bot edits in history, possible human review... Being over the 360K limit by 25% would when shrunk to 360K pixels shrink each dimension 10.56%. Being over by 10% would when shrunk to 360K pixels shrink each dimension 4.65%. <small>(1 - 1/sqrt(1+%over360K))</small> So 10% to 25% pixel count margins seem plausible to me - and the bot could flag these as "current version too large, please shrink to X by Y when the image is edited for another reason". [[User:GRBerry|GRBerry]] 22:14, 17 March 2008 (UTC)

***(ec) Well seeing those, I'll probably increase the minimal size to 400,000 square pixels. Basically that puts a bit of leeyway, and gets rid of the problems you mention. Now, the idea from here would be to do the resizing of the obvious cases, get those down to at least thumbnail size. As far as the costs, this bot is actually operating from the wikimedia toolservers, so all the queries are direct database queries, as far as getting that list. The actual resize requires that the bot download the image (to memory, not to hard disk), change the size, and upload the new image size. This is all done inside of [[RAM]]. The point at this stage is really to get the obvious violators, not split hairs, I did not realize that the smaller ones would result in a 1 pixel change. —— '''[[user:Eagle 101|<font color="navy">Eagle</font><font color="red">101]]'''</font>^{[[user_talk:Eagle 101|Need help?]]} 23:20, 17 March 2008 (UTC)

**** Well, I fear that you might eliminate a lot of the issues, but you will still have borderline cases. For example, [[:Image:ChoosecologotypeTM.jpg]] will be resized to 410k (and [[:Image:ShereKhanJBSM.jpg]] will be resized minimally). This is all a factor of the size of the thumbnail being as large as possible to fit inside an 800x600 box (this is configurable in preferences, too, so there are multiple thumbnail sizes on the server, it would seem). I see two potential ways to handle this. One would be to only work with images above size X (eg 400k) but make sure to size them below size Y (eg 360k). The other would be to just define the size you are going to make them (i.e. define a maximum dimension). Am I missing the reason that you are tying the new size to the thumbnail? -&nbsp;[[User:AWeenieMan|AWeenieMan]]&nbsp;([[User talk:AWeenieMan|talk]]) 23:53, 17 March 2008 (UTC)

*From [[User:David Shankbone]], I understand that deleting the oversize version doesn't actually save any space on the servers, since the oversize version is still kept around (like a deleted article). If this theory is correct, has it been factored into the calculation of benefits? [[User:EdJohnston|EdJohnston]] ([[User talk:EdJohnston|talk]]) 23:16, 17 March 2008 (UTC)

**(ec x2)Correct, we know that, the point is to remove the high resolution version of the image. Using our non-free content policies means we use the smallest version we can use. —— '''[[user:Eagle 101|<font color="navy">Eagle</font><font color="red">101]]'''</font>^{[[user_talk:Eagle 101|Need help?]]} 23:20, 17 March 2008 (UTC)