This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
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? --Wikimol22:02, 1 July 2006 (UTC)
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.Message09: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. --Ikiwaner06:30, 12 February 2007 (UTC)
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. --Gmaxwell19: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. --Ikiwaner06: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='gmaxwell@gmail.com' -Owner='Gregory Maxwell' -UsageTerms='Use only with attached copyleft license grant.' -CopyrightFlag=True -Copyright='2006 by Gregory Maxwell (gmaxwell@gmail.com). 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. --Ikiwaner18: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 Wills00: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. Fg210: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? --Gmaxwell01:00, 13 May 2007 (UTC)
Guidelines on Panoramas
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 K16:51, 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 K12: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.
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 K17: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 K18: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 K18: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 K18:47, 25 June 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?
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? -- Slaunger02:42, 14 August 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 Wills06: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. --Slaunger22: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). --Dschwen10:59, 3 September 2007 (UTC)
Resolution arguments
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 Dantas23:28, 28 October 2007 (UTC)
About perspective correction
Figure 1Figure 2Figure 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 Vladuck16:51, 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 Vladuck21: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. --Dschwen22: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 Vladuck22: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. -- Slaunger22: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. --Dschwen22: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 Vladuck23: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. --Dschwen03: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 Vladuck07: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. --Dschwen12: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 Vladuck13: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. --Dschwen14: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 Vladuck15: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. --Dschwen18:51, 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. --Dschwen21: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. --Dschwen21: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 Vladuck21: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. --Dschwen21: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 Vladuck22: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. --Ikiwaner10: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 Vladuck11: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). --Dschwen14:51, 12 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...? --Ikiwaner18: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 www.DeepL.com/Translator
Downsampling and colour spaces
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".
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. --Dschwen13: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. --Dschwen13: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 Vladuck15: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. --Ikiwaner18: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 Vladuck21: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)
Diagrams
There should be a section for diagrams etc. or even an even more general section for non-photographic images. /Lokal_Profil15:54, 16 June 2008 (UTC)
Progressive JPEG
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 - Talk22: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 - Talk23: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 - Talk00:07, 15 October 2008 (UTC)
Downsampling, again
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)
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)
Sometimes when people say cropping they mean framing. Although nowadays it's hard to tell a crop from a full size frame. --Dori - Talk18:26, 6 December 2008 (UTC)
Confusing image title
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?
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 - Talk23:51, 4 December 2009 (UTC)
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):
This photo is of high quality and just above the 2 megapixel minimum.
Guideline
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.
Discussion
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.
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?
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)
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).
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 Replication
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:
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"
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:
Questions during improvement of German translation
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.
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).
"@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?
"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.
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)
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)
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)
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)
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)
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."
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."
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.
We could use a guideline on how to limit the colour depth in (non-photographic) illustrations.
Rationale
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 1
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 2
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.
What do you think? I think the consensus has been there for a while that we should be using location templates. We just didn't manage to mention it here. Regards, --Podzemnik (talk) 00:45, 20 January 2020 (UTC)
I would support it while allowing exceptions for privacy in specific circumstances, but the problem is, if it's a guideline, do we enforce it through our votes or is it just something exemplary that's regarded merely as an ideal? -- Ikan Kekek (talk) 01:09, 20 January 2020 (UTC)
I would oppose. There are quite different reasons to do not so, e. g. privacy, keeping the place hidden (see for instance the discussions on Wiki Loves Earth), or simply not having the location (on old paper photos). Second it is often not useful, so it's quite unimportant for all the studio portraits, in which studio they were taken respectively where the studio is located. --Stepro (talk) 01:18, 20 January 2020 (UTC)
I agree that it's not useful for studio portraits, but I would simply make those an exception. Can you please summarize and link to relevant discussions on Wiki Loves Earth? -- Ikan Kekek (talk) 03:19, 20 January 2020 (UTC)
For example, there are highly endangered plant populations or animal species that would be very likely to be destroyed by collectors if GPS data were used to locate them to within a few metres. Here in my neighboring village there is a site with a very rare orchid species. You can surely imagine what would happen if it became known in interested groups. In such and similar cases it must be sufficient to indicate the approximate region, e.g. the nearest village. I would not support a "must have gps location", but something like "should have a meaningful description of the location" is fine for me. When shooting in cities, a description like "The house Marktplatz 5 in $City seen from the south" would suffice, but "Old building in $City" is not enough. --Smial (talk) 08:48, 20 January 2020 (UTC)
Geolocation should be recommended only, but not mandatory. I am ready to support only this wording. With the reasons:
1. Subjects (studio shooting) - this can be pointless. For example, a glass cup or scissors made in China and photographed somewhere in Europe.
2. Location during the trip. In the village, this is possible. But what about when traveling in the wild (in a forest or on a boat trip)? Exact coordinates are not always possible to obtain, restore if they were not recorded at the time of shooting. In this case, it is better not to indicate anything than to write erroneous coordinates for the sake of estimation QI.
3. Closed objects for which it is forbidden to indicate the exact coordinates (military, strategic or police).
Without amendment, that geocoding is desirable, but not necessarily, i will be strong oppose. -- George Chernilevskytalk14:32, 20 January 2020 (UTC)
I would go with a version of George's suggestion and I also think it would be good to help people who do not know all the templates that are available. We had this discussion a while back on a FPC nom where the concern raised by Smial was discussed.
My proposal would be:
"Use of geolocation is recommended, use {{Location}} and/or {{Object location}}. If the location is difficult to obtain, use {{Location estimated}}. For sensitive locations like in nature reserves, military areas or private homes, use {{Location withheld}}. You can also use the normal {{Location}} but only use three decimals in the coordinates."
So how do we write the wording so that it allows for leniency when a photo from say WLM by a newbie, who has only made edits during that competition, is nominated by someone; while demanding location for lazy/grumpy old-timers who know the rules very well but simply can't be bothered with such things. We have an unwritten "rule" that newbies don't have to do any reviews the first time they make QIC noms simply because they are not experienced enough. Do we set a rule that a location should be given, except in some very special cases, as soon as a user has for example 20 QIs? --Cart(talk)18:06, 20 January 2020 (UTC)
I like the wording: "Geocode is highly recommended" only.
But geocode is not required, for cases 1,2,3 and possible for other reasons.
I had all three options. I took studio shots and added the geocode, although it was almost useless. I experienced great difficulty in specifying coordinates for images from the wild. And finally, i did not have the right to specify the coordinates for military objects sample. -- George Chernilevskytalk21:15, 20 January 2020 (UTC)
I think it's better to have a standard something like this: "Geocoding is required except when it's impossible or inappropriate. Photos that can't or shouldn't be geocoded may include those which would show the locations of endangered plants and animals that might be threatened by poachers, military installations, locations that should be hidden to respect rights of privacy, locations for studio photos, and deep forest locations where there is no GPS signal. In such cases, you may have the choice of giving the general location (to 3 decimal places or fewer, as appropriate), or you can use the {{Location withheld}} template." But it sounds like you'd like to cut new users some slack. So the upshot is that if you haven't previously nominated photos to QIC, a photo with no more indication than being in a particular nation or on a particular 1000+-km river is adequate, or what? -- Ikan Kekek (talk) 23:14, 20 January 2020 (UTC)
It was a random brainstorming thought since it is often next to impossible to get additional info on photos from most new users who only upload a few, sometimes extremely good photos, but long-time contributors should definitely not get away with such laziness. Then again, perhaps it's more fair that you should learn a bit before you start getting QIs. I'm thinking out loud, it's a bad habit... --Cart(talk)23:29, 20 January 2020 (UTC)
I am still strongly opposed to “required,” but support "is highly recommended.” I do not want to divert the discussion to the side, but here I consider the rigid framework inappropriate. We also have rules that are already spelled out but not respected. Why else add a new rule in which uniqueness is impossible. A rule that deserves a separate discussion: the existence of EXIF. This can be hidden (deleted) / greatly reduced or distorted in images. Do we needed to require a mandatory EXIF? This is also very useful information. A rule that has long been broken: the mandatory biological identification of all organisms / life forms. An exception may be only for cultivated plants and animals for which a common name is known. However, we have thousands of promoted QI images of unknown animals (mostly insects). So why do we need to add another “dead rule” without executing it? -- George Chernilevskytalk06:49, 21 January 2020 (UTC)
The requirement for a higher resolution than 2 MPixel for photos that are easy to take is not mandatory, but may be required, and this rule works imho. So I agree with George: we cannot demand GPS data on a mandatory basis. Many widely used cameras do not provide GPS information at all and not everyone has a GPS tracker running all the time to synchronize the camera position afterwards. Nevertheless I am in favour of increasing the requirements for position information. But this must remain a "should" and it must be interpreted with common sense. --Smial (talk) 14:18, 21 January 2020 (UTC)
I also agree with George Chernilevsky, even though in part for somewhat selfish reasons. Most of my recent QI candidates (usually wildflower images) are from 2014 or earlier. My oldest QI that I got in 2019 is from 2002. I had no means of obtaining the GPS location prior to summer of 2015. Adding approximate coordinates makes rarely sense. Also, I must confess that I removed the coordinates for almost all the more recent images from guided field trips, because I am not so sure whether the guides would like precise coordinates of the possibly sensitive places where I photographed the plants they showed to me. --Robert Flogaus-Faust (talk) 22:00, 21 January 2020 (UTC)
I hear you. I'll defer to you all on the phrasing of the guidelines, and we'll continue to have discussions in Consensual Review on cases that seem worth discussing. -- Ikan Kekek (talk) 06:00, 22 January 2020 (UTC)
Location requirement should be in our Image Guidelines but it shouldn't be enforced but "only" (highly) recommended
There are exceptions where the location is not desirable like studio shots, military objects, endangered plant populations or animal species etc.
To put this into words, I suggest this:
"It is recommended to geocode images by using {{Location}} and/or {{Object location}} templates. If the location is difficult to obtain (eg. in the wilderness areas), you may have the choice of giving the general location (to 3 decimal places or fewer, as appropriate), or use {{Location estimated}}. Photos that can't or shouldn't be geocoded include those which would show the locations of endangered plants and animals, military installations, studio photos or locations that should be hidden to respect rights of privacy. To communicate this in the image, you may wish to use {{Location withheld}} template."
I think that it is well permissible not to indicate the location without explanation. A photographer who voluntarily gives his work to the Commons, has the right not to turn himself inside out. Such insistence is too reminiscent of interrogation. And again, this could be come to a "dead rule" if the requirements are tightened. -- George Chernilevskytalk08:09, 23 January 2020 (UTC)
The suggestion looks fine to me and I agree with George above. Also, most of the time people are intelligent enough to understand why the location was withheld. No one has bugged me about why I have that template on this photo. It is always optional to write a comment in the description as to why the location is not given if the reason is foggy. For me, being open about a non-disclosed location by using the template is better than just looking lazy by adding noting. --Cart(talk)08:50, 23 January 2020 (UTC)
I also will not support the obligation to use the {{Location withheld}} template. However, I might add rather precise locations to some of my more recent images, where I have not got any location data for the respective image, but a different image of the same subject at almost the same place that does contain GPS data. For much of the rest a general location such as an arbitrary point between two known locations might be feasible, with a {{Location estimated}} template and possibly some additional explanatory text. So, in my opinion, the suggested text by Podzemnik should be acceptable. --Robert Flogaus-Faust (talk) 15:45, 24 January 2020 (UTC)
The River Benue photo is clearly one of photos leading to this proposal. This is a fine image and IMHO voting it down for lack of GPS coords is defeating the purpose of a QI rating. This GPS info should be only recommended not required. As mentioned above, there are several valid exceptions to requiring this. I add to George's limitations:
1. Subjects (studio shooting) - this can be pointless. For example, a glass cup or scissors made in China and photographed somewhere in Europe.
2. Location during the trip. In the village, this is possible. But what about when traveling in the wild (in a forest or on a boat trip)? Exact coordinates are not always possible to obtain, restore if they were not recorded at the time of shooting. In this case, it is better not to indicate anything than to write erroneous coordinates for the sake of estimation QI.
3. Closed objects for which it is forbidden to indicate the exact coordinates (military, strategic or police).
4. Places lovers hang out (EX: River Benue photo)
5. Personal residences (if you take a photo of a plant in your home garden do you want to advertise to the world where your residence is?)
@Seven Pandas: I don't know what you mean by "The River Benue" photo. Yes, we talked about it and we agreed that GPS should be only recommended - at this stage it's not even mentioned here. That's what I'm trying to fix. Yes, these exceptions are included in my proposal. --Podzemnik (talk) 21:02, 25 January 2020 (UTC)
For the record, I never insisted on exact coordinates for that photo, but specifying nothing but an over-1,000-km river is not specific enough. Some general indication of what part of the river's flow the photo is of would be sufficient to be meaningful. -- Ikan Kekek (talk) 07:15, 26 January 2020 (UTC)
I have a question of principle : This/my photo was manipulated (Modifications: seagulls repositioned) by a third party - and then was successfully put up for candidacy by this third party : "This image has been assessed using the Quality image guidelines and is considered a Quality image." --- Does this approach correspond to the educational purpose and the credibility of the Wiki-Commons ? --Gordito1869 (talk) 13:48, 10 October 2020 (UTC)
I share your concern. In my mind, Wikipedia and Wikimedia Commons are supposed to exist for documentary purposes, not for artistic/creative purposes. There are many other websites which are suitable for showing off artistic expression, so using Commons as a way to do so is unnecessary. If artistic/aesthetic manipulation which involves actually moving or removing significant elements of a scene is encouraged, then the documentary value of the media will be diminished. On the plus side: at least in this example the alternative version has been correctly tagged with the "retouched" template, with a note that states clearly that the position of the gulls has been altered, and a link to the original. But I still doubt the value of hosting such aesthetic variations on Commons. --Bobulous (talk) 19:07, 10 October 2020 (UTC)
Cell phone masts and satellite dishes are virtually deleted. The users of Wikipedia want to visit an old castle and find a cell phone mast on its tower; however, the current photos in Wikipedia do not show a cell phone mast. I think this is deceiving readers and visitors. In this way, Josef Stalin made opponents of the regime virtually disappear from photos. In my opinion, a manipulated photo cannot be an encyclopedic photo - and therefore also not a quality documentary photo in an encyclopedic article on Wikipedia. --Gordito1869 (talk) 07:19, 11 October 2020 (UTC)
I think digital manipulations are ok, since Commons is the central repo for all photos taken, not just photos for WP-articles. But what is really important, that all manipulations changing the content (not just brightnes corrections) should be mentioned. Also, it would be helpful if the original version is uploaded too for reference. But with that done, theese photos can also be QI, but hardly VI in my oppinion.--Tesla - 💬09:13, 11 October 2020 (UTC)
Best color spaces are sRGB or, optionally, Adobe RGB, which is wider, as these are standard color spaces and hence easiest to support and for other editors to use. If using a non-sRGB color space – say for greater color range – consider making an sRGB version of the image for greater compatibility.
All major web browsers and operating systems support color profiles, and modern cameras capture more colors and bit depth as well. Other color spaces are also standards. We shouldn't discourage people from posting wide gamut images if they need to show some colors which are not part of the ancient sRGB standard. The only compelling argument for sRGB is that JPEG is only 8-bits (so likely posterization with very wide gamut profiles like Rec.2020) but that doesn't apply to AdobeRGB which isn't that wide and it's hopefully all going away soon with modern >8-bit codecs like JPEG XL.
So, by not suggesting a standard, or preferable shortlist, would it be ok for people to submit images in *any* color space? I'm thinking that would cause some problems. Hohum (talk) 16:05, 13 September 2021 (UTC)
I believe so. It's pretty rare that people change from the default sRGB color space, and I assume one would know why they are chosing something else, so why bother with restrictions for problems that do not materialize? --Trougnouf (talk) 16:23, 13 September 2021 (UTC)
Moreover if one were to create a custom color space for their image, then it would likely just be beneficial because they could then fit the colors they need in only 8-bits. Either way, no one does that. --Trougnouf (talk) 16:28, 13 September 2021 (UTC)
A few notes: Every thumbnail of an image must include the profile used for that image. When a file is thumbnailed by Thumbor, sRGB profiles are replaced by TinyRGB (see phab:T100976). This can result in a performance improvement, especially for users on limited connections. Most other profiles are larger than sRGB to start with and aren't made smaller. AdobeRGB isn't too bad, but I've seen some hilariously large color profiles. Due to phab:T219569, TIFFs with certain profiles will be converted to TinyRGB during thumbnailing anyway. While ICCv2 is well-supported among desktop browsers, ICCv4 is not. I have no idea about mobile browsers.In summary: it's still best to use sRGB unless you have a good reason not to. AntiCompositeNumber (talk) 23:53, 13 September 2021 (UTC)
ICCv2 seems to be supported on Apple mobile devices and Chrome on Android (both ICCv2 and ICCv4 here). Neither work on my phone with Firefox mobile (which is the only exception I know of). Mobile devices tend to have wider gamut than most desktops since they are small enough for AMOLEDs and such fancy tech to have been cost effective. ICCv4 is supported on desktops by Chrome, IE, and Safari, but not Firefox (v2 only) but either I haven't seen one in the wild or most software export in a backward compatible way somehow? (I am a Firefox user and I sometimes export my images in Rec. 2020 to preserve colors which don't exist in sRGB or Adobe RGB.)
I can see your argument for saving bandwidth, especially on thumbnails, but these are the image guidelines which we use in Commons:Quality Images; size is not so much of an issue when we specifically ask authors not to downsize their image. Color gamut compression is definitely a downsizing operation, which is usually worse than spatial dimensions imo, and the size difference is minimal; ***most color profiles take up less than 1 kB***, eg 732 bytes for Rec.2020, 1.1 kB for ProPhoto RGB with half of the data being a string containing copyright (CC-BY-SA-3.0) information. That is nothing compared to the megabytes we use up by providing full resolution.
I think it would be ok to use a wording that mentions Wikimedia Commons is optimized to save bandwidth on thumbnails with sRGB images, but the current wording is just misleading; sRGB (or optionally Adobe RGB) are not just "best" anymore, and software support is prevalent among viewers and editors so there is no added difficulty for the other editors. This has created pointless arguments on Commons:Quality images candidates that have repeated and will repeat so long as the guidelines mislead reviewers into prefering sRGB over color accuracy.
" 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)
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)
Support --Hasenläufer (talk) 11:51, 19 January 2016 (UTC)
_4.jpg){kind=link}
