Bug 420675 - SVG in video with semi-transparent areas is rendered without them
Summary: SVG in video with semi-transparent areas is rendered without them
Status: CONFIRMED
Alias: None
Product: kdenlive
Classification: Applications
Component: Video Display & Export (show other bugs)
Version: 20.04.0
Platform: Mint (Ubuntu based) Linux
: NOR normal
Target Milestone: ---
Assignee: Jean-Baptiste Mardelle
URL:
Keywords:
: 405249 415440 421168 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-04-27 18:11 UTC by csavas.g95
Modified: 2021-03-16 13:01 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:
fritzibaby: Brainstorm+

Attachments
SVG image with shadow (4.61 KB, image/svg+xml)
2020-04-27 18:11 UTC, csavas.g95 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description csavas.g95 2020-04-27 18:11:34 UTC 
Created attachment 127931 [details]
SVG image with shadow

SUMMARY

I have a project created in 20.04.0 version, with the attached SVG image. It has a shadow layer, with semi-transparent gray color. I've used it in another project made with 19.12.3 some days before the fresh project. I also rendered this older project with 19.12.3, and in it the shadow-part of my image is visible. But rendering my new project with 20.04.0 only renders the red shape itself, without the semi-transparent shadow part. Interestingly, after I load the new project into the old version, and do the rendering, the shadow is visible again.

STEPS TO REPRODUCE
1. Insert some background in a new project on V1 track, for example white color.
2. Place the attached image above it, on V2 track (default 5 seconds duration is enough)
3. Render the video and check it

OBSERVED RESULT
My video shows the red shape, but not the shadows.

EXPECTED RESULT
My video should show every part of my image, the shape and also the shadow.

SOFTWARE/OS VERSIONS
Linux: Linux Mint 19.3 x64
KDE Frameworks Version: 4:4.14.38-0ubuntu3.1
Qt Version: 5.9.5
Comment 1 emohr 2020-04-28 19:12:26 UTC 
Thank you for reporting. Confirmed as you descript.
Comment 2 Jean-Baptiste Mardelle 2020-04-28 19:55:25 UTC 
Thanks for your report. In fact this regression was caused by a change in MLT, our video backend. Svg can be handled by 2 different plugins:

-qimage using Qt's svg rendering
-pixbuf using GTK's rendering.

While Qt's support for image formats generally seems better, SVG support is still very limited.

This commit in MLT switched from pixbuf to qimage by default causing the regression:
https://github.com/mltframework/mlt/commit/7bf5da86d4f2f8f83f45b9809fb061cbfdd97906#diff-3618679c822f96781a092c5f0114ccfc

I will try to ask if there was a reason for this switch for SVG or if it can be reverted...
Comment 3 Vincent PINON 2020-04-28 19:56:41 UTC 
Hello,
Very recently MLT switched the default module used for image rendering (from FFmpeg to Qt I believe). This is probably the problem.
The change is in loader.dict text file, that can be copied from one install to the other to check?
Comment 4 csavas.g95 2020-04-28 20:45:50 UTC 
Thank you for the information.

I am using AppImage executables, one for each version, so I can't change my installation files. I can read them, though... As you pointed out, I also have qimage set to default over pixbuf:

*.svg=qimage,pixbuf
Comment 5 Vincent PINON 2021-03-16 13:00:22 UTC 
*** Bug 415440 has been marked as a duplicate of this bug. ***
Comment 6 Vincent PINON 2021-03-16 13:00:39 UTC 
*** Bug 421168 has been marked as a duplicate of this bug. ***
Comment 7 Vincent PINON 2021-03-16 13:01:04 UTC 
*** Bug 405249 has been marked as a duplicate of this bug. ***