Bug 415371

Created attachment 124594 [details]
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.