dcpomatic/src/lib, branch 1575-save-windowsDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=1575-save-windows2025-09-28T17:49:26ZSave window metrics in the config file (#1575).2025-09-28T17:49:26ZCarl Hetheringtoncth@carlh.net2024-11-23T22:53:12Zurn:sha1:f3275bba73347eef03bbe6f7982e8ca25f2aced6
Perhaps these should be in a separate GUI file, like how it's done for
Films, but I can't really see a big advantage (and there already
GUI-only details in there).
In this commit we also save the hints dialog size/position and
start it a bit larger (#2892).
Updated nl_NL translation from Rob van Nieuwkerk.2025-09-28T17:48:32ZCarl Hetheringtoncth@carlh.net2025-09-28T17:48:32Zurn:sha1:0c3b063196a5cfe8223cee71ed749b7c1bddc6f9Fix Windows build.2025-09-28T16:21:15ZCarl Hetheringtoncth@carlh.net2025-09-28T16:21:15Zurn:sha1:8ea0c463b344b8adb776c3e0c48224ea1d7ea7a7Updated fr_FR translation from Dan Cohen.2025-09-28T15:59:33ZCarl Hetheringtoncth@carlh.net2025-09-28T15:59:28Zurn:sha1:78a17618ca57d4226e843636ec6cd99c373af671Draw markers better next to the position slider (#3005).2025-09-27T20:41:38ZCarl Hetheringtoncth@carlh.net2025-07-14T20:51:44Zurn:sha1:1dddce26733fc87e559e547003890357969350caRe-order cairo context scaling and pango layout setup (#2337).2025-09-26T21:57:09ZCarl Hetheringtoncth@carlh.net2025-09-25T10:51:43Zurn:sha1:492c0d0597230e680e7b59800d4f6e26d6a82e5e
This seems to fix problems where letters were scaled individually, but
their spacing didn't change (when x scale was applied).
Big thanks to user1768761
https://stackoverflow.com/questions/58528024/pangocairo-shows-cluttered-text-when-cairo-context-is-scaled
pot/merge.2025-09-26T17:56:55ZCarl Hetheringtoncth@carlh.net2025-09-26T17:56:55Zurn:sha1:66100d5f14759220c9f25d6facfccb188ef81f12Updated fr_FR translation from Dan Cohen.2025-09-26T17:50:24ZCarl Hetheringtoncth@carlh.net2025-09-26T17:50:24Zurn:sha1:bdb74456058727aa0da23dcf9476b837f41a057bReturn 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.
Add missing include.2025-09-15T12:27:20ZCarl Hetheringtoncth@carlh.net2025-09-14T19:57:35Zurn:sha1:d5c0e4ca0027dce6ab2473f512db35605e1ea9a6