Date   

Re: Slack access request

Carol Payne
 

Hi Andy, invite sent!

On Tue, May 12, 2020 at 12:22 AM Andy Jones <andy.jones@...> wrote:
Could I get an invite for andy.jones@...?  Thanks!

On Wed, Apr 29, 2020 at 12:30 AM Sean Cooper <sean@...> wrote:
Sent.

Let me know if there are any issues. 

On Wed, 29 Apr 2020, 07:34 Steve Agland, <sagland@...> wrote:
To sagland@... please.


Sent from my phone.



--

CAROL PAYNE

Imaging Specialist

Creative Technologies & Infrastructure

T 505.553.0076

5808 W. Sunset Blvd  |  Los Angeles, CA 90028


Re: Slack access request

Andy Jones
 

Could I get an invite for andy.jones@...?  Thanks!


On Wed, Apr 29, 2020 at 12:30 AM Sean Cooper <sean@...> wrote:
Sent.

Let me know if there are any issues. 

On Wed, 29 Apr 2020, 07:34 Steve Agland, <sagland@...> wrote:
To sagland@... please.


Sent from my phone.


Re: Required Roles

Troy Sobotka <troy.sobotka@...>
 



On Mon, May 11, 2020 at 10:24 PM Doug Walker <doug.walker@...> wrote:

OCIO::ROLE_DEFAULT, OCIO::ROLE_SCENE_LINEAR, OCIO::ROLE_DATA, OCIO::ROLE_REFERENCE, OCIO::ROLE_COMPOSITING_LOG, OCIO::ROLE_COLOR_TIMING, OCIO::ROLE_COLOR_PICKING, OCIO::ROLE_TEXTURE_PAINT, OCIO::ROLE_MATTE_PAINT 

However, once the DisplayTransform refactor is completed (as discussed at the previous working group meeting), none of these will actually be required for the proper operation of the core library.  So the ociocheck is basically only enforcing this for the benefit of various apps/plug-ins that may want to rely on those roles being present.


I am hoping that some bedrock aliases will remain in the event that a configuration is added and reconciliation cannot be made in a DCC.

Without aliases, the whole system would have to revert to hard coded transforms, which is of course ghastly.

Data, working space / scene linear, and a few others are vital in this regard.

With respect,
TJS


Re: Inverting a 3D LUT

Doug Walker
 

> How is this overridden with an environment variable?

 

Check out OCIO_OPTIMIZATION_FLAGS_ENVVAR in OpenColorTypes.h.

 

> If I do getDefaultCPUProcessor(), it's always the same as getOptimizedCPUProcessor(OPTIMIZATION_DEFAULT).

 

Yes, that is expected.  But if that env var was set, both of those would be overridden by the env var.

 

Doug



 


Re: Required Roles

Doug Walker
 

That's a good suggestion Brendan, we will look into adding that.

 

And as Troy wrote, ociocheck does in fact throw an error if the following roles are not present:

 

OCIO::ROLE_DEFAULT, OCIO::ROLE_SCENE_LINEAR, OCIO::ROLE_DATA, OCIO::ROLE_REFERENCE, OCIO::ROLE_COMPOSITING_LOG, OCIO::ROLE_COLOR_TIMING, OCIO::ROLE_COLOR_PICKING, OCIO::ROLE_TEXTURE_PAINT, OCIO::ROLE_MATTE_PAINT

 

However, once the DisplayTransform refactor is completed (as discussed at the previous working group meeting), none of these will actually be required for the proper operation of the core library.  So the ociocheck is basically only enforcing this for the benefit of various apps/plug-ins that may want to rely on those roles being present.

 

Doug

 


Re: Inverting a 3D LUT

Brendan Bolles
 

On Mon, May 11, 2020 at 03:02 PM, Doug Walker wrote:
But note that (as with a number of other OCIO features) it is also possible for users to override the optimization setting via an environment variable.  So even if apps don't provide a UI, that may provide an alternative for power users.
How is this overridden with an environment variable? If I do getDefaultCPUProcessor(), it's always the same as getOptimizedCPUProcessor(OPTIMIZATION_DEFAULT).

Brendan


Re: Required Roles

Brendan Bolles
 

On Mon, May 11, 2020 at 03:36 PM, Doug Walker wrote:
A v2 config must specify a default color space, but this could either be done using the default role or a default file rule.  So if the config does not use file rules, then yes, the default role is required.
Hmmm, what would you guys think about adding a getDefaultColorspace() function to match and getDefaultDisplay() and getDefaultView() functions?

Brendan


Re: Required Roles

Troy Sobotka <troy.sobotka@...>
 

On Mon, May 11, 2020 at 3:36 PM Doug Walker <doug.walker@autodesk.com> wrote:

As Troy wrote, the scene linear role is required by ociocheck, which also verifies that any supplied roles have color spaces that exist. However it does not require any other roles and I don't believe any others are required.
ociocheck and sanity check should abide by the following
pre-established roles I believe:
```
ociocheck --iconfig config.ocio

OpenColorIO Library Version: 1.1.1
OpenColorIO Library VersionHex: 16843008
Loading config.ocio

** General **
Search Path:
Working Dir: /foo/bar

Default Display:
Default View:

** Roles **
ERROR: NOT DEFINED (default)
ERROR: NOT DEFINED (scene_linear)
ERROR: NOT DEFINED (data)
ERROR: NOT DEFINED (reference)
ERROR: NOT DEFINED (compositing_log)
ERROR: NOT DEFINED (color_timing)
ERROR: NOT DEFINED (color_picking)
ERROR: NOT DEFINED (texture_paint)
ERROR: NOT DEFINED (matte_paint)

** ColorSpaces **
Error: scene_linear role must be defined.

** Looks **
no looks defined

** Sanity Check **
ERROR
Config failed sanitycheck. No displays are specified.

11 tests failed.
```

With respect,
TJS


Re: Required Roles

Doug Walker
 

> I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the

> "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?

Brendan, the default role was used used by the v1 feature for extracting  a color space name from an image file path.  If strict parsing was not enabled and no color space name was found, then the default color space is returned.  The default role was also used by some other API calls, such as getIndexForColorSpace (although that is not the case for OCIO v2).

 

Not sure if your question was for OCIO v1 or v2 (that is, master branch).  The documentation you linked to is for v1.  Note that the v2 documentation remains to be written (and we are looking for volunteers to help us with that!).

 

The new File Rules feature in v2 expanded the ability for users to assign color spaces based on file paths.  If you're interested in that topic, please check out PR #904.

 

A v2 config must specify a default color space, but this could either be done using the default role or a default file rule.  So if the config does not use file rules, then yes, the default role is required.

 

As Troy wrote, the scene linear role is required by ociocheck, which also verifies that any supplied roles have color spaces that exist.  However it does not require any other roles and I don't believe any others are required.

 

Doug

 


Re: Inverting a 3D LUT

Doug Walker
 

>I guess there have been some changes in this area. So I take it OPTIMIZATION_LUT_INV_FAST has now taken

> taken the place of not using FINALIZATION_EXACT. And the exact mode is used if you don't include the flag?

Yes, the finalization options were merged into the optimization options since there was so much overlap.

 

And yes, the exact mode is used if that bit of the optimization settings is zero.

 

But just to be clear for others, the default settting (OPTIMIZATION_DEFAULT) does include OPTIMIZATION_LUT_INV_FAST, so the exact mode is actually not the default.  (This was the preference of the group when it was discussed at one of the v2 working group meetings.)


> What sort of UI for this quality stuff are we expecting to present to the user?

> ... should OCIO apps now give a general Draft/Best option for all OCIO operations?

 

It's a good question Brendan.  For now, there is no guidance and it is up to the apps to decide if the feature is useful for their users or not.  In my opinion, OPTIMIZATION_DEFAULT will cover the vast majority of use-cases.  So my view is that the UI for "average users" should not present this as an option as it will likely cause needless worry and confusion.

 

But note that (as with a number of other OCIO features) it is also possible for users to override the optimization setting via an environment variable.  So even if apps don't provide a UI, that may provide an alternative for power users.

 

It might be useful to work on some user interface guidelines that could cover topics like this.  If anyone is interested in helping draft something like that, please reach out to me or another TSC member.

 

Doug

 


Re: Required Roles

Troy Sobotka <troy.sobotka@...>
 

On Mon, May 11, 2020 at 12:12 PM Brendan Bolles <brendan@...> wrote:
I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?


The ociocheck tool and the sanity check API should flag missing default roles.

With respect,
TJS


Required Roles

Brendan Bolles
 

I've been using "default" (aka ROLE_DEFAULT) as my default color spaces, but then looking at the docs, I guess the "default" role isn't required to be in a config. Is "scene_linear" required? Any others? Somehow strictparsing is involved?


Brendan


Re: Inverting a 3D LUT

Brendan Bolles
 

I guess there have been some changes in this area. So I take it OPTIMIZATION_LUT_INV_FAST has now taken taken the place of not using FINALIZATION_EXACT. And the exact mode is used if you don't include the flag?

What sort of UI for this quality stuff are we expecting to present to the user? I see that OPTIMIZATION_DEFAULT = OPTIMIZATION_VERY_GOOD, which includes OPTIMIZATION_LUT_INV_FAST. And there's OPTIMIZATION_LOSSLESS, which does not and has other flags as well.

I currently provide a back door to doing the exact LUT invert, but should OCIO apps now give a general Draft/Best option for all OCIO operations?


Brendan


Upcoming Events #cal-summary

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

OpenColorIO Dev Discussion Upcoming Events

OpenColorIO TSC meeting (weekly)

When:
Monday, 11 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 18 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 25 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 1 June 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 8 June 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


Re: ACES OpenColorIO-Configs (and other stories)

Michael Dolan
 

This issue has been created to further discuss a starting point for the future of OpenColorIO-Configs and the ACES config. 

https://github.com/imageworks/OpenColorIO-Configs/issues/19  

We're getting closer to putting this discussion into action, so any input is appreciated.

On Tue, Oct 1, 2019 at 8:56 PM Doug Walker <doug.walker@...> wrote:

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.

 

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.

 

Other options could be:

  • ACES-1.1.0_Config-1.0
  • ACES 1.1.0 OpenColorIO-Config v1.0

 

 

On Tue, Oct 1, 2019 at 8:28 PM Thomas Mansencal <thomas.mansencal@...> wrote:

@Sean: I'm not saying we should remove them, but just clean up the stack:

Image removed by sender. image.png

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.

 

On Tue, Oct 1, 2019 at 9:20 AM Thomas Mansencal <thomas.mansencal@...> wrote:

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

 

 

On Tue, 1 Oct 2019 at 21:08, Deke Kincaid <dekekincaid@...> wrote:

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.

 

On Tue, Oct 1, 2019 at 12:34 AM Thomas Mansencal <thomas.mansencal@...> wrote:

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:

  1.  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
  2. 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
  3. 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
  4. Ownership of the ACES OCIO configs presently sits outside of both ACES and OCIO (though the contributors are closely involved with both projects)
  5. The OpenColorIO-Configs repo size has become a burden to work with

A step towards tomorrow:

  1. The ACES OCIO Configs should be assigned a license
  2. The ACES 1.1 config should be merged to Master as-is
    1. Updates pushed and versioned as-per the next bullet
  1. I propose a repository structure such as can be found in my fork (https://github.com/scoopxyz/OpenColorIO-Configs)
    1. All old ACES configs are removed from master
    2. Dedicated ACES configs branches and tags will be created
    3. The dedicated ACES config tags will have a secondary version number
    4. All users of the configs should be pointed to the Release zips

A path to the future:

  1. An ACES virtual working group should be formed to outline the clear path of the ACES OCIO configs
  2. A new-breed config repository should be crafted to move under the ASWF
    1. Clear license inherited from ASWF
    2. All Configs and LUTs must be generated by CI as artefacts
    3. Repo structure and artefacts must account for:
      1. External Versioning (e.g. ACES)
      2. Internal Versioning (e.g. naming changes)
      3. 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@...


Upcoming Events #cal-summary

ocio-dev@lists.aswf.io Calendar <ocio-dev@...>
 

OpenColorIO Dev Discussion Upcoming Events

OpenColorIO TSC meeting (weekly)

When:
Monday, 4 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 11 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 18 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 25 May 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


OpenColorIO TSC meeting (weekly)

When:
Monday, 1 June 2020, 9:30am to 10:00am
(GMT-07:00) America/Los Angeles

Where:
https://zoom.us/j/924729729

Organizer: Michael Dolan michdolan@...

Details:
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 Meeting
https://zoom.us/j/924729729

One 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-free
Meeting ID: 924 729 729
Find your local number: https://zoom.us/u/abo9cwSMxj

View Event


Re: Slack access request

Sean Cooper
 

Sent.

Let me know if there are any issues. 

On Wed, 29 Apr 2020, 07:34 Steve Agland, <sagland@...> wrote:
To sagland@... please.


Sent from my phone.


Slack access request

Steve Agland
 

To sagland@... please.


Sent from my phone.


Re: Suggestion to switch from Zoom to an open source alternative for meetings

Rashil Gandhi <rashil2000@...>
 

Oh, if the entire ASWF uses Zoom as a standard, then I guess using it makes sense. Although it might have seemed so, my main reason for the suggestion was to use and promote open source tech. instead of the security issues surrounding Zoom, because it won't make much difference to OCIO as their meetings are already public (however, the user data of the attendees might still be at risk).


Re: Suggestion to switch from Zoom to an open source alternative for meetings

Larry Gritz
 

We're really drafting off the fact that all the ASWF groups (and I assume the rest of the Linux Foundation) use Zoom as their standard for meetings. So really, if this is an important topic, it is one to address at the TAC level or above; there is probably no benefit to each project in the organization trying to go its own way on infrastructure.

I think there is merit to being suspicious of Zoom. They certainly have some embarrassing black marks in their history, as far as security and privacy go. But on the other hand, the eyes of the world are on them now and they have pledged to make that a top priority. We'll see how that goes. But in any case, since the OCIO and other TSC meetings are public by design, I think the worst of the privacy/security concerns mostly don't apply to us.

-- lg


On Apr 24, 2020, at 1:18 AM, Rashil Gandhi via lists.aswf.io <rashil2000=iitkgp.ac.in@...> wrote:

[Edited Message Follows]
[Reason: While both Jitsi and Wire are open source, Wire is a paid service whereas Jitsi is completely free for use. ]

Hi all, 
This is my first message on the list here, so if I get something wrong, I apologize for that. 

The title explains it all though. Zoom has come under a lot of scrutiny lately. Letting unwanted users to join in, exposing file access to remote users, selling user data on the dark web are just some of the allegations that have been made against it. Also, the web client offers limited functionality and support, forcing users to download the app. 

I suggest using free and open source alternatives to Zoom. I have two of them in mind, namely Jitsi and Wire. The source code for these can be viewed on GitHub by anyone, and their web clients are fully featured. It also fits in the overall philosophy of ASWF and OpenColorIO to help develop and promote open source technologies. 

Regards, 
Rashil

--
Larry Gritz




201 - 220 of 2154