[kdenlive] [Bug 423658] New: Change of color when adding a fully transparent PNG over a color clip

2020-06-29 Thread Boris Dalstein
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)

2018-06-05 Thread Boris Dalstein
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)

2018-06-05 Thread Boris Dalstein
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)

2018-06-05 Thread Boris Dalstein
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)

2018-06-05 Thread Boris Dalstein
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

2018-06-05 Thread Boris Dalstein
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.