Files
test2/scripts
Brecht Van Lommel 5cc6ad6afe Video: Save colorspace metadata based on display, remove HDR option
Now that there are Rec.2100 PQ and HLG displays, the additional HDR option
for video export is redundant. Typically you would now select a HDR display
early on and do all your video editing with it enabled.

For saving a HDR video, the encoding panel will now show the name of the color
space, and warn when the video codec or color depth is incompatible.

Since this is now based on interop IDs for the dislpay color spaces, we can
map more of those to the appropriate CICP code. This works fine for Display P3,
in my tests it looks identical to sRGB except that the wide gamut colors are
preserved.

However Rec.1886 and Rec.2020 are problematic regarding the transfer function,
although the latter at least has the correct primaries now. So it should be
a net improvement and this could be looked at later if anyone wants.

---

Background:

* Rec.1886 and Rec.2020 display color spaces in Blender use gamma 2.4.
* BT.709 trc is almost the same as gamma 2.4, so seems like the correct choice.
* We already write sRGB with BT.709 trc, which seems wrong.
* Yet sRGB matches exactly between Blender display and QuickTime, while
  Rec.1886 and Rec.2020 do not.
* Display P3 with BT.709 trc matches sRGB with BT.709 trc, just adding the wide
  gamut colors. So that is what is used for now. Also using the sRGB trc the
  file is not recognized by QuickTime.

There is apparently a well known "QuickTime gamma shift" issue, where the
interpretation of the BT.709 trc is different than other platforms. And you need
to do workarounds like writing gamma 2.4 metadata outside of CICP to get
things to display properly on macOS.

Not that QuickTime is necessarily the reference we should target, but just to
explain that changing the previous behavior would have consequences, and so
it this commit leaves that unchanged.

Pull Request: https://projects.blender.org/blender/blender/pulls/145373
2025-09-03 16:32:33 +02:00
..