Wikipedia talk:Preparing images for upload

From Wikipedia, the free encyclopedia

note: most of this was written when the page was under the title How to keep image file sizes as small as possible. A title that is somewhat misleading considering that reducing size at all costs should not be the goal of preparing an image.

Contents

[edit] Size of PNG thumbnails

It seems that the PNG thumbnails here at wikipedia don't work very well. Take a look at this logo for example. Its original size is 8 kb, but when displayed thumbnailed in an article it's more than twice as large (21 kb). What's wrong with the PNG compressor? This does not happen with GIF-thumbnails. Perhaps I should use GIF files for logos instead, seeing as they make the pages load much faster? /Jebur 23:37, 28 Apr 2005 (UTC)

It's a known issue. Basically every png that comes out of the autoscaler is truecolor. The real problem is how is the software supposed to know how much it can cut down the pallette of the output without significant quality loss. In the case of gifs the output is forced to 256 color simply because that is the highest gif supports (without dirty tricks). Plugwash 00:05, 29 Apr 2005 (UTC)
Ok, so isn't it better to stick to GIF then, seeing as it makes the thumbs up to 10 times smaller? /Jebur 00:10, 29 Apr 2005 (UTC)
Not if you're an eventualist. Once Bug:234 gets fixed (someday . . .), PNGs will be better than GIFs again. And then every single image that's been converted to GIF will have to be replaced. —Simetrical (talk • contribs) 21:21, 18 May 2006 (UTC)
Hmm, I just spotted the date there. Oh well, no harm done.  :) —Simetrical (talk • contribs) 21:22, 18 May 2006 (UTC)
Don't worry I often reply to messages I find months after they wrote it even when I know they're most likely not paying attention to it anymore and probably will never see it again - look I'm doing it now!! --WikiSlasher 12:12, 18 October 2006 (UTC)
Well don't worry. If Plugwash really is an eventualist like you suggested, then they will probably stick around to read your message. -Colin MacLaurin 20:51, 2 November 2006 (UTC)
But it's Simetrical that I was replying to - not Plugwash --WikiSlasher 09:58, 3 November 2006 (UTC)
Me i'm not so much an eventualist, but i've given up on pushing too hard on issues like this. The existing devs are overworked already just firefighting the issues caused by the ever growing wikipedia. Recruiting devs is hard because mediawiki is poorly documented and written in php and because even when a fix is written those with the power to apply it to the wikimedia wikis are very slow to act. Add that to the fact that this issue really doesn't affect me as i have a decent connection and i have very little motivation to actively try and do anything about this issue. Plugwash 21:14, 2 November 2006 (UTC)
This is a very serious problem for dialup users. This is another reason why wikipedia might allow ads on user pages where the user has OKed ads. Lots more money for developers. See my user page for more on how wikipedia might accept ads safely without advertisers having any power over wikipedia. End of plug. :) Why is this png thumbnailer autoscaler problem not been dealt with for so long? Would a few more paid developers help? Is any of the latest money from fundraising going to developers? I sure hope so. They deserve all the help we can give them. Including CASH!! As do board members and any other staff. --Timeshifter 04:13, 16 January 2007 (UTC)

[edit] filesizes don't concur with advice?

Hmm, this would be a lot more convincing if it weren't for the fact that the "with title" picture is 1556 bytes, and the "with no title" picture is 1932 bytes. *sigh* It really is Image:Covalent.png all over again, isn't it? ;) -- John Owens 21:41 Apr 24, 2003 (UTC)

Ah ha, you interlaced the "with no title" picture but not the "with title" one, I bet that's what it is this time. At least they're the same number of colours. ;) -- John Owens
I have a very good image optomizer, can compress images very very well. I compressed teh smiley face without any visible differance to 1,108 bytes on my PC. -fonzy
I got it down to 1,012 bytes, and the "with title" only went down to 1,496. Much better, as an example of why you shouldn't include a title. -- John Owens


It's me learning as I go along. At least I get to make all the mistakes of a new user, so they all get covered in this page. I was mucking about with the interlace/no interlace options with Paint Shop Pro under windows and according to the image information screen the file sizes were exactly the same! I thought it a bit strange, but was tired and thought I'd worry about it in the morning.When I come to sort things out today all you nice people have done a lot of the work already :-) I love wikipedia! Theresa knott

[edit] discussion from village pump

Moved from the Village pump

Hi

I'm trying to reduce the size of an uploaded image, anyone got experience of that. I tied to crop it in Graphic Converter offline, then up load it , but the new upload was bigger, although still a croped version of the old... help! TonyClarke 11:40 May 6, 2003 (UTC)

Do you mean Image:Hobies.jpg and Image:Trimhobies.jpg? Because the trimmed image is definitely smaller than the original image. Egil uploaded a scaled version of Image:Hobies.jpg which was much smaller (pixel-wise and byte-wise) than the original. How about I rescale the trimmed one for you? -- Tim Starling 12:13 May 6, 2003 (UTC)
Okay, that's done now. I adjusted the levels a bit too. Just revert it if you don't like it.
Image compression is a bit of a dark art. If you're recompressing a JPEG image, there will be far more loss of quality than it is worth.
Yes, I know. I was going to ask you for a higher quality image (if you have one), but it was getting late here in UTC+10 land, and I was only using a modem so multi-megabyte image files are a bit annoying. -- Tim Starling 00:15 May 7, 2003 (UTC)
Wikipedia:How to keep image file sizes as small as possible might help. --Menchi 15:20 May 6, 2003 (UTC)

End of moved text

[edit] some more rules of thumb from Wapcaplet

I haven't followed the discussion at all, but some good rules of thumb that I use when doing website graphic work:

  • Use the appropriate image format
    • jpg for photographic images with lots of colors and/or continuous smooth areas of color.
    • png for diagrams, line drawings, pictures with few colors or not much smooth variation in color. For very small images (under 50x50 or so), png is probably best for any circumstance, since it preserves good clarity at small sizes. (not lossy)
  • Reduce the number of colors for png. If the image only has black and white or very few colors in it, you can probably cut it down to 8-bit or lower color depth. In fact, if cutting an image down to 8-bit looks really bad, it should probably be jpg anyway. Never use 24-bit png unless you need near-print quality (which means never, if you're only designing for the web).
  • Find a good freeware or shareware compression tool. There are lots that will let you compare various levels of compression as you tweak it; you can get a good tradeoff between quality and file size this way.
  • The most obvious: Make the image smaller. Crop it to frame the subject well, or resize/resample the image to a lower resolution. Somewhere in the vicinity of 200 pixels in width or height is typically adequate for most pictures for the web. More than that, and the file starts getting pretty large, and running off the edge of the user's browser window.

Hope this helps some people. -- Wapcaplet 19:26 30 May 2003 (UTC)

[edit] jpeg size reducer

Why doesn't the article mention a good JPEG file size reducer, JPEG Cleaner? It doesn't worsen the image quality, it just removes useless data. I am not the only one who likes it. -Anon. 14:25, 9 Jul 2004 (UTC)

I think we're just a bit nervous about any technology which actually changes the content of the image. All of the PNG compressors mentioned here make absolutely no changes to the images---they're identical. JPEGs have a tendency to get muddy and funky when you play around with them repeatedly, compressing and decompressing. I'd never heard of JPEG Cleaner; I don't know if it's useful or problematic or what, but that's the reason for the general distrust of JPEG modification. Plus, changes to photographic images are often subtle and hard to notice. Images might be damaged beyond recognition. It's easier just to leave the JPEGs as plain.
All that said, I'll have a look. grendel|khan 08:48, 2004 Jul 10 (UTC)
And now that I've checked it out, I see that my above comment is utterly irrelevant, as JPEG Cleaner only tosses out extra metadata. Some of this---embedded previews, for instance---can definitely go, but the date, exposure-type, camera-information stuff embedded by many digital cameras might be pretty useful. Is there some way of configuring which information it drops? If so, dropping redundant stuff could definitely be helpful. grendel|khan 08:51, 2004 Jul 10 (UTC)

[edit] reprocessing stored images

What about a bot going through Wikipedia's image archive and processing all the PNG's with OptiPNG? This would demand lots of CPU, though.Etz Haim 22:59, 25 Aug 2004 (UTC)

[edit] User:Etz Haim/Tech Corner

If you are interested in this page, you may want to review my tech corner. Any comments will be appreciated. Etz Haim 09:50, 24 Sep 2004 (UTC)

[edit] anti-aliasing?

Should we really be discouraging anti-aliasing? In my opinion it vastly improves the easthetics and 'visual feel' of most diagrams and should be used wherever possible. Diagrams don't normally consume nearly as much space as photographs. It probably only makes up for a fraction of the total disk space. -Anon

It was never my intention to discorage anti aliasing. Only to point out the fact that if you anti alias you need a greater colour depth than you might otherwise have thought. Theresa Knott (Not the skater) 10:13, 21 Oct 2004 (UTC)

[edit] webpack

An interesting project I've found on Freshmeat: Webpack

From the site: "Webpack is an open-source command-line tool for automatically packing websites by shrinking them down without affecting the way they look or behave.Webpack is also useful for losslessly shrinking image collections and locating corrupted files. Webpack works by stripping unnecesary information from & optimising the compression of images, and removing comments/whitespace from html. This makes for a faster website for your users, and lower bandwidth usage/costs for you! (oh, and it's free - both as in speech and as in beer)." — Etz Haim 18:19, 13 Nov 2004 (UTC)


[edit] How does the thumbnailer do it?

I have wondered for sometime how/if the thumbnailer produces optimal size PNGs. I had a lot of hassle with my PNG-optimizing with a batch of pngs for Wikipedia, and finally figured to drop that step, resulting in 5-25 % larger uploaded images. I was thinking that Wikipedia's thumbnailer really had to do this optimizing, smart as it is (I presume), and me having trouble with it.

Well, how is it? Does the thumbnailer use pngcrush or equivalent on the thumbs. Why not use it on all uploads? ✏ Sverdrup 02:43, 5 Dec 2004 (UTC)

i don't think it does optimise them. I think it pretty much just uses imagemagiks convert program on more or less its default settings. Plugwash 00:37, 24 Jan 2005 (UTC)
It should be noted that ImageMagick's png writer is better than average. I just tried png crushing some mediawiki thumbnailed stuff and even with the most agressive setting on PNG crush I wasn't able to get more than 5-6% reduction. --Gmaxwell 14:55, 20 February 2006 (UTC)

[edit] Respect the originals

Is it really a good idea to have 70-80 % compression for JPEGs? I mean, suppose that in the future you make a print Wikipedia, you want the most quality images you can have. I propose that we upload JPEGs in a high quality byte- and pixel-size (if available) and let the software downgrade it for browsers.

Also don't remove EXIF data before uploading.

And for those who propose to run permanent compression on the image collections, you may lose interesting metadata like IPTC or EXIF or some embedded copyright notice.

(The above is from User:80.58.3.172, who has a whole bunch of anon edits.) I concur partly---high-resolution and high-quality are good ideas, because higher-resolution displays and high-quality PDF output are goals that I think we should be working toward. Though image editors frequently remove EXIF data when, for instance, images are cropped. It's not always reasonable to include EXIF. grendel|khan 22:43, 2005 Jan 19 (UTC)
yeah most jpegs will go through the autoscaler anyway meaning the quality setting on the original will have no effect on the file the browser gets. Ideally we should archive images in a lossless format but unfortunately we can't change the format in rescale operations. Where jpeg is used quality 95 (the highest you can use before getting into insanely diminishing returns) should be used without too much caution/ Plugwash 08:34, 18 Feb 2005 (UTC)
The suggestion of '95%' for JPEGs is a good one. As far as format in the autoscaler: We *can* change the format, in the sense that there is no technical barrier stopping such a feature, we just don't... the reason for this is that there are images which are uploaded in PNG which should stay PNG and we have no way of identifying them to the software. You could go impliment a [[Image:foo.png|png]] flag which would prevent the transforming to JPEG, but I worry that no one would use it. ... However now that we have SVG much of what was previously PNG is being converted... so perhaps the time is right. Patches to mediawiki are usually accepted. :) --Gmaxwell 14:47, 20 February 2006 (UTC)

[edit] move and major edits

i moved this page and made some significant edits to try and remove the suggestion that we wan't to reduce filesize at all costs. Comments on the new version welcome.

[edit] Old photographs?

Here is a question that should probably be covered on this page: What should you do with old photographs that one is planning to upload to the Wikipedia? I've uploaded a few old photos from the Library of Congress. Unfortunately, like many of the pre-1923 public domain photos at the LOC, they were darkened and yellowed. Most of the photos I uploaded I have used "as is". For one of the photos, however, I cropped the image, and then converted the image to greyscale and lightened up the image, which I think gave a much better picture. I am wondering if there should be any sort of guidlines for this type of photo manipulation. BlankVerse ∅ 12:54, 23 July 2005 (UTC)

It's fine as long as you say what you did on the description page and leave the copyright status clear(i.e. release it back into the public domain or license it GFDL) Superm401 | Talk 22:18, August 3, 2005 (UTC)
its often a good idea to upload the untouched version of an image first and then the retouched version, that way people who wan't to try and do a better job of improving the image can. Plugwash 14:58, 2 December 2005 (UTC)

[edit] Inappropriate use of JPEG

For cases of non-photographic images using JPEG compression, I have created a template to place on the image page, {{badJPEG}}. It suggests replacing the JPEG image with a PNG or SVG image and refers the reader to Wikipedia:Preparing images for upload. It has a corresponding category, Category:Images with inappropriate JPEG compression, which is under Category:Images for cleanup. Please use as you find appropriate. --ChrisRuvolo (t) 14:33, 2 December 2005 (UTC)

Why Do all the templates I come across say to Upload as a new file and mark the privious file as redundant. Why not just Upload a new version of this file. I haven't done this yet so i'm probaly missing someting important.--E-Bod 23:51, 20 March 2006 (UTC)

If possible, please upload a PNG or SVG version of this image, ... After doing so, please replace all instances of this version throughout Wikipedia (noted under the "File links" header), and mark this image as {{redundant|Image:replacement image}}

Because "a new version of this file" will still be a JPEG. The whole point of this template is to replace JPEGs with PNG and SVG images. --ChrisRuvolo (t) 12:49, 21 March 2006 (UTC)
Thanks. That Explains it for the Template for Images to convert to SVG and Images with inappropriate JPEG compression but what about for Category:Images with opaque backgrounds where most the images are already in PNG --E-Bod 22:24, 21 March 2006 (UTC)
{{opaque}} asks for a PNG or SVG image. It does not specify whether the source image is PNG or JPEG or GIF. There may be a change in filetype because of this. If not, obviously a new version of the same filename would be preferred. If you want to edit the template to specify all this, go right ahead. --ChrisRuvolo (t) 22:43, 21 March 2006 (UTC)

[edit] Why SVG over PNG?

Compare Image:Star of life.gif and Commons:Image:Star of life.svg. The underlying image in the latter is 5.76 KB, and the displayed PNG at full size is 15.37 KB. By contrast, the GIF (and we're talking a GIF, which could be further compressed into a PNG) is 3.81 KB.

Now, I realize that the SVG can be more easily scaled up. But is anyone seriously planning on scaling up a roughly 200×200 pixel image? I also realize that it's theoretically easier to edit, but in practice, surely most people would find it easier to use a graphics program. Finally, I realize that the size disparity would probably be reversed if SVGZ were fully supported by mainstream browsers, but that's probably not happening for another two years or so.

So I see two logical possibilities. Either there was a problem in converting the specific file to SVG that resulted in an excessively large file size, and this problem is aberrant and/or can be corrected; or we should stick with plain PNGs for now where scaling isn't useful and the SVG filesize is greater. Am I missing something? —Simetrical (talk • contribs) 01:46, 20 February 2006 (UTC)

SVG isn't supported by mainstream browsers, and everything that supports SVG supports SVGZ (I'd welcome a counterexample...). But all that is irrelvent: We don't send the SVG to the browser at all, it's rasterized into PNG on the server where size doesn't matter much. The PNG the server rasterizes should be roughly the same size as the PNG you rasterized. The ability to edit and the ability to use the image for more purposes is important.--Gmaxwell 14:41, 20 February 2006 (UTC)
"The PNG the server rasterizes should be roughly the same size as the PNG you rasterized." maybe so but a carefully produced png with the same content optimised for the display size will be much much smaller, this is related to the thumbnail colors issue mentioned higher up, to get an optimal png at a specified pixel size requires a human who can make quality/size judgements. Plugwash 21:22, 26 October 2006 (UTC)

[edit] Category:Images with opaque backgrounds

I noticed Category:Images with opaque backgrounds. Could sombody point me to where the value of Transparency in an image is prefered. and as a side thought why all the templates in Images for cleanup all say to creat a reduntant page and fix it instead of simply updating a newer verthion of the file.--E-Bod 03:17, 19 March 2006 (UTC)

The background of Wikipedia's articles is not always white. Some images have unused portions (such as seals or insignias or logos). To have the image look correct on all backgrounds it should be transparent. --ChrisRuvolo (t) 23:07, 21 March 2006 (UTC)
Ok, but what about when you want to print a page. For example the image on Bucklin_voting#An_example when it prints (on paper not screen), the transparent part prints black and the image look awful on paper. I was thinking of changing a few images with opaque backgrounds but I don't notice a problem on a typical view of the image and making the background transparent will make it print funny. Is it my printer settings? I am using a Canon i860. If this would be valuables to include in the article I could submit a screenshot of the printing problem to illustrate the point if we chose to include this in the article. Should we make a section in this page to advise about transparent opaque backgrounds? I don’ want spend my time figuring out how to make the images have a transparent if it would just degrade form the articles they are in.--E-Bod 04:15, 1 April 2006 (UTC)
I just Discovered The Printable version so mabe i should sugest a fix somewhere else--E-Bod 00:33, 4 April 2006 (UTC)
I don't know where to sugest the fix though--E-Bod 21:23, 12 April 2006 (UTC)
Except that it doesn't look correct if you do as the template suggests, because IE 6 messes up when displaying images with alpha channels. While it might be nice to have images in that format, is it really a good idea to upload images that won't look right for the majority of our users? I like alpha-blended PNG as much as the next guy, but that doesn't mean it's the right thing to use if we want things to display as intended. GreenReaper 19:26, 18 April 2006 (UTC)
If you set the background color on the image correctly IE6 shouldn't look too bad. PNGs with alpha are widely used on Wikipedia, it's a given that we've mostly given up on IE6 looking perfectly. Wikipedia is in it for the long run... our content will most likely outlive some broken version of IE by such a huge margin it isn't even worth discussing. --Gmaxwell 21:50, 18 April 2006 (UTC)
How do you properly print a page with an image with a transparent background so that the background isn't printed black. I use Firefox but an explanation for IE would also be helpful. Since a page is Blank I would like to be able to print the images as if the background is white.--E-Bod 20:45, 24 April 2006 (UTC)

[edit] Coverting Illustrator file to SVG

I created this map Image:First century palestine.gif using Illustrator CS2. I was asked to convert it to SVG and also to upload it on the commons. SO I reopened my illustrator file and saved it as an SVG from the "Save as..." menu option. I then uploaded that file here Image:Iudaea province.svg, but as you can see something has gone array. I thought initially it may had to do with the clipping mask I used to crop the image, so I released that and uploaded another version, but still the same. As you can see Iudaea Province, there is an error: "Error creating thumbnail". Does anyone know what is wrong? Any advice on how to properly save a SVG for upload? Thanks!--Andrew c 14:45, 12 April 2006 (UTC)

Ok, I figured out one problem. I had a crop area as well. Once I released the crop area, I could save the file and upload it and get the image to show. However, now I need to figure out how to make a crop area without using a crop area.--Andrew c 14:58, 12 April 2006 (UTC)
Hmm... that didn't fix it. Well, I had one file version work. If you look at the file history, it is the 14:54 revision. I'm totally confused now. The only thing I did to the revision that worked, was deleted some anchor points that extended outside of the document page in order to get square borders (the reason I was originally using a crop area and a clipping mask). I thought it was releasing these things that made that one version work. But maybe that is not the case, because the latest upload doesn't work. I am totally confused now.--Andrew c 15:29, 12 April 2006 (UTC)
I haven't touched anything since the last edit, but now it seems to be working, although the image on the Image: page looks terrible (the thumbnail on the article Iudaea Province looks fine though). Maybe it had something to do with my browser (Opera) because I am at work and firefox and IE show it fine. Totally confused still.--Andrew c 01:31, 13 April 2006 (UTC)

I would like to know the details how to save a file in SVG-format in Illustrator for Wikipedia. I made some images and I saved them in the default SVG 1.1 mode and uploaded and they showed up blank. Haven't used SVG before so I don't know what options should I use when saving. Quick solution was to download Inkscape, open the Illustrator files in there, save and upload. Seemed to work but this puzzles me. 84.253.230.58

[edit] Upload SVG files at what native size?

I'm a little confused, but I'm just starting out with SVG files so maybe that's understandable.

I know that SVG files are converted by the server/software to PNGs before they display them inline; but are we supposed to see pixelation when we scale up an SVG file inline? For example, [[Image:Benbrook flag.svg|1200px]] (inline) shows distinct pixelation that doesn't exist on Image:Benbrook flag.svg. What am I doing wrong? Or do SVGs also "autoresize" on the image page once you get to a certain native size, like very large JPG files do, where you get the Download high resolution version (1600x1200)? -- nae'blis 22:21, 13 September 2006 (UTC)

Looks like a size (width, height) limit was put on PNGs generated from SVGs. Maybe to prevent people from abusing the sever with [[Image:x.svg|100000000px]]. I think the ideal size for an SVG would depend on how detailed it is. --Pmsyyz 01:25, 27 October 2006 (UTC)

[edit] Updating PNG rasterization

I've uploaded a newer version of [[Image:Co2-temperature-plot.svg]] but the generated PNGs (how it displays on any pages that don't render it to size that hasn't previously been displayed) all still look like the old version. Is there some way to force an update or something? Leland McInnes 17:39, 4 November 2006 (UTC)

Go to the image description page (Image:Co2-temperature-plot.svg) and in the address bar add
?action=purge

to the end of it. Got that info from WP:PURGE. --WikiSlasher 07:28, 5 November 2006 (UTC)

[edit] reducing PNG size

If a PNG is uploaded with a large file size, should it be optimized and re-uploaded, or should it just be left alone because re-uploading it will just add more bytes to the server? --75.20.216.191 20:13, 31 December 2006 (UTC)

I don't think storage space is a problem. It should be optimized and re uploaded because file size does affect download speed and bandwidth. Theresa Knott | Taste the Korn 20:18, 31 December 2006 (UTC)
True but most downloads go via the thumbnailer which will undo your optimisation anyway, re-uploading will also mean lots more work for the servers regenerating thumbnails and more bandwidth for browsers as they discover thier cached versions are old. Of course if its an image that is frequently used *without* scaling optimise away. Plugwash 15:53, 3 January 2007 (UTC)
Will not new visitors make up for this? In that the servers will be loading the new smaller png images for them. Also, dialup users would greatly appreciate smaller png images. Even with the thumbnailer problem the thumbs and mid-size images will be smaller for new visitors?
Is this thumbnailer problem going to be fixed? I take other people's word that png image files are better than gif ones. But this png thumbnailer problem negates any benefits in my mind. Because most people use dialup internet access. For them a single high-kilobyte png thumb or mid-size png image on a wikipedia page can make for a very slow-loading wikipedia page. Because paradoxically they use a lot more kilobytes than the full-size png image. I used dialup until a few months ago, so I remember this clearly.
Gif images don't seem to have this problem at wikipedia. Their thumbs and mid-size images use less kilobytes than their full-size images. My suggestion is that people load png images at around 450 pixels wide since they can be shown on wikipedia pages without being reduced first to thumbs or mid-size images. Text can flow around those images. I am currently using a 17 inch CRT monitor. --Timeshifter 04:02, 16 January 2007 (UTC)

[edit] DeflOpt

There is another quite an unknown software called DeflOpt that can squeeze some bytes out of PNGs compressed by OptiPNG, advpng, advdef and PNGOUT. It's current version is 2.04. I have been using it for some weeks now without problems. It is run on Windows using the command line interface. It can be downloaded from http://www.walbeehm.com/download/. --Hautala 21:08, 22 February 2007 (UTC)

[edit] Image framing

(I looked around and couldn't find a direct answer to this question, so I figured I would ask it here.)

What should I do about whitespace on the edge of diagrams? For example, I just vectorized this image into this one. As you can see, in the original diagram there's some space around the outside edge, while on my version there is none. In terms of image-creation guidelines, is this ideal? Or should I have left a little whitespace ("transparentspace") around the edge? Check the article it's on to see how it looks on the page. Thanks!  MithrandirMage  T  06:50, 20 March 2007 (UTC)

It would be a good idea to leave a little whitespace around the edges, like the raster copy has. —Remember the dot (talk) 04:54, 25 March 2007 (UTC)
Retrieved from "http://en.wikipedia.org../../../p/r/e/Wikipedia_talk%7EPreparing_images_for_upload_0de7.html"