dcpomatic/src/lib/j2k_image_proxy.h, branch debug/niclasDCP-o-matic DCP toolshttps://git.carlh.net/cgit/dcpomatic/atom?h=debug%2Fniclas2018-04-13T22:23:00ZAccount for J2K decoding at lower-than-maximum resolution when cropping2018-04-13T22:23:00ZCarl Hetheringtoncth@carlh.net2018-04-13T22:23:00Zurn:sha1:0ff4fa6058b305476e7bc60c590acb6135c49b1c
the resulting images; fixes #1274.
Add basic memory-used stuff for butler and reduce minimum audio2017-12-29T22:51:50ZCarl Hetheringtoncth@carlh.net2017-12-29T22:51:50Zurn:sha1:a5ea5c0d2637dd41e3d356cb62cac75b8cadf8ce
readahead quite a bit. This in turn reduces the maximum butler memory
usage as it will keep getting audio (and hence video) until the
minimum audio readahead is hit.
Basics of forced reduction of JPEG2000 decode resolution.2017-08-14T20:07:49ZCarl Hetheringtoncth@carlh.net2017-08-03T16:54:06Zurn:sha1:0253b4e45c71a1c2e2a8bffaf1c3cb84a0a3e41aMulti-threaded decode of DCP when previewing.2017-07-26T14:47:52ZCarl Hetheringtoncth@carlh.net2017-07-26T14:47:52Zurn:sha1:3e230d3785f19bc707fd7ea2b1f55321b93f536fRename some variables.2017-07-26T12:21:40ZCarl Hetheringtoncth@carlh.net2017-07-26T12:21:40Zurn:sha1:b395478cbb0706de2b6afa9a34fb33e49c61ee67Reduce during J2K decode where possible for playback (#986).2016-11-26T15:14:11ZCarl Hetheringtoncth@carlh.net2016-11-26T15:14:11Zurn:sha1:5bbf16e87ca09369174c9d2bb7f7fe94b6d70275Fix handling of incorrectly-recognised JPEG2000 files.2016-06-29T15:01:14ZCarl Hetheringtoncth@carlh.net2016-06-29T15:01:14Zurn:sha1:92c691f29c5da9abca6a06605998e09f9b8103bb
Previously we asked libdcp whether an imported J2K file was
RGB or XYZ. The answer it gives is sometimes wrong, for reasons
that are not clear (either the files are not marked correctly,
or openjpeg is not parsing whatever metadata correctly).
However it seems that, in general, we use the user's specified
colour conversion to decide what to do with an image, rather than
asking the image what should be done to it.
Hence it makes more sense to assume that if a user specifies no
colour conversion for a J2K file then the file is XYZ.
With preview, the colour conversion from XYZ back to RGB is done
by FFmpeg, so we have to set the pixel format correctly on the
Image that comes back from J2KImageProxy. Now we get that pixel
format from the configured colourspace conversion rather than
from openjpeg's guess as to the file's colourspace.
It's a bit ugly that the only thing we ask the file about is whether
or not it is in YUV (which governs whether or not FFmpeg applies
the user's configured YUV-to-RGB conversion). Everything else is
decided by the configured conversion.
I think there's still some uglyness in here that I can't put my
finger on.
No-op; fix GPL address and use the explicit-program-name version.2016-05-25T19:56:58ZCarl Hetheringtoncth@carlh.net2016-05-25T19:56:58Zurn:sha1:3828baf56467224f5d44049bf1e7a7ed11f43a05Fix build.2015-12-04T21:14:06ZCarl Hetheringtoncth@carlh.net2015-12-01T20:53:57Zurn:sha1:009caa68c337760b618e18b8aff1ed4fd1ff0040Use libdcp's compress_j2k; move Data into libdcp.2015-12-04T21:14:06ZCarl Hetheringtoncth@carlh.net2015-11-30T00:05:34Zurn:sha1:6c19b21e12f73ce63edd406ea617ff25bcc9bfea