Commons talk:Superseded images policy

"This image has been superseded" is not a sufficient reason for deletion!

Deletion of superseded images

I have moved the discussion from Commons:Village pump to Commons talk:Deletion requests/Superseded. The discussion became too long and to crowded. So please continue here a civil discussion without personal attacks. Thank you, -- Bryan (talk to me) 18:23, 26 April 2007 (UTC)

Do not delete "superseded" images!

Over the last months, a system for deleting "superseded" images seems to have emerged - see Commons:Deletion requests/Superseded, {{Superseded}}, and {{SupersededSVG}}, and is used largely to replace PNG files for which an SVG version exists. From what I see, this is completely contrary what Commons:Deletion guidelines says: A clear example which is never exact enough a duplicate to be speedily deleted would be an SVG replacement of a PNG file, and it lists {{Superseded}} and {{SupersededSVG}} as grounds for replacing an image where used, not for deletion. This policy was adopted after we have had some very bad experiences with people replacing PNG images (especially icons) with SVG versions indiscriminately - this lead to much wailing and gnashing of teeth, and entire communities threatening to boycott commons (the dutch wikipedia, notably). You can read some of the discussion here: Commons:Village_pump/Deleting_of_images, there are several more discussions in the village pump archives and the mailing list. So, please beware the following points, and help to make them clear to people using Commons:Deletion requests/Superseded and the respective templates:

• 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!
• Do not delete originals after creating derivatives. It is good practice, and also often required by license, to refer to the original and indicate any changes made to it. Deleting the original because a derivative is available is thus a bad idea, and in some cases even a violation of license terms.
• In case of "official" originals, perhaps scanned, we need the pixel version to check if the SVG is correct. And no, checking once is not enough, we need to have it around to settle any disputes that may arise.

This basically means that "superseded" only applies as a reason for deletion if they have become completely useless - basically only if they are of very bad quality and the "better" version was not derived from it. Which we don't really need a separate deletion process for. So, as far as I see:

• "superseded" tags are useful to point users to different / better versions of an image. They should not be treated as deletion tags at all.
• having an SVG version of icons is useful, because SVG can easily be scaled and edited; However, in many cases it is preferable to use a hand-optimized PNG version derived from the SVG, especially when there are transparent regions, which is often the case with icons. We probably should have a tag for PNGs that are optimized that way.
• SVG versions of maps, diagrams, etc, that do not use transparency, can and should be used directly - but if derived directly from a pixel version, the original should be kept for documentation purposes.

The above was actually adopted as de-facto policy at one point (after much arguing), and partially formalized in Commons:Deletion guidelines. I personally was for deleting "redundant" images in the beginning, but was convinced that it causes way more trouble than it avoids (true duplicates are a different matter, obviously).

So, please help to spread the word... -- Duesentrieb ⇌ 10:30, 29 March 2007 (UTC)

I agree with this reasoning. We have the space... is spreading the word sufficient or should the page itself be sunsetted if consensus exists for it? ++Lar: t/c 12:34, 29 March 2007 (UTC)

Furthermore deletion doesn't actually save space. I think the page could be retasked: Instead of being a deletion discussion it could provide discussion to determine if the superseded image should be replaced on WM projects.--Nilfanion 20:56, 29 March 2007 (UTC)

I agree, I don't really see a use for COM:Deletion requests/Superseded in its current form so it should either be changed and when it's decided a PNG should be superseded by an SVG completely (like a map) the admins add a template to the PNG version and replace the PNG with the SVG, otherwise, no .xxx -> .svg requests should be accepted and it should just be for .jpg, .gif -> .png and the likes. Yonatan ^talk 22:59, 29 March 2007 (UTC)

 Oppose Bugs in internet explorer are not our problem! We should delete superseded images, cause they can re-spread through projects :(. I think there is no need of keeping bad, when we have good ;) --WarX 23:05, 29 March 2007 (UTC)

You have never worked on software that is used in the real world, have you? While you are right in theory, pissing off half the userbase is simply not acceptable. Why do you think MediaWiki's monobook skin ships with extra CSS files for each version of MSIE?

Anyway, "superseeded" versions should clearly be tagged, yes. But generally not deleted. -- Duesentrieb ⇌ 10:38, 30 March 2007 (UTC)

 Oppose So just include the "PNG fix", a small javascript floating around on the internet that works around the transparency bug. (Take a look at the headers of http: //jengelh.hopto.org/ ) That IMHO goes nicely along with the extra IE-specific CSS files. -jengelh (wikipedia) // 134.76.62.65 16:25, 12 June 2007 (UTC)

One may make an analogy with {{JPEG version of PNG}}, a tag usually used to mark "temporary" JPEG versions of PNG photographs. Edits are based on the PNG version, while the JPEG is included on pages for technical reasons. Likewise, we could upload "hand-tuned" PNG renderings, clearly marking them with a tag that says "don't base edits on this image - it's just here for technical reasons" - in this case, transparency.

However, just as with that tag, which I reluctantly created, I believe the true solution lies in software. We should be able to specify how the PNG thumbnail is rendered from the SVG, including colour depth and transparency.

That said, that's no reason to keep the old PNG version around, which can lead to a splitting of effort maintaining the image. And I don't know of any license that requires derivative works to refer to the original work. Dcoetzee 07:19, 30 March 2007 (UTC)

Yes, a marker tag would be the thing to do, making it clear the the SVG should be used as a basis for any derivatives. A software solution would of course be preferrable, but the people maintaining rsvg didn't like any suggestions in that regard, it seems. You can of course get the source and add the desired functionality...

As to licenses requireing a reference to the original - from the GFDL, paragraph 4, section J: Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. Seems pretty clear to me.

Even if not required by the license, having the pixel version around to check against is a good idea at least if the pixel version is authoritative - like for example a flag or coats of arms from a government site, later re-drawn in SVG, or maps, etc. -- Duesentrieb ⇌ 10:38, 30 March 2007 (UTC)

Here are my (ALE!'s) comments to this issue:

First some answers to some comments already placed here by collegues:

1. There is no contradiction to the Deletion guidelines, because:
   • the SVG replacements of PNGs are not speedied.
   • {{Superseded}} and {{SupersededSVG}} are only grounds for replacing, because the images tagged with these template have to be listed for deletion under Commons:Deletion requests/Superseded, where a discussion takes place.
2. transparency is an issue. But I think IE7 now supports correctly (alpha) transparent PNGs, doesn't it? So SVG can be rendered correctly in most browsers.
3. "Do not delete originals after creating derivatives.": There is no need to keep these images, because also the history of deleted images and the original file is being kept in Commons. Another option would be to tag these images with an Do not use this image. It is only kept for reference. tag.
4. "we need the pixel version to check if the SVG is correct": No, an admin can do that if requested. Also, it is the task of the deleting admin to check whether the new (svg) version is correct.
5. "the page could be retasked": Currently, almost nobody works on the deletion requests for superseded images. I think this will be even less the case, if replacing will be the only task. (If not done by a bot.)
6. I totally agree with the argument 'Likewise, we could upload "hand-tuned" PNG renderings, clearly marking them with a tag that says "don't base edits on this image - it's just here for technical reasons"' by user Dcoetzee.

Some personal arguments for the deletion of redundant images:

1. IMHO icons should always be SVGs, because they are freely scaleable.
2. There is no point e.g. to have four, five or more different versions of the same flag available at Commons. There should only be one, a SVG version. Deleting redundant images helps our users to choose the correct version, where various versions in format and contents are available (e.g. flags, COAs, maps, etc.)

Well that is enough for the moment I think. The summary of my arguments: delete redundant images. --ALE! ¿…? 13:14, 2 April 2007 (UTC)

Some thoughts in response:

1. • the deletion guidelines do not list "superseded" as a reason for any deletion, as far as I can see.
   • if superseded is only grounds for replacing, then why have a deletion page for them? I don't see the point. The normal deletion page should be sufficient for cases where there are other reasons.
2. alpha-blending in PNG is supported by most browsers, yes, but not by most users. IE6 is still very widely used, w3schools lists IE7 with 16.4%, IE6 with 39.8%, and Firefox 31.2%. Browser News also has IE6 as the most widely used browser. I guess it'll be another two years or so until we can disregard compatibility to IE6.
3. I strongly believe that original versions have to be available to anyone without any hassle. "Available on request" is not good enough. I also believe that most free licenses require that. An "only for reference" tag would be a good idea.
4. again, everyone needs to be able to check, with a click. Why do you want to make it hard for people? It's like making past revisions on wikipedia available only to admins: that would be unacceptable. Same here.
5. Currently, almost nobody works on the deletion requests for superseded images. - Well, nobody should, IMHO.
6. yes, a "hand tweaked for technical reasons" tag would be good.

As to your personal arguments:

1. there should always be an SVG version of icons, yes. This does not mean we should only have SVG versions - for the reasons stated above, technical, legal and social.
2. Deleting incorrect images is good, yes - but we don't need a special process for that. Deleting variants of, for example, coats of arms, is not good - people should have a choice, be able to compare or even use both, to contrast. Deleting duplicates again is good in theory, but not a priority, and often troublesome in practive. We have a separate tags and process for that though.

Yes, delete redundant images. Not all superseded images are redundant, and I believe most images tagged as superseded as by current practise arn't - but people still treat it like a deletion request. That's not good. -- Duesentrieb ⇌ 16:11, 3 April 2007 (UTC)

We need a way to make an image we are only keeping for historic reasons impossible to inline. One way to do that is to 'delete' it. Deletion also has the side-effect of making the image hard to find and unavailable to non-admins, both of which are undesired in this case. If anyone gets around to implimenting Image: subpages, I hope they also make it possible to flag an image subpage as unavailable for use on other projects... --Gmaxwell 14:01, 2 April 2007 (UTC)

For images we only keep for reference, yes, this possibility would be good to have. But on the other hand... inlining such images in discussion about the image would still be useful. So, I don't know really.

It would be so cool if we could get automatic overlay icons superimposed on images (like icons for copyvio, deprecated, etc), triggered by tags on the description page. That would be useful. -- Duesentrieb ⇌ 16:11, 3 April 2007 (UTC)

You go, Duesentrieb! Version history is extremely important in free copyleft projects like Wikimedia, and we must keep it. We really shouldn't delete anything (we should only supersede things) unless absolutely necessary. --Toby Bartels 23:43, 5 April 2007 (UTC)

• Agree with the original poster. Do not automatically delete. Also, IE bugs ARE our problem if we want WP to be accessible to the widest audience, who may not always be free to choose better browser software. -- Dgpxyz 23:05, 29 July 2007 (UTC)

Sub

<copypasted from de:user talk:ALE!>

Please dont scare other communities with your POV that the images should be deleted. You let it look like a fact, however, I understand from other Commonists that it is rubbish, and they will not be deleted. I assume you will place rectifications on all wiki's where you have placed this message. Maletwasanderes 12:52, 2. Apr. 2007 (CEST)

No, usually I get positive reactions. From time to time I receive a negative one. Especially with regards to COAs and flags I do not understand the harsh dutch crticism against replacing PNGs with SVGs. If you want, you can discuss this on Commons. There is currently a discussion going on at the Village punp. See: http://commons.wikimedia.org/wiki/Commons:Village_pump#Do_not_delete_.22superseded.22_images.21 --ALE! 2 apr 2007 16:22 (CEST)

The problem is that you state that it is quite sure that they will be deleted. As I understand also from that discussion, is that it is totally not sure. So I guess you shouldnt implicate that. About the "harshness": that is because we have/had a few people who were quite familiar on COA's, and saw claerly a lot of times that the SVG-COA were *not correct*, ugly, or did not have the same look as the original, official, version. What *i* do not understand, is your harshness to deleted the PNG's. Please let the local communities decide themselves what they prefer. Let them decide themselves which quality, both the look as the factual part, is best. There is no urge for deletion. It doesnt save disk space, as the deleted version is stored, there is no real advantage to delete them other then to force people to the svg, which is imho a bad thing. (the force, not necessarily the svg). I do not say svg is evil, but the svg's are sometimes wrong, and as there is an advantage to keep them (reference at least) and no advantage to delete them, why would you delete them? It causes a lot of discussion, distrust, trouble, *and* it is quite a lot of work for the admins. Just leave them where they are, and everybody is happy. Please beleive in the judgement of the local communities and do not force everybody to your beleive in the superceding of svg. Forcing a change through someone's throat with false arguments is a bad way to persuade someone too, by the way. Your behavious is probably one of the most important cases why the Dutch Wikipedia is so harsh on Commons. Maletwasanderes 17:43, 2. Apr. 2007 (CEST)

</copypasted>

Commons:Deletion requests/Superseded is illegitimate.

I was about to type a message remarkably similar to the one written by Duesentrieb at the start of this discussion. That it's been "superseded" by an image in a different format is not a valid reason to delete an image. As noted above, there often are advantages to using the older versions. But even when there aren't, it's far more useful to retain the long-standing image as a means of directing users to the newer version via a tag. If it's simply deleted, it's much more difficult for users to find any appropriate image.

According to Erik Möller (conceiver of the Wikimedia Commons and member of Wikimedia's Board of Trustees), policy dictates that "'obsolete' images should indeed no longer be deleted except where they're orphaned and there's clearly no opposition." Obviously, there is significant opposition.

I just learned of the Commons:Deletion requests/Superseded system when ALE! retagged an image on my watchlist (Geographylogo.png) from {{Vector version available}} to {{SupersededSVG}} with the edit summary "we have a deletion request going on". This surprised me, given the fact that the description page contains absolutely no mention of this. In fact, it appears that none of the images listed at Commons:Deletion requests/Superseded contain deletion request tags. In other words, the Wikimedia community isn't even being notified that these images are being considered for deletion. (Perhaps this is why "almost nobody works on the deletion requests for superseded images.") With no link to follow, I had to check ALE!'s contribution history to figure out what was going on.

This underground process needs to be shut down immediately, and all of the images deleted through it should be restored. —David Levy 15:25, 5 April 2007 (UTC)

I retagged the image because the template {{Vector version available}} (as I understand it) is thought for images where a vector version is available but where no deletion request is (or might be) in process. The templates {{Superseded}} and {{SupersededSVG}} are thought for images where a vector version is available and where a deletion request is going or is implicitly proposed by using this tag instead of {{Vector version available}}. For the same reasons I have changed the redirect of the template {{Vva}} from Template:SupersededSVG to template:Vector version available.

But as this discussion is getting a little bit contraverse I will put a message on the page Commons:Deletion requests/Superseded that this deletion process is temporarily suspended due to the discussion here. I hope this is ok for everybody. It seems that consensus is needed first before proceeding.

My personal opinion is, that redundant images - these are images with the same contents, but just in another format - should be deleted. Especially in the case of COAs and flags, I think that all "wrong" images should be deleted and that only one image should persist. Regards. --ALE! ¿…? 20:24, 5 April 2007 (UTC)

1. Again, what you've been doing does not reflect policy. Images should not be deleted because they've been "superseded" by other images. Your personal opinion that this makes them "wrong" is not backed by consensus.

2. Template:SupersededSVG provides absolutely no indication that the image's deletion has been proposed. No mention of this is made, nor is a debate link included. As the proper community notifications did not occur, all of the deletion discussions were carried out primarily by a handful of people who advocate this non-policy-backed behavior. In other words, all of the deletions were invalid. —David Levy 20:53, 5 April 2007 (UTC)

@1.: That is not true. That is not my personal opinion. Superseded images have been deleted before through the "normal" deletion request process. It was common practice. However, theses request where increasingly cloging up the deletion request page and the "normal" request page could not be handled any more. That was why User:Cool Cat started Commons:Deletion requests/Superseded in September 2006.

@2.: Template {{SupersededSVG}} states: "If you just added this tag and want to nominate this image for deletion, please check if it is used and if so replace it with the new image. Afterwards please add the following code to <Commons:Deletion_requests/Superseded>". And further on it says: "Important: Before deleting this file, check if the new one is really superior! Also check: Does the superseding file have a proper license?, Is the representation of the flag / COA / symbol correct?, Are the colours of the flag / COA / symbol correct?, Is the aspect ratio of the flag / symbol correct?, Is the chemical structure the same?"

So this seems quite obvious to me, that there is a deletion request going on or at least possibly going on. --ALE! ¿…? 21:07, 5 April 2007 (UTC)

1. There are legitimate reasons to delete "superseded" images, but the mere fact that they've been "superseded" isn't one of them. After a great deal of discussion, it became clear that there was no consensus for such deletions.

2. The above text contains absolutely no mention that the image has been nominated for deletion, nor is there a link to the discussion. As I said, I had to check your contribution history to figure out what "deletion request" you were referring to.

This is what people expect to see when an image's deletion is proposed, and I can't imagine why it wasn't adapted for the Commons:Deletion requests/Superseded process (unless I stop assuming good faith). —David Levy 21:30, 5 April 2007 (UTC)

I can assure you that there was no "bad faith" it was only an afford of some people to get the deletion request page to work again.

@2.: "The above text contains absolutely no mention that the image has been nominated for deletion": Ahm, I see it. You do not?

I'll be out of here for a couple of days for vacation. But please do not hesitate to discuss this further. We need a (new?) consensus on that or at least clear guidelines. But please keep in mind, that these deletion requests for superseded images should not clog up again the normal deletion requests IMHO. Read you soon! --ALE! ¿…? 21:44, 5 April 2007 (UTC)

1. I'm not claiming that anyone has acted in bad faith. I would have to stop assuming good faith for the lack of a proper deletion tag to make sense to me, but I have not done that.

2. The text in question merely explains what to do if one wishes to nominate the image for deletion. It does not indicate that this already has occurred, nor does it provide a link to the discussion. This is not a subtle distinction.

3. Deletion requests for superseded images needn't clog the normal process; there's no need for most of them to exist at all. —David Levy 22:02, 5 April 2007 (UTC)

It also appears that the images' uploaders were not notified of the proposed deletions. I honestly don't understand why anyone believed that these obscure, unadvertised discussions were remotely legitimate. —David Levy 22:10, 5 April 2007 (UTC)

Hmm... anyone want to put Commons:Deletion requests/Superseded up for deletion? Ahh the irony ;)--Nilfanion 23:57, 5 April 2007 (UTC)

Deletion of superseded images would make sense if deletion meant deletion. However, as "deleted" files still exist on the servers there is no gain there. Basically we would end up hosting a load of free images formats that are not actually available for use.--Nilfanion 00:04, 6 April 2007 (UTC)

If a better version of same image is uploaded, old version can go so as not to be used (we still have PNG/JPG flag usages when svg is available). Whats the issue here? -- Cat ^chi? 00:19, 6 April 2007 (UTC)

Did you bother to read the above discussion? How about the related discussions that preceded your creation of this largely hidden deletion process? —David Levy 00:42, 6 April 2007 (UTC)

Keep the raster. It's not doing any harm. You guys need to stop being such elitists. Just replace the png/gif/jpg/etc with an svg on the wikipedia page and move on. -Indolences 00:47, 6 April 2007 (UTC)

I would agree. Unless if it is a bunch of png road signs, and they are sent to deletion requests, don't delete superseded images.  V60 ^{干什么？ · VContribs} 02:52, 8 April 2007 (UTC)

While in general I don't have a problem with in general with replacing PNGs with SVGs and don't give a hoot about the plight of IE users, I think stricter requirements for the removal are required. For instance, in the case of PNG files that are part of a package (such as icons), we should either replace the whole package or not at all (I'm not saying we can't upload the SVGs, but that we shouldn't force out a full set for an incomplete set). Another issue is quality and authorship. Are the SVG replacements the official replacements for a particular set? If the SVGs come from the authors of the PNG version or are derived from the same source files then I daresay that they would be up to the quality of the originals. That is my small rant on the subject. Dread Lord CyberSkull ✎☠ 08:18, 8 April 2007 (UTC)

I agree that this should not circumvene deletion process; I have had bad experience with a user using it to delete 'competing' images when he thought he uploaded better the picture of the same object (building, etc.); he would tag other users' images with superseed even if the angle/time/etc. where different arguing that his images are better quality...--Piotr Konieczny aka Prokonsul Piotrus ^Talk 05:17, 9 April 2007 (UTC)

I just discovered this discussion and should weigh in since I have contributed to superseded image deletions. I want to address to major points: 1) Policy issues and 2) procedural problems.

1. With regards to policy issues, let me requote Erik Möller that policy dictates that "'obsolete' images should indeed no longer be deleted except where they're orphaned and there's clearly no opposition". When an image is posted for supersession, the two images are compared by an administrator to make sure that new image is really a replacement. Often this includes a png vs. svg where the image content is exactly identical. There is no reason to keep identical images, and regarding the issue of transparency, we should not have to maintain an otherwise needless duplicate just for MSIE users. It should not be the job of the commons to enforce browser compliance with standards. That's a maintanence nightmare that would never end. All that said, if licensing requirements require the original image to be kept, then by all means we should not delete. Similarly I want to be clear: an image should never be deleted if it is not orphaned. The purpose of this page is to have a discussion and determine if there is an opposition to it being deleted. Thus Erik Möller's two requirements are accomplished. When an image is found to be superseded, it must first be orphaned before deletion (via CheckUsage). Images that are already orphaned are generally "automatically" deleted if there is no other opposition. There are plenty of other valid reasons for deleting superseded images, including deleting images that are wrong. I want to address David Levy's comment: "That it's been "superseded" by an image in a different format is not a valid reason to delete an image". This should not be considered a blanket deletion: images should be deleted for a number of reasons and there are good and bad reasons to supersede an image. This is not speedy deletion, but a discussion for deletion that may result in an image being kept. If we have two flag images that are identical and one is a png and the other an svg, it makes perfect sense to eliminate the png, since it is not efficient and has scaling issues. In this case, "a different format" is a perfectly valid reason to supersede.
2. With regards to procedural issues: Supersessions could be used for abuse, but that is no reason to oppose the page itself. This is a procedural issue. Similarly, whether or not it is clear that it is a deletion is a matter of clarifying templates and perhaps updating and clarifying the process pages. Now if there is an issue with the superseded page being "in the dark" or user's not being notified, that's also a procedural issue that should be addressed.

-- Ram-Man 15:40, 10 April 2007 (UTC)

1. Your statement that "there is no reason to keep identical images" is false. There are reasons why otherwise identical images in other formats can be useful. Your opinion that "we should not have to maintain an otherwise needless duplicate just for MSIE users" is indicative of precisely the sort of elitist attitude that is alienating the other Wikimedia projects from the Commons.
2. It's funny that you would quote Erik Möller's statement that "'obsolete' images should indeed no longer be deleted except where they're orphaned and there's clearly no opposition." Just before I noticed the above reply, I stumbled upon a debate from Commons:Deletion requests/Superseded in which someone opposed an image's deletion (because it was not identical to the image by which it was "superseded"), but you deleted it anyway. Of course, it's very difficult to analyze these discussions (given the fact that the standard procedure is to blank them, thereby further obscuring the already obscure process through which images are improperly deleted without community notification, uploader notification or consensus). I was trying to find the discussion through which it was determined that one of my images was worthy of deletion, but the deletion log merely indicates that it was deleted through this process (without specifying the page location or date of listing). It's almost as though the operators of Commons:Deletion requests/Superseded have gone out of their way to make it as difficult as possible for other users to review the proceedings.
3. I plainly stated above that "there are legitimate reasons to delete 'superseded' images." There is not, however, a need for a separate process (let alone an underground process through which a handful of users list images without notifying the Wikimedia communities or the uploaders, ignore the outside feedback that they do receive, and delete images that people want to use despite an obvious lack of consensus). It's been noted that the regular deletion process was being bogged down by the number of "superseded" images listed, but that was only because people were blindly nominating perfectly good files for deletion (purely because they were "superseded").
   Commons:Deletion requests/Superseded is/was a solution in search of a problem (and a creator of new problems). —David Levy 15:19, 17 April 2007 (UTC)

I was really unaware that the process was so difficult to use and that it was difficult for others to review. I just used the procedure as it had been used and didn't know any better. I have not deleted any more images since discovering these serious issues. As for the specific example you cited above, it seemed clear that the orphaned image was not possibly going to be reused because the opposition was on purely theoretical grounds whereas the reason to delete was one of practical usage. Let me explain: The opposition just said we shouldn't delete it because it was different. It definitely was different. However, the issue was clarified by additional information: The image was no longer useful for the reasons given. The very people who were using the image obsoleted it. I deleted it over a theoretical objection that didn't seem to matter. The reason for deletion was not based on the fact that it was simply replaced but that the previous image was made useless. It has very specific content. If someone feels it was incorrect, they can restore the image. -- Ram-Man 13:22, 24 April 2007 (UTC)

1. I'm not blaming you (or anyone in particular). I just want to determine why so many important, longstanding practices were abandoned in the first place (and why no one involved seemed to notice) and ensure that nothing similar happens in the future.

2. Regarding the specific case cited above (selected at random), my concern applies to all of the images deleted through this process: proper notification did not occur, so the discussion did not adequately gauge consensus. —David Levy 04:48, 25 April 2007 (UTC)

MSIE 7 supports alpha transparency. Furthermore, we ARE allowed to delete images. We need to specify source, but not to keep the original. Anyways, that's what the Creative Commons and the GPL says. --80.63.213.182 18:22, 10 April 2007 (UTC)

So now it's policy to go around replacing PNG images with crappy SVG images, remove all instances of the PNG, and then delete it because it's "unused"?? — Omegatron 02:56, 13 April 2007 (UTC)

Oh, no, I did not mean to imply this. If the svg images are not substantially identical or improvements, then the original should continue to be used. In cases like that, the svg is sometimes deleted. Removing all the instances of the png is still no excuse for making sure that the svg is the same or better. That is the point of the discussion, to see if there are any objections. Policy does not allow for blanket deletion of png with svg files. -- Ram-Man 12:25, 13 April 2007 (UTC)

Unfortunately, some people seem to be running somewhat rampant with deleting raster images without checking whether the SVG is similar in relevant respects and of good quality -- including User:ALE! when he deleted Image:No_cross.png with no warning whatsoever on its image description page (which I had on my watchlist), merely because of the existence of the crappy misproportioned low-quality non-equivalent SVG file Image:No_cross.svg. Therefore I support any reasonable measures to put the brakes on these careless or over-zealous deletions. AnonMoos 16:54, 13 April 2007 (UTC)

Yeah, I don't have a problem with a renewed call to be more judicious and careful. I'd just rather not see a useful process go away, since there are legitmate uses for it. I've probably made some over-zealous deletions myself, but I'll be more careful from now on. -- Ram-Man 12:29, 16 April 2007 (UTC)

I do agree with Ram-Man. We must find a concensus and discover a better way to use the "supersededSVG" procedure. It is really helpful in order to reduce redundancies, taking off a large amount of requests from the "normal deletion" procedure. Maybe we were not careful enough to judge which images are REALLY superseded. In my perception, what Erik Möller wanted to say is that 'A superseded image MAY be deleted, IF it is orphaned and there is a concensus -- so, it depends upon each case. Also, in the case of SVG, I do agree that we must consider the preview problems in the browsers -- something I'm always trying to fix... --Tonyjeff 02:57, 18 April 2007 (UTC)

Once again, someone is noting the need to lesson the burden placed on the normal deletion process without explaining why these images need to be deleted at all. It's patently obvious that there is no consensus for the idea that we should "reduce redundancies" by removing free images purely because they've been "superseded."

Erik said nothing about "consensus." He plainly stated that "'obsolete' images should indeed no longer be deleted except where they're orphaned and there's clearly no opposition" (emphasis mine).

Of course, these images were deleted without consensus. (No notifications were provided to the communities or the uploaders, and the few outsiders who were able to object evidently were ignored.) Can someone involved in this process please explain to me why:

1. The images were not tagged to indicate that they'd been nominated for deletion or to provide links to the discussions.

2. The uploaders were not notified via their talk pages.

3. The completed deletion debates were blanked.

4. The sysops included no links to the relevant subpages in the deletion summaries (making it extremely difficult to even find the discussions in the histories and determine the rationales behind the deletions).

—David Levy 14:29, 18 April 2007 (UTC)

I feel like you are being ignored. No one else has really bothered to adequately explain it. I'll try from my relatively new perspective. I have not been a commons admin for long, so I just assumed the process was acceptable. It apparently had problems I was unaware of until this discussion. 1) Images were not tagged for deletion and links provided to discussion because the procedure was never determined to be necessary. Yes, this is a blatent oversight for sure and it should be remedied. I don't think this was done in bad faith however. 2) I never notified uploaders because the instructions did not list that as a requirement. Again, this was an process oversight which should be fixed. 3) The images were blanked, I would guess, because it made it easier to view the complete list. There were so many on the list that all those red-links made it difficult to view the page. There was no attempt to conceal the actions, only to make the process easier. Clearly looking back I can see why it would be vitally important not to blank the pages. Oh well, fix the problem and move on, I say. 4) Adding subpages to deletion summaries would be really easy. I could have globally done that in 5 minutes had I known it was required. In fact, I used to delete images without even specifying which image was replaced in the edit summary. Someone asked me to add that, so I did. (See the CheckUsage template). -- Ram-Man 13:32, 24 April 2007 (UTC)

1. As noted elsewhere, I don't blame you (and I commend you for taking this matter seriously and addressing the community's concerns).

2. The reason why it's difficult to understand why the images weren't tagged for deletion and the uploaders weren't notified is that these are standard steps in the Commons deletion process. I assume that everyone involved was acting in good faith (and I understand that you lacked familiarity with the accepted procedure), but it's baffling that none of the experienced Commons admins noticed and rectified these obvious flaws.

3. Instead of being blanked, closed debates can be hidden (but remain available for review) via JavaScript. See, for example, this subpage from the English Wikipedia's deletion review process. —David Levy 04:48, 25 April 2007 (UTC)

I don't understand what it is with those SVG-files. They shouldn't be used at all, since WP is a free enzyclopedia and most users can't use, ie. transform such into another format, at all. AFAIK noe free programm exists which reads SVG files and stores them in another format, e.g. .png or .jpg --213.155.224.232 16:35, 25 April 2007 (UTC)

David, clearly no opposition needs some kind of concensus, doesn't it? About the comment of user 213, SVG files are easier to be edited than PNG. --Tonyjeff 17:42, 26 April 2007 (UTC)

False. Inkscape is free and has full exporting ability. Palmtree3000 19:23, 26 May 2007 (UTC)

Chemical structures

I have noticed that certain users replace chemical structures (that exist as high-resolution PNG files with transparent background, according to the Wikipedia WikiProject Chemistry structure drawing guidelines) with low-quality SVG images (e.g. Image:Dimethyltryptamine.svg vs. Image:DMT.png) and tag the PNG version for deletion. This is not acceptable and should be discussed first on the WikiProject Chemistry discussion pages. Cacycle 14:46, 11 April 2007 (UTC)

Yes, seconded! This problem has plagued us for some time - we have a perfectly good, compact PNG file, then someone from outside of the Chemistry project replaces it with an inferior SVG. Only rarely is the SVG as good as the file it replaced. We often have to spend our time restoring the good quality image and orphaning the SVG, assuming we find the problem - usually we aren't informed of the change. I think we need to make sure that

1. Only people who have the tools to make top-quality SVG files work on replacement.
2. In areas like chemistry with specific needs, the people working on this need to work with the relevant WikiProject, to ensure compliance with subject-specific standards
3. If a PNG file is to be deleted, the author should be contacted.

We are not opposed to properly done SVG files - indeed, we are currently trying to get one software company to adapt their en:molecule editor to generate SVG files - but most "conversion jobs" (PNG to SVG) we have seen in chemistry are worse than the files they aim to replace. Walkerma 15:58, 11 April 2007 (UTC)

A number of these files have been posted but were denied supersession after discussion and both files were kept. I processed some of the requests myself. But yes, it would be helpful if this issue were addressed. -- Ram-Man 16:55, 11 April 2007 (UTC)

Could anyone point out what in the two images above makes Image:Dimethyltryptamine.svg inferior to Image:DMT.png (im not saying it's superior)? A problem with taking checking everything with wiki specifik porjects is that it's not always the case that the person supplying the new file knows about them. It might also be the case that the new files are being produced by a WikiProject Chemistry on another wiki. The easiest way to get around all of these troubles is if a branch of WikiProject Chemistry opened here on Commons where you could discuss these things and you're concerns with the contributors and members of similar projects on other wikis. /Lokal_Profil 15:07, 13 April 2007 (UTC)

One problem in the SVG version is that the heteroatoms are not centered between the bonds. In addition the relation between the bonds and the heteroatoms changes if you scale the picture with your browser (Ctrl + mousewheel in Firefox). --NEUROtiker 13:35, 15 April 2007 (UTC)

I have recoverted the file to svg, and it seems to be high quality. the pic you are refrering to is now at this archive. --Ashfire908 19:37, 17 April 2007 (UTC)

What happened, the image now looks hideous. It's a skill to be able to get a pixlated svg. Reverting the image.

NEUROtiker, I take it you meant that the N isn't correctly centered between the bonds? Yes that is a miss in the svg. Didn't get a problem when I scaled the image though. /Lokal_Profil 18:33, 18 April 2007 (UTC)

@Ashfire: Did you convert this PNG to SVG? They seemed to match perfectly, even in size.
@Lokal Profil: The problem with heteroatoms not centered can be solved by transforming the letters to paths. The scaling problem appears only when scaling with the browser (e.g. here) not via wikisyntax. --NEUROtiker 22:17, 18 April 2007 (UTC)

The text has now been converted to paths and I centered the N atom in between the bonds. This seams to have solved the scaling problem (which looked hilarious btw) aswell. Don't know if it has any relevans to the discussion further down on this page but the svg file seems to contain metadata about something called cdml and seems to have been constructed using BKchem. /Lokal_Profil 11:13, 21 April 2007 (UTC)

It is so easy :)

Well, the problem seems complicated, but let us bring it back to proportions. An easy question, to which I have not seen an answer yet:

1. What is the advantage of deleting the 'superseded' image (assuming the image in question is indeed superseded). Also assuming that the the description page would point to the better version.
   1. The only thing I can think of is "categorizing". It is some easier to categorize a smaller amount of images.
2. Are there problems with deleting superseded problems? Well, quite some:
   1. Source material can be deleted. When a png is used as source for svg, it should be kept. When a process exists to delete superseded images, there will always be some images that are deleted when they shouldn't.
   2. When the superseding image is a derivative, the original should be mentioned for license purposes.
   3. url's from external don't work anymore. People are pointed to a non existing image, without a proper notification where the new image is.
   4. Communities can not make their own decision any more on what they prefer: png (for the MIE-users sake for instanse, or any other reason they may come up with) or svg (scalability). Imho it would be best to let the communities choose themselves. Deleting the superseded image would *force* them to a certain choise.
   5. Communities have little / loose trust in Commons every time an image is deleted they want to use. At least the Dutch Wikipedia community has quite a low trust level in Wikimedia Commons due to the deletion of superseded COA and flags. This went wrong a lot in the past, and apperently still happens. The risk is that they will host the content on their own wiki locally, due to lack of trust in Commons. That would mean unnecessarily waste of disk space in Florida.
   6. And, last but not least, everytime it gives a lot of discussion, and it also costs a lot of time to nominate and delete those images at all. I guess we can all think of some better uses of that time.

This combined, I think the choise should be quite easy. Little advantage to deletion (please clarify to me when there appears to be a major advantage to deleting, I haven't seen it yet) and a lot of arguments against. More important: Quite a lot of people against the process. And keep in mind: some are against deletion of COA, some of the flags, some of the chemical structures, but that is only because you can judge that area. It is logical that similar errors happen on other area's, but are not noticed by you, as you are less an expert on that area.

greetings, Effeietsanders 19:26, 15 April 2007 (UTC)

One thing in favour of deleting superseded images is that it's simply easier to find the good/final version of an image. It's also easier to make sure hat the old/incorrect/superseded image is not being used. Note that this argument is only for images are properly superseded, i.e. duplicates but different fileformats or similar. Not deleting some superseded images would also mean that we would have to change the "duplicate" deletion condition to accept images of different fieltypes. There are lots of gif images here which are superseded by identical png images, or png images generated from vector files where the original vector file is now uploaded. If we stop deleting superseded images then these type of images should be able to qualify for duplicate deletion. /Lokal_Profil 22:23, 15 April 2007 (UTC)

@ good / final versions: This is a good argument. IMHO there should be only one, correct version of a COA or a flag. There is no point to have 10 variants around if there is only one true version. (However, if there are also unofficial variants we should keep them, tagging them with something like {{Unofficial variant}}.

@ duplicates with a different file format. We should extend the {{Duplicate}} process to identical files in a better file format (png instead of gif, png instead of jpg for COAs/flags, svg instead of png/jpg/gif for COAs/flags/drawings). I stress on "identical". If there is the need to have a png/gif/jpf for reference or for technical reasons, these images should be tagged with something like {{For reference}} or {{Duplicate (tech)}}. So they are not used.

@ categorizing: The images kept for technical reasons or for reference should be moved in a subcategory of the correct category (category:flags of Argentina (duplicate versions) instead of category:flags of Argentina) or in a special category (category:reference images and category:technical duplicates).

Regrads --ALE! ¿…? 09:53, 16 April 2007 (UTC)

Even the wrong versions should be kept imho. This is an example where it could be usefull as reference for the future. It can be good documentation. It is just very important that these images are well documentated, and that they point to the correct version. Again I see no advantage in deleting the image over tagging them correctly. It happens all the time that an error is made (we're all humans), so it can be very well that in fact the good image is deleted. Especially on flags and COA. (I've seen it happen several times)

I still don't get any reason why a png should be deleted if a svg is available, even if they are exactly identical. I think this is a principal question, as it is here about who should make the decision what version a community uses. If a community decides that the MIE users are very important to them, or that they feel that SVG flags are too cartoonish and do not look realistic a lot of times (that is actually an opinion among some users), and they want to use PNG instead of SVG, who is Commons then to stop them from deciding and doing that? Why should it be Commons here who makes that decision. It should imho be the responsibility of the communities to decide over A) the content (i.e. what is the correct version) and B) what rules they make for layout, which includes the choise for PNG or SVG. Commons should support them in making the right decision (mostly by documenting the choises and arguments well) but Commons should *not* take over that responsibility. It is not able, nor should it be willing to.

For categorization a solution can be found. That is just a question of time and consensus seeking. A possibility is categorizing with [Category:Blablabla|ZZZ Subject] so it always ends up on the tail side of the category. Another possibility is the subcategory, or even a big huge seperate category. Personally I would prefer the |ZZ subject] idea, as that doesnt require more categories, especially for small subjects with little amounts of "duplicates".

It's also easier to make sure hat the old/incorrect/superseded image is not being used.. Yes, that is true. But then again, it would be commons deciding what should and what shouldn't be used anymore. Even incorrect images have their function :) Especially on flags it is not for nothing that it is incorrect. It might be an outdated version (thus historically important), it might be a commonly made error (thus encyclopedically important) or for some other reason important. Usually it is very very hard to dig into every image so deep that you can positively assure yourself that there is no such situation. The chance that you will not find such a reason while it is there is quite big, so correctly tagging them as incorrect might be the best approach.

My proposal: Make a clear decision that images should *not* be deleted when it is a duplicate, and should *not* be deleted when an outdated or incorrect version of a COA/Flag (and maybe some other categories of images too?), except the case where an uploader made for instance the mistake to upload twice the same image (like .png and .PNG). Further these images should be clearly tagged as such, and categorized as being a duplicate or being an incorrect version.

The main argument: Communities should be able to make their own decisions on the behalf of which image they prefer, for whatever (sometimes maybe silly) reason. Further there is little to no advantage to deleting these images. It is better to not delete 100 images that could have been deleted then that 1 image is deleted while it should not have been.

I hope that you people support this. Effeietsanders 12:19, 17 April 2007 (UTC)

The answer to why commons should decide is because commons is pretty much in charge of images and if there's a decision by the community to delete all PNG dupes of SVG's (and there's no big disadvantage to using SVG's, ie. all MSIE users having SVG's rendered incorrectly) then it should be enforced and if local projects want to have PNG versions they are welcome to upload them locally. HOWEVER, in this particular case the argument does not hold water since there is no community decision to do this and SVG's show up messed up in MSIE but if Microsoft released a patch fixing this in IE6 (very unlikely) or if a year from now IE6 is rarely used, I would support deleting PNG's since a different file format doesn't make it a new work IMHO which means we don't need to link to the source as the SVG is the source. Are you opposed to the current deletion of non-animated GIF's after they've been converted to PNG's? I think there's no problem with it even for the different projects and the moment SVG doesn't show up with a white background in IE we can do a similar thing with PNG->SVG IMO. Yonatan ^talk 13:31, 17 April 2007 (UTC)

1. The Commons is not "pretty much in charge of images." The Commons acts as a file repository for the other projects. We work for them, not the reverse. If a Wikimedia project wants to use a free file, deleting it here (and forcing that project to upload the file locally) encourages its members to distrust the Commons and keep its free media to itself. If even one additional project wants to use the same file, it also wastes disk space. Those are very bad things.

2. GIF is now a 100% free file format, and it always will be compatible with more browsers than the PNG format is. In some cases, the difference in file size is negligible or nonexistent (and occasionally, a GIF actually is smaller than its optimized PNG counterpart), so there's no valid reason to delete a GIF simply because it's been converted to a PNG. —David Levy 15:19, 17 April 2007 (UTC)

I'm not commenting as to whether it's justified or not but the fact is that today we reupload most if not all re-animated GIFs as PNGs and most of the time the original GIFs are then orphaned and deleted as dupes. As I said above, I don't think deleting PNG's just because we have SVG's is the right thing to do *at the moment* but if the issues with SVG's are sorted out there should be no difference between that and what currently goes on with the GIFs, unless, that is, what goes on with GIFs at the moment should be stopped as well. Yonatan ^talk 03:04, 18 April 2007 (UTC)

Yes, what goes on with GIFs at the moment should be stopped as well. There certainly can be valid reasons to delete GIFs that have been superseded by PNGs, but the mere fact that both exist isn't one of them. —David Levy 14:29, 18 April 2007 (UTC)

I just want to reaffirm that I am opposed to blanket deletion of PNGs just because an SVG replacement has been created. I am also opposed to blanket replacement of PNGs with SVG replacements. The SVGs are very often of worse quality than the PNGs, and the PNG version may be needed on specific wikis for specific reasons that haven't been thought of by the person going around replacing them without asking. If you create a replacement image, clearly tag the old image as having a replacement, but let individual users decide if they like the replacement better.

If you want to go around to every wiki, do so, but not to replace the image. Instead, make a note on the talk page that a newer version is available so that the article's editors can decide if it is actually better in their particular situation. We could create a standard template for this with the same name on all projects, but which displays text in the local language. — Omegatron 14:18, 20 April 2007 (UTC)

• I fully support Duesentrieb's initial statement. Do NOT delete superseded images. --Rosenzweig 22:51, 20 April 2007 (UTC)

This attitude is really alarming

@ good / final versions: This is a good argument. IMHO there should be only one, correct version of a COA or a flag. There is no point to have 10 variants around if there is only one true version. (However, if there are also unofficial variants we should keep them, tagging them with something like {{Unofficial variant}}.

@identical files in a better file format (png instead of gif, png instead of jpg for COAs/flags, svg instead of png/jpg/gif for COAs/flags/drawings). I stress on "identical". If there is the need to have a png/gif/jpf for reference or for technical reasons, these images should be tagged with something like Template:For reference or Template:Duplicate (tech). So they are not used.

@ categorizing: The images kept for technical reasons or for reference should be moved in a subcategory of the correct category (category:flags of Argentina (duplicate versions) instead of category:flags of Argentina) or in a special category (category:reference images and category:technical duplicates).

Regrads --ALE! ¿…? 09:53, 16 April 2007 (UTC)

Let me begin by echoing the above endorsement of Duesentrieb's initial statement, Omegatron's, David Levy, and Effeietsanders. Let me further add that after reading all the above, is that perhaps what is really needed here is a deletion nomination of the templates and total eradication of the concept of "superceded by", "superceding", "better" and such judgmental evaluations by a belief system on shakey ground at best.

Don't want to get too personsonal on this but who the hell appointed you dictator of any policy, much less the whole commons and the rest of the Wikimedia Foundation Projects? Just because you see or perceive some benefit to Svg's over other long standing graphics technologies does make that ALLEDGED improvement into actual fact. Your biases are just a theoretical abstraction without a long track record to back them up, or you wouldn't be getting gripes about quality concerns and bad effects.

The first grapics capable computer system I programmed code for in 1975 used vector graphics, but that doesn't make the technology superior in all or even many cases. Back in the mid-eighties, the conventional wisdom was all printer output would become post-script—a technology with much in common with Svg's as I understand it. Hah hah... ROTFLMAO!

CW is usually wrong, and the concept that svg's should EVER supercede other technologies in all cases is more of the same hopeless idealisms being pushed by a noisy minority from what i have seen the past eight months.

So I'll repeat what Deusentrieb said on that too... you must have little or no real world experience with large diverse systems... which means you need to throttle down your enthusiasms and drop juvenile black-white judgments across the board. Radical changes are rarely good things and will hardly ever get good receptions. Things are rarely that easy in the real world... it's a messy place as this discusion shows.

1. Fact: IE6 is and will be the predominant and most important browser for off the shelf computers in by far the most households for at least two years. Most people are very leery or clueless about updating to the newest latest greatest... and rightly so. Most greatest-latest is "Advertisers doing their usual Lying", as most anyone with 20+ years as an adult consumer learns and knows intuitively after a while. To "write off" IE6 users is to cut our own throats in all the foundations projects and is a patently bad idea. I've seen an estimate that about 75% of our readers are using IE6, and you want to ASSUME that customer base keeps up with new fangled fads like Firefox! Because you (and technically savvy young people do--are we to write off the young folks who aren't tech heavy, and the generations older than them who would love to have the time to just have a hobby and wouldn't do that on a computer? What about the many readers who use a community computer that have no control over the software suite it uses?
   
   Why for pete's sake would anyone trying for maximum circulation (as most of aim for) would we want to take that attitude? What proof can you give me that even a tenth of the people I email regularly have updated beyond MSIE-6? None, if your realistic and honest. I know for a fact several are still using MSIE-5 and Windows-95/98. So Game - set - match on that one.
   
   Maybe it's an old person thing, but those of us who grew up before the Eighties sort of have this strange idea that things are supposed to work properly out of the box and keep working for years as bought. The idea that something should be updated is anathema, and asking for trouble. By extension, if BMPs, Gifs and jpg's and such worked fine ten years ago, we expect them to work BETTER now, not to be replaced by the newest fad.
   
   
2. Fact: Many Svg'S have scaling issues, which none of the above is addressing whatever. This shows up as partial images, blank images, and is dependent upon not the browser used, but the zoom-in/zoom-out applied, or that and the combination of image size preferences.
   
   This is occuring even when they are high quality. As I understand it from discussions on this on en.wp WP:VPT last month, our servers are still converting Svg to Png then sending that out, not SVG's.
   
   
3. Editorial choice of competing images should be kept and maintained. Period. Forcing an image replacement on an editor because of some elitest beliefs as emperor of the universe demotivates the poor sod in the trenches pouring man-days as a volunteer into making an aesthetically pleasing as well as accurate page on the main foundation projects. That should not be decided for them by someone working an archiving project like this one.

1. Bad Thinking, simplistic: png instead of gif, png instead of jpg for COAs/flags, svg instead of png/jpg/gif... all that crude is a judgement this project has no business making. There are for example DOZENS of administrative templates on en.wp using gifs and they are mostly all carrying a disclaimer as an imbedded comment to NOT replace the gif with a png, etc.
2. Bottom line, the cabal pushing svg's is not working to consensus at all, but has probably been feeding off of other people of like mindset, and is confused. Most of us don't care a bit until and unless it costs us extra time, and I think that verdict is in. SVG's suck, and are far more trouble than they're worth, to put it bluntly as an engineer of many years experience. All I've seen the tech being forced down our throats do is cost other people time we could be using to otherwise improve the projects. This svg initiative isn't working, was a bad idea to begin with, and enough time has passed to see that it is both unrealistically idealistic, but in effect, disruptive. Sorry, but that's the way I've seen it and I've been concerned about it for a long while now. Best regards // FrankB 06:56, 22 April 2007 (UTC)

Although FrankB says he agrees with me, I'd like to make it clear that I disagree with him on the subject of SVGs "sucking". The SVG format is great, and I support using it for diagram-ish graphical images. (I'm also an engineer, though I don't know why this is relevant.) However, that doesn't mean there's anything inherently wrong with raster formats, or that there's some urgent imperative to replace high-quality PNGs with high-quality SVGs (why not first spend our time creating images that haven't been illustrated at all?) And it is not Commons' place, in general, to decide that an SVG is in fact superior to the PNG it is meant to replace. By all means create SVG replacements, and tag the original PNGs as such, but then leave it at that. Don't go around changing the image in every instance. It's not automatically superior just because the file format is superior. The image itself might be better, but it might not. Let the editors who are actually using the image decide which they prefer. If you want to go around to all the projects, fine, but go to the projects to notify them that there is a replacement, and let them decide if it suits their purposes. I also disagree with eradicating the "superseded" templates. They need to be reformed, not destroyed. — Omegatron 02:53, 8 July 2007 (UTC)

You have a different position than I have. You said "I do not want to get personal". But you do! So please base your arguments on facts and do not implicitöly insult me, ok?

Some facts:

• I was not appointed to anything more than being an Admin and I was working on the deletion requests. When Cool Cat changed the deletion request process for superseded images nobody complained and it was a good idea because the "normal" deletion request process was not working any more. So I was working on the superseded images deletion requests. Nothing more. I am not any dictator (dictators do not get elected).
• Superseded images were already deleted for being redundant in the "old" deletion request process and only very rarly somebody complained.
• But I am not the only one who has the same opinion on the superseded images. Anyway, we should find a consensus.

So could someone please propose a good proceeding for the future? Especially with some focus on the fact, that there is usually only one true version of a flag and a COA. An we should vote on the new process, when it is designed.

So, please would you all calm down and make some proposal for the future handling, which shouldn't be a muddling through process. It does not help our users. --ALE! ¿…? 10:12, 22 April 2007 (UTC)

"Nobody complained" about Commons:Deletion requests/Superseded because almost no one knew about it. As you've continued to defend this underground process as "a good idea," I'll once ask the questions that were ignored above:

1. Why weren't the images tagged to indicate that they'd been nominated for deletion and to provide links to the discussions?

2. Why weren't the uploaders notified via their talk pages?

3. Why were the completed deletion debates blanked?

4. Why did the sysops include no links to the relevant subpages in the deletion summaries (making it extremely difficult to even find the discussions in the histories and determine the rationales behind the deletions)?

—David Levy 05:22, 23 April 2007 (UTC)

As I've pointed out, this type of argument can be caught in the red-herring logical falacy if we are not careful. The reasons you list above are all procedural issues with a simple answer: Just because that's the way we do it. It is simple. It may be very wrong, but the answer is easy: Change the procedure to implement the things listed above. The answer is not to eliminate supersession of images. That's a totally different argument from the procedural problems you list above. There is plenty of indication that consensus does not support the current procedure but that it does support superseding images, when done properly. -- Ram-Man 19:43, 23 April 2007 (UTC)

1. Yes, we're dealing with two separate issues, and I'm not suggesting that the idea's horrendous implementation automatically means that it should be scrapped entirely. I just don't think that it's unreasonable to expect an explanation of why this blatantly inappropriate conduct went on for months.

2. "Just because that's the way we do it" is not a valid response. You do realize that we need to restore all of the images deleted through this improper process, don't you?

3. I see absolutely no consensus for the routine deletion of "superseded" images; there actually appears to be far more opposition than support (not to mention Erik's statement). —David Levy 21:49, 23 April 2007 (UTC)

I may have oversimplified when I said "just because we do". There are historical reasons why the supersession process is the way it is, and that has been stated elsewhere on this page. I don't think it matters why it is the way it is because we should be focusing on how to fix it. I don't like the implication that people are performing supersessions as some sort of covert operation. Now, I've read Erik's statement and quoted and discussed it elsewhere. I follow it to the letter. But you are wrong that deletion of superseded images has no consensus, at least in general. What you are correct in is that deletion of PNG images over their SVG counterparts has no consensus. It seems clear to me that consensus is that PNGs and SVGs should both be kept and instructions provided to use the "superseded" SVG image for future usage, but still allowing for PNG files to used on a case-by-case basis. That should probably be implemented immediately and the entire backlog of PNG -> SVG images removed. I say that only for identical images. There are a number of other cases where superseding images is perfectly valid. If an image of, say, a flag or COA exists with incorrect colors and another exists with official colors, the one with official colors should be kept and the other one deleted unless there is a good reason to keep it. It may be difficult to determine if there is a good reason, so the process is not obvious and cannot be a blanket deletion. The english Wikipedia has a process for deleting "obsolete" images. I add a lot of images of plants and animals. Some of mine are not very good but are the only ones available of a particular subject. If someone uploads a better version of the same subject, I'd expect my version to be declared obselete and superseded by the new one. My image should be deleted. (See this example) The situation is often reversed: I'll upload a crisp, clear, high resolution image (of say, a leaf) and it will replace a grainy, blurry, low-resolution image. Bad images should be superseded because they clutter up gallery pages and make it more difficult to find useful images. My point is that there are valid reasons for superseding images that have not been much discussed on this page because the entire focus has been on the PNG vs. SVG debate. It is also clear that there is consensus that the procedure for doing supersessions needs to be improved to solve the problems you listed. -- Ram-Man 12:52, 24 April 2007 (UTC)

1. As indicated above, I'm not claiming that anyone has acted in bad faith. I don't believe that these deletions were intentionally hidden from view, but I'm curious as to why no one involved realized that this was the end result. Ideally, I'd like to determine the underlying cause and prevent this sort of thing from occurring again. (I'm not referring to this specific process, of course.)

Additionally, I'm troubled by some of the replies that have been posted here. You've acknowledged that major mistakes have been made and must be rectified, but others have largely dismissed the community's concerns and implied that little or nothing is wrong. Thank you for taking the matter seriously.

2. I also noted above that there are legitimate reasons to delete "superseded" images. My point is that the mere fact that an image had been "superseded" isn't one of them.

If a "superseded" image is of low quality, that's an entirely different situation. I don't, however, see a need for a separate process dedicated to the deletion of such images. Most of the undue burden placed on the regular Deletion requests process was due to the needless nomination of high-quality graphics. Also keep in mind that poor quality can justify the deletion of images without direct replacements. —David Levy 04:48, 25 April 2007 (UTC)

I want to amend my statement. There are times when incorrect COA/Flag images should be kept, but not in all cases. If an incorrect image is not used anywhere, it should be deleted without issue. If it *is* used, then care must be taken to determine whether the use is correct or not. Hypothetically, let's say there was a correct and incorrect version of the U.S. flag that only differed in colors. It would make sense in almost all cases to replace instances of the incorrect image in articles about the United States and deleting the image if it then becomes orphaned. I can see no reason to keep an image that isn't used or is incorrect unless an assertion is made as to why it should be kept. That assertion should be included in the image descripton page so it is clear why the image should or should not be used. -- Ram-Man 13:07, 24 April 2007 (UTC)

Agreed. —David Levy 04:48, 25 April 2007 (UTC)

Dear FrankB,

@ALLEDGED improvement: Just zoom in on an SVG. Now do the same with a JPEG. You'll notice the JPEG will become blurry. Also raster graphics are effectively read-only, in the sense that editing them after they have been created is a needlessly laborious process, especially those without layer support.

@Postscript: Actually most printers currently sold are PostScript printers. And the most commonly used page description interchange format, PDF, is essentially PostScript.

@should EVER supercede other technologies: actually, SVG is broadly accepted as the standard, common vector graphics interchange format, having broad backing in both industry and the free software / free culture movement. You are living in the past.

@IE6: I'm currently browsing Wikipedia with IE6, and SVG's don't cause any of the problems mentioned. Your cheap rhetoric doesn't give you much credence either.

@Many Svg'S have scaling issues: no, you're simply wrong. SVG's don't have scaling issues.

@verdict is in. SVG's suck: Actually all your arguments went up in smoke. So, no.

@engineer of many years experience: you do realize you don't actually come across as an engineer with many years experience? If you use language like you do, and fail to base your opinions on real facts and arguments, people will think you're either blinded by your preconceptions, a twelve-year-old, or a troll. While I don't much care how you come across (it's your own freedom to leave any impression you like), behaviour like that in a serious discussion is disruptive. Find yourself a forum somewhere.

For what it's worth, I personally don't think that the original raster images on which SVG's are based should be deleted, primarily because they're an important part of the image history. Just like we keep all the old versions of articles on Wikipedia.

Yours faithfully, Shinobu 10:59, 22 April 2007 (UTC)

Your claim that "SVG's don't have scaling issues" is patently false. On paper, vector graphics are infinitely scalable without quality degradation, but in practice, our scaling and conversion to PNG often results in images of significantly lower quality than their native raster counterparts (even when the source SVGs are perfect). This is a flaw not in the SVG format, but in the current MediaWiki implementation. Nonetheless, it's a real problem. —David Levy 05:22, 23 April 2007 (UTC)

The point may be partial missed. PNGs have scaling issues that are the essence of the format while SVGs do not. The problems with scaling of SVGs are all software related and can be improved. PNG scaling problems cannot be fixed, regardless of what trend technology takes. Shinobu is exactly correct when he says that SVGs do not have scaling issues. The issues are all in post-processing, but that is not a problem with the SVG format itself. Arguing over semantics, sure, but it is important to be clear. PNGs and SVGs have scaling issues caused by different reasons. One can be corrected, the other can't be. Using raster instead of vector graphic files ensures long-term mediocrity. Your example above has a problem as well: if both the PNG and the SVG have to be scaled, the end result will depend entirely on how good the processing is for both formats and depends on the size of the original png and the final scaled size. One can't predict the scaled sizes ahead of time, so how can you know if the PNG file will look better scaled than an SVG file? The argument doesn't work because what looks good is temporal and could change at any time with the next MediaWiki software update. Even if a project chooses the PNG format because it looks good today doesn't mean it will be good tommorow. The SAME argument applies to SVG. You simply can't decide to keep one or the other or both on the basis of this argument because the argument could be invalid tommorow. -- Ram-Man 20:05, 23 April 2007 (UTC)

1. I understood the point perfectly and plainly stated that "this is a flaw not in the SVG format, but in the current MediaWiki implementation." Presently, MediaWiki often does a better job of scaling down native PNGs than it does of converting and scaling equivalent SVGs to PNGs of the same dimensions. Additionally, some raster image files (typically icons) already exist in the exact dimensions at which they're commonly used. (They either were created at those sizes or were manually scaled and tweaked to ensure the highest possible quality.) And yet, people blindly attempt to replace them with (and even delete them in favor of) SVGs that look far worse when scaled to the same sizes (despite the fact that this provides absolutely no benefit to anyone and often breaks transparency for most users).

2. No one is proposing that we keep raster graphic files available "instead of vector graphic files." There's absolutely no reason why we can't have both (and use them on a case-by-case basis). Upload and advertise all of the vector graphics that you can, but stop trying to take away the raster versions. —David Levy 21:49, 23 April 2007 (UTC)

Sometimes I like to take the devil's advocate approach, which I am doing here. I don't care if we have one of each. I have to wonder: What size PNG files do we keep? It may be great that we keep some icons at a certain size and that right now that size is used without scaling, but what happens if another size becomes popular? Do we then just upload another version of the same file? When does the madness end? What happens when software scaling of SVG files improved? Also please understand that I do not support blindly deleting anything. -- Ram-Man 12:52, 24 April 2007 (UTC)

1. The projects tend to be fairly consistent with icon sizing, especially in the context that I'm thinking of (templates). I've personally created some custom-scaled icons and uploaded them to the English Wikipedia (thinking that they were too specific to be of value elsewhere), only to see them transferred to the Commons and used by Wikimedia projects in dozens of languages.

2. If certain improvements were made to MediaWiki's SVG scaling, this would no longer be an issue, but that doesn't help us now.

3. I realize that you don't advocate "blindly" replacing raster graphics with SVGs, but some people do. They literally argue that SVGs are automatically better than raster graphics in all cases. —David Levy 04:48, 25 April 2007 (UTC)

SVGs since they are vector graphics files can be converted to other vector graphics file formats without any quality loss. Converting, say, a PNG to a JPG or to a differently scaled PNG must be definition result in a loss of quality, however minor. What would happen if PNGs were obsoleted in the future and no one used lossless formats anymore? Probably not going to happen, but who can predict the future. SVGs are relatively future-proof, as they can be converted to any format and any scale without any additional generational loss. If the argument is about guessing the future, one should choose SVG. Regarding this quote above: ...the concept that svg's should EVER supercede other technologies in all cases is more of the same hopeless idealisms.... The point is that SVGs do not have to supersede other formats because they can be converted without loss to any of those formats at any time, including to other vector graphic formats. It's not hopeless idealism. There is no reason that the SVG format ever has to replace any other format, only that it can be converted. -- Ram-Man 20:18, 23 April 2007 (UTC)

Again, no one is arguing that we shouldn't have SVGs. We're saying that we can keep the other formats too. Nothing will explode. —David Levy 21:49, 23 April 2007 (UTC)

Ok David, I´d like just to observe that not always IE6 has problems with SVG extension, and in many cases the file may be corrected in order to be well viewable by IE6 users. Cheers. --Tonyjeff 17:33, 26 April 2007 (UTC)

I'm certainly not claiming that all SVGs are problematic. —David Levy 19:21, 26 April 2007 (UTC)

Key points

Actually, that's pretty much the key point I'd made. Those of you with the CS savvy may know that SVG's are in theory 20x better, but the word superceded is emotionally loaded as it implies they are being deleted. Then when experience over and over shows a SVG rendered as a PNG poorly, yes, I'm liable to get a bit excited by the negative impact it has on product quality. They also scale wrongly in Firefox and Netscape, so that supports the answer David Levy gave above, which matches the answer on WP:VPT given last month. I don't know enough about scripts and browser interactions, but sometimes zooming in or out can "fix" the problem, but other times it doesn't.

Face it, none of us are getting paid enough for the time we put in <g>, so it really sucks when we have to spend ten minutes playing with sizes on a long page to reset the positions, nesting, et. al. because the SVG isn't scaling in effect, if not as the cause. The only work around I've been able to use to cure the occurrence is changing the image widths. Perhaps Depreciated is a better way to tag these. And yes, at times, I'm happy to live in the past, for the past has a track record and has proven itself. By the same token, in my years of engineering, I've seen quite a few so called standards which didn't gell and kept presenting new problems for their entire run, and just as many which took a decade to stabilize and really gell. Hell, I recall when JPG's were the Holy Grail.

I've no problems with efficiency (That'd be really silly in an engineer! <g>), were it reliable, but neither do I see it as any groups place to force a particular technology down peoples throats. Which image a person chooses is an editorial job, not the job of the archivists here, nor the purpose which this repository was set up to accomplish. It's supposed to store and make available all sorts of media, not the newest fangled graphics fad.

I've a son who is very into graphics and graphics designs, as I'm not, and he's never heard of SVG's which is indicative of how common they are not. So, what's the rush. Why all the effort to convert this or that? Isn't there enough work to do on the site without creating unnecessary extra work and concerns? So, please make haste more slowly. If wikimedia fixes the scaling issue, then perhaps it will be reasonable to think about superceding images which are in place an working. Before that, it's causing unnecessary haphazard breakage. I've never seen a PNG that didn't display properly, and I wish I could say the same about SVG's, but it would be, at least, a sixfold lie. // FrankB 07:01, 26 April 2007 (UTC)

It's funny, because just yesterday I converted an SVG into a PNG using OpenOffice (of all things) and then uploaded the PNG here to the commons. While it is true that many pieces of software don't support SVG, there are quite a few that do, including open source packages. Not to mention that the text of the SVG is such that you could use it to rebuild it manually into another vector format. One of my core arguments is that if the scaling issues with SVGs -> PNGs are fixed, then having PNG files will then be worthless. It doesn't matter what other software supports SVGs if they can be converted to PNGs efficiently and accurately. We have just not reached that point yet. At the moment, keeping both types is the thing to do. PNGs will always be stuck in the past and both types can easily be converted to other formats in the future if either becomes obsolete. -- Ram-Man 16:19, 26 April 2007 (UTC)

Let me point out some differences

1. Some of us could care less (closer to most of us, considering the staffing problems here on the commons!) how the image is generated, but are interested solely in whether it is usable and have great concerns with effects on quality and reliability, but care not at all about manipulating or changing such.
2. Editing to add useful maps, as I do often, into history and geography articles, when that proceeding goes awry as it has, then it impinges upon my time. I resent that, and I've been burned too often too recently by SVG's to trust them.
3. If SUCH settings/renderings/conversions are happening to me, they are happening far more often to our unsuspecting customer-readers using the product of our efforts. That experience reflects poorly on the project using that image, and it is only made worse from my standpoint as an editor, because the manifestation is unpredictable and intermittent. THAT IS THE KEY PROBLEM. Reliability. Secondarily, I doubt any of the man-hours spent in changing things over is anything but marginally beneficial--base images sans languages to be used for annoted by language templates make some sense. Beyond that, if an image exists, why bother? This is after a, a library. The project(s) can use your time in other ways than doing what amounts to make-work.
4. The casual user cares not whether the tech is better, only that such an such an image only rendered as half a picture, or as a placeholder and entered some endless software loop that timed out delaying his interactive ability with his computer console, and that -- when it took an inordinately long time for the page to load and finish updating -- creates a big negative experience. He doesn't care that that may be solved in the future, but that it's costing him his precious time today.
5. It is folly to mistake your knowledge and experience and willingness to try new things with the attitudes and beliefs and experience of the general populous. That's a mistake only life's experience will gradually overcome, but such a difference is one of the marked difference between someone who has matured into possessing common middle aged wisdom, and the all too wearing gung-ho enthusiasm evinced all too often by those thirty-something and under. (Sigh <g>)
6. Free software and sales-trailing products market frequently incorporate features and advances not common in established products. Were it an older version of a widely distributed commercial product like MS-Office, Corel, etcetera the presence of the format would carry more weight. The new is not always better, and if you were creating say a computer video game, you'd be foolish and cutting your own potential sales, if you were producing to new video cards and technology. Basically, such behavior paints oneself into a corner, and that's not smart business, or strategy.
7. But there again, one must be aware of the lags between cutting edge and wide distribution and availability. Most people are conservative and don't go off willy nilly to add extensions, expansions, or upgrades unless they have firm indicator that 'taking the time' to do that (with it's many risks--alas, Windoze used to crash with alarming regularity and had no easy way of recovery! Those experiences really mess with the downside time worries to those of us who literally spent days trying to resuscitate a broken system! Now, recovery is easier, but the wariness remains!), but leave that to the last minute forced need situation.
8. Lastly, you get what you pay for in life. Generally, most of us are leery of open source software, and use it only as an only recourse. Why should anyone established in life with many time pressures take the risk of loosing a precious half-hour plus to find out something just created a problem? Then again, there are people out there with families to feed and educate that need compensated for their training, time, and since they offer guarantees and customer support, I'm supposed to take a risk and worst, risk my valuable time? Sorry. I'd rather get paid than not, and pay out than benefit at the expense of something free--most of the time. // FrankB 17:30, 26 April 2007 (UTC)

Point of view from a WN-FR bureaucrat

I oppose strongly for deleting superseded image. So, if you see Image:Wikinews-Logo.svg and Image:Wikinews-logo.png, they are requested for deletion. But theses one are Wikinews logos for our project. Many templates, many pages are using theses logos.

This is a authors' license violation, too.

-- Bertrand GRONDIN → ^(écrire) 08:10, 7 July 2007 (UTC)

IE6 and SVG

Xpost follow on to the above...

Hi there, Frank! I´d like just to observe that not always IE6 has problems with SVG extension, and in many cases the file may be corrected in order to be well viewable by IE6 users. It is a matter to firstly test the file in different browser and make the needed adjustments. Cheers. --Tonyjeff 17:36, 26 April 2007 (UTC)

• Thanks, but that's irrelevant to the time cost of the moment, not to mention the reliability worries when coming across a problem as an article editor. It's hard enough to get text straight and position HTML elements properly so as to minimize whitespace useage without taking a distractive side trip to fix up an image with a problem. That circumstance simply means I found an image or resized one that that cost me extra time when I have little enough to volunteer as is; so such jarred my elbow whilst I'm likely editing in three or four related articles, and does little to ease the peace of mind as to what the customers may see.
  
  I keep my browsers free of extensions and scripts and such and use the default skin specifically so I can see what the customers see as a rendered page, and this is worrisome to me with my eye on the big picture. An isolated occurrence is NBD, but the half-dozen or more I've seen raise sincere concerns that we need to make progress more deliberately more slowly.
  
  My harsh rehetoric was purposeful to make that issue clear! However your assurance does suggest there ought to be a tag for such problems so some body of people who do have an interest in editing images can address such fixups. Maybe I should propose THAT here and on WP:VPT!) Cheers and thanks! // (emphasis added)

I so propose now. How about a group of image specialists set up a category here and on all wikiprojects with a tagging template that documents said problems and so the date and time where they occured and in which page. // FrankB 18:46, 26 April 2007 (UTC)

I believe you're talking about Commons:Images for cleanup. It exists already. --pfctdayelise (说什么?) 05:17, 11 May 2007 (UTC)

IFC already has some subcategories, it wouldn't be hard to make one specifically for "missbehaving" SVGs. /Lokal_Profil 13:52, 11 May 2007 (UTC)

Create a template for each project

When people delete superseded images they go to every project and replace them, right? Instead, we should have a standardized template that says something like "The image X which appears in this article has been superseded by the image Y. If you think it is superior for your purposes, please replace it and then delete this template." This template should have the same name on all projects and the text would be localized into each language. Then instead of going around replacing the images, you can go around and put the template on the talk page instead, and let each project decide for themselves. — Omegatron 12:52, 30 April 2007 (UTC)

If we do it like that I would suggest the following: The Superseded template here on Commons is being modified accordingly. A bot puts the template on each article. However, I think for mass used images this will produce an outcry! --ALE! ¿…? 08:21, 2 May 2007 (UTC)

Why would it produce an outcry? Can you give an example of such a "mass used" image? — Omegatron 02:57, 8 July 2007 (UTC)

Tag

I think toe superseeded tag is incorrectly used - It should not be something to tag items to be deleted - it should be pointing out to users there is a better image existing --talk to symode09's 08:21, 6 May 2007 (UTC)

Agreed. Currently it says "This file has been superseded by ___. It is recommended that the other file be used." Instead, it should say something like "Someone has created an image meant to supersede this one. Please compare the two and change to the newer one if appropriate". — Omegatron 02:59, 8 July 2007 (UTC)

Further considerations and (future) suggestions

Greetings everybody, I am (was?) the keeper of Commons:Deletion requests/Superseded (other than ALE!, that is), but I've almost been forced away from here the last 4-6 months, just randomly making minor edits. I've spent my last half hour reading this lengthy talk, which I found not only interesting, but somewhat scary. Let me explain on this.

1. I see the point in keeping older versions (even useless or obviously lower in quality) of the images. I agree as well on deleting duplicate (or superseded) images when the superseding image is an (almost) exact 1:1 copy, that is:
   • PNG vs. GIF: the PNG has binary transparency (8-bit PNG).
   • PNG vs. JPG: the PNG has no or binary transparency, and there is no noticeable color quality loss (8-bit-only consideration).
   • SVG vs. PNG: the PNG was generated from the SVG, or the SVG and the PNG are almost impossible (that is, to an human) to distinguish.
2. Right now I think there's a big issue not only in Commons, but in every Wikimedia project: the software forces every image to be unrelated to each other just because their file format is different! That is, we're not free to switch to a different file format for a given image (given 1:1 criteria as of #1 are met), because we'd have to correct every link in every Wiki should we. I think the software should strip the file type extensions off of the file names, instead of actually binding the image name to the image file format. Given this fixed limitation, the only solution we can come up with is (as already proposed here) to tag every superseded image with clearly discouraging banners, indicating the image is only kept as a reference or as history and should no longer be inlined. This however will not keep users from copy/paste'ing the image inside and across Wikimedia projects, since I think few users (editors) do care about the image description page as long as the image they found (on pages other than the one they are editing) is what they are looking for. Again, a software solution (image redirect, "no-inline" image tagging) would solve the issue, but I have no expectations nor hope to see this coming to life any soon.
3. The audience. I can't stand pointless FUD on PNG and SVG being inherently "evil". (Any following everywhere is intended to mean "almost any browser", that is covering the largest part by far of Wiki* audience).
   • 8-bit PNG is fully supported everywhere.
   • 32-bit (true color) PNG with simple (binary) or no transparency is supported everywhere as well.
   • So far, MediaWiki never serves inlined SVG files directly; it outputs PNG renderings instead. SVG images lacking transparent areas fall straight back to preceding point, since they are served as 32-bit transparency-less PNGs. It's true, however, that MediaWiki does have issues with some SVG files at certain sizes. Images should be double-checked prior to proceeding with replacement or even with submitting the supersedement (is this English?! Delete → deletion, supersede → ???) request.

The only current suggestions I can give:

1. (Again) extensive tagging of superseded (or should-but-could-not-be-deleted) images with persuasive discouraging banners, and their removal from any category (maybe except Category:Images kept as history or similar).
2. Redefinition (or just definition?) of an accurate policy for the deletion of superseded images, maybe based on the points in #1 of the first list.
3. Introduction of a design policy for SVG images, to ensure the generated PNG files are correctly viewed anywhere.
4. Beg MediaWiki programmers to provide us with a solution for this mess...

It took me more than an hour to write this down, I hope it'll take much less for you to read :) --ColdShine 10:49, 12 May 2007 (UTC)

I sincerely appreciate that you took the time to respond, but you appear not to be picking up all of the community's concerns.

1. Please stop trying to dictate which files the projects use. Contrary to Yonatan's claim, the Commons is not "pretty much in charge of images," and there are valid reasons to transclude graphics that have been deemed "superseded." (What perceived harm do you seek to prevent?) Just tag the description pages with links to the new files and allow the projects to decide for themselves. It might even be appropriate to replace some transclusions, but not to mandate such changes.

2. There is nothing wrong with GIFs. The format is now 100% free worldwide, and it always will be compatible with more browsers than the PNG format is. In many instances, the difference in size between a GIF and an 8-bit PNG is negligible or nonexistent, and there are occasional instances in which the GIF actually is smaller. If projects want to use GIFs, let them use GIFs. The Commons is here to serve them, not the reverse.

3.You're mistaken about PNG compatibility in IE6. Only 8-bit PNGs are displayed with the transparencies intact. If the color depth is higher, any transparency is broken, even if the transparency is binary and 256 or fewer colors appear in the image. Furthermore, MediaWiki renders all SVGs and scaled PNGs as truecolor PNGs, even when the source images are 8-bit. Only an 8-bit PNG displayed at its native size will remain 8-bit.

4. There are legitimate reasons to upload and transclude PNGs derived from SVGs. As you reiterated, MediaWiki renders SVGs as PNGs anyway. It often is possible to tweak the resultant files for enhanced performance in specific applications. For example, MediaWiki automatically inserts a bKGD chunk containing the attribute "255,255,255." This means that in IE6, the transparent background will appear as white instead. Modifying the bKGD chunk enables the selection of any background color as a fallback in IE6 (thereby serving as a good workaround for this problem). Also, it often is possible to improve the image's compression, and it sometimes is possible to reduce the color depth to 8-bit (significantly reducing the size and addressing the IE6 transparency issue without even including a bKGD chunk).

5. Given that you were one of the keepers of Commons:Deletion requests/Superseded, perhaps you could explain why:

• The images were not tagged to indicate that they'd been nominated for deletion or to provide links to the discussions.
• The uploaders were not notified via their talk pages.
• The completed deletion debates were blanked.
• The sysops included no links to the relevant subpages in the deletion summaries (making it extremely difficult to even find the discussions in the histories and determine the rationales behind the deletions).

Thank you. —David Levy 15:57, 12 May 2007 (UTC)

I think part of the solution is redirects. That is how duplicate articles are handled on other projects. With the current software, only the description pages are redirected, so redirecting will only work for exact duplicate files. But if the software is changed so that the file at the target of the redirect is used, it will work for most superseded images. Redirecting will not work for the "almost superseded" files that are needed for special purposes (e.g. optimised thumbs or transparent pngs for IE). But if the relevant information is put in the descriptions of those files I don't think that should be a problem. /82.212.68.183 19:54, 12 May 2007 (UTC)

@David Levy:

1. I can't see where I ever suggested an endorsement of the graphics file formats to use on Commons. I only put down some policies I think should be taken into account for deletion of images which have already been tagged as superseded.
2. Same here: my positive criticism on PNG doesn't imply negative criticism on GIF.
3. I actually was wrong with the entire 32-bit transparent PNGs point. When I read your reply, it suddenly came to my mind a test I did one year ago, which resulted exactly in what you say here. Yet again, there is no issue with solid-background PNGs.
4. That's one I had in mind but I forgot to mention in my #1. I agree some hand-optimized PNG renderings of SVG might be acceptable.
5. I'm sorry I can't help you on all of these questions right now. My task on Commons is was very specific, as I applied to trim off the huge lists of images which were being converted (reconstructed) from GIF/PNG to SVG, mainly icons such as flags and road signs (including my own), at that time. I acted according to the guidelines at that time, with few exceptions to help quicken the lengthy process (I initially thought the list could be emptied someday, until I was forced away by external events, several days after).

I'm sorry I have to stop writing this reply now, yet I'm sure I left something out (including a comment on 82.212.'s reply). I'll get back the next few days. --ColdShine 22:09, 13 May 2007 (UTC)

ColdShine has a very important point: Fixing Mediawiki's image title limitations would solve a large chunk of the problem here. Keeping older versions of images on the image description page is obviously desired, but changing an image's file format or name makes this useless. The file format should be stripped from the image's name (Bugzilla:4421), and images should be movable to different names and redirected, just like articles (Bugzilla:709). If the histories of two images could be merged the way articles are, that would be great, too. — Omegatron 03:15, 8 July 2007 (UTC)

BMP

Can bitmaps be submitted? —the preceding unsigned comment was added by 71.60.139.201 (talk • contribs) 2007-08-02T15:56:54

This isn't really the place to talk about that, but the answer is simple: Yes, although they may not be the best format. If a bitmap is all that you have, however, then submit it, link it, and then watch the wiki process at work if other people translate it into different formats! —Toby Bartels 19:00, 3 August 2007 (UTC)

Objections ...

I just found the 'superseeded-and-should-be-deleted(-but-not-yet)' info under one of the images (a photograp) I have loaded up here at commons. While the png-version is fine and clearly of enzyklopaedic value, I don't see why the original photograph should be deleted. It has its own value(s): it is an actual photography of the way the JSA locally informs visitors about its work, it holds the original descriptions in Khmer and Japanese ...
Instead of simply deleting it, I recommend using the 'other version'-section of the info-box. And I will do that now.

Regarding the superseeded-info in general: if not suspended like at the moment, it seems to work just like another kind of speedy deletion - without notifying the uploader, that the image is bound to be deleted. Am I wrong, that there is no provision made for objections? --Tsui 23:04, 2 August 2007 (UTC)

Please do not delete originals

Sometimes I came across the case where a SVG file wasn't useable in the place where I wanted to reuse some Commons hosted icons, and PNG were really worthy.
BTW, the previous comment seems OK for me: when a SVG file superseeds a GIF/PNG/JPG image, it shoud be categorized in place of the orginal picture, the original picture should be recategorized and also have a link as 'alternate picture'/'other version' from the SVG one.
Bestt regards from France,
-- AlNo (discuter/talk/hablar/falar) 10:21, 3 August 2007 (UTC)

Deletion process

It's pretty obvious that no one wants superseded images deleted. Can we remove this from the template now? The "temporarily suspended" notice has been there for a long time. — Omegatron 20:03, 5 August 2007 (UTC)

Summary of the above discussion

I have been following the discussion above with some interest. I think an accurate summation of the above is as follows (my apologies to any whom I may have misattributed):

Those against the deletion of superseded images

User:Duesentrieb User:Lar User:Nilfanion User:Yonatanh User:Toby_Bartels User:Dgpxyz User:Effeietsanders User:David_Levy User:Nilfanion User:Indolences User:Vishwin60 User:Piotrus User:Omegatron User:AnonMoos User:213.155.224.232 User:Cacycle User:Walkerma User:NEUROtiker User:Rosenzweig User:Gerbrant User:Fabartus User:Grondin User:Tsui User:Alno

Those for the deletion of superseded images

User:WarX User:Jengelh User:Dcoetzee User:ALE! User:Gmaxwell User:Lokal_Profil User:Cool_Cat User:80.63.213.182 User:Ram-Man User:Tonyjeff User:Palmtree3000 User:Lokal_Profil User:Andrew_Hampe User:ColdShine User:murraybuckley

Those who I can't say were for/against

User:CyberSkull User:Yonatanh User:Symode09 User:82.212.68.183

Conclusion

I would state that this indicates that there is no consensus for the deletion of superseded images.

Action

I note that User:Bdesham has already changed Template:Superseded/en here to state that "The deletion of superseded images has been suspended indefinitely; see the discussion for more information", and the change has cascaded to Template:SupersededSVG. I will change Commons:Deletion_requests/Superseded, Category:SupersededSVG and Category:Superseded to match. I think it will be correct to do the same for the non-English language equivalents that are not conducting their own discussion, but it will take me some while to work out the languages involved.

I hope this helps. Kind regards, Anameofmyveryown 03:08, 18 August 2007 (UTC)

Scaled GIF images use much fewer kilobytes than scaled SVG/PNG images

GIF is a great 8-bit lossless format. Why are there so few gif images in this graphics category: Category:Criminal justice diagrams

From this previous talk section higher up: #Further considerations and (future) suggestions

"2. There is nothing wrong with GIFs. The format is now 100% free worldwide, and it always will be compatible with more browsers than the PNG format is. In many instances, the difference in size between a GIF and an 8-bit PNG is negligible or nonexistent, and there are occasional instances in which the GIF actually is smaller. If projects want to use GIFs, let them use GIFs. The Commons is here to serve them, not the reverse.

3.You're mistaken about PNG compatibility in IE6. Only 8-bit PNGs are displayed with the transparencies intact. If the color depth is higher, any transparency is broken, even if the transparency is binary and 256 or fewer colors appear in the image. Furthermore, MediaWiki renders all SVGs and scaled PNGs as truecolor PNGs, even when the source images are 8-bit. Only an 8-bit PNG displayed at its native size will remain 8-bit."

We should not only be saving the superseded images. We should be using the gif images in preference to the PNG or SVG images.

Because the gif image format is 8-bit only. So gif images only scale to 8-bit versions. So they use a lot fewer kilobytes than scaled SVG/PNG images on MediaWiki.

That is because most images are placed in articles in clickable thumbnail form. For example; I uploaded these gif images: Image:USA. Prisoners 1995 to 2005.gif and Image:Incarceration rates worldwide.gif. See the thumbnail versions to the right. They use only 8 and 12 kilobytes, respectively, at the 180-pixel-wide thumbnail size.

Imagine how many kilobytes they would use if I, or others, had followed all the confusing advice to create PNG or SVG versions of them. Even 8-bit versions of them. It wouldn't matter because MediaWiki would create 32-bit versions in the scaled versions. A page with several such scaled images would require a lot more kilobytes.

MediaWiki scales one of the gif images on the right to a 400-pixel-wide-size of 29 kilobytes. See below:

The original gif size that I uploaded is 21 kilobytes:

That is the size for the gif image at the original source here:

• http://november.org/graphs/LeadingJailer.gif
• http://november.org/graphs

So why are so many of the graphics (diagrams) at Category:Criminal justice diagrams using hundreds of thousands of kilobytes? It is because they were uploaded in 32-bit jpg and png formats. That is totally unnecessary and useless for most graphics, diagrams, maps. etc.. They use few colors. --Timeshifter 06:57, 19 August 2007 (UTC)

There are some heinous crimes against the computer there. Uploading graphs as jpegs is bad. This is common cause. As for uploading a table of text as an image of any kind, I am not able to rightly apprehend the kind of confusion of ideas that could provoke such an action, to paraphrase Babbage. --Slashme 15:59, 14 November 2007 (UTC)

The table of text was from a PDF file from the Bureau of Justice Statistics. As a webmaster myself it is much easier to copy a table as a GIF from a PDF file than to fiddle around with HTML table formatting. Most webmasters feel this way about tables in general. Why bother unless I want to edit the table? It is historical data, and there is no need to edit the data. The Bureau of Justice Statistics will change the table if need be. Then the table can be again copied as a GIF file and put as a replacement in the web page. Simplicity is what webmasters want in the real world. --Timeshifter 20:04, 14 November 2007 (UTC)

As for maps, take a look at a png map Image:Nafaanra_language.png that I converted to Image:Nafaanra_language.svg. The png is 94k, and if it is converted to a gif, it is 69k. Nothing to write home about there. The svg is 52k. Sure, it gets converted to pngs. The nice, large preview on the svg image's page is 123k. Not only does it look much better than a resized gif, the source is right there, so if I in my ignorance had misspelled Banka, someone else would have been able to fix it without wondering where exactly the border goes after erasing the text. Google and friends can read the svg and figure out what it is all about. And one day not to far from here (maybe a decade or two?), when all browsers support svg as well as firefox does today, we can chuck all the png previews out of the window. --Slashme 16:13, 14 November 2007 (UTC)

In the meantime we need GIF and PNG images. There is no reason not to keep the SVG images as the working format for image creation. For the reasons you pointed out. But for final use of graphics in web pages we are stuck with GIF and PNG. We can always upload newer versions of the GIF and PNG images on top of the old versions. The PNG version does not look worse when it is converted to GIF. See for yourself. I converted it to a GIF version and uploaded it here: Image:Nafaanra language.gif. Compare it to the PNG version used here: Image:Nafaanra language.svg. --Timeshifter 20:27, 14 November 2007 (UTC)

Imagine all the page loading time we could save the average wikipedia reader by using gif images. Look at all the jpg, png, and svg maps using hundreds of thousands of kilobytes each that would work fine with GIF versions using far fewer kilobytes: Category:Maps. More importantly, more people would upload graphics, diagrams, maps, etc.. Because gif editing is much easier than png editing. There are many more cheap and free image editing programs that edit gif images. And the editing is near-instant. Little or no tweaking is necessary.

Repeat after me:

• GIF is good
• GIF is good
• GIF is good! --Timeshifter 06:57, 19 August 2007 (UTC)

uh, dude, PNG has a 256 color/8-bit option which shrinks file size smaller than 8-bit gifs and svg has other obvious advantages,such as SCALING. --66.158.232.102 22:49, 25 August 2007 (UTC)

SVG is not actually used in wikipedia articles. Wikimedia converts SVG images to 32-bit PNG images. And the wikipedia servers convert 8-bit PNG images to 32-bit PNG images when scaling them. So in reality nearly all the PNG images in wikipedia articles are much larger (in kilobytes used) than the gif versions. And they don't look any better than the gif images. --Timeshifter 16:08, 26 August 2007 (UTC)

I don't quite get your point, Timeshifter, about why you think editing GIFs is any easier than editing PNGs. MS Paint can save to both formats, whilst popular free programs (e.g. Kolourpaint) tend to lack GIF support rather than PNG support (that is, if they lack either). 82.36.26.70 08:44, 28 August 2007 (UTC)

I use IrfanView, a consistently highly-rated, easy-to-use, and very popular, freeware image editor. I also use its plugin package [1]. For low-color graphics IrfanView is much easier, and faster, for editing, resizing, and resampling GIF images. Versus doing the same things with PNG images.

GIF is only 8-bit color. There is no need to set options for the number of colors. Also, GIF is lossless. GIF compression is transparent. There are no choices for compression settings.

PNG is much more difficult to use for doing the same things with low-color graphics. Because one has to be sure to choose the correct settings for 8-bit color. Also, PNG takes longer in other ways too. The multiple-pass PNG compression is particularly time-consuming at times. IrfanView's use of a PNG plugin is discussed here:

w:Portable Network Graphics#File size and optimization software --Timeshifter 08:46, 29 August 2007 (UTC)

If you have a problem with the way the server generates thumbnails, bring it up with the developers. I would imagine a proper resize generates additional colors, though, so the higher-color version would be superior. File size is not an issue. — Omegatron 05:25, 30 August 2007 (UTC)

The developers are well aware of the wikimedia image scaling problem. Many commons users are not aware of the problem. Scaling, resizing and/or resampling a PNG image via the wikimedia servers does not generate additional colors. So, for graphics, the scaled wikimedia version is not superior. Most graphics (as opposed to photos) do not have a lot of colors to begin with, no matter the format they were first created in. Converting those graphics to other formats or sizes does not generate additional colors. --Timeshifter 09:45, 30 August 2007 (UTC)

Use SVG for graphs like yours:

• The scaling is much better (see for example the jagged edges at the large size that you posted).
• The text is searchable by web spiders. Google, for example, would be able to look at your svg and figure out that it is about incarceration, but not from a gif.
• The text is easily editable: If I wanted to fix your gif, I'd have to fiddle with the text settings of an image editor, but with an SVG I can just haul out the text tool and edit the text.
• The image is much easier to fix. For example, your bar labels are extremely ugly. If I wanted to fix them, the GIMP and I would sort it out, but it's so much easier in SVG.

There are many good reasons to use SVG, and graphs with text and sharp lines are some of the best applications. --Slashme 15:47, 14 November 2007 (UTC)

I don't see any appreciable problem with jagged edges on the GIF image. I did not create the image. The image is only as good as the creator makes it originally.

As I said earlier there is no reason not to use all 3: SVG, PNG, and GIF. SVG is not viewed in most browsers. So we are stuck with PNG and GIF for actual use in web pages. The problem is that people are confusing intermediate working formats (SVG, Photoshop, etc.) with the final format.

And by the way, the GIF chart I uploaded to wikipedia currently comes up 3rd from the top when doing this image search on Google:

http://images.google.com/images?q=incarceration+rates

It is a copy of the wikipedia image that has been copied by www.answers.com for use on their website. Answers.com copies text and images from Wikipedia. I don't understand Google's magic, but the GIF format does not seem to be blocking the image from being found by Google. Google may be indexing the image file name, captions, and/or links to the image.

I see your point here and on the other talk page about using SVG and other intermediate formats as working tools to create highly customizable images. Which tools would you recommend for creating 2-dimensional graphs, bar charts, and tables? I can always convert the resulting SVG images, etc. into PNG or GIF images depending on my needs.

Which tools are best, and which are easiest to use? Which tools have the best balance between ease of use, and functionality, in the specific area I am interested in using them for? I am only interested in free software.

There is related discussion here. --Timeshifter 01:28, 15 November 2007 (UTC)

I discovered the following while searching for some easy graph creation tools:

Create A Graph. Free online graph creation tool at the website for the National Center for Education Statistics (NCES) (located within the U.S. Department of Education and the Institute of Education Sciences). Bar charts, line charts, area charts, pie charts, and XY graphs. Choice of PDF, PNG, JPG, EMF, EPS, and SVG output. --Timeshifter 04:52, 15 November 2007 (UTC)

Modern reproduction Hokusai's "superceding" genuine originals

This modern reproduction (using the original techniques) has superceded this original. All these points were made in a featured pic debate on the Great Wave from the same series. We should NOT be doing this. They are NOT the same picture. Since people seem to have trouble grasping the difference, I would explain that the genuine one would be worth about 1,000 times more than the reproduction, though that has value also. In addition, the copyright status of the recut versions must be regarded as dubious, as they are said to date from the 1930s, and the cutters are likely to have copyright, even though they copied Hokusai's design, now PD. I expect this has happened to other prints in the series (of 36) but have not checked. Johnbod 01:55, 10 October 2007 (UTC)

Category:SupersededSVG?

I haven't been part of this discussion, but I figured this was the best place to post this question. I was wondering what we should do with Category:SupersededSVG, as {{SupersededSVG}} now places images in Category:Vector version available. Do we even need this category anymore? Rocket000 02:51, 3 November 2007 (UTC)

Oh well, I deleted it. Rocket000 07:36, 9 January 2008 (UTC)

Image deletion request

Delete this image http://commons.wikimedia.org/wiki/Image:Jesus_on_the_cross.png because it's superseded and with no derivatives and is not used on any wikimedia pages. --Seans Potato Business 20:50, 24 December 2007 (UTC)

Sorry, we don't really do that anymore and this wouldn't be the place to ask. You would have to request deletion on COM:DEL by following the nomination process (also listed there). I wouldn't recommend doing this as the image is currently being used by Wikimedia projects and is quite different from the other. Rocket000 22:34, 24 December 2007 (UTC)

Seans listed it here. —Toby Bartels 15:01, 25 December 2007 (UTC)

This policy is ridiculous

Is there any good reason why the images at Commons:Deletion_requests/Texas_FM_shields_1 should be kept? This policy is what is preventing these images from being deleted. So far, nobody has been able to give me a good reason why the images should be kept except "that's how things are done as Commons." That is unreasonable and is not wikilike. --Rschen7754 04:27, 11 February 2008 (UTC)

You can always ignore a policy when common sense says to do so. — Omegatron 04:49, 11 February 2008 (UTC)

So then why are we getting the votes that we are in the DR above? --Rschen7754 04:51, 11 February 2008 (UTC)

You already know the reason: because they came here from Wikipedia after seeing a link to a deletion discussion posted on the talk page of one of the projects there. Lewis Collard! (hai thar, wut u doin) 07:13, 12 February 2008 (UTC)

No, the keep votes. --Rschen7754 07:14, 12 February 2008 (UTC)

Oh, never mind then. Lewis Collard! (hai thar, wut u doin) 07:27, 12 February 2008 (UTC)

When better images become available, the old ones should be deleted. That's common sense. Yes, there's not a technical reason to do so, but rather a social one; we should discourage usage of suboptimal images wherever possible. —Scott5114↗ [EXACT CHANGE ONLY] 04:35, 11 February 2008 (UTC)

The problem is that people think that better images have become available, while others think that merely different images have been available. The one example I've seen is where images were specifically made to look good in a table together, and someone replaced half of them but not the other half, and then put the replaced ones up for deletion. So now the table has half of one style and half of another and looks stupid.

So instead of going around to every project and deleting "replaced" images, you should go around to every project and notify them that replacement images are available. If they think the newer images are better, they'll replace them. When all have been replaced by local users, then you can delete them. — Omegatron 04:49, 11 February 2008 (UTC)

The problem is that there are some users who will not delete superseded images, no matter what. Read the DR above. --Rschen7754 04:51, 11 February 2008 (UTC)

Also, in nearly all cases, the English Wikipedia is the only wiki that uses these images, if they are used at all: [2] [3] [4] Since they are the ones obviously backing this request, what is the issue here? --Rschen7754 05:20, 11 February 2008 (UTC)

That doesn't account for someone using them in another project in future. It also doesn't account for people away from Wikimedia using them. They're won't be linking directly to the images on Wikimedia's servers, of course, but it's bad form to go around creating 404s for people that might have used the image on their site and linked back to us. Think of how annoying it is when source links go dead on us; it's not nice to do that to everyone else on the Internet, especially those that care about copyright and sourcing. Lewis Collard! (hai thar, wut u doin) 07:20, 12 February 2008 (UTC)

That is an argument to the future. --Rschen7754 07:28, 12 February 2008 (UTC)

We're not allowed to think about the future now? Hokay. Lewis Collard! (hai thar, wut u doin) 07:31, 12 February 2008 (UTC)

No, you're doing a "what if" that is highly unlikely. Furthermore, Commons was created for Wikimedia sites. Look at deletion processes - they serve the needs of Wiki**** and not the internet at large. --Rschen7754 07:38, 12 February 2008 (UTC)

"That is unreasonable and is not wikilike." On the contrary, what is un-wiki-like is to delete the images, because this makes them unavailable to anybody that might decide, for whatever reason, to make use of the old version. (It might be different if anybody could look at something even after it had been deleted, but unfortunately that's not the case.) Put a big note on the image page stating that it's superseded, then let Wikimedians make use of it anyway as they see fit. —Toby Bartels 22:27, 11 February 2008 (UTC)

What is the difference? The images are exactly the same. Furthermore, apparently there are those who use the PNGs anyway, even on a local wiki where the policy is to use the SVG images. --Rschen7754 22:59, 11 February 2008 (UTC)

Per latest comment in the deletion discussion. SVG is a newer format. There is going to be software out there that handles PNG but not SVG. 85.166.82.246 09:50, 12 February 2008 (UTC)

Can you name any specific software? --Rschen7754 01:30, 13 February 2008 (UTC)

Internet Explorer. →Rocket°°° 16:11, 13 February 2008 (UTC)

I have not had any issues with viewing SVG in IE. --Holderca1 21:27, 13 February 2008 (UTC)

I have not had issues either, with IE 6 or 7. --Rschen7754 23:47, 13 February 2008 (UTC)

And you can thank Adobe for that. The joys of being a Windows user... →Rocket°°° 01:11, 14 February 2008 (UTC)

What about animation? Audio? Filters? Any support for those? →Rocket°°° 01:12, 14 February 2008 (UTC)

None of those apply to the images in question. --Holderca1 03:08, 14 February 2008 (UTC)

Ok, fair enough. I didn't know there was a group of images in question. I thought we were talking about all SVGs. →Rocket°°° 15:33, 14 February 2008 (UTC)

What's the difference!?!? One's a vector and one's a raster. SVGs can never get pixelated no matter what size you stretch it. It can contain text for nearly instant translation (think of diagrams). It's human readable and fits the whole open source / open community thing. You can edit it with notepad and soon online like a wiki page. It's extremely easy to reuse. Animation will be possible soon. etc. etc. :) →Rocket°°° 14:22, 12 February 2008 (UTC)

That doesn't answer the question. --Rschen7754 01:30, 13 February 2008 (UTC)

You asked what the difference was. How did that not answer your question? If you just meant visually, you are ignoring the bigger picture. But anyway, speaking visually, almost all our PNGs are not fit for printing. We use such low resolution it's ugly. Try zooming in on one of those PNG's that look "exactly" the same. See those jagged blurry edges. Now do the same to the SVG. That's the difference. SVGs are a lot like fonts. Why do we even use them, if we can make PNGs for each letter? Because we want to be able to scale them, auto-translate them, render them differently, reuse them simpler, mix 'em together without worrying about pixels, feed 'em to a machine, all that stuff. And you can make PNGs/JPEGs/GIFs/whatever from a SVG, but not the other way around. Compatibility is the key. Right now, our browsers like PNGs, so that's what Mediawiki makes them, but about the future? What about having the option via css/js to render images in whatever format you want? SVG is the only open format that allows that. →Rocket°°° 15:59, 13 February 2008 (UTC)

Not the difference between the formats - between the images themselves. --Rschen7754 23:22, 13 February 2008 (UTC)

He is advocating for removing the PNG images that have SVG images available. Currently the "policy" doesn't allow this for some reason that isn't clear. --Holderca1 21:27, 13 February 2008 (UTC)

Rschen: No, the images are not exactly the same. (Sometimes they are, but sometimes they're not.) And as you note, some Wikimedians choose to use PNGs anyway; it should be (and now is) Commons policy to allow that choice. If usage of the PNGs contradicts the local wiki's policy (and this varies), then let the local wiki deal with that. Commons is an archive of images for all Wikimiedia wikis to use, however they find best. —Toby Bartels 00:06, 13 February 2008 (UTC)

The images being deleted are exactly the same, which is the point I'm trying to make. --Rschen7754 01:27, 13 February 2008 (UTC)

So what? (I presume you mean "the images not going to be deleted", BTW :-) Deleting "superseded" files doesn't even free up the file space on the servers' disks. I recently was glad to find some PNGs of SVG files, as it saved me the trouble to download the SVG, fire up my SVG editing program, and export to a PNG bitmap. I just needed a PNG; SVG was useless for my purpose. So, PNGs may serve a purpose, even if there are equivalent SVGs. Who are we to decide which file format might be useful for our re-users? If we already got a PNG, the appearance of an SVG version is just no reason to remove the PNG. Lupo 12:44, 13 February 2008 (UTC)

It's never about the severs. The main reason we keep them is we can't overwrite files with different extensions. It's the file history, I guess. Remember, if you want a PNG, you can save the thumbnail (at whatever size you want). →Rocket°°° 16:08, 13 February 2008 (UTC)

The file history isn't the issue in this instance, these SVG images were created from scratch and not from a PNG image. --Holderca1 21:27, 13 February 2008 (UTC)

That is one common argument I've heard. I'm all for deleting superseded images anyway. →Rocket°°° 01:14, 14 February 2008 (UTC)

Also, the policy currently states that superceded images are deleted on a case-by-case basis. I am curious as to what would be considered a good case for deleting a superceded image? --Holderca1 21:29, 13 February 2008 (UTC)

To stop the "SVGs can't be used by some software" argument, I will say that I have viewed SVG Wikipedia images on many systems, including but not limited to: Internet Explorer 5.1 for Mac, 6 and 7 (on 98, XP and Vista), Firefox 2 (Mac and Windows), Safari 2, Safari 3 (Mac and PC), AOL 9 (98 and XP), AOL for OS X, and some crappy version of Netscape (4.7? on 98). --Rschen7754 03:36, 14 February 2008 (UTC)

Well, they there's no native support with most of those. You need plug-in, which why all those worked for you. That's not the arguement I'm making though. Like I said above, you can make any format from SVGs, but not vice-versa. You can even edit it in something as simple as notepad. And you're right, software support is not a reason for keeping these. MediaWiki makes them PNG anyway. I agree with you that keeping superseded (exact) images is kinda pointless. However, deleting or not deleting on the grounds of the format itself is why we have these discussions. The only reason SVGs supersede PNGs is because of the format. So saying "Not the difference between the formats - between the images themselves." is not the best approach. We have one side saying "they look the same, no reason to keep both" and the other saying "having two formats to choose from is better than one". These are two different things both sides are not addressing. →Rocket°°° 15:31, 14 February 2008 (UTC)

You don't need plugins to view SVGs. For one, I'm told that Wikimedia converts SVG to PNG in the browser. Secondly, you have not backed up your assertion with specific software that requires a plugin to view SVGs. --Rschen7754 00:04, 16 February 2008 (UTC)

w:Scalable Vector Graphics#Plugin support and here's some stats. That's not the issue though. Mediawiki does convert to PNG. Have you even read my comments. I'm not making that arguement, I'm just trying to help explain the situation. →Rocket°°° 01:29, 16 February 2008 (UTC)

(unindent) I believe that before this policy of not automatically deleting superseded mages was implemented images were being deleted that were not the same as the SVG image. Also, some SVG images were being created from original GIF, PNG, and JPG images. The originals were needed since they were what the SVG image was supposed to duplicate. Map images for example. It was important that the SVG image was accurate. How was one to know that without an original to compare it too?

Also, an SVG image may be a duplicate at one point, and the GIF, PNG, or JPG image gets deleted. Then the SVG image further evolves, and then it is no longer the same as the original image. But then the original image is gone.

SVG images can sometimes have difficulties with text sizing. I set my font setting to a large size in my browser. This can really screw up some SVG images (such as labeled maps) that allow the font in the SVG image to vary according to the font setting in people's browser.

Clickable image maps need GIF images in many cases because they use far fewer kilobytes than PNG images at the intermediate and large sizes those clickable images require to be useful in articles. So that is another reason to save the original GIF images. Yes, PNG images can be converted to GIF images easily, but if that PNG image came from an evolving SVG image, then we are back to the problem of accuracy of duplication. This is important for maps.

These are just a few reasons not to automatically delete superseded images. --Timeshifter 02:24, 16 February 2008 (UTC)

Problem is, none of these apply to the images in question. These SVGs were created from a SVG template that was created from scratch. There are specific government templates that tell you if the SVG is accurate or not. The numbers are converted to paths as unique fonts are used. There are no clickable image maps involved here. --Rschen7754 06:11, 16 February 2008 (UTC)

I can see two things that apply in this instance. If I want a 300x300 image, the PNG is superior to the MediaWiki-generated PNG from the SVG: The file is about half the size. Titoxd's point on the deletion request is also relevant, and not just to downstream reusers. If the file was ever used in a mainspace article, then the permanent link to the old version would have a redlinked file. These may be marginal benefits, but they are benefits to having both files. If local users are using PNGs against local rules, handle the issue locally. The most constructive thing that can be done on Commons for these images would be to recategorise them to Category:Superseded Texas road shields or similar. This way anyone looking at the Commons category would find the SVG first but could find the PNG if they wanted them.

Incidentally I'm concerned about these images from a copyright perspective: TX Gov != US Gov and as these are faithful reproductions from the TXDOT specifications, TXDOT copyright may apply (I'm checking into that). That isn't relevant to this discussion, but could be extremely relevant to the images themselves.--Nilfanion 12:06, 16 February 2008 (UTC)

see Image:Texas FM 1410.svg - all road signs in the US (except Interstate shields) are speced under the w:MUTCD making them US Government property - granted yes many of the shields have different license tags (more than likely inappropriate). We have had previous debates both on en-wikipedia and here regarding copyright status. master son^{T - C} 21:00, 16 February 2008 (UTC)

Even if it wasn't, it's just a map of Texas (the shape of Texas is not copyrightable) with some text. PD due to simplicity. —Scott5114↗ [EXACT CHANGE ONLY] 21:29, 16 February 2008 (UTC)

“There is an exception to every rule”

I support the rule not to delete superseded images in general. However, for some cases there should be an exception. Structural formulas of chemicals in an inappropriate format (e.g. JPG) and in very low resultion should not be kept if there is a better SVG or PNG version. The old image also do not have to be kept as a source for the new one, as the structure of a chemical can be derived from its name or open databases. --Leyo 18:33, 24 March 2008 (UTC)

I think no image that is superseded should be deleted for that reason alone, but it should be taken into account if there are other reasons for deletion. The thing is, if the image was used in any article on any project in at least one version there is a reason for keeping the file - not ruining that oldid (example of a page that would be damaged if a LQ image was deleted). The clogging of categories with superseded imagery is a problem, with an obvious solution: Don't categorize superseded stuff (or remove it from those categories). Just have it in a superseded category and its license category, and its gone. If that principle is followed for all superseded stuff, whether it is high-quality PNGs superseded by a SVG or a JPG chemical structure replaced with a raster image, then only the preferred files will be included in content galleries and categories.--Nilfanion 20:05, 6 April 2008 (UTC)

“People say there's no reason to delete, it doesn't even free room on the servers. They forget the benefits of deleting. It's makes things easier to manage, people find good images faster without having to wade though tons of crap, more time is spent on categorizing and describing the good images when the poorer quality ones are gone. Also, users may use those poor quality ones thinking that's all we have.” (cited from here).

For me, oldid versions aren't an important argument for keeping really poor or even incorrect images, as readers can always get a better image in the current version. If e.g. a replaced template is deleted, oldid versions also don't look as they did before. --Leyo 22:13, 6 April 2008 (UTC)

But that is no reason to delete poor images, and there are possible problems (I agree oldid is not that significant but it is of value to preserve when possible). Incorrect images are different and should be deleted, but "low quality" isn't a useful deletion reason in itself. Just decategorize and that solves the problems in your snip.--Nilfanion 01:03, 7 April 2008 (UTC)

... and the next user thinks he/she does a good job and recategorizes a poor image. No, IMHO deletion is the best solution in some cases as stated above. --Leyo 16:01, 7 April 2008 (UTC)

I think what I suggested should be tried to see how it fares, its clear enough "if superseded, decategorize", that explaining it to other users is viable. Send images individually to COM:DEL if you disagree, bulk requests will get rejected (like what happened in the above thread), but well thought out requests on single images may work (I'm not totally against deletion here, but am trying to interpret the anti-deletion stance for you). This page is very problematic, in that this page was never meant to stop all deletions of this type. However, a result of what happened here in 2006/7, the consensus developed that these deletions were bad not here, but on COM:DEL. Like I said, incorrect images probably should go and deleted by process - start with those (I'd likely vote delete too). If you send those through COM:DEL and they get deleted, a more mature rule can develop. Speedy deleting these images, even if you have favourable admins willing to do so, is not going to help solve the broader issue, just make it worse. I'm thinking about doing a version of this is actually helpful for this issue as opposed to the meaningless page, this talk page is hardly a useful "policy".--Nilfanion 21:04, 7 April 2008 (UTC)

Deleting of unusable images is IMHO the best way of “decategorizing” (deleting is in fact just hiding from normal users). --Leyo 11:58, 18 April 2008 (UTC)

Aren't normal users important? Deleting images hides them from me, which is in part why I don't want images deleted (without good reason). Some of my own work has been thus hidden from me (albeit under bad policies that are no longer used). —Toby Bartels 22:08, 4 May 2008 (UTC)

Graphics containing errors

What about maps containing some errors (wrong borders) which have been reworked but come now with another color scheme and a different filename? Should we keep the wrong and unused files, too? E.g. wrong –> correct, or wrong –> correct. --Bob. (talk) 14:59, 16 August 2008 (UTC)

When comes to things like maps or other man-made things (ideas, really) where POVs can be involved, it's usually preferred to put them through regular deletion just in case. The argument to make here is not that it's wrong but that it's not useful. Kinda the same thing, but how you word it affects things, I've noticed. Rocket000(talk) 19:15, 16 August 2008 (UTC)

If the correct graphic is a derivative work from the incorrect graphic, then the incorrect graphic must be preserved to satisfy licences like the GFDL (and in any case should be preserved to show the true history of the work). If convenient, the incorrect graphic could be replaced with the correct graphic converted into the old format, but there may not really be any need for this. In any case, the fact that the old graphic is superseded by a different format is irrelevant. —Toby Bartels (talk) 05:58, 17 August 2008 (UTC)

Giving this a better title

What would you think about changing the title to something more fitting like Commons:Superseded images or Commons:Superseded image policy. The current title rather suggests that it's an usual deletion request for some superseded images, rather than an important policy. --The Evil IP address (talk) 14:25, 7 October 2009 (UTC)

I agree with you. I think the second title fits. — Kanonkas // talk // e-mail // 14:48, 7 October 2009 (UTC)

+1 --Leyo 15:26, 7 October 2009 (UTC)

Yes, good idea. The current title made sense when these were being deleted, but not now. (I would vote for the first suggestion, but it doesn't really matter.) —Toby Bartels (talk) 18:55, 7 October 2009 (UTC)

 Done, after the comments. I've also changed the design a bit similar to the other policies. I think it would be good if this policy would also be translated. --The Evil IP address (talk) 20:47, 7 October 2009 (UTC)

the whole concept of "superceded" is problematic...

the whole concept of "superceded" is problematic here; commons is a media repository.

we are supposed to stockpile lots of media files for others to use; that includes providing variety & choice. this is the primary purpose & function of commons.

we're not just collecting a gallery with "one of everything"!

if we can reach some kind of consensus that one file is better than another, in representing the same topic, & the two files are extremely similar, but not identical, then there may be some basis for indicating which is the "superior" file.

however, there is no valid rationale for deleting one file, merely because another, simillar but non-identical file exists, & is considered by some users to be superior in some ways and/or for some uses.

a "superceded" (non-identical) file should only be deleted when there are other, valid rationale(s) for the deletion.

the deletion policy that was being practiced here de facto has only succeeded in created conflicts between users, & breaking dependencies in the structure of commons.

also; it's pretty clear by now that the media-wiki software, even bot-assisted, isn't up to dealing smoothly with the complexities of this operating function. not to mention, it makes for a hell of a lot of unnecessary manual labour!

Lx 121 (talk) 03:51, 4 December 2009 (UTC)

No dispute there! That said the page is pretty clear in meaning. It needs a minor rephrase (its still talking about the rejected deletion method not the principle of keeping superseded imagery). Any thoughts on how to change it?--Nilfanion (talk) 11:34, 4 December 2009 (UTC)

(sry wasn't following the discussion, my bad) thoughts:

1. if we have consensus about not deleting images just because they are "superceded", then we should draft a section clearly stating this, as a permanent change, explaining in more detail why it's a bad idea to delete items for this reason, & explaining how the "superceded" status might factor in (&/or complicate things), when considering deletion for other reasons.

2. we should probably try & map out the potential complications in deleting a "superceded" image, especially when it is part of a complex set of interdependencies (both practical, i.e.: linking, mediawiki functions, etc. &/or legal: i.e.: licensing). this relates to the previous point, but it is important enough that it should probably be expanded on as a separate topic, or at least as a sub-section

3. we should probably re-think the whole concept of "superceded"; i'm not sure how well it fits with the stated purpose of WMC in the first place. perhaps we should separate technical issues with file quality, technical issues with the accuracy of the info the file contains, & subjective opinions of file quality; making 3 differentiated types of quality-assessment? maybe add a 4th: technical file utility, in the sense of the types of practical application a specific file is better (or less-well) suited to. for example: a) a higher-resolution, larger filesize would be more useful in some applications, while a smaller filesize is better in others. b) the screen-size (& other factors) of the intended end-user device (for a specific applied use of a file) are relevant to the file's usefulness; an HD monitor vs a cell=phone screen, for example.

this goes well beyond the parameters of the current discussion, but it might be worth beginning to re-consider & re-structure some of the quality-control & other organizational aspects of WMC's "system", so that they fit together more logically & better serve the goals of the project.

actually reaching consensus on any of that would be... "interesting" XD

(it would also mean that "we" have a lot of work to do... so much for my thoughts on a "minor reword"; hope you aren't sorry that you asked!)

i try not to spend too much time on policy, or any of the other "behind the scenes" stuff, i get sucked in & it uses up too much of my time, but i'm willing to have a go @ re-drafting a short-form explanation, maybe sketching the outlines of a bigger piece, & revising the wording to establish that this is now a permanent change in wmc policy?

Lx 121 (talk) 13:42, 12 December 2009 (UTC)

Certainly makes sense to me, though I think it would make more sense to draft guidelines as opposed to policy. I think structure you suggest makes sense too. All the objections to deletion are on this talk page somewhere, would help people to state them clearly. As for "guideline" to "policy" once we have a draft form can see if consensus exists to call it policy. I've certainly noticed this issue come up on the VP a few times lately - suggests we need a meaningful page on it.

By the way know what you mean about setting sucked in... I do have some actual useful stuff to do (uploading) but have consumed 100% of time lately in dispute resolution :(--Nilfanion (talk) 22:26, 12 December 2009 (UTC)

As I recall, the biggest problem was that the deletions were carried out essentially in secret (with the knowledge of few other than the handful of individuals operating the process with the agenda of deleting "superseded" images).

No notifications or discussion links were placed on the images' description pages or the uploaders' talk pages. When a discussion was closed, its page was promptly blanked (thereby removing it from the list of pages linking to the image). If the outcome was deletion (which occurred the vast majority of the time), a sysop deleted the image without providing a link to the aforementioned page (thereby preventing interested parties from even checking the pre-blanking history to evaluate the discussion).

I assume good faith, but it almost seemed as though these users went out of their way operate without community oversight (and despite my continual requests, no one ever provided an explanation beyond "just because that's the way we do it").

Literally every deletion that occurred via this underground process was illegitimate. Did anyone ever restore the images? —David Levy 17:46, 12 December 2009 (UTC)

I opened an deletion request on the log pages Commons:Undeletion_requests/Archive/2009-11#Commons:Deletion requests/Superseded, nothing came of it due to lack of interest. That's the first stage to restoring any of the deleted images as it allows identification of the files. If you want to dig through it I can restore (part of) the logs and/or post a list of the deleted files somewhere - the second will take a fair bit of my time of course! I suspect that the images will not be restored en masse by discussion on COM:UNDEL, but selective restores (as in ones where the SVG replacement is obviously not a true replacement) would be considered.--Nilfanion (talk) 22:26, 12 December 2009 (UTC)

In my view, selective restorations are unacceptable, as the images were deleted without community oversight. Administrators have no special authority to evaluate content in this manner, so any such process must be open to all editors in good standing.

Additionally, re-deletion should be based upon the assessment that the image in question is of poor quality or otherwise inappropriate for inclusion in our media repository. There is no consensus that the existence of an accurate SVG replacement is a valid reason to delete a raster image. (If anything, there is consensus to the contrary.)

The images should have been restored by the misguided (an assumption of good faith) administrators who deleted them in the first place. Evidently, they instead decided to walk away and leave the mess for someone else to clean up. —David Levy 14:38, 18 December 2009 (UTC)

I agree that administrators have no special standing on this. However, no one was particularly bothered about restoring the log pages - that makes me feel there will be a distinct lack of interest in restoring the files. There is a difference between the original deletions and the situation now: When the images were originally deleted they were probably in use. If they are restored, they won't be in use and as they have "superior" replacements they likely won't be used again either. The process they got deleted through was deplorable (as was the attitude of the admins involved in the aftermath), but IMO the fact that the process was awful doesn't justify restoring everything by itself.

If you want to start an undeletion request on some or all of the files COM:UNDEL is the place to go, talking about it here won't get anything restored. I can provide you with a list of files (or restore logs) if you want to do that. I'd point out that a "restore everything" request is more likely to get turned down than a whole series of selective restores. For example, asking for restoration of coat of arms imagery is relatively likely to succeed : CoAs are complex and there's a fair chance that the SVG versions are inaccurate compared to the raster files.--Nilfanion (talk) 11:53, 19 December 2009 (UTC)

I agree that the amount of harm currently stemming from the the images' collective absence is substantially lower than the amount of harm caused at the time of their deletion. But I see no practical means of separating images worthy of restoration from those that are not. (Non-administrators are equally entitled to participate in any such evaluation, and the fact that the images were deleted long ago means that said individuals have not even had an opportunity to view them in the recent past.)

More importantly, I see no basis for such a determination, as it has been agreed that even disused images should remain accessible for historical purposes (unless they contain actual problems warranting deletion under our normal standards, of which "obsolescence" is not one).

And this isn't a case of pragmatism outweighing principle, as it surely would be easier to undelete the images en masse (ideally via the assistance of a bot) then it would be to conduct an investigation into which ones are the most valuable, followed by multiple restoration proposals.

As the images were deleted outside of any accepted process (a practice that proved extremely controversial and was thoroughly rejected by the community), I see no reason why their undeletion requires advance discussion or special approval.

For the record, in response to doubts that sufficient manpower is available, I volunteer my services (but only toward actual restoration efforts, not bureaucracy). —David Levy 13:11, 22 December 2009 (UTC)

How about categorization?

Should the superseded images remain in the original thematic/topic categories?

Should be the implied general servicing category of Category:Superseded duplicated by hybrid categories like Category:Superseded maps? --ŠJů (talk) 00:35, 13 March 2010 (UTC)

In my opinion, categories should in general not be removed unless the image is nominated for deletion, but I guess it's OK to create sub-categories like Category:Anti logos obsoleted by SVG replacement in a few selective cases. AnonMoos (talk) 08:41, 13 March 2010 (UTC)

Bad plan. Superseded is extremly point of view. The images shouldn't be hidden in this way. Multichill (talk) 08:50, 13 March 2010 (UTC)

Sometimes yes, but that's probably a misuse of the word. You can usually count of unanimous agreement for files that have technically superior replacements. Alternate versions that the majority prefer is a different story. They are, well, alternate versions, not superseded. Rocket000 (talk) 02:11, 16 March 2010 (UTC)

I think that superseded images should not be totally decategorised, but may remain only in very special (narrow) categories, to allow searching them only by a user who know what exactly he searches. The rationale is to keep densely populated thematic categories in a browsable state. Large categories should not be flooded by bad JPEGs and obsolete PNGs. Incnis Mrsi (talk) 19:27, 26 April 2010 (UTC)

No, keeping "categories in a browsable state" is not really a priority on Wikimedia Commons. Carefully selected subsets of images are for galleries, not categories. AnonMoos (talk) 06:00, 27 April 2010 (UTC)

Then, may be subcategories “Superseded images of …” will be useful for some thematic categories? Incnis Mrsi (talk) 11:12, 8 May 2010 (UTC)

No, not practical. The software should provide the possibility to switch on and off the display of superseded images in categories. --Leyo 11:22, 8 May 2010 (UTC)

I agree with Leyo. -- User:Docu at 07:05, 10 May 2010 (UTC)

 Support Complete removal of relevant categories is not justified by itself (since the image does not change when superseded, its belonging to categories should not change as well), but is useful only to remove the clutter from galleries. It seems that this uncluttering can be easily done by software means alone: if the file description includes any of the "superseded" templates, then just list the image below all "normal" images, under "Superseded" subsection (which, BTW, might be collapsed by default). -- Mikhail Ryazanov (talk) 22:17, 8 June 2011 (UTC)

I think you may have misunderstood my comments on your talk page. A category is to provide categorisation to *all* related images on Commons, not just the good ones. A gallery page, such as Apollo 11, can be used to showcase the best images and provide additional information. — Huntster (t @ c) 03:04, 9 June 2011 (UTC)

My comment above is not directly related to the conversation on my talk page. Explicitly: I agree that all images must be properly and fully categorized; Here I suggest how to improve the representation of category listings without undesirable side effects. -- Mikhail Ryazanov (talk) 02:22, 10 June 2011 (UTC)

I agree with Mikhail Ryazanov. We desperately need some filtering tools at MediaWiki level. Sadly, galleries are not the solution, because they tend to be outdated and underdeveloped comparing to categories. Trycatch (talk) 03:32, 10 June 2011 (UTC)

Couldn't we use some of the new MW features the boards is having implemented for this? --  Docu  at 05:16, 10 June 2011 (UTC)

What are the features (and where to read about them)? -- Mikhail Ryazanov (talk) 22:51, 14 June 2011 (UTC)

Has anything been decided about this? I've been creating a fair few SVGs recently to replace older format images. I've just been removing the older images from their original categories, as I don't want to see duplicates when browsing, but can go back and add them to Category:Superseded if this is the agreed policy? Serenthia 19:44, 8 October 2010 (UTC)

I don't want to see them either when browsing but this is a challenge we are still dealing with. I strongly suggest not de-categorizing them anymore as it is establish policy that all files belong to at least one topical (non-hidden) category. If a file remains uncategorized long enough, a bot will ask the uploaders to categorize them or may even try to categorize them itself (usually with like 10 useless random categories and ugly "check categories" templates that no one removes). You may create a "superseded" category if you think this would be a good idea, but it's probably better just to create a selectively chosen gallery instead at this time. Rocket000 (talk) 07:14, 9 October 2010 (UTC)

Current status – gone strange? (link to VP)

Cross-talkpage link → Commons:Village pump#Commons:Superseded images policy - gone strange? ↔ User: Perhelion 23:39, 11 February 2016 (UTC)

Your vintage 2012 summary in the archive info box here could be added to the project page. –Be..anyone 💩 17:12, 14 April 2016 (UTC)

Images should never be deleted because of InstantCommons

InstantCommons is a feature of MediaWiki to allow the usage of any uploaded media file from the Wikimedia Commons in any MediaWiki installation world-wide.

Let's not forget that the use of an image by a third-party wiki does not show on image page. So there is no way to know whether an image is used elsewhere or not.

By deleting images that are not used in Wikipedia you may break some other third-party wikis.

Wikimedia Commons is not a Wikipedia repository. It's a global repository for all the 25+ thousands of wikis out there.

--Ioannis Protonotarios (talk) 13:37, 6 January 2017 (UTC), a third-party wiki owner.

From what I've seen, nobody and Commons cares much about that. If someone can make a semi-coherent case for deletion, then the administrator will delete it. The amount of low quality, out of scope, or. improperly license images uploaded to Commons is overwhelming (and growing at an increased rate all the time).  Senator2029 ➔ “Talk”  21:02, 28 June 2018 (UTC)

I totally agree with you. Commons:Deletion policy#Reasons for deletion should not say "Before requesting a bad quality file for deletion, make sure that the file is not in use anymore by using GlobalUsage." GlobalUsage is for checking Wikipedia usage but not any usage world-wide. --Tomchen1989 (talk) 13:26, 14 July 2018 (UTC)

Comments regarding COM:Dupe and COM:Redundant

It shows a bad conversion from raster image to vector image. The word "you" above is raster image, the one below is vector image converted from the raster one. As you can see, although vector image is scalable and considered to have better quality, the detail of the shape could be lost during the vectorization. The lose of detail depends on the technique the user uses for vectorization, but a 100% perfect vectorization is generally very hard, or almost impossible, to achieve. Be careful when you vectorize a raster image. And Be careful when you request for deletion of an original raster image from an official source only because of its unofficial, user-converted vector version exists on Wikimedia Commons.

COM:Dupe and COM:Redundant are quite silly or unclear. It should clearly state how to handle the case where initial and/or official image is JPEG or other raster, and is converted unofficially by user to "lossless" PNG or vector. In this case, reasonably the initial/official image should be kept. During a simple conversion from JPEG to PNG without any fixing, the quality of the image cannot get better. During a conversion from JPEG to vector, depending on the technique the user uses, the shape of the image could be a little different to very different comparing to the initial/official version, despite the vector image is scalable. A converted vector version can almost never be 100% the same as the initial/official version regarding the shape, the lines and everything. It also does not disccuss how to handle old versions (e.g. a business' logo's change results in different version), and of course, old versions should also be kept. --Tomchen1989 (talk) 13:29, 14 July 2018 (UTC)