Created attachment 167939 [details] PANO images are shown as video clips of 5' duration. When opening a project that had panoramic .jpeg images referenced in the source explorer, they all now appear like a white clip of 5:00 seconds with 2 black stripes on top and bottom. They used to be supported (and seen as images) fine in 23.08 version ; I can't tell when this regression happened. The panoramic images seem to be considered like video clips and under the "properties" panel, the video codec is the MJPEG (which is indeed useless for a picture). I believe either kdenlive or MLT defaults to video clips for some reason, hence the confusion. You can find a screenshot attached to this bug report. SUMMARY STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION
This looks like a packaging issue. Could you try with the AppImage version just to confirm if it works : https://download.kde.org/stable/kdenlive/24.02/linux/kdenlive-24.02.1-x86_64.AppImage.mirrorlist If it works, then you have a packaging problem - probably some missing or not compiled MLT modules. If it also doesn't work with the appimage, please provide a link or attach an image triggering the problem.
Hi Jean-Baptiste, As always, you're pretty much spot on ! It works just fine with the AppImage : I tried it from a WSL2 Ubuntu and with the appropriate dependencies installed panoramic images are displayed and rendered as they should. So I believe you're right with the packaging issue and it might be reported to arch linux maintainers. By the way, I'm sorry for the poor bug report quality, kde bug form is lacking the edition functionality and a misclick leads us to writing half-cooked bugs/comments (...) I'll double-check that on a real Arch box the AppImage is also behaving as it should, and for the sake of it I'll try with a local build of Kdenlive and report back if things are not behaving as expected. Thanks for your time !
Created attachment 168070 [details] Panoramic image (15936x4320px) Attached a repro image. 1. Create a new Kdenlive project 2. Import the picture (drag and drop or "Add clip" button)
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
Thanks for your investigation and feedback! You are correct, this bug is caused by Qt6's new limit on image size. I am working on a fix.
Git commit 36d9d2d76f329185d4daab1f4e7c2e4c6990ddb7 by Jean-Baptiste Mardelle. Committed on 03/04/2024 at 05:08. Pushed by mardelle into branch 'release/24.02'. Increase Qt6 limit for max image size M +6 -0 src/core.cpp https://invent.kde.org/multimedia/kdenlive/-/commit/36d9d2d76f329185d4daab1f4e7c2e4c6990ddb7
Hi Jean-Baptiste, Nice, I tested with the latest revision of master (pulled from GitLab repo) with commit hash 8094aed4d (Merge branch 'release/24.02') and it seems to do the trick, now I can open the very large panoramic images. So, on Arch it works with a local build. Thanks for your time on this one !