2024-08-19 - NanoColor

Owned by Carol Payne
Aug 19, 2024
2 min read

August 19th, 2024

Host: Doug Walker, Carol Payne

Secretary: Carol Payne

Attendees: 

Doug Walker
Carol Payne 
Jonathan Stone
Doug Smythe
Cuneyt Ozdas
Nick Porcino
J. Schulte
Dennis Adams
Mark Reid
Barry Dempsey
Anders Langlands
Matthias Scharfenberg
Jessica Wang

OCIO NanoColor Working Group Meeting Notes

  • Jonathan: like the idea of maintaining the "processor" concept from OCIO, think that makes sense. This likely might just be a very generic type of processor, that could be for MaterialX, but also possibly other shader languages in the future

  • Doug: you're envisioning that a third-party could write their own implementation? Currently, we encourage folks who want to use OCIO with a different language to integrate that back to OCIO, so other people can use it. 

  • Jonathan: we want to be able to support both - contribute back as well as have a proprietary implementation

  • Carol: we should have a defined path for folks, having multiple paths easily becomes hard to maintain.

  • Nick: Can't currently pull out the bits that are NanoColor separably - in order to compile and link it, needed to include the entire OCIO library. Including the bits we wouldn't be using at all. Hoping we can move in a direction where NanoColor is just the bits we need. 

  • Doug: We were definitely thinking this would be a subset. But that you would link against the library, not individual modules. 

  • Jonathan: thinking about it like imath, easy to intern that file and use.

  • Nick: trivial link compatibility is paramount. Things like games mono-repos, etc

  • Carol: how much is too much? because it's in general just not how OCIO is built, it doesn't exist in a similar paradigm to exr and imath 

  • Nick: could OCIO have an object have a NanoColor "context"? That only calls exactly what is needed? 

  • Group has different definitions of "lightweight"

  • OCIO team was not anticipating folks approaching the library from anything other than an include

  • Nick pulls the parts he needs from exr, because the library can support that.

  • Jonathan: if we could keep it to imath size (around 42 files) that would be fine, but bigger might get tricky to vendor. 

  • Doug/Carol: this is fundamentally different to how OCIO is currently architected. It's designed as a package, not modular parts. Whether or not that's a good thing is a separate discussion... but it is what it is. 

  • Let's all take some time to re-group and think about options and the best way to proceed.