Implement QOI importing. #80768
Implement QOI importing. #80768
Conversation
|
Could you make a proposal to gauge interest on the QOI format? I find it quite interesting myself, but in core? Unsure right now? |
There's already an open proposal: godotengine/godot-proposals#3726 |
|
It is fair if it is not included in the core, but more and more programs are natively supporting it. |
You could use BMP or TGA exporting if speed is a priority. These should be even faster to write than QOI, as they're not compressed. |
|
You are right but in that case why does Godot support more than one image format if every image can be converted into one format? I'm just taking things to the extreme, no hard feelings on the final decision. |
|
Sorry. I'm aware they are alternative suggestions, but both BMP and TGA cannot be compared for how space efficient QOI is. |
|
Binary size of Linux x86_64 release export templates with LTO (stripped): This is a difference of exactly 8192 bytes. It's not huge, but it's not negligible either considering this affects every exported project that uses official export templates. The exact size difference will vary depending on the platform.
QOI isn't very space-efficient compared to PNG or WebP. My point is, you can use BMP/TGA during iteration and convert to lossless WebP (which is more efficient than PNG) once you're done iterating. This way, you'll get very fast save times while iterating and an efficient saved file once you're done. There's unfortunately no image format that can do both good compression or fast saving without having to use another format.1 In my experience, PNG in uncompressed form is still fairly slow to save for some reason. Footnotes
|
|
EDIT: As discussed below, movie maker mode would be a good use case that could justify this feature. |
|
Just to set any misconceptions to rest I use took an image set1 (1.2 GB PNG) and re-encoded it imagemagick2 and here are the results.
QOI is very fast and has very good compression when compared to bmp. Compared to png it falls just a little behind but it has very quick encoding. Script used to encode images ext=$1
mkdir $ext
find "./Art" -type f -name "*.png" -print0 | while read -r -d '' i ; do
mkdir -p "./$ext/${i%/*}"
convert "$i" "./$ext/${i::-4}.$ext"
doneFootnotes
|
Encode times actually look quite competitive compared to BMP (and especially TGA), so it may be worth having this for Movie Maker mode (where saving uncompressed data may be unreasonably large, e.g. for 4K video). The only issue is making sure you have a FFmpeg version that can read QOI files so you can reencode them into a video format (this is the case since FFmpeg 5.1). That said, having support for Movie Maker mode would require implementing QOI encoding, not decoding. This is almost guaranteed to be a better tradeoff than #74324 when you don't need compatibility with software that can't read QOI files. |
| <return type="int" enum="Error" /> | ||
| <param index="0" name="buffer" type="PackedByteArray" /> | ||
| <description> | ||
| Loads an image from the binary contents of a QOI file. |
There was a problem hiding this comment.
| Loads an image from the binary contents of a QOI file. | |
| Loads an image from the binary contents of a [url=https://qoiformat.org/]QOI[/url] file. |
|
I will take a look at implementing QOI encoding if there is interest in it. |
|
May I suggest where QOI encoding could be useful? Whenever an image gets imported into Godot, it gets internally converted into WebP. When an image being imported is above the WebP limit (16383x16383) the importer converts it to PNG instead. QOI claims to have a higher dimension limit when compared to PNG (although I doubt anyone would use an image that large). Maybe QOI could be an alternative to that? |
Godot doesn't support images larger than 32768×32768, and desktop GPUs rarely support images larger than 16384×16384 (no mobile GPUs do). Displaying a single 16384×16384 image without VRAM compression also requires a lot of video memory 🙂 |
Both in the website and the repository clearly state that QOI is under the MIT license. CC0 is only for the logo. Unless... Is this based on the format specification instead of the reference implementation? If so, then there's no problem (that's how public-domain single-file libraries like stb_image and minimp3 are made). |
|
You are correct. I did not read the license correctly. I am not a lawyer. I am just a programmer for fun. |
@Calinou Either way, apologies for poking the dead thread, but thought it was worth mentioning |
I'd like to point problem I see with JPEG XL: the less complex the image is (like a pixel art) compression tends to become less effective, sometimes losing even to PNG. Take the following image from Kenney for example:
Since we're talking about fast saving, I should mention you can always use lowest effort, which kinda results in a lower size when compared to QOI (I haven't tested encoding time though). |
I gave this a shot and the results look very promising. A 6x speedup. Uses a bit more storage space, but that doesn't really matter if you goal is to just feed it into ffmpeg anyway. |
|
That looks very promising. |
|
I let the editor convert Godot Lumberyard Bistro from 4.0 -> 4.3 and added a camera. i9-12900K, 3070Ti, 128GB ram. This is using the reference encoder. Ill try that scene. |
|
Similar results on @Calinou 's movie test scene |
|
I pushed a draft of QOI Movie Maker support to #91263 if you want to try for yourself. |
I added support for the QOI format of images. More information can be found at https://qoiformat.org/.
Only importing was implemented not exporting of QOI images.
There are two checks for if the image is formatted correctly.
Should there be any other checks before decoding the image?
QOI is an opensource image format under the CC0 License.