https://bugs.kde.org/show_bug.cgi?id=484752
--- Comment #4 from Benoît Tarrade <benoittarr...@hotmail.fr> --- Hi again, very interesting : I bubbled up the issue to Arch's kdenlive package maintainer, and he managed to pinpoint the issue coming from Gwenview. Here is the link to the bug I raised on Gitlab : https://gitlab.archlinux.org/archlinux/packaging/packages/kdenlive/-/issues/4 which I duplicated from this one. Quoting Antonio Rojas : > This is just an instance of https://bugs.kde.org/show_bug.cgi?id=482195 And if you look at the ticket, I can see the same logs : ``` :::::::::::::::::::::: /////////// creatclipsfromlist QList(QUrl("file:///<my file path>.jpg")) true "2" /////////// createClipFromFile "/<my file path>.jpg" "2" === GOT DROPPED MIME: "image/jpeg" /////////// final xml "<producer in=\"0\" length=\"125\" type=\"5\">\n <property name=\"resource\">/<my file path>.jpg</property>\n</producer>\n" ============STARTING LOAD TASK FOR: 4 = "/<my file path>.jpg" ::::::::::::::::::: qt.gui.imageio: QImageIOHandler: Rejecting image as it exceeds the current allocation limit of 256 megabytes <--------------------------------------------- Here is the interesting part which is common to Gwenview's bug ! qt.gui.imageio: QImageIOHandler: Rejecting image as it exceeds the current allocation limit of 256 megabytes ################### ProjectClip::setproducer ################# ################### ClipController::updateProducer ################### ClipController::addmasterproducer FOR: "4" ========== READY FOR TASK DISCARD ON: 4 // WARNING EMPTY CLIP HASH: ======= SETTING AUDIO DATA IN MONITOR EMPTY!!! === GOT THUMB FOR: -1 x -1 MUTEX LOCK!!!!!!!!!!!! setmodel MUTEX UNLOCK!!!!!!!!!!!! setmodel MUTEX LOCK!!!!!!!!!!!! loadEffects COUNT: 0 ACTION: "&My Custom job" = "custom;" :::: COMPARING ACTIONTYPE: "" = ClipType::Video ACTION: "&Découpage automatique des scènes..." = "scenesplit;v" :::: COMPARING ACTIONTYPE: "v" = ClipType::Video ACTION: "&Stabiliser" = "stabilize;v" :::: COMPARING ACTIONTYPE: "v" = ClipType::Video ACTION: "Dupliquer &la vidéo avec une modification de vitesse" = "timewarp;av" :::: COMPARING ACTIONTYPE: "av" = ClipType::Video ACTION: "&Configurer les tâches de vidéos..." = "" :::: COMPARING ACTIONTYPE: "" = ClipType::Video ========== READY FOR TASK DISCARD ON: 4 ============STARTING LOAD TASK FOR: 4 = "qimage:/<my file path>.jpg" ::::::::::::::::::: ################### ProjectClip::setproducer ################# ################### ClipController::updateProducer // replace finished: "4" : qimage:/<my file path>.jpg ========== READY FOR TASK DISCARD ON: 4 // WARNING EMPTY CLIP HASH: === GOT THUMB FOR: -1 x -1 ======= ``` And I've tried again on a real Arch linux system, and this time the *AppImage version behaved exactly as the one packaged with pacman !* I had exactly the same logs as well ! I've added a fake picture so that you can try for yourself. So far it seems related to Qt6 and default QImageIOHandler behavior where buffered image (uncompressed raw pixels) exceeds 256MBytes of RAM. I believe that's the case we are hitting with such big images. This is documented here on Qt6 documentation : https://doc.qt.io/qt-6/qimageiohandler.html#allocateImage -- You are receiving this mail because: You are watching all bug changes.