Commons talk:Overwriting existing files

From Wikimedia Commons, the free media repository
Jump to: navigation, search

See Archive 1 for the RFC establishing COM:OVERWRITE as guideline. This is the talk page about this guideline. Please use the upload help or a help desk in your language for questions about its application.


Change title to "Commons:Changes to existing files", because that is what this is about - when to create a new file and when to upload a new version. It is not about "Overwriting existing files". Moving it will automatically create a redirect from "Commons:Overwriting existing files". Delphi234 (talk) 03:15, 8 September 2012 (UTC)

Overwriting and changing are functionally the same thing. Sven Manguard Wha? 04:55, 8 September 2012 (UTC)
I don't see the need. The "overwrite" terminology and COM:OVERWRITE shortcut for it are quite familiar to many people, so I wouldn't rename away from that without good reason. Rd232 (talk) 10:27, 8 September 2012 (UTC)
Changes seems to ignore the common case of replacing the file with a whole new one.--Prosfilaes (talk) 21:23, 8 September 2012 (UTC)
I oppose the proposal. To create new (derivative as well as non-derivative) files and upload them is (itself) uncontroversial and is not the matter of this guideline. This guideline is focused specific on the problem of overwriting existing files. --ŠJů (talk) 23:59, 5 January 2013 (UTC)

Reproductions of two-dimensional works[edit]

I think, the guudeline should mention a question of reproductions of artwork and documents. I propose to add into the section "DO overwrite" (please correct my ungainly English):

Better version of a reproduction

If the uploaded file is a simple reproduction (copy, facsimile etc.) of the original work (photo, painting), document etc., it can be ovewritten with a better version. However, when the copy or reproduction itself could be considered as a creative or important derivative work, it should not be ovewritten. Usually, photographs of three-dimensional works are considered as creative derivative works and shouldn't be overwritten not even with a better version; simple copies and photographs of two-dimensional works with no perspective distortion and no special illumination are not considered as an additive creative work and can be overwritten with a better version. Don't overwrite a reproduction which should document the condition of the depicted subject.

--ŠJů (talk) 00:27, 6 January 2013 (UTC)

This is not always so obvious. Take as an example my own batch uploads at Category:Chromolithographs at Boston Public Library. There are many duplicate prints in this category and sub-categories, however choosing the best version and just keeping that visible is not to the greater benefit of open knowledge. Wear and tear, printing marks, differences in print runs and even some pencil mark-up in the margins are all useful to notice and may help identify information about the print that is not yet documented (even by Boston Library in their catalogue). This may not be so true with pure digital variations (such as different sizes or crops), but with scans of printed images there needs to be more in the guideline than just encouraging users to overwrite an apparently inferior version. Thanks -- (talk) 01:12, 6 January 2013 (UTC)

EXIF information[edit]

It should be added:

DO overwrite

A file without EXIF metadata or with incorrect or incomplete EXIF metadata can be ovewritten with a file with original, corrected or added EXIF metadata.

DO NOT overwrite

A file with EXIF metadata should not be ovewritten with a file without EXIF metadata (even if the main change falls under "DO overwrite" cases). When you made whatever change of any file, pay attention to sustaining of metadata.

--ŠJů (talk) 01:43, 6 January 2013 (UTC)

collaborative efforts unlikely to be controversial[edit]

I think an addition would be handy, something like

✓ collaborative efforts unlikely to be controversial, such as Commons:Graphics Lab requests.

Penyulap 07:41, 11 April 2013 (UTC)

I don't agree unless the author of the original is a collaborator and the overwrite is shortly after the upload of unedited version. This case is already permitted by the criteria. I don't understand why people want to overwrite rather than upload with a new name. My experience is that the former wastes time and causes conflict. --Walter Siegmund (talk) 17:00, 11 April 2013 (UTC)
I can't see the case of collaboration, there is no tick in the box for it. Penyulap 17:30, 11 April 2013 (UTC)


I disagree with the rule saying QI/VI/FP cannot be adjusted at all. The author/uploader should be able to make some minor fixes or upload a higher-resolution version or change EXIF data, etc. A recent example was where an image passed QI but was clearly rotated and that needed fixed to stand any consideration for FP (yes I know the standards are supposed to be the same, but..) I think instead we should say that the change should be uncontroversially a minor improvement, and generally only by the original author/uploader. For example, someone "helpfully" changing the colourspace or white balance or crudely applying more noise reduction could all be controversial. We really don't want someone to have to renom and delist their FP just to remove a dust spot. Colin (talk) 12:26, 9 September 2013 (UTC)

I dunno. I do not consider rotation to be a minor change at all. How FP QI or VI run their processes should have zero impact on this guideline, in my opinion. If the problem is that FP requires delisting, then the solution should be found within FP, not here. On the other hand I do see that Commons generally allows changes shortly after first upload, maybe within a day. Those cases are covered by the three green-ticked cases under major improvements. And now, having looked at what counts as "minor", I find each can easily be controversial, but I have become quite biased towards the never (or hardly ever) overwrite position. Why? I've seen too much controversy and wasted editor time (e.g. map edit wars), all avoided by having "changed" versions uploaded under different filenames. -84user (talk) 15:06, 12 September 2013 (UTC)
A fraction-of-a-degree rotation to fix a faulty horizon is certainly a minor fix. As is removing dust spots. Or CA. Or any number of other sensible things that people might do that are clear improvements. This is less to do with FP/QI process and more about regulations getting in the way of improving Commons/WP. An image that makes QI or FP has a higher than normal chance of being used on WP. So who is going to change all the links on the various WPs, including ones I don't have an account on? And then we're left with our repository containing two virtually identical images but one has dust spots. Are you really saying we have to waste people's time on QI/FP/Wikipedia re-reviewing images, and changing image links just so someone can fix a dust spot. Looking at the history of this guideline, it is clear this extra rule was invented by someone unfamiliar with the consequences (and who said so themselves). Colin (talk) 16:55, 12 September 2013 (UTC)
I agree with you Colin. Authors should be able to make small changes if they are unambiguously improvements, even on featured images. Others should need to get the permission of the QI/VP/FP author even to make minor improvements. --99of9 (talk) 10:52, 17 October 2013 (UTC)

I have made an edit here. The rule about QI/FP was added to this guideline by someone who doesn't participate on those forums and there is no consensus for it on those forums. It gets in the way of doing the right thing. In addition, users should be much more cautious about editing other people's work -- it is nearly always better to have the creator do the fixes. -- Colin (talk) 13:53, 9 March 2014 (UTC)

Accessibility replacements?[edit]

Where do replacements for accessibility purposes fall into this overwrite/don't overwrite scheme?

Example: An existing .svg map uses low-opacity (0.15-0.25) lines to indicate that a particular transit service is under construction or planned. That is less than 50% gray, leaving almost no contrast with the white background, which means that the graphic is not considered accessible under WCAG 2.0.

It would be better if the graphic used full opacity, and replaced the low-opacity lines with dashed lines.

Does doing such a replacement, provided I have ensured that the various meanings in the legend are still in agreement with the meanings of the original, qualify for direct replacement, or do Wikimedia guidelines prefer a new graphic in this case?

Thisisnotatest (talk) 06:24, 3 January 2014 (UTC)

This sounds like useful work. If the end result is just as likely to be as pleasing in style to most people, I would recommend uploading the new version over the old file. Should the changes be potentially jarring for some (which might be the case for high contrast images) you would avoid any possible debate or controversy if you upload this as a new file and link to it from the original as a derived work. There is a guide at Commons:Overwriting existing files, it is mostly common sense. -- (talk) 09:51, 3 January 2014 (UTC)
It's actually pretty standard on transit maps to show under construction and planned lines as dashed lines; the existing map is the outlier here. The one thing that I would think likely to be jarring is making the yellow line, which cannot provide good contrast against a white background, accessible. Actually that's a good reason for transit agencies not to call a line the "yellow line", but given that transit agencies sometimes do this, we are stuck with the accessibility challenges of mapping it. The only way to provide sufficient contrast is to trace them with black, but that sets them apart from other lines unless those, too, are traced. The other issue is when there are labels in those colors with the lettering punched out in white as is done with this map. Technically, any color lighter than 50% gray should have black text instead of white in the punch-out.
That said, given the new map is likely to be less aesthetically pleasing, I'll take your recommendation and make it a new map. Thank you for your assistance.
Thisisnotatest (talk) 07:02, 4 January 2014 (UTC)

Mentioning the modifications made to the original[edit]

In all CC licenses, we must indicate if we have modified the work — for example, if you have taken an excerpt, or cropped a photo. We must retain an indication of previous modifications to the work too. See this example. I think this should be mentioned at Commons:Overwriting_existing_files#Attribution. Jee 06:55, 16 March 2014 (UTC)


I'm confused by the guideline to not overwrite existing files. I understand the idea, that it is desirable to preserve the original because that's the starting point for any derivative works, and because many changes are apt to lose some information. Let me highlight two examples, beginning with a portrait that's been around for awhile: File:James_Fletcher,_official_NASA_portrait.jpg shows a revision history, beginning with an original, then a crop, then a revert, then "brightening." Should I want to make some improvement upon the picture, I could begin with any of the four versions. There's a similar litany of changes for the better at File:Dick_Cheney.jpg. Given this clear revision history and the evident improvements, what is the problem with minor corrections as in this case? -- Ke4roh (talk) 15:33, 4 November 2014 (UTC)

The problems with not making the corrections directly in these files are that then it becomes necessary to edit however many articles reference the files to take advantage of the improvements, and it adds work on Commons. -- Ke4roh (talk) 15:59, 4 November 2014 (UTC)
I am sure someone will explain the rationale better than me, but the idea is that Commons should serve the reader and reuser as far as possible and not really concern itself with work required by we "editors", or better, "curators". As to that NARA image, the intention behind not overwriting is explained in the template text "Please do not overwrite this file: any restoration work should be uploaded with a new name and linked in this page's "Other versions =" parameter, so that this file represents the exact file found in the NARA catalog record to which it links.". We want, I hope, to keep the original historical image, regardless of any colour or other defects. The decision as to which version (crop, colour balance, what have you) of an image should appear on separate projects should be left to those projects and we should not dictate them ourselves. Your NASA example demonstrates the problem of insufficient source details, but it appears the brightened version came directly from the "Large" version on the NASA page - the file sizes are the same. -84user (talk) 02:01, 5 November 2014 (UTC)
Our approach is inconsistent, so it is a good idea for projects such as NARA to explain when they wish to keep the identical image as the "top copy" and keep derivatives separate. There may be times when removing obvious flaws could usefully overwrite the file, and others where even removing border could damage an archive photograph's value for reusers. I can think of examples of both scenarios among my own GLAM uploads, just today I overwrote Psychoanalysts including Freud. Photograph. Wellcome V0027600.jpg to remove a highly distracting reproduction sticker which most folks would agree has no value, however it is useful that the image can be referred to in the file history. -- (talk) 02:12, 5 November 2014 (UTC)

Fixing an invalid SVG[edit]

Hi, triggered by a question on COM:Upload help I plan to add "fixing an invalid SVG under Rillke's law" as commonly used plausible overwrite reason. –Be..anyone (talk) 06:39, 31 December 2014 (UTC)

Here are a improved version to this file, I am not a computer expert, so it doesn't create an image in SVG. --58inejohns (talk) 06:05, 5 January 2015 (UTC)
I've linked the variants (PNG to SVG, SVG to PNG), users can pick what they like better. Or they adopt your fix for the SVG, and flag the PNG as redundant. Thanks. –Be..anyone (talk) 12:13, 5 January 2015 (UTC)
That seems reasonable. bobrayner (talk) 21:25, 8 January 2015 (UTC)