Blender video editor, when saving in any format with compression, changes the colors of the original video very much. #103422

New Issue

Konstantin · 2022-12-22T23:41:11+01:00

Konstantin commented

2022-12-22 23:41:11 +01:00

System Information
Operating system: Arch Linux
Graphics card: 3070 Ti

Blender video editor, when saving in any format with compression, changes the colors of the original video very much.

I attach the image: "before" at the top, "after" at the bottom.

Exact steps for others to reproduce the error
Add any video −> Render −> Render Animation.

P.S. If you save one picture, not video, the colors are not distorted.

**System Information** Operating system: Arch Linux Graphics card: 3070 Ti Blender video editor, when saving in any format with compression, changes the colors of the original video very much. I attach the image: "before" at the top, "after" at the bottom. ![2022-12-23_01-26-44.png](https://archive.blender.org/developer/F14084496/2022-12-23_01-26-44.png) **Exact steps for others to reproduce the error** Add any video −> Render −> Render Animation. P.S. If you save one picture, not video, the colors are not distorted.

Konstantin commented

2022-12-22 23:41:11 +01:00

Added subscriber: @imlegr

Germano Cavalcante commented

2022-12-23 02:15:47 +01:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-12-23 02:15:47 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2022-12-23 02:15:47 +01:00

What are these formats with compression?
The colors don't seem to have changed that much in my opinion.
Could it be that this is more a matter of output quality rather than compression?

I have not been able to replicate the problem.
VSE_format_compression_colors__bug.blend

What are these formats with compression? The colors don't seem to have changed that much in my opinion. Could it be that this is more a matter of output quality rather than compression? I have not been able to replicate the problem. [VSE_format_compression_colors__bug.blend](https://archive.blender.org/developer/F14084789/VSE_format_compression_colors__bug.blend)

Konstantin commented

2022-12-23 02:27:43 +01:00

The colors change noticeably. All of them. I've been doing graphics for years and most clients simply refuse to accept work if there are changes they haven't asked for.

The picture becomes less contrasty. Try rendering the animation in this file and see what happens in the output. Exactly the video itself.

Test.blend

The colors change noticeably. All of them. I've been doing graphics for years and most clients simply refuse to accept work if there are changes they haven't asked for. The picture becomes less contrasty. Try rendering the animation in this file and see what happens in the output. Exactly the video itself. [Test.blend](https://archive.blender.org/developer/F14084800/Test.blend) ![2022-12-23_04-23-36.png](https://archive.blender.org/developer/F14084807/2022-12-23_04-23-36.png)

Germano Cavalcante commented

2022-12-23 02:41:00 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Konstantin commented

2022-12-23 03:27:46 +01:00

What details do you need? I sent you the file.

Evan Wilson commented

2022-12-23 21:45:51 +01:00

Added subscriber: @EAW

Evan Wilson commented

2022-12-23 21:45:51 +01:00

Possibly a duplicate of #60947 (FFMpeg color offset)

Konstantin commented

2022-12-23 21:58:36 +01:00

In #103422#1465232, @EAW wrote:
Possibly a duplicate of #60947 (FFMpeg color offset)

No. I think this is another error. If you look in the render window (F11) - everything is displayed there correctly. But after saving it already appears a strong distortion of colors.

There are 2 images in the archive. Open them in any editor and compare.

pic.zip

> In #103422#1465232, @EAW wrote: > Possibly a duplicate of #60947 (FFMpeg color offset) No. I think this is another error. If you look in the render window (F11) - everything is displayed there correctly. But after saving it already appears a strong distortion of colors. There are 2 images in the archive. Open them in any editor and compare. [pic.zip](https://archive.blender.org/developer/F14087092/pic.zip)

Michael commented

2022-12-27 11:48:36 +01:00

Added subscriber: @James-Glover

Michael commented

2022-12-27 11:48:36 +01:00

This comment was removed by @James-Glover

*This comment was removed by @James-Glover*

Richard Antalik commented

2023-01-04 11:56:14 +01:00

Added subscriber: @iss

Richard Antalik commented

2023-01-04 11:56:14 +01:00

@imlegr I have rendered video from image you have provided and there is no such color offset. Can you check if this happens when you use video as input and not image? If so can you upload short video that I can use for testing?

Richard Antalik commented

2023-01-04 11:58:01 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Konstantin commented

2023-01-04 12:20:16 +01:00

In #103422#1469026, @iss wrote:
@imlegr I have rendered video from image you have provided and there is no such color offset. Can you check if this happens when you use video as input and not image? If so can you upload short video that I can use for testing?

There are no distortions in the render window, they are when saving. The file I sent you has video.

> In #103422#1469026, @iss wrote: > @imlegr I have rendered video from image you have provided and there is no such color offset. Can you check if this happens when you use video as input and not image? If so can you upload short video that I can use for testing? There are no distortions in the render window, they are when saving. The file I sent you has video.

Richard Antalik commented

2023-01-05 07:45:44 +01:00

Ah thanks, did not notice packed video...
On surface this seems to be same issue as #60947. It is important to check result in other player, like VLC.

Input video is encoded in yuv420p(tv, bt709), but sequencer can only work in RGB. At this stage colors are fairly preserved (in preview). Then image has to be converted to YUV again, but here we don't specify any encoding.

I don't quite understand why when same rendered output is viewed in Blender vs ffplay for example, the image is different, since whole encoding/decoding pipeline is pretty much default.

Blender decoding source:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\John\Desktop\work\cut.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2mp41
    encoder         : Lavf59.27.100
  Duration: 00:00:10.10, start: 0.000000, bitrate: 19376 kb/s
  Stream #0:0[0x1](und), 1, 1/15360: Video: hevc (Main), 1 reference frame (hev1 / 0x31766568), yuv420p(tv, bt709, left), 2560x1440 [SAR 1:1 DAR 16:9], 0/1, 23844 kb/s, 60 fps, 60 tbr, 15360 tbn (default)

[swscaler @ 000002ca37edd040] bilinear scaler, from yuv420p to rgba using MMXEXT
[swscaler @ 000002ca37edd040] 2560x1440 -> 2560x1440
[swscaler @ 000002ca37edd040] lum srcW=2560 srcH=1440 dstW=2560 dstH=1440 xInc=65536 yInc=65536
[swscaler @ 000002ca37edd040] chr srcW=1280 srcH=720 dstW=2560 dstH=1440 xInc=32768 yInc=32768
[swscaler @ 000002ca37edd040] using unscaled yuv420p -> rgba special converter

Blender decoding render:

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\John\Desktop\0001-0050.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    date            : 2023/01/05 07:28:12
    encoder         : Lavf59.27.100
  Duration: 00:00:00.85, start: 0.000000, bitrate: 20246 kb/s
  Stream #0:0[0x1](und), 1, 1/15360: Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(progressive, left), 2560x1440 [SAR 1:1 DAR 16:9], 0/1, 20477 kb/s, 60 fps, 60 tbr, 15360 tbn (default)

[swscaler @ 000002ca31d9ef40] bilinear scaler, from yuv420p to rgba using MMXEXT
[swscaler @ 000002ca31d9ef40] 2560x1440 -> 2560x1440
[swscaler @ 000002ca31d9ef40] lum srcW=2560 srcH=1440 dstW=2560 dstH=1440 xInc=65536 yInc=65536
[swscaler @ 000002ca31d9ef40] chr srcW=1280 srcH=720 dstW=2560 dstH=1440 xInc=32768 yInc=32768
[swscaler @ 000002ca31d9ef40] using unscaled yuv420p -> rgba special converter

All these cases have in common, that incorrect colorspace is assumed during encoding, even if colorspace is specified (not reflected by ffprobe so this may be done incorrectly). But not sure where this incorrect conversion happens exactly.

Ah thanks, did not notice packed video... On surface this seems to be same issue as #60947. It is important to check result in other player, like VLC. Input video is encoded in yuv420p(tv, bt709), but sequencer can only work in RGB. At this stage colors are fairly preserved (in preview). Then image has to be converted to YUV again, but here we don't specify any encoding. I don't quite understand why when same rendered output is viewed in Blender vs ffplay for example, the image is different, since whole encoding/decoding pipeline is pretty much default. ---- Blender decoding source: ``` Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\John\Desktop\work\cut.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2mp41 encoder : Lavf59.27.100 Duration: 00:00:10.10, start: 0.000000, bitrate: 19376 kb/s Stream #0:0[0x1](und), 1, 1/15360: Video: hevc (Main), 1 reference frame (hev1 / 0x31766568), yuv420p(tv, bt709, left), 2560x1440 [SAR 1:1 DAR 16:9], 0/1, 23844 kb/s, 60 fps, 60 tbr, 15360 tbn (default) [swscaler @ 000002ca37edd040] bilinear scaler, from yuv420p to rgba using MMXEXT [swscaler @ 000002ca37edd040] 2560x1440 -> 2560x1440 [swscaler @ 000002ca37edd040] lum srcW=2560 srcH=1440 dstW=2560 dstH=1440 xInc=65536 yInc=65536 [swscaler @ 000002ca37edd040] chr srcW=1280 srcH=720 dstW=2560 dstH=1440 xInc=32768 yInc=32768 [swscaler @ 000002ca37edd040] using unscaled yuv420p -> rgba special converter ``` Blender decoding render: ``` Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\Users\John\Desktop\0001-0050.mp4': Metadata: major_brand : isom minor_version : 512 compatible_brands: isomiso2avc1mp41 date : 2023/01/05 07:28:12 encoder : Lavf59.27.100 Duration: 00:00:00.85, start: 0.000000, bitrate: 20246 kb/s Stream #0:0[0x1](und), 1, 1/15360: Video: h264 (High), 1 reference frame (avc1 / 0x31637661), yuv420p(progressive, left), 2560x1440 [SAR 1:1 DAR 16:9], 0/1, 20477 kb/s, 60 fps, 60 tbr, 15360 tbn (default) [swscaler @ 000002ca31d9ef40] bilinear scaler, from yuv420p to rgba using MMXEXT [swscaler @ 000002ca31d9ef40] 2560x1440 -> 2560x1440 [swscaler @ 000002ca31d9ef40] lum srcW=2560 srcH=1440 dstW=2560 dstH=1440 xInc=65536 yInc=65536 [swscaler @ 000002ca31d9ef40] chr srcW=1280 srcH=720 dstW=2560 dstH=1440 xInc=32768 yInc=32768 [swscaler @ 000002ca31d9ef40] using unscaled yuv420p -> rgba special converter ``` All these cases have in common, that incorrect colorspace is assumed during encoding, even if colorspace is specified (not reflected by ffprobe so this may be done incorrectly). But not sure where this incorrect conversion happens exactly.

Thomas Dinges commented

2023-05-12 14:52:12 +02:00

@iss What is the status here? So is that actually a confirmed report or a duplicate of #60947? Please update the status accordingly.

Richard Antalik commented

2023-05-13 01:18:47 +02:00

It is duplicate, I wanted to do bit deeper dive as I do think there is something incorrect going on there, but haven't got time yet.

Closing as duplicate of #60947.

It is duplicate, I wanted to do bit deeper dive as I do think there is something incorrect going on there, but haven't got time yet. Closing as duplicate of #60947.

Richard Antalik closed this issue

2023-05-13 01:18:49 +02:00

Blender Bot added

Status

Archived

and removed

Status

Needs Information from User

labels 2023-05-13 01:18:50 +02:00

Sign in to join this conversation.