[kdenlive] [Bug 484752] [Panoramic Image] regular .jpeg panoramic image is considered as a clip when imported

[Benoît Tarrade]

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.