https://bugs.kde.org/show_bug.cgi?id=415371
Bug ID: 415371
Summary: Applying LUT to SMPTE 170M colorspace videos is
incorrect
Product: kdenlive
Version: git-master
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Video Display & Export
Assignee: j...@kdenlive.org
Reporter: lilo...@gmail.com
Target Milestone: ---
Created attachment 124594
--> https://bugs.kde.org/attachment.cgi?id=124594&action=edit
SMPTE 170M colorspace video
Version of Kdenlive where bug is present (downloaded as Nightly AppImage):
20.03.70-539f6b3 (it's not present in versions list for reporting, so I chosen
"git-master" as the closest). The bug appeared at least as early as in 19.04.2.
To reproduce (100% repeatability):
- Create a project with any builtin profile.
- Add attached video file "smpte170m_sample.mp4" as clip to the project. Answer
to "Create and switch to new profile?" message doesn't matter.
- Move the clip to video track. Activate Timeline->"Fit zoom to project" to
ensure the clip is added (the video contains single frame, so it is difficult
to navigate to it manually).
- Add "Apply LUT" effect to the clip.
- For "LUT file to apply" field, browse and select attached file
"nochange.cube". Frame image in monitor will show that brightness and contrast
are changed, which is incorrect behavior, because nochange.cube represents
trivial handmade 3dlut which introduces absolutely no modifications to the
image. Rendering video produces the same wrong frame images as monitor does.
As a proof, you could perform the same actions on any BT.709 colorspace (the
most popular one for AVC) video file, and ensure applying nochange.cube
introduces no changes to the image.
I've attached two scaled down *.png files to quickly demonstrate the problem.
Video file is from my smartphone of quite popular model, so SMPTE 170M
colorspace (sometimes referred as BT.601 colorspace) doesn't seem to be too
rare to ignore. Anyway, it is defined as allowed for AVC.
ffmpeg video stream summary of the video (attention to "yuvj420p(pc,
smpte170m)"):
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.20.100
Duration: 00:00:00.04, start: 0.000000, bitrate: 42597 kb/s
Stream #0:0(und): Video: h264 (Baseline) (avc1 / 0x31637661), yuvj420p(pc,
smpte170m), 1920x1080, 42495 kb/s, SAR 1:1 DAR 16:9, 24.42 fps, 24.42 tbr,
24422 tbn, 48844 tbc (default)
Aside from bug reporting, I can suggest quick and dirty solution for ones who
have the same task as I do. My task is to shoot color calibration target on my
camera, create camera ICC profile, and produce .cube file which would convert
image from my camera colorspace to sRGB colorspace, i.e. fixing camera color
distortion. I use Argyll CMS and all the steps described well at
https://argyllcms.com/doc/Scenarios.html#PS1 (using collink with "-3c" key to
produce .cube file after that), so I was able to perform everything except I
noted the bug under question. The single additional step is needed to evade the
bug: open the footage with color target in kdenlive, apply nochange.cube I've
attached, render video, extract desired frame, and use it for "scanin" program
instead of original footage frame. So, resulting .cube file will fix both
camera color distortion and kdenlive LUT applying color distortion.
--
You are receiving this mail because:
You are watching all bug changes.
