|
Re: Build error on CentOS 7.5
Yeah, I'm sorry, in OIIO master branch (the *next* release, in development), there has been an API change that OCIO has not yet caught up with. That's my fault, it's on my list to fix right away.
In the mean time, OCIO requires OIIO 1.8 (the current official stable release) or earlier, if you are building ocioconverr and the other command-line utilities. (OCIO's core library doesn't have any OIIO dependency at all.)
-- lg
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 error:
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp: In function 'int main(int, const char**)':
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:122:66: error: cannot convert 'OpenImageIO_v1_9::ImageInput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageInput>}' to 'OpenImageIO_v1_9::ImageInput*' in initialization
OIIO::ImageInput* f = OIIO::ImageInput::create(inputimage);
^
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:311:69: error: cannot convert 'OpenImageIO_v1_9::ImageOutput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageOutput>}' to 'OpenImageIO_v1_9::ImageOutput*' in initialization
OIIO::ImageOutput* f = OIIO::ImageOutput::create(outputimage);
I also get these warnings initially during the build but not sure if they eventually cause the build to error out?
/oss/imageworks/OpenColorIO/build/ext/yaml-cpp/src/ptr_stack.h:35:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<T> t(m_data.back());
I'm following the build instructions on this page. I have already built oiio and its installed in the default system location and ocio is picking that up correctly during the build process. But I came across this post re the cyclic dependency issue between ocio and oiio and I'm wondering if I need to follow the instructions on that thread in Linux as well since I intend to build all the ocio apps?
Thanks, Sachin
--
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Build error on CentOS 7.5
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 error:
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp: In function 'int main(int, const char**)':
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:122:66: error: cannot convert 'OpenImageIO_v1_9::ImageInput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageInput>}' to 'OpenImageIO_v1_9::ImageInput*' in initialization
OIIO::ImageInput* f = OIIO::ImageInput::create(inputimage);
^
/oss/imageworks/OpenColorIO/src/apps/ocioconvert/main.cpp:311:69: error: cannot convert 'OpenImageIO_v1_9::ImageOutput::unique_ptr {aka std::unique_ptr<OpenImageIO_v1_9::ImageOutput>}' to 'OpenImageIO_v1_9::ImageOutput*' in initialization
OIIO::ImageOutput* f = OIIO::ImageOutput::create(outputimage);
I also get these warnings initially during the build but not sure if they eventually cause the build to error out?
/oss/imageworks/OpenColorIO/build/ext/yaml-cpp/src/ptr_stack.h:35:8: warning: 'template<class> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
std::auto_ptr<T> t(m_data.back());
I'm following the build instructions on this page. I have already built oiio and its installed in the default system location and ocio is picking that up correctly during the build process. But I came across this post re the cyclic dependency issue between ocio and oiio and I'm wondering if I need to follow the instructions on that thread in Linux as well since I intend to build all the ocio apps?
Thanks, Sachin
|
|
|
Re: Considering OCIO --> ASWF
Sebastian Sylwan <syl...@...>
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 address what was identified as useful to these projects (as many of you already know).
S
On Sun, Sep 23, 2018 at 11:58 AM, Steve Agland <sag...@...> wrote:
> 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 together.
>
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 got
the feeling that people thought the ASWF was emphasizing the Software
side of things for the moment and ACES covers larger concerns, and
thus was a 'not yet'.
That said the last ASWF TAC meeting did bring up discussion over none
software artefacts.
Also to add to Larry's point about who is/would be driving things, you
can find out yourself by simply participating in the public calls (I
just listen in).
Kevin
--
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: Considering OCIO --> ASWF
Kevin Wheatley <kevin.j....@...>
On Sun, Sep 23, 2018 at 11:58 AM, Steve Agland <sag...@...> wrote: 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 together.
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 got the feeling that people thought the ASWF was emphasizing the Software side of things for the moment and ACES covers larger concerns, and thus was a 'not yet'. That said the last ASWF TAC meeting did bring up discussion over none software artefacts. Also to add to Larry's point about who is/would be driving things, you can find out yourself by simply participating in the public calls (I just listen in). Kevin
|
|
|
Re: Considering OCIO --> ASWF
Sean Looper <sean....@...>
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 structure I hope to see continued leadership from you and others who have helped propel OCIO forward. It sounds like a win for everyone involved if all goes to plan.
On Sun, Sep 23, 2018 at 5:23 PM Larry Gritz < l...@...> wrote: On Sep 23, 2018, at 12:28 PM, Sean Looper < sean....@...> wrote: I would like to hear how AWSF plans to avoid design/development by committee and the tendency that such a strategy has to fall short of the mark.
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 establish a charter that lays out our procedures. They are happy to accept a benevolent dictator, or a committee, or whatever else we want that would seem to work. We need to decide how to proceed.
To clarify, here are some things ASWF can do for us:
* Be a neutral party to hold assets like the domain, trademarks, etc., as well as encourage usage and contributions by making it a shared industry project rather than having the appearance of "ownership" by one studio.
* Shield us from liability by holding each project in its own LLC, legally distinct from any of us, our companies, or other projects.
* Provide and share some infrastructure and expertise, including some of the painful nuts and bolts related to CI, porting, testing, release engineering.
* Help direct toward this project the engineering contribution obligations of the premier member companies.
* Help coordinate communication with other projects and copies in the ecosystem, and help us get organized if we again fall into some period of disorganization.
It's worth also pointing out that ASWF is not some mysterious council of alien overlords. It literally *is* us, with its governance and technical direction set by the same companies that have been involved in using and building OCIO all along -- Dreamworks, Autodesk, DNeg, Disney, Sony (er, any day now, really), etc.
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: Considering OCIO --> ASWF
On Sep 23, 2018, at 12:28 PM, Sean Looper < sean....@...> wrote: I would like to hear how AWSF plans to avoid design/development by committee and the tendency that such a strategy has to fall short of the mark.
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 establish a charter that lays out our procedures. They are happy to accept a benevolent dictator, or a committee, or whatever else we want that would seem to work. We need to decide how to proceed.
To clarify, here are some things ASWF can do for us:
* Be a neutral party to hold assets like the domain, trademarks, etc., as well as encourage usage and contributions by making it a shared industry project rather than having the appearance of "ownership" by one studio.
* Shield us from liability by holding each project in its own LLC, legally distinct from any of us, our companies, or other projects.
* Provide and share some infrastructure and expertise, including some of the painful nuts and bolts related to CI, porting, testing, release engineering.
* Help direct toward this project the engineering contribution obligations of the premier member companies.
* Help coordinate communication with other projects and copies in the ecosystem, and help us get organized if we again fall into some period of disorganization.
It's worth also pointing out that ASWF is not some mysterious council of alien overlords. It literally *is* us, with its governance and technical direction set by the same companies that have been involved in using and building OCIO all along -- Dreamworks, Autodesk, DNeg, Disney, Sony (er, any day now, really), etc.
|
|
|
Re: Considering OCIO --> ASWF
Sean Looper <sean....@...>
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 in my mind being the potential for fits and starts being tied solely to that sponsor. The major benefit, as I think we've seen with projects like OpenEXR, Alembic, USD and others is an authoritarian focus on a single, owner-centric goal. I don't necessarily need convincing of AWSF governance for OCIO given its sometimes aimless history since Jeremy moved on but I would like to hear how AWSF plans to avoid design/development by committee and the tendency that such a strategy has to fall short of the mark.
On Sun, Sep 23, 2018 at 11:05 AM Haarm-Pieter Duiker < li...@...> wrote: Two thumbs up. OCIO is a great candidate for the services and standardization that the AWSF will provide.
--
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: Considering OCIO --> ASWF
Haarm-Pieter Duiker <li...@...>
Two thumbs up. OCIO is a great candidate for the services and standardization that the AWSF will provide.
HP
On Fri, Sep 21, 2018 at 12:22 PM, Larry Gritz <l...@...> wrote: 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 that underway, I want to make sure there's a chance here to air any reservations or objections so that we can move forward with a high degree of community consensus, and to answer any questions you may have about the process.
ASWF got a lot of publicity at SIGGRAPH, so I'm going to presume you all know its significance and relevance to us and the basic value proposition. But do speak up if you want more explanation, and I'm happy to expand on it.
I think there are several reasons why turning over governance to ASWF is good for this project:
(1) It emphasizes that OCIO really is a work of and for the VFX community as a whole and shouldn't be thought of as an "Imageworks project", especially in light of the new infusion of contributions from Autodesk and elsewhere. Having it be underneath the foundation's umbrella should be a help to adoption and contributions, versus continuing to be thought of as belonging to one studio.
(2) There are a variety of licensing, legal, and other issues that will be nice to turn over to a neutral party that likely can manage it better, and can do so with close coordination and uniformity with other projects in the ecosystem.
(3) It lets us use the shared infrastructure and engineering support from LF for continuous integration, artifact archival (i.e. compiled release binaries people can directly download and install!), and release management tasks, that are being coordinated and dedicated to ASWF projects. (That's where a lot of the money from the corporate members is going.)
(4) The corporate members not only fork over the $$, they also have to pledge a certain amount of engineering effort to open source. The first couple years (when there is a paucity of ASWF projects), it can go to any project that seems important in the ecosystem, but eventually it will be tightened and fulfilling the engineering obligations of the members will be expected to be dedicated as much as possible to ASWF projects. So by being an official ASWF project, OCIO is more likely to be the recipient of that engineering effort.
(5) OCIO has, to be honest, had some periods when it lacked a strong and consistent leadership, design direction, and implementation contributions. It's pretty healthy right now, but being part of this organization I think is also insurance for the future, to help us with organization, resources, and coordination if and when needed or in times of crisis.
If we go ahead with this, on a day-to-day basis, not much would change. The open source license we use (BSD) would remain the same. The copyrights would continue to be held by the individual authors or their companies. There might be a new CLA (or equivalent), perhaps a common one for all ASWF projects, and maintained by them rather than by Imageworks. Maybe the official canonical repo would eventually move from imageworks to the AcademySoftwareFoundation account on GitHub? But the same developers would work in the same way, the same people would have commit privileges, our process for developing and setting the design and engineering direction would remain as before, all by the same people. There's no micromanagement from above; the healthy projects run their own communities, unless they need help. There might be a more formal notion of a technical steering committee for the project, with the organization helping to facilitate the stakeholders staying in contact. An accepted project gets to elect a representative to the overall ASWF Technical Advisory Committee. I think that covers all the bases of what we'd see on the ground.
I want to emphasize that we haven't made the formal application yet, the ASWF has not yet accepted the project (though since they have solicited our application, our odds are good), and also Sony Imageworks (the current owner/sponsor) has not yet formally committed to the change in governance. But before proceeding further on any of those fronts, I want to make sure this is aligned with the goals and sentiments of the OCIO stakeholders.
Questions or discussion? Pros/cons as you see it?
--
Larry Gritz
l...@... / l...@...
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Considering OCIO --> ASWF
Steve Agland <sag...@...>
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 together.
Steve
|
|
|
Re: Considering OCIO --> ASWF
Francois Lord <flord...@...>
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 this.
Francois
toggle quoted message
Show quoted text
On 2018-09-21 03:22 PM, Larry Gritz wrote: 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 that underway, I want to make sure there's a chance here to air any reservations or objections so that we can move forward with a high degree of community consensus, and to answer any questions you may have about the process.
ASWF got a lot of publicity at SIGGRAPH, so I'm going to presume you all know its significance and relevance to us and the basic value proposition. But do speak up if you want more explanation, and I'm happy to expand on it.
I think there are several reasons why turning over governance to ASWF is good for this project:
(1) It emphasizes that OCIO really is a work of and for the VFX community as a whole and shouldn't be thought of as an "Imageworks project", especially in light of the new infusion of contributions from Autodesk and elsewhere. Having it be underneath the foundation's umbrella should be a help to adoption and contributions, versus continuing to be thought of as belonging to one studio.
(2) There are a variety of licensing, legal, and other issues that will be nice to turn over to a neutral party that likely can manage it better, and can do so with close coordination and uniformity with other projects in the ecosystem.
(3) It lets us use the shared infrastructure and engineering support from LF for continuous integration, artifact archival (i.e. compiled release binaries people can directly download and install!), and release management tasks, that are being coordinated and dedicated to ASWF projects. (That's where a lot of the money from the corporate members is going.)
(4) The corporate members not only fork over the $$, they also have to pledge a certain amount of engineering effort to open source. The first couple years (when there is a paucity of ASWF projects), it can go to any project that seems important in the ecosystem, but eventually it will be tightened and fulfilling the engineering obligations of the members will be expected to be dedicated as much as possible to ASWF projects. So by being an official ASWF project, OCIO is more likely to be the recipient of that engineering effort.
(5) OCIO has, to be honest, had some periods when it lacked a strong and consistent leadership, design direction, and implementation contributions. It's pretty healthy right now, but being part of this organization I think is also insurance for the future, to help us with organization, resources, and coordination if and when needed or in times of crisis.
If we go ahead with this, on a day-to-day basis, not much would change. The open source license we use (BSD) would remain the same. The copyrights would continue to be held by the individual authors or their companies. There might be a new CLA (or equivalent), perhaps a common one for all ASWF projects, and maintained by them rather than by Imageworks. Maybe the official canonical repo would eventually move from imageworks to the AcademySoftwareFoundation account on GitHub? But the same developers would work in the same way, the same people would have commit privileges, our process for developing and setting the design and engineering direction would remain as before, all by the same people. There's no micromanagement from above; the healthy projects run their own communities, unless they need help. There might be a more formal notion of a technical steering committee for the project, with the organization helping to facilitate the stakeholders staying in contact. An accepted project gets to elect a representative to the overall ASWF Technical Advisory Committee. I think that covers all the bases of what we'd see on the ground.
I want to emphasize that we haven't made the formal application yet, the ASWF has not yet accepted the project (though since they have solicited our application, our odds are good), and also Sony Imageworks (the current owner/sponsor) has not yet formally committed to the change in governance. But before proceeding further on any of those fronts, I want to make sure this is aligned with the goals and sentiments of the OCIO stakeholders.
Questions or discussion? Pros/cons as you see it?
--
Larry Gritz
l...@... / l...@...
|
|
|
Considering OCIO --> ASWF
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 that underway, I want to make sure there's a chance here to air any reservations or objections so that we can move forward with a high degree of community consensus, and to answer any questions you may have about the process.
ASWF got a lot of publicity at SIGGRAPH, so I'm going to presume you all know its significance and relevance to us and the basic value proposition. But do speak up if you want more explanation, and I'm happy to expand on it.
I think there are several reasons why turning over governance to ASWF is good for this project:
(1) It emphasizes that OCIO really is a work of and for the VFX community as a whole and shouldn't be thought of as an "Imageworks project", especially in light of the new infusion of contributions from Autodesk and elsewhere. Having it be underneath the foundation's umbrella should be a help to adoption and contributions, versus continuing to be thought of as belonging to one studio.
(2) There are a variety of licensing, legal, and other issues that will be nice to turn over to a neutral party that likely can manage it better, and can do so with close coordination and uniformity with other projects in the ecosystem.
(3) It lets us use the shared infrastructure and engineering support from LF for continuous integration, artifact archival (i.e. compiled release binaries people can directly download and install!), and release management tasks, that are being coordinated and dedicated to ASWF projects. (That's where a lot of the money from the corporate members is going.)
(4) The corporate members not only fork over the $$, they also have to pledge a certain amount of engineering effort to open source. The first couple years (when there is a paucity of ASWF projects), it can go to any project that seems important in the ecosystem, but eventually it will be tightened and fulfilling the engineering obligations of the members will be expected to be dedicated as much as possible to ASWF projects. So by being an official ASWF project, OCIO is more likely to be the recipient of that engineering effort.
(5) OCIO has, to be honest, had some periods when it lacked a strong and consistent leadership, design direction, and implementation contributions. It's pretty healthy right now, but being part of this organization I think is also insurance for the future, to help us with organization, resources, and coordination if and when needed or in times of crisis.
If we go ahead with this, on a day-to-day basis, not much would change. The open source license we use (BSD) would remain the same. The copyrights would continue to be held by the individual authors or their companies. There might be a new CLA (or equivalent), perhaps a common one for all ASWF projects, and maintained by them rather than by Imageworks. Maybe the official canonical repo would eventually move from imageworks to the AcademySoftwareFoundation account on GitHub? But the same developers would work in the same way, the same people would have commit privileges, our process for developing and setting the design and engineering direction would remain as before, all by the same people. There's no micromanagement from above; the healthy projects run their own communities, unless they need help. There might be a more formal notion of a technical steering committee for the project, with the organization helping to facilitate the stakeholders staying in contact. An accepted project gets to elect a representative to the overall ASWF Technical Advisory Committee. I think that covers all the bases of what we'd see on the ground.
I want to emphasize that we haven't made the formal application yet, the ASWF has not yet accepted the project (though since they have solicited our application, our odds are good), and also Sony Imageworks (the current owner/sponsor) has not yet formally committed to the change in governance. But before proceeding further on any of those fronts, I want to make sure this is aligned with the goals and sentiments of the OCIO stakeholders.
Questions or discussion? Pros/cons as you see it?
--
Larry Gritz
l...@... / l...@...
|
|
|
Any plans to update ACES config to version 1.1 (https://acescentral.com/t/aces-1-1-now-available/1420) in near future?
Thanks
|
|
|
Re: SIGGRAPH 2018 - OpenColorIO Birds of a Feather
George Siddiqui <geo...@...>
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: https://opencolorio.slack.com to: geo...@...Please may I be added to the ocio-v2 google group if it's up and running?
Best wishes,
George On Thursday, 16 August 2018 20:58:20 UTC+1, Michael Dolan wrote: 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 agenda
focused on the latest pull requests from the Autodesk OCIO v2 team: Doug
Walker, Patrick Hodoul, and Bernard Lefebvre. Doug ran a live demo in
Flame showing Lut3D inversion, tetrahedral interpolation on the GPU, ICC
and CLF support, and new Range and CDL ops. Patrick then gave an
explanation of the new GPU renderer, greatly expanded unit tests, and
additions to ocioconvert and ociodisplay for validating OCIO output.
I
followed Doug and Patrick's presentation with a case study on how we
implemented the new GPU renderer at Imageworks, and are seeing parity
with the same color transforms in Nuke's implementation of the OCIO CPU
renderer.
We also heard an update from Foundry's Tony Micilotta on the future of OCIO integration in Nuke.
Sean
Cooper (DNEG) and Mark Boorer (ILM) concluded the meeting by moderating
a discussion on the OCIO v2 proposal for rigorous built-in transforms
and the potential for an external "OpenColorMath" C++ library.
The
presentation slides are attached for your reference. Conversation will
continue in this mail list and the OCIO Slack group, so feel free to add
your thoughts or ask any questions you may have. A recorded version of
Doug's demo will be made available sometime after SIGGRAPH, so stay
tuned.
Thanks! Michael Dolan
On Thursday, 16 August 2018 17:55:38 UTC+1, Douglas Walker wrote: 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 to share the working group slides on my return, although they were pretty minimal and mostly just intended as conversation starters, so the audio is probably a better record of the event. Also, Patrick, Bernard, and I will be hosting an online meeting in two weeks for those that could not be in Vancouver and we will do a recap of the SIGGRAPH sessions there as well.
I second your shout out to Patrick, Bernard, and Mike, awesome work guys!
Sean, it was great to see you in Vancouver. It's very cool to see the Imageworks / Autodesk collaboration you helped us start last year delivering some nice results!
Doug On Aug 16, 2018, at 4:07 AM, Sean Cooper < se...@...> wrote:
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 colourspaces like ACES become more problematic. Where forcing recompiling and linking of the library for every ACES release isn't ideal. We're open to ideas on how to effectively solve this problem set and benefit us all with a uniform and reliable implementation of colour transforms.
And a special shout out to Patrick, Bernard, and Mike for the huge help and verification of our moving development. The community is very grateful for your contributions and care.
P.S. I recorded the conversation of this year's v2 working group in addition to Doug's notes. I'll append notes or provide the full audio log if some one requests it, pending Doug et. al. approval. On Wed, 15 Aug 2018, 7:25 pm Michael Dolan, < mic...@...> wrote: 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 agenda focused on the latest pull requests from the Autodesk OCIO v2 team: Doug Walker, Patrick Hodoul, and Bernard Lefebvre. Doug ran a live demo in Flame showing Lut3D inversion, tetrahedral interpolation on the GPU, ICC and CLF support, and new Range and CDL ops. Patrick then gave an explanation of the new GPU renderer, greatly expanded unit tests, and additions to ocioconvert and ociodisplay for validating OCIO output.
I followed Doug and Patrick's presentation with a case study on how we implemented the new GPU renderer at Imageworks, and are seeing parity with the same color transforms in Nuke's implementation of the OCIO CPU renderer.
We also heard an update from Foundry's Tony Micilotta on the future of OCIO integration in Nuke.
Sean Cooper (DNEG) and Mark Boorer (ILM) concluded the meeting by moderating a discussion on the OCIO v2 proposal for rigorous built-in transforms and the potential for an external "OpenColorMath" C++ library.
The presentation slides are attached for your reference. Conversation will continue in this mail list and the OCIO Slack group, so feel free to add your thoughts or ask any questions you may have. A recorded version of Doug's demo will be made available sometime after SIGGRAPH, so stay tuned.
Thanks! Michael Dolan
--
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.
--
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.
|
|
|
Re: SIGGRAPH 2018 - OpenColorIO Birds of a Feather
Douglas Walker <doug_...@...>
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 to share the working group slides on my return, although they were pretty minimal and mostly just intended as conversation starters, so the audio is probably a better record of the event. Also, Patrick, Bernard, and I will be hosting an online meeting in two weeks for those that could not be in Vancouver and we will do a recap of the SIGGRAPH sessions there as well.
I second your shout out to Patrick, Bernard, and Mike, awesome work guys!
Sean, it was great to see you in Vancouver. It's very cool to see the Imageworks / Autodesk collaboration you helped us start last year delivering some nice results!
Doug
On Aug 16, 2018, at 4:07 AM, Sean Cooper < se...@...> wrote:
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 colourspaces like ACES become more problematic. Where forcing recompiling and linking of the library for every ACES release isn't ideal. We're open to ideas on how to effectively solve this problem set and benefit us all with a uniform and reliable implementation of colour transforms.
And a special shout out to Patrick, Bernard, and Mike for the huge help and verification of our moving development. The community is very grateful for your contributions and care.
P.S. I recorded the conversation of this year's v2 working group in addition to Doug's notes. I'll append notes or provide the full audio log if some one requests it, pending Doug et. al. approval. On Wed, 15 Aug 2018, 7:25 pm Michael Dolan, < mich...@...> wrote: 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 agenda focused on the latest pull requests from the Autodesk OCIO v2 team: Doug Walker, Patrick Hodoul, and Bernard Lefebvre. Doug ran a live demo in Flame showing Lut3D inversion, tetrahedral interpolation on the GPU, ICC and CLF support, and new Range and CDL ops. Patrick then gave an explanation of the new GPU renderer, greatly expanded unit tests, and additions to ocioconvert and ociodisplay for validating OCIO output.
I followed Doug and Patrick's presentation with a case study on how we implemented the new GPU renderer at Imageworks, and are seeing parity with the same color transforms in Nuke's implementation of the OCIO CPU renderer.
We also heard an update from Foundry's Tony Micilotta on the future of OCIO integration in Nuke.
Sean Cooper (DNEG) and Mark Boorer (ILM) concluded the meeting by moderating a discussion on the OCIO v2 proposal for rigorous built-in transforms and the potential for an external "OpenColorMath" C++ library.
The presentation slides are attached for your reference. Conversation will continue in this mail list and the OCIO Slack group, so feel free to add your thoughts or ask any questions you may have. A recorded version of Doug's demo will be made available sometime after SIGGRAPH, so stay tuned.
Thanks! Michael Dolan
--
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...@....
For more options, visit https://groups.google.com/d/optout.
--
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
Re: SIGGRAPH 2018 - OpenColorIO Birds of a Feather
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 colourspaces like ACES become more problematic. Where forcing recompiling and linking of the library for every ACES release isn't ideal. We're open to ideas on how to effectively solve this problem set and benefit us all with a uniform and reliable implementation of colour transforms.
And a special shout out to Patrick, Bernard, and Mike for the huge help and verification of our moving development. The community is very grateful for your contributions and care.
P.S. I recorded the conversation of this year's v2 working group in addition to Doug's notes. I'll append notes or provide the full audio log if some one requests it, pending Doug et. al. approval.
On Wed, 15 Aug 2018, 7:25 pm Michael Dolan, < mich...@...> wrote: 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 agenda focused on the latest pull requests from the Autodesk OCIO v2 team: Doug Walker, Patrick Hodoul, and Bernard Lefebvre. Doug ran a live demo in Flame showing Lut3D inversion, tetrahedral interpolation on the GPU, ICC and CLF support, and new Range and CDL ops. Patrick then gave an explanation of the new GPU renderer, greatly expanded unit tests, and additions to ocioconvert and ociodisplay for validating OCIO output.
I followed Doug and Patrick's presentation with a case study on how we implemented the new GPU renderer at Imageworks, and are seeing parity with the same color transforms in Nuke's implementation of the OCIO CPU renderer.
We also heard an update from Foundry's Tony Micilotta on the future of OCIO integration in Nuke.
Sean Cooper (DNEG) and Mark Boorer (ILM) concluded the meeting by moderating a discussion on the OCIO v2 proposal for rigorous built-in transforms and the potential for an external "OpenColorMath" C++ library.
The presentation slides are attached for your reference. Conversation will continue in this mail list and the OCIO Slack group, so feel free to add your thoughts or ask any questions you may have. A recorded version of Doug's demo will be made available sometime after SIGGRAPH, so stay tuned.
Thanks! Michael Dolan
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
SIGGRAPH 2018 - OpenColorIO Birds of a Feather
Michael Dolan <mich...@...>
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 agenda focused on the latest pull requests from the Autodesk OCIO v2 team: Doug Walker, Patrick Hodoul, and Bernard Lefebvre. Doug ran a live demo in Flame showing Lut3D inversion, tetrahedral interpolation on the GPU, ICC and CLF support, and new Range and CDL ops. Patrick then gave an explanation of the new GPU renderer, greatly expanded unit tests, and additions to ocioconvert and ociodisplay for validating OCIO output.
I followed Doug and Patrick's presentation with a case study on how we implemented the new GPU renderer at Imageworks, and are seeing parity with the same color transforms in Nuke's implementation of the OCIO CPU renderer.
We also heard an update from Foundry's Tony Micilotta on the future of OCIO integration in Nuke.
Sean Cooper (DNEG) and Mark Boorer (ILM) concluded the meeting by moderating a discussion on the OCIO v2 proposal for rigorous built-in transforms and the potential for an external "OpenColorMath" C++ library.
The presentation slides are attached for your reference. Conversation will continue in this mail list and the OCIO Slack group, so feel free to add your thoughts or ask any questions you may have. A recorded version of Doug's demo will be made available sometime after SIGGRAPH, so stay tuned.
Thanks! Michael Dolan
|
|
|
Re: Digest for ocio...@googlegroups.com - 2 updates in 1 topic
Joseph Goldstone <jgold...@...>
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 “Digital Color Handbook”), and Amazon still shows a mock-up page
for it, but it never came out.
To ARRI Partner Program members who are curious about this we recommend one of Kang’s books. You could look at pp. 70-72 of “Color Technology for Electronic Imaging Devices":
https://books.google.com/books?id=vzQH3qA_RKkC&pg=PA72&lpg=PA72&dq=kang+tetrahedral+interpolation&source=bl&ots=DC1eh_t_Xh&sig=3DrpvVzNk2RaTz3fZV7c32Wm2Hw&hl=en&sa=X&ved=0ahUKEwjql8_iz6vcAhUNKXwKHfneA8cQ6AEIVzAG#v=onepage&q=kang
tetrahedral interpolation&f=false
But there’s also the Truelight documentation, and Richard Kirk does a nicer, I think, job of presentation than Kang (perhaps because Richard only outlines one scheme, whereas Henry Kang seems to outline every conceivable interpolation scheme ever invented).
If you go to this page:
and download the "Truelight Software Library” document from 2006, § 6.6 (“Colour Cube Transforms”), pp. 55-57, does a nice job and includes straightforward C code. I haven’t personally tested the code by cutting and pasting but I suspect it works. You
want to be sure that the tetrahedra are cut in such a way that the (0,0,0) to (1,1,1) chord of the cube runs along tetrahedral edges — this is kind of the natural way to do it, and in fact is how the (probably little used) 3D LUT processors in the original
DLP Projector electronics packages did it, back in the day — a handy thing back when image processing components were twenty years behind today’s components in terms of performance.
michael...@...: Jul 17 11:04PM -0700
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 make sense,
since it would be faster. And as for interpolation, I think we were both
referring to the same 2x2x2 cubes. You said ({6|7}, {12|13}, {18|19}),
while I used cartesian coordinates. Your way of expressing it makes sense
and fills in the blanks for me.
So I think I've got it, and thank you very much! How did you learn this
stuff? I can't find even one book that explains the math of cube luts. Can
you recommend any books or journal articles? My search has been
frustrating, as I said before, and I feel very fortunate that you've helped
me out. Anything you recommend I will definitely read.
Try it yourself, do a search and see if you can find any technical
documentation. Maybe I just don't know the right keywords. But I have a
feeling that other people who are curious about luts are going to find this
conversation in the future, and it will be a good resource for them too.
On Tuesday, July 17, 2018 at 12:11:42 AM UTC-4, Dennis Adams wrote:
|
Jim Houston <jim.h...@...>: Jul 18 12:07AM -0700
> On Jul 17, 2018, at 11:04 PM, michael...@... wrote:
> I can't find even one book that explains the math of cube luts.
One source is Chapter 11 of Digital Color Handbook by Guarav Sharma, CRC Press 2003 —
“Efficient Color Transformationion Implementation”
Jim Houston
|
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+unsu...@.... |
This message is confidential. It may also be privileged or otherwise protected by work product immunity or
other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing deadlines as incoming e-mails
are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.
This message is confidential. It may also be privileged or otherwise protected
by work product immunity or other legal rules. If you have received it by mistake, please let us know by e-mail reply and delete it from your system; you may not copy this message or disclose its contents to anyone. Please send us by fax any message containing
deadlines as incoming e-mails are not screened for response deadlines. The integrity and security of this message cannot be guaranteed on the Internet.
This email has been scanned for email related threats and delivered safely by Mimecast.
For more information please visit http://www.mimecast.com
|
|
|
Re: how to write .cube luts?
Jim Houston <jim.h...@...>
I can't find even one book that explains the math of cube luts.
One source is Chapter 11 of Digital Color Handbook by Guarav Sharma, CRC Press 2003 — “Efficient Color Transformationion Implementation”
Jim Houston
|
|
|
Re: how to write .cube luts?
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 make sense, since it would be faster. And as for interpolation, I think we were both referring to the same 2x2x2 cubes. You said ({6|7}, {12|13}, {18|19}), while I used cartesian coordinates. Your way of expressing it makes sense and fills in the blanks for me.
So I think I've got it, and thank you very much! How did you learn this stuff? I can't find even one book that explains the math of cube luts. Can you recommend any books or journal articles? My search has been frustrating, as I said before, and I feel very fortunate that you've helped me out. Anything you recommend I will definitely read.
Try it yourself, do a search and see if you can find any technical documentation. Maybe I just don't know the right keywords. But I have a feeling that other people who are curious about luts are going to find this conversation in the future, and it will be a good resource for them too.
On Tuesday, July 17, 2018 at 12:11:42 AM UTC-4, Dennis Adams wrote: 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}) -- so not (5, ...) and (7, ...) like your first set but (6, ...) and (7, ...) more like your second (but your G and B values are one too large). Then trilinear or tetrahedral interpolation is used for the final output value: 0.3 in R, 0.6 in G, and 0.9 in B (due to the fractions above). You would not multiply the output values by 63 as the LUT dimension is only used to scale input values.
Do you completely understand how a 1D LUT works? That should be your first step before attempting to understand how 3D LUTs work.
///d@
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 retrieve the output values written there. Let's say it finds values like 0.333333, 0.555555, 0.888888 written in that row. But the actual output won't be R(63*0.333333) G(63*0.555555) B(63*0.888888) because the processor will "average" those values with the values of neighboring cells in the table. But what cells?
Is (6 13 19) regarded as the center of a cubic block of 8 cells? It could be the center of a cube made up of 2x2x2 cells with corners at (5 12 18), (7 12 18), (5 14 18), (7 14 18), (5 12 20 ), (7 12 20), (5 14 20), (7 14 20). Or is the cube that is broken up into tetrahedra just a single cell in the table? Say, a cube with corners (6 13 19), (6 14 19), (7 13 19), (7 14 19), (6 13 20), (6 14 20), (7 13 20), (7 14 20) If I'm ever going to write a .cube lut file, I will need to know.
I'm also uncertain if the input value in its unrounded state is ever used again. In your example, it started out as (6.3, 12.6, 18.9). Are the fractional parts forever discarded, after rounding has been used to get the row index? Or are they used again in the interpolation?
On Saturday, July 14, 2018 at 12:22:00 AM UTC-4, Dennis Adams wrote: 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 fractional (in-between) parts are used to interpolate the output values.
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 impossible (255*63, 255*63, 255*63)] but instead rgb(0.1, 0.2, 0.3) is drawn from the range rgb(0.0-1.0, 0.0-1.0, 0.0-1.0), such that 0.0 means 0/63 and 1.0 means 63/63. What else could it be? I'm surprised it's been so difficult to find info on how to write .cube lut files. Is there a reference book or article you can recommend? I'd like to know everything about luts. My searches have been frustrating, as I mentioned, so you've really been a big help. Thanks again! On Wednesday, June 27, 2018 at 1:58:18 PM UTC-4, Dennis Adams wrote: How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases). Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.
///d@
I've been searching for weeks and can't find a clear explanation of how
.cube files are written. Please help me understand them.
I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.
I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?
Thanks.
--
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-d...@....
For more options, visit https://groups.google.com/d/optout.
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-d...@....
For more options, visit https://groups.google.com/d/optout.
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.
|
|
|
Re: how to write .cube luts?
Dithermaster <dither...@...>
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}) -- so not (5, ...) and (7, ...) like your first set but (6, ...) and (7, ...) more like your second (but your G and B values are one too large). Then trilinear or tetrahedral interpolation is used for the final output value: 0.3 in R, 0.6 in G, and 0.9 in B (due to the fractions above). You would not multiply the output values by 63 as the LUT dimension is only used to scale input values.
Do you completely understand how a 1D LUT works? That should be your first step before attempting to understand how 3D LUTs work.
///d@
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 retrieve the output values written there. Let's say it finds values like 0.333333, 0.555555, 0.888888 written in that row. But the actual output won't be R(63*0.333333) G(63*0.555555) B(63*0.888888) because the processor will "average" those values with the values of neighboring cells in the table. But what cells?
Is (6 13 19) regarded as the center of a cubic block of 8 cells? It could be the center of a cube made up of 2x2x2 cells with corners at (5 12 18), (7 12 18), (5 14 18), (7 14 18), (5 12 20 ), (7 12 20), (5 14 20), (7 14 20). Or is the cube that is broken up into tetrahedra just a single cell in the table? Say, a cube with corners (6 13 19), (6 14 19), (7 13 19), (7 14 19), (6 13 20), (6 14 20), (7 13 20), (7 14 20) If I'm ever going to write a .cube lut file, I will need to know.
I'm also uncertain if the input value in its unrounded state is ever used again. In your example, it started out as (6.3, 12.6, 18.9). Are the fractional parts forever discarded, after rounding has been used to get the row index? Or are they used again in the interpolation?
On Saturday, July 14, 2018 at 12:22:00 AM UTC-4, Dennis Adams wrote: 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 fractional (in-between) parts are used to interpolate the output values.
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 impossible (255*63, 255*63, 255*63)] but instead rgb(0.1, 0.2, 0.3) is drawn from the range rgb(0.0-1.0, 0.0-1.0, 0.0-1.0), such that 0.0 means 0/63 and 1.0 means 63/63. What else could it be? I'm surprised it's been so difficult to find info on how to write .cube lut files. Is there a reference book or article you can recommend? I'd like to know everything about luts. My searches have been frustrating, as I mentioned, so you've really been a big help. Thanks again! On Wednesday, June 27, 2018 at 1:58:18 PM UTC-4, Dennis Adams wrote: How does a 3D LUT work? Each numeric row has three entries, which represent R, G, and B output values, often 0.0 to 1.0 (but could be higher or negative for some cases). Each row represents a position in the 64x64x64 input cube. The input R,G,B value (sometimes after running through a lg2 "shaper" if it is linear) gets multiplied by 63 (in the case of a 64x64x64 cube) and rounded to the nearest integer. Then the row number of r*64*64 + g*64 + b. For example, input of rgb={0.1, 0.2, 0.3} becomes rgb_index={6.3, 12.6, 18.9} which become rgb_index_int={6, 13, 19} which is row index 6*64*64 + 13*64 + 19 = 25427, if you are looking for the nearest element. It's actually more complex than that since tri-linear or tetrahedral interpolation is used, which means 8 or 4 elements surrounding the 3D position are looked up and interpolated to create the output RGB value.
///d@
I've been searching for weeks and can't find a clear explanation of how
.cube files are written. Please help me understand them.
I have a .cube file that was generated with 3D Lut Creator, with an
image source of a HALD color image (64x64x64). No adjustments were
applied to the image, so the .cube file should show input=output. But
the decimal values in the lookup table mystify me. How were they
generated? The decimal values, when multiplied by 64, do round to a
number close to list position in the (64 64 64) list, but surely there's
a precise algorithm to output those decimal values.
I've tried reading the OCIO C++ code to get the answer, but I don't
really know the language. I want to write luts in Java. Can someone
there help me?
Thanks.
--
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-d...@....
For more options, visit https://groups.google.com/d/optout.
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-d...@....
For more options, visit https://groups.google.com/d/optout.
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...@....
For more options, visit https://groups.google.com/d/optout.
|
|
|
