|
Re: Problems using OCIO with QT and QtOpenGLWidget
Thanks Patrick,
you are right, the result of the log is black because the values are negative, it works correclty.. stupid me. So it has something to do with the lookup table. Is there any way to check the content of the 3d texture in opengl? I tried it with this fragement shader:
varying vec2 vTexCoord;
uniform sampler2D tex1;
uniform sampler3D tex2;
void main() {
vec3 t = vec3(vTexCoord, 0.0);
gl_FragColor = abs(texture3D(tex2, t));
}
to get part of the content of the 3d texture. Even if the content does not make any sense, I should see something if the content is not 0.0, is this correct? So if I see nothing, the 3d texture is black.
|
|
|
Re: Problems using OCIO with QT and QtOpenGLWidget
Patrick Hodoul
Hi, As a first investigation step, did you try using `ociodisplay` directly (i.e. as-is):
- `set OCIO=C:/daten/coding/imgview/imgView/AE_OCIO/config.ocio`
- `ociodisplay.exe -v c:/daten/testBilder/bake.jpg` where `-v` displays extra information
- Select the same color space
The fragment shader code is perfectly fine (MatrixOp + LogOp + Lut3DOp), and it compiles so I can only think of something related to the OpenGL setup and/or Input texture definition. Regards, Patrick
|
|
|
Re: Problems using OCIO with QT and QtOpenGLWidget
Found a possible reason for the black image. In the fragment shader code generated by ocio which look like this:
vec4 OCIODisplayA(vec4 inPixel, sampler3D lut3d){
vec4 out_pixel = inPixel;
out_pixel.rgb = max(vec3(1.17549e-38, 1.17549e-38, 1.17549e-38), vec3(1, 1, 1) * out_pixel.rgb + vec3(0, 0, 0));
out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
out_pixel = vec4(0.047619, 0.047619, 0.047619, 1) * out_pixel;
out_pixel = vec4(0.714286, 0.714286, 0.714286, 0) + out_pixel;
out_pixel.rgb = texture3D(lut3d, 0.96875 * out_pixel.rgb + 0.015625).rgb;
return out_pixel;
}
The line line
out_pixel.rgb = vec3(1.4427, 1.4427, 1.4427) * log(out_pixel.rgb) + vec3(0, 0, 0);
results in a black color what means log(out_pixel.rgb) is zero. Any ideas why this is the case?
|
|
|
Problems using OCIO with QT and QtOpenGLWidget
Hi,
I try to make a simple imageviewer with the help of QT and ocio. From the ociodisplay.cpp I tried to extract the needed pieces and transfer it to a Qt workflow. Displaying pictures with OpenGl seems to work fine. But since the Qt-Opengl workflow is a little bit different, I suppose I make some mistakes because as soon as I try to use the ocio fragment shader, the image becomes black. If someone could give me a hint I'd really appreciate it.
The cpp code of an example and the whole question can be found here.
https://stackoverflow.com/questions/58857698/qtopenglwidget-with-opencolorio-gpu-results-in-black-image
|
|
|
Re: pyOCIO Windows compilation error against Python36
That's great news, thank you !
|
|
|
Re: pyOCIO Windows compilation error against Python36
I'm currently writing new Python bindings for OCIO (with pybind11, targeting the 2.0 release), which will support Python 3 (and 2). Stills a ways to go, but it's in the works.
Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.
|
|
|
Re: pyOCIO Windows compilation error against Python36
Sorry for re-opening this so late. I did test the fix I thought work among other few things but I can't get OCIO to work with Python 3+ on Windows.
I tested with both OCIO 1.1 and OCIO 2.0 (master branch) and I can't compile against Python3. Any news on when this will be supported ?
Thank you.
|
|
|
Cancelled Event: OpenColorIO TSC meeting (weekly) - Monday, 14 October 2019
#cal-cancelled
ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
Cancelled: OpenColorIO TSC meeting (weekly)
This event has been cancelled.
When:
Monday, 14 October 2019
9:30am to 10:00am
(UTC-07:00) America/Los Angeles
Where:
https://zoom.us/j/924729729
Organizer: Michael Dolan
michdolan@...
Description:
Weekly meeting of the OpenColorIO TSC.
Add topics to the meeting agenda.
Meeting notes listed by YYYY-MM-DD.md format at:
https://github.com/imageworks/OpenColorIO/tree/master/docs/tsc/meetings
Join Zoom Meetinghttps://zoom.us/j/924729729One tap mobile+16699006833,,924729729# US (San Jose)+16465588656,,924729729# US (New York)Dial by your location +1 669 900 6833 US (San Jose) +1 646 558 8656 US (New York) +1 877 369 0926 US Toll-free +1 855 880 1246 US Toll-freeMeeting ID: 924 729 729Find your local number: https://zoom.us/u/abo9cwSMxj
|
|
|
Re: Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO
Thanks for the update Michael,
That all makes sense. I saw that assignment bug and got worried that cut wasn't something I should really consider. Looking forward to 2.x.
Cheers,
- James
|
|
|
Re: Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO
Hi James,
OCIO 1.1.1 should compile if you tell your compiler to not treat warnings as errors, or pass a flag to ignore that particular warning.
That warning was resolved in master a while back, but was only fixed recently (after 1.1.1) in RB-1.1, which represents the 1.x source. Master is the OCIO 2.x dev branch. We will be making a 1.1.2 release later this year with that and some other fixes. You can test it now by building from RB-1.1.
If this doesn't solve the problem, you can file an issue in GitHub. These new warnings popping up are mostly due to newer compiler versions that were not included in OCIO CI until recently. I fixed this exact issue in RB-1.1 a few weeks ago when Travis-CI bumped their Ubuntu version.
Thanks! Michael
On Wed, Oct 9, 2019, 9:19 PM , < jrb@...> wrote: Hi,
I was trying to pick a more modern version of OCIO than the one I've been using (1.0.9) so I started at the latest at the old download location https://opencolorio.org/downloads.html with v1.1.1. Unfortunately, that didn't compile because of a typo in Config.cpp in the operator= method that tries assign to itself. So then I wondered if that had been fixed in github (yes) and then wondered if any of the tags there were newer than the fix, no. What's odd is the fix to that typo was back in 2018 but the old website says v1.1.1 was from March 2019. A little confused at that point so I thought I'd ask here:
What I really want to know is, when is the next (stable-ish) version of OCIO expected to be cut? Or has it been and I'm just too dumb to understand the branches/tags in github?
Cheers,
- James
|
|
|
Expected release of OCIO from its new home in AcademySoftwareFoundation/OpenColorIO
Hi, I was trying to pick a more modern version of OCIO than the one I've been using (1.0.9) so I started at the latest at the old download location https://opencolorio.org/downloads.html with v1.1.1. Unfortunately, that didn't compile because of a typo in Config.cpp in the operator= method that tries assign to itself. So then I wondered if that had been fixed in github (yes) and then wondered if any of the tags there were newer than the fix, no. What's odd is the fix to that typo was back in 2018 but the old website says v1.1.1 was from March 2019. A little confused at that point so I thought I'd ask here: What I really want to know is, when is the next (stable-ish) version of OCIO expected to be cut? Or has it been and I'm just too dumb to understand the branches/tags in github? Cheers, - James
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Sean, thank you for the detailed and well thought out proposal. I fully support it but agree the versioning plan needs some more discussion.
Given that OCIO v2 has some features that are specifically aimed at benefiting ACES config development, I would anticipate needing separate OCIO v1 and v2 versions of the config during the transition period. So I do agree that there are
three versions to work into the release naming: ACES version, OCIO version, and Config version.
Any ideas for how to work the OCIO version into the branch naming and repo directory structure naming?
Doug
From: Sean Cooper <sean@...>
Date: Tuesday, October 1, 2019 at 7:47 PM
To: Thomas Mansencal <thomas.mansencal@...>
Cc: Michael Dolan <mdolan@...>, "ocio-dev@..." <ocio-dev@...>, Scott Dyer <sdyer@...>, Mark Boorer <markboo99@...>, Doug Walker <Doug.Walker@...>, Haarm-Pieter Duiker <hpd@...>, Kevin
Wheatley <kevin.j.wheatley@...>, Carl Rand <carl.rand@...>, Larry Gritz <lg@...>, Patrick Hodoul <Patrick.Hodoul@...>, Alex Forsythe <aforsythe@...>, John Mertic <jmertic@...>
Subject: Re: [ocio-dev] ACES OpenColorIO-Configs (and other stories)
The descriptions and release notes definitely needed some love, but since it was just a draft proposal I didn't put that effort in. I also think the release names could be better as "ACES-v1.1.0_Config-v1", which is as clear as it can be
(I think).
"ACES-v1.1.0_OCIO-v1.1_Config-v1" starts to get painful, but it is the reality of the versioning-magedon.
I still think maintaining the releases for all configs that were once in the master branch is useful for now, instead of them just disappearing to the annals of git history. If a user can't figure out the releases from email announcements,
in-line descriptions, and links from ACESCentral and the OpenColorIO website... then we're all just a stones throw away.
Keeping in mind my overall intention is to make all of this disappear with a better system.
toggle quoted message
Show quoted text
On Tue, Oct 1, 2019 at 11:58 PM Thomas Mansencal < thomas.mansencal@...> wrote:
Maybe we keep the tags as they are but create smaller amount of explicit releases with good descriptions of what they are? Users will most likely look for releases anyway.
On Wed, 2 Oct 2019, 11:11 Sean Cooper, <sean@...> wrote:
The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only track versions of the repository as a whole.
Its an open question.
Its unfortunate that the OpenColorIO-Configs and ACES version are both v1.1 at the moment.
The general logic of my fork is:
vX.X are OpenColorIO-Config version numbers
ACES-X.X.X_Y.Y.Y are the <ACES>_<OCIO-Config> versions.
-
ACES-1.1.0_Config-1.0
-
ACES 1.1.0 OpenColorIO-Config v1.0
@Sean: I'm not saying we should remove them, but just clean up the stack:
e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?
On Wed, 2 Oct 2019 at 07:04, Michael Dolan <mdolan@...> wrote:
The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't
as relevant these days, the educational value is high enough to keep them around IMO.
On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper <sean@...> wrote:
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI
Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users
to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
-
Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
-
Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
-
I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
-
minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi,
Crossing fingers for things to move forward! I cannot say we have not tried :)
A few comments:
I.1: As mentioned in
https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that.
I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions?
II.2: Agreed!
II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic.
III.1: Sounds good too, I'm assuming that the AMPAS drives it?
III.2: Yes!
I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper <sean@...> wrote:
Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today:
-
Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
-
The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
-
There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
-
Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
-
The OpenColorIO-Configs repo size has become a burden to work with
-
The ACES OCIO Configs should be assigned a license
-
The ACES 1.1 config should be merged to Master as-is
-
Updates pushed and versioned as-per the next bullet
-
I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
-
All old ACES configs are removed from master
-
Dedicated ACES configs branches and tags will be created
-
The dedicated ACES config tags will have a secondary version number
-
All users of the configs should be pointed to the Release zips
-
An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
-
A new-breed config repository should be crafted to move under the ASWF
-
Clear license inherited from ASWF
-
All Configs and LUTs must be generated by CI as artefacts
-
Repo structure and artefacts must account for:
-
External Versioning (e.g. ACES)
-
Internal Versioning (e.g. naming changes)
-
OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing
OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
--
Michael Dolan
Color Scientist
Sony Pictures Imageworks
p. (604)673-3886
e. mdolan@...
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Sean Cooper
The descriptions and release notes definitely needed some love, but since it was just a draft proposal I didn't put that effort in. I also think the release names could be better as "ACES-v1.1.0_Config-v1", which is as clear as it can be (I think).
"ACES-v1.1.0_OCIO-v1.1_Config-v1" starts to get painful, but it is the reality of the versioning-magedon.
I still think maintaining the releases for all configs that were once in the master branch is useful for now, instead of them just disappearing to the annals of git history. If a user can't figure out the releases from email announcements, in-line descriptions, and links from ACESCentral and the OpenColorIO website... then we're all just a stones throw away.
Keeping in mind my overall intention is to make all of this disappear with a better system.
Maybe we keep the tags as they are but create smaller amount of explicit releases with good descriptions of what they are? Users will most likely look for releases anyway. On Wed, 2 Oct 2019, 11:11 Sean Cooper, < sean@...> wrote: The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only track versions of the repository as a whole. Its an open question.
Its unfortunate that the OpenColorIO-Configs and ACES version are both v1.1 at the moment.
The general logic of my fork is: vX.X are OpenColorIO-Config version numbers
ACES-X.X.X_Y.Y.Y are the <ACES>_<OCIO-Config> versions.
Other options could be:
- ACES-1.1.0_Config-1.0
- ACES 1.1.0 OpenColorIO-Config v1.0
@Sean: I'm not saying we should remove them, but just clean up the stack: e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?
On Wed, 2 Oct 2019 at 07:04, Michael Dolan < mdolan@...> wrote: The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't as relevant these days, the educational value is high enough to keep them around IMO.
On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper < sean@...> wrote: @Deke
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
@Thomas
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
--
Michael Dolan Color Scientist
Sony Pictures Imageworks
p. (604)673-3886 e. mdolan@...
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Maybe we keep the tags as they are but create smaller amount of explicit releases with good descriptions of what they are? Users will most likely look for releases anyway.
On Wed, 2 Oct 2019, 11:11 Sean Cooper, < sean@...> wrote: The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only track versions of the repository as a whole. Its an open question.
Its unfortunate that the OpenColorIO-Configs and ACES version are both v1.1 at the moment.
The general logic of my fork is: vX.X are OpenColorIO-Config version numbers
ACES-X.X.X_Y.Y.Y are the <ACES>_<OCIO-Config> versions.
Other options could be:
- ACES-1.1.0_Config-1.0
- ACES 1.1.0 OpenColorIO-Config v1.0
@Sean: I'm not saying we should remove them, but just clean up the stack: e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?
On Wed, 2 Oct 2019 at 07:04, Michael Dolan < mdolan@...> wrote: The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't as relevant these days, the educational value is high enough to keep them around IMO.
On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper < sean@...> wrote: @Deke
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
@Thomas
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
--
Michael Dolan Color Scientist
Sony Pictures Imageworks
p. (604)673-3886 e. mdolan@...
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Sean Cooper
The dual version numbers is pretty gross, but I'm not sure how else you can have two independent versions tracked. Unless we just don't care about having independent ACES Config releases, and only track versions of the repository as a whole. Its an open question.
Its unfortunate that the OpenColorIO-Configs and ACES version are both v1.1 at the moment.
The general logic of my fork is: vX.X are OpenColorIO-Config version numbers
ACES-X.X.X_Y.Y.Y are the <ACES>_<OCIO-Config> versions.
Other options could be:
- ACES-1.1.0_Config-1.0
- ACES 1.1.0 OpenColorIO-Config v1.0
@Sean: I'm not saying we should remove them, but just clean up the stack: e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?
On Wed, 2 Oct 2019 at 07:04, Michael Dolan < mdolan@...> wrote: The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't as relevant these days, the educational value is high enough to keep them around IMO.
On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper < sean@...> wrote: @Deke
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
@Thomas
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
--
Michael Dolan Color Scientist
Sony Pictures Imageworks
p. (604)673-3886 e. mdolan@...
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
@Sean: I'm not saying we should remove them, but just clean up the stack: e.g. which one do I take for ACES 1.1? v1.1 or ACES-1.1.0_v1.0.0?
On Wed, 2 Oct 2019 at 07:04, Michael Dolan < mdolan@...> wrote: The sony and nuke configs (with accompanying Python code) are also great as really simple examples of building a custom config. The aces config code is much more daunting to someone new to OCIO, so while these older configs themselves aren't as relevant these days, the educational value is high enough to keep them around IMO.
On Tue, Oct 1, 2019 at 7:57 AM Sean Cooper < sean@...> wrote: @Deke
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
@Thomas
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
--
Michael Dolan Color Scientist
Sony Pictures Imageworks
p. (604)673-3886 e. mdolan@...
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Sean Cooper
@Deke
The Sony configs are heavily referenced in the present documentation (the only place where real OCIO usage is described) so until a new user-story is put forth they should remain accessible.
I'd wait to hear from The Foundry reps on whether the nuke-default should exist there or not. If it's still useful I don't think it's causing harm.
The onus is certainly on OCIO v2 Docs to learn from OCIO v1 and provide clear and obvious modern use cases and implementation references.
@Thomas
I don't think the tags/releases would pollute the ecosystem too much and provided a very simple link-able way for end-users to avoid ever touching git, which was my intent.
Doing this also drops the download size quite a bit because you aren't pulling down all of time when you download the zip, or even git clone from master.
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Hi Deke,
To be fair, at this stage, I don't think it hurts to leave them as they are.
To some extent, the SPI Gospel is what tipped the balance on my end to improve the shaper, if people did not do comparisons with it recently, maybe I would not have done it :]
I had the same quibble about the version number on the folder. I said to myself that while not super elegant, it was no big deal and would actually help non-techie users to know exactly which config they get. I must admit it is itching a bit :)
Cheers,
Thomas
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Deke Kincaid
Comments on II #3 - Why even include the nuke-default? Those are the configs from Nuke 6.3 when OCIO was first implemented in Nuke 7-8 years ago, wildly out of date compared to what ships with the software.
- Same with both Sony examples, also wildly out of date compared to what is used internally at Sony (unless they contribute new ones as examples).
- I have seen many people use the Sony configs as gospel when they should perhaps be looking at the ACES config instead as an example.
- minor quibble: Why include the ACES version number in the folder name, this should be representative of the tag, not the folder name.
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
|
|
|
Re: ACES OpenColorIO-Configs (and other stories)
Hi, Crossing fingers for things to move forward! I cannot say we have not tried :) A few comments: I.1: As mentioned in https://github.com/imageworks/OpenColorIO-Configs/pull/17, I'm fine with whatever license is chosen, and HP said that his work was done under the Academy Umbrella thus the Academy license should apply, so there should not be a problem fixing that. I.3: Are you referring to the 2.2, 1.8 and Venice recent discussions? II.2: Agreed! II.3: Sounds good! Although we should drop some tags/releases, it is excessively confusing currently and because Github cannot render the diffs it makes the experience a bit traumatic. III.1: Sounds good too, I'm assuming that the AMPAS drives it? III.2: Yes! I would need to think about the minute details but seems like a good plan to me, I like it :)
On Tue, 1 Oct 2019 at 14:21, Sean Cooper < sean@...> wrote: Hello,
I know this is coming from a long and storied past but we (the OCIO TSC), high on the spirits of migrating our repo to the ASWF, would like to once and for all come to a resolution on the OCIO + ACES dilemma.
There are a number of issues that are rolled under this banner and by no means can they be (or should they be) resolved in this email thread, but I will do my best to lay them out as they are...
As the world exists today: - Due to HP's and Thomas's contributions to the OpenColorIO-Configs repo not being licensed, they are unable to be carried over to the ASWF as-is
- The ACES 1.1 OCIO configs, due to various factors, have yet to be merged into the SPI OpenColorIO-Configs repo and yet, are already seeing active use
- There will likely be multiple versions of the ACES 1.1 OCIO config in existence due to continued discussion about what should be included and the names they are given
- Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
- The OpenColorIO-Configs repo size has become a burden to work with
A step towards tomorrow: - The ACES OCIO Configs should be assigned a license
- The ACES 1.1 config should be merged to Master as-is
- Updates pushed and versioned as-per the next bullet
- I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
- All old ACES configs are removed from master
- Dedicated ACES configs branches and tags will be created
- The dedicated ACES config tags will have a secondary version number
- All users of the configs should be pointed to the Release zips
A path to the future: - An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
- A new-breed config repository should be crafted to move under the ASWF
- Clear license inherited from ASWF
- All Configs and LUTs must be generated by CI as artefacts
- Repo structure and artefacts must account for:
- External Versioning (e.g. ACES)
- Internal Versioning (e.g. naming changes)
- OCIO Versioning (e.g. utilising v2.x features)
As a general summary I personally don't think the OpenColorIO-Configs repo, as it exists today, should be merged to the ASWF at all. Instead, we really do need to build a fresh slate and a new way of thinking about creating and distributing OCIO Configs (both ACES and non-ACES). This should happen as a new wave of development.
I think its quite clear the present Imageworks Configs repo and its configs should (and will) continue to be supported while future development happens.
Please let me know your thoughts, and please start a new thread if your topic of discussion warrants in-depth conversation (such as the ACES Working Group). Or please continue the conversation on the relevant GitHub PR:
|
|
|
