I think ocioconvert can disappear completely from OCIO -- its functionality (and 1000x more) has been in OIIO for quite some time now. It's purely an artifact of a long-ago era when OIIO did not have OCIO functionality and Jeremy wanted to demo how you'd use OCIO and OIIO together. But nowadays that's not how you'd do it at all.

So it's really only an issue of ociolutimage.

Three approaches have been suggested:

1. As you said, move ociolutimage functionality into some part of OIIO (perhaps just as an oiiotool command) and remove it from OCIO.

2. If we are satisfied with ociolutimage ONLY working with exr files, we can use "tinyexr", which is an open source header-only exr reader/writer that we can embed in OCIO, thus removing the need for OIIO here (but limiting to one file type).

3. Rewrite ociolutimage in Python (using the OIIO python bindings) -- this still makes *execution* of ociolutimage dependent on having OIIO installed at runtime, but it no longer has an onerous build-time dependency. The natural build order, then, will be OCIO first, then OIIO second, with no circularity or repeated builds.

-- lg

On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

Re. the cyclic (two-way?) dependency between openimageio and opencolorio:

Would it be unreasonable to suggest moving the executables that depend on openimageio out of opencolorio and into openimageio?

Is it just ocioconvert and ociolutimage?

Are there downsides?

-blake

--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Larry Gritz

l....@...