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.

Proposal[edit]

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)
I agree with the spirit of this proposal, but in lieu of the above concerns, perhaps "Updating existing files" is the best fit for a new name. This would cover all conceivable cases that I can think of, and remains clear (and significantly more accurate than "overwriting"). The concern about moving away from often-used shortcuts is legitimate, but in this case I believe the change is worthwhile: I myself (a new editor) was confused and concerned by the "overwriting" terminology, fearful that I would be eradicating an earlier contributor's work if I "overwrote" a Commons file. FormAllTheHides (talk) 02:36, 30 March 2017 (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)

QI/VI/FP[edit]

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)

I work with a lot of time sensitive data files, like for example File:Global Wind Power Cumulative Capacity.svg, and often update the work of others, but I strongly prefer that they update their own files - and often wait to give them a chance to do that. For myself it is the opposite - I would prefer someone else update the files that I have created - less work for me to do - and I am never going to run out of work to do (6,000 files that need to be converted to SVG, 6,000 SVGs that need to be translated). Photographs and some graphs are different, just because whoever created the original image may have access to more information than anyone else, and thus be better equipped to make the edits. Delphi234 (talk) 18:46, 21 February 2015 (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)

Overwriting?[edit]

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 http://grin.hq.nasa.gov/ABSTRACTS/GPN-2002-000107.html - 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)

Periodically updated files[edit]

This section was split from the previous section --09:53, 23 February 2015 (UTC)

A lot of the work that I do is updating images with new data (not photographs, but diagrams), like File:Average Retail Prices for Electricity in the US.png (that one I would probably make an SVG first though, and leave the PNG as is - right now I am holding off for a few days or a few weeks because 2014 data will soon be available). But File:Global Wind Power Cumulative Capacity.svg is used in 32 articles now, and is used to show the growth of and current status of the wind industry, and needs to be updated annually, each February. I am thinking of creating a Category:Files that are updated periodically (at scheduled intervals?) with the subcategories weekly, monthly, and annually. There are as many as a dozen files about the Ebola outbreak that various editors are updating weekly now, as each new situation report comes out. The biggest problem I have been having actually is to lose track of files that should have been updated, and have become out of date, so categories like updated annually in February, or November, for example would help. Delphi234 (talk) 18:38, 21 February 2015 (UTC)

That sounds reasonable. Maybe it would be helpful to have a "Files that need updating in..." or "Files that are outdated by..." category for things like that? Especially any graph based on annual data releases.
However, there are likely to be some other files which need updates at less predictable intervals. bobrayner (talk) 21:26, 22 February 2015 (UTC)
Both good points. Top level? "Files that will require updating" "Temporal data files"? There are some, like File:US monthly wind capacity factor.svg where the data is available monthly, but they really only need to be updated about once or twice a year. Delphi234 (talk) 00:07, 23 February 2015 (UTC)
Are you aware of {{current}}? Perhaps your "monthly/yearly" "outdated by" could be managed automatically by adding template parameters? --99of9 (talk) 09:53, 23 February 2015 (UTC)
Can it create a set of hidden categories, so that we can find a list of files? Can it compare the last upload date with the current date to create a stale dated hidden category? Can we change "This file may be updated to reflect new information." to "This file is updated {parameter 1} to reflect new information."? With parameter 1 being "in February", "in July", "in November", "in 2020", "annually", "monthly", "weekly", "daily". The File:Diagram of the United States Census Data.png only shows the decennial census, and would only be updated once every ten years, or to make corrections. There are occasional current events where data changes rapidly - hourly or even shorter periods. Delphi234 (talk) 19:08, 25 February 2015 (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)
If nobody objects I still intend do that, i.e., move a subpage of my user page to a subpage of the project page and add a link to it on the project page with a note about overwriting invalid SVGs with a valid version. –Be..anyone 💩 05:31, 13 April 2016 (UTC)
I mean this falls absolutely under non-controversial edit and also minor improvements, so an enlargement seems needless. User: Perhelion 10:28, 13 April 2016 (UTC)

✓ Fixed by AlumnumDelphi234 + –Be..anyone 💩 06:00, 14 April 2016 (UTC) Edited: credits for the fixed credits to Perhelion, see below. 13:44, 14 April 2016 (UTC)

? The reason SVG fixing was included by Delphi234 on 14 March 2016 (as example of minor-improvements.[1] User: Perhelion 12:52, 14 April 2016 (UTC)
I am not sure what "Rillke's law" has to do with fixing invalid SVG, but if someone asks can I fix SVG that means it needs to be either disallowed and say that or allowed and say so. I see no reason for disallowing, although I would encourage anyone who has created invalid SVG to make a note something like this SVG is invalid but please leave it like that as it is being used as an example of invalid SVG. Delphi234 (talk) 09:57, 7 October 2016 (UTC)

Question of principle: How much sensible?[edit]

How ingenious is to improve a file, and then replace it (with GlobalReplace) with more than 500 usages⁉ I ask this because this is not an individual case and gets a new recommendation for some users (in particular CoA SVG-artists). User: Perhelion (Commons: = crap?) 15:57, 29 November 2015 (UTC)

Additionally, how ingenious or useful is it if the (previous) files get then deleted? User: Perhelion (Commons: = crap?)  14:32, 16 December 2015 (UTC)

Examples (of the last month, what I mean)
File:Wappen Landkreis Helmstedt.svg (>400 replacements at Nov.) 7. Dez. 2015
File:Wappen Landkreis Lüneburg.svg (850 replacements at Dec. 06) 16. Dez. 2015
File:Wappen Landkreis Cloppenburg.svg (324 replacements at Nov. 12) 29. Nov. 2015

or

User: Perhelion (Commons: = crap?)  15:17, 16 December 2015 (UTC)

Very unlucky example[edit]

The File: Wappen Kottmarsdorf klein.gif got overwritten by an SVG rendering, which violates "normally" the redundant and duplicate policy. This was also a part for the occasion for creating the whole Superseded images policy thematic. I suggest to remove this example. I always revert such images. User: Perhelion 15:38, 6 June 2016 (UTC)

Global detection[edit]

I noticed many times that any image was overwritten inappropriately. Sometimes by mistake (I myself overlooked the warning and overwrote even my own files several times), sometimes from ignorance (somebody overwrite an image with better or "better" one, not knowing that a new file should be uploaded under a new name) etc.

Should'nt somebody find and tag ALL overwritten files and filter them systematically to find and save (restore) all inappropriately overwritten files, and to enable to mark the suitably overwritten files as approved to the date of the check? Some bot should take care of it permanently. --ŠJů (talk) 19:39, 7 August 2016 (UTC)

This is not a rule, only a guideline. Jan Arkesteijn (talk) 21:08, 7 August 2016 (UTC)
Yes, "it illustrates standards or behaviors which most editors agree with in principle and generally follow." I do not assert that ALL overwriting files should be reverted to the first version. I propose that all overwritten files should be considered to be saved. Previous version should be restored especially in cases of inappropriate overwriting, and the new image ("version") can be uploaded under a new name (or the old version under a new name), if it has a valid license and attribution. Reasonable overwritings can be tagged as approved. --ŠJů (talk) 23:12, 8 August 2016 (UTC)

Cropping issue for Tangyes Lantern Slide Collection[edit]

Category:Tangyes Lantern Slide Collection needs to be cropped to make the images usable. How should this be done? Is there any virtue to re-uploading under new names, or is the old form not useful enough to need any more than the image history? See Tangyes Lantern Slide Collection#Cropping? Andy Dingley (talk) 13:52, 24 August 2016 (UTC)

Redundant non photographic images[edit]

I would like to state just another small negative side-effect of this policy: A possible amount of redundant personal interpreted user images. Which problem then get spread over the whole Wikipedias. Example: Commons:Deletion requests/Fictional Papal Arms User: Perhelion 21:42, 28 August 2016 (UTC)

This does not seem to be about personal images, but whether or not to keep coats of arms that do not follow the official blazon. Calling them redundant or saying they should be overwritten with each other is distracting from the real issue. This real issue should be solved case by case or category by category, not by changing this policy. Rewriting different versions of CoAs with each other is a not too uncommon edit war topic, much better solved on the Wikipedias. --LPfi (talk) 11:08, 29 August 2016 (UTC)
What have out-of-scope files to do with overwriting policy? --ŠJů (talk) 14:45, 29 August 2016 (UTC)
@ŠJů: The Papal Arms at generally is not out-of-scope. Maybe it was an unlucky example. But yes the question is, when is it out-of-scope!?
@LPfi: Maybe you're right, thanks for response. But compare also Commons:Village_pump/Proposals#Proposed_mass_deletion_of_Latin-named_coats_of_arms_uploaded_by_Ssolbergj of this issue (on Wikipedia are mostly not that people which solve this for all Wikipedias).
I do not want generally a change of the policy, only an indication of the subject matter. User: Perhelion 18:52, 29 August 2016 (UTC)
@Perhelion: Here is discussion about Commons:Overwriting existing files policy. I did not understand what fictional coats of arms have to do with overwriting policy to be discussed here. --ŠJů (talk) 18:57, 29 August 2016 (UTC)
@ŠJů: I mean not really fictional (that's only in the title of the link). You are right, if an thematic question should be, what is fictional!? Often we can not view each policy separate. Redundant files (Coat of arms was only an example) of a possible side-effect of the result of this policy (if NOT Overwriting). I see now the relevant section is high probably #Controversial or contested changes =COM:UPLOADWAR. I see you are Czech, what do you think about this:[2]vs[3] or [4]vs[5] or [6] or [7] etc... (changed dozens of sign sets from silver to black border without source). Okay or not? You were also here, not redundant? User: Perhelion 23:02, 29 August 2016 (UTC)
As regards the Czech road signs, I mean that the image from the official ordinance should be not overwritten with "improved" versions. And an image with full name and full description should be not deleted when any undescribed derivative with unclear source is the "better version". Czech road signs have a white margin only, not a black. The subtle silver shadow is better to depict it. --ŠJů (talk) 23:25, 29 August 2016 (UTC)
Thanks for your opinion, I fully agree. (the relevant user has admitted in his last sentence, that the black border is only his own point of view, after many trouble and block of us both). In short, I mean people made often her own very similar redundant (most likely unnecessary) copies and push them. That's the problem what I mean and thereby files without source (we can't say fictional). User: Perhelion 23:47, 29 August 2016 (UTC)

This guideline should be reopened for discussion with notice to all Wikimedia Foundation projects[edit]

Because the Commons community failed to notify the Wikipedia community that this was being proposed as an official guideline back around 2012, I was unaware of this guideline and uploaded newer versions of about 20 to 25 of my own photographs---that is, where I was passing by the same subject and took the opportunity to get a better photograph (either because the lighting was better, the subject had changed somewhat, or because I had since bought a DSLR). To bring those photographs into compliance with this useless guideline is going to take about 50 hours of work, which I am quite irritated about. Because I have higher priorities (like improving the University of California article) than redoing work I already did years ago, it is going to take over two years to complete that task. It is because of poorly-thought-out guidelines like this one that all Wikimedia Foundation projects are hemorrhaging editors at an unsustainable rate.

It seems to me it would be much better to get rid of this guideline, because I do not understand why there is any need for it. As a matter of common sense, this guideline creates far too much unnecessary work; then all editors on all Wikimedia Foundation projects have to constantly scour Commons and/or other Wikimedia Foundation projects for updated images of the same subject matter (e.g., the Alameda Avenue entrance to the Walt Disney Studios), when an update can be propagated to all Wikimedia Foundation projects through a simple overwrite. (For example, earlier this year, the Walt Disney Company redecorated their Alameda Avenue entrance with a more conservative design and added the Mickey Mouse shape to the entrance gate, but it is unlikely that any article will discuss that change, as it did not draw any media coverage which could be cited in article text as a reliable source.) I propose reopening this guideline for discussion with proper notice to all Wikimedia Foundation projects. --Coolcaesar (talk) 06:21, 17 October 2016 (UTC)

Yep; when Crimea gets absorbed in Russia, it can be updated on all pages simultaneously. Then Wikinews editors who used a map can go back and revert, to be reverted by Russian Wikipedia editors, to be reverted by Ukrainian Wikipedia editors, to get changed to a "neutral" version, which won't satisfy any of the previous editors ... Loads of fun, as every long-term Commons editor can tell you.
If the Alameda Avenue entrance changes, then overwriting the image causes two problems:
  • We don't have a picture of the old entrance available, except hidden in history.
  • Any page that uses it to display the Disney Studios at a certain point in time, or to show how Disney is moving away from the Mouse, now has an inappropriate image.
Yes, Wikipedia pages need to be updated every so often. Go ahead and upload the new pictures and update the English Wikipedia, and other Wikipedias will likely follow suit, or sometimes not, upon looking at the changes.--Prosfilaes (talk) 16:17, 17 October 2016 (UTC)
You're begging the question without actually answering it. You're making the silent assumption that there would be any need to display the prior appearance of the Walt Disney Studios' entrance at a certain point in time. Under current Wikipedia guidelines, that specific issue would never go into an article (or would not remain there long) because we don't have a reliable source on it. The dramatic change to the Alameda Avenue entrance has not been covered in any reliable sources. In turn, there is no need for a photograph to illustrate a point that will never come up in an article. --Coolcaesar (talk) 05:38, 28 October 2016 (UTC)
Photographs on Commons are not just here for encyclopaedic value, there is a wider brief for a likely educational value. For this reason the project has many images that will never be used by a Wikipedia project. In the hypothetical case you put, I can imagine a commercial historian would find historical images of the Disney Studios (and therefore their branding) educationally useful for illustrations. As you are discussing policy, then yes, overwriting images that are in use on Wikipedia articles is a concern and remains poorly managed. This is one of the reasons that the live report at BLP overwrites was created, as this 'blindspot' for Wikipedia and Commons was being used for serious vandalism of biographic articles. -- (talk) 08:12, 28 October 2016 (UTC)
We are not an archive of pictures for Wikipedia; we serve all Wikimedia projects and to some extent a far larger community. Your interpretation of the English Wikipedia rules is your interpretation, and certainly not binding on even all Wikipedias.
In this specific case, yes, a Wikipedia editor could chose the older image for aesthetic reason or any number of reasons. That would be a discussion that should be had on Wikipedia, not Commons. The idea that it is known that there is no reliable source seems silly; has anyone checked all issues of the Alameda Sun, the San Francisco Examiner, Oakland Tribute, as well as any other newspaper that might cover it? That no one in the wide world has published a journal article or even a book on the subject that might have escaped notice? That no one will?--Prosfilaes (talk) 21:14, 28 October 2016 (UTC)

Crop[edit]

I have an argument over cropping as a minor modification : I scan through many aircraft pictures and often there is much empty space of sky around the subject (aircraft are often far away and need a long telephoto, and the uploader often transfer from other websites without editing). Since there is the lossless croptool, I often crop them to better fit the frame and avoid thumbnails with a tiny speck somewhere. I made this in compliance with Commons:Overwriting existing files, specifically #DO overwrite > Minor improvements [...] removal of a watermark/ cropping ("where the essential composition is not altered") as in File:Miyasaka Hakuryu II - Tigress with Two Cubs - Walters 71909.jpg where the useless background cropping is considered a minor improvement as the main subject isn't altered. But others thinks it is a #Substantial crop or un-crop and thus should be uploaded as a separate file. I think it could be a good thing to establish more clearly that a neutral background crop is a minor improvement. It was discussed before in Commons_talk:Overwriting_existing_files/Archive_1#RFC--Marc Lacoste (talk) 09:19, 6 December 2016 (UTC)

@Marc Lacoste: Read COM:UPLOADWAR. If an editor contests your change (by reverting it) you may not simply put your version back on top... instead, upload it under a new filename as a derivative version. Croptool is capable of doing so automatically. Reventtalk 10:15, 6 December 2016 (UTC)
Indeed but when an edit complies with a policy the revert could be misled.--Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)
We need to keep in mind that though how images may appear when in use in Wikipedia articles is important, and hence images that look good in thumbnail sizes are needed, it is also true that reusers may want original uncropped versions to make their own versions, such as enhancements, or their own crop preferences or where they are using the original where extra space may be a useful feature of reuse such as for mixed presentation slides. Though images are always in the history, our reusers are likely to find these overly complex to view and recover, hence the importance of sticking to creating significant crop as new files. Exceptions should be obvious, such as removing artificial margins, handing very poor framing or an unhelpfully angled image which distracts from the subject, and in those cases we rarely see reverts. -- (talk) 10:30, 6 December 2016 (UTC)
It doesn't seem more accessible to search a file origin for an hypothetical uncropped variant than for its history. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)
I'm unsure of your exact meaning, however it's normal to link to derivatives by using the parameter 'other_versions'. I tend to use the gallery tag to link to and from the original, which makes them literally easy to see. -- (talk) 23:02, 6 December 2016 (UTC)
Yes, like that it is similar to the file history--Marc Lacoste (talk) 06:08, 7 December 2016 (UTC)
Two things: 1. As was already pointed out, if an editor contests a change, upload as a new version. The change obviously was not "uncontroversial". 2. I personally find the tight crops that aviation photographers seem to prefer hideous. Give the poor planes some room to breathe. Tight crop vs. non-tight crops is clearly an artistic choice. The wording about "small crops" is in my opinion targeted at cropping away unclean borders or distracting detail in corners or on borders. --Sebari – aka Srittau (talk) 14:05, 6 December 2016 (UTC)
I don't like too tight crops either, I dislike too thin aspect ratio images and stay with a 3:2-2:3 frame. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)

All I was saying wasn't to defend my position, but if the example shouldn't pass now it should be changed and the rule clarified. --Marc Lacoste (talk) 20:47, 6 December 2016 (UTC)

"You cannot overwrite this file." message[edit]

How about explaining Why and what options i have available in such a case. Also, it would help if this message were a bit more visible... -- Random20161229 (talk) 22:17, 29 December 2016 (UTC)

PS Using the Special:Upload, i am told the reason ("because your account is too new") and given a potential course of action: "Please go back and upload the file under a new name. Once you've done that, you can ask someone at the Help desk to move your file to the name you want."... But in such a case, can users actually "merge" the two images (the existing one and the new version i am trying to add to its "version history")?! -- Random20161229 (talk) 22:25, 29 December 2016 (UTC)
Apparently, admins have that options, but i don't think regular users do... -- Random20161229 (talk) 21:04, 30 December 2016 (UTC)

problems with displaying my overwriting file.[edit]

I've just updated a new version of this file [8] which is considerably different from its previous versions. The problem here is that in the article using this file, Nguoi Nung of Vietnamese Wikipedia [9], it is displayed as its previous version instead of its newly uploaded file [10]. How could I make the file to be displayed as its latest version. Thanks. Bookworm8899 (talk) 15:51, 13 March 2017 (UTC)

My question has been replied here [11]. No further answer needed. Bookworm8899 (talk) 18:12, 13 March 2017 (UTC)

Transparency[edit]

Nothing mentioned here. Until today I thought a background is not important (especially for coat of arms and icons) and is not a reason for duplicates (case for speedy-deletion). I thought also there is a sentence on the Commons guides for this, but also nothing? Would it be ok to write something here under Minor improvements? -- User: Perhelion 13:51, 3 April 2017 (UTC)

  • Adjusting transparency would fall under the category of minor improvements. It's something that's only visible in certain conditions. Wikimandia (talk) 16:23, 5 July 2017 (UTC)

Bad files - overwrite or replace?[edit]

I'm trying to eliminate the bad coats of arms in Category:Bad SVG Adobe files with CDATA blocks. All of these files were created by the same user (Oxenhillshaw) who has not been active since 2010. As an example, file:Arms of Baron Alvingham.svg, which I'm working on at the moment, has nearly 1,000 errors. I'm not working with the original files but recreating them, so these are not minor changes. I was uploading a new, original file for this reason, but then I realized this would create extra steps in doing global replace and then proposing deletion of the bad original file. (There is no point of keeping the bad files around, since they are hugely bloated, about 10x the size of the improved). It seems easier just to overwrite the file with errors. But someone just told me I'm violating this policy. I can see the reason behind both approaches, so what is the best way to proceed? I'm fine with reverting and uploading as separate files, but it would be good to have instructions in this guideline on what to do in the future with files that have errors. Wikimandia (talk) 16:36, 5 July 2017 (UTC)

If you deem that an old version is bad enough to be deleted and, fortunately, have a re-created image showing approximately the same picture, then you should boldly upload it over and wait for a reaction. Deletion of the old stuff is a reasonable option in two cases:
  • The old image is so bad that shouldn’t be kept even in file histories (usually, due to copyright issues).
  • The new version has differences so substantial that some Web pages depending on the old file wouldn’t willingly display the new one.
Incnis Mrsi (talk) 08:56, 6 July 2017 (UTC)

“Higher resolution“[edit]

This clause sometimes result in consequences (see February 2012) which reasonable people writing the guideline didn’t probably envisage. I know more cases of clueless tampering with good images. Shouldn’t the clause be restricted to photographic images and other obtained from digitization? Including scans, tomography, remote sensing and alike, but excluding everything which might rely on pixel structure. Incnis Mrsi (talk) 19:57, 8 February 2018 (UTC)

Should be limited to cases where it is a higher quality and more accurate representation of the same original work. Otherwise they must be separate uploads. -- (talk) 20:23, 8 February 2018 (UTC)
A correct heading of thought, but not in every appropriate case the original thing is an [art]work. In File:HXMM01.jpg#filehistory we see a fix of a clear mistake by the original uploader who accidentally degraded the photo, but generally it would not be unreasonable to replace one image with another showing the same things about the same part of deep sky (essentially permanent by our time scale), but of better quality. In more complex cases it would require a great wisdom to judge whether is the original subject identical or not (for example, landscapes in morning and in afternoon are certainly distinct for photography). There is a well-defined “original thing” which didn’t change between images → one can at least consider replacement; otherwise it is prohibited from the onset. Incnis Mrsi (talk) 10:15, 9 February 2018 (UTC)
Nothing should rely on pixel structure, not in a world where the image might be displayed through a 640x480 projector or through a 3840 x 2160 monitor and the person on the other end might be someone with 20/20 eyesight, or someone legally blind with zoom cranked up on everything. The only exceptions I can think of is screenshots of consoles or computers. In the case of your example, the SVG is much better; it will zoom cleanly to the needed resolution, and never blur because it's in general impossible to for algorithms to know whether or not pixel structure should be preserved or interpolated. (Cf. w:Pixel-art scaling algorithms, and note that for that specific case, there's quite a number of choices, with different problems.)
I don't see that we need to change this clause at all, nor that changing it will have a significant effect on cluelessness.--Prosfilaes (talk) 21:59, 8 February 2018 (UTC)
Do not force own understanding of graphics upon all the world, even if it is 99% correct. Compare: I really detest such things as “x” as a multiplication sign and wrappable spaces around it, but deem unwise to restrict Prosfilaes’s freedom to make typographic errors, even considering that they could potentially induce other people into the same habit. Prosfilaes likes SVG incarnation of Zeckendorf – let’m use it everywhere, but my PNG displayed pixel-by-pixel has a better quality than rasterized SVG and, moreover, intrinsically represents the subject in a more straightforward way. Incnis Mrsi (talk) 10:15, 9 February 2018 (UTC)
Do not force own understanding of policy upon all the world.--Prosfilaes (talk) 02:52, 10 February 2018 (UTC)
We now see one user arguing about such remotely related matters as projectors and legal blindness, and two users deeming that the clause needs a more precisely defined domain of applicability because (mis)interpretation caused demonstrable disruption in images hosted here, as they are encoded in digitized form – without any projectors, monitors, and eyes. Incnis Mrsi (talk) 06:34, 10 February 2018 (UTC)