Date   

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.

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

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...@larrygritz.com / l...@imageworks.com




Considering OCIO --> ASWF

Larry Gritz <l...@...>
 

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...@larrygritz.com / l...@imageworks.com


ACES 1.1 config?

Shanky <shank...@...>
 

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

Sean Cooper <se...@...>
 

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.

On Jul 18, 2018, at 1:35 PM, ocio...@... wrote:

Topic digest 
View all topics
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...@...>
 


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


Re: how to write .cube luts?

michael...@...
 

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@




On Mon, Jul 16, 2018 at 9:51 PM <micha...@...> wrote:
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 found this Nvidia infographic explaining tetrahedral interpolation somewhat. The math seems straightforward enough, provided one knows which neighboring cells are included in the calculation. It's not clear from the graphics which cells are included. http://www.nvidia.com/content/GTC/posters/2010/V01-Real-Time-Color-Space-Conversion-for-High-Resolution-Video.pdf    

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.



On Fri, Jul 13, 2018 at 10:22 PM <micha...@...> wrote:
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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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@




On Mon, Jul 16, 2018 at 9:51 PM <michael...@...> wrote:
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 found this Nvidia infographic explaining tetrahedral interpolation somewhat. The math seems straightforward enough, provided one knows which neighboring cells are included in the calculation. It's not clear from the graphics which cells are included. http://www.nvidia.com/content/GTC/posters/2010/V01-Real-Time-Color-Space-Conversion-for-High-Resolution-Video.pdf    

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.



On Fri, Jul 13, 2018 at 10:22 PM <micha...@...> wrote:
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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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.


Re: how to write .cube luts?

michael...@...
 

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 found this Nvidia infographic explaining tetrahedral interpolation somewhat. The math seems straightforward enough, provided one knows which neighboring cells are included in the calculation. It's not clear from the graphics which cells are included. http://www.nvidia.com/content/GTC/posters/2010/V01-Real-Time-Color-Space-Conversion-for-High-Resolution-Video.pdf    

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.



On Fri, Jul 13, 2018 at 10:22 PM <micha...@...> wrote:
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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


8th annual Open Source VFX Beers of a Feather at SIGGRAPH

Larry Gritz <l...@...>
 

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 Vancouver, we will once again hold an event for developers and users of VFX-specific open source projects.  It's a great chance to meet in person with people you've been working with on the other end of the mail, while enjoying drinks and hors d'oeuvres, courtesy of our generous sponsors:

Academy of Motion Picture Arts & Sciences (ACES and OSS)
Autodesk
DigitalFish, Inc.
DreamWorks Animation
Google Cloud
Industrial Light & Magic
Method Studios 
Netflix
Peregrine Labs
Pixar Animation Studios 
Sony Pictures Imageworks 
Walt Disney Animation Studios 
Weta Digital 
Zorroa

Please direct questions to: lg AT imageworks.com

Please feel free to forward this email to your developers and post on the appropriate mail lists for open source VFX projects you administer or participate in.

Also, if your organization is not one of the sponsors but you'd like to be (no contribution is too small), contact LG and there's certainly time to help charge up a bigger tab, or to make sure we know to check with you for sponsorship next year. 


--
Larry Gritz
l...@...





Re: how to write .cube luts?

Jim Houston <jim.h...@...>
 

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 color value (  0 to 1023 )
or 
Normalized LUT input color value ( 0 to 1.0 from #/1023 )

The LUT access calculation normalizes the input color value, scales it by the number of entries to
get LUT array index positions (6.3, 12.6, 18.9 in the first example), and then uses all three Color values
to perform the interpolation (several types) to get an output value from the LUT.

A 1D LUT can be used to change the input value in a set way as long as the 3DLUT was generated with the same calculation, which 
is why it is called a shaper LUT.  It changes the result of the LUT access calculation.  As a result, you can have greater or less sample points
at different positions in the LUT. 

There, I think I have said the same things as in the e-mails below.


Though it is not about the .cube format, and runs the risk of confusion because it was written for programmers, there
is the ASC/Academy LUT format document which does explain some of the concepts for a fully general LUT and color matrix manipulation
system using integer or floating point HDR color.  https://www.dropbox.com/s/dl/jv6qavit4bpbu32/S-2014-006.pdf

If you want more particulars about the Resolve form of a .cube file, you can look at




Good Luck.


Jim Houston








On Jul 13, 2018, at 9:21 PM, Dithermaster <dither...@...> 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.



On Fri, Jul 13, 2018 at 10:22 PM <michael...@...> wrote:
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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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-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: how to write .cube luts?

Dithermaster <dither...@...>
 

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.



On Fri, Jul 13, 2018 at 10:22 PM <michael...@...> wrote:
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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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-dev+u...@....
For more options, visit https://groups.google.com/d/optout.


Re: how to write .cube luts?

michael...@...
 

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@




On Wed, Jun 27, 2018 at 12:03 PM mc <micha...@...> wrote:
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-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Homebrew version of OCIO not bringing all apps ...

jordi...@...
 

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



On Wednesday, 4 July 2018 06:38:17 UTC+1, Peter wrote:
+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 <deke...@...>
Sent: Wednesday, July 4, 2018 5:12 PM
To: oci...@...
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.

On Tue, Jul 3, 2018 at 5:01 PM Larry Gritz <l....@...> wrote:
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.


On Jul 3, 2018, at 3:37 PM, Liam <liam...@...> wrote:

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:
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


On Jul 3, 2018, at 2:06 PM, bsloan <bsl...@...> wrote:

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

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

--
Larry Gritz
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Larry Gritz




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

421 - 440 of 2147