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.

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


 * 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 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:
 * 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.
 * 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 byemulation (like 3DS and Wii U titles) is impossible due to the lack of emulators or they're not developed enough to take screenshots.
 * 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. -- 04:00, 16 April 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.

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)
 * So, the HUD could be bloated? HUDs that are 2D are extremely common, so wouldn't those be bloated? 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). -- 14:34, 15 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)