Kunja kheda कुंजाखेड़ा village tehsil kumbhraj District Guna Madhya Pradesh india Devend meena (talk) 04:49, 12 January 2017 (UTC)

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 difference 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

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

Village kunja kheda aad on Google Devend meena (talk) 04:59, 20 December 2016 (UTC)

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)

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)

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)

This would most likely be pointless. If we really need to save disk space then it would be more effective to compress everything on the database level than to recompress our png's by a few percent. Joshua.leahy (talk) 19:18, 3 November 2009 (UTC)

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)

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 doc. 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)

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)

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)

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.

Hanuman tempale kunja kheda Beautiful tempale in kumbhraj thasil

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)

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)

"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." Then why do these SVG images take up all my system memory when I click on them? In my experience with this format, it is garbage for use on the web, and the fact that you goons are actually replacing PNGs with them makes me want to choke babies. PNG is optimized precisely for what it's used for. SVG, regardless of your fetish with it, is crap for this purpose. Ditch it. New doesn't equal better. --76.224.90.253 04:28, 25 September 2007 (UTC)

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)

hello i am from the future. yes the transparent alpha channel presents a problem. images are uploaded with the assumption of a white background. the black text in the images is problematic. there needs to be an option to download images with the alpha channel converted to a white background. — Preceding unsigned comment added by 101.98.178.115 (talk) 12:50, 22 December 2022 (UTC)

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

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)

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)

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)

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)

An alternative/complement to DeflOpt is defluff. Being also a command line tool, it is available for Linux, Mac OS X, and Windows. Have a look at http://encode.ru/tags.php?tag=defluff for more information.

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

PNGOUT has a '/ks' (keep settings) option, which lets it recompress the PNG using the same settings it was compressed with before (e.g. colour type, bit depth, filter method). Since the image has been previously compressed with OptiPNG, which quickly runs trials over filter methods, and can also do color type optimizations, it should be able to benefit from the settings it used, rather than have to rely on basic heuristics. Ultimately, for best results, it would be better to try it with both methods, but if you were only going to run it once, for speed, would it be better to run it with or without /ks? CountingPine 11:19, 10 May 2007 (UTC)

I can't find any documentation on a /ks option. The tutorial says that /kxyz is for keeping a chunk named xyz. —Remember the dot ^(talk) 17:23, 10 May 2007 (UTC)

It's a relatively new feature, and Ken hasn't gotten around to updating the tutorial since he released PNGOUTWin. But if you run the pngout.exe program without any parameters, then it mentions /ks in the help text. Make sure you're using the latest version.

Note: Currently, PNGOUT does a quick check, and if the file looks like it was saved in PNGOUT, then it will keep the settings anyway. Otherwise, it will automatically reduce the color type if it can and use the LibPNG heurstics to choose the filter type. (Whatever the case, the settings can be overridden by specifiying them as command line parameters.) CountingPine 18:45, 10 May 2007 (UTC)

Ooh, nice. This optipng + pngout combination seems to have pushed Image:Gguklogo2.jpg over the threshold for conversion (a PNG is now at Image:Girlguiding UK logo 2.png). Thanks for the information! —Remember the dot ^(talk) 21:37, 10 May 2007 (UTC)

Can anybody help me to improve my photo of tenrec (Lesser Hedgehog Tenrec - Echinops telfairi)? Pinky sl 08:06, 30 May 2007 (UTC)

Nice Picture. The Wikipedia Graphics Lab would probably be the best place to try for something like this. CountingPine 14:04, 30 May 2007 (UTC)

Thanks, Pinky sl 16:47, 30 May 2007 (UTC)

I support Wikipædia 100% for their philosophy of using the right media type for the right data type (ie SVG for line drawings). However, I don’t think we go far enough, and I think it would be better if we finished the job we have started. In other words, I think it would be better if the pages that use a certain image used the actual SVG source image itself, inline, as opposed to simply a bitmapped PNG version of it (which more or less defeats the point of it in the first place)

So what I am proposing is that SVG images are embedded into articles using <object> or whatever (with a bitmapped fallback for older software), rather than using <img>. Not only would this speed up loading times and reduce bandwidth, and all the other used benefits of vector images, but it would also increase the adoption of W3-standard browsers in the world at large, and would also encourage Internet Explorer users to upgrade to something more compliant (and maybe it would also encourage Microsoft to improve their browser with full native support for this established format).

So how do we go about implementing this in the templates?

--- Different Author ---
When showing a mathematical plot (in whatever image format the uploader uses) it would be great if they included the formula or source code (IE: Matlab, GNUPlot, LaTex) used to produce the image. This allows corrections to be made in the event that there is an error in the plot.

The source code could be used by the reader (on thier own computer, without uploading the change) in the event that:

1. The reader desires to scale the image to view the finest possible details.
2. The reader chooses to remove some of the plotted lines when viewed so there is less clutter or better scaling of the desired portion.
3. The reader is colour-blind and desires to change some of the colours chosen by the author.

An example of where this would be useful is on this page: http://en.wikipedia.org/wiki/Window_function#Comparison_of_windows where there is a plot of over a dozen window functions on a small graphic (even when the larger image is viewed one may desire to remove some of the lines). —Preceding unsigned comment added by 24.85.104.61 (talk) 15:22, 20 May 2008 (UTC)

Can anyone help with Image:Arbans page 22 chromatic study.png? Wikimedia states: "Error creating thumbnail: Invalid thumbnail parameters." If you download the full resolution image you will see that there are no problems with the PNG file. For some reason the JPEG version works fine (Image:Arbans page 22 chromatic study.jpg). I've had problems with the Wikimedia image rendering before but don't know where to ask for help or report bugs/issues.--Dbolton 19:56, 25 July 2007 (UTC)

The problem seems to be common with two-coloured (one bit for colour) images. See for example Commons:Image:Aamulehti numero nolla etusivu.png. A work-around could be forcing the file to be saved in 4-bit or 8-bit palette. --Hautala 21:05, 25 July 2007 (UTC)

There appears to be a memory limit that is reached by large (pixel-size) images. I reduced the image size by 50% and it fixed the problem--Dbolton 22:20, 25 July 2007 (UTC)

Are we allowed to use flash (.swf) files on wikipedia? If not, why? They could relly help explain things more. —Preceding unsigned comment added by Theconster (talk • contribs) 23:28, 21 February 2008 (UTC)

The resizing of images for thumbnails generally works great, but for some reason it does not for a small subset of images. This subset seems to be GIF images with large transparent backgrounds, e.g. logos. When they are being resized, some of the foreground is being dropped. This dropping does not occur if you resize in Photoshop. Could it be that a simple change in setting is needed?

Examples:

• —Preceding unsigned comment added by 72.94.249.34 (talk) 23:31, 2 March 2008 (UTC)

Probably the resizing code retains the same color palette as the original image, and what you're seeing is the best that can be done with that limitation. This is another reason GIFs are discouraged here on Wikipedia. Try using PNGs instead. —Bkell (talk) 23:43, 2 March 2008 (UTC)

Please see commons:Commons talk:Deletion requests/Superseded#Do not delete "superseded" images! A quote from a March 29, 2007 comment there:

MSIE does not support transparency in PNGS well - in fact, it does not support alpha blending, but only binary transparency. This means that all PNGs automatically generated from SVG files, or even just scaled from a large PNG file, look very bad in Internet Explorer if they have any transparent parts! Especially for icons, hand-tweaked PNG images that use indexed colors and binary transparency, and have just the right size, are often preferable. Deleting such files or replacing them with SVG counterparts is counter-productive!

A quote from an April 10 2007 comment there says:

MSIE 7 supports alpha transparency.

So I guess there are variations in how MSIE 6 and 7 handle transparency. I am not knowledgeable concerning transparency, and I am just passing on info. Internet Explorer_7#Features and changes says: "Support for per-pixel alpha channel transparency in PNG images has been added."

It references this: "IE7 Transparent PNG Implementation" at http://blogs.msdn.com/ie/archive/2005/04/26/412263.aspx

GIFs are fine, and preferred in some cases, if there is no transparency in the image. Especially for images with less than 256 colors. GIF is an 8-bit format. GIF images often use fewer kilobytes when resized to smaller images. And no special tweaking is required. Versus PNG image resizing.

There are ways to make transparency work correctly with GIF images too according to this:

http://www.handson.nu/HTML/transparency.sdoc --Timeshifter (talk) 11:02, 3 March 2008 (UTC)

This doesn't address any of the issues brought up here. GIFs have only binary transparency, not alpha transparency, so replacing a GIF with a PNG will not run into any of the problems Internet Explorer has with PNG alpha transparency. We aren't talking about SVG at all. GIFs are generally not preferred for images except animated images; see Wikipedia:Preparing images for upload, which states "GIF - Files may be larger, less scalable, and not as colorful. Should usually be converted to PNG unless animated." PNG images can be 8-bit images just as GIFs are, but they can also have higher color depths if needed. Often PNG compression is better than GIF compression, and it's never significantly worse; besides, file size is not our primary concern here. The page you posted about GIF transparency is also not applicable; we are talking about what happens when a large GIF image with transparency is automatically resized by the Wikipedia servers. —Bkell (talk) 13:00, 3 March 2008 (UTC)

I was just pointing out various problems and solutions concerning transparencies. In order to avoid creating new problems while solving other problems with transparencies.

As concerns GIF versus PNG: In most cases, I don't see how PNG images are any better than GIF images for 8-bit images without transparency. And with many image editors GIF images are a lot easier and faster to edit than PNG images. That is my experience. For 8-bit images (less than 256 colors) GIF is not "less scalable" than PNG images. Both GIF and PNG images are less scalable than SVG though. There is no reason to convert a GIF image to a PNG image if the image is fine as a GIF image. In fact, converting it to a PNG image can CAUSE future problems with scalability. Especially with MediaWiki scaling. --Timeshifter (talk) 15:30, 3 March 2008 (UTC)

It is not a deficiency of GIFs in this case. That is, it can be resized correctly. I did the following one in Photoshop (still transparent):

• Image:Techcrunch-transparent-photshop.gif

Can the resizing code be changed to make it work like this one? —Preceding unsigned comment added by Yegg13 (talk • contribs) 15:21, 3 March 2008

You're right; it's not an inherent deficiency of GIFs. It's a flaw in the MediaWiki resizing code. If you like, you can file a Bugzilla report about it, but it's probably already known. I think the issue is that the Wikipedia resizing code preserves the color palette of the original image, and uses the closest available colors after it does the resizing, which sometimes produces bad results. When you resize the image with Photoshop, the program creates a new color palette to better fit the needed colors after the resizing.

I don't know of any modern image editor for which editing GIF images is easier or faster than editing PNG images. In all modern image editors that I know of, you just edit an image and then save it in whatever format you like; PNG is just as easy as GIF. I also don't know of any problems with MediaWiki's scaling of PNGs (the problem of rescaling GIFs goes away, I think, because MediaWiki converts PNGs to 24-bit color before doing the resizing). I certainly disagree with Timeshifter's claim that converting an image to a PNG can cause future problems with scalability.

In general, 8-bit PNG images with no transparency or binary transparency are very comparable to GIF images. There aren't significant reasons to convert existing GIFs on Wikipedia to PNGs, except for issues such as MediaWiki's GIF scaling problems or in cases where the 256-color limit of GIFs produces a badly dithered image (this requires some image editing to fix, of course). However, often PNG can result in a smaller filesize than GIF (see Portable Network Graphics#File size and optimization software). If you're going to upload a new image to Wikipedia, and you're trying to decide whether to upload it as a GIF or a PNG, generally you should choose PNG, unless it's an animated image. —Bkell (talk) 20:52, 3 March 2008 (UTC)

With IrfanView, for example, if you choose to save a graphic as a PNG image versus a GIF image, the PNG image oftentimes uses many more kilobytes. This is because some graphics use more than 256 colors. For most graphics this is unnecessary. If the graphic started out with more than 256 colors, then converting it to a GIF image instantly lessens the number of colors and kilobytes since GIF is an 8-bit format only. The graphic looks essentially the same. This is fine for graphics. Of course, GIF shouldn't be used for photos. Lessening the color palette and kilobytes in PNG graphics is time consuming. IrfanView comes with PNGOUT in its plugin pack. And I believe that MediaWiki converts even 8-bit PNG back to 24-bit PNG when scaling the image as occurs for many images placed in Wikipedia articles. This causes the scaled PNG image to use more kilobytes than the same 8-bit GIF image when scaled. This is a serious problem for clickable image maps in Wikipedia. I have had to convert PNG images to GIF images in order to lessen the kilobytes enough that other editors would allow the clickable image map at a usable size in a Wikipedia article. The PNG image was too large to use at its original size as an image map. So it had to be scaled. The MediaWiki-scaled PNG image used more kilobytes than the original PNG image, and many more kilobytes than the GIF image. I am also a webmaster, and it is so much easier to use GIF graphics in web pages if one wants a fast way to lower image kilobytes for dialup users. --Timeshifter (talk) 13:43, 4 March 2008 (UTC)

I filed a Bug in Bugzilla as you suggested:

• —Preceding unsigned comment added by 72.94.249.34 (talk • contribs) 22:13, 4 March 2008

(unindent) The problem with PNG scaling (for those who want more info) is more thoroughly discussed here: commons:Template talk:BadGIF --Timeshifter (talk) 09:06, 9 March 2008 (UTC)

The first paragraph of this page says: " Space on the images server is not at a premium, and we should not throw information away." Although I would say I'm fluent in English (my second language), I was not entirily sure whether this was supposed to mean that the space is not unlimited, or not expensive and I had to check a dictionary for the premium expression. I suggest to change the wording, e.g.

• You don't need to worry about disk usage on the image server;
• It is not necessary to throw information away in order to save space on the images server;.

Han-Kwang (t) 07:49, 7 July 2008 (UTC)

I agree, it could be worded better. Note that the phrase "throw information away" (which you copied from the previous wording) should ideally be arranged as "throw away information".

(PS. You are indeed highly fluent, but not entirely.) (*grin*) Ian Fieggen (talk) 00:45, 8 July 2008 (UTC)

Hmm. I am a native speaker of American English, and I see nothing wrong with "throw information away." —Bkell (talk) 21:31, 6 February 2011 (UTC)

Ah, agreed -- I only wanted to change "at a premium" which seemed confusing, maybe because it refers implicitly to price when capacity is the issue. If you prefer any version of "throw information away" to the less kinetic phrasing I just posted, freely change the phrasing. I was just adapting to the critique above while I was in there. I don't have an opinion about it. -- Econterms (talk) 16:32, 7 February 2011 (UTC)

Agreed and fixed. I had difficulty with the phrasing too. Thanks for the specific suggestions! -- Econterms (talk) 20:42, 6 February 2011 (UTC)

In the section where we say svg is the preferred image format for diagrams we recommend scribus, we should probably also mention inkscape, as I know most people prefer it. Also if we provide more options hopefully more people will actually start sending us in svg's. Joshua.leahy (talk) 19:20, 3 November 2009 (UTC)

Under a new top level heading "General concerns" a second level heading "Text" should be created, with the following advice:

The placement of text in images should be limited or avoided, instead placed in the image caption, per Wikipedia:How to create graphs for Wikipedia articles#Guidelines (#3) and Wikipedia:Image use policy#Rules of thumb (#5).

Hyacinth (talk) 23:57, 11 April 2010 (UTC)

This is my first attempt to upload an image of my own creation. I stumbled onto this page so now I know to use SVG. However I expected this page to have a See Also link to the next step. § Music Sorter § (talk) 16:28, 16 June 2010 (UTC)

I saw Commons template Commons:Template:Opaque links to Wikipedia:Preparing images for upload but that page does not mention it.

One, should we add some brief explanation and a link back to Commons in the see also?

Two, and I'm expecting my edit to be mercilessly reworked, but hopefully not blindly reverted, I have added this to the Commons template to suggest making a derivative in cases where a better original is unavailable. My intention is to avoid editors downloading the Commons image, modifying it to remove the background and then uploading a new (PNG or SVG) image and then deleting the original. In the case where no better original image is available I cannot see why deletion is a good idea. An example is File:Mustafafazl.jpg. -84user (talk) 15:01, 17 June 2010 (UTC)

It seems that some uploaded images are produced from screenshots with subpixel rendering (I don't believe that any sane software can export such images). Here is one example: File:BeethovenSymphonyNo5Mvt1SecondTheme.png. There are two concerns about it:

1. Subpixel rendring must match the display type, and thus can look quite ugly if it does not match (rotated screens or printers are just two common examples).
2. It is not intended for scaling, so its resampling can produce noticeable color artifacts.

Therefore, it might be appropriate to warn against using subpixel rendering in the images and to advise turning it off before taking screenshots (if the screenshots are unavoidable).

I don't know how many such images are uploaded, so I'm not sure whether a category to mark them needs to be created...

Mikhail Ryazanov (talk) 04:22, 6 February 2011 (UTC)

I tried to upload a plot in EPS format, and it was rejected due to the file format. I created the plot using IDL, which uses PostScript as its default graphics output format. This document should contain instructions on how to convert a PostScript plot into SVG format. --BlueMoonlet (t/c) 19:55, 2 December 2013 (UTC)

• This page has barely been edited in five years, despite changes to MediaWiki and common practice since then (maximum upload sizes are now 1 gigabyte, SVG is no longer used for just simple images (example), and as mentioned above file size is barely a consideration). Perchance there is someone interested in updating this page? — Crisco 1492 (talk) 14:53, 23 January 2015 (UTC)