dcpomatic/test/3042_regression_test.cc, branch deb13DCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=deb132025-08-12T15:16:07ZNew/improved pixel format decision when converting to XYZ.2025-08-12T15:16:07ZCarl Hetheringtoncth@carlh.net2025-07-21T22:48:42Zurn:sha1:98a8023dd774fd82c144a68039e0ea3131fb9142
For a long time we would keep XYZ12LE, if that's what we have, otherwise
ask FFmpeg to switch to RGB48LE.
Then in 1d5c211dadb9a9dc2318adce86ca9c31b367cabe I tried to fix the case
of an XYZ source mis-tagged as YUV. I changed things so that with no
colour conversion we'd always ask FFmpeg to convert to XYZ. This meant
that RGB sources with no colour conversion would get treatment by FFmpeg
due to the RGB -> XYZ switch.
Here we're going back to the more-or-less the "long time" behaviour when
there is a conversion (keep XYZ12LE but otherwise convert to RGB48).
When there's no conversion, keep RGB (to avoid the FFmpeg conversion
from RGB -> XYZ) but convert everything else to XYZ.
Fix incorrect colours with "no colourspace conversion" sources that are not AV_PIX_FMT_XYZ12LE.2025-05-26T19:51:18ZCarl Hetheringtoncth@carlh.net2025-05-22T23:23:43Zurn:sha1:1d5c211dadb9a9dc2318adce86ca9c31b367cabe
Prepare the image for where it is going to next. I don't understand the difference
in this situation between XYZ12LE and RGB48LE (it seems they are both 16-bit-per-channel)
but there you go.