Shotcut 22.10.25 on UBUNTU 22.04 is not exporting JPG images from the timeline.
What build or package are you using? Are you using the Export panel or File > Export > Frame?
I just tested both kinds of export on the Flatpak and portable on the Ubuntu-based Pop!_OS 22.04, and it works fine.
I am using ver. 22.10.25 on UBUNTU 22.04 installed as standard latest stable snap from UBUNTU Snap Store. When converting (in external program) JPG files to PNG, everything is OK, but the sama fiele in JPG is exported as blank white frame.
You are talking about putting a JPEG in the project. I thought you were talking about export AS JPEG. Basically, this is a duplicate issue on Linux that no developer has reproduced. You can search for the duplicate and try to figure it out and share the solution please.
Putting JPEG into a project is OK. After finishing the project, trying to export the project as MPEG4 the used JPEG images are exported as white blank. Other tracks are OK. After using PNG files to put in to project, export as MPEG4 is OK. I am using LINUX UBUNTU 22.04. the Shotcut is installed from the official UBUNTU Snap Store.
Ubuntu 22.04 - Shotcut 22.11.25 -. Qt lib 5.15.3
Seems that SOME jpg fails to be exported in video, not every jpg files…
See attached jpgs…
The first image (white egg) gets a blank white result, the second (green egg) gets mastered correctly in he video.
Is it a known bug ? Maybe due to the qt libraries ?
Tried with many formats, with hw and without hw encoding… same result…
Attach the two jpg, the mlt and the mp4 files…
GL
testinfo.zip (236.2 KB)
FOUND !!
ROOT of the problem
The problem arise ONLY when the jpg file does incorporate an icc profile, typically an Adobe icc profile.
When converting to png the icc profile gets removed and so the problem stops
TEMPORARY SOLUTION
Using Gimp,
-from Image->color management disable the color managment,
- MORE important when exporting to jpg again , UNCHECK the incorporate the icc profile
LONG TERM SOLUTION
Next version should use the QT libraries to strip out the icc profile…
The interesting part is that the preview in the editor is performed correctrly… BUT when exporting to mp4 the problem of the icc profile arise…
WHERE we can inform about the bug ?
GL
I have no idea what that means. We already use Qt to open the image. How can you use Qt to ignore or discard the ICC profile when the image fails to load using Qt?
I reproduced it from the JPEG with ICC profile provided. The export log shows
[mlt_producer 0x55673a3b34f0] /home/ddennedy/Downloads/testinfo/ 1885 The Hen Egg5.jpg
QImage retry: 1 - File not found
[mlt_producer 0x55673a3b34f0] /home/ddennedy/Downloads/testinfo/ 1885 The Hen Egg5.jpg
QImage fail: 1 - File not found
In any case, it is not because there is an ICC profile, it is because the file name 1885 The Hen Egg5.jpg starts with a non-breaking space!
Renaming it to restore a space does not reproduce the problem. I had to use ls | hexdump -C to see the weird characters! It is c2 a0, which is a UTF-8 unicode non-breaking space also known as in HTML. This is not passing properly through the export MLT XML conversion where it is converted into a regular space (hex 20).
Update: this only happens on Linux, not on Windows or macOS - even with same Qt version. I used a debugger to verify that actually, the non-breaking space passes all of the way into the QImageReader class without losing the c2 a0. So, it is something weird maybe with the way the Qt operates under melt when running the export since it is not a problem within Shotcut interactively.
I tried to follow your instruction, and it works even with icc profile.
First of all, my consideration are only toward and improvement of a program that I found wonderful.
Linux use a utf8 filesystem, so the filename (got from a webpage, so with a nb space) is a completely valid filename.
For what I can see, even under Windows 10 build 17134, the filesystem use UF8, so the filename is valid.
Seems a filename filter should be used in creating the output stream, to validate the filename against UTF8 and eventually create a alert dialog.
The exporting job runs and terminates without error in the UI, reporting no kind of error.
Consider that the editor windows does perfectly read the file, so it is getting the correct handle to the file even with UTF8 …
the problem that arise during export shows an inconsistency between the two subcomponents of shotcut…
maybe the files are “reopened” during exporting of the video ?
If it is the same process or a subprocess, it should get the same working file handles of the editor…
ext2/3/4 stores filenames as a sequence of bytes. No encoding is implied or required or interpreted. This is why Python users beat their heads against the wall whenever a filename doesn’t follow proper Unicode code points, because strings and pathlib objects in Python do adhere to Unicode, and can’t pass non-conforming byte sequences directly.
An example showing international angst:
Invalid Unicode path encountered · Issue #221 · GoogleCloudPlatform/gsutil · GitHub
However, to your point, Qt as a convention will encode as the user’s locale, which is generally Unicode compliant. But not always.
The filenames given so far don’t appear to present a problem. I’m just offering a heads-up in case a different filename appears that isn’t Unicode compliant.
I use (not so often …) utf8 chars in filename.
And it is supposed to work correctly; eg:
giuliano@Astra2A:~$ touch ΧειμεÏινÏ.pdf
giuliano@Astra2A:~$ ls
Documenti Immagini post_install_3.sh snap
eclipse Modelli Pubblici uvcerror.txt
eclipse-workspace Musica Scaricati Video
ΧειμεÏινÏ.pdf opt Scrivania
Right, but that is UI interpretation based on locale, which is totally separate from how the filename is actually stored in the ext2/3/4 file system. Somebody using a different locale will not necessarily see the same results you do. Hence, there is a layer of separation where problems can potentially creep in.
This topic was automatically closed after 90 days. New replies are no longer allowed.