Support the Quite Okay Image Format

[BlueCyro]

Is your feature request related to a problem? Please describe.

Currently resonite does not support the QOI (Quite Okay Image) format

Describe the solution you'd like

Add support for Resonite to be able to load QOI images without needing to convert them to another supported format.

Describe alternatives you've considered

• Use a different image format; doable but defeats the purpose of storing images as QOI

Additional Context

QOI is a very light and simple image format that rivals the compression ratio of PNG while being 20x-50x faster to encode, and 3x-4x faster to decode.

The implementation details fit on a single page of PDF and should be very easy to integrate.

Requesters

Myself

[Frooxius]

Hmm... I'm not sure about this right now. Adding new supported formats can be a big commitment, because we have to make sure that format is supported long term (unless we transform the data into another format).

For that we need to ensure that the format has good stability and wide-spread support. If it ever drops support and issues start accumulating, supporting it long term could become a significant maintenance burden.

How does this compare to AVIF for example? Why would we use this over that?

Keep in mind that:

• Decode/encode speed doesn't matter super much for most cases, because the raw image formats are usually not directly loaded anyways - the asset variant system generates specialized formats
• Size also doesn't matter super much (other than storage) for the same reason as above

So the main benefits would be long term storage of assets - but this is where the stability of this format becomes a concern. Can we rely on this format being supported and developed long term?

[kitlith]

With regards to stability: The specification has been declared final (https://github.com/phoboslab/qoi/issues/95), and there are only two (noted as purely informational) header fields that can contain currently unspecified values, and no version fields. So, unless the author decides to abuse those fields for other purposes in a version 2, the only thing we're likely to see in the future is a limited amount of colorspace information.

Looking at the wikipedia article (https://en.m.wikipedia.org/wiki/QOI_(image_format)#Software_and_language_support), I would not call it a widely supported format. Granted, wikipedia is probably not the best source to make these judgements.

Given the compressibility of QOI, if you were implementing this it might be worth supporting .qoi.gz/.qoi.bz2/.qoi.br, etc, but you've noted that size doesn't particularly matter anyway.

So far as I can tell, unless an argument is being made to (eventually) use QOI as a format internal to Resonite, to take advantage of it's simplicity for both encoding and decoding (and avoid hopefully avoid stuff like the webp vulnerability because the decoder is so simple), the argument for supporting QOI would be "supporting niche usecases" or "because I like the format and would like to support people who use it". (That doesn't mean that there isn't something else, just that I'm not thinking of it!)

Aside, one place where size might matter is with regards to ResonitePackages (users would likely appreciate keeping them as small as possible).

(Personal Opinion: I think QOI is neat, but I'm unsure of the use for Resonite. It's most interesting when you're using it as the primary image format for a project, which I don't think is going to be the case here.)

(It's also worth noting that for some of these niche usecases there are some subsets of PNG that are of similar speed to encode/decode to qoi: https://github.com/richgel999/fpng, while still being compatible with standard png decoders. This is only useful if you have control over the program generating the image, though.)

[Frooxius]

The specification being marked final doesn't really help with stability here. Given that the format is niche, there might not be enough pressure on it to find vulnerabilities.

Simple specification makes vulnerabilities less likely, but not impossible. And question is - if/when they're found - what will happen? Will they get addressed quickly? Or will it be up to us to try to fix those?

That's one of the benefits of a lot more commonly used formats - there's a lot more eyes on them and a lot more people who will support them long term and keep evolving them.

You mention ResonitePackages, but question is - does QOI really provide best results here, that would outweigh the possible downsides? Even compared to WebP? Or say AVIF? And other modern advanced formats? If the problem we're trying to solve is minimizing the package size, then we need to look at all formats, not just this one and weigh them against each other.