Integration - Fixes from main into RB-2.2 - Adsk Contrib (#1750)

* Changing version release type for 2.2.1 official release.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* replace texture2D function with texture for GLSL 1.3 (#1723)

Signed-off-by: Bart Styczen <bart.styczen@cine.dev>

Signed-off-by: Bart Styczen <bart.styczen@cine.dev>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit d5cedbf551)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* CheckSupportSSE2: Fix sse flags unexpected propagation (#1721)

Set function will affects all variables in current directory. If sse
flags are added in CheckSupportSSE2.cmake, they will remain in
Findminizip-ng.cmake which will cause liblzma cannot be detected. This
patch keep CMAKE_REQUIRED_FLAGS being changed only in current file
scope. This patch has been tested on riscv64.

Signed-off-by: Letu Ren <fantasquex@gmail.com>

Signed-off-by: Letu Ren <fantasquex@gmail.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit b6e40f4fca)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk contrib - Fix issue with minizip build (#1725)

* - Refactoring how OCIO search for minizip-ng. The first step is to search for an external minizip-ng. If not found, search for minizip-ng with MZ_COMPAT=ON (libminizip). If it is not found either, download and install minizip-ng with MZ_COMPAT=OFF.
- Removing the minizip-ng part for the includes for minizip-ng headers.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Update comments

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Improved find_package in Config mode (adding it back)
Added missing scripts to install minizip-ng and zlib for the analysis workflow

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding +x permissions for install_minizip_ng and zlib
Fixing path to find zlib in install_minizip-ng.sh

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Changing target name to match the one used by minizip-ng library (+ using the imported target instead of creating a new one when minizip-ng is found)

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 811902b37d)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk contrib - Processor cache does not detect changes in cccid (#1726)

* For Looks that has a FileTransform and for Colorspace with FileTransfrom, add the CCCID to the processor's cache key for that transform.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing the workaround in the related unit tests and fixing the issue by adding the environment variable to the context using setStringVar. The processor's cache key is using the context cache ID which has all the context variables taken into account.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Now using addStringVars and creating a new context instead of reusing the one used for the filename.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding cccid to the context when there are no context variable.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding a few unit tests to test that the processor is different when changing the FileTransform's CCCID.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Using setStringVar to set CCNUM context variable in unit test.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding a test in FileTransform to test CollectContextVariables directly.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Minor tweaks for the unit test

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 4fa775030a)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk contrib - Configure the OpenColorIO.pc file on Windows (#1720)

* Configure the OpenColorIO.pc file on Windows and fix an issue where CMAKE_INSTALL_PREFIX wasn't included in the cmake build command in ocio.bat.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing pkconfig folder since that PC file is not used.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Small tweak in the configuration of OpenColorIO.cmake.in to handle absolute path with CMAKE_INSTALL_LIBDIR or CMAKE_INSTALL_INCLUDEDIR.
Keeping exec_prefix for CMAKE_INSTALL_INCLUDE_DIR since it was changed for a specific issue on Mac (see PR #1120).

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Using ${prefix} for includedir

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 332462e7f5)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk contrib - Hiding minizip-ng symbols on Mac (#1729)

* Hiding minizip-ng symbols on Mac

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fixing a linking issue related to the code that tries to hide expat symbols and small refactor to add robustness.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 907ed3be17)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk contrib - Fix issue with is colorspace linear (#1734)

* Throw when the colorspace is undefined for isColorSpaceLinear method. (+ unit test)

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Typo

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 6d7c4791f1)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk Contrib - Improve naming of ICC-based displays on Windows (#1742)

* Adding a method to get the Monitor's userFriendlyName if available

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing the slashes at the start of the display name

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding descriptions and comments.
Adding troubleshooting script that print the monitor display name and ICC profile path.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* no message

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Comments

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 1d126b56e9)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fix minizip-ng CMake args passing (#1741)

Signed-off-by: Rémi Achard <remiachard@gmail.com>

Signed-off-by: Rémi Achard <remiachard@gmail.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 051241c9f1)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fix inverse Lut1D optimization bug (#1743)

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

Signed-off-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 5152635a18)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Update documentation for 2.2 release (#1738)

* Update documentation for 2.2 release

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Fix typos

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Remove V2_DOC_README.md

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Tweaks to 2.2

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Improve installation section

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Add link to demo config

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Fix typos

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

* Improve file_rules section

Signed-off-by: Doug Walker <doug.walker@autodesk.com>

Signed-off-by: Doug Walker <doug.walker@autodesk.com>
(cherry picked from commit 17f5c98f9b)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adsk Contrib - OCIO cmake improvements (#1736)

* - Refactoring how OCIO search for minizip-ng. The first step is to search for an external minizip-ng. If not found, search for minizip-ng with MZ_COMPAT=ON (libminizip). If it is not found either, download and install minizip-ng with MZ_COMPAT=OFF.
- Removing the minizip-ng part for the includes for minizip-ng headers.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Update comments

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Improved find_package in Config mode (adding it back)
Added missing scripts to install minizip-ng and zlib for the analysis workflow

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding +x permissions for install_minizip_ng and zlib
Fixing path to find zlib in install_minizip-ng.sh

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Changing target name to match the one used by minizip-ng library (+ using the imported target instead of creating a new one when minizip-ng is found)

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* First pass for the OpenColorIOConfig.cmake file with the required dependencies only.
A few extra fixes for OpenEXR, ZLIB and Minizip-ng.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding a informative message when building static ocio instead of per module.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding an extra step to test the consumer app with static OpenColorIO for Windows, Linux and MacOS.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Re-using the same test instead of creating a new one by removing the condition on build-shared.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fixing spacing, typo and adding back the NOT in the condition. (it was removed for debugging purpose)

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Changing directory where we share OCIO custom find modules (now in <install dir>/share/cmake/modules).
Adding a cmake macro when installing OCIO since it is needed by some custom find modules.
The find modules are only installed when building OCIO as a static library.
The config.cmake.in files now only looks for the dependency when OCIO was built as a static library.
Tentative (ci-workflow): Adding cmake-consumer test for static builds.
Overhaul of the Findzlib module to be more inline with the FindZLIB from cmake and to be more robust.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding missing backward slashes and saving the build path in an existing step instead of creating a new step.
Adding a check for CMake version for a section in Findzlib.cmake.
Re-phrasing some comments.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Prevent the download of the dependencies in the scenario where static OCIO is linked to a consumer project. Since OCIO_INSTALL_EXT_PACKAGES is not defined, our find module tries to download the dependencies, but we don't want that mecanism for consumer project.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Changing path where OCIO install its own custom find module.
Removing custom Findzlib and making modifications to use CMake FindZLIB.
Created a InstallZLIB module which does the download and install part if OCIO_INSTALL_EXT_PACAKGES is ALL or MISSING.
Tweaked config.cmake.in to use CMake FindZLIB.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Adding more details in comments

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing an extra "shell" property in CI workflow.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fix issues discovered with the failing CI workflow:

Cmake-consumer test now prefer the static version of the dependencies.
Fix an issue where yaml-cpp is not found by a consumer app (variable spelled incorectly in Findyaml-cpp).
Fix an issue expat library is not found by a consumer app on Windows.
Adding support for OCIO's  <pkg_name>_STATIC_LIBRARY for ZLIB while supporting ZLIB_USE_STATIC_LIBS (CMake 3.24+) from CMake's FindZLIB.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing pystring_STATIC_LIBRARY does not exists in CI workflow.
Detecting if the build is Debug in the find module that OCIO installs since they can't rely on variables set by OCIO CMakefiles.
Fix issue with yaml-cpp library naming in debug.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fix issues on Windows with expat and minizip-ng library naming when building static OCIO.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Added option for macOS CI job in order to get more info on a failed job. Will be reverted once the issue is found.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Fixing a issue on macOS.
Improving ZLIB usage comments.
Bumping minizip-ng to the latest version - 3.0.7.
Bumping ZLIB to the latest version 2.1.13 to fix a vulnerability (CVE-2022-37434)

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Proposing to remove Findminizip module since external minizip-ng build need to be done with the same option as the internal build.
Otherwise, linking and symbols issues are going to happend if the other libraries are not linked in correctly.
It is going to simplify the maintainability of OCIO.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

* Removing findminizip.cmake from the install since it does not exist anymore.

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Signed-off-by: Cédrik Fuoco <105517825+cedrik-fuoco-adsk@users.noreply.github.com>
(cherry picked from commit 91761f256b)
Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>

Signed-off-by: Cédrik Fuoco <cedrik.fuoco@autodesk.com>
Signed-off-by: Bart Styczen <bart.styczen@cine.dev>
Signed-off-by: Letu Ren <fantasquex@gmail.com>
Signed-off-by: Rémi Achard <remiachard@gmail.com>
Signed-off-by: Doug Walker <doug.walker@autodesk.com>
Signed-off-by: Cédrik Fuoco <105517825+cedrik-fuoco-adsk@users.noreply.github.com>
Co-authored-by: bartstyczen <93516126+bartstyczen@users.noreply.github.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>
Co-authored-by: FantasqueX <voidren@outlook.com>
Co-authored-by: Rémi Achard <remiachard@gmail.com>

.github/workflows/analysis_workflow.yml

@@ -7,13 +7,23 @@
 name: Analysis
 
 on:
+  pull_request:
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+    paths:
+      - .github/workflows/analysis_workflow.yml
   schedule:
     # Nightly build
     - cron: "0 0 * * *"
 
 jobs:
   # ---------------------------------------------------------------------------
-  # Latest ext packages
+  # Linux latest ext packages
   # ---------------------------------------------------------------------------
 
   linux_latest:
@@ -86,17 +96,30 @@ jobs:
         if: matrix.build-docs == 'ON'
       - name: Install tests env
         run: share/ci/scripts/linux/yum/install_tests_env.sh
+      - name: Setup ext environment
+        run: |
+          EXT_PATH=/usr/local
+          echo "EXT_PATH=$EXT_PATH" >> $GITHUB_ENV
+      - name: Install indirect dependencies
+        run: |
+          share/ci/scripts/multi/install_pugixml.sh latest
+      - name: Install fixed ext package versions
+        # Minizip-ng depends on ZLIB. ZLIB must be installed first.
+        run: |
+          share/ci/scripts/multi/install_expat.sh 2.4.1 $EXT_PATH
+          share/ci/scripts/multi/install_lcms2.sh 2.2 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.7.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.3 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 2.9.2 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.2.12 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 3.0.6 $EXT_PATH
       - name: Install latest ext package versions
         run: |
-          share/ci/scripts/linux/install_expat.sh latest
-          share/ci/scripts/linux/install_lcms2.sh latest
-          share/ci/scripts/linux/install_yaml-cpp.sh latest
-          share/ci/scripts/linux/install_pystring.sh latest
-          share/ci/scripts/linux/install_pybind11.sh latest
-          share/ci/scripts/linux/install_openexr.sh latest
-          share/ci/scripts/linux/install_imath.sh latest
-          share/ci/scripts/linux/install_oiio.sh latest
-          share/ci/scripts/linux/install_openfx.sh latest
+          share/ci/scripts/multi/install_imath.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openexr.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_oiio.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_osl.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openfx.sh latest $EXT_PATH
       - name: Create build directories
         run: |
           mkdir _install
@@ -112,7 +135,8 @@ jobs:
                 -DOCIO_BUILD_GPU_TESTS=OFF \
                 -DOCIO_INSTALL_EXT_PACKAGES=NONE \
                 -DOCIO_WARNING_AS_ERROR=OFF \
-                -DPython_EXECUTABLE=$(which python)
+                -DPython_EXECUTABLE=$(which python) \
+                -DOCIO_USE_OIIO_CMAKE_CONFIG=ON
         working-directory: _build
       - name: Build
         run: |
@@ -122,17 +146,267 @@ jobs:
                 -- -j$(nproc)
         working-directory: _build
       - name: Test
-        run: ctest -V
+        run: ctest -V -C Release
         working-directory: _build
+      - name: Test CMake Consumer
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=Release
+          cmake --build . \
+                --config Release
+          ./consumer
+        working-directory: _build/tests/cmake-consumer-dist
+
+  # ---------------------------------------------------------------------------
+  # MacOS latest ext packages
+  # ---------------------------------------------------------------------------
+
+  macos-latest:
+    name: 'macOS latest 
+      <AppleClang 12.0 
+       cxx=${{ matrix.cxx-standard }}, 
+       docs=${{ matrix.build-docs }}, 
+       python=${{ matrix.python-version }}>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    runs-on: macos-latest
+    strategy:
+      matrix:
+        build: [1, 2]
+        include:
+          # C++17
+          - build: 1
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 17
+            python-version: 3.9
+          # C++14
+          - build: 2
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 14
+            python-version: 3.9
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@v1
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/macos/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/macos/install_tests_env.sh
+      - name: Setup ext environment
+        run: |
+          EXT_PATH=/usr/local
+          echo "EXT_PATH=$EXT_PATH" >> $GITHUB_ENV
+      - name: Install indirect dependencies
+        run: |
+          share/ci/scripts/macos/install_bison.sh latest
+          share/ci/scripts/macos/install_boost.sh latest
+          share/ci/scripts/multi/install_pugixml.sh latest $EXT_PATH
+      - name: Install fixed ext package versions
+        # Minizip-ng depends on ZLIB. ZLIB must be installed first.
+        run: |
+          share/ci/scripts/multi/install_expat.sh 2.4.1 $EXT_PATH
+          share/ci/scripts/multi/install_lcms2.sh 2.2 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.7.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.3 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 2.9.2 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.2.12 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 3.0.6 $EXT_PATH
+      - name: Install latest ext package versions
+        run: |
+          share/ci/scripts/multi/install_imath.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openexr.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_oiio.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_osl.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openfx.sh latest $EXT_PATH
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=Release \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=NONE \
+                -DOCIO_WARNING_AS_ERROR=OFF \
+                -DPython_EXECUTABLE=$(which python) \
+                -DOCIO_USE_OIIO_CMAKE_CONFIG=ON
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config Release \
+                -- -j$(sysctl -n hw.ncpu)
+        working-directory: _build
+      - name: Test
+        run: ctest -V -C Release
+        working-directory: _build
+      - name: Test CMake Consumer
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=Release
+          cmake --build . \
+                --config Release
+          ./consumer
+        working-directory: _build/tests/cmake-consumer-dist
+
+
+  # ---------------------------------------------------------------------------
+  # Windows latest ext packages
+  # ---------------------------------------------------------------------------
+
+  windows-latest:
+    name: 'Windows latest 
+      <MSVC 
+       cxx=${{ matrix.cxx-standard }}, 
+       docs=${{ matrix.build-docs }}, 
+       python=${{ matrix.python-version }}>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    runs-on: windows-latest
+    strategy:
+      matrix:
+        build: [1, 2]
+        include:
+          # C++17
+          - build: 1
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 17
+            python-version: 3.9
+          # C++14
+          - build: 2
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 14
+            python-version: 3.9
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@v1
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@v2
+      - name: Install docs env
+        run: share/ci/scripts/windows/install_docs_env.sh
+        shell: bash
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/windows/install_tests_env.sh
+        shell: bash
+      - name: Setup ext environment
+        run: |
+          EXT_PATH=$GITHUB_WORKSPACE/_ext
+          VCPKG_ROOT=$VCPKG_INSTALLATION_ROOT/installed/x64-windows
+          echo "EXT_PATH=$EXT_PATH" >> $GITHUB_ENV
+          echo "CMAKE_PREFIX_PATH=$VCPKG_ROOT;$EXT_PATH" >> $GITHUB_ENV
+          echo "$VCPKG_ROOT/bin" >> $GITHUB_PATH
+          echo "$EXT_PATH/bin" >> $GITHUB_PATH
+          mkdir $EXT_PATH
+        shell: bash
+      - name: Install indirect dependencies
+        run: |
+          vcpkg install zlib:x64-windows
+          vcpkg install tiff:x64-windows
+          vcpkg install boost-asio:x64-windows
+          vcpkg install boost-container:x64-windows
+          vcpkg install boost-filesystem:x64-windows
+          vcpkg install boost-math:x64-windows
+          vcpkg install boost-stacktrace:x64-windows
+          vcpkg install boost-system:x64-windows
+          vcpkg install boost-thread:x64-windows
+          share/ci/scripts/multi/install_pugixml.sh latest $EXT_PATH
+        shell: bash
+      - name: Install fixed ext package versions
+        # Minizip-ng depends on ZLIB. ZLIB must be installed first.
+        run: |
+          share/ci/scripts/multi/install_lcms2.sh 2.2 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.7.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.3 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 2.9.2 $EXT_PATH
+          share/ci/scripts/multi/install_expat.sh 2.4.1 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.2.12 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 3.0.6 $EXT_PATH
+        shell: bash
+      # OSL not installed due to LLVM compilation time.
+      - name: Install latest ext package versions
+        run: |
+          share/ci/scripts/multi/install_imath.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openexr.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_oiio.sh latest $EXT_PATH
+          share/ci/scripts/multi/install_openfx.sh latest $EXT_PATH
+        shell: bash
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+        shell: bash
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=Release \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DCMAKE_GENERATOR_PLATFORM=x64 \
+                -DOCIO_BUILD_DOCS=OFF \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=NONE \
+                -DOCIO_WARNING_AS_ERROR=OFF \
+                -DPython_EXECUTABLE=$(which python) \
+                -DOCIO_BUILD_PYTHON=OFF \
+                -DOCIO_USE_OIIO_CMAKE_CONFIG=ON
+        shell: bash
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config Release \
+                --parallel
+        shell: bash
+        working-directory: _build
+      - name: Test
+        run: |
+          ctest -V -C Release
+        shell: bash
+        working-directory: _build
+      - name: Test CMake Consumer
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=Release
+          cmake --build . \
+                --config Release
+          export PATH=../../../_install/bin:$PATH
+          ./Release/consumer
+        shell: bash
+        working-directory: _build/tests/cmake-consumer-dist
+
 
   # ---------------------------------------------------------------------------
   # SonarCloud static analysis
   # ---------------------------------------------------------------------------
 
   linux_sonarcloud:
-    name: 'Linux CentOS 7 VFX CY2020 SonarCloud <GCC 6.3.1>'
+    name: 'Linux CentOS 7 VFX CY2022 SonarCloud <GCC 9.3.1>'
     # Don't run on OCIO forks
-    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    if: |
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO' &&
+      github.event.pull_request.head.repo.full_name == github.repository
     # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
     runs-on: ubuntu-latest
     container:
@@ -160,7 +434,7 @@ jobs:
           cmake ../. \
                 -DCMAKE_INSTALL_PREFIX=../_install \
                 -DCMAKE_BUILD_TYPE=Release \
-                -DCMAKE_CXX_STANDARD=11 \
+                -DCMAKE_CXX_STANDARD=14 \
                 -DCMAKE_CXX_FLAGS="-g -O0 -fprofile-arcs -ftest-coverage" \
                 -DCMAKE_CXX_OUTPUT_EXTENSION_REPLACE=ON \
                 -DCMAKE_EXE_LINKER_FLAGS="-lgcov" \
@@ -174,7 +448,7 @@ jobs:
         run: build-wrapper-linux-x86-64 --out-dir bw_output make clean all
         working-directory: _build
       - name: Test
-        run: ctest -V
+        run: ctest -V -C Release
         working-directory: _build
       - name: Generate code coverage report
         run: share/ci/scripts/linux/run_gcov.sh

.github/workflows/ci_workflow.yml

@@ -46,7 +46,12 @@ jobs:
        shared=${{ matrix.build-shared }}, 
        sse=${{ matrix.use-sse }}, 
        cxx=${{ matrix.cxx-standard }}, 
-       docs=${{ matrix.build-docs }}>'
+       docs=${{ matrix.build-docs }}, 
+       oiio=${{ matrix.use-oiio }}>'
+    # Avoid duplicated checks when a pull_request is opened from a local branch.
+    if: |
+      github.event_name == 'push' ||
+      github.event.pull_request.head.repo.full_name != github.repository
     # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
     runs-on: ubuntu-latest
     container:
@@ -55,46 +60,59 @@ jobs:
       image: aswf/ci-ocio:${{ matrix.vfx-cy }}
     strategy:
       matrix:
-        build: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
+        build: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13]
         include:
           # -------------------------------------------------------------------
           # VFX CY2022 (Python 3.9)
           # -------------------------------------------------------------------
-          # Clang, Debug, OpenFX
-          - build: 12
+          # C++17, Clang, Debug, OpenFX
+          - build: 13
             build-type: Debug
             build-shared: 'ON'
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'ON'
             cxx-standard: 17
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 9
             vfx-cy: 2022
-          # GCC, no SSE, OpenFX
-          - build: 11
+          # C++17, GCC, no SSE, OpenFX
+          - build: 12
             build-type: Release
             build-shared: 'ON'
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'OFF'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 17
             cxx-compiler: g++
             cc-compiler: gcc
             compiler-desc: GCC 9.3.1
             vfx-cy: 2022
-          # GCC, static, docs
-          - build: 10
+          # C++14, GCC, static, docs
+          - build: 11
             build-type: Release
             build-shared: 'OFF'
             build-docs: 'ON'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
-            cxx-standard: 17
+            use-oiio: 'OFF'
+            cxx-standard: 14
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC 9.3.1
+            vfx-cy: 2022
+          # C++11, GCC, static
+          - build: 10
+            build-type: Release
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-openfx: 'OFF'
+            use-sse: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 11
             cxx-compiler: g++
             cc-compiler: gcc
             compiler-desc: GCC 9.3.1
@@ -102,41 +120,41 @@ jobs:
           # -------------------------------------------------------------------
           # VFX CY2021 (Python 3.7)
           # -------------------------------------------------------------------
-          # Clang, docs
+          # C++17, Clang
           - build: 9
             build-type: Release
             build-shared: 'ON'
-            build-docs: 'ON'
+            build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'ON'
             cxx-standard: 17
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 9
             vfx-cy: 2021
-          # Clang, static, no SSE, OpenFX
+          # C++14, Clang, static, no SSE, OpenFX
           - build: 8
             build-type: Release
             build-shared: 'OFF'
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'OFF'
-            use-openexr-half: 'ON'
-            cxx-standard: 17
+            use-oiio: 'OFF'
+            cxx-standard: 14
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 9
             vfx-cy: 2021
-          # GCC, Debug
+          # C++11, GCC, Debug
           - build: 7
             build-type: Debug
             build-shared: 'ON'
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
-            cxx-standard: 17
+            use-oiio: 'OFF'
+            cxx-standard: 11
             cxx-compiler: g++
             cc-compiler: gcc
             compiler-desc: GCC 9.3.1
@@ -144,41 +162,41 @@ jobs:
           # -------------------------------------------------------------------
           # VFX CY2020 (Python 3.7)
           # -------------------------------------------------------------------
-          # Clang, OpenFX
+          # C++14, Clang, OpenFX
           - build: 6
             build-type: Release
             build-shared: 'ON'
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'OFF'
-            use-openexr-half: 'ON'
+            use-oiio: 'OFF'
             cxx-standard: 14
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 7
             vfx-cy: 2020
-          # GCC, static, Debug, OpenFX
+          # C++14, GCC, static, Debug, OpenFX
           - build: 5
             build-type: Debug
             build-shared: 'OFF'
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'ON'
             cxx-standard: 14
             cxx-compiler: g++
             cc-compiler: gcc
             compiler-desc: GCC 6.3.1
             vfx-cy: 2020
-          # GCC, no SSE, docs
+          # C++11, GCC, no SSE
           - build: 4
             build-type: Release
             build-shared: 'ON'
-            build-docs: 'ON'
+            build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
-            cxx-standard: 14
+            use-oiio: 'OFF'
+            cxx-standard: 11
             cxx-compiler: g++
             cc-compiler: gcc
             compiler-desc: GCC 6.3.1
@@ -186,7 +204,7 @@ jobs:
           # -------------------------------------------------------------------
           # VFX CY2019 (Python 2.7)
           # -------------------------------------------------------------------
-          # Clang, static
+          # C++11, Clang, static
           - build: 3
             build-type: Release
             build-shared: 'OFF'
@@ -194,13 +212,13 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'ON'
             cxx-standard: 11
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 7
             vfx-cy: 2019
-          # Clang, Debug, no SSE
+          # C++11, Clang, Debug, no SSE
           - build: 2
             build-type: Debug
             build-shared: 'ON'
@@ -208,13 +226,13 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'OFF'
-            use-openexr-half: 'ON'
+            use-oiio: 'OFF'
             cxx-standard: 11
             cxx-compiler: clang++
             cc-compiler: clang
             compiler-desc: Clang 7
             vfx-cy: 2019
-          # GCC, OpenFX
+          # C++11, GCC, OpenFX
           - build: 1
             build-type: Release
             build-shared: 'ON'
@@ -222,7 +240,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'OFF'
             cxx-standard: 11
             cxx-compiler: g++
             cc-compiler: gcc
@@ -234,6 +252,10 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v2
+      # minizip-ng requires CMake 3.13+ but VFX2019 image ships with 3.12
+      - name: Upgrade VFX2019 CMake
+        run: pip install cmake==3.13.3
+        if: matrix.vfx-cy == '2019'
       - name: Install docs env
         run: share/ci/scripts/linux/yum/install_docs_env.sh
         if: matrix.build-docs == 'ON'
@@ -254,7 +276,7 @@ jobs:
                 -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
                 -DOCIO_BUILD_GPU_TESTS=OFF \
                 -DOCIO_USE_SSE=${{ matrix.use-sse }} \
-                -DOCIO_USE_OPENEXR_HALF=${{ matrix.use-openexr-half }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
                 -DOCIO_INSTALL_EXT_PACKAGES=ALL \
                 -DOCIO_WARNING_AS_ERROR=ON \
                 -DPython_EXECUTABLE=$(which python)
@@ -265,11 +287,12 @@ jobs:
                 --target install \
                 --config ${{ matrix.build-type }} \
                 -- -j$(nproc)
+          echo "ocio_build_path=$(pwd)" >> $GITHUB_ENV
         working-directory: _build
       - name: Test
-        run: ctest -V
+        run: ctest -V -C ${{ matrix.build-type }}
         working-directory: _build
-      - name: Test CMake Consumer
+      - name: Test CMake Consumer with shared OCIO
         if: matrix.build-shared == 'ON'
         run: |
           cmake . \
@@ -279,6 +302,34 @@ jobs:
                 --config ${{ matrix.build-type }}
           ./consumer
         working-directory: _build/tests/cmake-consumer-dist
+      - name: Test CMake Consumer with static OCIO
+        if: matrix.build-shared == 'OFF'
+        # The yaml-cpp_VERSION is set below because Findyaml-cpp.cmake needs it but is unable to 
+        # extract it from the headers, like the other modules.
+        #
+        # Prefer the static version of each dependencies by using <pkg>_STATIC_LIBRARY. 
+        # Alternatively, this can be done by setting <pkg>_LIBRARY and <pkg>_INCLUDE_DIR to 
+        # the static version of the package.
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -Dexpat_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dexpat_STATIC_LIBRARY=ON \
+                -DImath_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DImath_STATIC_LIBRARY=ON \
+                -Dpystring_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_STATIC_LIBRARY=ON \
+                -Dyaml-cpp_VERSION=0.7.0 \
+                -DZLIB_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DZLIB_STATIC_LIBRARY=ON \
+                -Dminizip-ng_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dminizip-ng_STATIC_LIBRARY=ON
+          cmake --build . \
+                --config ${{ matrix.build-type }}
+          ./consumer
+        working-directory: _build/tests/cmake-consumer-dist
 
   # ---------------------------------------------------------------------------
   # macOS
@@ -292,7 +343,12 @@ jobs:
        sse=${{ matrix.use-sse }}, 
        cxx=${{ matrix.cxx-standard }}, 
        python=${{ matrix.python-version }}, 
-       docs=${{ matrix.build-docs }}>'
+       docs=${{ matrix.build-docs }}, 
+       oiio=${{ matrix.use-oiio}}>'
+    # Avoid duplicated checks when a pull_request is opened from a local branch.
+    if: |
+      github.event_name == 'push' ||
+      github.event.pull_request.head.repo.full_name != github.repository
     runs-on: macos-10.15
     strategy:
       matrix:
@@ -305,7 +361,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'ON'
             cxx-standard: 17
             python-version: 3.9
           # C++11, Python 3.7
@@ -315,7 +371,7 @@ jobs:
             build-docs: 'ON'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # Debug, OpenFX
@@ -325,7 +381,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # C++14, OpenEXR, OpenFX
@@ -335,7 +391,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'OFF'
             cxx-standard: 14
             python-version: 3.7
           # Static, no SSE
@@ -345,7 +401,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'OFF'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # Python 2.7
@@ -356,7 +412,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'ON'
             cxx-standard: 11
             python-version: 2.7
     steps:
@@ -386,7 +442,7 @@ jobs:
                 -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
                 -DOCIO_BUILD_GPU_TESTS=OFF \
                 -DOCIO_USE_SSE=${{ matrix.use-sse }} \
-                -DOCIO_USE_OPENEXR_HALF=${{ matrix.use-openexr-half }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
                 -DOCIO_INSTALL_EXT_PACKAGES=ALL \
                 -DOCIO_WARNING_AS_ERROR=ON \
                 -DPython_EXECUTABLE=$(which python)
@@ -397,11 +453,12 @@ jobs:
                 --target install \
                 --config ${{ matrix.build-type }} \
                 -- -j$(sysctl -n hw.ncpu)
+          echo "ocio_build_path=$(pwd)" >> $GITHUB_ENV
         working-directory: _build
       - name: Test
-        run: ctest -V
+        run: ctest -V -C ${{ matrix.build-type }}
         working-directory: _build
-      - name: Test CMake Consumer
+      - name: Test CMake Consumer with shared OCIO
         if: matrix.build-shared == 'ON'
         run: |
           cmake . \
@@ -411,6 +468,34 @@ jobs:
                 --config ${{ matrix.build-type }}
           ./consumer
         working-directory: _build/tests/cmake-consumer-dist
+      - name: Test CMake Consumer with static OCIO
+        if: matrix.build-shared == 'OFF'
+        # The yaml-cpp_VERSION is set below because Findyaml-cpp.cmake needs it but is unable to 
+        # extract it from the headers, like the other modules.
+        #
+        # Prefer the static version of each dependencies by using <pkg>_STATIC_LIBRARY. 
+        # Alternatively, this can be done by setting <pkg>_LIBRARY and <pkg>_INCLUDE_DIR to 
+        # the static version of the package.       
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -Dexpat_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dexpat_STATIC_LIBRARY=ON \
+                -DImath_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DImath_STATIC_LIBRARY=ON \
+                -Dpystring_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_STATIC_LIBRARY=ON \
+                -Dyaml-cpp_VERSION=0.7.0 \
+                -DZLIB_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DZLIB_STATIC_LIBRARY=ON \
+                -Dminizip-ng_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dminizip-ng_STATIC_LIBRARY=ON
+          cmake --build . \
+                --config ${{ matrix.build-type }}
+          ./consumer
+        working-directory: _build/tests/cmake-consumer-dist
 
   # ---------------------------------------------------------------------------
   # Windows
@@ -426,7 +511,12 @@ jobs:
        sse=${{ matrix.use-sse }}, 
        cxx=${{ matrix.cxx-standard }}, 
        python=${{ matrix.python-version }}, 
-       docs=${{ matrix.build-docs }}>'
+       docs=${{ matrix.build-docs }}, 
+       oiio=${{ matrix.use-oiio }}>'
+    # Avoid duplicated checks when a pull_request is opened from a local branch.
+    if: |
+      github.event_name == 'push' ||
+      github.event.pull_request.head.repo.full_name != github.repository
     runs-on: windows-2019
     strategy:
       matrix:
@@ -439,17 +529,17 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'ON'
             cxx-standard: 17
             python-version: 3.9
           # C++11, Python 3.7
           - build: 5
             build-type: Release
             build-shared: 'ON'
-            build-docs: 'ON'
+            build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # Debug
@@ -459,7 +549,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # C++14, OpenEXR, OpenFX
@@ -469,7 +559,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'ON'
-            use-openexr-half: 'ON'
+            use-oiio: 'OFF'
             cxx-standard: 14
             python-version: 3.7
           # Static, no SSE, OpenFX
@@ -479,7 +569,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'ON'
             use-sse: 'OFF'
-            use-openexr-half: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 11
             python-version: 3.7
           # Python 2.7
@@ -490,7 +580,7 @@ jobs:
             build-docs: 'OFF'
             build-openfx: 'OFF'
             use-sse: 'ON'
-            use-openexr-half: 'OFF'
+            use-oiio: 'ON'
             cxx-standard: 11
             python-version: 2.7
     steps:
@@ -506,6 +596,7 @@ jobs:
         if: matrix.build-docs == 'ON'
       - name: Install tests env
         run: share/ci/scripts/windows/install_tests_env.sh
+        shell: bash
       - name: Create build directories
         run: |
           mkdir _install
@@ -523,7 +614,7 @@ jobs:
                 -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
                 -DOCIO_BUILD_GPU_TESTS=OFF \
                 -DOCIO_USE_SSE=${{ matrix.use-sse }} \
-                -DOCIO_USE_OPENEXR_HALF=${{ matrix.use-openexr-half }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
                 -DOCIO_INSTALL_EXT_PACKAGES=ALL \
                 -DOCIO_WARNING_AS_ERROR=ON \
                 -DPython_EXECUTABLE=$(which python)
@@ -534,13 +625,14 @@ jobs:
           cmake --build . \
                 --target install \
                 --config ${{ matrix.build-type }}
+          echo "ocio_build_path=$(pwd)" >> $GITHUB_ENV
         shell: bash
         working-directory: _build
       - name: Test
-        run: ctest -V
+        run: ctest -V -C ${{ matrix.build-type }}
         shell: bash
         working-directory: _build
-      - name: Test CMake Consumer
+      - name: Test CMake Consumer with shared OCIO
         if: matrix.build-shared == 'ON'
         run: |
           cmake . \
@@ -552,3 +644,33 @@ jobs:
           ./${{ matrix.build-type }}/consumer
         shell: bash
         working-directory: _build/tests/cmake-consumer-dist
+      - name: Test CMake Consumer with static OCIO
+        if: matrix.build-shared == 'OFF'
+        # The yaml-cpp_VERSION is set below because Findyaml-cpp.cmake needs it but is unable to 
+        # extract it from the headers, like the other modules.
+        #
+        # Prefer the static version of each dependencies by using <pkg>_STATIC_LIBRARY. 
+        # Alternatively, this can be done by setting <pkg>_LIBRARY and <pkg>_INCLUDE_DIR to 
+        # the static version of the package.
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -Dexpat_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dexpat_STATIC_LIBRARY=ON \
+                -DImath_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DImath_STATIC_LIBRARY=ON \
+                -Dpystring_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dyaml-cpp_STATIC_LIBRARY=ON \
+                -Dyaml-cpp_VERSION=0.7.0 \
+                -DZLIB_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -DZLIB_STATIC_LIBRARY=ON \
+                -Dminizip-ng_ROOT=${{ env.ocio_build_path }}/ext/dist \
+                -Dminizip-ng_STATIC_LIBRARY=ON
+          cmake --build . \
+                --config ${{ matrix.build-type }}
+          export PATH=../../../_install/bin:$PATH
+          ./${{ matrix.build-type }}/consumer
+        shell: bash
+        working-directory: _build/tests/cmake-consumer-dist

.github/workflows/wheel_workflow.yml

@@ -6,15 +6,11 @@ name: Wheel
 
 on:
   push:
-    # Versioned branches and tags are ignored for OCIO <= 1.x.x
-    branches-ignore:
-      - RB-0.*
-      - RB-1.*
-      - gh-pages
-    tags-ignore:
-      - v0.*
-      - v1.*
+    # Workflow run on tags for v2 only.
+    tags:
+      - v2.*
   pull_request:
+    # Workflow run on pull_request only when related files change.
     branches-ignore:
       - RB-0.*
       - RB-1.*
@@ -22,6 +18,15 @@ on:
     tags-ignore:
       - v0.*
       - v1.*
+    paths:
+      - .github/workflows/wheel_workflow.yml
+      - MANIFEST.in
+      - pyproject.toml
+      - setup.cfg
+      - setup.py
+  schedule:
+    # Nightly build
+    - cron: "0 0 * * *"
 
 jobs:
   # Linux jobs run in Docker containers (manylinux), so the latest OS version
@@ -29,59 +34,85 @@ jobs:
   # environment versions to mitigate issues from OS updates, and will require
   # maintenance as OS versions are retired.
   #
-  # Notes:
-  #
-  # Documentation fails to build on manylinux2010, maybe too old
-  # doxygen ? First fail in PyColorSpaceSet for documentation
-  # referencing PyOpenColorIO (eg. __sub__). Consequence is we don't
-  # support python 2.7, alternatively build without docstrings, or
-  # fix the doxygen issue.
-  #
-  # When installing doc environment, Python package are not used as the wheel
-  # is built in it's own isolated environment, hence package are listed again
-  # in pyproject.toml.
-  #
+  # Due to documentation build failing on manylinux2010 (maybe too old doxygen
+  # version), we build on manylinux2014 image, this requires pip >= 19.3.
 
   # ---------------------------------------------------------------------------
-  # Linux
+  # Source Distribution
+  # ---------------------------------------------------------------------------
+
+  sdist:
+    name: Build SDist
+    runs-on: ubuntu-latest
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+
+    steps:
+
+    - uses: actions/checkout@v2
+
+    - name: Build SDist
+      run: pipx run build --sdist
+
+    - name: Check metadata
+      run: pipx run twine check dist/*
+
+    - uses: actions/upload-artifact@v2
+      with:
+        path: dist/*.tar.gz
+
+  # ---------------------------------------------------------------------------
+  # Linux Wheels
   # ---------------------------------------------------------------------------
 
   linux:
     name: Build wheels on Linux
     runs-on: ubuntu-latest
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
     strategy:
       matrix:
         include:
           # -------------------------------------------------------------------
-          # CPython 32 bits
-          # -------------------------------------------------------------------
-          - build: CPython 3.6 32 bits
-            python: cp36-*
-            arch: i686
-          - build: CPython 3.7 32 bits
-            python: cp37-*
-            arch: i686
-          - build: CPython 3.8 32 bits
-            python: cp38-*
-            arch: i686
-          - build: CPython 3.9 32 bits
-            python: cp39-*
-            arch: i686
-          # -------------------------------------------------------------------
           # CPython 64 bits
           # -------------------------------------------------------------------
-          - build: CPython 3.6 64 bits
-            python: cp36-*
-            arch: x86_64
           - build: CPython 3.7 64 bits
-            python: cp37-*
+            python: cp37-manylinux*
             arch: x86_64
           - build: CPython 3.8 64 bits
-            python: cp38-*
+            python: cp38-manylinux*
             arch: x86_64
           - build: CPython 3.9 64 bits
-            python: cp39-*
+            python: cp39-manylinux*
             arch: x86_64
+          - build: CPython 3.10 64 bits
+            python: cp310-manylinux*
+            arch: x86_64
+          - build: CPython 3.11 64 bits
+            python: cp311-manylinux*
+            arch: x86_64
+          # -------------------------------------------------------------------
+          # CPython ARM 64 bits
+          # -------------------------------------------------------------------
+          - build: CPython 3.7 ARM 64 bits
+            python: cp37-manylinux*
+            arch: aarch64
+          - build: CPython 3.8 ARM 64 bits
+            python: cp38-manylinux*
+            arch: aarch64
+          - build: CPython 3.9 ARM 64 bits
+            python: cp39-manylinux*
+            arch: aarch64
+          - build: CPython 3.10 ARM 64 bits
+            python: cp310-manylinux*
+            arch: aarch64
+          - build: CPython 3.11 ARM 64 bits
+            python: cp311-manylinux*
+            arch: aarch64
 
     steps:
       - uses: actions/checkout@v2
@@ -91,38 +122,38 @@ jobs:
         with:
           python-version: '3.8'
 
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v1
+        with:
+          platforms: all
+
       - name: Build wheels
-        uses: joerick/cibuildwheel@v1.12.0
+        uses: pypa/cibuildwheel@v2.11.2
         env:
-          CIBW_MANYLINUX_X86_64_IMAGE: manylinux2014
-          CIBW_MANYLINUX_I686_IMAGE: manylinux2014
-          CIBW_BUILD_VERBOSITY: 1
           CIBW_BUILD: ${{ matrix.python }}
           CIBW_ARCHS: ${{ matrix.arch }}
-          CIBW_BEFORE_BUILD: share/ci/scripts/linux/yum/install_docs_env.sh
-          CIBW_TEST_REQUIRES: numpy
-          CIBW_TEST_COMMAND: python -m PyOpenColorIOTests.OpenColorIOTestSuite
 
       - uses: actions/upload-artifact@v2
         with:
           path: ./wheelhouse/*.whl
 
   # ---------------------------------------------------------------------------
-  # macOS
+  # macOS Wheels
   # ---------------------------------------------------------------------------
 
   macos:
     name: Build wheels on macOS
     runs-on: macos-10.15
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
     strategy:
       matrix:
         include:
           # -------------------------------------------------------------------
           # CPython 64 bits
           # -------------------------------------------------------------------
-          - build: CPython 3.6 64 bits
-            python: cp36-*
-            arch: x86_64
           - build: CPython 3.7 64 bits
             python: cp37-*
             arch: x86_64
@@ -132,6 +163,12 @@ jobs:
           - build: CPython 3.9 64 bits
             python: cp39-*
             arch: x86_64
+          - build: CPython 3.10 64 bits
+            python: cp310-*
+            arch: x86_64
+          - build: CPython 3.11 64 bits
+            python: cp311-*
+            arch: x86_64
           # -------------------------------------------------------------------
           # CPython ARM 64 bits
           # -------------------------------------------------------------------
@@ -141,6 +178,12 @@ jobs:
           - build: CPython 3.9 ARM 64 bits
             python: cp39-*
             arch: arm64
+          - build: CPython 3.10 ARM 64 bits
+            python: cp310-*
+            arch: arm64
+          - build: CPython 3.11 ARM 64 bits
+            python: cp311-*
+            arch: arm64
 
     steps:
       - uses: actions/checkout@v2
@@ -151,50 +194,32 @@ jobs:
           python-version: '3.8'
 
       - name: Build wheels
-        uses: joerick/cibuildwheel@v1.12.0
+        uses: pypa/cibuildwheel@v2.11.2
         env:
-          CIBW_BUILD_VERBOSITY: 1
           CIBW_BUILD: ${{ matrix.python }}
           CIBW_ARCHS: ${{ matrix.arch }}
-          CIBW_BEFORE_BUILD: share/ci/scripts/macos/install_docs_env.sh
-          CIBW_TEST_REQUIRES: numpy
-          CIBW_TEST_COMMAND: python -m PyOpenColorIOTests.OpenColorIOTestSuite
 
       - uses: actions/upload-artifact@v2
         with:
           path: ./wheelhouse/*.whl
 
   # ---------------------------------------------------------------------------
-  # Windows
+  # Windows Wheels
   # ---------------------------------------------------------------------------
 
   windows:
     name: Build wheels on Windows
     runs-on: windows-2019
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
     strategy:
       matrix:
         include:
           # -------------------------------------------------------------------
-          # CPython 32 bits
-          # -------------------------------------------------------------------
-          - build: CPython 3.6 32 bits
-            python: cp36-*
-            arch: x86
-          - build: CPython 3.7 32 bits
-            python: cp37-*
-            arch: x86
-          - build: CPython 3.8 32 bits
-            python: cp38-*
-            arch: x86
-          - build: CPython 3.9 32 bits
-            python: cp39-*
-            arch: x86
-          # -------------------------------------------------------------------
           # CPython 64 bits
           # -------------------------------------------------------------------
-          - build: CPython 3.6 64 bits
-            python: cp36-*
-            arch: AMD64
           - build: CPython 3.7 64 bits
             python: cp37-*
             arch: AMD64
@@ -204,6 +229,12 @@ jobs:
           - build: CPython 3.9 64 bits
             python: cp39-*
             arch: AMD64
+          - build: CPython 3.10 64 bits
+            python: cp310-*
+            arch: AMD64
+          - build: CPython 3.11 64 bits
+            python: cp311-*
+            arch: AMD64
 
     steps:
       - uses: actions/checkout@v2
@@ -214,14 +245,10 @@ jobs:
           python-version: '3.8'
 
       - name: Build wheels
-        uses: joerick/cibuildwheel@v1.12.0
+        uses: pypa/cibuildwheel@v2.11.2
         env:
-          CIBW_BUILD_VERBOSITY: 1
           CIBW_BUILD: ${{ matrix.python }}
           CIBW_ARCHS: ${{ matrix.arch }}
-          CIBW_BEFORE_BUILD: bash -c share/ci/scripts/windows/install_docs_env.sh
-          CIBW_TEST_REQUIRES: numpy
-          CIBW_TEST_COMMAND: python -m PyOpenColorIOTests.OpenColorIOTestSuite
 
       - uses: actions/upload-artifact@v2
         with:
@@ -229,7 +256,7 @@ jobs:
 
 
   upload_pypi:
-    needs: [linux, macos, windows]
+    needs: [sdist, linux, macos, windows]
     runs-on: ubuntu-latest
     if: github.event_name == 'push' && startsWith(github.event.ref, 'refs/tags/v')
     steps:

ASWF/Charter.md

@@ -52,7 +52,7 @@ This charter (the "Charter") sets forth the responsibilities and proce
 7. Intellectual Property Policy
   * **a.** Participants acknowledge that the copyright in all new contributions shall be retained by the copyright holder as independent works of authorship and that no contributor or copyright holder will be required to assign copyrights to the Project.
   * **b.** Except as described in Section 7.c., all code contributions to the Project are subject to the following:
-    * **i.** All new inbound code contributions to the Project must be made using the **BSD 3-Clause License (available here: [https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE))** (the "Project License").
+    * **i.** All new inbound code contributions to the Project must be made using the **BSD 3-Clause License (available here: [https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE))** (the "Project License").
     * **ii.** All new inbound code contributions must:
       1. be made pursuant to a duly executed Project Contribution License Agreement (the "CLA"), available on the Project's web site; and
       2. be accompanied by a Developer Certificate of Origin ([http://developercertificate.org](http://developercertificate.org)) sign-off in the source code system that is submitted through a TSC-approved contribution process which will bind the authorized contributor and, if not self-employed, their employer to the applicable license;

ASWF/meetings/tsc/2019-02-04.md

@@ -36,7 +36,7 @@ Attendees:
 * Infrastructure
   * GitHub repo needs migrating to the ASWF organisation
   * **TODO** - John Mertic to coordinate with Steve Winslow at the LF to complete.
-  * https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md
+  * https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md
 * Require that any existing copyright notices are reviewed and amended by the current stated owners if their respective legal agrees.
   * Once migrated will enable DCO sign off checking and CLA checks.
 * Sub-discussion on the option of separate sign off for committer vs developer sign off.

ASWF/meetings/tsc/2019-02-11.md

@@ -44,9 +44,9 @@ Attendees:
     * Do a patch against 1.1 that fixes a few minor things?
         * Consensus is that we should make 1.1.1 with some important non-breaking patches and release that fix right away.
         * **TODO**: Patrick will send Slack the list of candidate commits for a 1.1.1.
-    * Do we make an intermediate release from master before v2.0? People want a "developer preview" to be able to use the new GPU path.
+    * Do we make an intermediate release from main before v2.0? People want a "developer preview" to be able to use the new GPU path.
         * Patrick reluctant to make a full release.
-        * Proposal: just make a "developer preview" tag in master to designate a point we think is stable and has some helpful new features, but we don't promise any support or compatibility with the eventual v2.
+        * Proposal: just make a "developer preview" tag in main to designate a point we think is stable and has some helpful new features, but we don't promise any support or compatibility with the eventual v2.
             * Down side: people will use it and expect us to support it.
             * No consensus that this is a good idea. Mark especially doesn't like unsupported dev preview tag.
             * But v2 will NOT be ready by SIGGRAPH 2019. In light of this, Mark thinks maybe we should have a real intermediate release.

ASWF/meetings/tsc/2019-03-04.md

@@ -26,7 +26,7 @@ Attendees:
         - Doug: As established in the initial 2.0 proposal, this is not feasible.
         - The plan remains to release a complete feature set when the full v2 roadmap is completed.
     - Community concern is that the v2 release schedule is unknown, and time between OCIO releases is long.
-        - This can make planning for software vendors challenging, but preliminary implementation of the v2 interface is possible now from master for testing.
+        - This can make planning for software vendors challenging, but preliminary implementation of the v2 interface is possible now from main for testing.
         - Autodesk discussing an official roadmap and insight on a potential release window. Stay tuned.
         - Long PR review cycles contribute to development slowdowns:
             - Most PRs are merged with the 2 week single reviewer clause.
@@ -37,7 +37,7 @@ Attendees:
                 - PRs are becoming smaller, more focused, which should help with review accessability
             - **TODO**: Doug/Patrick to review and report back on what project management changes could help them
     - Larry: Should we have a known commit for testing a given feature (i.e. GPU renderer) for internal testing purposes.
-        - Doug: Testing off of master at any given time is stable, and ideal.
+        - Doug: Testing off of main at any given time is stable, and ideal.
 
 * ASWF/LF CI update from TAC meeting
     - Thanh presented comparison of Circle CI and current Jenkins infrastructure:

ASWF/meetings/tsc/2019-03-18.md

@@ -43,7 +43,7 @@ Attendees:
     - Any recommendations from LF regarding what to add to CI?
         - Thanh: Some options are Nexus IQ, WhiteSource for security, Sonar Qube for static.
         - Thanh is doing some investigation for TAC, we will follow closely for recommendations.
-    - John provide the following link: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/security.md
+    - John provide the following link: https://github.com/coreinfrastructure/best-practices-badge/blob/main/doc/security.md
     - Chair asked John if we were moving too slowly, John: no.
 
 * 1.1.1 Release

ASWF/meetings/tsc/2019-06-10.md

@@ -29,7 +29,7 @@ Apologies:
         - Waiting approval
 
 * Azure CI Build:
-    - Larry G.: Needs to build OCIO with some dependency master branch to trap coming issues?
+    - Larry G.: Needs to build OCIO with some dependency main branch to trap coming issues?
         - Larry G. Only some libraries:
             As OpenEXR is an indirect dependency, perhaps not needed.
             But OIIO could be a good candidate.

ASWF/meetings/tsc/2019-08-05.md

@@ -38,7 +38,7 @@ Apologies:
       Meatballs” images with Sony.
     - Kevin: We also need to update the LICENSE on the OCIO website
     - Michael: That is pulled from GitHub, but currently from the RB-1.1 
-      branch. Since the license cleanup work is being done in master, is it Ok 
+      branch. Since the license cleanup work is being done in main, is it Ok 
       to wait for a 2.0 release next year to update the site?
     - John: That should be Ok.
     - Kevin: Let’s make a note to not forget it.

ASWF/meetings/tsc/2019-08-19.md

@@ -30,8 +30,8 @@ Attendees:
 * RB-1.1
     - Michael: Following the approval for another minor release (*TSC meeting 2019-08-12*),
       Travis & AppVeyor (i.e. the former CI build) are back for the RB-1.1 branch only.
-        - AppVeyor uses RB-1.1 & master branch
-            - **TODO**: Sean will help to disable master.
+        - AppVeyor uses RB-1.1 & main branch
+            - **TODO**: Sean will help to disable main.
         - Travis triggers new warnings/errors.
           Check [PR 798](https://github.com/imageworks/OpenColorIO/pull/798) for details.
             - Agreed to fix them.

ASWF/meetings/tsc/2019-09-16.md

@@ -28,7 +28,7 @@ Apologies:
     - Doug raised that pull request #831 removes macros specific to these versions of GCC.
     - Patrick raised that as we add more C+11 features the more we will be restricted.
     - Kevin thinks we should definitely drop support for GCC 3.
-    - Patrick thought dropping GCC 3 would be fine and should be done in the master branch.
+    - Patrick thought dropping GCC 3 would be fine and should be done in the main branch.
 
 * Azure CI build
     - Patrick raised that the communication between Azure and Github is broken.

ASWF/meetings/tsc/2019-10-28.md

@@ -26,7 +26,7 @@ Attendees:
     - To document the policy concerning repository rights vs. roles.
 
 * Branch protected
-    - Agreement to only protect `master`, `RB-**` and `gh-pages`.
+    - Agreement to only protect `main`, `RB-**` and `gh-pages`.
 
 * Stalled pull requests
     - Agreement to not have any automatic removal of stalled pull requests.

ASWF/meetings/tsc/2020-02-03.md

@@ -32,7 +32,7 @@ Attendees:
 * ASWF GSoC discussion
     - Polled Slack for project ideas for ASWF's application to Google Summer of 
       Code, and submitted PR to: 
-      `https://github.com/AcademySoftwareFoundation/tac/blob/master/gsoc/README.md`_
+      `https://github.com/AcademySoftwareFoundation/tac/blob/main/gsoc/README.md`_
     - In summary, four projects initially proposed:
           - Add Metal, Vulkan, or CUDA language support to GPU renderer
           - Restore Java bindings
@@ -52,7 +52,7 @@ Attendees:
     
 * Python bindings
     - Michael: Resumed work on pybind11 bindings. Got everything up to date with 
-      master.
+      main.
     - Mei Chu (Imageworks) is interested in helping with this work, potentially 
       designing unit tests to start.
           - Mei: Looking forward to getting more involved in OCIO

ASWF/meetings/tsc/2020-03-23.md

@@ -61,7 +61,7 @@ Apologies: Michael Dolan
         in what types of EXR images may be read (e.g. looking for a specific channel layout,
         no multi-part support).
     - Kevin: A quick scan of the EXR codec shows it only really outputs 16 bit RGB, RGBA, YCbCr.
-        
https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/exr.c#L1691

+        
https://github.com/FFmpeg/FFmpeg/blob/main/libavcodec/exr.c#L1691

         - Mark: Is that integer 16 bit?

         - Kevin: Yes, integers.
     - Mark: One approach would be to make video filters for OCIO ColorSpaceTransform and

ASWF/meetings/tsc/2020-05-18.md

@@ -70,7 +70,7 @@ Apologies:
     - Carol: A lot of it can hopefully be to work with DCC vendors to help them 
       update their docs as well, and to understand coming changes. Then we can 
       point our docs to theirs.
-    - Michael: The [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/docs/CompatibleSoftware.rst) 
+    - Michael: The [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/docs/CompatibleSoftware.rst) 
       page of the OCIO website was updated recently and contains many 
       up-to-date documentation links.
     - Doug: Also may want to add OCIO developers to the list of consumers, to 

ASWF/meetings/tsc/2020-07-20.md

@@ -87,7 +87,7 @@ Apologies:
     - Sean: Docstring header PR is in. Need another PR for pybind11 docstring 
       header, and another for reorganization of doc structure. The RTD page 
       points to official OCIO repo, so we're live now, but API docs and new 
-      style is missing. Any changes to master are getting pushed to RTD now. 
+      style is missing. Any changes to main are getting pushed to RTD now. 
       Not as much holding back docs as it seems. 
     - Simran: An event hook in GH communicates to RTD when to update the site.
     - Michael: Can we open GH issues for logical chunks of work?

ASWF/meetings/tsc/2021-01-04.md

@@ -100,10 +100,10 @@ Apologies:
       begin that?
     - Kevin: If we create them together we are saying they are the same. If 
       separated, might be different.
-    - Patrick: Where do we put the tag? In master or in RB-2.0?
-    - Mark: Have it in both, and cherry pick master changes into RB-2.0.
-    - Patrick: Only consequence is master will be tagged as RC.
-    - All agree to create tag in master and branch RB-2.0 from that.
+    - Patrick: Where do we put the tag? In main or in RB-2.0?
+    - Mark: Have it in both, and cherry pick main changes into RB-2.0.
+    - Patrick: Only consequence is main will be tagged as RC.
+    - All agree to create tag in main and branch RB-2.0 from that.
 
 * General discussion:
     - Kevin: If we are concerned with ABI compatibility, should we put 

ASWF/meetings/working_groups/documentation/2020-06-12.md

@@ -69,7 +69,7 @@ Attendees:
     - Alexa: Better to link to DCC vendors own guides.
     - Michael: There is some of that on the site now in the Compatible Software 
       page, which was updated recently: 
-      [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/docs/CompatibleSoftware.rst)
+      [Compatible Software](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/docs/CompatibleSoftware.rst)
     - Carol: Tricky to know which vendors to include tutorials for.
     - Alexa: Could be better to explain the config, and what each part means. 
       It's difficult to find everything right now.

ASWF/meetings/working_groups/ocio_v2/2020-01-23.md

@@ -30,7 +30,7 @@ Recording on Zoom cloud:
    - Mark: Is ociocheck crashing for anyone?
    - Doug: We will look into it.
    - *UPDATE:* We tested this and it is working.  We found a case where illegal
-(too long) spi1d LUTs caused a crash in master.  These LUTs were not flagged as
+(too long) spi1d LUTs caused a crash in main.  These LUTs were not flagged as
 being illegal in OCIO v1 and would have had incorrect results.
 
 **STRING UTILS**

ASWF/meetings/working_groups/ocio_v2/2020-02-27.md

@@ -218,7 +218,7 @@ discussion about the questions raised.
 
 **GENERAL DISCUSSION**
 
-   - Mark:  I was testing master and found that role names are now
+   - Mark:  I was testing main and found that role names are now
 case-sensitive.  This is a change from OCIO v1.
    - Doug:  Are we agreed we want case-insensitive behavior?  Same for color
 spaces too?   Group agreed.

CMakeLists.txt

@@ -28,7 +28,7 @@ endif()
 # Project definition.
 
 project(OpenColorIO 
-    VERSION 2.1.0
+    VERSION 2.2.1
     DESCRIPTION "OpenColorIO (OCIO) is a complete color management solution"
     HOMEPAGE_URL https://github.com/AcademySoftwareFoundation/OpenColorIO
     LANGUAGES CXX C)
@@ -36,9 +36,22 @@ project(OpenColorIO
 # "dev", "beta1", rc1", etc or "" for an official release.
 set(OpenColorIO_VERSION_RELEASE_TYPE "")
 
+
+###############################################################################
+# ctest
+
+# To correctly generate the DartConfiguration.tcl, include the CTest CMake file.
+# By doing so 'ctest -F memcheck' works.
+include (CTest)
+
 enable_testing()
 
 
+###############################################################################
+# Provides install directory variables as defined by the GNU Coding Standards.
+include(GNUInstallDirs)
+
+
 ###############################################################################
 # Forbid in-source build.
 
@@ -126,12 +139,17 @@ option(OCIO_BUILD_JAVA "Specify whether to build java bindings" OFF)
 
 option(OCIO_WARNING_AS_ERROR "Set build error level for CI testing" OFF)
 
+if (WIN32)
+    option(OCIO_USE_WINDOWS_UNICODE "Compile with Windows Unicode support" ON)
+endif()
+
 
 ###############################################################################
 # Optimization / internal linking preferences
 
 option(OCIO_USE_SSE "Specify whether to enable SSE CPU performance optimizations" ON)
-option(OCIO_USE_OPENEXR_HALF "Specify whether to use an OpenEXR/IlmBase install of the Half library (<=v2.5) instead of the newer Imath library (>=v3.0)" OFF)
+option(OCIO_USE_OIIO_CMAKE_CONFIG "Specify whether to look for OIIO using the generated CMake Config script instead of the custom FindOpenImageIO.cmake script" OFF)
+option(OCIO_USE_OIIO_FOR_APPS "Request OIIO to build apps (ociolutimage, ocioconvert and ociodisplay), the default uses OpenEXR." OFF)
 
 
 ###############################################################################
@@ -189,12 +207,12 @@ endif()
 
 if(NOT DEFINED OCIO_NAMESPACE)
 	set(OCIO_NAMESPACE "OpenColorIO_v${OpenColorIO_VERSION_MAJOR}_${OpenColorIO_VERSION_MINOR}${OpenColorIO_VERSION_RELEASE_TYPE}" CACHE STRING 
-        "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
+        "Specify the main OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
 elseif(OCIO_NAMESPACE STREQUAL "")
     message(FATAL_ERROR "A namespace cannot be empty.")
 else()
     set(OCIO_NAMESPACE "OpenColorIO_${OCIO_NAMESPACE}_v${OpenColorIO_VERSION_MAJOR}_${OpenColorIO_VERSION_MINOR}${OpenColorIO_VERSION_RELEASE_TYPE}" CACHE STRING 
-        "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
+        "Specify the main OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
     message(STATUS "Setting namespace to '${OCIO_NAMESPACE}' as none was specified.")
 endif()
 
@@ -233,6 +251,15 @@ if(OCIO_BUILD_STATIC)
 	endif()
 endif()
 
+if (NOT BUILD_SHARED_LIBS AND NOT OCIO_INSTALL_EXT_PACKAGES STREQUAL NONE)
+   message(STATUS "Note that building the static version of OpenColorIO does not embed the dependencies\  
+   into the library file. The needed dependencies must be linked to the consumer
+   application or shared library that uses static OpenColorIO.
+
+   The following mandatory dependencies MUST be linked to the consumer application or shared library:
+   expat, yaml-cpp, Imath, pystring, minizip-ng and ZLIB")
+endif()
+
 
 ###############################################################################
 # Find or install external dependencies
@@ -246,20 +273,12 @@ include(FindExtPackages)
 ###############################################################################
 # Progress to other sources
 
-# The presence of OpenImageIO allows additional ocio apps and the OSL translation unit tests
-# to be built.
-
-# OpenImageIO
-# https://github.com/OpenImageIO/oiio
-find_package(OpenImageIO 2.1.9)
-
 add_subdirectory(vendor)
 if(OCIO_BUILD_DOCS)
 	add_subdirectory(docs)
 endif()
 add_subdirectory(tests)
 add_subdirectory(src)
-add_subdirectory(include)
 add_subdirectory(ext)
 
 
@@ -275,7 +294,7 @@ endif()
 configure_file(${CMAKE_SOURCE_DIR}/share/ocio/${OCIO_SETUP_NAME}.in
     ${CMAKE_CURRENT_BINARY_DIR}/share/ocio/${OCIO_SETUP_NAME} @ONLY)
 
-INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/share/ocio/${OCIO_SETUP_NAME} DESTINATION share/ocio/)
+INSTALL(FILES ${CMAKE_CURRENT_BINARY_DIR}/share/ocio/${OCIO_SETUP_NAME} DESTINATION ${CMAKE_INSTALL_DATADIR}/ocio/)
 
 
 ###############################################################################
@@ -289,6 +308,8 @@ set(OCIO_TARGETS_EXPORT_NAME "${PROJECT_NAME}Targets.cmake")
 set(OCIO_VERSION_CONFIG "${CMAKE_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake")
 set(OCIO_PROJECT_CONFIG "${CMAKE_BINARY_DIR}/${PROJECT_NAME}Config.cmake")
 set(OCIO_CONFIG_INSTALL_DIR "${CMAKE_INSTALL_LIBDIR}/cmake/${PROJECT_NAME}")
+set(OCIO_CUSTOM_FIND_MODULE_DIR "${CMAKE_INSTALL_PREFIX}/share/OpenColorIO/cmake/modules")
+set(OCIO_CUSTOM_MACROS_MODULE_DIR "${CMAKE_INSTALL_PREFIX}/share/OpenColorIO/cmake/macros")
 
 # Version fetched from the top level project()
 write_basic_package_version_file(
@@ -311,6 +332,24 @@ install(
     FILE ${OCIO_TARGETS_EXPORT_NAME}
 )
 
+if (NOT BUILD_SHARED_LIBS)
+    # Install custom macros used in the find modules.
+    install(FILES
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/macros/VersionUtils.cmake
+        DESTINATION ${OCIO_CUSTOM_MACROS_MODULE_DIR}
+    )
+
+    # Install custom Find modules.
+    install(FILES
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/modules/Findexpat.cmake
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/modules/FindImath.cmake
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/modules/Findpystring.cmake
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/modules/Findminizip-ng.cmake
+        ${CMAKE_CURRENT_LIST_DIR}/share/cmake/modules/Findyaml-cpp.cmake
+        DESTINATION ${OCIO_CUSTOM_FIND_MODULE_DIR}
+    )
+endif()
+
 install(
     FILES "${OCIO_PROJECT_CONFIG}" "${OCIO_VERSION_CONFIG}"
     DESTINATION "${OCIO_CONFIG_INSTALL_DIR}"

COMMITTERS.md

@@ -19,3 +19,5 @@ The current OpenColorIO Committers are:
 | Cottalango Leon | @loorthu
 | Doug Walker | @doug-walker |
 | Kevin Wheatley | @KevinJW |
+| Rémi Achard | @remia |
+| Cédrik Fuoco | @cedrik-fuoco-adsk |

CONTRIBUTING.md

@@ -19,7 +19,7 @@ explains our contribution process and procedures, so please review it first:
 For a description of the roles and responsibilities of the various
 members of the OpenColorIO community, see [GOVERNANCE](GOVERNANCE.md), and
 for further details, see the project's
-[Technical Charter](docs/aswf/Charter.md). Briefly, Contributors are anyone
+[Technical Charter](ASWF/Charter.md). Briefly, Contributors are anyone
 who submits content to the project, Committers review and approve such
 submissions, and the Technical Steering Committee provides general project
 oversight.
@@ -91,7 +91,7 @@ can be merged.
   [Corporate Contributor Licence Agreement](https://docs.linuxfoundation.org/lfx/easycla/contributors/corporate-contributor).
 
 The OCIO CLA's are the standard forms used by Linux Foundation projects and
-[recommended by the ASWF TAC](https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contributor-license-agreement-cla).
+[recommended by the ASWF TAC](https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contributor-license-agreement-cla).
 
 ### Commit Sign-Off
 
@@ -113,7 +113,7 @@ can be merged. Otherwise the EasyCLA system will provide instructions on
 signing a CLA, or request inclusion in an existing corporate CLA approved list.
 
 See the
-[ASWF TAC CONTRIBUTING.md](https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contribution-sign-off)
+[ASWF TAC CONTRIBUTING.md](https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contribution-sign-off)
 file for more information on this requirement.
 
 ### Copyright Notices
@@ -161,15 +161,15 @@ You are now ready to contribute.
 The OpenColorIO repository has a relatively straight-forward structure, and a
 simple branching and merging strategy.
 
-All development work is done directly on the master branch. This represents the
+All development work is done directly on the main branch. This represents the
 bleeding-edge of the project and any contributions should be done on top of it.
 
-After sufficient work is done on the master branch and OCIO leadership
+After sufficient work is done on the main branch and OCIO leadership
 determines that a release is due, we will bump the relevant internal versioning
 and tag a commit with the corresponding version number, e.g. v2.0.1. Each Minor
 version also has its own “Release Branch”, e.g. RB-1.1. This marks a branch of
 code dedicated to that Major.Minor version, which allows upstream bug fixes to
-be cherry-picked to a given version while still allowing the master branch to
+be cherry-picked to a given version while still allowing the main branch to
 continue forward onto higher versions. This basic repository structure keeps
 maintenance low, while remaining simple to understand.
 
@@ -183,7 +183,7 @@ Please review [PROCESS.md](PROCESS.md) for important procedures related to
 making changes to OpenColorIO. Small bug fixes and documentation changes can be
 more informal, but modifications to core OpenColorIO functionality MUST follow
 the 
-[Core Library Changes](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/PROCESS.md#Core-Library-Changes) process.
+[Core Library Changes](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/PROCESS.md#Core-Library-Changes) process.
 
 The development cycle for a code change should follow this protocol:
 
@@ -210,22 +210,24 @@ who may discuss, offer constructive feedback, request changes, or approve
 the work.
 
 7. Upon receiving the required number of Committer approvals (as outlined in 
-[Required Approvals](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/PROCESS.md#Required-Approvals)), 
+[Required Approvals](https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/PROCESS.md#Required-Approvals)), 
 a Committer other than the PR contributor may squash and merge changes into the 
-master branch.
+main branch.
 
-See also (from the OCIO Developer Guide):
-* [Getting started](http://opencolorio.org/developers/getting_started.html)
-* [Submitting Changes](http://opencolorio.org/developers/submitting_changes.html)
+For a more detailed description of the contribution process, please see the 
+Contributing Guide in the main OCIO documentation:
+
+* [Getting Started](https://opencolorio.readthedocs.io/en/latest/guides/contributing/contributing.html#getting-started)
+* [Submitting Changes](https://opencolorio.readthedocs.io/en/latest/guides/contributing/contributing.html#submitting-changes)
 
 ## Coding Standards
 
 Please see the OpenColorIO
-[Coding guidelines](http://opencolorio.org/developers/coding_guidelines.html)
+[Coding guidelines](https://opencolorio.readthedocs.io/en/latest/guides/contributing/contributing.html#coding-style-guide)
 for a reference on project code style and best practices.
 
 For standards on contributing to documentation, see the
-[Documentation guidelines](http://opencolorio.org/developers/documentation_guidelines.html).
+[Documentation guidelines](https://opencolorio.readthedocs.io/en/latest/guides/contributing/contributing.html#documentation-guidelines).
 
 ## Test Policy
 
@@ -245,27 +247,8 @@ The test should should be run, via ``ctest``, before submitting a pull request.
 
 ## Versioning Policy
 
-OpenColorIO uses [semantic versioning](https://semver.org), which labels each
-version with three numbers: Major.Minor.Patch, where:
+OpenColorIO labels each version with three numbers: Major.Minor.Patch, where:
 
-* **MAJOR** indicates incompatible API changes
-* **MINOR** indicates functionality added in a backwards-compatible manner
-* **PATCH** indicates backwards-compatible bug fixes
-
-## Creating a Release
-
-To create a new release from the master branch:
-
-1. Update the release notes in ``CHANGELOG.md`` with a high-level summary of
-   the features and improvements. Also include the summary in the Release
-   comments.
-
-2. Create a new release on the GitHub Releases page.
-
-3. Tag the release with name beginning with '``v``', e.g. '``v2.1.0``'.
-
-4. Download and sign the release tarball, as described
-   [here](https://wiki.debian.org/Creating%20signed%20GitHub%20releases),
-
-5. Attach the detached ``.asc`` signature file to the GitHub release as a
-   binary file.
+* **MAJOR** indicates major architectural changes
+* **MINOR** indicates an introduction of significant new features
+* **PATCH** indicates ABI-compatible bug fixes and minor enhancements

GOVERNANCE.md

@@ -107,12 +107,13 @@ project at all ASWF TAC meetings.
 
 ### TSC Leaders
 
-* Chair: Michael Dolan
+* Chair: Carol Payne
 * Chief Architect: Doug Walker
 * ACES TAC Rep: Sean Cooper
 
 ### TSC Members
 
+* Rémi Achard - DNEG
 * Mark Boorer - Industrial Light & Magic
 * Mei Chu - Sony Pictures Imageworks
 * Sean Cooper - ARRI

MANIFEST.in

@@ -1,2 +1,8 @@
-graft tests/data
-exclude tests/data/CMakeLists.txt
+include LICENSE
+graft docs
+graft ext
+graft include
+graft share
+graft src
+graft tests
+global-include CMakeLists.txt *.cmake *.md

PROCESS.md

@@ -28,7 +28,7 @@ across the project so are treated as core changes.
    [ocio-dev](https://lists.aswf.io/g/ocio-dev), but are ultimately brought to a 
    TSC meeting where consensus can be reached around the proposal's relevance 
    and approach. TSC meetings are public and meeting notes are posted to the 
-   [OCIO repo](https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/master/ASWF/meetings/tsc) 
+   [OCIO repo](https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/ASWF/meetings/tsc) 
    within days of a meeting for a permanent record of decisions.
 2. Following acceptance of the proposal by the TSC, an issue is created in 
    GitHub to present a design proposal. A period of further community 

THIRD-PARTY.md

@@ -9,32 +9,6 @@ In no particular order:
 
 ---------------------------------------------------------------------
 
-MD5, courtesy of L. Peter Deutsch, Aladdin Enterprises.
-http://sourceforge.net/projects/libmd5-rfc/files/
-
-Copyright (C) 1999, 2002 Aladdin Enterprises.  All rights reserved.
-
-This software is provided 'as-is', without any express or implied
-warranty.  In no event will the authors be held liable for any damages
-arising from the use of this software.
-
-Permission is granted to anyone to use this software for any purpose,
-including commercial applications, and to alter it and redistribute it
-freely, subject to the following restrictions:
-
-1. The origin of this software must not be misrepresented; you must not
-   claim that you wrote the original software. If you use this software
-   in a product, an acknowledgment in the product documentation would be
-   appreciated but is not required.
-2. Altered source versions must be plainly marked as such, and must not be
-   misrepresented as being the original software.
-3. This notice may not be removed or altered from any source distribution.
-
-L. Peter Deutsch
-ghost@aladdin.com
-
----------------------------------------------------------------------
-
 argparse, courtesy of OpenImageIO and Larry Gritz
 http://openimageio.org
 
@@ -229,4 +203,33 @@ England
 
 ---------------------------------------------------------------------
 
+xxHash Library
+Copyright (c) 2012-2021 Yann Collet
+All rights reserved.
+
+BSD 2-Clause License (https://www.opensource.org/licenses/bsd-license.php)
+
+Redistribution and use in source and binary forms, with or without modification,
+are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice, this
+  list of conditions and the following disclaimer in the documentation and/or
+  other materials provided with the distribution.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+---------------------------------------------------------------------
+
 If we have left anything out, it is unintentional. Please let us know.

buildspec.yml

@@ -41,7 +41,6 @@ phases:
         cmake ../. \
               -DCMAKE_INSTALL_PREFIX=../_install \
               -DOCIO_USE_HEADLESS=ON \
-              -DOCIO_USE_OPENEXR_HALF=ON \
               -DOCIO_BUILD_APPS=ON \
               -DOCIO_BUILD_DOCS=OFF \
               -DOCIO_BUILD_TESTS=ON \

docs/Doxyfile.in

@@ -1301,7 +1301,7 @@ CHM_FILE               =
 HHC_LOCATION           =
 
 # The GENERATE_CHI flag controls if a separate .chi index file is generated
-# (YES) or that it should be included in the master .chm file (NO).
+# (YES) or that it should be included in the main .chm file (NO).
 # The default value is: NO.
 # This tag requires that the tag GENERATE_HTMLHELP is set to YES.
 

docs/V2_DOC_README.md

@@ -1,106 +0,0 @@
-# OCIO v2 Documentation Effort
-
-Since the API autodoc effort is happening simultaneously it will be easier for
-a lot of contributors to do a light-weight build of the Sphinx docs, which
-doesn't require building OCIO in its entirety.
-
-## How to Build HTML Docs
-
-In addition to the general OCIO v2 dependencies, install Doxygen, Sphinx, and 
-the Python packages listed in the `docs/requirements.txt` file.
-
-Doxygen can be installed with a package manager, or by downloading a binary 
-distribution from [Doxygen's website](https://www.doxygen.nl/download.html). 
-Use one of the following commands to install Doxygen with a platform-specific 
-package manager:
-
-Linux (Debian, etc.):
-
-```
-apt-get install doxygen
-```
-
-Linux (Fedora, etc.):
-
-```
-yum install doxygen
-```
-
-macOS ([Homebrew](https://brew.sh/)):
-
-```
-brew install doxygen
-```
-
-Windows ([Chocolatey](https://chocolatey.org/)):
-
-```
-choco install doxygen.install
-```
-
-Sphinx and the other Python dependencies can be installed with a single `pip` 
-command on all platforms:
-
-```
-pip install -r docs/requirements.txt
-```
-
-To build only the RST docs (excluding API) locally:
-
-```
-cd docs
-mkdir _build
-sphinx-build -b html . _build
-<your web browser name> _build/index.html
-```
-
-To build all HTML docs (including API) locally:
-
-```
-mkdir _build
-cd _build
-cmake ../. -DOCIO_BUILD_DOCS=ON -DCMAKE_INSTALL_PREFIX=../_install
-make -j<your thread count> docs
-<your web browser name> docs/build-html/index.html
-```
-
-Python 3 is required to build the documentation. If you have multiple Python
-installs you'll need to make sure pip and CMake find the correct version. You 
-can manually inform cmake of which to use by adding this option to the above 
-`cmake` command, which configures the documentation build:
-
-```
--DPython_ROOT=<Path to Python 3 root directory>
-```
-
-To ease the documentation build and test on macOS one could also add these 
-three lines in the ~/.zshrc file:
-
-```
-alias python=/usr/local/bin/python3
-alias pip=/usr/local/bin/pip3
-alias <your web browser name>=open -a "<your web browser application name>"
-```
-
-## Quirks
-
-The vuepress theme that we've migrated to has some quirks to its design. For
-example it only allows two nested table of contents (TOC). So things have to be
-organized in a slightly different way than other sphinx projects.
-
-The root-level `toc_redirect.rst` points to where to find the different section
-TOCs. The name and contents of each sections TOC is defined in that
-sub-directory's `_index.rst` file.
-
-In this TOC the `:caption:` directive determines what the name of the section
-will be in the side-bar, and in the header of the website. The *H1* header
-determines the name of the page in the right/left arrows navigation bar. In a
-lot of cases this ends up doubling up the name on the page, but this seems
-unavoidable at the present time. If additional explanatory text is put in the
-`_index.rst` files then it shouldn't be as problematic.
-
-The site will show all *H1* headers in the side panel by default, these then
-expand when selected to show all *H2* headers.
-
-Due to the limited TOC and side-bar depth, we shouldn't be afraid of looong
-pages with many *H2* headings to break down the page into logical quadrants.

docs/api/python/frozen/pyopencolorio_allocation.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <Allocation.ALLOCATION_UNKNOWN: 0>
 
+
+   .. py:property:: Allocation.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_baker.rst

@@ -61,6 +61,10 @@
       :module: PyOpenColorIO
 
 
+   .. py:method:: Baker.getDisplay(self: PyOpenColorIO.Baker) -> str
+      :module: PyOpenColorIO
+
+
    .. py:method:: Baker.getFormat(self: PyOpenColorIO.Baker) -> str
       :module: PyOpenColorIO
 
@@ -94,6 +98,10 @@
       :module: PyOpenColorIO
 
 
+   .. py:method:: Baker.getView(self: PyOpenColorIO.Baker) -> str
+      :module: PyOpenColorIO
+
+
    .. py:method:: Baker.setConfig(self: PyOpenColorIO.Baker, config: PyOpenColorIO.Config) -> None
       :module: PyOpenColorIO
 
@@ -103,7 +111,13 @@
    .. py:method:: Baker.setCubeSize(self: PyOpenColorIO.Baker, cubeSize: int) -> None
       :module: PyOpenColorIO
 
-      Override the default cube sample size. default: <format specific>
+      Override the main LUT (3d or 1d) sample size. Default value is -1, which allows each format to use its own most appropriate size.
+
+
+   .. py:method:: Baker.setDisplayView(self: PyOpenColorIO.Baker, display: str, view: str) -> None
+      :module: PyOpenColorIO
+
+      Set the display and view to apply during the baking. Must not be used if setTargetSpace is used.
 
 
    .. py:method:: Baker.setFormat(self: PyOpenColorIO.Baker, formatName: str) -> None
@@ -133,13 +147,13 @@
    .. py:method:: Baker.setShaperSpace(self: PyOpenColorIO.Baker, shaperSpace: str) -> None
       :module: PyOpenColorIO
 
-      Set an *optional* :ref:`ColorSpace` to be used to shape / transfer the input colorspace. This is mostly used to allocate an HDR luminance range into an LDR one. If a shaper space is not explicitly specified, and the file format supports one, the :ref:`ColorSpace` Allocation will be used (not implemented for all formats).
+      Set an *optional* :ref:`ColorSpace` to shape the incoming values of the LUT. When baking 3DLUT, this will correspond to the 1D shaper used to normalise incoming values to the unit range. When baking 1D LUT, this will be used to determine the input range of the LUT.
 
 
    .. py:method:: Baker.setTargetSpace(self: PyOpenColorIO.Baker, targetSpace: str) -> None
       :module: PyOpenColorIO
 
-      Set the target device colorspace for the LUT.
+      Set the target (i.e., output) color space for the LUT. Must not be used if setDisplayView is used.
 
 
 .. py:class:: FormatIterator

docs/api/python/frozen/pyopencolorio_bitdepth.rst

@@ -22,7 +22,7 @@
 
      BIT_DEPTH_UINT16 :
 
-     BIT_DEPTH_UINT32 :
+     BIT_DEPTH_UINT32 : Here for historical reason but that's not supported.
 
      BIT_DEPTH_F16 :
 
@@ -75,3 +75,7 @@
       :module: PyOpenColorIO
       :value: <BitDepth.BIT_DEPTH_UNKNOWN: 0>
 
+
+   .. py:property:: BitDepth.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_cdlstyle.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <CDLStyle.CDL_NO_CLAMP: 1>
 
+
+   .. py:property:: CDLStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_channelordering.rst

@@ -47,3 +47,7 @@
       :module: PyOpenColorIO
       :value: <ChannelOrdering.CHANNEL_ORDERING_RGBA: 0>
 
+
+   .. py:property:: ChannelOrdering.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_colorspace.rst

@@ -10,8 +10,6 @@
 
    While a complete discussion of color spaces is beyond the scope of header documentation, traditional uses would be to have *ColorSpaces* corresponding to: physical capture devices (known cameras, scanners), and internal 'convenience' spaces (such as scene linear, logarithmic).
 
-   *ColorSpaces* are specific to a particular image precision (float32, uint8, etc.), and the set of ColorSpaces that provide equivalent mappings (at different precisions) are referred to as a 'family'.
-
 
    .. py:method:: ColorSpace.__init__(*args, **kwargs)
       :module: PyOpenColorIO
@@ -97,7 +95,7 @@
    .. py:method:: ColorSpace.getEqualityGroup(self: PyOpenColorIO.ColorSpace) -> str
       :module: PyOpenColorIO
 
-      Get the :ref:`ColorSpace` group name (used for equality comparisons) This allows no-op transforms between different colorspaces. If an equalityGroup is not defined (an empty string), it will be considered unique (i.e., it will not compare as equal to other ColorSpaces with an empty equality group). This is often, though not always, set to the same value as 'family'.
+      Get the :ref:`ColorSpace` group name (used for equality comparisons) This allows no-op transforms between different colorspaces. If an equalityGroup is not defined (an empty string), it will be considered unique (i.e., it will not compare as equal to other ColorSpaces with an empty equality group).
 
 
    .. py:method:: ColorSpace.getFamily(self: PyOpenColorIO.ColorSpace) -> str

docs/api/python/frozen/pyopencolorio_colorspacedirection.rst

@@ -24,3 +24,7 @@
       :module: PyOpenColorIO
       :value: <ColorSpaceDirection.COLORSPACE_DIR_TO_REFERENCE: 0>
 
+
+   .. py:property:: ColorSpaceDirection.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_colorspacevisibility.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <ColorSpaceVisibility.COLORSPACE_INACTIVE: 1>
 
+
+   .. py:property:: ColorSpaceVisibility.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_config.rst

@@ -24,13 +24,47 @@
    See developers-usageexamples
 
 
+   .. py:method:: Config.CreateFromBuiltinConfig(arg0: str) -> PyOpenColorIO.Config
+      :module: PyOpenColorIO
+      :staticmethod:
+
+      Create a configuration using an OCIO built-in config.
+
+      :param configName: Built-in config name.
+
+      The available configNames are: "cg-config-v0.1.0_aces-v1.3_ocio-v2.1.1"-- ACES CG config, basic color spaces for computer graphics apps. More information about these configs is available at: https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES
+
+      Information about the available configs is available from the :ref:`BuiltinConfigRegistry`.
+
+      :exception :ref:`Exception`: If the configName is not recognized.
+
+      :return: One of the configs built into the OCIO library.
+
+
+   .. py:method:: Config.CreateFromConfigIOProxy(arg0: OpenColorIO_v2_2dev::ConfigIOProxy) -> PyOpenColorIO.Config
+      :module: PyOpenColorIO
+      :staticmethod:
+
+      Create a config from the supplied :ref:`ConfigIOProxy` object. This allows the calling program to directly provide the config and associated LUTs rather than reading them from the standard file system.
+
+      See the :ref:`ConfigIOProxy` class documentation for more info.
+
+      :param ciop: :ref:`ConfigIOProxy` object providing access to the config's files.
+
+      :exception :ref:`Exception`: If the config may not be read from the proxy, or does not parse.
+
+      :return: The :ref:`Config` object.
+
+
    .. py:method:: Config.CreateFromEnv() -> PyOpenColorIO.Config
       :module: PyOpenColorIO
       :staticmethod:
 
       Create a configuration using the OCIO environment variable.
 
-      If the variable is missing or empty, returns the same result as :ref:`Config::CreateRaw` .
+      Also supports the OCIO URI format for Built-in configs and supports archived configs. See :ref:`Config::CreateFromFile`.
+
+      If the variable is missing or empty, returns the same result as :ref:`Config::CreateRaw`. :return: The :ref:`Config` object.
 
 
    .. py:method:: Config.CreateFromFile(fileName: str) -> PyOpenColorIO.Config
@@ -39,6 +73,14 @@
 
       Create a configuration using a specific config file.
 
+      Also supports the following OCIO URI format for Built-in configs: "ocio://default" - Default Built-in config. "ocio://<CONFIG NAME>" - A specific Built-in config. For the list of available <CONFIG NAME> strings, see :ref:`Config::CreateFromBuiltinConfig`.
+
+      Also supports archived configs (.ocioz files).
+
+      :exception :ref:`Exception`: If the file may not be read or does not parse.
+
+      :return: The :ref:`Config` object.
+
 
    .. py:method:: Config.CreateFromStream(str: str) -> PyOpenColorIO.Config
       :module: PyOpenColorIO
@@ -46,6 +88,16 @@
 
       Create a configuration using a stream.
 
+      Note that CreateFromStream does not set the working directory so the caller would need to set that separately in order to resolve FileTransforms. This function is typically only used for self-contained configs (no LUTs).
+
+      Configs created from CreateFromStream can not be archived unless the working directory is set and contains any necessary LUT files.
+
+      :param istream: Stream to the config.
+
+      :exception :ref:`Exception`: If the stream does not parse.
+
+      :return: The :ref:`Config` object.
+
 
    .. py:method:: Config.CreateRaw() -> PyOpenColorIO.Config
       :module: PyOpenColorIO
@@ -53,7 +105,15 @@
 
       Create a fall-back config.
 
-      This may be useful to allow client apps to launch in cases when the supplied config path is not loadable.
+      This may be useful to allow client apps to launch in cases when the supplied config path is not loadable. :return: The :ref:`Config` object.
+
+
+   .. py:class:: Config.DisplayAllIterator
+      :module: PyOpenColorIO
+
+
+      .. py:method:: Config.DisplayAllIterator.__init__(*args, **kwargs)
+         :module: PyOpenColorIO
 
 
    .. py:method:: Config.GetProcessorFromConfigs(*args, **kwargs)
@@ -77,12 +137,28 @@
       4. GetProcessorFromConfigs(srcContext: PyOpenColorIO.Context, srcConfig: PyOpenColorIO.Config, srcColorSpaceName: str, srcInterchangeName: str, dstContext: PyOpenColorIO.Context, dstConfig: PyOpenColorIO.Config, dstColorSpaceName: str, dstInterchangeName: str) -> PyOpenColorIO.Processor
 
 
+   .. py:class:: Config.ViewForViewTypeIterator
+      :module: PyOpenColorIO
+
+
+      .. py:method:: Config.ViewForViewTypeIterator.__init__(*args, **kwargs)
+         :module: PyOpenColorIO
+
+
+   .. py:class:: Config.VirtualViewIterator
+      :module: PyOpenColorIO
+
+
+      .. py:method:: Config.VirtualViewIterator.__init__(*args, **kwargs)
+         :module: PyOpenColorIO
+
+
    .. py:method:: Config.__init__(self: PyOpenColorIO.Config) -> None
       :module: PyOpenColorIO
 
       Create an empty config of the current version.
 
-      Note that an empty config will not pass validation since required elements will be missing.
+      Note that an empty config will not pass validation since required elements will be missing. :return: The :ref:`Config` object.
 
 
    .. py:method:: Config.__str__(self: PyOpenColorIO.Config) -> str
@@ -167,6 +243,30 @@
       :module: PyOpenColorIO
 
 
+   .. py:method:: Config.addVirtualDisplaySharedView(self: PyOpenColorIO.Config, sharedView: str) -> None
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.addVirtualDisplayView(self: PyOpenColorIO.Config, view: str, viewTransformName: str, colorSpaceName: str, looks: str = '', ruleName: str = '', description: str = '') -> None
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.archive(self: PyOpenColorIO.Config, arg0: str) -> None
+      :module: PyOpenColorIO
+
+      Archive the config and its LUTs into the specified output stream.
+
+      The config is archived by serializing the :ref:`Config` object into a file named "config.ocio" and then walking through the current working directory and any sub-directories. Any files that have an extension matching a supported LUT file format are added to the archive. Any files that do not have an extension (or have some unsupported LUT extension, including .ocio), will not be added to the archive. To reiterate, it is the in-memory :ref:`Config` object that is archived, and not any .ocio file in the current working directory. The directory structure relative to the working directory is preserved. No files outside the working directory are archived so that if it is later expanded, no files will be created outside the working dir.
+
+      The reason the archive is created using all supported LUT file extensions rather than by trying to resolve all the FileTransforms in the :ref:`Config` to specific files is because of the goal to allow context variables to continue to work.
+
+      If a :ref:`Config` is created with CreateFromStream, CreateFromFile with an OCIOZ archive, or CreateFromConfigIOProxy, it cannot be archived unless the working directory is manually set to a directory that contains any necessary LUT files.
+
+      The provided output stream must be closed by the caller, if necessary (e.g., an ofstream).
+
+      :param ostream: The output stream to write to.
+
+
    .. py:method:: Config.clearColorSpaces(self: PyOpenColorIO.Config) -> None
       :module: PyOpenColorIO
 
@@ -202,6 +302,12 @@
       :module: PyOpenColorIO
 
 
+   .. py:method:: Config.clearVirtualDisplay(self: PyOpenColorIO.Config) -> None
+      :module: PyOpenColorIO
+
+      Clear the virtual display.
+
+
    .. py:method:: Config.filepathOnlyMatchesDefaultRule(self: PyOpenColorIO.Config, filePath: str) -> bool
       :module: PyOpenColorIO
 
@@ -256,7 +362,7 @@
    .. py:method:: Config.getColorSpaceFromFilepath(self: PyOpenColorIO.Config, filePath: str) -> tuple
       :module: PyOpenColorIO
 
-      Get the color space of the first rule that matched filePath.
+      Get the color space of the first rule that matched filePath. (For v1 configs, this is equivalent to calling parseColorSpaceFromString with strictparsing set to false.)
 
 
    .. py:method:: Config.getColorSpaceNames(*args, **kwargs)
@@ -303,7 +409,7 @@
       Get the default coefficients for computing luma.
 
       .. note::
-         There is no "1 size fits all" set of luma coefficients. (The values are typically different for each colorspace, and the application of them may be nonsensical depending on the intensity coding anyways). Thus, the 'right' answer is to make these functions on the :ref:`Config` class. However, it's often useful to have a config-wide default so here it is. We will add the colorspace specific luma call if/when another client is interesting in using it.
+         There is no "1 size fits all" set of luma coefficients. (The values are typically different for each colorspace, and the application of them may be nonsensical depending on the intensity coding anyways). Thus, the 'right' answer is to make these functions on the :ref:`ColorSpace` class. However, it's often useful to have a config-wide default so here it is. We will add the colorspace specific luma call if/when another client is interesting in using it.
 
 
    .. py:method:: Config.getDefaultSceneToDisplayViewTransform(self: PyOpenColorIO.Config) -> PyOpenColorIO.ViewTransform
@@ -312,9 +418,15 @@
       This view transform is the one that will be used by default if a :ref:`ColorSpaceTransform` is needed between a scene-referred and display-referred color space. The config author may specify a transform to use via the default_view_transform entry in the config. If that is not present, or does not return a valid view transform from the scene-referred connection space, the fall-back is to use the first valid view transform in the config. Returns a null ConstTransformRcPtr if there isn't one.
 
 
-   .. py:method:: Config.getDefaultView(self: PyOpenColorIO.Config, display: str) -> str
+   .. py:method:: Config.getDefaultView(*args, **kwargs)
       :module: PyOpenColorIO
 
+      Overloaded function.
+
+      1. getDefaultView(self: PyOpenColorIO.Config, display: str) -> str
+
+      2. getDefaultView(self: PyOpenColorIO.Config, display: str, colorSpacename: str) -> str
+
 
    .. py:method:: Config.getDefaultViewTransformName(self: PyOpenColorIO.Config) -> str
       :module: PyOpenColorIO
@@ -362,6 +474,10 @@
       :module: PyOpenColorIO
 
 
+   .. py:method:: Config.getDisplaysAll(self: PyOpenColorIO.Config) -> PyOpenColorIO.Config.DisplayAllIterator
+      :module: PyOpenColorIO
+
+
    .. py:method:: Config.getEnvironmentMode(self: PyOpenColorIO.Config) -> PyOpenColorIO.EnvironmentMode
       :module: PyOpenColorIO
 
@@ -472,15 +588,25 @@
 
       6. getProcessor(self: PyOpenColorIO.Config, context: PyOpenColorIO.Context, srcColorSpaceName: str, display: str, view: str, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
 
-      7. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform) -> PyOpenColorIO.Processor
+      7. getProcessor(self: PyOpenColorIO.Config, namedTransform: PyOpenColorIO.NamedTransform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+
+      Get the processor to apply a :ref:`NamedTransform` in the specified direction.
+
+      8. getProcessor(self: PyOpenColorIO.Config, context: PyOpenColorIO.Context, namedTransform: PyOpenColorIO.NamedTransform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+
+      9. getProcessor(self: PyOpenColorIO.Config, namedTransformName: str, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+
+      10. getProcessor(self: PyOpenColorIO.Config, context: PyOpenColorIO.Context, namedTransformName: str, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+
+      11. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform) -> PyOpenColorIO.Processor
 
       Get the processor for the specified transform.
 
       Not often needed, but will allow for the re-use of atomic OCIO functionality (such as to apply an individual LUT file).
 
-      8. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+      12. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
 
-      9. getProcessor(self: PyOpenColorIO.Config, context: PyOpenColorIO.Context, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
+      13. getProcessor(self: PyOpenColorIO.Config, context: PyOpenColorIO.Context, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Processor
 
 
    .. py:method:: Config.getRoleNames(self: PyOpenColorIO.Config) -> PyOpenColorIO.Config.RoleNameIterator
@@ -528,7 +654,33 @@
 
       1. getViews(self: PyOpenColorIO.Config, display: str) -> PyOpenColorIO.Config.ViewIterator
 
-      2. getViews(self: PyOpenColorIO.Config, display: str, colorSpaceName: str) -> PyOpenColorIO.Config.ViewForColorSpaceIterator
+      2. getViews(self: PyOpenColorIO.Config, type: PyOpenColorIO.ViewType, display: str) -> PyOpenColorIO.Config.ViewForViewTypeIterator
+
+      3. getViews(self: PyOpenColorIO.Config, display: str, colorSpaceName: str) -> PyOpenColorIO.Config.ViewForColorSpaceIterator
+
+
+   .. py:method:: Config.getVirtualDisplayViewColorSpaceName(self: PyOpenColorIO.Config, view: str) -> str
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.getVirtualDisplayViewDescription(self: PyOpenColorIO.Config, view: str) -> str
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.getVirtualDisplayViewLooks(self: PyOpenColorIO.Config, view: str) -> str
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.getVirtualDisplayViewRule(self: PyOpenColorIO.Config, view: str) -> str
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.getVirtualDisplayViewTransformName(self: PyOpenColorIO.Config, view: str) -> str
+      :module: PyOpenColorIO
+
+
+   .. py:method:: Config.getVirtualDisplayViews(self: PyOpenColorIO.Config, display: PyOpenColorIO.ViewType) -> PyOpenColorIO.Config.VirtualViewIterator
+      :module: PyOpenColorIO
 
 
    .. py:method:: Config.getWorkingDir(self: PyOpenColorIO.Config) -> str
@@ -541,6 +693,69 @@
       Return true if the role has been defined.
 
 
+   .. py:method:: Config.instantiateDisplayFromICCProfile(self: PyOpenColorIO.Config, ICCProfileFilepath: str) -> int
+      :module: PyOpenColorIO
+
+      Instantiate a new display from a virtual display, using an ICC profile.
+
+      On platforms such as Linux, where the :ref:`SystemMonitors` class is not able to obtain a list of ICC profiles from the OS, this method may be used to manually specify a path to an ICC profile.
+
+      Will throw if the virtual display definition is missing from the config.
+
+      Returns the index of the display.
+
+
+   .. py:method:: Config.instantiateDisplayFromMonitorName(self: PyOpenColorIO.Config, monitorName: str) -> int
+      :module: PyOpenColorIO
+
+      Instantiate a new display from a virtual display, using the monitor name.
+
+      This method uses the virtual display to create an actual display for the given monitorName. The new display will receive the views from the virtual display.
+
+      After the ICC profile is read, a display name will be created by combining the description text from the profile with the monitorName obtained from the OS. Use the :ref:`SystemMonitors` class to obtain the list of monitorName strings for the displays connected to the computer.
+
+      A new display color space will also be created using the display name. It will have a from_display_reference transform that is a :ref:`FileTransform` pointing to the ICC profile.
+
+      Any instantiated display color spaces for a virtual display are intended to be temporary (i.e. last as long as the current session). By default, they are not saved when writing a config file. If there is a need to make it a permanent color space, it may be desirable to copy the ICC profile somewhere under the config search_path.
+
+      Will throw if the config does not have a virtual display or if the monitorName does not exist.
+
+      If there is already a display or a display color space with the name monitorName, it will be replaced/updated.
+
+      Returns the index of the display.
+
+
+   .. py:method:: Config.isArchivable(self: PyOpenColorIO.Config) -> bool
+      :module: PyOpenColorIO
+
+      Verify if the config is archivable.
+
+      A config is not archivable if any of the following are true: -- The working directory is not set -- It contains FileTransforms with a src outside the working directory -- The search path contains paths outside the working directory -- The search path contains paths that start with a context variable
+
+      :ref:`Context` variables are allowed but the intent is that they may only resolve to paths that are within or below the working directory. This is because the archiving function will only archive files that are within the working directory in order to ensure that if it is later expanded, that it will not create any files outside this directory.
+
+      For example, a context variable on the search path intended to contain the name of a sub-directory under the working directory must have the form "./$DIR_NAME" rather than just "$DIR_NAME" to be considered archivable. This is imperfect since there is no way to prevent the context variable from creating a path outside the working dir, but it should at least draw attention to the fact that the archive would fail if used with context vars that try to abuse the intended functionality.
+
+      :return: bool Archivable if true.
+
+
+   .. py:method:: Config.isColorSpaceLinear(self: PyOpenColorIO.Config, colorSpace: str, referenceSpaceType: PyOpenColorIO.ReferenceSpaceType) -> bool
+      :module: PyOpenColorIO
+
+      Return true if the specified color space is linear.
+
+      The determination of linearity is made with respect to one of the two reference spaces (i.e., either the scene-referred one or the display-referred one). If the reference space type of the color space is the opposite of the requested reference space type, false is returned immediately rather than trying to invoke the default view transform to convert between the reference spaces.
+
+      Note: This function relies on heuristics that may sometimes give an incorrect result. For example, if the encoding attribute is not set appropriately or the sampled values fail to detect non-linearity.
+
+      The algorithm proceeds as follows: -- If the color space isdata attribute is true, return false. -- If the reference space type of the color space differs from the requested reference space type, return false. -- If the color space's encoding attribute is present, return true if it matches the expected reference space type (i.e., "scene-linear" for REFERENCE_SPACE_SCENE or "display-linear" for REFERENCE_SPACE_DISPLAY) and false otherwise. -- If the color space has no to_reference or from_reference transform, return true. -- Evaluate several points through the color space's transform and check if the output only differs by a scale factor (which may be different per channel, e.g. allowing an arbitrary matrix transform, with no offset).
+
+      Note that the encoding test happens before the sampled value test to give config authors ultimate control over the linearity determination. For example, they could set the encoding attribute to indicate linearity if they want to ignore some areas of non-linearity (e.g., at extreme values). Or they could set it to indicate that a color space should not be considered linear, even if it is, in a mathematical sense.
+
+      :param colorSpace: Color space to evaluate.
+      :param referenceSpaceType: Evaluate linearity with respect to the specified reference space (either scene-referred or display-referred).
+
+
    .. py:method:: Config.isColorSpaceUsed(self: PyOpenColorIO.Config, name: str) -> bool
       :module: PyOpenColorIO
 
@@ -550,6 +765,10 @@
          Name must be the canonical name.
 
 
+   .. py:method:: Config.isDisplayTemporary(self: PyOpenColorIO.Config, display: str) -> bool
+      :module: PyOpenColorIO
+
+
    .. py:method:: Config.isStrictParsingEnabled(self: PyOpenColorIO.Config) -> bool
       :module: PyOpenColorIO
 
@@ -561,7 +780,7 @@
    .. py:method:: Config.parseColorSpaceFromString(self: PyOpenColorIO.Config, str: str) -> str
       :module: PyOpenColorIO
 
-      Given the specified string, get the longest, right-most, colorspace substring that appears. This is now deprecated, please use getColorSpaceFromFilepath.
+      Given the specified string, get the longest, right-most, colorspace substring that appears.
 
       - If strict parsing is enabled, and no color space is found, return an empty string.
       - If strict parsing is disabled, return ROLE_DEFAULT (if defined).
@@ -596,6 +815,12 @@
       Remove a shared view. Will throw if the view does not exist.
 
 
+   .. py:method:: Config.removeVirtualDisplayView(self: PyOpenColorIO.Config, view: str) -> None
+      :module: PyOpenColorIO
+
+      Remove the view from the virtual display.
+
+
    .. py:method:: Config.serialize(*args, **kwargs)
       :module: PyOpenColorIO
 

docs/api/python/frozen/pyopencolorio_cpuprocessor.rst

@@ -10,8 +10,6 @@
    .. py:method:: CPUProcessor.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: CPUProcessor.apply(*args, **kwargs)
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_dynamicproperty.rst

@@ -51,8 +51,6 @@
    .. py:method:: DynamicProperty.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: DynamicProperty.getDouble(self: PyOpenColorIO.DynamicProperty) -> float
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_dynamicpropertytype.rst

@@ -54,3 +54,7 @@
       :module: PyOpenColorIO
       :value: <DynamicPropertyType.DYNAMIC_PROPERTY_GRADING_TONE: 5>
 
+
+   .. py:property:: DynamicPropertyType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_environmentmode.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <EnvironmentMode.ENV_ENVIRONMENT_UNKNOWN: 0>
 
+
+   .. py:property:: EnvironmentMode.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_exposurecontraststyle.rst

@@ -33,3 +33,7 @@
       :module: PyOpenColorIO
       :value: <ExposureContrastStyle.EXPOSURE_CONTRAST_VIDEO: 1>
 
+
+   .. py:property:: ExposureContrastStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_filerules.rst

@@ -30,6 +30,8 @@
 
    Getters and setters are using the rule position, they will throw if the position is not valid. If the rule at the specified position does not implement the requested property getter will return NULL and setter will throw.
 
+   When loading a v1 config, a set of :ref:`FileRules` are created with ColorSpaceNamePathSearch followed by the Default rule pointing to the default role. This allows getColorSpaceFromFilepath to emulate OCIO v1 code that used parseColorSpaceFromString with strictparsing set to false.
+
 
    .. py:method:: FileRules.__init__(self: PyOpenColorIO.FileRules) -> None
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_fixedfunctionstyle.rst

@@ -34,7 +34,7 @@
 
      FIXED_FUNCTION_ACES_GAMUTMAP_07 : ACES 0.7 Gamut clamping algorithm -- NOT IMPLEMENTED YET.
 
-     FIXED_FUNCTION_ACES_GAMUTMAP_13 : ACES 1.3 Gamut mapping algorithm.
+     FIXED_FUNCTION_ACES_GAMUT_COMP_13 : ACES 1.3 Parametric Gamut Compression (expects ACEScg values)
 
    .. py:method:: name() -> str
       :property:
@@ -54,9 +54,9 @@
       :value: <FixedFunctionStyle.FIXED_FUNCTION_ACES_GAMUTMAP_07: 11>
 
 
-   .. py:attribute:: FixedFunctionStyle.FIXED_FUNCTION_ACES_GAMUTMAP_13
+   .. py:attribute:: FixedFunctionStyle.FIXED_FUNCTION_ACES_GAMUT_COMP_13
       :module: PyOpenColorIO
-      :value: <FixedFunctionStyle.FIXED_FUNCTION_ACES_GAMUTMAP_13: 12>
+      :value: <FixedFunctionStyle.FIXED_FUNCTION_ACES_GAMUT_COMP_13: 12>
 
 
    .. py:attribute:: FixedFunctionStyle.FIXED_FUNCTION_ACES_GLOW_03
@@ -103,3 +103,7 @@
       :module: PyOpenColorIO
       :value: <FixedFunctionStyle.FIXED_FUNCTION_XYZ_TO_xyY: 7>
 
+
+   .. py:property:: FixedFunctionStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_formatmetadata.rst

@@ -28,8 +28,6 @@
    .. py:method:: FormatMetadata.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: FormatMetadata.__iter__(self: PyOpenColorIO.FormatMetadata) -> PyOpenColorIO.FormatMetadata.AttributeNameIterator
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_gpulanguage.rst

@@ -18,8 +18,14 @@
 
      GPU_LANGUAGE_GLSL_4_0 : OpenGL Shading Language.
 
+     GPU_LANGUAGE_GLSL_ES_1_0 : OpenGL ES Shading Language.
+
+     GPU_LANGUAGE_GLSL_ES_3_0 : OpenGL ES Shading Language.
+
      GPU_LANGUAGE_HLSL_DX11 : DirectX Shading Language.
 
+     GPU_LANGUAGE_MSL_2_0 : Metal Shading Language.
+
    .. py:method:: name() -> str
       :property:
 
@@ -43,7 +49,26 @@
       :value: <GpuLanguage.GPU_LANGUAGE_GLSL_4_0: 3>
 
 
+   .. py:attribute:: GpuLanguage.GPU_LANGUAGE_GLSL_ES_1_0
+      :module: PyOpenColorIO
+      :value: <GpuLanguage.GPU_LANGUAGE_GLSL_ES_1_0: 6>
+
+
+   .. py:attribute:: GpuLanguage.GPU_LANGUAGE_GLSL_ES_3_0
+      :module: PyOpenColorIO
+      :value: <GpuLanguage.GPU_LANGUAGE_GLSL_ES_3_0: 7>
+
+
    .. py:attribute:: GpuLanguage.GPU_LANGUAGE_HLSL_DX11
       :module: PyOpenColorIO
       :value: <GpuLanguage.GPU_LANGUAGE_HLSL_DX11: 4>
 
+
+   .. py:attribute:: GpuLanguage.GPU_LANGUAGE_MSL_2_0
+      :module: PyOpenColorIO
+      :value: <GpuLanguage.GPU_LANGUAGE_MSL_2_0: 8>
+
+
+   .. py:property:: GpuLanguage.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_gpuprocessor.rst

@@ -10,8 +10,6 @@
    .. py:method:: GPUProcessor.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: GPUProcessor.extractGpuShaderInfo(self: PyOpenColorIO.GPUProcessor, shaderDesc: PyOpenColorIO.GpuShaderDesc) -> None
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_gpushadercreator.rst

@@ -8,9 +8,10 @@
 
    Inherit from the class to fully customize the implementation of a GPU shader program from a color transformation.
 
-   When no customizations are needed then the :ref:`GpuShaderDesc` is a better choice.
+   When no customizations are needed and the intermediate in-memory step is acceptable then the :ref:`GpuShaderDesc` is a better choice.
 
-   To better decouple the DynamicProperties from their GPU implementation, the code provides several addUniform() methods i.e. one per access function types. For example, an :ref:`ExposureContrastTransform` instance owns three DynamicProperties and they are all implemented by a double. When creating the GPU fragment shader program, the addUniform() with :ref:`GpuShaderCreator::DoubleGetter` is called when property is dynamic, up to three times.
+   .. note::
+      To better decouple the DynamicProperties from their GPU implementation, the code provides several addUniform() methods i.e. one per access function types. For example, an :ref:`ExposureContrastTransform` instance owns three DynamicProperties and they are all implemented by a double. When creating the GPU fragment shader program, the addUniform() with :ref:`GpuShaderCreator::DoubleGetter` is called when property is dynamic, up to three times.
 
    **An OCIO shader program could contain:**
 
@@ -121,7 +122,7 @@
    .. py:method:: GpuShaderCreator.getNextResourceIndex(self: PyOpenColorIO.GpuShaderCreator) -> int
       :module: PyOpenColorIO
 
-      To avoid texture/unform name clashes always append an increasing number to the resource name.
+      To avoid global texture sampler and uniform name clashes always append an increasing index to the resource name.
 
 
    .. py:method:: GpuShaderCreator.getPixelName(self: PyOpenColorIO.GpuShaderCreator) -> str
@@ -201,6 +202,10 @@
       :value: <TextureType.TEXTURE_RGB_CHANNEL: 1>
 
 
+   .. py:property:: TextureType.value
+      :module: PyOpenColorIO.GpuShaderCreator
+
+
 .. py:class:: DynamicPropertyIterator
    :module: PyOpenColorIO.GpuShaderCreator
 

docs/api/python/frozen/pyopencolorio_gpushaderdesc.rst

@@ -87,18 +87,9 @@
 
        // Step 1: Create a GPU shader description
        //
-       // The three potential scenarios are:
+       // The two potential scenarios are:
        //
-       //   1. Instantiate the legacy shader description.  The color processor
-       //      is baked down to contain at most one 3D LUT and no 1D LUTs.
-       //
-       //      This is the v1 behavior and will remain part of OCIO v2
-       //      for backward compatibility.
-       //
-       OCIO::GpuShaderDescRcPtr shaderDesc
-             = OCIO::GpuShaderDesc::CreateLegacyShaderDesc(LUT3D_EDGE_SIZE);
-       //
-       //   2. Instantiate the generic shader description.  The color processor
+       //   1. Instantiate the generic shader description.  The color processor
        //      is used as-is (i.e. without any baking step) and could contain
        //      any number of 1D & 3D luts.
        //
@@ -107,7 +98,7 @@
        //
        OCIO::GpuShaderDescRcPtr shaderDesc = OCIO::GpuShaderDesc::Create();
        //
-       //   3. Instantiate a custom shader description.
+       //   2. Instantiate a custom shader description.
        //
        //      Writing a custom shader description is a way to tailor the shaders
        //      to the needs of a given client program.  This involves writing a
@@ -158,16 +149,24 @@
    .. py:method:: GpuShaderDesc.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: GpuShaderDesc.add3DTexture(self: PyOpenColorIO.GpuShaderDesc, textureName: str, samplerName: str, edgeLen: int, interpolation: PyOpenColorIO.Interpolation, values: buffer) -> None
       :module: PyOpenColorIO
 
+      Add a 3D texture with RGB channel type.
+
+      .. note::
+         The 'values' parameter contains the 3D LUT data which must be used as-is as the dimension and origin are hard-coded in the fragment shader program. So, it means one GPU 3D texture per entry.
+
 
    .. py:method:: GpuShaderDesc.addTexture(self: PyOpenColorIO.GpuShaderDesc, textureName: str, samplerName: str, width: int, height: int, channel: PyOpenColorIO.GpuShaderCreator.TextureType, interpolation: PyOpenColorIO.Interpolation, values: buffer) -> None
       :module: PyOpenColorIO
 
+      Add a 2D texture (1D texture if height equals 1).
+
+      .. note::
+         The 'values' parameter contains the LUT data which must be used as-is as the dimensions and origin are hard-coded in the fragment shader program. So, it means one GPU texture per entry.
+
 
    .. py:method:: GpuShaderDesc.addToDeclareShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
       :module: PyOpenColorIO
@@ -245,7 +244,7 @@
    .. py:method:: GpuShaderDesc.getNextResourceIndex(self: PyOpenColorIO.GpuShaderCreator) -> int
       :module: PyOpenColorIO
 
-      To avoid texture/unform name clashes always append an increasing number to the resource name.
+      To avoid global texture sampler and uniform name clashes always append an increasing index to the resource name.
 
 
    .. py:method:: GpuShaderDesc.getPixelName(self: PyOpenColorIO.GpuShaderCreator) -> str
@@ -319,6 +318,7 @@
 
 .. py:class:: TextureType
    :module: PyOpenColorIO.GpuShaderDesc
+   :canonical: PyOpenColorIO.GpuShaderCreator.TextureType
 
    Members:
 
@@ -339,6 +339,10 @@
       :value: <TextureType.TEXTURE_RGB_CHANNEL: 1>
 
 
+   .. py:property:: TextureType.value
+      :module: PyOpenColorIO.GpuShaderDesc
+
+
 .. py:class:: UniformData
    :module: PyOpenColorIO.GpuShaderDesc
 
@@ -363,75 +367,64 @@
       :module: PyOpenColorIO.GpuShaderDesc
 
 
-   .. py:method:: UniformData.type
+   .. py:property:: UniformData.type
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
 .. py:class:: Texture
    :module: PyOpenColorIO.GpuShaderDesc
 
 
-   .. py:method:: Texture.channel
+   .. py:property:: Texture.channel
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
    .. py:method:: Texture.getValues(self: PyOpenColorIO.GpuShaderDesc.Texture) -> numpy.ndarray
       :module: PyOpenColorIO.GpuShaderDesc
 
 
-   .. py:method:: Texture.height
+   .. py:property:: Texture.height
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture.interpolation
+   .. py:property:: Texture.interpolation
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture.samplerName
+   .. py:property:: Texture.samplerName
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture.textureName
+   .. py:property:: Texture.textureName
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture.width
+   .. py:property:: Texture.width
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
 .. py:class:: Texture3D
    :module: PyOpenColorIO.GpuShaderDesc
 
 
-   .. py:method:: Texture3D.edgeLen
+   .. py:property:: Texture3D.edgeLen
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
    .. py:method:: Texture3D.getValues(self: PyOpenColorIO.GpuShaderDesc.Texture3D) -> numpy.ndarray
       :module: PyOpenColorIO.GpuShaderDesc
 
 
-   .. py:method:: Texture3D.interpolation
+   .. py:property:: Texture3D.interpolation
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture3D.samplerName
+   .. py:property:: Texture3D.samplerName
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
-   .. py:method:: Texture3D.textureName
+   .. py:property:: Texture3D.textureName
       :module: PyOpenColorIO.GpuShaderDesc
-      :property:
 
 
 .. py:class:: UniformIterator
@@ -496,6 +489,7 @@
 
 .. py:class:: DynamicPropertyIterator
    :module: PyOpenColorIO.GpuShaderDesc
+   :canonical: PyOpenColorIO.GpuShaderCreator.DynamicPropertyIterator
 
 
    .. py:method:: DynamicPropertyIterator.__getitem__(self: PyOpenColorIO.GpuShaderCreator.DynamicPropertyIterator, arg0: int) -> PyOpenColorIO.DynamicProperty

docs/api/python/frozen/pyopencolorio_gradingcontrolpoint.rst

@@ -19,12 +19,10 @@
       2. __init__(self: PyOpenColorIO.GradingControlPoint, x: float = 0.0, y: float = 0.0) -> None
 
 
-   .. py:method:: GradingControlPoint.x
+   .. py:property:: GradingControlPoint.x
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingControlPoint.y
+   .. py:property:: GradingControlPoint.y
       :module: PyOpenColorIO
-      :property:
 

docs/api/python/frozen/pyopencolorio_gradingprimary.rst

@@ -23,69 +23,56 @@
       :module: PyOpenColorIO
 
 
-   .. py:method:: GradingPrimary.brightness
+   .. py:property:: GradingPrimary.brightness
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.clampBlack
+   .. py:property:: GradingPrimary.clampBlack
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.clampWhite
+   .. py:property:: GradingPrimary.clampWhite
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.contrast
+   .. py:property:: GradingPrimary.contrast
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.exposure
+   .. py:property:: GradingPrimary.exposure
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.gain
+   .. py:property:: GradingPrimary.gain
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.gamma
+   .. py:property:: GradingPrimary.gamma
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.lift
+   .. py:property:: GradingPrimary.lift
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.offset
+   .. py:property:: GradingPrimary.offset
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.pivot
+   .. py:property:: GradingPrimary.pivot
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.pivotBlack
+   .. py:property:: GradingPrimary.pivotBlack
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.pivotWhite
+   .. py:property:: GradingPrimary.pivotWhite
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingPrimary.saturation
+   .. py:property:: GradingPrimary.saturation
       :module: PyOpenColorIO
-      :property:
 
 
    .. py:method:: GradingPrimary.validate(self: PyOpenColorIO.GradingPrimary, arg0: PyOpenColorIO.GradingStyle) -> None

docs/api/python/frozen/pyopencolorio_gradingrgbcurve.rst

@@ -21,22 +21,18 @@
       2. __init__(self: PyOpenColorIO.GradingRGBCurve, red: PyOpenColorIO.GradingBSplineCurve = <control_points=[<x=0, y=0><x=0.5, y=0.5><x=1, y=1>]>, green: PyOpenColorIO.GradingBSplineCurve = <control_points=[<x=0, y=0><x=0.5, y=0.5><x=1, y=1>]>, blue: PyOpenColorIO.GradingBSplineCurve = <control_points=[<x=0, y=0><x=0.5, y=0.5><x=1, y=1>]>, master: PyOpenColorIO.GradingBSplineCurve = <control_points=[<x=0, y=0><x=0.5, y=0.5><x=1, y=1>]>) -> None
 
 
-   .. py:method:: GradingRGBCurve.blue
+   .. py:property:: GradingRGBCurve.blue
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBCurve.green
+   .. py:property:: GradingRGBCurve.green
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBCurve.master
+   .. py:property:: GradingRGBCurve.master
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBCurve.red
+   .. py:property:: GradingRGBCurve.red
       :module: PyOpenColorIO
-      :property:
 

docs/api/python/frozen/pyopencolorio_gradingrgbm.rst

@@ -19,22 +19,18 @@
       2. __init__(self: PyOpenColorIO.GradingRGBM, red: float, green: float, blue: float, master: float) -> None
 
 
-   .. py:method:: GradingRGBM.blue
+   .. py:property:: GradingRGBM.blue
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBM.green
+   .. py:property:: GradingRGBM.green
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBM.master
+   .. py:property:: GradingRGBM.master
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBM.red
+   .. py:property:: GradingRGBM.red
       :module: PyOpenColorIO
-      :property:
 

docs/api/python/frozen/pyopencolorio_gradingrgbmsw.rst

@@ -21,32 +21,26 @@
       3. __init__(self: PyOpenColorIO.GradingRGBMSW, start: float, width: float) -> None
 
 
-   .. py:method:: GradingRGBMSW.blue
+   .. py:property:: GradingRGBMSW.blue
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBMSW.green
+   .. py:property:: GradingRGBMSW.green
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBMSW.master
+   .. py:property:: GradingRGBMSW.master
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBMSW.red
+   .. py:property:: GradingRGBMSW.red
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBMSW.start
+   .. py:property:: GradingRGBMSW.start
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingRGBMSW.width
+   .. py:property:: GradingRGBMSW.width
       :module: PyOpenColorIO
-      :property:
 

docs/api/python/frozen/pyopencolorio_gradingstyle.rst

@@ -33,3 +33,7 @@
       :module: PyOpenColorIO
       :value: <GradingStyle.GRADING_VIDEO: 2>
 
+
+   .. py:property:: GradingStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_gradingtone.rst

@@ -13,29 +13,24 @@
       :module: PyOpenColorIO
 
 
-   .. py:method:: GradingTone.blacks
+   .. py:property:: GradingTone.blacks
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingTone.highlights
+   .. py:property:: GradingTone.highlights
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingTone.midtones
+   .. py:property:: GradingTone.midtones
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingTone.scontrast
+   .. py:property:: GradingTone.scontrast
       :module: PyOpenColorIO
-      :property:
 
 
-   .. py:method:: GradingTone.shadows
+   .. py:property:: GradingTone.shadows
       :module: PyOpenColorIO
-      :property:
 
 
    .. py:method:: GradingTone.validate(self: PyOpenColorIO.GradingTone) -> None
@@ -44,7 +39,6 @@
       The valid range for each parameter varies. The client is expected to enforce these bounds in the UI.
 
 
-   .. py:method:: GradingTone.whites
+   .. py:property:: GradingTone.whites
       :module: PyOpenColorIO
-      :property:
 

docs/api/python/frozen/pyopencolorio_interpolation.rst

@@ -71,3 +71,7 @@
       :module: PyOpenColorIO
       :value: <Interpolation.INTERP_UNKNOWN: 0>
 
+
+   .. py:property:: Interpolation.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_logginglevel.rst

@@ -45,3 +45,7 @@
       :module: PyOpenColorIO
       :value: <LoggingLevel.LOGGING_LEVEL_WARNING: 1>
 
+
+   .. py:property:: LoggingLevel.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_lut1dhueadjust.rst

@@ -33,3 +33,7 @@
       :module: PyOpenColorIO
       :value: <Lut1DHueAdjust.HUE_WYPN: 2>
 
+
+   .. py:property:: Lut1DHueAdjust.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_mixingslider.rst

@@ -20,8 +20,6 @@
    .. py:method:: MixingSlider.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: MixingSlider.getSliderMaxEdge(self: PyOpenColorIO.MixingSlider) -> float
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_namedtransform.rst

@@ -12,6 +12,13 @@
    curve" transform where there is no need to convert to or from a reference space.
 
 
+   .. py:method:: NamedTransform.GetTransform(transform: PyOpenColorIO.NamedTransform, direction: PyOpenColorIO.TransformDirection) -> PyOpenColorIO.Transform
+      :module: PyOpenColorIO
+      :staticmethod:
+
+      Get the requested transform, creating the transform from the inverse direction if the transform for the requested direction is missing.
+
+
    .. py:class:: NamedTransform.NamedTransformAliasIterator
       :module: PyOpenColorIO
 
@@ -19,8 +26,6 @@
       .. py:method:: NamedTransform.NamedTransformAliasIterator.__init__(*args, **kwargs)
          :module: PyOpenColorIO
 
-         Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: NamedTransform.__init__(*args, **kwargs)
       :module: PyOpenColorIO
@@ -113,7 +118,7 @@
       :module: PyOpenColorIO
 
 
-   .. py:method:: NamedTransform.setEncoding(self: PyOpenColorIO.NamedTransform, encodig: str) -> None
+   .. py:method:: NamedTransform.setEncoding(self: PyOpenColorIO.NamedTransform, encoding: str) -> None
       :module: PyOpenColorIO
 
 

docs/api/python/frozen/pyopencolorio_namedtransformvisibility.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <NamedTransformVisibility.NAMEDTRANSFORM_INACTIVE: 1>
 
+
+   .. py:property:: NamedTransformVisibility.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_negativestyle.rst

@@ -40,3 +40,7 @@
       :module: PyOpenColorIO
       :value: <NegativeStyle.NEGATIVE_PASS_THRU: 2>
 
+
+   .. py:property:: NegativeStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_optimizationflags.rst

@@ -208,3 +208,7 @@
       :module: PyOpenColorIO
       :value: <OptimizationFlags.OPTIMIZATION_VERY_GOOD: 263995331>
 
+
+   .. py:property:: OptimizationFlags.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_processor.rst

@@ -12,8 +12,6 @@
    .. py:method:: Processor.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: Processor.createGroupTransform(self: PyOpenColorIO.Processor) -> PyOpenColorIO.GroupTransform
       :module: PyOpenColorIO
@@ -31,7 +29,7 @@
       Get an optimized :ref:`CPUProcessor` instance.
 
       .. note::
-         This may provide higher fidelity than anticipated due to internal optimizations. For example, if the inputColorSpace and the outputColorSpace are members of the same family, no conversion will be applied, even though strictly speaking quantization should be added.
+         This may provide higher fidelity than anticipated due to internal optimizations. For example, if the inputColorSpace and the outputColorSpace are members of the same equalitygroup, no conversion will be applied, even though strictly speaking quantization should be added.
 
       .. note::
          The typical use case to apply color processing to an image is:

docs/api/python/frozen/pyopencolorio_processorcacheflags.rst

@@ -40,3 +40,7 @@
       :module: PyOpenColorIO
       :value: <ProcessorCacheFlags.PROCESSOR_CACHE_SHARE_DYN_PROPERTIES: 2>
 
+
+   .. py:property:: ProcessorCacheFlags.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_rangestyle.rst

@@ -26,3 +26,7 @@
       :module: PyOpenColorIO
       :value: <RangeStyle.RANGE_NO_CLAMP: 0>
 
+
+   .. py:property:: RangeStyle.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_referencespacetype.rst

@@ -26,3 +26,7 @@
       :module: PyOpenColorIO
       :value: <ReferenceSpaceType.REFERENCE_SPACE_SCENE: 0>
 
+
+   .. py:property:: ReferenceSpaceType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_rgbcurvetype.rst

@@ -47,3 +47,7 @@
       :module: PyOpenColorIO
       :value: <RGBCurveType.RGB_RED: 0>
 
+
+   .. py:property:: RGBCurveType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_searchreferencespacetype.rst

@@ -31,3 +31,7 @@
       :module: PyOpenColorIO
       :value: <SearchReferenceSpaceType.SEARCH_REFERENCE_SPACE_SCENE: 0>
 
+
+   .. py:property:: SearchReferenceSpaceType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_setcomputehashfunction.rst

@@ -8,5 +8,7 @@
 
    Set the Compute Hash Function to use; otherwise, use the default.
 
+   This is not used when using CreateFromFile with an OCIOZ archive or CreateFromConfigIOProxy.
+
    :param ComputeHashFunction:
 

docs/api/python/frozen/pyopencolorio_transform.rst

@@ -12,8 +12,6 @@
    .. py:method:: Transform.__init__(*args, **kwargs)
       :module: PyOpenColorIO
 
-      Initialize self.  See help(type(self)) for accurate signature.
-
 
    .. py:method:: Transform.getDirection(self: PyOpenColorIO.Transform) -> PyOpenColorIO.TransformDirection
       :module: PyOpenColorIO

docs/api/python/frozen/pyopencolorio_transformdirection.rst

@@ -24,3 +24,7 @@
       :module: PyOpenColorIO
       :value: <TransformDirection.TRANSFORM_DIR_INVERSE: 1>
 
+
+   .. py:property:: TransformDirection.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_transformtype.rst

@@ -164,3 +164,7 @@
       :module: PyOpenColorIO
       :value: <TransformType.TRANSFORM_TYPE_RANGE: 21>
 
+
+   .. py:property:: TransformType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_uniformdatatype.rst

@@ -54,3 +54,7 @@
       :module: PyOpenColorIO
       :value: <UniformDataType.UNIFORM_VECTOR_INT: 4>
 
+
+   .. py:property:: UniformDataType.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_viewtransformdirection.rst

@@ -24,3 +24,7 @@
       :module: PyOpenColorIO
       :value: <ViewTransformDirection.VIEWTRANSFORM_DIR_TO_REFERENCE: 0>
 
+
+   .. py:property:: ViewTransformDirection.value
+      :module: PyOpenColorIO
+

docs/api/python/frozen/pyopencolorio_viewtype.rst

@@ -24,3 +24,7 @@
       :module: PyOpenColorIO
       :value: <ViewType.VIEW_SHARED: 0>
 
+
+   .. py:property:: ViewType.value
+      :module: PyOpenColorIO
+

docs/aswf/charter.rst

@@ -8,7 +8,7 @@ Charter
 =======
 
 See `Charter.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/Charter.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/Charter.md>`__ 
 on GitHub.
 
 Technical Charter (the “Charter”) for OpenColorIO a Series of LF Projects, LLC
@@ -193,7 +193,7 @@ Project must comply with the terms of this Charter.
 
    -  **i.** All new inbound code contributions to the Project must be
       made using the **BSD 3-Clause License (available
-      here: **\ https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE\ **)**
+      here: **\ https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE\ **)**
       (the “Project License”).
    -  **ii.** All new inbound code contributions must:
 

docs/aswf/cla_dco.rst

@@ -12,7 +12,7 @@ follows the open source software best practice policies of the ASWF TAC with
 the guidance from the Linux Foundation.
 
 See `CONTRIBUTING.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/CONTRIBUTING.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/CONTRIBUTING.md>`__ 
 for more information.
 
 CLA
@@ -35,7 +35,7 @@ then you should use the :ref:`Corporate Contributor Licence Agreement <ccla>`.
 
 The OCIO CLA's are the standard forms used by Linux Foundation projects and 
 `recommended by the ASWF TAC 
-<https://github.com/AcademySoftwareFoundation/tac/blob/master/process/contributing.md#contributor-license-agreement-cla>`__.
+<https://github.com/AcademySoftwareFoundation/tac/blob/main/process/contributing.md#contributor-license-agreement-cla>`__.
 
 .. _ccla:
 
@@ -43,7 +43,7 @@ CLA-corporate
 +++++++++++++
 
 See `CLA-corporate.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/CLA-corporate.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/CLA-corporate.md>`__ 
 on GitHub.
 
 ----
@@ -108,7 +108,7 @@ CLA-individual
 ++++++++++++++
 
 See `CLA-individual.md 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/ASWF/CLA-individual.md>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/ASWF/CLA-individual.md>`__ 
 on GitHub.
 
 ----

docs/aswf/license.rst

@@ -12,7 +12,7 @@ library should abide by that license unless otherwised approved by the OCIO
 TSC and ASWF Governing Board.
 
 See `LICENSE 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/LICENSE>`__ 
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/LICENSE>`__ 
 on GitHub.
 
 ----

docs/concepts/overview/internal_architecture.rst

@@ -222,7 +222,7 @@ are loaded, etc.
 CPU CODE PATH
 +++++++++++++
 
-The master list of ops is then optimized, and stored internally in the processor.
+The main list of ops is then optimized, and stored internally in the processor.
 
 .. code-block:: cpp
 
@@ -260,7 +260,7 @@ After all ops have been applied, the results are copied back to the source
 GPU CODE PATH
 +++++++++++++
 
-#. The master list of ops is partitioned into 3 ordered lists:
+#. The main list of ops is partitioned into 3 ordered lists:
 
 - As many ops as possible from the BEGINNING of the op-list that can be done
   analytically in shader text. (called gpu-preops)
@@ -276,7 +276,7 @@ analyze the op-stream metadata and determine the appropriate allocation to use.
 interserting a forward allocation to the end of the pre-ops, and the inverse
 allocation to the start of the lattice ops.
 
-See https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/src/core/NoOps.cpp#L183
+See https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/src/core/NoOps.cpp#L183
 
 #. The 3 lists of ops are then optimized individually, and stored on the processor.
 The Lut3d is computed by applying the gpu-lattice ops, on the CPU, to a lut3d

docs/concepts/publications/publications.rst

@@ -4,11 +4,28 @@
 
 .. _publications:
 
-Publications
-============
+Presentations & Publications
+============================
 
-DigiPro 2020 **paper** `"The ASWF takes OpenColorIO to the Next Level" <https://drive.google.com/file/d/1y_0ZEftivHH0zoKwvKZx3gH_u_cDm1bD/view?usp=sharing>`_
+* OCIO wins the Pipeline Tool award at DigiPro 2022! `video <https://vimeo.com/742052701>`_
 
-DigiPro 2020 **video** `"The ASWF takes OpenColorIO to the Next Level" <https://vimeo.com/458011669>`_
+* ASWF Open Source Days 2022 `video <https://www.youtube.com/watch?v=WzFlz1HeNdI>`_
 
-`Cinematic Color <http://cinematiccolor.org/>`_
+* HPA Tech Retreat 2022 "Color Processing with OCIO v2 and the Academy/ASC Common LUT Format"
+  `Slides & Tutorial <https://drive.google.com/drive/folders/1ZRTIYE6kFb-7sTUtYIYFNJndhY6tmJee?usp=share_link>`_
+
+* OCIO v2 wins an Engineering Excellence award from the Hollywood Post Alliance! 
+  `article <https://www.hollywoodreporter.com/movies/movie-news/hpa-engineering-excellence-award-recipients-announced-1234995410/>`_
+
+* SIGGRAPH 2021 course "Color management with OpenColorIO V2" 
+  `video <https://vimeo.com/689093714>`__  `PDF <https://drive.google.com/file/d/1v37Bz7s1wbJNg-ULsBqnGPA9h7pWNfhU/view?usp=share_link>`__  `ACM <https://dl.acm.org/doi/10.1145/3450508.3464600>`_
+
+* ASWF Open Source Days 2021 `video <https://youtu.be/FSzLwSTJjWo>`_
+
+* DigiPro 2020 "The ASWF takes OpenColorIO to the Next Level" `video <https://vimeo.com/458011669>`__  `PDF <https://drive.google.com/file/d/1y_0ZEftivHH0zoKwvKZx3gH_u_cDm1bD/view?usp=sharing>`__  `ACM <https://dl.acm.org/doi/abs/10.1145/3403736.3403942>`_
+
+* ASWF Open Source Days 2020 `video <https://www.youtube.com/watch?v=7e0SSka8Ar8>`_
+
+* ASWF Open Source Days 2019 `video <https://youtu.be/L5dpFtgZuhQ>`_
+
+* `Cinematic Color <http://cinematiccolor.org/>`_

docs/conf.py

@@ -61,8 +61,8 @@ else:
     description = "@CMAKE_PROJECT_DESCRIPTION@"
     version = "@CMAKE_PROJECT_VERSION@"
     version_major = "@OpenColorIO_VERSION_MAJOR@"
-    version_minor = "@OpenColorIO_VERSION_MAJOR@"
-    version_patch = "@OpenColorIO_VERSION_MAJOR@"
+    version_minor = "@OpenColorIO_VERSION_MINOR@"
+    version_patch = "@OpenColorIO_VERSION_PATCH@"
     ocio_namespace = "@OCIO_NAMESPACE@"
 
 author = "Contributors to the {} Project".format(project)

docs/configurations/_index.rst

@@ -10,8 +10,10 @@ Configurations
 .. toctree::
    :caption: Configurations
 
+   aces_studio
+   aces_cg
+   ocio_v2_demo
    aces_1.0.3
-   nuke_default
    spi_anim
    spi_vfx
-   ocio_v2_demo
+   nuke_default

docs/configurations/aces_1.0.3.rst

@@ -2,17 +2,21 @@
   SPDX-License-Identifier: CC-BY-4.0
   Copyright Contributors to the OpenColorIO Project.
 
+.. _aces_1.0.3:
+
 aces_1.0.3
 ==========
 
 This section describes the ACES 1.0.3 OpenColorIO configuration.
 
 .. note::
-    There is a more recent version of the ACES config for ACES 1.2 available here:
+    There is a more recent version of the ACES 1.0.3 config for ACES 1.2 available here:
 
     - https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.2-config
 
-    An ACES config that takes advantage of the new OCIO v2 features is under development.
+.. note::
+    Please note that both of these configurations have been supplanted by the new 
+    :ref:`aces_studio` for OCIO v2.
 
 
 Information about ACES
@@ -311,7 +315,7 @@ Features exposed for customization by the user include:
 - Selection of shaper function: Log2 or Dolby PQ
 
 **CTL Source**
-The configuration depends on the **ACES 1.0.3** release. The release contains a number of file renames and the new ACEScct color space and a number of minor bug fixes and small additions, but is otherwise very similar as the master **ACES 1.0.2** release. 
+The configuration depends on the **ACES 1.0.3** release. The release contains a number of file renames and the new ACEScct color space and a number of minor bug fixes and small additions, but is otherwise very similar as the main **ACES 1.0.2** release. 
 
 The CTL is available here:
 

docs/configurations/aces_cg.rst

@@ -0,0 +1,42 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+.. _aces_cg:
+
+ACES CG Config
+==============
+
+The ACES Computer Graphics (CG) config is a simple, lightweight config intended for use
+in typical digital content creation (DCC) apps that need robust choices for texture and
+rendering spaces and a basic selection of display and view transforms.
+
+Users who need a more extensive set of color spaces, including digital cinema camera
+color spaces and a wider set of displays and view should look at the :ref:`aces_studio`.
+
+The latest version of this config may be downloaded from the Releases page of its GitHub
+`repo. <https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases>`_
+
+The ACES CG Config leverages the high quality ACES implementation built into OCIO itself
+and so requires no external LUT files.  In fact, even the config file is built into OCIO
+and users may access it from any application that uses OCIO 2.2 or higher by using the
+following string in place of the config path::
+    ocio://cg-config-v1.0.0_aces-v1.3_ocio-v2.1
+
+The default built-in config is currently the ACES CG Config, so the even simpler:
+``ocio://default`` may be used instead.  Note however, that the value of the default
+config may evolve over time.
+
+The OCIO Configs Working Group collected input from the community and simplified the
+naming scheme relative to the earlier OCIO v1 ACES configs.  However, aliases have been 
+added so that the original color space names continue to work (if there is an equivalent
+space in the new config).
+
+Please note that with OCIO v2 we are trying to be more rigorous about what constitutes a 
+"color space". For this reason, the new configs do not bake view transforms or looks into 
+the display color spaces.  Therefore, it is necessary to use a DisplayViewTransform rather 
+than a ColorSpaceTransform if you want to bake in an ACES Output Transform.  This is not 
+only more rigorous from a color management point of view, it also helps clarify to end-users 
+the important role of a view transform in the process.  Baking in a view transform is a 
+fundamentally different process than just converting between color space encodings, and it 
+should be perceived as such by users.

docs/configurations/aces_studio.rst

@@ -0,0 +1,41 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+.. _aces_studio:
+
+ACES Studio Config
+==================
+
+The ACES Studio Config is the successor to the widely used :ref:`ACES config <aces_1.0.3>`
+for OCIO v1.
+
+It contains the complete set of ACES color spaces, displays, and views.  In addition, it
+contains some extra color spaces that are widely used in the VFX and post-production 
+industries.
+
+Users who need a simpler config that contains just the basics needed to use ACES color
+management in common DCC tools are encouraged to check out the :ref:`aces_cg`.
+
+The latest version of this config may be downloaded from the Releases page of its GitHub
+`repo. <https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/releases>`_
+
+The ACES Studio Config leverages the high quality ACES implementation built into OCIO itself
+and so requires no external LUT files.  In fact, even the config file is built into OCIO
+and users may access it from any application that uses OCIO 2.2 or higher by using the
+following string in place of the config path::
+    ocio://studio-config-v1.0.0_aces-v1.3_ocio-v2.1
+
+The OCIO Configs Working Group collected input from the community and simplified the
+naming scheme relative to the earlier OCIO v1 ACES configs.  However, aliases have been 
+added so that the original color space names continue to work (if there is an equivalent
+space in the new config).
+
+Please note that with OCIO v2 we are trying to be more rigorous about what constitutes a 
+"color space". For this reason, the new configs do not bake view transforms or looks into 
+the display color spaces.  Therefore, it is necessary to use a DisplayViewTransform rather 
+than a ColorSpaceTransform if you want to bake in an ACES Output Transform.  This is not 
+only more rigorous from a color management point of view, it also helps clarify to end-users 
+the important role of a view transform in the process.  Baking in a view transform is a 
+fundamentally different process than just converting between color space encodings, and it 
+should be perceived as such by users.

docs/configurations/ocio_v2_demo.rst

@@ -10,6 +10,10 @@ ocio-v2_demo
 Note: this is not intended to be a complete production-ready config, its purpose
 is to introduce many of the new features in OCIO v2.
 
+Due to the limitations of the web template, it may be easier for you to read this
+config in a text editor.  The config file is located 
+`here. <https://github.com/AcademySoftwareFoundation/OpenColorIO/tree/main/docs/configurations/ocio-v2_demo.ocio>`_ 
+
 
 .. literalinclude:: ocio-v2_demo.ocio
    :language: yaml

docs/guides/authoring/colorspaces.rst

@@ -15,19 +15,19 @@ Colorspaces
 
 Required.
 
-This section is a list of all the colorspaces known to OCIO. A
-colorspace can be referred to elsewhere within the config (including
+This section is a list of the scene-referred colorspaces in the config.
+A colorspace may be referred to elsewhere within the config (including
 other colorspace definitions), and are used within OCIO-supporting
 applications.
 
-A color space may use the following keys:
+A colorspace may use the following keys:
 
 
 ``to_scene_reference`` and ``from_scene_reference``
 ---------------------------------------------------
 
 These keys specify the transforms that define the relationship between
-the color space and the scene-referred reference space.
+the colorspace and the scene-referred reference space.
 
 Note: In OCIO v1, the keys ``to_reference`` and ``from_reference`` were
 used (since there was only one reference space).  These are still supported
@@ -404,10 +404,10 @@ compatibility.
 
 Optional.
 
-These two options are used when OCIO transforms are applied on the
-GPU.
+These two options were used in OCIO v1 when transforms were applied on the
+GPU.  However, the new GPU renderer in OCIO v2 does not need these.
 
-It is also used to automatically generate a "shaper LUT" when
+However, they may still be used to automatically generate a "shaper LUT" when
 :ref:`baking LUT's <userguide-bakelut>` unless one is explicitly
 specified (not all output formats utilise this)
 
@@ -469,6 +469,8 @@ It's common to use literal ``|`` block syntax to preserve all newlines:
         This is the second.
 
 
+.. _config-display-colorspaces:
+
 Display Colorspaces
 *******************
 
@@ -477,7 +479,7 @@ Display Colorspaces
 
 Optional.
 
-This section is a list of all the display colorspaces known to OCIO. 
+This section is a list of all the display-referred colorspaces in the config. 
 A display colorspace is very similar to a colorspace except its transforms
 go from or to the display-referred reference space rather than the
 scene-referred reference space.

docs/guides/authoring/looks_example.rst

@@ -142,7 +142,7 @@ Example:
 
 
 Note that if the per-shot lut is not found, you can control whether a
-fallback LUT succeeds based on if it's in the master location. You can
+fallback LUT succeeds based on if it's in the main location. You can
 also use this for multiple levels (show, shot, etc).
 
 Advanced option: If some shots use .cc files, and some use 3d-luts

docs/guides/authoring/overview.rst

@@ -18,6 +18,12 @@ This page alone will not help you to write a useful config file! See
 the :ref:`configurations` section for examples of complete, practical
 configs, and discussion of how they fit within a facilities workflow.
 
+Please note that you should use the OCIO Python or C++ API to generate
+the config.ocio file rather than writing the YAML by hand in a text editor.
+However, if you do ever modify YAML by hand rather than via the API, you
+should run :ref:`overview-ociocheck` on it to ensure that the syntax is
+correct.
+
 YAML basics
 ***********
 
@@ -29,7 +35,7 @@ has a good overview.
 
 OCIO configs typically use a small subset of YAML, so looking at
 existing configs is probably the quickest way to familiarise yourself
-(just remember the indentation is important!)
+(just remember the indentation is important!).
 
 Checking for errors
 *******************
@@ -59,8 +65,12 @@ An OCIO config has the following sections:
 * :ref:`config-displays-views` -- This section defines how color spaces should be viewed.
 * :ref:`config-looks` -- Looks are transforms used to adjust colors, such as to apply a
   creative effect.
-* :ref:`config-colorspaces` -- This section defines the universe of color space encodings
+* :ref:`config-colorspaces` -- This section defines the scene-referred color space encodings
   available within the config.
+* :ref:`config-display-colorspaces` -- This section defines the display-referred color space
+  encodings available within the config.
+* :ref:`config-named-transforms` -- Named Transforms are a way to provide transforms that
+  do not have a fixed relationship to a specific reference space, such as a utility curve.
 
 A collection of :ref:`config-transforms` is provided for use in the various sections
 of the config file.
@@ -99,11 +109,12 @@ Optional. A brief description of the configuration.
 ``name``
 ^^^^^^^^
 
-Optional. A unique name for the config.
+Optional. A unique name for the config.  Future versions of OCIO might use this as a
+sort of "namespace" for the color spaces defined in the rest of the config.
 
 .. code-block:: yaml
 
-    name: foo_2021-02-01
+    name: studio-config-v1.0.0_aces-v1.3_ocio-v2.1
 
 
 ``search_path``

docs/guides/authoring/rules.rst

@@ -16,7 +16,9 @@ File & Viewing rules
 ``file_rules``
 ^^^^^^^^^^^^^^
 
-Either file_rules or the default role are Required.
+.. warning::
+    Either the file_rules section or the default role are Required for configs of
+    version 2 or higher.
 
 Use the File Rules to assign a default color space to files based on their path.
 
@@ -24,10 +26,10 @@ Here is example showing the various types of rules that may be defined:
 
 .. code-block:: yaml
 
-  files_rules:
+  file_rules:
     - !<Rule> {name: LogC, extension: "*", pattern: "*LogC*", colorspace: ARRI LogC}
     - !<Rule> {name: OpenEXR, extension: "exr", pattern: "*", colorspace: ACEScg}
-    - !<Rule> {name: TIFF, regex: ".*\.TIF?F$", colorspace: sRGB}
+    - !<Rule> {name: TIFF, regex: ".*\\.TIF?F", colorspace: sRGB}
     - !<Rule> {name: ColorSpaceNamePathSearch}
     - !<Rule> {name: Default, colorspace: default}
 
@@ -42,36 +44,41 @@ other keys depend on the rule type.
 This is the basic rule type that uses Unix glob style pattern matching and is 
 thus very easy to use. It contains the keys:
 
-* ``name``: Name of the rule
+* ``name``: Name of the rule.
 * ``pattern``: Glob pattern to be used for the main part of the name/path.
-  This is case-sensitive.
+  This is case-sensitive.  It must be in double-quotes.  Set it to "*" if you only 
+  want the rule to consider the extension.
 * ``extension``: Glob pattern or string to be used for the file extension. Note that
   if glob tokens are not used, the extension will be used in a non-case-sensitive 
   way by default.  For example the simple string "exr" would match "exr" and "EXR".  
-  If you only want to match "exr", use the glob pattern "[e][x][r]".
+  If you only want to match "exr", use the glob pattern "[e][x][r]".  It must be 
+  in double-quotes.  Set it to "*" if you only want the rule to consider the pattern.
 * ``colorspace``: ColorSpace name to be returned.
 
-2. Regex Rules -- 
+2. RegEx Rules -- 
 This is similar to the basic rule but allows additional capabilities for 
 power-users. It contains the keys:
 
-* ``name``: Name of the rule
-* ``regex``: Regular expression to be evaluated.
+* ``name``: Name of the rule.
+* ``regex``: Regular expression to be evaluated.  It must be in double-quotes.
 * ``colorspace``: ColorSpace name to be returned.
 
+Note that a backslash character in a RegEx expression needs to be doubled up as ``\\``
+(as shown in the example above for the TIFF rule) to make it through the Yaml parsing.
+
 3. OCIO v1 style Rule -- 
 This rule allows the use of the OCIO v1 style, where the string is searched for 
 ColorSpace names from the config. This rule may occur 0 or 1 times in the list. 
 The position in the list prioritizes it with respect to the other rules. It has 
 the key:
 
-* ``name``: Must be "ColorSpaceNamePathSearch".
+* ``name``: Must be ``ColorSpaceNamePathSearch``.
 
 4. Default Rule -- 
-The file_rules must always end with this rule. If no prior rules match, this 
+The file_rules section must always end with this rule. If no prior rules match, this 
 rule specifies the ColorSpace applications will use. It has the keys:
 
-* ``name``: must be "Default".
+* ``name``: must be ``Default``.
 * ``colorspace``: ColorSpace name to be returned.
 
 Note: OCIO v1 defined a ``default`` role intended to specify a default color space
@@ -84,19 +91,24 @@ missing, an exception will be thrown when loading the config.
 
 Note that the strictparsing token does not affect the behavior of the File Rules 
 API. In other words, evaluating the rules will always result in a ColorSpace being 
-available to an application. However, the API alsos allow the application to know 
+available to an application. However, the API also allows the application to know 
 which rule was the matching one. So apps that want to work in "strict" mode should 
 first check if strictparsing is true and if so check to see if the matching rule 
 was the Default Rule. If so, it could then notify the user and take whatever action 
-is appropriate.
+is appropriate.  (As an alternative to checking which rule number was matched, the 
+API call ``filepathOnlyMatchesDefaultRule`` may be used instead.)
 
 Roles may be used rather than ColorSpace names in the rules.
 
-It is also legal for rules  to have additional key:value pairs where the value 
+It is also legal for rules to have additional key:value pairs where the value 
 may be an arbitrary string. The API provides access to getting/setting these 
 additional pairs and will preserve them on a Config read/write.  These may be
 used to define application-specific behavior.
 
+Note to developers: The older ``parseColorSpaceFromString`` API call is now deprecated
+and should be replaced with ``getColorSpaceFromFilepath``.
+
+
 ``strictparsing``
 ^^^^^^^^^^^^^^^^^
 
@@ -107,12 +119,21 @@ Optional. Valid values are ``true`` and ``false``. Default is ``true``
 
     strictparsing: true
 
-OCIO provides a mechanism for applications to extract the colorspace
-from a filename (the ``parseColorSpaceFromString`` API method)
+.. warning::
+    This attribute is from OCIO v1.  In OCIO v2, the FileRules system was
+    introduced and so the ``strictparsing`` attribute is less relevant now.
+    The ``parseColorSpaceFromString`` API call is now deprecated and the
+    proper way to obtain this information is ``getColorSpaceFromFilepath``.
+    The FileRules always return a default color space but the API
+    ``filepathOnlyMatchesDefaultRule`` may be used by applications that
+    want to take some special action if ``strictparsing`` is true.
+
+OCIO v1 provided a mechanism for applications to extract the colorspace
+from a filename (the ``parseColorSpaceFromString`` API method).
 
 So for a file like ``example_render_v001_lnf.0001.exr`` it will
 determine the colorspace ``lnf`` (it being the right-most substring
-containing a colorspace name)
+containing a colorspace name).
 
 However, if the colorspace cannot be determined and ``strictparsing:
 true``, it will return an empty string.

docs/guides/authoring/transforms.rst

@@ -344,6 +344,7 @@ Keys:
     must also be present and the result is clamped at the high end.
 
 
+.. _config-named-transforms:
 
 Named Transforms
 ****************

docs/guides/contributing/documentation_guidelines.rst

@@ -14,18 +14,39 @@ The documentation primarily lives in the ``docs/`` folder, within the
 main OpenColorIO repository.
 
 The rST source for the C++ API documentation is extracted from
-comments in the public header files in ``export/``
+comments in the public header files in ``include/``
 
-The Python API documentation is extracted from dummy .py files within
-the ``src/pyglue/DocStrings/`` folder
+Installation of requirements
+****************************
+
+Scripts are available, for each platform, to install the documentation 
+requirements.
+
+The ``install_docs_env.sh`` script in the share/ci/scripts/<Platform> directory
+will install the Python-related requirements for building the documentation
+(Sphinx, six, testresources, recommonmark, sphinx-press-theme, sphinx-tabs,
+and breathe) and Doxygen.  
+
+Use GitBash (`provided with Git for Windows <https://gitforwindows.org/>`_) to 
+execute the script on Windows.
+
+Python 3 is required to build the documentation. If you have multiple Python
+installs you'll need to make sure pip and CMake find the correct version. You 
+can manually inform CMake of which to use by adding this option to the below 
+`cmake` command, which configures the documentation build:
+
+    -DPython_ROOT=<Path to Python 3 root directory>
+
+For the Python packages, ensure their locations are in your ``PYTHONPATH`` 
+environment variable prior to configuring the build.
 
 Building the docs
 *****************
 
-Just like a :ref:`regular build from source <building-from-source>`,
-but specify the ``-D OCIO_BUILD_DOCS=yes`` argument to CMake.
+The build is just like a :ref:`regular build from source <building-from-source>`,
+but specify the ``-D OCIO_BUILD_DOCS=ON`` argument to CMake.
 
-Then run the ``make doc`` target. The default HTML output will be
+Then run the ``make docs`` target. The default HTML output will be
 created in ``build_dir/docs/build-html/``
 
 Note that CMake must be run before each invocation of ``make`` to copy
@@ -37,7 +58,50 @@ Initial run::
 
 Then after each change you wish to preview::
 
-    $ cmake -D OCIO_BUILD_DOCS=yes .. && make doc
+    $ cmake -D OCIO_BUILD_DOCS=ON .. && make docs
+
+Updating the Python docs
+************************
+
+If a contributor makes changes to any part of OCIO which affects the Python API docs 
+(so, public headers, Python bindings, any documentation process code, etc.) they should 
+do a local build with the new CMake option -DOCIO_BUILD_FROZEN_DOCS=ON, and add the 
+modified rST files under docs/api/python/frozen to their PR.
+
+Note: If you run the scripts on Linux, the freezing process should work well.  On other 
+platforms, the process may sometimes make spurious deltas to rST files unrelated to your 
+changes.  Please don't add these files to your PR.
+
+The OCIO conf.py module has a switch that detects when docs are being built on GH Actions 
+(CI env var == true) it will backup the frozen folder to a sibling backup folder on Sphinx 
+init, and following Sphinx build completion will do a file-by-file comparison of the new 
+frozen and the backup folders. If there are differences, the CI job may fail with an error 
+explaining where the differences were found and with instructions on how to fix them.
+
+The conf.py also has a switch that detects when it is being run on RTD, and in that case 
+will itself run Doxygen to generate the XML needed by breathe prior to building the docs, 
+and will also facilitate a CMake configure_file-like process (via Python) to handle 
+substitutions in headers and docs source files that CMake would usually handle, but can't 
+in this case. One potential plus to all of this is that if someone wants to just build 
+OCIO docs, they can technically do so by running sphinx-build in the docs directory, and 
+nothing more. Right now that only works when the READTHEDOCS env var == True, but it could 
+be easily exposed another way if needed.
+
+These features required several custom Sphinx extensions tuned for our project which are
+located under share/docs.
+
+Building the docs -- Excluding the API docs
+*******************************************
+
+If you don't need to build the API documentation, there is a quick and dirty way to 
+do a docs build.  This approach does not need to compile the C++ code but is not ideal
+since it modifies files in the source directory rather than the build directory:
+
+    export READTHEDOCS=True
+    cd docs  (in the source directory)
+    mkdir _build
+    sphinx-build -b html . _build
+    <your web browser name> _build/index.html
 
 Basics
 ******
@@ -79,6 +143,30 @@ Basics
 
       In order to bake a LUT, ...
 
+Quirks
+******
+
+The vuepress theme that we've migrated to has some quirks to its design. For
+example, it only allows two nested table of contents (TOC). So things have to be
+organized in a slightly different way than other sphinx projects.
+
+The root-level `toc_redirect.rst` points to where to find the different section
+TOCs. The name and contents of each sections TOC is defined in that
+sub-directory's `_index.rst` file.
+
+In this TOC the `:caption:` directive determines what the name of the section
+will be in the sidebar, and in the header of the website. The *H1* header
+determines the name of the page in the right/left arrows navigation bar. In a
+lot of cases this ends up doubling up the name on the page, but this seems
+unavoidable at the present time. If additional explanatory text is put in the
+`_index.rst` files then it shouldn't be as problematic.
+
+The site will show all *H1* headers in the side panel by default, these then
+expand when selected to show all *H2* headers.
+
+Due to the limited TOC and sidebar depth, we shouldn't be afraid of looong
+pages with many *H2* headings to break down the page into logical quadrants.
+
 Emacs rST mode
 **************
 

docs/guides/contributing/getting_started.rst

@@ -10,12 +10,12 @@ Getting started
 Checking Out The Codebase
 *************************
 
-The master code repository is available on Github:  http://github.com/AcademySoftwareFoundation/OpenColorIO
+The main code repository is available on Github:  http://github.com/AcademySoftwareFoundation/OpenColorIO
 
 For those unfamiliar with git, the wonderful part about it is that even though
-only a limited number people have write access to the master repository, anyone
+only a limited number people have write access to the main repository, anyone
 is free to create, and even check in, changes to their own local git repository. 
-Your local changes will not automatically be pushed back to the master
+Your local changes will not automatically be pushed back to the main
 repository, so everyone feel free to informally play around with the codebase.
 Also - unlike svn - when you download the git repository you have a full copy of
 the project's history (including revision history, logs, etc), so the majority
@@ -47,7 +47,7 @@ To check out a read-write version of the repository (GitHub acct required)::
     Receiving objects: 100% (2220/2220), 2.89 MiB | 2.29 MiB/s, done.
     Resolving deltas: 100% (1434/1434), done.
 
-Both read + read/write users should then add the `AcademySoftwareFoundation/OpenColorIO <https://github.com/AcademySoftwareFoundation/OpenColorIO>`_ master branch
+Both read + read/write users should then add the `AcademySoftwareFoundation/OpenColorIO <https://github.com/AcademySoftwareFoundation/OpenColorIO>`_ main branch
 as a remote. This will allow you to more easily fetch updates as they become
 available::
 
@@ -104,33 +104,33 @@ commits, and in the case of in-progress feature branches, you'll need to merge
 those changes or rebase your commits on top of them regularly to stay up to 
 date. To update your fork from upstream run the::
 
-    git checkout master
-    git pull upstream master && git push origin master
+    git checkout main
+    git pull upstream main && git push origin main
 
-The first command makes sure you have the master branch checked out, and the 
+The first command makes sure you have the main branch checked out, and the 
 second combines an upstream pull (getting all the new commits to bring your
 local clone up to date) and an origin push (updating your fork's remote 
-master). Following these commands the master branch will be identical between
+main). Following these commands the main branch will be identical between
 the OpenColorIO repository and your fork.
 
 To merge these changes into a feature branch (making the branch able to merge 
-with the upstream master), run::
+with the upstream main), run::
 
     git checkout myFeature
-    git merge master
+    git merge main
 
 git will report any merge conflicts encountered and allow you to resolve them 
 locally prior to committing the merge.
 
 Alternatively you can rebase the changes into your branch, which will replay
-your branch commits on top of the latest master branch commits. A rebase should
+your branch commits on top of the latest main branch commits. A rebase should
 only be used if you are the only contributor to a branch. Since rebasing alters
 the branch's commit history, a force push is required to push the changes to
 the remote repository, which can be problematic for others contributing to the
 same branch. To rebase, run::
 
     git checkout myFeature
-    git rebase master
+    git rebase main
 
 Follow the interactive instructions that git provides during the rebase to 
 resolve merge conflicts at each replayed commit. Update your remote branch

docs/guides/contributing/issues.rst

@@ -28,4 +28,4 @@ help reproduce code-related defects.
 
 If the issue you are reporting is related to a security vulnerability, please 
 follow the reporting procedures outlined in the `OpenColorIO security policy 
-<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/master/SECURITY.md>`__.
+<https://github.com/AcademySoftwareFoundation/OpenColorIO/blob/main/SECURITY.md>`__.

docs/guides/contributing/repository_structure.rst

@@ -10,16 +10,16 @@ Repository structure
 The OpenColorIO repository has a relatively straight-forward structure, and a 
 simple branching and merging strategy.
 
-All development work is done directly on the master branch. This represents 
+All development work is done directly on the main branch. This represents 
 the bleeding-edge of the project and any contributions should be done on top of 
 it.
 
-After sufficient work is done on the master branch and OCIO leadership 
+After sufficient work is done on the main branch and OCIO leadership 
 determines that a release is due, we will bump the relevant internal versioning 
 and tag a commit with the corresponding version number, e.g. v2.0.1. Each Minor 
 version also has its own “Release Branch”, e.g. RB-1.1. This marks a branch of 
 code dedicated to that Major.Minor version, which allows upstream bug fixes to 
-be cherry-picked to a given version while still allowing the master branch to 
+be cherry-picked to a given version while still allowing the main branch to 
 continue forward onto higher versions. This basic repository structure keeps 
 maintenance low, while remaining simple to understand.
 
@@ -45,32 +45,32 @@ continuous integration (CI) workflows for all supported platforms. Each .yml
 file defines one GHA workflow, which can contain one or more jobs and the 
 repository events that trigger the workflow.
 
+ASWF
+****
+
+This subdirectory contains important ASWF governance documents like the 
+OpenColorIO charter, CLAs and DCO reference.
+
+The ``meetings`` subdirectory contains historical meeting minutes for 
+TSC (Technical Steering Committee) and working group meetings.  More 
+recent TSC and working group meeting notes are stored on the 
+`ASWF Wiki. <https://wiki.aswf.io/display/OCIO/Meetings>`_
+
 docs
 ****
 
 This directory contains the OpenColorIO documentation source and build 
 configuration. 
 
-The ``guides/contributing/tsc`` subdirectory contains meeting minutes for all 
-recorded TSC (Technical Steering Committee) and working group meetings. The 
-``guides/contributing/aswf`` subdirectory contains important ASWF governance 
-documents like the OpenColorIO charter, CLAs and DCO reference.
-
 See :ref:`documentation-guidelines` for information on contributing to OCIO
 documentation.
 
 ext
 ***
 
-This directory serves two purposes:
-
-1. House modified external dependencies which are permissible to store within 
-   the OpenColorIO repository. Permissible dependencies have compatible FOSS
-   licenses which have documented approval by the ASWF governing board.
-
-2. Location for external dependencies temporarily installed and statically 
-   linked by OpenColorIO when using the CMake ``OCIO_INSTALL_EXT_PACKAGES`` 
-   option with the value ``MISSING`` or ``ALL``.
+Houses modified external dependencies which are permissible to store within 
+the OpenColorIO repository. Permissible dependencies have compatible FOSS
+licenses which have documented approval by the ASWF governing board.
 
 include
 *******
@@ -112,8 +112,8 @@ following subdirectories:
   this work is welcome and appreciated).
 
 - **libutils**: Supplementary and example helper libraries for integrating 
-  OpenColorIO into applications. Utilities for using OCIO with OpenGL and 
-  OpenImageIO are included.
+  OpenColorIO into applications. Utilities for using OCIO with OpenGL
+  and with OpenImageIO/OpenEXR are included.
   
 - **utils**: Common header-only utilities shared by the core OpenColorIO 
   library and the other utility sources.