Open main menu

Commons talk:Image guidelines

Quality MediaEdit

I've added subsections related to different kinds of images than photography. I think similar set of guidelines as for digiatal photography could be developed.

Reasones: QI would be even more useful for vector maps & like. Such media are received at Featured Picutes with very mixed feelings

  • first group: it's just a map, there is nothing visually pleasing about it -> mostly oppose
  • second group: oh, to create that must have taken so much work... -> mostly support
  • sometimes, there are critical and enlightened comments about quality of drawing, cartography, etc. -> lost in the crowd, result is usualy determined by relative power of first 2 groups

Maybe, concept of QI could be extended to any media con Commons ... maybe, rename to Quality Media? --Wikimol 22:02, 1 July 2006 (UTC)

I support this proposal. Ben Aveling 00:07, 2 September 2007 (UTC)

Optical IllusionEdit

IMO the image in paragraph „Computer Contrast“ could cause an optical illusion. At the first and also the seccond sight I saw no fourth circle. But the more I looked at the image the more a fourth circle appeared at the left side. It was in the same shade of grey like its right neighbour. --Eva K. Message 09:36, 26 July 2006 (UTC)

I think this test doesn't fulfill its purpose when viewed as a thumbnail. The problem is the contrast against the white background which is too high for my eye. Others seem to have the same problem. If your eye is adapted to the bright white background it doesn't see the fine shadows of black. It works if you have a look at the test image full screen with a black background. --Ikiwaner 06:30, 12 February 2007 (UTC)

More Background
Maybe this here would solve the problem? --Rubik-wuerfel 22:00, 3 April 2007 (UTC)

Metadata criteriaEdit

Unless there is some objection, I'm planning on writing some requirement for quality metadata to the quality image guidelines. In order to make our images accessible they should clearly identify the copyright holder, the subject (with geocoding where applicable), the equipment used (ideally via exif), and the images should be placed in categories/galleries where applicable. I believe this should be part of the quality process because, like the technical aspects of the image itself, requires the help of the photographer. --Gmaxwell 19:18, 11 February 2007 (UTC)

A requirement for exif data is problematic in terms of privacy. EXIF contains your camera name, model and serial number. There can be your real name too. Many editing programs put their infos in as well. This data can be crawled by search engines of Camera manufacturers. This is not what I want. If somebody had not bought editing software this might cause troubles for him. Thats why I recommend to delete EXIF information before uploading. Requirement for categories is good. --Ikiwaner 06:26, 12 February 2007 (UTC)
I probably should have proposed language... what I would have written is asking for EXIF or at least the primary data about the image (shutter speed, camera type, ISO, aperture, focal length.. or that it's a pano/composit). I very much do think we should have photographers specify what equipment they used, we should encourage it if not demanding it.
Perhaps we should approach this by setting up a general metadata recommendation page, and then putting in the quality criteria that the image must generally follow the metadata recommendations.
I'm well aware of the privacy implications, especially since my camera is configured to store my phone number in my exif (to improve the chances of recovering my camera if it is stolen). All my images are run through the following script:
exiftool -ThumbnailImage= -ICC_Profile:All= -CreatorTool= -Software= -Photoshop:All= -xmp:All= -CopyrightFlag=True -ColorSpace=sRGB -IPTC:All= -MakerNotes:All= -MIE:All= $1
exiftool -XMP-dc:Creator='Gregory Maxwell' -XMP-dex:LicenseType='open source' -CreatorContactInfoCiEmailWork='' -Owner='Gregory Maxwell' -UsageTerms='Use only with attached copyleft license grant.' -CopyrightFlag=True -Copyright='2006 by Gregory Maxwell ( Distribution only permitted with accompanying license grant.' $1
This tool is a good idea. I had to delete all EXIF information till now. Is it a lossless transformation? It would be a nice feature to me to automatically remove exif info after uploading except those closely related to the picture. --Ikiwaner 18:27, 12 February 2007 (UTC)
I support the idea of Exif data relating to the photograph being a recommended part of all images, and as I noted elsewhere adding a note if the image is a composit (or otherwise significantly edited) would be useful. --Tony Wills 00:50, 1 March 2007 (UTC)
I advocate judging images as images, not according to external criteria such as EXIF, geocoding, categorization, genus and species, statements about equipment, settings, composites, and all the other things people want to add. The only external criterion we should use is licensing, and any license acceptable to Commons should be fine. We should not require any additional information. Fg2 10:17, 1 March 2007 (UTC)
I don't agree. Part of point of the QI process is to help encourage our contributors to produce the best possible illustrations. By having requirements about things like resolution, noise, and distortions we encourage people to do well on points that they otherwise wouldn't. All the metadata factors make our images more useful, many of them are easy to add by the author but hard/impossible to add by anyone else, and many are currently forgotten. They are all pretty easy for the author to add, so why not suggest them? --Gmaxwell 01:00, 13 May 2007 (UTC)

Guidelines on PanoramasEdit

Hello, I wonder how to expand on the panorama side (I'd like to contribute time permitting). Simple errors like bad alignment or ghosts at a blurred seam line tend to be less common now, parallax errors can still persist, but now more intricate quality problems occur. Two recent examples:

Ciemniak panorama.jpg

Possibly photos were taken with the camera panorama mode, but unless one fixes the exposure to the brightest part of the view, one risks blown highlights. Hugin is currently implementing exposure correction, maybe in future taking photos each individually exposed will avoid this intensity clipping. I see the problem mainly on the camera side, i.e. on my Canon I cannot set underexposure in panorama mode.

Tatra Mountains Panorama 01.jpg

Blending programmes like enblend have done away with seam lines and smoothened structure at feathered overblending, but by design they do not correct lense vignetting. Good stitching programmes incorporate vignetting correction, one also can preprocess images which is more cumbersome, one should make people aware. See in the photo above how the sky brightness changes.

Getting a good panorama ready can take some time, with suitable guidelines people could avoid pitfalls when creating them. What do you think, how and where would be a good location to point out panorama-specific mistakes? (and actually what to do for a good panorama) -- Klaus with K 16:51, 23 June 2007 (UTC)

Here is good, I'll add what you've written, if you can check it for me? Thanks, Ben Aveling 23:42, 23 June 2007 (UTC)

I'll add two photos of mine, with vignetting and with vignetting mostly corrected away. May write some better blurp later. Is this photo pair a suitable illustration (it is a real life example)?

Mostly in the sky one notices three bright areas from left ot right separated by two darker bands. These correspond to the middle and the sides/corners of the three original images.

Although programmes like enblend do remove visible seam lines, they do remove vignetting effects. For instance in the sequence hugin-enblend it is the hugin input (or within a recent hugin version) where vignetting has to be corrected. -- Klaus with K 12:50, 24 June 2007 (UTC)

Further illustrations of some more basic stitching errors:

The ingredient photos were taken with a camera not in panorama mode, and some camera-bundled software was used for the top stitch. One notices that the left part is darker, that is due to the camera exposing each photo individually and could be dealt with adjusing brightness before the stitching.

More sublte errors are at the right of the castle, where there appear to be two more vertical bands in the sky. Look are where these bands touch the hill, at the middle one the stitching programme misaligned producing a ghost. Also the programme feathers the transitions, while this avoids a visible edge one can notice that in such feathering region the image noise is reduced, which makes these parts stand out from the rest of the image.

The bottom image shows that using a different software the photos can be stitched without such errors. -- Klaus with K 17:19, 25 June 2007 (UTC)

For the stitch left the photographer captured the bottom part of the church, then stepped left and took a photo of the top part. The seam line is visible in the windows just below the clock, and one sees shifts in different directions in the middle and on the tower structures. Stitching software is not meant to cope with such parallax error as the problem here is located behind the camera, and the way out in this case was the availability of matching photos, albeit from a different perspective, to create the image on the right. -- Klaus with K 17:42, 25 June 2007 (UTC)

Some software provides blending algorithms that make the seamline invisible. But if the brightness of the original photos differs significantly, one still notices a transition in between photos. A few minor misalignments notwithstandig, this is what the top photo shows.

Some programs incorporate brightness adjustment for the photos, but the algorithm has to be designed carefully otherwise one can end up with posterisation effects like the purple and light blue patches in the clouds on the left in the bottom image. -- Klaus with K 18:19, 25 June 2007 (UTC)

Proper alignment of images is a crucial first step and has been achieved in this view taken in the Western Scottish Highlands. But the exposure differs between images and cameras have vignetting, both make seamlines visible. And as these photo have been aligned regarding the distant features, some parallax errors can be seen at seamlines in the foreground. There exists software that makes such seams disappear, the parallax error visibility can be reduced by choosing a suitable seamline. -- Klaus with K 18:47, 25 June 2007 (UTC)

Is it appropriate to name open-source software like hugin and enblend, and new features that are just being implemented in the most recent releases, i.e. brightness and vignetting correction in hugin and a seamline finding algorithm in enblend? -- Klaus with K 18:47, 25 June 2007 (UTC)

I think so. If there is a best tool for the job, we should mention it. Regards, Ben Aveling 23:27, 1 September 2007 (UTC)
It took a while to get around to doing it, but I've copied your stuff to the main page. Can you please review it? And if you have more to say, do please add it directly to the main page. Don't worry if your English isn't perfect. Either I or someone else will fix it, eventually. Regards, Ben

Geodata recommendation?Edit

I was wondering whether the time has come for stating that geodata are recommended or perhaps even required for certain types of photos such as plants, animals, buildings, landscapes, and so on? I have noticed that an increasing number of users find that geodata adds quality to these images and recommend nominating users to add geodata in order to get a supporting vote or turn a hesitant vote to a promoting one. I am in the process of adding geodata where relevant to all of my own contributions and I find it facinating to see the images pop up in, e.g., Google Earth in the right places after enbaling a Commons layer. I guess over time the uses of the geodata will be expanded to area which I cannot even image - especially if a large fraction of the good images has geodata. The downside is that the hill to climb for an image to get QI status increases. Any other opinions on this? -- Slaunger 02:42, 14 August 2007 (UTC)

Is there any easy way to get geo-data without owning a GPS? Ben Aveling 00:06, 2 September 2007 (UTC)
A recommendation is certainly a good idea. For fixed objects like buildings, landmarks, and landscapes definitely a good idea, and googlemaps etc can be used to get a pretty good GPS location accuracy (this is how I locate my GPS coords) but note I specify the location of the subject, rather than the location of the photographer as obtained from a GPS equipped camera (does it matter, should we suggest a standard?). For animals and plants and other moveable objects I don't see much point unless either 1) The individual is identifiable (eg a banded/ringed bird) where someone might want to know where it had been spotted for tracking purposes (but note just being 'ringed' is not enough, you must be able to read the id from the photo, eg coloured bands), or 2) The object is rare, and so the occurrence of one may be significant. Significant trees fall into the 'landmark' category and should have location data. --Tony Wills 06:24, 2 September 2007 (UTC)
Concerning Ben's question on how to obtain geo-data without GPS, I suggest looking into Commons:Geocoding for some advise. Personally, I have installed the Ald-Hjl-Koord-en.kmz geotagging tool in Google Earth. I then have Google Earth running while entering the upload descriptions. A cross-hair can be placed over the location where the photograph was taken and then activated. This brings up a {{Location}} line which can be copied and pasted directly into the file upload. Then I add additional parameters such as the heading, region and sometimes type, when relevant. Especially the heading can be very useful. For instance, in Google Earth all geocoded images from Wikimedia Commons can be displayed as Wikimedia icons by installing GeoCommons.kml. Here the heading parameter is used to rotate the Wikimedia icon such that it points to the subject. Very nice if you have like a series of images of a mountain taken from different locations - or images taken from a mountain in different directions. To get these visual things right it is my opinion that the location of the photographer shall be located, not the subject, quite opposite to the practise mentioned by Tony. Actually, locating the photographer is how it is normally done in a Geocoded photograph. IMO the location of the subject shall be given on the article/gallery page for the subject itself if such an article exists. The individual photographs in the gallery will then contain the individual locations the same subject is photographed from. Concerning plants and animals of known species I find it relevant in almost all cases to add the location - also if it is very common in some areas. The location data can in principle be used in the future to generate dynamic maps of the area of distribution of a species. I think this is very usefull. One caveat is, I guess, protected species where you do not want to be too precise in the geodata as it could provide cynical trophee hunters with information with which he could go out and remove, e.g., rare plants from a very well specified location. I think the location should still be there, but in such an inaccurate form that it is unlikely to help trophee hunters into collecting protected species. --Slaunger 22:04, 2 September 2007 (UTC)
I use this javascript plugin (converts Google Maps links to {{Location}} and inserts it automatically. Please note that the current policy is to geocode camera location (and heading). --Dschwen 10:59, 3 September 2007 (UTC)

Resolution argumentsEdit

What about mentioning as a further reason for uploading pictures at the highest available resolution the fact that a Commons image will not always be used in its entirety? There are legitimate uses that involve cropping a small portion of what was originally a full picture. Luis Dantas 23:28, 28 October 2007 (UTC)

About perspective correctionEdit

Figure 1
Figure 2
Figure 3

I was thinking that it might be good to make it a requirement for new QIs and FPs to mention any perspective correction that was applied in the image description, and more importantly what method was used. The reason is the following:

There are basically two methods of perspective correction:

  • With the "perspective tool" in Gimp or similar programs: works reasonably well for the correction of "falling lines", but doesn't take foreshortening into account.
  • With Hugin or similar programs: full perspective correction, yields the correct proportions as if the image had been taken keeping the camera axis horizontal.

The difference between the two can be quite dramatic if the deviation from the horizontal direction is large. For example, in figure 1 the camera was at an angle of almost 45 degrees. In figure 2, the convergent lines have been made parallel, but foreshortening has not been compensated (clock is egg-shaped). The fully corrected image (figure 3 bottom right) looks quite different and is proportionally correct (clock is round).

Partial correction can mislead people into thinking that the image reflects the actual geometry of an architectural object. I think we should let people know when this is not the case.

(Personally I'm not fond of partial perspective correction, but it seems that opinions diverge on this matter.) --Stefan Vladuck 16:51, 7 May 2008 (UTC)

I'm against such prescriptions, photography is not only technical documentation. --Mbdortmund 21:27, 7 May 2008 (UTC)

Of course not, but Wikimedia Commons has an educational purpose, it's not a primarily artistic community like, say, deviantart or onexposure. What does it cost you to write "perspective corrected with ..." on the image page? The more accurate the image description, the more useful the image. And for architecture (among others) it's certainly useful to know if the image matches the actual object or not. --Stefan Vladuck 21:46, 7 May 2008 (UTC)
Foreshortening is irrelevant in your examples, the odd shape of the clock can be corrected by applying rotation and shear. --Dschwen 22:02, 7 May 2008 (UTC)
There are certainly many ways to correct the odd shape (which by the way is due to foreshortening). What I'm trying to say is that when it is not corrected, like in figure 2, we should tell people. After all, on most pictures there is no clock that will make it evident that the proportions are distorted. --Stefan Vladuck 22:16, 7 May 2008 (UTC)
I agree, and I like your example, which I find instructive. I do beleive it is worth mentioning this somewhere on Commons. -- Slaunger 22:23, 7 May 2008 (UTC)
Yes we should tell people. But I'm still not convinced about your example. The spatial angle under which we see the clock is so small that foreshortening must be completely irrelevant. --Dschwen 22:54, 7 May 2008 (UTC)
The angle of the camera with respect to the horizontal plane was about 43° (as computed with Hugin), which is anything but irrelevant. Besides, the image in figure 1 is straight from the camera, and since it was taken with a rectilinear lens, I don't think the distortion can be attributed to anything but foreshortening... --Stefan Vladuck 23:04, 7 May 2008 (UTC)
Sorry I didnt make myself clear enough. The spatial angle means not the angle from the plane, but the angular difference between opposing sides of the clock face. --Dschwen 03:24, 8 May 2008 (UTC)
But it's the angle from the plane that causes the foreshortening. If you take a photo with the axis of the camera perpendicular to the clock face, the clock will look round. The larger the angle between the camera axis and the perpendicular direction, the more "squashed" the clock gets. As you approach 90°, the clock shrinks to a line, no matter how close or far you are. --Stefan Vladuck 07:08, 8 May 2008 (UTC)
No, it is not. You linked to the wikiarticle yourself! Foreshortening is due to to a difference in distance of opposing points on the object with respect to the viewer (with farther portions looing smaller than closer portions). For the small clock the distance from the viewer/camera to the top of the clockface and the bottom of the clockface will be almost identical. The clock shrinking to a line at 90° has nothing to do with foreshortening, that would happen in an isometric perspective world as well. --Dschwen 12:39, 8 May 2008 (UTC)
Maybe I'm overlooking something, but I can't find any support for your interpretation in the wiki-article. I read: "Foreshortening refers to the visual effect or optical illusion that an object or distance is shorter than it actually is because it is angled toward the viewer" (emphasis mine). Also, "foreshortening can occur in other types of non-perspective drawing representations (such as oblique parallel projection)." Maybe you are referring to a different article?
As for the isometric projection you refer to, well... "It is a method of visually representing three-dimensional objects in two dimensions, in which the three coordinate axes appear equally foreshortened"... --Stefan Vladuck 13:16, 8 May 2008 (UTC)
I agree that the article could be writte clearer ;-). Check out Image:Perspective-foreshortening.svg. Isometric projection has no foreshortening. What you are referring to can be corrected with the Gimp. Take a face of cube A in the example image, Gimp can distort it correctly into a square. This won't work with cube B due to foreshortening, you will get a square, but the contents of the square will remain distorted as more pixels per real area are used in the parts of the face closer to the camera. --Dschwen 14:26, 8 May 2008 (UTC)
Apparently there is some disagreement about the meaning of words. But it seems that at least we agree that distances do appear shorter when viewed at an angle.
As for the correction with Gimp, you are mistaken. Try it for yourself (I did): use the "perspective tool" (not the "shear tool") to adjust one of the sides of cube "B" to a square. Each of the two halves will be of the exact same size.
However this works only because you know beforehand that the shape is supposed to be a square. If you don't know a priori the proportions of the object you are adjusting, there is no way to get the correct height/width ratio. In fact, you could adjust the church tower from figure 1 properly with Gimp simply by rescaling the height/width until the clock is round. But if you have no reference from which to determine the correct ratio (like a clock which you know to be round), there is no way to do proper perspective correction with Gimp. This is why I think users should know in such cases that the height/width ratio of the image might not match the real object. --Stefan Vladuck 15:18, 8 May 2008 (UTC)
Sometimes I wish there was a magic button I could press to make people just believe that I'm right. The usual way is just so exhausting ;-). Check this image of a perspective construction note that the left face consists of two squares. Foreshortening makes The front edge longer than the back edge, which is no problem for a correction in Gimp. 'But foreshortening also makes the top edge of the front square in the left face seem longer than the top edge of the rear square, and Gimp can not correct for that. Please note that it is the ratio of edge lengths depends on the angular difference we are viewing them (as well as the absolute angle), but for small angular differences the effect is negligeble (just like in the clock face above. --Dschwen 18:51, 8 May 2008 (UTC)

File:Vladuck GIMP perspective demo.png

I respectfully disagree with your statement. --Stefan Vladuck 20:37, 8 May 2008 (UTC)

Wow, you must have a better version of Gimp! Well, then the whole thing is solved. You just proved that your advanced Gimp version can in fact correct foreshortening. This is great! Fortunately this makes your proposal obsolete. --Dschwen 21:13, 8 May 2008 (UTC)
I just tried it myself. Amazing! I only used that gimp tool to perform slight perspective corrections so far and I never noticed the full foreshortening correction! This makes it equivalent to using hugin as a perspective correction tool. --Dschwen 21:17, 8 May 2008 (UTC)
No it is not equivalent to Hugin because you can't determine the right height/width ratio unless you know it beforehand! If you did not already know beforehand that the face is made up of two squares, you could not know how to pull it apart to get the right height/width proportion. Same thing with the tower: how would you determine the right proportions if you didn't have the clock as a reference (of which you already know that it is supposed to turn out round)? It's not possible. Hugin will give you the right height/width ratio (if it is fed the right lens data, e.g. via EXIF), but GIMP can't do that. That's the difference between the two methods, and this difference can be very relevant for people interested in architectural objects. --Stefan Vladuck 21:28, 8 May 2008 (UTC)
Ahhhhhhh! That's what you mean by foreshortening! Well, yes, you are right. That difference exists, I agree with you. Sorry, but Figure 3 above confused me. In essence: with Gimp you need a reference to keep the aspect-ratio of the picture correct. --Dschwen 21:48, 8 May 2008 (UTC)
Exactly. It's remarkable how we've managed to spend thousands of words to come to this simple conclusion. :-) --Stefan Vladuck 22:12, 8 May 2008 (UTC)

To go back to the original question: I'm against this new rule. Not that accurate PC is not desired (almost all my images are corrected in Hugin). But it leads to the absurde situation that if the perspective correction method is not known images out of compact cameras with no PC are favoured. And what about PC by cropping? If you take a wide angle lens and crop the lower part this "true" perspective correction. Would you really like to tag all cropped images?

I think it's better just to write "we do not recommend software perspective correction with GIMP and Photoshop" in our guidelines. --Ikiwaner 10:38, 12 May 2008 (UTC)

Well, I would not consider cropping a "correction", because the uncropped image already has the correct perspective; you do the cropping to get rid of the unneeded parts of the image, not to fix a distorted perspective.
At any rate, I agree with your suggested recommendation. But how about also recommending (rather than requiring) to add info about perspective correction (just a short indication like "perspective corrected with Hugin/GIMP/a sledgehammer")? We won't convince everybody to do proper perspective correction, so I think it might still be a good idea to encourage (if not to require) uploaders to identify the methods they used. --Stefan Vladuck 11:03, 12 May 2008 (UTC)
Yeah, make it a suggestion, and let's make a page with verbose explanations why specifying the PC method is indeed a good idea (and link to it). --Dschwen 14:51, 12 May 2008 (UTC)
Yes, I had actually the same idea. I guess I'll start working on it next week if no-one beats me to it. --Stefan Vladuck 07:02, 13 May 2008 (UTC)
Thanks in advance for your work. And keep in mind the added value of that site is to prevent people from using an incorrect method as described above. It should not lead to a situation where untagged images are discriminated.
Another thing for Stefan: If cropping is no perspective correction what about using the PC-E 24 mm lens shifted...? --Ikiwaner 18:40, 13 May 2008 (UTC)

I think perspective correction should not be applied at all since it is misleading and badly done in most instances I’ve seen here. Unless you use a PC-Lens when taking the picture. Photography is never about reproducing reality to the extend of a CAD-Drawing. Nubero (talk) 22:47, 12 May 2015 (UTC)

I agree that perspective correction is undesirable, and do not feel it should be named as a requirement within the Wikimedia Commons image guidelines. Perspective is a natural feature of any scene, and stretching parts of a captured image to turn everything into a perfect rectangle creates a false representation of the scene, whether this is done with software or a tilt-shift lens. In many cases these corrections give a very odd look, because the photographer is situated at the base of a tall building, looking up at it, with a view of the underside of arches, ledges, etc, and stretching the building face into a rectangle means that the arches and ledges look plain wrong, tricking the brain into thinking that they're somehow jutting downward or upward (to explain how you can see the underside of them when the overall rectangular shape suggests that the camera is looking at the building head-on from a perfectly centred position). Portraying perspective in a photo is entirely reasonable, and it should not be a requirement that converging lines must be artificially stretched into parallels in order to create a quality image. --Bobulous (talk) 11:29, 7 September 2019 (UTC)
Perspective corrections are not devilish by definition. However, they must be applied in such a way that no completely surreal image impression is created. The main argument of the users, who always demand one hundred percent verticalization, is that the architect of the respective building or the designer of the photographed object did not draw any sloping walls. It is completely misjudged that the creator of the drawings can of course freely choose the virtual location from which his object is viewed. The camera location when photographing such an object, however, can only be freely chosen in the rarest cases, so that a different perspective inevitably emerges. And as soon as you have to point the camera diagonally upwards or downwards, you get the infamous "falling lines" that need to be corrected. Now one could easily argue that with shift lenses or adjustable cameras it is possible and usual to correct views in perspective. This is completely correct, but has limits, because the adjustment range of such photo technology is quite limited. Lenses for adjustable cameras are available up to a picture angle of about 120°, beyond that it becomes exotic. However, with the perspective correction by image processing, far higher values are available at the push of a button without any problems (obviously, of course, no rectilinear 180°...) - but exactly such absurd corrections are absolutely required by some QIC evaluators here on commons. This has absolutely nothing to do with realistic reproduction. Besides the unspeakable aesthetics, extreme perspective corrections via software have another, purely technical disadvantage: The correct simulation of a shift lens via software requires (in the case of the mostly needed application with a building that is photographed with the camera held obliquely upwards) that in the upper half of the image more and more pixels have to be interpolated, which are not present in the original. Similarly, pixels in the lower half are lost. While the latter is not a big drama because only a little image resolution is lost, the former leads to more or less strong blurring. In order to compensate for this inevitable blurring, photographers all around the world then reduce the size of such images to such an extent that the result is a pleasant, homogeneous impression of sharpness. But not here on commons, because the (technically and aesthetically necessary) reduction violates the other sacred cow of quality criteria: Scaling down photos is forbidden under threat of the most serious consequences! And so in the collection of quality images there are tons of perspective-corrected architectural photos with completely absurd perspective representation, absurd proportions, avoidable blurs, representations far away from reality and creepy aesthetics. In short: perspective corrections yes, but please sensitive. --Smial (talk) 10:33, 8 September 2019 (UTC) Translated with

Downsampling and colour spacesEdit

It is not my intention to overload this page with too many guidelines, but there are two more points which I would consider fairly important:

  • Downsampling: Sometimes it is suggested to downsample an image to "improve" quality. However downsampling never actually improves an image. It may seem to look better 1:1 on screen, but that's only because you are looking at a lower resolution! For "real-world" usage, e.g. print, the lower resolution is never better and usually worse (you don't gain quality and you add "blockiness" from the low-res pixel pattern on top of it). Therefore I suggest making it a rule, or at least a strong recommendation, to not downsample images that have been uploaded in high resolution.
  • Colour spaces: Some people upload their images in AdobeRGB. Most browsers however ignore colour profiles and assume sRGB, thus displaying wrong colours (less saturated and with a colour cast). I think it should be a rule that an sRGB version has to be provided. Other versions in AdobeRGB or other colour spaces can obviously be uploaded additionally and linked via "other versions".

--Stefan Vladuck 08:50, 13 May 2008 (UTC)

    • Downsampling: this is the stuff we (I) do want to have in the guidelines, just to refer people to it and save typing the same sermons over and over again. --Dschwen 13:38, 13 May 2008 (UTC)
    • Colour spaces: not sure about this one. Why should we make life more complicated for our users to limbo around broken browsers? Color profiles are a good thing. We should just permit/use them and have the browser makers fix their broken display software. --Dschwen 13:38, 13 May 2008 (UTC)
Well, to the best of my knowledge the situation is this:
  • No current browser (stable release) supports icc profiles, except Apple's Safari.
  • The Firefox 3 beta release has icc profile support, but it is disabled by default.
  • Mediawiki itself (!) has no support for icc profiles. When an image is rescaled, the profile is just ignored and discarded. For Wikipedia and all the other Wikimedia projects this means that all non-sRGB images will be displayed with wrong colours in every browser (even in Safari).
In my opinion, just using icc profiles (other than sRGB) and relying on the software makers to support them some day in the future, amounts to displaying wrong colours to the majority of users for years to come. To me, this seems like a bad idea. --Stefan Vladuck 15:09, 13 May 2008 (UTC)

About Downsampling: I completely agree with you Stefan. The problem is that too many reviewers think a picture is best judged at 100% on screen. And I tell it a thousand times on these discussion pages that this is wrong for high resolution images. They should be reviewed at a reasonable size e.g. full screen.

About Colour profiles: I think it's counterproductive to request sRGB. Browsers don't assume sRGB they don't colour manage. sRGB is bad for dark blues or saturated greens. Therefore it's sometimes better to upload AdobeRGB because you otherwise just clip colour information. If we really want to improve our guidelines we should request to review pictures using Photoshop or ACDSee Pro. These proprietary products that cost a lot are the only ones that provide correct colour management. Last but not least colour management does not make your monitor better than it is. So it's worth spending something for it. --Ikiwaner 18:33, 13 May 2008 (UTC)

Indeed, browsers don't colour manage, but "Nearly all software was and is designed with the assumption that an 8-bit-per-channel image file placed unchanged onto an 8-bit-per-channel display will appear much as the sRGB specification dictates." (Wikipedia) AdobeRGB images on the other hand will look dull on an unmanaged display.
I'm not opposing the use of AdobeRGB to take advantage of its wider gamut. But the problem is: these images won't display correctly to the average end-user, period. You can't expect e.g. Wikipedia users to buy Photoshop just to see the images properly. (On a side note, Cinepaint is free and supports colour management as well.) The only solution that I see is to have (additionally) an sRGB version to use in Commons galleries, on Wikipedia, and all the other projects. --Stefan Vladuck 21:15, 13 May 2008 (UTC)

About Downsampling again: I agree with the things said about not to downsample high resolution images. But if we agree on this, the guidelines for reviewers should really clearly state that not all of the quality criteria should be checked at the full resolution view. For me as photographer it makes a big difference if I optimize a picture for a certain size (which absolutely includes downsampling) or if I can rely on the reviewers to know what it means to review a not downsampled picture. It is easy to let a not that sharp picture look great after downsampling and sharpening (which in most programs comes along each other). --JuliusR (talk) 14:00, 16 January 2009 (UTC)


There should be a section for diagrams etc. or even an even more general section for non-photographic images. /Lokal_Profil 15:54, 16 June 2008 (UTC)

Progressive JPEGEdit

This_change, made by Dori was reverted by me, until a consensus is reached. I don't have a strong opinion on the subject but it seems to me that a picture shouldn't be punished in COM:FPC by the fact of using progressive jpeg encoding, as it only affects the way it loads, not its content. On the other hand, resolutions about the optimal formats to use in Commons shouldn't be made here. -- Alvesgaspar (talk) 13:37, 11 October 2008 (UTC)

Well, now one seems to be bothered (or has even noticed) this message. I'll give it a week from the notice, if no objections I'll put it back. --Dori - Talk 22:32, 14 October 2008 (UTC)
What's the reason for putting it in? Isn't it part of the standard? Why should we discourage these sub-formats? They seem useful for low bandwidth situations. --Dschwen (talk) 23:04, 14 October 2008 (UTC)
It's an annoying feature. It makes you guess as to whether you're looking at the real image or some intermediate one. It also wastes CPU cycles for no good reason. How is it useful for low-bandwidth? You still must download the entire image, and if you're not looking to get the entire image, you might as well look at the thumbnail. I don't see this feature helping anyone. The only use-case I can think of is if someone tricked you into downloading a high-res, but progressive, goatse JPEG, and you can manage to get away before you've had a chance to be permanently scarred by the highest resolution version of the image. --Dori - Talk 23:38, 14 October 2008 (UTC)
Hehe. Well, I still think that badwidth is more of an issue than CPU cycles (we wouldn't be serving gzip compressed HTTP streams it it weren't!). And I think you'll have to do a little better than it's an annoying feature to justify a guideline change ;-). Hm. Yeah, the usefulness of the low bandwidth preview character is a bit lost on Mediawiki sites with thumbnailing capabilities. But rememb? Are they more than a fringe case? Do they cause enough harm to warrant a mentioning in this guideline? --Dschwen (talk) 00:01, 15 October 2008 (UTC)
That comparison would be valid only if you somehow downloaded the entire uncompressed stream in addition to it being compressed. Progressive doesn't conserve bandwidth unless you stop loading. --Dori - Talk 00:07, 15 October 2008 (UTC)

Downsampling, againEdit

The actual example for downsampling is the perfect illustration about what not to do. I propose to put it a little " " right in front of the description, and to put an imperfect-at-full-resolution-but-as-per-standard-FP. I propose my picture to serve as an acceptable example. Any comments? --S23678 (talk) 18:06, 31 October 2008 (UTC)

The extra text was recently added by an aficionado, I removed it. Lycaon (talk) 18:47, 31 October 2008 (UTC)

Red link about QI helpdeskEdit

There's a red link in the guidelines, about Commons:Quality images helpdesk. Is this page located somewhere? --Eusebius (talk) 10:21, 10 November 2008 (UTC)

I have removed the link it was an outcast idea from the early development of QI that didnt gain any momentum, there is Commons:Photography critiques that offers something vaguely similar. Gnangarra 13:32, 29 January 2009 (UTC)


In the last few days I've seen a few nominated images get dinged for cropping. I am curious though - what is wrong with cropping? (And should we add it somewhere to the Commons:Image guidelines)? --Bachrach44 (talk) 23:58, 3 December 2008 (UTC)

To the best of my knowledge, cropping is not bad in itself, and what's criticized is actually the composition induced by this cropping, when the subject is not well positionned in the picture, when it is cut or when distracting elements appear near the edges. These elements already are in the guidelines. --Eusebius (talk) 07:45, 4 December 2008 (UTC)
Okay, I think I see why those pics were rejected then - thanks for the explanation. --Bachrach44 (talk) 20:49, 5 December 2008 (UTC)
Sometimes when people say cropping they mean framing. Although nowadays it's hard to tell a crop from a full size frame. --Dori - Talk 18:26, 6 December 2008 (UTC)

Confusing image titleEdit

In table of the guidelines, there is a picture of a frog on the right. The title for the picture says "This photo is of high quality and just above the 2 megapixel limit." To me it sounds like limit is a maximum, but isn't it a minimum? What could we change it to if it should be more clear? --Henrik (talk) 17:41, 28 January 2009 (UTC)

  Done This downsampled image was not a good example, since it went against the guideline about downsampling. I changed it with a FP that was not downsampled --S23678 (talk) 17:04, 10 May 2009 (UTC)
I'm sorry but I have just reverted you: the role of the image (as I understand it) was primarily to show what a 2Mpx image looks like, and the one you proposed is way over that. Additionally, I don't see how it addresses the formulation problem pointed out here. --Eusebius (talk) 17:38, 10 May 2009 (UTC)
I really think the actual example sends the wrong message for the rule about image size, since it was probably downsampled (1/4 from the 40D's native resolution). Nominators should be incited to submit their work at full resolution, and voters should realize that a native resolution image will likely not be perfect at a 100% zoom... I think we need that kind of example more than an image showing only the minimum requirements for size. In a nutshell : in explaining one rule, it's disobeying the other. --S23678 (talk) 21:56, 10 May 2009 (UTC)

colour profiles?Edit

What do you think of requiring an embedded ICC profile for Featured and quality pictures? For adequate image reproduction it's mandatory to know how the RGB or CMYK values are measured. The downside is that current cameras write colour space information only as a tag in the exif information. We would need to manually add the colour spaces for plenty of images. I'm glad to hear your opinions. --Ikiwaner (talk) 18:50, 4 December 2009 (UTC)

This is nonsense, we don't even require EXIF data. It may be better and more professional if the profile is there, but I'm against any such requirement. --Eusebius (talk) 19:29, 4 December 2009 (UTC)
Absolutely against, the people who know how, and have the means, to do this right will already do it, people like myself are more likely to screw it up. --Dori - Talk 23:51, 4 December 2009 (UTC)


How would you define the "Wow factor"? Belgrano (talk) 15:30, 2 February 2010 (UTC)

Not falling asleep watching the image? --Peter Kaino Jensen (talk) 05:00, 4 February 2010 (UTC)

Guidelines for Vector Images?Edit

I see that the guidelines primarily address raster images and do not present guidelines for vector images! --JovianEye (talk) 18:24, 7 April 2010 (UTC)

Color space guidelinesEdit

I’ve made a stab at writing color space guidance at Commons:Image guidelines#Color space (in this edit), summarizing the discussion above in Downsampling and colour spaces colour profiles? and my own reading and understanding.

In summary, I suggest:

  • Use sRGB unless you’ve good reason not to.
  • Mac users should be careful (b/c of gamma 1.8).
  • Other color spaces (esp. Adobe RGB) are useful, but currently break Wikimedia and browsers – consider sRGB version for compatibility.

My main concerns are:

  • not confusing contributors who aren’t familiar with this – they should just use sRGB;
  • not forbidding non-sRGB color spaces, but highlighting the difficulties.

Hope this is useful and fair, and please feel free to rework and discuss!

—Nils von Barth (nbarth) (talk) 22:33, 19 June 2010 (UTC)
BTW, see also this dicussion: Village pump, 2009 Sep: Wikimedia unable to scale-down non-sRGB images properly on issues with scaling of non-sRGB images (discussing this image).
—Nils von Barth (nbarth) (talk) 22:45, 19 June 2010 (UTC)

"Quality and featured photographic images" tableEdit

My idea: to use another design for this table in order to make it less saturated. It is uncomfortable to read very short lines. Therefore, I have prepared this more spaced and clean structure. Sketch of the idea (grey lines not included):

Image size
Common problems
  • Images should have at least 2 real megapixels of information, for example, 1600x1250. For “easy to take” images, reviewers may choose to demand more if the image would benefit from it.
  • Images should not be downsampled (sized down in order to appear of better quality). Downsampling reduces the amount of information stored in the image file.
Graphics located on Commons may be used in ways other than viewing on a conventional computer screen. They may be also used for printing or for viewing on very high resolution monitors. We can't predict what devices may be used in the future, so it is important that our best pictures have as high a resolution as possible.

If there is more than one example, the will be shown as they are now, two per line. --Tintero (talk) 20:31, 25 September 2010 (UTC)

Exposure examplesEdit

You mark my work as "Underexposed foreground". Please mention that artistic work can be specially underexposed (this is exactly about my work) and overexposed by author for special purposes - atmospheric, mood, etc. Peter Porai-Koshits (talk) 19:24, 27 January 2011 (UTC)

Golden Ratio?Edit

We recommend something vague about the Golden ratio along with the Rule of Thirds under composition. As I understand its use in photography, the golden ratio involves using 0.381 where under the rule of thirds you'd use 0.333. This doesn't seem to be a big deal when you consider that most folks are pretty imprecise about these things in photography. There is a lot of psychobabble and even numerology when it comes to describing what the golden ratio is all about. I'll suggest that we remove it unless somebody can clearly explain what it means in this context. Smallbones (talk) 20:53, 7 February 2013 (UTC)

I'll remove the Golden ratio drive-by mention in a few days if nobody says anything. Smallbones (talk) 03:40, 11 February 2013 (UTC)

Panorama exposure and lightingEdit

A solution to overexposed areas in panoramas is to use tone-mapped high dynamic range images. If the panorama was taken with multiple exposure bracketing, it should be possible to capture the entire dynamic range in the image. Now that Hugin has good support for HDR panoramas, it is easy to stitch HDR panoramas even from handheld shots (such as the panorama below). The resulting HDR image can be tone-mapped with the free and open-source luminance-hdr[1].

As an example, here is a panorama I took:

Tone-mapped HDR image. Highlights in the sky are not overblown.
Non-HDR version. Notice overexposed sky.
-2ev exposure to capture detail in sky (esp. the right).
+2ev exposure to capture detail in shadow regions (e.g. in houses).

Purpy Pupple (talk) 02:24, 23 February 2013 (UTC)

Downsampling examplesEdit

Hello, are there any examples, where an image downsampled to 2 megapixels has lower quality than an image taken from a 2 megapixel camera? Why both pictures should not have the same amount of information? I would even go so far to say, that the downsampled picture is of better quality, because it has more sharpness. By the way the image from the frog was taken with a Canon EOS 40D which has 10,1 megapixels, so this image is possibly an example for downsampling. --Sinuhe20 (talk) 10:53, 15 October 2014 (UTC)

For a downsampled picture and a out-of-the-camera picture that are the same size, the downsampled picture will always be considerably superior, assuming both cameras are similar in quality. In fact, you see downsampled pictures all the time -- MediaWiki downsamples to create thumbnails and to create the preview-sized images in the image description page. And it does a modest amount of sharpening at the same time. The problem with uploading a heavily downsampled image is that it might look nice on a small monitor, but will look rubbish on a retina-quality display or when printed. So we discourage "resize for the web" mentality where images from a 24MP camera are downsized to 2MP for display. They look great, but have significantly limited value to the project. For example, to print an A4 magazine page you need around 5MP for high quality result. -- Colin (talk) 12:40, 15 October 2014 (UTC)
Then not downsampling is the problem, but the resolution. "Images should have at least 2 real megapixels of information" says the guideline (by the way: what are real megapixels?).--Sinuhe20 (talk) 21:18, 19 October 2014 (UTC)
I don't know what "real" megapixels are either. Perhaps it is to discourage someone from upsampling a low-res photo merely to meet the threshold. The downsampling issue is more of a behavioural one. Both QI and FP reviews have a tendency towards pixel-peeping. The easiest behavioural thing to do to counter that is to downsize one's photos. So rather than 24MP image from my camera, I upload a 6MP image. Nobody can pixel-peep it because it looks great. And while we should continue to try to educate reviewers against pixel-peeping a high-resolution image, we also need to advise uploaders/nominators to not take the easy option. The project benefits from high resolution images. 2-megapixels is a necessary resolution but not a sufficient resolution for FP/QI. It might be allowed for historical or for long-lens nature photography, but a 2MP image of a building or a 2MP studio portrait is unlikely to succeed. -- Colin (talk) 07:38, 20 October 2014 (UTC)

Taxa Naming and Rule ReplicationEdit

There was a discussion recently about new rules for QIC. The new rules are formulated on the QIC page. One major change was to drop the requirement to specify taxa names for organisms. Now this page replicates these image page requirements, see Image guidelines page, but still contains the requirement to specify taxa names for organisms and scientific names for organisms. There are two possibilities to handle this inconsistentcy:

I prefer the second approach in order to avoid future inconsistency. Any other opinions? --Uoaei1 (talk) 07:37, 2 December 2014 (UTC)

  • Updated. I don't think we can remove it as it is applicable to COM:FPC too. Jee 08:01, 2 December 2014 (UTC)
Thanks! --Uoaei1 (talk) 09:50, 2 December 2014 (UTC)

Colour spaceEdit

The guidelines make the mistake of saying AdobeRGB "allows more colours" (and saying it is "wider" is rather vague to most readers). An 8-bit JPG has the same rather small number of colours no matter what (reasonable) colourspace is used. It may be drawn from very slightly wider set, but in 8-bit there's actually less fine tonal graduation possible as a result. The guideline does not make it clear that for a wide colourspace to function, many components in the image-chain need to be set up properly. The most common problems for wide-colourspace images to fail to display are operating system limitations, browser or image-viewer limitations, and monitor limitations. Only a tiny minority of our users will have correctly-setup wide-gamut monitors, using colour managed viewing software. Everyone else cannot see better than sRGB. The problem has actually got worse in recent times due to the rise of mobile browsing. There are no colour managed browsers for mobile OS and most mobile devices struggle to display all of even sRGB.

AdobeRGB was great for pro's shooting JPG for print in the past. But only a negligible percentage of today's images are printed. The world is online and takes many more digital photographs every year than were ever shot in the previous century. And currently, the world is sRGB. We can grumble with that historical legacy but it's reality. Some of the best pro photo websites actually convert to sRGB on upload, because offering AdobeRGB JPGs on the web is stupid. But converting JPGs is not ideal. When an AdobeRGB JPG is rendered as sRGB in a browser, all the more-saturated colours are (of course) lost. So some of the tonal range that an 8-bit JPG can offer (which is fairly limited already) is wasted. And the actual transformation to sRGB is done crudely by a browser (aiming for speed) unlike Photoshop which would like to keep quality high. So there is a good chance that posterisation will occur in the sky or skintones.

Also consider that many photographic subjects do not contain colours outside of sRGB's range. The colourspace triangle on this guideline gives the misleading impression that a whole load of lovely saturated colours are missing. In fact, the triangle is not to scale if calibrated by what the eye can sense, and a whole junk of the triangle is outside what is even visible to our eye at all. We are better at distinguishing less saturated colours (those in the middle) than fully saturated colours. In effect, our eyes can't easily tell the difference between very deep red and very very deep red. Very deeply saturated colours (whether dull, mid-tone or bright) are those at risk of being affected, and these tend to appear more in man-made plastic objects than in the natural world or architecture. It is possible to use Lightroom or Photoshop to preview the effect of applying a colourspace, though this assumes you are viewing on a wide-gamut monitor that is correctly calibrated and configured in the operating system.

Considering that the majority of our users will suffer slightly poorer image quality (less final tonal variation) or risk seeing significantly wrong colours when viewing AdobeRGB images, and a nearly negligible number of our viewers might benefit from viewing an AdobeRGB image, it is hard to justify at present. It's the Betamax of colourspace. I hope that not too soon from now we'll be viewing 10 or 12-bit images in Rec. 2020. But to achieve that, we'll need new software, new operating systems and new monitors -- because currently that's not a consumer reality. -- Colin (talk) 19:51, 15 April 2015 (UTC)

Apparently you want to tweak one statement: sRGB is most common and compatible, while other color spaces, notably Adobe RGB, allow more colors but are less compatible, and must be correctly supported by users' computers. How about this: sRGB is most common and compatible. While other color spaces might allow more colors, the conversions on systems not supporting these color spaces can cause prohibitive losses. Or anything you like better for this simple statement, whose only purpose is apparently the wikilink. –Be..anyone (talk) 12:40, 20 April 2015 (UTC)
I gave a lengthy explanation as I wanted to wait and see if anyone disagreed or corrected any mistake. To be honest, this guideline should probably be split up / rewritten. We only really need a small set of well-agreed requirements. Most of what is written here would be better written as either a tutorial for beginners (e.g. how to create a stitched panorama), a list of common mistakes and how to avoid them, and discussion pages on aspects of photographic quality (e.g. noise, perspective). -- Colin (talk) 13:03, 20 April 2015 (UTC)

Anchors in rows of table "Quality and featured photographic images"Edit

FYI, I've added anchors in the rows of the table Quality and featured photographic images. They can be used to lead to a specific row of the table. All possible usages:

Hope, this might be useful. --Hasenläufer (talk) 07:12, 17 January 2016 (UTC)

Questions during improvement of German translationEdit

Currently I'm working at improvements/extension of the German translation. In this context I got these questions:

  • What are "JPEG maps"? I can't find a soure specifying this term.
  • "lossless format (such as XCF)" – why is XCF mentioned? It seems to be a special file format of GIMP. My proposal is to substitute "(such as XCF)" by "(such as DNG, PSD or XCF)" – in the hope, this leads not to "political" discussions.

Kind regards, --Hasenläufer (talk)

Hello Hasenläufer, thanks for you work here. I also guess that not all is perfect here (alone to the fact that it's old, and unfortunately my English too).
@XCF: I guess the simple reason is, it is open and free in the same time with his edit-tool (which the others are not).
@"JPEG maps": I've also no clue, maybe ask here Commons:Graphic_Lab/Map_workshop (or on the corresponding En). :-P
PS: On help-pages I would prefer to link more to Commons-pages (like Commons:File types instead to Wikipedia)
User: Perhelion (Commons: = crap?)  09:55, 18 January 2016 (UTC)
User: Perhelion,
"@XCF: I guess the simple reason is, it is open and free in the same time with his edit-tool (which the others are not)."
Not to open a general discussion: Is there a common guideline to mention only open and free file formats and tools while keeping secret market-leading formats and tools? I know, Wikimedia projects propagate free knowledge, tools, file formats, operating systems and so on. But do we have to recommend users, to use only free tools and file formats?
"@"JPEG maps": I've also no clue, maybe ask here Commons:Graphic_Lab/Map_workshop (or on the corresponding En). :-P"
Thanks for the hint, I will follow it.
"PS: On help-pages I would prefer to link more to Commons-pages (like Commons:File types instead to Wikipedia)"
Why do you prefer this? I'm a bit sceptical. Typically Common articles go less in detail and are written in English, based of the character of Commons to be a repository. Up to now my understanding is, links of terms should reference to the most detailled information at the appropriate encyclopedia of the used language.
May be, in the case of file types it makes sense to have a clear differentation between (a) speaking in general, addressing a user and his usage of file types, (b) when speaking about file types Commons accepts, to link to specific pages at Commons like Commons:Dateitypen. BTW, up to now, I've never seen a XCF file at Commons, although it is mentioned at Commons:Dateitypen#Bilder.
--Hasenläufer (talk) 11:08, 18 January 2016 (UTC)
Probably TIFF and PNG should be the mentioned lossless formats, for the reason that they will be supported by any decent up-to-date image editing software. If nobody objects here, I'll make that change. --Junkyardsparkle (talk) 15:46, 18 January 2016 (UTC)
Let's have a look to the context, where the term XCF is used: "If editing a JPEG multiple times, perform all edits starting with the original, or use a lossless format (such as XCF)." The question is: What is the best storage format during image editing. Clear, JPEG isn't. But should TIFF and PNG treated to be the best storage formats? From my viewpoint TIFF and PNG are possible output formats, not typical storage formats (TIFF is a typical archive format). The best storage format depends from the used software. It seems, there is no typical storage format. Is XCF the typical storage format of GIMP? (I don't use GIMP). The market leading imaging program uses PSD as storing standard. Why not mention it? BTW: In the cited sentence the term "or" should definitely be substituted by "and", and appended by "for storage". So it would be: "If editing a JPEG multiple times, perform all edits starting with the original, and use a lossless format (such as XXX) for storage." (where XXX should be discussed). My opinion for XXX: "PSD (Adobe Photoshop) or XCF (GIMP)", the market leader should be mentioned first. It seems the discussion gets "political" :-( --Hasenläufer (talk) 17:38, 18 January 2016 (UTC)
Another idea: Can we link to an article which clarifies the question of possible/typical storage formats? --Hasenläufer (talk)
A further idea: Let's avoid to disuss a "typical storage format". Let's use something like "save your edits in a format, which is recommended by your image editing software." --Hasenläufer (talk) 17:53, 18 January 2016 (UTC)
Yes, I think something like "your image editing software's native project format" would be better than naming any software-specific formats (some people could be confused by this). I think it's also a good idea to mention at least TIFF (and probably PNG, if it's as universally supported as I suspect it is by now) as lossless formats that will provide compatibility between different software , as this is sometimes the use case. --Junkyardsparkle (talk) 22:48, 18 January 2016 (UTC)
  Support --Hasenläufer (talk) 11:51, 19 January 2016 (UTC)
Junkyardsparkle, thanks for this change! It's nearly perfect. There's only one detail which bothers me: ... 90% or higher .... Recently I investigated this theme. There are several pages in the web available, considering this theme by comparing visible results of different compression settings of JPEG outputs. My conclusion was, 80% is a suitable value. All higher settings don't lead to visible differences. Therefore they do not make sense, they solely increase the file size. Maybe we should open a new chapter at this page for discussing this, because a recommendation of a JPEG compression level could impact a lot. --Hasenläufer (talk) 07:35, 20 January 2016 (UTC)
Yes, I changed it from the rather arbitrary "95%", but it's a complicated topic that's hard to simplify to a general guideline. It depends somewhat on the content of the image, and 80% gives a good trade-off between quality and size for general web display, but since commons is more of an "archive" from which web versions are generated as needed by the wikimedia software, it seems reasonable to upload at a fairly high quality, if it doesn't impose a burden on the person uploading. In any case, the diminishing returns above 90% are very steep, so maybe I shouldn't have said "at least 90%". That was mostly only because of the original "95%" statement. Maybe "from 80% to 90%, depending on acceptable file size"? --Junkyardsparkle (talk) 08:51, 20 January 2016 (UTC)
  Support --Hasenläufer (talk) 09:15, 20 January 2016 (UTC)

Regarding "JPEG maps"Edit

I addressed this theme at two points: Commons talk:Graphic Lab/Map workshop#What are "JPEG maps"? and w:Wikipedia talk:Graphics Lab/Photography workshop#What are "JPEG maps"?. Up to now, there's only one comment at the second mentioned page. Let's see, what will happen to these both postings. --Hasenläufer (talk) 07:46, 20 January 2016 (UTC)

To avoid other users spend time to consider an odd question, I reverted these both postings --Hasenläufer (talk) 09:57, 20 January 2016 (UTC)

In addition: My interim result is, the term "JPEG maps" seems not to be a common used term. It might be a solely technical expression. Therefore it should be avoided to mention it in the guideline. --Hasenläufer (talk) 08:01, 20 January 2016 (UTC)

I decided in a pragmatically way, to remove the term from the guideline. It makes no sense to generate efforts at other users to follow an odd question. If anyone doesn't agree, he's free to contribute his opinion. --Hasenläufer (talk) 08:48, 20 January 2016 (UTC)

For what it's worth, "JPEG map" means nothing to me, either. Much of the contents on this page seems in need of updating from what made sense to someone ten years ago. --Junkyardsparkle (talk) 09:07, 20 January 2016 (UTC)
Junkyardsparkle, I'm with you. --Hasenläufer (talk) 09:15, 20 January 2016 (UTC)
Just as a bit of advice: If you encounter an odd term, add it to the following string to make a google search (be sure to leave the quotation marks in the string, but replace the square brackets):
photoshop OR gimp OR retouching OR "image editing" "[insert your string here]" -wikipedia -wiki -wikimedia
when you do that, I'm positive you'll find results, but if one of the results on the first page isn't the same exact thing you've seen it in reference to, it's a safe bet that most people (even experts) won't understand it either, and it should be ignored or re-phrased. You can also message me on my EN.WP talk page if you need any help. Mein deutsch ist nicht so gut, but I can read and write just a bit, and I have a basic grasp of the grammar, plus I've worked in the photography industry and been an artist for decades, so I have a good grasp of the jargon. MjolnirPants (talk) 13:44, 20 January 2016 (UTC)
MjolnirPants, thanks for the hint. --Hasenläufer (talk) 19:53, 20 January 2016 (UTC)

Photographs and non-photographic mediaEdit

As non-photographic media can definitively qualify for quality images, the image guidelines should also reflect this. I suggest that there could be (at least) two main sections, one for photographic media, which now covers the whole page containing criterias like exposure etc., and one section for non-photographic media where things like usage of an appropriate vector format, accuracy of drawings, how clearly things are depicted, how uncluttered and compatible svg source code should be etc. are explained. There are many quality criteria for non-photographic media, and I think that quality there also matters and guidelines could be helpful. --Geek3 (talk) 20:57, 10 January 2017 (UTC)

Totally agree! And see below. Yahya Abdal-Aziz (talk) 12:32, 30 September 2018 (UTC)

Downsampling because of personality rightsEdit

I take portrait pictures of politicians after TV-Shows. In full resolution and and fullscreen-views those pictures enlarge details in a person's face 2-3 times. Skin pores and body hairs are clearly visible & enlarged, as well as skin blemishes, blackheads, micro-teeth-problems and other details. Due to personality rights (and to avoid complains / keep my accreditation) I downsample such images to 50% of their size, still above 2 Megapixels and certainly not "in order to appear of better quality", as the image guidelines say. My last candidate for QI was declined for that reason, although it didn't have a quality-issue but a personality-right issue I wanted to solve by downsampling. I want to discuss that: Modern Cameras and good lenses can turn any portrait into a Macro photography of people's faces. Unless the person on the picture did not comply posting a Macro-View on their skin we should be sensitive to that issue, or is resolution the only thing that counts? --Superbass (talk) 15:31, 4 December 2017 (UTC)

I'm always downsampling all my photos to 50% of the original resolution, whether it's a commissioned work, a hobby project or for Commons. In my opinion, the modern camera sensors are now completely "overbred" just to be more attractive to number fetishists. --Stepro (talk) 17:04, 4 December 2017 (UTC)
Most of my images of people are downsampled to about 6 MPixels, sometimes less. Same reason. The high resolution of modern cameras can show details which can be considered offensive. Unfortunately, pure pixel counting has become popular with QI. Even well-founded exceptions will no longer be allowed, no matter whether they are technical or aesthetic or based on personality rights. --Smial (talk) 23:14, 4 December 2017 (UTC)
It might make sense to use a phrase like....
"Downsampling images of living persons is advisable if the images would otherwise show details of the body (e. g. skin, teeth) in unacceptable magnification, which could be considered offensive or violate the person's rights."
in the image guidelines. --Superbass (talk) 12:01, 5 December 2017 (UTC)

I disagree with censoring and not providing all the data. Maybe it seems like a lot of unnecessary detail in today's standard, and maybe we get offended for silly reasons like our own bodies, but technology moves fast and in no time those few pixels are going to look like what we know as the 90's internet when we commonly take high resolution 3d scans of people. These pixels are going to be useful in restoring our soon to look archaic photos. --Trougnouf (talk) 20:54, 30 September 2018 (UTC)

"Quality noise reduction software is expensive and algorithms computationally intensive."Edit

Can we remove this line from Commons:Image_guidelines#Noise? It seems to be discouraging noise reduction with an archaic statement; quality software is free (ie gimp, darktable, bm3d) and the computing cost is negligible.

I agree wholeheartedly with the above (latest) revision as of 23:50, 6 August 2018 by User:Trougnouf - Yahya Abdal-Aziz (talk) 11:06, 30 September 2018 (UTC)
  Done I went ahead and removed it. --Trougnouf (talk) 16:59, 5 January 2019 (UTC)

Colour depth in (non-photographic) illustrationsEdit

We could use a guideline on how to limit the colour depth in (non-photographic) illustrations.


Many a picture, created using some (standard, or even custom) software, is meant to illustrate some technical point or to clearly diagram the structure of a manufactured object or system. The intent in such pictures is not at all photographic; we're not trying to faithfully represent a physical likeness, so fine gradations of colour can be detrimental to creating a clear message. Particularly in technical drawings, distinct colours can carry specific meanings, so may be limited to just a handful of specific and fixed colours. In such cases, if the picture is meant to show, say, just 8 colours, it will be best if the creator saves it in a format (preferably uncompressed PNG RGB without transparency; or possibly GIF) that supports that fixed palette of colours — without resampling the created colours to a greater colour depth.

Example 1Edit

For example, the image below, created by a past user, is supposed to have just six colours, according to its description:

Algebraic numbers colored by degree (blue = 4, cyan = 3, red = 2, green = 1). The unit circle is black.

Algebraic numbers colored by degree (blue = 4, cyan = 3, red = 2, green = 1). The unit circle is black.

However, examining it in software such as Irfanview, we find it actually has 8,441 colours! This is due to its having been saved with ZIP compression, despite comprising only 779 x 516 pixels. (So that on average, every set of about 50 pixels has its own colour.) Few of us can name even 1,000 colours, and it's doubtful whether anybody could name the specific 8,441 colours in this image. Yet it's only intended to have a white background, a black unit circle and four other colours: a total of just six colours.

Now, it is perfectly possible to create an image like this one, using software, with those exact six colours. And it is equally possible to save that image as an uncompressed PNG file with exactly the same six colours. Had the picture's creator done so, the resulting image would have perfectly conveyed the intended information. But because the image was saved in a lossy format (compressed PNG, in this case; JPG, in others), it's now not possible to reconstruct the original six-colour picture from the one we have before us.

Example 2Edit

We can contrast this image with another one (presently on English-language Wikipedia - click to view, not yet on Wikimedia Commons), for which we have the C source code for the software that created it.

This large image actually has 286,399 colours, although the software code implies the selection of just 10 colours before output using OpenGL graphics library functions. Thus, if wanted, it should be possible to modify the software code to produce just those 10 colours at every (pixel) point. The picture's creator, Stephen J. Brooks, describes it as having smaller points corresponding to larger polynomial coefficients. Clearly, there's some anti-aliasing going on to present the larger points as smoothly-shaded discs between the centre colour and the black background, or to allow for overlap of two or more discs. If we wanted to, we might represent each point of the complex number plane by just one coloured pixel, regardless of the size of the coefficients that generate it. The resulting image would then have just the 10 colours specifically selected in the current code. And again, we could save that image as an uncompressed PNG file with exactly the same 10 colours.

The next stepEdit

I'd welcome any comment on such a guideline:

  • the value of having one;
  • suggestions on what it should contain;
  • its specific wording.

Yahya Abdal-Aziz (talk) 12:31, 30 September 2018 (UTC)

Return to the project page "Image guidelines".