|Anonymous | Login | Signup for a new account||2014-09-02 11:58 CEST|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002808||Kdenlive||Rendering||public||2012-11-01 01:22||2014-04-10 15:45|
|Platform||64 bit||OS||Ubuntu||OS Version||12.10|
|Product Version||Recent git|
|Target Version||Fixed in Version|
|Summary||0002808: BT601 Color Matrix HD Source (Canon DSLR's) encoded in 1080P HD BT709 Project Matrix is not converted. Pinks to Orange.|
|Description||Annoyingly a number of DSLR's including Canon T2i's encode h264 with BT709 color primaries but BT601 color matrix. It's flagged in the metadata and utilities like ffplay display correct results.|
Kdenlive / MLT recognize and assign it as a BT601 color matrix and therefore previews in both Clip & Project Monitors are correct which is great.
But as the 'standard' for rec709 HD video is BT709 color matrix and kdenlive HD Project Profiles follow that, when encoding out to HD h264 or mpeg2 containing BT601 color matrixed sources there appears to be no conversion of the matrix BT601 -> BT709, as a result blue hues turn towards green and pink hues turn towards orange, the latter having an unwanted effect on skin tone.
Yes it's possible to create a custom BT601 matrixed HD project in kdenlive / MLT which is great and metadata to flag BT601 can be added in a remux, but that's really non 'standard', detrimental, confusing for mixed HD source projects and can lead to misinterpretation, default handling by a media player for HD pixel resolution is BT709.
Also as preview in kdenlive respects the differences and therefore anyone grading in kdenlive will be judging adjustments in the monitor previews, when it comes to playback of the encoded project outside of kdenlive results will almost certainly differ.
I've attached a couple of images to illustrate the problem. A Project Monitor frame grab of correct rendition and a frame extracted via a controlled RGB conversion in Avisynth from the same source clip encoded out from kdenlive using a HD project profile.
I'm aware this again may seem a little pedantic, would it be possible to implement?
Sunabs git build
|Tags||No tags attached.|
|Build/Install Method||3rd party package|
|Attached Files|| BT601_Matrix_Source.png [^] (1,759,616 bytes) 2012-11-01 01:22|
BT601_Matrix_Source_Encoded_BT709_Proj.png [^] (2,026,987 bytes) 2012-11-01 01:22
video-from-bitmaps-always-bt601.png [^] (610,558 bytes) 2014-04-09 15:18
|May be related: with bitmap clips right colors now only on preview in "Clip properties".|
What exactly do you mean by “BT709 color primaries but BT601 color matrix”? The matrix for converting a given colorspace to XYZ follows directly from the primaries and white point (and the white point is D65 for both spaces).
Hm, from your description, it sounds like maybe the issue is the Y'CbCr conversion, not the RGB to XYZ as I initial thought… could that be right?
Movit can certainly handle such a combination, but getting Kdenlive to recognize it might be a different game. Especially since it's risky business to let heuristics override encoded colorspace information.
I found related info about DSLR's color primaries & matrixes here -
May be this will be useful for you if original reporter does not answer soon.
If colorshift in in video from bitmaps related to this may I ask you what you think about, this is wrong RGB to XYZ or something else?
This depends a bit. There are several things that are relevant for the decoding of a picture:
- Y'CbCr coefficients, if the picture is in YCbCr. There's also unfortunately the added complexity of “full range” vs. “TV range” here, due to JPEG deviating from MPEG back in the day.
- Color primaries (i.e. when you say “red” or “green“ or “blue”, what color exactly do you mean?) and white point (when R=G=B, what color exactly do you mean?).
- Gamma ramp, if the picture is not in linear color space (e.g. OpenEXR).
Then there's ICC profiles, which are more complex and I don't know much about. Movit doesn't do those (yet).
For a static bitmap having wrong colors, I would assume it's the color primaries that are off, especially if it's not a JPEG image (JPEG is pretty much the only format in wide use that uses YCbCr). A reasonable guess if there's no ICC profile would be sRGB, both for color primaries and gamma ramp. (sRGB conveniently enough shares primaries with BT709, which is the standard HDTV color space, but it has a slightly different gamma ramp.) I don't know what Kdenlive or MLT does here, really.
|Thank you for the explanation Sesse. It gave me hope that with YCbCr JPEGs colors will be the same after kdenlive/mlt. But no :( Same shift. The only workaround I have found is to make 1 fps videos from pictures with ffmpeg and work in kdenlive with this videos. Only in this way original colors preserved.|
|Obviously not; adding YCbCr to the mix only makes more ambiguity, it doesn't resolve any.|
edited on: 2014-04-10 04:44
Further experiments shown that I'm just a lamer. All my previous color comparisons was player to player or player to image viewer, kdenlive preview to player or image viewer. But such comparisons are useless because of overlay! Colors in video overlay slightly differs from other surfaces. Furthermore, looks like overlay can be used by only one application at time so other running overlay users will render to another surface with different results. I feel ashamed.
So, new result of experiments with scheme where overlay excluded - COLORS are OKAY. Slight brightens difference.
For example BT601_Matrix_Source.png from here, rendered in kdenlive with bt709 colorspace in profile, then frame extraction with "ffmpeg -i render.mkv -vframes 1 -c:v png -an -f image2 rendered-frame.png" and comparison with source in image viewer shown no difference in colors. Brightens differs (new brighter) but i better will say nothing about it...
Colors not okay.
And workaround with ffmpeg mentioned in previous message dosn't work.
I'm going crazy
1. Please do not hijack this bug to talk about color interpretation of static bitmaps. You have filed 21 bugs over the last few weeks, surely you can stick to commenting in one of them.
2. If you really want color management to work better, you will need to be much more solid than just to try all different options and conversions and checking it by eyesight. I don't think you can do this reasonably right now without adding some debugging code; MLT doesn't provide any way of looking at the linear color values, but that's really what you want to figure out which of the conversions go in what direction. (Well, that, and printing out what colorspace information it sends to Movit for the input and output.)
I think the nature of this specific bug is fairly understood (he wants Kdenlive to choose a different set of Y'CbCr coefficients for his clip, or at the very least allow overriding them); it would probably be easier to reproduce if the submitter sent a (very) short segment of video, but that's a different story.
Oh, and I'm going away for a while soon, so I doubt I can look at it.
|:-( ok, hijacking this bug was rude. But not more rude then leaving a user alone with bugs in yours software. I'm kdenlive hostage, with more then 15 hours of clips on timeline with no alternative to kdenlive in current stage of work because almost all done. After workarounding of a bug with audio (and others) just one thing to be done is render with proper colors and brightens. Please don't judge this post as disrespect, understand me, this is last one before total frustration and desperation :-(|
|2012-11-01 01:22||yellow||New Issue|
|2012-11-01 01:22||yellow||File Added: BT601_Matrix_Source.png|
|2012-11-01 01:22||yellow||File Added: BT601_Matrix_Source_Encoded_BT709_Proj.png|
|2014-04-09 15:18||varchar||File Added: video-from-bitmaps-always-bt601.png|
|2014-04-09 15:22||varchar||Note Added: 0009965|
|2014-04-09 19:03||Sesse||Note Added: 0009966|
|2014-04-09 19:28||Sesse||Note Added: 0009967|
|2014-04-09 21:20||varchar||Note Added: 0009968|
|2014-04-09 21:43||Sesse||Note Added: 0009969|
|2014-04-09 23:17||varchar||Note Added: 0009970|
|2014-04-09 23:26||Sesse||Note Added: 0009971|
|2014-04-10 04:06||varchar||Note Added: 0009972|
|2014-04-10 04:44||varchar||Note Edited: 0009972||View Revisions|
|2014-04-10 10:40||Sesse||Note Added: 0009973|
|2014-04-10 15:45||varchar||Note Added: 0009975|
|Copyright © 2000 - 2014 MantisBT Team|