Topics

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:
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


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:
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:
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


Gonzalo Garramuño
 

El 8/8/19 a las 15:32, Mark Boorer escribió:
1. OpenEXR
2. OpenColorIO
3. OpenImageIO
4. OpenColorIO tools

The core OCIO library doesn't depend on OIIO, only the extra tools.
Is 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

  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.   

       

 

-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


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.   
       
 
-blake
 

--
Larry Gritz





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:

El 8/8/19 a las 15:32, Mark Boorer escribió:
> 1. OpenEXR
> 2. OpenColorIO
> 3. OpenImageIO
> 4. OpenColorIO tools
>
> The core OCIO library doesn't depend on OIIO, only the extra tools.
Is there a target to build only the OpenColorIO tools?

--
Gonzalo Garramuño