Formats to keep/remove for 1.0

[fintelia]

Another topic we should discuss ahead of 1.0 is what formats we want to include. Now that there's image-extras and decoding hooks, we can remove formats from this main crate without totally removing support if a small number of people are still relying on them.

We also have the option of making some formats behind a feature flag but not part of the default feature set.¹

---

Looking at individual formats...

• dds: Already moved to image-extras.

• farbfeld: Another we should probably move to image-extras. I haven't come across anyone using this format who didn't add it because we did.

• exr: This format is implemented via an external crate and has a relatively heavy dependency tree. We've gotten very little in the way of complaints / issues about this one, so I'm not sure how much it gets used? Another candidate to remove.

• pnm: Not sure about this one. There's definitely a lot of references to PNM in older software. But I don't have a good sense of usage. And Split PNM ImageFormat into subformats for PBM, PGM, etc. #2841 raised the question of how to properly handle subformats which doesn't seem like it has a good option besides treating them as five different formats.

• qoi: I'd somewhat lean towards keeping this one simply because it isn't too complex and I like the format. But maybe doesn't need to be enabled by default.

• avif: Our current codecs have a pretty heavy dependency tree, and the decoder isn't enabled by default yet (since we're still waiting to switch to a Rust implementation). I think this could make sense behind a feature flag.

• tiff: I think we'll want to keep support. Though as we add more functionality upstream like ZStandard compression and such, we might want to consider a feature flag?

• bmp / gif / hdr / ico / jpeg / png / tga / webp: I think we want to keep all these.

Footnotes

1. I've been reluctant to allow disabled-by-defaults formats in the past because I feared it would lead to pressure to add tons of obscure/rarely used formats. But I think that's less likely now that there's other avenues for them. ↩

[mstoeckl]

While decoding hooks are supported, encoding hooks are not, so moving any format to image-extras would affect the behavior of image::save_buffer or DynamicImage::write_to, which could be given arbitrary user-supplied paths. I would recommend caution in removing any of the current format set. Except maybe Farbfeld.

pnm. [...] But I don't have a good sense of usage. [...]

I sometimes use PPM as an uncompressed output format (to dump image data to a tmpfs or pipe before running some other program on it); a number of other programs (imagemagick, cjpeg, cwebp, cjxl) accept it as an input. It isn't a particularly good format for this purpose due to lack of alpha (and other issues), but no other alternative has become as established, and it isn't always easy to request uncompressed PNG.

I'm not sure to what extent people actually use it, but the Linux screenshot tool wayshot uses image to write to ppm and qoi formats, among others.

[197g]

how to properly handle subformats which doesn't seem like it has a good option besides treating them as five different formats.

I want to remark that this is caused by the way our ImageEncoder trait is shaped. It's not very different from other configuration options that may not be baseline in other decoders e.g. jpeg loss-ratio vs. lossless jpeg; or lots of equivalents in tiff. Indeed, PNM permits multiple images in a single file by just appending additional headers and there is no reason to suppose that those are all the same. Convention is to use the specific file endings only if that is the case though. Here we have a configuration option implied by a file ending, nothing more imo.

[okaneco]

I agree with the core listed in the last bullet point.

If the maintenance burden is not too much, I would also agree with PNM remaining even though I don't use it much.

1. It's useful for reasons mentioned above, and also as a human readable-writable-editable image format.
2. It's common to use in C/C++ tutorials as an output format instead of adding a dependency: Raytracing in One Weekend is one place I remember using it (which is also a popular beginner Rust project to implement).

[RunDevelopment]

Regarding the formats, I mostly agree, just a few notes:

• EXR is used heavily in the VFX field, and they typically compress their files with DWAA or DWAB, AFAIK. (Regrettably) neither of these compression methods are supported by the exr crate. The fact that no issue about this has been raised here is a strong indication to me that not a lot of people are using image's EXR support.
• QOI is a format I've never seen in the wild. I was looking for test images once and was hard-pressed to find any online. Then there's also the fact that the qoi crate seems to be currently unmaintained (New Release? aldanor/qoi-rust#14), which causes issues. I would favor moving this format to image-extras.
• AVIF is such a good format, and the fact that we can't enable decoding support by default for it right now is a shame. If it can't be enabled by default, I think a feature flag makes sense.

While decoding hooks are supported, encoding hooks are not, [...]

I think the obvious (but not easy) fix for that is to add support for encoding hooks. This would be a useful feature even outside this context.

[tristanphease]

Do we have any metrics for usage of the various image formats; either via this crate or more generally?
I assume all formats supported on the web would be widely used since that's one of the most common method of distributing/viewing images but the other ones are fairly obscure/niche.