Re: [ocio-dev] Digest for ocio-dev@googlegroups.com - 7 updates in 1 topic

[Blake Sloan]

Because of Deke's point that some applications for lut images require other 8-bit formats, I like 1 and 3.

My pitch in favor of #1 is that anyone using ociolutimage already has a build of OIIO somewhere (because of the build/runtime dependency). So it would seem that changing ociolutimage's parent package to OIIO would not require any significant changes to existing pipelines. 

-blake

On Jul 4, 2018 1:41 PM, <ocio...@googlegroups.com> wrote:

ocio...@googlegroups.com

Google Groups

Topic digest
View all topics

• Homebrew version of OCIO not bringing all apps ... - 7 Updates

Homebrew version of OCIO not bringing all apps ...

bsloan <bsl...@gmail.com>: Jul 03 02:06PM -0700 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

Larry Gritz <l...@larrygritz.com>: Jul 03 02:41PM -0700 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       -- Larry Gritz l...@larrygritz.com

Liam <liamfe...@gmail.com>: Jul 03 03:37PM -0700 Hi, I've been working building the the OpenEXR/Alembic/OIIO/OCIO/USD stack for Windows and it would be great to resolve the cyclic dependency. Let me know if I can help.   I like choice #1 and if for some reason no major action is done, can the cyclic dependency be documented somewhere?   Thx! Liam     On Tuesday, July 3, 2018 at 2:42:01 PM UTC-7, Larry Gritz wrote:

Larry Gritz <l...@larrygritz.com>: Jul 03 05:01PM -0700 The question for #1 ("move" ociolutimage functionality to oiio) is: Are there people/products using OCIO, who need this bit of functionality, but don't need any other part of OIIO, and therefore it would be a burden on them to have to install another large package (with many dependencies of its own)?   The question for #2 is: can the users of ociolutimage live with the restriction of ociolutimage working only with OpenEXR files?   #3 was my attempt at a compromise -- no restriction on file types for ociolutimage, no need for OIIO at all for people who don't need ociolutimage, and for those who do, at least the oiio dependency is only run time, not build time.       -- Larry Gritz l...@larrygritz.com

Liam <liamfe...@gmail.com>: Jul 03 05:32PM -0700 Hi, thank you for allowing my previous post.   Making ociolutimage dependent on OIIO should be ok because the dependency is needed and the change is to resolve a cyclic dependency.   #3 seems good also and how long would it take to rewrite ociolutimage in Python? Who could do this? Would it support Python 2/3?   Thx! Liam https://github.com/LiamGFX https://www.imdb.com/name/nm9070367 https://www.linkedin.com/in/liamfernandez     On Tuesday, July 3, 2018 at 5:01:35 PM UTC-7, Larry Gritz wrote:

Deke Kincaid <dekek...@gmail.com>: Jul 03 10:12PM -0700 I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.   So I vote for #1.

Peter Hillman <peterm...@googlemail.com>: Jul 04 05:38PM +1200 +1 for #1 It would be nice for OCIO to provide optionally built drop-in replacements for ocioconvert, ociolutimage etc as lightweight wrappers around oiiotool which map the command line arguments. Again, there'd be a runtime-only dependency on OIIO but it would prevent pipeline nightmares that happen when tools disappear between versions.   ________________________________ From: Deke Kincaid <dekek...@gmail.com> Sent: Wednesday, July 4, 2018 5:12 PM To: ocio...@googlegroups.com Subject: Re: [ocio-dev] Homebrew version of OCIO not bringing all apps ...   I’ve worked on some games in the past where the lut written out is a tiff and not just an exr.     So I vote for #1.     -- 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.

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to ocio-dev+u...@googlegroups.com.