Wikipedia talk:Manual of Style/Images/Archive 11

Question

The policy on this page regarding the use of upright imaging seems very straightforward. It reads, in part: "upright=scaling factor is preferred whenever possible." Yet, I now have an editor posting the exact opposite on my user page: "You don't need to upright images in MOST cases." The upright imaging employed certainly looks good on the pages where it is used. I'd appreciate some input on this given the hugely contrasting interpretations of upright use. Thanks very much. Keystone18 (talk) 20:16, 2 May 2023 (UTC)[reply]

To clarify (as one of those editors mentioned above): @Keystone18: insists that adding |upright=1| or similar (often 1.1 or higher) to every image is what this policy sates. However, myself, @Magnolia677:, @Dough4872: and @Pi.1415926535: have all told him that this policy actually says that the default is just to ensure that images are thumbnails, and that adding additional sizing is generally unnecessary, BUT THAT IF NEEDED, using upright is the preference. Famartin (talk) 21:40, 2 May 2023 (UTC)[reply]

While I think your intentions are good Keystone18, I also think you need to read that bullet point in its full context. It reads as follows: "Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified. This ignores the user's base width setting, so upright=scaling factor is preferred whenever possible." It's the first part of that bullet point which is important. Users use various devices when reading Wikipedia and the software will adjust image size accordingly based upon a user's device or their user preferences; fixing to a set pixel width, however, defeats both of these things and forces everyone to see the same sized image regardless. Using the upright factor allows the size scaling in cases where an image is better seen at either a larger or smaller size that its default value, but it's not needed if the default value is fine. Of course, if you feel an image should be resized, it's OK to be WP:BOLD and do so; however, if others disagree, you should try and resolve things through article talk page discussion per WP:DR just like you would with respect to any content dispute. Perhaps in some cases scaling to |upright=1.1 is an improvement and perhaps in some cases it's not. When there's a disagreement, you should try and resolve things on a per image basis. Finally, in general, when multiple editors are expressing concerns about some edits you're making, it's probably wise to stop entirely or at least slow down a bit until things get sorted out. Plowing full speed ahead as before could be eventually be seen as a case of WP:IDHT. It also could create lots of unnecessary cleanup if you're wrong on the matter. Most of the time, it's better to seek clarification earlier than not, unless they're some serious and clear policy/guideline violations that require immediate attention. -- Marchjuly (talk) 22:05, 2 May 2023 (UTC)[reply]

First, User:Famartin, stop stalking my posts on this site; your views, unclear as they are, have been made following every single attempt I have made to get additional input and clarification on this question, which is actually giving your position probably more credit than it warrants. And User:Marchjuly, your response, while appreciated, lacks an understanding of the underlying historical issues here. I have never stated that the use of upright=1.1 is suitable in all cases, and I have never consistently employed it. This policy does seem clear to me: "Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified. This ignores the user's base width setting, so upright=scaling factor is preferred whenever possible." In almost all of these cases, a fixed width in pixels was correctly not specified, and I employed the upright scaling, exactly as the policy suggests, "whenever possible." I would welcome additional and objective input on this question: In what possible cases should upright be used? In what possible cases, if any, should it not be used? Keystone18 (talk) 21:02, 6 May 2023 (UTC)[reply]

If you scroll to the top of MOS:IMAGES, you'll find that it's a guideline, not a policy. I'm not making this distinction to try say you're wrong; I'm just doing so because someone else most likely will later on. I'm not sure what you mean by underlying historical issues, but to me any relevant historical issues regarding scaling are more likely to be find in the archives of this talk page than perhaps anywhere else. There are some examples of how and when to use scaling found in MOS:UPRIGHT and WP:THUMBSIZE; the latter might even provide some clue as what to do here as well since is also touches on the use of scaling. However, as I mentioned above, this might be something that needs to be discussed on a per image basis (possibly even including side by side comparisons) on an article's talk page. If you make such a change and nobody seems to disagree, then great per WP:SILENCE; on the other hand, if others start disagreeing, you may need to establish a consensus in favor of making the change in question. Finally, it's probably best to avoid referring to other editors as "stalkers" per things like WP:HA#NOT and WP:AOHA and keep comments focused on what's being discussed instead of who's doing the discussing. When discussions start on one page but then move to another page, it's not totally unexpected that those participating in the original discussion will also follow it to the new page. If you truly feel you're being stalked, then you probably should make your concerns known at one of the administrator noticeboards which are better venues for dealing with such things. -- Marchjuly (talk) 22:37, 6 May 2023 (UTC)[reply]

I’m gonna add this comment just for Keystone18 to ponder: Wikipedia has certain defaults. The default with thumbnails, therefore, would naturally be the normal preference, would it not? You can change scaling if there’s a good reason, but using upright was never intended to be a blanket standard on all images. Why would you add upright=1 to every thumb when it just gives you the default? It’s a waste of space. And, if there’s a default for thumbs, why would you change scaling on every image (as you have previously done on quite a few articles) to something larger? Many articles have had all images set to upright=1.1 or greater by Keystone18. That’s absolutely not what should happen. It wastes space for text, and neglects the fact that you can click on any thumb and get a much larger version.Famartin (talk) 22:50, 6 May 2023 (UTC)[reply]

A great example of this that I just reverted in New York City: 520 useless characters which comrpised |upright=1 on a bunch of images, all of which just set the images to do what the default is. If you compare the two versions side by side with the visual editor, you'll see they are IDENTICAL, but one version has 520 extra useless characters which did NOTHING. Famartin (talk) 00:29, 7 May 2023 (UTC)[reply]

I just compared a few images using both default thumb and upright=1 and see no notable difference in their sizing or appearance. I suppose the discretionary use of upright is when photos need or should be modestly expanded or reduced. I'm comfortable on using the default thumb in most cases, including the ones we disagreed on in this interaction. I do think the wording of this guideline, like other guidelines and policies on here, is poorly written and not immediately clear, which contributes to these unnecessary disputes. I was once instructed pretty boldly by another editor to begin using upright imaging and to ensure images were at the top of the respective section, or I'd never have begun using it. If I can find that editor, I'll try to have him or her weigh in here in case I've missed anything, which is possible. But I think we're on the same page on this, especially now that I compared the images under both scenarios and see no notable difference. Keystone18 (talk) 04:44, 7 May 2023 (UTC)[reply]

I think you've misunderstood the guideline. Maybe we should change the wording. "Except with very good reason, a fixed width in pixels (e.g. 17px) should not be specified. This ignores the user's base width setting, so upright=scaling factor is preferred when an image must be scaled to something other than the default size." GA-RT-22 (talk) 15:31, 15 May 2023 (UTC)[reply]

What's the guidance for colorized images?

... beyond the requirement to note major image edits in captions per MOS:IMAGE#Editing images. E.g. if the colors aren't given in reliable sources or completed by reliable sources themselves, would user-colorized images violate WP:V? Ed ^{[talk] [majestic titan]} 18:20, 4 April 2023 (UTC)[reply]

There is a very, very lengthy discussion about a colorized image at Talk:Wright Flyer/Archive 1#Colorized photo from 2021, with a follow-up at Talk:Wright Flyer#Colorized image (again) from 2022. The basic conclusion was that colorization is original research, and they shouldn't be used in that particular article. So yes, some firm guidance in the MOS would be greatly appreciated. BilCat (talk) 20:10, 4 April 2023 (UTC)[reply]

There's a difference, though, between user-colorized images and images for which there is some historical provenance for the colorization. For instance, File:Mulberry Street NYC c1900 LOC 3g04637u edit.jpg, a photo colorized around 1900 (according to discussion at Wikipedia:Featured picture candidates/Mulberry Street, New York City) is a featured picture here and on several other-language Wikipedias. There should be no guidance discouraging such images. So if we want to discourage user-colorized images, we need to be very careful how it is worded. —David Eppstein (talk) 20:19, 4 April 2023 (UTC)[reply]

Of course. That's why I specified user-colored. :-) Ed ^{[talk] [majestic titan]} 20:23, 4 April 2023 (UTC)[reply]

I think it could be relatively straightforward to provide guidance centered on the state of the photograph at the time of original publication. This could also apply to other potential OR issues such as digital restoration. Orange Suede Sofa (talk) 01:46, 5 April 2023 (UTC)[reply]

In addition to the question of original research, I think the potential copyright implications of colorization probably should also be discussed and whether it would be appropriate to consider such images non-free content for Wikipedia's purposes. For example, many institutions seems to think that merely digitalizing an old image is sufficient to create a derivative work (i.e. a new copyright) even though US case law (and thus Commons and Wikipedia) tends to see that as c:COM:2D copying. Since colorization seems to involve more creativity than digitalization (this is just my non-expert opinion), it seems a credible claim could be made that a derivative work would be created, which could depending on various factors require it to be treated as non-free content for Wikipedia's purposes. This might be problematic per WP:FREER since all things considered equal, the original uncolorized freely licensed or public domain work would be preferable in most cases per Wikipedia's non-free use policy. When this was discussed at Wikipedia talk:Non-free content/Archive 70#Colorized photos/screenshots in 2020, most of the replies received seemed to that colorized photos are derivative works and thus eligible for their own copright protection, independent of the original; this in turn affected how they could be used under Wikipedia's non-free content use policy. -- Marchjuly (talk) 01:22, 5 April 2023 (UTC)[reply]

This has also come up at Titanic. I have taken a stab at adding some text to the MOS. I know it's not perfect, please tweak or discuss as needed. GA-RT-22 (talk) 23:39, 18 May 2023 (UTC)[reply]

I adjusted the text to cover all monochrome image types (sepia, etc.) rather than focusing specifically on black-and-white. Orange Suede Sofa (talk) 02:14, 19 May 2023 (UTC)[reply]

Proposal to change the default format of galleries

You are invited to join the discussion at Wikipedia:Village pump (proposals) § Galleries. {{u|Sdkb}} ^talk 03:37, 29 May 2023 (UTC)[reply]

Left-aligned images

FYI

There is a discussion at Wikipedia talk:Manual of Style/Accessibility § Left-hand images about apparent conflicts between MOS:IMAGELOC and MOS:ACCIM regarding left-aligned images.—Bagumba (talk) 04:30, 1 June 2023 (UTC)[reply]

Add disclaimer/note about different screen settings

Lately I've seen a lot of disruptive drive-by edits to articles with long-standing image layouts, based on this or that reading of image placement guidelines. But what appears to be happening is that some editors assume that what they see, for example specific instances of WP:image sandwiching and white space, is what everyone else sees, even though this is not always the case. Could we have some guideline that says that before changing the current/long standing image layout of an article, an editor who wants to do this should propose it on the talk page so that the main editors of said articles and others can evaluate the proposed changes to see if they are even a problem for anyone else? This seems to have particularly become an issue after the new extremely narrow text layout has become standard (which I have personally disabled because it looks awful to me). FunkMonk (talk) 17:45, 3 June 2023 (UTC)[reply]

Syntax style

I want to discuss the style of content that readers don't see: the syntax or coding style.

The 'Syntax' section gives this as an example:

[[File:Siberian Husky pho.jpg|thumb|alt=A white dog in a harness playfully nuzzles a young boy |A [[Siberian Husky]] used as a pack animal]]

I would say that this is easier to read:

[[File: Siberian Husky pho.jpg | thumb | alt = A white dog in a harness playfully nuzzles a young boy | A [[Siberian Husky]] used as a pack animal]]

For the same reason that

A Siberian Husky used as a pack animal

is easier to read than

ASiberianHuskyusedasapackanimal

additionally,

[[File:Siberian Husky pho.jpg |thumb |alt = A white dog in a harness playfully nuzzles a young boy |A [[Siberian Husky]] used as a pack animal]]

is more difficult to read than the aforementioned, for the same reason that

lA lSiberian lHusky lused las la lpack lanimal

is more difficult to read than the aforementioned.

I often see people following the example on this page and eschewing any space that is not between two words. Not only that, but many editors see spaces used in code and remove them. I'm not sure what is being improved. Do they quickly read the content, decide it doesn't need to be read again, and want it to take up less space?

To be sure, some parts of computer code do not need spaces between them (series of rote tags that everyone ignores anyways). But some code can slightly differ from use to use, and it needs to be easy to read.

It isn't just image tags with this problem, to be sure. But this page must be fairly popular and get a lot of different viewers, so I figured I'd bring it up here. Wizmut (talk) 12:45, 1 July 2023 (UTC)[reply]

I wish we had some kind of rule discouraging changing white space. Not outright prohibiting it. When someone makes a 500 line change, with 499 lines of white space changes and one line of hard-to-see typo, that's not an improvement. GA-RT-22 (talk) 13:09, 1 July 2023 (UTC)[reply]

I'm glad we don't, and a general one would run afoul of WP:EDITING, WP:CITE, etc. The most common spacing-cleanup case is making citations consistent and more readable. It often is a genuine improvement for other editors (has no effect on readers, of course), especially when someone has injected vertical citations (which are really appropriate only in WP:LDR) into the middle of a paragraph, making it hard to understand the paragraphization, or when people do daft things like {{Cite book| title =Yadda Yadda| last =Foo| first =Bar| date =2023| ...}} — SMcCandlish ☏ ¢ 😼 14:12, 19 August 2023 (UTC)[reply]

Our documentation should reflect what editors typically do (especially since people tend to copy-paste from the doc and change the details). And, well, [[File: Name | thumb | alt = Whatever | More Whatever]] is not it. The prevalent styles are [[File:Name|thumb|alt=Whatever|More Whatever]] and [[File:Name |thumb |alt=Whatever |More Whatever]], to mirror typical formatting of templates. And "File: Name" is just weird. No one does that, any more than they refer to "Wikipedia: Administrator's noticeboard" or "MOS: IMAGES". — SMcCandlish ☏ ¢ 😼 14:12, 19 August 2023 (UTC)[reply]

thumbnails rendering at 170px by default, not 220px?

Does anyone know why, for me at least, the thumbnails at Dundas station (Toronto) are rendering at 170px and not 220px when both |upright and |thumb are set? Isn't the default for |upright = 1? —Joeyconnick (talk) 05:29, 12 June 2023 (UTC)[reply]

No, the default is .75. See the warning in the Size section: "But upright alone, with no =scaling factor ... is equivalent to upright=0.75". This has caused confusion before, see the "Question" section above. I'm going to add some text. GA-RT-22 (talk) 12:54, 12 June 2023 (UTC)[reply]

I question the need for the upright tag on those photos in that article. They are not large photos. BilCat (talk) 17:45, 12 June 2023 (UTC)[reply]

Indeed. Except for very tall and narrow images, we should avoid fixing below the 220 px default, which is what using "upright" without a number achieves. Johnbod (talk) 17:55, 12 June 2023 (UTC)[reply]

I suspect whoever added the "upright" tags was confused in the same way that OP in the "Question" section was, and assumed that "whenever possible" meant "always" and not "when an image must be scaled to something other than the default size". I hope my edit to the MOS has cleared this up. GA-RT-22 (talk) 19:46, 12 June 2023 (UTC)[reply]

Wouldn't it make more sense to have a bot go through and change existing plain "upright" to "upright=0.75" and then make upright with no value = 1? I don't understand why it would default to 0.75. I am clearly not the first person to not know this weird default value.

If 0.75 was some magic value that would fix all potentially large images, then sure. But it's not. Sometimes 0.75 will be too much and sometimes it won't be enough, so shouldn't it just do nothing by default unless someone has actually picked a value that has the intended effect? —Joeyconnick (talk) 03:57, 13 June 2023 (UTC)[reply]

It actually is some magic number that fixes the majority of images. 4:3 is the most common aspect ratio for still photos. Take one of these and turn it on its side, and you will need to multiply the width by .75 to get an image of the same area as the original. I would be opposed to changing the default, because I don't want to have to remember that .75 is the right number to use. GA-RT-22 (talk) 04:19, 13 June 2023 (UTC)[reply]

Agreed. And if it were changed, all the extant uses of it would have be bot-replaced to specify .75, because for many of them this size was chosen on purpose (or rather the |upright= was used because it had this particular result). I know I only use it when the image is vertically too large, and using it produces an image of reasonable height in relation to the rest of the images on the page usually without further adjustment. — SMcCandlish ☏ ¢ 😼 18:45, 19 August 2023 (UTC)[reply]

@Joeyconnick: Getting the behaviour of plain |upright changed isn't something that we can do here, it would require a change to the MediaWiki software, and would affect all wikis using that software - almost a thousand WMF wikis, and then there are all the non-WMF wikis as well. You could try filing a ticket at phab: and see what they say. --Redrose64 🌹 (talk) 22:26, 13 June 2023 (UTC)[reply]

Thanks but yeah, no: sounds pretty hopeless. I'll just adjust. —Joeyconnick (talk) 03:34, 14 June 2023 (UTC)[reply]

Dragable image comparisons

In Fleetwood Park Racetrack, I've got two maps showing the same area in 1885 and today. Is there some way to build a composite image which lets you drag a slider to expose one or the other, in the style of https://web-toolbox.dev/en/tools/image-compare-slider? RoySmith (talk) 16:25, 28 August 2023 (UTC)[reply]

I don't think this exists. We're just now starting to even have interactive maps. Wiki is always 5-10 years behind the rest of the internet in technological capabilities, unfortunately.

ɱ

(talk) 17:06, 28 August 2023 (UTC)[reply]

Add disclaimer/note about different screen settings

Lately I've seen a lot of disruptive drive-by edits to articles with long-standing image layouts, based on this or that reading of image placement guidelines. But what appears to be happening is that some editors assume that what they see, for example specific instances of WP:image sandwiching and white space, is what everyone else sees, even though this is not always the case. Could we have some guideline that says that before changing the current/long standing image layout of an article, an editor who wants to do this should propose it on the talk page so that the main editors of said articles and others can evaluate the proposed changes to see if they are even a problem for anyone else? This seems to have particularly become an issue after the new extremely narrow text layout has become standard (which I have personally disabled because it looks awful to me). FunkMonk (talk) 17:45, 3 June 2023 (UTC)[reply]

That seems like a pretty reasonable idea, along with additional advice to test at multiple browser widths and on different devices. — SMcCandlish ☏ ¢ 😼 04:17, 29 August 2023 (UTC)[reply]

Image stacking

We really ought to add guidance that you shouldn't stack images.

[[File:1]]
[[File:2]]
[[etc...]]
Lorem ipsum dolor sit amet, consectetur adipiscing elit...

This displays on mobile as a centered continuous stack of images, and not a neatly cascading set of images beside the text. I've seen articles where on mobile, you had to scroll through like five screens of images to get to the text. This is covered a bit in Help:Pictures, but not in the MOS and not specific to mobile. GMG ^talk 11:19, 29 July 2023 (UTC)[reply]

Yes - it is in there but should be strengthened. Mind you, in my experience most high-traffic articles have now been converted. I'd also like to see discouragement of "mosaic" multiple images, especially large ones. These are bad both on mobile and desktop. Johnbod (talk) 14:21, 19 August 2023 (UTC)[reply]
Where is the current guidance? E Eng 15:45, 19 August 2023 (UTC)[reply]
What we should say is that there shouldn't be more than "a few" images in a ~~row~~ stack like that. There are plenty of cases where 2 or 3 or 4 in a ~~row~~ stack makes perfect sense (especially if some are left and some are right -- and please, I don't need to hear about SANDWICHing), and there may be places where even more (small?) images in a ~~row~~ stack might makes sense. Explain the reason and leave it to editor judgment. Please let's not have one more absolutist rule giving self-appointed roving enforcers another excuse for making pests of themselves. E Eng 15:45, 19 August 2023 (UTC)[reply]
Oh well, maybe it isn't there - I can't find it, & if you can't, it probably isn't. We're not talking about "row"s here, but stacks or columns - let's not confuse ourselves. It should be in there - at the minimum all we need to say is to move images lower down to break up a stack. It used to be a sensible and very common tactic to stack all the images at the top of the article, so that there would be a continuous flow of images at the right of the screen, whatever the screen size or settings. With mobiles this doesn't work at all, as you get Pinterest before any text. We should advise against this. With the multiple images syntax you don't even get captions (there is an ongoing discussion re this at Talk:Prodigy_house#Multiple_Image). Johnbod (talk) 16:31, 19 August 2023 (UTC)[reply]
Obviously stacking all of an article's images at the start of the article is no good. But stacking two images, relevant to a give section, at the start of that section is often better than having one image at the start, floated next to text, then a few whispy lines of text with no image floated next to them, then another image floated next to text. This usually looks awful.
I'll say again: the important thing is to warn against big stacks. Modest stacks are OK. E Eng 18:19, 19 August 2023 (UTC)[reply]
Images should be inserted at the point in the source that they belong to (that way they make sense in mobile). To avoid stacking, alternate images right and left and ignore all sandwiches (which are rarely a problem on desktop and never a problem on mobile). —Kusma (talk) 16:39, 19 August 2023 (UTC)[reply]
I find sandwitching to be a problem on desktop. I also find overly rigid staggering that ignores article layout (especially left first - right, irrespective of headers) to worsen readability.—Alalch E. 17:53, 19 August 2023 (UTC)[reply]
I use larger than default images on a wide screen, which almost guarantees that sandwiching will happen whenever there are any left-aligned images. It is nearly impossible to illustrate an article well without sacrificing something: the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes. I personally prefer sandwiching to having to use fixed image sizes. —Kusma (talk) 18:13, 19 August 2023 (UTC)[reply]
"It is nearly impossible to illustrate an article well without sacrificing something" - Agreed. "the gallery and multiple images options do not support automatic resizing to larger thumbnail sizes." That will probably be fixed some day, and those layout tools still make sense in various cases (e.g. gallery at Regimental tartan#Late 18th century diversification, where the list isn't even complete yet, and where using a table with regular [[File:...|thumb|]] markup would waste a lot of space). — SMcCandlish ☏ ¢ 😼 18:41, 19 August 2023 (UTC)[reply]

"I also find overly rigid staggering that ignores article layout (especially left first - right, irrespective of headers) to worsen readability." Definitely. It can make it hard to tell where sections/subsections start and what the heading depth is. As for "I find sandwitching to be a problem on desktop." What kind of problem? Can you link to an example? Are you on some really tiny monitor or something? — SMcCandlish ☏ ¢ 😼 18:41, 19 August 2023 (UTC)[reply]
Are we ready for a draft? I think we are boadly in agreement, but I think there are still a good number of editors for whom "stacking all of an article's images at the start of the article is no good" is not yet obvious. I'm ok with two or more in a stack, if there is a good reason, but usually there isn't. Otherwise there's no reason not to space them out a bit, and we should say so in a non-absolutist way. I used to stagger left & right, but now I generally only put images that strongly "face into the page" on the left. That's enough for now, but one day we should update WP:GALLERY, which has hardly changed for 15 years, and doesn't even mention the use of "mini-galleries" placed around the article in visual subjects. Johnbod (talk) 22:15, 19 August 2023 (UTC)[reply]
The "good reason" is actually quite common, and it's a long lead and/or ToC, producing a huge block of whitespace on the right (in a regular browser view; not sure about on mobile). — SMcCandlish ☏ ¢ 😼 04:20, 29 August 2023 (UTC)[reply]
If it's a long lead the images for that should be spaced out, between paragraphs. For those still on the old desktop default, a long TOC is a reason to stack, but what proportion of our readers are still viewing like that? You had to be registered, and to override the new default. Johnbod (talk) 02:34, 2 September 2023 (UTC)[reply]