Replace OpenImageIO dependency with OpenEXR

[michdolan]

We've been talking about how to solve the OCIO/OIIO circular dependency for years now, and I agree with @lgritz recent point that the best solution is to just support OpenEXR. The reasons I think this is the right answer are:

• OCIO already depends on OpenEXR. We currently just rip out Half and throw the rest away, but extending this to use the file format itself when apps need to be built is fairly trivial in terms of build logic. With Imath becoming its own project, this would migrate into two separate dependencies eventually, but even that is not unreasonable.
• OpenEXR is arguably the right format for most tasks needing the OCIO apps. It's the official format of ACES, supports OCIO's internal data type losslessly, and is easily converted to other formats in other tools without impacting the image.
• The circular dependency is a long standing issue, and it's critical for OIIO to be built against OCIO, but not the other way around. The apps are already written in C++, so re-writing in Python to make OIIO a runtime dependency has large side effects. Not to mention that one of the primary goals of the apps is to provide implementation examples to app developers, who are primarily using the C++ interface.
• This will be necessary to support package managers inuitively. The circular dependency topic often arrises with users hitting walls in homebrew, etc. while trying to get a full OCIO build.

I'm happy to tackle this work in the coming weeks, but certainly raise objections if you think this is not the right answer. There is no perfect answer, but after years of this conversation brewing around, this is the least controversial solution IMO.

Mentioning @aloysbaillet since this has also been impacting the complexity of aswf-docker.

[zachlewis]

Thank you Michael -- getting rid of that circular dependency is really going to make things so much easier -- especially for those of us maintaining OCIO and OIIO packages! Our current method for building OCIO against OIIO against OCIO is unconscionable. It's gonna be like night and day.

@lgritz, perhaps there's space in oiiotool for something like ociolutimage? I've personally only used it with EXRs (i.e., with ctlrender), but I can imagine scenarios where interchanging creative lattices as EXRs might be less feasible than other image formats.

[michdolan]

We could make an optional dependency to libtiff or something too to support integer formats.

[zachlewis]

I think libtiff would definitely do the trick, if it doesn't complicate things too much.

FWIW, I think between libtiff and OpenEXR, we'd satisfy the minimum requirements for statically building OIIO... :)

[michdolan]

We discussed this topic in today's TSC meeting and other suggestions were re-raised as to how to solve (or not solve) this circular dependency.

I have been working on implementing a lightweight image interface to support OpenEXR in OCIO apps, but as was discussed today, it would be simpler to just keep the OIIO dependency and instead refine the build process into two explicit steps. That's how we all build it now generally:

1. build OCIO without apps
2. build OIIO
3. build OCIO apps.

The following options were suggested:

1. Move apps to a separate repo (OpenColorIO-Apps)
2. Move apps to a sub-project in the current repo, which has it's own CMake project
3. Keep everything as-is, but default to not building the apps, or at least not the apps that depend on OIIO.

Despite having put some time into this, I'm not stuck on the approach I opened this issue to suggest. Supporting our own image library has clear downsides. I am personally equally ok with moving the apps to another repo, which is fairly consistent with OpenEXR's recent creation of their openexr-examples repo: https://github.com/AcademySoftwareFoundation/openexr-examples

Please add your opinions/suggestions. We've had this conversation many times, but would be great to resolve it with actionable steps.

Curious on your thoughts too @lgritz .

[lgritz]

OpenColorIO-Apps, which would have both OpenColorIO and OpenImageIO as dependencies, makes sense to me as a way to break the circular dependency. Plus, the vast majority of people who are building OCIO simply to get the libraries as a dependency for something else, do not need the apps at all.

Just to pick nits: openexr-examples is a bunch of example images (big enough to avoid embedding in the main repo), it's not a case of splitting the code base into two repos. (Though for 3.0, we did break Imath off into a separate repo, which OpenEXR now treats as a dependency.)

[maxnbk]

I thought the TinyExr idea was not a bad one, but as someone who maintains a lot of packages, I went the way of building things basically as described (ocio libs, oiio, ocio apps) long ago to avoid heartache from this issue being unsolved for so long, and solving it that way has felt "clean" to me. I'm not a fan of submoduling it, but just having it as a separate repo people can choose to build, or choose not to build, if they desire.

One complicating factor to me is, would these now be versioned independently? I would assume so, but I'd hope the "v1" of the split would match the version of OpenColorIO out at that present time, to avoid weird confusions around the idea of "OpenColorIO-2.1.0 against OpenColorIO_Apps-1.0.0", when the apps themselves are ostensibly already "2.1.0" or whatever version they get forked at.

[KelSolaar]

Hi,

I would favour 1. if possible. Our package manager that we also use to resolve the build environments does not like circular dependencies and the current situation means makes building both the libraries rather painful.

Having a separate repo makes it straightforward as it solves any dependency problem!

[darix]

Also for option 1

[darix]

Any updates on this?

[doug-walker]

Closing this as fixed via PR #1637. Many thanks to Remi and Michael for their work on this! This will be part of OCIO 2.2.