1. ocio-dev@lists.aswf.io
  2. Messages
   Date   
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.

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
  3. 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:
Re: ACES OpenColorIO-Configs (and other stories)

Thomas Mansencal
 

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
  3. 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:
Re: PLEASE READ: OpenColorIO repo moving

Richard Shaw
 

On Mon, Sep 30, 2019 at 12:10 PM Michael Dolan <michdolan@...> wrote:
The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.

Fedora SPEC file updated and at release-monitoring.org:


Thanks,
Richard 
ACES OpenColorIO-Configs (and other stories)

Sean Cooper
 

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
  3. 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:
Re: PLEASE READ: OpenColorIO repo moving

Larry Gritz
 

Please also note that contributors to OCIO henceforth need to sign appropriate CLAs with LF/ASWF. Please do not send any OCIO related CLAs to Imageworks. Not our circus, not our monkeys. :-)



On Mon, Sep 30, 2019 at 10:10 AM Michael Dolan <michdolan@...> wrote:
The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.



--
Larry Gritz
lg@...
Re: PLEASE READ: OpenColorIO repo moving

Michael Dolan
 

The OpenColorIO repo has been moved. The new URL is:

https://github.com/AcademySoftwareFoundation/OpenColorIO
Previous URLs will forward to this new location.
Re: PLEASE READ: OpenColorIO repo moving

Diogo Girondi
 

Thanks for the heads-up Michael!

Cheers,
Diogo

 

From: ocio-dev@... on behalf of Michael Dolan <michdolan@...>
Sent: Thursday, September 26, 2019 7:34 PM
To: ocio-dev@...
Subject: [ocio-dev] PLEASE READ: OpenColorIO repo moving
 
Hi all,

It's been a busy year for OpenColorIO!

We recently graduated from an incubation to adopted ASWF project (more on what that means at this link). It was a lot of work getting to that point, but we got it done. Now it is time to move the OpenColorIO GitHub repo from the Imageworks organization to the AcademySoftwareFoundation organization.

The good news is GitHub handles this process fairly seamlessly. The old URLs will forward to the new ones, so the impact on the wider community should be minimal. We will update this thread with status updates and to provide further information about the move or any expected disruptions.

This process will likely be completed over the next week, so stay tuned. Also note that we are NOT moving the OpenColorIO-Configs repo at this time. That will remain with the Imageworks GitHub organization for now.

Thanks!

PLEASE READ: OpenColorIO repo moving

Michael Dolan
 

Hi all,

It's been a busy year for OpenColorIO!

We recently graduated from an incubation to adopted ASWF project (more on what that means at this link). It was a lot of work getting to that point, but we got it done. Now it is time to move the OpenColorIO GitHub repo from the Imageworks organization to the AcademySoftwareFoundation organization.

The good news is GitHub handles this process fairly seamlessly. The old URLs will forward to the new ones, so the impact on the wider community should be minimal. We will update this thread with status updates and to provide further information about the move or any expected disruptions.

This process will likely be completed over the next week, so stay tuned. Also note that we are NOT moving the OpenColorIO-Configs repo at this time. That will remain with the Imageworks GitHub organization for now.

Thanks!
Cancelled Event: OpenColorIO TSC meeting (weekly) - Monday, 2 September 2019 #cal-cancelled

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

Cancelled: OpenColorIO TSC meeting (weekly)

This event has been cancelled.

When:
Monday, 2 September 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 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

Calendar
Calendar

Re: Setting OCIO->Displays->Active in RV

Ravindra Korde
 

Hi Michael,

No problem at all.
I will check the links you provided & try to create it in RV.


On Mon, Aug 19, 2019, 8:22 PM Michael Dolan <michdolan@...> wrote:
Sorry for the late reply. It might be worth asking this question on RV's support site instead, since it pertains to their bundled OCIO package:

https://support.shotgunsoftware.com

Here are some really old developer docs about customizing OCIO in RV, which may or may not be a helpful starting point:


On Thu, Aug 1, 2019, 10:47 PM Ravindra Korde, <rravindrakorde@...> wrote:
Hi All,
 
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
 
Can anyone have any idea how to do it in RV?
Re: Setting OCIO->Displays->Active in RV

Michael Dolan
 

Sorry for the late reply. It might be worth asking this question on RV's support site instead, since it pertains to their bundled OCIO package:

https://support.shotgunsoftware.com

Here are some really old developer docs about customizing OCIO in RV, which may or may not be a helpful starting point:


On Thu, Aug 1, 2019, 10:47 PM Ravindra Korde, <rravindrakorde@...> wrote:
Hi All,
 
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
 
Can anyone have any idea how to do it in RV?
Re: SIGGRAPH 2019 - OpenColorIO Birds of a Feather

Pipeliner TD
 

thank you for sharing the presentation!

Am Mi., 31. Juli 2019 um 20:44 Uhr schrieb Michael Dolan <michdolan@...>:

Hello all,

We held the OpenColorIO Birds of a Feather yesterday at SIGGRAPH in LA. Thank you to everyone who could join us! We directly followed the ACES BoF and both events had very good attendance. For those who couldn't be there, we recorded the meeting and will make the video available following SIGGRAPH. 

I opened the BoF with a project update covering our ASWF incubation status, related improvements to the OCIO build and CI systems, and a summary of Thomas Mansencal's work on the ACES 1.1 OCIO config. Doug Walker and Patrick Hodoul then outlined their progress and roadmap for OCIO v2, as well as discussing support for new pixel formats, ACES output transforms, CLF, and measurable CPU renderer performance gains. Lastly, Mark Boorer gave an overview of his work on the companion OpenColorMath library, covering its design, interface, and vision for where to take it next.

The presentation slides are attached to this thread, where you can find a detailed outline of the information presented. Feel free to respond with any questions or points of discussion.

I wanted to also give a big thanks to Emily Olin, John Mertic, and the rest of the Linux Foundation team for skillfully organizing this event (as well as 9 other open source BoF meetings for Open Source Day!).

Thanks!

Re: Compile order for OCIO, OIIO, OpenExr?

Mark Boorer
 

> Is there a target to build only the OpenColorIO tools?

-DOCIO_BUILD_APPS=OFF

-DOCIO_BUILD_APPS=ON

You will unnecessarily build the core lib twice, but reinstalling it over the top should cause no issues.


On Thu, 8 Aug 2019, 19:39 Gonzalo Garramuño, <ggarra13@...> wrote:

El 8/8/19 a las 15:32, Mark Boorer escribió:
> 1. OpenEXR
> 2. OpenColorIO
> 3. OpenImageIO
> 4. OpenColorIO tools
>
> The core OCIO library doesn't depend on OIIO, only the extra tools.
Is there a target to build only the OpenColorIO tools?

--
Gonzalo Garramuño
Re: Compile order for OCIO, OIIO, OpenExr?

Larry Gritz
 

This is all my understanding, too. To recap:

OIIO's dependency on OCIO is fundamental (well, if you want all the color conversion functionality, which of course any studio user does). 

OCIO's dependency on OIIO is limited. If you just need the OCIO libraries, OIIO is not needed at all. The ways that OCIO uses OCIO are strictly for ocioconvert, ociodisplay, and ociolutimage.

ocioconvert is a historical quirk dating from a time when OIIO did not have OCIO support and there was an actual purpose to 'ocioconvert', whereas now you just want to use 'oiiotool --colorconnvert.

ociodisplay is really just an example (and maybe ocioconvert is, too), and as examples, they don't need the full flexibility of an OpenImageIO-backed support of all possible data and file formats. So maybe a solution there is, say, to support OpenEXR only and use tinyexr (a header-only implementation of just exr core features).

ociobakelut is a little more fundamental, though only used by power users. But again, if you're willing to stipulate that the baked LUT images are always openexr, maybe there as well using OpenEXR or even tinyexr will let us avoid pulling all of OIIO in.

Also, it is worth noting that if these utilities were changed from C++ to Python, even if they still use OIIO, it would at least be a simple runtime dependency and not a circular build-order dependency.

-- lg


On Aug 8, 2019, at 11:39 AM, Sloan, Blake <bsloan@...> wrote:

Hi Steve!
 
OpenEXR does not (and should not) depend on OCIO.
 
I think I bring the OCIO->OIIO dependency up at every BoF.
 
What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)  
 
Build OCIO without ociorender
Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory)
Build OCIO with ociorender against OIIO
Install OCIO
Install OIIO
 
OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.
 
OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be 
  1. moved to a separate package, say OpenColorIOExtensions,
  2. made a build option that defaults to off, or better,
  3. made to depend on a lightweight image library whose code ships with OCIO (ppm?)
  4. dropped altogether from the build, as an installation of OIIO built against OCIO will already have oiiotool, whose functionality overlaps with ociorender.   
       
 
-blake
 

--
Larry Gritz
Re: Compile order for OCIO, OIIO, OpenExr?

Sloan, Blake
 

Hi Steve!

 

OpenEXR does not (and should not) depend on OCIO.

 

I think I bring the OCIO->OIIO dependency up at every BoF.

 

What Mark suggests works but is a bit more complicated for shops using an automated build system (OCIO build may succeed but link to the system’s installed OIIO libs instead of the yet-to-be-built ones)  

 

Build OCIO without ociorender

Build OIIO against OCIO (make sure rpaths do not explicitly point to OCIO build directory)

Build OCIO with ociorender against OIIO

Install OCIO

Install OIIO

 

OIIO’s dependency on on OCIO is, in my opinion, a necessary thing as it allows OIIO clients to manage color using OCIO.

 

OCIO’s dependency on OIIO is not essential and should be deprecated (I think its current custodians are in agreement). One of OCIO’s example executables (ociorender?) depends on OIIO for image file IO. This executable can either be

  1. moved to a separate package, say OpenColorIOExtensions,
  2. made a build option that defaults to off, or better,
  3. made to depend on a lightweight image library whose code ships with OCIO (ppm?)
  4. dropped altogether from the build, as an installation of OIIO built against OCIO will already have oiiotool, whose functionality overlaps with ociorender.   

       

 

-blake

 
Re: Compile order for OCIO, OIIO, OpenExr?

Gonzalo Garramuño
 

El 8/8/19 a las 15:32, Mark Boorer escribió:
1. OpenEXR
2. OpenColorIO
3. OpenImageIO
4. OpenColorIO tools

The core OCIO library doesn't depend on OIIO, only the extra tools.
Is there a target to build only the OpenColorIO tools?

--
Gonzalo Garramuño
Re: Compile order for OCIO, OIIO, OpenExr?

Mark Boorer
 

1. OpenEXR
2. OpenColorIO
3. OpenImageIO
4. OpenColorIO tools

The core OCIO library doesn't depend on OIIO, only the extra tools.


On Thu, 8 Aug 2019, 19:24 Alex Hughes, <alex@...> wrote:
From my understanding, OpenEXR can simply be built first. The OCIO and OIIO thing gets a bit more complicated for those two but I have never had complications where I would not build OpenEXR first

-Alex

On Thu, Aug 8, 2019 at 7:01 PM Steve Hwan <svhwan+opencgi@...> wrote:
I asked Larry a variation of this at DigiPro and he suggested I ask on this list, as the answer was mildly complicated.

I observed OCIO and OIIO had build dependencies on each other, so I was wondering if there was a recommended build order? (And now that I'm asking, I'll throw OpenExr into the mix for the question as well - are there any dependencies on OCIO? Or is it as simple as "Just build OpenExr first."?)

-Steve
Re: Compile order for OCIO, OIIO, OpenExr?

Alex Hughes
 

From my understanding, OpenEXR can simply be built first. The OCIO and OIIO thing gets a bit more complicated for those two but I have never had complications where I would not build OpenEXR first

-Alex

On Thu, Aug 8, 2019 at 7:01 PM Steve Hwan <svhwan+opencgi@...> wrote:
I asked Larry a variation of this at DigiPro and he suggested I ask on this list, as the answer was mildly complicated.

I observed OCIO and OIIO had build dependencies on each other, so I was wondering if there was a recommended build order? (And now that I'm asking, I'll throw OpenExr into the mix for the question as well - are there any dependencies on OCIO? Or is it as simple as "Just build OpenExr first."?)

-Steve
Compile order for OCIO, OIIO, OpenExr?

Steve Hwan
 

I asked Larry a variation of this at DigiPro and he suggested I ask on this list, as the answer was mildly complicated.

I observed OCIO and OIIO had build dependencies on each other, so I was wondering if there was a recommended build order? (And now that I'm asking, I'll throw OpenExr into the mix for the question as well - are there any dependencies on OCIO? Or is it as simple as "Just build OpenExr first."?)

-Steve
Setting OCIO->Displays->Active in RV

Ravindra Korde
 

Hi All,
 
Every time after loading a ocio.config file in RV i have to go to the ocio menu & select displays to active. so I'm trying to set displays to active automatically as i load a config file, but i couldn't find anything it.
I have search for it in every .mu file in RV which supports to assignments.
 
Can anyone have any idea how to do it in RV?
361 - 380 of 2201