5
$\begingroup$

I use Blender's video editing capabilities and noticed that the resulting video seems to have less intensive colors:

image comparison with VLC

The one on the left is the original, the right video was rendered with Blender.

The original video is in a mov container and ffprobe says this about the video stream:

h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, bt709)

I added the original video in a new video editing project, and did the following:

  • defined a rendering range
  • set this in the output properties:
    • container: Matroska
    • video output quality: Lossless
    • encoding speed: Good
    • audio codec: AAC

Is there a way I can avoid losing the color intensity?


Here's a link the original video.

Blender version is 2.82, running on Arch Linux 5.6.12.


Following Leander's suggestion, I created some PNGs from the original video file with ffmpeg -ss 00:30 -i MV* -t 00:01 images_%03d.png. Then I imported one of those images into Blender, and exported it again. Color was set to RGB, 8 bit color depth, compression was 15%:

ffmpeg left, Blender right

Left: extracted with ffmpeg. Right: imported and exported with Blender.

$\endgroup$
9
  • $\begingroup$ Set the colorspace to sRGB (not filmic) $\endgroup$
    – susu
    Commented May 28, 2020 at 14:33
  • 1
    $\begingroup$ Thanks @susu. In "Render Properities" → "Color Management", sRGB is the value for both "Display Device" and "Sequencer". "View Transform" is "Standard". When selecting the video strip of the original movie, I can see in its properties under "Source", that the color space is sRGB. Is there another place where I can and should set the color space to sRGB? $\endgroup$ Commented Jun 2, 2020 at 14:12
  • $\begingroup$ Just to be sure, can you try converting the video to PNGs, importing the PNGs into Blender and export them as PNGs as well? You can use a small sequence with a length of 1. Just to make sure that the color change doesn't happen because of encoding or format specific settings. $\endgroup$
    – Leander
    Commented Jun 6, 2020 at 6:48
  • $\begingroup$ can you provide the file? $\endgroup$
    – Crantisz
    Commented Jun 6, 2020 at 6:53
  • $\begingroup$ I provided the original file and also the comparison of PNGs. $\endgroup$ Commented Jun 6, 2020 at 7:30

2 Answers 2

8
+50
$\begingroup$

Since all outputs and original video opened in QT and Blender is "desaturated" in the same way, I would say that it is more like wrong interpretation of colours in VLC. There is also noticeable contrast in VLC that totally flatten black parts (hairs) = loose all the rest of details that wasn't destroyed by camera and compression already.


Original video and rendered VSE PNG inside Blender ... enter image description here

... they perfectly match (top row on bottom row with blend type - Different). I used curves to bring contrast in extreme values to see result better. Completely black. enter image description here

BTW also your screen of PNG's match perfectly.

But result differs when the same data (video and render is opened in VLC. enter image description here

Rendering into QuickTime H.264, opened in QT, produce differences only due compression artefacts.

enter image description here

$\endgroup$
6
  • 1
    $\begingroup$ I think this is a valid answer. It is hard to account for all the variables, other than to know that there is no perfect way to keep the information intact across different compression-decompression-recompression schemes. Compounded with different methodologies to display and decode depending on the particluar app. $\endgroup$
    – Pullup
    Commented Jun 6, 2020 at 19:19
  • $\begingroup$ I'd much prefer if you didn't delete your answer. Knowing that the cause of desaturation lies with VLC and not with Blender is valuable to me (and others, I assume). Optimally, we could find a way to make Blender produce video that VLC shows with the same colors as the input file. But your post is the next best thing. $\endgroup$ Commented Jun 7, 2020 at 8:17
  • 2
    $\begingroup$ When in doubt, ffmpeg is mostly the correctest. When still in doubt, use exr-sequences (I know, overkill for many situations.) $\endgroup$
    – Leander
    Commented Jun 8, 2020 at 11:47
  • 1
    $\begingroup$ @Matthias You know, VLC also has color correction. Maybe you can research about how vlc interprets certain formats or if there are color correction presets. $\endgroup$
    – Leander
    Commented Jun 8, 2020 at 11:48
  • 1
    $\begingroup$ Correct answer I believe. The problem is, as Leander noted wisely, extremely nuanced and complex, covering essentially: 1. Lack of tag acknowledgement in decoder, 2. Lack of tags in encoding, 3. Broken encoding in subtle ways, 4. Broken decoding in subtle ways. Try a different wrapper might resolve the issue, such as MOV. Not all wrappers provide all required tags, and the surface of proper decoding that would honour them is complex. $\endgroup$
    – troy_s
    Commented Jun 9, 2020 at 15:06
0
$\begingroup$

check the color management perhaps filmic is active here altering the colors. https://docs.blender.org/manual/en/latest/render/color_management.html

$\endgroup$
1
  • $\begingroup$ I already had a look. Here's a comment of mine in response to user susu: In "Render Properities" → "Color Management", sRGB is the value for both "Display Device" and "Sequencer". "View Transform" is "Standard". When selecting the video strip of the original movie, I can see in its properties under "Source", that the color space is sRGB. Is there another place where I can and should set the color space to sRGB? $\endgroup$ Commented Jun 9, 2020 at 14:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .