-
Notifications
You must be signed in to change notification settings - Fork 804
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The Future of OpenColorIO-Configs #19
Comments
My proposal, based on previous discussions and feedback is the following (and this is just my opinion... other ideas are welcome):
Alternatively, we could create a repo per config instead of doing something like OpenColorIO-Config-Share. We could instead provide a standard template to be used under the ASWF organization where it makes sense, and within external projects where the contributor prefers to own their own repo. |
Also a quick shout out: @KelSolaar and Michael Parsons have been doing an excellent job maintaining the ACES config in recent years. Thank you both for your efforts, which have been very appreciated by many! Thomas has also done a great job in keeping this conversation going over the last year and will be instrumental in making it a success IMO. And a call to the OCIO community: If you want to be a part of building the next generation of OCIO configs, please get involved. The OCIO community has a vast array of talent and your input is valuable. |
Would it make sense to have a bare-bones proof of principle configuration as part of this new "core" that works in conjunction with @scoopxyz's documentation project, complete with a low-barrier-to-entry Python generation file? |
Thanks @michdolan! :) @mlfp is Michael Parsons Github handle btw!
Yes that would be a good idea, at least to setup all the requisites for CI, CLA, README, whatever...
Yes although I reckon that different Configs will have different requirements from a generation standpoint. Some facts about the ACES one:
I think that the new ACES config should try as much as possible to be backwards compatible OR if we choose it does not have to be (which would be odd given OCIO 2 will be itself backwards compatible) we will have to implement a migration process. The ACES config is huge and just because of that we need a generator of some sort, given the last point about semi-proceduralism, it is maybe worth reaching a state of full-proceduralism where the generator is able to do everything just by pointing at the aces-dev CTL directory to create the baseline and then on top of that, adding the extra sugar that makes the config production-grade. |
Oh and mandatory shout-out to @hpd obviously :) |
OCIOv2 has many new Ops and features that makes OCIOv2 config files incompatible with OCIOv1 library i.e. limiting new configs to only use OCIOv1 ops forbids the use of these new Ops. The OCIOv2 library is backward compatible to enable users with OCIOv1 configs to operate even after a library update and to ease their later transition from v1 to v2 configs.
Without addressing the number of color spaces in a config, a partial answer to the config size is a new OCIOv2 feature Issue 980. The change in PR 1006 adds the built-in transform mechanism and implements some ACES CSC transforms. That should help config maintainers writing much more compact configs i.e. less external file dependencies and also help coding of any config generator. |
Yes! A huge thanks to @hpd for creating the ACES config! And to all those who contributed to the effort! That work has been invaluable to OCIO users! |
@hodoulp : Sorry if it was not clear, backwards compatible in term of public API, i.e. functionality, i.e. same layout, colorspaces, etc..., whatever happens inside the file itself is private business! :) Ideally, if a user loads a large comp template with the new config, his work should not break, likewise for a Maya scene. And yeah, the plan is to use the built-in transforms! |
^^ Ditto -- I'm really appreciative of everyone's past, present, and future efforts and contributions -- it's hard to overstate how valuable (and educational!) (and ubiquitous!) the ACES and SPI configs, tools, and documentation have been. Thanks HP, Thomas, Michael, Other Michael, Alex, Other Alex, Scott, Kevin, Joseph, Steve, Doug, Patrick, Jim, Nick, Troy, Sean, Jeremy, and everyone else... I owe each of you a beverage of your choosing.
|
Actually, this is already supported via the OCIO API. The config's cache ID is a hash (md5) of the entire config. It isn't stored in the config, but is simple to get via Python: |
What are your thoughts @scoopxyz ? I know you have had great ideas around this too. |
Thanks everyone for the input! Discussion can now be moved here: |
We're starting this issue to publicly discuss the future of this repository. There has been a fair amount of discussion on this topic within the OCIO TSC, and with ACES leadership, and we need to put a plan into action as soon as possible. Here's where we stand currently:
That all puts us in the right direction to make some progress, but there are some decisions to be made to get started. To be discussed first (there is MUCH more to discuss, but let's focus on these topics initially):
The text was updated successfully, but these errors were encountered: