option for a chunk based api

[ratchetfreak]

Currently the encode and decode functions take in the whole buffer of data and will allocate the target buffer for you.

This isn't great when you want to decode straight into for example a mapped GPU buffer when loading textures or when malloc access is limited or when you can't read the whole file (in some esoteric memory constrained situation).

Instead a chunked api like zlib would be nicer:

The decode and encode functions then take in the state of the decoder and a pointer to the pointers to input and output buffers

struct qoi_state{
    void* input;
    size_t input_remaining;
    void* output;
    size_t output_remaining;

   qoi_coder_state state; //(by value because the state needed is fairly small: 66 pixels (the hash table, previous and partial current), a run count and how much of the header has been parsed/emitted)

}

After each call the user code must then update the buffer pointers if either input_remaining or output_remaining are 0, or finalize the stream.

on top of the chunked function the existing functions can be built quite easily.

[HookedBehemoth]

Hi, I'm also interested in such a chunked API. I hacked one together just now to use it in a heavily memory constrained environment - a background process on the Nintendo Switch.

[shraiwi]

I wrote a streaming QOI decoder that takes data in on a byte-by-byte basis. Hopefully it fits your needs :)