Talk: File Policy

Gifs?[]

I was wondering if animated gifs are acceptable? I was thinking of making animated gifs showing the animation of say a spell being used. While I know we have video support on the wiki, I feel gifs would have certain advantages over videos (various networks block Youtube, Youtube is beyond our control, etc). --Zenoxio 19:19, 16 May 2007 (CDT)

So long as they don't otherwise violate policy, go ahead. --Chrisjander 19:27, 16 May 2007 (CDT)

Is there a certain filesize I should try to stay under? I know gifs can get quite large if they are long. --Zenoxio 19:29, 16 May 2007 (CDT)

Try to keep it less than 50 KB if you can, less than 100KB if not. --Chrisjander 19:30, 16 May 2007 (CDT)

What file formats are allowed? Just GIF and JPG? can I use PNG? Tahngarthor 22:44, 13 June 2007 (CDT)

You can use png, but watch your file size, as they can get pretty big. --◄Chrisjander► t/ c 23:04, 13 June 2007 (CDT)

Well, I suppose I'm DL$S, but I do have advice for anyone who wishes to use the PNG format for their images. I Believe I've proven time and again against what Chrisjander said on 20070613 regarding PNG images, that they can get "pretty big" My advice is as follows:

Make certain the program you are using to take screenshots is outputting either BMP or PNG, because...
Conversion from JPEG to PNG will make compression difficult. It is better to have a JPEG than a PNG from a JPEG source
there exist programs which can recompress PNG images. your best bets would be AdvanceCOMP advpng and PNGOUT
keep an eye out for artifacts. some PNG images were converted from JPEG. in this case, a new source image will be necessary.
PNG performs best on non-photographic images. this is why most of the images i've submitted have been item description boxes.
in cases where animation is not required, GIF should be avoided, as, in cases where an image has 256 or fewer colors, PNG provides better compression, and in the case of greater than 256 colors, preserves all color values.

--Pandora Xero Is Not A Bot 09:06, 2 January 2008 (UTC)

Image Cropping[]

There needs to be a line or sentence or something that clarifies how images must be cropped, I've fixed a lot of images lately that have backgrounds showing outside the "gray border". --User:Charitwo/Sig 11:02, 28 August 2007 (CDT)

This is covered by extension of purpose of the transparent image clause: "Images of items should not have transparent backgrounds showing other players, zones, or any other obstructions." since improperly cropped items, which show outside the border, show other players and/or zones, these images, by minor extension of policy, are in violation of the image policy. I myself have replaced more than a few images for this very reason. This issue should probably be clarified, though. --Pandora Xero Is Not A Bot 21:25, 2 January 2008 (UTC)

Really? That's the very reason I made this section, it would seem. --User:Charitwo/Sig 21:31, 2 January 2008 (UTC)

IMHO it depends on what the image has to display. An item or key item or map etc. image should be cropped exactly to the border of their window. FFXI already stuffs things in windows, so when we want to display an item, the entire window should be displayed, nothing less, nothing more. Therefore, I believe the border of the window the item is displayed in should be the cropped size. When it comes to actual NPC/Mob shots, as long as the target is entirely displayed from the front perspective, the NPC name seen without any altered font and no Player Character in the frame of the picture, the cropping should be acceptable. NPC Images tend to work better with a higher height than width value since the NPC Infobox Template scales the Images down to a width of 200px. For images that are only slightly miscropped, for example having a pixel or two in one direction too many or too few, it is acceptable as long as there is no better image, but should be replaced when someone gets a better cropped picture with at least similar quality and file size. The priority should be Information > Overall-Quality > Cropping > File Size > Detail-Quality in my obligation. All five aspects matter, Information referring to outdated images, the overall quality referring to blurried images or transparent ones, cropping being the topic of this section, file size being something to ALWAYS keep in mind, and Detail-Quality referring to smaller problems with the quality, such as minor misplacements of pixels - which can always happen depending on image capturing and processing software. I believe to set aside many of the discussions we've had over images, we need to all agree on a priority scale for replacing images. An image that does not NEED to be replaced, when Information, Overall Quality and Cropping are acceptable, should still be replaced if anyone sees a need on the lower end of the priority scale, as long as the image is otherwise acceptable by means of the image policy. They wouldn't have to be marked for replacement, though. In other news, Charitwo, without any rudeness intended, please avoid comments such as the above, for they contain no information whatsoever, sarcasm and irony don't really add up to a good wiki. --Elvaron 05:17, 24 January 2008 (UTC)

Fish Measurements and Consistency - Clarification[]

In a conversation about images and policies I had with Pandoraxero, it has come to my attention that these measurements aren't really needed and can cause an inconsistency among images of fish. Because of the fact that selling a measured fish to the auction house erases these measurements, it's possible to have both unmeasured and measured fish, and I think it would be a good idea to mark measured fish for replacement across the board in order to have some consistency between them. Thoughts? --User:Charitwo/Sig 05:14, 2 January 2008 (UTC)

Since Charitwo is asking for thoughts on this matter, i figured i would impart to you a quote on ffxi which is ignored as much as it is output to the log:
If merchandise remains unsold after 9 weeks (Vana'diel time), it will be returned to your current residence. If a successful bid is made, the proceeds from the sale will be delivered to your current residence.
Signed items will lose their signature after being purchased.
Emphasis being on that final line. nowhere on there does it state that fish measurements will be lost. This, in effect, implies that Fish measurements are a signuature, despite their differences in appearance, database storage, packet structure, and storage in memory --Pandora Xero Is Not A Bot 05:38, 2 January 2008 (UTC)

Is this really hard to test? It's just a question of whether you can buy a fish with a measurement from the AH, right? The only reason to leave the measurements in the images is to track the potential fish sizes. If doing it this way however leads to bad/ugly images, then we can simply create a new box for smallest/largest fish and let is be done with text rather than images. --GAHOO t/ c 13:47, 2 January 2008 (UTC)

You cannot buy a fish with a measurement from the AH, that's the point. --User:Charitwo/Sig 13:55, 2 January 2008 (UTC)

I'd agree that fish images that have measurements probably ought to be replaced with images of the items from the AH list which do not have measurements. If, however, you really think that if you go to the AH and purchase a large fish that it won't have measurements on it, you need to go do some research. --TECHNO-- Talk / Contrib 14:57, 2 January 2008 (UTC)

Pardon? --User:Charitwo/Sig 15:08, 2 January 2008 (UTC)

You're saying that if I go to the AH right now and buy a Grimmonite, a large fish, that the fish I purchased would not have measurements on it. Is that right? --TECHNO-- Talk / Contrib 15:14, 2 January 2008 (UTC)

The last time I bought a large fish off the AH, it did not have measurements. It was a Ryugu Titan. --User:Charitwo/Sig 15:24, 2 January 2008 (UTC)

I don't know what, if anything, was wrong with that fish or how long ago you bought it, but I advise you to go check again. Something cheaper like a Gigant Squid or Grimmonite will do. Even though I was absolutely, 100% certain that measurements are left on the fish, I still went and bought a Grimmonite a few minutes ago off the AH. It had measurements. --TECHNO-- Talk / Contrib 15:44, 2 January 2008 (UTC)

I stand corrected. Upon a new observation, Techno's findings were found to be correct as of 20080102193000UTC. For purposes of this discussion, I have an image, [1], containing unaltered data, including evidence that the fish itself was bought off AH, as well as the item description box. While this IS how the item appears when in inventory, It is also a simple matter for one to go to the AH, and take as screenshot of the item as the AH shows it: without the measurements. Further, it is my opinion that, as this is VARIABLE data, one should not include the data, as there is:

No pre-agreed-upon value
No way to control the values
A range of values which would best be described in text

I'm of the opinion that ONE image containing the measurements should be kept for Reference Purposes, so that those who have, for one reason or another, never seen the measurements, know what they look like. Otherwise, it is my belief that, due to the uncontrollable nature of the measurements, they should not be included, and rather, should have a range specified on the item page, as Gahoo suggested above --Pandora Xero Is Not A Bot 21:06, 2 January 2008 (UTC)

Might as well replace that with the current transparent version. In any case, nice to have some clarification. --User:Charitwo/Sig 21:18, 2 January 2008 (UTC)

Hmm... see, that's the thing... pending culmination of this discussion, the new image might be invalidated. I suppose i could upload 2 versions of the image, one With the measurements, one without, and pending culmination of this particular discussion, either Revert to, or have deleted the first one I upload. Yes, i am a contrib-hungry bastard. --Pandora Xero Is Not A Bot 21:58, 2 January 2008 (UTC)

Offset Icons[]

It seems I have run into a "speed bump" of sorts with my image contributions. I have noticed that, on this site, there are a lot of item images which somehow have a shifted icon. Offhand, my best examples of this would be Image:Trump Gun.jpg and Image:Braves Gamashes.jpg. The icons in these images are shifted one to the left, and two down, noticeably protruding from the normal container. I have always been of the belief that the image policy is NOT exhaustive, and thus should be read in terms of context, rather than just content. An attempt at replacing these images resulted in Charitwo removing my new images, and giving me the following warning, among others: "Do not replace an image that does not need replaced. Ginger Cookie, Trump Gun, Brave's Gamashes, Spharai, Royal Squire's Sollerets, Foe Requiem V, Thunder IV, Chocobo Mazurka fit perfectly within the image policy and do not need to be replaced." While I will admit the reason for replacing the Ginger Cookie image was entirely size-motivated, the rest were NOT "perfect" and, indeed, were replaced due to an offset icon. This offset icon is NOT an accurate portrayal of how the item box would look in-game, and I feel that, just as with altered text, or altered backgrounds, this type of anomaly does not have a place on FFXIclopedia. I am not certain how so many images like this made their way in, but I feel that this is a problem, and that it needs to be fixed, and I am likely the only person with the means to fix it all. --Pandora Xero Is Not A Bot 20:31, 20 January 2008 (UTC)

Like with several months ago, you take things too far. And you are doing it again, making big deals out of things normal people don't notice. This "offset icon" reasoning is ill-founded and is just an excuse to get more contributions. You need to focus on things currently in replacements and image-stub. Those images are just fine. Focus on things that really need it. The policy stands. --User:Charitwo/Sig 21:21, 20 January 2008 (UTC)

The image policy is sound, even with the new addition related to size. If an image is put up for speedy deletion, and the admin believes that it is not warranted, it should be re-tagged as a normal delete and a AfD discussion begun. Speedy delete of the new image is not appropriate. In this manner, and only in manner, can there be a civil discussion among more than 2 people, about whether the replacement is warranted - with both images being on the site and being subject to review. --GAHOO t/ c 03:17, 21 January 2008 (UTC)

Agreed to Gahoo, please, both of you, don't take this stuff too seriously. You're reaching the realm of Edit War, where one adds an image where he sees a need of replacement and the other hastily deletes the work done. That shouldn't be how things are done, although I can understand Charitwo's way of thinking, that it would lead to too many AfD Discussions regarding offset icons. Therefore we should come to a conclusion where both parties can agree on a state, that leads to the benefit of the entire wiki. You both work hard on the wiki and none of your opinions are ignored here. The question at hand is how to determine whether a replacement is deemed necessary and therefore acceptable. I will here reiterate my proposal stated unter the section Cropping, a priority scale for Image Replacements: Information > Overall-Quality > Cropping > File Size > Detail Quality, with the first 3 requiring a Replacement Tag, the latter 2 not leading to a replacement tag, but are acceptable replacements as long as neither the 3 primary priorities nor the image policy is violated. And no, I will not take "the image policy is good as it is and will not be changed" as an answer. This is a subject we have to discuss and come up with a solution for, simply for the benefit of the wiki. An offset icon IS an offset icon and even if most users may not notice or care about it, we still have to take the matter seriously. Otherwise, all replacements are unnnecessary, as long as the user is able to somehow see what should be displayed by the image. We either go for precision or we don't. --Elvaron 05:29, 24 January 2008 (UTC)

Official Windowed Mode?[]

Just wondering... why aren't we supposed to upload pictures using the official windowed mode? I can get pictures that look fine enough by taking FFXI out of focus, and I'd rather not have to use the unofficial windower just to upload images. --Urth 10:50, 16 May 2008 (UTC)

Because the quality is horrible on official windowed mode. Even the standard in-game screenshot function is better. And we don't care if you use the unofficial windower for capturing images, we prefer it. Fraps is also a solution. --User:Charitwo/Sig 11:22, 16 May 2008 (UTC)

Clarification on where image is used[]

Please make it clear that the image must be located on the "User Page" - the wiki - and not the "Social Profile". I don't believe the distinction is clear enough between the two, many seeing the profile as their "user page". --Leuqarte 21:17, 23 June 2008 (UTC)

A social profile cannot be edited when it is in profile mode, which is why the image did not show as being used. If your User: namespace page is in profile mode, your Userpage is UserWiki:Username, if you click the toggle button, your profile gets moved to User profile:Username and you can now edit User:Username again. --User:Charitwo/Sig 21:46, 23 June 2008 (UTC)

Grammar edit[]

Violation of this rule will result in a temporary or permanent a ban from FFXIclopedia.

Strike the 'a' mentioned above, please :) --Leuq 17:33, 2 July 2008 (UTC)

Modeled Armor and weapons image policy[]

Do we have a policy concerning images of modeled armor or weapons that would be placed on the armor piece's article? (i.e. in regards to size, full-body vs cropped to only show armor piece, etc) A small percentage of item pages show a character modeling armor or weapons but I see no guideline that specifies the standard for this. --Leuq 03:06, 14 August 2008 (UTC)

Clarification of Backgrounds, please?[]

I don't understand what is meant by this: Images of items should not have transparent backgrounds showing other players, zones, or any other obstructions. This includes anything outside the border of the item. They should be easy to read with some type of solid background (we prefer #2, 4 and 6).

What do you mean by "transparent background"?
Regarding the second line ("anything outside the border"), I'm reading this to mean that you want the image as tightly cropped on the subject as possible, with nothing else around it. Is that correct?
What are backgrounds #2, #4, #6?

I've done some wiki-editing in the past, but haven't done much image editing. I'm hoping to add images for things around Bastok, but I want to make sure I follow policies correctly. Thanks! Altheav 16:38, 31 May 2009 (UTC)

"Transparent background" means the background of the window is transparent (i.e. you can see graphics drawn behind it, as opposed to an opaque background). This is seen in window types 1, 3, 5 and 8 (Menu > Config > Windows).
Outside of the border means anything outside of the border surrounding the window containing the item information.
Backgrounds 2, 4 and 6 are the background selections found in the Windows configuration (Menu > Config > Windows).

Daveoh 17:07, 31 May 2009 (UTC)

It refers to the setting you've chosen for Window type (Main Menu/Config#Windows) --◄Chrisjander► t/ c 17:29, 31 May 2009 (UTC)

Thanks! I discovered what you meant by transparency when I logged on to play and saw the windows (heh) but this helps a lot. Altheav 19:38, 31 May 2009 (UTC)

clarification on player character in screenshot of monster[]

From the way its written it seems the concern is a player in the way of seeing the monster:

Images of monsters should be uploaded with a filename containing only the mob's name and nothing else. (e.g. Robber Crab or Leaping Lizzy)
Monster images should be taken to the best of your ability with no other obstructions in the image besides the Monster.
The monster's name should be clearly visible in the original game font, altered fonts are not appropriate, but are acceptable until a more suitable replacement is uploaded.
If a Monster is unclaimed, player characters generally do not need to be in the shot.
Images should be taken from the front arc of the monster. It is understandable that there are times in the heat of battle where you may snap a shot and then upload it to the wiki. This is acceptable until a more suitable replacement is uploaded.

Is the intention to keep players out of screenshots altogether or just make certan the mob is fully visible and Should I crop and re-upload NM pics to remove the Player Character when possible? PollyWog 17:26, June 26, 2010 (UTC)

The intention is to keep players out of screenshots altogether. If it is absolutely impossible to crop the player out, we will reluctantly take it, but it needs to be flagged for immediate replacement. --User:Charitwo/Sig 17:28, June 26, 2010 (UTC)

Present Issues as I See Them[]

My issues with the image policy concern primarily the Item Image section.
Item boxes have been my specialty for a very. long. time. as some of the proverbial "Old Guard" can attest.
I have the following concerns with this section of the File Policy:

Images of key items should be uploaded with a filename containing only the exact name of the key item, with capitalization as it appears in the image, and nothing else. (e.g. Silver Sea ferry ticket or Map of the Aqueducts)
This sounds good. Web services, however, do not always play nice with special characters in filenames. Take, for example, "Dial Key #Ab", which I would normally give a filename of "I-DialKeyAb", I do this because the "#" character can cause bad things to happen. Likewise, Key Items such as ""Quiescence"", with their quotation marks, can, will, and do throw things off, same with items containing words such as "Al'Taieu", "Tu'Lia" or "Ru'Aun". In a similar vein, things such as Key Item "Job gesture: warrior" can cause issues as well due to the ":" character. Spaces make things difficult when dealing with large image sets as I do.
Images of items should be uploaded with a filename containing only the exact name in the description of the item (not Article name/Inventory name), with capitalization as it appears in the image, and nothing else. (e.g. Handful of stone arrowheads or Clump of Boyahda moss)
Prima facie, this sounds good, but there are Items and Key Items which share names. I prefix my images accordingly. A prefix of "I-" for Regular Items, "PKI-" for Permanent Key Items, "TKI-" for Temporary key items and so on. Additionally, who honestly has the patience to type out a full item name as shown in a description? Not I. "Stone Arrowheads" will be "StoneArrowheads"
Images should not contain any type of branding, such as a website name or the name of the uploader in the image or the filename.
I take no particular issue with this. However, if these images are needed, they are needed, branding or no. Images of this sort should be reviewed on a case-by-case basis. Additionally, it would be a trivial matter for me to insert a signature or block of text into my images which would be practically undetectable. I mean, my smallest of my images are, I think, 366x56. I could slip up to 7686 bytes of data into that and no one would know except me.
Item images should not contain player signatures or be altered (i.e. via photoshop or dat swaps) in any fashion.
well, this sounds good, too, but good luck getting an image for "Linkpearl", "Pearlsack", or an opened "Linkshell" with these qualifiers. there are also certain Holiday Items which cannot legitimately, to my knowledge, be obtained without a signature, so... have fun with that, I guess. Also, there's the "Glory Crown", which you have only ONE opportunity to snag a screenshot of without Naja's signature. So, yeah, have fun with that, too, I guess. I would like to add that, in all technicality, simply cropping the image can be considered as "altering" it. This part really needs to be reworded.
Images of items should not have transparent backgrounds showing other players, zones, or any other obstructions. This includes anything outside the border of the item. They should be easy to read with some type of solid background. If no other image is available, images with non-preferred backgrounds are acceptable until a more suitable replacement is uploaded.
I mostly agree, here. my arguments are purely semantic. My preferred background is BG#6, which is a solid background and compresses well in lossless algorithms. What does need to be stated here, though, is what backgrounds are and are not allowed. additionally, the dat swap thing needs to be re-emphasized here - only official backgrounds should be used. Otherwise, it would be a simple matter for me to swap out BG#6 with a solid black and get some ridiculous lossless compression. Additionally... I have recently run into a key Item whose text overflows outside the key item box. I would, in this case, either have to include part of the background... or crop out part of the last line.
Images of items should contain text in the original game font, altered fonts are not appropriate, but are acceptable until a more suitable replacement is uploaded.
no argument here.
Images should not be captured using the official windowed mode.
As I understand, the original reasoning behind this applies to image quality, and more specifically to environmental elements. It is not possible, using any official mode to capture item boxes. That said, it is possible to use screenshot utilities including the "PrintScreen" button and pasting the resultant screenshot into an image program, "Alt+Win+PrintScreen" to have Microsoft Game Bar - which at present (see signature timestamp) can only do up to 256 images without rebooting - capture a PNG screenshot of the current window. Or, as I am the "Linux Guy" here, there is a tool called 'grim' for wayland-based environments and another called 'scrot' for X-based environments, and either of them should be usable from a remote SSH session, but I only have experience with 'scrot'.
I have a relatively new concern, specifically regarding certain items with multi-page item descriptions. Should these be uploaded as two separate images, or should they be combined into one image? It would be a simple matter to combine them into a single file, but it should probably be stated here which way is preferred.
My concerns with this site presenting my images in a manner inconsistent with their intended purpose (that being pixel-perfection with size optimization) appears to have been nullified by uploading in WebP lossless format. This said, I feel there needs to be a certain specification regarding image formats. Specifically, it is my opinion that images containing primarily background/rendered content should be uploaded in either JPEG or WebP with Lossy compression. Images containing Item or Key Item Boxes - which are my particular specialty - should be uploaded in WebP with Lossless compression. -- Pandora Xero Is Not A Bot (talk) 01:48, 17 December 2023 (UTC)

I'll take some time to address the individual concerns here but I think the most efficient thing to do would be to dramatically shorten the 'image policy' to more common-sense bullet points (see https://finalfantasy.fandom.com/wiki/Special:Upload) and work on a separate, more comprehensive File Use policy and link to that. The actual file policy shouldn't try to cover every conceivable base as the tech has evolved since the initial authorship and will likely not stop evolving, but by and large I'd prefer the goals to make it easier for new editors to grapple with the act of uploading any file, not just images. Currently it's not clear from our upload page how to embed videos or music, for example, and other wikis have guidelines that cover both of those use cases. And I don't want to get perscriptive about file formats, either. Folks thought jpeg 2000 would supplant all and it didn't. APNG isn't well-supported on a lot of platforms. If someone only has a free or old image editor to work I don't want to reject their work on the basis that it didn't tick the correct checkboxes when exporting. The policy should be updated to say 'some modifications to screenshots are allowable (add link to guide on effectively editing media for visual clarity, perhaps), but full replacement of in-game fonts or graphics are not acceptable' in concise language and let editors choose a workflow they're comfortalbe with. The site has thousands of images that likely need replacement for being out of date or otherwise of unacceptable quality, so the fewer barriers to uploading the better, long term. ToastTheKnowing (talk) 06:53, 17 December 2023 (UTC)

As I was the one to update the Image Policy back in 2017 (which at the time was about four years overdue), which felt like unnecessary admin to a degree as there were precisely two of us uploading images and performing any major site updates, but I did anyway, I thought I'd weigh in.

Pan, I appreciate that you were uploading images on the site pre-2009. I don't remember if, like me, you shifted over to GE at that time, but I returned after a couple of years as I wasn't a fan of the layouts used on that wiki. You can probably tell that we've had a huge overhaul of item boxes here, spearheaded by Karuberu, with functionality enhanced by myself and Toast doing most of the heavy lifting (I'd guess that he's sourced and uploaded about 90% of all item images since 2017, which is likely around 10k items; I presume like me he has a local folder that can quantify that!). To your points:

Images of key items... Where special characters exist in item names that aren't accepted as standard filenames, just omit them. I think Jamcake always replaced special characters with a '-', which also seems a practical solution.
Images of items should be uploaded with... Hey, not even Toast pays attention to me on this one! This was stated because the filename should represent the image, and the image title is printed as the extended item name. There are hundreds of filenames not recorded like this, so I'm not losing any sleep for 'StnArrHds' if an uploader cba. When it comes to items that share names with Key Items or mobs, etc. then I put the qualifier in brackets after ie " (Key Item)", but again the standard varies by editor and we all have better things to do than align them.
Images should not contain any type of branding... This was effectively to stop people just uploading files from BGWiki, which from 2012 to 2015 was a massive drain on my time constantly correcting at the request of BG admins. If you want to insert an invisible signature, you do you (as you say, undetectable), but that sounds like an incredible waste of time.
Item images should not contain player signatures... This is to clarify that we don't want crafted signed items up. If it's an unavoidable aspect of the game, it's unavoidable. Feels like you're nitpicking minutiae talking about the use of the word 'altering' and the concept of cropping... this isn't a legal document! It's guidelines that apply to half a dozen people in the world who upload item images to the site.
Images of items should not have transparent backgrounds... I mean this is years ago... is it three of the in-game backgrounds that have a level of transparency? The other four or five are fine based on user preference. I do the brown, Toast does the brushed steel, we've got plenty of the deep blue ones on site too. Fine to re-emphasise in-game only. Not entirely sure the relevance of compression when talking about files that are a few dozen KB when basic redundant browser scripting is dozens of megabytes.
Images should not be captured using the official windowed mode... Right, so in 2017, official windowed mode wasn't borderless. This meant that taking screenshots in windowed mode resulted in an image that was compressed by the siz of the border versus the overall window size. We were getting a number of item images that were taken out of that with essentially missing lines (at eg 54 or 55px height for a 56px image). S-E subsequently made windowed mode borderless which stops this from happening. So this statement can certainly be removed!
Regarding certain items with multi-page item descriptions... Yeah I take a screenie of each page and combine them one under the other. Toast goes a bit further and (I presume) edits out the borders and elements to create a new item image altogether. As long as it's clear and shows all of the information, it's good as far as I'm concerned.
My concerns with this site presenting my images... I'll level with you, I have no idea what you're referring to when you're talking about purpose. I use .png because it's lossless. About 20 years ago I would have used .jpgs for rendered content, but we're at a point now where the difference between the two when compared to data connections which are vastly broader in capacity and speed, is negligible. Personally, before now I'd never even heard of WebP, and the image software I use to crop my .pngs (Microsoft Paint) doesn't need to be anything more than hella basic. For sure though, I don't have a problem with the format you want to use as long as the quality is consistent with what the site already has/aspires to.

My key point really is that do what works best for you as long as it doesn't impact other contributors and change the consistency of the site. As you're probably aware, there have been about five or ten major contributors to the site in the last 8 years, so devising and writing up strict rules aren't really a good use of anyone's time; certainly useful back in 2009 when we had dozens of active editors every day, a forum, moderators, sysops and tens of thousands of users, but yeah, not so much now. --Haldarn (talk) 16:53, 17 December 2023 (UTC)

I have been to the GE FFXI Wiki. And I'm aware of, and actively avoid, BGWiki. The problem with there being three wikis is that it makes the current situation a three-way race. Allakhazam Got Atari'd (Killed as a result of being too early) when FFXIclopedia was started, and among the three current wikis, SOMEONE is gonna get Sega'd (Killed as a result of simply being the third-place contestant like Dreamcast). GE is more focused on the XIV end these days, so it's likely going to end up being FFXIclopedia vs BGWiki. There are aspects of both which I do not like. But the community surrounding BGwiki has always seemed to have too much of an elitist mentality. As part of the Linux Userbase, I know a thing or two about elitist mentalities.

As far as my specific concerns - they are... well... highly technical. It took days of research to find the best way to optimize a PNG image. The file sizes I obtained on my PNG images are not something you can get through most PNG optimizers. I found that one may upload an image as a PNG, here, and, if I'm not mistaken, it is stored server-side as PNG. But likely through some sort of server-side script, your browser doesn't get served the PNG, it gets served a WebP image with lossy compression. You can use 'dumb' tools such as 'wget' to obtain the original file, but your browser will always be served the WebP format - Presumably unless the server-side script detects your user agent (i.e. Browser and Version) to be incompatible, but I have not tested this assumption. The fact that webp in lossless mode compresses better than my most heavily-optimized PNGs is salt in the wounds for me, especially considering the research and CPU cycles that went into optimizing my 2007 batch of PNGs, but I've had worse. The knowledge that I can upload a lossless webp and thus not have it converted to a lossy format (see File:TKI-ZeruhnReport.webp, which was my Test Case) is good news in that my image quality is preserved, and I get better file size. -- Pandora Xero Is Not A Bot (talk) 21:31, 17 December 2023 (UTC)

That's interesting for sure! I just ran a comparison between the .webp and the .png for ♪Adamantoise companion (you can access the original .png from the respective File: page). The .png is 51.44KB and the .webp is 16.70KB. Running a pixel comparison for the two images results in a 0.00% difference (pixel-perfect match), so Fandom's .webp does seem to automatically convert losslessly? If Fandom is innately optimizing, then that's great for the end-user (though we are only talking a couple of dozen KB, so impact for individual users of the site would be negligible - I guess spread over Fandom as a whole, that adds up though for them). What I'm trying to understand is why it's relevant for us editors to provide optimised file sizes if Fandom handle it on the back-end. I think our experience of Fandom's .webp files differs in that you're getting a lossy image back whereas I'm not? -- Haldarn (talk) 23:38, 17 December 2023 (UTC)

Are you quite so certain? This does appear to be true for the File:♪Adamantoise companion.png, but it does not seem to do the same in every case. File:Gil.png - one of my original works - is being served in lossy format. I downloaded both the webp and the png version, then put them both on my Linux rig, ran the following commands, and got the following output (certain data redacted for system security purposes):

~ $ convert Gil.png Gil.png.rgb
~ $ convert Gil.webp Gil.webp.rgb
~ $ ls -l Gil*rgb
61488 Dec 17 18:31 Gil.png.rgb
61488 Dec 17 18:31 Gil.webp.rgb
~ $ expr 366 \* 56 \* 3
61488
~ $ crc32 Gil*rgb
29570079        Gil.png.rgb
f1d5f175        Gil.webp.rgb

What this tells me is that the RGB values between the png and the webp for this image have changed, indicating some sort of lossy compression. CRC32 is far from perfect - it is collision-prone to an extreme, but when the CRC32 differs between two files of identical sizes, it means they aren't the same. Why this is not the case for your Adamantoise Companion (I ran the same test on it)... I don't know. It may have something to do with the symbol in the filename. I shall have to find another file and continue my research.

Additionally, I ran compression optimization on the Adamantoise Companion PNG. Results:

~ $ time advpng -z4i256 Adamantoise_companion.png
       52675       30349  57% Adamantoise_companion.png
       52675       30349  57%

real    0m25.641s
user    0m25.636s
sys     0m0.004s

I'm not going to bother replacing the file, though. Not when what's there works fine. 'advpng' is part of the AdvanceCOMP package, which is in turn part of the AdvanceMAME project, and it does have a Windows version. Just figured I'd give a little insight into my PNG workflow. MSPaint does only a mediocre job with PNG compression. -- Pandora Xero Is Not A Bot (talk) 01:18, 18 December 2023 (UTC)

I'd like to add, I've always walked a fine line between file size and image quality. I seem to recall a Talk Page and IRC Chat argument I had when I started my item image crusade - something along the lines of "Oh, PNG will always give a bigger file size!" "...actually, this PNG is smaller than the JPEG it's replacing" "Oh, you're only concerned about jaggies!" "...when you get a JPEG down to the file sizes I get, artifacting is quite noticeable" ... and so on. It's not like I'm against Lossy Compression - it has its place. The item box images, though, are not that place. I'm just glad it seems, for the most part, that people caught on.

Incidentally, I found a new test case. This time, I uploaded my file in PNG. File:TKI-AmaurasFormula.png - shows the same sort of issues as with Gil.png:

~/testing $ convert TKI-AmaurasFormula.png TKI-AmaurasFormula.png.rgb
~/testing $ convert TKI-AmaurasFormula.webp TKI-AmaurasFormula.webp.rgb
~/testing $ ls -l TKI-Ama*rgb
307440 Dec 17 20:53 TKI-AmaurasFormula.png.rgb
307440 Dec 17 20:54 TKI-AmaurasFormula.webp.rgb
~/testing $ crc32 TKI-Ama*rgb
1d120635        TKI-AmaurasFormula.png.rgb
7bd500af        TKI-AmaurasFormula.webp.rgb

There's definitely some issue with the backend. And File:♪Adamantoise companion.png was likely just an outlier - again, possibly because of the special character at the beginning. I'll have to see about breaking my naming convention when I get to the Mount Key Items to see if that is indeed the case. -- Pandora Xero Is Not A Bot (talk) 02:58, 18 December 2023 (UTC)

Why do these key item images need a crop of the system menu feedback (e.g. "Key Items | Temporary Key Items") at the top? Does the user need to see that when they look up a key item? Surely the categorization in the article page should satisfy curiosity there and not introduce redundancy? ToastTheKnowing (talk)

A fair question. It is for GEwiki consistency purposes. That said, I have no objection to removing the header. It is a simple matter for me that would take about an hour or two as soon as I have access to my Linux Rig again. Like say, I have the ability to automate the process entirely. I'm just not in a position right now where I can conveniently access the Linux rig. I'll fix it. Just give me some time. -- Pandora Xero Is Not A Bot (talk) 00:58, 19 December 2023 (UTC)

And when I call it a "header", that is, in fact, what it is. It's added to the image in post. It's a 75% scripted operation for the KI boxes. The 25% is what takes the longest time. I take the screenshots, The first script auto-crops the images, then I name the images, second script adds the headers, third optimizes the PNGs, and the fourth converts to webp. Since I intend to use only webp here going forward, I can add webp conversion to the second script before the headers are added. That should solve the issue -- Pandora Xero Is Not A Bot (talk) 01:43, 19 December 2023 (UTC)

Whilst renaming my files, Windows 11 Gave me the following message when I tried to use a special character in a filename:

A file name can't contain any of the following characters:
\ / : * ? " < > |

This means no one can be reasonably expected to name images with these characters - and I'm fairly certain, of these, :, ?, and " all appear in Item and Key Item Names. -- Pandora Xero Is Not A Bot (talk) 19:15, 23 December 2023 (UTC)