Date   

Re: blackbody and daylight functions

Larry Gritz
 

The "sky color by temperature" function is just a model that sort of relates color temperature to a plausible overall color of the sky integrated over all directions. In a rendering context, I'm not sure how or why you would use this. You certainly wouldn't want the sky to be this color, because it would be the same in all directions. What you really want is the correct directional radiance function.

Hosek/Wilkie "An Analytic Model for Full Spectral Sky-Dome Radiance" from SIGGRAPH 2012 is usually the go-to on this topic. That paper, and some other work from the same researchers, can be found here: https://cgg.mff.cuni.cz/projects/SkylightModelling/  I think most studios have an in-house shader that implements this paper or some fairly close variant. I believe there are open source implementations in various shading language already out there to be found with a little googling.

The state of the art is likely this year's EGSR 2020 paper from Sebastien Hillaire, "A Scalable and Production Ready Sky and Atmosphere Rendering Technique," which describes what's implemented in Unreal Engine. Here's the paper: https://diglib.eg.org/bitstream/handle/10.1111/cgf14050/v39i4pp013-022.pdf and here's the code (MIT licensed): https://github.com/sebh/UnrealEngineSkyAtmosphere

-- lg



On Jan 11, 2021, at 5:40 AM, chrisbrejon@... wrote:

And just for the record, it looks like there is a CIE standard for sky values :

This web app generates sky luminance and radiance distributions using the updated Perez All-Weather Sky model, as defined in ISO 15469:2004(E) and CIE S 011/E:2003. You can dynamically adjust each of the Perez sky coefficients individually, choose any of the 16 CIE Standard General Skies, set your own direct and diffuse illuminance/irradiance values, or use annual hourly weather data for dynamic simulations or cumulative sky distributions. It also provides a range of different sky subdivision techniques and resolutions, including Tregenza’s 145 patch sky and Reinhart’s extensions.

The Commission Internationale de l’Éclairage (CIE) has defined a set of 15 standard sky types for modelling the radiance/luminance distribution under a wide range of weather conditions from overcast to cloudless, and with or without direct sunlight. The 16th varient corresponds to a much simpler mathematical model for overcast skies defined and used by CIE prior to this standard.

The various sky types are generated using different values for each of the 5 sky coefficients shown in the panel above.

Quite cool !  ;-)

--
Larry Gritz





Re: blackbody and daylight functions

chrisbrejon@...
 

And just for the record, it looks like there is a CIE standard for sky values :

This web app generates sky luminance and radiance distributions using the updated Perez All-Weather Sky model, as defined in ISO 15469:2004(E) and CIE S 011/E:2003. You can dynamically adjust each of the Perez sky coefficients individually, choose any of the 16 CIE Standard General Skies, set your own direct and diffuse illuminance/irradiance values, or use annual hourly weather data for dynamic simulations or cumulative sky distributions. It also provides a range of different sky subdivision techniques and resolutions, including Tregenza’s 145 patch sky and Reinhart’s extensions.

The Commission Internationale de l’Éclairage (CIE) has defined a set of 15 standard sky types for modelling the radiance/luminance distribution under a wide range of weather conditions from overcast to cloudless, and with or without direct sunlight. The 16th varient corresponds to a much simpler mathematical model for overcast skies defined and used by CIE prior to this standard.

The various sky types are generated using different values for each of the 5 sky coefficients shown in the panel above.

Quite cool !  ;-)


Re: blackbody and daylight functions

chrisbrejon@...
 

Thanks Brecht for the answer.
We did pay a lot of attention to colorspace conversions and we did compare to several render engines.
We do have a match with renderman, guerilla and arnold. I don't think it is an implementation issue, but rather using a dataset that is not the right fit.

When I say red/purple, obvisouly I mean a blue color with too much red component. And this is where it gets tricky, right ? It can be very subjective to compare these colors.

From all the tests I have made, I never get a blue sky color (to my eyes) when I use 15000 to 27000 kelvin blackbody temperature.
And I believe it just comes from the fact that blackbody temperatures are the wrong dataset for that.

Chris


Re: blackbody and daylight functions

Brecht Van Lommel
 

From what I understand, high blackbody temperatures giving similar colors to a blue sky is coincidental.

Still, I think that with correct color space conversions and a neutral view transform the result should look blue rather than red/purple. And I do get blue with OSL blackbody() in Blender/Cycles. So I suspect a color space conversion issue.


On Mon, Jan 11, 2021 at 1:28 PM <chrisbrejon@...> wrote:
Hi everyone,
thanks a lot for your answers ! They are definitely helpful.

I was not speaking specifically about skylight here even if topics are definitely connected. ;-)
I have been looking at some papers myself for the past few months and there are indeed different approaches/datasets :

wiki_sky_comparison_02
Sebastien Hilaire has done a great presentation, comparing different approaches (with LUTs, without...).
So we could say that skylights are indeed a complex topic which include many factors/parameters.

In my original question, I was actually more talking about light's temperatures, like an area light.
If we look at Arnold, Guerilla or Renderman,you may find in the lights some temperature options.
If we look at the Renderman documentation :


We can read that at 15000 to 27000 kelvin temperature would be a clear blue poleward sky. Except that it looks very red/purple...
I wish there would be a mention : blackbody values are not recommended for temperatures above 5500 for example. But if there is
no general agreement/consensus on a daylight data set, that would indeed make things hard to implement. ;-)

I don't know if any of this makes sense,
Chris


Re: blackbody and daylight functions

chrisbrejon@...
 

Hi everyone,
thanks a lot for your answers ! They are definitely helpful.

I was not speaking specifically about skylight here even if topics are definitely connected. ;-)
I have been looking at some papers myself for the past few months and there are indeed different approaches/datasets :

wiki_sky_comparison_02
Sebastien Hilaire has done a great presentation, comparing different approaches (with LUTs, without...).
So we could say that skylights are indeed a complex topic which include many factors/parameters.

In my original question, I was actually more talking about light's temperatures, like an area light.
If we look at Arnold, Guerilla or Renderman,you may find in the lights some temperature options.
If we look at the Renderman documentation :


We can read that at 15000 to 27000 kelvin temperature would be a clear blue poleward sky. Except that it looks very red/purple...
I wish there would be a mention : blackbody values are not recommended for temperatures above 5500 for example. But if there is
no general agreement/consensus on a daylight data set, that would indeed make things hard to implement. ;-)

I don't know if any of this makes sense,
Chris


Re: blackbody and daylight functions

Brecht Van Lommel
 

I think there is something that needs to be improved in OSL regarding blackbody() and color spaces. However I'm not sure how you'd use blackbody() (or D65) to compute a blue sky color, so it may be unrelated to this specific question.

The renderer needs to set a rendering color space, to define the XYZ to RGB transform for blackbody(). However only fixed set of color space are supported. There is no ACEScg for example, so if a renderer uses that the colors would be off.

A solution could be to support setting an arbitrary 3x3 XYZ to RGB matrix instead. At least that matrix is what I already have available in my renderer, and I wouldn't mind implementing this.


On Sat, Jan 9, 2021 at 1:32 PM <chrisbrejon@...> wrote:
Hi everyone,

first time posting here. First of all, best wishes for 2021. ;-)
I am a lighting lead at illumination mac guff and our developers are currently implementing OSL
in our proprietary render engine, which is awesome. ;-)

I had a question about the blackbody function if that's okay with you. I have recently been explained that
for higher temperatures we might want daylight and not black body values.Think of it as being the delta between
a pure black body and the fact that in reality we have the sun + atmosphere filtering the light.
so for Displays we tend to match the daylight locus and most colour spaces are daylight whitepoints.

I found this information (shared by Kevin Wheatley) quite fascinating because we have been investigating
blackbody values for the past months and we did notice that something felt "off" for high values (like blue sky).
If you're interesting, here is an article on the topic and the definition by the CIE.

So my question would be if there is any interest to implement a daylight function into OSL ?
A bit like what you did with the blackbody_rgb function and the BB_TABLE.

As you can tell, I am no developer so I apologize for any noob question or misconception I'd have. ;-)
Regards,
Chris


Re: OSL Docs

Larry Gritz
 

This is great, I'm thrilled to see you moving forward on these.

Note that we already have "contributing" and "install" documents in the current repo, and it's fine to just directly propose changes there. But if you are just intending osl-doc to be a staging area, someplace where you can temporarily start fresh without any distraction by or temptation to keep the existing docs, then that's fine, and when you feel they're ready, they can be moved back.

In the long run, any docs that are tightly coupled to a particular OSL version (API docs and installation docs, for example) probably belong in the main repo, as having them in a separate project just invites confusion or errors that result from somebody not having exactly the right corresponding versions of the two projects. The argument may be stronger for larger and not-tied-to-specific-versions documentation projects to be separate from the main code repo (the web site, or an extensive OSL shading tutorial might be good examples). These are all things where we can defer until farther down the road discussion of the merits of exactly where they should permanently live.

If you need a staging area, or eventually even a permanent second repository for things that should not be part of the main code repo, it is not necessary for you to do it in your own personal account. We can create secondary/scratch repos under AcademySoftwareFoundation, and there's no reason (especially for new material) to wait until we move the main repo from imageworks to ASWF (which will happen, hopefully, in the next few weeks anyway). Just give the word, and we can make you a new repo.

I also just gave you write permissions on the current repo (the imageworks one), so if you need to, you should feel free to make separate branches where you can work on in-tree docs (and even accept PRs into those branches only) without polluting master quite yet.

Any secondary repository should be populated with the OSL license files and notices (BSD 3-clause for code, Creative Commons CC BY 4.0 for docs) at the very least. You don't want to get to the point where you've collected contributions from a bunch of people, and then when it's time to re-integrate it into the main project, we can't do it because it's not legally clear what licenses it's covered by and you might need to track down every last person who contributed any bit and get their explicit ok to relicense it. Huge PITA.

-- lg


On Jan 8, 2021, at 1:50 PM, Mitch Prater <mprater@...> wrote:

Hi All,

I've created a temporary github project/repo for collecting any OSL documentation we're working on: https://github.com/mprater/osl-doc

I've never managed an on-line or collaborative documentation project before, so this is the best I could come up with. If there's a better way to go about this please let me know. I've initialized the repository with the work we've already done.

Please consider contributing useful information you may have.

Thanks, mitch

--
Larry Gritz





Re: blackbody and daylight functions

Mitch Prater
 

Aha - here's the one I was thinking of: https://www2.cs.duke.edu/courses/cps124/spring08/assign/07_papers/p91-preetham.pdf
There's also a similar night sky paper: http://graphics.stanford.edu/~henrik/papers/nightsky/nightsky.pdf

A quick search also turned up this: https://www.researchgate.net/publication/265111517_REAL-TIME_DAYLIGHT_SKY_COLOR_MODELING


Re: blackbody and daylight functions

Larry Gritz
 

We are always interested in PRs that propose and implement new standard OSL functions that are broadly helpful to shader writers. Shy of making an "official" standard library function, we can also simply include sample shader code with the OSL distribution (this may be better for something that's useful, but that perhaps we can't agree that there is one true way to do it).

As Mitch alludes to, there are several computational models that have been published for sky color, and they are usually more complex than merely the raw daylight color temperature -- they are a complex function of position on earth, time of day and year, direction, and atmospheric conditions. These have even been implemented in OSL (though I don't know if any are published). I don't know what the debate would be like in choosing one that everybody could agree on, but if there was consensus that a particularly good one should be part of the language, or like I said as an example for us to ship even if not a language feature per se, we would be happy to receive that submission.


On Jan 9, 2021, at 10:22 AM, Mitch Prater <mprater@...> wrote:

[Edited Message Follows]

Excellent question Chris - thanks for raising it!

The short, and I believe "standard" answer to such questions, is that if OSL doesn't currently provide functionality you desire, you can implement it yourself either using OSL shader code, or by adding that functionality to the language so that it can be incorporated into the OSL repository, or just within your own rendering system implementation if you prefer to not make that public.

The long answer is that color science and its application within lighting, shading, and rendering systems is a fascinating topic and obviously one that deserves a great deal of attention. OSL is fundamentally however, a programming language only. Questions of what color is, how it's controlled, represented, processed, displayed, and finally perceived is more within the purview of the CIE, Open Color IO, and the implementers of your rendering system. OSL in its current form represents color as a 3-tuple, so its ability to process color is constrained to quantities that can be represented by that data type (and the underlying assumptions about the orthogonality of those values). But, since shading is fundamentally a process of generating color, it's absolutely valid to raise the question of how much of the definition of color should be a part of the language and how to manage and implement it. As spectral representations of light make their way out of research and into production renderers, this topic deserves more discussion.

But I digress. The ability to specify a "daylight color" as a function of a temperature value certainly sounds useful. It does bring up the question as to what the atmospheric filtering consists of, and whether you'd want the ability to control that instead. The sun's output is actually constant, so its illumination on the ground is completely a function of the atmospheric conditions and the sun's path through it, so using a temperature value might not be the most useful physically-based control. Pixar had implemented just such an atmospheric light source many years ago. I seem to recall it having been presented at Siggraph, but I can't say for sure.

mitch

--
Larry Gritz





Re: blackbody and daylight functions

Mitch Prater
 
Edited

Excellent question Chris - thanks for raising it!

The short, and I believe "standard" answer to such questions, is that if OSL doesn't currently provide functionality you desire, you can implement it yourself either using OSL shader code, or by adding that functionality to the language so that it can be incorporated into the OSL repository, or just within your own rendering system implementation if you prefer to not make that public.

The long answer is that color science and its application within lighting, shading, and rendering systems is a fascinating topic and obviously one that deserves a great deal of attention. OSL is fundamentally however, a programming language only. Questions of what color is, how it's controlled, represented, processed, displayed, and finally perceived is more within the purview of the CIE, Open Color IO, and the implementers of your rendering system. OSL in its current form represents color as a 3-tuple, so its ability to process color is constrained to quantities that can be represented by that data type (and the underlying assumptions about the orthogonality of those values). But, since shading is fundamentally a process of generating color, it's absolutely valid to raise the question of how much of the definition of color should be a part of the language and how to manage and implement it. As spectral representations of light make their way out of research and into production renderers, this topic deserves more discussion.

But I digress. The ability to specify a "daylight color" as a function of a temperature value certainly sounds useful. It does bring up the question as to what the atmospheric filtering consists of, and whether you'd want the ability to control that instead. The sun's output is actually constant, so its illumination on the ground is completely a function of the atmospheric conditions and the sun's path through it, so using a temperature value might not be the most useful physically-based control. Pixar had implemented just such an atmospheric light source many years ago. I seem to recall it having been presented at Siggraph, but I can't say for sure.

mitch


blackbody and daylight functions

chrisbrejon@...
 

Hi everyone,

first time posting here. First of all, best wishes for 2021. ;-)
I am a lighting lead at illumination mac guff and our developers are currently implementing OSL
in our proprietary render engine, which is awesome. ;-)

I had a question about the blackbody function if that's okay with you. I have recently been explained that
for higher temperatures we might want daylight and not black body values.Think of it as being the delta between
a pure black body and the fact that in reality we have the sun + atmosphere filtering the light.
so for Displays we tend to match the daylight locus and most colour spaces are daylight whitepoints.

I found this information (shared by Kevin Wheatley) quite fascinating because we have been investigating
blackbody values for the past months and we did notice that something felt "off" for high values (like blue sky).
If you're interesting, here is an article on the topic and the definition by the CIE.

So my question would be if there is any interest to implement a daylight function into OSL ?
A bit like what you did with the blackbody_rgb function and the BB_TABLE.

As you can tell, I am no developer so I apologize for any noob question or misconception I'd have. ;-)
Regards,
Chris


Re: OSL API Documentation

Reza Aarabi
 

I got you
I thought I can not find the C++ API Documentation. :)
thanks though

On Fri, Jan 8, 2021 at 4:56 PM Larry Gritz <lg@...> wrote:
I'm not trying to make excuses for our lack of documentation, just trying to explain it. 

The "end users" are the people writing shaders, and so we do publish the language spec (and hopefully, are working toward more OSL programming tutorial material). The rest of the "end user" documentation is kind of pushed to the renderers, because OSL is embedded in rendering products as a library so the way it's exposed to users will vary a lot from renderer to renderer.

But the basic reason that there is currently no separate documentation for the C++ APIs is that they aren't something that ordinary end users (people who write shaders) ever need to know about. Those APIs are only of interest to the authors of renderers who wish to embed OSL into their renderer.  We're trying to improve this, but that's the basic reason why the current "documentation" is just the comments in the headers themselves, and the code of the sample programs like testshade and test render.

-- lg


On Jan 7, 2021, at 3:09 PM, Reza Aarabi <madoodia@...> wrote:

Hi guys

Just wanted to know there is any Doxygen style documentation for OSL API?

I wanted to read about some C++ classes (like RendererService) but couldn't find the good Detail Description about it,
there is any link for C++ API classes of OSL?
please share with me
thanks

--
Larry Gritz






--


---------------------
--= Reza Aarabi =--


Re: OSL API Documentation

Larry Gritz
 

I'm not trying to make excuses for our lack of documentation, just trying to explain it. 

The "end users" are the people writing shaders, and so we do publish the language spec (and hopefully, are working toward more OSL programming tutorial material). The rest of the "end user" documentation is kind of pushed to the renderers, because OSL is embedded in rendering products as a library so the way it's exposed to users will vary a lot from renderer to renderer.

But the basic reason that there is currently no separate documentation for the C++ APIs is that they aren't something that ordinary end users (people who write shaders) ever need to know about. Those APIs are only of interest to the authors of renderers who wish to embed OSL into their renderer.  We're trying to improve this, but that's the basic reason why the current "documentation" is just the comments in the headers themselves, and the code of the sample programs like testshade and test render.

-- lg


On Jan 7, 2021, at 3:09 PM, Reza Aarabi <madoodia@...> wrote:

Hi guys

Just wanted to know there is any Doxygen style documentation for OSL API?

I wanted to read about some C++ classes (like RendererService) but couldn't find the good Detail Description about it,
there is any link for C++ API classes of OSL?
please share with me
thanks

--
Larry Gritz





Re: OSL API Documentation

Reza Aarabi
 

Any Idea?


On Thu, Jan 7, 2021 at 3:09 PM Reza Aarabi via lists.aswf.io <madoodia=gmail.com@...> wrote:
Hi guys

Just wanted to know there is any Doxygen style documentation for OSL API?

I wanted to read about some C++ classes (like RendererService) but couldn't find the good Detail Description about it,
there is any link for C++ API classes of OSL?
please share with me
thanks



--


---------------------
--= Reza Aarabi =--


OSL Docs

Mitch Prater
 

Hi All,

I've created a temporary github project/repo for collecting any OSL documentation we're working on: https://github.com/mprater/osl-doc

I've never managed an on-line or collaborative documentation project before, so this is the best I could come up with. If there's a better way to go about this please let me know. I've initialized the repository with the work we've already done.

Please consider contributing useful information you may have.

Thanks, mitch


Upcoming Events #cal-summary

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

Open Shading Language discussion list Upcoming Events

OSL TSC meeting ( every other week )

When:
Thursday, 21 January 2021, 2:00pm to 3:00pm
(GMT-08:00) America/Los Angeles

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

Organizer: Chris Kulla ckulla@...

Details:

Every other week meeting of the OSL TSC.

Meeting Agenda / Notes: https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/

Confirm this meeting invite is still valid by finding the meeting at https://lists.aswf.io/calendar.

Join Zoom Meeting https://zoom.us/j/100511909

Meeting ID: 100 511 909

One tap mobile +16465588656,,100511909# US (New York) +13126266799,,100511909# US (Chicago)

Dial by your location +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 6833 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 438 809 7799 Canada 855 703 8985 Canada Toll-free Meeting ID: 100 511 909 Find your local number: https://zoom.us/u/acBVrM6HWR

View Event


OSL TSC meeting ( every other week )

When:
Thursday, 4 February 2021, 2:00pm to 3:00pm
(GMT-08:00) America/Los Angeles

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

Organizer: Chris Kulla ckulla@...

Details:

Every other week meeting of the OSL TSC.

Meeting Agenda / Notes: https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/

Confirm this meeting invite is still valid by finding the meeting at https://lists.aswf.io/calendar.

Join Zoom Meeting https://zoom.us/j/100511909

Meeting ID: 100 511 909

One tap mobile +16465588656,,100511909# US (New York) +13126266799,,100511909# US (Chicago)

Dial by your location +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 6833 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 438 809 7799 Canada 855 703 8985 Canada Toll-free Meeting ID: 100 511 909 Find your local number: https://zoom.us/u/acBVrM6HWR

View Event


OSL API Documentation

Reza Aarabi
 

Hi guys

Just wanted to know there is any Doxygen style documentation for OSL API?

I wanted to read about some C++ classes (like RendererService) but couldn't find the good Detail Description about it,
there is any link for C++ API classes of OSL?
please share with me
thanks


OSL TSC meeting ( every other week ) - Thu, 01/07/2021 #cal-notice

osl-dev@lists.aswf.io Calendar <noreply@...>
 

OSL TSC meeting ( every other week )

When:
Thursday, 7 January 2021
2:00pm to 3:00pm
(GMT-08:00) America/Los Angeles

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

Organizer:
ckulla@...

Description:

Every other week meeting of the OSL TSC.

Meeting Agenda / Notes: https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/

Confirm this meeting invite is still valid by finding the meeting at https://lists.aswf.io/calendar.

Join Zoom Meeting https://zoom.us/j/100511909

Meeting ID: 100 511 909

One tap mobile +16465588656,,100511909# US (New York) +13126266799,,100511909# US (Chicago)

Dial by your location +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 6833 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 438 809 7799 Canada 855 703 8985 Canada Toll-free Meeting ID: 100 511 909 Find your local number: https://zoom.us/u/acBVrM6HWR


OSL TSC meeting ( every other week ) - Thu, 01/07/2021 2:00pm-3:00pm #cal-reminder

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

Reminder: OSL TSC meeting ( every other week )

When: Thursday, 7 January 2021, 2:00pm to 3:00pm, (GMT-08:00) America/Los Angeles

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

View Event

Organizer: Chris Kulla ckulla@...

Description:

Every other week meeting of the OSL TSC.

Meeting Agenda / Notes: https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/

Confirm this meeting invite is still valid by finding the meeting at https://lists.aswf.io/calendar.

Join Zoom Meeting https://zoom.us/j/100511909

Meeting ID: 100 511 909

One tap mobile +16465588656,,100511909# US (New York) +13126266799,,100511909# US (Chicago)

Dial by your location +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 6833 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 438 809 7799 Canada 855 703 8985 Canada Toll-free Meeting ID: 100 511 909 Find your local number: https://zoom.us/u/acBVrM6HWR


OSL TSC meeting ( every other week ) - Thu, 01/07/2021 2:00pm-3:00pm #cal-reminder

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

Reminder: OSL TSC meeting ( every other week )

When: Thursday, 7 January 2021, 2:00pm to 3:00pm, (GMT-08:00) America/Los Angeles

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

View Event

Organizer: Chris Kulla ckulla@...

Description:

Every other week meeting of the OSL TSC.

Meeting Agenda / Notes: https://docs.google.com/document/d/1yf0bG6eoE2EvKZBNZX3nskdTvu99ADTDTNOknCDJd1I/

Confirm this meeting invite is still valid by finding the meeting at https://lists.aswf.io/calendar.

Join Zoom Meeting https://zoom.us/j/100511909

Meeting ID: 100 511 909

One tap mobile +16465588656,,100511909# US (New York) +13126266799,,100511909# US (Chicago)

Dial by your location +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 6833 US (San Jose) +1 253 215 8782 US +1 301 715 8592 US +1 346 248 7799 US (Houston) 877 369 0926 US Toll-free 855 880 1246 US Toll-free +1 587 328 1099 Canada +1 647 374 4685 Canada +1 647 558 0588 Canada +1 778 907 2071 Canada +1 438 809 7799 Canada 855 703 8985 Canada Toll-free Meeting ID: 100 511 909 Find your local number: https://zoom.us/u/acBVrM6HWR

321 - 340 of 4810