[kdenlive] [Bug 423658] New: Change of color when adding a fully transparent PNG over a color clip
https://bugs.kde.org/show_bug.cgi?id=423658 Bug ID: 423658 Summary: Change of color when adding a fully transparent PNG over a color clip Product: kdenlive Version: 20.04.1 Platform: Appimage OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: Effects & Transitions Assignee: vpi...@kde.org Reporter: dalbo...@gmail.com Target Milestone: --- Created attachment 129764 --> https://bugs.kde.org/attachment.cgi?id=129764=edit Description of the bug: incorrect colors when layering color clips with transparent PNGs STEPS TO REPRODUCE 1. Create a Kdenlive project with two video tracks 2. Bottom track: a full red #ff "color clip" 3. Top track: a fully transparent PNG (e.g., created in Gimp). Note: in the attached series of screenshots, "circle.png" is fully transparent, except for the opaque white circle in the middle. OBSERVED RESULT The output color (as seen in the project monitor or the rendered H264 video) is not the same, depending on whether there's the transparent PNG on top. More precisely, the output color is #ff18000 without the transparent PNG, and #ff0001 with the transparent PNG. See attached image, the problem should be pretty clear. EXPECTED RESULT The color should not change (to avoid visible flicker) when adding a fully transparent PNG on top. Also, the color should be exactly #ff, which it never is with or without the transparent PNG. Adding the transparent PNG makes it in fact "more correct", but still not perfectly correct. DETAILS AND DISCUSSION The project has the following video settings: Video Settings Frame size: 1920 x 1080 (16:9) Frame rate: 23,976 fps Pixel Aspect Ratio: 1 Color Space: ITU-R 709 Interlaced: no My expectation is that when creating a #ff color clip, the "#ff" should be interpreted as a full red in the ITU-R 709 color space (which is by the way the same chromacity as a full red in sRGB). Therefore, I don't understand why the color clip is rendered as #ff18000 instead of #ff. It seems as if there is some color space conversion happening which doesn't seem to make sense to me. When adding the transparent PNG on top, it seems to behave as if the color clip is now interpreted in the correct color space, and thus give the correct result (besides the "1" in #ff0001, which I assume is some sort of rounding error) Note that if instead of a "#ff color clip", I use a PNG filled with a #ff color, I get #ff0001 as output, both with or without a transparent PNG layered on top. Therefore, we have the four following behaviors: A: #ff color clip (output = #ff1800) B: #ff color clip + fully transparent PNG (output = #ff001) B: #ff PNG (output = #ff001) B: #ff PNG + fully transparent PNG (output = #ff001) Finally, note that if I render the video as a PNG image sequence (instead of either an H-264 encoded video, or the Project Monitor's preview), then I do get the correct #ff output in all four situations described above. SOFTWARE/OS VERSIONS Kubuntu 18.04 Kdenlive Version 20.04.1 (Official AppImage) KDE Frameworks 5.68.0 Qt 5.14.1 (built against 5.14.1) The xcb windowing system -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395056] Video thumbnails in timeline display incorrect frames when using speed effect (or when clip's fps different from project's fps)
https://bugs.kde.org/show_bug.cgi?id=395056 --- Comment #4 from Boris Dalstein --- Created attachment 113093 --> https://bugs.kde.org/attachment.cgi?id=113093=edit Correct video thumbnails when zoomed-out -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395056] Video thumbnails in timeline display incorrect frames when using speed effect (or when clip's fps different from project's fps)
https://bugs.kde.org/show_bug.cgi?id=395056 --- Comment #3 from Boris Dalstein --- Created attachment 113092 --> https://bugs.kde.org/attachment.cgi?id=113092=edit Incorrect video thumbnails when zoomed-in -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395056] Video thumbnails in timeline display incorrect frames when using speed effect (or when clip's fps different from project's fps)
https://bugs.kde.org/show_bug.cgi?id=395056 --- Comment #2 from Boris Dalstein --- (and sorry for the first message, it seems I hit "submit" in the middle of writing the bug report, please delete if someone has admin rights to do so) -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395056] Video thumbnails in timeline display incorrect frames when using speed effect (or when clip's fps different from project's fps)
https://bugs.kde.org/show_bug.cgi?id=395056 Boris Dalstein changed: What|Removed |Added Platform|Other |Kubuntu Packages Summary|Video thumbnails in |Video thumbnails in |timeline display incorrect |timeline display incorrect |frames when using speed |frames when using speed |effect (or when clipclip|effect (or when clip's fps |with different fps than |different from project's |project |fps) Version|unspecified |17.12.3 --- Comment #1 from Boris Dalstein --- The video thumbnails in the timeline (the ones that appear for all frames when zooming in, not the first/last thumbnails which seem to be okay) seem to ignore the 'speed' effect. That is, when speed=200%, it seems to display frame X/2 (w.r.t the beginning of the input non-cut clip) when the desired behaviour is to display frame X. See attachments showing: 1. When zoomed in, the "first" thumbnail is correct, but the "middle" and "last" thumbnails are incorrect 2. When zoomed out, all thumbnails (=first+last thumbnails) are correct This bug also seems to occur when the FPS of the input clip (e.g. 24fps) is different from the FPS of the project (e.g., 25 fps). I know this is bad practice to mix FPS and it's better to first convert the input clips to the target FPS before importing them, but still, the bug should not occur. -- You are receiving this mail because: You are watching all bug changes.
[kdenlive] [Bug 395056] New: Video thumbnails in timeline display incorrect frames when using speed effect (or when clipclip with different fps than project
https://bugs.kde.org/show_bug.cgi?id=395056 Bug ID: 395056 Summary: Video thumbnails in timeline display incorrect frames when using speed effect (or when clipclip with different fps than project Product: kdenlive Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Video Display & Export Assignee: j...@kdenlive.org Reporter: dalbo...@gmail.com Target Milestone: --- When zooming the timeline, it displays every individual video frame as a thumbnail -- You are receiving this mail because: You are watching all bug changes.