QOI replacing PNG for OpenRaster

[incoheart]

I am wondering if QOI can be feasibly substituted into PNG for project files. QOI is an image format that encodes 20 times as fast as PNG and decodes 4 times as fast as PNG at a similar compression ratio, therefore being easy on the CPU. It can be compressed further with bzip2, generally faster and occasionally smaller than PNG is written and/or optimized. This means that an OpenRaster in Drawpile could be saved without compression with only QOI layers and a filesize larger than a normal OpenRaster, which is a fair tradeoff during workflows. Conversely, if compression is chosen to be enabled, the user has to wait a few seconds to twenty seconds for really big drawings, but with better compression ratio. Yes, a better compression than OpenRaster which is already better than PSD. My mind is blown right now. I'm sorry if I am wrong about this and getting ahead of myself. GIMP can do a very similar compression ratio with xcf.xz, but I think what I am proposing is faster and more open. And, so far it is saving a lot more space for large, involved project files than xcf.xz but I'm still testing.

The two features I am asking to be in Drawpile is:

1. Have Drawpile read and write project files that are QOI for layers, thumbnail, and merged image while defaulting to bzip2 compression for the archive
2. Have Drawpile have a setting to disable the compression

Even though the OpenRaster shouldn't change as a format for accessibility, I think Drawpile could be the first to implement QOI for workflow and maybe improve OpenRaster for the future. I'd at least like to have a tip on how to implement it for myself. As someone trying to keep as many sketches in the same file, the saved time spent waiting and the saved hard disk space would be really nice. I find that Drawpile is capable of opening an OpenRaster that was re-zipped with bzip2 compression. So it's just the QOI support that isn't there, and should be easy to add, as what I've read is that QOI is very very simple. Code to have Drawpile simply export to QOI would be great, since compressing itself can be done separately.

Here are the commands I do to make an OpenRaster with this compression method, so you can see how fast it is with how good of a compression ratio. Try it on your own drawing, called project_file.ora in the example, and see how much space you can save. I use zip, magick, and bzip2 (which needs to be installed in order to be used by zip).

mkdir project_file
unzip project_file.ora -d project_file
cd project_file
find ./ -name '*.png' -exec sh -c 'magick "$0" "${0%.png}.qoi" && rm "$0"' {} \;
zip ../project_file_qoi_bz2.ora -r -Z bzip2 ./

[askmeaboutlo0m]

Yes, these would be possible. QOI more so than bzip2, since the latter isn't supported by most installations of Drawpile, it would require building KArchive with that compression enabled and somehow finding a solution for Qt6, since we use libzip instead there. Although that's mostly because KArchive didn't work with it at the time, meanwhile it should be available.

Integrating QOI does look pretty simple, it's a single file to copy into the source tree and then wire it up by creating an accompanying .c file that defines QOI_IMPLEMENTATION. You can't use it to write QOI files on Android because it only supports stdio and that doesn't work there, but for ORA files you would write the data to memory anyway, so it's no matter in that regard. Otherwise, it's mostly a matter of upgrading ORA stuff in save.c and load.c to deal with the different image format.

Although I'm not too sure if this stuff should go into ORA files. Drawpile has historically used them to save its stuff and they're good for interchange with other programs, but they're not really ideal as a project file format, since they can only be written in one big chunk. We could do much better than that with a bespoke format that automatically records everything you do and you can recover from it or travel back in time, cf. #1065. It would also mix better with Android and the browser, where you don't really have file access in the classic sense and a format that just runs along in the background works much better for those environments. QOI and bzip2 compressions would definitely be contenders to use for that kind of format though, if they're sufficiently small and fast. Lossless WEBP would be another one, which Drawpile already supports and may be something you can try as well.

That doesn't need to stop you from exploring that avenue though, it seems like it could still be useful to have a faster archive format of that sort. I know people have asked for other image formats to be used in ORA before, so having an implementation that does it may end up making it into the standard.