Commons talk:File types

This is the talk page for discussing improvements to Commons:File types.

This is not a forum for general discussion of the page’s subject.
Put new text under old text. Click here to start a new topic.
Please sign and date your posts by typing four tildes (~~~~).
New to Commons? Check out the project scope. Ask questions, get answers.

Archives: 1, 2, 3

This talk page is automatically archived by ArchiveBot. Any sections older than 180 days are automatically archived. Sections without timestamps are not archived.

Stray explanations of why some preferred GIFs

I'm looking at File:Blue dot 7px.png#Format and File talk:Blue dot 7px.png#More PNG troubles, which is basically one author's series of reasons why he preferred GIFs over PNGs (in 2008). Obviously, that file was converted to PNG and the GIF deleted and redirected despite the author's wishes. Others have not been converted, eg. File:Green dot 7px.gif. File:Nopngs.gif#filelinks has 17 links of similar notices. I reckon some of these actions should happen:

The conversion from GIF to PNG could be reverted.
The remaining GIFs could be converted to PNGs.
The notices about why GIFs are superior to PNGs could be removed from the images that have already been converted to PNGs.
The notices about why GIFs are superior to PNGs could be removed from all these images.

At the very least, a page on a PNG image shouldn't include an explanation of why it is a GIF, when it's not a GIF. Daask (talk) 16:18, 29 July 2024 (UTC)[reply]

Resizing static GIF images (in thumbnails) as PNG

I wonder why the Wikimedia thumbnail generator still tries to generate GIF thumbnails for GIF images, when the original GIF image contains NO animation (i.e. contain a single frame).
In my opinion, in that case, it should convert it just to an R8G8B8A8 PNG image. We should then no longer need to upload a PNG image for correct display of static GIF images at various sizes, with correct alpha transparency (allowing source 1-bit transparency to be correctly handled when pixel sizes are adjusted) and correct colors (no more limitation of the original 8-bit palette, no need to recompute an best-fitting palette for the resized image with subpixels color averaging). Of course, internal metadata in the GIF should be converted (notably if there are licencing/author info), and possibly an extra internal metadata specifying the GIF-to-PNG generator and version used by the Wikimedia thumbnail generator.
The GIF thumbnail generator for source GIF images should still be kept only for animated images, containing multiple frames, because we don't have good support of animation for multiframed PNG, and the alternative to convert it to animated SVG (which could be done simply by embedding the GIF into a SVG container as an "image" element with a "href=data:URI" using "base64" encoding), as many browsers still don't render SVG animation, given that SVG animation is still alpha (not enough specified and tested to be portable across a wide range of SVG renderers).

In that case we would not longer need to display the "badGIF" banner, asking users to convert the static GIF images and to edit all wikis to make the change with the new image. That banner is also not necessary and still undesirable for animated GIFs (as long as we don't have another option, such as converting these animations to an open "video" format, which could also be done automatically in the thumbnail generator, and would work better than using animated SVG: almost all browsers have now excellent support of HTML5 video).

Note that the static-GIF to SVG conversion (by embedding) works directly (the SVG renderers perform the conversion correctly, keeping accurate colors and transparency, including on subpixels). However the Base64 encoding may be verbose in terms of bandwidth for large static GIF image. The same is true for the JPEG to SVG conversion (by embedding): see many working examples in maps rendered with embedded bitmaps for texturing terrain models (elevation, shadows).

Additionally, these static-GIF-to-PNG (or animated-GIF-to-video) converters may become an external usable by users if needed, or on request by a bot to perform such conversion. Such bot could then automatically link the converted uploaded version in the GIF page description (this could be done first by running this tool specifically to perform tests, before integrating it to the thumbnail generator (which will still be used on wikis that have not edited their page to use the new version). Another bot could then safely edits wikis with images generated by this common tool. verdy_p (talk) 12:06, 6 January 2025 (UTC)[reply]

BMP files

I am not asking for BMP support to be added, I am just curious whether there a specific reason WAV (uncompressed audio) files are supported while BMP (uncompressed pictures) aren't.

My closest guess would be that a tool to convert BMP to PNG was pre-installed on Windows since its early days. Given that the majority of computer users run Windows, they can convert BMP into PNG using the pre-installed Microsoft Paint. But Windows has no out-of-the-box tool to convert WAV to any other lossless format. Also, Windows Media Player didn't have out-of-the-box FLAC support until at least Windows 8 or 10, so WAV was the only lossless audio format natively supported by Windows for a long time.

Also, audio like WAV is streamed, not loaded in one piece, so slower loading might not be noticeable to a user with weak connectivity. Elominius (talk) 08:27, 14 February 2025 (UTC) (edited 09:37, 14 February 2025 (UTC))[reply]