Expand description
Encoding and decoding for various image file formats.
Supported formats
| Format | Decoding | Encoding |
|---|---|---|
| PNG | All supported color types | Same as decoding |
| JPEG | Baseline and progressive | Baseline JPEG |
| GIF | Yes | Yes |
| BMP | Yes | RGB8, RGBA8, Gray8, GrayA8 |
| ICO | Yes | Yes |
| TIFF | Baseline(no fax support) + LZW + PackBits | RGB8, RGBA8, Gray8 |
| WebP | Lossy(Luma channel only) | No |
| AVIF | Only 8-bit | Lossy |
| PNM | PBM, PGM, PPM, standard PAM | Yes |
| DDS | DXT1, DXT3, DXT5 | No |
| TGA | Yes | RGB8, RGBA8, BGR8, BGRA8, Gray8, GrayA8 |
| farbfeld | Yes | Yes |
A note on format specific features
One of the main goals of image is stability, in runtime but also for programmers. This
ensures that performance as well as safety fixes reach a majority of its user base with little
effort. Re-exporting all details of its dependencies would run counter to this goal as it
linked all major version bumps between them and image. As such, we are wary of exposing too
many details, or configuration options, that are not shared between different image formats.
Nevertheless, the advantage of precise control is hard to ignore. We will thus consider wrappers, not direct re-exports, in either of the following cases:
- A standard specifies that configuration x is required for decoders/encoders and there exists an essentially canonical way to control it.
- At least two different implementations agree on some (sub-)set of features in practice.
- A technical argument including measurements of the performance, space benefits, or otherwise objectively quantified benefits can be made, and the added interface is unlikely to require breaking changes.
Features that fulfill two or more criteria are preferred.
Re-exports of dependencies that reach version 1 will be discussed when it happens.