I want to be sure I understand, so please advise me. As I understand it, when a lut receives an input value of (0.1 0.2 0.3), the processor looks to row_index (6*64*64 + 13*64 + 19) in the table to

8th annual Open Source VFX Beers of a Feather Monday, 13 Aug 2018, 6-8pm Steamworks Brewpub, 375 Water St, Vancouver, BC http://steamworks.com/ For those of you attending SIGGRAPH 2018 in

It is useful to think separately about LUT color values { say 0 to 1023 } output from the LUT interpolation LUT array index positions { 0 to 63 for a 64 cube LUT in each color ) and either LUT input

Yes. The RGB input value range to an OCIO 3D LUT is always 0.0--1.0. Those values get mapped to the LUT indexes (0 to 64 for a 65x65x65, or 0 to 32 for 33x33x33, or 0 to 63 for 64x64x64, etc.). The

Thank you. I hope I understand correctly, that rgb(0.1, 0.2, 0.3) in your example is not drawn from the range rgb(0-255, 0-255, 0-255) [because then, say rgb(255, 255, 255) would be mapped to the

Plus now that I am trying to re-install so I can get ocioconvert I find myself with a build problem... attached.

Agreed, at the moment I have a couple of dependencies with the ocioconvert executable and the current situation is quite disruptive. +1 jb

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

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

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.

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

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

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

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

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

fyi homebrew/science has been deprecated. Luckily they migrated oiio/ocio into homebrew/core (default repo).

That’s the correct approach. The build steps from the readme are copied below. HP Building on Mac OSX Use the following commands to build these packages on Mac OSX OpenColorIO brew install -vd

We should find a way to fix this cyclic dependency once and for all. -- lg -- Larry Gritz l...@...

To build "ociolutimage", OCIO needs to be linked against OpenImageIO. These two packages have optional dependencies on each other, so build order can be troublesome if you need both packages with full

Just to highligth that ocio is expecting 'Red first' 3D luts.