:: The profile is either misinterpreted or broken (in which case it is used only by Firefox, I guess). If you remove all metadata, Firefox renders the images like the other software. See e.g. history of [[:File:Command and control center Port of Long Beach CA.jpg]], or [http://imgur.com/qAU2j this profile-less PNG version] of [[:File:Overijse Processiestraat kerk.jpg]]’s 800px thumbnail (thanks to Kevin Brosnan for the links). --[[User:AVRS|AVRS]] ([[User talk:AVRS|<span class="signature-talk">talk</span>]]) 19:24, 4 August 2011 (UTC)
:: The profile is either misinterpreted or broken (in which case it is used only by Firefox, I guess). If you remove all metadata, Firefox renders the images like the other software. See e.g. history of [[:File:Command and control center Port of Long Beach CA.jpg]], or [http://imgur.com/qAU2j this profile-less PNG version] of [[:File:Overijse Processiestraat kerk.jpg]]’s 800px thumbnail (thanks to Kevin Brosnan for the links). --[[User:AVRS|AVRS]] ([[User talk:AVRS|<span class="signature-talk">talk</span>]]) 19:24, 4 August 2011 (UTC)
:: If I try to expand from what MKFI said, I don't really understand why 120px-Arnhem_station.jpg (bright) and 800px-Arnhem_station.jpg (bright) behave differently from 1024px-Arnhem_station.jpg (too pale) on Firefox 3.6. It seems that Mediawiki removed the profile from the 120px and from the 800 px, but kept it for the 1024 px. Perhaps it is a very rare bug that happened only at 20:27, 4 March 2007 and had already disappeared two and a half hours later when [[:File:Overijse Processiestraat kerk.jpg]] (all thumbnail sizes are too pale on FF3.6) was uploaded ? [[User:Teofilo|Teofilo]] ([[User talk:Teofilo|<span class="signature-talk">talk</span>]]) 14:04, 5 August 2011 (UTC)
:: If I try to expand from what MKFI said, I don't really understand why 120px-Arnhem_station.jpg (bright) and 800px-Arnhem_station.jpg (bright) behave differently from 1024px-Arnhem_station.jpg (too pale) on Firefox 3.6. It seems that Mediawiki removed the profile from the 120px and from the 800 px, but kept it for the 1024 px. Perhaps it is a very rare bug that happened only at 20:27, 4 March 2007 and had already disappeared two and a half hours later when [[:File:Overijse Processiestraat kerk.jpg]] (all thumbnail sizes are too pale on FF3.6) was uploaded ? [[User:Teofilo|Teofilo]] ([[User talk:Teofilo|<span class="signature-talk">talk</span>]]) 14:04, 5 August 2011 (UTC)
::: The 120px and 800px thumbnails were rendered in 2009, before [[bugzilla:19960|ImageMagick was upgraded to a version that preserves color profiles]]. I've taken the liberty of doing an ?action=purge on the image to force them to be rerendered -- if you force a reload you'll see that they now are just like the others.
::: So it looks to me like this is a combination of 1) a few old thumbnails left over from before color profiles were preserved [causing the inconsistencies on some particular images between different thumb sizes] and 2) Firefox's color management mishandling some particular color profiles [thus the very visible difference in this case]. --[[User:Brion VIBBER|brion]] ([[User talk:Brion VIBBER|<span class="signature-talk">talk</span>]]) 08:50, 6 August 2011 (UTC)
This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2024/04.
Please note:
If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.
Purposes which do not meet the scope of this page:
In particular this is relating to the ongoing behaviour of User:Mikhail Ryazanov and his habit of tagging large numbers of others' perfectly good JPEG uploads as if they're somehow not worthy of inclusion here. Latest would appear to be here, re Category:Engravings from Album du Centenaire
Whilst recognising the advantage of SVG (which this crude template suggests, even though it would have no value whatsoever for book scans like this), and the narrow advantages of PNG in some cases, there is no reason why this large number of images should be considered for any form of format conversion. Especially not by drive-by tagging like this, which the uploader is clearly puzzled by, if not downright infuriated (the tagging editor does this a lot, some editors, myself included, considerably resent it).
There are some scans with technical problems, either of the source material (often unavoidable), of the scanning process, of image processing post-scan, and only rarely of the final format. Some of these are fixable, some are fixable after upload by other's collaborative work - I'm certainly grateful to user:A7N8X and his cleanup work to my own Category:Scans from 'The Book of the Motor Car', 1912. If scans are truly poor, then it's reasonable to re-work them, or even to request a re-scanning. The very least of these issues though is the technical format of the file. This tagging as if all JPEGs are too poor for inclusion here is quite unwarranted, and it's especially discouraging to the scanners. It is simply untrue that using PNG will improve quality. This may be seen by the tagger's own uploads, and especially where they have converted others files from JPEG to PNG and re-uploaded, sometimes then even seeking deletion of the original. Winding up the contrast to pure black & white is not always an improved image, even if it often looks "sharper" or "clearer" at first glance. Especially for those working with old or faded source materials, this absolute contrast (the narrow case where PNG might show some real benefit) is unattainable and undesirable anyway.
Is JPEG to be banned from Commons? If so, then ban it.
If not, then lay off this disparaging template, especially when it's used in such a critical and unhelpful manner to others' work. Andy Dingley (talk) 17:24, 13 July 2011 (UTC)[reply]
Those are good scans. And the JPEG conversion makes them worse because of lossy compression, while PNG format keeps them in good condition because of lossless compression.--PereslavlFoto (talk) 17:48, 13 July 2011 (UTC)[reply]
I do not see any problems with those photographs either and I am not sure what people fixing images tagged with {{BadJPEG}} should be doing with them. Converting JPEGs to PNGs is not going to improve anything. --Jarekt (talk) 18:40, 13 July 2011 (UTC)[reply]
Well, I may list several problems with those images. 1) There are small gray dots around any big black dot, seems like they appeared because of compression. 2) There are light spots here and there, seems like the portraits were not retouched. 3) They are not contrast enough, because the image prepared with black ink only cannot contain light gray places.--PereslavlFoto (talk) 18:49, 13 July 2011 (UTC)[reply]
(1) The original dimension is ca 10 cm x 7 cm , the linear enlargment is about a factor 10. (2) Old books have dots, yellowish-grey area's and other imperfections and the old paper was not blank, therefore I added much contrast, removed on the sides parts wich came from neighbouring images or texte (that however gave white side parts, I tried to avoid that) and I did a minimum of retouching. (I let further improvement be done by users of the images). But I still do not understand what you mean by compression. My question: At what stage of the process there was compression and how could i have got a SVG or PNG format without passing by the JPG format first? --Havang(nl) (talk) 19:14, 13 July 2011 (UTC)[reply]
Everything's right! Theoretically speaking, it's better to avoid JPG files from start, and make the photos in TIF or RAW formats. As soon as they are done in JPEG, it is not bad because camera JPEGs are usually compressed with fine quality producing quite big files. Any possible loss can appear with saving the final JPEGs. Yes, it may be tiny and invisible; but with PNG it may not be at all. That's the only difference.--PereslavlFoto (talk) 20:01, 13 July 2011 (UTC)[reply]
PereslavlFoto -- PNG files can theoretically preserve certain fine distinctions which JPEG can't, but with many photographic sources, this theoretical difference really doesn't matter too much in practical terms. And also, PNG files are actually less usable in Wikipedia articles than are JPEGs, since the PNG image resizing algorithm (thumbnail generator) used here is rather poor-quality and inefficient... AnonMoos (talk) 11:25, 14 July 2011 (UTC)[reply]
Yes, the format my originals have too. If you save the google version on your computer, and try to make it as big as my versions, thy look bad. Thanks for explaining those things. So the limit is the quality of my pocket camera: I don't have TIF or RAW format (or I don't know how to programm my camera for that). Finally: ==> Do we keep or remove that badJPEG tag on the category? --Havang(nl) (talk) 20:14, 13 July 2011 (UTC)[reply]
This tag was intended for cases where obviously digital-born diagrams were uploaded as JPEG instead of PNG or SVG, not for scans from paper sources. Digitally-created diagrams exhibit severe artifacts near sharp edges when compressed with JPEG, especially in thumbnails, while scans or photos tend to exhibit enough blur near edges that this isn't a big issue. Also, it's much easier to re-save an existing digitally-created digram as PNG than to obtain a camera that can shoot raw, which was not at all the intention. Dcoetzee (talk) 23:35, 13 July 2011 (UTC)[reply]
Perhelion, aren't you comparing apples with pears... your png-images, blown up to the same picture-dimensions as mine, are worse then mine. Also, converting one of my images to PNG, (opnening in paint and saving as PNG) makes it not better, just makes it four times more bits. But that can every user do with my images, so no need to do it in advance. Having had this discussion, I am convinced that I did a fairly good job at Category:Engravings from Album du Centenaire, and I removed the badJPEG tag. --Havang(nl) (talk) 12:12, 14 July 2011 (UTC)[reply]
all red are potential artefacts However, yes your images are good, but I mean you have edited the pictures, and I don't really believe your camera save with a JPG compression of 75%!? I made a small demonstration for this artefacts (from your original, as you requested) and why PNG images get bigger bits (saved in 24bit, if the PNG would be clean in ~6-8bit it would be smaller than JPG) However in (this high-res) photo like images, this effect is negligible. -- πϵρήλιο℗01:51, 15 July 2011 (UTC)[reply]
Perhelion, I see, you are a professional. Therefore some more questions.
How good a screen do you have, as I don't see on the originals the artifacts you made red?
Being a non-professional, I have run the 2010 HP-mediasmart fotoprogram over all photo's for making it black-white, taking away the yellowish-brown papercolor, and I saw the files go down from appr. 4MB to 1,7 MB, has that something to do with the 75% JPG-compression you are pointing at?
@Havang: (Thanks for the compliment, I'm only a semi advanced) Yes this details are not really recognizable (on this example). @75%: Yes, semi, color-reduction has affect too. @Converted to PNG: this can every normal graphic tool, I used (viewer) IrfanView and Gimp. If you „resave“ a JPG, a PNG choose would „save“ quality, but not improve (if you not do manually improve). Another point is that the thumbnail is compressed again, in addition stronger (but with sharpening), thus acting worse. I used only the Histogram and the Layer feature (coloring), see Wikipedia:Image editing (but it give more sure tricks to do such). -- πϵρήλιο℗00:43, 20 July 2011 (UTC)[reply]
As I said on User_talk:Mikhail_Ryazanov, the purpose of Template:BadJPEG is for diagrams, charts, graphs, computer-generated maps and the like. A large number of User:Mikhail_Ryazanov taggings fall outside those parameters, and actually have no relevance whatsoever to the current JPEG image file specifically, but instead are intended to serve as a marker that if someone were to speculatively and hypothetically do a different scan of the same picture at some time in the future, then it might be best to upload this speculative hypothetical completely-different scan in a non-JPEG format. Unfortunately for User:Mikhail_Ryazanov, that's simply not what the "BadJPEG" template is intended for, which is why his behavior is unconstructive and unproductive. AnonMoos (talk) 11:18, 14 July 2011 (UTC)[reply]
I should repeat my question again: where did you get such a queer interpretation of the BadJPEG tag? According to en:WP:PIFU and Help:Scanning, JPEG is suitable only for photographs, and all other images are to be uploaded as PNG or PNG/JPEG pairs. Why do you think that tagging of images uploaded in a wrong format is "unconstructive and unproductive"? — Mikhail Ryazanov (talk) 20:45, 14 July 2011 (UTC)[reply]
If you read the whole text at Help:Scanning, it points out that JPEGs are good enough, not inherently wrong for scans (and needed in some circumstances, like large files), and once an image is a JPEG (like most on the web) it's generally impractical to convert it. (The English Wikipedia page doesn't discuss scans.) I don't see why these should be tagged, now that the quite fine JPEGs exist, and unless good PNGs could easily have been generated earlier. —innotata21:06, 14 July 2011 (UTC)[reply]
@innotata Help:Scanning nowhere points that JPEGs are good enough. Quite the opposite, it points that PNG is preferable because it's lossless, and quality of JPEGs should not go below 85, when the preferable quality is 95-99. Trycatch (talk) 18:48, 15 July 2011 (UTC)[reply]
Such recommendations are not that helpful, since if you set the "quality" parameter above 95% using libjpeg, it greatly increases the size of the generated file without any meaningful increase in real image quality. From the nature of the JPEG format, even a 100% setting still generates a file with lossy compression. AnonMoos (talk) 10:49, 17 July 2011 (UTC)[reply]
These recommendations make a lot of sense. Yes, even with Q=100 JPEG is lossy, that's why PNG is still better as a lossless format. But that doesn't mean that higher quality settings (>95) do not matter, the quality increase at these settings is tremendous. Trycatch (talk) 01:18, 20 July 2011 (UTC)[reply]
Setting the so-called "quality" parameter to values above 95 results in tremendous increases in filesize, but the actual improvement in real image quality is marginal. Changing the sampling parameters to 1:1:1 can have a much greater impact on real JPEG image quality than futzing around with settings of the so-called "quality" parameter in the 90s (or 100)... AnonMoos (talk) 06:40, 20 July 2011 (UTC)[reply]
"Hard-disks are cheap" (c) Jimbo Wales. There is no point to save server space harming image quality. From my perception JPEG is virtually "perfect" somewhere around 98-99, and I can't call the improvements at 90-97 "marginal" (see the picture on the right). What about sampling -- of course downsampling is more important, but it matters only for colored pictures, while scans are often grayscale. And there is no dichotomy between downsampling and high quality quantization, it's possible to turn off downsampling and to use high quality settings at the same time. Trycatch (talk) 16:23, 23 July 2011 (UTC)[reply]
That image is interesting, but it contains data fundamentally unsuitable for the JPEG format (as opposed to anything like a real photograph or scan). AnonMoos (talk) 14:48, 5 August 2011 (UTC)[reply]
And even there: for example, when the Seattle Municipal Archive releases a map only as a JPEG, what's the point of tagging it as "bad" when it is the only form of the document available? - Jmabel ! talk15:27, 15 July 2011 (UTC)[reply]
If it's indeed a bad JPEG, why it should not be tagged as such? And it will be good if one will take Photoshop or GIMP in his hands and remove the most annoying artifacts. Trycatch (talk) 18:22, 15 July 2011 (UTC)[reply]
Many scanned pages contains diagrams, charts, graphs and so on as well, and look awfully in low quality JPEG compression with all these w:ringing artifacts. I really don't see a point why such scans should not be tagged. Trycatch (talk) 18:22, 15 July 2011 (UTC)[reply]
That is a legitimate concern, but as AnonMoos says, "the purpose of Template:BadJPEG is for diagrams, charts, graphs, computer-generated maps and the like," which would also include scans of those things, as long as they're clear and reasonably high resolution. Any low-res scan pretty much has to be PNG to be remotely legible, and should be tagged with a resolution notice no matter what format it is, not a BadJPEG notice. A scan is only a Template:BadJPEG if the JPEG quality is so low that it creates harsh visible blocks and noise, IMHO. Foxyshadis (talk) 00:59, 16 July 2011 (UTC)[reply]
Are there any actual examples of images tagged by this editor, where the image is at a poor compressions ratio such that artefacts are a problem? Andy Dingley (talk) 21:01, 16 July 2011 (UTC)[reply]
For the map, I can't see the effects you complain of. If anything, I can see a problem with print registration for the spot colours. This won't be fixed by PNG or even re-scanning! Andy Dingley (talk) 13:43, 20 July 2011 (UTC)[reply]
JPEG artifacts are bloody obvious on the both pictures (both blocking and ringing), especially on the map. Of course the problem will not be fixed by converting to PNG, but it's possible to remove the artifacts (make them less visible and annoying) using special filters or by manual editing. Trycatch (talk) 16:23, 23 July 2011 (UTC)[reply]
Is the name of the template the problem here? Just because it's "Bad" doesn't mean it's unwanted; it just means it's not ideal. And for anything other than photographs (which some scans could be considered -- close up photos of a document), it's not ideal. Aren't we agreed on that much, at least? Powers (talk) 18:54, 15 July 2011 (UTC)[reply]
In this context, "Bad" is supposed to have the very specific meaning that the visual nature of the picture is such that it is inherently not very suitable to be captured using the JPEG file format. It is NOT intended to be applied to any random poor-quality JPEG... AnonMoos (talk) 01:47, 16 July 2011 (UTC)[reply]
However looney-crazy-kookoo-whacko you think it is, it seems to be agreed to by a number of active and informed people at Wikimedia Commons -- while you stand alone with your views. AnonMoos (talk) 10:49, 17 July 2011 (UTC)[reply]
I have supported my views by references to Commons and Wikipedia guidelines. Can you give me any factual proofs of your "seems to be agreed to by a number of active and informed people" claims (after I have asked you three times)? — Mikhail Ryazanov (talk) 06:56, 20 July 2011 (UTC)[reply]
Too bad for you that no one other than you agrees with your personal interpretations of such things. "The cheese stands alone" as the old nursery rhyme says... AnonMoos (talk) 12:50, 20 July 2011 (UTC)[reply]
Info For other users: my phrase was: "the drawings are uploaded in JPEG format, which is perhaps the worst imaginable for them", referring to the format, not the scans. — Mikhail Ryazanov (talk) 07:49, 17 July 2011 (UTC)[reply]
Let me now express my point of view on the subject. I believe that tagging of "lineart" scans uploaded in JPEG with BadJPEG:
Does not affect the current use of the images and does not prevent any future use of them.
Attracts some attention to the files, increasing the probability of uploading better versions.
Attracts some attention of all users in general, increasing the chances that the users will be at least aware of the formats and may consider better formats for the future uploads.
Therefore, I do not see how such tagging can do any harm to anyone particular or to Commons (and other projects) in general. At the same time, there are at least potential benefits.
However, the benefits are in fact not just potential. As an illustration, I can point to the related story with this file. While somebody was arguing against my attempts to remove the JPEG artifacts, a more adequate user has found and uploaded a much better quality image.
Regarding my behavior, when I can find the lossless (or just better) original, I do the work myself (unfortunately, do not have enough time now to continue with these PSM illustrations); when I can't — I put the tag in a hope that somebody else will.
The problem is that you don't get it. Just opening a jpg in a graphics programm and saving it as a png does not improve anything because you cannot regain information that was lost by compression. The images that are tagged with BadJPEG have to be redrawn. And that is the purpose of that template. By adding it to other images you are spamming the category in addition to spamming the version history and the file description page. And the effective way to change uploaders behaviour is to notify them timely on their discussion page not to tag images years after they have been uploaded with the uploader long being inactive. --Cwbm (commons) (talk) 10:20, 17 July 2011 (UTC)
Let me quote what the template really says: "If possible, please upload a PNG or SVG version of this image without compression artifacts, derived from a non-JPEG source (or with existing artifacts removed)." There is nothing about "just opening a jpg in a graphics programm and saving it as a png".
I do notify the uploaders of recent files when I find it appropriate, and it does not interfere with the tagging of the files. As for "years" — can you propose any better way to obtain higher quality versions of old files?
Mikhail Ryazanov, you're perfectly confirming the point that I've been making all along -- namely, that your use of the BadJPEG template is actually generally about hypothetical speculative future completely-different scans of the same underlying picture, and not about the specific image file that you're tagging. Unfortunately, that's not the intended purpose of the BadJPEG template... AnonMoos (talk) 10:49, 17 July 2011 (UTC)[reply]
Because image tagging in most cases (including this case) is supposed to be ABOUT THE ACTUAL CONCRETE SPECIFIC IMAGE FILE THAT YOU'RE TAGGING (not about some future hypothetical completely different scan). AnonMoos (talk) 12:53, 20 July 2011 (UTC)[reply]
You're not just applying this to "lineart" images, of the type that most authors recognise ar better as SVG, but also to book scans of old engravings. We could (unproductively) argue the precise distinction for "lineart" and whether engravings fall within this, but in practical terms for scanning old books, the scanner is often working with a grey-scale image that's no longer a simple sharp line. Andy Dingley (talk) 14:27, 17 July 2011 (UTC)[reply]
It does not mean that JPEG (alone) is the desired format. (Before I also gave you references about postprocessing of grayscale scans for suppression of irrelevant information and enhancement of the relevant. Besides other advantages, PNG even becomes more efficient than JPEG after such processing.) — Mikhail Ryazanov (talk) 06:56, 20 July 2011 (UTC)[reply]
While JPEG (alone) is not appropriate for scans, it is not obvious that PNG is always the best choice.
First of all, there are formats designed purposely for scanned images (like CCITT Group 4 and JBIG2 for monochrome prints), and I don't exclude the possibility that they will be supported in future (in principle, even now, JBIG2 can be uploaded in DjVu or PDF container, but this approach has some deficiencies, and CCITT Group 4 is probably (?) supported in TIFF files, but TIFF is discouraged).
Second, it might be possible to produce vector images more or less directly from the paper original. In such case they would be more preferable than PNGs. (And BadJPEG does mention SVG.)
As an example I show a comparison of the already analyzed (see above) Voltaire's portrait in different formats:
JPEG photograph
PNG: simulation of bilevel scan
SVG: Vectorization of the PNG
(Important explanation! These PNG and SVG files are shown only for illustration of capabilities of the corresponding formats. I don't claim that the images are better than the original JPEG, simply because they were derived from that JPEG, and not from the paper original.)
The PNG shows a simulation of 1200 dpi (assuming 900 dpi for the original JPEG) bilevel scan. Such resolution/bitdepth should be enough to capture all relevant details of a black and white picture printed on plain paper and to acceptably reproduce it in print with up two twofold magnification. Notice, that the file size (486 kb) is ~4 times smaller compared to the JPEG (1.93 Mb). CCITT Group 4 encoding makes a 280 kb file, JBIG2 — 212 kb — almost 10 times smaller.
For those with jaggy-phobia, there is a vectorized version, which has smooth lines and can be scaled arbitrarily. The vectorization was quite foolish (I just used the general "trace bitmap" method in Inkscape with almost default settings. The distribution of reference points is probably far from optimal. One would probably also expect separate paths for each element instead of one huge path for the whole contour.), but nevertheless looks reasonably and has not that huge size (the compressed SVGZ is actually ~1.7 Mb — even slightly smaller than the JPEG). More appropriate methods must yield even better results.
So, since there is no unique recommendation about the desired format, and we do not have (yet?) a "make better scan" template, I was using this general BadJPEG.
If someone is afraid of cluttering the "inappropriate JPEG" category, we can add a "type" parameter to the template (like it's done in toSVG), so that the files are placed in corresponding subcategories. However, I don't see it necessary, since if you are browsing all tagged files, engravings are clearly distinguishable from drawings and diagrams even in thumbnails, so you can easily skip everything uninteresting for you. On the other hand, if you are, for example, converting bitmap diagrams or drawings to SVG, then what's the difference between computer-generated and scanned files — in any case you'll have to redraw it manually. -- 09:10, 20 July 2011 User:Mikhail Ryazanov
First off, fax compression (called "Group 4 compression" in the Wikipedia article) only handles pure black and pure white (ignoring all intermediate possibilities), so that it's guaranteed in advance to be very low quality (except with certain extremely restricted and constrained types of image data), and it's quite bizarre (not to mention quite irrelevant) of you to offer it as a supposed serious alternative in this context. Secondly, Wikimedia Commons doesn't really care about filesize in that particular way -- for most cases of imges containing continuously-varying tones, a JPEG with a reasonable choice of image compression parameters will be smaller in filesize than a corresponding PNG (and will certainly generate smaller JPEG thumbnails, since the PNG thumbnail-generation algorithm is rather low performance). So JPEG is more than "good enough" with respect to image filesizes. And the purpose of the "BadJPEG" tag is the same as the purpose of all tags here -- namely, to further the practical goal of making numerous freely-licensed images with possible educational use widely-available. It's not to allow you to compare how 50 different image formats (47 of which are not permitted to be uploaded on Wikimedia Commons) might speculatively hypothetically metaphysically handle the same data. Please consult the remarks I left on your user talk page about "obsessive image-geeking". AnonMoos (talk) 13:12, 20 July 2011 (UTC)[reply]
My view: I made the best I could, expecting that somebody wants to use a portrait printed, he may adapt it by techniques as did User:Mikhail Ryazanov; I found that self-evident, and still consider that tag superfluous on that category but with a side-effect that it chases visitors away from the category. --Havang(nl) (talk) 13:50, 20 July 2011 (UTC)[reply]
Question: is there any utility Commons could run to actually assess pictures for JPEG damage, rather than tagging jpeg willy-nilly? I mean, it's not hard to see the squares in a bad jpeg, and there are certain types of terrain (like foliage) that tends to show it up most. I'd think there would be some way to program a piece of software to see those squares itself, and to give the uploader a little map of the picture indicating the damaged areas. Then you could only pester those uploaders, and provide them the means to see themselves what the problem is. Wnt (talk) 17:38, 24 July 2011 (UTC)[reply]
I doubt whether there's an existing program to detect exactly what you're asking, but there could be programs to detect very crude and coarse quantization; for example, the output of the old command-line "jpegdump" program reports on that. Don't think this would really resolve the issues between Mikhail_Ryazanov and the rest of us, though... AnonMoos (talk) 18:46, 24 July 2011 (UTC)[reply]
I have modified {{BadJPEG}} to indicate that it should not be applied to photographs or scans. If Mikhail really wants to tag scans of line art, they should create a new template for that purpose. Dcoetzee (talk) 18:19, 28 July 2011 (UTC)[reply]
Where? As I understand, at least User:Perhelion (Wikigraphist) and User:Trycatch (administrator) did not show their support for such selectivity. On the other hand, the "BadJPEG haters" did not provide any rational arguments and simply ignored my references to Commons guidelines. In any case, the main question was whether "to tag scans of line art", not how to tag, and it is still not answered (I mean, User:Dcoetzee suggested me to create another template, while the "BadJPEG haters" were actually opposing any such tagging). — Mikhail Ryazanov (talk) 02:30, 31 July 2011 (UTC)[reply]
Dcoetzee, I have a few questions about your modification:
Did you read the resulting message? In my opinion, "...consists of non-photographic data. ...should not be applied to photographs..." sounds a little bit funny, so to speak.
You changed only the English version. If you look at other languages, you may notice that they convey somewhat different meanings. Does it mean that, for example, that Russian map can still be tagged, since the message in BadJPEG/ru perfectly applies to it?
Common sense tells me that the usage instructions should be given in the template's documentation page instead of the generated message. And that they must be consistent with the general regulations. Don't you think so?
I have no idea about what caused it. In the last few days, while reviewing the FAL queue uploaded by UW, I occasionally found some files suffering from that disease, though they were quite rare. But I've never seen such a collection.--- DarwinAhoy!05:12, 21 July 2011 (UTC)[reply]
Hi Rillke, if I understand correctly, what's happening here is that a user is simply selecting lots and lots of licensing checkboxes because they're confused by the licensing process (perhaps they don't even understand the language in the upload form and simply check all checkboxes in the assumption that doing so represents consent). Because of the possibility of multi-licensing, we have to use checkboxes here, and allow for some degree of multi-licensing.
Unless there's something else going on, I don't see this as a bug, and I don't think there's an obvious fix. Sure, we could do some degree of consistency checking on the checkboxes and throw an error, but if the user doesn't speak the language and doesn't understand what's going on, they'll just try whatever combination of clicking works. It may be sensible to create a new Category:Possibly incorrectly licensed for this, and add it when all or most checkboxes are ticked. In that way, UW could actually help detect user problems that probably went un-noticed in the old upload form.--Eloquence (talk) 04:52, 22 July 2011 (UTC)[reply]
On the one hand you are talking about multi-licensing but on the other hand you don't provide an option for multi-licensing for own work. That's actually confusing.
It is nonsense to provide multi-licensing for not own work. Almost always only one license (such as on Flickr or US-Gov) is applicable if it is not own work. On the other hand you are impeding reusing of "own work" by your "new preferred option" and by not providing an option for dual licensing: GFDL+CC-By-SA.
Furthermore, I don't understand why PD-US-Gov is listed in the "german version" and not "PD-german stamp" which is more likely uploaded by a german speaking user. So you prefer the work of the US-government and don't want that from other country's governments? very nationalistic ... -- RE rillkequestions?08:38, 22 July 2011 (UTC)[reply]
Rillke, it's not an accident that the "own work" options are simplified. We're nudging users to stick to one of the three options provided. The case for GFDL/CC-BY-SA dual-licensing is a very weak one at best. The GFDL is not really a license suitable for media files, and we don't want to promote it in the UI. With that said, we're going to add the ability to add custom licensing templates for users who know what they're doing, to make it possible to add any of the myriad templates, in both the own work case and the third party case. That would also ensure that you'll have access to any of the more country-specific templates. (I agree that ideally the experience should be country-optimized.)
The difference between the own work case and the third party case is that, in the own work case, you have a choice whether you're adopting a certain licensing regime, while in the third party case, you are given works with a specific license, and it's in our interest to ensure that the licensing of a given work is correctly recognized. It would be trivial to change the checkbox to a radiobutton there, but do you really believe that would be the right answer?--Eloquence (talk) 21:34, 22 July 2011 (UTC)[reply]
Thank you for the polite reply. "interest to ensure that the licensing of a given work is correctly recognized" - we would call it "de:Elfenbeinturm" or just schmanchy fancy. As you discovered, we have a lot (and too much for a UI) license-templates. Therefore I do not see realistic use of multilicensing. If one of the licenses provided by the source matches, it is enough. It is more likely to me that this feature is abused. Again, I never found a license which is correctly multi-licensed and not own work and uploaded with UWiz.
Concerning Dual-Licensing of own work: We have some uploaders, uploading under GFDL and FAL only. So if you want to combine one picture of those and one licensed under cc-by-sa, you definitely have a problem. -- RE rillkequestions?21:59, 22 July 2011 (UTC)[reply]
Hmmm, how about the user selected those names for the simple reason that he
didn't knew better
haven't had a better name
wanted to obfuscate that those pictures are simply private pictures without any relevance for our project!?!
Oops, I haven't noticed the squall of license templates ... same question as above: Maybe the user did this, don't know why. a×pdeHello!08:24, 21 July 2011 (UTC)[reply]
Have you considered the possibility of asking the guy in question what he did and what was he trying to do. Separate questions, in that order. Palosirkka (talk) 10:35, 22 July 2011 (UTC)[reply]
Wow, Neil was quite rude to you in that bugzilla thread. I'll poke Epolk about this thread and maybe he can explain the steps he took when uploading. Would that help? Killiondude (talk) 22:27, 22 July 2011 (UTC)[reply]
One possibilty, I found out is to "select the license for each file in the next step", then select cc0. You'll get {{self|self or {{self|self|self {{self|self|self|self {{self|self|self|self|self|self dependent on the file-count. And yes this belongs to this bug -- RE rillkequestions?22:33, 22 July 2011 (UTC)[reply]
The other option is to cancel the upload declaring it is not your own work and then selecting a file and uploading this.
Sorry I am a little late getting back on this. Vacations and all that...
Anyway, what I have been doing with the upload wizard is uploading one image at a time. After it uploads, I select "my own work" then click on "use a different license". I select Public Domain then click Next. I add in all the details about the image then finish it off. Apparently, this is creating some kind of weird license loop. For example: File:Yolo County Courthouse.jpg has a license that reads: {{self|self|self|self|cc-zero}}. There is one possible thing that I might have done that contributed to this weirdness. Rather than reselect the upload link, I might have been using the browser back button to go back to initial page of the upload sequence but I am not entirely sure of that.
File:Stele-Gedenkanlage.JPG has been overwritten with a different photo previously removed from an article in de:WP. The common user who uploaded the files seemingly wants to manipulate the article by his action replacing another foto still in the article on commons with the one removed in the WP article. As a result, the other picture had to be removed from the article as well. Is there some policy in commons to undo the replacement in commons? 7Pinguine (talk) 13:03, 24 July 2011 (UTC)[reply]
Thanks for the information and for reverting. I had tried that too but must have done something wrong as it didn't change anything. 7Pinguine (talk) 14:15, 25 July 2011 (UTC)[reply]
Info The same user tried again to delete this image by taking out the license, adding a lack of license template and by uploading a blurry version of this image. Tm (talk) 17:41, 28 July 2011 (UTC)[reply]
License (CC BY-ND 3.0)
I found some photos on Flickr that are licensed CC BY-ND 3.0 [1]. The photos are attributed to the U.S. Embassy Tel Aviv. Can these photos be used on Commons? •••Life of Riley (talk) 22:11, 24 July 2011 (UTC)[reply]
If we look at the EXIF data of the photos in this album, we see that they are credited to an individual. They are not attributed to the embassy, which is mentioned only as the source. Also, if we look at all the albums from the embassy's account, we see that, in some of the albums, the photos are offered under a CC-by-sa 2.0 license and, in other albums, the photos are offered under a CC-by-nd 2.0 license. A priori, we should assume that they know what they are doing when they are tagging their photos. The current licensing implies that the photographers were not employees of the U.S. government taking the photos in the course of their work. And the licensing would be the choice of the photographers (or of the embassy if it acquired the rights from the photographers). But it might be worth the effort of verifying with them. There is always some possibility that they were not paying attention when they tagged the photos. There is a contact address for their web team where they invite questions from users. If you want, you could try to contact them and verify the status of the photos. -- Asclepias (talk) 23:32, 24 July 2011 (UTC)[reply]
No, please DO NOT assume State Department employees understand what restrictions they can impose on images. In the last 2 years dozens of new flickr-ids have been created, which seem to be run by (junior) officials from State, DoD and the USCG, specifically to republish official photos which should all be PD. Most of these flickr-ids inappropriately use "all rights reserved". Some of these officials will change their liscensing when approached with a polite explanation of the US rules on the PD nature of official works of Federal employees. Most ignore those explanations. Initially the flickr-id US Missions Canada uploaded images with restrictive liscenses. I wrote to them and they changed all their liscenses to free liscenses. The equivalent flickr-id for State Department images from Afghanistan uses the wrong liscense, and has ignored all their flickrmail. So, mo, please DO NOT assume State Department employees understand what restrictions they can impose on images. Geo Swan (talk) 13:49, 1 August 2011 (UTC)[reply]
July 25
make gallery images larger?
Any way I can set my gallery images (permanently or ad hoc) so that they look bigger? I'm talking when I am looking at images in a category. They are often so micro, I have to click on them and play with them to see how they will look at a decent size. This is to help selecting stuff for articles.TCO (talk)
The idea will be to organize this effort at COM:NARA (still under construction!). Specifically, each NARA document belongs to a series (the one above is in "Signal Corps Photographs of American Military Activity, compiled 1754 - 1954"), which we have marked with a category. Each series belongs to a record group, which we are placing those record group categories. We should be able to show break the job of categorizing into these smaller series and track our progress in a table with something like Commons:National Archives and Records Administration/Categorize, with the numbers updated by bot. That's what I am working on, but right now of people want to help categorize, you can just watch the bot feed or work off of Category:Media from the National Archives and Records Administration needing categories. Dominic (talk) 18:52, 26 July 2011 (UTC)[reply]
Can we implement a process for error reports or suggestions? In the past I did some work with Category:William S. Soule for example, besides some new versions of NARA files credited to Soule I also saw some files not credited to him but taken by him. Im not a historian and not more than an intrigued reader on this field, but If I can provide a reference for authorship and more accurate date (for example a record in SIRIS), can I report this to NARA somewhere? --Martin H. (talk) 19:17, 27 July 2011 (UTC)[reply]
Per the above thread, I noticed several images in my watchlist that had had "Cateogry" fixed. Is there any way that we could have "Cateogry" made into a pseudo-namespace for "Category"? I don't know how this would work technically, but it's possible to do something like this in MediaWiki. For example, "WP:" is a pseudo form of the Wikipedia namespace in en:wp — whenever you type "WP:" at en:wp, it's automatically treated as if you'd typed "Wikipedia:". I'm asking for essentially the same thing to happen when yoe type or click "Cateogry". Nyttend (talk) 05:39, 27 July 2011 (UTC)[reply]
Not sure you're aware of what's required to get modifications made to the configuration of the wiki. While it's as easy as adding a single line to the configuration, we have to get widespread consensus before the developers will make changes and it will take several weeks to months after a bug report is filed before it is implemented. For 150 typos that we know of that can be fixed. Few even enter categories in by hand anymore with HotCat making it easy to do so. – Adrignolatalk16:12, 27 July 2011 (UTC)[reply]
It's far more than 150 — I'm always typing "Cateogry"; it's just that I usually notice a random piece of text beginning with "Cateogry" and have to make more edits to fix it. Nyttend (talk) 17:07, 27 July 2011 (UTC)[reply]
The pseudo-namespace CAT: is documented on Help:Namespaces, and I fixed my erroneous listing of COM: as pseudo-namespace on this help page: COM: is technically an alias for Commons: or Project:, just like what you find for WP:, Wikipedia: or Project: on Wikipedia. Typos as namespaces make no sense, why not use Special:Prefixindex? –Be..anyone (talk) 14:00, 1 August 2011 (UTC)[reply]
Renaming subcategories of Collections of the Shanghai Museum
The chinese olympic cheerleaders team kindly offered to help to attract comments.
I'm going to do work on the files of this museum, but i prefer to check if cat names are correct before creating the other missing categories, and categorizing files... i don't want to start and than have to go back to all the files to move the cat, you know ? --Lilyu (talk) 10:55, 27 July 2011 (UTC)[reply]
Probably not a good idea in general (although "Furnitures" is wrong, the plural is also "Furniture"). These should be subcategories of, for example, Category:Ancient Chinese Jades, and should fit the pattern of being the same term further qualified by location. - Jmabel ! talk14:57, 27 July 2011 (UTC)[reply]
I'm not sure to understand why you disagree to my proposition:
It works also as you said, specifying Ancient Chinese changes nothing to that. And the subcategories i'm listing are already both inside Collections of the Shanghai Museum and in the respective "typeofart in/of china" (see)
Please, can we get a consensus ? i'm waiting for other advices before working on the shanghai museum. Because i have hundreds of files to categorize, missing collections categories to create (painting, calligraphy, coins, seals, etc) and i'm waiting to know if we keep or not "ancient chinese" to all those subcategories and create the new ones with the same pattern. --Lilyu (talk) 06:40, 29 July 2011 (UTC)[reply]
It's fine - the source and accession number are valuable info, and it's not worth it to modify it just to remove the promotional language. Dcoetzee (talk) 18:14, 28 July 2011 (UTC)[reply]
I would even say that such a promotional text placement in EXIF or similar metadata could be proposed as argument to convince someone to contribute rare images, to convince someone like an archive or a library to donate images... This should be a fair deal for Commons. Grand-Duc (talk) 21:10, 28 July 2011 (UTC)[reply]
Archives and libraries are having a bad influence on Commons. Look at the first version of :File:Patrick Henry in the House of Burgesses - NARA - 532930.tif : they are usurping the artist's authorship, removing the artist's name and putting their own name in a prominent place instead. It is not enough to put their name "NARA" in the file name. They also want to have the picture inserted into 4 categories bearing their name : Media from the National Archives and Records Administration needing categories |Images from the National Archives and Records Administration | High-resolution TIFF images from the National Archives and Records Administration | Media contributed by the National Archives and Records Administration. They ignore the rule not to use cryptic names "Don't use a non-descriptive name like "DSC123456.jpg" : Commons:First_steps/Upload_form#4._Set_an_appropriate_file_name and put their record number in the file name "532930.tif". But that is not enough. They spill all their garbage of reference numbers all over the page : "Record group: Item from Record Group 148: Records of Commissions of the Legislative Branch, 1928 - 2007 (ARC identifier: 477)Series: The George Washington Bicentennial Commission, compiled 1931 - 1932 (ARC identifier: 532858)NAIL Control Number: NWDNS-148-GW-872 Select List Identifier: REVWAR #1 148-GW-872". What is 20740-6001 after 8601 Adelphi Road, College Park, MD ? A postcode ? Do they want to add their phone number too ? Are we going to keep decent neatly presented pages like File:Patrick Henry Rothermel.jpg with a meaningful title, a simple description with the standard Template:Information or is that a nostalgia of a foregone era ? If the future is a future where author names are removed and replaced by a Record creator name instead and garbage meaningless numbers everywhere, this future is totally crazy. Teofilo (talk) 23:10, 28 July 2011 (UTC)[reply]
They didn't remove the artist's name; they labeled it as unknown. Which it is; the person we credit as the author now is merely the painter whose work the engraver copied. The full name is a descriptive one; is it really such a crime to have a record number in there?--Prosfilaes (talk) 00:37, 29 July 2011 (UTC)[reply]
y
I was about to respond similarly...Teofilo, I'm afraid I don't understand your outrage here. The image in question was bot-uploaded with information based on a dump from the NARA database. I sincerely doubt the bot could be smart enough to recognise "P.H. Rothermel" and automatically assign it to the author field (which would be incorrect in any case, as Prosfilaes points out) Further, why is having the record number in the name in any way ignoring the rule to not use cryptic names? There's more to the title than just the record name! Not exactly apples-apples, but when I upload NASA media, I typically include their image ID number in the file name as well. In short, I see nothing wrong with any part of this upload process, other than that the NARA categories might be better off hidden. They are providing high-quality images to Commons, and they've already done the vast majority of the work in fleshing out details of those images. I don't think it is too much to ask that interested volunteers do bits of tidying here and there to fit the descriptions to our norms. — Huntster (t@c)01:44, 29 July 2011 (UTC)[reply]
I am also guilty of adding source information to filenames of images from WGA. It sure makes it easier to keep track of what was successfully uploaded and what did not. Also I do do not thing NARA is doing anything other than allowing wikimedians access to their database. Uploads are done by wikimedians, so we can not blame NARA for formatting. --Jarekt (talk) 01:55, 29 July 2011 (UTC)[reply]
Hey guys, who is this "they"? It's we. :-) I don't even know where to start with that comment, Teofilo. The National Archives has not required or even asked anything from us related to all the documents they are making available. The kinds of things they want to see happen with the documents, like accurate metadata, use on the projects, and topical categorization, are precisely the things that we as a community are already engaged in. Moreover, the National Archives can't require anything of Commons. It's a contributor without any special rights. The way the categories and templates are structured on Commons represents the best attempt of Wikimedians to make it all work within community norms while dealing with the pressures of creating an automated process to import these files, not some dictate from the National Archives. Indeed, the things you have complained about, everything from the IDs in the file names to the categories, have been done at the suggestion of Commons editors themselves. Dominic (talk) 03:07, 29 July 2011 (UTC)[reply]
What you are saying is all true. The problem is why on earth are wikimedians so infatuated with archives and libraries that they want to copy the archives and libraries's habits. In the case of Bundesarchiv there was a secret agreement (there was a press release but the exact terms of the agreement were never publicized) so probably adding the Bundesarchiv brand name in file title names and the Bundesarchiv sorting number was part of the deal. I don't know what the deal with NARA is. There are deals between Wikimedia chapters and archives or libraries. The deals are stronger than wikimedians. Wikimedians can't fight, because the chapters are too powerful. Teofilo (talk) 08:43, 29 July 2011 (UTC)[reply]
I swear, the only phrase that comes to mind is "looking the gift horse in the mouth". I think we like these archives and such because they contain large quantities of historic documents and art, along with associated metadata, that would ordinarily take a very long time to wrangle individually. So, they are providing their expertise in preservation and collection, and are basically getting nothing in return other than a link. I'd prefer to not antagonise them because their name is in the title... — Huntster (t@c)10:28, 29 July 2011 (UTC)[reply]
Not to mention the fact that everything Teofilo has complained about has been for our own benefit. The file numbers and "brand names" (good heavens) are in the filenames for quick and easy identification; that's exactly what we like to see in filenames. The categories are likewise extremely useful for Commons editors. I really don't see any cause for concern here, let alone cause for outrage. Powers (talk) 13:21, 29 July 2011 (UTC)[reply]
One challenge faced by someone writing an upload bot is how to ensure that file name is unique and the technical solution to the problem is to add some source acronym (like NARA or WGA) and their unique accession number so even different copies of the same artwork by the same author from the same source have unique filename. This is the main reason why mass-upload filenames use that format. As for Teofilo's "nostalgia of a foregone simple description with the standard Template:Information" - mass upload use Template:Information when appropriate, but {{Artwork}} and {{Book}} are able to capture much more relevant metadata about artworks and books, as a result they are much preferred for files where such metadata is available. For example, Commons:Wikipedia Loves Art projects often use {{Information}} template with a lot of good image metadata, see for example File:WLA cma Farallon Island 1887.jpg, but the data is practically unreadable in the original format (try to find painters name in the description). As for Teofilo's concern that "author names are removed and replaced by a Record creator name instead" as shown by the first version of :File:Patrick Henry in the House of Burgesses - NARA - 532930.tif. I think this comment refereed to earlier version of {{NARA-image-full}} where author and "record creator" field were placed in the same cell. That was fixed since, so Teofilo's example does not show anymore the issue that (justifiably) outraged him. --Jarekt (talk) 14:16, 29 July 2011 (UTC)[reply]
Perhaps I'm misunderstanding your statement, but I don't see anything in that image's description labeled as being author unknown. There is uncertainty about who the author was, but the U.S. Archive's data is provided. — Huntster (t@c)05:25, 1 August 2011 (UTC)[reply]
@Teofilo: I have on numerous occasions placed the source in the filename and added image source categories when uploading files from a third party, even when I had no contact with or permission from that third party, much less some kind of imagined "deal" (e.g. all files in Category:Google Art Project). This effectively distinguishes them from other digitizations of the same works from other sources, which are quite common on Commons, and lets you browse all works from a particular source, which is useful to both readers and editors. Dcoetzee (talk) 22:06, 1 August 2011 (UTC)[reply]
July 29
Personality rights violation?
I was wondering if this image I uploaded is okay or not regarding personality rights. I took it in a public jazz club in Paris, you do have to pay to get in. Can anyone enlighten me? Richardprins (talk) 15:10, 29 July 2011 (UTC)[reply]
Nothing particularly damaging or derogatory to anyone's reputation seems to be going on, so it's not a serious concern. If the club-owner prohibits photography, then that would be a matter between you and the club, and would not directly affect Commons. AnonMoos (talk) 23:03, 29 July 2011 (UTC)[reply]
Precise rules on this differ in different countries. In the US, certainly this would raise no issues for most uses; the only issue would be if this were used in an advertisement, where it would quite likely require releases by the people depicted. If you want to play it very cautiously, you could add {{Personality rights}} to the image description page, but that's really just a reminder to any re-users that they should give thought to the laws of their respective countries.
Having to pay to get in is irrelevant to the notions of "public" or "private" space in the sense relevant for photography. - Jmabel ! talk06:02, 30 July 2011 (UTC)[reply]
Is there a privilege to vanish and can I (please) exercise it? I don't have a user page, but whatever traces of mine, that you will allow to be deleted, please get rid of.
No drama, just want to disengage and not have a big online profile and not that interested in contributing any more. Would like it cut from all WMF areas if possible.
Not trying to get any content cut. You are welcome to it.
As I understand it a complete user deletion is not possible, but your talk page and other userscape pages can be deleted and user name (possibly) changed. For more information, see meta:Right to vanish. MKFI (talk) 11:32, 30 July 2011 (UTC)[reply]
July 30
July 31
In Public Domain because...
...The author wanted it to be so. I mean, it's not because the rights expired; is not a NASA picture or any other reason but the solely will of the autor.
Problem: the author is not me. ¿Where is the proper template for that? ¿How can I license the picture under Public Domain (as it already was) without saying i'm the owner, or that the picture was made by the Goverment, or whatever? Thank you. --3coma14 (talk) 09:45, 31 July 2011 (UTC)[reply]
I found the template, but wasn't listed in the program used to upload files. I think should be included. Greetings --3coma14 (talk) 09:59, 31 July 2011 (UTC)[reply]
You can use Commons Helper to make transfers from other Wikimedia projects a little easier. (You still need to do a little manual work.) I used it to add some of the source information which you had left out. I also tagged the file on English Wikipedia as transferred. —LX (talk, contribs)11:36, 31 July 2011 (UTC)[reply]
I've noticed that even though there is a SVG metadata format, it displays just a small amount of the information compared to the number of fields you can fill out in Inkscape for example; can't there all filled fields be displayed? I suppose this could also be used to extract information like the author, source or licence (if available) when the uploader doesn't specify them, or the metadata may reveal different information than the one specified by the uploader. Same issue applies to the additional chunks in PNG formats (I use to add them using Tweak PNG).
Also, when in Google Chrome and accessing one of the PNG available size versions of a SVG, except for the 2000px version, there seems to be a problem with the rendering, it doesn't display the said size but an upsized version of the PNG, don't know if this has anything to do with the site. --ANDROBETA15:05, 31 July 2011 (UTC)[reply]
Yes, I've noticed that the metadata table has a "short title" field (which may not be short at all, as in your example) which it fills with randomly chosen information from one of the fields in the image's metadata or with text from the image itself.
In your example it probably took information from the description field, in this one from the publisher or contributors fields, in this one from one of the tags (not the first), in this one from the source field, in this one from the title field and in this one from the image itself. --ANDROBETA16:09, 31 July 2011 (UTC)[reply]
"Inkscape SVG" is not recommended,[3] because unnecessary file size and for reasons of compatibility, amongst other things. "Plain SVG" does not remove metadata. -- πϵρήλιο℗19:46, 31 July 2011 (UTC)[reply]
It says right there, in the link you provided, that it does remove it :P (though I made a test and it really appears not to). However this is not related to the issue/suggestion i brought in this section. --ANDROBETA10:00, 1 August 2011 (UTC)[reply]
You're entering into deeper waters than I was aware of -- I never observed it to pay any attention to the SVG "metadata" (as opposed to the SVG "title" and SVG "desc") at all before... AnonMoos (talk) 11:35, 1 August 2011 (UTC)[reply]
Category question - Science videos vs Videos of sciences
"Science videos" would be videos made by science -- a category which is "<Noun> video" are videos made with that process or method. "Videos of science" would be videos of scientific experiments, outcomes, equipment. So, "Videos of <noun>" would be videos of that noun (or verb -- grammar is not my strong point). See Category:Videos by technique and the problem that I really have created (and shall repair) in Category:Videos of computer design. Several of the members of that category should not be there and should instead be relocated to Category:Computer generated videos.
Is this the proper location at the commons to thank people for their patience during the move? Also, during this move, I have kept my watch list to a minimum, if there are more questions or suggestions or the ever possible spelling problem or other mistake, please contact me on my talk page. (I would like to actually accomplish this task rather than talk about it ;) ) -- Queeg (talk) 21:37, 1 August 2011 (UTC)[reply]
User Queeg is doing a reconstruction and harmonization of standards of the video categories (great work!). During this time there may exist some categories in the old form and also in the new form (Videos of ...). For more information feel free to contact him directly. Regards, --Pristurus (talk) 21:19, 1 August 2011 (UTC)[reply]
Queeg, I have to disagree with you concerning the difference between "Foo videos" and "Videos of foo". From a semantic point of view, I don't think it can be said that the first category unambiguously relates to videos made by foo, and the second category to videos about foo. For example, the term "Gorilla videos" does not necessarily only refer to videos made by gorillas. Even if you disagree with me on this, I would say that the distinction is too subtle. You will either have to add a usage note to both of the categories explaining how they are to be used or, preferably, use a clearer category name (such as "Videos of science experiments").
While I agree that "foo videos" doesn't necessarily mean that foo made those videos, in the case of your example, those videos not made by gorillas would simply be relocated to "Videos of gorillas". It's just one of those things that have to be examined on a case by case basis to determine which naming style is most appropriate. But having a declaration of intent for each type of category is invaluable to editors and end users. — Huntster (t@c)04:58, 2 August 2011 (UTC)[reply]
Some of this can be resolved with more specific naming than just "X videos" and "Videos of X", for example "Videos by X" or "Videos produced by X", etc. The basic distinction between "videos by production technique/author/source/etc" and "videos by subject" makes good sense, but the distinction ought to be clear in the category name itself, if at all possible. Rd232 (talk) 09:27, 2 August 2011 (UTC)[reply]
blocks and clean slates...
I'd like some input over the issue of when a contributor who has served out their block is not entitled to the assumption of good faith, and a clean slate.
I've had a discussion with another contributor over whether a third contributor merited AGF.
That third contributor came off a long block, for persistently uploading certain kinds of images, in the face of community consensus the images weren't in scope. When that block was over that blocked contributor up0loaded some images.
My correspondent acknowledged that all those newly uploaded images were within scope, with one single exception.
They nominated that one image they had concerns about for deletion, which I have no problem with, although I disagreed with their concern.
I was concerned that the nomination brought up again the problematic images the formerly blocked contributor uploaded that triggered the block -- even though the new image had little in common with the earlier problematic images.
Because I don't want to seem to be forum shopping, I won't name the deletion discussion, or the identities of the other parties here.
I'd like input from others on something I wrote in this discussion. I suggested that since the block was over, and the concern that triggered the new deletion discussion had nothing in common with the concerns that triggered the block, that it was a mistake to mention the block in the deletion discussion.
If the concern that triggered the new deletion nomination was similar to the concerns that triggered the block, mentioning the block would make sense.
So, once a block is over, should a formerly blocked ocntributor be able to expect a clean slate -- the assumption of good faith?
In general I really do like AGF and I think anyone who contributes positively (on this project) should be encouraged. Such a view tends to set us apart from that "other place" I guess as does the general lack of policy in some areas.
As a general rule if someone uses an alternative account for a fresh start it is sensible to inform some of the projects CUs just so they don;t get the wrong idea and that has happened before.
IMO Assumption of Good Faith should not be thought of as some absolute that is either there or not there. In practice, it is more like a sliding scale. Double checking each others work is common on Commons. Even the most experienced contributors with excellent records can make occasional mistakes. Some who has been blocked should probably expect that at first they will be watched to make sure they learned from their mistake rather that repeating whatever got them blocked. If they are making good and proper contributions, their AGF will grow over time. Infrogmation (talk) 16:30, 1 August 2011 (UTC)[reply]
There's not really a concept of a contributor having "served their time." If they return and re-commence the behaviour for which they were blocked, of course it is relevant that they were blocked for it in the past, as this speaks to a pattern (e.g. we often depend on user reputation when considering the merits of "own work" assertions). In a case where it's not actually the same behaviour, people in the discussion should raise that point, and the closing admin should take that into account. Dcoetzee (talk) 22:00, 1 August 2011 (UTC)[reply]
On English Wikipedia we have w:Wikipedia:Geonotices, where location specific messages can be displayed to users. Many of these notices are GLAM related, so they would be more relevant here on Commons. Also as Commons is where the languages come together, it would be useful for Commons to run geonotices which might be relevant to people of different languages. For example, an event in Canada might be relevant to English and French speakers. An event in Europe could be relevant to people of the many languages of Europe.
Absolutely Geonotices are a useful communiction tool, more effective then banner notices and would be an effective tool to assist in notifying whn transaltion assistance is required Gnangarra01:49, 2 August 2011 (UTC)[reply]
Whorled Loosestrife: Lysimachia quadrifolia
Have a look at your wiki page with the above specs.
Your plant has leaves in whorls of FIVE
Quadrifolia implies leaves in FOURS
Why is not your photograph labelled lysimachia quintifolia (for FIVE)? — Preceding unsigned comment added by 79.123.71.6 (talk • contribs)
This is from New England Wildflowers, A Guide to Common Plants p 174 by Frank Kazmeric:
"The leaves are in whorls from 3-6 (most commonly in 4)."
I have also seen this in other references, but they are not handy now. If need be, I can produce them. Having five leaves does not disqualify a specimen from being Lysimachia quadrifolia. There is no such plant as L. quintifolia. Please restore the category as it was, as it was correct! --Jomegat (talk) 00:03, 2 August 2011 (UTC)[reply]
I improved and replaced the image meetjeslandlocatie.png , but after uploading the old image stayed visible. I uploaded again, and now my previous upload changed to the improved image, and my new upload was again like the old original image. So I clicked revert on the penultimate upload. Now this one showed the old image again...
I gave it a few days to see if maybe something had to be processed, but it's still like that.
The image is only used on three to four wiki's. Should I wait untill this fixes, or just start a new file and replace it on these wiki's?
Please go to File:meetjeslandlocatie.png and then Please purge your browser’s cache or enable JavaScript in your Browser's settings. (You only need to do it once.)
I have successfully applied ImageAnnotator on my gallery images as instructed in the Help page but when I select it and cut and paste it to my Wikiarticle it doesn't transfer. My browser is Google chrome and windows 7 PC is my operating system. Beyond that I don't know what you need to help me.Thank you for any guidance you can give me. This gadget looks very useful for many articles I have planned. Mlane18:32, 2 August 2011 (UTC)[reply]
The article is en:Château de la Motte, Joué du Plain. It is a line drawn map of the Chateau. Maybe I misunderstand something, but I thought that the images at wikicommons were primarily for wikipedia articles. I'm not sure why I would want to annotate an image solely for wikicommons. Please enlighten me.
For some reason the above link says there is no article. I'm not sure why. I visit the article daily to work on it.Mlane 10:19, 4 August 2011 (UTC)
Imageannotator is installed in en.wp but you have to enable it in your settings and it does not work in the article namespace. Ask your local administrator to enable this feature in wgNamespace == 0, too. -- RE rillkequestions?11:18, 4 August 2011 (UTC)[reply]
adding categories
I'm new to this and I've added numerous images, and I thought I gave them categories but a bot tells me otherwise. After several, what I would consider common sense searches and poking around, I still can't understand how I am to update my images with new categories. Please explain.
As a general issue, I've observed throughout wikidom, there is too much information in some places; I'm overwhelmed. Often it is hard to tell what to do, or I can't find the answer to what must be common questions. Thankfully everyone is willing to help. Thanks for the for whatever guidance you can give me. Mlane 18:49, 2 August 2011 (UTC) -- User:Mlane78212
I've found a template at Commons:Upload which points users to the new UploadWizard. Since the former is English-only (I think) and the latter is translated into at least some other languages, the template, {{UploadWizard}}, should be translated into other languages. I've listed it at {{Requested translations}} but I mention it here because it seems rather important. I've made the template use LangSwitch, so it's easy to translate, and it's just one line. NB I've already done the German translation. Rd232 (talk) 22:23, 2 August 2011 (UTC)[reply]
If there are no responses to this, I might do some other languages... probably not very well. Crappy translation still better than no translation here, I think. Rd232 (talk) 08:47, 5 August 2011 (UTC)[reply]
Dunno, more than one language is a good start, the +/- or similar link should be clear for folks wishing to add more languages. I tested the procedure on a new polling Template:Merge_icon some weeks ago, if you know the "correct" de:w: terminology please fix it. –Be..anyone (talk) 10:08, 5 August 2011 (UTC)[reply]
August 3
Pale photos
I have seen that a few photos are very pale. For example this and that one. This one showed before also a pale large image, but now it is normal again, but the thumbnail is still pale as also in the Wikipedia page. I wonder what is the cause. If needed I can re-upload the photos. Wouter (talk) 09:08, 3 August 2011 (UTC)[reply]
That's very weird. I assume you uploaded the correct versions of the photographs? (Or there is only one version?) — Cheers, JackLee–talk–09:17, 3 August 2011 (UTC)[reply]
I see two of them really pale. The third one is normal, but if i click on it to get the full size version, it is very pale too. Same with the tiny image in the upload log. Too high brightness. I'm pretty sure there's nothing wrong with the image, it might be some new bug on mediawiki. When i download the photos to my hardrive, they are normal. --Lilyu (talk) 09:18, 3 August 2011 (UTC)[reply]
I guess it’s some metadata in the file, which changes the brightness, and is supported by one viewer but not the other. Looks pale in my Firefox, but OK in Geeqie and Gwenview. Did you ever change brightness of the file before uploading? --AVRS (talk) 10:24, 3 August 2011 (UTC)[reply]
All files contain "Nikon D70 generic V2" color profile, possibly this is the culprit? Pale colors show in Firefox 3.6, but looks ok in IE 8 for me. MKFI (talk) 10:55, 3 August 2011 (UTC)[reply]
I checked a few other photos uploaded in the same period all with "Nikon D70 generic V2" color profile. Indeed again pale photos (in Firefox 5.0.1 on Macintosh) but for example this photo shows normal behavior for the 800x532 pixels and the thumb nail, but the full resolution is very pale. Photos with an other color profile did not show the "pale behavior". Wouter (talk) 12:13, 3 August 2011 (UTC)[reply]
I think the thumbnails are actually fine -- the color correction rather seems to depend on the browser. Both the full-size and thumbnail files render too pale in Firefox 5.0.1 on Mac OS X 10.7, and both sizes render correctly on Safari 5.1 or saved to disk and loaded in Preview on the same machine. Perhaps Firefox is either ignoring or misinterpreting the color profile? Is there a particular browser/version/os combination that you're using that shows different results on different files? --brion (talk) 17:26, 4 August 2011 (UTC)[reply]
If I try to expand from what MKFI said, I don't really understand why 120px-Arnhem_station.jpg (bright) and 800px-Arnhem_station.jpg (bright) behave differently from 1024px-Arnhem_station.jpg (too pale) on Firefox 3.6. It seems that Mediawiki removed the profile from the 120px and from the 800 px, but kept it for the 1024 px. Perhaps it is a very rare bug that happened only at 20:27, 4 March 2007 and had already disappeared two and a half hours later when File:Overijse Processiestraat kerk.jpg (all thumbnail sizes are too pale on FF3.6) was uploaded ? Teofilo (talk) 14:04, 5 August 2011 (UTC)[reply]
The 120px and 800px thumbnails were rendered in 2009, before ImageMagick was upgraded to a version that preserves color profiles. I've taken the liberty of doing an ?action=purge on the image to force them to be rerendered -- if you force a reload you'll see that they now are just like the others.
So it looks to me like this is a combination of 1) a few old thumbnails left over from before color profiles were preserved [causing the inconsistencies on some particular images between different thumb sizes] and 2) Firefox's color management mishandling some particular color profiles [thus the very visible difference in this case]. --brion (talk) 08:50, 6 August 2011 (UTC)[reply]
Edit page of retired user
Is there anyone who can edit this page? To me it only dipslay the source code. The problem is that this template contains a category that has become obsolete, and to change the category of all the images we need to change that template. The user has retired so I cannot ask him. -- H00521:18, 3 August 2011 (UTC)[reply]
Hello. :) If any project is keeping up with this, I'm sure you guys are, but as the dates are approaching, I wanted to make sure that everyone knows (or remembers).
The Wikimedia Foundation, at the direction of the Board of Trustees, will be holding a vote to determine whether members of the community support the creation and usage of an opt-in personal image filter, which would allow readers to voluntarily screen particular types of images strictly for their own accounts. The referendum is scheduled for 12-27 August. You can read more about it at m:Image filter referendum/en; if you are interested in weighing in, you may especially want to review M:Image filter referendum/FAQ/en. Your participation there will be very much appreciated in helping to determine the approach to this. Thanks, and my apologies if I'm reminding you of something you all remember very well. :) --Maggie Dennis (WMF) (talk) 13:33, 4 August 2011 (UTC)[reply]
How to replace and earlier .JPG file with a .PNG version of the same name?
I plan to replace some of my earlier .JPG uploads with clearer .PNG versions IN THIS CATEGORY. All images are grayscale, and the replacements have identical names, save for the extension. Because of this, the feature Upload a new version of this file will not accept the replacement. Can this option be modified? Otherwise, I have to upload the new images and then ask for a duplicate delete which doubles the processing time. Ineuw talk page on en.ws 20:49, 4 August 2011 (UTC)
Dcoetzee, thanks for the info however, I must say that this is a very annoying issue. After uploading about 5,000 .JPG files, in April 2011, many of my uploads were marked as {{BadJPG}} by User:Mikhail_Ryazanov. HERE IS THE DISCUSSION ON HIS TALK PAGE. I also noticed an extensive post about this issue above on June 15. There must be some common agreement between the administrators as to the instructions given to the contributors. Now, I have no clue as to what to do as I have some 5-6,000+ more images to upload. Please advise and thank you.Ineuw talk page on en.ws 01:41, 5 August 2011 (UTC)
Unless there are visual or technical problems with the files you've previously uploaded (and I see none), then I see no reason to replace those files with PNGs. Leave them be, and just start uploading PNGs for future editions. Ultimately, the choice is yours as to which format you prefer using. They both have their positives and negatives. — Huntster (t@c)03:35, 5 August 2011 (UTC)[reply]
Thanks for both comments. There are no problems with my original uploads, it's only that I became better at using the software tool when prepapring the images. At times, I feel that some of my earlier efforts could be improved. Based on this post, I will replace .JPG with .JPG and save time. I will continue new uploads as .PNGs because since May, I've set myself accordingly. At least 50% of the images are still drawings and the most photos are of less than desirable quality. Everything is grayscale and all from the 19th century. Thanks again.Ineuw talk page on en.ws 03:58, 5 August 2011 (UTC)
Ineuw -- look above under "June 15" to see how User:Mikhail_Ryazanov holds a minority opinion here. I really wouldn't re-upload thousands of files just to satisfy his objections alone... AnonMoos (talk) 14:40, 5 August 2011 (UTC)[reply]
@Dcoetzee's „I recommend continuing to use JPEG thumbnails in articles, because the filesize is smaller and they are appear sharper due to JPEG thumbnail postprocessing.“ I do not share this recommendation for figures and diagrams. The JPG compression artifacts in the thumbnails are very ugly in many cases. See also my related proposal. --Leyo07:41, 5 August 2011 (UTC)[reply]
Quite a few of us have criticized Mikhail Ryazanov for his overuse of this template. Both formats are useful. I would agree with Dcoetzee above that the ideal is to upload both and use the cross-linking templates, but I don't think there is a solid consensus to prefer one to the other. In general, JPEGs to better on photographs of things found in nature; PNGs do better on things with sharp lines, such as most logos and some other graphic design. PNGs also do better if they have to undergo numerous subsequent edits. If I have to upload only one, I usually go for the JPEG. On low-quality images, it hardly matters. Just do either one. I suppose that one advantage of a PNG is that someone can typically make a higher quality JPEG from an existing PNG than vice versa. - Jmabel ! talk15:04, 5 August 2011 (UTC)[reply]
Appreciate very much all this info. Thanks to all.Ineuw talk page on en.ws 15:24, 5 August 2011 (UTC)
August 5
my gallery has not functioned for several days
I uploaded around 20 plus images last week and the heading said delays of several days expected. No new images appeared. I was in no hurry, but my gallery has not functioned since. Only one appears on each page and a strange code appears in bold colors as a headline. What is going on?Mlane (talk) 20:11, 5 August 2011 (UTC) Mlane[reply]
Uploading tools like UploadWizard and Commonist may be unable to complete uploads. The administrators are working to fix this problem. The Commons:Upload form is not affected.
There is currently a problem with thumbnail generation when images are replaced/updated, a solution is being worked on.
System notices:
Uploading tools like UploadWizard and Commonist may be unable to complete uploads. The administrators are working to fix this problem. The Commons:Upload form is not affected.
There is currently a problem with thumbnail generation when images are replaced/updated, a solution is being worked on.
System notices:
Uploading tools like UploadWizard and Commonist may be unable to complete uploads. The administrators are working to fix this problem. The Commons:Upload form is not affected.
There is currently a problem with thumbnail generation when images are replaced/updated, a solution is being worked on.
This is very annoying: a page loads, you attempt to click on some item of interest, and then it skips down two inches because the javascript kicks in, displaying the same pair of notices three times each. Your mouse pointer hits the wrong item, you go to the wrong page. Curiously, the message pair only occurs once in the page source, in the var siteNoticeValue. --Redrose64 (talk) 23:15, 5 August 2011 (UTC)[reply]
_artifacts.png)
Comment Mikhail Ryazanov is trying to jump discussion to Commons:Administrators'_noticeboard/User_problems#User:AnonMoos. --Jarekt (talk) 21:22, 14 July 2011 (UTC)
Info For other users: my phrase was: "the drawings are uploaded in JPEG format, which is perhaps the worst imaginable for them", referring to the format, not the scans. — Mikhail Ryazanov (talk) 07:49, 17 July 2011 (UTC).JPG)
.png)
.svg)
-- AnonMoos (talk) 14:48, 5 August 2011 (UTC)
--Lilyu (talk) 10:55, 27 July 2011 (UTC)
.jpg&action=edit&redlink=1){kind=link}
I was wondering if this image I uploaded is okay or not regarding personality rights. I took it in a public jazz club in Paris, you do have to pay to get in. Can anyone enlighten me? Richardprins (talk) 15:10, 29 July 2011 (UTC)
