On Oct 24, 2016 17:43, "Larry Gritz" <[email protected]> wrote: > > Currently, it's only ColorConfig::createLookTransform and createDisplayTransform that take the key/value pair, so it's only those two that would need new varieties added. Not a big deal to add two methods. (Reality check: right now, createColorProcessor doesn't take any key/value parameters, and I'm not 100% sure if that's because the underlying OCIO functionality doesn't need them, or just that nobody has ever asked for it from me. Do you know? Should we be adding key/value to that as well?)
In OCIO, there are versions of Config::getProcessor that accept a Context pointer, but otherwise the existing context on the Config is used. So as long as OIIO transfers any user-specified context vars from the command line to the config before creating any processors, things will work as expected. However, if someone wanted to use OIIO's color API directly to create a processor while supplying their own context variables, I guess they would currently be out of luck. > I like sticking with #3, too, as it certainly makes things simple because it adds no new API calls, and the common 0-key and 1-key cases don't change at all. But I admit it's a little quirky. Do you believe that the comma as separator will be no problem? Nobody would have key or values names that themselves needed a comma embedded in them? OCIO allows context variables to be driven by environment variables. Thus, I think it would be reasonable to assume that the context keys won't stray outside alphanumerics and underscores, but I don't know if values are as clear-cut. Just my two cents: It's probably not worth worrying about now, but there's an outside chance that commas in values would be needed someday. -Nathan
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
