Hi!
TD 2025.32820, macOS. With project.workingColorSpace = PASS_THROUGH
(the default), Movie File Out always writes transfer = sRGB (13) into the
colr atom, and silently sets matrix = BT.2020-NCL (9) whenever height ≥ 2160p.
Primaries stay BT.709 (1).
So a 4K H.264 export comes out tagged (1, 13, 9) — a meaningless combo.
Visible effect: same file looks brighter in QuickTime than on YouTube /
Chrome / Premiere, because QT compensates the sRGB-transfer tag while web
players read it literally.
par.outputcolorspace and par.outputreferencewhite are enable=False in
PASS_THROUGH with no UI hint — that gating isn’t on the Movie File Out wiki
page either.
Attached td_color_bug_test.tox — one baseCOMP, pulse “Run All Tests”.
Renders 13 clips, parses the colr atom natively (no ffmpeg needed), shows
results in a table DAT. Confirmed across h264 / h265 / prores / mjpa / hap
and across mov / mp4 — same pattern, so it’s a TD-level default, not a
libx264 quirk.
Suggested fix: in PASS_THROUGH either omit the colr atom, or pin matrix to
BT.709 to match the asserted primaries/transfer.
td_color_bug_test.tox (7.6 KB)
Cheers,
Alex