dcpomatic/test/test.h, branch mainDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=main2025-10-15T20:33:26ZRelax and tidy some test references for Arch.2025-10-15T20:33:26ZCarl Hetheringtoncth@carlh.net2025-10-09T08:35:49Zurn:sha1:494dc3cee73ac03d84b9826869c8a4b92dc673c4Return quite close to original approach for "no colour conversion".2025-09-23T07:14:10ZCarl Hetheringtoncth@carlh.net2025-09-19T09:41:03Zurn:sha1:aac6fad8adad9020e6a82140085091fdef2873cf
There's a few things going on here:
1. Improve the regression test for 3042. Previously we made a DCP from
the reporter's _original_ prores file (before they converted it to XYZ)
and compared the result to a reference J2K file of uncertain origin.
This seems wrong because:
a) We never got confirmation from the reporter that the fix worked for
them, so any arbitrary reference is dubious.
b) It doesn't seem to reflect their actual complaint, which was that
they got a different result when making a DCP from XYZ TIFFs compared
to their "XYZ" Prores.
The new test makes a DCP from their TIFFs and "XYZ" Prores and compares
the result.
2. Revert to the old approach to "no conversion" handling. In the good
old days we did everything -> RGB48LE except XYZ12LE -> XYZ12LE, and
that's what we do again here.
3. Change the YUV->RGB conversion from Rec.601 to Rec.709 for the
"no conversion" case. This fixes the 3042 regression test.
The supposed "XYZ" Prores is yuv444p12le according to ffprobe. So I
think what we have here is actually a file that was converted to XYZ
and then back to YUV by Resolve. I experimented with using the raw
YUV values and considering them as XYZ but this was clearly wrong.
I think 3 is probably what I should have done in the first place.
Rename check_one_frame -> check_one_frame_against_j2c2025-09-22T09:42:52ZCarl Hetheringtoncth@carlh.net2025-09-18T10:44:16Zurn:sha1:a757fe63424074e9d3dfe7847a17bfe2b5fd93deFix 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.
Add parameter names.2025-01-18T20:06:40ZCarl Hetheringtoncth@carlh.net2025-01-17T10:12:35Zurn:sha1:10c45dc1418bc8c4766ec2c189dc78162d4664ddUse ConfigRestorer to reset override_path after use.2024-05-29T08:35:55ZCarl Hetheringtoncth@carlh.net2024-05-25T18:21:27Zurn:sha1:ca969a5faa17913d1da04e57f56c29d20340ce2cRename new_test_film2 -> new_test_film.2024-05-22T08:33:45ZCarl Hetheringtoncth@carlh.net2024-05-20T14:55:57Zurn:sha1:c95ba3eb99c5e4d6dca90cee7e5bb9077b6ed02cReplace all new_test_film with new_test_film2.2024-05-21T21:52:46ZCarl Hetheringtoncth@carlh.net2024-05-20T14:54:37Zurn:sha1:e3dba6242aed7415eddbbfb1e5d56ce6680603c1Allow building with C++17 and updated libxml++/pangomm/cairomm.2024-03-20T17:25:09ZCarl Hetheringtoncth@carlh.net2024-02-22T21:51:44Zurn:sha1:0232d80a625b2ffae687e6473ab3fc2603cf87eaInspect most DCPs made during tests with ClairMeta (#76).2024-01-15T11:44:53ZCarl Hetheringtoncth@carlh.net2024-01-12T14:29:12Zurn:sha1:de1b4a967e6854782e88e83d48af74289977c8c3