User talk:Wildgoosespeeder/QualityRequestTypes/sandbox

This talk page or section has a conflict or question that needs to be answered. Please try to help and resolve the issue by leaving a comment.

Template:PArchive This page is for addressing specific concerns with proposing new tags and modifying existing tags. These are current concerns that have yet to see a resolution be reached. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 03:25, 12 April 2016 (EDT)

Categories

• Category:Quality requested
• Category:Images that need improvement
• Category:Images that need a game rip
• Category:PNG requested

Comments

There have been concerns that these two additional categories may not be enough and current crowding will just be shifted over to the new categories. The categories should be split even further into one for screenshots, sprites, etc..

Now Category:Images that need a game rip has been added. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 00:31, 14 April 2016 (EDT)

Implementation

Someone suggested that if the proposal passes, ~70,000 files need to be examined. This is false. Only images with {{image-quality}}, which is around ~1,000 images at this current time, will be examined and have their tags changed. The only thing the proposal adds/removes/changes is giving more tag options and reducing debates surrounding the {{image-quality}} tag. The way we go about finding images to tag will remain the same (casual regular everyday browsing of MarioWiki).

Definitions/Restrictions

{{image-quality}} doesn't have a shared understanding on its proper use. That is why additional tags are being created and new rules are being suggested as to reduce subjectiveness surrounding its use.

Template:Image-quality

• Bad cropping
• Blurriness
• Too small
• Used a camera to take a screenshot of a game

Comments

Well for some of your points, that depends. What if the said screenshot is the only image source of said game? I guess you could say vaporware or pre-release builds are the exception to these. Ray Trace^(T|C) 18:19, 12 April 2016 (EDT)

Right. I have that established in yet another future proposal. User:Wildgoosespeeder/sandbox. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:50, 12 April 2016 (EDT)

I got a weird idea. Would a special tag for beta images needing a better image be acceptable? --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:06, 12 April 2016 (EDT)

I'll put examples of each. I tried to order it by most awful to least awful-looking

• NOTE: These images were scanned April 12, 2016. Their quality may have improved since then. Check their file histories for further details.
• 

  Used camera (screenshot)

• 

  Bad cropping (screenshot)

• 

  Blurriness (screenshot)

• Cyrrus.jpg

  Too small (screenshot)

• 

  Used camera (artwork)

• 

  Bad cropping (artwork)

• Toad hands raised Mario Party.png

  Blurriness (artwork)

• 

  Too small (artwork)

If you like these, then you should reupload these as separate images just for the page. Don't upload them until you create the page, though! It's me, Mario! (Talk / Stalk) 22:58, 12 April 2016 (EDT)

File:SMG BobOmb Dispenser.png Why is this even an image? It looks like it was taken from File:Bob-omb Dispenser.png as a source, and the source is of terrible quality. I have been meaning to redo the bunch of Battlerock Galaxy images anyways, but there are a lot to do, especially the gallery section of that page. I don't know if that many images are necessary.

Anyways, the rest of the image are good examples. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:06, 12 April 2016 (EDT)

Didn't realize that the DISPENSER image is a massive derp. Try File:Kamella SMG.png. Bonus: you tagged that one. :P Also, I agree, Battlerock Galaxy has WAY too many images and I also think the gallery is a bit excessive. It's me, Mario! (Talk / Stalk) 00:21, 13 April 2016 (EDT)

I also think you should put emulator glitches as a parameter, but I don't know how often that pops up. Ray Trace^(T|C) 19:08, 13 April 2016 (EDT)

I can think of five off the top of my head: --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:23, 13 April 2016 (EDT)

• NOTE: These images were scanned April 13, 2016. Their quality may have improved since then. Check their file histories for further details.
• 

  Super Mario Sunshine (formerly a screenshot containing a glitch)

• 

  Super Mario Sunshine (cube path markers shouldn't be visible)

• Cosmicclone.png

  Super Mario Galaxy (Cosmic Mario's shell isn't supposed to look like that)

• Glide64 2.png

  N64 games in general (bad filtering, see here how to fix)

• 

  Super Mario 64 (HUD looks ugly, see here for correct HUD look)

• 

  Megadardery (talk) says the fog is missing

Yeah, all are pretty bad as well as well misleading. You're going to consider making a separate image-quality template for that as well?

I think the easier solution is to just amend {{tweak}} section of this proposal. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:36, 13 April 2016 (EDT)

Template:Convert to PNG

No questions asked images should be PNG:

• {{game-screenshot}}
• {{game-sprite}}
• {{game-3Drender}}

Iffy if JPEG or PNG:

• {{art}}
• {{character-artwork}}

Comments

It really depends on the screenshot. As you said on the proposal, shader-based games with relatively high-res screenshots generally don't need color preservation. I get sprite-based low-res games like GBA games, but I think we can tolerate .jpg for stuff like Super Mario Galaxy or even Paper Mario.

Also, .jpg in art and character-artwork is acceptable. The only reason you'd be using .png is for preserving transparency. You could also upload art as .png while expecting a better-quality work to come later such as File:BabyLuigibeinghimself.PNG, but that's not guaranteed. It's me, Mario! (Talk / Stalk) 21:48, 12 April 2016 (EDT)

If we are going to make exceptions with JPEG being tolerable with screenshots, how are we going to educate people how to get good quality JPEG screenshots for MarioWiki? I'm very stupid with that format. PNG is just so much easier to work with. Microsoft Paint's JPEG saving is terrible. That I know for sure. The only exceptions I am willing to throw with JPEG for sure are 3DS and Wii U screenshots because the 3DS upload to Miiverse looks quite nice. Wii U, I don't advise images be uploaded to Miiverse because those images are 800x450. The Wii U is capable of uploading 1280x720 screenshots directly to any website willing to host the images, including MarioWiki because the Wii U's built-in web browser has special upload dialog box handlers. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 22:04, 12 April 2016 (EDT)

Not sure how GIMP handles them, but I've uploaded .jpg images in another wiki by putting the .png in GIMP and exporting as .jpg with default settings, and it doesn't seem trashy to me. I still think you should discuss 3DS homebrew stuff. Speaking of which, you probably need a disclaimer on ISOs and homebrew just to be safe. It's me, Mario! (Talk / Stalk) 22:21, 12 April 2016 (EDT)

The entirety of emulation needs a disclaimer. :P Emulation is legal because it falls under the lines of reverse engineering being fair use. Distribution of the games for emulation is illegal as well as downloading them, even if you own authentic copies of those games. Obtaining a back-up copy of the games you own authentic copies of yourself is legal. Homebrewing is something that Nintendo does not like at all but it isn't illegal, but it does void any warranties. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 22:29, 12 April 2016 (EDT)

I feel like some .gifs don't necessarily need to be in .png format, such as the grayscale Super Mario Land sprites. I'd maybe take issue with more complex sprites like the Paper Mario ones, as .gifs are rendered worse as thumbnails, but is there any difference of the rendering .png/.gif of the lower-res sprites such as the aforementioned SML sprites? Ray Trace^(T|C) 23:00, 13 April 2016 (EDT)

To get technical, the GIF format in general suffers from having a limited 8-bit color pallet (256 colors) with limited transparency (value of 0 or 1) and has dated compression algorithms. PNG has a 24-bit color pallet (16,777,216 colors) with less limiting transparency (values ranging from 0 to 255) and higher compression in almost all cases compared to GIF counterparts (a few edge cases would put GIF superior). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:32, 13 April 2016 (EDT)

Template:Tweak

• Transparency requested
• Incorrect aspect ratio
• Images with artifacting present
• Removal of watermarks
• A proper resampling is needed
• Slightly inaccurate colors
• Screenshots featuring emulator glitches

Comments

What's a "resampling"? Is it retaking a screenshot to fit the appropriate resolution? Also, include .jpg screenshots on sprite-based games. It's me, Mario! (Talk / Stalk) 21:44, 12 April 2016 (EDT)

Resampling when it comes to saving in an imaging format is regenerating something to be in a raw format (such as a BMP) and then converting that raw image into a different file format for compression. In the case of game screenshots, it would be the regular playing of a game live and then pressing the screenshot button. The expected output format should be BMP or PNG. If we want a JPEG from that, there would be no artifacting with the input image. The output image would be untainted. The only artifacting would be from the JPEG algorithm itself with the output JPEG format. Essentially we want a clean input file to generate a good output JPEG file. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 22:15, 12 April 2016 (EDT)

Template:Tweak-gamerip

• Looking through game sprites via hacking or hex editing would provide the best version of an image compared to screenshot cropping.
• A custom 3D render would be of higher quality than a cropped screenshot render.

Comments

I don't 100% get what the latter is saying. You say we should get a model from the game, slap it right in 3DS Max/Maya/Blender and just take a picture there? It's me, Mario! (Talk / Stalk) 14:17, 15 April 2016 (EDT)

I guess. I don't have much experience in game ripping, more specifically, 3D rendering of the ripped 3D model data. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:25, 15 April 2016 (EDT)

The results of ripping these properly is something like this: File:Mario and Luigi (render) - Mario Tennis Ultra Smash.png. Except the lighting is manually added because the lighting from the game, for the most part, simply isn't present. Also, models are in that strange pose just for the modelers' convenience. When you're trying to animate, for instance, you're defining weight values for these little points (vertices) on the models for the model's bones (joints in the model). You do NOT want the arms to be by the sides or the fists close or it will be unnecessarily difficult. On the other hand, the reason the image, File:MLNPC.png, has fists is that Super Mario Galaxy doesn't animate fingers; they swap around many different meshes for the hands. Anyhow, despite their T-shaped pose, you can move and even animate these models since the rig (what we call defining those weight values) is ripped as well, but an image doesn't do them justice. However, unless we get animation files, getting the models into a specific pose may be tricky. It's me, Mario! (Talk / Stalk) 14:38, 15 April 2016 (EDT)

Target Audience

Only a few users actively contribute to fixing bad quality images. What is the ratio of writers vs. uploaders?

• Users can choose to:

1. Take on one of the two roles, or
2. Handle both roles as a writer and an uploader in varying degrees of effort.

• Amount of effort for a writer or uploader can make is determined by:
  • Time investment to perform such a task
  • Content sources that are accessible digitally (like the internet, or a downloaded game) or in physical form
  • The ability to successfully capture what said content it is about

• As a general starting point, video games (not non-video game media based on video games) will be covered as it covers most of the overall images uploaded in the wiki in order to understand:

1. How those two roles perform their tasks, and
2. How it influences and explains the ratio of writers vs. uploaders

• Role descriptions

• Writers: Describe the information of the story, lore, game mechanics, actions, description of the subject's looks/imagery, anything that's not uploading images.
• Uploaders: Find images that capture what the subject is about.

• Sources

• Writers: Playing the game (from a console, or from an emulator), YouTube videos, or walkthroughs
• Uploaders: Taking screenshots from a game (with a capture device, or from an emulator), Miiverse (people playing Wii U/3DS games can upload screenshots on their accounts), screenshots from video game websites, game sprite image repositories, or off-hand sources (such as screenshoting a lossy-compressed YouTube video frame)

• Difficulty

• Writers: 1) Quality of gathering info. 2) Written info dependent on the quality of writing, grammar, etc from gathered info.
• Uploaders: Utilizing info to find the location of the content to be uploaded as an image.

• Margin of error

• Writers: Ways for incorrect info: 1) Misremembering info details, 2) misinterpreting given info, and 3) deliberate incorrect info.
• Uploaders: Ways for incorrect images: 1) Uploading the image that isn't the subject, and 2) deliberate incorrect image upload.

• Getting the highest quality content possible

• Writers:

• The highest possible quality of writing is limited by it's writing and analyzing skills.
• Writers can get all the info from the video game itself (from a console or from an emulator) by playing the game normally, with exceptions:

• Technical info such as enemy RPG statistics that can only be found through a strategy guide or hacking game files.
• Games with different versions and/or different languages with differing content, like story localization changes or additional content.

• If writers never played a particular video game before, they can use second-hand sources such as YouTube videos and walkthroughs.

• Writers using second-hand info should ask for verification from someone who has played that particular video game since second-hand info may not be accurate.

• Uploaders:

• Uploaders must get the highest quality of game screenshots through emulation, homebrew, or a screen capture device.

• Getting a game screenshot from a particular location through emulators requires playing through the game with accompanied skills to do so.

• Uploaders playing a video game from an emulator can use:

1. Save states as a safety net to lower difficulty by replaying a difficult part without loss of time, or moments in the game that go by too fast to screenshot it.
2. Download game saves from the internet in order to access to a particular part of the game to screenshot faster.

• Uploaders uploading should be aware that game screenshots captured through emulation may have emulation render errors.
• Screenshoting newer games by emulation (like 3DS and Wii U titles) is impossible due to:

1. Lack of emulator programs.
2. Emulators are not developed enough to take screenshots.
3. Newer game console emulators like the Nintendo GameCube, or Nintendo Wii may require more powerful computer hardware due to increasing complexity of successfully emulating software in comparison to older game console emulators.

• A suggested alternative way is to retrieve screenshots posted from Miiverse (screenshots uploaded from 3DS and Wii U); however, I have no knowledge on how accurate the screen captures are uploaded from a 3DS or Wii U.

• For uploading game sprites, they can be found from image repositories, after making the background transparent, and cropping to only the game sprite.

• If the desired game sprite is not found, if the desired game sprite and game background is not too complicated to deal with: Screenshot that particular part from an emulator, separate the background from the sprite by removing the background, and make the background transparent.

• If the desired game sprite is too complex to successfully retrieve:

• Ask someone who specializes in retrieving and compiling sprites to request a particular game sprite piece.
• Learn specialized skills of retrieving and compiling sprites from a video game through emulation.

That was a lot of thinking and writing out! Took around 6 hours to write it out! I'm not sure which one is easier to do, since it's dependent on well you do in one of the two. Although, I would say that the potential for users to be image uploaders by uploading the best possible game screenshots through the use of emulators is suggested to be stunted because of the stigma crafted by publishers in that "emulating equals piracy" when emulators are a legal tool to be used. --RAP... 04:00, 16 April 2016 (EDT)

• Very insightful stuff there RAP (talk). For the YouTube video screenshot as a source, my WIP has become more lenient with that source, although I advise these images shouldn't be forgotten and should be tagged or have a more appropriate screenshot be taken, whichever is the least time-consuming to achieve a good quality screenshot.
• As for 3DS screenshots, Miiverse is acceptable but those screenshots are JPEG. I think the JPEGs are on the higher quality end of JPEG quality instead the lower quality end like this exaggeration of File:CoinRush.png. However, Bazooka Mario (talk) has brought 3DS homebrew to my attention and is capable of taking raw screenshots and converting those to lossless PNGs. There is a catch. Nintendo regularly patches the 3DS firmware. I can't take PNG screenshots with my 3DS currently because I am running my 3DS on the latest firmware, which block current homebrewing methods. This method has yet to be verified as a viable method of screenshot taking. User:Wildgoosespeeder/sandbox#3DS --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:10, 18 April 2016 (EDT)

Just to let you know, I've just gotten a message from Kuribo64, just today: "[browserhax] is a really old version of webkit, expect browserhax to return someday." Browserhax lets you install homebrew using an exploit in the Internet browser. Nintendo did patch it, but I'm going to try to stop updating my 3DS from now on so I could use a possible newer version of browserhax. In the meantime, there are indeed other methods to run homebrew, but they're quite limited, especially on the latest firmware.

Also, RAP, great summary. I do believe that you should include fluidity between the two. I myself interchange between a writer and an uploader. I'd also like to say that not only there is bad publicity on emulators, but those things require decently powerful computers to take images efficiently. You don't necessarily need powerful computers, but it could get tedious and tiring to slog through 3 FPS gameplay to get the screenshot you want. This is how we uploaded all of our Mario Party screenshots, and we even broken button mashing records that way. :P It's me, Mario! (Talk / Stalk) 20:59, 18 April 2016 (EDT)

• "Fluidity"

• I'm not sure what additional bulletpoints I would write about the fluidity between a writer and an uploader.
• The purpose of creating the bulletpoint list is listing down what tasks and obstacles both of those roles face in the wiki from my knowledge of observing and taking those respective roles.
• I can make an acknowledgement that both users can take both roles instead of just strictly one in varying degrees.
• I don't think I want to pigeonhole users to a particular role and ignore or deny them from taking on the other role.

• For instance, I lean heavily on image uploading over writing articles (because for me, I sometimes have trouble outputting my thoughts into words for subjects that I have to tackle in a variety of angles (such as not taking account that emulation for later consoles may require more powerful computers!) and type it out in a accessible, accurate, and compact matter.

• If you take account of this comment, and read the bulletpoint list, you can safely infer that I have a history of uploading a ton of game screenshots and games sprite images in the wiki in general; and if you check my contributions and took a quick skim of my work, you can infer that I have minor contributions of writing (most of it gnomework, and maintenance but I don't mind that), but has a notable foothold in writing articles for Mario Party series mini-games, particularly 1-3.

• However, thinking about the role of a writer, does it extend to the amount of wiki code knowledge? (This is one of those angles that I haven't considered covering and defining!). For it to be the highest quality content, information like statistics would be more suited for wiki tables for neatness and readability. I could probably add that (or maybe have it's own separate category due to technical details of using wiki coding). May need extensive thinking or help. Maybe another time?

• Another barrier: Emulating newer game consoles = more powerful computer hardware

• Oh yeah, powerful computers. That's another barrier...I forgot about that.
• I blocked that memory when I failed to play an emulated GameCube (the latest is earlier in 2016) because it's slow and unproductive for my tastes.
• I'll edit the bulletpoint list accordingly.
• Oh, when you played those GameCube Mario Party mini-games, I seriously hope you changed the characters at random, it would stupidly odd to have like 50 Mario Party 4 images of Mario, Luigi, Donkey Kong, and Yoshi playing those mini-games, and not randomly mixed those characters. >;o

--RAP... 23:02, 18 April 2016 (EDT)

for those gamecube titles crap, we could reupload it with different characters if you really want us to. i'd be more comfortable doing all of that myself than someone else doing this because "lol characters" crap. our computer's graphic card can handle it pretty good, so we can take a stab at it. Ray Trace^(T|C) 23:56, 18 April 2016 (EDT)

@Baby Luigi (talk): The reason I suggested to have randomized characters in those Mario Party series mini-games is to continue the positive reinforcement that there are multiple playable characters players can choose, whether it's their favorite, or just 1-button confirm Mario. :P While I admit it sounds like a nitpick, tiny but subtle stuff like that counts, tis fair representation I say. --RAP... 01:16, 19 April 2016 (EDT)

that's fair enough i guess. though, fun fact, not even ndcube/hudson follows this: I think in Mario Party 9, 90% of the game previews used only Mario, Luigi, Peach, and Yoshi if I recall correctly, or, if it's a another certain amount of characters. I'm not saying that we should follow them and do screenshots exactly like they do, of course. but i agree that some variety is nice, and we can please all viewers whose favorite character should be represented at least once. Ray Trace^(T|C) 02:42, 19 April 2016 (EDT)

Yeah, maybe we went a little overboard with Mario/Toad/Toadette vs. the evil Daisy Waluigi Wario team. :P I think I'll limit it to everyone vs. the evil Daisy Waluigi Wario (and occasional Yoshi) team. It's me, Mario! (Talk / Stalk) 17:20, 19 April 2016 (EDT)

• Why Mario, Luigi, Peach, and Yoshi in most game previews of Mario Party 9? – @Baby Luigi (talk):
  • It's probably a PR thing. Mario, Luigi, Peach, and Yoshi are the most recognizable Mario characters they can pick from.
    • Bowser has the same level of recognition as those 4, but cannot be picked as a playable character.
  • The purpose of those characters being picked is to maximize exposure through reinforcement and reach:

1. Fans who engage with the Mario series casually (not like MarioWiki users per say, they would've known more than just those 4), and
2. Non-fans who never engaged themselves with the material, but had some surface knowledge from advertisement imagery, or noticing other people engaging with Mario content through discussion, playing Mario video games, or interacting with merchandise (like shirts or toys).

• The way PR has handled for Mario Party 9 could be a sub-section as marketing.

• Problem is that it's more subtle, non-gameplay, and usually under our noses when just wanting to engage with game mechanics and lore in the wiki. :p
• For example, I wrote a sub-section dedicated to marketing for Donkey Kong Country Returns (click here for my last revision dedicated to that section).

• There's a revision note I wrote that says: "Wow, this section remained untouched. Adding the sectionstub back; doesn't cover GameStop retailer bonuses. I have a feeling there's more than that." Apparently someone did not catch that note or felt like the sub-section is fulfilled enough and removed Template:stub. I know there's more than that!

• Or...there's a piece of marketing info that's just stuffed to the trivia section. Wow.

• @Bazooka Mario (talk): Why those four?! Is it because of their AI making them act more cunning and aggressive? :p

--RAP... 04:13, 20 April 2016 (EDT)

No, they're just funny to play against. We don't hate them. Ray Trace^(T|C) 21:21, 20 April 2016 (EDT)

Yeah, but we varied it a bit more in Mario Party 8, so would you be okay with that if we did it like this? Or do you want full-on variety? It's me, Mario! (Talk / Stalk) 21:24, 20 April 2016 (EDT)

I would prefer full-on variety, just try to make sure it's reasonably randomized and not notably obvious. Some with against those four that you two like, some completely different. Stuff like that. --RAP... 23:22, 20 April 2016 (EDT)

Downloading saves to shorten iteration time replacing images

RAP (talk) mentions downloading saves to shortcut replacing images. Should my screenshot guide include where to find such saves? Zophar's Domain has a lot of saves for NES (if supported or a savestate), SNES, N64, GB (if supported or a savestate), GBC, and GBA (I think) using "native saves" (battery back-up or flash memory, varies by cartridge). GameFAQs has GBA GameShark saves, DS Action Replay saves, *.gci (GameCube memory card save files) and Wii saves that can be imported to real hardware using GCMM (GCN only) or through Dolphin (both save types). For the GameShark and Action Replay saves, this requires you to import through the menu of the emulator because these saves are not native. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:07, 24 April 2016 (EDT)

As long as it gets the job done faster on getting better quality screenshots, yeah. Just make sure that the instructions of using saves (created from emulators and from actual hardware) are simple, concise, and tries to cover every angle; like try to idiot-proof it as much as possible, such as my PNG Monster guide, in which for example, if there are unforeseen scenarios that I didn't cover due to not enough experience using this seemingly simple program or the actuality or perception that it would alter your computer without using virtual sandboxing when testing out extreme possibilities of stupidity, I blanket cover it with a note on backing up your PNG files before compression.

If I took your place and wrote instructions on handling saves (either emulated replicate like native saves or as save states, and native saves copied from actual hardware) for your screenshot guide, I would have to cover questions like "If I use a hardware native save file, and I came across a point where I save in-game in an emulator either by prompt or automatically (that's not a save state), does it alter the actual file?", or "Where are the save states and emulated native saves stored?", and write them out either by describing the process of how these emulators function and execute when dealing with save files, put it in a FAQ format, or just blanket cover backup your stuff. --RAP... 02:44, 8 May 2016 (EDT)

Section added. User:Wildgoosespeeder/sandbox --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:49, 11 May 2016 (EDT)

Personal Lists vs. Tagging

Personal lists as well as tagging both have their pros and cons. Personal lists are great for people who are dedicated to supplying images and are aware of on-going MarioWiki projects but risks being too obscure for regular users. Tagging is more up front about requesting a better replacement image but overtagging is a concern and users should just upload anyways.

If you interested reading this sub-topic lurkers, Wildgoosespeeder (talk) and I discussed this topic on my talk page (click here if the talk page was archived) about my perspective on my experiences and tasks in working on my personal list of images that need to be tackled.

In regards to how my project progress goes, most of the reports and activity came from the MarioWiki forums (I will still refer to it to this day). Users that aid my project would usually discuss and debate on anything that has to do with images. Doing the percentage each week was tedious, as I had to manually total up all (this post is a good example) the crossed out images from all the sections I covered in the project. It got to the point that Megadardery (talk) aided me in manual counting to rack up the percentage. I abandoned the project because of focus on college education, and felt that it wasn't getting enough help, not realizing this project covers a niche that not all users may have time or skill (on getting highest quality images) to tackle it (which sucks thinking about it). 3 years later and then I pop up on these kinds of stuff after checking MarioWiki each month passively to see how it's going. --RAP... 20:55, 18 April 2016 (EDT)

Screenshots

How do we define good screenshots? Internal native resolution (User:Wildgoosespeeder/sandbox)? What actually displays on an SDTV or HDTV? Should oversized screenshot images be discouraged? Encouraged?

I think the best screenshots show the best impression of the game. Internal native resolution is ideal, I believe. That means the screenshot should be at the closest size to the game (File:Ground Pound Down.png is at a close resolution to native, File:MarioMechs.png is probably oversized. BUT, if oversized screenshots exist, we should not be going backward to replace them. File size may not be a concern, but it's still best to save at internal native resolution to prevent bloating. This opinion may rub a bit against my sister, where File:Mario Party 5 Bill Blasters.png in this image, I attempted to revert to a closer native resolution, but she just undid it because she thinks the higher resolution is worthwhile. It's me, Mario! (Talk / Stalk) 22:16, 12 April 2016 (EDT)

My experiences with GCN and Wii screenshots have been very tricky. No other game system have I had issues with generating 1x native screenshots through emulation or some other method. I know my uploads are not native at all. The developers themselves of Dolphin Emulator have stated the screenshot code is looking at the wrong "buffer" when it is saving a frame as a PNG. Other emulators don't have this issue or there are very easy ways to get this corrected. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 22:21, 12 April 2016 (EDT)

Don't worry about getting it exactly at native. We're not as stringent as SmashWiki (who's adamant about resolution sizes) when it comes to resolution, so don't let these issues get in the way. If you can't get it exactly at native, but you can get the aspect ratio correct, just don't bother. It's me, Mario! (Talk / Stalk) 23:01, 12 April 2016 (EDT)

In my opinion, I do personally like the looks of higher resolution screenshots. My opinion of this is why not? If we can capture gameplay with better clarity via emulation and therefore illustrates subjects better, then I like it. In my opinion, it's not that much different than rendering game-ripped models at higher resolutions than the game they originally appeared in. Ray Trace^(T|C) 23:03, 13 April 2016 (EDT)

The issue of oversized emulator images vs. real hardware render is usually due to how true 3D graphics render vs. sprite-based renders. Rendering 3D images in general to look nice in a specified resolution does a lot of behind-the-scenes math that can round out rough edges before converting that scene into what is called a raster graphic, similar to how vector graphics work but in three dimensions instead of two. If you were to do the same to a sprite-based render, which is just a dynamic raster graphic, you would be duplicating pixels, increasing redundancy in the image. In that case, you are better off with 1x native because we can resize that on-the-fly to be any multiple native resolution without affecting the source image. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:46, 13 April 2016 (EDT)

So, the HUD could be bloated? HUDs that are 2D are extremely common, so wouldn't those be bloated? It's me, Mario! (Talk / Stalk) 14:15, 15 April 2016 (EDT)

100% the case with N64 games. I've noticed a few oddities with oversized Wii games. The world "Life" in the life meter of Super Mario Galaxy seems to be a vector graphic or something because no blurring occurs to make it appear smoother unlike the number (:File:Buldergiestpunching.PNG). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:34, 15 April 2016 (EDT)

Nope, for the sake of the argument all HUDs I have seen are raster sprites, Dolphin just does "behind the scene" edits and scaling to make the sprites look better when enlarged.--

09:17, 18 April 2016 (EDT)

Oooh, good point, so I guess I'll have to throw out the sprite bloating argument. I still don't see exactly why we need 2K-sized screenshots when something close to native resolution works perfectly fine. It would ease screenshot browsing for starters. It's me, Mario! (Talk / Stalk) 21:01, 18 April 2016 (EDT)

The way Dolphin takes screenshots is faulty. It's looking at the wrong buffer. I keep trying to explain this to Megadardery (talk) as to why I upload oversized versions of GCN/Wii game screenshots but I don't think I am being very clear with communicating that fact to him because he keeps wanting to extend that argument to N64 games as well. The thing is that N64 emulation screenshot code is working perfectly for games running at native 320x237 while Dolphin is not. Usually N64 games are running in 320x237, but sometimes I see games truly go 640x474, like Bulbapedia:File:Pokemon Stadium Mode Select.png. Dolphin has a hard time capturing at native cleanly, even with recommended settings to capture at native resolution without the image being too large. Widescreen-enabled games have issues the most. The devs themselves have said so. The oversize resampling that happens above 1x native, which is the method I am currently recommending, just hides the blunders of the faulty screenshot code trying to capture at native at the expense of being bigger than what a real GCN/Wii can produce. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 00:24, 19 April 2016 (EDT)

Maintenance Concerns

Is this just pointless maintenance or does this maintenance save time and energy in the longrun?

If I thought it's pointless, I wouldn't be providing feedback AND I would be saying that it is a waste of time. It's me, Mario! (Talk / Stalk) 00:25, 13 April 2016 (EDT)

Not specifically you, but it could be a concern of others. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 00:38, 13 April 2016 (EDT)

In the long-run, it's far better organization than what we currently have now, where literally everything is slapped under one header. Editors will find this more useful than sifting through images which all have their own problems. Ray Trace^(T|C) 23:14, 13 April 2016 (EDT)

Other Concerns

Voice them!

PNG Monster Misconceptions

I think there are some misconceptions about what PNG Monster does to existing PNGs. Technically, a PNG is an already compressed bitmap image just with the PNG extention instead of BMP. PNG Monster is there to apply the best compression algorithm possible for each PNG it looks at and remove meta data that is unusable in a web browser (like EXIF data that can be found on JPEGs). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:04, 26 May 2016 (EDT)

Potentially Bad Images (Not Really Up For Discussion But Rather a Personal Log)

It has been requested that this image be reuploaded for better quality.

PNG and clean versions wanted. --Wildgoosespeeder (talk)

File:Character - Pink Gold Peach (Tennis).png File:Character - Metal Mario (Tennis).png File:Character - Rosalina (Tennis).png File:Character - Wario (Tennis).png File:Character - Donkey Kong (Tennis).png File:Character - Waluigi (Tennis).png File:Character - Boo (Tennis).png File:Character - Baby Mario (Tennis).png File:Character - Baby Luigi (Tennis).png File:Character - Diddy Kong (Tennis).png File:Character - Bowser Jr (Tennis).png File:Character - Daisy (Tennis).png File:Character - Peach (Tennis).png File:Character - Birdo (Tennis).png File:Character - Yoshi (Tennis).png File:Character - Luigi (Tennis).png File:Character - Mario (Tennis).png File:Character - Bowser (Tennis).png File:FloatCastleII.png File:MTM Paradise.png File:Boo PMSS.png File:AngryKab-Omb.png‎ File:3DSrecorder.PNG File:3DScamera.PNG‎ File:Cheep Cheep PMSS.png‎ File:LightBlueYoshiYS.png File:MPDS-DesertDuel.png File:Paper bowser jr..png File:Satella-Q-Toad.gif File:SatellaQPointSystem.png File:SatellaQToad.png File:SatellaQToadGame.png File:SMW2-YI - Ice Block.png File:Paper Mario making copies of himself..jpg File:Bowser meets Paper Bowser.jpg File:PJwigglerboss.png File:TDS Balloon Fighter.jpg File:TDS Donkey Kong.jpg File:TDS Excitebiker.jpg File:TDS Ice Climbers.jpg File:TDS Yoshi.jpg File:TDS Standard.jpg File:TDS Push.jpg File:TDS mainmenu.jpg File:TDS Catch.jpg File:TDS Mission.jpg File:TDS Standard2.jpg File:TDS Touch.jpg File:Yoshi Touch and Go Multiplayer.jpg File:Beehoss Bees.gif File:Peps.gif File:Pwallop.gif File:Stonk.gif File:Japan hole.jpg File:UK.jpg File:PMTTYDChapter1Title.png File:PMTTYDChapter2Title.png File:PMTTYDChapter3Title.png File:PMTTYDChapter4Title.png File:PMTTYDChapter5Title.png File:PMTTYDChapter6Title.png File:PMTTYDChapter7Title.png File:PMTTYDChapter8Title.png File:AzaleaHIOAT.jpg File:BetaMGATcastle.jpg File:Castlepeachsprite.jpg File:DKHoleInOneAT.jpg File:DKStatsAT.jpg File:EagleNeil.jpg File:EllaEagle.jpg File:EllaHoleInOne.jpg File:HoleinoneMario.jpg File:KidHoleInOneAT.jpg File:MarioEagleAT.jpg File:NeilAlbatross.jpg File:NeilHoleInOne.jpg File:Ninebogey.jpg File:PeachStatsMGAT.jpg File:RoughMGAT.jpg File:Sherry.jpg File:SherryHIOAT.jpg File:TripleBogey.jpg File:DDRMMboos.jpg File:DDRMMKoopa.jpg File:Ddrsuperhard.jpg File:HammerBroGuardsDDRMarioMix.png File:DDRMM IceSpiny.jpg File:WheelMice.png File:BessieBass.gif File:BlackyoshiYIDS.jpg File:Crusher Blargg.gif File:Whit Yoshi YIDS.gif

File:SMG2 Dino Piranha Defeated.png File:Dino Piranha Angry.png File:SMG2 BBG Medal.png File:SMG Beach Bowl Cave.png File:SMG Beach Bowl Grass.png File:SMG2 Flipsville Starting Basement.png File:SMG2 Flipsville Starting Planet.png File:SMG2 Dirt Tower Underside.png File:SMG2 Honeyhop Queen Bee.png File:SMG2 Honeyhop Start.png File:SMG2 Bob-Omb Planet.png File:SpStG6.png File:SMG2 Hot and Cold.png File:SMG2 Whomp Lava.png File:SMG2 Meteor Gate.png File:SMG2 Lava Cube.png File:SMG2 Bowser Statues.png File:SMG Secret Room.png File:SMG Capsule Star.png File:Freezy Flake Launch Star.png File:SMG2 Stone Mountains Side.png File:SMG2 Cloudy Drums.png File:SMG2 Paintbrush Planet.png File:SMG2 Tape Roll Planet.png File:SMG2 Pencil Planet.png File:SMG2 Palette Planet.png File:SMG Chomp Saucer.png File:SMG2 Yoshi Star Welcome.png File:SMG2 Yoshi Star Road.png File:DinoMighty Shockwave.png File:DinoMighty Tongue.png File:DinoMighty Lava.png File:Winter Windster Evil Eye.png File:Winter Windster Arena.png File:Winter Windster Boulders.png File:SMG2 Tower Planet.png File:SMG2 Fossil Planet.png File:SMG BJAA Bowswer Jr Star Bits.png File:Spideraticus Power Wave.png File:Spideraticus Glue Globes.png File:Mean Emcee Arena.png File:Scythe-armed Monster attacks.png File:Clown-a-Round Ball.png File:Clown-a-Round True Form.png File:Clown-a-Round Heads.png File:Dual Dragon Fire.png File:MegaHammerWeak.png File:SMG Goombeetle Screenshot.png File:Tbutton.png File:Spooktastic World Exterior.png File:Thrillsville Exterior.png File:SMG Topmaniac Dormant.png File:SMG2 Whomp King Arena.png File:SMG Rolling Green Start.png File:SMG2 Fiery Flotilla Switch.png File:SMG2 Slipsand Gravity.png File:SMG2 Cosmic Clone Chase.png File:Wanwan Sky Station.png File:SMG2 Shiverburn Frozen.png File:SMG2 Gravity Castle.png File:SMG2 Cheep Cheep.png File:King Boo Bowser Fight2.png File:King Boo Bowser Fight1.png File:King Boo Bowser Fight3.png File:DKJC King K. Rool.png File:DKJC Fiery Volcano Jungle.png File:DKJC Fiery Volcano Pebbles.png File:DKJC King Kruiser IV Saws.png File:DKJC King Kruiser IV Crane.png File:DKJC Kremling Dock Crusher.png File:DKJC Panic Factory Crane.png File:DKJC Panic Factory Outside.png File:DKJC Kremling Dock Outside.png File:DKJC Toybox 3.png File:DKJC Glass Labyrinth 3.png File:DKJC Little High High Island.png File:DKJC Little Chill 'n' Char Island.png File:DKJC Glass Labyrinth 2.png File:DKJC Little Ghost Island.png File:DKJC Toybox 2.png File:DKJC Little Lost Island.png File:Robot Kremling Head.png File:DKJC Mega AMP Complete.png File:DKJC Kremling Head.png File:DKJC Forest Ruins.png File:DKJC Snowful Slope.png File:DKJC Veggie Patch.png File:Giant King K Rool.png File:DKJC Panic Factory.png File:DKJC Spooky Woods.png File:Beat Block Goombeetle.png File:Bugaboom SMG2.png File:SMG2 King Kaliente.png File:Major Burrows SMG2.png File:Elder Shrooboid Appears.png File:Evil King Battle.png File:Rank B Portrait.png File:Rank A Portrait.png File:Rank C Portrait.png File:Rank D Portrait.png File:Rank E Portrait.png File:Rank F Portrait.png File:Rank G Portrait.png File:Rank H Portrait.png File:Rank S 3DS Portrait.png

File:Rank A 3DS Portrait.png File:Rank B 3DS Portrait.png File:Rank C 3DS Portrait.png File:Rank D 3DS Portrait.png File:Rank E 3DS Portrait.png File:Rank F 3DS Portrait.png File:Rank G 3DS Portrait.png File:Rank H 3DS Portrait.png File:Black Hole SMG.png File:BowserBlockBattle17-MP9.png File:BowserBlockBattle16-MP9.png File:BowserBlockBattle15-MP9.png File:Orange Rabbit.png File:Green Rabbit.png File:Bowser Jr Final Battle.png File:Captain Skull's Showdown.png File:Ghost Spring.png File:RedBriefJ Attack5.png File:RedBriefJ Attack4.png File:RedBriefJ Attack3.png File:RedBriefJ Burned.png File:RedBriefJ Attack2.png File:RedBriefJ Attack1.png File:RedBriefJ Entrance.png File:Glamdozer Belly.png File:Glamdozer Lava Sprouts.png File:SMG2 Bouldergeist Crushing.png File:MMG2.png File:MMG3.png File:MMG1.png File:MMG5.png File:MMG0.png File:MMG4.png File:Squizzardcannons.png File:Squizzard Battle.png File:SquizzardBombs.png File:Blue Prince Bully.png File:CapturedGearmos.png File:BanzaiCannon3D Land.png File:SM3DL Hammer Bro.png File:SM3DL Magikoopa.png File:SM3DL Dry Bones.png File:Gold Statue Heart.png File:SpaceJunkPurple.png File:DeepDarkDaredevil.png File:GoodEggSpeedy.png File:BeachBowlFastFoe.png File:Pi'illo Temple.png File:Yellow Gearmo.png File:Pink Gearmo.png File:Blue Gearmo.png File:Green Helibird.png File:Black Helibird.png File:Pink Helibird.png File:Yellow Helibird.png File:Ghastly King Defeated.png File:Ghastly King Mount.png File:Tusk Battle.png File:Roc Battle.png File:Hog Battle.png File:Hog Defeated.png File:Defeated Tusk.png File:Roc Egg.png File:Tusk Heart.png File:Tusk Trunk.png File:Red Cataquack.png File:Black Chest.png File:First Spriteling.png File:Treasure Square Destroyed.png File:WonkyCircusCogs.png File:Desert Fungus.jpg File:Treasure Button Green.png File:Treasure Button Cyan.png File:Treasure Button Yellow.png File:Treasure Button Blue.png File:Treasure Button Purple.png File:Treasure Button Red.png File:Treasure Button Chartreuse.png File:Treasure Button Pink.png File:Winter Windster Wario Inflation.png File:Blue Crystal Creature.png File:Yellow Crystal Creature.png File:Red Crystal Creature.png File:Yellow Crystal Creature Flying.png File:Red Crystal Creature Flying.png File:Blue Crystal Creature Flying.png File:Barrel Buster Mirror Mansion.png File:Barrel Buster Shivering Mountains.png File:Greenhorn Ruins Statue.png File:Greenhorn Forest Statue.png File:Wonky Circus Statue.png File:Horror Manor Statue.png File:Mirror Mansion Statue.png File:Pecan Sands Statue.png File:Beanstalk Way Statue.png File:Shivering Mountains Statue.png File:Giant Treasure Key Thrillsville.png File:Giant Treasure Key Sparkle Land.png File:Giant Treasure Key Excitement Central.png File:Excitement Central Magon.png File:Beanstalk Way Magon.png File:Horror Manor Small Magon.png File:Pecan Sands Small Magon.png File:Mirror Mansion Small Magon.png File:Shivering Mountains Small Magon.png File:Wonky Circus Small Magon.png File:Upside Dizzy Starting Planet.png

Comments

A lot of these images were tagged by Hiccup (talk). While I do understand that game-rips are preferable, are they accessible for general people like wiki editors? Ray Trace^(T|C) 23:04, 13 April 2016 (EDT)

I think I have another tag idea that {{image-quality}}, {{tweak}}, and {{Convert to PNG}} would be too extreme. I don't have much experience dealing with game rips but I think I have a tag that Hiccup (talk) would be happy with (in theory). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:09, 13 April 2016 (EDT)

Tweak would apply to most of those, so those images should go under there. Ray Trace^(T|C) 23:13, 13 April 2016 (EDT)

The images Hiccup specifically had issues with, that is where a tag that deals with a subcategory of {{tweak}} comes into play. The other images, yeah, {{tweak}}. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 23:21, 13 April 2016 (EDT)

My overall concerns regarding everything that has to do with images

PNG vs. JPG

Sure JPG images are not as heavy as PNG, but the lower quality and the difficulty (due to how many settings can be set, png is just a set and go) of using them is not worth the bandwidth, I remember Porplemontage saying something about how the bandwidth is not an issue currently, you can ask him again if you want, but even if it becomes tight, there are a dozen and more of edit warring of high-res images that can be deleted if it is absolutely necessary. Again you should ask Porplemontage if you are so concerned about this issue.--

I know, a very late reply. I was very wrapped up with our native resolution conversation at the time (see bottom of the page). I needed a cool-down period. I think that issue is separate from figuring out how to split up images currently found in Category:Quality requested. Anyways, for sure, all console screenshots, except N64, GCN, Wii, Wii U, DS, and 3DS, are better saved as a PNG than a JPEG because the file sizes are significantly smaller (exceptions for sprite-based games, such as Tetris DS). JPEG is debatable for those consoles that I made an exception for. True 3D with shaders and lighting effects have far fewer redundant pixels for PNG compression to take advantage of. Exceptions possibly being any game in the Paper Mario (series) and toon-shaded games. Best way to sum up PNG vs. JPEG. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:38, 26 May 2016 (EDT)

Emulators bugs

I don't mind creating a separate template to deal with these issues. They are extremely low in count though. They should be replaced, but depending on the case, they are usually of a lower priority than image-quality. Sometimes the errors are so minor that it doesn't even matter (like the HUD), and in the meantime, you can add to the images' aboutfile description to state that something in this image is wrong and should not appear on the actual hardware.--

The whole draft thingy

I don't think we need to create a policy page for such a thing, especially because those guidelines are not rules, they are recommendations, I believe it is certainly more efficient overall to redraft it for a help page. That would be the best way to go, and most users would like to refer to a help page, more than a policy page. Remember, these are simple guidelines, not strict rules marked in stone.--

Agreed. Actually, all of MarioWiki's policy can be argued as guidelines. However, help pages are more of a resource rather than establishing rules, and I think this page would be exactly that: a useful resource. It's me, Mario! (Talk / Stalk) 21:03, 18 April 2016 (EDT)

If you check my talk, he seems to suggest my guideline page should be a rule than a helpful resource as dictated by sysops. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:41, 26 May 2016 (EDT)

Well that is not something I agree with. These should not be rules, these should be recommendations. I wouldn't even discourage people from talking youtube screenshots.--

19:52, 26 May 2016 (EDT)

There are a few advantages to making uploads more restrictive as desired by sysops, such as getting the best possible image to make our wiki be more professional in its presentation and reduce the need for {{image-quality}} and the proposal to make sub-templates of it. In other words, get the image upload right the first time. I say continue the discussion with Henry Tucayo Clay (talk) because that is the person who said it was OK on behalf of the other sysops. Even invite him to insert his thoughts on this page in the various sections I have set up. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:37, 27 May 2016 (EDT)

Native resolution

Ahh, the thing that we have been most disagreed on, I already stated my opinion countless times, but you seem to always answer with the same selective answer: Wii/GCN are hard to capture in native. Well, the MarioWiki:Image use policy clearly states that Screenshots with a resolution close to that of the actual hardware are preferable, so you should generally avoid uploading a 4K SMG screenshots. You could argue that this is an outdated source, especially because multiple users have mentioned that there is no harm in uploading high-scaled screenshots. But I can say the same thing for uploading "regular" (640px) sized screenshots for the N64. You will then argue that HUD scaling in N64 produces a low quality while the upscaling in Wii/GCN does not, I will then respond by saying that Dolphin does behind the scene edits to the sprites (that's why TTYD even looks good in hd) and then tell you that we should basically stick to what the console outputs to your screen normally, and that "native" N64 are small for the eyes, decent sized screenshots are more efficient at displaying the subject in question. You might then argue about the DS native res and about some technical aspects of how the console actually works. Finally I would respond by saying that DS was carefully and clearly designed for a small screen, the games were too, so that is not an issue, and I will say that it doesn't matter what the console does technically, the users and the player only care about what they see, they don't see the digital stream of info, they see a slightly upscaled game for their convenience, we should reflect that.--

The thing with N64 emulation compared to GCN/Wii emulation is that it is very behind in its development. GCN/Wii emulation has had more active development to it. The very well known plug-ins, such as Glide64, Rice Video Plugin, and the Project64 default plug-ins, all have various levels of inaccuracy, such as glitching and producing unwanted artifacts. The angrylion plug-in more closely matches what an N64 is able to produce (probably due to un-reverse-engineered hacked out N64 code being interpreted by the emulator or something, I don't know how that stuff works). If this were used to produce screenshots for N64 games, it would eliminate any question of uncertainty that the screenshot has a certain minimum level of quality to it to be considered acceptable. I can't exactly pinpoint why GCN/Wii games upscale better than N64 games. It could be a 3D architecture difference being run on computers. I need an expert on how translating N64/GCN/Wii instructions for a modern CPU/GPU works. Is it harder for N64 games compared to GCN/Wii games? --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 16:21, 18 April 2016 (EDT)

I'm slightly in favor of sticking to a regular/native res for all systems as close as possible (as close as possible to what a capture card outputs, my opinion of emulator images is that of a super high quality capture card). And that includes 640px N64 whenever possible. And simply not uploading high scaled GCN/Wii images (that being, stick to the 1x Native setting, and take the screenshot in windowed mode) If you are going to create another proposal, I recommend creating one about this specific issue first. I would like to see what the community as a whole thinks of this.--

10:23, 18 April 2016 (EDT)

Two faults: I have been noticing some patterns. The N64 is mostly incapable of producing true 640x480 images. The only cases it was able to were when 3D was not being rendered (Bulbapedia:File:Pokemon Stadium Mode Select.png). If you are going to upscale all N64 images to be 640x480, use with caution. If HUD elements are present, the upscaling will likely produce garbage results, such as poor filtering, pixelization, or blurring. Paper Mario specifically, it makes the paper styling of the characters look terrible. I don't know why you have this fixation that 640x480 is what a N64 can produce when it has been shown it can't in most cases. It is true that the signal coming from the N64 is 640x480, but the input used to convert into the 640x480 signal is 320x237. If you enter fullscreen using the proper configuration of the angrylion plug-in, this is likely what you are going to see on your TV. I can understand fixating on 640x480 with GCN/Wii games because the technology is much more powerful than the N64 and people analyzing runtime of the GCN/Wii games notice that it gets rather close to 640x480, but an N64 seems to not in almost all cases.

Also even windowed resolution is wrong. My screen still produces bigger than 640x480. It all has to do with how Dolphin is coded when it takes a screenshot. It is looking at the wrong buffer. One thing that N64 emulation does right compared to GCN/Wii emulation is it has tighter control over the display resolution. That is why I am pushing for native resolution more with N64 than GCN/Wii games. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 16:21, 18 April 2016 (EDT)

Again, you went with the technical response, I don't care what the "secret" behind the scene signal, I care about what 99% of the console original owners saw when they plugged their console and used a capture card. Emulators for me are glorified screen captures. And that's about it. 320px N64 games are just too small to properly represent the subject. You can take "normal" sized Paper Mario images with a little work and they will look normal, without many mistakes.

As for Dolphin screenshots, for starters, you can check the option "Auto adjust Window Size" to better try to stick to native resolutions. And second, our policy recommends images close to the native res, 4K is not close. You literally have no reason to try to capture HD Wii/GCN, except because it looks nice. But I can argue that 640px N64 looks nice too, and we will go on and on about what's native and what's not. Again, I don't care much about whether Dolphin screenshots are upscaled or not, I'm just bringing the argument you made against 640px N64.--

16:42, 18 April 2016 (EDT)

The good quality GCN/Wii screenshots are an entirely different debate because of screenshot-related bugs. As for forcing 640x480 on N64 games when they truly can't do that, that misrepresents those games and may spread misinformation about the N64's capabilities. Remember we can always force 640x480 on an 320x240 image like so: --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 17:09, 18 April 2016 (EDT)

which doesn't look that bad in my eyes, except that the file description page has the image down-sized. And for the last time, what goes for the N64 argument, goes for the GCN/Wii too, the only difference is that you can't get a "perfect" sized shot from Dolphin, you can get a close one though, which if you want to enforce native screenshots all over the wiki (I would oppose that, but let me continue for the sake of the argument) - would be as close as possible to the required quality, The GCN/Wii cannot even come close to such high resolutions, as for the N64, the console does a final scaling before outputting, which is fine and should be captured here. Any bigger than 640x480 should not be allowed though.--

18:25, 18 April 2016 (EDT)

My argument is that if we have tight control over screenshot resolutions to produce the true screenshots identical to real hardware internally, minus the digital-to-analog conversion that forces the screenshots to be 640x480 due to composite video specifications, we should use that. Else, we come up with alternative methods that are the easiest to perform. We can do that with every emulator that emulates each Nintendo console except Dolphin Emulator at this current time. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:40, 18 April 2016 (EDT)

This is the fifth time I said it thus far, with a little work we can get close-to-native dolphin screenshots. But again, it has been mentioned by a few users that we shouldn't restrict the size, and if that's true, then we shouldn't limit the N64 size to 320px. It's an inconsistency that has to be dealt with. Most ideally with a proposal, if enough people are interested in the topic. (The options I have in mind are, leave all sizes unlimited, limit both to the native (that being 320px for n64 and 640px-or as close as possible- for the wii) and limit both to the normal (that being 640px for both the n64 and Wii/GCN)--

18:58, 18 April 2016 (EDT)

Don't tie N64 screenshots with GCN/Wii screenshots. These are two separate issues. The problem is solved with N64 emulation screenshots but issues persist with GCN/Wii emulation screenshots, at least until the devs fix that which is explained below this paragraph. Anyways, bigger isn't always better because it doesn't take into account HUD elements. This only works with 3D models or vector graphics. Bitmaps or raster graphics, which is what the HUD of most N64 games are made out of, look poor when they are upscaled. Native resolution prevents this.

Your method to generate good quality Dolphin screenshots is just as faulty as my method because the underlying problem is with the screenshot code itself. I've talked to the devs directly and even they say the screenshot code is screwed up. It takes a picture of what displays in the window, with all it's scaled stretching, and not the internal resolution buffer itself. It especially has issues with widescreen-enabled games. On TCRF.net, there are reports of games running slightly under 640x480 at 1x native. To me, this just means there isn't much consistency to the "Auto adjust Window Size" setting as it has issues capturing images cleanly. Alterative measures should be taken because they produce better results. This is the only exception that should be made for the time being. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:56, 18 April 2016 (EDT)

I can't help but notice that are defending the HD Dolphin res, I think if we are going to stick to native in everything, we better stick close to 1x, and not jump to any higher than that. And what is the problem with a slightly stretched HUD on N64 emulators? It is better than modified screenshots, Dolphin cheats by visually modifying sprites. All that if we decided to restrict the size on screenshots, which has not been decided yet. Again a few users have said that it doesn't matter, which means that you shouldn't reupload N64 screenshots to a lower size unless there is a major issue with the image in its current form (which does not include slightly stretched HUD, which happens on your actual TV, and like I said, taking screenshots from a emulator in that sense would be like a capture card in a perfect world). If you want to do that, you have to change the rules.--

05:02, 19 April 2016 (EDT)

I had a feeling that is what you were thinking I was doing. That is not the case. I would be uploading native resolution if the screenshot code of Dolphin wasn't so faulty. It's the only emulator that I have used that has bugged screenshot code. I am simply trying to compensate for its inadequacies. I know what Dolphin is doing when upscaling from above 1x native. Although it does look nicer than N64 emulation upscaling, I do realize the upscaling is wrong. I'm doing the best I can to give MarioWiki great imagery. I think only you and Baby Luigi (talk) seem to be undecided about native N64 images. The other people participating in this conversation either don't care or are on-board for native N64 images. I think Henry Tucayo Clay (talk) also agrees with my N64 screenshots, even though he hasn't said anything yet. The only reason I think this is because he does delete images I tag that I think are poor quality. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:09, 19 April 2016 (EDT)

I need to say, I'm not an expert on emulation or native resolution. That being said, on one hand, while N64 images should not adhere to a strict, tight standard on sizes, while the other hand, we're supposed to replicate gaming impressions as accurately as we can, and at 320px, the screenshots look tiny. I think we should go with 640x480, even for purely sprite-based games like Dr. Mario 64 because 320px is tiny and I don't think the games were designed for 320px in mind, even though that's the internal resolution. At 320px size, the text File:Paper Mario First Meet Merlon.png is fairly difficult to read. Overall, I think it all boils down to taste, but I'll go for 640x480 because it's easier on the eyes (though it could be that I'm accustomed to this size) and it's the dominant resolution in the wiki. It's me, Mario! (Talk / Stalk) 17:14, 19 April 2016 (EDT)

OK, but how are we going to sample these images at 640x480 while still maintaining accuracy? Forcing a multiple of 1x native like we are doing for GCN/Wii games is wrong (but there is a valid reason for doing so until the Dolphin emulator does screenshots correctly). I say we just upload at internal native anyways and do what I suggested a little ways up ([[File:Paper Mario First Meet Merlon.png|640px|center]]) or we make an edit to the angrylion output by increasing it to 640x474 (no smoothing filters). This is what a real N64 does so that way it appears big enough on your TV. There is a mechanism that takes the internal resolution and converts it to composite video (640x480 480i). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:06, 19 April 2016 (EDT)

Overall, I think this isn't a big deal at all. In cases like this, I'd go with first comes first served. It's more important we get the images there on the first place, eh? It's me, Mario! (Talk / Stalk) 19:14, 19 April 2016 (EDT)

Even though bandwidth isn't a concern for Porplemontage (talk) at this time, I kind of want to make as little impact as possible on the resources while still maintaining quality images for MarioWiki (only exception is GCN/Wii games but the root of the problem is the screenshot code itself). That is why I push for internal resolution uploads. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:17, 19 April 2016 (EDT)

Of course, you can save space when needed, that's why we push for compression of .pngs, right? But if Megadardery or anyone else (like me) uploads images at 640px, don't start upload wars. I think both resolutions have their advantages and disadvantages so again, just upload as you see fit. It's me, Mario! (Talk / Stalk) 19:22, 19 April 2016 (EDT)

PNG compression is one aspect of reducing file space requirements of one file. Another factor is how the sample was achieved. If you sample in its purist and correct form (1x internal resolution for any game or system, see my guide), the file size is reduced even more while still maintaining accuracy. 640x480 images are 4x the pixels compared to 320x240 images. There is more than one way to maximize your compression. The only reason Megadardery (talk) was concerned with my uploading is because I was uploading over existing Paper Mario images. From my experiences, Paper Mario has been a tricky task at emulating the game correctly. I was more making sure that emulation inaccuracies were being removed. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:36, 19 April 2016 (EDT)

I have come up with a template sandbox that can be transcluded onto file pages so that way native resolution is preferred as an upload but the image can be enlarged to be in the resolution of how a TV would display it. User:Wildgoosespeeder/TVres/sandbox Here's an example: File:Glide64 2.png. I keep referring to this image because it is a personal image where I get to test out my template ideas. The template is very rudimentary. Any suggestions to improve it are welcome. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 21:20, 19 April 2016 (EDT)

I think it's a tad convoluted to attempt to compromise via template, if that's what I'm getting. It's me, Mario! (Talk / Stalk) 21:28, 20 April 2016 (EDT)

I do think so too. Best I can do. Have any better ideas? Maybe we can get Porplemontage (talk) to integrate some sort of plug-in that can better integrate enlarging those images without affecting the real size of the image. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 02:58, 21 April 2016 (EDT)

and why do that if we can just modify the real size of the image directly with no bad consensuses.--

09:32, 21 April 2016 (EDT)

Unnecessary file size increase and encourages wrong resolutions. It's better to perform this on-the-fly (doesn't affect the source image) rather than to induce this on the images (affects the source image). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 13:46, 21 April 2016 (EDT)

The file size increase is not a major issue, and it's a debate what's wrong and what's correct. Doing it in a separate template is annoying to say the least.--

15:07, 21 April 2016 (EDT)

Like I said before, I agree that the template probably is a terrible way to approach this, at least in its current condition. It was just a start of an idea that I think needs more than just a template to execute cleanly. I think this requires the help of Porplemontage (talk). --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:55, 21 April 2016 (EDT)

No, it doesn't need to be executed that way, there is absolutely no reason to even bother with this thing, porple elaborated that the bandwidth is not an issue, and we shouldn't consider it as such.--

19:27, 24 April 2016 (EDT)

Even if bandwidth isn't an issue, wouldn't it be logical to treat it like it is? That mentality should be encouraged while lazier approaches to screenshot submission should be discouraged, just don't enforce the rule like TCRF.net or don't forbid such screenshots. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 21:27, 24 April 2016 (EDT)

Yes, but in this case, the space saved is pretty negligent. I'd be more concerned about multi-K resolution screenshots than this. It's me, Mario! (Talk / Stalk) 17:16, 25 April 2016 (EDT)

What I'm aiming at is that the 640px should be the norm (and the size increase does not matter one way or another, I'm not encouraging mega-sized images), unless there is a major issue with the image (stretched HUDs don't count, because it's mostly unnoticeable). Because the bigger screenshots are more visible and clearer, and represents the console's final output. However, that doesn't and shouldn't mean that we should upload over every single 320px image. Only if it's seriously unclear. Are you okay with that?--

08:32, 25 April 2016 (EDT)

As long as the source image uploaded is ~320x240 for the N64 images and we can just specify 640px in the file link parameters (or integrate some sort of magnifying plug-in or modification that can do 2x or more the dimensions for file pages), yes. Remember that 320x240 is before digital to analog conversion, which is what happens between the N64 and composite video, as this is most representative of the N64's capabilities. Uploading true 640x480 images when the N64 is incapable of rendering it in most cases isn't right. This is different than stretching a 320x240 image to fit a 640x480 resolution. Refer back to the image I linked a little ways up about Merlon first meeting up with Mario. This is what I am suggesting. The sprite-based HUDs or text are just a good indicator if the output image is the correct size. If there are missing or duplicated pixels, or if the sprites are blurring or have artifacts to them, compared to the ripped counterparts, it's not the appropriate size. To make things easy and to minimize fiddling around with graphics settings, the angrylion N64 graphics plug-in, when set to be pixel-accurate, produces the right output when you take a screenshot. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 14:08, 25 April 2016 (EDT)

no, I meant uploading them straight out from the emu as 640px. And not using any templates whatsoever. This discussion is not working.

Your screenshot recommendation is 2x native in most cases, which is inaccurate to what a real N64 produces before the rendered frame is sent to the thing that makes it 640x480 (see this image when the N64 truly does 640x480). Like I said before, I acknowledge the template is not the best way to approach this issue, but it is the best I got. I think a better approach is modifying default MediaWiki file page behavior somehow instead of transcluding my template idea. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 16:52, 25 April 2016 (EDT)

This whole contentious argument still makes me think that it's all boiled down to preferences and we shouldn't make a big deal out of it. Images should be treated as a first-come, first served. It's me, Mario! (Talk / Stalk)

The thing that makes that mentality flawed is that uninformed users who submit images aren't aware that their submissions may be flawed. I'm finding it extremely common that emulated N64 games are being played like this (bad filtering), like this (inappropriate pixelated HUD elements), or like this (bad filtering even at 320x240). I can't blame the submitters though. They are likely playing on default settings of Project64 (most common) or Mupen64Plus (not sure). Don't get me wrong, I get what Megadardery (talk) is saying. From a pixel-accurate standpoint, the image is appropriately sized and every pixel is accounted for (my N64 screenshot submissions), but for a casual viewing perspective, it's too small. My suggestion leaves alone pixel-accurate images but finds a way to enlarge them on-the-fly. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 17:54, 25 April 2016 (EDT)

You can change obvious problems like filtering, but stuff like "pixel accuracy" and "appropriate size" shouldn't be tussled over. It's me, Mario! (Talk / Stalk) 17:56, 25 April 2016 (EDT)

We shouldn't be fussing over screenshot size, but we are. My suggestion is one way to try and find the best compromise that accounts for being big enough, accurate enough, and take up as little bandwidth/storage space as possible. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:05, 25 April 2016 (EDT)

I pretty much responded the same as LGM, so thankfully, someone other than me told you about it. Don't upload over already-existing 640px screenshots, otherwise make a proposal yourself before doing so.--

18:07, 25 April 2016 (EDT)

...but a lot of those 640px N64 screenshots are likely going to have flaws with them. That is the nature of sampling something beyond what it was designed to do. Pixel-accurate uploads fix that issue. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 18:12, 25 April 2016 (EDT)

subjectiveness--

18:52, 25 April 2016 (EDT)

Isn't that what we are trying to eliminate? I can show you more of your fixation towards 640x480 (or higher) produces artifacts that don't exist on real hardware output internally (can't say that is subjective):

• File:SM64 game over.png - (Game Over) The texture behind Mario's head in the background has perceptible lines. I am willing to bet that the game over texture is devised of at least four segments if you were to extract the textures somehow. The filters that the graphics plug-in is deploying applies the filters on a per-texture basis. It is going to have a hard time sampling four textures as a whole. I don't think it is even possible to filter as such without doing some major guesswork in the programming of the plug-in.
• File:Brothers Bowser Battle.png - (Bowser???) The file was appropriately filtered before being cropped from a 640x480 image. If you look at the file history, Jump has a white outline that doesn't exist on real hardware. Test this yourself. My overwrite that is smaller doesn't have that issue. It's sharp and precise.

--Wildgoosespeeder (talk) ^{(Stats - Contribs)} 19:39, 25 April 2016 (EDT)

Yeah, I'm with LGM here. This entire argument isn't really going anywhere; images should be first come, first served unless they have real explicit problems such as, I don't know, maybe like this where even normal readers can tell that the screenshot has problems. The policy is fine as it is now and doesn't need any change. Ray Trace^(T|C) 19:44, 25 April 2016 (EDT)

Hate to go off-topic but is LGM Bazooka Mario (talk) older initialed name she went by on MarioWiki? I'm only familiar with the name she currently goes by. :P

Also yeah, this isn't going anywhere. I just don't want Megadardery (talk) to feel compelled to revert the changes if native resolution images would overwrite technically oversized 640x480 N64 images. It's not just me that would do it. Hiccup (talk) is another person that does this sort of thing (like File:PaperMarioTitleScreen.png). There is nothing deeply wrong with 320x240 N64 images if their internal render is that big. It's just a gripe that Megadardery (talk) has to make sure users can make out what the image is displaying without squinting at it just like my gripe is making sure accuracy is maintained in the images we upload. --Wildgoosespeeder (talk) ^{(Stats - Contribs)} 20:05, 25 April 2016 (EDT)

Yup: LeftyGreenMario (talk). Also, if you ever looked at the right archives, I also went by Mario (talk) (that's for your information). My stance on "first come first served" also applies to Megadardery. I think both images have their strengths and weaknesses and they're both good enough to have for the wiki. It might be inconsistent in the end, but that's not a huge loss. Just as long as we get serivceable images in the first place, we should be good. Please no upload wars over this. If he reverts it, tell him to stop. It's me, Mario! (Talk / Stalk) 23:33, 28 April 2016 (EDT)

RAP (talk)'s thoughts

This section on native resolutions on video games will take a while for me to process, not in terms of reading this whole block of text between you (Wildgoosespeeder (talk)) and others necessarily, but the overall dealing of the concept of native resolutions from my experiences and observing this subject outside of this wiki, like discussions elsewhere or how users view images, if you acknowledge my through thinking from the "Target Audience" section; also college work and mid-terms! While my mind is slowly thinking though carefully in the background, if you are interested in one of the pieces of my thinking, refer to this very test page that I plan on out of many (click here if section doesn't exist anymore) if there is nothing else to talk about, which may be part of my attempted recollection of my thoughts. I made a separate sub-section because the overall section is getting longer and bigger to scroll through when editing for convenience (this could be it's own separate section that co-exists with the original topic, and not a sub-section of the topic). --RAP... 22:04, 25 April 2016 (EDT)