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

Revision as of 21:31, 17 March 2008

Revision as of 22:14, 17 March 2008

Line 39:

* Question: What do you think about an image such as [[:Image:Cannibalised.jpg]]? As it stands, it is just above your mark (600 × 601) (I agree, it's much too big in its current state), but shrinking it to thumbnail size makes it just below your mark (599 × 600), which seems like a minor difference. And then there are images like [[:Image:Aroundtheworld.jpg]] where the thumbnail seems to be the full size of the image. These are really just test cases to me, as I am just wondering how you plan on handling them (not an argument to ignore them in any way). - [[User:AWeenieMan|AWeenieMan]] ([[User talk:AWeenieMan|talk]]) 21:31, 17 March 2008 (UTC)

**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)