Commons:Graphics village pump

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


  Welcome to Commons   Community Portal   Help Desk
Upload help
  Village Pump
copyright • proposals
  Administrators' Noticeboard
vandalism • user problems • blocks and protections
 

Graphics community: Graphic Lab · Graphics Village Pump · Picture Requests · Photography Critiques

color palette logo Welcome to the Graphics village pump!

A village pump

Hello and Welcome to this Graphics village pump of Commons. This Graphics village pump aims to provide help and information about the several Graphic Labs spread in the Wikipedias, and to be the technical support forum for all the local Labs, graphists (graphic artists), and users interested in graphic works, and is a page where graphists and users from all the Labs can talk about graphics, tutorials, graphic software, help to build new Graphic Labs, etc. Also for exchanging opinions, ideas, protocols, and ways of improvement.

See also: Other graphic community pages (list on top) | Graphics abilities page | Graphic Tool | Project Insignia | Stroke Order Project | Current requests/discussions

Important discussion pages (index)
Gnome User Speech.svg



Graphics village pump archives
Monthly archives
2007 - - - April May June July August September October November December
2008 January February March April May June July August September October November December
2009 January February March April May June July August September October November December
2010 January February - April May June July August September October November December
2011 January February March April May June July August September October - December
2012 January February March April May June July August September October November December
2013 January February March April May June July August September October - December
2014 January February March April May June July August September October November December
Topic-specific archives

Creating SVG graphs X (usually a date range) vs. Y data[edit]

Many of the png or jpg graphs are tagged {{svg}}, and I am trying to learn how to create these in SVG, having created many of these in png. I would like to include the data in the file, like in File:World Reserves to Production Crude Oil.svg, but using a scale makes the line look like a ribbon instead of constant width. In svg 1.2 there is a non-scaling parameter, <path vector-effect="non-scaling-stroke", will this work, and do I need to change the first few lines of the file to say 1.2 instead of 1.1? The file that I ran into this with was File:US Proved Crude Oil Reserves.svg, which I wanted to use

 <g transform="translate(0 580) scale(6 -.012) translate(-1899 0)">
 
  <!-- reserves -->
  <path style="fill:none; stroke:#00A4EA; stroke-width:4" d="
M 1899 2500
L 1900 2900
L 1901 3000
L 1902 3200
...
L 2012 30529

but the line came out looking like a wide ribbon. The multiple uploads were because it looked fine in Inkscape, but was trashed in a browser and after uploading. Also is there a way of creating semi-log graphs on the fly like this as well, or even both in the same image, such as File:Wind generation-with semilog plot.png? Also if there is a way to do this with pie charts that would be helpful too. Are there any samples that can be copied (PD only)? Can information about how to create a simple chart be added to Help:SVG, or at least to the examples? Delphi234 (talk) 20:20, 8 June 2014 (UTC)

Hello Delphi, good that you ask. Unfortunately you use a scale(6 -12) so the stroke get transformed (if the x/y scaling is near the same then it's ok). MediaWiki don't support SVG 1.2. If you have more questions ask only. Greetings Perhelion     23:00, 8 June 2014 (UTC)
Okay, for now I will use SVG 1.1. In this case I changed to a scaling near the same for x:y, and divided all the y values by 100. If an area plot is used, the issue does not appear. (start at M 1899 0, end with V 0 z), but an area plot is not always appropriate. Delphi234 (talk) 23:25, 8 June 2014 (UTC)

If someone could look at File:Global Wind Power Cumulative Capacity.svg that would be helpful. Would this look better with a fill for the bars (use a narrow dark border for each bar, with a blue fill)? That is a lot more code but is it worth doing, or is this acceptable? Would adding minor grid lines for 10, 20, 30, 40, etc. be useful, or would it just add clutter? Delphi234 (talk) 16:44, 9 June 2014 (UTC)

It looks very good as it is. How do you create this SVG, with a script language and text-editor? How do you create the PNG diagrams? Some editors can export to vector-data. Perhelion     18:26, 10 June 2014 (UTC)
I create the PNG diagrams (can not answer how MW creates the PNG ones from SVG charts) using Open Office Calc. I create a chart and then cut and paste it into Microsoft Paint, which I use to add the labels (chart size has to be the same as the size in Calc). I created the SVGs by copying an existing PD SVG chart and modifying it, to change it to a line chart instead of an area chart (remove the M 1990 0 at the beginning and the V 0 z at the end, change fill to none). Each time I make a new one I start with the most recent one and modify the scale first to get it to fit, then work on each other feature. To keep the lines from being ribbons I scale the data as needed. All of it is done by hand one element at a time. The data is copy and pasted from Calc. I locate the highest X and Y legend first, and then divide the difference to the lowest one by the number of legend spacings to space each. Sometimes I move them by a pixel to make them look better. The lines are automatically correctly placed. In some cases I copied the same colors that were used by Calc. There are a very large number of charts that can be converted to svg. Being able to see the data in the source code is a significant advantage, particularly for ones that get updated. Delphi234 (talk) 17:58, 12 June 2014 (UTC)
Mmmh, you specified font-family : Verdana, Tahoma, sans-serif; – all sans-serif fonts as far as I can see (which is the right choice for diagrams). So why on earth are the preview-pngs rendered with a serif font? Bug in the renderer?
If this was supposed to be published in a scientific journal, there would be some changes I'd suggest (but feel free to ignore them):
  • I'd make the labels (of the axes, if possible also those above the bars) much bigger. Try printing it at the size it would have in a (scientific) publication, e.g. smaller than half an (upright) A4 sheet (or a horizontal A7 ;-) ), and see if it's still readable.
  • data-ink ratio (aka "get rid of everyting you don't really need"):
    • The vertical ticks on the X-axis don't make sense to me. They don't really serve any purpose, so I'd simply get rid of them.
    • Grid lines are very uncommon in scientific publications. Since you have labelled the single bars with their values, the horizontal lines are quite redundant → get rid of them
    • The box (top and right rule) is unnecessary as well
Well, and then there are lots of people telling you that bar plots are evil and you should always use line graphs instead ;-)
Cheers, --El Grafo (talk) 12:49, 11 June 2014 (UTC)
The first try looked fine in Inkscape but the lines were trashed in the browser and on here. The font size used was a default of something which was not picked up, so I added explicitly setting it to 20 for each number. I see that a different font style is displayed by the SVG in the browser than in the PNG renderings. I think that is what is referred to as the serif font in the preview-pngs.
This code appears to be ignored by the PNG rendering:
text {
	font-family : Verdana, Tahoma, sans-serif;
	font-size : 20px;
	fill : black;
	stroke : none;
}
On the PNG charts I have normally used 24 or 36 for the title and 16 for the axis labels. Normally the number of font sizes used in a chart should be relatively small, as in two or three (or four) for example. I can try using 36 for the title and 24 for the labels. By vertical ticks, these are the tick marks that go below the zero axis? In the PNG charts I have been including not only rulings, but sub-rulings in the charts, so that if someone wanted to know, say, the value in 2008, they could locate it more easily, and read it off of the chart. Published charts that do not include lines actually annoy me because it is very hard to estimate values - but I agree that including them is out of the question. (In the lab, finely lined graph paper is used - for publication, a blank sheet of paper is used, with only the graph elements needed.)
I have recently discovered Template:SVG Chart and am trying to get up to speed with using it instead. Delphi234 (talk) 17:58, 12 June 2014 (UTC)
To make it hard for you to decide Face-wink.svg (in case you don't switch to the mentioned template anyway):
  • I liked the vertical grid and would keep it.
  • I liked the horizontal ticks and and would keep them.
  • I liked the box (upper and right border) and would keep it.
What I can agree on with El Grafo is that
  • Font size of labels should be large (suppose you want to include the image in an article; some users might want to be able to read it without having to expand the image first). Also font sizes of axis labels and axis ticks should be in sync.
  • Changing of dimensions might be worth a thought. Most of the time landscape plots aren't really useful. E.g. square plots make use of the given space much better in most cases (and even more so when embedded in articles).
  • Optionally you could even think about abandoning the caption (inside articles the caption is redundant to the thumbnails description anyway; on Commons the file name itself can replace the caption).
--Patrick87 (talk) 19:29, 12 June 2014 (UTC)
As I said: Feel free to completely ignore what I wrote up there. Removing those things would be more or less standard in a scientific publication, but of course that doesn't mean it has to be done here! --El Grafo (talk) 13:55, 13 June 2014 (UTC)
@Text CSS "font" bug: this is well known but nobody has reported this, so I did (see above, also someone has removed it on HELP:SVG I put it in again).[1] Use the group tag instead. Perhelion     19:40, 12 June 2014 (UTC)
I am not likely to re-do an existing SVG using the chart template, so anything that exists is unaffected by using it. The only exception is a chart like File:Annual electricity net generation in the world.svg, which is not easily updated with current data. For that one I have downloaded Gnumeric, to explore using it to update the chart. The wind chart started out when there were three less years to plot, and will eventually either need to be a line chart or limit the number of years plotted. Abandoning the captions actually has a significant advantage that there is no translation needed to other languages, or most other languages. Most SVG charts though, are easily translated into other languages. My guess is that it is easier to have several variations of the same chart instead of trying to find options that everyone agrees with. I would like to find a solution to the font style issue, and unless there are other objections will restore the lines and ticks. The years have to be a fairly small font size because there are so many of them; should the word "Year" be the same font size as that used for the years? And the Y axis legend the same font size for the words and numbers? Delphi234 (talk) 20:01, 12 June 2014 (UTC)
Regarding translation you might want to look into multiple translations within one SVG file using <switch> elements.
Regarding font size: Yes, I'd make all labels exactly the same size. If one can read one label at a specific size, one can read all other labels at that size. Therefore it doesn't make sense to mix different sizes, because it will always result in either a) the larger parts being huge as soon as one can read the smaller parts or b) the smaller parts being unreadable if the large parts are scaled to normal size. You're right that in this specific case it's hard to achieve this ideal case, but it wouldn't be fun if there were no "challenges", would it? Face-wink.svg --Patrick87 (talk) 21:14, 12 June 2014 (UTC)
Added translations from English to Chinese, German, Spanish, French, Italian, Danish, Portuguese, Swedish, and Japanese to File:Global Wind Power Cumulative Capacity.svg. I only understand English, so if someone could look at the other languages it would be helpful. In some cases the PNG for this file is used on the Wind power article in that language, and I copied the legend there. Adding switch was relatively easy. Delphi234 (talk) 03:57, 13 June 2014 (UTC)
German version looks good to me. --El Grafo (talk) 14:05, 13 June 2014 (UTC)
Could rotating the labels for the years 90° counter-clockwise be an option to yield more space for a bigger font size? --El Grafo (talk) 14:00, 13 June 2014 (UTC)
Yes, or even 45°. I think I will wait for next year to do that though, although of course anyone else is free to make any modifications they see fit, including that. I have to say it was a lucky guess on the correct German! I hope the commas are appreciated too. Delphi234 (talk) 15:55, 13 June 2014 (UTC)
Actually, I didn't notice the commas until now, but yes, that's very much appreciated. (Although personally I have grown to hate the fact that our conventions are different. It's a real pain to work with if you've got data from different copuntries/persons – especially if it's in CSV format Face-wink.svg) --El Grafo (talk) 09:46, 16 June 2014 (UTC)
Let me also suggest additional some things (after analysis of this file I made 2 bug reports):
  • Change the current <desc> to <title>, the bottom comment (with the lang desc) to <desc> so everyone can see the current languages on the file-page in the "Metadata"
  • The use of clones is good, but the baddest possible case (imo) is to use a clone for a very simply line. So convert please all to path (the code size should now be the half or lesser).
I replaced all PNG presentations of this with this SVG version (but not yet with the lang switch option (only in fr). I mean this should be somehow a default parameter on each local Wiki)
Good working, keep on. :) Perhelion     05:29, 17 June 2014 (UTC) PS: I mean the title could be someting wrong?:P Perhelion     06:45, 17 June 2014 (UTC)
I think the language has to be specified when used or it is lost. I could not figure out how that was supposed to work - if someone using another language could say whether they are seeing the correct language or English it would be helpful. I think that theoretically it is supposed to render in whatever language the viewer prefers, but in practice I do not see that happening (an Italian speaker going to an English page with the chart would see Italian, but an English speaker would see English, but if the page said that everyone viewing it should see it as English, that is what everyone would see). Also, as mentioned, the translations might look Googlish. Now that it is in use in a large number of places hopefully there will be some feedback, but unfortunately most people just say - oh, that looks strange, and leave it that way. My guess is the talk page will stay empty almost forever - unless someone starts it. But the collaboration has been very much appreciated. Delphi234 (talk) 08:18, 19 June 2014 (UTC)

SVG 1.2[edit]

A general comment on SVG version 1.2: The 1.2 "full" standard is not formally adopted, has not been updated in over nine years (13 April 2005), and it seems will never be adopted. The SVG "Tiny 1.2" process was highly productive and influential, but the "Full 1.2" has not been (other than introducing some incompatible junk into Inkscape, such as "flowtext" nonsense)... AnonMoos (talk) 00:03, 14 June 2014 (UTC)

World energy consumption[edit]

I am working on some other translations of charts that were created from the template, and it seems easiest to just translate the rendered SVG directly, and ignore trying to create a new SVG source in the other languages. The one I am working on now is File:World energy consumption.svg. As of now I have only done Arabic, but it is used in about nine other languages. Delphi234 (talk) 08:18, 19 June 2014 (UTC)

All done. I did not add the template:translate because I could not get it to work. I mean I could not get svgtranslate.php from the toolserver to work. Delphi234 (talk) 22:31, 21 June 2014 (UTC)
I like to add --Steinsplitter (talk) 19:25, 5 July 2014 (UTC)

History of energy consumption in the United States[edit]

Help is needed with Arabic. I can not figure out how to get a closing parentheses, like (1776-2013) or a % sign to be at the left where it belongs. It keeps showing up at the right. See File:History of energy consumption in the United States.svg, in Arabic. I took out the parentheses, but have not figured out how to get the percent sign to be in the right place. When I use Google translate, everything looks fine, but then when I paste it into the file it gets trashed. Delphi234 (talk) 03:00, 24 June 2014 (UTC)

An LRM or RLM between the Arabic text and the bracket or percent sign might help. SiBr4 (talk) 09:09, 24 June 2014 (UTC)
Thanks. That worked. &lrm; does not render, but &#8206; does work. I placed it in front of the text that is in Arabic. Delphi234 (talk) 16:26, 24 June 2014 (UTC)

Creating New Figure From Public Domain Data Different From Published Figure[edit]

I would like to produce a Wikimedia figure that will look nearly identical to one in a published scientific article (Figure 1 here). The figure itself is an unrooted phylogenetic tree which uses 143 public domain genetic sequences. There is an example of a similar figure here but in that case it was released by the paper authors under CC license. If I use the same 143 public domain genetic sequences as the original paper above, the output image from a phylogenetic tree program will look very similar to the copyrighted image. I asked on Copyright Violations and they suggested I could modify my figure to make it sufficiently different so I don't violate the copyright of the paper or make a derivative work. Does anyone have suggestions about how to do that in my case? For example, could I use a different colouring scheme, omit some aspect of the plot, or make it more/less detailed? Ideally, I would cite the paper as the source of the concept for the figure. Ceing (talk) 15:18, 17 July 2014 (UTC)

If you're using the same software as the paper authors did, and it naturally produces a similar diagram from similar data, then I wouldn't worry too much about that. If you're using different software to produce your diagram, then there should be many small visual differences between your diagram and the diagram in the published paper... AnonMoos (talk) 07:59, 18 July 2014 (UTC)

Table[edit]

Would anyone be willing to create scaleable tables in SVG from the following date? Source is Table 18. Page 279.[2] I can do charts, but do not have any easy way to make a table, other than using markup. Delphi234 (talk) 04:14, 21 July 2014 (UTC)

Not sure I understand -- tables are encouraged to be placed in Wikipedia articles as markup tables, not images. Don't know what the advantages of an image would be in this case... AnonMoos (talk) 18:34, 21 July 2014 (UTC)
That is why I have not had any reason to learn how to create them. The very existence of them surprises me, but apparently they are used occasionally. To me they are just an annoyance, because I would have to use OCR to get access to the data, if it was not included along with the image. Right now for me, "OCR" means typing in the data one character at a time... Eight months later I have no idea how I created this one, but it was probably done in Paint. It could have even just have been a touchup of a screenshot of the table on that page. But the request now is for something that is scaleable, and not just lossless. Delphi234 (talk) 19:57, 21 July 2014 (UTC)
I am guessing that Inkscape could be used, but my attempts to use Inkscape have not [always] gone well. Delphi234 (talk) 19:59, 21 July 2014 (UTC)
Nah, Inkscape is not really good for tables. You can create tables in the Draw component of w:LibreOffice (copy and paste from Calc or Excel should be possible to some extend). Then export to SVG via FileExport…'. Make sure to set your page size to fit the table in order to avoid huge borders or clean up in Inkscape afterwards. Note however, that tables are not really considered to be in scope at Commons and might get deleted. We even have a template for stuff that should be wiki markup. Might be advisable to upload stuff like that locally at Wikipedia … --El Grafo (talk) 21:08, 21 July 2014 (UTC)

Ownership percentage 2004-2005
Country Firearm % Handgun % 2005
Australia 6.2 0.3 *
Austria 15.1 5.6 *
Belgium 11.4 5.2
Bulgaria 9.7 6.6
Canada 15.5 2.9
Denmark 12.6 1.2
England & Wales 6.1 0.5 *
Estonia 7 3.6 *
Finland 37.9 6.3
France 16.1 3.7 *
Germany 12.5 4.2 *
Greece 20.6 1.4
Hungary 10.4 2.2 *
Iceland 23.5 1.4 *
Ireland 12.4 1
Italy 12.9 5.3 *
Japan 0.8 0
Luxembourg 12.3 7 *
Mexico 2.8 2.8 *
Netherlands 4.8 1.3
New Zealand 16.6 0.6
Northern Ireland 12.7 2.1
Norway 26.1 3.7 *
Poland 4.4 0.9
Portugal 18.3 3.9 *
Scotland 6.7 0.7 *
Spain 12 0.5 *
Sweden 19.3 1.6 *
Switzerland 28.6 10.3 *
United Kingdom 6 0.4
United States 42.8 17.6
Average 14.2 3.4


Ownership percentage 2004-2005
City Country Firearm % Handgun % 2005
Amsterdam Netherlands 1.5 0.7 *
Athens Greece 10.8 2.1 *
Belfast Northern Ireland 1.8 0.3
Berlin Germany 7.6 3.8 *
Brussels Belgium 5.4 2.5 *
Budapest Hungary 8 2.9 *
Buenos Aires Argentina 8.8 6.8
Copenhagen Denmark 6.9 1.4 *
Dublin Ireland 2.2 0.1 *
Edinburgh Scotland 2 0.2
Johannesburg RSA 8.4 0.4
Helsinki Finland 16.2 4.6 *
Hong Kong SAR China 0 0
Istanbul Turkey 10.1 6
Lima Peru 6.9 6
Lisbon Portugal 12.1 3.7 *
London England 1.8 0 *
Madrid Spain 10 2 *
Maputo Mozambique 3 2.8
New York United States 8.1 3.7
Oslo Norway 13.7 2.9
Paris France 4.1 2.1 *
Reykjavic Iceland 15.9 0.6
Rio de Janeiro Brazil 3
Rome Italy 9.9 5.7 *
Sao Paulo Brazil 0.5
Stockholm Sweden 10.1 1.3 *
Sydney Australia 2.4 0.1
Tallinn Estonia 5.1 4.3
Vienna Austria 8.9 5.2 *
Warsaw Poland 1.8 1.2
Zurich Switzerland 16.2 6.8
Average 7 2.5

Clarification of policy for artwork[edit]

There seems to be a conflict between {{JPEG version of PNG}} (with its counterpart {{PNG with JPEG version}}) and {{SupersededPNG}}.

{{JPEG version of PNG}} displays "Generally, this JPEG version should be used when displaying the file from Commons, in order to reduce the file size of thumbnail images." Meanwhile, {{SupersededPNG}} claims "A PNG version of this file is now available" as a sufficient reason for any JPG to be superseded by a PNG. So one tells editors to use the JPG version and the other tells them to use the PNG version.

The conflict seems to arise from the fact that the former template is oriented towards paintings (which can be quite large), while the latter is for (small?) maps and other graphics. Commons:Deletion_policy#Redundant.2Fbad_quality (where "Superseded images policy" redirects) clearly states that {{supersededPNG}}is "For raster graphics (especially JPEG) that have been superseded by PNG images" (emphasis added). Since paintings aren't "raster graphics," it seems to me that the template shouldn't be applied to them.

Scrolling through Category:PNG version available, I noticed several paintings and portraits; however, I also noticed that they seem to all have curved borders, e.g., an oval portrait or a panel with a rounded top. The PNG versions of these files have made the blank but opaque spaces in the original JPG files transparent.

I found some discussion touching on this in Commons:Graphics village pump/May 2011 (second "Oval JPGs" header), but it was inconclusive.

So my primary question is: what is the policy for which approach trumps the other? Where can I find an explanation of this policy? Can the cited policy and the templates themselves have language added to clarify their usage regarding art? Is the concern about the size of thumbnail images obsolete? And, of course, is there some other place where this discussion would be more appropriate? Thanks for any assistance. Laura1822 (talk) 16:29, 29 July 2014 (UTC)

JPEG is very useful for displaying images of paintings or other photographic type images in articles. PNG can be useful 1) Where there is a desire to archive a lossless source version of an image (without the lossy artefacts inherent in the JPEG format). 2) Where there is need for transparency or an alpha channel (not allowed in JPEG format). 3) Where the nature of the image is fundamentally non-photographic (limited number of colors, flat color areas, thin lines, sharp transitions, etc.), and so unsuitable for JPEG.
JPEG image thumbnails are auto-sharpened, which helps with photographic-type images, but would be inappropriate for diagram-type images... AnonMoos (talk) 10:02, 30 July 2014 (UTC)
Thanks. So do PNGs trump JPGs for paintings with curved borders? Laura1822 (talk) 14:53, 31 July 2014 (UTC)
Depends on whether you want a transparent background in the area outside the painting. AnonMoos (talk) 05:52, 1 August 2014 (UTC)

Clarification/update of TIFF policy[edit]

Tangential to the PNG question above, I also need a clarification or update of the policy for TIFF files as archives vs. JPEG for use.

I just came across a (fantastic) set of 20k TIFF images uploaded from a group of museums in Sweden. Category:Images from Livrustkammaren och Skoklosters slott med Stiftelsen Hallwylska museet is the umbrella category for them. These images are generally far superior to any other images of the same objects that already exist on Commons, except for a few that have also been uploaded from Google Art Project.

In particular, what I want to know is whether the paintings need to have JPEG versions created and uploaded with {{JPEG version of TIF}} and {{LargeTIFF}} tags. I left an inquiry at Commons:Batch uploading/LSH regarding whether there were any plans to upload JPG versions (since it would be extremely inefficient for editors to do them piecemeal), but since the project seems finished, I don't really expect an answer. Also, part of the goal of the project was to track usage of the files across all wikis. Therefore, unless they upload corresponding JPGs themselves, that goal will be thwarted by the creation of JPG versions.

A few of the paintings have JPG counterparts from the Google Art Project that seem to be approximately the same dimensions — see File:Porträtt, Henrietta Maria av Frankrike - Skoklosters slott - 88967.tif (3,337 × 3,913 pixels, file size: 37.41 MB) and File:Mary Villiers, Duchess of Richmond and Lennox (1622 – 85) - Google Art Project.jpg (3,338 × 3,914 pixels, file size: 5.11 MB). Would it be appropriate to pair these with {{JPEG version of TIF}} and {{LargeTIFF}} tags?

I just noticed that one of the links under source/photographer goes to the item's page at the museum's website, where a JPG image of the same dimensions as the TIFF here is available for download.

I am sure that this set of TIFF images is only one example (there are already 91 subcategories in Category:Images from museums). So what is the proper approach for using these TIFF files from GLAM sources? Should they supersede other images of the same objects? Are all the concerns about file sizes and thumbnails obsolete, or will they be obsolete in the foreseeable future, making these questions moot? If so, it seems to me that a general revision of the policy (and the various tags) needs to be addressed. Where should such a discussion be opened, if not here? Thanks for any help. Laura1822 (talk) 14:53, 31 July 2014 (UTC)

I brought these issues up here because I thought it was the most appropriate place. However, I have since done a search in the archives of the main Village pump, and TIFFs have been discussed several times there in the last few months, with no consensus on the right approach. I think that with TIFFs from GLAMs becoming more prevalent, the time is probably right for addressing these issues as a policy or guideline. At a minimum, it seems that the various templates that depend on {{Archival version}} seem to need updating. Is the main Village pump the place to propose these? Laura1822 (talk) 16:57, 31 July 2014 (UTC)

TIFF is kind of an extendable container format rather than an image file format in the usual sense, and there's no absolute guarantee that a TIFF will have any kind of thumbnails at all if uploaded to Commons. If a TIFF does generate usable thumbnails, then opinions differ as to whether to also upload a JPEG. Sometimes the JPEG can be an edited version of the image, as opposed to the untouched raw archival TIFF. JPEG thumbnails also have automatic sharpening, which some people like... AnonMoos (talk) 05:56, 1 August 2014 (UTC)

Personally, I support to have a JPEG version in addition of a TIFF version. If one likes to download the image, it is not practical with TIFF on a slow connection (yes, these still exist). Regards, Yann (talk) 06:54, 1 August 2014 (UTC)