Fix ocioconvert invalid bidepth handling (#2323)

Signed-off-by: zial <zhenlai1013@gmail.com>
Co-authored-by: Doug Walker <doug.walker@autodesk.com>

.github/dependabot.yml

@@ -0,0 +1,20 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+
+version: 2
+
+updates:
+
+  - package-ecosystem: "github-actions"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    # Only do security updates rather than all version updates.
+    open-pull-requests-limit: 0
+
+  - package-ecosystem: "pip"
+    directory: "/"
+    schedule:
+      interval: "monthly"
+    # Only do security updates rather than all version updates.
+    open-pull-requests-limit: 0

.github/workflows/analysis_workflow.yml

@@ -7,166 +7,49 @@
 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:
-    name: 'Linux CentOS 7 VFX CY${{ matrix.vfx-cy }} latest 
-      <${{ matrix.compiler-desc }} 
-       cxx=${{ matrix.cxx-standard }}, 
-       docs=${{ matrix.build-docs }}>'
-    # Don't run on OCIO forks
-    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
-    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
-    runs-on: ubuntu-latest
-    container:
-      # DockerHub: https://hub.docker.com/u/aswf
-      # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
-      image: aswf/ci-base:${{ matrix.vfx-cy }}
-    strategy:
-      matrix:
-        build: [1, 2, 3, 4, 5, 6]
-        include:
-          # -------------------------------------------------------------------
-          # GCC, VFX CY2020
-          # -------------------------------------------------------------------
-          # C++11, Python 3.7
-          - build: 1
-            build-docs: 'ON'
-            cxx-standard: 11
-            cxx-compiler: g++
-            cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
-          # C++14
-          - build: 2
-            build-docs: 'OFF'
-            cxx-standard: 14
-            cxx-compiler: g++
-            cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
-          # -------------------------------------------------------------------
-          # GCC, VFX CY2019
-          # -------------------------------------------------------------------
-          # Python 2.7
-          - build: 3
-            # Doc build requires Python 3
-            build-docs: 'OFF'
-            cxx-standard: 11
-            cxx-compiler: g++
-            cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2019
-          # -------------------------------------------------------------------
-          # Clang, VFX CY2020
-          # -------------------------------------------------------------------
-          # C++11, Python 3.7
-          - build: 4
-            build-docs: 'OFF'
-            cxx-standard: 11
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # C++14
-          - build: 5
-            build-docs: 'OFF'
-            cxx-standard: 14
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # -------------------------------------------------------------------
-          # Clang, VFX CY2019
-          # -------------------------------------------------------------------
-          # Python 2.7
-          - build: 6
-            # Doc build requires Python 3
-            build-docs: 'OFF'
-            cxx-standard: 11
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2019
-    env:
-      CXX: ${{ matrix.cxx-compiler }}
-      CC: ${{ matrix.cc-compiler }}
-    steps:
-      - name: Checkout
-        uses: actions/checkout@v2
-      - 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_oiio.sh latest
-      - name: Install latest documentation ext package versions
-        run: |
-          share/ci/scripts/linux/install_sphinx.sh latest
-          share/ci/scripts/linux/install_testresources.sh latest
-          share/ci/scripts/linux/install_recommonmark.sh latest
-          share/ci/scripts/linux/install_sphinx-press-theme.sh latest
-          share/ci/scripts/linux/install_sphinx-tabs.sh latest
-        if: matrix.build-docs == 'ON'
-      - 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_GPU_TESTS=OFF \
-                -DOCIO_INSTALL_EXT_PACKAGES=NONE \
-                -DOCIO_WARNING_AS_ERROR=OFF \
-                -DPython_EXECUTABLE=$(which python)
-        working-directory: _build
-      - name: Build
-        run: |
-          cmake --build . \
-                --target install \
-                --config Release \
-                -- -j$(nproc)
-        working-directory: _build
-      - name: Test
-        run: ctest -V
-        working-directory: _build
-
   # ---------------------------------------------------------------------------
   # SonarCloud static analysis
   # ---------------------------------------------------------------------------
 
   linux_sonarcloud:
-    name: 'Linux CentOS 7 VFX CY2020 SonarCloud <GCC 6.3.1>'
+    name: 'Linux VFX CY2023 SonarCloud'
     # Don't run on OCIO forks
     if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
-    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
+    # GH-hosted VM. The build runs in ASWF 'container' defined below.
     runs-on: ubuntu-latest
     container:
       # DockerHub: https://hub.docker.com/u/aswf
       # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
-      image: aswf/ci-ocio:2020
+      image: aswf/ci-ocio:2023
     env:
       CXX: g++
       CC: gcc
     steps:
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
         with:
           fetch-depth: 50
+      - name:  Install build-wrapper
+        uses: SonarSource/sonarqube-scan-action/install-build-wrapper@59db25f34e16620e48ab4bb9e4a5dce155cb5432 # v8.0.0
+      - name: Install docs env
+        run: share/ci/scripts/linux/dnf/install_docs_env.sh
+      - name: Install tests env
+        run: share/ci/scripts/linux/dnf/install_tests_env.sh
       - name: Create build directories
         run: |
           mkdir _install
@@ -176,7 +59,7 @@ jobs:
           cmake ../. \
                 -DCMAKE_INSTALL_PREFIX=../_install \
                 -DCMAKE_BUILD_TYPE=Release \
-                -DCMAKE_CXX_STANDARD=11 \
+                -DCMAKE_CXX_STANDARD=17 \
                 -DCMAKE_CXX_FLAGS="-g -O0 -fprofile-arcs -ftest-coverage" \
                 -DCMAKE_CXX_OUTPUT_EXTENSION_REPLACE=ON \
                 -DCMAKE_EXE_LINKER_FLAGS="-lgcov" \
@@ -190,12 +73,12 @@ 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
       - name: Run sonar-scanner
+        uses: SonarSource/sonarqube-scan-action@59db25f34e16620e48ab4bb9e4a5dce155cb5432 # v8.0.0
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
-        run: sonar-scanner -X -Dsonar.login=$SONAR_TOKEN

.github/workflows/ci_workflow.yml

@@ -40,200 +40,219 @@ jobs:
   # ---------------------------------------------------------------------------
 
   linux:
-    name: 'Linux CentOS 7 VFX CY${{ matrix.vfx-cy }} 
+    name: 'Linux VFX CY${{ matrix.vfx-cy }} 
       <${{ matrix.compiler-desc }} 
        config=${{ matrix.build-type }}, 
        shared=${{ matrix.build-shared }}, 
-       sse=${{ matrix.use-sse }}, 
+       simd=${{ matrix.use-simd }}, 
        cxx=${{ matrix.cxx-standard }}, 
-       docs=${{ matrix.build-docs }}>'
-    # GH-hosted VM. The build runs in CentOS 7 'container' defined below.
+       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 ASWF 'container' defined below.
     runs-on: ubuntu-latest
     container:
       # DockerHub: https://hub.docker.com/u/aswf
       # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
-      image: aswf/ci-ocio:${{ matrix.vfx-cy }}
+      image: aswf/ci-ocio:${{ matrix.container-tag || matrix.vfx-cy }}
     strategy:
+      fail-fast: false
       matrix:
         build: [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]
         include:
           # -------------------------------------------------------------------
-          # VFX CY2021
+          # VFX CY2026 (Python 3.13)
           # -------------------------------------------------------------------
           - build: 12
             build-type: Debug
             build-shared: 'ON'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'OFF'
-            cxx-standard: 17
+            build-openfx: 'ON'
+            use-simd: 'ON'
+            use-oiio: 'ON'
+            aswf-ocio-version: 2.5.2
+            cxx-standard: 20
             cxx-compiler: clang++
             cc-compiler: clang
-            compiler-desc: Clang 9
-            vfx-cy: 2021
+            compiler-desc: Clang
+            vfx-cy: 2026
+            install-ext-packages: MISSING
           - build: 11
             build-type: Release
             build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            use-oiio: 'OFF'
             cxx-standard: 17
             cxx-compiler: g++
             cc-compiler: gcc
-            compiler-desc: GCC 9.3.1
-            vfx-cy: 2021
-          # -------------------------------------------------------------------
-          # GCC, VFX CY2020
-          # -------------------------------------------------------------------
-          # C++11, Python 3.7
+            compiler-desc: GCC
+            vfx-cy: 2026
+            install-ext-packages: ALL
           - build: 10
             build-type: Release
-            build-shared: 'ON'
-            build-docs: 'ON'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
+            build-shared: 'OFF'
+            build-docs: 'OFF'
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
             cxx-compiler: g++
             cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
-          # Debug
+            compiler-desc: GCC
+            vfx-cy: 2026
+            install-ext-packages: ALL
+          # -------------------------------------------------------------------
+          # VFX CY2025 (Python 3.11)
+          # -------------------------------------------------------------------
           - build: 9
             build-type: Debug
             build-shared: 'ON'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            cxx-compiler: g++
-            cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
-          # C++14
+            build-openfx: 'ON'
+            use-simd: 'ON'
+            use-oiio: 'ON'
+            aswf-ocio-version: 2.4.2
+            cxx-standard: 20
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            vfx-cy: 2025
+            install-ext-packages: MISSING
           - build: 8
             build-type: Release
             build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 14
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            use-oiio: 'OFF'
+            cxx-standard: 17
             cxx-compiler: g++
             cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
-          # Static, no SSE
+            compiler-desc: GCC
+            vfx-cy: 2025
+            install-ext-packages: ALL
           - build: 7
             build-type: Release
             build-shared: 'OFF'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'OFF'
-            cxx-standard: 11
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
             cxx-compiler: g++
             cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2020
+            compiler-desc: GCC
+            vfx-cy: 2025
+            install-ext-packages: ALL
           # -------------------------------------------------------------------
-          # GCC, VFX CY2019
+          # VFX CY2024 (Python 3.11)
           # -------------------------------------------------------------------
-          # Python 2.7
           - build: 6
-            build-type: Release
+            build-type: Debug
             build-shared: 'ON'
-            # Doc build requires Python 3
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            cxx-compiler: g++
-            cc-compiler: gcc
-            compiler-desc: GCC 6.3.1
-            vfx-cy: 2019
-          # -------------------------------------------------------------------
-          # Clang, VFX CY2020
-          # -------------------------------------------------------------------
-          # C++11, Python 3.7
+            build-openfx: 'ON'
+            use-simd: 'ON'
+            use-oiio: 'ON'
+            aswf-ocio-version: 2.3.2
+            cxx-standard: 20
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            vfx-cy: 2024
+            install-ext-packages: MISSING
           - build: 5
             build-type: Release
             build-shared: 'ON'
             build-docs: 'ON'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # Debug
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2024
+            install-ext-packages: ALL
           - build: 4
-            build-type: Debug
-            build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            build-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # C++14
-          - build: 3
-            build-type: Release
-            build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 14
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # Static, no SSE
-          - build: 2
             build-type: Release
             build-shared: 'OFF'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'OFF'
-            cxx-standard: 11
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2024
+            install-ext-packages: ALL
+          # -------------------------------------------------------------------
+          # VFX CY2023 (Python 3.10)
+          # -------------------------------------------------------------------
+          - build: 3
+            build-type: Debug
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-openfx: 'ON'
+            use-simd: 'ON'
+            use-oiio: 'ON'
+            aswf-ocio-version: 2.2.1
+            cxx-standard: 20
             cxx-compiler: clang++
             cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2020
-          # -------------------------------------------------------------------
-          # Clang, VFX CY2019
-          # -------------------------------------------------------------------
-          # Python 2.7
-          - build: 1
+            compiler-desc: Clang
+            vfx-cy: 2023
+            install-ext-packages: MISSING
+          - build: 2
             build-type: Release
             build-shared: 'ON'
-            # Doc build requires Python 3
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2023
+            install-ext-packages: ALL
+          - build: 1
+            build-type: Release
+            build-shared: 'OFF'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            cxx-compiler: clang++
-            cc-compiler: clang
-            compiler-desc: Clang 7
-            vfx-cy: 2019
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2023
+            install-ext-packages: ALL
     env:
       CXX: ${{ matrix.cxx-compiler }}
       CC: ${{ matrix.cc-compiler }}
     steps:
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install docs env
+        run: share/ci/scripts/linux/dnf/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/linux/dnf/install_tests_env.sh
+      - name: Install ASWF OpenColorIO for OpenImageIO
+        # The container's prebuilt OpenImageIO is linked against a specific
+        # OpenColorIO release that the container does not ship (it's built
+        # from source here instead). Fetch that release from the ASWF Conan
+        # remote so OpenImageIO's dependency resolves at link/run time.
+        if: matrix.use-oiio == 'ON'
+        run: share/ci/scripts/linux/dnf/install_aswf_opencolorio.sh ${{ matrix.aswf-ocio-version }} ${{ matrix.vfx-cy }}
       - name: Create build directories
         run: |
           mkdir _install
@@ -246,10 +265,11 @@ jobs:
                 -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
                 -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
                 -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
-                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
-                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
-                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
-                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_USE_SIMD=${{ matrix.use-simd }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
+                -DOCIO_INSTALL_EXT_PACKAGES=${{ matrix.install-ext-packages }} \
                 -DOCIO_WARNING_AS_ERROR=ON \
                 -DPython_EXECUTABLE=$(which python)
         working-directory: _build
@@ -259,98 +279,106 @@ 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 with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --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.8.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
+  # macOS Intel
   # ---------------------------------------------------------------------------
 
   macos:
-    name: 'macOS 10.15 
-      <AppleClang 11.0 
+    name: 'macOS 15 intel
+      <AppleClang 
+       arch=${{ matrix.arch-type }},
        config=${{ matrix.build-type }}, 
        shared=${{ matrix.build-shared }}, 
-       sse=${{ matrix.use-sse }}, 
+       simd=${{ matrix.use-simd }}, 
        cxx=${{ matrix.cxx-standard }}, 
        python=${{ matrix.python-version }}, 
-       docs=${{ matrix.build-docs }}>'
-    runs-on: macos-10.15
+       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-15-intel
     strategy:
       matrix:
-        build: [1, 2, 3, 4, 5, 6]
+        build: [3, 4]
         include:
-          # C++17
-          - build: 6
-            build-type: Release
-            build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 17
-            python-version: 3.7
-          # Static, no SSE
-          # C++11, Python 3.7
-          - build: 5
-            build-type: Release
-            build-shared: 'ON'
-            build-docs: 'ON'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 3.7
-          # Debug
           - build: 4
-            build-type: Debug
+            arch-type: "x86_64;arm64"
+            build-type: Release
             build-shared: 'ON'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 3.7
-          # C++14
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 20
+            python-version: '3.12'
           - build: 3
-            build-type: Release
-            build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 14
-            python-version: 3.7
-          # Static, no SSE
-          - build: 2
-            build-type: Release
+            arch-type: "x86_64"
+            build-type: Debug
             build-shared: 'OFF'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'OFF'
-            cxx-standard: 11
-            python-version: 3.7
-          # Python 2.7
-          - build: 1
-            build-type: Release
-            build-shared: 'ON'
-            # Doc build requires Python 3
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 2.7
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            python-version: '3.10'
     steps:
       - name: Setup Python
-        uses: actions/setup-python@v1
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
         with:
           python-version: ${{ matrix.python-version }}
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - 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: Create build directories
         run: |
           mkdir _install
@@ -363,12 +391,14 @@ jobs:
                 -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
                 -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
                 -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
-                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
-                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
-                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_USE_SIMD=${{ matrix.use-simd }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
                 -DOCIO_INSTALL_EXT_PACKAGES=ALL \
                 -DOCIO_WARNING_AS_ERROR=ON \
-                -DPython_EXECUTABLE=$(which python)
+                -DPython_EXECUTABLE=$(which python) \
+                -DCMAKE_OSX_ARCHITECTURES="${{ matrix.arch-type }}"
         working-directory: _build
       - name: Build
         run: |
@@ -376,99 +406,267 @@ 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 with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --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.8.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 Arm
+  # ---------------------------------------------------------------------------
+
+  macos-arm:
+    name: 'macOS 14 arm
+      <AppleClang
+        arch=${{ matrix.arch-type }},
+        config=${{ matrix.build-type }},
+        shared=${{ matrix.build-shared }},
+        simd=${{ matrix.use-simd }},
+        cxx=${{ matrix.cxx-standard }},
+        python=${{ matrix.python-version }},
+        docs=${{ matrix.build-docs }},
+        oiio=${{ matrix.use-oiio}}>'
+
+    runs-on: macos-14
+    strategy:
+      matrix:
+        build: [1, 2]
+        include:
+          - build: 1
+            arch-type: "arm64"
+            test-rosetta: "OFF"
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'ON'
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'ON'
+            cxx-standard: 20
+            python-version: '3.13'
+          - build: 2
+            arch-type: "x86_64;arm64"
+            test-rosetta: "ON"
+            build-type: Release
+            build-shared: 'ON'
+            build-docs: 'OFF'
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            python-version: '3.12'
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - 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: Install OIIO
+        if: matrix.use-oiio == 'ON'
+        run: time share/ci/scripts/macos/install_oiio.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          OIIO_CMAKE_ARGS=()
+          if [ "${{ matrix.use-oiio }}" = "ON" ]; then
+            OIIO_CMAKE_ARGS+=(-DOpenImageIO_ROOT=$(brew --prefix openimageio))
+          fi
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_USE_SIMD=${{ matrix.use-simd }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python) \
+                -DCMAKE_OSX_ARCHITECTURES="${{ matrix.arch-type }}" \
+                "${OIIO_CMAKE_ARGS[@]}"
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --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 -C ${{ matrix.build-type }}
+        working-directory: _build
+      - name: Test Rosetta
+        if: matrix.test-rosetta == 'ON'
+        run: |
+          /usr/bin/arch -x86_64 /bin/zsh -c "ctest -V -C ${{ matrix.build-type }}"
+        working-directory: _build
+      - name: Test CMake Consumer with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --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.8.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
   # ---------------------------------------------------------------------------
-  # TODO: Install pythonXX_d.lib (or work around it being needed) to support 
-  #       Debug build testing with Python bindings and docs enabled.
 
   windows:
-    name: 'Windows 2019 
-      <MSVC 16.4 
+    name: 'Windows 2022 
+      <MSVC 
        config=${{ matrix.build-type }}, 
        shared=${{ matrix.build-shared }}, 
-       sse=${{ matrix.use-sse }}, 
+       simd=${{ matrix.use-simd }}, 
        cxx=${{ matrix.cxx-standard }}, 
        python=${{ matrix.python-version }}, 
-       docs=${{ matrix.build-docs }}>'
-    runs-on: windows-2019
+       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-2022
     strategy:
       matrix:
-        build: [1, 2, 3, 4, 5, 6]
+        build: [1, 2, 3, 4]
         include:
-          # C++17
-          - build: 6
+          - build: 4
             build-type: Release
             build-shared: 'ON'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 17
-            python-version: 3.7
-          # C++11, Python 3.7
-          - build: 5
+            build-openfx: 'ON'
+            use-simd: 'OFF'
+            # NB: OIIO is not currently set up for Windows CI builds
+            use-oiio: 'OFF'
+            cxx-standard: 20
+            python-version: '3.13'
+          - build: 3
             build-type: Release
-            build-shared: 'ON'
+            build-shared: 'OFF'
             build-docs: 'ON'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 3.7
-          # Debug
-          - build: 4
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            python-version: '3.12'
+          - build: 2
             build-type: Debug
             build-shared: 'ON'
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 3.7
-          # C++14
-          - build: 3
-            build-type: Release
-            build-shared: 'ON'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 14
-            python-version: 3.7
-          # Static, no SSE
-          - build: 2
-            build-type: Release
-            build-shared: 'OFF'
-            build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'OFF'
-            cxx-standard: 11
-            python-version: 3.7
-          # Python 2.7
+            build-openfx: 'OFF'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            python-version: '3.11'
+          # C++14, OpenEXR, OpenFX
           - build: 1
             build-type: Release
             build-shared: 'ON'
-            # Doc build requires Python 3
             build-docs: 'OFF'
-            build-gpu: 'OFF'
-            use-headless: 'OFF'
-            use-sse: 'ON'
-            cxx-standard: 11
-            python-version: 2.7
+            build-openfx: 'ON'
+            use-simd: 'ON'
+            use-oiio: 'OFF'
+            cxx-standard: 17
+            python-version: '3.10'
     steps:
       - name: Setup Python
-        uses: actions/setup-python@v1
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
         with:
           python-version: ${{ matrix.python-version }}
       - name: Checkout
-        uses: actions/checkout@v2
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install docs env
+        run: |
+          DOXYGEN_PATH=$GITHUB_WORKSPACE/doxygen
+          share/ci/scripts/windows/install_docs_env.sh "$DOXYGEN_PATH"
+          echo "$DOXYGEN_PATH" >> $GITHUB_PATH
+        shell: bash
+        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
@@ -483,9 +681,10 @@ jobs:
                 -DCMAKE_GENERATOR_PLATFORM=x64 \
                 -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
                 -DOCIO_BUILD_DOCS=${{ matrix.build-docs }} \
-                -DOCIO_BUILD_GPU_TESTS=${{ matrix.build-gpu }} \
-                -DOCIO_USE_HEADLESS=${{ matrix.use-headless }} \
-                -DOCIO_USE_SSE=${{ matrix.use-sse }} \
+                -DOCIO_BUILD_OPENFX=${{ matrix.build-openfx }} \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_USE_SIMD=${{ matrix.use-simd }} \
+                -DOCIO_USE_OIIO_FOR_APPS=${{ matrix.use-oiio }} \
                 -DOCIO_INSTALL_EXT_PACKAGES=ALL \
                 -DOCIO_WARNING_AS_ERROR=ON \
                 -DPython_EXECUTABLE=$(which python)
@@ -496,9 +695,52 @@ 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 with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --config ${{ matrix.build-type }}
+          export PATH=../../../_install/bin:$PATH
+          ./${{ 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.8.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/dependencies_latest.yml

@@ -0,0 +1,375 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: Dependencies latest
+
+on:
+  pull_request:
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+    paths:
+      - .github/workflows/dependencies_latest.yml
+  schedule:
+    # Nightly build
+    - cron: "0 0 * * *"
+
+jobs:
+  # ---------------------------------------------------------------------------
+  # Linux latest ext packages
+  # ---------------------------------------------------------------------------
+
+  linux_latest:
+    name: 'Linux VFX CY${{ matrix.vfx-cy }} latest 
+      <${{ matrix.compiler-desc }} 
+       cxx=${{ matrix.cxx-standard }}, 
+       docs=${{ matrix.build-docs }}>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    # GH-hosted VM. The build runs in ASWF 'container' defined below.
+    runs-on: ubuntu-latest
+    container:
+      # DockerHub: https://hub.docker.com/u/aswf
+      # Source: https://github.com/AcademySoftwareFoundation/aswf-docker
+      image: aswf/ci-base:${{ matrix.vfx-cy }}
+    strategy:
+      fail-fast: false
+      matrix:
+        build: [1, 2, 3, 4]
+        include:
+          # -------------------------------------------------------------------
+          # GCC
+          # -------------------------------------------------------------------
+          - build: 1
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 20
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2025
+          - build: 2
+            build-docs: 'OFF'
+            build-openfx: 'OFF'
+            cxx-standard: 17
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            vfx-cy: 2024
+          # -------------------------------------------------------------------
+          # Clang
+          # -------------------------------------------------------------------
+          - build: 3
+            build-docs: 'OFF'
+            build-openfx: 'OFF'
+            cxx-standard: 20
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            vfx-cy: 2025
+          - build: 4
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 17
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            vfx-cy: 2024
+    env:
+      CXX: ${{ matrix.cxx-compiler }}
+      CC: ${{ matrix.cc-compiler }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install docs env
+        run: share/ci/scripts/linux/dnf/install_docs_env.sh
+        if: matrix.build-docs == 'ON'
+      - name: Install tests env
+        run: share/ci/scripts/linux/dnf/install_tests_env.sh
+      - name: Setup ext environment
+        run: |
+          EXT_PATH=/usr/local
+          echo "EXT_PATH=$EXT_PATH" >> $GITHUB_ENV
+      - 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.7.2 $EXT_PATH
+          share/ci/scripts/multi/install_lcms2.sh 2.17 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.8.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.4 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 3.0.1 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.3.1 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 4.0.10 $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_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)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config Release \
+                -- -j$(nproc)
+        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
+          # ASWF ci-base 2025.2 is missing lib64 (2025.1 have it)
+          export LD_LIBRARY_PATH=/usr/local/lib64:$LD_LIBRARY_PATH
+          ./consumer
+        working-directory: _build/tests/cmake-consumer-dist
+
+  # ---------------------------------------------------------------------------
+  # MacOS latest ext packages
+  # ---------------------------------------------------------------------------
+
+  macos-latest:
+    name: 'macOS latest 
+      <AppleClang 
+       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:
+          - build: 1
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 20
+            python-version: '3.14'
+          - build: 2
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 17
+            python-version: '3.10'
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - 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=$GITHUB_WORKSPACE/_ext
+          echo "EXT_PATH=$EXT_PATH" >> $GITHUB_ENV
+          echo "CMAKE_PREFIX_PATH=$EXT_PATH" >> $GITHUB_ENV
+      - 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.7.2 $EXT_PATH
+          share/ci/scripts/multi/install_lcms2.sh 2.17 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.8.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.4 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 3.0.1 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.3.1 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 4.0.10 $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_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)
+        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
+          export DYLD_LIBRARY_PATH=$EXT_PATH/lib:$DYLD_LIBRARY_PATH
+          ./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:
+          - build: 1
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 20
+            python-version: '3.14'
+            use-oiio: 'ON'
+          - build: 2
+            build-docs: 'ON'
+            build-openfx: 'ON'
+            cxx-standard: 17
+            python-version: '3.10'
+            use-oiio: 'OFF'
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install docs env
+        run: |
+          DOXYGEN_PATH=$GITHUB_WORKSPACE/doxygen
+          share/ci/scripts/windows/install_docs_env.sh "$DOXYGEN_PATH"
+          echo "$DOXYGEN_PATH" >> $GITHUB_PATH
+        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 directx-headers:x64-windows
+        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.17 $EXT_PATH
+          share/ci/scripts/multi/install_yaml-cpp.sh 0.8.0 $EXT_PATH
+          share/ci/scripts/multi/install_pystring.sh 1.1.4 $EXT_PATH
+          share/ci/scripts/multi/install_pybind11.sh 3.0.1 $EXT_PATH
+          share/ci/scripts/multi/install_expat.sh 2.7.2 $EXT_PATH
+          share/ci/scripts/multi/install_zlib.sh 1.3.1 $EXT_PATH
+          share/ci/scripts/multi/install_minizip-ng.sh 4.0.10 $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_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
+        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

.github/workflows/deploy_site.yml

@@ -0,0 +1,85 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: Deploy OCIO Homepage
+
+on:
+  # Runs on pushes targeting the default branch
+  push:
+    branches:
+      - main
+    paths:
+      - 'docs/site/**'
+
+  # Allows you to run this workflow manually from the Actions tab
+  workflow_dispatch:
+
+# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
+permissions:
+  contents: read
+  pages: write
+  id-token: write
+
+# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
+# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
+concurrency:
+  group: "pages"
+  cancel-in-progress: false
+
+# Default to bash
+defaults:
+  run:
+    shell: bash
+
+jobs:
+  # Build job
+  build:
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    runs-on: ubuntu-latest
+    env:
+      HUGO_VERSION: 0.128.0
+    steps:
+      - name: Install Hugo CLI
+        run: |
+          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
+          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
+      - name: Install Dart Sass
+        run: sudo snap install dart-sass
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+        with:
+          submodules: recursive
+      - name: Setup Pages
+        id: pages
+        uses: actions/configure-pages@45bfe0192ca1faeb007ade9deae92b16b8254a0d  # 6.0.0
+      - name: Install Node.js dependencies
+        run: "[[ -f package-lock.json || -f npm-shrinkwrap.json ]] && npm ci || true"
+      - name: Build with Hugo
+        env:
+          HUGO_CACHEDIR: ${{ runner.temp }}/hugo_cache
+          HUGO_ENVIRONMENT: production
+        run: |
+          cd docs/site/homepage
+          hugo -D \
+            --minify \
+            --baseURL "${{ steps.pages.outputs.base_url }}/" \
+            --themesDir ../..
+      - name: Upload artifact
+        uses: actions/upload-pages-artifact@fc324d3547104276b827a68afc52ff2a11cc49c9  # 5.0.0
+        with:
+          path: docs/site/homepage/public
+
+  # Deployment job
+  deploy:
+    environment:
+      name: github-pages
+      url: ${{ steps.deployment.outputs.page_url }}
+    runs-on: ubuntu-latest
+    needs: build
+    steps:
+      - name: Deploy to GitHub Pages
+        id: deployment
+        uses: actions/deploy-pages@cd2ce8fcbc39b97be8ca5fce6e763baed58fa128  # 5.0.0

.github/workflows/gpu_workflow.yml

@@ -33,13 +33,14 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Configure AWS Credentials
-        uses: aws-actions/configure-aws-credentials@v1
+        uses: aws-actions/configure-aws-credentials@v2
         with:
           aws-access-key-id: ${{ secrets.CODEBUILD_ID }}
           aws-secret-access-key: ${{ secrets.CODEBUILD_SECRET }}
           aws-region: us-west-2
       - name: Run CodeBuild
-        uses: aws-actions/aws-codebuild-run-project@v1.0.0
+        uses: aws-actions/aws-codebuild-run-build@v1
         with:
           project-name: OpenColorIO
           buildspec-override: buildspec.yml
+          image-override: aswf/ci-ocio:2025

.github/workflows/platform_latest.yml

@@ -0,0 +1,396 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+# GitHub Actions workflow file
+# https://help.github.com/en/actions/reference/workflow-syntax-for-github-actions
+
+name: Platform latest
+
+on:
+  pull_request:
+    branches-ignore:
+      - RB-0.*
+      - RB-1.*
+      - gh-pages
+    tags-ignore:
+      - v0.*
+      - v1.*
+    paths:
+      - .github/workflows/platform_latest.yml
+  schedule:
+    # Nightly build
+    - cron: "0 0 * * *"
+
+jobs:
+  # ---------------------------------------------------------------------------
+  # Linux latest ext packages
+  # ---------------------------------------------------------------------------
+
+  linux_latest:
+    name: 'Linux Ubuntu latest 
+      <${{ matrix.compiler-desc }} 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       cxx=${{ matrix.cxx-standard }}>'
+    # Don't run on OCIO forks
+    if: github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    runs-on: ubuntu-latest
+    strategy:
+      matrix:
+        build: [1, 2, 3, 4]
+        include:
+          # -------------------------------------------------------------------
+          # GCC
+          # -------------------------------------------------------------------
+          - build: 1
+            build-python: ON
+            build-type: Release
+            build-shared: ON
+            cxx-standard: 23
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            enable-sanitizer: OFF
+          - build: 2
+            build-python: OFF
+            build-type: Debug
+            build-shared: ON
+            cxx-standard: 23
+            cxx-compiler: g++
+            cc-compiler: gcc
+            compiler-desc: GCC
+            enable-sanitizer: ON
+          # -------------------------------------------------------------------
+          # Clang
+          # -------------------------------------------------------------------
+          - build: 3
+            build-python: ON
+            build-type: Release
+            build-shared: ON
+            cxx-standard: 23
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            enable-sanitizer: OFF
+          - build: 4
+            build-python: OFF
+            build-type: Debug
+            build-shared: ON
+            cxx-standard: 23
+            cxx-compiler: clang++
+            cc-compiler: clang
+            compiler-desc: Clang
+            enable-sanitizer: ON
+    env:
+      CXX: ${{ matrix.cxx-compiler }}
+      CC: ${{ matrix.cc-compiler }}
+    steps:
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install tests env
+        run: share/ci/scripts/linux/dnf/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=OFF \
+                -DOCIO_BUILD_OPENFX=OFF \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_BUILD_PYTHON=${{ matrix.build-python}} \
+                -DOCIO_USE_SIMD=ON \
+                -DOCIO_USE_OIIO_FOR_APPS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DOCIO_ENABLE_SANITIZER=${{ matrix.enable-sanitizer }} \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --target install \
+                --config ${{ matrix.build-type }} \
+                -v \
+                -- -j$(nproc)
+          echo "ocio_build_path=$(pwd)" >> $GITHUB_ENV
+        working-directory: _build
+      - name: Test
+        run: ctest -V -C ${{ matrix.build-type }}
+        working-directory: _build
+      - name: Test CMake Consumer with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DOCIO_ENABLE_SANITIZER=${{ matrix.enable-sanitizer }}
+          cmake --build . \
+                --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.8.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 latest ext packages
+  # ---------------------------------------------------------------------------
+
+  macos-latest:
+    name: 'macOS latest 
+      <AppleClang 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       cxx=${{ matrix.cxx-standard }}, 
+       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:
+          - build: 1
+            build-python: ON
+            build-type: Release
+            build-shared: ON
+            cxx-standard: 23
+            enable-sanitizer: OFF
+            python-version: '3.14'
+          - build: 2
+            build-python: OFF
+            build-type: Debug
+            build-shared: ON
+            cxx-standard: 23
+            enable-sanitizer: ON
+            python-version: '3.10'
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install tests env
+        run: share/ci/scripts/macos/install_tests_env.sh
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=OFF \
+                -DOCIO_BUILD_OPENFX=OFF \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_BUILD_PYTHON=${{ matrix.build-python}} \
+                -DOCIO_USE_SIMD=ON \
+                -DOCIO_USE_OIIO_FOR_APPS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DOCIO_ENABLE_SANITIZER=${{ matrix.enable-sanitizer }} \
+                -DPython_EXECUTABLE=$(which python)
+        working-directory: _build
+      - name: Build
+        run: |
+          cmake --build . \
+                --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 -C ${{ matrix.build-type }}
+        working-directory: _build
+      - name: Test CMake Consumer with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --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.8.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 latest ext packages
+  # ---------------------------------------------------------------------------
+
+  windows-latest:
+    name: 'Windows latest 
+      <MSVC 
+       config=${{ matrix.build-type }}, 
+       shared=${{ matrix.build-shared }}, 
+       cxx=${{ matrix.cxx-standard }}, 
+       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:
+          - build: 1
+            build-python: ON
+            build-type: Release
+            build-shared: ON
+            cxx-standard: 20
+            python-version: '3.14'
+          - build: 2
+            build-python: ON
+            build-type: Debug
+            build-shared: ON
+            cxx-standard: 20
+            python-version: '3.10'
+    steps:
+      - name: Setup Python
+        uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        with:
+          python-version: ${{ matrix.python-version }}
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+      - name: Install tests env
+        run: share/ci/scripts/windows/install_tests_env.sh
+        shell: bash
+      - name: Create build directories
+        run: |
+          mkdir _install
+          mkdir _build
+        shell: bash
+      - name: Configure
+        run: |
+          cmake ../. \
+                -DCMAKE_INSTALL_PREFIX=../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }} \
+                -DCMAKE_CXX_STANDARD=${{ matrix.cxx-standard }} \
+                -DCMAKE_GENERATOR_PLATFORM=x64 \
+                -DBUILD_SHARED_LIBS=${{ matrix.build-shared }} \
+                -DOCIO_BUILD_DOCS=OFF \
+                -DOCIO_BUILD_OPENFX=OFF \
+                -DOCIO_BUILD_GPU_TESTS=OFF \
+                -DOCIO_BUILD_PYTHON=${{ matrix.build-python}} \
+                -DOCIO_USE_SIMD=ON \
+                -DOCIO_USE_OIIO_FOR_APPS=OFF \
+                -DOCIO_INSTALL_EXT_PACKAGES=ALL \
+                -DOCIO_WARNING_AS_ERROR=ON \
+                -DPython_EXECUTABLE=$(which python)
+        shell: bash
+        working-directory: _build
+      - name: Build
+        run: |
+          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 -C ${{ matrix.build-type }}
+        shell: bash
+        working-directory: _build
+      - name: Test CMake Consumer with shared OCIO
+        if: matrix.build-shared == 'ON'
+        run: |
+          cmake . \
+                -DCMAKE_PREFIX_PATH=../../../_install \
+                -DCMAKE_BUILD_TYPE=${{ matrix.build-type }}
+          cmake --build . \
+                --config ${{ matrix.build-type }}
+          export PATH=../../../_install/bin:$PATH
+          ./${{ 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.8.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/release-sign.yml

@@ -0,0 +1,67 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+
+#
+# Releases are signed via https://github.com/sigstore/sigstore-python.
+# See https://docs.sigstore.dev for information about sigstore.
+#
+# This action creates a .tar.gz of the complete OpenColorIO source tree at
+# the given release tag, signs it via sigstore, and uploads the
+# .tar.gz and the associated .tar.gz.sigstore credential bundle.
+#
+# To verify a downloaded release at a given tag:
+#
+#   % pip install sigstore
+#   % sigstore verify github --cert-identity https://github.com/AcademySoftwareFoundation/OpenColorIO/.github/workflows/release-sign.yml@refs/tags/<tag> OpenColorIO-<tag>.tar.gz
+#
+
+name: Sign Release
+
+on:
+  release:
+    types: [published]
+
+permissions:
+  contents: read
+
+jobs:
+  release:
+    name: Sign & upload release artifacts
+    runs-on: ubuntu-latest
+
+    env:
+      TAG: ${{ github.ref_name }}
+    permissions:
+      contents: write
+      id-token: write
+      repository-projects: write
+
+    steps:
+
+      - name: Set Prefix
+        # The tag name begins with a 'v', e.g. "v2.4.0", but the prefix
+        # should omit the 'v', so the tarball "OpenColorIO-2.4.0.tar.gz"
+        # extracts files into "OpenColorIO-2.4.0/...". This matches
+        # the GitHub release page autogenerated artifact conventions.
+        run: |
+          echo OCIO_PREFIX=OpenColorIO-${TAG//v}/ >> $GITHUB_ENV
+          echo OCIO_TARBALL=OpenColorIO-${TAG//v}.tar.gz >> $GITHUB_ENV
+        shell: bash
+
+      - name: Checkout
+        uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - name: Create archive
+        run: git archive --format=tar.gz -o ${OCIO_TARBALL} --prefix ${OCIO_PREFIX} ${TAG}
+
+      - name: Sign archive with Sigstore
+        uses: sigstore/gh-action-sigstore-python@04cffa1d795717b140764e8b640de88853c92acc # v3.3.0
+        with:
+          inputs: ${{ env.OCIO_TARBALL }}
+          upload-signing-artifacts: false
+          release-signing-artifacts: false
+
+      - name: Upload release archive
+        env:
+          GH_TOKEN: ${{ github.token }}
+        run: gh release upload ${TAG} ${OCIO_TARBALL} ${OCIO_TARBALL}.sigstore.json

.github/workflows/wheel_workflow.yml

@@ -0,0 +1,390 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+#
+
+name: Wheel
+
+on:
+  push:
+    # 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.*
+      - gh-pages
+    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
+  # is OK. macOS and Windows jobs need to be locked to specific virtual
+  # environment versions to mitigate issues from OS updates, and will require
+  # maintenance as OS versions are retired.
+  #
+  # Due to documentation build failing on manylinux2010 (maybe too old doxygen
+  # version), we build on manylinux2014 image, this requires pip >= 19.3.
+
+  # ---------------------------------------------------------------------------
+  # 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@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - name: Build SDist
+        run: pipx run build --sdist
+
+      - name: Check metadata
+        run: pipx run twine check dist/*
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-sdist
+          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 64 bits manylinux_2_28
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 64 bits manylinux_2_28
+            manylinux: manylinux_2_28
+            python: cp310-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.11 64 bits manylinux_2_28
+            manylinux: manylinux_2_28
+            python: cp311-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.12 64 bits manylinux_2_28
+            manylinux: manylinux_2_28
+            python: cp312-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.13 64 bits manylinux_2_28
+            manylinux: manylinux_2_28
+            python: cp313-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.14 64 bits manylinux_2_28
+            manylinux: manylinux_2_28
+            python: cp314-manylinux_x86_64
+            arch: x86_64
+          # -------------------------------------------------------------------
+          # CPython 64 bits manylinux2014
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp310-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.11 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp311-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.12 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp312-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.13 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp313-manylinux_x86_64
+            arch: x86_64
+          - build: CPython 3.14 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp314-manylinux_x86_64
+            arch: x86_64
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        name: Install Python
+        with:
+          python-version: '3.11'
+
+      - name: Build wheels
+        uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
+        env:
+          CIBW_BUILD: ${{ matrix.python }}
+          CIBW_ARCHS: ${{ matrix.arch }}
+          CIBW_MANYLINUX_X86_64_IMAGE: ${{ matrix.manylinux }}
+          CIBW_BEFORE_BUILD: "pip install sphinx-press-theme"
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-wheels-${{ matrix.python }}-${{ matrix.manylinux }}
+          path: ./wheelhouse/*.whl
+
+  # ---------------------------------------------------------------------------
+  # Linux ARM Wheels
+  # ---------------------------------------------------------------------------
+
+  linux-arm:
+    name: Build wheels on Linux ARM
+    runs-on: ubuntu-24.04-arm
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    strategy:
+      matrix:
+        include:
+          # -------------------------------------------------------------------
+          # CPython ARM 64 bits manylinux2014
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 ARM 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp310-manylinux_aarch64
+            arch: aarch64
+          - build: CPython 3.11 ARM 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp311-manylinux_aarch64
+            arch: aarch64
+          - build: CPython 3.12 ARM 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp312-manylinux_aarch64
+            arch: aarch64
+          - build: CPython 3.13 ARM 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp313-manylinux_aarch64
+            arch: aarch64
+          - build: CPython 3.14 ARM 64 bits manylinux2014
+            manylinux: manylinux2014
+            python: cp314-manylinux_aarch64
+            arch: aarch64
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        name: Install Python
+        with:
+          python-version: '3.11'
+
+      - name: Build wheels
+        uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
+        env:
+          CIBW_BUILD: ${{ matrix.python }}
+          CIBW_ARCHS: ${{ matrix.arch }}
+          CIBW_MANYLINUX_AARCH64_IMAGE: ${{ matrix.manylinux }}
+          CIBW_BEFORE_BUILD: "pip install sphinx-press-theme"
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-wheels-${{ matrix.python }}-${{ matrix.manylinux }}
+          path: ./wheelhouse/*.whl
+
+  # ---------------------------------------------------------------------------
+  # macOS Wheels
+  # ---------------------------------------------------------------------------
+
+  macos:
+    name: Build wheels on macOS
+    runs-on: macos-15-intel
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    strategy:
+      matrix:
+        include:
+          # -------------------------------------------------------------------
+          # CPython 64 bits
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 64 bits
+            python: cp310-macosx_x86_64
+            arch: x86_64
+          - build: CPython 3.11 64 bits
+            python: cp311-macosx_x86_64
+            arch: x86_64
+          - build: CPython 3.12 64 bits
+            python: cp312-macosx_x86_64
+            arch: x86_64
+          - build: CPython 3.13 64 bits
+            python: cp313-macosx_x86_64
+            arch: x86_64
+          - build: CPython 3.14 64 bits
+            python: cp314-macosx_x86_64
+            arch: x86_64
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        name: Install Python
+        with:
+          python-version: '3.11'
+
+      - name: Remove brew OpenEXR/Imath
+        run: |
+          brew uninstall --ignore-dependencies openexr imath || true
+            
+      - name: Build wheels
+        uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
+        env:
+          CIBW_BUILD: ${{ matrix.python }}
+          CIBW_ARCHS: ${{ matrix.arch }}
+          CIBW_BEFORE_BUILD: "pip install sphinx-press-theme"
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-wheels-${{ matrix.python }}
+          path: ./wheelhouse/*.whl
+
+  # ---------------------------------------------------------------------------
+  # macOS ARM Wheels
+  # ---------------------------------------------------------------------------
+
+  macos-arm:
+    name: Build wheels on macOS ARM
+    runs-on: macos-14
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    strategy:
+      matrix:
+        include:
+          # -------------------------------------------------------------------
+          # CPython ARM 64 bits
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 ARM 64 bits
+            python: cp310-macosx_arm64
+            arch: arm64
+          - build: CPython 3.11 ARM 64 bits
+            python: cp311-macosx_arm64
+            arch: arm64
+          - build: CPython 3.12 ARM 64 bits
+            python: cp312-macosx_arm64
+            arch: arm64
+          - build: CPython 3.13 ARM 64 bits
+            python: cp313-macosx_arm64
+            arch: arm64
+          - build: CPython 3.14 ARM 64 bits
+            python: cp314-macosx_arm64
+            arch: arm64
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        name: Install Python
+        with:
+          python-version: '3.11'
+
+      - name: Build wheels
+        uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
+        env:
+          CIBW_BUILD: ${{ matrix.python }}
+          CIBW_ARCHS: ${{ matrix.arch }}
+          CIBW_BEFORE_BUILD: "pip install sphinx-press-theme"
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-wheels-${{ matrix.python }}
+          path: ./wheelhouse/*.whl
+
+  # ---------------------------------------------------------------------------
+  # Windows Wheels
+  # ---------------------------------------------------------------------------
+
+  windows:
+    name: Build wheels on Windows
+    runs-on: windows-2022
+    # Don't run on OCIO forks
+    if: |
+      github.event_name != 'schedule' ||
+      github.repository == 'AcademySoftwareFoundation/OpenColorIO'
+    strategy:
+      matrix:
+        include:
+          # -------------------------------------------------------------------
+          # CPython 64 bits
+          # -------------------------------------------------------------------
+          - build: CPython 3.10 64 bits
+            python: cp310-win_amd64
+            arch: AMD64
+          - build: CPython 3.11 64 bits
+            python: cp311-win_amd64
+            arch: AMD64
+          - build: CPython 3.12 64 bits
+            python: cp312-win_amd64
+            arch: AMD64
+          - build: CPython 3.13 64 bits
+            python: cp313-win_amd64
+            arch: AMD64
+          - build: CPython 3.14 64 bits
+            python: cp314-win_amd64
+            arch: AMD64
+
+    steps:
+      - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
+
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+        name: Install Python
+        with:
+          python-version: '3.11'
+
+      - name: Build wheels
+        uses: pypa/cibuildwheel@ee02a1537ce3071a004a6b08c41e72f0fdc42d9a # v3.4.0
+        env:
+          CIBW_BUILD: ${{ matrix.python }}
+          CIBW_ARCHS: ${{ matrix.arch }}
+          CIBW_BEFORE_BUILD: "pip install sphinx-press-theme"
+
+      - uses: actions/upload-artifact@bbbca2ddaa5d8feaa63e36b76fdaad77386f024f # v7.0.0
+        with:
+          name: cibw-wheels-${{ matrix.python }}
+          path: ./wheelhouse/*.whl
+
+  # ---------------------------------------------------------------------------
+  # Upload
+  # ---------------------------------------------------------------------------
+
+  upload_pypi:
+    needs: [sdist, linux, linux-arm, macos, macos-arm, windows]
+    runs-on: ubuntu-latest
+    if: github.event_name == 'push' && startsWith(github.event.ref, 'refs/tags/v')
+    steps:
+      - uses: actions/setup-python@a309ff8b426b58ec0e2a45f0f869d46889d02405 # v6.2.0
+
+      - uses: actions/download-artifact@70fc10c6e5e1ce46ad2ea6f2b72d43f7d47b13c3 # v8.0.0
+        with:
+          pattern: cibw-*
+          path: dist
+          merge-multiple: true
+
+      - uses: pypa/gh-action-pypi-publish@ed0c53931b1dc9bd32cbe73a98c7f6766f8a527e # v1.13.0
+        with:
+          user: __token__
+          password: ${{ secrets.PYPI_API_TOKEN }}

.gitignore

@@ -10,4 +10,8 @@ dist*
 mastercopy
 *.pyc
 !*.yml
-.vscode
+.idea/
+.venv/
+.vscode/
+
+src/apps/ocioview/uv.lock

.readthedocs.yml

@@ -0,0 +1,23 @@
+# SPDX-License-Identifier: BSD-3-Clause
+# Copyright Contributors to the OpenColorIO Project.
+
+# Read the Docs configuration file
+# See https://docs.readthedocs.io/en/stable/config-file/v2.html for details
+
+version: 2
+
+build:
+  os: ubuntu-lts-latest
+  tools:
+    python: "3.14"
+
+sphinx:
+  configuration: docs/conf.py
+
+formats:
+  - pdf
+  - htmlzip
+
+python:
+  install:
+    - requirements: docs/requirements.txt

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/gsoc_2021_README.md

@@ -0,0 +1,124 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+# OpenColorIO Google Summer of Code 2021
+
+OpenColorIO (OCIO) is a complete color management solution geared towards
+motion picture production with an emphasis on visual effects and computer 
+animation. OCIO provides a straightforward and consistent user experience
+across all supporting applications while allowing for sophisticated back-end
+configuration options suitable for high-end production usage. OCIO is compatible
+with the Academy Color Encoding Specification (ACES) and is LUT-format agnostic,
+supporting many popular formats.
+
+OpenColorIO version 1.0 was released in 2011, having been in development since
+2003. OCIO v1 represented the culmination of years of production experience
+earned on such films as SpiderMan 2 (2004), Surf’s Up (2007), Cloudy with a
+Chance of Meatballs (2009), Alice in Wonderland (2010), and many more.  
+OpenColorIO v2 has been in development since 2017 and was feature complete as of
+SIGGRAPH 2020. After a stabilization and bug-fixing period, an official 2.0.0 
+release was made in January 2021! 
+
+While OCIO is a color management library (written in C++ with a Python API), 
+its only knowledge of color science comes from its execution of the transforms 
+defined in the OCIO configuration file, written in YAML. These transforms are 
+either defined by the end user in a custom OCIO config or inherited from the 
+publicly available configs.  By specifying your desired config file in the local 
+environment all OCIO compatible applications and software libraries will be able 
+to see your defined color transform “universe”. You can then direct the 
+transformation of image data from one defined OCIO Color Space to another, in 
+addition to the other transforms documented elsewhere - the options are endless!
+
+## About the Academy Software Foundation
+
+The Academy Software Foundation (ASWF) is collaboration between the Linux
+Foundation and the Academy of Motion Picture Arts and Sciences, serving as
+an umbrella organization that is the home to several key open source
+software projects used by the film industry (primarily visual effects and
+animation production). The projects we manage are some of the most
+high-profile and widely used open source projects originating and used in
+film production studios. It's a great opportunity for students to get
+involved with projects that will be used professionally on films!
+
+The mission of the ASWF is to increase the quality and quantity of
+contributions to the content creation industry's open source software base;
+to provide a neutral forum to coordinate cross-project efforts; to provide a
+common build and test infrastructure; and to provide individuals and
+organizations a clear path to participation in advancing our open source
+ecosystem.
+
+In 2020, the ASWF projects OpenEXR, OpenTimelineIO, and OpenCue mentored 
+GSoC students. This year, OpenColorIO is the ASWF project that looks forward 
+to welcoming and mentoring GSoC students.
+
+## Application Instructions for Students
+
+Please review the CONTRIBUTING guidelines thoroughly before applying. OCIO 
+maintains a contributor license agreement (CLA) which must be signed to 
+accept contributions.
+
+**Successfully submitting a Pull Request to the OCIO project is a strict**
+**requirement prior to submitting an application.**
+This is not negotiable. We will not even read applications from students who 
+have not submitted an acceptable PR to the project. It can be a truly minimal 
+change -- for example, fixing a typo in an error message. You will find issues 
+tagged "good first issue" on our GitHub repo, which are ideal candidates for 
+your small trial PR to qualify for application.
+
+## Application template
+
+Please use this application template. Feel free to expand or tell us any other
+relevant details, but this is a good place to start. The applications will be 
+judged by representatives of the OCIO technical steering comittee.
+
+* Student name:
+* School / year / area of study:
+* Relevant courses, materials studied, jobs, programming projects, skills, other 
+open source projects you've contributed to. Go ahead and tell us anything about 
+your background that you think we will find interesting for our projects.
+* Project proposal - please explain in detail and give specifics on acceptance 
+criteria -- how we can measure your success, how we can test your code. Provide 
+a weekly timeline for expected progress.
+* Please tell us which test PR you had merged into the OCIO repo:
+
+## Project information and suggested ideas list
+
+Home page:  https://opencolorio.org/ <br>
+GitHub:     https://github.com/AcademySoftwareFoundation/OpenColorIO <br>
+Skills/knowledge relevant to the project: C++11, CMake, color science
+
+Mentor suggestions: Patrick Hodoul, Doug Walker, Michael Dolan
+
+## Project Ideas:
+
+**Add OCIO support to FFmpeg or another FOSS project**
+An important effort for OCIO is expanding the libraries and applications where
+OCIO is implemented. Users have specifically called out FFmpeg as a library and
+command-line tool where they would like to see OCIO support, but any other FOSS 
+project leveraged by digital artists or production pipelines could be considered. 
+This could also include upgrading an existing implementation to support the OCIO 
+v2 API and leverage new functionality.
+Special skills: Familiarity with prospective host library or tool, and knowledge 
+of working with image buffers and authoring plugins.
+
+**OpenFX Plugin Development**
+OCIO currently has a number of plug-ins in the GitHub repo for proprietary 
+application interfaces. (And in several cases, these have become out of sync 
+with the actual plug-ins shipped by vendors.) It would be great to have OpenFX 
+plug-ins in the repo. These would have the benefit of bringing OCIO support to 
+a wider range of applications. Furthermore, the existing plug-ins are all based 
+on OCIO v1, the new OpenFX plug-ins would be the perfect place to showcase the 
+new OCIO v2 features.
+Special skills: Access to a host application that supports OpenFX plug-ins and 
+ability to build the basic demo plug-ins in the OpenFX SDK.
+
+**Add support for more ICC profile structures**
+OCIO currently supports basic ICC monitor profiles.  These are the type that 
+are most often set as monitor profiles on Mac and Windows.  But it would be nice 
+for OCIO to be able to read and convert some of the more advanced ICC profile 
+structures such as the A2B* and B2A* tags.  There are some monitor profiles that
+use these tags to implement gamut mapping. OCIO already has operators to support
+the most common usage of these tags, so the project is simply about importing a
+profile into existing OCIO operators. It would not be a goal of this project to 
+import structures that don’t already have an OCIO equivalent, such as 
+4-dimensional tables.

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/2020-11-16.md

@@ -0,0 +1,100 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 16, 2020
+
+Host: Doug Walker
+
+Rotating Secretary: Carol Payne
+
+Attendees:
+  * [x] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [x] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [ ] Michael Dolan (_TSC Chair_) - Epic Games
+  * [x] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [x] Carol Payne (_TSC_) - Netflix
+  * [x] Mark Titchener (_TSC_) - Foundry
+  * [x] Carl Rand (_TSC_) - Weta Digital
+  * [x] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [x] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] J Schulte - ILM
+  * [x] Matthias Scharfenberg - ILM
+  * [x] Larry Gritz - SPI
+  * [x] Aymee Kennett (Yeh) - Netflix
+
+Apologies:
+  Michael Dolan
+
+# **OCIO TSC Meeting Notes**
+
+* Named Color Transforms - Continued discussion
+    - Doug: Patrick, Bernard and I have been discussing the feedback and how to respond. We have made it possible to turn off the NamedTransforms - similar to an environment variable. Config author/ dev would be able to control whether or not the feature is visible to the user. Bernard has pushed that commit to the PR so it should be available for viewing.
+    - Mark: on/off isn't a true solution - we don't want to fracture the community. The opposition was because we felt that NamedTransforms opposed the way we want OCIO to work.
+    - Doug: would be interested to hear alternate proposals.
+    - Mark: the solutions already exist - you just have to utilize your working space as your reference space. 
+    - Doug: Not everyone is going to be solely using the working space of the config. 
+    - Mark: You design your config based on your requirements for your work. Having different in and out colorspaces is not how it's defined to work.
+    - Doug: We can't expect everyone to have a separate config per working space. Even a difference between rendering space vs. compositing space. Thinking ahead to the studio config as well, it would be ideal if this workflow was easier to implement. 
+    - Mark: But ACES is trying to be the single working space - and should be for the future. 
+    - Carl: WETA works in a different compositing colorspace than rendering space, for example.
+    - Matthias: verifying that we're talking about NamedTransforms that are basically a transfer funtion or something similar? So you don't get the matrix transform that you would get by using the colorspace which goes through the reference space as well? It sounds like a "trapdoor" in the color management system.
+    - Kevin: I didn't see it quite that way. Instead of performing a 2-sided transformation, it's a 1 sided.
+    - Matthias: but isn't that not how OCIO is designed? That you need to go through the reference? This becomes like a "transfer function toolbox" for debugging, design, etc. Could be handy but don't see how it ties into the OCIO ecosystem itself. 
+    - Kevin: Are we talking about something that a DCC needs access to? Or just a toolbox of options. 
+    - Doug: So we wanted to clarify this by not calling it a colorspace - it's a NamedTransform. The ability to define a transform rather than a colorspace. 
+    - Mark: will you see these in say, the list of options to load a texture in an application?
+    - Kevin: Are we just missing some UI/UX design features? Do we need an OCIOTransform op? Would that accomplish the same thing?
+    - Matthias: the concern is that this really offers a trapdoor - an exit from the color managed worflow - what happens when you don't know where you're coming from or where you're going? 
+    - Mark: Still don't understand who the end user is here - seems to be config authors, but config authors already know how to do this correctly.
+    - Doug: we have received feedback that this feature is a requirement. From multiple users / DCC authors. Not everyone knows how to write a config
+    - J: but if we think to the future, and if we can help users move forward to a correct color management workflows, that a lot of these requests would be moot?
+    - Doug: a lot of users don't understand/want anything more than a 1d linear/log workflow - but still need to be able to connect into a color managed world.
+    - Mark: I don't think you can have it both ways.
+    - J: Is the concept of what we're trying to get out of this enabling workflows that go against the "correct" OCIO usage? Does this matter - or are we just providing ways to work to DCCs to use it as they will. 
+    - Carol: Is there a middle ground? We want people to graduate to color management, and if this is a feature that's been requested, wouldn't we rather enable them to move forward into OCIO?
+    - Mei: what transforms are we talking about that couldn't be expressed via an OCIOFileTransform node in Nuke?
+    - J: Worried about introducing this potential for breakage in already complicated pipelines and worflows. 
+    - Doug: tools already have this, what's the opposition to having it in OCIO?
+    - J: We try to operate solely in fully color managed workflows, and introducing this throws a wrench in those workflows that requires additional support and tracking and awareness. Should OCIO be setting the standard and authority of good practices, or is it solely middleware at this point?
+    - Doug: It's a complete color management solution. I feel that if it's going to be complete, it can't only be state of the art, as practiced by the best. We need to make it applicable and achievable to all. There's an expectation that workflows that have existed still exist and there is a broad user base we need to support. We need to be realistic.
+    - Carol: there's a huge group of people who have been working the way they are for years, who might not benefit at all from changing their workflows. 
+    - Mark: the rest of the line in the documentation is - geared toward the motion picture industry for visual effects and animation.
+    - Doug: visual effects is a very big industry - learning the craft through youtube without guidance. A number of these features are indeed broadening the scope of the original OCIO features. I don't think that is uncommon as projects grow, their user base expands, and needs change. Michael and I tried to start this earlier in the year when we updated the mission statement. We feel we've been very clear in our participation in OCIO - which is to suit the needs of a wide range of visual effects and animation artists in every area. We used to have two color management systems - we are trying to have one system to meet all of the needs.
+    - J: Thank you, that's very clarifying.
+    - Doug: I don't know where this leaves us, we have a few more things to discuss.
+    - J: would love to think about this and regroup.
+    
+* RC1 or beta1 tag:
+  - Doug: we are fine with beta1 instead of rc1.
+  - Mark: Good with that.
+
+* CUDA implementation followup.
+    - Doug: We talked about this last week, but missed the intent of Larry's original question - so he's here this week to help us understand his ask for OSL and other renderers.
+    - Larry: Traditionally OCIO functionality has been in 2 directions - using interactive graphics APIs to color correct a display. Makes sense for this to be OpenGL. But there's a 2nd interface callable from c++, which we use in OSL which do arbitrary transforms in shaders that we need at the time, as long as it's in the config. Trick here is renderers that take advantage of that are switching to CUDA based implementations - want to figure out how to continue to access this functionality in the new CUDA world? Or is this not something these libraries will continue to be able to use OCIO for? It's not uncomplicated - there has to be a directly accesible implementation for CUDA. 
+    - Mark: So added functionality to the API to get a CUDA callable alternative would this solve the problem? 
+    - Larry: CPU based c++ app launching CUDA kernels. Can the CPU app ask for the correct CUDA version to pass for the shader - think this would be fine. Just want something - get a handle to a CUDA callable transform.
+    - Mark: only thing we have now is the GLSL "get me a shader". Another API call where you pass in CUDA instead of whatever, that would work? Either texture source or byte code?
+    - Larry: either is fine.
+    - Mark: Textural source would be much easier. 
+    - Doug: Issue with the GPU is how to get the texture onto the GPU.
+    - Patrick: Yeah it's a big blob of data - the texture that you have to get onto the GPU. The structure is there to be able to generate the CUDA code. There are two APIs - one that's openGL oriented, the other that just takes what it needs to do.
+    - Larry: CUDA has similar texture lookup to what you find in OpenGL.
+    - Patrick: Dynamic properties are another functionality to consider.
+    - Doug: Yes, how would you do uniforms?
+    - Larry: Not sure, will find out - but not critical right now.
+    - Mark: Imagine it's there, values you can tweak on your shaders.
+    - Larry: There are assumptions it makes - numbers you can't change without regenerating the shader. But it's not the primary concern right now.
+    - Mark: should be doable - just need someone to do it. There's not a lot to change, it's just annoying - go through every transform to add the CUDA implementation.
+    - Larry: good news is CUDA is basically C++ with decorators. 
+    - Patrick: Another thing we have are helper functions - still C++ but soemthing to consider. It's a function in the shader. 
+    - Mark: so the hooks in the shader where you're expecting user input?
+    - Patrick: No, at the intitial generation. A shader might use another method to call to perform a function - it's a subfunction.
+    - Mark: Ah, so it's like a standard library of things you can use in your GLSL.
+    - Patrick. Yes, so we're not repeating a bunch of code. 
+    - Doug: to summarize, the current API would support CUDA, but it would be a fair amount of work to implement - we have an issue open for it now, looking for volunteers.
+    - Doug: thanks everyone, there's a configs meeting tomorrow, make sure you check the times! 
+    
+

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

@@ -0,0 +1,153 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 23, 2020
+
+Host: Michael Dolan
+
+Rotating Secretary: Doug Walker
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Deke Kincaid - Digital Domain
+
+Apologies:
+  Mark Boorer
+
+# **OCIO TSC Meeting Notes**
+
+* ASWF Survey:
+    - Michael: Our part of the ASWF survey includes a question "Are there any
+      areas of color management that OCIO is NOT helping you with?".  Is there a
+      way to make this multiple choice to fit with the rest of the survey?
+    - Carol: I would remove if it needs to be multiple choice.  Don't want to
+      seed responses.  Michael, Doug, Kevin: agree.  
+    - Kevin: Also don't want to imply we are thinking about adding something
+      that we actually are not.
+    - Michael: Will try to keep it as an optional write-in.
+
+* Documentation Update:
+    - Michael: Hoping to wrap up PR #1197 in a few days.  Adding the part to
+      handle Python that we discussed previously.  Basic issue is that RTD does not
+      allow us to use cmake and build.  Implies Python needs to be pre-generated and
+      "frozen" into the repo.  Also implies Doxygen needs to be run via Sphinx rather
+      than cmake.
+    - Michael: Not happy with how complicated the solution is but until RTD
+      supports cmake, will need some kind of solution like this.  The process of
+      generating and updating the documentation will itself need careful
+      documentation.
+    - Doug: Thanks for working on this Michael!
+
+* Review of Current and Upcoming PRs:
+    - Doug: We've pushed several PRs in the past week: #1208, #1214, #1215. 
+      These are all either minor clean-ups or bug fixes.  The most important is #1215
+      since it fixes a bug reading v1 configs that use "interpolation=unknown" in a
+      FileTransform.  We view this as a critical bug fix and would like to merge it
+      before placing the beta1 tag.  Does anyone object to us going ahead and merging
+      this one now?
+    - Michael, Mark, Carol, Kevin: Yes, merge #1215 immediately.  (No one objected.)
+    - Doug: We will go ahead and merge it and then place the "beta1" tag
+      discussed at the previous TSC meeting.
+    - Doug: We have two more PRs that will land this week.  First is related to
+      Issue #1155.  In that issue I proposed cleaining up the CDLTransform API.  We
+      have done that and moved the parsing and serialization code out of CDLTransform
+      and put it in the FileFormat modules, to be more like the other formats.  We did
+      not go quite as far as I had proposed in Issue #1155 in that we did not remove
+      all the mentioned functions (although the name of one was changed to clarify
+      what it does).  Also, we moved the write method from the Processor class to the
+      GroupTransform class.
+    - Michael: Why move the write method to the GroupTransform?
+    - Patrick: It allows for more flexibility, don't need to create a Processor
+      in order to write.  No functionality is removed, one may always get a
+      GroupTransform from a Processor.
+    - Doug: Note that this was not in v1, so moving it will not break any
+      existing apps.
+    - Michael: Is there a case for also leaving it on Processor so that it's
+      more discoverable?
+    - Patrick: Metadata may be lost when a Processor is built, also some
+      spurious items may be added (Allocation, etc.).  Having it on the GroupTransform
+      is a better design, allows one to write exactly what is intended.  It's more
+      deterministic.
+    - Kevin: If the worry is about making it discoverable, that could be done
+      via documentation rather than leaving it in the Processor API.
+    - Michael: Yes, and it could also be confusing to have it in both places
+      giving somewhat different results.
+    - Doug: The other PR landing this week is a move of the AppHelpers modules
+      into the core.  This is following up on the TSC's request to move it from a
+      separate library into the core.  The goal is to avoid needing two OCIO libraries
+      (for Linux distros, etc.).
+    - Michael: What about the OIIO and OGL helpers?  Patrick: Those remain as
+      separate.  Really don't want to bring those third-party dependencies into the
+      core library.  AppHelpers adds no third-party dependencies.
+
+* OpenEXR 3.0
+    - Michael: Their v3 is on the way.  Pulling from top of tree may break
+      downstreams.  We pull from most recent tag, so not impacted yet but will be
+      soon.  Currently we do some special stuff in our cmake since the only thing we
+      need is half.h.  This could probably be improved based on their refactoring.
+    - Patrick: This dependency is not in our public API, but agree it will
+      require some updates.  Could be a good first issue for someone.
+    - Doug: Michael, would you create an issue on GitHub so it has more
+      visibility?  Michael: Yes, will do.
+
+* Open Tasks Needed for OCIO v2
+    - Michael: Wanted to discuss some of the remaining items.  Mei, where do we
+      stand with the Python unit tests?
+    - Mei: The Transforms is the area that needs the most work.  Would also like
+      to centralize more.
+    - Michael: If you need help, reach out.  Don't want you to feel like this is
+      all on your shoulders.  Mei: Will do.
+    - Michael: On the documentation front, where are there holes?  Is it all
+      documented in the GitHub Project?
+    - Carol: We don't have Issues created for everything.  There are still some
+      items in my head, and Doug's too probably.  We have been trying to onboard new
+      contributors.  Have received some great assistance from Zach.  We have some
+      tasks that would benefit from having a sample v2 config, but not blocked by that
+      yet.
+    - Doug: Another important task is making OpenFX plug-ins for v2.  We have a
+      student who has volunteered to help with this but he is having trouble getting
+      the example plug-ins from the OpenFX SDK loaded.  He's tried Natron but the
+      plug-ins are not loading.  Not sure if it is a problem with what he's built or
+      in Natron.  Once he gets the plug-ins loading in a host, Patrick and I could
+      help him with the OCIO part but is there anyone that could help us get him over
+      this first hurdle of getting some example plug-ins to load?  The student has
+      posted in #dev on Slack asking for help.
+    - Michael: Mark, OpenFX was originally a Foundry initiative, right?  Is
+      there someone on your team that could help?
+    - Mark: I will check.  Also, once the plug-ins are ready to test, we could
+      help with that too.
+
+* Items for next TSC meeting agenda:
+    - Doug: The Named Transform will soon be a blocker for us.  Need to get to a
+      resolution on that.  Also, would like to know if our reply to ILM's memo
+      addressed their other concerns.
+    - Michael: I have put Named Transform on the agenda for next meeting. 
+      Carol: Could set a goal to resolve it.
+    - Patrick: The end of the year is rapidly approaching and in the roadmap
+      presentations we showed releasing a v2 library at year end.  Need to make rapid
+      progress.
+    - Michael: We may need to settle for just having the release candidate done
+      by then.  Would like to have more feedback before the final release.
+    - Doug: Agree.  I'd also like to have a discussion around the categories feature. 
+      The code was added a long time ago but we still need to have the discussion
+      around what are the recommended strings.  (These are the strings that allow apps
+      to filter the list of color spaces based on the specific menus.)
+    - Deke: Sounds good, we're excited about that.
+    - Carol: Yes, I'll also put some thoughts on GitHub prior to the next live
+      discussion.
+    - Doug: I'll create an Issue for the category naming.
+
+* Documentation Meeting Schedule
+    - The group decided to cancel the documentation working group meeting this
+      Friday due to the Thanksgiving holiday in the US.

ASWF/meetings/tsc/2020-11-30.md

@@ -0,0 +1,213 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 30, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [x] Bernard Lefebvre - Autodesk
+  * [x] Deke Kincaid - Digital Domain
+  * [x] Joseph Goldstone - ARRI
+  * [x] Matthias Scharfenberg - Industrial Light & Magic
+  * [x] Nick Shaw - Antler Post
+  * [x] J Schulte - Industrial Light & Magic
+  * [x] Alessandra Tomassi - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to recap goals of OCIO v2 and relation to OCIO mission:
+    - Some recent discussions about controversial topics. Thought it would be 
+      useful to recap what we're doing with v2 from AD point of view - clarify 
+      motivation for some of these new features. As written in origin proposal, 
+      goal is to be able to use OCIO across apps more broadly, and to rely on 
+      it entirely as our color management system (CMS). We would like to 
+      standardize on OCIO across apps. Need OCIO to do a variety of color 
+      management tasks. When thinking about how OCIO is used, there's color 
+      space based transformations (OCIOColorSpaceNode, etc.) and other 
+      operations which are more ignorant of color spaces (OCIOFileTransform, 
+      etc.). In ideal world, only the former would exist, since it requires the 
+      least knowledge from user. Reality is though there is need for people to 
+      apply independent transforms, in apps where it's expected the user knows 
+      a reasonable amount about color management (e.g. Flame - users know how 
+      to load a LUT and apply it). Don't want two separate libs for applying 
+      LUTs. For things like dynamic properties and NamedTransform, it's more 
+      the latter case, using the same CMS to apply the independent transforms. 
+      We aren't trying to change the existing config way of working - very 
+      supportive of that workflow. Don't want to enable people with ability to 
+      edit individual transforms in a config to edit look of a config.
+    - Mark B: Caught up with Doug offline to discuss. The way Doug describes it 
+      now, it makes sense. Objections were based more around how these features 
+      would map to configs. Some of the objectional features don't map to 
+      configs, so we're ok with that.
+    - Deke: Really useful for tools like Nuke, where you have to jump over a 
+      wall to implement things differently based on what workflow you are 
+      doing. Would be nice if Foundry could have one code path instead of two 
+      separate ways.
+    - Mark T: Agree. We would like that too and hope to standardize on OCIO in 
+      Nuke and across products.
+    - Doug: Would be helpful to write whitepaper to try to establish best 
+      practices. Sometimes we have people who are asked to implement color 
+      management but are not color management experts, and implement without 
+      being aware of best practices. Think having something that documents this 
+      more extensively than current docs would be helpful. Hope TSC can focus 
+      on this once v2 is out. Help people understand color management and 
+      implement it correctly.
+    - Deke: Any support for deep merging of multiple configs?
+    - Doug: There is a way to convert between multiple configs in OCIO v2. USD 
+      for example could reference one scene config, and import an asset using 
+      another config. We added a processor command which can convert between a 
+      known color space present in both configs. Looks for these two roles that 
+      have been added which act as an interchange. Also added a version where 
+      you can provide your own interchange (common color space used across 
+      studio).
+    - Deke: No way to merge two configs though? To support vendors having 
+      configs which inherit from each other.
+    - Doug: No.
+    - Mark B: Any use case where you're trying todo that?
+    - Deke: If vendors could have their own internal config and add it on top 
+      of yours. You could add it above or below and merge them together and 
+      have access to those transforms. Also for MaterialX, USD, etc. Point to 
+      someone else's config to get transforms without cleaning up and 
+      ingesting.
+    - Mark B: Need to use the solution Doug describes since you don't know if 
+      the two config are compatible.
+    - Deke: Could also be a studio vs show level config.
+    - Mark B: We have same thing, facility, show, shot. We merge them through 
+      custom sanitizing tools.
+    - Deke: Same. Inherit from ACES config and build on it.
+    - Mark B: Might put out another doc to clarify what was discussed with Doug 
+      offline. Might be more to discuss but inconsequential compared to other 
+      stuff.
+  
+* Named Color Transforms - Continued discussion:
+    - Michael: Is this topic still up for debate? Or was it resolved through 
+      offline discussion?
+    - Mark B: Didn't cover this topic. Still up for discussion.
+    - Doug: We implemented ability to make NamedTransforms inactive. Commit 
+      pushed to existing PR that does this. Zach proposed alternative way to 
+      make them inactive. I replied that we are open to implementing that 
+      instead of or along with what was done. His idea was to use env var to 
+      disable named transforms all together, instead of treating them as 
+      inactive color spaces where they are disabled one at a time.
+    - Michael: Could be good to have a config attribute in that case too since 
+      the env could be cleared accidentally when shelling out to a process. 
+      That would prevent it in a persistent way. Like how active displays and 
+      views are handled currently, with env var or config property.
+    - Doug: The individual inactive flags are persistent, so can be used in 
+      that way.
+    - Michael: Does that answer ILM concerns?
+    - Mark B: Our concern is feature itself, not the implementation. And how 
+      it's exposed inside of tools. Does processor take NamedTransform 
+      constructor?
+    - Doug: Would call getProcessor which takes generic transform, and pass 
+      in NamedTransform. Same approach as using FileTransform.
+    - Mark B: Based on conversation earlier, don't have strong objection. If 
+      intent to enable DCC to expose individual transforms where they won't get 
+      confused with other transforms.
+    - J: Yes, and this is progress on previous discussion. With beta going out 
+      and implementation being considered, need to get standardized view on 
+      implementation.
+    - Mark B: In terms of enabling/disabling, like active displays/active 
+      users, sounds reasonable.
+    - Carol: As aside, another useful case Matthias and I were discussing. This 
+      would be the perfect vehicle for the ACES gamut compression transform. 
+      Would be nice to be able to do that separately, in ACES config. Fits 
+      nicely.
+    - Mark B: One point we discussed. Two very separate use cases for OCIO. One 
+      we're trying to defend is config author creating black box, being 
+      represented properly. Second use case with graph and a skilled artists 
+      making decisions with toolbox of consistent math. In terms of first 
+      users, don't see much use for NamedTransforms. Can see benefit for second 
+      group of people though.
+    - Michael: Use of NamedTransforms could be covered in Doug's proposed 
+      whitepaper too.
+    - Nick: Would that be a separate node in Nuke?
+    - Mark B: Think so
+    - Mark T: Yes, think that would be the case.
+    - Michael: Wanted to propose we form a UX working group to discuss these 
+      topics and forming standards for OCIO v2 implementation in DCCs. We could
+      transition from the doc working group to that. If anyone is interested in
+      helping lead that, please reach out.
+    - Others: Agree. 
+    - Deke: ACES has own UI rules, could collaborate between projects.
+    - J: Don't think OCIO UX being involved with ACES is good fit, since there 
+      are workflows that don't involve ACES.
+    - Doug: As config working group moves forward a lot of the same questions 
+      are going to come up. A lot of questions from initial config discussion 
+      was on things like naming and interface.
+    - **TODO**: Michael will help organize a UX working group. 
+
+* Categories discussion (Issue #1222):
+    - Doug: At last TSC meeting talked about this. Created issue #1222. Trying 
+      to collect a number of new features and discussions on how color spaces 
+      appear in application menus. Motivation is the new categories attribute. 
+      Hadn't gotten to the list of proposed categories, or sorted out how we 
+      expect applications to use this. Want to make sure we're all on the same 
+      page in case tweaks are needed to get this working as expected. Proposed 
+      some tweaks in the issue. One of the things that came up in v2 working 
+      group meetings was request from people that they want to specify, from 
+      studio perspective, env vars to filter color spaces for artist 
+      groups, like compositors, lighting artists, modelers, etc. Different from 
+      app developer point of view with different menus for tasks. Proposed both 
+      use cases and something which could work on both ends. Want feedback on 
+      whether I've captured this correctly. See issue content:
+      https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1222
+    - Kevin: Have existing concept of roles. Fixed set of assumed roles plus 
+      extended set. How would we choose to filter those with this. Nuke now 
+      shows roles in menus, and would be good to filter those as well.
+    - Doug: App helpers code has setting to show roles or not.
+    - Kevin: Want users to find the roles they want to find. Artists trained 
+      to use particular roles for certain tasks.
+    - Deke: Mari has roles listed too, and has its own roles.
+    - Mark B: Intention for roles was just to make sure basic color spaces were 
+      there. Roles have been misused since then. Don't think roles should 
+      appear at all in menus.
+    - Deke: Like roles there, but need to filter them.
+    - Mark B: Category system is powerful. If DCCs have prefs as to what 
+      category might be associated with a dropdown (i.e. texture in Maya). DCCs 
+      can assign categories to UI elements and only show those. Don't think 
+      this should be OCIO-wide env var. Should be per-DCC.
+    - Doug: Yes, would be fixed for certain menu. Specific documented category 
+      so config authors know what an app uses.
+    - Mark B: Could end up with overlapping categories. If up to user they 
+      could define that themselves.
+    - Doug: Proposing standard categories to encourage consistency, but doesn't 
+      need to be limited to this. The key part is there is a set pre-defined to 
+      an application. So Maya would say what categories it's using for different 
+      menus. There is another set that is end-user defined and would expect to 
+      find those at runtime.
+    - Mark B: What if you have both types of categories?
+    - Doug: Then would use the intersection. So for texture, you could have 
+      file-io intersected with an end-user environment variable (basic-3d etc.)
+    - Mark B: If either is empty, defaults to other?
+    - Doug: Yes.
+    - Mark B: Would make these categories configured by the config author. DCC 
+      authors would allow users to customize the category names, or fallback on 
+      the default list.
+    - Carol: Something to fall back on is good. Most people just use defaults. 
+      Don't have a problem with proposed options.
+    - Mark: Defaults from DCC (as documented) is fine. Want to avoid problem 
+      with roles where categories are inconsistent between apps. If all left to 
+      user can be very explicit.
+    - Michael: More topics for discussion at UX group.
+    - Mark T: Agree. Highlights importance of best practice to show how things 
+      are intended to be used. Developer may not find the right thing and use 
+      something outside standard use. UX stuff really important.
+    - Mark B: App helpers has concrete implementation for reference.
+    - **TODO**: All: Read through issue #1222 and provide feedback there or in 
+      next TSC meeting.
+
+* Items for next TSC meeting agenda:
+    - Finish discussion on standard categories.

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

@@ -0,0 +1,141 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 7, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Nick Shaw - Antler Post
+
+Apologies:
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to summarize in-progress work:
+    - Doug: With regard to categories, looking at issue (#1222). Idea to 
+      improve app helpers code to implement improved category mechanism.
+    - Other work in progress:
+        - Color space alias mechanism. Seemed to be good consensus on this 
+          being helpful.
+        - Improve list of builtin transforms in support of ACES.
+        - Various bug fixes.
+    - Michael: Any feedback so far on OCIO v2 testing?
+    - Doug: Not as much as we would like - a risk factor on release. Wondering
+      what we can do to improve that situation. Draft PR for OFX plugin arrived 
+      yesterday. Still ways from being done, but could get us more testing upon 
+      completion. Chicken and egg situation.
+    - Michael: Any studios here tested it out?
+    - Kevin: Not that I'm aware of [at Framestore]. Have used commandline stuff.
+    - Michael: Might be worth starting ocio-dev thread to invite people to beta 
+      test. Could mention what needs feedback and provide more details.
+    - **TODO**: Michael and Doug will draft ocio-dev thread to reiterate beta 
+      testing. 
+    - Mark T: We have started testing it, but off for break. In new year will 
+      hope to have something. End of January-ish.
+    - Kevin: Talked to Nigel about work done there so far. Suggested demoing 
+      the work for the TSC.
+    - Michael: We're happy to set up a Zoom meeting if that's helpful, to give
+      feedback. Will help once we have UX working group up and running.
+
+* Frozen doc generation platform differences and difference threshold:
+    - Michael: See PR #1197 for explanation, but faced challenge with frozen 
+      docs differing between platforms, due to subtle naming differences from
+      the C++ side. Implemented fuzzy matching to pass/fail CI based on 
+      difference threshold, which isn't ideal, but will work for now. Should 
+      probably limit freezing to Linux builds only since that's what RTD uses.
+      Any objections to the current RST freezing workflow?
+    - Doug: May impact developers. Have to build docs and run python 3 to pass 
+      CI. 
+    - Michael: True. Alternative solution was to store CI build artifacts in an 
+      S3 bucket and download those during RTD build, but current ASWF S3 bucket 
+      is not public and requires secrets to access. Would need another setup.
+    - Mark B: Good first step to get in the door. Good for now. Not such a bad 
+      thing.
+    - Doug: Huge step forward in process. Have looked at review. Think we 
+      should merge it, and do follow ups.
+    - **TODO**: Michael to talk to Lf and/or RTD about plans for future 
+      CMake/compiler support. Would remove need for these workarounds.
+
+* Categories, continued discussion (Issue #1222)
+    - Doug: To summarize, we're proposing making the 3 changes listed in 
+      summary of issue #1222.
+    - Doug: Documenting these initial categories would not be part of the 
+      initial PR. any questions?
+    - Kevin: The names we give these things have to be really bulletproof about 
+      what they mean, or leave it up to the apps to tell us what to look for. 
+      Would make is straightforward to link apps and config. May need default 
+      set of terms, but need to be careful to say what they mean.
+    - Doug: If we don't companies will come up with their own and could make 
+      the list much longer if everyone has different name for same thing. Will 
+      be differences between apps, so not clear cut.
+    - Carol: Can we reach out to some subsets of apps, Foundry, AD, and others 
+      (Black Magic) and ask what their preferences would be?
+    - Doug: Proposed these from an app point of view. These three seemed like 
+      they would be common menus. Proposed starting point. 
+    - Carol: Would be worthwhile to show to Foundry and others.
+    - Mark T: I can show this and discuss internally.
+    - Mark B: We could agree on the categories, but the list is large and some 
+      are not represented in this meeting. Felt that empowering users to always 
+      set it is the only answer. Would allow all needed workflows; up to config 
+      author if they want to tag them as disciplines or tag based on 
+      functionality.
+    - Carol: What would we do for ACES studio config?
+    - Mark B: That will come up in that working group discussion. Should expect 
+      the default case to be a user telling a DCC what category is assigned to 
+      what drop down menu.
+    - Doug: That would be the ultimate in flexibility. Does impose more work on 
+      app vendors - that customization, and not everyone may do it.
+    - Kevin: If we had that and same default terms. Would need map between apps 
+      and what they need to know about. Also other cases where rules were used 
+      in past. Becomes open ended at some point. Sometimes we have SG task or 
+      process step that tells the app why the user is loading it: tracking, 
+      lighting, etc. In that case, doing it in one config would be difficult.
+    - Mark: If you want artist based workflow, tag those, but still up to app 
+      to associate the tags with menus. Need app preferences of which category 
+      to assign to specific menus.
+    - Kevin: That's almost a different table of mappings.
+    - Mark: Or a different config per DCC, which we would likely not have.
+    - Doug: In terms of proposed code, app helpers implements possibility to 
+      pass in two categories and do a join/intersection. Initial PR doesn't 
+      need to sort out question of recommended categories or not, or if users 
+      should be able to customize menus. Talked about UX working group, that 
+      would be a topic to wrestle with.
+    - Mark: Current proposed work seems fine and mergeable then. Would be great 
+      if working group result would be PR into app helpers. Already a place to 
+      point to for DCC authors to buy into. Almost outside our scope, 
+      encouraging apps to save these options. 
+    - Michael: We have one volunteer to lead the UX group, but would like to 
+      have a second to balance the work. If anyone is interested place reach 
+      out.
+    - Carol: Definitely want to be part of it.
+    - Kevin: In response to Zach's comment in issue: Not sure I'm enamoured by 
+      the suggested do-not-use approach. If going to have a feature it should 
+      be explicit.
+    - Doug: Will make PR and have concrete stuff to review. For purposes of 
+      docs, what we can take these menu and artist categories and include them 
+      in docs as examples. Make it clear it's open to what users want.
+    - Carol: Agree.
+    - Doug: Can use OFX plugin as prototype. Can have field in plugin for 
+      categories to use, and users can type different things. Can anyone 
+      provide some help on this OFX work? It's an important step for 
+      testing.
+    - Mark T: Spoke to some at Foundry. Many involved in OFX no longer there, 
+      but some could help with specific questions. Reached out to contributor 
+      after previous TSC meeting about build issues and got that fixed. Tried 
+      examples on my end and worked fine. Just had bad flag. Definitely 
+      potential for help from engineers at Foundry.
+    - Michael: I can help with guidance too. I'll have a look at the PR.

ASWF/meetings/tsc/2020-12-14.md

@@ -0,0 +1,148 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 14, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [ ] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Alessandra Tomassi - Industrial Light & Magic
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Joseph Goldstone - ARRI
+
+Apologies:
+  * Mark Boorer
+  * Mark Titchener
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to summarize in-progress work:
+    - Doug: Have PR in progress about moving app helpers to core, and for 
+      category updates described in issue #1222.
+        - Current PR for small BuiltinTransform changes. Much larger PR in 
+          progress - adding remaining ACES transforms.
+        - CDLTransform cleanup PR is ready to be merged.
+        - Maya beta going out with preliminary OCIO v2 integration. Not on 
+          by default - needs environment variable. Very preliminary, missing 
+          stuff, but felt it was important to get it out as soon as possible. 
+          We're worried it's not being tested enough. Good way to get 
+          additional coverage.
+        - Carol: We'll do some testing at Netflix with it.
+        - Thomas: Any word on Nuke?
+        - Michael: Mark Titchener mentioned last week that they are working on 
+          Nuke implementation. Hoping to have something around end of January 
+          or so.
+        - Patrick: Regarding the preliminary Maya integration - it just hints 
+          at what's coming, so keep in mind.
+        - Doug: Will be a post on rendering forum with more details.
+        - Michael: How long did it take to implement, roughly?
+        - Patrick: Took quite a bit of time. We did deep integration of color 
+          management in Maya, so replacement with OCIO v2 is a lot of work. 
+          Depends on integration in your tool; could be straightforward. In 
+          Maya it was deeply integrated, so was not trivial. Nothing to do 
+          with library itself. Even if it's preliminary, OCIO v2 is still here. 
+          Can use config and displays, etc. Limitations listed in release 
+          notes.
+        - Doug: Not sure in release notes, but in rendering forum. Will post 
+          issues there. We had the most difficult job since we're transitioning 
+          from SynColor and have to have backwards compatibility. Lot of work 
+          for us, but hoping companies already using OCIO v1 exclusively will 
+          be more straightforward. Some new work to take advantage of new 
+          features, but getting up and running should be less complex.
+        - Patrick: Someone did integration in another tool and had it up and 
+          running in week.
+
+* Enable the new GitHub Discussions feature for OCIO?
+    - Michael: Been some discussion on this in Slack with mixed responses. I 
+      can enable it to play with if we think it's useful.
+    - Thomas: Can mark topics as answered, so could be mini Stack Overflow on 
+      GH. Could be useful. Will try to use it on colour science.
+    - Patrick: How do you compare it to Google groups?
+    - Thomas: Good question. We don't have a lot of good Groups traffic, but 
+      think will make sense to put it in GH.
+    - Michael: Would be nice to get ocio-dev/ocio-user out there like that. 
+      Lots of channels currently, but lists is less accessible.
+    - Thomas: Not much traffic there now.
+    - Carol: Would be interested in that too. Could test as method for 
+      replacing it.
+    - Michael: Could enable it just to test. To push buttons, etc. Could set it 
+      up on OpenColorIO-Configs-ACES repo if we want to test it somewhere less 
+      active.
+    - Patrick: Have to be careful. We have changed a lot. Need to not lose 
+      existing community. Something to keep in mind.
+    - Thomas: Good point. We have same concern. Has useful features though, 
+      like turning GH issues into discussion. Can move between issue and 
+      discussion, to keep issue board clean. Much harder on mail list. Could 
+      de-clutter issue tracker.
+    - Michael: A lot of our traffic has moved to Slack, since it's more real 
+      time. Same for ASWF discussion. There was initially concern about Slack,
+      since it is expensive to keep history, but a lot of discussion has moved 
+      there.
+    - Doug: Happened to quite a few mail lists when they added Slack option.
+
+* Remove OIIO dependency from OCIO apps (Issue #1233)
+    - Michael: This topic has been ongoing for a couple years. Propose in #1233 
+      to implement the fix of replace OIIO with OpenEXR and libTiff. Any 
+      objections?
+    - Doug: Could also use DPX vs tiff.
+    - Carol: Prefer tiff.
+    - Thomas: Agree.
+    - Doug: DPX is simple enough that makes it easy to grab. Could be fallback 
+      if libTiff implementation is involved.
+    - Patrick: Do we agree on the direction?
+    - Michael: The main arguments for this solution are that the apps don't 
+      need to be rewritten (or duplicated) in Python, or broken into their own 
+      repo. The cpp apps are currently the main implementation example for app 
+      developers. Python examples are more useful for topic of config 
+      authoring.
+    - Patrick: Should not underestimate app examples. Some use these heavily.
+    - Doug, Patrick, Thomas: Agree with proposal.
+    - Thomas: OCIO/OIIO are a pain right now to build because of that circular 
+      dependency.
+    - Michael: Aloys is also facing issues with this in the development of 
+      production VFX ref platform Docker images for aswf-docker.
+    - Patrick: Should also think about package managers; brew, vcpkg, etc. 
+      vcpkg is broken right now.
+    - Michael: Yes, a discussion on Conan is what brought this topic back up.
+
+* GH Actions macOS runners maintenance:
+    - Michael: Received notice from GitHub that they are doing maintenance on 
+      macOS runners this week, so we may see interruption.
+    - Patrick: Any problems with CentOS runners?
+    - Michael: No, those are run on Ubuntu runners. CentOS is purely in the 
+      Docker container, managed by aswf-docker.
+
+* Next TSC meeting January 4:
+    - Michael: After tomorrow's Config working group meeting, no OCIO meetings
+      until January 4th. All events have been cancelled in that window since 
+      most have holidays.
+
+* Other discussion:
+    - Doug: As mentioned previously, a student is working on high priority OFX 
+      plugins for OCIO, and may need assistance. If anyone has time to help 
+      him, see PR #1231.
+    - Michael: I reached out last week to see if specific help was needed, but 
+      no request as of yet. Can bump issue to get status.
+    - Michael: Also, last week we talked about sending an update to ocio-dev 
+      to invite more testing, but I hadn't noticed that Doug already sent 
+      something like that to announce the beta 2 release.
+    - Doug: May do beta 3 before next TSC meeting. If anyone has time, would 
+      appreciate testing and feedback, to move forward with RC in early 
+      January.
+    - Michael: Are the PRs coming this week the last major changes?
+    - Doug: The last feature, aliases, should land next week. Still some other 
+      PRs finishing up features already in place. Polishing, fixing, etc. 
+      Will have some PRs in early January.

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

@@ -0,0 +1,122 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 4, 2021
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [ ] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+  * [X] Robin Rowe - CinePaint
+
+Apologies:
+  * Carol Payne
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* rawtoaces:
+    - Michael: rawtoaces was accepted as an ASWF incubation project at the 
+      last TAC meeting. Might be some interesting collaboration opportunity 
+      there.
+
+* Doug to summarize in-progress work:
+    - Doug: New PRs two weeks ago, some updated commits last week.
+        - Grading op implementation now complete.
+        - Minor fixes/changes: v1/v2 serialization issue (#1244). 
+          to_reference/from_reference synonyms. Default view transform 
+          specification.
+        - #1241 implements color space alias feature.
+        - Michael: Use case for config name added in PR? Comment seemed to 
+          imply could be used as a color space namespace, and referenced 
+          externally?
+        - Doug: Optional config name, could be useful for:
+            - Alternative to filename for tracking config.
+            - Indicate version. 
+            - Future use as more fully qualified name for a color space. 
+            - Reference for USD, other projects, etc.
+        - Just metadata for now.
+        - **TODO**: Bernard will clarify comment in API that config name has no
+          influence on color space lookups.
+
+* Seeking approval to merge PRs #1220, 1234, 1241 (today), 1244, 1245 
+  (tomorrow):
+    - Doug: Want to get OCIO v2 out there, since we're over the VFX ref 
+      platform release date a bit. Suggest releasing 2.0.0 by mid-January. 
+      Want to get last PRs merged and RC tag to communicate final testing 
+      state.
+    - Michael: Have a Python binding fix for CPUProcessor that should be in 
+      RC release.
+    - Mark: Did apphelpers (#1220) add dependecy to core? OpenGL?
+    - Doug: No, that's in another helpers lib separate from core.
+    - No objections to proposed merges.
+
+* Version handling discussion:
+    - Doug: Once config v2 version starts getting used, will be need to bump 
+      version for future changes. Want to discuss how to handle versioning. If 
+      config syntax needs tweaking, what to do. Currently will throw for v3 
+      and warn for v2.1.
+    - Michael: Currently just single int right?
+    - Doug: Yes, and added ability to have minor version in OCIO v2.
+    - Kevin: What additions would we make to need a version warning? Fixed 
+      transform?
+    - Doug: Yes, and some things would throw. A new style string for a 
+      transform for example.
+    - Mark: Don't think there's need to be future compatible. Would prefer to 
+      fail fast vs. silently ignoring incompatibility. OCIO and config version 
+      numbers can diverge.
+    - Patrick: For debugging would be useful to keep major version in sync 
+      between lib and config.
+    - Kevin: Does the minor version increment sequentially, or is it tied to 
+      lib release? Under what circumstances is a warning valid. Or is it just 
+      valid or not valid, ok or throw.
+    - Doug: If an older version config is not using new features, it could 
+      try to load.
+    - Michael: Failing fast would avoid subtle differences, like 
+      ExponentTransform negative handling changing for example.
+    - Kevin: Or changed defaults.
+    - Michael: Could have metadata in config with exact lib version if needed.
+    - Patrick: Need to be careful with optional metadata. Could get out of date 
+      and be confusing.
+    - Mark: If having minor version helps keep it organized, have no problem 
+      with it.
+    - All agree to allow minor version, and fail on unknown/unsupported version 
+      rather than raising a warning.
+    - **TODO**: Bernard will push updated to #1244, which is related.
+
+* Discussion about creating a RB-2.0 release branch:
+    - Doug: After these PRs get merged, will create the branch. Should RC tag 
+      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 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 
+      something in place to warn about it? Extra symbol appears or disappears, 
+      etc.
+    - Mark: OCIO is good at avoiding this since all symbols have version 
+      namespace. Only issue if you don't update the version number.
+    - Patrick: If we are consistent, won't happen. Should be caught in review.
+    - Mark: Difficult to comare symbols to detect change. Would need two builds 
+      or maintained list of symbols.
+    - Patrick: Even changing order could be an issue.
+    - Kevin: What about for Python?
+    - Michael: We are setting __version__ currently.
+    - Mark: It is likely used in setup.py, etc.
+    - Michael: We will eventually setup PyPi, so could be used there too.
+    - Follow up: See PEP 396: https://www.python.org/dev/peps/pep-0396/

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

@@ -0,0 +1,159 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 18, 2021
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [X] Sean Cooper (_TSC ACES TAC Rep_) - ARRI
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [X] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Bernard Lefebvre - Autodesk
+
+Apologies:
+  * Mei Chu
+
+# **OCIO TSC Meeting Notes**
+
+* Doug to summarize in-progress work:
+    - Doug: Number of PRs landing this week. Bug fixes in Python bindings, etc. 
+      No new features. Small but appreciate quick turn around.
+
+* Any volunteers to help get the OpenFX plug-ins compiling (PR #1232)?
+    - Doug: Contributor needs help with compilation and loading in OFX 
+      compliant app. Doesn't need help writing plugins, just initial step of 
+      getting it built.
+    - Michael: Currently is swapping code into a Resolve plugin example I 
+      believe.
+    - Carol: Is there more we can do to help people get up and running with 
+      OCIO? Many new developers are struggling to get up and running. Not sure 
+      what the issue is.
+    - Doug: Valid point. Heard similar feedback from ACES community too. Not 
+      all those trying to build OCIO are necessarily developers.
+    - Sean: Might be lack of familiarity with C++ build env.
+    - Carol: Could link to some CMake help for getting started, etc.
+    - Sean: After release, when we get into other package envs, those 
+      complaints will go away.
+    - Michael: I brought this up in the last CI working group. Pushed for 
+      making one of the goals this year to work on standardized package manager 
+      support across ASWF projects.
+    - Mark T: He had example plugins building. I talked to him about some of 
+      that. Is able to build examples now, but not able to build his plugin.
+    - Michael: We can do zoom to help support if needed.
+
+* VFX Reference Platform 2.0.x -> 2.x:
+    - Michael: I reached out to the platform working group and the TAC about 
+      the change and got good feedback. OpenVDB has always had a variable minor 
+      version, but has to be handled carefully. Stance from VFX ref platform is
+      that a CY version range must be ABI compatible.
+    - Doug: Challenge is we may want to do 2.x release that breaks ABI 
+      compatibility. Lots of things could break it.
+    - Michael: Can do minor version ranges in platform, if we could commit to 
+      certain minor versions being ABI compatible.
+    - Doug: Anyone rememberer when tetrahedral interpolation was added to 
+      OCIO v1? Did that break ABI compatibility?
+    - Kevin: It didn't quite. Was able to put binary from Nuke into Mari and 
+      it worked.
+    - Patrick: Can add enum, but add at end.
+    - Doug: Risk is committing to all 2.x not breaking ABI.
+    - Patrick: Need to say that for next 9 months, no change will break ABI 
+      compatibility. Since v2 is first being used, challenge to say that.
+    - Carol: Have not done enough testing to be confident.
+    - Michael: Semver doesn't explicitly say ABI compatibility, but sort of 
+      implies it in minor version changes being backwards compatible. That 
+      would impact the decision too.
+    - Patrick: We will have to change API.
+    - Carol: Might be 6 months before we see v2 release with Nuke.
+    - Mark T: Yes, taking longer than we hoped. also delay getting into 
+      production once it's in DCCs.
+    - Michael: Suggest we back out changes if we're not confident in adhering 
+      to the rule.
+    - Doug: Will need to be 2.0.1 as bug fix, and then eventually 2.1.
+    - Carol: Can push bigger changes to CY2022.
+    - Mark B: Don't forsee needing to use these new features at facility scale 
+      in 2021. Not a huge deal if VFX ref misses some of those minor features.
+    - Michael: We're currently missing builtin transforms needed for the ACES 
+      config. Would we need to resort to LUTs to get that out?
+    - Doug: Can do like was pasted in Slack a while back, building the output 
+      transforms in the config.
+    - Michael: Any performance cost? Or since builtin transform just builds ops 
+      directly, is it about the same?
+    - Doug: Shouldn't be. Have not tested yet.
+    - Michael: Complicates config build script a bit. ACES 1.3 can wait, but we 
+      will need output transforms.
+    - Kevin: How many releases could we have this year? How many versions on 
+      active support? Committing to support VFX ref platform. Minor versions 
+      could be more to support. Tradeoff of not locking ref platform down.
+    - Mark B: Could add broken endpoints for features we're planning to add. 
+      Then API won't change.
+    - Michael: Good idea. I have seen other libraries do that. Let's continue 
+      this discussion in the config wg meeting tomorrow. I will followup with 
+      platform working group after that.
+
+* Release plan discussion for 2.0.0:
+    - Doug: Would like to do 2.0.0 release next week, Monday or Tuesday. Minor 
+      PRs in this week to merge quickly.
+
+* Issues, Built-in Transform, Documentation, or other “must haves” for 2.0.0:
+    - Doug: If there are things people feel are must haves, want to get them on 
+      table. Bernard working on issues. Not currently working on reported 
+      OpenEXR 2.5 CMake issue. 
+    - **TODO**: Michael will roll back OIIO find module to resolve that 
+      issue for now.
+
+* Ociocheck behavior for missing roles:
+    - Doug: ociocheck looks for known set of roles. If they are missing it 
+      prints error message. Added new roles to OCIO v2, so was going to add 
+      them to OCIO check, but they aren't mandatory. some of the roles it is 
+      currently complaining about don't seem mandatory. Propose changing 
+      message to warning instead of error.
+    - Kevin: Difference in behavior with new roles. They are required in 
+      certain circumstances. Without matte_paint role config will work. Would 
+      like a strict check that validates as an error. Agree on some other roles 
+      being warnings though.
+    - Sean: Core roles could be hard coded in DCCs and know that those exist. 
+      More for DCC/API compatibility. With newer v2.0 features, can question 
+      whether they are necessary.
+
+* Should inactive color spaces be included by parseColorSpaceFromString?
+    - Doug: Inactive spaces won't be in menus. Should we parse inactive color 
+      spaces from strings?
+    - Kevin: I think so. Useful for loading historical color spaces. Like to be 
+      able to load file on disk.
+    - Mark, Sean: Agree. Good to load them still if it's defined.
+
+* Scope of image IO support for app refactor (to remove OpenImageIO dependency):
+    - Michael: I've been building simple image interface to load EXRs for apps. 
+      OpenEXR is a broad interface though, with many types of files. Should we 
+      support them all? Or limit it since the apps only operate on RGBA?
+    - Mark B: Think we can keep the OIIO dependency. If needed can change how 
+      they are built, with apps in another repo, or a separate CMake build.
+    - Kevin: Package managers would prefer library and tools separate.
+    - Mark B: That's what debian and brew do. 
+    - Patrick: Agree not a huge problem, but falls in problem category. Two 
+      types of commandline tools. Helpers and apps like ociodisplay, which are 
+      useful for development. Moving tools for external users outside could be 
+      good. But ocioperf less convinced. ocioperf would be ok only having 
+      OpenEXR format. Tool we really need OIIO for is ociodisplay.
+    - Group agrees to continue discussion next week and in GH issue. Leaning 
+      toward keeping OIIO dependency and implementing one of Mark's 
+      suggestions.
+
+* ASWF 2020 CCLA 2.1 transition:
+    - Sean: What would the timeline by for this change? 6 months?
+    - Michael: I talked to John and it sounds like we can get the new CCLA 
+      signed before we switch and then switch it over once we know there will
+      be no disruption to contributions. Will follow up more on this next week.
+
+* Items for next TSC meeting agenda:
+    - Removing apps from repo or main build.
+    - ASWF 2020 CCLA 2.1 transition plan.

ASWF/meetings/tsc/2021-02-08.md

@@ -0,0 +1,87 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+February 8, 2021
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Mei Chu (_TSC_) - Sony Pictures Imageworks
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - ARRI
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Patrick Hodoul (_TSC_) - Autodesk
+  * [ ] John Mertic - Academy Software Foundation / Linux Foundation
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Mark Titchener (_TSC_) - Foundry
+  * [ ] Carl Rand (_TSC_) - Weta Digital
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Rémi Achard - DNEG
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] J Schulte - Industrial Light & Magic
+
+# **OCIO TSC Meeting Notes**
+
+* Several pending pull requests: some are Python reviews, but most of them are 
+  meeting minute reviews.
+    - Patrick: Few PRs awaiting review. Not C++ changes - meeting minutes, 
+      Python, etc.
+    - Carol: There's a website PR ready for review too. I will take a look at 
+      that.
+    - Michael: Noting some issues reported related to v2, which means it's 
+      being used and tested. I've been testing it and love the new config 
+      features. Being able to build configs without external files is great.
+    - Patrick: Doug and I are investigating the issues. Big thanks to Doug for
+      the config improvements. *clap*
+    - Kevin: Using pre-release of v2 and encountered a bug while baking to 
+      Resolve cube with ociobakelut. Known issue? Asking to bake 3D cube, but 
+      resulted in 1d cube. I will investigate further.
+
+* GSoC/D&I internships:
+    - Carol: Put doc in TSC channel. Two projects - ffmpeg support, and OFX 
+      plugins:
+      https://docs.google.com/document/d/1sa68Cjq0TzSYFg2xhf2w2FFAQ1In7G391iINWKXfDo8/edit?usp=sharing
+    - Carol: Going to ask community for more ideas, and for more mentor 
+      volunteers this week. End of this week needs to go to Larry. Think we're 
+      the only ones submitting to GSoC this year.
+    - Michael: Quick mention that there's a new ASWF working group forming 
+      around topic of Rust bindings for VFX OSS libs. Sounds like a group of 
+      developers interested in working on this for several projects. First need
+      to make C bindings.
+    - Mark B: Talked about OCIO C bindings a while ago. Complex due to use 
+      of shared pointers everywhere.
+    - Patrick: Earlier we discussed the idea of going back and making OCIO a C
+      lib with header only C++ bindings. Too late now, but interesting topic.
+
+* Static builds - cmake export:
+    - Mark B: Problems with static builds when deploying on Windows. Looking at 
+      fixing a number of CMake issues and improving 3rd party lib builds. 
+      Improving debug and release builds too. PR will have a lot of changes, 
+      but only to CMake. Hoping to open PR this week. Also noting some issues 
+      with the way unit tests are linked which could be improved later. Tests 
+      don't use same targets as lib, so must rebuild code.
+    - Patrick: Unit tests need private part of some files, so needed in some 
+      places. Even if CMake is platform agnostic, have to deal with Windows 
+      specific stuff. Often seems slightly broken on Windows platform.
+    - Mark: Big one for me was debug. CMake build type variable doesn't work on 
+      all platforms. Default setup on Windows uses VS solutions, which support 
+      multiple targets. Since on Windows release and debug libs can't be mixed, 
+      current setup can be problematic.
+
+* Locale issue:
+    - Patrick: Working on OCIO v2 integration in Maya. Facing locale issue - 
+      numeric separator handling. We discussed this earlier, but will need to 
+      resume conversation.
+    - Mark B: Parsing LUT files with locale wrong can cause read issues. 
+      Probably want correct locale when reading yaml files, but one consistent 
+      locale when reading LUTs.
+    - Patrick: Previous Turkish locale bug was related to upper to lower case 
+      conversion (PR #984). I agree that numeric parsing should be locked to 
+      decimal points.
+    - Doug: Lib is quite dependent on lowercase conversions. Could argue not 
+      needed, but for backward compatibility might have to keep it.
+
+* Items for next TSC meeting agenda:
+    - Absent next week: Patrick, Michael. Doug will be present and host.

ASWF/meetings/tsc/template.md

@@ -5,12 +5,12 @@ DATE
 
 Host: NAME (Michael Dolan?)
 
-Rotating Secretary: NAME
+Secretary: NAME
 
 Attendees:
   * [ ] Mark Boorer (_TSC_) - Industrial Light & Magic
   * [ ] Mei Chu (_TSC_) - Sony Pictures Imageworks
-  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - DNEG
+  * [ ] Sean Cooper (_TSC ACES TAC Rep_) - ARRI
   * [ ] Michael Dolan (_TSC Chair_) - Epic Games
   * [ ] Patrick Hodoul (_TSC_) - Autodesk
   * [ ] John Mertic - Academy Software Foundation / Linux Foundation
@@ -36,5 +36,3 @@ Apologies:
 
 * Items for next TSC meeting agenda:
     - xxx
-    
-

ASWF/meetings/working_groups/configs/2020-11-17.md

@@ -0,0 +1,176 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+November 17, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Christophe Brejon
+  * [X] Deke Kincaid - Digital Domain
+  * [X] Allie Moon - Industrial Light & Magic
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Zach Lewis - Method
+  * [X] Alex Forsythe - A.M.P.A.S.
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+
+Apologies:
+  * 
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* OCIO output transform implementation:
+    - Doug: Working on PR to do something similar to ACES color space 
+      transforms. Add builtin transforms to facilitate making ACES config, etc. 
+      Involves mapping ACES output transform structure to OCIO structure.
+        - **See slides**: https://docs.google.com/presentation/d/1sLyY8Q4JVkM6TqDHbqq9OWAW0zNcwvJQnh_jCtM4JHU/edit?usp=sharing
+        - Plan is to map ACES 1.0 and 1.1 output transforms into OCIO v2 
+          structure. Reduces code and makes it clear how the ACES transforms 
+          are defined. Moving linearCV to outputCV section of CTL into its own 
+          transform. Transforms which have similar calculations would share 
+          components in OCIO.
+        - Naming can be discussed. Table is just straw-man for group 
+          discussion.
+    - Alex: So primaries don't come into play until clamping happens?
+    - Doug: Yes. Last slide has summary of all view transforms and display 
+      color spaces. display color spaces are very simple - basically matrix and 
+      gamma, or matrix and EOTF. Working on PR for this, but wanted to share 
+      high level thought process.
+    - Mark: What is the PR for?
+    - Doug: To add builtin transforms outlined in the slides. Each view 
+      transform would become a builtin transform. PR only on the OCIO repo 
+      (not configs repo).
+    - Mark: Does this mean we have multiple display referred spaces, and some 
+      outputs attached to each one? Or are they associated with specific 
+      displays?
+    - Doug: In display/view section of config. For example, "Rec. 709" 
+      display/view with "ACES 1.0 SDR-video" view transform, and "Rec. 709" 
+      display color space. Each would have name, view transform, and display 
+      color space. Down in 'view_transform' section of config would have the 
+      view transforms with a transform referencing builtin transform 
+      (see slides).
+    - Mark: Shame that so many view transforms are required, due to gamut 
+      limiting and simming. Not a nice common space for them all to go through, 
+      like OCES for example. Can limits not be done on display end after 
+      transform?
+    - Doug: Could be done that way. Depends what we think of as a display color 
+      space. Would take things from view transforms and move to display color 
+      spaces (limits, etc.). Did it the current way because it's nicer to keep 
+      display color spaces as simple matrix/gamma transform. The limiting and 
+      white poiont simulating parts are more of the view rather than part of 
+      Rec. 709/Rec. 2020, etc. Display color spaces kept as simple pure display 
+      specs.
+    - Mark: Under assumption that with separate view transforms, the graph 
+      would be simpler. But with the complexity, why even need the view 
+      transform? Rather than going direct from scene to display?
+    - Doug: This is more flexible. Allows adding other combinations not in 
+      aces-dev repo. Right now aces-dev doesn't have D60 sim on Rec. 2020 
+      monitor. If someone needs that there's no way to do it. With this, 
+      that could be done easily.
+    - Mark: That would need to be explicitly added to the config right?
+    - Doug: Need to decide what we need to do with ACES config. Could be 
+      faithful mapping of things just in aces-dev repo. And a studio config 
+      with the other parts in the current ACES configs. Would be a choice for 
+      config author to make. The building blocks are there.
+    - J: Know trying to map CTL to OCIO. There are lot of color spaces that use 
+      limited output, but we would never use the limited output. Adds a lot of 
+      extra outputs.
+    - Doug: These are convenance things for people that want to work that way. 
+      Common request that people don't want to put colors out that they can't 
+      preview on their device. Goes against original ACES design intent, which 
+      was to preserve all of the colors. In practice post production doesn't 
+      want to take risk on out of gamut colors and clamp.
+    - Kevin: Artistic intent to clamp in range sometimes, in DI.
+    - J: Yes, we master to an explicit target with no room for 
+      misinterpretation.
+    - Michael: The idea too is that the config generator would be configurable. 
+      Definitely the studio config, but we could also make the reference config
+      configurable to include/exclude certain transforms, like limited outputs.
+    - Doug: Could also make them inactive, and just turn them on, wouldn't need 
+      to re-generate. Either way fine though.
+    - Carol: Get the reasoning for adding ACES version to the naming, but also 
+      don't know how much that's going to be relevant to people. For change 
+      control mechanism?
+    - Kevin: Runs risk of comparing versions and saying one is better than 
+      other.
+    - Mark: Need it to support revisions. Very internal pieces.
+    - Carol: Would version config with transforms usually.
+    - Doug: Name of builtin transform definitely have version in it, but only 
+      seen by config author. Good point that for user facing parts, do we need 
+      the version in there?
+    - Matthias: If the SDR transform hasn't changed and we're on new version, 
+      means that the SDR transform is still same for new version. Consistent 
+      version number that matches latest version of ACES release. If all taken 
+      from same ACES version, use current name, instead of old name.
+    - Mark: Can alias them between versions and have same math if that helps 
+      people. Gives flexibility for building version specific configs.
+    - Kevin: Version number change makes sense when look changes.
+    - Mark: Would be nice if you could make a config based on specific ACES 
+      version, aliasing versions to keep them up to date.
+    - Doug: One concern on ACES side about the transform ID. Thomas pulls name 
+      from the ID, which has persistent name for things like ACES metadata 
+      file. Wouldn't want to bump the ID version unless the code changed, but 
+      not a user facing name. For ID strings, shouldn't bump version, but for 
+      user facing things we need to figure out something thats not confusing.
+    - Mark: Config authors are also users. Currently no mapping from ID strings 
+      to builtin transforms.
+    - Doug: Correct, no direct mapping. Tried to demonstrate that in slides. 
+      Thomas is filtering some of the names. Kept it simpler for presentation, 
+      but agree that builtin transform code should have full transform id string.
+    - Mark: If someone really has to understand history - the way ACES config 
+      code was structured at time. We have generator that sees both worlds. If 
+      you remove half from users, will have no idea.
+    - Doug: That's behind string proposals in slides. But need to decide as 
+      group.
+    - Michael: Could we store that in format metadata? accessible from API?
+    - Doug: Yes, could create description tags in format metadata. More human 
+      readable name and include data from CTL which has a lot of great 
+      information.
+    - Thomas: Being put in description right now.
+    - J: A UI bomb for tools that use it.
+    - Michael: Will it be 1:1 transform -> CTL?
+    - Mark: Hard to keep that link because of the view/display split. Breaks 
+      that relationship. Free then to put whatever comment you like.
+    - Doug: For input and color space conversion side, more 1:1. For output 
+      transform would need table.
+
+* ACES transform spreadsheet:
+    - Another item we previously discussed was creating a spreadsheet with all 
+      ACES transforms, where we could discuss what should be included in the 
+      reference config.
+    - Mark: Can take names from Doug's slides as well?
+    - Kevin: For lib itself, would these transforms introduce new ops? Or black 
+      boxes?
+    - Mark: Black boxes, implemented however we like. Either existing ops or on 
+      the fly 1D or 3D LUT.
+    - Doug: No 3D LUTs in builtin transforms. Goal is to move beyond 3D LUT 
+      limitations. Big limitation in current config. Have ops now (fixed 
+      function, etc.) added for this purpose, which is faithful to CTL itself.
+    - Kevin: Tradeoff between the black box and being able to understand that 
+      it is doing what the CTL is doing.
+    - Doug: Will be very clear, mapping from ops to the CTL. That will be in 
+      the PR, and I can show corresponding YAML to help. Should show this 
+      comparison in meeting at some point.
+    - Mark: Already quite a few implemented in OCIO source, under builtin 
+      transform folder.
+    - Kevin: It's a bit opaque.
+    - Mark: Its a black box by design, not having to think about how to add all 
+      the pieces to get an ACES config. Opting to have the pre-made collection 
+      of transforms.
+    - Doug: convenience for config authors. If someone looks at the internals, 
+      could manually put all the pieces in the config yourself to be more 
+      transparent. Could have a builtin transform and more exposed version 
+      which lists individual ops. Would be long and verbose, but clearer for 
+      those who want to understand each step.
+    - For next week let's get a spreadsheet populated so we can discuss config 
+      contents.
+    - Mark: Can we link empty sapreadsheet in notes?
+    - **Spreadsheet for next discussion**: https://docs.google.com/spreadsheets/d/1SXPt-USy3HlV2G2qAvh9zit6ZCINDOlfKT07yXJdWLg/edit?usp=sharing

ASWF/meetings/working_groups/configs/2020-12-01.md

@@ -0,0 +1,227 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 1, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Christophe Brejon
+  * [X] Mitch Prater - LAIKA
+  * [X] Zach Lewis - Method
+  * [X] Alessandra Tomassi - Industrial Light & Magic
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Nick Shaw - Antler Post
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Review spreadsheet, agree on reference config scope:
+    - Spreadsheet: https://docs.google.com/spreadsheets/d/1SXPt-USy3HlV2G2qAvh9zit6ZCINDOlfKT07yXJdWLg/edit#gid=0
+    - NOTE: Doug updating and adding discussion comments in spreadsheet.
+    - Michael: Thanks to Zach for populating much of the spreadsheet! Of this 
+      list, which transforms are accounted for currently in BuiltinTransform?
+    - Doug: All of ACES CSC complete.
+    - Mark: Do we need 10 and 12 bit ACESproxy?
+    - Doug: Those are annoying. They are implemented differently, with bitshift 
+      scaling.
+    - Mark: Is it possible to correctly use those? Due to not supporting 10 and 
+      12-bit integer inputs.
+    - Doug: you can directly process integer pixels on input and output. Could 
+      produce correct pixel with 10i or 12i values. Sort of like ADX10 or 
+      ADX16. Not claiming they need to be encoded at that depth. They are just 
+      different color spaces. I think they should be in reference config since 
+      they are part of ACES.
+    - Mark: Don't agree with putting it in config just because it's in CTL. 
+      Muddying the waters by having them in here. If not possible to input 10 
+      or 12-bit integer into OCIO, doesn't make sense to support the use case 
+      where bit-shifting is needed.
+    - Thomas: Might be requirement for logo program. For ACES official support.
+    - Michael: Was initial meeting with ACES team to get OCIO in ACES logo 
+      program.
+    - Doug: ACES committee maintains product partners. Vendor would sign up as 
+      partner. There is implied commitment to meet the requirements. Since 
+      there is new CLF and AMF specs, probably will be more forceful about 
+      adhering to the standards. They would like OCIO to be part of the 
+      program.
+    - Mark: Don't think they would deny the logo program based on agreed 
+      exclusions.
+    - Thomas: Should discuss with ACES.
+    - Carol: Agree, don't think they would have a problem excluding something 
+      if it can't be implemented correctly.
+    - Doug: Can be implemented correctly. No technical reason it would not 
+      work.
+    - Mark: Still have to do conversion outside of OCIO.
+    - Kevin: Sample application. What happens in Nuke were color processing is 
+      independent of file processing. Relying on downstream tool to do correct 
+      output. Ambiguous about who should do that.
+    - Doug: OCIO does support 10 and 12-bit pixel formats, and it would produce 
+      ready to use pixels. Not saying we have to support it, but it would work 
+      in OCIO.
+    - Mark: Should you have new color space for that? Or do you assume just by 
+      choosing that you get the right output.
+    - Doug: Complicated because of the scaling implementation. Would be nicer 
+      if you could just select ACESproxy and let something else worry about 
+      the scaling.
+    - **TODO**: Michael will add another option to include columns in 
+      spreadsheet.
+      marking a transform as undecided or in discussion.
+    - Kevin: We can't control implementations even if OCIO does the right 
+      thing. If builtin into reader or writer, ok, but in color space 
+      conversion node, all bets are off.
+    - Thomas: Could come with caveat - documentation on how to use. Don't think 
+      a lot of people will use it.
+    - Mark: Should do ADX ones as well.
+    - Doug: Don't think there's a question about including those. They are 
+      vastly different color spaces. ADX10 not able to capture everything on 
+      current negative films.
+    - Kevin: We never get anything film scanned that's ADX10. Always different 
+      density range than ADX can hold.
+    - Doug: ACES team has identified ADX support as an area that they want to 
+      upgrade.
+    - J: Discussion outside this scope.
+    - Michael: Next discussion id about ALEXA IDTs.
+    - Doug: These aren't all of them. These are the EI 800 ones.
+    - Thomas: Some of these will likely be removed. Need to discuss with 
+      Joseph, Scott, and Alex.
+    - Mark: Strong preference that they aren't included. Just include one.
+    - Kevin: Might need to be two. These are from RAW. Still need wide gamut 
+      as well.
+    - Matthias: Should they be included at all? Haven't seen ALEXA RAW image 
+      at all, except what I've made. Question the usefulness. Will need ALEXA 
+      wide gamut.
+    - J: Agree. Camera native is unlikely to show up in our workflows due to 
+      sophistication of our pipelines. Support removing all of these others 
+      bits of noise.
+    - Carol: Think that's what ARRI will say as well. Moving forward there are 
+      use cases for debugging, but not necessity to have all in a config.
+    - Thomas: Goes back to ACES logo program. Should say to Academy what we're 
+      not supporting and why.
+    - Matthias: In last IDT meeting showed table of what qualified as logo 
+      program. Needed two matrices in camera, or a common gamut where 
+      white-point optimization is already done.
+    - Doug: Making note about sensor RAW ALEXA, which are not commonly 
+      received.
+    - Kevin: If we go for logo program status, do we have to keep following 
+      ACES when new IDTs are added?
+    - Matthias: Don't see way out of it if new camera color space is made.
+    - Michael: What about all the Sony spaces?
+    - Mark: Need some of them.
+    - Carol: Need venice.
+    - Doug: Have CSC transforms for SGamut spaces, which are the newest 
+      implementation.
+    - Zach: Do we need to differentiate between 10 and 12 bit, or include 
+      SLog1?
+    - Doug: Other way to think about this is we could implement all of them, 
+      but set them as inactive in the config. Proves OCIO has implemented the 
+      full library, but wouldn't show up unless enabled.
+    - All: Sounds reasonable.
+    - Doug: Could start with essentials, and talk to ACES about doing more 
+      later.
+    - Matthias: Agree to focus on what's important.
+    - Michael: Could put more builtin transforms in lib and not use them all in 
+      config. The two don't have to align exactly.
+    - Mark: Think we should put minimal collection in OCIO, rely on LUTs for 
+      others.
+    - Doug: Agree. For some would use LUTs.
+    - Mark: For ACES, not sure IDTs should even be included.
+    - Michael: If they can be implemented without builtin transforms (e.g. 
+      LogCameraTransform), should they be?
+    - Doug: Convenient to have builtin transform to promote standardization. 
+      Builtin transform gives confidence - don't need to check matrix 
+      coefficients, etc.
+    - Michael: If we have rule about not including external files in reference 
+      config, need to limit based on that as well.
+    - Doug: LMTs could be named transforms. Blue light fix gets used. Far from 
+      optimal fix, and hopefully migrate to gamut mapping in future.
+    - Carol: Would be great to implement gamut compress.
+    - Thomas: Blue light fix still gets used.
+    - Kevin: Can give warning and deprecate in 1.3.
+    - Mark: Since this is an LMT, and productions are expected to provide own 
+      LMT, could LMT be slotted into this config like in ACES graph?
+    - Kevin: Generally LMT is a cube or something else, rather than CDL.
+    - Mark: Whole look section is not useful in terms of OCIO config. Can put 
+      it in to have correct pathway, as a block in a view.
+    - Carol: Might be space in studio config to write tools to enable that. 
+      Reference config is what it is.
+    - Mark: Yes, and NamedTransform makes sense in same way as gamut compress.
+    - Zach: Any reason this LMT would be part of ACES logo program?
+    - Doug: Might be. After we have our proposed list we should run this by 
+      ACES committee to see what they feel strongly about. 
+    - Thomas: We don't know what all their users are doing and don't have that 
+      feedback.
+    - Michael: Include all ODTs?
+    - J: Another question for ACES team.
+    - Mark: Would be nice to discourage use of D60 sim ODTs.
+    - Doug: Why do people not like D60 sim?
+    - Mark: Just get the right hardware.
+    - Kevin: Or provide LMT that does the same.
+    - Carol: That would be my preference too.
+    - Nick: Could D60 sim be done as LMT?
+    - Kevin: Haven't tried it, but think it could be done.
+    - Thomas: With inversion capabilities of RRT itself.
+    - **TODO**: Michael will share this spreadsheet with ACES for feedback. May 
+      need to reformat it to be more concise. Could also invite them to join 
+      next meeting to discuss.
+    - Kevin: Some controversy about DCDM ODT.
+    - Doug: For people needing to make DCDM, isn't this there best option?
+    - Kevin: Rely on downstream conversion to make tiff files. Rarely done in 
+      same application grading is done in.
+    - Nick: Was ACES central discussion about this recently. Scott said 
+      recommended approach was P3 master and make DCDM from that.
+    - Doug: Recommended in the sense that you get what you saw if grading on 
+      P3, but some people actually setup projectors in X'Y'Z'.
+    - Kevin: And use native projector gamut as well. Just encoding XYZ and 
+      don't go near ACES configs. Is there intersection of someone who does 
+      this and who is using ACES as ACES?
+
+* Talk about what we can do with the incorrectly named ACEStransformID as I 
+  have the feeling we won’t get a resolution from the AMPAS soon:
+    - Thomas: Didn't have a feeling there would be resolution to this issue. 
+      What should we do?
+    - Mark: Do you mean just fix the names that are wrong?
+    - Thomas: Yes.
+    - Mark: Thought we decided not to generate config directly.
+    - Thomas: Are doing that now, and can continue to do so.
+    - Mark: Had concerns about code base being complex. Good for graph layout, 
+      querying, etc. But those things are ancillary to task of generating OCIO 
+      config. When tried to go through it, found it difficult to get started. 
+      Someone with little experience in ACES would have hard time.
+    - Thomas: Made like that to be similar to what was done for previous 
+      version of config. Trivial to update generator and re-generate.
+    - Mark: Getting to point where maintaining exception list is as complex 
+      as explicitly writing down combinations needed for final config.
+    - Thomas: Maybe? Not too much work right now, but fair point.
+    - Carol: Regardless, need to keep pushing on transform IDs getting fixed. 
+      Have opportunity now to get those fixes in 1.3. If we can push on that, 
+      it would help.
+    - Mark: What was their hesitance to merge PR?
+    - Carol: ACES release schedule. They don't do hot fixes. Would need to go 
+      in new release.
+    - Doug: There is a hotfix branch, but doesn't get merged into main branch 
+      until there is a release. Also an issue for ACES metadata file since 
+      those IDs are important there too. Could push from that end too.
+
+* Items for next TSC meeting agenda:
+    - Talk to ACES representative about spreadsheet questions. May be offline 
+      discussion, but will make it public.
+    - Conclude discussion about whether to generate config from graph code 
+      currently in repo, or to have separate library which explicitly builds 
+      config, using the graph lib to validate.
+    - Talk about dev workflow, it is a bit painful atm:
+      https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/9#issuecomment-735352837
+    - Fully fledged display spaces, it was agreed here on Slack, but maybe we 
+      can make it official.
+        - Zach: Specifically, we were talking about having a set of 
+          display-referred CIE_XYZ-D65_to_Display-xxxx BuiltinTransform styles 
+          that we could use to define display color spaces, just like we can 
+          with the current scene-referred xxxxx-to-ACES2065-1 csc styles and 
+          normal color spaces. These would be useful for non-ACES configs as 
+          well, of course.

ASWF/meetings/working_groups/configs/2020-12-15.md

@@ -0,0 +1,184 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+December 15, 2020
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Matthias Scharfenberg - Industrial Light & Magic
+  * [X] Dennis Adams - Sony
+  * [X] Thomas Mansencal - Weta Digital
+  * [X] Christophe Brejon
+  * [X] Zach Lewis - Method
+  * [X] J Schulte - Industrial Light & Magic
+  * [X] Scott Dyer - A.M.P.A.S.
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Continue spreadsheet discussion. Update from ACES:
+    - Michael: Would like to shift this meeting one week forward in the new 
+      year as it currently conflicts with a SMPTE meeting Scott attends. 
+      Any objections?
+    - No objections.
+    - Michael: Scott shared his opinion via email that he thinks we could omit 
+      ACESproxy and DCDM ODTs from the reference config. Can discuss with him 
+      further in new year to make a formal decision.
+    - Carol: No problem with that.
+    - Doug: No objection. Think it's better to track what Academy is doing and 
+      remove if it matches what they are doing. Some we may need to preempt for 
+      practical reasons.
+    - Zach: Is there a way to deprecate?
+    - Michael: Deprecation is supported with inactive color spaces and the 
+      upcoming alias feature (for deprecated names).
+    - Mark: Since they are not currently there, would be better to not 
+      implement.
+    - Doug: Agree.
+    - Mark: Depends what mean by deprecating. Doesn't work any more? Think we 
+      would follow typical OCIO patch notes saying this doesn't exist anymore 
+      and add ociocheck warnings.
+    - Thomas: Deprecate is not removal. Warn in prior release. We're talking 
+      about removal without warning.
+    - Mark: If we were to deprecate a BuiltinTransform, would likely be over 
+      multiple versions.
+
+* Conclude discussion about whether to generate config from graph code 
+  currently in repo, or to have a separate library which explicitly builds 
+  config, using the graph lib to validate:
+    - Michael: Discussing whether we should stay on course with current config 
+      generation code, or use that for validation and have separate more 
+      concise script just for config generation.
+    - Mark: Nothing wrong with usefulness of this code, but as someone involved 
+      with setting up configs, found it hard to approach current setup and to 
+      make changes. It does so many other things than generate the config. Can 
+      get stats, build graph, etc. I previously showed simpler version I 
+      created that just builds config. Discussed mapping needed between CTL and 
+      what we wanted color spaces to be called, and the intermediate color space 
+      that doesn't exist. Sounds like there are more exceptions to the rule 
+      than just following CTL. Think we would be better hand rolling config 
+      code.
+    - Carol: With the display spaces, we're getting to place with mapping where 
+      we have to do it ourselves anyway. Once fixed on ACES side, would manual 
+      intervention lessen?
+    - Mark: Two PRs for URNs that mismatch. Each of our code has chunk to 
+      handle the misnaming. Don't think those are dominant parts of the problem. 
+      Different problem with needing to tease apart ODTs.
+    - Zach: Not going to avoid mapping one way or other.
+    - Mark: Nice aspects to tracking CTL. Comment strings make good docstrings, 
+      but one of the big UX decisions is in regard to how those are formatted 
+      since some are long and can't be displayed easily in apps. Should we lead 
+      the way and lessen those? Feel our intent would be clearer expressed, 
+      even with risk of drifting. Should present ACES workflow in OCIO way.
+    - Michael: Think we could use the current lib to support generating 
+      config in smaller script. Find a middle ground between both approaches.
+    - Thomas: That's what it currently is essentially. CTL discovery code 
+      builds list of transforms, can be used directly, which is similar to what 
+      Mark did. Graph built on top of that, used to fit config generation code. 
+      Config code is agnostic. Just gets input from graph. Nothing says graph 
+      needs to be used. I think there is value in getting that info from CTL. 
+      Can highlight issues which wouldn't be discovered otherwise. What is 
+      being used to maintain current config. As current maintainer, it 
+      is useful. When switched from 1.0 to 1.1, was easy to see what was 
+      missing. Is complex, but can also look at complexity and reduce where 
+      needed and make it easier. Don't have strong opinion. Can go in another 
+      way. Just need to know to not waste time maintaining code that won't be 
+      used.
+    - Carol: Think there's an overarching thing with OCIO way of doing stuff. 
+      A partnership aspect of this between OCIO and ACES that should be 
+      improved. Mark's points are valid. Hard to translate between projects. 
+      Think if this is going to be ACES reference config, have responsibility 
+      to link to CTL, to keep us accountable.
+    - Thomas: Agree. When started to work on automated generation, idea was to 
+      have something Scott and Alex could run automatically. Could be useful 
+      for them to check stuff on their end.
+    - Carol: Thinking too with comments, this is ACES reference config so can 
+      be more verbose. Can make descriptions for a more well rounded studio 
+      config.
+    - Thomas: To that, could be something in CTL itself, front facing (one 
+      liner) user comments. Maybe some roads to be made here, and CTL can help 
+      us do that work.
+    - Mark: I'll push my simplified version in a PR so you can see what I was 
+      looking for. At this point it's doing same thing. Just less code. There's 
+      a disconnect between CTL and OCIO. We aren't using the CTL in OCIO, but 
+      re-implementing transforms ourselves. Get the desire to strengthen link 
+      between projects, but feel the relationship goes opposite direction too, 
+      with many using ACES through OCIO.
+    - Doug: Because of Thomas experience maintaining existing configs, has 
+      learned how challenging it is to maintain. At each update may not be 
+      obvious what has changed. What has been produced is complex, but it does 
+      try to solve this problem with how to keep in sync with something with 
+      many moving parts. Certainly not a unique problem for OCIO. All ACES 
+      product partners face same problem. Every time there's a new ACES release 
+      takes days to go through and make sure the transforms are implemented 
+      correctly. Everyone is re-implementing it vs. using CTL directly. It 
+      would be nice to give feedback to Academy to make it easier to do what 
+      we're trying to do since we're not the only ones.
+    - Michael: Since we will also need to use this to generate the studio 
+      config, which will include much more than just ACES, more argument to 
+      leverage this code as library supporting config generation. Then both 
+      scripts can use it as needed and for validation.
+    - Thomas: Agree to find middle ground. We can raise exception when we don't 
+      have things mapped. Want library because I'm planning to use it, and hope 
+      others too. Can become tools to not only generate ACES config, but other 
+      configs too.
+    - Mark: For ACES config, all the guts are builtin transforms being chained 
+      together. Just need to write YAML file in correct order.
+    - Carol: If we are thinking future extensible, good to start out well.
+    - Thomas: Needs to be something we can test. Advantage on a show is if 
+      something is broken you change it, but here we're talking about 
+      something being shipped in software. It needs to work. When I did 
+      transition between 1.0 and 1.1, took ages because a mistake will effect 
+      everybody. When Nuke ships with this, it's a big difference. Internal and 
+      public software different jobs.
+    - Mark: Discussions around entry points for building ACES config vs config 
+      library different. Would have had other discussions around creating the 
+      lib. That's my concern. Not putting down current work. There is massive 
+      ramifications for doing it wrong, so that's important and I appreciate 
+      what's there.
+    - Thomas: Understand. Maybe I can do a write up on current state and idea.
+    - Zach: Raise interesting question. Do we want to have mechanism for 
+      testing against ctlrender, etc?
+    - Thomas: Yes, planning to do that.
+    - Michael: Thomas set up GHA CI so we can test against images, etc.
+    - Thomas: Not implemented yet, but where I want to go. Don't think we can 
+      do less than current config. Need to confirm implementation is matching.
+    - Doug: Think this will be very helpful to ACES project. Already flagged 
+      issues with Transform IDs. As we get it, we'll likely find differences 
+      with CTL and reference images.
+
+* Talk about dev workflow, it is a bit painful atm: 
+    - https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES/pull/9#issuecomment-735352837
+    - Thomas: Annoyance currently is we're not using gitflow. Currently one 
+      main branch. When merging and squashing, get diverging history 
+      because of other in-progress work. If you have two feature branches, if 
+      you squash one, need to rebase.
+    - Michael: Same setup we have for core OCIO. Messy if people have many 
+      commits, which is why we enforce squashing.
+    - Thomas: Can ask people to be cleaner. We tend to rebase on develop before 
+      merging. Can ask people to squash on their own. Makes it easier to revert 
+      changes.
+    - Mark: Think we expect most dev work to happen on forks, and for changes 
+      to come in as PRs, vs. feature branches pushed to repo.
+    - Thomas: Yeah, that's what is happening. Look at PR #9. Can talk on Slack.
+    - Michael: Gitflow can get complex. OpenEXR is doing something in the 
+      middle, with a develop and main branch. We could do something like that.
+    - Thomas: Mostly talking about main/develop. Not full gitflow. Two branches. 
+      Suggested same to Academy.
+
+* Talk about what we can do with the incorrectly named ACEStransformID as I 
+  have the feeling we won’t get a resolution from the AMPAS soon:
+    - Scott: Working to get issues resolved with our repo. Fixes in dev branch 
+      not integrated yet.
+
+* Fully fledged display spaces, it was agreed here on Slack, but maybe we can 
+  make it official:
+    - Thomas: Doug agreed in slides that the way the transforms were broken up 
+      could be simplified to have single transform instead of group transform.
+    - Doug: Agree. Adding BuiltinTransforms in current PR.
+
+* Items for next TSC meeting agenda:
+    - Further discuss spreadsheet questions with Scott.

ASWF/meetings/working_groups/configs/2021-01-19.md

@@ -0,0 +1,107 @@
+<!-- SPDX-License-Identifier: CC-BY-4.0 -->
+<!-- Copyright Contributors to the OpenColorIO Project. -->
+
+January 19, 2021
+
+Host: Michael Dolan
+
+Attendees:
+  * [X] Mark Boorer (_TSC_) - Industrial Light & Magic
+  * [X] Michael Dolan (_TSC Chair_) - Epic Games
+  * [X] Carol Payne (_TSC_) - Netflix
+  * [X] Doug Walker (_TSC Chief Architect_) - Autodesk
+  * [X] Dennis Adams - Sony
+  * [X] Christophe Brejon
+  * [X] Zach Lewis - Method
+  * [X] Scott Dyer - A.M.P.A.S.
+  * [X] Sean Cooper (_TSC_) - ARRI
+  * [X] Kevin Wheatley (_TSC_) - Framestore
+
+Apologies:
+  * Thomas Mansencal
+
+# **OCIO Configs Working Group Meeting Notes**
+
+* Include skeleton API for missing building transforms in v2.0.0? Need to make 
+  call on CY2021 ABI compatibility for VFX ref platform. If not may need to 
+  expose transform internals in config:
+    - Michael: Following up from TSC meeting discussion. Options put on the 
+      table: Add stubs for missing transforms? Switch to a minor version range 
+      in CY2021?
+    - Decision: Back out of requested VFX ref platform change. Stick with 2.0.x
+      for CY2021 and move forward with any needed minor version updates 
+      throughout the year. ACES 1.3 support won't arrive until CY2022, and the 
+      ACES config will use verbose color space definitions instead of Builtin 
+      transforms in some places, but in performance and functionality will be 
+      equivalent. We will attempt to maintain ABI compatibility for initial 
+      minor version releases for users who want to drop newer versions into 
+      CY2021 DCCs. There are some algorithms (e.g. PQ) that need to be added to
+      core lib to support LUT-free ACES config. AD will submit PR with these 
+      additions this week for the v2.0.0 release next week.
+          - Other proposed plans would have worked, but the group determined it
+            would be better to strictly follow semver and not make a rash 
+            decision based solely on getting the changes into VFX ref platform. 
+            As Sean put it: "Feels like the cart driving the horse". The agreed 
+            upon resolution permits completion of the ACES reference 
+            (and studio) configs and gives us a year to polish the v2 features 
+            for CY2022. DCCs likely won't have v2 support until near mid year 
+            anyway, and studios will likely delay further beyond that.
+
+* Make decision on config generation code direction:
+    - Michael: Propose we stick with current code in repo. Refinements can be 
+      contributed via PR if needed. 
+    - Mark and group: Go for it.
+    - Sean: Will there be artifacts via CI? Biggest buffer to people not caring 
+      about code.
+    - Mark: Discussed artifacts and versioning earlier. Still plan to provide 
+      artifacts.
+    - Michael: Yes, Thomas add CI setup which can be extended to support that.
+
+* Spreadsheet questions ACES feedback:
+    - Michael: Open questions are related to inclusion of ACESproxy and the 
+      DCDM output transforms. Scott suggested they not be included by email, 
+      but we can discuss here to confirm a decision.
+    - Carol: Get rid of them if ACES doesn't want them.
+    - Scott: Better way to do DCDM than the transforms. Leave them out.
+    - Michael: Same about ACESproxy?
+    - Doug: Clipped integer version of ACEScc. Not sure why needed in OCIO.
+    - Scott: Not sure of many using ACESproxy at all.
+    - Group agrees to exclude these. Set to "excluded" in spreadsheet.
+    - Carol: In first version, get people to speak up if they miss it.
+    - Michael: Anything else?
+    - Sean: Why only Sony Venice included?
+    - Doug: Other Sony transforms in CSC section further up.
+    - Carol: There isn't CSC of new Sony Venice IDTs yet.
+
+* Un-tonemapped view naming:
+    - Doug: Discussion about needing another view (un-tone-mapped) in config. 
+      Trying to come up with name: Source colors, scene referred colors, 
+      textures, colorimetry, colorimetric view, un-ton-mapped, no tone-map, 
+      identity tone-map, identity view, 1:1, flat...
+    - Decision: Group agrees on "un-tone-mapped" since it is explicit and 
+      clear. It may be confusing to users not familiar with color science, but
+      it is better to have something clear to config authors, and a good 
+      learning opportunity for others. Also the term used by ACES.
+
+* Review of ACES Output Transform prototype:
+    - Doug demos how to implement output transform with current OCIO v2 state. 
+      Breaking down transforms needed to create ODT, which in the future will 
+      be defined in a builtin transform via C++.
+    - Doug: Clamps around ACES primary change prevent negative values from 
+      becoming large positives due to matrix. In testing that, noticed that 
+      some ACES output transforms generate black in unexpected places. Tested 
+      synthetic chart with camera log space. Values going through power 
+      function to infinity. Builtin functions for CSC log transforms will send 
+      large input values (outside 0-1) to infinity on output. Is that ok? Or 
+      should we clamp to large positive value? Often implemented with LUTs 
+      where infinity won't occur. Implemented here with LogCameraTransform, so 
+      exact math. Value greater than one could give infinity.
+    - Mark: Think infinity fine in that context. Doing the right thing.
+    - Doug: Downside is for synthetic chart image, with RGB inf,inf,inf one 
+      channel will become negative and get mapped to NaN (Inf - Inf) when going 
+      through a matrix. Since NaN typically maps to zero, it's possible that 
+      extremely bright values map to black on display.
+    - Mark: Don't think would be problem. The formula should do what it does. 
+      We understand floating point limitations and are used to hitting them, 
+      so not crazy to expect same behavior here. Would be weird to do something 
+      different.

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.

CHANGELOG.md

@@ -1,8 +1,14 @@
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 <!-- Copyright Contributors to the OpenColorIO Project. -->
 
-**Version 2.0.0 (unreleased):**
-    * Renamed sanityCheck() method to validate()
+This file documents releases up to 1.1.1.  For a description of version 2.0 and later
+please refer to the Releases page on GitHub:
+
+https://github.com/AcademySoftwareFoundation/OpenColorIO/releases
+
+and for more details please see the release notes in latest documentation pages:
+
+https://opencolorio.readthedocs.io/en/latest/releases/_index.html#releases
 
 **Version 1.1.1 (April 2 2019):**
     * Added optional compatibility for building apps with OpenImageIO 1.9+

CMakeLists.txt

@@ -5,13 +5,14 @@
 ###############################################################################
 # CMake definition.
 
-cmake_minimum_required(VERSION 3.12)
+cmake_minimum_required(VERSION 3.14...4.0)
 
 set(CMAKE_MODULE_PATH
     ${CMAKE_MODULE_PATH}
-    ${CMAKE_SOURCE_DIR}/share/cmake/utils
-    ${CMAKE_SOURCE_DIR}/share/cmake/macros
-    ${CMAKE_SOURCE_DIR}/share/cmake/modules
+    ${CMAKE_CURRENT_SOURCE_DIR}/share/cmake/utils
+    ${CMAKE_CURRENT_SOURCE_DIR}/share/cmake/macros
+    ${CMAKE_CURRENT_SOURCE_DIR}/share/cmake/modules
+    ${CMAKE_CURRENT_SOURCE_DIR}/share/cmake/modules/install
 )
 
 set(CMAKE_WARN_DEPRECATED ON)
@@ -20,7 +21,7 @@ set(CMAKE_WARN_DEPRECATED ON)
 if(APPLE AND NOT DEFINED CMAKE_OSX_DEPLOYMENT_TARGET)
     # The value of this variable should be set prior to the first project() command invocation
     # because it may influence configuration of the toolchain and flags.
-    set(CMAKE_OSX_DEPLOYMENT_TARGET "10.13" CACHE STRING "Minimum OS X deployment version")
+    set(CMAKE_OSX_DEPLOYMENT_TARGET "10.15" CACHE STRING "Minimum OS X deployment version")
 endif()
 
 
@@ -28,21 +29,34 @@ endif()
 # Project definition.
 
 project(OpenColorIO 
-    VERSION 2.0.0
+    VERSION 2.6.0
     DESCRIPTION "OpenColorIO (OCIO) is a complete color management solution"
     HOMEPAGE_URL https://github.com/AcademySoftwareFoundation/OpenColorIO
     LANGUAGES CXX C)
 
 # "dev", "beta1", rc1", etc or "" for an official release.
-set(OpenColorIO_VERSION_RELEASE_TYPE "beta1")
+set(OpenColorIO_VERSION_RELEASE_TYPE "dev")
+
+
+###############################################################################
+# 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.
 
-if(${CMAKE_SOURCE_DIR} STREQUAL ${CMAKE_BINARY_DIR})
+if(${PROJECT_SOURCE_DIR} STREQUAL ${PROJECT_BINARY_DIR})
     message(FATAL_ERROR 
             "In-source build not allowed. Please make a new sub-directory and run cmake from there.")
 endif()
@@ -81,11 +95,26 @@ set_property(CACHE CMAKE_BUILD_TYPE PROPERTY STRINGS "Debug" "Release" "MinSizeR
 
 # Is that a valid build type?
 
-if(NOT "${CMAKE_BUILD_TYPE}" IN_LIST CMAKE_CONFIGURATION_TYPES)
+set(_build_type_valid_ false)
+foreach (_build_type_ ${CMAKE_CONFIGURATION_TYPES})
+    string(TOLOWER ${_build_type_} _lowercase_build_type_)
+    string(TOLOWER ${CMAKE_BUILD_TYPE} _lowercase_cmake_build_type_)
+
+    if (_lowercase_cmake_build_type_ STREQUAL _lowercase_build_type_)
+        # Build type is supported.
+        set(_build_type_valid_ true)
+        break()
+    endif()
+endforeach()
+unset(_lowercase_build_type_)
+unset(_lowercase_cmake_build_type_)
+
+if (NOT _build_type_valid_)
     string(REPLACE ";" ", " _CMAKE_CONFIGURATION_TYPES_STR "${CMAKE_CONFIGURATION_TYPES}")
     message(FATAL_ERROR 
             "CMAKE_BUILD_TYPE=${CMAKE_BUILD_TYPE} is unsupported. Supported values are: ${_CMAKE_CONFIGURATION_TYPES_STR}.")
 endif()
+unset(_build_type_valid_)
 
 # Is that in debug mode?
 
@@ -109,43 +138,234 @@ include(CppVersion)
 
 option(BUILD_SHARED_LIBS "Set to OFF to build static libraries" ON)
 option(OCIO_BUILD_APPS "Set to OFF to disable command-line apps" ON)
+option(OCIO_BUILD_OPENFX "Specify whether to build OpenFX plugins" OFF)
 option(OCIO_BUILD_NUKE "Specify whether to build nuke plugins" OFF)
-option(OCIO_BUILD_DOCS "Specify whether to build documentation" OFF)
 option(OCIO_BUILD_TESTS "Specify whether to build unittests" ON)
 option(OCIO_BUILD_GPU_TESTS "Specify whether to build gpu unittests" ON)
 option(OCIO_USE_HEADLESS "Specify whether the GPU rendering is headless" OFF)
 
+option(OCIO_BUILD_DOCS "Specify whether to build documentation" OFF)
+
 option(OCIO_BUILD_PYTHON "Specify whether to build python bindings" ON)
+set (OCIO_PYTHON_VERSION "" CACHE STRING
+     "Preferred Python version (if any) in case multiple are available")
+
 option(OCIO_BUILD_JAVA "Specify whether to build java bindings" OFF)
 
+if (WIN32)
+    option(OCIO_USE_WINDOWS_UNICODE "Compile with Windows Unicode support" ON)
+endif()
+
+###############################################################################
+# Other preferences
+
+option(OCIO_VERBOSE "Display more information when searching or installing dependencies" OFF)
+option(OCIO_USE_SOVERSION "Enable versioning in OCIO shared library name" ON)
+
+###############################################################################
+# Warnings / debugging settings
+
 option(OCIO_WARNING_AS_ERROR "Set build error level for CI testing" OFF)
 
+if (NOT WIN32)
+    option(OCIO_ENABLE_SANITIZER "Specify whether to enable compiler sanitizers (address)" OFF)
+endif()
+
 
 ###############################################################################
 # Optimization / internal linking preferences
-
-option(OCIO_USE_SSE "Specify whether to enable SSE CPU performance optimizations" ON)
-option(OCIO_INLINES_HIDDEN "Specify whether to build with -fvisibility-inlines-hidden" ${UNIX})
+option(OCIO_USE_SIMD "Specify whether to enable SIMD CPU performance optimizations" ON)
+option(OCIO_USE_OIIO_FOR_APPS "Request OIIO to build apps (ociolutimage, ocioconvert and ociodisplay), the default uses OpenEXR." OFF)
 
 
-###############################################################################
-# Supplemental builtins
+if (NOT APPLE)
+    if("${CMAKE_GENERATOR_PLATFORM}" MATCHES "(ARM64|arm64)" OR CMAKE_SYSTEM_PROCESSOR STREQUAL "ARM64")
+        set(OCIO_ARCH_X86 0)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX OFF)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C OFF)
+    elseif ("${CMAKE_SYSTEM_PROCESSOR}" MATCHES "(AMD64|IA64|EM64T|x86_64|X86|i386|i686)")
+        # Intel-based architecture (not APPLE)
+        if ("${CMAKE_SYSTEM_PROCESSOR}" MATCHES "(X86|i386|i686)")
+            set(OCIO_ARCH_X86_32 1)
+        endif()
+        set(OCIO_ARCH_X86 1)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX ON)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C ON)
+    else()
+        set(OCIO_ARCH_X86 0)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE OFF)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX OFF)
+        set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C OFF)
+    endif()
+elseif (APPLE)
+    # Multiple possible scenarios:
+    # A. Building on an Apple arm64 architecture for the native architecture (arm64).
+    # B. Building on an Apple arm64 architecture for x86_64.
+    # C. Building on an Apple arm64 architecture for universal binaries (x86_64 + arm64).
+    #
+    # D. Building on an Apple Intel architecture for the native architecture (x86_64).
+    # E. Building on an Apple Intel architecture for arm64.
+    # F. Building on an Apple Intel architecture for universal binaries (x86_64 + arm64).
 
-# Add supplemental built-in transformations such as camera related one.
-option(OCIO_ADD_EXTRA_BUILTINS "Specify whether to add supplemental built-in transforms" ON)
+    # Check if we are NOT cross-compiling to another Apple architecture.
+    if (NOT DEFINED CMAKE_OSX_ARCHITECTURES OR CMAKE_OSX_ARCHITECTURES STREQUAL "")
+        # Building for the native architectures.
+        if ("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "x86_64")
+            # Apple Intel-based computer or Rosetta. (covers case D)
+
+            set(OCIO_ARCH_X86 1)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+            # The AVX and F16C will be compiled, but it won't used at runtime by Rosetta.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX ON)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C ON)
+        elseif ("${CMAKE_SYSTEM_PROCESSOR}" STREQUAL "arm64")
+            # Apple arm64. (covers case A)
+
+            set(OCIO_ARCH_X86 0)
+            # OCIO translates the SSE instructions into ARM Neon with the library SSE2NEON.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+            # OCIO does not translate AVX to ARM Neon.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX OFF)
+            # Turn F16C off since they are x86_64 instructions.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C OFF)
+        endif()
+    else()
+        # Cross-compiling to another Apple architecture (x86_64, arm64, or both (universal))
+        if ("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "x86_64")
+            # Compiling for x86_64 regardless of native architecture.
+            # Covers case B assuming CMAKE_SYSTEM_PROCESSOR is arm64.
+            # Covers case D if CMAKE_OSX_ARCHITECTURES is set to x86_64 on x86_64 architecture.
+
+            set(OCIO_ARCH_X86 1)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+            # The AVX and F16C will be compiled, but they won't used at runtime by Rosetta.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX ON)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C ON)
+        elseif ("${CMAKE_OSX_ARCHITECTURES}" STREQUAL "arm64")
+            # Compiling for arm64 regardless of native architecture.
+            # Covers case E assuming CMAKE_SYSTEM_PROCESSOR is x86_64.
+            # Covers case A if CMAKE_OSX_ARCHITECTURES is set arm64 on arm64 architecture.
+
+            set(OCIO_ARCH_X86 0)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX OFF)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C OFF)
+        elseif ("${CMAKE_OSX_ARCHITECTURES}" MATCHES "(arm64;x86_64|x86_64;arm64)")
+            # Universal build (covers case C and F).
+
+            set(OCIO_ARCH_X86 1)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE ON)
+            # The AVX and F16C will be compiled, but they won't used at runtime by Rosetta.
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX ON)
+            set(OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C ON)
+        endif()
+    endif()
+endif()
+
+option(OCIO_USE_SSE2 "Specify whether to enable SSE2 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE})
+option(OCIO_USE_SSE3 "Specify whether to enable SSE3 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE})
+option(OCIO_USE_SSSE3 "Specify whether to enable SSSE3 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE})
+option(OCIO_USE_SSE4 "Specify whether to enable SSE4 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE})
+option(OCIO_USE_SSE42 "Specify whether to enable SSE4.2 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_SSE})
+option(OCIO_USE_AVX "Specify whether to enable AVX CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX})
+option(OCIO_USE_AVX2 "Specify whether to enable AVX2 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX})
+option(OCIO_USE_AVX512 "Specify whether to enable AVX512 CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_AVX})
+option(OCIO_USE_F16C  "Specify whether to enable F16C CPU performance optimizations" ${OCIO_BUILD_ENABLE_OPTIMIZATIONS_F16C})
+
+if (APPLE OR WIN32)
+   # TODO: Revisit whether that option is necessary.
+   option(OCIO_USE_SSE2NEON "Specify whether to enable SSE CPU performance optimizations using SSE2NEON for Apple ARM architecture" ON)
+   mark_as_advanced(OCIO_USE_SSE2NEON)
+endif()
 
 
 ###############################################################################
 # GPU configuration
-
+message(STATUS "")
+message(STATUS "Checking for GPU configuration...")
 include(CheckSupportGL)
 
+# DirectX 12 is only available on Windows.
+if(WIN32)
+    option(OCIO_DIRECTX_ENABLED "Enable DirectX 12 GPU rendering support" ON)
+else()
+    set(OCIO_DIRECTX_ENABLED OFF CACHE BOOL "Enable DirectX 12 GPU rendering support" FORCE)
+endif()
+mark_as_advanced(OCIO_DIRECTX_ENABLED)
+
+# Vulkan is cross-platform but requires an external SDK, so it is off by
+# default; enable explicitly with -DOCIO_VULKAN_ENABLED=ON.
+option(OCIO_VULKAN_ENABLED "Enable Vulkan GPU rendering support" OFF)
+mark_as_advanced(OCIO_VULKAN_ENABLED)
+
+
+###############################################################################
+# Check for ARM neon here because we need to know if ARM NEON is supported
+# quickly. Once we know that ARM NEON is supported, we can add sse2neon library
+# to the build.
+
+if(OCIO_USE_SIMD)
+    include(CheckSupportARMNeon)
+
+    if (NOT COMPILER_SUPPORTS_ARM_NEON)
+        # Force it to OFF since ARM Neon is not supported.
+        set(OCIO_USE_SSE2NEON OFF)
+    endif()
+endif()
+
+
+###############################################################################
+# Add sse2neon to the build if ARM NEON intrinsics are supported.
+
+if(OCIO_USE_SIMD AND OCIO_USE_SSE2NEON AND COMPILER_SUPPORTS_ARM_NEON)
+    # Install sse2neon. Please note that sse2neon is downloaded during the configure step as it is
+    # needed for CompilerFlags.cmake and CheckSupportSSEUsingSSE2NEON.cmake.
+
+    # Sse2neon is not treated like an imported target. The logic to find sse2neon is here because 
+    # a find module is not suitable for sse2neon's use case.
+    find_path(sse2neon_INCLUDE_DIR
+        NAMES
+            sse2neon.h
+        HINTS
+            ${sse2neon_ROOT}
+        PATH_SUFFIXES
+            sse2neon
+            include
+            sse2neon/include
+    )
+
+    # As per instructions on sse2neon's GitHub page, the following compiler flags should be used:
+    # "-march=armv8-a+fp+simd+crypto+crc". These flags are required for some ARM platforms that do
+    # not enable floating point calculations or SIMD instructions by default. However, for ARM64
+    # (Apple ARM platform) and x86_64 platforms, these features are already enabled by default.
+    # Therefore, no additional compiler flags are needed.
+    if (NOT sse2neon_INCLUDE_DIR)
+        include(Installsse2neon)
+    else()
+        # Any changes to the following lines must be replicated in Installsse2neon.cmake as well.
+        # Create a target for sse2neon (non-imported)
+        add_library(sse2neon INTERFACE)
+        # Add the include directories to the target.
+        target_include_directories(sse2neon INTERFACE "${sse2neon_INCLUDE_DIR}")
+        if(NOT MSVC)
+            # Ignore the warnings coming from sse2neon.h as they are false positives.
+            target_compile_options(sse2neon INTERFACE -Wno-unused-parameter)
+        endif()
+    endif()
+endif()
+
 
 ###############################################################################
 # Define compilation and link flags
 
 include(CompilerFlags)
 
+###############################################################################
+# Include utility functions for setting debugging environments
+
+include(DebuggerEnvironment)
 
 ###############################################################################
 # External linking options
@@ -189,11 +409,12 @@ endif()
 # Namespace
 
 if(NOT DEFINED OCIO_NAMESPACE)
-    set(OCIO_NAMESPACE OpenColorIO CACHE STRING 
-        "Specify the master OCIO C++ namespace: Options include OpenColorIO OpenColorIO_<YOURFACILITY> etc.")
-    message(STATUS "Setting namespace to '${OCIO_NAMESPACE}' as none was specified.")
+	set(OCIO_NAMESPACE "OpenColorIO_v${OpenColorIO_VERSION_MAJOR}_${OpenColorIO_VERSION_MINOR}${OpenColorIO_VERSION_RELEASE_TYPE}" CACHE STRING 
+        "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()
+    message(STATUS "Setting namespace to '${OCIO_NAMESPACE}'.")
 endif()
 
 
@@ -231,6 +452,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
@@ -244,11 +474,84 @@ include(FindExtPackages)
 ###############################################################################
 # Progress to other sources
 
-add_subdirectory(ext)
-add_subdirectory(include)
-add_subdirectory(src)
-add_subdirectory(tests)
+add_subdirectory(vendor)
 if(OCIO_BUILD_DOCS)
 	add_subdirectory(docs)
 endif()
-add_subdirectory(vendor)
+add_subdirectory(tests)
+add_subdirectory(src)
+add_subdirectory(ext)
+
+
+###############################################################################
+# Configure env script
+
+if(WIN32)
+    set(OCIO_SETUP_NAME setup_ocio.bat)
+else()
+    set(OCIO_SETUP_NAME setup_ocio.sh)
+endif()
+
+configure_file(${PROJECT_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 ${CMAKE_INSTALL_DATADIR}/ocio/)
+
+
+###############################################################################
+# Generate OpenColorIO-config.cmake
+# Targets exported to ${PROJECT_NAME}_EXPORTED_TARGETS will be available for
+# import using find_package(OpenColorIO).
+
+include(CMakePackageConfigHelpers)
+
+set(OCIO_TARGETS_EXPORT_NAME "${PROJECT_NAME}Targets.cmake")
+set(OCIO_VERSION_CONFIG "${PROJECT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake")
+set(OCIO_PROJECT_CONFIG "${PROJECT_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(
+    ${OCIO_VERSION_CONFIG}
+    # Version range supported only if generated by CMake 3.19.2 or newer.
+    COMPATIBILITY SameMajorVersion
+)
+
+configure_package_config_file(
+    ${CMAKE_CURRENT_LIST_DIR}/src/cmake/Config.cmake.in ${OCIO_PROJECT_CONFIG}
+    INSTALL_DESTINATION ${OCIO_CONFIG_INSTALL_DIR}
+    NO_SET_AND_CHECK_MACRO
+    NO_CHECK_REQUIRED_COMPONENTS_MACRO
+)
+
+install(
+    EXPORT ${PROJECT_NAME}_EXPORTED_TARGETS
+    DESTINATION ${OCIO_CONFIG_INSTALL_DIR}
+    NAMESPACE ${PROJECT_NAME}::
+    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

@@ -3,19 +3,32 @@
 
 # OpenColorIO Committers
 
-The current OpenColorIO Committers are:
+### Current OpenColorIO Committers
 
 | Name           | GitHub ID |
-| -------------- | -----------------
+| -------------- | ----------------- | 
+| Michael Dolan | @michdolan |
+| Mark Boorer | @Shootfast |
+| Sean Cooper | @scoopxyz | 
+| Doug Walker | @doug-walker |
+| Kevin Wheatley | @KevinJW |
+| Rémi Achard | @remia |
+| Carol Payne | @carolalynn | 
+| Thomas Mansencal | @KelSolaar |
+| Mark Reid | @markreidvfx |
+| Cuneyt Ozdas | @cozdas | 
+
+### Emeritus OpenColorIO Committers
+
+| Name           | GitHub ID |
+| -------------- | ----------------- | 
 | Malcolm Humphreys | @malcolmhumphreys |
 | Jeremy Selan | @jeremyselan |
 | Steve Lavietes | @stevelavietes |
 | Robert Molholm | @rmolholm |
-| Michael Dolan | @michdolan |
-| Mark Boorer | @Shootfast |
 | Matthias Scharfenberg | @Tristimulus |
-| Sean Cooper | @scoopxyz
-| Patrick Hodoul | @hodoulp
-| Cottalango Leon | @loorthu
-| Doug Walker | @doug-walker |
-| Kevin Wheatley | @KevinJW |
+| Patrick Hodoul | @hodoulp | 
+| Cottalango Leon | @loorthu | 
+| Cédrik Fuoco | @cedrik-fuoco-adsk |
+| Larry Gritz | @lgritz | 
+| Michael Parsons | @mlfp | 

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
 
@@ -241,31 +243,12 @@ expected to validate the behavior of every part of OCIO:
 * Any change to existing functionality should have tests added if they
   don't already exist.
 
-The test should should be run, via ``ctest``, before submitting a pull request.
+The test 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

@@ -69,7 +69,14 @@ A subset of the Committers forms the Technical Steering Committee (TSC), which
 has final authority over this project. As defined in the project charter, TSC
 responsibilities include, but are not limited to:
 
-* Coordinating technical direction of the Project
+* Coordinating technical direction of the Project, including but not limited to:
+    * Participating in roadmapping and feature priority each year
+    * Participating in Working Groups as appropriate
+    * Actively tracking development & giving feedback promptly
+    * Participating in maintenance of technical documentation
+    * Actively discussing issues & reviewing pull requests
+    * Actively monitoring and assisting contributors on GitHub
+    * Actively monitoring and assisting folks on the OCIO slack instance
 * Project governance and process (including this policy)
 * Contribution policy
 * GitHub repository hosting
@@ -81,7 +88,7 @@ communities
 matters relating to the code base that affect multiple projects
 * Coordinating any marketing, events, or communications regarding the project
 
-Within the TSC are three elected leadership roles to be held by its members and
+Within the TSC are two elected leadership roles to be held by its members and
 voted on annually. Any TSC member can express interest in serving in a role, or
 nominate another member to serve. There are no term limits, and one person may
 hold multiple roles simultaneously. Should a TSC member resign from a leadership
@@ -96,10 +103,6 @@ providing oversight to project administration.
 technical decisions, and is responsible for avoiding "design by committee"
 pitfalls.
 
-* ACES TAC Rep: This position maintains oversight of the critical relationship
-between OCIO and ACES, representing OCIO on the ACES TAC and facilitating 
-coordination of shared initiatives between both project's leadership.
-
 At the time of election, the TSC will also agree upon which of these two leaders
 will serve as the OpenColorIO ASWF (Academy Software Foundation) TAC (Technical
 Advisory Council) representative for the term. This member represents the
@@ -107,23 +110,30 @@ 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 - DNEG
+* Sean Cooper - ARRI
 * Michael Dolan - Epic Games
-* Patrick Hodoul - Autodesk
-* Carol Payne - Netflix
-* Carl Rand - Weta Digital
+* Zach Lewis - Method Studios
+* Thomas Mansencal - Wētā FX
+* Cuneyt Ozdas - Autodesk
+* Carol Payne - Independent Consultant
 * Mark Titchener - Foundry
+* Mark Reid - Animal Logic
 * Doug Walker - Autodesk
 * Kevin Wheatley - Framestore
 
+### TSC Emeritus
+
+* Patrick Hodoul - Autodesk
+* Carl Rand - Wētā FX
+
 ### TSC Meetings
 
 Any meetings of the TSC are intended to be open to the public, except where
@@ -143,7 +153,7 @@ happen continuously on GitHub and be handled by the larger group of Committers.
 
 Any community member or Contributor can ask that something be reviewed by the
 TSC by logging a GitHub issue. Any Committer, TSC member, or the meeting chair
-can bring the issue to the TSC's attention by applying the `tsc-review` label.
+can bring the issue to the TSC's attention by applying the `Needs Discussion` label.
 
 Prior to each TSC meeting, the meeting chair will share the agenda with members
 of the TSC. TSC members can also add items to the agenda at the beginning of
@@ -152,11 +162,11 @@ each meeting. The meeting chair and the TSC cannot veto or remove items.
 The TSC may invite additional persons to participate in a non-voting capacity.
 
 The meeting chair is responsible for ensuring that minutes are taken and that
-notes are submitted after the meeting to the public mailing list.
+notes are submitted after the meeting to the public wiki.
 
 Due to the challenges of scheduling a global meeting with participants in
 several time zones, the TSC will seek to resolve as many agenda items as
-possible outside of meetings on the public mailing list.
+possible outside of meetings via discussion on Slack or other methods.
 
 ### TSC Nomination
 

INSTALL.md

@@ -1,4 +1,4 @@
 <!-- SPDX-License-Identifier: CC-BY-4.0 -->
 <!-- Copyright Contributors to the OpenColorIO Project. -->
 
-For install instructions, see docs/installation.rst
+For install instructions, see docs/quick_start/installation.rst

MANIFEST.in

@@ -0,0 +1,11 @@
+include LICENSE
+graft docs
+graft ext
+graft include
+graft share
+graft src
+graft tests
+global-include CMakeLists.txt *.cmake *.md
+global-exclude */__pycache__/*
+global-exclude *.pyc
+global-exclude .DS_Store

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 

README.md

@@ -10,6 +10,7 @@ OpenColorIO
 [![Analysis Status](https://github.com/AcademySoftwareFoundation/OpenColorIO/workflows/Analysis/badge.svg)](https://github.com/AcademySoftwareFoundation/OpenColorIO/actions?query=workflow%3AAnalysis)
 [![Quality Gate Status](https://sonarcloud.io/api/project_badges/measure?project=AcademySoftwareFoundation_OpenColorIO&metric=alert_status)](https://sonarcloud.io/dashboard?id=AcademySoftwareFoundation_OpenColorIO)
 [![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/2612/badge)](https://bestpractices.coreinfrastructure.org/projects/2612)
+[![Wheels](https://github.com/AcademySoftwareFoundation/OpenColorIO/workflows/Wheel/badge.svg)](https://github.com/AcademySoftwareFoundation/OpenColorIO/actions?query=workflow%3AWheel)
 
 Introduction
 ------------
@@ -28,16 +29,16 @@ configuration options suitable for high-end production usage. OCIO is
 compatible with the Academy Color Encoding Specification (ACES) and is
 LUT-format agnostic, supporting many popular formats.
 
-OpenColorIO is released as version 1.0 and has been in development since 2003.
+OpenColorIO is released as version 2.0 and has been in development since 2003.
 OCIO represents the culmination of years of production experience earned on
 such films as SpiderMan 2 (2004), Surf's Up (2007), Cloudy with a Chance of
 Meatballs (2009), Alice in Wonderland (2010), and many more. OpenColorIO is
 natively supported in commercial applications like Katana, Mari, Nuke, Maya,
 Houdini, Silhouette FX, and
-[others](https://opencolorio.org/CompatibleSoftware.html).
+[others](https://opencolorio.org/#supported_apps).
 
 OpenColorIO is free and open source software ([LICENSE](LICENSE)), and
-one of several projects actvively sponsored by the ASWF
+one of several projects actively sponsored by the ASWF
 ([Academy Software Foundation](https://www.aswf.io/)).
 
 OpenColorIO Project Mission
@@ -49,12 +50,12 @@ content creation applications and pipelines.
 
 OpenColorIO aims to:
 
-* be stable, secure, and thouroughly tested on Linux, macOS, and Windows
+* be stable, secure, and thoroughly tested on Linux, macOS, and Windows
 * be performant on modern CPUs and GPUs
 * be simple, scalable, and well documented
 * be compatible with critical color and imaging standards
 * provide lossless color processing wherever possible
-* maintain config backwards compatability across major versions
+* maintain config backwards compatibility across major versions
 * have every new feature carefully reviewed by leaders from the motion picture, 
   VFX, animation, and video game industries
 * have a healthy and active community
@@ -64,13 +65,14 @@ OpenColorIO Project Governance
 ------------------------------
 
 OpenColorIO is governed by the Academy Software Foundation (ASWF). See 
-[GOVERNANCE.md](GOVERNANCE.md) for detailed infomation about how the project 
+[GOVERNANCE.md](GOVERNANCE.md) for detailed information about how the project 
 operates.
 
 Web Resources
 -------------
 
 * Website: <http://opencolorio.org>
+* Documentation: <https://opencolorio.readthedocs.io/en/latest/>
 * Mailing lists:
   * Developer: <ocio-dev@lists.aswf.io>
   * User: <ocio-user@lists.aswf.io>
@@ -98,6 +100,11 @@ The following reference implementations are provided:
 * Other
   * nuke-default
 
+Sources for the newer builtin ACES configuration files can be found in the releases section of the
+[OpenColorIO-Config-ACES](https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES)
+repository.
+
+
 Acknowledgements
 ----------------
 

SECURITY.md

@@ -14,23 +14,15 @@ would be naive to say our code is immune to every exploit.
 
 ## Reporting Vulnerabilities
 
-Quickly resolving security related issues is a priority. If you think
-you've found a potential vulnerability in OpenColorIO, please report it by
-emailing security@opencolorio.org. Only TSC members and ASWF project
-management have access to these messages.
+Quickly resolving security related issues is a priority. The best way to report a 
+vulnerability is to file a GitHub security advisory. If that is not possible, it 
+is also fine to email your report to security@opencolorio.org. Only the project 
+administrators have access to these reports.
 
 Include detailed steps to reproduce the issue, and any other information that
 could aid an investigation. Someone will assess the report and make every
 effort to respond within 14 days.
 
-## Outstanding Security Issues
-
-None
-
-## Addressed Security Issues
-
-None
-
 ## File Format Expectations
 
 Attempting to read an OCIO config (YAML) file will:
@@ -65,5 +57,6 @@ It is a bug if calling a function with well-formed arguments causes the
 library to crash. It is a security issue if calling a function with 
 well-formed arguments causes arbitrary code execution.
 
-We do not consider this as severe as file format issues because in most 
-deployments the parameter space is not exposed to potential attackers.
+## History of CVE Fixes
+
+CVE-2026-42450 -- Stack buffer overflow in sscanf. (Fixed in OCIO 2.5.2)

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
 
@@ -192,4 +166,70 @@ SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 ---------------------------------------------------------------------
 
+OpenFX Support Library, courtesy of The Open Effects Association Ltd.
+http://openeffects.org/
+
+Software License :
+
+Copyright (c) 2004-2007, The Open Effects Association Ltd. All rights reserved.
+
+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.
+    * Neither the name The Open Effects Association Ltd, nor the names of its 
+      contributors may be used to endorse or promote products derived from this
+      software without specific prior written permission.
+
+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 OWNER 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.
+
+The Open Effects Association Ltd
+1 Wardour St
+London W1D 6PA
+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.

docs/CMakeLists.txt

@@ -3,100 +3,105 @@
 
 ###############################################################################
 ### Python ###
-find_package(Python REQUIRED COMPONENTS Interpreter)
+
 if(${Python_VERSION_MAJOR} GREATER_EQUAL 3)
     if(NOT OCIO_BUILD_PYTHON)
         message(FATAL_ERROR "Doc generation requires that the python bindings be built")
     endif()
 
-    ###############################################################################
+    ###########################################################################
+    ### Required dependencies ###
+
+    # Doxygen
+    # https://github.com/doxygen/doxygen
+    find_package(Doxygen REQUIRED)
+
+    # Sphinx
+    # https://pypi.python.org/pypi/Sphinx
+    find_package(Sphinx REQUIRED)
+
+    include(FindPythonPackage)
+
+    # six
+    # https://pypi.org/project/six/
+    find_python_package(six REQUIRED)
+
+    # testresources
+    # https://pypi.org/project/testresources/
+    find_python_package(testresources REQUIRED)
+
+    # Recommonmark
+    # https://pypi.org/project/recommonmark/
+    find_python_package(recommonmark REQUIRED)
+
+    # Sphinx Press Theme
+    # https://pypi.org/project/sphinx-press-theme/
+    find_python_package(sphinx-press-theme REQUIRED)
+
+    # sphinx-tabs
+    # https://pypi.org/project/sphinx-tabs/
+    find_python_package(sphinx-tabs REQUIRED)
+
+    # Breathe
+    # https://pypi.org/project/breathe/
+    find_python_package(breathe REQUIRED)
+
+    ###########################################################################
     ### Setup PYTHONPATH ###
 
-    # Override PYTHONPATH prior to running Sphinx. This makes the PyOpenColorIO
-    # build available, prioritizes ext/ installed Python dependencies, and
-    # propagates the system PYTHONPATH.
-    if(WIN32)
-        # Use Windows path separators since this is being passed through to cmd
-        file(TO_NATIVE_PATH ${CMAKE_BINARY_DIR} WIN_BINARY_DIR)
+    include(GetPythonPreCommand)
 
-        set(DLL_PATH "${WIN_BINARY_DIR}\\src\\OpenColorIO")
-        if(MSVC_IDE)
-            set(DLL_PATH "${DLL_PATH}\\${CMAKE_BUILD_TYPE}")
-        endif()
+    # Sets Python_PRE_CMD, which sets PATH and PYTHONPATH for Sphinx
+    get_python_pre_command()
 
-        string(CONCAT PATH_SET
-            "PATH="
-            "${DLL_PATH}"
-            "\\\\;"
-            "%PATH%"
-        )
-
-        set(PYD_PATH "${WIN_BINARY_DIR}\\src\\bindings\\python")
-        if(MSVC_IDE)
-            set(PYD_PATH "${PYD_PATH}\\${CMAKE_BUILD_TYPE}")
-        endif()
-
-        string(CONCAT PYTHONPATH_SET
-            "PYTHONPATH="
-            "${PYD_PATH}"
-            "\\\\;"
-            "${WIN_BINARY_DIR}\\ext\\dist\\lib${LIB_SUFFIX}\\site-packages"
-            "\\\\;"
-            "%PYTHONPATH%"
-        )
-        # Mimic *nix:
-        #   '> PYTHONPATH=XXX CMD'
-        # on Windows with:
-        #   '> set PYTHONPATH=XXX \n call CMD'
-        # '\n' is here because '\\&' does not work.
-        set(PYT_PRE_CMD set ${PATH_SET} "\n" set ${PYTHONPATH_SET} "\n" call)
-
-    else()
-        set(_Python_VARIANT "${Python_VERSION_MAJOR}.${Python_VERSION_MINOR}")
-        string(CONCAT PYT_PRE_CMD
-            "PYTHONPATH="
-            "${CMAKE_BINARY_DIR}/src/bindings/python"
-            ":"
-            "${CMAKE_BINARY_DIR}/ext/dist/lib${LIB_SUFFIX}/python${_Python_VARIANT}/site-packages"
-            ":"
-            "$ENV{PYTHONPATH}"
-        )
-    endif()
-
-    ###############################################################################
+    ###########################################################################
     ### Copy templates to build area ###
 
-    # NOTE: The *.in extension is omitted from conf.py since RTD uses this file 
-    #       without CMake configuration.
-    message(STATUS "Substitute sphinx conf.py variables")
-    configure_file(${CMAKE_SOURCE_DIR}/docs/conf.py
-        ${CMAKE_BINARY_DIR}/docs/conf.py @ONLY)
+    # Find and configure all *.in files in documentation. conf.py needs 
+    # configuration, but omits *.in to work in RTD builds.
+    message(STATUS "Substitute documentation variables")
+    file(GLOB_RECURSE DOC_IN_FILES 
+        "${PROJECT_SOURCE_DIR}/docs/**.in"
+        "${PROJECT_SOURCE_DIR}/docs/conf.py"
+    )
+    foreach(in_file ${DOC_IN_FILES})
+        string(REPLACE "${PROJECT_SOURCE_DIR}/" "${PROJECT_BINARY_DIR}/"
+            out_file ${in_file})
+        string(REPLACE ".in" "" 
+            out_file ${out_file})
+        configure_file(${in_file} ${out_file} @ONLY)
+    endforeach()
 
-    file(GLOB_RECURSE DOC_SOURCES "${CMAKE_SOURCE_DIR}/docs/*")
+    # Copy documentation source to build location
+    file(GLOB_RECURSE DOC_SOURCES "${PROJECT_SOURCE_DIR}/docs/*")
     list(APPEND DOC_SOURCES
-        ${CMAKE_SOURCE_DIR}/README.md
-        ${CMAKE_SOURCE_DIR}/INSTALL.md
-        ${CMAKE_SOURCE_DIR}/CHANGELOG.md
-        ${CMAKE_SOURCE_DIR}/LICENSE
+        ${PROJECT_SOURCE_DIR}/README.md
+        ${PROJECT_SOURCE_DIR}/INSTALL.md
+        ${PROJECT_SOURCE_DIR}/CHANGELOG.md
+        ${PROJECT_SOURCE_DIR}/LICENSE
     )
     if(OCIO_BUILD_NUKE)
-        list(APPEND DOC_SOURCES ${CMAKE_SOURCE_DIR}/share/nuke/ocionuke/viewer.py)
+        list(APPEND DOC_SOURCES ${PROJECT_SOURCE_DIR}/share/nuke/ocionuke/viewer.py)
     endif()
 
+    # Don't copy configured files. In particular this prevents overwriting conf.py,
+    # since it isn't renamed during configuration.
+    list(REMOVE_ITEM DOC_SOURCES ${DOC_IN_FILES})
+
     add_custom_target(doc_copy
         COMMENT "Copying doc files to staging area"
     )
 
     foreach(f ${DOC_SOURCES})
-        string(REGEX REPLACE "^${CMAKE_SOURCE_DIR}/" "" relpath ${f})
+        string(REGEX REPLACE "^${PROJECT_SOURCE_DIR}/" "" relpath ${f})
         string(REGEX REPLACE "[/. ]" "_" tgtname ${relpath})
         string(REGEX MATCH "^docs" IN_DOCS ${relpath})
 
-        set(SRC_PATH ${CMAKE_SOURCE_DIR}/${relpath})
-        set(DST_PATH ${CMAKE_BINARY_DIR}/${relpath})
+        set(SRC_PATH ${PROJECT_SOURCE_DIR}/${relpath})
+        set(DST_PATH ${PROJECT_BINARY_DIR}/${relpath})
         if(NOT IN_DOCS)
             get_filename_component(F_NAME ${relpath} NAME)
-            set(DST_PATH "${CMAKE_BINARY_DIR}/docs/${F_NAME}")
+            set(DST_PATH "${PROJECT_BINARY_DIR}/docs/${F_NAME}")
         endif()
 
         add_custom_command(OUTPUT ${DST_PATH}
@@ -107,43 +112,56 @@ if(${Python_VERSION_MAJOR} GREATER_EQUAL 3)
         add_dependencies(doc_copy "copy_${tgtname}")
     endforeach()
 
-    ###############################################################################
-    ### Extract rst from c++ headers ###
+    ###########################################################################
+    ### Extract XML from C++ headers ###
 
-    set(EXTRACT_COMMAND "${CMAKE_SOURCE_DIR}/share/sphinx/ExtractRstFromSourceCPP.py")
-    set(OCIO_HEADER_DIR "${CMAKE_SOURCE_DIR}/include/OpenColorIO")
-    set(RST_DESTINATION "${CMAKE_BINARY_DIR}/docs/developers/api/")
-    add_custom_target(rst_extraction
-        COMMAND ${CMAKE_COMMAND} -E make_directory ${RST_DESTINATION}
-        COMMAND ${Python_EXECUTABLE} ${EXTRACT_COMMAND} ${OCIO_HEADER_DIR}/OpenColorIO.h ${RST_DESTINATION}/OpenColorIO.rst
-        COMMAND ${Python_EXECUTABLE} ${EXTRACT_COMMAND} ${OCIO_HEADER_DIR}/OpenColorTransforms.h ${RST_DESTINATION}/OpenColorTransforms.rst
-        COMMAND ${Python_EXECUTABLE} ${EXTRACT_COMMAND} ${OCIO_HEADER_DIR}/OpenColorTypes.h ${RST_DESTINATION}/OpenColorTypes.rst
-        COMMENT "Extracting .rst files from C++ headers"
+    get_target_property(DOXYGEN_EXECUTABLE Doxygen::doxygen IMPORTED_LOCATION)
+
+    file(GLOB_RECURSE DOXYGEN_SOURCES 
+        "${PROJECT_SOURCE_DIR}/include/*.h"
+        "${PROJECT_BINARY_DIR}/include/*.h"
+    )
+    set(DOXYGEN_INDEX_XML "${PROJECT_BINARY_DIR}/docs/_doxygen/xml/index.xml")
+
+    # Run doxygen if index.xml is behind OCIO headers or doxygen config
+    add_custom_command(OUTPUT ${DOXYGEN_INDEX_XML}
+        COMMAND "${DOXYGEN_EXECUTABLE}" "${PROJECT_BINARY_DIR}/docs/Doxyfile"
+        DEPENDS
+            ${PROJECT_BINARY_DIR}/docs/Doxyfile
+            ${DOXYGEN_SOURCES}
+        COMMENT "Extracting XML files from C++ headers"
     )
 
-    ###############################################################################
+    add_custom_target(doxygen_extraction
+        DEPENDS ${DOXYGEN_INDEX_XML}
+    )
+
+    ###########################################################################
     ### HTML doc target ###
 
+    file(GLOB_RECURSE SPHINX_EXTENSIONS
+        "${PROJECT_SOURCE_DIR}/share/docs/*.py"
+    )
+
+    # Run Sphinx
     add_custom_target(docs ALL
         COMMAND
-            ${PYT_PRE_CMD} "${Sphinx_EXECUTABLE}" -b html . "${CMAKE_CURRENT_BINARY_DIR}/build-html"
+            ${Python_PRE_CMD} "${Sphinx_EXECUTABLE}" -b html . "${CMAKE_CURRENT_BINARY_DIR}/build-html"
         DEPENDS
-            ${CMAKE_BINARY_DIR}/docs/conf.py
+            ${PROJECT_BINARY_DIR}/docs/conf.py
+            ${SPHINX_EXTENSIONS}
+            ${DOXYGEN_INDEX_XML}
         COMMENT "Building html docs"
     )
 
     add_dependencies(docs
         OpenColorIO
         PyOpenColorIO
-        rst_extraction
         doc_copy
-        Sphinx
-        sphinx-press-theme
-        recommonmark
-        sphinx-tabs
+        doxygen_extraction
     )
 
-    ###############################################################################
+    ###########################################################################
     ### Installation ###
 
     install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/build-html/
@@ -151,48 +169,6 @@ if(${Python_VERSION_MAJOR} GREATER_EQUAL 3)
             PATTERN .* EXCLUDE
     )
 
-    ###############################################################################
-    ### PDF target ###
-
-    find_package(LATEX)
-    package_root_message(LATEX)
-
-    if(PDFLATEX_COMPILER)
-
-        add_custom_target(latex
-            COMMAND
-                ${PYT_PRE_CMD} "${Sphinx_EXECUTABLE}" -b latex . "${CMAKE_CURRENT_BINARY_DIR}/build-latex"
-            DEPENDS
-                ${CMAKE_BINARY_DIR}/docs/conf.py
-            COMMENT "Building latex doc"
-        )
-
-        add_dependencies(latex
-            OpenColorIO
-            PyOpenColorIO
-            rst_extraction
-            doc_copy
-            Sphinx
-            sphinx-press-theme
-            recommonmark
-        )
-
-
-        add_custom_target(pdf ALL
-            COMMAND ${PDFLATEX_COMPILER} OpenColorIO.tex
-            WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/build-latex
-            COMMENT "Building pdf doc"
-        )
-
-        add_dependencies(pdf
-            latex
-        )
-
-        install(FILES ${CMAKE_CURRENT_BINARY_DIR}/build-latex/OpenColorIO.pdf
-                DESTINATION ${CMAKE_INSTALL_PREFIX}/share/doc/OpenColorIO/)
-
-    endif()
-
 else()
     message(Warning "Skipping local documentation generation, requires Python >= 3.x")
 endif()

docs/V2_DOC_README.md

@@ -1,47 +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 RST-Only Docs
-
-In addition to the general OCIO v2 dependencies (Python and Sphinx), install the
-Python packages listed in the `docs/requirements.txt` file.
-
-```
-pip install -r docs/requirements.txt
-```
-
-Build the sphinx docs locally...
-
-```
-cd docs
-mkdir _build
-sphinx-build -b html . _build
-firefox _build/index.html
-```
-
-
-## 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/_index.rst

@@ -8,24 +8,24 @@ API
 .. toctree::
    :caption: API
 
-   installation
-   c_baker
-   c_colorspace
-   c_colorspaceset
-   c_config
-   c_context
-   c_cpuprocessor
-   c_dynamicproperty
-   c_filerules
-   c_formatmetadata
-   c_gpuprocessor
-   c_gpushadercreator
-   c_gpushaderdesc
-   c_imagedesc
-   c_look
-   c_packedimagedesc
-   c_planarimagedesc
-   c_processor
-   c_viewingrules
+   apphelpers
+   baker
+   colorspace
+   config
+   constants
+   context
+   dynamicproperty
+   enums
+   exceptions
+   formatmetadata
+   global
+   grading_transforms
+   imagedesc
+   look
+   namedtransform
+   processors
+   rules
+   shaders
+   systemmonitors
    transforms
-   types
+   viewtransform

docs/api/apphelpers.rst

@@ -0,0 +1,129 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Applications Helpers
+====================
+
+ColorSpaceMenuHelpers
+*********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.ColorSpaceHelpers.AddColorSpace
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceMenuParameters
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: AddedColorSpaceIterator
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceMenuHelper
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: ColorSpaceLevelIterator
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceMenuHelper.ColorSpaceLevelIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ColorSpaceMenuParameters
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const ColorSpaceMenuParameters&)
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ColorSpaceMenuHelper
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const ColorSpaceMenuHelper&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstColorSpaceMenuHelperRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ColorSpaceMenuHelperRcPtr
+
+DisplayViewHelpers
+******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.DisplayViewHelpers.GetProcessor
+      .. autofunction:: PyOpenColorIO.DisplayViewHelpers.GetIdentityProcessor
+      .. autofunction:: PyOpenColorIO.DisplayViewHelpers.AddDisplayView
+      .. autofunction:: PyOpenColorIO.DisplayViewHelpers.RemoveDisplayView
+
+   .. group-tab:: C++
+
+      .. doxygennamespace:: ${OCIO_NAMESPACE}::DisplayViewHelpers
+         :members:
+         :undoc-members:
+
+LegacyViewingPipeline
+*********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.LegacyViewingPipeline
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::LegacyViewingPipeline
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const LegacyViewingPipeline&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstLegacyViewingPipelineRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::LegacyViewingPipelineRcPtr
+
+MixingHelpers
+*************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.MixingSlider
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+      .. autoclass:: PyOpenColorIO.MixingColorSpaceManager
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: MixingSpaceIterator, MixingEncodingIterator
+
+      .. autoclass:: PyOpenColorIO.MixingColorSpaceManager.MixingSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.MixingColorSpaceManager.MixingEncodingIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::MixingSlider
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const MixingSlider&)
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::MixingColorSpaceManager
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const MixingColorSpaceManager&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstMixingColorSpaceManagerRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::MixingColorSpaceManagerRcPtr

docs/api/baker.rst

@@ -0,0 +1,28 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Baker
+=====
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Baker
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: FormatIterator
+
+      .. autoclass:: PyOpenColorIO.Baker.FormatIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Baker
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstBakerRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::BakerRcPtr

docs/api/bindings/PythonAPI.rst

@@ -1,157 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Python API
-==========
-
-Description
-***********
-
-A color configuration (:py:class:`PyOpenColorIO.Config`) defines all the color spaces to be
-available at runtime.
-
-(:py:class:`PyOpenColorIO.Config`)  is the main object for interacting with this library. 
-It encapsulates all the information necessary to use customized
-:py:class:`PyOpenColorIO.ColorSpaceTransform` and
-:py:class:`PyOpenColorIO.DisplayTransform` operations.
-
-See the :ref:`user-guide` for more information on selecting, creating, 
-and working with custom color configurations.
-
-For applications interested in using only one color configuration at
-a time (this is the vast majority of apps), their API would
-traditionally get the global configuration and use that, as
-opposed to creating a new one. This simplifies the use case
-for plugins and bindings, as it alleviates the need to pass
-around configuration handles.
-
-An example of an application where this would not be
-sufficient would be a multi-threaded image proxy server
-(daemon) that wants to handle multiple show configurations
-concurrently in a single process. This app would need to keep
-multiple configurations alive, and manage them appropriately.
-
-Roughly speaking, a novice user should select a default
-configuration that most closely approximates the use case
-(animation, visual effects, etc.), and set the :envvar:`OCIO`
-environment variable to point at the root of that configuration.
-
-.. note::
-   Initialization using environment variables is typically preferable
-   in a multi-app ecosystem, as it allows all applications to be consistently configured.
-
-.. note::
-   Paths to LUTs can be relative. The search paths are defined in :py:class:`PyOpenColorIO.Config`.
-
-See :ref:`developers-usageexamples`
-
-Examples of Use
-+++++++++++++++
-
-.. code-block:: python
-
-    import PyOpenColorIO as OCIO
-    
-    # Load an existing configuration from the environment.
-    # The resulting configuration is read-only. If $OCIO is set, it will use that.
-    # Otherwise it will use an internal default.
-    config = OCIO.GetCurrentConfig()
-    
-    # What color spaces exist?
-    colorSpaceNames = [ cs.getName() for cs in config.getColorSpaces() ]
-    
-    # Given a string, can we parse a color space name from it?
-    inputString = 'myname_linear.exr'
-    colorSpaceName = config.parseColorSpaceFromString(inputString)
-    if colorSpaceName:
-        print 'Found color space', colorSpaceName
-    else:
-        print 'Could not get color space from string', inputString
-    
-    # What is the name of scene-linear in the configuration?
-    colorSpace = config.getColorSpace(OCIO.Constants.ROLE_SCENE_LINEAR)
-    if colorSpace:
-        print colorSpace.getName()
-    else:
-        print 'The role of scene-linear is not defined in the configuration'
-    
-    # For examples of how to actually perform the color transform math,
-    # see 'Python: Processor' docs.
-    
-    # Create a new, empty, editable configuration
-    config = OCIO.Config()
-    
-    # Create a new color space, and add it
-    cs = OCIO.ColorSpace(...)
-    # (See ColorSpace for details)
-    config.addColorSpace(cs)
-    
-    # For additional examples of config manipulation, see
-    # https://github.com/imageworks/OpenColorIO-Configs/blob/master/nuke-default/make.py
-
-Exceptions
-**********
-
-.. autoclass:: PyOpenColorIO.Exception
-    :members:
-    :undoc-members:
-
-.. autoclass:: PyOpenColorIO.ExceptionMissingFile
-    :members:
-    :undoc-members:
-
-Global
-******
-
-.. autofunction:: PyOpenColorIO.ClearAllCaches
-
-.. autofunction:: PyOpenColorIO.GetCurrentConfig
-
-.. autofunction:: PyOpenColorIO.GetLoggingLevel
-
-.. autofunction:: PyOpenColorIO.SetCurrentConfig
-
-.. autofunction:: PyOpenColorIO.SetLoggingLevel
-
-Config
-******
-
-.. autoclass:: PyOpenColorIO.Config
-    :members:
-    :undoc-members:
-
-ColorSpace
-**********
-
-.. autoclass:: PyOpenColorIO.ColorSpace
-    :members:
-    :undoc-members:
-
-Look
-****
-
-.. autoclass:: PyOpenColorIO.Look
-    :members:
-    :undoc-members:
-
-Processor
-*********
-
-.. autoclass:: PyOpenColorIO.Processor
-    :members:
-    :undoc-members:
-
-Context
-*******
-
-.. autoclass:: PyOpenColorIO.Context
-    :members:
-    :undoc-members:
-
-Baker
-*****
-
-.. autoclass:: PyOpenColorIO.Baker
-    :members:
-    :undoc-members:

docs/api/bindings/PythonTransforms.rst

@@ -1,138 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-.. _python-transforms:
-
-Python Transforms
-=================
-
-Transform
-*********
-
-.. autoclass:: PyOpenColorIO.Transform
-    :members:
-    :undoc-members:
-
-AllocationTransform
-*******************
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-    transform = OCIO.AllocationTransform()
-    transform.setAllocation(OCIO.Constants.ALLOCATION_LG2)
-
-.. autoclass:: PyOpenColorIO.AllocationTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-CDLTransform
-************
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-    
-    cdl = OCIO.CDLTransform()
-    # Set the slope, offset, power, and saturation for each channel.
-    cdl.setSOP([, , , , , , , , ])
-    cdl.setSat([, , ])
-    cdl.getSatLumaCoefs()
-
-.. autoclass:: PyOpenColorIO.CDLTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-ColorSpaceTransform
-*******************
-
-This class is meant so that ColorSpace conversions can be reused, referencing ColorSpaces that already exist.
-
-.. note::
-    Careless use of this may create infinite loops, so avoid referencing the colorspace you're in. 
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-    transform = OCIO.ColorSpaceTransform()
-
-.. autoclass:: PyOpenColorIO.ColorSpaceTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-DisplayTransform
-****************
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-    transform = OCIO.DisplayTransform()
-
-.. autoclass:: PyOpenColorIO.DisplayTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-ExponentTransform
-*****************
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-    transform = OCIO.ExponentTransform()
-
-.. autoclass:: PyOpenColorIO.ExponentTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-FileTransform
-*************
-
-.. autoclass:: PyOpenColorIO.FileTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-GroupTransform
-**************
-
-.. autoclass:: PyOpenColorIO.GroupTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-LogTransform
-************
-
-.. code-block:: python
-    
-    import PyOpenColorIO as OCIO
-
-:py:class:`PyOpenColorIO.LogTransform` is used to define a log transform. The direction of
-the transform and its numerical base can be specified.
-
-.. autoclass:: PyOpenColorIO.LogTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-LookTransform
-*************
-
-.. autoclass:: PyOpenColorIO.LookTransform
-    :members:
-    :undoc-members:
-    :inherited-members:
-
-MatrixTransform
-***************
-
-.. autoclass:: PyOpenColorIO.MatrixTransform
-    :members:
-    :undoc-members:
-    :inherited-members:

docs/api/bindings/PythonTypes.rst

@@ -1,13 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Python Types
-============
-
-Constants
-*********
-
-.. automodule:: PyOpenColorIO.Constants
-    :members:
-    :undoc-members:

docs/api/c_baker.rst

@@ -1,197 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Baker
-=====
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class Baker**
-
-In certain situations it is necessary to serialize transforms into
-a variety of application specific LUT formats. Note that not all
-file formats that may be read also support baking.
-
-**Usage Example:** *Bake a CSP sRGB viewer LUT*
-
-::
-
-    OCIO::ConstConfigRcPtr config = OCIO::Config::CreateFromEnv();
-    OCIO::BakerRcPtr baker = OCIO::Baker::Create();
-    baker->setConfig(config);
-    baker->setFormat("csp");
-    baker->setInputSpace("lnf");
-    baker->setShaperSpace("log");
-    baker->setTargetSpace("sRGB");
-    auto & metadata = baker->getFormatMetadata();
-    metadata.addChildElement(OCIO::METADATA_DESCRIPTION, "A first comment");
-    metadata.addChildElement(OCIO::METADATA_DESCRIPTION, "A second comment");
-    std::ostringstream out;
-    baker->bake(out); // fresh bread anyone!
-    std::cout << out.str();
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:function:: BakerRcPtr createEditableCopy() const
-
-            Create a copy of this Baker.
-
-        .. cpp:function:: ConstConfigRcPtr getConfig() const
-
-        .. cpp:function:: void setConfig(const ConstConfigRcPtr &config)
-
-            Set the config to use.
-
-        .. cpp:function:: const char *getFormat() const
-
-        .. cpp:function:: void setFormat(const char *formatName)
-
-            Set the LUT output format.
-
-        .. cpp:function:: const FormatMetadata &getFormatMetadata() const
-
-        .. cpp:function:: FormatMetadata &getFormatMetadata()
-
-            Get editable *optional* format metadata. The metadata that will
-            be used varies based on the capability of the given file format.
-            Formats such as CSP, IridasCube, and ResolveCube will create
-            comments in the file header using the value of any first-level
-            children elements of the formatMetadata. The CLF/CTF formats
-            will make use of the top-level “id” and “name” attributes and
-            children elements “Description”, “InputDescriptor”,
-            “OutputDescriptor”, and “Info”.
-
-        .. cpp:function:: const char *getInputSpace() const
-
-        .. cpp:function:: void setInputSpace(const char *inputSpace)
-
-            Set the input ColorSpace that the LUT will be applied to.
-
-        .. cpp:function:: const char *getShaperSpace() const
-
-        .. cpp:function:: void setShaperSpace(const char *shaperSpace)
-
-            Set an *optional* 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
-            ColorSpace Allocation will be used (not implemented for all
-            formats).
-
-        .. cpp:function:: const char *getLooks() const
-
-        .. cpp:function:: void setLooks(const char *looks)
-
-            Set the looks to be applied during baking. Looks is a
-            potentially comma (or colon) delimited list of lookNames, where
-            +/- prefixes are optionally allowed to denote forward/inverse
-            look specification. (And forward is assumed in the absence of
-            either).
-
-        .. cpp:function:: const char *getTargetSpace() const
-
-        .. cpp:function:: void setTargetSpace(const char *targetSpace)
-
-            Set the target device colorspace for the LUT.
-
-        .. cpp:function:: int getShaperSize() const
-
-        .. cpp:function:: void setShaperSize(int shapersize)
-
-            Override the default shaper LUT size. Default value is -1, which
-            allows each format to use its own most appropriate size. For the
-            CLF format, the default uses a half-domain LUT1D (which is ideal
-            for scene-linear inputs).
-
-        .. cpp:function:: int getCubeSize() const
-
-        .. cpp:function:: void setCubeSize(int cubesize)
-
-            Override the default cube sample size. default: <format specific>
-
-        .. cpp:function:: void bake(std::ostream &os) const
-
-            Bake the LUT into the output stream.
-
-        .. cpp:function:: ~Baker()
-
-        -[ Public Static Functions ]-
-
-        .. cpp:function:: BakerRcPtr Create()
-
-            Create a new Baker.
-
-        .. cpp:function:: int getNumFormats()
-
-            Get the number of LUT bakers.
-
-        .. cpp:function:: const char *getFormatNameByIndex(int index)
-
-            Get the LUT baker format name at index, return empty string if
-            an invalid index is specified.
-
-        .. cpp:function:: const char *getFormatExtensionByIndex(int index)
-
-            Get the LUT baker format extension at index, return empty string
-            if an invalid index is specified.
-
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.Baker
-
-        .. py:class:: FormatIterator
-
-        .. py:method:: bake(*args,**kwargs)
-
-        Overloaded function.
-
-        1. .. py:method:: bake(self: PyOpenColorIO.Baker, fileName: str) -> None
-
-        2. .. py:method:: bake(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: getConfig(self: PyOpenColorIO.Baker) -> PyOpenColorIO.Config
-
-        .. py:method:: getCubeSize(self: PyOpenColorIO.Baker) -> int
-
-        .. py:method:: getFormat(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: getFormatMetadata(*args, **kwargs)**
-
-        Overloaded function.
-
-        1. .. py:method:: getFormatMetadata(self: PyOpenColorIO.Baker) -> PyOpenColorIO.FormatMetadata
-
-        2. .. py:method:: getFormatMetadata(self: PyOpenColorIO.Baker) -> PyOpenColorIO.FormatMetadata
-
-        .. py:method:: getFormats() -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Baker>, 0>
-
-        .. py:method:: getInputSpace(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: getLooks(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: getShaperSize(self: PyOpenColorIO.Baker) -> int
-
-        .. py:method:: getShaperSpace(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: getTargetSpace(self: PyOpenColorIO.Baker) -> str
-
-        .. py:method:: setConfig(self: PyOpenColorIO.Baker, config: PyOpenColorIO.Config) -> None
-
-        .. py:method:: setCubeSize(self: PyOpenColorIO.Baker, cubeSize: int) -> None
-
-        .. py:method:: setFormat(self: PyOpenColorIO.Baker, formatName: str) -> None
-
-        .. py:method:: setInputSpace(self: PyOpenColorIO.Baker, inputSpace: str) -> None
-
-        .. py:method:: setLooks(self: PyOpenColorIO.Baker, looks: str) -> None
-
-        .. py:method:: setShaperSize(self: PyOpenColorIO.Baker, shaperSize: int) -> None
-
-        .. py:method:: setShaperSpace(self: PyOpenColorIO.Baker, shaperSpace: str) -> None
-
-        .. py:method:: setTargetSpace(self: PyOpenColorIO.Baker, targetSpace: str) -> None

docs/api/c_colorspace.rst

@@ -1,199 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-ColorSpace
-**********
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-The *ColorSpace* is the state of an image with respect to colorimetry
-and color encoding. Transforming images between different
-*ColorSpaces* is the primary motivation for this library.
-
-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'.
-
-**class ColorSpace**
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: ColorSpaceRcPtr createEditableCopy() const
-
-      .. cpp:function:: const char *getName() const noexcept
-
-      .. cpp:function:: void setName(const char *name)
-
-      .. cpp:function:: const char *getFamily() const noexcept
-
-         Get the family, for use in user interfaces (optional) The family
-         string could use a ‘/’ separator to indicate levels to be used
-         by hierarchical menus.
-
-      .. cpp:function:: void setFamily(const char *family)
-
-         Set the family, for use in user interfaces (optional)
-
-      .. cpp:function:: const char *getEqualityGroup() const noexcept
-
-         Get the 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’.
-
-      .. cpp:function:: void setEqualityGroup(const char *equalityGroup)
-
-      .. cpp:function:: const char *getDescription() const noexcept
-
-      .. cpp:function:: void setDescription(const char *description)
-
-      .. cpp:function:: BitDepth getBitDepth() const noexcept
-
-      .. cpp:function:: void setBitDepth(BitDepth bitDepth)
-
-      .. cpp:function:: ReferenceSpaceType getReferenceSpaceType() const noexcept
-
-         A display color space will use the display-referred reference
-         space.
-
-      .. cpp:function:: bool hasCategory(const char *category) const
-
-         Return true if the category is present.
-
-      .. cpp:function:: void addCategory(const char *category)
-
-         Add a single category.
-
-         **Note**
-         Will do nothing if the category already exists.
-
-      .. cpp:function:: void removeCategory(const char *category)
-
-         Remove a category.
-
-         **Note**
-         Will do nothing if the category is missing.
-
-      .. cpp:function:: int getNumCategories() const
-
-         Get the number of categories.
-
-      .. cpp:function:: const char *getCategory(int index) const
-
-         Return the category name using its index.
-
-         **Note**
-         Will be null if the index is invalid.
-
-      .. cpp:function:: void clearCategories()
-
-         Clear all the categories.
-
-      .. cpp:function:: const char *getEncoding() const noexcept
-
-      .. cpp:function:: void setEncoding(const char *encoding)
-
-      .. cpp:function:: bool isData() const noexcept
-
-      .. cpp:function:: void setIsData(bool isData) noexcept
-
-      .. cpp:function:: Allocation getAllocation() const noexcept
-
-      .. cpp:function:: void setAllocation(Allocation allocation) noexcept
-
-      .. cpp:function:: int getAllocationNumVars() const
-
-      .. cpp:function:: void getAllocationVars(float *vars) const
-
-      .. cpp:function:: void setAllocationVars(int numvars, const float *vars)
-
-      .. cpp:function:: ConstTransformRcPtr getTransform(ColorSpaceDirection dir) const
-
-         If a transform in the specified direction has been specified,
-         return it. Otherwise return a null ConstTransformRcPtr
-
-      .. cpp:function:: void setTransform(const ConstTransformRcPtr &transform, ColorSpaceDirection dir)
-
-         Specify the transform for the appropriate direction. Setting the
-         transform to null will clear it.
-
-      .. cpp:function:: ColorSpace(const ColorSpace&) = delete
-
-      .. cpp:function:: ColorSpace &operator=(const ColorSpace&) = delete
-
-      .. cpp:function:: ~ColorSpace()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: ColorSpaceRcPtr Create()
-
-      .. cpp:function:: ColorSpaceRcPtr Create(ReferenceSpaceType referenceSpace)
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.ColorSpace
-
-      .. py:class:: ColorSpaceCategoryIterator
-
-      .. py:method:: addCategory(self: PyOpenColorIO.ColorSpace, category: str) -> None
-
-      .. py:method:: clearCategories(self: PyOpenColorIO.ColorSpace) -> None
-
-      .. py:method:: getAllocation(self: PyOpenColorIO.ColorSpace) -> PyOpenColorIO.Allocation
-
-      .. py:method:: getAllocationVars(self: PyOpenColorIO.ColorSpace) -> List[float]
-
-      .. py:method:: getBitDepth(self: PyOpenColorIO.ColorSpace) -> PyOpenColorIO.BitDepth
-
-      .. py:method:: getCategories(self: PyOpenColorIO.ColorSpace) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ColorSpace>, 0>
-
-      .. py:method:: getDescription(self: PyOpenColorIO.ColorSpace) -> str
-
-      .. py:method:: getEncoding(self: PyOpenColorIO.ColorSpace) -> str
-
-      .. py:method:: getEqualityGroup(self: PyOpenColorIO.ColorSpace) -> str
-
-      .. py:method:: getFamily(self: PyOpenColorIO.ColorSpace) -> str
-
-      .. py:method:: getName(self: PyOpenColorIO.ColorSpace) -> str
-
-      .. py:method:: getReferenceSpaceType(self: PyOpenColorIO.ColorSpace) -> PyOpenColorIO.ReferenceSpaceType
-
-      .. py:method:: getTransform(self: PyOpenColorIO.ColorSpace, direction: PyOpenColorIO.ColorSpaceDirection) -> PyOpenColorIO.Transform
-
-      .. py:method:: hasCategory(self: PyOpenColorIO.ColorSpace, category: str) -> bool
-
-      .. py:method:: isData(self: PyOpenColorIO.ColorSpace) -> bool
-
-      .. py:method:: removeCategory(self: PyOpenColorIO.ColorSpace, category: str) -> None
-
-      .. py:method:: setAllocation(self: PyOpenColorIO.ColorSpace, allocation: PyOpenColorIO.Allocation) -> None
-
-      .. py:method:: setAllocationVars(self: PyOpenColorIO.ColorSpace, vars: List[float]) -> None
-
-      .. py:method:: setBitDepth(self: PyOpenColorIO.ColorSpace, bitDepth: PyOpenColorIO.BitDepth) -> None
-
-      .. py:method:: setDescription(self: PyOpenColorIO.ColorSpace, description: str) -> None
-
-      .. py:method:: setEncoding(self: PyOpenColorIO.ColorSpace, encoding: str) -> None
-
-      .. py:method:: setEqualityGroup(self: PyOpenColorIO.ColorSpace, equalityGroup: str) -> None
-
-      .. py:method:: setFamily(self: PyOpenColorIO.ColorSpace, family: str) -> None
-
-      .. py:method:: setIsData(self: PyOpenColorIO.ColorSpace, isData: bool) -> None
-
-      .. py:method:: setName(self: PyOpenColorIO.ColorSpace, name: str) -> None
-
-      .. py:method:: setTransform(self: PyOpenColorIO.ColorSpace, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.ColorSpaceDirection) -> None

docs/api/c_colorspaceset.rst

@@ -1,141 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-ColorSpaceSet
-*************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class ColorSpaceSet**
-
-The *ColorSpaceSet* is a set of color spaces (i.e. no color space
-duplication) which could be the result of
-:cpp:func:```Config::getColorSpaces`_`` or built from scratch.
-
-**Note**
-The color spaces are decoupled from the config ones, i.e., any
-changes to the set itself or to its color spaces do not affect
-the original color spaces from the configuration. If needed, use
-:cpp:func:```Config::addColorSpace`_`` to update the
-configuration.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: ColorSpaceSetRcPtr createEditableCopy() const
-
-         Create a set containing a copy of all the color spaces.
-
-      .. cpp:function:: bool operator==(const ColorSpaceSet &css) const
-
-         Return true if the two sets are equal.
-
-         **Note**
-         The comparison is done on the color space names (not a deep comparison).
-
-      .. cpp:function:: bool operator!=(const ColorSpaceSet &css) const
-
-         Return true if the two sets are different.
-
-      .. cpp:function:: int getNumColorSpaces() const
-
-         Return the number of color spaces.
-
-      .. cpp:function:: const char *getColorSpaceNameByIndex(int index) const
-
-         Return the color space name using its index. This will be null
-         if an invalid index is specified.
-
-      .. cpp:function:: ConstColorSpaceRcPtr getColorSpaceByIndex(int index) const
-
-         Return the color space using its index. This will be empty if an
-         invalid index is specified.
-
-      .. cpp:function:: ConstColorSpaceRcPtr getColorSpace(const char *name) const
-
-         Will return null if the name is not found.
-
-         **Note**
-         Only accepts color space names (i.e. no role name).
-
-      .. cpp:function:: int getColorSpaceIndex(const char *name) const
-
-         Will return -1 if the name is not found.
-
-         **Note**
-         Only accepts color space names (i.e. no role name).
-
-      .. cpp:function:: bool hasColorSpace(const char *name) const
-
-         **Note**
-         Only accepts color space names (i.e. no role name)
-
-         **Return**
-         true
-
-         **Return**
-         false
-
-         **Parameters**
-         * ``name``:
-
-      .. cpp:function:: void addColorSpace(const ConstColorSpaceRcPtr &cs)
-
-         Add color space(s).
-
-         **Note**
-         If another color space is already registered with the same
-         name, this will overwrite it. This stores a copy of the
-         specified color space(s).
-
-      .. cpp:function:: void addColorSpaces(const ConstColorSpaceSetRcPtr &cs)
-
-      .. cpp:function:: void removeColorSpace(const char *name)
-
-         Remove color space(s) using color space names (i.e. no role
-         name).
-
-         **Note**
-         The removal of a missing color space does nothing.
-
-      .. cpp:function:: void removeColorSpaces(const ConstColorSpaceSetRcPtr &cs)
-
-      .. cpp:function:: void clearColorSpaces()
-
-         Clear all color spaces.
-
-      .. cpp:function:: ~ColorSpaceSet()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: ColorSpaceSetRcPtr Create()
-
-         Create an empty set of color spaces.
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.ColorSpaceSet
-
-      .. py:class:: ColorSpaceIterator
-
-      .. py:class:: ColorSpaceNameIterator
-
-      .. py:method:: addColorSpace(self: PyOpenColorIO.ColorSpaceSet, colorSpace: PyOpenColorIO.ColorSpace) -> None
-
-      .. py:method:: addColorSpaces(self: PyOpenColorIO.ColorSpaceSet, colorSpace: PyOpenColorIO.ColorSpaceSet) -> None
-
-      .. py:method:: clearColorSpaces(self: PyOpenColorIO.ColorSpaceSet) -> None
-
-      .. py:method:: getColorSpace(self: PyOpenColorIO.ColorSpaceSet, name: str) -> PyOpenColorIO.ColorSpace
-
-      .. py:method:: getColorSpaceNames(self: PyOpenColorIO.ColorSpaceSet) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ColorSpaceSet>, 0>
-
-      .. py:method:: getColorSpaces(self: PyOpenColorIO.ColorSpaceSet) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ColorSpaceSet>, 1>
-
-      .. py:method:: removeColorSpace(self: PyOpenColorIO.ColorSpaceSet, colorSpace: str) -> None
-
-      .. py:method:: removeColorSpaces(self: PyOpenColorIO.ColorSpaceSet, colorSpace: PyOpenColorIO.ColorSpaceSet) -> None

docs/api/c_config.rst

@@ -1,975 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Config
-******
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-A config defines all the color spaces to be available at runtime.
-
-The color configuration (:cpp:class:`Config`) is the main object for
-interacting with this library. It encapsulates all of the information
-necessary to use customized :cpp:class:`ColorSpaceTransform` and
-:cpp:class:`DisplayViewTransform` operations.
-
-See the :ref:`user-guide` for more information on
-selecting, creating, and working with custom color configurations.
-
-For applications interested in using only one color config at
-a time (this is the vast majority of apps), their API would
-traditionally get the global configuration and use that, as opposed to
-creating a new one. This simplifies the use case for
-plugins and bindings, as it alleviates the need to pass around configuration
-handles.
-
-An example of an application where this would not be sufficient would be
-a multi-threaded image proxy server (daemon), which wished to handle
-multiple show configurations in a single process concurrently. This
-app would need to keep multiple configurations alive, and to manage them
-appropriately.
-
-Roughly speaking, a novice user should select a
-default configuration that most closely approximates the use case
-(animation, visual effects, etc.), and set the :envvar:`OCIO` environment
-variable to point at the root of that configuration.
-
-.. NOTE::
-    Initialization using environment variables is typically preferable in
-    a multi-app ecosystem, as it allows all applications to be
-    consistently configured.
-
-
-**class Config**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: ConfigRcPtr createEditableCopy() const
-
-      .. cpp:function:: unsigned int getMajorVersion() const
-
-         Get the configuration major version.
-
-      .. cpp:function:: void setMajorVersion(unsigned int major)
-
-         Set the configuration major version.
-
-      .. cpp:function:: unsigned int getMinorVersion() const
-
-         Get the configuration minor version.
-
-      .. cpp:function:: void setMinorVersion(unsigned int minor)
-
-         Set the configuration minor version.
-
-      .. cpp:function:: void upgradeToLatestVersion()
-
-         Allows an older config to be serialized as the current
-         version.
-
-      .. cpp:function:: void sanityCheck() const
-
-         Performs a thorough sanity check for the most common user
-         errors.
-
-         This will throw an exception if the config is malformed. The
-         most common error occurs when references are made to
-         colorspaces that do not exist.
-
-      .. cpp:function:: char getFamilySeparator() const
-
-         If not empty or null a single character to separate the
-         family string in levels.
-
-      .. cpp:function:: void setFamilySeparator(char separator)
-
-         Succeeds if the characters is null or a valid character from
-         the ASCII table i.e. from value 32 (i.e. space) to 126 (i.e.
-         ‘~’); otherwise, it throws an exception.
-
-      .. cpp:function:: const char *getDescription() const
-
-      .. cpp:function:: void setDescription(const char *description)
-
-      .. cpp:function:: void serialize(std::ostream &os) const
-
-         Returns the string representation of the Config in YAML text
-         form.
-
-         This is typically stored on disk in a file with the extension
-         .ocio.
-
-      .. cpp:function:: const char *getCacheID() const
-
-         This will produce a hash of the all colorspace definitions,
-         etc. All external references, such as files used in
-         FileTransforms, etc., will be incorporated into the cacheID.
-         While the contents of the files are not read, the file system
-         is queried for relevant information (mtime, inode) so that
-         the config’s cacheID will change when the underlying luts are
-         updated. If a context is not provided, the current Context
-         will be used. If a null context is provided, file references
-         will not be taken into account (this is essentially a hash of
-         `Config::serialize`_).
-
-      .. cpp:function:: const char *getCacheID(const ConstContextRcPtr &context) const
-      
-
-      .. cpp:function:: ConstContextRcPtr getCurrentContext() const
-
-      .. cpp:function:: void addEnvironmentVar(const char *name, const char *defaultValue)
-
-      .. cpp:function:: int getNumEnvironmentVars() const
-
-      .. cpp:function:: const char *getEnvironmentVarNameByIndex(int index) const
-
-      .. cpp:function:: const char *getEnvironmentVarDefault(const char *name) const
-      
-
-      .. cpp:function:: void clearEnvironmentVars()
-
-      .. cpp:function:: void setEnvironmentMode(EnvironmentMode mode)
-
-      .. cpp:function:: EnvironmentMode getEnvironmentMode() const
-
-      .. cpp:function:: void loadEnvironment()
-
-      .. cpp:function:: const char *getSearchPath() const
-
-      .. cpp:function:: void setSearchPath(const char *path)
-
-         Set all search paths as a concatenated string, ‘:’ to
-         separate the paths.
-
-         See `addSearchPath`_ for a more robust and platform-agnostic
-         method of setting the search paths.
-
-      .. cpp:function:: int getNumSearchPaths() const
-
-      .. cpp:function:: const char *getSearchPath(int index) const
-
-         Get a search path from the list.
-
-         The paths are in the order they will be searched (that is,
-         highest to lowest priority).
-
-      .. cpp:function:: void clearSearchPaths()
-
-      .. cpp:function:: void addSearchPath(const char *path)
-
-         Add a single search path to the end of the list.
-
-         Paths may be either absolute or relative. Relative paths are
-         relative to the working directory. Forward slashes will be
-         normalized to reverse for Windows. Environment (context)
-         variables may be used in paths.
-
-      .. cpp:function:: const char *getWorkingDir() const
-
-      .. cpp:function:: void setWorkingDir(const char *dirname)
-
-         The working directory defaults to the location of the config
-         file. It is used to convert any relative paths to absolute.
-         If no search paths have been set, the working directory will
-         be used as the fallback search path. No environment (context)
-         variables may be used in the working directory.
-
-      .. cpp:function:: ColorSpaceSetRcPtr getColorSpaces(const char *category) const
-      
-
-         Get all active color spaces having a specific category in the
-         order they appear in the config file.
-
-         **Note**
-         If the category is null or empty, the method returns all
-         the active color spaces like
-         :cpp:func:```Config::getNumColorSpaces`_`` and
-         :cpp:func:```Config::getColorSpaceNameByIndex`_`` do.
-
-         **Note**
-         It’s worth noticing that the method returns a copy of the
-         selected color spaces decoupling the result from the
-         config. Hence, any changes on the config do not affect the
-         existing color space sets, and vice-versa.
-
-      .. cpp:function:: int getNumColorSpaces(SearchReferenceSpaceType searchReferenceType, ColorSpaceVisibility visibility) const
-
-         Work on the color spaces selected by the reference color
-         space type and visibility.
-
-      .. cpp:function:: const char *getColorSpaceNameByIndex(SearchReferenceSpaceType searchReferenceType, ColorSpaceVisibility visibility, int index) const
-
-         Work on the color spaces selected by the reference color
-         space type and visibility (active or inactive).
-
-         Return empty for invalid index.
-
-      .. cpp:function:: ConstColorSpaceRcPtr getColorSpace(const char *name) const
-
-         Get the color space from all the color spaces (i.e. active
-         and inactive) and return null if the name is not found.
-
-         **Note**
-         The fcn accepts either a color space OR role name. (Color
-         space names take precedence over roles.)
-
-      .. cpp:function:: int getNumColorSpaces() const
-
-         Work on the active color spaces only.
-
-         **Note**
-         Only works from the list of active color spaces.
-
-      .. cpp:function:: const char *getColorSpaceNameByIndex(int index) const
-
-         Work on the active color spaces only and return null for
-         invalid index.
-
-         **Note**
-         Only works from the list of active color spaces.
-
-      .. cpp:function:: int getIndexForColorSpace(const char *name) const
-
-         Get an index from the active color spaces only and return -1
-         if the name is not found.
-
-         **Note**
-         The fcn accepts either a color space OR role name. (Color
-         space names take precedence over roles.)
-
-      .. cpp:function:: void addColorSpace(const ConstColorSpaceRcPtr &cs)
-
-         Add a color space to the configuration.
-
-         **Note**
-         If another color space is already present with the same
-         name, this will overwrite it. This stores a copy of the
-         specified color space.
-
-         **Note**
-         Adding a color space to a Config does not affect any
-         ColorSpaceSet sets that have already been created.
-
-      .. cpp:function:: void removeColorSpace(const char *name)
-
-         Remove a color space from the configuration.
-
-         **Note**
-         It does not throw an exception if the color space is not
-         present or used by an existing role. Role name arguments
-         are ignored.
-
-         **Note**
-         Removing a color space to a Config does not affect any
-         ColorSpaceSet sets that have already been created.
-
-      .. cpp:function:: bool isColorSpaceUsed(const char *name) const noexcept
-
-         Return true if the color space is used by a transform, a
-         role, or a look.
-
-      .. cpp:function:: void clearColorSpaces()
-
-         Remove all the color spaces from the configuration.
-
-         **Note**
-         Removing color spaces from a Config does not affect any
-         ColorSpaceSet sets that have already been created.
-
-      .. cpp:function:: const char *parseColorSpaceFromString(const char *str) const
-      
-
-         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).
-
-         * If the default role is not defined, return an empty
-         string.
-
-      .. cpp:function:: bool isStrictParsingEnabled() const
-
-      .. cpp:function:: void setStrictParsingEnabled(bool enabled)
-
-      .. cpp:function:: void setInactiveColorSpaces(const char *inactiveColorSpaces)
-      
-
-         Set/get a list of inactive color space names.
-
-         * The inactive spaces are color spaces that should not
-         appear in application menus.
-
-         * These color spaces will still work in
-         :cpp:func:``Config::getProcessor`` calls.
-
-         * The argument is a comma-delimited string. A null or empty
-         string empties the list.
-
-         * The environment variable OCIO_INACTIVE_COLORSPACES may
-         also be used to set the inactive color space list.
-
-         * The env. var. takes precedence over the
-         inactive_colorspaces list in the config file.
-
-         * Setting the list via the API takes precedence over either
-         the env. var. or the config file list.
-
-         * Roles may not be used.
-
-      .. cpp:function:: const char *getInactiveColorSpaces() const
-
-      .. cpp:function:: void setRole(const char *role, const char *colorSpaceName)
-
-         **Note**
-         Setting the ``colorSpaceName`` name to a null string
-         unsets it.
-
-      .. cpp:function:: int getNumRoles() const
-
-      .. cpp:function:: bool hasRole(const char *role) const
-
-         Return true if the role has been defined.
-
-      .. cpp:function:: const char *getRoleName(int index) const
-
-         Get the role name at index, this will return values like
-         ‘scene_linear’, ‘compositing_log’.
-
-         Return empty string if index is out of range.
-
-      .. cpp:function:: const char *getRoleColorSpace(int index) const
-
-         Get the role color space at index.
-
-         Return empty string if index is out of range.
-
-      .. cpp:function:: void addSharedView(const char *view, const char *viewTransformName, const char *colorSpaceName, const char *looks, const char *ruleName, const char *description)
-
-         Will throw if view or colorSpaceName are null or empty.
-
-      .. cpp:function:: void removeSharedView(const char *view)
-
-         Remove a shared view. Will throw if the view does not exist.
-
-      .. cpp:function:: const char *getDefaultDisplay() const
-
-      .. cpp:function:: int getNumDisplays() const
-
-      .. cpp:function:: const char *getDisplay(int index) const
-
-         Will return “” if the index is invalid.
-
-      .. cpp:function:: const char *getDefaultView(const char *display) const
-
-      .. cpp:function:: int getNumViews(const char *display) const
-
-         Return the number of views attached to the display including
-         the number of shared views if any. Return 0 if display does
-         not exist.
-
-      .. cpp:function:: const char *getView(const char *display, int index) const
-
-      .. cpp:function:: int getNumViews(const char *display, const char *colorspaceName) const
-
-         If the config has ViewingRules, get the number of active
-         Views for this colorspace. (If there are no rules, it returns
-         all of them.)
-
-      .. cpp:function:: const char *getView(const char *display, const char *colorspaceName, int index) const
-
-      .. cpp:function:: const char *getDisplayViewTransformName(const char *display, const char *view) const
-
-         Returns the view_transform attribute of the (display, view)
-         pair. View can be a shared view of the display. If display is
-         null or empty, config shared views are used.
-
-      .. cpp:function:: const char *getDisplayViewColorSpaceName(const char *display, const char *view) const
-
-         Returns the colorspace attribute of the (display, view) pair.
-         (Note that this may be either a color space or a display
-         color space.)
-
-      .. cpp:function:: const char *getDisplayViewLooks(const char *display, const char *view) const
-
-         Returns the looks attribute of a (display, view) pair.
-
-      .. cpp:function:: const char *getDisplayViewRule(const char *display, const char *view) const noexcept
-
-         Returns the rule attribute of a (display, view) pair.
-
-      .. cpp:function:: const char *getDisplayViewDescription(const char *display, const char *view) const noexcept
-
-         Returns the description attribute of a (display, view) pair.
-
-      .. cpp:function:: void addDisplayView(const char *display, const char *view, const char *colorSpaceName, const char *looks)
-
-         For the (display, view) pair, specify which color space and
-         look to use. If a look is not desired, then just pass a null
-         or empty string.
-
-      .. cpp:function:: void addDisplayView(const char *display, const char *view, const char *viewTransformName, const char *colorSpaceName, const char *looks, const char *ruleName, const char *description)
-
-         For the (display, view) pair, specify the color space or
-         alternatively specify the view transform and display color
-         space. The looks, viewing rule, and description are optional.
-         Pass a null or empty string for any optional arguments. If
-         the view already exists, it is replaced.
-
-         Will throw if:
-
-         * Display, view or colorSpace are null or empty.
-
-         * Display already has a shared view with the same name.
-
-      .. cpp:function:: void addDisplaySharedView(const char *display, const char *sharedView)
-
-         Add a (reference to a) shared view to a display.
-
-         The shared view must be part of the config. See
-         `Config::addSharedView`_
-
-         This will throw if:
-
-         * Display or view are null or empty.
-
-         * Display already has a view (shared or not) with the same
-         name.
-
-      .. cpp:function:: void removeDisplayView(const char *display, const char *view)
-      
-
-         Remove the view and the display if no more views.
-
-         It does not remove the associated color space. If the view
-         name is a shared view, it only removes the reference to the
-         view from the display but the shared view, remains in the
-         config.
-
-         Will throw if the view does not exist.
-
-      .. cpp:function:: void clearDisplays()
-
-      .. cpp:function:: void setActiveDisplays(const char *displays)
-
-         $OCIO_ACTIVE_DISPLAYS envvar can, at runtime, optionally
-         override the allowed displays. It is a comma or colon
-         delimited list. Active displays that are not in the specified
-         profile will be ignored, and the left-most defined display
-         will be the default.
-
-         Comma-delimited list of names to filter and order the active
-         displays.
-
-         **Note**
-         The setter does not override the envvar. The getter does
-         not take into account the envvar value and thus may not
-         represent what the user is seeing.
-
-      .. cpp:function:: const char *getActiveDisplays() const
-
-      .. cpp:function:: void setActiveViews(const char *views)
-
-         $OCIO_ACTIVE_VIEWS envvar can, at runtime, optionally
-         override the allowed views. It is a comma or colon delimited
-         list. Active views that are not in the specified profile will
-         be ignored, and the left-most defined view will be the
-         default.
-
-         Comma-delimited list of names to filter and order the active
-         views.
-
-         **Note**
-         The setter does not override the envvar. The getter does
-         not take into account the envvar value and thus may not
-         represent what the user is seeing.
-
-      .. cpp:function:: const char *getActiveViews() const
-
-      .. cpp:function:: int getNumDisplaysAll() const
-
-         Get all displays in the config, ignoring the active_displays
-         list.
-
-      .. cpp:function:: const char *getDisplayAll(int index) const
-
-      .. cpp:function:: int getNumViews(ViewType type, const char *display) const
-
-         Get either the shared or display-defined views for a display.
-         The active_views list is ignored. Passing a null or empty
-         display (with type=VIEW_SHARED) returns the contents of the
-         shared_views section of the config. Return 0 if display does
-         not exist.
-
-      .. cpp:function:: const char *getView(ViewType type, const char *display, int index) const**
-
-      .. cpp:function:: ConstViewingRulesRcPtr getViewingRules() const noexcept
-
-         Get read-only version of the viewing rules.
-
-      .. cpp:function:: void setViewingRules(ConstViewingRulesRcPtr viewingRules)
-
-         Set viewing rules.
-
-         **Note**
-         The argument is cloned.
-
-      .. cpp:function:: void getDefaultLumaCoefs(double *rgb) const
-
-         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 :cpp:class:``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.
-
-      .. cpp:function:: void setDefaultLumaCoefs(const double *rgb)
-
-         These should be normalized (sum to 1.0 exactly).
-
-      .. cpp:function:: ConstLookRcPtr getLook(const char *name) const
-
-      .. cpp:function:: int getNumLooks() const
-
-      .. cpp:function:: const char *getLookNameByIndex(int index) const
-
-      .. cpp:function:: void addLook(const ConstLookRcPtr &look)
-
-      .. cpp:function:: void clearLooks()
-
-      .. cpp:function:: int getNumViewTransforms() const noexcept
-
-      .. cpp:function:: ConstViewTransformRcPtr getViewTransform(const char *name) const noexcept
-
-      .. cpp:function:: const char *getViewTransformNameByIndex(int i) const noexcept
-      
-
-      .. cpp:function:: void addViewTransform(const ConstViewTransformRcPtr &viewTransform)
-
-      .. cpp:function:: ConstViewTransformRcPtr getDefaultSceneToDisplayViewTransform() const
-
-         The default transform to use for scene-referred to
-         display-referred reference space conversions is the first
-         scene-referred view transform listed in that section of the
-         config (the one with the lowest index). Returns a null
-         ConstTransformRcPtr if there isn’t one.
-
-      .. cpp:function:: void clearViewTransforms()
-
-      .. cpp:function:: ConstFileRulesRcPtr getFileRules() const noexcept
-
-         Get read-only version of the file rules.
-
-      .. cpp:function:: void setFileRules(ConstFileRulesRcPtr fileRules)
-
-         Set file rules.
-
-         **Note**
-         The argument is cloned.
-
-      .. cpp:function:: const char *getColorSpaceFromFilepath(const char *filePath) const
-
-         Get the color space of the first rule that matched filePath.
-
-      .. cpp:function:: const char *getColorSpaceFromFilepath(const char *filePath, size_t &ruleIndex) const
-
-         Most applications will use the preceding method, but this
-         method may be used for applications that want to know which
-         was the highest priority rule to match filePath. The
-         :cpp:func:```FileRules::getNumCustomKeys`_`` and custom keys
-         methods may then be used to get additional information about
-         the matching rule.
-
-      .. cpp:function:: bool filepathOnlyMatchesDefaultRule(const char *filePath) const
-
-         Returns true if the only rule matched by filePath is the
-         default rule. This is a convenience method for applications
-         that want to require the user to manually choose a color
-         space when strictParsing is true and no other rules match.
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstContextRcPtr &context, const ConstColorSpaceRcPtr &srcColorSpace, const ConstColorSpaceRcPtr &dstColorSpace) const
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstColorSpaceRcPtr &srcColorSpace, const ConstColorSpaceRcPtr &dstColorSpace) const
-      
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const char *srcColorSpaceName, const char *dstColorSpaceName) const
-
-         **Note**
-         Names can be colorspace name, role name, or a combination
-         of both.
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstContextRcPtr &context, const char *srcColorSpaceName, const char *dstColorSpaceName) const
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const char *srcColorSpaceName, const char *display, const char *view) const
-      
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstContextRcPtr &context, const char *srcColorSpaceName, const char *display, const char *view) const
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstTransformRcPtr &transform) const
-
-         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).
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstTransformRcPtr &transform, TransformDirection direction) const
-
-      .. cpp:function:: ConstProcessorRcPtr getProcessor(const ConstContextRcPtr &context, const ConstTransformRcPtr &transform, TransformDirection direction) const
-
-      .. cpp:function:: Config(const Config&) = delete
-
-      .. cpp:function:: `Config`_ &operator=(const Config&) = delete
-
-      .. cpp:function:: ~Config()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: ConfigRcPtr Create()
-
-         Create a default empty configuration.
-
-      .. cpp:function:: ConstConfigRcPtr CreateRaw()
-
-         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.
-
-      .. cpp:function:: ConstConfigRcPtr CreateFromEnv()
-
-         Create a configuration using the OCIO environment variable.
-
-         If the variable is missing or empty, returns the same result
-         as `Config::CreateRaw`_ .
-
-      .. cpp:function:: ConstConfigRcPtr CreateFromFile(const char *filename)
-
-         Create a configuration using a specific config file.
-
-      .. cpp:function:: ConstConfigRcPtr CreateFromStream(std::istream &istream)
-
-         Create a configuration using a stream.
-
-      .. cpp:function:: ConstProcessorRcPtr GetProcessorFromConfigs(const ConstConfigRcPtr &srcConfig, const char *srcColorSpaceName, const ConstConfigRcPtr &dstConfig, const char *dstColorSpaceName)
-
-         Get a processor to convert between color spaces in two
-         separate configs.
-
-         This relies on both configs having the aces_interchange role
-         (when srcName is scene-referred) or the role
-         cie_xyz_d65_interchange (when srcName is display-referred)
-         defined. An exception is thrown if that is not the case.
-
-      .. cpp:function:: ConstProcessorRcPtr GetProcessorFromConfigs(const ConstContextRcPtr &srcContext, const ConstConfigRcPtr &srcConfig, const char *srcColorSpaceName, const ConstContextRcPtr &dstContext, const ConstConfigRcPtr &dstConfig, const char *dstColorSpaceName)
-
-      .. cpp:function:: ConstProcessorRcPtr GetProcessorFromConfigs(const ConstConfigRcPtr &srcConfig, const char *srcColorSpaceName, const char *srcInterchangeName, const ConstConfigRcPtr &dstConfig, const char *dstColorSpaceName, const char *dstInterchangeName)
-
-         The srcInterchangeName and dstInterchangeName must refer to a
-         pair of color spaces in the two configs that are the same. A
-         role name may also be used.
-
-      .. cpp:function:: ConstProcessorRcPtr GetProcessorFromConfigs(const ConstContextRcPtr &srcContext, const ConstConfigRcPtr &srcConfig, const char *srcColorSpaceName, const char *srcInterchangeName, const ConstContextRcPtr &dstContext, const ConstConfigRcPtr &dstConfig, const char *dstColorSpaceName, const char *dstInterchangeName)
-
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.Config
-
-      .. py:class:: ActiveColorSpaceIterator
-
-      .. py:class:: ActiveColorSpaceNameIterator
-
-      .. py:class:: ColorSpaceIterator
-
-      .. py:class:: ColorSpaceNameIterator
-
-      .. py:function:: CreateFromEnv() -> PyOpenColorIO.Config
-
-      .. py:function:: CreateFromFile(fileName: str) -> PyOpenColorIO.Config
-
-      .. py:function:: CreateFromStream(str: str) -> PyOpenColorIO.Config
-
-      .. py:function:: CreateRaw() -> PyOpenColorIO.Config
-
-      .. py:class:: DisplayIterator
-
-      .. py:class:: EnvironmentVarNameIterator
-
-      .. py:function:: GetProcessorFromConfigs(*args,**kwargs)
-
-      Overloaded function.
-
-         1. .. py:function:: GetProcessorFromConfigs(srcConfig: PyOpenColorIO.Config, srcColorSpaceName: str, dstConfig: PyOpenColorIO.Config, dstColorSpaceName: str) -> OpenColorIO_v2_0dev::Processor
-
-         2. .. py:function:: GetProcessorFromConfigs(srcContext: OpenColorIO_v2_0dev::Context, srcConfig: PyOpenColorIO.Config, srcColorSpaceName: str, dstContext: OpenColorIO_v2_0dev::Context, dstConfig: PyOpenColorIO.Config, dstColorSpaceName: str) -> OpenColorIO_v2_0dev::Processor
-
-         3. .. py:function:: GetProcessorFromConfigs(srcConfig: PyOpenColorIO.Config, srcColorSpaceName: str, srcInterchangeName: str, dstConfig: PyOpenColorIO.Config, dstColorSpaceName: str, dstInterchangeName: str) -> OpenColorIO_v2_0dev::Processor
-
-         4. .. py:function:: GetProcessorFromConfigs(srcContext: OpenColorIO_v2_0dev::Context, srcConfig: PyOpenColorIO.Config, srcColorSpaceName: str, srcInterchangeName: str, dstContext: OpenColorIO_v2_0dev::Context, dstConfig: PyOpenColorIO.Config, dstColorSpaceName: str, dstInterchangeName: str) -> OpenColorIO_v2_0dev::Processor
-
-      .. py:class:: LookIterator
-
-      .. py:class:: LookNameIterator
-
-      .. py:class:: RoleColorSpaceIterator
-
-      .. py:class:: RoleNameIterator
-
-      .. py:class:: SearchPathIterator
-
-      .. py:class:: SharedViewIterator
-
-      .. py:class:: ViewForColorSpaceIterator
-
-      .. py:class:: ViewIterator
-
-      .. py:class:: ViewTransformIterator
-
-      .. py:class:: ViewTransformNameIterator
-
-      .. py:method:: addColorSpace(self: PyOpenColorIO.Config, colorSpace: OpenColorIO_v2_0dev::ColorSpace) -> None
-
-      .. py:method:: addDisplaySharedView(self: PyOpenColorIO.Config, display: str, view: str) -> None
-
-      .. py:function:: addDisplayView(*args,**kwargs)
-
-      Overloaded function.
-
-         1. addDisplayView(self: PyOpenColorIO.Config, display: str,
-         view: str, colorSpaceName: str, looks: str) -> None
-
-         2. addDisplayView(self: PyOpenColorIO.Config, display: str,
-         view: str, viewTransform: str, displayColorSpaceName:
-         str, looks: str, ruleName: str, description: str) -> None
-
-      .. py:method:: addEnvironmentVar(self: PyOpenColorIO.Config, name: str, defaultValue: str) -> None
-
-      .. py:method:: addLook(self: PyOpenColorIO.Config, look: OpenColorIO_v2_0dev::Look) -> None
-
-      .. py:method:: addSearchPath(self: PyOpenColorIO.Config, path: str) -> None
-
-      .. py:method:: addSharedView(self: PyOpenColorIO.Config, view: str, viewTransformName: str, colorSpaceName: str, looks: str, ruleName: str, description: str) -> None
-
-      .. py:method:: addViewTransform(self: PyOpenColorIO.Config, viewTransform: OpenColorIO_v2_0dev::ViewTransform) -> None
-
-      .. py:method:: clearColorSpaces(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: clearDisplays(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: clearEnvironmentVars(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: clearLooks(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: clearSearchPaths(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: clearViewTransforms(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: filepathOnlyMatchesDefaultRule(self: PyOpenColorIO.Config, filePath: str) -> bool
-
-      .. py:method:: getActiveDisplays(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getActiveViews(self: PyOpenColorIO.Config) -> str
-
-      .. py:function:: getCacheID(*args,**kwargs)
-
-         Overloaded function.
-
-         1. getCacheID(self: PyOpenColorIO.Config) -> str
-
-         2. getCacheID(self: PyOpenColorIO.Config, context: OpenColorIO_v2_0dev::Context) -> str
-
-      .. py:function:: *getColorSpace(self: PyOpenColorIO.Config, name: str) -> OpenColorIO_v2_0dev::ColorSpace**
-
-      .. py:function:: getColorSpaceFromFilepath(*args,**kwargs)
-
-         Overloaded function.
-
-         1. getColorSpaceFromFilepath(self: PyOpenColorIO.Config,
-         filePath: str) -> str
-
-         2. getColorSpaceFromFilepath(self: PyOpenColorIO.Config,
-         filePath: str, ruleIndex: int) -> str
-
-      .. py:function:: getColorSpaceNames(*args,**kwargs)
-
-      Overloaded function.
-
-         1. getColorSpaceNames(self: PyOpenColorIO.Config, searchReferenceType: PyOpenColorIO.SearchReferenceSpaceType, visibility: PyOpenColorIO.ColorSpaceVisibility) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 2, OpenColorIO_v2_0dev::SearchReferenceSpaceType, OpenColorIO_v2_0dev::ColorSpaceVisibility>
-
-         2. getColorSpaceNames(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 4>
-
-      .. py:function:: getColorSpaces(*args,**kwargs)
-
-      Overloaded function.
-
-         1. getColorSpaces(self: PyOpenColorIO.Config, category: str) -> OpenColorIO_v2_0dev::ColorSpaceSet
-
-         2. getColorSpaces(self: PyOpenColorIO.Config, searchReferenceType: PyOpenColorIO.SearchReferenceSpaceType, visibility: PyOpenColorIO.ColorSpaceVisibility) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 3, OpenColorIO_v2_0dev::SearchReferenceSpaceType, OpenColorIO_v2_0dev::ColorSpaceVisibility>
-
-         3. getColorSpaces(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 5>
-
-      .. py:method:: getCurrentContext(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::Context
-
-      .. py:method:: getDefaultDisplay(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getDefaultLumaCoefs(self: PyOpenColorIO.Config) -> List[float[3]]
-
-      .. py:method:: getDefaultSceneToDisplayViewTransform(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::ViewTransform
-
-      .. py:method:: getDefaultView(self: PyOpenColorIO.Config, display: str) -> str
-
-      .. py:method:: getDescription(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getDisplayViewColorSpaceName(self: PyOpenColorIO.Config, display: str, view: str) -> str
-
-      .. py:method:: getDisplayViewDescription(self: PyOpenColorIO.Config, display: str, view: str) -> str
-
-      .. py:method:: getDisplayViewLooks(self: PyOpenColorIO.Config, display: str, view: str) -> str
-
-      .. py:method:: getDisplayViewRule(self: PyOpenColorIO.Config, display: str, view: str) -> str
-
-      .. py:method:: getDisplayViewTransformName(self: PyOpenColorIO.Config, display: str, view: str) -> str
-
-      .. py:method:: getDisplays(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 8>
-
-      .. py:method:: getEnvironmentMode(self: PyOpenColorIO.Config) -> PyOpenColorIO.EnvironmentMode
-
-      .. py:method:: getEnvironmentVarDefault(self: PyOpenColorIO.Config, name: str) -> str
-
-      .. py:method:: getEnvironmentVarNames(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 0>
-
-      .. py:method:: getFamilySeparator(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getFileRules(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::FileRules
-
-      .. py:method:: getInactiveColorSpaces(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getLook(self: PyOpenColorIO.Config, name: str) -> OpenColorIO_v2_0dev::Look
-
-      .. py:method:: getLookNames(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 12>
-
-      .. py:method:: getLooks(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 13>
-
-      .. py:method:: getMajorVersion(self: PyOpenColorIO.Config) -> int
-
-      .. py:method:: getMinorVersion(self: PyOpenColorIO.Config) -> int
-
-      .. py:function:: getProcessor(*args,**kwargs)
-
-         Overloaded function.
-
-         1. getProcessor(self: PyOpenColorIO.Config, srcColorSpace: OpenColorIO_v2_0dev::ColorSpace, dstColorSpace: OpenColorIO_v2_0dev::ColorSpace) -> OpenColorIO_v2_0dev::Processor
-
-         2. getProcessor(self: PyOpenColorIO.Config, context: OpenColorIO_v2_0dev::Context, srcColorSpace: OpenColorIO_v2_0dev::ColorSpace, dstColorSpace: OpenColorIO_v2_0dev::ColorSpace) -> OpenColorIO_v2_0dev::Processor
-
-         3. getProcessor(self: PyOpenColorIO.Config, srcColorSpaceName: str, dstColorSpaceName: str) -> OpenColorIO_v2_0dev::Processor
-
-         4. getProcessor(self: PyOpenColorIO.Config, context: OpenColorIO_v2_0dev::Context, srcColorSpaceName: str, dstColorSpaceName: str) -> OpenColorIO_v2_0dev::Processor
-
-         5. getProcessor(self: PyOpenColorIO.Config, srcColorSpaceName: str, display: str, view: str) -> OpenColorIO_v2_0dev::Processor
-
-         6. getProcessor(self: PyOpenColorIO.Config, context: OpenColorIO_v2_0dev::Context, srcColorSpaceName: str, display: str, view: str) -> OpenColorIO_v2_0dev::Processor
-
-         7. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform) -> OpenColorIO_v2_0dev::Processor
-
-         8. getProcessor(self: PyOpenColorIO.Config, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> OpenColorIO_v2_0dev::Processor
-
-         9. getProcessor(self: PyOpenColorIO.Config, context: OpenColorIO_v2_0dev::Context, transform: PyOpenColorIO.Transform, direction: PyOpenColorIO.TransformDirection) -> OpenColorIO_v2_0dev::Processor
-
-      .. py:method:: getRoleNames(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 6>
-
-      .. py:method:: getRoles(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 7>
-
-      .. py:method:: getSearchPath(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: getSearchPaths(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 1>
-
-      .. py:method:: getSharedViews(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 9>
-
-      .. py:method:: getViewTransform(self: PyOpenColorIO.Config, name: str) -> OpenColorIO_v2_0dev::ViewTransform
-
-      .. py:method:: getViewTransformNames(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 14>
-
-      .. py:method:: getViewTransforms(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 15>
-
-      .. py:method:: getViewingRules(self: PyOpenColorIO.Config) -> OpenColorIO_v2_0dev::ViewingRules
-
-      .. py:function:: getViews(*args,**kwargs)
-
-         Overloaded function.
-
-         1. getViews(self: PyOpenColorIO.Config, display: str) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 10, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >
-
-         2. getViews(self: PyOpenColorIO.Config, display: str, colorSpaceName: str) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Config>, 11, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >
-
-      .. py:method:: getWorkingDir(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: hasRole(self: PyOpenColorIO.Config, role: str) -> bool
-
-      .. py:method:: isColorSpaceUsed(self: PyOpenColorIO.Config, name: str) -> bool
-
-      .. py:method:: isStrictParsingEnabled(self: PyOpenColorIO.Config) -> bool
-
-      .. py:method:: loadEnvironment(self: PyOpenColorIO.Config) -> None
-
-      .. py:method:: parseColorSpaceFromString(self: PyOpenColorIO.Config, str: str) -> str
-
-      .. py:method:: removeColorSpace(self: PyOpenColorIO.Config, name: str) -> None
-
-      .. py:method:: removeDisplayView(self: PyOpenColorIO.Config, display: str, view: str) -> None
-
-      .. py:method:: removeSharedView(self: PyOpenColorIO.Config, view: str) -> None
-
-      .. py:method:: sanityCheck(self: PyOpenColorIO.Config) -> None**
-
-      .. py:function:: serialize(*args,**kwargs)
-
-         Overloaded function.
-
-         1. serialize(self: PyOpenColorIO.Config, fileName: str) -> None
-
-         2. serialize(self: PyOpenColorIO.Config) -> str
-
-      .. py:method:: setActiveDisplays(self: PyOpenColorIO.Config, displays: str) -> None
-
-      .. py:method:: setActiveViews(self: PyOpenColorIO.Config, views: str) -> None
-
-      .. py:method:: setDefaultLumaCoefs(self: PyOpenColorIO.Config, rgb: List[float[3]]) -> None
-
-      .. py:method:: setDescription(self: PyOpenColorIO.Config, description: str) -> None
-
-      .. py:method:: setEnvironmentMode(self: PyOpenColorIO.Config, mode: PyOpenColorIO.EnvironmentMode) -> None
-
-      .. py:method:: setFamilySeparator(self: PyOpenColorIO.Config, separator: str) -> None
-
-      .. py:method:: setFileRules(self: PyOpenColorIO.Config, fileRules: OpenColorIO_v2_0dev::FileRules) -> None
-
-      .. py:method:: setInactiveColorSpaces(self: PyOpenColorIO.Config, inactiveColorSpaces: str) -> None
-
-      .. py:method:: setMajorVersion(self: PyOpenColorIO.Config, major: int) -> None
-
-      .. py:method:: setMinorVersion(self: PyOpenColorIO.Config, minor: int) -> None
-
-      .. py:method:: setRole(self: PyOpenColorIO.Config, role: str, colorSpaceName: str) -> None
-
-      .. py:method:: setSearchPath(self: PyOpenColorIO.Config, path: str) -> None
-
-      .. py:method:: setViewingRules(self: PyOpenColorIO.Config, ViewingRules: OpenColorIO_v2_0dev::ViewingRules) -> None
-
-      .. py:method:: setWorkingDir(self: PyOpenColorIO.Config, dirName: str) -> None
-
-      .. py:method:: upgradeToLatestVersion(self: PyOpenColorIO.Config) -> None

docs/api/c_context.rst

@@ -1,116 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Context
-*******
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class Context**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: ContextRcPtr createEditableCopy() const
-
-      .. cpp:function:: const char *getCacheID() const
-
-      .. cpp:function:: void setSearchPath(const char *path)
-
-      .. cpp:function:: const char *getSearchPath() const
-
-      .. cpp:function:: int getNumSearchPaths() const
-
-      .. cpp:function:: const char *getSearchPath(int index) const
-
-      .. cpp:function:: void clearSearchPaths()
-
-      .. cpp:function:: void addSearchPath(const char *path)
-
-      .. cpp:function:: void setWorkingDir(const char *dirname)
-
-      .. cpp:function:: const char *getWorkingDir() const
-
-      .. cpp:function:: void setStringVar(const char *name, const char *value)
-
-      .. cpp:function:: const char *getStringVar(const char *name) const
-
-      .. cpp:function:: int getNumStringVars() const
-
-      .. cpp:function:: const char *getStringVarNameByIndex(int index) const
-
-      .. cpp:function:: void clearStringVars()
-
-      .. cpp:function:: void setEnvironmentMode(EnvironmentMode mode)
-
-      .. cpp:function:: EnvironmentMode getEnvironmentMode() const
-
-      .. cpp:function:: void loadEnvironment()
-
-         Seed all string vars with the current environment.
-
-      .. cpp:function:: const char *resolveStringVar(const char *val) const
-
-         Do a string lookup. Do a file lookup.
-
-         Evaluate the specified variable (as needed). Will not throw
-         exceptions.
-
-      .. cpp:function:: const char *resolveFileLocation(const char *filename) const
-
-         Do a file lookup. Do a file lookup.
-
-         Evaluate all variables (as needed). Also, walk the full search
-         path until the file is found. If the filename cannot be found,
-         an exception will be thrown.
-
-      .. cpp:function:: ~Context()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: ContextRcPtr Create()
-
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.Context
-
-      .. py:class:: SearchPathIterator
-
-      .. py:class:: StringVarIterator
-
-      .. py:class:: StringVarNameIterator
-
-      .. py:method:: addSearchPath(self: PyOpenColorIO.Context, path: str) -> None
-
-      .. py:method:: clearSearchPaths(self: PyOpenColorIO.Context) -> None
-
-      .. py:method:: clearStringVars(self: PyOpenColorIO.Context) -> None
-
-      .. py:method:: getCacheID(self: PyOpenColorIO.Context) -> str
-
-      .. py:method:: getEnvironmentMode(self: PyOpenColorIO.Context) -> PyOpenColorIO.EnvironmentMode
-
-      .. py:method:: getSearchPath(self: PyOpenColorIO.Context) -> str
-
-      .. py:method:: getSearchPaths(self: PyOpenColorIO.Context) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Context>, 2>
-
-      .. py:method:: getStringVars(self: PyOpenColorIO.Context) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Context>, 1>
-
-      .. py:method:: getWorkingDir(self: PyOpenColorIO.Context) -> str
-
-      .. py:method:: loadEnvironment(self: PyOpenColorIO.Context) -> None
-
-      .. py:method:: resolveFileLocation(self: PyOpenColorIO.Context, fileName: str) -> str
-
-      .. py:method:: resolveStringVar(self: PyOpenColorIO.Context, value: str) -> str
-
-      .. py:method:: setEnvironmentMode(self: PyOpenColorIO.Context, mode: PyOpenColorIO.EnvironmentMode) -> None
-
-      .. py:method:: setSearchPath(self: PyOpenColorIO.Context, path: str) -> None
-
-      .. py:method:: setWorkingDir(self: PyOpenColorIO.Context, dirName: str) -> None

docs/api/c_cpuprocessor.rst

@@ -1,107 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-CPUProcessor
-************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class CPUProcessor**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: bool isNoOp() const
-
-         The in and out bit-depths must be equal for isNoOp to be true.
-
-      .. cpp:function:: bool isIdentity() const
-
-         Equivalent to isNoOp from the underlying Processor, i.e., it
-         ignores in/out bit-depth differences.
-
-      .. cpp:function:: bool hasChannelCrosstalk() const
-
-      .. cpp:function:: const char *getCacheID() const
-
-      .. cpp:function:: BitDepth getInputBitDepth() const
-
-         Bit-depth of the input pixel buffer.
-
-      .. cpp:function:: BitDepth getOutputBitDepth() const
-
-         Bit-depth of the output pixel buffer.
-
-      .. cpp:function:: DynamicPropertyRcPtr getDynamicProperty(DynamicPropertyType type)
-      const**
-
-         Refer to `GPUProcessor::getDynamicProperty`_.
-
-      .. cpp:function:: void apply(ImageDesc &imgDesc) const
-
-         Apply to an image with any kind of channel ordering while
-         respecting the input and output bit-depths.
-
-      .. cpp:function:: void apply(const ImageDesc &srcImgDesc, ImageDesc &dstImgDesc)
-      const**
-
-      .. cpp:function:: void applyRGB(float *pixel) const
-
-         Apply to a single pixel respecting that the input and output
-         bit-depths be 32-bit float and the image buffer be packed
-         RGB/RGBA.
-
-         **Note**
-         This is not as efficient as applying to an entire image at
-         once. If you are processing multiple pixels, and have the
-         flexibility, use the above function instead.
-
-      .. cpp:function:: void applyRGBA(float *pixel) const
-
-      .. cpp:function:: ~CPUProcessor()**
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.CPUProcessor
-
-      .. py:function:: apply(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: apply(self: PyOpenColorIO.CPUProcessor, imgDesc: OpenColorIO_v2_0dev::PyImageDesc) -> None
-
-         2. .. py:function:: apply(self: PyOpenColorIO.CPUProcessor, srcImgDesc: OpenColorIO_v2_0dev::PyImageDesc, dstImgDesc: OpenColorIO_v2_0dev::PyImageDesc) -> None
-
-      .. py:function:: applyRGB(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: applyRGB(self: PyOpenColorIO.CPUProcessor, pixel: buffer) buffer
-
-         2. .. py:function:: applyRGB(self: PyOpenColorIO.CPUProcessor, pix List[float]) -> List[float]
-
-      .. py:function:: applyRGBA(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: applyRGBA(self: PyOpenColorIO.CPUProcessor, pixel: buffer) -> buffer
-
-         2. .. py:function:: applyRGBA(self: PyOpenColorIO.CPUProcessor, pixel: List[float]) -> List[float]
-
-      .. py:method:: getCacheID(self: PyOpenColorIO.CPUProcessor) -> str
-
-      .. py:method:: getDynamicProperty(self: PyOpenColorIO.CPUProcessor, type: PyOpenColorIO.DynamicPropertyType) -> `PyOpenColorIO.DynamicProperty`_
-
-      .. py:method:: getInputBitDepth(self: PyOpenColorIO.CPUProcessor) -> PyOpenColorIO.BitDepth
-
-      .. py:method:: getOutputBitDepth(self: PyOpenColorIO.CPUProcessor) -> PyOpenColorIO.BitDepth
-
-      .. py:method:: hasChannelCrosstalk(self: PyOpenColorIO.CPUProcessor) -> bool
-
-      .. py:method:: isIdentity(self: PyOpenColorIO.CPUProcessor) -> bool
-
-      .. py:method:: isNoOp(self: PyOpenColorIO.CPUProcessor) -> bool

docs/api/c_dynamicproperty.rst

@@ -1,47 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-DynamicProperty
-***************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class DynamicProperty**
-
-Allows transform parameter values to be set on-the-fly (after
-finalization). For example, to modify the exposure in a viewport.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: DynamicPropertyType getType() const = 0
-
-      .. cpp:function:: DynamicPropertyValueType getValueType() const = 0
-
-      .. cpp:function:: double getDoubleValue() const = 0
-
-      .. cpp:function:: void setValue(double value) = 0
-
-      .. cpp:function:: bool isDynamic() const = 0
-
-      .. cpp:function:: DynamicProperty &operator=(const DynamicProperty&) = delete
-
-      .. cpp:function:: ~DynamicProperty()
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.DynamicProperty
-
-      .. py:method:: getDoubleValue(self: PyOpenColorIO.DynamicProperty) -> float
-
-      .. py:method:: getType(self: PyOpenColorIO.DynamicProperty) -> PyOpenColorIO.DynamicPropertyType
-
-      .. py:method:: getValueType(self: PyOpenColorIO.DynamicProperty) -> PyOpenColorIO.DynamicPropertyValueType
-
-      .. py:method:: isDynamic(self: PyOpenColorIO.DynamicProperty) -> bool
-
-      .. py:method:: setValue(self: PyOpenColorIO.DynamicProperty, value: float) -> None

docs/api/c_filerules.rst

@@ -1,239 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-FileRules
-*********
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-
-The File Rules are a set of filepath to color space mappings that are evaluated
-from first to last. The first rule to match is what determines which color space is
-returned. There are four types of rules available. Each rule type has a name key that may
-be used by applications to refer to that rule. Name values must be unique i.e. using a
-case insensitive comparison. The other keys depend on the rule type:
-
-Basic Rule: 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
-
-* colorspace: Color space name to be returned.
-
-* pattern: Glob pattern to be used for the main part of the name/path.
-
-* extension: Glob pattern 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.
-
-Regex Rule: This is similar to the basic rule but allows additional capabilities for
-power-users. It contains the keys:
-
-* name: Name of the rule
-
-* colorspace: Color space name to be returned.
-
-* regex: Regular expression to be evaluated.
-
-OCIO v1 style Rule: This rule allows the use of the OCIO v1 style, where the string
-is searched for color space 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.
-StrictParsing is not used. If no color space is found in the path, the rule will not
-match and the next rule will be considered.
-See :cpp:func:`FileRules::insertPathSearchRule`.
-It has the key:
-
-* name: Must be "ColorSpaceNamePathSearch".
-
-Default Rule: The file_rules must always end with this rule. If no prior rules match,
-this rule specifies the color space applications will use.
-See :cpp:func:`FileRules::setDefaultRuleColorSpace`.
-It has the keys:
-
-* name: must be "Default".
-
-* colorspace : Color space name to be returned.
-
-Custom string keys and associated string values may be used to convey app or
-workflow-specific information, e.g. whether the color space should be left as is
-or converted into a working space.
-
-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.
-
-
-**class FileRules**
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: FileRulesRcPtr createEditableCopy() const
-
-         The method clones the content decoupling the two instances.
-
-      .. cpp:function:: size_t getNumEntries() const noexcept
-
-         Does include default rule. Result will be at least 1.
-
-      .. cpp:function:: size_t getIndexForRule(const char *ruleName) const
-
-         Get the index from the rule name.
-
-      .. cpp:function:: const char *getName(size_t ruleIndex) const
-
-         Get name of the rule.
-
-      .. cpp:function:: const char *getPattern(size_t ruleIndex) const
-
-         Setting pattern will erase regex.
-
-      .. cpp:function:: void setPattern(size_t ruleIndex, const char *pattern)
-
-      .. cpp:function:: const char *getExtension(size_t ruleIndex) const
-
-         Setting extension will erase regex.
-
-      .. cpp:function:: void setExtension(size_t ruleIndex, const char *extension)
-
-      .. cpp:function:: const char *getRegex(size_t ruleIndex) const
-
-         Setting a regex will erase pattern & extension.
-
-      .. cpp:function:: void setRegex(size_t ruleIndex, const char *regex)
-
-      .. cpp:function:: const char *getColorSpace(size_t ruleIndex) const
-
-         Set the rule’s color space (may also be a role).
-
-      .. cpp:function:: void setColorSpace(size_t ruleIndex, const char *colorSpace)
-
-      .. cpp:function:: size_t getNumCustomKeys(size_t ruleIndex) const
-
-         Get number of key/value pairs.
-
-      .. cpp:function:: const char *getCustomKeyName(size_t ruleIndex, size_t key) const
-      
-
-         Get name of key.
-
-      .. cpp:function:: const char *getCustomKeyValue(size_t ruleIndex, size_t key) const
-      
-
-         Get value for the key.
-
-      .. cpp:function:: void setCustomKey(size_t ruleIndex, const char *key, const char *value)
-
-         Adds a key/value or replace value if key exists. Setting a NULL
-         or an empty value will erase the key.
-
-      .. cpp:function:: void insertRule(size_t ruleIndex, const char *name, const char *colorSpace, const char *pattern, const char *extension)
-
-         Insert a rule at a given ruleIndex.
-
-         Rule currently at ruleIndex will be pushed to index: ruleIndex +
-         1. Name must be unique.
-
-         * ”Default” is a reserved name for the default rule. The
-         default rule is automatically added and can’t be removed.
-         (see `FileRules::setDefaultRuleColorSpace`_ ).
-
-         * ”ColorSpaceNamePathSearch” is also a reserved name (see
-         `FileRules::insertPathSearchRule`_ ).
-
-         Will throw if ruleIndex is not less than
-         `FileRules::getNumEntries`_ .
-
-      .. cpp:function:: void insertRule(size_t ruleIndex, const char *name, const char *colorSpace, const char *regex)
-
-      .. cpp:function:: void insertPathSearchRule(size_t ruleIndex)
-
-         Helper function to insert a rule.
-
-         Uses Config:parseColorSpaceFromString to search the path for any
-         of the color spaces named in the config (as per OCIO v1).
-
-      .. cpp:function:: void setDefaultRuleColorSpace(const char *colorSpace)
-
-         Helper function to set the color space for the default rule.
-
-      .. cpp:function:: void removeRule(size_t ruleIndex)
-
-      .. cpp:function:: Note
-         Default rule can’t be removed. Will throw if ruleIndex + 1 is
-         not less than `FileRules::getNumEntries`_ .
-
-      .. cpp:function:: void increaseRulePriority(size_t ruleIndex)
-
-         Move a rule closer to the start of the list by one position.
-
-      .. cpp:function:: void decreaseRulePriority(size_t ruleIndex)
-
-         Move a rule closer to the end of the list by one position.
-
-      .. cpp:function:: FileRules(const FileRules&) = delete
-
-      .. cpp:function:: `FileRules`_ &operator=(const FileRules&) = delete
-
-      .. cpp:function:: ~FileRules()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: FileRulesRcPtr Create()
-
-         Creates FileRules for a Config. File rules will contain the
-         default rule using the default role. The default rule cannot be
-         removed.
-
-
-   .. group-tab:: Python
-
-      .. py:method:: decreaseRulePriority(self: PyOpenColorIO.FileRules, ruleIndex: int) -> None
-
-      .. py:method:: getColorSpace(self: PyOpenColorIO.FileRules, ruleIndex: int) -> str
-
-      .. py:method:: getCustomKeyName(self: PyOpenColorIO.FileRules, ruleIndex: int, key: int) -> str
-
-      .. py:method:: getCustomKeyValue(self: PyOpenColorIO.FileRules, ruleIndex: int, key: int) -> str
-
-      .. py:method:: getExtension(self: PyOpenColorIO.FileRules, ruleIndex: int) -> str
-
-      .. py:method:: getIndexForRule(self: PyOpenColorIO.FileRules, ruleName: str) -> int
-
-      .. py:method:: getName(self: PyOpenColorIO.FileRules, ruleIndex: int) -> str
-
-      .. py:method:: getNumCustomKeys(self: PyOpenColorIO.FileRules, ruleIndex: int) -> int
-
-      .. py:method:: getNumEntries(self: PyOpenColorIO.FileRules) -> int
-
-      .. py:method:: getPattern(self: PyOpenColorIO.FileRules, ruleIndex: int) -> str
-
-      .. py:method:: getRegex(self: PyOpenColorIO.FileRules, ruleIndex: int) -> str
-
-      .. py:method:: increaseRulePriority(self: PyOpenColorIO.FileRules, ruleIndex: int) -> None
-
-      .. py:method:: insertPathSearchRule(self: PyOpenColorIO.FileRules, ruleIndex: int) -> None
-
-      .. py:function:: insertRule(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: insertRule(self: PyOpenColorIO.FileRules, ruleIndex: int, name: str, colorSpace: str, pattern: str, extension: str) -> None
-
-         2. .. py:function:: insertRule(self: PyOpenColorIO.FileRules, ruleIndex: int, name: str, colorSpace: str, regex: str) -> None
-
-      .. py:method:: removeRule(self: PyOpenColorIO.FileRules, ruleIndex: int) -> None
-
-      .. py:method:: setColorSpace(self: PyOpenColorIO.FileRules, ruleIndex: int, colorSpace: str) -> None
-
-      .. py:method:: setCustomKey(self: PyOpenColorIO.FileRules, ruleIndex: int, key: str, value: str) -> None
-
-      .. py:method:: setDefaultRuleColorSpace(self: PyOpenColorIO.FileRules, colorSpace: str) -> None
-
-      .. py:method:: setExtension(self: PyOpenColorIO.FileRules, ruleIndex: int, extension: str) -> None
-
-      .. py:method:: setPattern(self: PyOpenColorIO.FileRules, ruleIndex: int, pattern: str) -> None
-
-      .. py:method:: setRegex(self: PyOpenColorIO.FileRules, ruleIndex: int, regex: str) -> None

docs/api/c_formatmetadata.rst

@@ -1,106 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-FormatMetadata
-**************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class FormatMetadata**
-
-The FormatMetadata class is intended to be a generic container to
-hold metadata from various file formats.
-
-This class provides a hierarchical metadata container. A metadata
-object is similar to an element in XML. It contains:
-
-* A name string (e.g. “Description”).
-
-* A value string (e.g. “updated viewing LUT”).
-
-* A list of attributes (name, value) string pairs (e.g. “version”,
-“1.5”).
-
-* And a list of child sub-elements, which are also objects
-implementing FormatMetadata.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: const char *getName() const = 0
-
-      .. cpp:function:: void setName(const char*) = 0
-
-      .. cpp:function:: const char *getValue() const = 0
-
-      .. cpp:function:: void setValue(const char*) = 0
-
-      .. cpp:function:: int getNumAttributes() const = 0
-
-      .. cpp:function:: const char *getAttributeName(int i) const = 0
-
-      .. cpp:function:: const char *getAttributeValue(int i) const = 0
-
-      .. cpp:function:: void addAttribute(const char *name, const char *value) = 0
-
-         Add an attribute with a given name and value. If an attribute
-         with the same name already exists, the value is replaced.
-
-      .. cpp:function:: int getNumChildrenElements() const = 0
-
-      .. cpp:function:: const `FormatMetadata`_ &getChildElement(int i) const = 0
-
-      .. cpp:function:: `FormatMetadata`_ &getChildElement(int i) = 0
-
-      .. cpp:function:: `FormatMetadata`_ &addChildElement(const char *name, const char *value) = 0
-
-         Add a child element with a given name and value. Name has to be
-         non-empty. Value may be empty, particularly if this element will
-         have children. Return a reference to the added element.
-
-      .. cpp:function:: void clear() = 0
-
-      .. cpp:function:: `FormatMetadata`_ &operator=(const FormatMetadata &rhs) = 0
-
-      .. cpp:function:: FormatMetadata(const FormatMetadata &rhs) = delete
-
-      .. cpp:function:: ~FormatMetadata()
-
-   .. group-tab:: Python
-
-
-      .. py:class:: PyOpenColorIO.FormatMetadata
-
-      .. py:class:: AttributeIterator
-
-      .. py:class:: AttributeNameIterator
-
-      .. py:class:: ChildElementIterator
-
-      .. py:class:: ConstChildElementIterator
-
-      .. py:method:: addChildElement(self: PyOpenColorIO.FormatMetadata, name: str, value: str) -> `PyOpenColorIO.FormatMetadata`_
-
-      .. py:method:: clear(self: PyOpenColorIO.FormatMetadata) -> None
-
-      .. py:method:: getAttributes(self: PyOpenColorIO.FormatMetadata) -> OpenColorIO_v2_0dev::PyIterator<OpenColorIO_v2_0dev::FormatMetadata const&, 1>
-
-      .. py:function:: getChildElements(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: getChildElements(self: PyOpenColorIO.FormatMetadata) -> OpenColorIO_v2_0dev::PyIterator<OpenColorIO_v2_0dev::FormatMetadata const&, 2>
-
-         2. .. py:function:: getChildElements(self: PyOpenColorIO.FormatMetadata) -> OpenColorIO_v2_0dev::PyIterator<OpenColorIO_v2_0dev::FormatMetadata&, 3>
-
-      .. py:method:: getName(self: PyOpenColorIO.FormatMetadata) -> str
-
-      .. py:method:: getValue(self: PyOpenColorIO.FormatMetadata) -> str
-
-      .. py:method:: setName(self: PyOpenColorIO.FormatMetadata, name: str) -> None
-
-      .. py:method:: setValue(self: PyOpenColorIO.FormatMetadata, value: str) -> None

docs/api/c_gpuprocessor.rst

@@ -1,69 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-GPUProcessor
-************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class GPUProcessor**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: bool isNoOp() const
-
-      .. cpp:function:: bool hasChannelCrosstalk() const
-
-      .. cpp:function:: const char *getCacheID() const
-
-      .. cpp:function:: DynamicPropertyRcPtr getDynamicProperty(DynamicPropertyType type) const
-
-         The returned pointer may be used to set the value of any dynamic
-         properties of the requested type. Throws if the requested
-         property is not found. Note that if the processor contains
-         several ops that support the requested property, only ones for
-         which dynamic has been enabled will be controlled.
-
-         **Note**
-         The dynamic properties in this object are decoupled from the
-         ones in the :cpp:class:``Processor`` it was generated from.
-
-      .. cpp:function:: void extractGpuShaderInfo(GpuShaderDescRcPtr &shaderDesc) const
-      
-
-         Extract & Store the shader information to implement the color
-         processing.
-
-      .. cpp:function:: void extractGpuShaderInfo(GpuShaderCreatorRcPtr &shaderCreator) const
-
-         Extract the shader information using a custom GpuShaderCreator
-         class.
-
-      .. cpp:function:: ~GPUProcessor()
-
-
-   .. group-tab:: Python
-
-
-      .. py:class:: PyOpenColorIO.GPUProcessor
-
-      .. py:function:: extractGpuShaderInfo(*args,**kwargs)
-
-         Overloaded function.
-
-         1. .. py:function:: extractGpuShaderInfo(self: PyOpenColorIO.GPUProcessor, shaderDesc: OpenColorIO_v2_0dev::GpuShaderDesc) -> None
-
-         2. .. py:function:: extractGpuShaderInfo(self: PyOpenColorIO.GPUProcessor, shaderCreator: OpenColorIO_v2_0dev::GpuShaderCreator) -> None
-
-      .. py:function:: getCacheID(self: PyOpenColorIO.GPUProcessor) -> str
-
-      .. py:function:: getDynamicProperty(self: PyOpenColorIO.GPUProcessor, type: PyOpenColorIO.DynamicPropertyType) -> `PyOpenColorIO.DynamicProperty`_
-
-      .. py:function:: hasChannelCrosstalk(self: PyOpenColorIO.GPUProcessor) -> bool
-
-      .. py:function:: isNoOp(self: PyOpenColorIO.GPUProcessor) -> bool

docs/api/c_gpushadercreator.rst

@@ -1,187 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-GpuShaderCreator
-****************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class GpuShaderCreator**
-
-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
-:cpp:class:`GpuShaderDesc` is a better choice.
-
-Subclassed by OpenColorIO::GpuShaderDesc
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:enum:: TextureType 
-
-         *Values:*
-
-         .. cpp:enumerator:: TEXTURE_RED_CHANNEL 
-
-            Only use the red channel of the texture.
-
-         .. cpp:enumerator:: TEXTURE_RGB_CHANNEL 
-
-      **Public Functions**
-
-      .. cpp:function:: GpuShaderCreatorRcPtr clone() const = 0
-
-      .. cpp:function:: const char *getUniqueID() const noexcept
-
-      .. cpp:function:: void setUniqueID(const char *uid) noexcept
-
-      .. cpp:function:: GpuLanguage getLanguage() const noexcept
-
-      .. cpp:function:: void setLanguage(GpuLanguage lang) noexcept
-
-         Set the shader program language.
-
-      .. cpp:function:: const char *getFunctionName() const noexcept
-
-      .. cpp:function:: void setFunctionName(const char *name) noexcept
-
-      .. cpp:function:: const char *getPixelName() const noexcept
-
-      .. cpp:function:: void setPixelName(const char *name) noexcept
-
-         Set the pixel name variable holding the color values.
-
-      .. cpp:function:: const char *getResourcePrefix() const noexcept
-
-         **Note**
-         Some applications require that textures, uniforms, and helper
-         methods be uniquely named because several processor instances
-         could coexist.
-
-      .. cpp:function:: void setResourcePrefix(const char *prefix) noexcept
-
-         Set a prefix to the resource name.
-
-      .. cpp:function:: const char *getCacheID() const noexcept
-
-      .. cpp:function:: void begin(const char *uid)
-
-         Start to collect the shader data.
-
-      .. cpp:function:: void end()
-
-         End to collect the shader data.
-
-      .. cpp:function:: void setTextureMaxWidth(unsigned maxWidth) = 0
-
-         Some graphic cards could have 1D & 2D textures with size
-         limitations.
-
-      .. cpp:function:: unsigned getTextureMaxWidth() const noexcept = 0
-
-      .. cpp:function:: unsigned getNextResourceIndex() noexcept
-
-         To avoid texture/unform name clashes always append an increasing
-         number to the resource name.
-
-      .. cpp:function:: bool addUniform(const char *name, const DynamicPropertyRcPtr &value) = 0
-
-      .. cpp:function:: void addTexture(const char *textureName, const char *samplerName, const char *uid, unsigned width, unsigned height, TextureType channel, Interpolation interpolation, const float *values) = 0
-
-      .. cpp:function:: void add3DTexture(const char *textureName, const char *samplerName, const char *uid, unsigned edgelen, Interpolation interpolation, const float *values) = 0
-
-      .. cpp:function:: void addToDeclareShaderCode(const char *shaderCode)
-
-      .. cpp:function:: void addToHelperShaderCode(const char *shaderCode)
-
-      .. cpp:function:: void addToFunctionHeaderShaderCode(const char *shaderCode)
-
-      .. cpp:function:: void addToFunctionShaderCode(const char *shaderCode)
-
-      .. cpp:function:: void addToFunctionFooterShaderCode(const char *shaderCode)
-
-      .. cpp:function:: void createShaderText(const char *shaderDeclarations, const char *shaderHelperMethods, const char *shaderFunctionHeader, const char *shaderFunctionBody, const char *shaderFunctionFooter)
-
-         Create the OCIO shader program.
-
-         The OCIO shader program is decomposed to allow a specific
-         implementation to change some parts. Some product integrations
-         add the color processing within a client shader program,
-         imposing constraints requiring this flexibility.
-
-         **Note**
-
-      .. cpp:function:: void finalize()
-
-      .. cpp:function:: ~GpuShaderCreator()
-
-
-   .. group-tab:: Python
-
-      .. py:class:: TextureType
-
-         Members:
-
-         .. py:const:: TEXTURE_RED_CHANNEL = TextureType.TEXTURE_RED_CHANNEL
-
-         .. py:const:: TEXTURE_RGB_CHANNEL = TextureType.TEXTURE_RGB_CHANNEL
-
-      .. py:method:: add3DTexture(self: PyOpenColorIO.GpuShaderCreator, textureName: str, samplerName: str, uid: str, edgeLen: int, interpolation: PyOpenColorIO.Interpolation, values: float) -> None
-
-      .. py:method:: addTexture(self: PyOpenColorIO.GpuShaderCreator, textureName: str, samplerName: str, uid: str, width: int, height: int, channel: OpenColorIO_v2_0dev::GpuShaderCreator::TextureType, interpolation: PyOpenColorIO.Interpolation, values: float) -> None
-
-      .. py:method:: addToDeclareShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
-
-      .. py:method:: addToFunctionFooterShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
-
-      .. py:method:: addToFunctionHeaderShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
-
-      .. py:method:: addToFunctionShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
-
-      .. py:method:: addToHelperShaderCode(self: PyOpenColorIO.GpuShaderCreator, shaderCode: str) -> None
-
-      .. py:method:: addUniform(self: PyOpenColorIO.GpuShaderCreator, name: str, value: PyOpenColorIO.DynamicProperty) -> bool
-
-      .. py:method:: begin(self: PyOpenColorIO.GpuShaderCreator, uid: str) -> None
-
-      .. py:method:: clone(self: PyOpenColorIO.GpuShaderCreator) -> `PyOpenColorIO.GpuShaderCreator`_
-
-      .. py:method:: createShaderText(self: PyOpenColorIO.GpuShaderCreator, shaderDeclarations: str, shaderHelperMethods: str, shaderFunctionHeader: str, shaderFunctionBody: str, shaderFunctionFooter: str) -> None
-
-      .. py:method:: end(self: PyOpenColorIO.GpuShaderCreator) -> None
-
-      .. py:method:: finalize(self: PyOpenColorIO.GpuShaderCreator) -> None
-
-      .. py:method:: getCacheID(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: getFunctionName(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: getLanguage(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: getNextResourceIndex(self: PyOpenColorIO.GpuShaderCreator) -> int
-
-      .. py:method:: getPixelName(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: getResourcePrefix(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: getTextureMaxWidth(self: PyOpenColorIO.GpuShaderCreator) -> int
-
-      .. py:method:: getUniqueID(self: PyOpenColorIO.GpuShaderCreator) -> str
-
-      .. py:method:: setFunctionName(self: PyOpenColorIO.GpuShaderCreator, name: str) -> None
-
-      .. py:method:: setLanguage(self: PyOpenColorIO.GpuShaderCreator, language: str) -> None
-
-      .. py:method:: setPixelName(self: PyOpenColorIO.GpuShaderCreator, name: str) -> None
-
-      .. py:method:: setResourcePrefix(self: PyOpenColorIO.GpuShaderCreator, prefix: str) -> None
-
-      .. py:method:: setTextureMaxWidth(self: PyOpenColorIO.GpuShaderCreator, maxWidth: int) -> None
-
-      .. py:method:: setUniqueID(self: PyOpenColorIO.GpuShaderCreator, uid: str) -> None

docs/api/c_gpushaderdesc.rst

@@ -1,269 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-GpuShaderDesc
-*************
-
-.. CAUTION::
-API Docs are a work in progress, expect them to improve over time.
-
-TODO: Move to .rst
-!rst::
-GpuShaderDesc
-*************
-This class holds the GPU-related information needed to build a shader program
-from a specific processor.
-
-This class defines the interface and there are two implementations provided.
-The "legacy" mode implements the OCIO v1 approach of baking certain ops
-in order to have at most one 3D-LUT.  The "generic" mode is the v2 default and
-allows all the ops to be processed as-is, without baking, like the CPU renderer.
-Custom implementations could be written to accommodate the GPU needs of a
-specific client app.
-
-
-The complete fragment shader program is decomposed in two main parts:
-the OCIO shader program for the color processing and the client shader
-program which consumes the pixel color processing.
-
-The OCIO shader program is fully described by the GpuShaderDesc
-independently from the client shader program. The only critical
-point is the agreement on the OCIO function shader name.
-
-To summarize, the complete shader program is:
-
-.. code-block:: cpp
-
-   ////////////////////////////////////////////////////////////////////////
-   //                                                                    //
-   //               The complete fragment shader program                 //
-   //                                                                    //
-   ////////////////////////////////////////////////////////////////////////
-   //                                                                    //
-   //   //////////////////////////////////////////////////////////////   //
-   //   //                                                          //   //
-   //   //               The OCIO shader program                    //   //
-   //   //                                                          //   //
-   //   //////////////////////////////////////////////////////////////   //
-   //   //                                                          //   //
-   //   //   // All global declarations                             //   //
-   //   //   uniform sampled3D tex3;                                //   //
-   //   //                                                          //   //
-   //   //   // All helper methods                                  //   //
-   //   //   vec3 computePos(vec3 color)                            //   //
-   //   //   {                                                      //   //
-   //   //      vec3 coords = color;                                //   //
-   //   //      ...                                                 //   //
-   //   //      return coords;                                      //   //
-   //   //   }                                                      //   //
-   //   //                                                          //   //
-   //   //   // The OCIO shader function                            //   //
-   //   //   vec4 OCIODisplay(in vec4 inColor)                      //   //
-   //   //   {                                                      //   //
-   //   //      vec4 outColor = inColor;                            //   //
-   //   //      ...                                                 //   //
-   //   //      outColor.rbg                                        //   //
-   //   //         = texture3D(tex3, computePos(inColor.rgb)).rgb;  //   //
-   //   //      ...                                                 //   //
-   //   //      return outColor;                                    //   //
-   //   //   }                                                      //   //
-   //   //                                                          //   //
-   //   //////////////////////////////////////////////////////////////   //
-   //                                                                    //
-   //   //////////////////////////////////////////////////////////////   //
-   //   //                                                          //   //
-   //   //             The client shader program                    //   //
-   //   //                                                          //   //
-   //   //////////////////////////////////////////////////////////////   //
-   //   //                                                          //   //
-   //   //   uniform sampler2D image;                               //   //
-   //   //                                                          //   //
-   //   //   void main()                                            //   //
-   //   //   {                                                      //   //
-   //   //      vec4 inColor = texture2D(image, gl_TexCoord[0].st); //   //
-   //   //      ...                                                 //   //
-   //   //      vec4 outColor = OCIODisplay(inColor);               //   //
-   //   //      ...                                                 //   //
-   //   //      gl_FragColor = outColor;                            //   //
-   //   //   }                                                      //   //
-   //   //                                                          //   //
-   //   //////////////////////////////////////////////////////////////   //
-   //                                                                    //
-   ////////////////////////////////////////////////////////////////////////
-
-
-**Usage Example:** *Building a GPU shader*
-
-This example is based on the code in: src/apps/ociodisplay/main.cpp
-
-.. code-block:: cpp
-
-   // Get the processor
-   //
-   OCIO::ConstConfigRcPtr config = OCIO::Config::CreateFromEnv();
-   OCIO::ConstProcessorRcPtr processor
-      = config->getProcessor("ACES - ACEScg", "Output - sRGB");
-
-   // Step 1: Create a GPU shader description
-   //
-   // The three 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
-   //      is used as-is (i.e. without any baking step) and could contain
-   //      any number of 1D & 3D luts.
-   //
-   //      This is the default OCIO v2 behavior and allows a much better
-   //      match between the CPU and GPU renderers.
-   //
-   OCIO::GpuShaderDescRcPtr shaderDesc = OCIO::GpuShaderDesc::Create();
-   //
-   //   3. 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
-   //      new class inheriting from the pure virtual class GpuShaderDesc.
-   //
-   //      Please refer to the GenericGpuShaderDesc class for an example.
-   //
-   OCIO::GpuShaderDescRcPtr shaderDesc = MyCustomGpuShader::Create();
-
-   shaderDesc->setLanguage(OCIO::GPU_LANGUAGE_GLSL_1_3);
-   shaderDesc->setFunctionName("OCIODisplay");
-
-   // Step 2: Collect the shader program information for a specific processor
-   //
-   processor->extractGpuShaderInfo(shaderDesc);
-
-   // Step 3: Create a helper to build the shader. Here we use a helper for
-   //         OpenGL but there will also be helpers for other languages.
-   //
-   OpenGLBuilderRcPtr oglBuilder = OpenGLBuilder::Create(shaderDesc);
-
-   // Step 4: Allocate & upload all the LUTs
-   //
-   oglBuilder->allocateAllTextures();
-
-   // Step 5: Build the complete fragment shader program using
-   //         g_fragShaderText which is the client shader program.
-   //
-   g_programId = oglBuilder->buildProgram(g_fragShaderText);
-
-   // Step 6: Enable the fragment shader program, and all needed textures
-   //
-   glUseProgram(g_programId);
-   glUniform1i(glGetUniformLocation(g_programId, "tex1"), 1);  // image texture
-   oglBuilder->useAllTextures(g_programId);                    // LUT textures
-
-
-**class GpuShaderDesc : public OpenColorIO::`GpuShaderCreator`_**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: GpuShaderCreatorRcPtr clone() const override
-
-      .. cpp:function:: unsigned getNumUniforms() const noexcept = 0
-
-      .. cpp:function:: void getUniform(unsigned index, const char *&name, DynamicPropertyRcPtr &value) const = 0
-
-      .. cpp:function:: unsigned getNumTextures() const noexcept = 0
-
-      .. cpp:function:: void getTexture(unsigned index, const char *&textureName, const char *&samplerName, const char *&uid, unsigned &width, unsigned &height, TextureType &channel, Interpolation &interpolation) const = 0
-
-      .. cpp:function:: void getTextureValues(unsigned index, const float *&values) const = 0
-
-      .. cpp:function:: unsigned getNum3DTextures() const noexcept = 0
-
-      .. cpp:function:: void get3DTexture(unsigned index, const char *&textureName, const char *&samplerName, const char *&uid, unsigned &edgelen, Interpolation &interpolation) const = 0
-
-      .. cpp:function:: void get3DTextureValues(unsigned index, const float *&values) const = 0**
-
-      .. cpp:function:: const char *getShaderText() const noexcept
-
-         Get the complete OCIO shader program.
-
-      .. cpp:function:: ~GpuShaderDesc()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: GpuShaderDescRcPtr CreateLegacyShaderDesc(unsigned edgelen)
-
-         Create the legacy shader description.
-
-      .. cpp:function:: GpuShaderDescRcPtr CreateShaderDesc()
-
-         Create the default shader description.
-
-   .. group-tab:: Python
-
-      .. py:class:: PyOpenColorIO.GpuShaderDesc
-
-      .. py:function:: CreateLegacyShaderDesc(edgeLen: int, language: PyOpenColorIO.GpuLanguage = GpuLanguage.GPU_LANGUAGE_UNKNOWN, functionName: str = 'OCIOMain', pixelName: str = 'outColor', resourcePrefix: str = 'ocio', uid: str = '') -> `PyOpenColorIO.GpuShaderDesc`_
-
-      .. py:function:: CreateShaderDesc(language: PyOpenColorIO.GpuLanguage = GpuLanguage.GPU_LANGUAGE_UNKNOWN, functionName: str = 'OCIOMain', pixelName: str = 'outColor', resourcePrefix: str = 'ocio', uid: str = '') -> `PyOpenColorIO.GpuShaderDesc`_
-
-      .. py:class:: Texture
-
-         **property channel**
-
-         **property height**
-
-         **property interpolation**
-
-         **property samplerName**
-
-         **property textureName**
-
-         **property uid**
-
-         **property width**
-
-      .. py:class:: Texture3D
-
-         **property edgeLen**
-
-         **property interpolation**
-
-         **property samplerName**
-
-         **property textureName**
-
-         **property uid**
-
-      .. py:class:: Texture3DIterator
-
-      .. py:class:: TextureIterator
-
-      .. py:class:: UniformIterator
-
-      .. py:method:: add3DTexture(self: PyOpenColorIO.GpuShaderDesc, textureName: str, samplerName: str, uid: str, edgeLen: int, interpolation: PyOpenColorIO.Interpolation, values: buffer) -> None
-
-      .. py:method:: addTexture(self: PyOpenColorIO.GpuShaderDesc, textureName: str, samplerName: str, uid: str, width: int, height: int, channel: PyOpenColorIO.GpuShaderCreator.TextureType, interpolation: PyOpenColorIO.Interpolation, values: buffer) -> None
-
-      .. py:method:: addUniform(self: PyOpenColorIO.GpuShaderDesc, name: str, value: PyOpenColorIO.DynamicProperty) -> bool
-
-      .. py:method:: get3DTextureValues(self: PyOpenColorIO.GpuShaderDesc, index: int) -> array
-
-      .. py:method:: get3DTextures(self: PyOpenColorIO.GpuShaderDesc) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::GpuShaderDesc>, 2>
-
-      .. py:method:: getNum3DTextures(self: PyOpenColorIO.GpuShaderDesc) -> int**
-
-      .. py:method:: getNumTextures(self: PyOpenColorIO.GpuShaderDesc) -> int**
-
-      .. py:method:: getTextureValues(self: PyOpenColorIO.GpuShaderDesc, index: int) -> array
-
-      .. py:method:: getTextures(self: PyOpenColorIO.GpuShaderDesc) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::GpuShaderDesc>, 1>
-
-      .. py:method:: getUniforms(self: PyOpenColorIO.GpuShaderDesc) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::GpuShaderDesc>, 0>

docs/api/c_imagedesc.rst

@@ -1,96 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-ImageDesc
-*********
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class ImageDesc**
-
-This is a light-weight wrapper around an image, that provides a
-context for pixel access. This does NOT claim ownership of the
-pixels or copy image data.
-
-Subclassed by OpenColorIO::PackedImageDesc,
-OpenColorIO::PlanarImageDesc
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: ImageDesc()
-
-      .. cpp:function:: ~ImageDesc()
-
-      .. cpp:function:: void *getRData() const = 0
-
-         Get a pointer to the red channel of the first pixel.
-
-      .. cpp:function:: void *getGData() const = 0
-
-         Get a pointer to the green channel of the first pixel.
-
-      .. cpp:function:: void *getBData() const = 0
-
-         Get a pointer to the blue channel of the first pixel.
-
-      .. cpp:function:: void *getAData() const = 0
-
-         Get a pointer to the alpha channel of the first pixel or null as
-         alpha channel is optional.
-
-      .. cpp:function:: BitDepth getBitDepth() const = 0
-
-         Get the bit-depth.
-
-      .. cpp:function:: long getWidth() const = 0
-
-         Get the width to process (where x position starts at 0 and ends
-         at width-1).
-
-      .. cpp:function:: long getHeight() const = 0
-
-         Get the height to process (where y position starts at 0 and ends
-         at height-1).
-
-      .. cpp:function:: ptrdiff_t getXStrideBytes() const = 0
-
-         Get the step in bytes to find the same color channel of the next
-         pixel.
-
-      .. cpp:function:: ptrdiff_t getYStrideBytes() const = 0
-
-         Get the step in bytes to find the same color channel of the
-         pixel at the same position in the next line.
-
-      .. cpp:function:: bool isRGBAPacked() const = 0
-
-         Is the image buffer in packed mode with the 4 color channels?
-         (“Packed” here means that XStrideBytes is 4x the bytes per
-         channel, so it is more specific than simply any
-         PackedImageDesc.)
-
-      .. cpp:function:: bool isFloat() const = 0
-
-         Is the image buffer 32-bit float?
-
-
-   .. group-tab:: Python
-
-      .. py:method:: getBitDepth(self: PyOpenColorIO.ImageDesc) -> PyOpenColorIO.BitDepth
-
-      .. py:method:: getHeight(self: PyOpenColorIO.ImageDesc) -> int
-
-      .. py:method:: getWidth(self: PyOpenColorIO.ImageDesc) -> int
-
-      .. py:method:: getXStrideBytes(self: PyOpenColorIO.ImageDesc) -> int
-
-      .. py:method:: getYStrideBytes(self: PyOpenColorIO.ImageDesc) -> int
-
-      .. py:method:: isFloat(self: PyOpenColorIO.ImageDesc) -> bool
-
-      .. py:method:: isRGBAPacked(self: PyOpenColorIO.ImageDesc) -> bool

docs/api/c_look.rst

@@ -1,73 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Look
-****
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-The *Look* is an 'artistic' image modification, in a specified image state.
-
-The processSpace defines the ColorSpace the image is required to be in, for the math to apply correctly.
-
-**class Look**
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: LookRcPtr createEditableCopy() const
-
-      .. cpp:function:: const char *getName() const
-
-      .. cpp:function:: void setName(const char *name)
-
-      .. cpp:function:: const char *getProcessSpace() const
-
-      .. cpp:function:: void setProcessSpace(const char *processSpace)
-
-      .. cpp:function:: ConstTransformRcPtr getTransform() const
-
-      .. cpp:function:: void setTransform(const ConstTransformRcPtr &transform)
-
-         Setting a transform to a non-null call makes it allowed.
-
-      .. cpp:function:: ConstTransformRcPtr getInverseTransform() const
-
-      .. cpp:function:: void setInverseTransform(const ConstTransformRcPtr &transform)
-
-         Setting a transform to a non-null call makes it allowed.
-
-      .. cpp:function:: const char *getDescription() const
-
-      .. cpp:function:: void setDescription(const char *description)
-
-      .. cpp:function:: ~Look()
-
-      .. cpp:function:: LookRcPtr Create()
-
-
-   .. group-tab:: Python
-
-      .. py:method:: getDescription(self: PyOpenColorIO.Look) -> str
-
-      .. py:method:: getInverseTransform(self: PyOpenColorIO.Look) -> `PyOpenColorIO.Transform`_
-
-      .. py:method:: getName(self: PyOpenColorIO.Look) -> str
-
-      .. py:method:: getProcessSpace(self: PyOpenColorIO.Look) -> str
-
-      .. py:method:: getTransform(self: PyOpenColorIO.Look) -> `PyOpenColorIO.Transform`_
-
-      .. py:method:: setDescription(self: PyOpenColorIO.Look, description: str) -> None
-
-      .. py:method:: setInverseTransform(self: PyOpenColorIO.Look, transform: PyOpenColorIO.Transform) -> None
-
-      .. py:method:: setName(self: PyOpenColorIO.Look, name: str) -> None
-
-      .. py:method:: setProcessSpace(self: PyOpenColorIO.Look, processSpace: str) -> None
-
-      .. py:method:: setTransform(self: PyOpenColorIO.Look, transform: PyOpenColorIO.Transform) -> None

docs/api/c_packedimagedesc.rst

@@ -1,118 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-PackedImageDesc
-***************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class PackedImageDesc : public OpenColorIO::`ImageDesc`_**
-
-All the constructors expect a pointer to packed image data (such as
-rgbrgbrgb or rgbargbargba) starting at the first color channel of
-the first pixel to process (which does not need to be the first
-pixel of the image). The number of channels must be greater than or
-equal to 3. If a 4th channel is specified, it is assumed to be
-alpha information. Channels > 4 will be ignored.
-
-**Note**
-The methods assume the CPUProcessor bit-depth type for the data
-pointer.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: PackedImageDesc(void *data, long width, long height, long numChannels)
-
-         **Note**
-         numChannels must be 3 (RGB) or 4 (RGBA).
-
-      .. cpp:function:: PackedImageDesc(void *data, long width, long height, long numChannels, BitDepth bitDepth, ptrdiff_t chanStrideBytes, ptrdiff_t xStrideBytes, ptrdiff_t yStrideBytes)
-
-         **Note**
-         numChannels must be 3 (RGB) or 4 (RGBA).
-
-      .. cpp:function:: PackedImageDesc(void *data, long width, long height, ChannelOrdering chanOrder)
-
-      .. cpp:function:: PackedImageDesc(void *data, long width, long height, ChannelOrdering chanOrder, BitDepth bitDepth, ptrdiff_t chanStrideBytes, ptrdiff_t xStrideBytes, ptrdiff_t yStrideBytes)
-
-      .. cpp:function:: ~PackedImageDesc()
-
-      .. cpp:function:: ChannelOrdering getChannelOrder() const
-
-         Get the channel ordering of all the pixels.
-
-      .. cpp:function:: BitDepth getBitDepth() const override
-
-         Get the bit-depth.
-
-      .. cpp:function:: void *getData() const
-
-         Get a pointer to the first color channel of the first pixel.
-
-      .. cpp:function:: void *getRData() const override
-
-         Get a pointer to the red channel of the first pixel.
-
-      .. cpp:function:: void *getGData() const override
-
-         Get a pointer to the green channel of the first pixel.
-
-      .. cpp:function:: void *getBData() const override
-
-         Get a pointer to the blue channel of the first pixel.
-
-      .. cpp:function:: void *getAData() const override
-
-         Get a pointer to the alpha channel of the first pixel or null as
-         alpha channel is optional.
-
-      .. cpp:function:: long getWidth() const override
-
-         Get the width to process (where x position starts at 0 and ends
-         at width-1).
-
-      .. cpp:function:: long getHeight() const override
-
-         Get the height to process (where y position starts at 0 and ends
-         at height-1).
-
-      .. cpp:function:: long getNumChannels() const
-
-      .. cpp:function:: ptrdiff_t getChanStrideBytes() const
-
-      .. cpp:function:: ptrdiff_t getXStrideBytes() const override
-
-         Get the step in bytes to find the same color channel of the next
-         pixel.
-
-      .. cpp:function:: ptrdiff_t getYStrideBytes() const override
-
-         Get the step in bytes to find the same color channel of the
-         pixel at the same position in the next line.
-
-      .. cpp:function:: bool isRGBAPacked() const override
-
-         Is the image buffer in packed mode with the 4 color channels?
-         (“Packed” here means that XStrideBytes is 4x the bytes per
-         channel, so it is more specific than simply any
-         PackedImageDesc.)
-
-      .. cpp:function:: bool isFloat() const override
-
-         Is the image buffer 32-bit float?
-
-
-   .. group-tab:: Python
-
-      .. py:method:: getChanStrideBytes(self: PyOpenColorIO.PackedImageDesc) -> int
-
-      .. py:method:: getChannelOrder(self: PyOpenColorIO.PackedImageDesc) -> PyOpenColorIO.ChannelOrdering
-
-      .. py:method:: getData(self: PyOpenColorIO.PackedImageDesc) -> array
-
-      .. py:method:: getNumChannels(self: PyOpenColorIO.PackedImageDesc) -> int

docs/api/c_planarimagedesc.rst

@@ -1,100 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-PlanarImageDesc
-***************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class PlanarImageDesc : public OpenColorIO::`ImageDesc`_**
-
-All the constructors expect pointers to the specified image planes
-(i.e. rrrr gggg bbbb) starting at the first color channel of the
-first pixel to process (which need not be the first pixel of the
-image). Pass NULL for aData if no alpha exists (r/g/bData must not
-be NULL).
-
-**Note**
-The methods assume the CPUProcessor bit-depth type for the
-R/G/B/A data pointers.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: PlanarImageDesc(void *rData, void *gData, void *bData, void *aData, long width, long height)
-
-      .. cpp:function:: PlanarImageDesc(void *rData, void *gData, void *bData, void *aData, long width, long height, BitDepth bitDepth, ptrdiff_t xStrideBytes, ptrdiff_t yStrideBytes)
-
-         Note that although PlanarImageDesc is powerful enough to also
-         describe all :cpp:class:``PackedImageDesc`` scenarios, it is
-         recommended to use a PackedImageDesc where possible since that
-         allows for additional optimizations.
-
-      .. cpp:function:: ~PlanarImageDesc()
-
-      .. cpp:function:: void *getRData() const override
-
-         Get a pointer to the red channel of the first pixel.
-
-      .. cpp:function:: void *getGData() const override
-
-         Get a pointer to the green channel of the first pixel.
-
-      .. cpp:function:: void *getBData() const override
-
-         Get a pointer to the blue channel of the first pixel.
-
-      .. cpp:function:: void *getAData() const override
-
-         Get a pointer to the alpha channel of the first pixel or null as
-         alpha channel is optional.
-
-      .. cpp:function:: BitDepth getBitDepth() const override
-
-         Get the bit-depth.
-
-      .. cpp:function:: long getWidth() const override
-
-         Get the width to process (where x position starts at 0 and ends
-         at width-1).
-
-      .. cpp:function:: long getHeight() const override
-
-         Get the height to process (where y position starts at 0 and ends
-         at height-1).
-
-      .. cpp:function:: ptrdiff_t getXStrideBytes() const override
-
-         Get the step in bytes to find the same color channel of the next
-         pixel.
-
-      .. cpp:function:: ptrdiff_t getYStrideBytes() const override
-
-         Get the step in bytes to find the same color channel of the
-         pixel at the same position in the next line.
-
-      .. cpp:function:: bool isRGBAPacked() const override
-
-         Is the image buffer in packed mode with the 4 color channels?
-         (“Packed” here means that XStrideBytes is 4x the bytes per
-         channel, so it is more specific than simply any
-         PackedImageDesc.)
-
-      .. cpp:function:: bool isFloat() const override
-
-         Is the image buffer 32-bit float?
-
-
-   .. group-tab:: Python
-
-      .. py:method:: getAData(self: PyOpenColorIO.PlanarImageDesc) -> array
-
-      .. py:method:: getBData(self: PyOpenColorIO.PlanarImageDesc) -> array
-
-      .. py:method:: getGData(self: PyOpenColorIO.PlanarImageDesc) -> array
-
-      .. py:method:: getRData(self: PyOpenColorIO.PlanarImageDesc) -> array

docs/api/c_processor.rst

@@ -1,240 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Processor
-*********
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class Processor**
-
-The *Processor* represents a specific color transformation which is
-the result of :cpp:func:``Config::getProcessor``.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: bool isNoOp() const
-
-      .. cpp:function:: bool hasChannelCrosstalk() const
-
-         True if the image transformation is non-separable. For example,
-         if a change in red may also cause a change in green or blue.
-
-      .. cpp:function:: const char *getCacheID() const
-
-      .. cpp:function:: ConstProcessorMetadataRcPtr getProcessorMetadata() const
-
-         The ProcessorMetadata contains technical information such as the
-         number of files and looks used in the processor.
-
-      .. cpp:function:: const `FormatMetadata`_ &getFormatMetadata() const
-
-         Get a FormatMetadata containing the top level metadata for the
-         processor. For a processor from a CLF file, this corresponds to
-         the ProcessList metadata.
-
-      .. cpp:function:: int getNumTransforms() const
-
-         Get the number of transforms that comprise the processor. Each
-         transform has a (potentially empty) FormatMetadata.
-
-      .. cpp:function:: const `FormatMetadata`_ &getTransformFormatMetadata(int index) const
-
-         Get a FormatMetadata containing the metadata for a transform
-         within the processor. For a processor from a CLF file, this
-         corresponds to the metadata associated with an individual
-         process node.
-
-      .. cpp:function:: GroupTransformRcPtr createGroupTransform() const
-
-         Return a GroupTransform that contains a copy of the transforms
-         that comprise the processor. (Changes to it will not modify the
-         original processor.)
-
-      .. cpp:function:: void write(const char *formatName, std::ostream &os) const
-
-         Write the transforms comprising the processor to the stream.
-         Writing (as opposed to Baking) is a lossless process. An
-         exception is thrown if the processor cannot be losslessly
-         written to the specified file format.
-
-      .. cpp:function:: DynamicPropertyRcPtr getDynamicProperty(DynamicPropertyType type) const
-
-      .. cpp:function:: bool hasDynamicProperty(DynamicPropertyType type) const
-
-      .. cpp:function:: ConstProcessorRcPtr getOptimizedProcessor(OptimizationFlags oFlags) const
-
-         Run the optimizer on a Processor to create a new
-         :cpp:class:``Processor``. It is usually not necessary to call
-         this since getting a CPUProcessor or GPUProcessor will also
-         optimize. However if you need both, calling this method first
-         makes getting a CPU and GPU Processor faster since the
-         optimization is effectively only done once.
-
-      .. cpp:function:: ConstProcessorRcPtr getOptimizedProcessor(BitDepth inBD, BitDepth outBD, OptimizationFlags oFlags) const
-
-         Create a :cpp:class:``Processor`` that is optimized for a
-         specific in and out bit-depth (as CPUProcessor would do). This
-         method is provided primarily for diagnostic purposes.
-
-      .. cpp:function:: ConstGPUProcessorRcPtr getDefaultGPUProcessor() const
-
-         Get an optimized GPUProcessor instance.
-
-      .. cpp:function:: ConstGPUProcessorRcPtr getOptimizedGPUProcessor(OptimizationFlags oFlags) const
-
-      .. cpp:function:: ConstCPUProcessorRcPtr getDefaultCPUProcessor() const
-
-         Get an optimized :cpp:class:``CPUProcessor`` instance.
-
-         ::
-
-            OCIO::ConstConfigRcPtr config = OCIO::GetCurrentConfig();
-
-            OCIO::ConstProcessorRcPtr processor
-            = config->getProcessor(colorSpace1, colorSpace2);
-
-            OCIO::ConstCPUProcessorRcPtr cpuProcessor
-            = processor->getDefaultCPUProcessor();
-
-            OCIO::PackedImageDesc img(imgDataPtr, imgWidth, imgHeight, imgChannels);
-            cpuProcessor->apply(img);
-
-
-         **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.
-
-         **Note**
-         The typical use case to apply color processing to an image
-         is:
-
-      .. cpp:function:: ConstCPUProcessorRcPtr getOptimizedCPUProcessor(OptimizationFlags oFlags) const
-
-      .. cpp:function:: ConstCPUProcessorRcPtr getOptimizedCPUProcessor(BitDepth inBitDepth, BitDepth outBitDepth, OptimizationFlags oFlags) const
-      
-
-      .. cpp:function:: ~Processor()
-
-      -[ Public Static Functions ]-
-
-      .. cpp:function:: int getNumWriteFormats()
-
-         Get the number of writers.
-
-      .. cpp:function:: const char *getFormatNameByIndex(int index)
-
-         Get the writer at index, return empty string if an invalid index
-         is specified.
-
-      .. cpp:function:: const char *getFormatExtensionByIndex(int index)
-
-   .. group-tab:: Python
-
-      .. py:class:: TransformFormatMetadataIterator
-
-      .. py:class:: WriteFormatIterator
-
-      .. py:method:: createGroupTransform(self: PyOpenColorIO.Processor) -> `PyOpenColorIO.GroupTransform`_
-
-      .. py:method:: getCacheID(self: PyOpenColorIO.Processor) -> str
-
-      .. py:method:: getDefaultCPUProcessor(self: PyOpenColorIO.Processor) -> OpenColorIO_v2_0dev::CPUProcessor
-
-      .. py:method:: getDefaultGPUProcessor(self: PyOpenColorIO.Processor) -> OpenColorIO_v2_0dev::GPUProcessor
-
-      .. py:method:: getDynamicProperty(self: PyOpenColorIO.Processor, type: PyOpenColorIO.DynamicPropertyType) -> `PyOpenColorIO.DynamicProperty`_
-
-      .. py:method:: getFormatMetadata(self: PyOpenColorIO.Processor) -> `PyOpenColorIO.FormatMetadata`_
-
-      .. py:method:: getOptimizedCPUProcessor(*args,**kwargs)
-
-         Overloaded function.
-
-         1. ..py:method:: getOptimizedCPUProcessor(self: PyOpenColorIO.Processor, oFlags: PyOpenColorIO.OptimizationFlags) -> OpenColorIO_v2_0dev::CPUProcessor
-
-         2. ..py:method:: getOptimizedCPUProcessor(self: PyOpenColorIO.Processor, inBitDepth: PyOpenColorIO.BitDepth, outBitDepth: PyOpenColorIO.BitDepth, oFlags: PyOpenColorIO.OptimizationFlags) -> OpenColorIO_v2_0dev::CPUProcessor
-
-      .. py:method:: getOptimizedGPUProcessor(self: PyOpenColorIO.Processor, oFlags: PyOpenColorIO.OptimizationFlags) -> OpenColorIO_v2_0dev::GPUProcessor
-
-      .. py:method:: getOptimizedProcessor(*args,**kwargs)
-
-         Overloaded function.
-
-         1. ..py:method:: getOptimizedProcessor(self: PyOpenColorIO.Processor, oFlags: PyOpenColorIO.OptimizationFlags) -> PyOpenColorIO.Processor
-
-         2. ..py:method:: getOptimizedProcessor(self: PyOpenColorIO.Processor, inBitDepth: PyOpenColorIO.BitDepth, outBitDepth: PyOpenColorIO.BitDepth, oFlags: PyOpenColorIO.OptimizationFlags) -> PyOpenColorIO.Processor
-
-      .. py:method:: getProcessorMetadata(self: PyOpenColorIO.Processor) -> OpenColorIO_v2_0dev::ProcessorMetadata
-
-      .. py:method:: getTransformFormatMetadata(self: PyOpenColorIO.Processor) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Processor>, 1>
-
-      .. py:method:: static getWriteFormats() -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::Processor>, 0>
-
-      .. py:method:: hasChannelCrosstalk(self: PyOpenColorIO.Processor) -> bool
-
-      .. py:method:: hasDynamicProperty(self: PyOpenColorIO.Processor, type: PyOpenColorIO.DynamicPropertyType) -> bool
-
-      .. py:method:: isNoOp(self: PyOpenColorIO.Processor) -> bool
-
-      .. py:method:: write(*args,**kwargs)
-
-         Overloaded function.
-
-         1. ..py:method:: write(self: PyOpenColorIO.Processor, formatName: str,
-         fileName: str) -> None
-
-         2. ..py:method:: write(self: PyOpenColorIO.Processor, formatName: str) -> str
-
-
-   ProcessorMetadata
-   *****************
-
-   **class ProcessorMetadata**
-
-   This class contains meta information about the process that
-   generated this processor. The results of these functions do not
-   impact the pixel processing.
-
-
-.. tabs::
-
-   .. group-tab:: C++
-
-      .. cpp:function:: int getNumFiles() const
-
-      .. cpp:function:: const char *getFile(int index) const
-
-      .. cpp:function:: int getNumLooks() const
-
-      .. cpp:function:: const char *getLook(int index) const
-
-      .. cpp:function:: void addFile(const char *fname)
-
-      .. cpp:function:: void addLook(const char *look)
-
-      .. cpp:function:: ~ProcessorMetadata()
-
-      .. cpp:function:: ProcessorMetadataRcPtr Create()
-
-   .. group-tab:: Python
-
-      .. py:class:: FileIterator
-
-      .. py:class:: LookIterator
-
-      .. py:method:: addFile(self: PyOpenColorIO.ProcessorMetadata, fileName: str) -> None
-
-      .. py:method:: addLook(self: PyOpenColorIO.ProcessorMetadata, look: str) -> None
-
-      .. py:method:: getFiles(self: PyOpenColorIO.ProcessorMetadata) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ProcessorMetadata>, 0>
-
-      .. py:method:: getLooks(self: PyOpenColorIO.ProcessorMetadata) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ProcessorMetadata>, 1>

docs/api/c_viewingrules.rst

@@ -1,161 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-
-ViewingRules
-************
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-**class ViewingRules**
-
-
-.. tabs::
-
-    .. group-tab:: C++   
-
-        .. cpp:function:: ViewingRulesRcPtr createEditableCopy() const 
-
-            The method clones the content decoupling the two instances.
-
-        .. cpp:function:: size_t getNumEntries() const noexcept 
-
-        .. cpp:function:: size_t getIndexForRule(const char *ruleName) const 
-
-            Get the index from the rule name. Will throw if there is no rule
-            named ruleName.
-
-        .. cpp:function:: const char *getName(size_t ruleIndex) const 
-
-            Get name of the rule. Will throw if ruleIndex is invalid.
-
-        .. cpp:function:: size_t getNumColorSpaces(size_t ruleIndex) const 
-
-            Get number of colorspaces. Will throw if ruleIndex is invalid.
-
-        .. cpp:function:: const char *getColorSpace(size_t ruleIndex, size_t colorSpaceIndex) const 
-
-            Get colorspace name. Will throw if ruleIndex or colorSpaceIndex
-            is invalid.
-
-        .. cpp:function:: void addColorSpace(size_t ruleIndex, const char *colorSpace) 
-
-            Add colorspace name. Will throw if:
-
-            * RuleIndex is invalid.
-
-            * :cpp:func:```ViewingRules::getNumEncodings`_`` is not 0.
-
-        .. cpp:function:: void removeColorSpace(size_t ruleIndex, size_t colorSpaceIndex) 
-
-            Remove colorspace. Will throw if ruleIndex or colorSpaceIndex is
-            invalid.
-
-        .. cpp:function:: size_t getNumEncodings(size_t ruleIndex) const 
-
-            Get number of encodings. Will throw if ruleIndex is invalid.
-
-        .. cpp:function:: const char *getEncoding(size_t ruleIndex, size_t encodingIndex) const 
-
-            Get encoding name. Will throw if ruleIndex or encodingIndex is
-            invalid.
-
-        .. cpp:function:: void addEncoding(size_t ruleIndex, const char *encoding) 
-
-            Add encoding name. Will throw if:
-
-            * RuleIndex is invalid.
-
-            * :cpp:func:```ViewingRules::getNumColorSpaces`_`` is not 0.
-
-        .. cpp:function:: void removeEncoding(size_t ruleIndex, size_t encodingIndex) 
-
-            Remove encoding. Will throw if ruleIndex or encodingIndex is
-            invalid.
-
-        .. cpp:function:: size_t getNumCustomKeys(size_t ruleIndex) const 
-
-            Get number of key/value pairs. Will throw if ruleIndex is
-            invalid.
-
-        .. cpp:function:: const char *getCustomKeyName(size_t ruleIndex, size_t keyIndex) const 
-
-            Get name of key. Will throw if ruleIndex or keyIndex is invalid.
-
-        .. cpp:function:: const char *getCustomKeyValue(size_t ruleIndex, size_t keyIndex) const 
-
-            Get value for the key. Will throw if ruleIndex or keyIndex is
-            invalid.
-
-        .. cpp:function:: void setCustomKey(size_t ruleIndex, const char *key, const char *value) 
-
-            Adds a key/value or replace value if key exists. Setting a NULL
-            or an empty value will erase the key. Will throw if ruleIndex is
-            invalid.
-
-        .. cpp:function:: void insertRule(size_t ruleIndex, const char *ruleName) 
-
-            Insert a rule at a given ruleIndex.
-
-            Rule currently at ruleIndex will be pushed to index: ruleIndex +
-            1. If ruleIndex is :cpp:func:``ViewingRules::getNumEntries`` new
-            rule will be added at the end. Will throw if:
-
-            * RuleIndex is invalid (must be less than or equal to
-                cpp:func:`ViewingRules::getNumEntries`).
-
-            * RuleName already exists.
-
-        .. cpp:function:: void removeRule(size_t ruleIndex) 
-
-            Remove a rule. Throws if ruleIndex is not valid.
-
-        .. cpp:function:: ViewingRules(const ViewingRules&) = delete 
-
-        .. cpp:function:: `ViewingRules`_ &operator=(const ViewingRules&) = delete 
-
-        .. cpp:function:: ~ViewingRules() 
-
-        -[ Public Static Functions ]-
-
-        .. cpp:function:: ViewingRulesRcPtr Create() 
-
-            Creates ViewingRules for a Config.
-
-    .. group-tab:: Python
-
-        .. py:class:: ViewingRuleColorSpaceIterator
-
-        .. py:class:: ViewingRuleEncodingIterator
-
-        .. py:method:: addColorSpace(self: PyOpenColorIO.ViewingRules, ruleIndex: int, colorSpaceName: str) -> None
-
-        .. py:method:: addEncoding(self: PyOpenColorIO.ViewingRules, ruleIndex: int, encodingName: str) -> None
-
-        .. py:method:: getColorSpaces(self: PyOpenColorIO.ViewingRules, ruleIndex: int) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ViewingRules>, 0, unsigned long>
-
-        .. py:method:: getCustomKeyName(self: PyOpenColorIO.ViewingRules, ruleIndex: int, key: int) -> str
-
-        .. py:method:: getCustomKeyValue(self: PyOpenColorIO.ViewingRules, ruleIndex: int, key: int) -> str
-
-        .. py:method:: getEncodings(self: PyOpenColorIO.ViewingRules, ruleIndex: int) -> OpenColorIO_v2_0dev::PyIterator<std::shared_ptr<OpenColorIO_v2_0dev::ViewingRules>, 1, unsigned long>
-
-        .. py:method:: getIndexForRule(self: PyOpenColorIO.ViewingRules, ruleName: str) -> int
-
-        .. py:method:: getName(self: PyOpenColorIO.ViewingRules, ruleIndex: int) -> str
-
-        .. py:method:: getNumCustomKeys(self: PyOpenColorIO.ViewingRules, ruleIndex: int) -> int
-
-        .. py:method:: getNumEntries(self: PyOpenColorIO.ViewingRules) -> int
-
-        .. py:method:: insertRule(self: PyOpenColorIO.ViewingRules, ruleIndex: int, name: str) -> None
-
-        .. py:method:: removeColorSpace(self: PyOpenColorIO.ViewingRules, ruleIndex: int, colorSpaceIndex: int) -> None
-
-        .. py:method:: removeEncoding(self: PyOpenColorIO.ViewingRules, ruleIndex: int, encodingIndex: int) -> None
-
-        .. py:method:: removeRule(self: PyOpenColorIO.ViewingRules, ruleIndex: int) -> None
-
-        .. py:method:: setCustomKey(self: PyOpenColorIO.ViewingRules, ruleIndex: int, key: str, value: str) -> None

docs/api/change_log.rst

@@ -1,553 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-ChangeLog
-*********
-
-**Version 1.1.1 (April 2 2019):**
-   * Added optional compatibility for building apps with OpenImageIO
-      1.9+
-
-   * Added USE_SSE checks to fix Linux build failure
-
-   * getDisplays() result ordering now matches the active_displays
-      config definition or OCIO_ACTIVE_DISPLAYS env var override.
-
-   * Fixed incorrect getDefaultDisplay()/getDefaultView() result when
-      OCIO_ACTIVE_DISPLAYS or OCIO_ACTIVE_VIEWS env vars are unset.
-
-   * Fixed Windows-specific GetEnv() bug
-
-   * Fixed Windows and MacOS CI failure cases
-
-**Version 1.1.0 (Jan 5 2018):**
-   * libc++ build fixes
-
-   * Added support for YAML > 5.0.1
-
-   * YAML and TinyXML patch fixes
-
-   * Clang visibility fix
-
-   * Added write support for Truelight LUTs
-
-   * Improved OCIOYaml
-
-   * Python string corruption fix
-
-   * Added support for CDL
-
-   * Updated documentation
-
-   * Added args/kwargs support to Python MatrixTransform
-
-   * Added description field to Look objects
-
-   * Improved Python 3 compatibility
-
-   * CSP file read fix
-
-   * Added Linux, MacOS, and Windows continuos integration
-
-   * Improved 1D LUT extrapolation
-
-   * Improved 1D LUT negative handling
-
-   * Improved Windows build system
-
-   * Improved cross-platform build system
-
-   * Undefined role crash fix
-
-   * After Effects plugin updated
-
-   * Added reference Photoshop plugin
-
-   * Added reference Docker image
-
-**Version 1.0.9 (Sep 2 2013):**
-   * CDL cccid supports both named id and index lookups
-
-   * ociobakelut / ocioconvert updates
-
-   * FreeBSD compile dixes
-
-   * FileTransform disk cache allows concurrent disk lookups
-
-   * CSP windows fix
-
-   * Python 3 support
-
-   * Fix envvar abs/relative path testing
-
-   * Can explicitly declare config envvars
-
-   * gcc44 compile warning fixes
-
-**Version 1.0.8 (Dec 11 2012):**
-   * After Effects plugin
-
-   * Core increased precision for matrix inversion
-
-   * Core md5 symbols no longer leaked
-
-   * CMake compatibility with OIIO 1.0 namespacing
-
-   * Cmake option to control python soname
-
-   * Nuke register_viewers defaults OCIODisplay to “all”
-
-   * Nuke ColorLookup <-> spi1d lut examples
-
-   * Windows uses boost shared_ptr by default
-
-   * Windows fixed csp writing
-
-   * Windows build fixes
-
-   * ociobakelut supports looks
-
-**Version 1.0.7 (April 17 2012):**
-   * IRIDAS .look support
-
-   * ociolutimage utility added (handles image <-> 3dlut)
-
-   * CMake build allows optional reliance on system libraries
-
-   * CMake layout changes for python and nuke installs
-
-   * Bumped internals to yaml 0.3.0, pystring 1.1.2
-
-   * Optimized internal handling of Matrix / Exponent Ops
-
-   * Added INTERP_BEST interpolation option
-
-   * Python config.clearLooks() added
-
-   * Python docs revamp
-
-   * Nuke config-dependent knob values now baked into .nk scripts
-
-   * Nuke OCIOLookTransform gets reload button
-
-   * Nuke nodes get updated help text
-
-**Version 1.0.6 (March 12 2012):**
-   * JNI (Java) updates
-
-   * ocioconvert arbitrary attr support
-
-**Version 1.0.5 (Feb 22 2012):**
-   * Internal optimization framework added
-
-   * SetLoggingLevel(..) bugfix
-
-   * Python API Documentation / website updates
-
-   * Clang compilation fix
-
-**Version 1.0.4 (Jan 25 2012):**
-   * ocio2icc deprecated (functionality merged into ociobakelut)
-
-   * rv integration (beta)
-
-   * nuke: updated channel handling
-
-   * Documentation / website updates
-
-**Version 1.0.3 (Dec 21 2011):**
-   * Tetrahedral 3dlut interpolation (CPU only)
-
-   * ociocheck and Config.sanityCheck() have improved validation
-
-   * Mari: updated examples
-
-   * Makefile: misc updates to match distro library conventions
-
-**Version 1.0.2 (Nov 30 2011):**
-   * 3D lut processing (cpu) is resiliant to nans
-
-   * Nuke OCIOFileTransform gains Reload buttons
-
-   * Installation on multi-lib >>*<<nix systems improved
-
-   * Installation handling of soversion for C++/python improved
-
-   * ociobakelut improvements
-
-   * Initial version of Java bindings (alpha)
-
-**Version 1.0.1 (Oct 31 2011):**
-   * Luts with incorrect extension are properly loaded
-
-   * ocio2icc / ociobakelut get –lut option (no longer requires ocio
-      config)
-
-   * DisplayTransform looks do not apply to ‘data’ passes.
-
-**Version 1.0.0 (Oct 3 2011):**
-   * ABI Lockoff for 1.0 branch
-
-   * General API Cleanup (removed deprecated / unnecessary functions)
-
-   * New features can be added, but the ABI will only be extended in
-      a binary compatible manner. Profiles written from 1.0 will
-      always be readable in future versions.
-
-   * Fixed Truelight Reading Bug
-
-   * ocio2icc no longer requires ocio config (can provide raw lut(s)
-
-======================================================================
-
-**Version 0.8.7 (Oct 3 2011):**
-   * Fixed Truelight Reading Bug
-
-**Version 0.8.6 (Sept 7 2011):**
-   * Updated .ocio config reading / writing to be forwards
-      compatibile with 1.0 (Profiles written in 0.8.6+ will be 1.0
-      compatible. Compatibility from prior versions is likely, though
-      not guaranteed.)
-
-   * Better logging
-
-   * Added ColorSpace.equalitygroup (makes ColorSpace equality
-      explicit)
-
-   * Substantial Nuke node updates
-
-   * Added support for Iridas .itx read/write
-
-   * Windows Build Support
-
-**Version 0.8.5 (Aug 2 2011):**
-   * Nuke OCIODisplay fixed (bug from 0.8.4)
-
-   * Updated Houdini HDL Reader / Writer
-
-**Version 0.8.4 (July 25 2011):**
-   * Native Look Support
-
-   * Core / Nuke OCIODisplay supports alpha viewing
-
-   * Added Houdini (.lut) writing
-
-   * Added Pandora (.mga,.m3d) reading
-
-   * Additional internal bug fixes
-
-**Version 0.8.3 (June 27 2011):**
-   * OCIO::Config symlink resolution fixed (bugfix)
-
-   * Nuke OCIODisplay knobs use string storage (bugfix)
-
-   * Makefile cleanup
-
-   * Documentation cleanup
-
-**Version 0.8.2 (June 7 2011):**
-   * Numerous Windows compatibility fixes
-
-   * Python binding improvements
-
-   * OCIO::Baker / ociobakelut improvements
-
-   * Lut1D/3D do not crash on nans (bugfix)
-
-   * Nuke UI doesnt crash in known corner case (bugfix)
-
-**Version 0.8.1 (May 9 2011):**
-   * New roles: TEXTURE_PAINT + MATTE_PAINT
-
-   * Mari API Example (src/mari)
-
-   * FileFormat registry updated to allow Windows + Debug support
-
-   * boost_ptr build compatibility option
-
-**Version 0.8.0 (Apr 19 2011):**
-   * ABI Lockoff for stable 0.8 branch New features can be added, but
-      the ABI will only be extended in a binary compatible manner
-
-   * Otherwise identical to 0.7.9
-
-======================================================================
-
-**Version 0.7.9 (Apr 18 2011):**
-   * Added support for .vf luts
-
-   * Misc. Nuke enhancements
-
-   * Adds optional boost ptr support (backwards compatibility)
-
-   * Makefile enhancements (Nuke / CMAKE_INSTALL_EXEC_PREFIX)
-
-   * cdlTransform.setXML crash fix
-
-**Version 0.7.8 (March 31 2011):**
-   * Iridas lut (.cube) bugfix, DOMAIN_MIN / DOMAIN_MAX now obeyed
-
-   * Exposed GPU functions in python (needed for Mari)
-
-   * Nuke OCIODisplay cleanup: Fixed knob names and added envvar
-      support
-
-   * ociobaker cleanup
-
-   * tinyxml ABI visibility cleaned up
-
-   * Removed Boost dependency, tr1::shared_ptr now used instead
-
-**Version 0.7.7 (March 1 2011):**
-   * Lut baking API + standalone app
-
-   * Truelight runtime support (optional)
-
-   * Cinespace (3d) lut writing
-
-   * CSP prelut support
-
-   * Boost argparse dependency removed
-
-   * SanityCheck is more exhaustive
-
-   * FileTransform supports relative path dirs
-
-   * Python enhancements (transform kwarg support)
-
-   * Makefile enhancements (OIIO Path)
-
-   * Processor API update (code compatible, binary incompatible)
-
-**Version 0.7.6 (Feb 1 2011):**
-   * Updated Config Display API (.ocio config format updated)
-
-   * Added ocio2icc app (ICC Profile Generation)
-
-   * Revamp of ASC CDL, added .cc and .ccc support
-
-   * Documentation Improvements
-
-   * Makefile enhancements (Boost_INCLUDE_DIR, etc)
-
-**Version 0.7.5 (Jan 13 2011):**
-   * ociodisplay enhancements
-
-   * gpu display bugfix (glsl profile 1.0 only)
-
-   * Makefile enhancements
-
-   * Nuke installation cleanup
-
-   * Doc generation using sphinx (html + pdf)
-
-**Version 0.7.4 (Jan 4 2011):**
-   * Added ‘Context’, allowing for ‘per-shot’ Transforms
-
-   * Misc API Cleanup: removed old functions + fixed const-ness
-
-   * Added config.sanityCheck() for validation
-
-   * Additional Makefile configuration options, SONAME, etc.
-
-**Version 0.7.3 (Dec 16 2010):**
-   * Added example applications: ociodisplay, ocioconvert
-
-   * Makefile: Add boost header dependency
-
-   * Makefile: Nuke plugins are now version specific
-
-   * Fixed bug in GLSL MatrixOp
-
-**Version 0.7.2 (Dec 9 2010):**
-   * GPUAllocation refactor (API tweak)
-
-   * Added AllocationTransform
-
-   * Added LogTransform
-
-   * Removed CineonLogToLinTransform
-
-   * A few bug fixes
-
-**Version 0.7.1 (Nov 15 2010):**
-   * Additional 3d lut formats: Truelight .cub + Iridas .cube
-
-   * FileTransform supports envvars and search paths
-
-   * Added Nuke plugins: LogConvert + FileTransform
-
-   * Improved OCIO profile formatting
-
-   * GCC visibility used (when available) to hide private symbols
-
-   * A few bug fixes
-
-**Version 0.7.0 (Oct 21 2010):**
-   * Switched file format from XML to Yaml
-
-======================================================================
-
-**Version 0.6.1 (Oct 5 2010):**
-   * Exposed ExponentTransform
-
-   * Added CineonLogToLinTransform - a simple ‘straight-line’
-      negative linearization. Not strictly needed (could be done
-      previously with LUTs) but often convenient to have.
-
-   * Added DisplayTransform.displayCC for post display lut CC.
-
-   * Many python improvements
-
-   * A few bug fixes
-
-   * A few Makefile enhancements
-
-**Version 0.6.0 (Sept 21 2010):**
-   * Start of 0.6, “stable” branch
-
-      All 0.6.x builds will be ABI compatible (forward only). New
-      features (even experimental ones) will be added to the 0.6
-      branch, as long as binary and source compatibility is
-      maintained. Once this no longer is possible, a 0.7 “dev” branch
-      will be forked.
-
-   * Split public header into 3 parts for improved readability (you
-      still only import <OpenColorIO/OpenColorIO.h> though)
-
-   * Added MatrixTransform
-
-   * Refactored internal unit testing
-
-   * Fixed many compile warnings
-
-======================================================================
-
-**Version 0.5.16 (Sept 16 2010):**
-   * PyTransforms now use native python class inheritance
-
-   * OCIO namespace can now be configured at build time (for
-      distribution in commercial apps)
-
-   * Updated make install behavior
-
-   * DisplayTransform accepts generic cc operators (instead of CDL
-      only)
-
-   * A few bug fixes / compile warning fixes
-
-**Version 0.5.15 (Sept 8 2010):**
-   * OCIO is well behaved when $OCIO is unset, allowing
-      un-color-managed use.
-
-   * Color Transforms can be applied in python config->getProcessor
-
-   * Simplification of API (getColorSpace allows cs name, role names,
-      and cs objects)
-
-   * Makefile enhancements (courtesy Malcolm Humphreys)
-
-   * A bunch of bug fixes
-
-**Version 0.5.14 (Sept 1 2010):**
-   * Python binding enhancements
-
-   * Simplified class implmentations (reduced internal header count)
-
-**Version 0.5.13 (Aug 24 2010):**
-   * GPU Processing now supports High Dynamic Range color spaces
-
-   * Added log processing operator
-
-   * Numerous bug fixes
-
-   * Numerous enhancements to python glue
-
-   * Exposed PyOpenColorIO header, for use in apps that require
-      custom python glue
-
-   * Matrix op is optimized for diagonal-only subcases
-
-   * Numerous changes to Nuke Plugin (now with an addition node,
-      OCIODisplay)
-
-**Version 0.5.12 (Aug 18 2010):**
-   * Additional DisplayTransform improvements
-
-   * Additional GPU Improvements
-
-   * Added op hashing (processor->getGPULut3DCacheID)
-
-**Version 0.5.11 (Aug 11 2010):**
-   * Initial DisplayTransform implementation
-
-   * ASC CDL Support
-
-   * Config Luma coefficients
-
-**Version 0.5.10 (July 22 2010):**
-   * Updated Nuke Plugin, now works in OSX
-
-   * Fixed misc. build warnings.
-
-   * Continued GPU progress (still under development)
-
-**Version 0.5.9 (June 28 2010):**
-   * Renamed project, classes, namespaces to OpenColorIO (OCIO)
-
-   * Added single-pixel processor path
-
-   * Improved python path makefile detection
-
-   * Continued GPU progress (still under development)
-
-**Version 0.5.8 (June 22 2010):**
-   * Support for .3dl
-
-   * Support for matrix ops
-
-   * Code refactor (added Processors) to support gpu/cpu model
-
-   * Much better error checking
-
-   * Compilation support for python 2.5
-
-   * Compilation support for OSX
-
-**Version 0.5.7 (June 14 2010):**
-   * Python API is much more fleshed out
-
-   * Improved public C++ header
-
-**Version 0.5.6 (June 8 2010):**
-   * PyConfig stub implementation
-
-   * Dropped ImageDesc.init; added PlanarImageDesc / PackedImageDesc
-
-   * Dropped tr1::shared_ptr; added boost::shared_ptr
-
-**Version 0.5.5 (June 4 2010):**
-   * .ocio supports path references
-
-   * Switch config envvar to $OCIO
-
-   * Added 3D lut processing ops
-
-**Version 0.5.4 (June 1 2010):**
-   * Initial Release
-
-   * CMake linux support
-
-   * XML OCIO format parsing / saving
-
-   * Example colorspace configuration with a few ‘trivial’
-      colorspaces
-
-   * Mutable colorspace configuration API
-
-   * Support for 1D lut processing
-
-   * Support for SPI 1D fileformats.
-
-   * Nuke plugin

docs/api/colorspace.rst

@@ -0,0 +1,66 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+ColorSpace
+==========
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ColorSpace
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: ColorSpaceCategoryIterator, ColorSpaceAliasIterator
+
+      .. autoclass:: PyOpenColorIO.ColorSpace.ColorSpaceCategoryIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.ColorSpace.ColorSpaceAliasIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ColorSpace
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const ColorSpace&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstColorSpaceRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ColorSpaceRcPtr
+
+ColorSpaceSet
+=============
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceSet
+         :members:
+         :undoc-members:
+         :special-members: __init__, __eq__, __ne__, __sub__, __or__, __and__
+         :exclude-members: ColorSpaceNameIterator, ColorSpaceIterator
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceSet.ColorSpaceNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceSet.ColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ColorSpaceSet
+         :members:
+         :undoc-members:
+
+      .. doxygengroup:: ColorSpaceSetOperators
+         :content-only:
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstColorSpaceSetRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ColorSpaceSetRcPtr

docs/api/config.rst

@@ -0,0 +1,112 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Config
+======
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Config
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: EnvironmentVarNameIterator, 
+                           SearchPathIterator, 
+                           ColorSpaceNameIterator, 
+                           ColorSpaceIterator, 
+                           ActiveColorSpaceNameIterator, 
+                           ActiveColorSpaceIterator, 
+                           RoleNameIterator, 
+                           RoleColorSpaceIterator, 
+                           DisplayIterator, 
+                           SharedViewIterator, 
+                           ViewIterator, 
+                           ViewForColorSpaceIterator, 
+                           LookNameIterator, 
+                           LookIterator, 
+                           ViewTransformNameIterator, 
+                           ViewTransformIterator,
+                           NamedTransformNameIterator,
+                           NamedTransformIterator,
+                           ActiveNamedTransformNameIterator,
+                           ActiveNamedTransformIterator
+
+      .. autoclass:: PyOpenColorIO.Config.EnvironmentVarNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.SearchPathIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ColorSpaceNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ActiveColorSpaceNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ActiveColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.RoleNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.RoleColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.DisplayIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.SharedViewIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ViewIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ViewForColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.LookNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.LookIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ViewTransformNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ViewTransformIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.NamedTransformNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.NamedTransformIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ActiveNamedTransformNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Config.ActiveNamedTransformIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetCurrentConfig
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::SetCurrentConfig
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Config
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const Config&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstConfigRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConfigRcPtr
+
+Constants: :ref:`vars_roles`, :ref:`vars_shared_view`

docs/api/constants.rst

@@ -0,0 +1,267 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Constants
+=========
+
+.. _vars_envvar:
+
+Environment Variables
+*********************
+
+These environmental variables are used by the OpenColorIO library
+(i.e. these variables are defined in src/OpenColorIO/Config.cpp).
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. data:: PyOpenColorIO.OCIO_CONFIG_ENVVAR
+
+         The envvar 'OCIO' provides a path to the config file used by 
+         :ref:`Config.CreateFromEnv`
+
+      .. data:: PyOpenColorIO.OCIO_ACTIVE_DISPLAYS_ENVVAR
+
+          The envvar 'OCIO_ACTIVE_DISPLAYS' provides a list of displays 
+          overriding the 'active_displays' list from the config file.
+
+      .. data:: PyOpenColorIO.OCIO_ACTIVE_VIEWS_ENVVAR
+
+         The envvar 'OCIO_ACTIVE_VIEWS' provides a list of views overriding the 
+         'active_views' list from the config file.
+
+      .. data:: PyOpenColorIO.OCIO_INACTIVE_COLORSPACES_ENVVAR
+
+         The envvar 'OCIO_INACTIVE_COLORSPACES' provides a list of inactive 
+         color spaces overriding the 'inactive_color_spaces' list from the 
+         config file.
+
+      .. data:: PyOpenColorIO.OCIO_OPTIMIZATION_FLAGS_ENVVAR
+
+         The envvar 'OCIO_OPTIMIZATION_FLAGS' provides a way to force a given 
+         optimization level. Remove the variable or set the value to empty to 
+         not use it. Set the value of the variable to the desired optimization 
+         level as either an integer or hexadecimal value. 
+         Ex: OCIO_OPTIMIZATION_FLAGS="20479" or "0x4FFF" for 
+         OPTIMIZATION_LOSSLESS.
+
+   .. group-tab:: C++
+
+      .. doxygengroup:: VarsEnvvar
+         :content-only:
+         :members:
+         :undoc-members:
+
+.. _vars_roles:
+
+Roles
+*****
+
+ColorSpace Roles are used so that plugins, in addition to this API can have
+abstract ways of asking for common colorspaces, without referring to them
+by hardcoded names.
+
+Internal::
+
+    Extracting color space from file path - (ROLE_DEFAULT)
+
+App Helpers::
+
+    ViewingPipeline         - (ROLE_SCENE_LINEAR (LinearCC for exposure))
+                              (ROLE_COLOR_TIMING (ColorTimingCC))
+    MixingColorSpaceManager - (ROLE_COLOR_PICKING)
+
+External Plugins (currently known)::
+
+    Colorpicker UIs       - (ROLE_COLOR_PICKING)
+    Compositor LogConvert - (ROLE_SCENE_LINEAR, ROLE_COMPOSITING_LOG)
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. data:: PyOpenColorIO.ROLE_DEFAULT
+
+         "default"
+
+      .. data:: PyOpenColorIO.ROLE_REFERENCE
+
+         "reference"
+
+      .. data:: PyOpenColorIO.ROLE_DATA
+
+         "data"
+
+      .. data:: PyOpenColorIO.ROLE_COLOR_PICKING
+
+         "color_picking"
+
+      .. data:: PyOpenColorIO.ROLE_SCENE_LINEAR
+
+         "scene_linear"
+
+      .. data:: PyOpenColorIO.ROLE_COMPOSITING_LOG
+
+         "compositing_log"
+
+      .. data:: PyOpenColorIO.ROLE_COLOR_TIMING
+
+         "color_timing"
+
+      .. data:: PyOpenColorIO.ROLE_TEXTURE_PAINT
+
+         This role defines the transform for painting textures. In some 
+         workflows this is just a inverse display gamma with some limits.
+
+      .. data:: PyOpenColorIO.ROLE_MATTE_PAINT
+
+         This role defines the transform for matte painting. In some workflows 
+         this is a 1D HDR to LDR allocation. It is normally combined with 
+         another display transform in the host app for preview.
+
+      .. data:: PyOpenColorIO.ROLE_RENDERING
+
+         The rendering role may be used to identify a specific color space to be 
+         used by CGI renderers.  This is typically a scene-linear space but the 
+         primaries also matter since they influence the resulting color, especially 
+         in areas of indirect illumination.
+
+      .. data:: PyOpenColorIO.ROLE_INTERCHANGE_SCENE
+
+         The aces_interchange role is used to specify which color space in the 
+         config implements the standard ACES2065-1 color space (SMPTE ST2065-1). 
+         This may be used when converting scene-referred colors from one config 
+         to another.
+
+      .. data:: PyOpenColorIO.ROLE_INTERCHANGE_DISPLAY
+
+         The cie_xyz_d65_interchange role is used to specify which color space in 
+         the config implements CIE XYZ colorimetry with the neutral axis at D65. 
+         This may be used when converting display-referred colors from one config 
+         to another.
+
+   .. group-tab:: C++
+
+      .. doxygengroup:: VarsRoles
+         :content-only:
+         :members:
+         :undoc-members:
+
+.. _vars_shared_view:
+
+Shared View
+***********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. data:: PyOpenColorIO.OCIO_VIEW_USE_DISPLAY_NAME
+
+         A shared view using this for the color space name will use a display 
+         color space that has the same name as the display the shared view is 
+         used by.
+
+   .. group-tab:: C++
+
+      .. doxygengroup:: VarsSharedView
+         :content-only:
+         :members:
+         :undoc-members:
+
+.. _vars_format_metadata:
+
+FormatMetadata
+**************
+
+These constants describe various types of rich metadata. They are used with 
+FormatMetadata objects as the "name" part of a (name, value) pair. All of these 
+types of metadata are supported in the CLF/CTF file formats whereas other 
+formats support some or none of them.
+
+Although the string constants used here match those used in the CLF/CTF 
+formats, the concepts are generic, so the goal is for other file formats to 
+reuse the same constants within a FormatMetadata object (even if the syntax 
+used in a given format is somewhat different).
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. data:: PyOpenColorIO.METADATA_DESCRIPTION
+
+         A description string -- used as the "Description" element in CLF/CTF 
+         and CDL, and to hold comments for other LUT formats when baking.
+
+      .. data:: PyOpenColorIO.METADATA_INFO
+
+         A block of informative metadata such as the "Info" element in CLF/CTF. 
+         Usually contains child elements.
+
+      .. data:: PyOpenColorIO.METADATA_INPUT_DESCRIPTOR
+
+         A string describing the expected input color space -- used as the 
+         "InputDescriptor" element in CLF/CTF and the "InputDescription" in 
+         CDL.
+
+      .. data:: PyOpenColorIO.METADATA_OUTPUT_DESCRIPTOR
+
+         A string describing the output color space -- used as the 
+         "OutputDescriptor" element in CLF/CTF and the "OutputDescription" in 
+         CDL.
+
+      .. data:: PyOpenColorIO.METADATA_NAME
+
+         A name string -- used as a "name" attribute in CLF/CTF elements. Use 
+         on a GroupTransform to get/set the name for the CLF/CTF ProcessList. 
+         Use on an individual Transform (i.e. MatrixTransform, etc.) to get/set 
+         the name of the corresponding process node.
+
+      .. data:: PyOpenColorIO.METADATA_ID
+
+         An ID string -- used as an "id" attribute in CLF/CTF elements. Use on 
+         a GroupTransform to get/set the id for the CLF/CTF ProcessList. Use 
+         on an individual Transform (i.e. MatrixTransform, etc.) to get/set the 
+         id of the corresponding process node.
+
+   .. group-tab:: C++
+
+      .. doxygengroup:: VarsFormatMetadata
+         :content-only:
+         :members:
+         :undoc-members:
+
+.. _vars_caches:
+
+Caches
+******
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. data:: PyOpenColorIO.OCIO_DISABLE_ALL_CACHES
+
+         Disable all caches, including for FileTransforms and Optimized/CPU/GPU 
+         Processors. (Provided only to facilitate developer investigations.)
+
+      .. data:: PyOpenColorIO.OCIO_DISABLE_PROCESSOR_CACHES
+
+         Disable only the Optimized, CPU, and GPU Processor caches. (Provided 
+         only to facilitate developer investigations.)
+
+      .. data:: PyOpenColorIO.OCIO_DISABLE_CACHE_FALLBACK
+
+         By default the processor caches check for identical color 
+         transformations when cache keys do not match. That fallback introduces 
+         a major performance hit in some cases so there is an env. variable to 
+         disable the fallback.
+
+   .. group-tab:: C++
+
+      .. doxygengroup:: VarsCaches
+         :content-only:
+         :members:
+         :undoc-members:

docs/api/context.rst

@@ -0,0 +1,38 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Context
+=======
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Context
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: StringVarNameIterator, 
+                           StringVarIterator, 
+                           SearchPathIterator
+
+      .. autoclass:: PyOpenColorIO.Context.StringVarNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Context.StringVarIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.Context.SearchPathIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Context
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const Context&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstContextRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ContextRcPtr

docs/api/dynamicproperty.rst

@@ -0,0 +1,89 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+DynamicProperty
+===============
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.DynamicProperty
+         :members:
+         :undoc-members:
+         :special-members: __init__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::DynamicProperty
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstDynamicPropertyRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::DynamicPropertyRcPtr
+
+DynamicPropertyValue
+====================
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygennamespace:: ${OCIO_NAMESPACE}::DynamicPropertyValue
+
+DynamicPropertyDouble
+=====================
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::DynamicPropertyDouble
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstDynamicPropertyDoubleRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::DynamicPropertyDoubleRcPtr
+
+DynamicPropertyGradingPrimary
+=============================
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::DynamicPropertyGradingPrimary
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstDynamicPropertyGradingPrimaryRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::DynamicPropertyGradingPrimaryRcPtr
+
+DynamicPropertyGradingRGBCurve
+==============================
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::DynamicPropertyGradingRGBCurve
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstDynamicPropertyGradingRGBCurveRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::DynamicPropertyGradingRGBCurveRcPtr
+
+DynamicPropertyGradingTone
+==========================
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::DynamicPropertyGradingTone
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstDynamicPropertyGradingToneRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::DynamicPropertyGradingToneRcPtr

docs/api/enums.rst

@@ -0,0 +1,484 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Enums
+=====
+
+LoggingLevel
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.LoggingLevel
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::LoggingLevel
+
+Conversions: :ref:`conversion_logging_level`
+
+ReferenceSpaceType
+******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ReferenceSpaceType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ReferenceSpaceType
+
+SearchReferenceSpaceType
+************************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.SearchReferenceSpaceType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::SearchReferenceSpaceType
+
+NamedTransformVisibility
+************************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.NamedTransformVisibility
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::NamedTransformVisibility
+
+ColorSpaceVisibility
+********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceVisibility
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ColorSpaceVisibility
+
+ViewType
+********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ViewType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ViewType
+
+ColorSpaceDirection
+*******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ColorSpaceDirection
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ColorSpaceDirection
+
+Conversions: :ref:`conversion_color_space_direction`
+
+ViewTransformDirection
+**********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ViewTransformDirection
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ViewTransformDirection
+
+.. _enum_transform_direction:
+
+TransformDirection
+******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.TransformDirection
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::TransformDirection
+
+Conversions: :ref:`conversion_transform_direction`
+
+TransformType
+*************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.TransformType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::TransformType
+
+Interpolation
+*************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Interpolation
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::Interpolation
+
+Conversions: :ref:`conversion_interpolation`
+
+BitDepth
+********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.BitDepth
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::BitDepth
+
+Conversions: :ref:`conversion_bit_depth`
+
+Lut1DHueAdjust
+**************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Lut1DHueAdjust
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::Lut1DHueAdjust
+
+ChannelOrdering
+***************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ChannelOrdering
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ChannelOrdering
+
+Allocation
+**********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Allocation
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::Allocation
+
+Conversions: :ref:`conversion_allocation`
+
+GpuLanguage
+***********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GpuLanguage
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::GpuLanguage
+
+Conversions: :ref:`conversion_gpu_language`
+
+EnvironmentMode
+***************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.EnvironmentMode
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::EnvironmentMode
+
+Conversions: :ref:`conversion_environment_mode`
+
+RangeStyle
+**********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.RangeStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::RangeStyle
+
+Conversions: :ref:`conversion_range_style`
+
+FixedFunctionStyle
+******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.FixedFunctionStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::FixedFunctionStyle
+
+Conversions: :ref:`conversion_fixed_function_style`
+
+ExposureContrastStyle
+*********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ExposureContrastStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ExposureContrastStyle
+
+Conversions: :ref:`conversion_exposure_contrast_style`
+
+CDLStyle
+********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.CDLStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::CDLStyle
+
+Conversions: :ref:`conversion_cdl_style`
+
+NegativeStyle
+*************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.NegativeStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::NegativeStyle
+
+Conversions: :ref:`conversion_negative_style`
+
+GradingStyle
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingStyle
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::GradingStyle
+
+Conversions: :ref:`conversion_grading_style`
+
+DynamicPropertyType
+*******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.DynamicPropertyType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::DynamicPropertyType
+
+RGBCurveType
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.RGBCurveType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::RGBCurveType
+
+UniformDataType
+***************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.UniformDataType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::UniformDataType
+
+OptimizationFlags
+*****************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.OptimizationFlags
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::OptimizationFlags
+
+ProcessorCacheFlags
+*******************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ProcessorCacheFlags
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+   .. group-tab:: C++
+
+      .. doxygenenum:: ${OCIO_NAMESPACE}::ProcessorCacheFlags

docs/api/exceptions.rst

@@ -0,0 +1,24 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Exceptions
+==========
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoexception:: PyOpenColorIO.Exception
+
+      .. autoexception:: PyOpenColorIO.ExceptionMissingFile
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Exception
+         :members:
+         :undoc-members:
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ExceptionMissingFile
+         :members:
+         :undoc-members:

docs/api/formatmetadata.rst

@@ -0,0 +1,46 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+FormatMetadata
+==============
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.FormatMetadata
+         :members:
+         :undoc-members:
+         :special-members: __init__, 
+                           __iter__, 
+                           __len__, 
+                           __getitem__, 
+                           __setitem__, 
+                           __contains__
+         :exclude-members: AttributeNameIterator,
+                           AttributeIterator,
+                           ConstChildElementIterator,
+                           ChildElementIterator
+
+      .. autoclass:: PyOpenColorIO.FormatMetadata.AttributeNameIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.FormatMetadata.AttributeIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.FormatMetadata.ConstChildElementIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.FormatMetadata.ChildElementIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::FormatMetadata
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const FormatMetadata&)
+
+Constants: :ref:`vars_format_metadata`

docs/api/global.rst

@@ -0,0 +1,416 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Global
+======
+
+Caching
+*******
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.ClearAllCaches
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::ClearAllCaches
+
+Constants: :ref:`vars_caches`
+
+Version
+*******
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.GetVersion
+
+      .. autofunction:: PyOpenColorIO.GetVersionHex
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetVersion
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetVersionHex
+
+Logging
+*******
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.GetLoggingLevel
+
+      .. autofunction:: PyOpenColorIO.SetLoggingLevel
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetLoggingLevel
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::SetLoggingLevel
+
+Logging Function
+^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.SetLoggingFunction
+
+      .. autofunction:: PyOpenColorIO.ResetToDefaultLoggingFunction
+
+      .. autofunction:: PyOpenColorIO.LogMessage
+
+   .. group-tab:: C++
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::LoggingFunction
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::SetLoggingFunction
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::ResetToDefaultLoggingFunction
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::LogMessage
+
+Compute Hash Function
+*********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.SetComputeHashFunction
+
+      .. autofunction:: PyOpenColorIO.ResetComputeHashFunction
+
+   .. group-tab:: C++
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ComputeHashFunction
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::SetComputeHashFunction
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::ResetComputeHashFunction
+
+Environment Variables
+*********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.GetEnvVariable
+
+      .. autofunction:: PyOpenColorIO.SetEnvVariable
+
+      .. autofunction:: PyOpenColorIO.UnsetEnvVariable
+
+      .. autofunction:: PyOpenColorIO.IsEnvVariablePresent
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetEnvVariable
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::SetEnvVariable
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::UnsetEnvVariable
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::IsEnvVariablePresent
+
+Constants: :ref:`vars_envvar`
+
+Casting
+*******
+
+.. tabs::
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::DynamicPtrCast
+
+Conversions
+***********
+
+Bool
+^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.BoolToString
+
+      .. autofunction:: PyOpenColorIO.BoolFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BoolToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BoolFromString
+
+.. _conversion_logging_level:
+
+LoggingLevel
+^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.LoggingLevelToString
+
+      .. autofunction:: PyOpenColorIO.LoggingLevelFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::LoggingLevelToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::LoggingLevelFromString
+
+.. _conversion_transform_direction:
+
+TransformDirection
+^^^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.TransformDirectionToString
+
+      .. autofunction:: PyOpenColorIO.TransformDirectionFromString
+
+      .. autofunction:: PyOpenColorIO.GetInverseTransformDirection
+
+      .. autofunction:: PyOpenColorIO.CombineTransformDirections
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::TransformDirectionToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::TransformDirectionFromString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GetInverseTransformDirection
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::CombineTransformDirections
+
+.. _conversion_bit_depth:
+
+BitDepth
+^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.BitDepthToString
+
+      .. autofunction:: PyOpenColorIO.BitDepthFromString
+
+      .. autofunction:: PyOpenColorIO.BitDepthIsFloat
+
+      .. autofunction:: PyOpenColorIO.BitDepthToInt
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BitDepthToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BitDepthFromString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BitDepthIsFloat
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::BitDepthToInt
+
+.. _conversion_allocation:
+
+Allocation
+^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.AllocationToString
+
+      .. autofunction:: PyOpenColorIO.AllocationFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::AllocationToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::AllocationFromString
+
+.. _conversion_interpolation:
+
+Interpolation
+^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.InterpolationToString
+
+      .. autofunction:: PyOpenColorIO.InterpolationFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::InterpolationToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::InterpolationFromString
+
+.. _conversion_gpu_language:
+
+GpuLanguage
+^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.GpuLanguageToString
+
+      .. autofunction:: PyOpenColorIO.GpuLanguageFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GpuLanguageToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GpuLanguageFromString
+
+.. _conversion_environment_mode:
+
+EnvironmentMode
+^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.EnvironmentModeToString
+
+      .. autofunction:: PyOpenColorIO.EnvironmentModeFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::EnvironmentModeToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::EnvironmentModeFromString
+
+.. _conversion_cdl_style:
+
+CDLStyle
+^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.CDLStyleToString
+
+      .. autofunction:: PyOpenColorIO.CDLStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::CDLStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::CDLStyleFromString
+
+.. _conversion_range_style:
+
+RangeStyle
+^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.RangeStyleToString
+
+      .. autofunction:: PyOpenColorIO.RangeStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::RangeStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::RangeStyleFromString
+
+.. _conversion_fixed_function_style:
+
+FixedFunctionStyle
+^^^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.FixedFunctionStyleToString
+
+      .. autofunction:: PyOpenColorIO.FixedFunctionStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::FixedFunctionStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::FixedFunctionStyleFromString
+
+.. _conversion_grading_style:
+
+GradingStyle
+^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.GradingStyleToString
+
+      .. autofunction:: PyOpenColorIO.GradingStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GradingStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::GradingStyleFromString
+
+.. _conversion_exposure_contrast_style:
+
+ExposureContrastStyle
+^^^^^^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.ExposureContrastStyleToString
+
+      .. autofunction:: PyOpenColorIO.ExposureContrastStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::ExposureContrastStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::ExposureContrastStyleFromString
+
+.. _conversion_negative_style:
+
+NegativeStyle
+^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autofunction:: PyOpenColorIO.NegativeStyleToString
+
+      .. autofunction:: PyOpenColorIO.NegativeStyleFromString
+
+   .. group-tab:: C++
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::NegativeStyleToString
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::NegativeStyleFromString

docs/api/grading_transforms.rst

@@ -0,0 +1,277 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+.. _grading_transforms:
+
+Grading Transforms
+==================
+
+GradingPrimaryTransform
+***********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingPrimaryTransform
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingPrimaryTransform
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingPrimaryTransform&) noexcept
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingPrimaryTransformRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingPrimaryTransformRcPtr
+
+GradingPrimary
+^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingPrimary
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenstruct:: ${OCIO_NAMESPACE}::GradingPrimary
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingPrimary&)
+
+GradingRGBM
+^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingRGBM
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenstruct:: ${OCIO_NAMESPACE}::GradingRGBM
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingRGBM&)
+
+GradingRGBCurveTransform
+************************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingRGBCurveTransform
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingRGBCurveTransform
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingRGBCurveTransform&) noexcept
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingRGBCurveTransformRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingRGBCurveTransformRcPtr
+
+GradingRGBCurve
+^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingRGBCurve
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingRGBCurve
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingRGBCurve&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingRGBCurveRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingRGBCurveRcPtr
+
+GradingHueCurveTransform
+************************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingHueCurveTransform
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingHueCurveTransform
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingHueCurveTransform&) noexcept
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingHueCurveTransformRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingHueCurveTransformRcPtr
+
+GradingHueCurve
+^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingHueCurve
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingHueCurve
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingHueCurve&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingHueCurveRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingHueCurveRcPtr
+
+GradingControlPoint
+^^^^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingControlPoint
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenstruct:: ${OCIO_NAMESPACE}::GradingControlPoint
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingControlPoint&)
+
+GradingBSplineCurve
+^^^^^^^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingBSplineCurve
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: GradingControlPointIterator
+
+      .. autoclass:: PyOpenColorIO.GradingBSplineCurve.GradingControlPointIterator
+         :special-members: __getitem__, __setitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingBSplineCurve
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingBSplineCurve&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingBSplineCurveRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingBSplineCurveRcPtr
+
+GradingToneTransform
+********************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingToneTransform
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GradingToneTransform
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingToneTransform&) noexcept
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGradingToneTransformRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GradingToneTransformRcPtr
+
+GradingTone
+^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingTone
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenstruct:: ${OCIO_NAMESPACE}::GradingTone
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingTone&)
+
+GradingRGBMSW
+^^^^^^^^^^^^^
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GradingRGBMSW
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenstruct:: ${OCIO_NAMESPACE}::GradingRGBMSW
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const GradingRGBMSW&)

docs/api/imagedesc.rst

@@ -0,0 +1,70 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+ImageDesc
+=========
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ImageDesc
+         :members:
+         :undoc-members:
+         :special-members: __init__
+
+      .. py:data:: AutoStride
+         :module: PyOpenColorIO
+         :type: int
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ImageDesc
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const ImageDesc&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstImageDescRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ImageDescRcPtr
+
+      .. doxygenvariable:: ${OCIO_NAMESPACE}::AutoStride
+
+PackedImageDesc
+***************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.PackedImageDesc
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::PackedImageDesc
+         :members:
+         :undoc-members:
+
+PlanarImageDesc
+***************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.PlanarImageDesc
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :inherited-members:
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::PlanarImageDesc
+         :members:
+         :undoc-members:

docs/api/look.rst

@@ -0,0 +1,26 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Look
+====
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Look
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Look
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const Look&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstLookRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::LookRcPtr

docs/api/namedtransform.rst

@@ -0,0 +1,30 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Named Transform
+===============
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.NamedTransform
+         :members:
+         :undoc-members:
+         :special-members: __init__, __str__
+         :exclude-members: NamedTransformCategoryIterator
+
+      .. autoclass:: PyOpenColorIO.NamedTransform.NamedTransformCategoryIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::NamedTransform
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const NamedTransform&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstNamedTransformRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::NamedTransformRcPtr

docs/api/processors.rst

@@ -0,0 +1,101 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Processors
+==========
+
+Processor
+*********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.Processor
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: TransformFormatMetadataIterator, WriteFormatIterator
+
+      .. autoclass:: PyOpenColorIO.Processor.TransformFormatMetadataIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::Processor
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstProcessorRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ProcessorRcPtr
+
+CPUProcessor
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.CPUProcessor
+         :members:
+         :undoc-members:
+         :special-members: __init__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::CPUProcessor
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstCPUProcessorRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::CPUProcessorRcPtr
+
+GPUProcessor
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GPUProcessor
+         :members:
+         :undoc-members:
+         :special-members: __init__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GPUProcessor
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGPUProcessorRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GPUProcessorRcPtr
+
+ProcessorMetadata
+*****************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ProcessorMetadata
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: FileIterator, LookIterator
+
+      .. autoclass:: PyOpenColorIO.ProcessorMetadata.FileIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.ProcessorMetadata.LookIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ProcessorMetadata
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstProcessorMetadataRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ProcessorMetadataRcPtr

docs/api/rules.rst

@@ -0,0 +1,59 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Rules
+=====
+
+FileRules
+*********
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.FileRules
+         :members:
+         :undoc-members:
+         :special-members: __init__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::FileRules
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const FileRules&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstFileRulesRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::FileRulesRcPtr
+
+ViewingRules
+************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.ViewingRules
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: ViewingRuleColorSpaceIterator, ViewingRuleEncodingIterator
+
+      .. autoclass:: PyOpenColorIO.ViewingRules.ViewingRuleColorSpaceIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.ViewingRules.ViewingRuleEncodingIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::ViewingRules
+         :members:
+         :undoc-members:
+
+      .. doxygenfunction:: ${OCIO_NAMESPACE}::operator<<(std::ostream&, const ViewingRules&)
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstViewingRulesRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ViewingRulesRcPtr

docs/api/shaders.rst

@@ -0,0 +1,99 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+Shaders
+=======
+
+GpuShaderCreator
+****************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GpuShaderCreator
+         :members:
+         :undoc-members:
+         :exclude-members: TextureType, 
+                           TEXTURE_RED_CHANNEL, 
+                           TEXTURE_RGB_CHANNEL, 
+                           DynamicPropertyIterator
+
+      .. autoclass:: PyOpenColorIO.GpuShaderCreator.TextureType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+      .. autoclass:: PyOpenColorIO.GpuShaderCreator.DynamicPropertyIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GpuShaderCreator
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGpuShaderCreatorRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GpuShaderCreatorRcPtr
+
+GpuShaderDesc
+*************
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: TextureType, 
+                           TEXTURE_RED_CHANNEL, 
+                           TEXTURE_RGB_CHANNEL, 
+                           UniformData,
+                           Texture, 
+                           Texture3D, 
+                           UniformIterator,
+                           TextureIterator, 
+                           Texture3DIterator,
+                           DynamicPropertyIterator
+         :inherited-members:
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.TextureType
+         :members:
+         :undoc-members:
+         :exclude-members: name
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.UniformData
+         :members:
+         :undoc-members:
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.Texture
+         :members:
+         :undoc-members:
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.Texture3D
+         :members:
+         :undoc-members:
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.UniformIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.TextureIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.Texture3DIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+      .. autoclass:: PyOpenColorIO.GpuShaderDesc.DynamicPropertyIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::GpuShaderDesc
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstGpuShaderDescRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::GpuShaderDescRcPtr

docs/api/systemmonitors.rst

@@ -0,0 +1,28 @@
+..
+  SPDX-License-Identifier: CC-BY-4.0
+  Copyright Contributors to the OpenColorIO Project.
+
+SystemMonitors
+==============
+
+.. tabs::
+
+   .. group-tab:: Python
+
+      .. autoclass:: PyOpenColorIO.SystemMonitors
+         :members:
+         :undoc-members:
+         :special-members: __init__
+         :exclude-members: MonitorIterator
+
+      .. autoclass:: PyOpenColorIO.SystemMonitors.MonitorIterator
+         :special-members: __getitem__, __iter__, __len__, __next__
+
+   .. group-tab:: C++
+
+      .. doxygenclass:: ${OCIO_NAMESPACE}::SystemMonitors
+         :members:
+         :undoc-members:
+
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::ConstSystemMonitorsRcPtr
+      .. doxygentypedef:: ${OCIO_NAMESPACE}::SystemMonitorsRcPtr

docs/api/types.rst

@@ -1,964 +0,0 @@
-..
-  SPDX-License-Identifier: CC-BY-4.0
-  Copyright Contributors to the OpenColorIO Project.
-
-Types
-*****
-
-.. CAUTION::
-   API Docs are a work in progress, expect them to improve over time.
-
-
-
-LoggingLevel 
-============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::LoggingLevel 
-
-            *Values:*
-
-            .. cpp:enumerator:: LOGGING_LEVEL_NONE = 0 
-
-            .. cpp:enumerator:: LOGGING_LEVEL_WARNING = 1 
-
-            .. cpp:enumerator:: LOGGING_LEVEL_INFO = 2 
-
-            .. cpp:enumerator:: LOGGING_LEVEL_DEBUG = 3 
-
-            .. cpp:enumerator:: LOGGING_LEVEL_UNKNOWN = 255 
-
-            .. cpp:enumerator:: LOGGING_LEVEL_DEFAULT = `LOGGING_LEVEL_INFO`_ 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.LoggingLevel
-
-            Members:
-
-            * LOGGING_LEVEL_NONE
-
-            * LOGGING_LEVEL_WARNING
-
-            * LOGGING_LEVEL_INFO
-
-            * LOGGING_LEVEL_DEBUG
-
-            * LOGGING_LEVEL_UNKNOWN
-
-ReferenceSpaceType 
-==================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ReferenceSpaceType 
-
-            OCIO does not mandate the image state of the main reference space
-            and it is not required to be scene-referred. This enum is used in
-            connection with the display color space and view transform features
-            which do assume that the main reference space is scene-referred and
-            the display reference space is display-referred. If a config used a
-            non-scene-referred reference space, presumably it would not use
-            either display color spaces or view transforms, so this enum
-            becomes irrelevant.
-
-            *Values:*
-
-            .. cpp:enumerator:: REFERENCE_SPACE_SCENE = 0 
-
-                the main scene reference space
-
-            .. cpp:enumerator:: REFERENCE_SPACE_DISPLAY 
-
-                the reference space for display color spaces
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ReferenceSpaceType
-
-            Members:
-
-            * REFERENCE_SPACE_SCENE
-
-            * REFERENCE_SPACE_DISPLAY
-
-SearchReferenceSpaceType 
-========================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::SearchReferenceSpaceType 
-
-            *Values:*
-
-            .. cpp:enumerator:: SEARCH_REFERENCE_SPACE_SCENE = 0 
-
-            .. cpp:enumerator:: SEARCH_REFERENCE_SPACE_DISPLAY 
-
-            .. cpp:enumerator:: SEARCH_REFERENCE_SPACE_ALL
-
-   .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.SearchReferenceSpaceType
-
-            Members:
-
-            * SEARCH_REFERENCE_SPACE_SCENE
-
-            * SEARCH_REFERENCE_SPACE_DISPLAY
-
-            * SEARCH_REFERENCE_SPACE_ALL
-
-ColorSpaceVisibility 
-====================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ColorSpaceVisibility 
-
-            *Values:*
-
-            .. cpp:enumerator:: COLORSPACE_ACTIVE = 0 
-
-            .. cpp:enumerator:: COLORSPACE_INACTIVE 
-
-            .. cpp:enumerator:: COLORSPACE_ALL 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ColorSpaceVisibility
-
-            Members:
-
-            * COLORSPACE_ACTIVE
-
-            * COLORSPACE_INACTIVE
-
-            * COLORSPACE_ALL
-
-ColorSpaceDirection 
-===================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ColorSpaceDirection 
-
-            *Values:*
-
-            .. cpp:enumerator:: COLORSPACE_DIR_UNKNOWN = 0 
-
-            .. cpp:enumerator:: COLORSPACE_DIR_TO_REFERENCE 
-
-            .. cpp:enumerator:: COLORSPACE_DIR_FROM_REFERENCE
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ColorSpaceDirection
-
-            Members:
-
-            * COLORSPACE_DIR_UNKNOWN
-
-            * COLORSPACE_DIR_TO_REFERENCE
-
-            * COLORSPACE_DIR_FROM_REFERENCE
-
-ViewTransformDirection 
-======================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ViewTransformDirection 
-
-            *Values:*
-
-            .. cpp:enumerator:: VIEWTRANSFORM_DIR_UNKNOWN = 0 
-
-            .. cpp:enumerator:: VIEWTRANSFORM_DIR_TO_REFERENCE 
-
-            .. cpp:enumerator:: VIEWTRANSFORM_DIR_FROM_REFERENCE 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ViewTransformDirection
-
-            Members:
-
-            * VIEWTRANSFORM_DIR_UNKNOWN
-
-            * VIEWTRANSFORM_DIR_TO_REFERENCE
-
-            * VIEWTRANSFORM_DIR_FROM_REFERENCE
-
-TransformDirection 
-==================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::TransformDirection 
-
-            *Values:*
-
-            .. cpp:enumerator:: TRANSFORM_DIR_UNKNOWN = 0 
-
-            .. cpp:enumerator:: TRANSFORM_DIR_FORWARD 
-
-            .. cpp:enumerator:: TRANSFORM_DIR_INVERSE 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.TransformDirection
-
-            Members:
-
-            * TRANSFORM_DIR_UNKNOWN
-
-            * TRANSFORM_DIR_FORWARD
-
-            * TRANSFORM_DIR_INVERSE
-
-Interpolation 
-=============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::Interpolation 
-
-            Specify the interpolation type to use If the specified
-            interpolation type is not supported in the requested context (for
-            example, using tetrahedral interpolationon 1D LUTs) an exception
-            will be thrown.
-
-            INTERP_DEFAULT will choose the default interpolation type for the
-            requested context:
-
-            1D LUT INTERP_DEFAULT: LINEAR 3D LUT INTERP_DEFAULT: LINEAR
-
-            INTERP_BEST will choose the best interpolation type for the
-            requested context:
-
-            1D LUT INTERP_BEST: LINEAR 3D LUT INTERP_BEST: TETRAHEDRAL
-
-            Note: INTERP_BEST and INTERP_DEFAULT are subject to change in minor
-            releases, so if you care about locking off on a specific
-            interpolation type, we’d recommend directly specifying it.
-
-            *Values:*
-
-            .. cpp:enumerator:: INTERP_UNKNOWN = 0 
-
-            .. cpp:enumerator:: INTERP_NEAREST = 1 
-
-                nearest neighbor
-
-            .. cpp:enumerator:: INTERP_LINEAR = 2 
-
-                linear interpolation (trilinear for Lut3D)
-
-            .. cpp:enumerator:: INTERP_TETRAHEDRAL = 3 
-
-                tetrahedral interpolation (Lut3D only)
-
-            .. cpp:enumerator:: INTERP_CUBIC = 4 
-
-                cubic interpolation (not supported)
-
-            .. cpp:enumerator:: INTERP_DEFAULT = 254 
-
-                the default interpolation type
-
-            .. cpp:enumerator:: INTERP_BEST = 255 
-
-                the ‘best’ suitable interpolation type
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.Interpolation
-
-            Members:
-
-            * INTERP_UNKNOWN
-
-            * INTERP_NEAREST
-
-            * INTERP_LINEAR
-
-            * INTERP_TETRAHEDRAL
-
-            * INTERP_CUBIC
-
-            * INTERP_DEFAULT
-
-            * INTERP_BEST
-
-
-BitDepth 
-========
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::BitDepth 
-
-            Used in a configuration file to indicate the bit-depth of a color
-            space, and by the Processor to specify the input and output
-            bit-depths of images to process. Note that Processor only supports:
-            UINT8, UINT10, UINT12, UINT16, F16 and F32.
-
-            *Values:*
-
-            .. cpp:enumerator:: BIT_DEPTH_UNKNOWN = 0 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT8 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT10 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT12 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT14 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT16 
-
-            .. cpp:enumerator:: BIT_DEPTH_UINT32 
-
-            .. cpp:enumerator:: BIT_DEPTH_F16 
-
-            .. cpp:enumerator:: BIT_DEPTH_F32 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.BitDepth
-
-            Members:
-
-            * BIT_DEPTH_UNKNOWN
-
-            * BIT_DEPTH_UINT8
-
-            * BIT_DEPTH_UINT10
-
-            * BIT_DEPTH_UINT12
-
-            * BIT_DEPTH_UINT14
-
-            * BIT_DEPTH_UINT16
-
-            * BIT_DEPTH_UINT32
-
-            * BIT_DEPTH_F16
-
-            * BIT_DEPTH_F32
-
-Lut1DHueAdjust 
-==============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::Lut1DHueAdjust 
-
-            Used by :cpp:classLut1DTransform to control optional hue
-            restoration algorithm.
-
-            *Values:*
-
-            .. cpp:enumerator:: HUE_NONE = 0 
-
-            .. cpp:enumerator:: HUE_DW3 
-
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.Lut1DHueAdjust
-
-            Members:
-
-            * HUE_NONE
-
-            * HUE_DW3
-
-ChannelOrdering 
-===============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ChannelOrdering 
-
-            Used by PackedImageDesc to indicate the channel ordering of the
-            image to process.
-
-            *Values:*
-
-            .. cpp:enumerator:: CHANNEL_ORDERING_RGBA = 0 
-
-            .. cpp:enumerator:: CHANNEL_ORDERING_BGRA 
-
-            .. cpp:enumerator:: CHANNEL_ORDERING_ABGR 
-
-            .. cpp:enumerator:: CHANNEL_ORDERING_RGB 
-
-            .. cpp:enumerator:: CHANNEL_ORDERING_BGR 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ChannelOrdering
-
-            Members:
-
-            * CHANNEL_ORDERING_RGBA
-
-            * CHANNEL_ORDERING_BGRA
-
-            * CHANNEL_ORDERING_ABGR
-
-            * CHANNEL_ORDERING_RGB
-
-            * CHANNEL_ORDERING_BGR
-
-Allocation 
-==========
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::Allocation 
-
-            *Values:*
-
-            .. cpp:enumerator:: ALLOCATION_UNKNOWN = 0 
-
-            .. cpp:enumerator:: ALLOCATION_UNIFORM 
-
-            .. cpp:enumerator:: ALLOCATION_LG2 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.Allocation
-
-            Members:
-
-            * ALLOCATION_UNKNOWN
-
-            * ALLOCATION_UNIFORM
-
-            * ALLOCATION_LG2
-
-GpuLanguage 
-===========
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::GpuLanguage 
-
-            Used when there is a choice of hardware shader language.
-
-            *Values:*
-
-            .. cpp:enumerator:: GPU_LANGUAGE_UNKNOWN = 0 
-
-            .. cpp:enumerator:: GPU_LANGUAGE_CG 
-
-                Nvidia Cg shader.
-
-            .. cpp:enumerator:: GPU_LANGUAGE_GLSL_1_0 
-
-                OpenGL Shading Language.
-
-            .. cpp:enumerator:: GPU_LANGUAGE_GLSL_1_3 
-
-                OpenGL Shading Language.
-
-            .. cpp:enumerator:: GPU_LANGUAGE_GLSL_4_0 
-
-                OpenGL Shading Language.
-
-            .. cpp:enumerator:: GPU_LANGUAGE_HLSL_DX11 
-
-                DirectX Shading Language.
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.GpuLanguage
-
-            Members:
-
-            * GPU_LANGUAGE_UNKNOWN
-
-            * GPU_LANGUAGE_CG
-
-            * GPU_LANGUAGE_GLSL_1_0
-
-            * GPU_LANGUAGE_GLSL_1_3
-
-            * GPU_LANGUAGE_GLSL_4_0
-
-            * GPU_LANGUAGE_HLSL_DX11
-
-EnvironmentMode 
-===============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::EnvironmentMode 
-
-            *Values:*
-
-            .. cpp:enumerator:: ENV_ENVIRONMENT_UNKNOWN = 0 
-
-            .. cpp:enumerator:: ENV_ENVIRONMENT_LOAD_PREDEFINED 
-
-            .. cpp:enumerator:: ENV_ENVIRONMENT_LOAD_ALL 
-
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.EnvironmentMode
-
-            Members:
-
-            * ENV_ENVIRONMENT_UNKNOWN
-
-            * ENV_ENVIRONMENT_LOAD_PREDEFINED
-
-            * ENV_ENVIRONMENT_LOAD_ALL
-
-RangeStyle 
-==========
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::RangeStyle 
-
-            A RangeTransform may be set to clamp the values, or not.
-
-            *Values:*
-
-            .. cpp:enumerator:: RANGE_NO_CLAMP = 0 
-
-            .. cpp:enumerator:: RANGE_CLAMP 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.RangeStyle
-
-            Members:
-
-            * RANGE_NO_CLAMP
-
-            * RANGE_CLAMP
-
-FixedFunctionStyle 
-==================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::FixedFunctionStyle 
-
-            Enumeration of the :cpp:class:FixedFunctionTransform transform
-            algorithms.
-
-            *Values:*
-
-            .. cpp:enumerator:: FIXED_FUNCTION_ACES_RED_MOD_03 = 0 
-
-                Red modifier (ACES 0.3/0.7)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_ACES_RED_MOD_10 
-
-                Red modifier (ACES 1.0)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_ACES_GLOW_03 
-
-                Glow function (ACES 0.3/0.7)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_ACES_GLOW_10 
-
-                Glow function (ACES 1.0)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_ACES_DARK_TO_DIM_10 
-
-                Dark to dim surround correction (ACES 1.0)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_REC2100_SURROUND 
-
-                Rec.2100 surround correction (takes one double for the gamma
-                param)
-
-            .. cpp:enumerator:: FIXED_FUNCTION_RGB_TO_HSV 
-
-                Classic RGB to HSV function.
-
-            .. cpp:enumerator:: FIXED_FUNCTION_XYZ_TO_xyY 
-
-                CIE XYZ to 1931 xy chromaticity coordinates.
-
-            .. cpp:enumerator:: FIXED_FUNCTION_XYZ_TO_uvY 
-
-                CIE XYZ to 1976 u’v’ chromaticity coordinates.
-
-            .. cpp:enumerator:: FIXED_FUNCTION_XYZ_TO_LUV 
-
-                CIE XYZ to 1976 CIELUV colour space (D65 white)
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.FixedFunctionStyle
-
-            Members:
-
-            * FIXED_FUNCTION_ACES_RED_MOD_03
-
-            * FIXED_FUNCTION_ACES_RED_MOD_10
-
-            * FIXED_FUNCTION_ACES_GLOW_03
-
-            * FIXED_FUNCTION_ACES_GLOW_10
-
-            * FIXED_FUNCTION_ACES_DARK_TO_DIM_10
-
-            * FIXED_FUNCTION_REC2100_SURROUND
-
-            * FIXED_FUNCTION_RGB_TO_HSV
-
-            * FIXED_FUNCTION_XYZ_TO_xyY
-
-            * FIXED_FUNCTION_XYZ_TO_uvY
-
-            * FIXED_FUNCTION_XYZ_TO_LUV
-
-ExposureContrastStyle 
-=====================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::ExposureContrastStyle 
-
-            Enumeration of the :cpp:class:ExposureContrastTransform
-            transform algorithms.
-
-            *Values:*
-
-            .. cpp:enumerator:: EXPOSURE_CONTRAST_LINEAR = 0 
-
-                E/C to be applied to a linear space image.
-
-            .. cpp:enumerator:: EXPOSURE_CONTRAST_VIDEO 
-
-                E/C to be applied to a video space image.
-
-            .. cpp:enumerator:: EXPOSURE_CONTRAST_LOGARITHMIC 
-
-                E/C to be applied to a log space image.
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.ExposureContrastStyle
-
-            Members:
-
-            * EXPOSURE_CONTRAST_LINEAR
-
-            * EXPOSURE_CONTRAST_VIDEO
-
-            * EXPOSURE_CONTRAST_LOGARITHMIC
-
-CDLStyle 
-========
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::CDLStyle 
-
-            Enumeration of the :cpp:class:CDLTransform transform
-            algorithms.
-
-            **Note**
-                The default for reading .cc/.ccc/.cdl files, config file YAML,
-                and CDLTransform is no-clamp, since that is what is primarily
-                desired in VFX. However, the CLF format default is ASC.
-
-            *Values:*
-
-            .. cpp:enumerator:: CDL_ASC = 0 
-
-                ASC CDL specification v1.2.
-
-            .. cpp:enumerator:: CDL_NO_CLAMP 
-
-                CDL that does not clamp.
-
-            .. cpp:enumerator:: CDL_TRANSFORM_DEFAULT = `CDL_NO_CLAMP`_ 
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.CDLStyle
-
-            Members:
-
-            * CDL_ASC
-
-            * CDL_NO_CLAMP
-
-            * CDL_TRANSFORM_DEFAULT
-
-NegativeStyle
-=============
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::NegativeStyle 
-
-            Negative values handling style for ExponentTransform and
-            ExponentWithLinearTransform transform algorithms.
-
-            *Values:*
-
-            .. cpp:enumerator:: NEGATIVE_CLAMP = 0 
-
-                Clamp negative values.
-
-            .. cpp:enumerator:: NEGATIVE_MIRROR 
-
-                Positive curve is rotated 180 degrees around the origin to
-                handle negatives.
-
-            .. cpp:enumerator:: NEGATIVE_PASS_THRU 
-
-                Negative values are passed through unchanged.
-
-            .. cpp:enumerator:: NEGATIVE_LINEAR 
-
-                Linearly extrapolate the curve for negative values.
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.NegativeStyle
-
-            Members:
-
-            * NEGATIVE_CLAMP
-
-            * NEGATIVE_MIRROR
-
-            * NEGATIVE_PASS_THRU
-
-            * NEGATIVE_LINEAR
-
-DynamicPropertyType 
-===================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::DynamicPropertyType 
-
-            *Values:*
-
-            .. cpp:enumerator:: DYNAMIC_PROPERTY_EXPOSURE = 0 
-
-                Image exposure value (double floating point value)
-
-            .. cpp:enumerator:: DYNAMIC_PROPERTY_CONTRAST 
-
-                Image contrast value (double floating point value)
-
-            .. cpp:enumerator:: DYNAMIC_PROPERTY_GAMMA 
-
-                Image gamma value (double floating point value)
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.DynamicPropertyType
-
-            Members:
-
-            * DYNAMIC_PROPERTY_EXPOSURE
-
-            * DYNAMIC_PROPERTY_CONTRAST
-
-            * DYNAMIC_PROPERTY_GAMMA
-
-OptimizationFlags 
-=================
-
-.. tabs::
-
-    .. group-tab:: C++
-
-        .. cpp:enum:: OpenColorIO::OptimizationFlags 
-
-            Provides control over how the ops in a Processor are combined in
-            order to improve performance.
-
-            *Values:*
-
-            .. cpp:enumerator:: OPTIMIZATION_NONE = 0x00000000 
-
-                Do not optimize.
-
-            .. cpp:enumerator:: OPTIMIZATION_IDENTITY = 0x00000001 
-
-                Replace identity ops (other than gamma).
-
-            .. cpp:enumerator:: OPTIMIZATION_IDENTITY_GAMMA = 0x00000002 
-
-                Replace identity gamma ops.
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_CDL = 0x00000004 
-
-                Replace a pair of ops where one is the inverse of the other.
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_EXPOSURE_CONTRAST =
-            0x00000008 
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_FIXED_FUNCTION = 0x00000010
-            
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_GAMMA = 0x00000020 
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_LUT1D = 0x00000040 
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_LUT3D = 0x00000080 
-
-            .. cpp:enumerator:: OPTIMIZATION_PAIR_IDENTITY_LOG = 0x00000100 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_EXPONENT = 0x00000200 
-
-                Compose a pair of ops into a single op.
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_GAMMA = 0x00000400 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_MATRIX = 0x00000800 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_LUT1D = 0x00001000 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_LUT3D = 0x00002000 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_RANGE = 0x00004000 
-
-            .. cpp:enumerator:: OPTIMIZATION_COMP_SEPARABLE_PREFIX = 0x00008000 
-
-                For integer and half bit-depths only, replace separable ops
-                (i.e. no channel crosstalk ops) by a single 1D LUT of input
-                bit-depth domain.
-
-            .. cpp:enumerator:: OPTIMIZATION_LUT_INV_FAST = 0x00010000 
-
-                Implement inverse Lut1D and Lut3D evaluations using a a forward
-                LUT (faster but less accurate). Note that GPU evals always do
-                FAST.
-
-            .. cpp:enumerator:: OPTIMIZATION_NO_DYNAMIC_PROPERTIES = 0x00020000 
-
-                Turn off dynamic control of any ops that offer adjustment of
-                parameter values after finalization (e.g. ExposureContrast).
-
-            .. cpp:enumerator:: OPTIMIZATION_ALL = 0xFFFFFFFF 
-
-                Apply all possible optimizations.
-
-            .. cpp:enumerator:: OPTIMIZATION_LOSSLESS = (`OPTIMIZATION_IDENTITY`_ | `OPTIMIZATION_IDENTITY_GAMMA`_ | `OPTIMIZATION_PAIR_IDENTITY_CDL`_ | `OPTIMIZATION_PAIR_IDENTITY_EXPOSURE_CONTRAST`_ | `OPTIMIZATION_PAIR_IDENTITY_FIXED_FUNCTION`_ | `OPTIMIZATION_PAIR_IDENTITY_GAMMA`_ | `OPTIMIZATION_PAIR_IDENTITY_LOG`_ | `OPTIMIZATION_PAIR_IDENTITY_LUT1D`_ | `OPTIMIZATION_PAIR_IDENTITY_LUT3D`_ | `OPTIMIZATION_COMP_EXPONENT`_ | `OPTIMIZATION_COMP_GAMMA`_ | `OPTIMIZATION_COMP_MATRIX`_ | `OPTIMIZATION_COMP_RANGE`_) 
-
-            .. cpp:enumerator:: OPTIMIZATION_VERY_GOOD = (`OPTIMIZATION_LOSSLESS`_ | `OPTIMIZATION_COMP_LUT1D`_ | `OPTIMIZATION_LUT_INV_FAST`_ | `OPTIMIZATION_COMP_SEPARABLE_PREFIX`_) 
-
-            .. cpp:enumerator:: OPTIMIZATION_GOOD = `OPTIMIZATION_VERY_GOOD`_ | `OPTIMIZATION_COMP_LUT3D`_ 
-
-            .. cpp:enumerator:: OPTIMIZATION_DRAFT = `OPTIMIZATION_ALL`_ 
-
-                For quite lossy optimizations.
-
-            .. cpp:enumerator:: OPTIMIZATION_DEFAULT = `OPTIMIZATION_VERY_GOOD`_ 
-
-
-    .. group-tab:: Python
-
-        .. py:class:: PyOpenColorIO.OptimizationFlags
-
-            Members:
-
-            * OPTIMIZATION_NONE
-
-            * OPTIMIZATION_IDENTITY
-
-            * OPTIMIZATION_IDENTITY_GAMMA
-
-            * OPTIMIZATION_PAIR_IDENTITY_CDL
-
-            * OPTIMIZATION_PAIR_IDENTITY_EXPOSURE_CONTRAST
-
-            * OPTIMIZATION_PAIR_IDENTITY_FIXED_FUNCTION
-
-            * OPTIMIZATION_PAIR_IDENTITY_GAMMA
-
-            * OPTIMIZATION_PAIR_IDENTITY_LUT1D
-
-            * OPTIMIZATION_PAIR_IDENTITY_LUT3D
-
-            * OPTIMIZATION_PAIR_IDENTITY_LOG
-
-            * OPTIMIZATION_COMP_EXPONENT
-
-            * OPTIMIZATION_COMP_GAMMA
-
-            * OPTIMIZATION_COMP_MATRIX
-
-            * OPTIMIZATION_COMP_LUT1D
-
-            * OPTIMIZATION_COMP_LUT3D
-
-            * OPTIMIZATION_COMP_RANGE
-
-            * OPTIMIZATION_COMP_SEPARABLE_PREFIX
-
-            * OPTIMIZATION_LUT_INV_FAST
-
-            * OPTIMIZATION_NO_DYNAMIC_PROPERTIES
-
-            * OPTIMIZATION_ALL
-
-            * OPTIMIZATION_LOSSLESS
-
-            * OPTIMIZATION_VERY_GOOD
-
-            * OPTIMIZATION_GOOD
-
-            * OPTIMIZATION_DRAFT
-
-            * OPTIMIZATION_DEFAULT