Date
1 - 7 of 7
Compile order for OCIO, OIIO, OpenExr?
|
Steve Hwan
I asked Larry a variation of this at DigiPro and he suggested I ask on this list, as the answer was mildly complicated. I observed OCIO and OIIO had build dependencies on each other, so I was wondering if there was a recommended build order? (And now that I'm asking, I'll throw OpenExr into the mix for the question as well - are there any dependencies on OCIO? Or is it as simple as "Just build OpenExr first."?) -Steve |
|
|
|
Alex Hughes
From my understanding, OpenEXR can simply be built first. The OCIO and OIIO thing gets a bit more complicated for those two but I have never had complications where I would not build OpenEXR first -Alex On Thu, Aug 8, 2019 at 7:01 PM Steve Hwan <svhwan+opencgi@...> wrote:
|
|
|
|
Mark Boorer
1. OpenEXR 2. OpenColorIO 3. OpenImageIO 4. OpenColorIO tools The core OCIO library doesn't depend on OIIO, only the extra tools. On Thu, 8 Aug 2019, 19:24 Alex Hughes, <alex@...> wrote:
|
|
|
|
Gonzalo Garramuño
El 8/8/19 a las 15:32, Mark Boorer escribió:
1. OpenEXRIs there a target to build only the OpenColorIO tools? -- Gonzalo Garramuño |
|
|
|
Sloan, Blake
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
-blake
|
|
|
|
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
|
|
|
|
Mark Boorer
> Is there a target to build only the OpenColorIO tools? -DOCIO_BUILD_APPS=OFF -DOCIO_BUILD_APPS=ON You will unnecessarily build the core lib twice, but reinstalling it over the top should cause no issues. On Thu, 8 Aug 2019, 19:39 Gonzalo Garramuño, <ggarra13@...> wrote:
|
|
|