Commons talk:Image guidelines

Update Image page requirements for QI to include SDC requirements

Quality images missing SDC depicts currently has a six-figure number of files in it. And yet about half of all promoted images don't have any depicts (P180) statement. Maybe it's time to update the Image page requirements to include some COM:SDC requirements?

My suggestion would be to change subsection 2.2 to read: "have a meaningful file name, be properly categorized and have an accurate caption in one or more languages (see also Commons:Language policy), at least one appropriate depicts (P180) statement and a location of creation (P1071) statement where applicable." MB-one (talk) 11:38, 19 March 2024 (UTC)

I do not believe that further tightening or increasing the number of rules for QIC will lead to better overall image results on commons. Such an approach is more likely to further restrict the circle of participants and discourage new, interested photographers. --Smial (talk) 18:02, 20 March 2024 (UTC)

+1 for Smial's answer. Plozessor (talk) 14:18, 21 March 2024 (UTC)

I agree with Smial. Let's have the focus on getting more files having depicts (P180) and let's focus on getting a better support/accessibility/tools for this property. Romaine (talk) 11:17, 5 September 2025 (UTC)

Smial is right. – Aristeas (talk) 14:40, 5 September 2025 (UTC)

Resolution and sharpness

I have two observations regarding resolution and sharpness.

• The official guideline of 2 megapixels is very low by modern standards. Two megapixels are fine for historical documents that are not available in higher resolution, but every phone nowadays can do 12 megapixels at least. The resolution guideline should also vary by subject. Subjects like birds are typically imaged at lower resolution since fast cameras for wildlife often have lower resolution than their stills counterparts (for example comparing the 24MP speedy Sony a9 III versus its contemporary 61MP Sony a7R V), and cropping is often needed. Meanwhile, still subjects such as architecture should have a much higher bar for resolution. I would suggest at least 12 megapixels for architectural photos.
• There seems to be a misunderstanding of some Commons members where they would look at every photo at 100% regardless of the resolution, and critique "sharpness" and "noise" based on that. Imagine a 100 megapixel photo and a 10 megapixel photo, where the 100 megapixel one is slightly soft in the corners but would be perfectly crisp across the frame had it been downsampled to, say, 50 megapixels. It is clear that the 100 MP one contains much more information than the 10 MP one. But if you pixel peep both of them at 100%, then on your monitor it might seem as though the 10 MP one is "sharper" than the 100 MP one. Likewise, a slightly noisy 100 MP photo could be downsampled to 50 MP and the noise would be gone while remaining superior to a 10 MP photo in every way. At present, due to misunderstandings arising from viewing each photo at 100%, it would seem that a downsampled 50 MP image would have a much greater chance of succeeding at FPC than the original 100 MP image. There is a clause in the guidelines that says that images should not be downsampled, but it is missing the detailed technical explanation that would solve such a misunderstanding. I suggest that we add a clear paragraph explaining this phenomenon.

I hope this makes sense! dllu (t,c) 18:06, 4 June 2024 (UTC)

Good points. Some thoughts and how I handle it:

• I agree that 2 MP is quite low. I usually accept pictures with not much more than 2 MP if they are otherwise perfect and razor-sharp. But if a picture is slightly blurred though it only has 2.5 MP, I decline it. Which is related to your second point:
• If the picture is slightly blurred but has 40 MP, and at 8 MP it is perfectly sharp, this is probably ok. However, as QI is mostly about taking technically 'correct' pictures, I still honor failures. Say, a picture has wrong focus. The subject is the tree, but the photographer focused on the mountain in the background. At 100 MP the mountain is razor-sharp but the tree is blurry. Downscaled to 8 MP you don't see the difference and both, the mountain and the tree, appear equally sharp. In that case I would still deny the QI status because it's a defect.

Plozessor (talk) 18:58, 4 June 2024 (UTC)

Agree with both of you; especially that people often do wrong to good photos when they judge sharpness, noise, CAs etc. at 100% without considering the resolution – dllu has explained this perfectly. If people want to enforce our policies (see other discussions on this page), I would happily support to change the general minimum requirement from 2 megapixels to at least 4 megapixels. It would also make sense to suggest ~ 12 megapixels for most static subjects, especially landscape and architecture photography. Most cameras for stills photography support at least 20–26 megapixels these days, so even after strong perspective correction and some cropping we should still have ~ 12 megapixels. To avoid injustice in very special cases, we should add to the QI rules the hint that these requirements can be suspended if the nominator gives a good, clear explanation why a photo was so difficult to take that it deserves to be a QI despite a resolution below ~ 12 megapixels. This should be a rarely used exception, of course. – Aristeas (talk) 14:52, 5 September 2025 (UTC)

Update regarding captions and descriptions

Hello dear Commoners, QI and FP enthusiasts,

Inspired by this QI review, I would like to propose we update the image page requirements: Any caption given to an image is automatically displayed as the image description in the template, unless a description is also given. While the current image guidelines demand a description, they don't require a caption. This seems utterly outdated to me. Thus, i would like to know your thoughts on these:

• Proposal A (my preferred choice): Item 2.2 of the image page requirements is changed to: “have a meaningful file name, be properly categorized and have an accurate caption on the file information in one or more languages. (See Commons:Language policy too.)”
• Proposal B: Item 2.2 of the image page requirements is changed to: “have a meaningful file name, be properly categorized and have either an accurate caption on the structured file information OR an accurate description on the file page in one or more languages. (See Commons:Language policy too.)”

What are your thoughts on this?

@Peulle, Alexander-93, Smial, Plozessor, Tournasol7, Benjism89, Carsten Steger, Mike1979 Russia, Ermell, Poco a poco, Jacek Halicki, XRay, Famberhorst, Красный, Jakubhal, Agnes Monkelbaan, Syntaxys, Terragio67, E bailey, Bgag, Lmbuga, Crisco 1492, Екатерина Борисова, Mike Peel, Phyrexian, Rodrigo.Argenton, Sebring12Hrs, Sandro Halank, আফতাবুজ্জামান, George Chernilevsky, Heylenny, Rangan Datta Wiki, Lvova, Tagooty, Rohit14400, Spurzem, Julesvernex2, FlocciNivis, Milseburg, Anna.Massini, TheBritinator, Igor123121, TTTNIS, Stephan Sprinz, Cvmontuy, Atudu, Gzen92, Tisha Mukherjee, Gnoeee, and Another Believer: @Panpanchik, ReneeWrites, Rhododendrites, Der Wolf im Wald, Manojk, Pangalau, Pierre André Leclercq, ZI Jony, Aboubacarkhoraa, A S M Jobaer, Acroterion, GoldenArtists, Юрий Д.К., Iketsi, Berthold Werner, Herpking, Petro Stelte, Robert Flogaus-Faust, Frank Schulenburg, JoachimKohler-HB, Ktkvtsh, Jamshid Nurkulov, Romzig, Dr. Thomas Liptak, Michielverbeek, Romainbehar, Alexis Lours, Pdanese, TOUMOU, Aethonatic, Bwag, D-Kuru, GiovanniPen, Imehling, ROCKY, Tigerente, WMrapids, Basile Morin, AuHaidhausen, GRDN711, KaiBorgeest, Kallerna, PantheraLeo1359531, Perituss, Shougissime, JayCubby, The Cosmonaut, Kiril Simeonovski, Wolverine X-eye, and MZaplotnik: @UnpetitproleX, Charlesjsharp, -donald-, Radomianin, Yann, Uoaei1, Llez, Aristeas, Cmao20, Mohammed Qays, MisawaSakura, Ezarate, and Giles Laurent: (Tried to ping everyone, who has been active on QIC or FPC recently. If I forgot someone, feel free to ping them too.) MB-one (talk) 08:10, 5 September 2025 (UTC)

You are mistaken, requirement of file descriptions is by no means "utterly outdated". Commons is for educational images. They typically must be accompanied by comprehensive descriptions. I wouldn't want the project to degrade by replacing normal full-fledged descriptions with some kind of scraps. Sneeuwschaap (talk) 09:37, 5 September 2025 (UTC)

One of the key components of information in our metadata on the file page is the description (and thus required), while the caption is not a key component. Sure we can think of displaying a caption in the description field when none is provided, and sure it would be good if more captions are added, but hell no this is not "utterly outdated".

What we are dealing with (regarding the captions of files) on Commons for years is a half baked product, not integrated in the infrastructure at all and just dumped on top of the file pages, and not thought trough. Both proposals here do not make the situation on Commons better, earlier worse, as all files have a description and many many files don't have a caption. Romaine (talk) 11:15, 5 September 2025 (UTC)

PS: A proper description is needed to have a good understanding of what is depicted and its context. One place where these file pages are used and seen are the various other wikis. Viewing a file page in another wiki, the captions (and other structured data) aren't visible at all. Having only a caption and no description, means there that there is nothing descriptive at all. Romaine (talk) 11:30, 5 September 2025 (UTC)

@Romaine @Sneeuwschaap,

Thank you for your input. Do you have another proposal, that would make the situation better? MB-one (talk) 11:32, 5 September 2025 (UTC)

Structured data including the captions is, as I already said a half baked product, which is top down implemented without thinking fully through. Software created far away from the Commons community, and then implemented without taking proper care of a proper implementation. If there is a genuine interest from the developing team in getting to know the issues, willingness to listen to the community, and prepared to actually solve the issues, then sure I am happy to help out, but at this moment I don't see it and I don't want to waste my time on things that won't be used. The description section with the information template is stable, the structured data section is crappy software. Something simple like removing wrong coordinates from the structured data often results in that it refuses me to even save it. Not to mention with the further lack of integration of it, including something simple as the depicts field. Both proposals are not making the situation better, but make it worse. Romaine (talk) 11:55, 5 September 2025 (UTC)

• First of all, I wonder how many of these people actually got the 'ping'. The template says that it should work for up to 50 people, but in reality it usually malfunctions for more than 5. It would be better to leave a link to this discussion on the FPC talk page.

Having said that, I don't think Captions should be a part of the required thing in the Image Guidelines, until the Structured data is fully developed and integrated into what people actually do with their images. It's hard enough to get people to leave even the bare minimum of info on the file pages for QIC and FPC. People have become too used to just upload and "like" photos online. I have tried drives to get nominators and voters to actually follow the IG rules, but I've more or less given up on it. I've often thought about proposing to skip all rules all together on FPC, since neither nominators or voters on FPC seems to care about them anyway. What's the use of rules when no one follows them?

Structured data should also be more integrated into what people are used to anyway. The 'depicts' value on a file page is essentially the same as 'tags' but connected to specific topics on Wikidata. People are familiar with tags since most other sites use them, they could be integrated into to Structured data system in a better way and used there. That would be a great help for Commons since a lot of photos keep 'tags' embedded in their exif. So since Structured data isn't fully functional, it shouldn't be required. --Cart (talk) 11:27, 5 September 2025 (UTC)

• Please don’t require ‘Captions’. If necessary I can elaborate on this, writing twelve volumes or so about The Decline and Fall of the Wiki Empire due to well-meaning, but badly implemented tools, policies, and requirements. But maybe this is enough for now.
  1. As long as many people are not even using proper, somewhat descriptive filenames for the media they upload to Commons, it does not help the project to require a ‘Caption’. The people who use proper filenames will also add a useful full description; the people who do not even use useful filenames will also not add a useful caption, but just type in (as I often see) nonsense like “Fish” or “Eiffel Tower” (without indicating the part, the point of view, the year, etc.).
  2. I would happily use the ‘Caption’ feature myself for my own photos if it would support a minimal subset of formatting; I need (i) links to Wikipedia articles and (ii) italics. Requiring plain text w/o links and minimal formatting seems utterly outdated to me. I mean this is not a typewriter, is it? (And even on a typewriter we encoded italics with the help of underlining.)
  3. There are general problems with Structured data including the captions, as explained by Romaine above. The idea of Wikidata is great, the idea of Structured Data is great, but the implementation of the Structured data is overcomplex; this makes it hard to understand, hard to maintain, prone to failures. Please take a look at the HTML text of a typical ‘File:’ page on Commons and see how the Structured data are embedded there. I was flabbergasted when I first saw that. No wonder that editing Structured data claims sometimes fails with some browsers (not long ago, editing the ‘Point of view’, P1259, failed with Firefox and all related browsers). We could represent the same amount of information in a much simpler way, both with a simpler data format and a simpler interface.
  4. This also applies to the relatively simple field of ‘Captions’. I have seen many many damaged and nonsensical captions on Featured pictures, sometimes probably due to vandalism, but often probably just because users misunderstood the interface and unintentionally damaged the data. When people want to add a caption in another language, they often click on the language pop-up menu to the left of an existing caption, and if they still don’t realize what they are doing and save the result, they have not added a new caption in a new language, but changed the language of the existing caption or deleted the existing caption. This means they unintentionally vandalize the existing captions without even knowing that. We could completely avoid this by using a simpler, more intuitive user interface for the captions. This is a typical problem of the implementation of Structured data and their user interface on Commons: overcomplex, confusing, and therefore prone to failure.
  5. If you see a contradiction between item 2 (my wish for some minimal formatting) and items 3, 4 (claim of overcomplexity), I can also put it the other way around. Given that the ‘Captions’ are just primitive plain text strings, it is astonishing that the data structure and the user interface for editing them are so complex. That’s a disproportion of expenditure and results.

So if we think it helps the project to enforce requirements, we should discuss how we can get people to use (i) better filenames and (ii) at least the most basic topical categories for their filenames. As long as not even these things work well, it will not help to add more requirements – which will not be met, too. No offence, just my 50 cent. – Aristeas (talk) 13:19, 5 September 2025 (UTC)

Per others, we're lucky to get proper filenames and descriptions, let's not get into captions. -- Plozessor (talk) 16:24, 5 September 2025 (UTC)

• I fully agree with the previous comments. I always try to fill in as many fields as possible in a meaningful way - descriptions in multiple languages, links, depicts, or location information. Doing all of this manually is time-consuming, as I don't use any additional tools. Structured data is useful, but maintaining it for each file requires a lot of effort. Proper categorization, on the other hand, is extremely valuable and indispensable. Meaningful filenames are even more important, as they make files easy to find through full-text search. In short, I completely agree that the main focus should be on providing meaningful filenames. Filling in all the other fields is certainly helpful, but with the current implementation, it remains a demanding task. Kind regards, -- Radomianin (talk) 21:15, 9 September 2025 (UTC)

I strongly dislike Captions and hope they will not be a requirement. I believe that we need less handworking on Commons, not more. imho the best way for improving the Commons' search is some AI search, and the way of teaching the model is not Captions. Анастасия Львова^ru/en 21:45, 5 October 2025 (UTC)

• disagree with Captions being complusory. Currently the Commons App uses captions as the file name, where as the description field is where you can expand on the file information. Mobile contribution are now more common than desk top/laptop contributions where the two options are open to the uploader. This current practice of captions being the filename also runs through many of the event specific tools as well, we seriously dont need paragraph sized filenames. What we need to do is keep filenames as simple as possible as the Commons and its underlying Wikimedia software is not being supported by the WMF. Any change to requirements should at least held over until after the WMF makes its decisions on the future of Commons and what they will support. Gnangarra 12:45, 6 October 2025 (UTC)

Hi @ all, From my perspective, this discussion makes clear that the majority here sees captions (in SDC) as insufficiently integrated and potentially fragile, while still valuing robust, multilingual descriptions, meaningful filenames, and solid categorization. Several voices warn that requiring captions now could worsen workflows, especially given current UI issues, cross-wiki visibility gaps, and the reality that many uploads already struggle to meet the basics. At the same time, the information template currently displays the caption when no description is provided, and in my view that automatically displayed caption/description should satisfy the Image Guidelines’ “description” requirement for QI evaluations. Concerns about browser/app reliability and SDC editing pitfalls are real, and I acknowledge the need to avoid degrading the quality or usability of metadata across wikis. Proposed non-partisan resolution:

• Keep descriptions required; do not require captions yet.
• Clarify in the Image Guidelines that an automatically displayed caption in the description field counts as a valid description for QI, provided it is accurate and meaningful.
• Adress the PTAC Unsupported Tools Working Group to review and improve SDC integration (captions UI/behavior, cross-wiki visibility, reliability), and revisit caption requirements only after those fixes are demonstrably in place.

Can we agree on these steps? Cheers, MB-one (talk) 14:05, 6 October 2025 (UTC)

Go ahead, make as many new rules as you like. People will continue to ignore them, just like they usually do. I've tried every trick in the book to make voters and photographers follow the rules we already have. To no avail. I've given up. --Cart (talk) 16:06, 6 October 2025 (UTC)

I think, the discussion has shown exhaustively, that the community does not want to create new rules under the current circumstances. But at least clarifying the current guidelines could increase compliance with the guidelines. MB-one (talk) 17:32, 6 October 2025 (UTC)

You are making the assumption that people actually read the guidelines, when multiple comments from seasoned and new nominators at FPC, show that at best people briefly scan the text on COM:QIC or COM:FPC, but don't make it to the COM:IG since that requires them to click on a link on the pages. The only way to make sure people follow the IG, would be to have some sort of AI-interactive form to fill in where the AI doesn't allow you to make the nom unless all the rules and criteria are met. (Preferably with a computer-generated voice saying: "I'm sorry, Dave, I'm afraid I can't do that.", when they try to force the nom without the right info filled in on the file page.) - But I guess we're a long way from that yet. --Cart (talk) 18:31, 6 October 2025 (UTC)

I'm not assuming, that all users actually read the guidelines. But I have good reason to believe, that at least some users do read them (I'm one of them, but most likely not the only one). And since discussions about about interpretation of the guidelines exist, it seems prudent to add clarification to them, even if only some users actually read them. Side-note: IMO it's completely ok, to call out users on CR who vote in clear conflict with existing IG and possibly even strike their vote. MB-one (talk) 20:34, 6 October 2025 (UTC)

Calling out voters and photographers who don't follow the rules - Been there done that. That's how you make enemies among users here. You have no idea! --Cart (talk) 20:57, 6 October 2025 (UTC)

We seem to be getting a bit off-topic here. But I gather, you don't necessarily oppose the push for clarification, correct? MB-one (talk) 07:21, 7 October 2025 (UTC)

I don't see how any of the two proposals above are actually clarifying anything, so I'd leave the rules be as they are now. But, since so few people read or take notice of this anyway, you can pretty much do what you like with this page. --Cart (talk) 11:28, 7 October 2025 (UTC)

I disagree in part. I do not understand why the image guidelines need to be changed. There should be a meaningful description. Why should anyone care whether this description is a copy of a caption? Clarification is not needed IMO. --Robert Flogaus-Faust (talk) 16:31, 6 October 2025 (UTC)

Thank you for the question. Apparently, you and I agree on what that guideline already means. However, there are users (at least one), who demand a description text written on the file page. That's why I'm seeking to clarify, not change, the section of the guidelines. MB-one (talk) 17:29, 6 October 2025 (UTC)

Thanks for your answer, but I still disagree. There should be a description, not just a caption and certainly not some kind of warning that the description is missing. However, with your caption I would not complain about the missing description (or only if I do not read the caption). I would just copy the caption into the description, just as you did. The upload wizard offers this as a standard, by the way. In a similar manner, I just add missing species categories for plants or animals if I can find all the necessary information on the image page. This is a wiki. --Robert Flogaus-Faust (talk) 23:52, 6 October 2025 (UTC)