Date   

Re: OCIO Configuration Reference Values

Malcolm Humphreys <malcolmh...@...>
 

I always thought this would be better as a 'chromaticities' field per colorspace. With one also being on the reference colorspace.

Question would be would this just be metadata or actually used to create extra ops.

What do you think?

.malcolm


On 28 Sep 2016 20:35, "Troy Sobotka" <troy.s...@...> wrote:
Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.
* Greyscale conversions. Again, missing metadata on Y weights.
* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.
* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.


Feedback appreciated.

With respect,
TJS

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


OCIO Configuration Reference Values

Troy Sobotka <troy.s...@...>
 

Greetings all.

Seeing as how development has appeared to have been kick-started again, I was wondering the feasibility of adding a much needed configuration element to OCIO?

Currently it is *exceptionally* difficult relying on OCIO to develop in-application UIs in terms of managing colour representation and more complex algorithms. The basic metadata of any given configuration's reference space is missing, and as a result, the following becomes extremely tricky to manage:

* Saturation UI elements. Incorrect Y weights for the various RGB primaries are impossible to glean from transforms.
* Greyscale conversions. Again, missing metadata on Y weights.
* Colour manage wheels and pickers. Missing primary chromaticities makes it impossible to properly correct wheels and pickers for any given display view.
* Formulas / functions / light math that might be required by shaders or algorithms that require known values for XYZ.

Given that Sony established the luma coefs metadata tag, which is largely unused, I was wondering if it might be feasible to add a similar, extremely bare-bones metadata tag for chromaticities for the reference space? Something similar such as:

reference_values: [R1, G1, B1, R2, G2, B2, R3, G3, B3, WR, WG, WB]

Where RGB 1-3 represent the reference space's transform to XYZ, and W RGB represents the white point as expressed in specifications. The need to reproduce the white point as per specifications might be required for algorithms or formulas that need to match values that may differ from the canonical Y positions in the RGB to XYZ matrix.

I've started a simple branch that does this basic feature, and am wondering about feedback from the big brains that lurk on this list. If this seems feasible, I'd be happy to flesh this out to include the matrix get / set and update the luma coefficients function to pull from the updated reference_values facet.


Feedback appreciated.

With respect,
TJS


NUKE CDL MatchGrade

kernelk...@...
 

I noticed that OCIO is used in Nuke for CDL exports. Are there any other programs apart from Nuke that create CDLs from matched grades? I was looking through the OCIO code and didn't see any code itself that does this. If any one has any repositories or pointers to available libraries, I would appreciate it.

K


Re: State of OCIO development re: CPU/GPU mismatches

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

I think it would be very interesting to take a look at an OpenCL OCIO implementation.

It seems like: #304, #396, + Kevin's CDL parse, would be easy first steps to get these creaky joints moving again.

I'll have more time next week to investigate the other pull requests, and catch up on the test suite.

@Malcolm: do know the status of the DNeg OCIO pull that has been referred to? And if there are still people there interested in pushing to the public repo? 

On Tue, Sep 13, 2016 at 9:37 AM, Dithermaster <dither...@...> wrote:
Nathan and others interested,

I've attached a PDF describing our OpenCL extensions to OpenColorIO. An accurate OpenGL path would do something very similar with multiple shader parameters, and would return GLSL instead of an OpenCL kernel. I am happy to work closely with anyone who wants to create the accurate OpenGL path starting from these changes, but I'm not an OpenGL expert so you'd need to handle the OpenGL side of things.

Sincerely,

///d@
Dennis Adams


On Tue, Sep 13, 2016 at 10:45 AM, Dithermaster <dither...@...> wrote:
Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


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


Re: State of OCIO development re: CPU/GPU mismatches

Dithermaster <dither...@...>
 

Nathan and others interested,

I've attached a PDF describing our OpenCL extensions to OpenColorIO. An accurate OpenGL path would do something very similar with multiple shader parameters, and would return GLSL instead of an OpenCL kernel. I am happy to work closely with anyone who wants to create the accurate OpenGL path starting from these changes, but I'm not an OpenGL expert so you'd need to handle the OpenGL side of things.

Sincerely,

///d@
Dennis Adams


On Tue, Sep 13, 2016 at 10:45 AM, Dithermaster <dither...@...> wrote:
Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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



Re: State of OCIO development re: CPU/GPU mismatches

Dithermaster <dither...@...>
 

Dennis, is your fork containing the OpenCL code path available to browse currently?
Nathan, no, but I could put something together for you if you'd like to review it.

///d@



On Mon, Sep 12, 2016 at 8:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


Re: State of OCIO development re: CPU/GPU mismatches

Mark Visser <mvi...@...>
 

+1 to Dennis's offer of fixed GPU path code, fixing the banding issue would be fantastic! I can pitch in with testing and code review if that helps.

I too would love to see what DNeg has been up to, but without a comprehensive test suite there's no easy way to see what changes a massive code dump introduces, and that's scary.

This PR is about as basic as it gets and has been in production at Mokko for years: https://github.com/imageworks/OpenColorIO/pull/396

cheers,
-Mark


On Tuesday, September 13, 2016 at 5:08:49 AM UTC-4, Malcolm Humphreys wrote:
I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <nath...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan

--
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: State of OCIO development re: CPU/GPU mismatches

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

Erlang, wow. That .travis.yml looks like it dates from when dinosaurs roamed the earth.

Having recently set it up for OIIO and OSL, perhaps I can take a stab at it. 



On Sep 13, 2016, at 2:08 AM, Malcolm Humphreys <malcolmh...@...> wrote:

I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <natha...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan



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



Re: State of OCIO development re: CPU/GPU mismatches

Malcolm Humphreys <malcolmh...@...>
 

I’m currently on holiday in-between gigs now that I have left dneg. I can do a bit of leg work before my new job starts if that helps.

Larry we did setup a very basic travis file back in 2012 but it seems dbr travis account no longer works. Do you think you could setup a more official travis account. I’m happy to improve this setup as it looks bit hacky using erlang? also to be a bit bigger of build matrix.


Does anyone have a pull request in mind which I can take a look at first?

This one needs a few tiny fixes and could signal the project is still alive

.malcolm

On 13 Sep 2016, at 8:31 am, Nathan Rusch <natha...@...> wrote:

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan

--
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: State of OCIO development re: CPU/GPU mismatches

Nathan Rusch <natha...@...>
 

Once again, thanks for chiming in everyone. It's definitely encouraging to see.

Andy, I agree with you on the idea of evaluating and trying to roll in as much of the usable "offline" development that has been done at DNeg as possible, especially if it could affect the state or validity of existing pull requests or issues.

Kevin, I also agree that I would rank anything related to image quality very high. As you can probably surmise from the topic of this thread, my motivations are not entirely unbiased with regard to the outstanding issues; if I had my druthers, the GPU/CPU mismatch would be at the top of the TODO list going forward, especially with more and more shows requesting ACES deliverables.

Larry, I think your triage proposal is a great one. From a quick look at the open PRs, it looks like there are probably at least 10 that could be merged completely painlessly and without changing any existing behavior. It sounds like there are still some internal details that need to be ironed out regarding how things will move forward, and I'm going to cross my fingers that that process is a smooth one, but I'd be lying if I didn't admit that having you involved in any capacity is immediately reassuring.


-Nathan


Re: State of OCIO development re: CPU/GPU mismatches

Kevin Wheatley <kevin.j....@...>
 

I'd like to also support Larry's suggestions, especially the
prioritisation/grouping of issues and using CI.

From my work point of view I'd like to see anything relating to image
quality near the top. we also have a couple of annoying CDL parsing
bugs one of which I didn't bother to report due to the inactivity. If
there is a chance of more activity, I'll prepare up a test case and
report it.

Kevin


Re: State of OCIO development re: CPU/GPU mismatches

Andy Jones <andy....@...>
 

Very happy to see this thread.  I don't have a lot to add, other than my support for the direction Larry outlined.   Also, thanks for kicking this thread off, Nathan!

The one thing I do want to add is that although public development stalled on github, I don't doubt that a lot of effort has already gone into preparing the big Dneg update that has been alluded to.  I'm guessing that the scope of the internal changes may have made it difficult to commit incremental updates.  Assuming we do start moving forward with public development, it would still be great to see some/all of those changes make it into the main repo in some form. Perhaps we could port aspects of that code piecemeal into master from an experimental branch over a series of releases?

Anyway, I'm sure we can all appreciate that getting code released and managing a software project can easily be as much work as developing it in the first place :)


Re: State of OCIO development re: CPU/GPU mismatches

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

Apologies for the name similarity Sean, people were very excited for your return when they heard I was starting haha.

On Mon, Sep 12, 2016 at 9:13 PM, Sean Looper <sean....@...> wrote:
Been lurking but glad to see a clearly outlined direction.

Also trying not to be mistook as Sean Cooper. 

Sean Looper

On Sep 12, 2016, at 8:58 PM, Larry Gritz <l...@...> wrote:

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-)

It has never been SPI's intention to abandon this project, and we definitely want to continue having a significant role in its continued development. We rely on it as heavily as anybody, so we are highly incentivized to keep it alive. I think it makes sense for us to step up as continued host and overall organizer of the project, but without Jeremy we are certainly going to need a lot of help and leadership from the senior developers elsewhere.

I'm really not qualified to run the project -- I have only passing familiarity with OCIO internals and color science. But I do know a thing or two about the proper care and feeding of open source projects, and it makes sense for me as SPI's software architect to help shepherd the process. So I'm prepared to help or kibbitz as needed and to the degree that I'm able. I also have admin privileges on the repo, so if there are necessary tasks such as granting others push privileges and so on, I can help with that backlog.

If anybody is interested in my opinion:

I don't believe in discrete "releases" (in the sense of something being developed offline and occasionally dropped in big hunks into open source).  The successful projects seem to be the ones where the actual day-to-day development is done out in the open on the master branch, with the biggest contributors themselves using the top-of-tree for their own productions. It's ok to have tagged releases or stable branches for the sake of users or vendors who want to lock down to a point where the software and APIs are known to be stable. But it's the user who should move forward in large discrete steps, not the developers. This is how we do it for OIIO and OSL -- in both cases, SPI's production tools build straight from master, we don't use a single line of code that's not on the public GitHub and going through public code review/pull request, and there is no design discussion other than on the public mail list. 

I think the first order of business is triage:

* Revisit all the outstanding pull requests: which are still relevant, which are important, which have been adequately code-reviewed and tested. They should be ranked in terms of how important/helpful they would be to merge. (You can't do them all at once; there has to be some order in which they are rebased, tested, and merged.)
* Revisit all the outstanding issues, close the ones irrelevant, mark duplicates, assess the difficulty of fixing them, and identify if any are potentially addressed by the pull requests.
* Identify people who have made significant improvements in private branches and encourage them to turn them into proper pull requests, so they can be code reviewed and integrated into the master.

Then find a reasonable number of PRs and fixes that can be more or less immediately merged, do so, and tag/release. It doesn't need to be an ambitious release, but releasing something will help put a stake in the ground declaring this as a living project.

I also think it might be helpful to invest some time up front in setting up TravisCI/Appveyor continuous integration to build with several platform configurations and run tests (please tell me OCIO has a testsuite?). I've done this for OIIO and OSL, and it's a tremendous time-saver to know that any pull requests being considered are known not to break the build or existing functionality; this will greatly streamline the processing of a long series of overdue pull requests (which, even if we presume each one works correctly when applied on the TOT master, should NOT be assumed to work when applied one after the other).

Does this sound like a reasonable path forward?

-- lg


On Sep 12, 2016, at 7:16 PM, Sean Cooper <se...@...> wrote:

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


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

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


Re: State of OCIO development re: CPU/GPU mismatches

Sean Looper <sean....@...>
 

Been lurking but glad to see a clearly outlined direction.

Also trying not to be mistook as Sean Cooper. 

Sean Looper

On Sep 12, 2016, at 8:58 PM, Larry Gritz <l...@...> wrote:

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-)

It has never been SPI's intention to abandon this project, and we definitely want to continue having a significant role in its continued development. We rely on it as heavily as anybody, so we are highly incentivized to keep it alive. I think it makes sense for us to step up as continued host and overall organizer of the project, but without Jeremy we are certainly going to need a lot of help and leadership from the senior developers elsewhere.

I'm really not qualified to run the project -- I have only passing familiarity with OCIO internals and color science. But I do know a thing or two about the proper care and feeding of open source projects, and it makes sense for me as SPI's software architect to help shepherd the process. So I'm prepared to help or kibbitz as needed and to the degree that I'm able. I also have admin privileges on the repo, so if there are necessary tasks such as granting others push privileges and so on, I can help with that backlog.

If anybody is interested in my opinion:

I don't believe in discrete "releases" (in the sense of something being developed offline and occasionally dropped in big hunks into open source).  The successful projects seem to be the ones where the actual day-to-day development is done out in the open on the master branch, with the biggest contributors themselves using the top-of-tree for their own productions. It's ok to have tagged releases or stable branches for the sake of users or vendors who want to lock down to a point where the software and APIs are known to be stable. But it's the user who should move forward in large discrete steps, not the developers. This is how we do it for OIIO and OSL -- in both cases, SPI's production tools build straight from master, we don't use a single line of code that's not on the public GitHub and going through public code review/pull request, and there is no design discussion other than on the public mail list. 

I think the first order of business is triage:

* Revisit all the outstanding pull requests: which are still relevant, which are important, which have been adequately code-reviewed and tested. They should be ranked in terms of how important/helpful they would be to merge. (You can't do them all at once; there has to be some order in which they are rebased, tested, and merged.)
* Revisit all the outstanding issues, close the ones irrelevant, mark duplicates, assess the difficulty of fixing them, and identify if any are potentially addressed by the pull requests.
* Identify people who have made significant improvements in private branches and encourage them to turn them into proper pull requests, so they can be code reviewed and integrated into the master.

Then find a reasonable number of PRs and fixes that can be more or less immediately merged, do so, and tag/release. It doesn't need to be an ambitious release, but releasing something will help put a stake in the ground declaring this as a living project.

I also think it might be helpful to invest some time up front in setting up TravisCI/Appveyor continuous integration to build with several platform configurations and run tests (please tell me OCIO has a testsuite?). I've done this for OIIO and OSL, and it's a tremendous time-saver to know that any pull requests being considered are known not to break the build or existing functionality; this will greatly streamline the processing of a long series of overdue pull requests (which, even if we presume each one works correctly when applied on the TOT master, should NOT be assumed to work when applied one after the other).

Does this sound like a reasonable path forward?

-- lg


On Sep 12, 2016, at 7:16 PM, Sean Cooper <se...@...> wrote:

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


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

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


Re: State of OCIO development re: CPU/GPU mismatches

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

Thanks for teeing that up, Sean, I was already intending to wade into this tonight. :-)

It has never been SPI's intention to abandon this project, and we definitely want to continue having a significant role in its continued development. We rely on it as heavily as anybody, so we are highly incentivized to keep it alive. I think it makes sense for us to step up as continued host and overall organizer of the project, but without Jeremy we are certainly going to need a lot of help and leadership from the senior developers elsewhere.

I'm really not qualified to run the project -- I have only passing familiarity with OCIO internals and color science. But I do know a thing or two about the proper care and feeding of open source projects, and it makes sense for me as SPI's software architect to help shepherd the process. So I'm prepared to help or kibbitz as needed and to the degree that I'm able. I also have admin privileges on the repo, so if there are necessary tasks such as granting others push privileges and so on, I can help with that backlog.

If anybody is interested in my opinion:

I don't believe in discrete "releases" (in the sense of something being developed offline and occasionally dropped in big hunks into open source).  The successful projects seem to be the ones where the actual day-to-day development is done out in the open on the master branch, with the biggest contributors themselves using the top-of-tree for their own productions. It's ok to have tagged releases or stable branches for the sake of users or vendors who want to lock down to a point where the software and APIs are known to be stable. But it's the user who should move forward in large discrete steps, not the developers. This is how we do it for OIIO and OSL -- in both cases, SPI's production tools build straight from master, we don't use a single line of code that's not on the public GitHub and going through public code review/pull request, and there is no design discussion other than on the public mail list. 

I think the first order of business is triage:

* Revisit all the outstanding pull requests: which are still relevant, which are important, which have been adequately code-reviewed and tested. They should be ranked in terms of how important/helpful they would be to merge. (You can't do them all at once; there has to be some order in which they are rebased, tested, and merged.)
* Revisit all the outstanding issues, close the ones irrelevant, mark duplicates, assess the difficulty of fixing them, and identify if any are potentially addressed by the pull requests.
* Identify people who have made significant improvements in private branches and encourage them to turn them into proper pull requests, so they can be code reviewed and integrated into the master.

Then find a reasonable number of PRs and fixes that can be more or less immediately merged, do so, and tag/release. It doesn't need to be an ambitious release, but releasing something will help put a stake in the ground declaring this as a living project.

I also think it might be helpful to invest some time up front in setting up TravisCI/Appveyor continuous integration to build with several platform configurations and run tests (please tell me OCIO has a testsuite?). I've done this for OIIO and OSL, and it's a tremendous time-saver to know that any pull requests being considered are known not to break the build or existing functionality; this will greatly streamline the processing of a long series of overdue pull requests (which, even if we presume each one works correctly when applied on the TOT master, should NOT be assumed to work when applied one after the other).

Does this sound like a reasonable path forward?

-- lg


On Sep 12, 2016, at 7:16 PM, Sean Cooper <se...@...> wrote:

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


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

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



Re: State of OCIO development re: CPU/GPU mismatches

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

Larry Gritz has and will be following the OCIO activity, but from what I understand isn't looking to be directly responsible for its progress. Erik Strauss has / will also be watching it's development. Apart from that, it'll be me actively working with all of you.

I agree on the open development. I think it would be beneficial at this point to sort through existing pull requests and issues, see what's ready to go, and what is still relevant after 2 years. Perhaps wrapping these into a dev branch?

On Mon, Sep 12, 2016 at 6:15 PM, Nathan Rusch <natha...@...> wrote:
Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks

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


Re: State of OCIO development re: CPU/GPU mismatches

Nathan Rusch <natha...@...>
 

Thanks for the responses everyone.

I'm attempting to reach out to some of the people who may have a connection to or interest in the project's stewardship, and will be asking them to weigh in on this thread so we can get as much information as possible out in the open. Sean, I'm wondering if you might be able to track down any of your colleagues who might have some interest or involvement in order to potentially get their input here as well. I'm not entirely sure how many of the original team are still at Imageworks, or how involved they want to be, so I don't necessarily want to blanket every name I can find.

In general, I'm inclined to agree with Deke that an ideal way forward from our perspective would be for active development to be out in the open on a development branch, rather than only landing in the form of releases.

Dennis, is your fork containing the OpenCL code path available to browse currently?


-Nathan


On Friday, September 9, 2016 at 2:18:51 PM UTC+10, Sean Cooper wrote:
Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks


Re: State of OCIO development re: CPU/GPU mismatches

se...@...
 

Hello fellow color wizards,

I'd just like to introduce myself to the community here. I've joined Sony Imageworks as our Color Scientist this past January, and have been working on our internal color pipeline and taking on more responsibility as I continue to learn.

I have interest in seeing OCIO continue it's open development, and would like to help where ever I can. Admittedly my background is in pure color/imaging science so I won't be able to immediately jump on the reins of it's core development. However, it seems like we have the opposite problem, and I would be happy to work with you to siphon through its present state and work towards a game plan to give OCIO a fresh breath of life.

Sean Cooper
Color Scientist
Sony Pictures Imageworks


State of OCIO development re: CPU/GPU mismatches

Deke Kincaid <dekek...@...>
 

I would also bring up your concerns with Erik Strauss at Sony.  As they founded the product they are still in control of it technically.  Mark at Dneg has been talking about their planned changes for many years now at Siggraph BOFs and on the forums but the promises of something coming "soon" has run it's course and is obviously not coming anytime soon.  We could easily have had a 1.10.0+ over 3 years ago with some of the now ancient pull requests. 

It feels that the management did not sign off as Dneg being the unofficial holder of development and instead this is a side project of some of the developers free time (which they obviously have zero of).  So no priority has been given to the project along with their regular duties of working on pipeline.  I also wish as others did that the planned/in progress development was much more out in the open like how Larry does with OSL & OIIO and previously Jeremy's work on ocio.  People are more likely to contribute & give feedback when this occurs rather then the 900lb code dump and everyone can take it or leave it.

-deke

On Thursday, September 8, 2016, Troy Sobotka <troy.s...@...> wrote:

Serious question, why not just publicly do a fork, and maintain it in the short term until the stewardship side of the official repository becomes clearer? At that point, the fork can be merged and everything carry on forward. If stewardship remains stuck, then the fork carries forward.

It seems win-win in this instance.

With respect,
TJS


On Wed, Sep 7, 2016, 9:55 PM Nathan Rusch <natha...@...> wrote:
Thanks for the information Dennis.

If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an OpenCL code path sounds like it could be an interesting addition to OCIO by itself anyway. I also wonder if the RV developers would be at all interested in taking a look at them.

Are those changes the kind of thing you would potentially be willing to share directly, rather than requiring them to be merged with the main repo first? I ask because the radio silence around the project is starting to get a little unnerving.

Thanks,

-Nathan



On Thursday, September 8, 2016 at 8:19:52 AM UTC+10, Dennis Adams wrote:
This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@
Dennis Adams
Sony Creative Software

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

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


Re: State of OCIO development re: CPU/GPU mismatches

Malcolm Humphreys <malcolmh...@...>
 

Hi,

I personally got very busy over the last year and I have been waiting to see Marks suggested changes to the core, so haven’t been involved as much as I would have liked.

From brief conversations it sounded like the ABI/API would be the same but the core has been reimplemented as plugins. The main advantage of this work would be to being able to have facility plugins for a grade database and automatic monitor selection.

Frankly it’s been a long time and I haven’t seen anything and at this stage this new core would need to exist in a development branch for sometime while it’s tested etc. Solving the banding issue is more important IMO as getting a new major version released and into 3rdParty vendors will take considerable lead time.

As Nathan and Troy suggests the OpenCL work would be great addition. Please do submit it as a fork so we can take a look at getting it merged.

.malcolm

On 8 Sep 2016, at 6:51 am, Troy Sobotka <troy.s...@...> wrote:

Serious question, why not just publicly do a fork, and maintain it in the short term until the stewardship side of the official repository becomes clearer? At that point, the fork can be merged and everything carry on forward. If stewardship remains stuck, then the fork carries forward.

It seems win-win in this instance.

With respect,
TJS


On Wed, Sep 7, 2016, 9:55 PM Nathan Rusch <natha...@...> wrote:
Thanks for the information Dennis.

If we do end up trying to tackle the OpenGL code path ourselves, I would definitely be interested in the idea of using your changes as a starting point, and an OpenCL code path sounds like it could be an interesting addition to OCIO by itself anyway. I also wonder if the RV developers would be at all interested in taking a look at them.

Are those changes the kind of thing you would potentially be willing to share directly, rather than requiring them to be merged with the main repo first? I ask because the radio silence around the project is starting to get a little unnerving.

Thanks,

-Nathan



On Thursday, September 8, 2016 at 8:19:52 AM UTC+10, Dennis Adams wrote:
This issue not just tetrahedral interpolation, it is the fact that the existing OCIO OpenGL GPU path folds all LUTs into a single 3D LUT, and this is not sufficient for many transformations (especially ACES when both 2D and 3D LUTs are being used).

We fixed this for our GPU processing pipeline and we were working on contributing it back to OCIO, but that effort got stalled (and it doesn't seem like there is anyone to take the pull request anyway). I'd like to gauge interest in what we did so we can determine if we should restart that effort. We added the ability to generate OpenCL 1.1 kernels which have the same processing steps as the CPU path and therefore produce very similar results (within numerical and math function accuracy). Benchmarked across a set of sample transformations it is, on average, 100x faster than the CPU path (ranging from 19x to 636x for the two dozen ACES transformations tested). However, our implementation is only beneficial to those using OpenCL, which is why I'm asking about interest. Notably, the technique we created could be for an accurate OpenGL path by someone needing OpenGL shaders instead of OpenCL kernels, and is only slightly more complicated for the caller than the existing GPU path, so even if you're not using OpenCL but are interested in an accurate OpenGL path, it would be a good starting point.

///d@
Dennis Adams
Sony Creative Software

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

741 - 760 of 2233