OCIOv2 with OSL native support, part IV, comment or discussion

Patrick Hodoul <patrick.hodoul@...>


The post is not a question but a comment on the current implementation in OSL of the color mgt support.  I faced a problem when developing the OSL unit test framework for OCIO, and I want to share what I found, some comments and perhaps a potential solution.

When run the OCIOv2 OSL unit test, it crashes if the OCIO env. variable is defined.

The problem originates from:
-> my main program creates "OSL::ShadingSystem"
---> creating "OSL::ShadingSystemImpl"
------> creating "OSL::OCIOColorSystem"
---------> creating "OIIO::ColorConfig" which load the config pointed by the OCIO env. variable

The problem is that OIIO is embedding OCIOv1 which cannot read an OCIOv2 config. That's the perfect example to illustrate Larry concerns about cyclic dependencies. I would also say that having an hidden dependency is problematic.

My comments are:
  • Why creating a OSL::OCIOColorSystem instance by default?  The code could delay the creation on the first request.
    • Cons - It will introduce a performance hit somewhere else!
    • Pros - It will do nothing if color mgt is never used.
  • There is no error handling i.e. OCIO throws an exception if the config is faulty, wrong version, etc. The OSL & OIIO layers must handle OCIO exceptions.
  • I think it highlights that the color mgt in OSL must be decoupled from OIIO, and only called on explicit demand.

Hoping it will help to improve OSL and / or OIIO and ultimately the OCIOv2 unit test framework :)

Join osl-dev@lists.aswf.io to automatically receive all group messages.