Created attachment 129764 [details] 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 #ff0000 "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 #ff0000, 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 #ff0000 color clip, the "#ff0000" 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 #ff0000. 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 "#ff0000 color clip", I use a PNG filled with a #ff0000 color, I get #ff0001 as output, both with or without a transparent PNG layered on top. Therefore, we have the four following behaviors: A: #ff0000 color clip (output = #ff1800) B: #ff0000 color clip + fully transparent PNG (output = #ff001) B: #ff0000 PNG (output = #ff001) B: #ff0000 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 #ff0000 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
Thanks for your good report! I can confirm #ff0000 -> #ff0001 but not -> #ff18000 with appimage version 20.12.2 Can you please test with the new version? Btw how have you analyzed the color? Does it only differ after you rendered the video or even in the timeline/project monitor?
Hi and thank you for your patience. Can you please check whether this issue still exists in the latest version 24.12.0? If yes, please update this report to reflect the new version and set the status to CONFIRMED. If it works now like you expect it would, you may change the status of this report to RESOLVED - FIXED. At any rate, this report will be closed if there is no activity for the next 30 days.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.