cdl_convert works in Python 2.6 through 3.4 and PyPy. A full test suite runs continuous integration through Travis-ci.org, coverage through coveralls.io, and code quality checked with landscape.io. Code is PEP 8 compliant, with docstrings following google code docstring standards.
Yes. No conversion or modification needed.
I either haven’t had time to build a parser for the format yet, or I might even be unaware it exists. Perhaps you should drop by the issues page and create a request for the format? If creating a request for a format it helps immensely to have a sample of that format.
This seemed the best approach for it’s place in the script converter that forms a backbone of this project. As support for the more complicated formats grows, It’s very like that export formats that write out a single file per CDL will live as methods of ColorCorrection , and export formats that write out multiple CDLs will live as methods of the yet unwritten container class.
It’s extremely unlikely that the parser functions will ever move to be methods of a class (either ColorCorrection or the container) as it wouldn’t make logical sense to instantiate the class, call a parse method of that class, then create more copies of itself.
At some point it may be desirable to create a class representing the input file, and at that point that class would definitely contain parse methods.
cdl_convert started as a simple script to convert from one format to another. As such, it wasn’t named with the standards that one would usually use for a python module. By the time the project became big enough, was on PyPI, etc, it was too spread out, in too many places to make changing easy. In the end, I opted to keep it. At some point, cdl_convert might migrate into a larger, more generic film & tv python module, which will be named properly.