Commons talk:Image guidelines

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

Quality Media[edit]

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 Illusion[edit]

Shadowtest.jpg

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 criteria[edit]

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='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. --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 Panoramas[edit]

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)?

Edinburgh view Princes Street vignetting 2001-05-05.jpg
Edinburgh view Princes Street 2001-05-05.jpg

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:

Panorama Eilean Donan Castle badstitch 2005-05-14.jpg
Panorama Eilean Donan Castle 2005-05-14.jpg

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)

Santa Cruz do Sul catedral parallaxerror 2005-03-21.jpg
Santa Cruz do Sul catedral 2005-03-21.jpg

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)

Skye panorama badcolour1 2005-05-14.jpg
Skye panorama badcolour2 2005-05-14.jpg

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)

Ardnish view huginonly.jpg
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 arguments[edit]

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 correction[edit]

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)

Downsampling and colour spaces[edit]

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)

Diagrams[edit]

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 JPEG[edit]

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, again[edit]

The actual example for downsampling is the perfect illustration about what not to do. I propose to put it a little "Symbol oppose vote.svg" 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 helpdesk[edit]

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)

cropping[edit]

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 title[edit]

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)

Wow[edit]

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 guidelines[edit]

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" table[edit]

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
Examples
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.

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 examples[edit]

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 lighting[edit]

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 examples[edit]

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[edit]

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)