Skip to content

JPEG-XL: fix unittest and bump libjxl to 0.8.2 for security patches

Rasyuqa A H requested to merge rasyuqaa/krita:rasyuqaa/jpegxl-fix-unittest-and-improve-lossy-f32 into master

Got another couple fixes for JPEG-XL unittest and overall usability/stability:

  • Fix Layered CMYK unit test file. Resaved the result file using current master fixed it. I got a finding though, on TestUtil::comparePaintDevicesClever it seems to always set the origin of HLineIterator to (x=0 y=0), not to the exactBounds origin. I'm not sure why my old result .kra file have a different extent on master while they both have the same exactBounds, but this might be noteworthy to check?
  • Fix another variable typo on export options, now the responsive / Progressive setting on advanced tab is loaded properly.
  • Took another workaround for buggy lossy F32 (see: https://github.com/libjxl/libjxl/issues/2064 ), it wasn't caused by the modular mode, but the progressive option that didn't work well with extra (alpha) channels on F32. Disabled that so lossy F32 didn't have a bloated file size. And while I'm also at it, I also remapped the quality to totally match libjxl cjxl and possibly other apps as well (eg. Darktable, for the one I tried). On before, I hardcoded it to cap the distance at 0.5, now with cjxl's formula it went down to 0.1, which means better higher end fidelity (for quality >90). This will also prevent (possible) confusion where our lossy export quality setting yields a different (worse) result than the reference cjxl at quality >90...
  • Bump libjxl to 0.8.2 for security patches, should be a painless update while improving stability (see: https://github.com/libjxl/libjxl/releases/tag/v0.8.2 ).

Test Plan

  • Build Krita
  • Check JXL unit test is working properly
  • Try export some F32 images to lossy and verify that it isn't bloated anymore

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