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.
Created attachment 124595 [details] 3dlut which performs no changes on source image
Created attachment 124597 [details] Original frame from the video
Created attachment 124599 [details] Frame from the video after nochange.cube applied
I confirm that the provided nochange.cube lut changes the color. This seems to be an MLT issue though. we will try to look into it.
I made a few tests regarding this issue. Problem seem to happen only if the project's colorspace is different than the clip colorspace. If you use a project matching your clips's profile (using a bt.601 colorspace), it works as expected, the lut doesn't change the image. However, when using a rec.709 color profile, adding the lut causes a color shift. However, when applying another effect after the lut, like "Position and Zoom" that is an rgb filter causing a yuv > rgb conversion, the colorshift is gone and the clip colors match the original clip. I am not sure if the problem is limited to clips using a full color range. So the issue seems to lie somewhere in MLT, when converting full range clips in bt.601 to rec.709, applying a LUT and exporting to YUV format.