Bug 501561

Summary: Even a small animated JXL causes krita to take up dozens of GB, leading to OOM
Product: [Applications] krita Reporter: schreibemirhalt
Component: Resource ManagementAssignee: Krita Bugs <krita-bugs-null>
Status: REPORTED ---    
Severity: normal CC: halla
Priority: NOR    
Version First Reported In: 5.2.9   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Xfce4 taskmanager showing a few processes like krita and gimp memory usage
The mkv that got converted to the jxl that leads to the OOM
Part 1/3 of the jxl.
Part 2/3 of the jxl.
Part 3/3 of the jxl.

Description schreibemirhalt 2025-03-16 07:24:32 UTC
Created attachment 179444 [details]
Xfce4 taskmanager showing a few processes like krita and gimp memory usage

SUMMARY
When I open a animated JXL in krita via the terminal then my systems will run out of memory.
Not happening with single-frame JXL files.
In the terminal output I see:
Invalid profile :  "/usr/share/color/icc/colord/Crayons.icc"
Invalid profile :  "/usr/share/color/icc/colord/x11-colors.icc"
Loading plugin "/usr/lib/kritaplugins/kritaseexprgenerator.so" failed,  "Die Bibliothek /usr/lib/kritaplugins/kritaseexprgenerator.so kann nicht geladen werden: (libKSeExprUI.so.4: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden)"
krita.general: ERROR: no sample brush found in  "/home/duda/.local/share/krita/smudge_blur_mignon.abr"
QObject::startTimer: Timers cannot have negative intervals
dlopen: /usr/lib/libheif/libheif-svtenc.so: undefined symbol: _Z21get_subsampled_size_vj12heif_channel11heif_chroma12scaling_mode
JXL file was marked as animation but it has only one frame.

STEPS TO REPRODUCE
0. Open something that shows RAM usage
1. In terminal: krita animation.jxl
2. Wait a few seconds

OBSERVED RESULT
RAM usage spike of several dozend GB until I run OOM within a few seconds, leading to a system freeze.

EXPECTED RESULT
krita opened with the JXL and only a few hundred mega of memory usage

SOFTWARE/OS VERSIONS
Qt Version: 5.15.16 & 6.8.2

ADDITIONAL INFORMATION
The animated.jxl got created by ffmpeg -i test.mkv -c libjxl_anim -f image2pipe -effort 5 -distance 0.5 animated.jxl (latest ffmpeg static from master; md5sum of archive: 812a4c55be70f1948ebfdcdee71397a9)
The input file itself is below 1M big. animated.jxl is 11M big and has 49 frames.
gimp manages to keep its RAM usage under 1 GiB with the file open; krita just continues to grow.
(Stopped the process before taking the attached screenshot that's why the CPU usage is 0 %)
Comment 1 schreibemirhalt 2025-03-18 04:07:03 UTC
Created attachment 179526 [details]
The mkv that got converted to the jxl that leads to the OOM
Comment 2 Halla Rempt 2025-03-28 09:24:49 UTC
Please attach the actual jxl file; If I convert the mkv file to jxl with imagemagick's convert tool, the resulting file cannot be opened.
Comment 3 schreibemirhalt 2025-03-28 11:41:19 UTC
Created attachment 179814 [details]
Part 1/3 of the jxl.

You should be able to merge via: cat animated_jxl_a* > animated.jxl.
I used: split -n 3 animated.jxl animated_jxl_
Comment 4 schreibemirhalt 2025-03-28 11:41:38 UTC
Created attachment 179815 [details]
Part 2/3 of the jxl.
Comment 5 schreibemirhalt 2025-03-28 11:41:57 UTC
Created attachment 179816 [details]
Part 3/3 of the jxl.
Comment 6 Halla Rempt 2025-03-28 11:52:04 UTC
Thanks, I managed to reconstruct the file, but it seems to load fine for me. No messages on the terminal, no excessive memory usage. Could it be an issue with the version of the jpeg-xl library that Arch provides? Could you also check with the 5.2.9 appimage?
Comment 7 schreibemirhalt 2025-03-28 12:23:44 UTC
(In reply to Halla Rempt from comment #6)
> Thanks, I managed to reconstruct the file, but it seems to load fine for me.
> No messages on the terminal, no excessive memory usage. Could it be an issue
> with the version of the jpeg-xl library that Arch provides? Could you also
> check with the 5.2.9 appimage?

You are faster than me replying, heh. Anyways, I will quickly attach what I have written in the meantime and then reboot and try fresh on standard Arch kernel with krita and krita appimage. Regarding libjxl: maybe, I don't use the git version of it but the one in standard Arch repos. Noting that, looks like I'm on 0.11.1-1 there while there is actually a 0.11.1-3 since March the 19th...

Just 1:1 the response I typed without anything added afterwards:
(In reply to Halla Rempt from comment #2)
> Please attach the actual jxl file; If I convert the mkv file to jxl with
> imagemagick's convert tool, the resulting file cannot be opened.

Thanks for the reply. I just woke up my system from suspend and tried to open again. This time it worked without OOM; it grows for a bit and stops right below "tiny" 8 GiB. It really is tiny RAM usage compared to some JXL's with 8k canvas size and 200+ layers that only contain screenshots of all open windows I have but then take 65 GiB of RAM in krita... but with those I did not get any OOM, let alone within seconds! Even tried on the same day as with this file when I had the issue. Back then I tried it more than three time and had the issue every single time, after reboot and with standard Arch kernel even.
This file here only shows one layer in krita but it looks like that this is to be expected since the image has frames with duration (can be checked by jxlinfo).

Well, I did install a few new packages in the meantime and filtering out those standalone programs I think those might be some that might be worth to note. Well, libx11 is at least a dependency of krita and there appears to be some way to script with python in krita:
libx11 1.8.11-1 to 1.8.12-1
mesa 1:24.3.4-1 to 1:25.0.2-2
python-numpy 2.2.3-1 to 2.2.4-1
python-parse 1.20.2-2 (new) 
python-partse-type 0.6.2-5 (new)

I can give the full list of (updated) packages — I keep track of them on a private repo or can try out more if wanted. Was actually on my way to leave my place for a bit but then saw the reply.
Comment 8 Halla Rempt 2025-03-28 14:07:03 UTC
I can't do much with the packages arch provides -- for our own builds, we maintain our own deps, that are often patched to work around issue: https://invent.kde.org/packaging/krita-deps-management
Comment 9 schreibemirhalt 2025-03-28 22:03:23 UTC
First of all: sorry that it took me until evening even tho I wrote "quickly". Personal... and then I tried it with downgraded Arch packages and then also tried with a complete update. Doesn't look like I'm able to get it to OOM my system anymore. Maybe there is some other factor that might show again in the future... Maybe something can be optimized regarding the JXL handling anyways since GIMP takes about 1/10th of RAM for this image (but could also be the case that they ignore some more stuff?) but that's outside the scope of what has been the issue here.
Feel free to close the issue; I will either comment and ask for re-open or will create a new one and reference this one if I experience a OOM situation regarding such a JXL file again.

(In reply to Halla Rempt from comment #8)
> I can't do much with the packages arch provides -- for our own builds, we
> maintain our own deps, that are often patched to work around issue:
> https://invent.kde.org/packaging/krita-deps-management

Okay, I do understand that. If you want me to try with your deps (and maybe then also krita from source) then I will attempt doing so. It just looks like a bit too much for me currently (and I might not attempt for weeks or months)...
Thanks for taking the time to not only read my bug report but also for your answers.
Greetings to the Netherlands from Germany and good night.
Comment 10 schreibemirhalt 2025-03-28 22:04:58 UTC
Oh, also: No problems with the appimage either.
Comment 11 Bug Janitor Service 2025-03-29 03:47:09 UTC
🐛🧹 Thanks for your comment!

Automatically switching the status to REPORTED so the team can perform further triage.

In the future you may also do this yourself when providing needed information.