The v2.0 release of OCIO is planned to be made in the next few months. The updating to v2 docs states -
OpenColorIO is “feature complete” at SIGGRAPH 2020 (late August). This means that feature development concludes and a stabilization period begins during which the focus will shift to bug-fixing and refinement of features based on developer feedback and testing.
OCIO v2 is in the VFX Reference Platform for calendar year 2021 and so the plan is to tag an official 2.0 release towards the end of the year to support this.
There is some pressure to remove v1 ocio from packages due to it requiring python2.7 for building the documentation.
At this stage blender fails to build with the current master of ocio.
...blender/intern/cycles/render/shader.cpp:399:27: error: no member named 'applyRGB' in 'OpenColorIO_v2_0dev::Processor'
to_xyz_processor->applyRGB(r);
I expect this would probably be a two step process, first adjust existing code to build with v2 and then looking into taking advantage of new features.
I think the VFX reference platform is chosen for the LTS release and then maintained. Who knows what 2.93 LTS will use? Probably won’t be out till a third of the way through 2021.
Well next year is only three months away. ASWF plans to release v2 before then.
With the VFX reference being ocio v2 for next year, we should expect 2.93 will need to use v2, so we have about six months to adjust and test blender to use ocio v2. That is why I am bringing this up, to get the ball rolling so it can be ready for the next LTS release.
The upgrade can be seen as 2 steps: EDIT: which I now see you already mentioned in the first post, doh!
Upgrading the libraries from v1 to v2.
Updating the code to use the new v2 optimizations.
I believe the video tintwotin linked above covers this at one point, (iirc from the last time I watched it), but I don’t have time right now to rewatch it and post a timestamp.
Step 1 is the relatively easy one, it can be done in the first week of Bcon1. I see this a positive place to test out the as of yet decided/finalized optimizations for the library upgrade process.
(@LazyDodo: I plan on having a diff for Windows ready to go on October 21. I’m not saying it will be the final one, but at least enough of one for you to look at.)
Step 2 is the longer one, with many possible sub-steps. How long that will take, and how much can be done for 2.92, I cannot say.
i already have a diff ready for updating the libs, but given there is significant work to be done in the integration and there is seemingly no-one available to do that work it’s somewhat useless, hence i have not posted it.
doing the libs first and then going “well, blender doesn’t build anymore, someone ought to fix” that seems to be putting the cart before the horse a tiny bit.
how this usually goes is,
Dev doing the integration works on it, usually takes care of the libs for his dev environment themselves, but I do offer assistance there, will give out a preliminary patch privately if required.
Once 1 gets close to landing in master, I put up a diff for integrating the libs into the deps builder.
libs builder change lands
all platforms update their libraries and/or build-scripts.
Actually I wasn’t off by one, I was specifically referring to 2.93 - the next LTS release - that is, a release that is to be maintained for two years should be using libs that will stay available during the two year maintenance period.
While the Win builds bundle the various oss libs, the OSX and *nix builds (normally) rely on system installed libs, so need to use the same version as other apps.
While I expect updating to fix the build can be done before 2.93, and then tested to ensure no changes in functionality, I expect updates that take advantage of new features will be kept for later releases.
