Skip to content

JPEG XL: bump libjxl to 0.11.0 and implement streaming encode

Rasyuqa A H requested to merge rasyuqaa/krita:rasyuqaa/bump-libjxl-0110-streaming-encode into master

This MR proposes a few updates to JPEG XL:

Update libjxl to 0.11.0

This release brings few improvement and bugfixes, mainly in streaming encode, speed regressions, and lossless encoding bugs. Along with new gain map API additions (though we don't use it yet). I also bumped highway to 1.1.0 with it.

Implement streaming encode

Instead of sending the whole raw data to the encoder, streaming encode will send the data per-frame (in case of animation) or per-layer (in case of multi-layered) basis. This will prevent massive lock-up and ease up memory usage when exporting a large animation or multi-layered image. This also gives us the ability to properly show the saving progress and give users ability to abort saving (only on animated and multi-layered case). However, this requires libjxl version at least 0.10.1, since there was a bug with streaming encoding in v0.10.0 that was fixed on v0.10.1: https://github.com/libjxl/libjxl/releases/tag/v0.10.1

Extra notes

  • There was a slight bug when aborting the saving progress midway, sometimes updater() didn't give an interrupted() signal and will continue to encode even though it's already cancelled (through clicking stop button beside the progress bar). Possibly out of scope of this MR though.
  • (nit) With this streaming encode implementation, there's quite a growing number of #ifdef-ing libjxl version number in the code... probably we should consider bumping the version requirements for libjxl as well? (it's currently at v0.7.0)

Test Plan

  • Build jpegxl deps and build Krita
  • Verify JPEG XL export functionality (especially animated and multi-layered) are working as intended

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.
  • Does the patch add a user-visible feature? If yes, is there a documentation MR ready for it at Krita Documentation Repository?

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