# VSE loss of colour saturation on export

I am editing a video(MOV format) shot on Nikon coolpix. And i want same quality output, but an MP4. I tried with fallowing settings and curves modifier But it just darkens the image and not improves the colour saturation. In the screen shot i have overlaid with and without curves modifies and part of the source footage screenshot and my export settings.

How can i match source colours?

Source Video Details

Format                                   : MPEG-4
Format profile                           : QuickTime
Codec ID                                 : qt   2007.09 (qt  /niko)
Overall bit rate                         : 8 419 kb/s
NCDT                                     : NCTG

Video
ID                                       : 1
Format                                   : AVC
Format profile                           : Main@L4
Format settings, CABAC                   : Yes
Format settings, ReFrames                : 1 frame
Format settings, GOP                     : M=1, N=8
Codec ID                                 : avc1
Codec ID/Info                            : Advanced Video Coding
Bit rate                                 : 8 282 kb/s
Width                                    : 1 280 pixels
Height                                   : 720 pixels
Display aspect ratio                     : 16:9
Frame rate mode                          : Constant
Frame rate                               : 29.970 (30000/1001) FPS
Color space                              : YUV
Chroma subsampling                       : 4:2:0
Bit depth                                : 8 bits
Scan type                                : Progressive
Bits/(Pixel*Frame)                       : 0.300
Stream size                              : 315 MiB (98%)

Color range                              : Full
Color primaries                          : BT.709
Transfer characteristics                 : BT.709
Matrix coefficients                      : BT.709

• Do you have a short clip in mov format which you could provide to us? – aliasguru Aug 4 '16 at 4:34
• Perhaps its a mistake of gamma parsing. Quicktime variants are notoriously hard to get the gamma right. – 3pointedit Aug 4 '16 at 10:50
• Are you actually trying to get better saturation, och do you use the curve to try to work around saturation changes introduced by the re-encoding? – user27640 Aug 6 '16 at 2:39
• 1: You could make better curves to achieve the desired result. Make brights brighter and darks darker, somethink that look like this (but starting from (0, 0) and ends at (1, 1)): docs.toonboom.com/help/harmony-12/premium/Content/Resources/… But this is only a workaround. – Róbert László Páli Aug 8 '16 at 10:57
• 2: Cloud it be that there is color profile mismatch (Adobe RGB, sRGB, Generic RGB, etc)? Maybe you have to simply assign (not convert) the color profile to the exported video. If Blender allows to choose between color profiles, use the same for importing and exporting as the source file already has. – Róbert László Páli Aug 8 '16 at 10:59

Marks to @3pointedit for likely getting close to the answer. The rest appears to be a stream of complificationingeering.

In all likelihood what you are seeing as “saturation” is actually a byproduct of an incorrect curve. The source of the problem is likely that your “source” reference analysis was being decoded incorrectly. Where that is entering the chain is going to be tricky as heck to diagnose.

Any codec is transformed to the YCbCr domain. In doing so, the RGB values should remain (quantization errors aside) very close to your source file RGB.

I can see that the “Source” file looks much more contrasty, which suggests to me that your player you are evaluating the material in is likely not decoding your footage correctly.

Any transform from RGB to YCbCr is typically done to the specification, which stipulates a broadcast range scaling. This scaling changes the 0-255 RGB values to 16-235 and 16-240 range on the YCbCr planes respectively. Those scaled values are, assuming players behave correctly, scaled back to their proper positions on decode.

What I suspect is happening is that the original “source” decoder is likely assuming, absolutely incorrectly, that your Nikon footage is broadcast scaled and chopping off a significant range of values and scaling the remaining values. This ends up making your image much more contrasted, as well as being incorrect.

DSLRs and some pocket cameras introduced a nonstandard “full range” YCbCr encoding which uses the full 0..255 range of the YCbCr stream. Sadly, many decoders decode it incorrectly, and you end up seeing hyper-contrasted images. See that “Range” tag in the data dump? Frequently too, the decoder will use the wrong set of luminance coefficients to decode the footage, which results in colour skew.

There are also a plethora of other areas where an encode to decode chain might go wrong. I outlined some of those tricky steps in another answer here.

Best advice is to check your source footage decode in a few different players. I suspect that, while potentially not perfect, the FFMPEG libraries Blender is using are trying to give you the full range of your shot’s data, as it is decoded from the raw YCbCr values. The result will be a slightly flatter image with much more dense data, which ends up being much more optimal for grading and a better resultant image.

All of that said, how to match a look?

Creative grading is most optimally achieved using a nodal system, frequently non-realtime. Assuming the guess above is correct, you can figure out what portions of your footage you intend to use and grade them in the compositor. It will be a little tricky because of some colour things that are beyond the scope of this answer, but should be achievable. Try an ASC CDL node with a slight increase in Power, and possibly a very slight decrease in Slope.

Bottom line is that there is a better than average chance the decode you are seeing in Blender is closer to the intention of your source stream than what you are seeing in Random Video Player. Test against VLC, FFPlay, or even the free version of DaVinci Resolve.

Your curve is not delivering the result you appear to desire because you have applied a simple arc to it. What it sounds like you are wanting is a subtle ‘S’ shaped curve that rounds off the lower left to a hump towards the upper right.

• – user1853 Aug 8 '16 at 16:26
{"extraction_info": {"found_math": true, "script_math_tex": 0, "script_math_asciimath": 0, "math_annotations": 0, "math_alttext": 0, "mathml": 0, "mathjax_tag": 0, "mathjax_inline_tex": 0, "mathjax_display_tex": 0, "mathjax_asciimath": 1, "img_math": 0, "codecogs_latex": 0, "wp_latex": 0, "mimetex.cgi": 0, "/images/math/codecogs": 0, "mathtex.cgi": 0, "katex": 0, "math-container": 0, "wp-katex-eq": 0, "align": 0, "equation": 0, "x-ck12": 0, "texerror": 0, "math_score": 0.355071097612381, "perplexity": 3158.174167606295}, "config": {"markdown_headings": true, "markdown_code": true, "boilerplate_config": {"ratio_threshold": 0.18, "absolute_threshold": 10, "end_threshold": 15, "enable": true}, "remove_buttons": true, "remove_image_figures": true, "remove_link_clusters": true, "table_config": {"min_rows": 2, "min_cols": 3, "format": "plain"}, "remove_chinese": true, "remove_edit_buttons": true, "extract_latex": true}, "warc_path": "s3://commoncrawl/crawl-data/CC-MAIN-2020-29/segments/1593657134758.80/warc/CC-MAIN-20200712082512-20200712112512-00083.warc.gz"}