Re: Compile order for OCIO, OIIO, OpenExr?

Larry Gritz

This is all my understanding, too. To recap:

OIIO's dependency on OCIO is fundamental (well, if you want all the color conversion functionality, which of course any studio user does). 

OCIO's dependency on OIIO is limited. If you just need the OCIO libraries, OIIO is not needed at all. The ways that OCIO uses OCIO are strictly for ocioconvert, ociodisplay, and ociolutimage.

ocioconvert is a historical quirk dating from a time when OIIO did not have OCIO support and there was an actual purpose to 'ocioconvert', whereas now you just want to use 'oiiotool --colorconnvert.

ociodisplay is really just an example (and maybe ocioconvert is, too), and as examples, they don't need the full flexibility of an OpenImageIO-backed support of all possible data and file formats. So maybe a solution there is, say, to support OpenEXR only and use tinyexr (a header-only implementation of just exr core features).

ociobakelut is a little more fundamental, though only used by power users. But again, if you're willing to stipulate that the baked LUT images are always openexr, maybe there as well using OpenEXR or even tinyexr will let us avoid pulling all of OIIO in.

Also, it is worth noting that if these utilities were changed from C++ to Python, even if they still use OIIO, it would at least be a simple runtime dependency and not a circular build-order dependency.

-- lg

On Aug 8, 2019, at 11:39 AM, Sloan, Blake <bsloan@...> wrote:

Hi Steve!
OpenEXR does not (and should not) depend on OCIO.
I think I bring the OCIO->OIIO dependency up at every BoF.
What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)  
Build OCIO without ociorender
Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory)
Build OCIO with ociorender against OIIO
Install OCIO
Install OIIO
OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.
OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be 
  1. moved to a separate package, say OpenColorIOExtensions,
  2. made a build option that defaults to off, or better,
  3. made to depend on a lightweight image library whose code ships with OCIO (ppm?)
  4. dropped altogether from the build, as an installation of OIIO built against OCIO will already have oiiotool, whose functionality overlaps with ociorender.   

Larry Gritz

Join to automatically receive all group messages.