MarioWiki talk:Image use policy


 * Images should be optimized and not exceed 5 megabytes in file size.
 * Images' dimensions should be in the original size and never exceed 5000 pixels in width or height.
 * Images cannot exceed an area of 12.5 million pixels or about 3500x3500 for a square image.

This rule should be changed because original, official artwork, namely, scenic artwork from recent games, such as this, this, this, this, this, this, this, and this must be resized according to that policy.

But I'm not sure why this rule is here. Is it for fair use or is it to prevent the wiki from carrying the burden of a large image? 14:23, 23 February 2014 (EST)
 * Maybe you can take this to the forums in the General Discussion topic? 16:06, 23 February 2014 (EST)
 * I think it would be very large. This wiki should only summarize the games, artworks are just an addition. PidgiWiki is an example of wikis that can contain any size of artworks.-- 15:43, 24 February 2014 (EST)


 * The rule is suspended until further notice. We might get serious on restrictions, but not necessarily those restrictions, and we don't want to have to resize everything twice. -- 16:21, 24 February 2014 (EST)
 * Ok, thanks, Steve! 19:28, 24 February 2014 (EST)

MediaWiki Headers
I think this project page can be better organized with the use of MediaWiki headers instead of four bullet points with sub-bulletpoints. Something to the effect below. -- 05:02, 8 February 2016 (EST)
 * This would make the page neater, it's fine by me. -- 22:08, 8 February 2016 (EST)
 * I think it's unnecessary. There's only four points, so it's pretty straightforward to find what you're looking for, and the screenshots and aboutfile points really don't seem substantial enough for full sections. The fact that the whole page is currently a (relatively) compact list is also a good thing, since people tend to not want to read long, multi-faceted policy pages. - 23:42, 8 February 2016 (EST)
 * The headers would make the rules more clear and faster to identify. Nobody likes walls of text. My suggestion was to make it more visually appealing or at least a less daunting read. The other MarioWiki pages use headers. -- 01:32, 9 February 2016 (EST)
 * I have decided to create a sandboxed version of this page to show what changes I am looking to implement: User:Wildgoosespeeder/MarioWiki:Image Use Policy -- 20:24, 9 July 2016 (EDT)

Cropping Letterboxing Mandated
and I have been talking about the quality of our image uploads and we are quite split if mandating cropping is a good idea. I suggest reading the talk page section (User talk:Porplemontage) to get an idea where our stances are with it. Thoughts? -- 03:30, 3 May 2016 (EDT)
 * How to cut this:
 * Koops shyness.png
 * I tried it with MS Paint and the resulting pic looks pretty "incomplete".  21:53, 5 May 2016 (EDT)
 * I'm not too keen on cropping screenshots as I said before but I can make exceptions if it is trying to zoom in on something, such as the Thorny Flower first picture. -- 23:07, 5 May 2016 (EDT)

1) Completely empty black border: crop out completely to the edge of the active image, every time (well, with the sole exception of "if the black border is part of the point' of uploading the image"). 2) Black border with text box impinging - case by case, but the general rule should be to crop roughly to the edge of the text box (not the text itself), including any black border visible against the active image.

So in the case of File:Koops shyness.png, this:
 * http://i.imgur.com/X6xKEKGs.jpg

would be my default. Although this is a case where you can get away with cropping all the way to the edge of the active image and it looks okay (sometimes, there's text either right on the edge of the black border, or actually inside it). *previews, is surprised it actually embeds the imgur image, changes to linked thumbnail* - Reboot (talk) 23:23, 5 May 2016 (EDT)
 * But that crop just looks even more odd than cropping Paper Mario images. -- 00:20, 6 May 2016 (EDT)
 * Koopa Bros. Toad.png (right) doesn't look odd to me.
 * Remember that the Paper Mario screen area was allowing for 10%ish overscan. The average player simply would not have seen most (or even all in some cases) of the black area. - Reboot (talk) 00:39, 6 May 2016 (EDT)
 * The case on the right: I'd like to see the remaining black border part made transparent.  01:05, 6 May 2016 (EDT)


 * I see the black border on my HDTV playing the game on real hardware through composite video. -- 15:08, 6 May 2016 (EDT)
 * Now try watching it on a 2000-era (say, bought in 1997 or 1998) CRT television. - Reboot (talk) 18:30, 6 May 2016 (EDT)
 * I'm not entirely sure we can rely on that because Nintendo did put in a "Screen Position" setting on the GameCube and Wii to correct any off-center screen positioning due to possible manufacturing defects of those CRT TVs. I know that has nothing to do with Paper Mario but it should shed light for CRT TVs. I had to use this setting to correct my old Toshiba CRT TV before I went to a Vizio HDTV. Also how a CRT TV processes input varies from TV to TV. With an HDTV, they are pretty consistent displaying correctly. -- 18:57, 6 May 2016 (EDT)
 * ...that lack of consistency and presence of overscan is the entire point I was making. Yes, LCD TVs are more consistent. With Paper Mario, they were playing to the lowest common denominator of 4:3 CRT viewable area (so did other games in terms of "safe" picture area. It was just that PM blacked out the "unsafe" area rather than putting non-essential graphics there). - Reboot (talk) 12:01, 8 May 2016 (EDT)

I'm good with cropping right across the top (1). Transparency is an interesting idea. -- 01:16, 6 May 2016 (EDT)
 * Like I said, you can get away with it with that image and it looks fine, but not in every case. The Paper Mario ones cut the dialogue too close to the top for that to look okay (note that the Battle HUD - File:PMBowserBattle1.png - has a 202-height active area as well). I've edited Koopa Bros. Toad.png (right) to have those two partially-surviving rows of black pixels be transparent - it looks fine, but it's more work to do. - Reboot (talk) 07:45, 6 May 2016 (EDT)

Well, if the screenshot is put on articles at the original size, that the transparent part by the top side of the picture will show as white. Since we have #f9f9f9 frames for pictures, If the picture has dark colors, this will make a "light gray--white--dark" contrast, which does not look good in my opinion. Thoughts? 11:27, 9 July 2016 (EDT)


 * We gotta keep thumb's background white so transparent character artwork looks good, so it's good. -- 18:12, 9 July 2016 (EDT)
 * Something I was wondering about the other day in relation to this sprite - is there an extension or something that would allow the background colour to be specified for an image? (A syntax something like file.ext .) - Reboot (talk) 18:20, 9 July 2016 (EDT)
 * Not that I know of, but I'll look into it. -- 18:29, 9 July 2016 (EDT)

Here is another issue: Super Paper Mario dialog boxes are the same black as the letterboxing and borders! -- 18:50, 26 May 2016 (EDT)
 * Only if you have your Wii set to narrowscreen/4:3. If you have it set to widescreen, there's no letterboxing. - Reboot (talk) 15:56, 28 May 2016 (EDT)
 * The image to the right needs to be recaptured anyways. That isn't my screenshot though. That's been there longer than I have been contributing (November 2015 even though I registered in 2010). Even with that said, I think the game controls the letterboxing on the top and bottom of the screens by inserting it when triggering a dialog sequence then makes it disappear when resuming control of the player character. The left and right letterboxing isn't supposed to be there. Bad cropping on the uploader's part. Here's what widescreen Super Paper Mario is supposed to look like: File:Hammer Whacker.PNG -- 15:59, 28 May 2016 (EDT)
 * ...that's not Super Paper Mario.
 * And I have Super Paper Mario running, on a Wii, right beside me. The game is not letterboxing, either in cutscenes or in gameplay. - Reboot (talk) 16:06, 28 May 2016 (EDT)
 * Unless I am thinking that Paper Mario: The Thousand-Year Door has that letterbox control. It's been a little while since I last played through the story and got the exact point the right picture is referencing. The image I linked to is from Super Paper Mario. It was taken from Flipside Arcade. -- 16:14, 28 May 2016 (EDT)
 * Okay, but it still isn't representative of the general UI/etc.
 * This is a photo, not a screenshot, but it shows what happens when you trigger a dialogue sequence with widescreen engaged. No borders (all the black is the actual bezel of the TV and beyond - I turned the light out to take the picture): http://imgur.com/j6W1TxX - Reboot (talk)
 * I think what I was trying to say about the Flipside Arcade image was what the widescreen mode looks like dimensionally so that way you can see if the game inserts letterboxing like I know Paper Mario: The Thousand-Year Door does. So would you require widescreen screenshots of Super Paper Mario so we don't have to put up with this odd cropping or transparency of screenshots? 4:3 screenshots are just as valid for this Wiki. -- 17:58, 29 May 2016 (EDT)
 * Require widescreen (which, since they don't waste a big chunk of the screen with empty black letterboxing, are automatically higher-resolution!). Besides, per the directive that started this discussion, the letterboxed ones *are* less valid than unletterboxed widescreen! (Direct comparisons notwtithstanding) - Reboot (talk) 18:51, 29 May 2016 (EDT)

Super Mario Galaxy dialogs for sure have an issue. The dialog box is translucent (alpha channel has a value somewhere between 0 and 255, which perfect transparency has a value of 255 for each pixel). Cropping would be wrong because it loses consistency with the rest of the dialog box and picture. Transparency is also wrong because part of the letterboxing is preserved caused by the overlapping translucent dialog box. How do we accommodate that? Also, we need to make sure we capture at native resolution (not always 854x480 or 640x480) because there is some filtering and blur applied to the rounded edges of the dialog box as well. Native resolution would likely not have this. Currently, that isn't accurate to take native resolution screenshots of Wii games at this current time. -- 01:59, 16 June 2016 (EDT)


 * Wildgoosespeeder: Border back but only for a few seconds. I still don't like the policy but I think if I upload two versions of the image, I won't have such a gripe with the policy.

...seriously?

No, I mean, SERIOUSLY?!? This coming from the PNG monster? - Reboot (talk) 17:39, 9 July 2016 (EDT)
 * No need to be disrespectful when addressing someone. Anyways, what does PNG Monster have to do with cropping screenshots? That's just a program to reduce file size of PNGs (doesn't affect the contents of the image). -- 18:04, 9 July 2016 (EDT)
 * Uploading an image twice is twice the size of a single upload. - Reboot (talk) 18:07, 9 July 2016 (EDT)
 * But only the current version of the image will be used. The other versions are archived. -- 19:31, 9 July 2016 (EDT)
 * I really didn't like the Paper Mario images due to the four large and uneven black borders. The Mario Galaxy images are fine, I'll update the policy so you can leave them as they are. -- 18:12, 9 July 2016 (EDT)


 * The rules you have decided months ago and updated moments ago don't really make a whole lot of sense to me. It's hard to come up with a uniform rule that fits each game nicely. That's why I have been questioning your decision. This is why I just upload an uncropped screenshot. Far easier. -- 18:35, 9 July 2016 (EDT)


 * It's pretty simple. The way that the Paper Mario images were cropped before your re-uploads was good. I didn't like the new black borders. The whole policy change was just a way to make those images look the way they used to, except of course with the better quality retained. Got it? -- 19:10, 9 July 2016 (EDT)
 * But why are you excusing Super Mario Galaxy from this rule? I'll just list the cons of cropping off the borders:


 * Not what real hardware produces, which is part of the image policy. The image is edited if cropped, so should reflect this change. If it is not mentioned, it's misleading. Then I will be OK with cropping.
 * This could make galleries in look kind of off when displaying screenshots. The title screen of Paper Mario is 320x237 while the game play screenshots are less than that. This can make pages using  look weird and off as well. -- 19:31, 9 July 2016 (EDT)


 * The general rule is that we don't crop, which Mario Galaxy follows. Think of Paper Mario as an exception to this rule, due to how terrible four large black and uneven borders look. It looks worse than your cited gallery problem, in my humble opinion. So note the crop in aboutfile line #4. -- 19:44, 9 July 2016 (EDT)

So note the crop in aboutfile line #4
 * Make it part of the policy? Then I will be much more satisfied with this policy change.

If the screenshot needs to be cropped to remove black borders or have transparency be added if a game element overlaps the black border, note it in, parameter 4. -- 19:52, 9 July 2016 (EDT)
 * I don't think it is necessary to mention cropping in #4, for the same reason Wikisource doesn't mention that it has "changed" the font or the layout of the original documents.  02:34, 17 July 2016 (EDT)
 * But it is a modification of the unaltered screenshot (or image that gets cropped). It should be documented if such an edit takes place. -- 02:44, 17 July 2016 (EDT)
 * It is a modification of the .png file output by the emulator, but what if you don't use the emulator's "screenshot" feature, but instead use the "Snipping Tool" that comes from Windows 7+? In the latter case, the borderless screenshot isn't modified at all.  03:49, 17 July 2016 (EDT)
 * You should be using the emulator's screenshot button. The reason is that it reads what the real output is (it's usually as close as possible to the real hardware's output). Only in odd cases should you use the snipping tool (or equivalent methods). I have had issues with MESSUI emulating CD-i using its screenshot button, but the screen resolution is always 384x280 for the Mario games we cover (including the letterboxing that should be cropped), so properly setting up MESS for the snipping tool fixes the issue. Other than that, just mention you use the snipping tool so that way if someone stumbles across your upload and it says so, they can compare with a non snipping tool screenshot of theirs to judge if a new upload tagging as cropped is required. Just out of curiosity, why do you use the snipping tool? Something wrong with BizHawk, similar to MESS? If so, show me a screenshot generated by BizHawk. -- 04:20, 17 July 2016 (EDT)
 * No, I don't use the snipping tool at all. But just as people have the freedom to choose what operating system to use to contribute to the encyclopedia -- Windows, Linux, Mac, etc. -- they should also have the freedom to choose how they take their screenshots, as long as they're of the same quality. What I'm worrying about is that snipping tool users will be compelled to act as if they were using the emulator method, even if they have done no modification at all. (Indeed, one of the great advantages of snipping tools is that you don't need to crop, if it's properly set up.)  09:31, 17 July 2016 (EDT)
 * [Note: I tried both methods of taking a Paper Mario screenshot and they're indeed of the same quality.  10:00, 17 July 2016 (EDT)]
 * [Another note: cropping is not editing the content of the screenshot. It isn't misleading either because the average readers of MarioWiki are players and look at screenshots to know what is on the screen, not how big the screen is or how much the screenshot differs from real hardware output.  12:36, 17 July 2016 (EDT)]
 * Real hardware doesn't crop. I trust the emulator screenshot button. I checked the NES, SNES, N64, GCN, and Wii and they relatively match. Therefore, cropping the image for MarioWiki is editing the screenshot. -- 15:18, 17 July 2016 (EDT)

I still don't agree. First, there isn't a rule in the image policy that says the hardware output is the only "correct" version of a screenshot and whatever disagrees with it is inauthentic. Second, the purpose of having screenshots on the wiki is to show the reader what is on the scene. It is only on a wiki like The Cutting Room Floor that being faithful to the hardware is important. 15:36, 17 July 2016 (EDT)
 * Hey, wait a minute -- it isn't my goal to argue whether cropping qualify as modification, and I was arguing over that like an idiot. All I ask is that people should be allowed to upload borderless Paper Mario screenshots without saying that they have "cropped" the picture in #4, since it is possible that they are honest.  15:53, 17 July 2016 (EDT)
 * I guess it is possible that there are people that don't know any better. My WIP screenshot guide is my attempt to better inform screenshot submitters the expected output of an emulator screenshot. If it matches, it's valid. Once validated, it can then be cropped, if necessary, as deemed by the policy. My WIP hasn't been modified to reflect the recent change in policy. Not sure of the best way to word it. -- 17:43, 17 July 2016 (EDT)
 * But what about snipping tool users? Why are you ignoring their feeling?  23:04, 17 July 2016 (EDT)
 * Another problem is that it compels the editors to think that cropping is modification, whether they agree or not.  23:30, 17 July 2016 (EDT)
 * Again, the intention of my WIP is to inform everyone submitting screenshots of expected outputs of emulator-taken screenshots, even snipping tool users. Snipping tool users should say they used the tool in the edit field. Doesn't matter if you agree cropping is editing. By definition alone, cropping is editing. It's like YouTubers video editing to zoom in or edit junk out of the raw footage or pictures they choose to include in their videos. -- 23:43, 17 July 2016 (EDT)
 * ''Snipping tool users should say they used the tool in the edit field.
 * OK, Now I feel better!  23:53, 17 July 2016 (EDT)
 * ↑ EDIT: mis-stated this sentence. My intention is to say that cropping doesn't affect the content of the screenshot. It _is_ a modification of the hardware output, though.  06:40, 19 July 2016 (EDT)

↑ 1 Aug 2016 update: Now hardware output has been explicitly mentioned in MW:UPLOAD. This should be no problem as long as people who use other methods are well informed of what the hardware output is. 23:39, 31 July 2016 (EDT)