Page MenuHomePhabricator

Deprecate xcf files
Open, Needs TriagePublic

Description

Wikimedia sites have supported XCF files since at least 2006 (T3410). The idea was that the files would be used for collaboration on images and could be used to translate images. However, XCF files have not seen significant use, and continuing to support them no longer makes sense.

The XCF file format is described by https://gitlab.gnome.org/GNOME/gimp/-/blob/master/devel-docs/xcf.txt. That, however, is a descriptive specification, not a prescriptive one, and the files GIMP actually generates are not guaranteed to comply with it. That makes it more difficult for other tools to read and write XCF files. Major browsers do not support it, and there is limited support for it in other tools.

Wikimedia sites currently use (through Thumbor) the xcf2png utility from https://github.com/j-jorge/xcftools to convert XCF files to PNG files during thumbnailing. That library is largely unmaintained. It is based on a version of the spec from 2006, and received limited updates when it was forked in 2013 to make it compatible with GIMP 2.8. Updates since then have been maintenance only. The project also has two active unfixed vulnerabilities, CVE-2019-5086 (CVSS 7.5) and CVE-2019-5087 (CVSS 8.8). Thumbor has sandboxing in place to account for vulnerabilities in conversion libraries, but running a library with known vulnerabilities is less than ideal, to put it mildly.

ImageMagick also has limited support for XCF files. It is partially compatible with GIMP 2.10, but does not support all the features of the format. While some benefits would be gained by switching from xcftools to xcf2png (T260285), the inherent downsides of the format remain. (ed: XCF rendering on Wikimedia sites has used ImageMagick since 2023)

Because XCF files uploaded to Wikimedia sites are restricted to a limited feature set and can only be edited by a few tools, they are not very useful for collaboration. The application for translatable text has been entirely replaced by SVGs. Were XCFs being actively used for collaboration, I would expect to see them being frequently overwritten with new versions. https://quarry.wmflabs.org/query/47384, however, shows that almost all of the recent overwrites have been one user converting the files to a GIMP 2.8-compatible format.

Out of the 1,426 XCFs on Commons, only 640 are actually used anywhere: https://quarry.wmflabs.org/query/47385. That the list of top 5 most used XCF images includes a blank file is especially telling. Most of the XCFs with significant usage were used in talk page messages, not on content pages. The choice of XCF is not clear for almost all of them, and almost all would be better served by SVG or PNG format.

Proposed deprecation steps:
  1. Prevent new XCFs from being uploaded
  2. Prevent thumbnails from being displayed for XCFs
  3. Remove support for XCFs from Thumbor

The XCF files themselves would not be deleted, as some have some useful history that's worth retaining. MediaWiki itself could retain XCF support, it just wouldn't be enabled on Wikimedia sites.

Event Timeline

XCF files are thumbnailed into PNG files, which means they don't get conditional sharpening. This produces a blurry-looking result for photographs.

Is there another image file format that supports layers?

I've used .xcf. Overwriting is not needed, I just provided the .xcf so others could make their own variations of the file: https://commons.wikimedia.org/wiki/File:Hook_turn_layered.xcf. I didn't insert the .xcf directly in any article as that could confuse users. https://commons.wikimedia.org/wiki/File:Hook_turn_bicycle.png and https://commons.wikimedia.org/wiki/File:Hook_turn_car.png are in use though.

If there isn't a better supported image format with layers, I oppose this.

I am in favour of removing XCF support in future. We get a tiny number of hits against thumbor a day for XCF files, usually single digits. Admittedly, that would be for new thumbnails, but it's an indication of how little need there is for it. For the time being I am happy with the solution in T260285 though.

The proposed use-case of the format is for storing the editable source-code-esque version of a layered raster image. Its not clear if anyone is using it for that, but even if they were, i would not expect them to have very many views. That use case doesn't even require thumbnailing support.

Just fyi, here is a perma-link to the discussion on commons https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2020/08#RfC%3A_Deprecate_XCF_file_format . It wasn't a popular proposal.

It didn't have much opposition either - two "oppose" votes, plus the oppose above. There are only ~1700 .xcf files on Commons, afaics it's really not worth spending any effort on keeping it

Just fyi, here is a perma-link to the discussion on commons https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2020/08#RfC%3A_Deprecate_XCF_file_format . It wasn't a popular proposal.

It didn't have much opposition either - two "oppose" votes, plus the oppose above. There are only ~1700 .xcf files on Commons, afaics it's really not worth spending any effort on keeping it

https://commons.wikimedia.org/wiki/Commons:Village_pump/Proposals/Archive/2026/06#Disallow_upload_of_new_.xcf_files

Ok I didn't know about that, but even so - fixing the rendering (or writing new code to handle .xcf if we replace thumbor) means not spending time on something else, which is v hard to justify for a format with such a tiny amount of usage. To me it seems a a better use of our resources to deprecate it

I mean, when the external tooling starts dying, then it's sort of game over. But i'd like to point out that another option is to only disable the thumbnailing and keep the storage part of it. Support for storage is often easier to maintain, as it only requires extracting very basic metadata that we often already do php side.

I don't like allowing uploads of image files that we don't thumbnail -- it's a moderation problem. But I definitely agree that spending any developer time on XCF support would be a waste.

I don't like allowing uploads of image files that we don't thumbnail -- it's a moderation problem. But I definitely agree that spending any developer time on XCF support would be a waste.

What if uploading was restricted to confirmed (not autoconfirmed) and autopatrolled user groups? Both are only assigned by admins, never automatically.