|
Nathan Rusch <natha...@...>
Hello all, This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide. Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files. Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse. At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code. Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging. Thanks, -Nathan
|
|
|
I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)
If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place
(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")
> Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code
If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:
- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice) - we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue - a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue
On 7 September 2016 at 19:21, Nathan Rusch <natha...@...> wrote: Hello all, This is mostly directed at those currently leading the OpenColorIO project, but I would be happy for any input or information anyone else can provide. Most of you are likely aware of the outstanding issue that causes pretty severe banding and other visual differences in images processed using OCIO's GPU code path (documented here). This issue effectively prevents OCIO from being used in a GPU-dependent application like RV without resorting to workarounds like intermediate baking of temporary LUT files. Because the Github repository has remained unchanged for two years now, and (more surprisingly) no one else seems to be asking about this issue in any public forums, I wanted to try and get some general information on the state of OpenColorIO development. This general question has been asked before (see this thread from November of last year), and there was mention of a large amount of new code that was about to be released, but that has yet to materialize. I don't know if there are other communication channels I'm not privy to, but to put it bluntly, the project seems to have lost its pulse. At this point, we are seriously considering trying to fix the GPU code ourselves to make OCIO a viable part of RV. However, that post specifically mentioned that the forthcoming updates would tackle "differences between the GPU and CPU code-paths" (among other things), so if we decide to dive into that rabbit hole, I'm wondering if there would be any way we could get our hands on whatever progress has been made and get a better idea of the state of things first. Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code. Anyway, I don't mean to come across as too doom-and-gloom, but I would appreciate any information anyone is willing to share, even if it's not very encouraging. Thanks, -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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
|
|
|
Deke Kincaid <dekek...@...>
Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs). It's still not as good as tetrahedral interpolation but it is close enough for gpu playback. Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.A Retrospective on the Adoption of the ACES Technology at Framestore
toggle quoted message
Show quoted text
On Wednesday, September 7, 2016, DBR - Ben < dbr....@...> wrote: I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)
If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place
(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")
> Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code
If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:
- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice) - we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue - a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue
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.
|
|
|
Dithermaster <dither...@...>
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
On Wed, Sep 7, 2016 at 11:02 AM, Deke Kincaid <dekek...@...> wrote: Without tetrahedral interpolation you can get better results by creating 65x cubes instead of the default of 32x that the example OCIO configs use (very easy to create with Hp's python script included with the ACES configs). It's still not as good as tetrahedral interpolation but it is close enough for gpu playback. Kevin Wheatley had some good slides & charts on this from his ACES presentation at Digipro if you have an ACM account.
A Retrospective on the Adoption of the ACES Technology at Framestore http://dl.acm.org/citation.cfm?id=2947695
-deke
On Wednesday, September 7, 2016, DBR - Ben <dbr....@...> wrote: I have no insight into the activity of the project - but from the outside the project does appears rather dead (no commits to the repo since Sep 2014, tickets piling up with little response, even simple pull requests unacknowledged)
If there is development happening, that is good.. but as one of the previously more active contributors to the project, it would sadden me the project has moved away from the "open-development" approach which encouraged me to contribute in the first place
(there was a nice part in one of the slides of an early OCIO presentation - http://www.tdforum.eu/pdf/2011ntfd_ocio_selan.pdf - "We really do our development in public/We’ve made some embarrassing mistakes/Integrity, not fear/Airing dirty laundry breeds trust amongst community")
> Like I mentioned, I'm genuinely surprised that there aren't more people making noise about this, so at this point I have to assume that A) not enough people are aware of the problem, B) they don't consider it a serious issue, or C) they're not using RV or anything else that relies on OCIO's GPU code
If the problem is as I suspect (mentioned in linked ticket #394 - there is no tetrahedral interpolation in GPU code path) - I suspect the the reasons people seem so quiet about the issue are numerous.. In addition to the options you describe, also:
- I would imagine some footage is more prone than others to highlighting the issue (so depending on the project and how the footage is processed, people might just not notice) - we heavily rely on RV's GPU path without encountering this issue, using a config based of the ACES 1.0.1 config, but with a custom simpler viewing transform which presumably avoids this issue - a common theme in that ticket comment was people found a workaround (like baking out intermediate LUT's), which lessens the need to "make noise" about the issue
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.
|
|
|
Nathan Rusch <natha...@...>
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
|
|
|
Troy Sobotka <troy.s...@...>
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.
|
|
|
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
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.
|
|
|
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.
|
|
|
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
|
|
|
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
|
|
|
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?
-NathanOn 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
|
|
|
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?
--
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.
|
|
|
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?
--
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.
|
|
|
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?
--
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.
|
|
|
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 :)
|
|
|
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
|
|
|
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
|
|
|
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.
|
|
|
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.
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
|
|
|
+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.
|
|
|
