Skip to content

Grum999/qoi file format

Grum 999 requested to merge grum/krita:grum999/qoi_file_format into master

Implement import/export support for QOI (Quite OK Image) file format.

Specifications, explanations, source code for file format can be found on official QOI site.
Also on the github repository, it start to get a long list of tools & software able to manage this file format.

What is interesting with this file format, for similar compression ratio to PNG, it's how fast are encode and decode process (20x-50x faster encoding and 3x-4x faster decoding according to the official site). \

Also, the QOI file format has been implemented into KDE's KImageFormats.
Implementation made here is ~90% copied from KDE's implementation and follow the same license (LGPL-2.0-or-later for QOI converter source code, GPL-2.0 for all other source code like it is for other import/export).
May be need to review this?
Original QOI source code is under MIT license.

Also what I'm not sure about is if we have to manage "3rd party" library or not (here it's a full implementation of import/export instead of trying to load 3rd party dependency, build a library, ...).

Implementation in Krita also takes care about:

  • The file dialog & welcome page to manage QOI thumbnails
  • Properly add the mime type (image/qoi)

Tests unit have been implemented (I think I just copied the one for TGA, replacing TGA by QOI).
They build and run without error, but I'm not sure what they exactly does.

Update of Krita's documentation for file formats will be made after MR is validated.

Test Plan

  • Open all "official QOI tests files"
  • Save Krita document, using options (alpha, transparent color)
  • Open files saved from Krita

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list, kimageshop@kde.org.

Merge request reports