Thanks Mike! I'm particularly interested to discuss the ramifications of built in colour science transforms. I suspect that well defined and static colourspaces won't be too controversial, but dynamic

Hello OCIO community, On Tuesday (August 14th) we held the OpenColorIO Birds of a Feather meeting at SIGGRAPH 2018 in Vancouver. Thanks to everyone who was able to attend, we had a great turnout! The

Pretty sure there was a killer typo in Guarav’s illustration of tetrahedral interpolation though. There was supposed to be a second edition of that book (“Digital Color Imaging Handbook”, not

One source is Chapter 11 of Digital Color Handbook by Guarav Sharma, CRC Press 2003 — “Efficient Color Transformationion Implementation” Jim Houston

I guess this means that the lut processor doesn't use (256 256 256) nomenclature when it outputs a color, so it doesn't have to perform a conversion to (256 256 256) by multiplying by 63. That would

You don't round-to-nearest the index values, you floor them. Then the fractional parts are used for the interpolation. So for (6.3, 12.6, 18.9) the 2x2x2 cells used would be ({6|7}, {12|13}, {18|19})

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