User talk:Wildgoosespeeder/QualityRequestTypes/sandbox

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. -- 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. -- 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, 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 tag. The way we go about finding images to tag will remain the same (casual regular everyday browsing of MarioWiki).

Definitions/Restrictions
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. 18:19, 12 April 2016 (EDT)
 * Right. I have that established in yet another future proposal. User:Wildgoosespeeder/sandbox. -- 19:50, 12 April 2016 (EDT)
 * I got a weird idea. Would a special tag for beta images needing a better image be acceptable? -- 23:06, 12 April 2016 (EDT)

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


 * 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 section of this proposal. -- 19:36, 13 April 2016 (EDT)

Template:Convert to PNG
No questions asked images should be PNG:

Iffy if JPEG or PNG:

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. 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. -- 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. 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. -- 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? 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). -- 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. 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. -- 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.

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

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.

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. 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. -- 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. 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. 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. -- 23:46, 13 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. 00:25, 13 April 2016 (EDT)
 * Not specifically you, but it could be a concern of others. -- 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.  23:14, 13 April 2016 (EDT)

Other Concerns
Voice them!

Comments

 * A lot of these images were tagged by . While I do understand that game-rips are preferable, are they accessible for general people like wiki editors? 23:04, 13 April 2016 (EDT)
 * I think I have another tag idea that, , and would be too extreme. I don't have much experience dealing with game rips but I think I have a tag that  would be happy with (in theory). -- 23:09, 13 April 2016 (EDT)
 * Tweak would apply to most of those, so those images should go under there. 23:13, 13 April 2016 (EDT)
 * The images Hiccup specifically had issues with, that is where a tag that deals with a subcategory of comes into play. The other images, yeah, . -- 23:21, 13 April 2016 (EDT)