Movie Writer Colors differ significantly from Rendered Output about godot HOT 5 OPEN

Hardware:

Running in Desktop Colour Accuracy Mode "Accurate" or "Override to Reference Mode" results in the same results. (I usually run in Accurate)

I do have Monitor color profiles installed:
(LG) 38GN950, LG SDQHD, LG ULTRAGEAR (for the three displays, respectively)

The bug occurs on all screens and appears unrelated to color correction in hardware / driver level.

from godot.

Re-Encoding the movie with HandBrake to something "default", like H.264 as written by the preset "Fast 1080p30", will result in a stream that's much closer to the original colors.

(comparing numerically is somewhat moot due to the complete re-encoding and default noisy quality of 22, but it's overall much closer)

from godot.

It could be that the file needs to be tagged as sRGB or something.

Well these are certainly linked
godotengine/godot-proposals#903

from godot.

It could be that the file needs to be tagged as sRGB or something.

Well these are certainly linked godotengine/godot-proposals#903

I don't think these are directly related, especially not after 4 years. I think that proposal is, at best, valid for Godot 3.

With no color grading enabled (i.e. Linear), a unshaded cube of color #808000FF reproduces exactly as color #808000FF on my display and screen capture. Also side-by-side.

Yet the same captured as video is much darker:

I think this may be a Color Gamut / Full vs. Limited Range scaling issue (due to how the colors actually scale up in bright regions and down in dark regions) in the written video file. Also noteworthy: The video color of the cube is only very subtly different. #808100FF

from godot.

I found this tidbit on my research after trying to take apart the moviewriter:

MJPEG videos are (according to VLC) in Planar 4:2:2 YUV full scale.
Most video is YUV limited scale so a lot of decoders do not expect full range video and AVI has no in-spec way to identify full-range video.

In reality, this is close to how the video is actually seen by VLC:

So it could indeed explain why the video appears dark/exaggerated in AVI format (values from 0..255 may be squished/remapped as if they were expected to be Limited Gamut 12..244 video or something)

(why are we using MJPEG in AVI containers, anyway? judging by the code, that was done because it's somewhat simple to implement, though one might ask why implement a video codec, there's excellent open source projects that do this made by wonderful people who enjoy doing this :) )

from godot.