Hi, I'm using a CentOS 7.5 (3.10.0-693.2.2.el7.x86_64) docker instance to build ocio with devtoolset-6 and my build fails with the following

Thumbs firmly up from me as well. FWIW, OCIO was one of the case studies that the VES Tech committee brought to the ASWF discussion as deep dive examples, so the ASWF structure was in a way biased to

Whilst I agree with the reasoning, I think it is better to be clear that there is no hard commitment for the ACES work to be moved under ASWF, there was discussion about this at the ACES next BoF but

I didn't realize how much I wanted a mysterious council of alien overlords until you said we weren't getting one. ;) That all sounds great, Larry. Thanks for the clarification. Within the ASWF

ASWF is not involved in the design or development per se. It's *us* who avoids design by committee, if that's what we want. In the process of being accepted, we (as a community) would need to

My only concerns are around the general benefits of having a single, production-focused sponsor (SPI in this case). As Larry alluded to, there are pros and cons to a single sponsor, the greatest con

Two thumbs up. OCIO is a great candidate for the services and standardization that the AWSF will provide. HP

Thumbs up from me. Another reason I see is that in my mind the Academy's ACES config is now the de facto "reference implementation" for OCIO and it makes sense to have them living closer

I'm all for it. OCIO has become an essential part of the VFX world and making sure its development will continue in a healthy fashion is important, in my opinion. I'm very happy to hear

Hey, everybody. We're thinking about applying to turn OpenColorIO governance over to the Academy Software Foundation (ASWF), and they are very enthusiastically seeking our application. Before we get

Any plans to update ACES config to version 1.1 (https://acescentral.com/t/aces-1-1-now-available/1420) in near future? Thanks

A big thank you from BlueBolt to all involved in the exciting developments announced last week at the BOF. Please could someone with slack workspace admin rights send me an invite for:

Sean, you're very welcome to share. The v2 project is being run entirely in the open and we want the community to be informed and to participate. I'm on my way back to Montreal ATM and would be happy

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