As discussed with @michdolan just 5 minutes ago, the codebase is growing, maturing and stabilising thus we should start looking at implementing some unit testing or general tests at least to protect the functionality.

At the moment, I periodically uses and launch the modules where I purposely put a __main__ clause. Maybe we could start there and turn those sections into tests and verify their output:

References

• https://leica-camera.com/sites/default/files/pm-65976-210914__L-Log_Reference_Manual_EN.pdf
• https://github.com/colour-science/colour/blob/develop/colour/models/rgb/transfer_functions/leica_llog.py

The named transforms such as Rec.1886 - Curve convert from gamma-encoded to linear values. The description says the opposite.

It's easy to miss when reading the YAML due to the double inverse (inverse_transform with direction set to inverse).

The descriptions of the named transforms for camera logs are correct.

Following the docker build instructions as follows:

1. git clone https://github.com/AcademySoftwareFoundation/OpenColorIO-Config-ACES.git
2. cd OpenColorIO-Config-ACES
3. sudo docker build -t aswf/opencolorio-config-aces:latest .

Hits an error on step 11, when it goes to pip install the requirements.txt file. Most things work correctly, but pygraphwiz errors.

Step 11/14 : RUN pip install -r requirements.txt     && rm /tmp/requirements.txt
 ---> Running in fca7bd02c30f
Collecting alabaster==0.7.12
  Downloading alabaster-0.7.12-py2.py3-none-any.whl (14 kB)
Collecting appdirs==1.4.4
  Downloading appdirs-1.4.4-py2.py3-none-any.whl (9.6 kB)
Collecting attrs==21.2.0
  Downloading attrs-21.2.0-py2.py3-none-any.whl (53 kB)
Collecting Babel==2.9.1
  Downloading Babel-2.9.1-py2.py3-none-any.whl (8.8 MB)
Collecting bleach==3.3.0
  Downloading bleach-3.3.0-py2.py3-none-any.whl (283 kB)
Collecting certifi==2021.5.30
  Downloading certifi-2021.5.30-py2.py3-none-any.whl (145 kB)
Collecting cfgv==3.3.0
  Downloading cfgv-3.3.0-py2.py3-none-any.whl (7.3 kB)
Collecting chardet==4.0.0
  Downloading chardet-4.0.0-py2.py3-none-any.whl (178 kB)
Collecting colorama==0.4.4
  Downloading colorama-0.4.4-py2.py3-none-any.whl (16 kB)
Collecting colour-science==0.3.16
  Downloading colour_science-0.3.16-py2.py3-none-any.whl (2.1 MB)
Collecting coverage==5.5
  Downloading coverage-5.5-cp37-cp37m-manylinux2010_x86_64.whl (242 kB)
Collecting coveralls==3.1.0
  Downloading coveralls-3.1.0-py2.py3-none-any.whl (14 kB)
Collecting decorator==4.4.2
  Downloading decorator-4.4.2-py2.py3-none-any.whl (9.2 kB)
Collecting distlib==0.3.2
  Downloading distlib-0.3.2-py2.py3-none-any.whl (338 kB)
Collecting docopt==0.6.2
  Downloading docopt-0.6.2.tar.gz (25 kB)
Requirement already satisfied: docutils==0.16 in /usr/local/lib/python3.7/site-packages (from -r requirements.txt (line 16)) (0.16)
Collecting filelock==3.0.12
  Downloading filelock-3.0.12-py3-none-any.whl (7.6 kB)
Collecting flake8==3.9.2
  Downloading flake8-3.9.2-py2.py3-none-any.whl (73 kB)
Collecting identify==2.2.10
  Downloading identify-2.2.10-py2.py3-none-any.whl (98 kB)
Collecting idna==2.10
  Downloading idna-2.10-py2.py3-none-any.whl (58 kB)
Collecting imageio==2.9.0
  Downloading imageio-2.9.0-py3-none-any.whl (3.3 MB)
Collecting imagesize==1.2.0
  Downloading imagesize-1.2.0-py2.py3-none-any.whl (4.8 kB)
Collecting importlib-metadata==4.6.1
  Downloading importlib_metadata-4.6.1-py3-none-any.whl (17 kB)
Collecting iniconfig==1.1.1
  Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting invoke==1.5.0
  Downloading invoke-1.5.0-py3-none-any.whl (211 kB)
Collecting Jinja2==3.0.1
  Downloading Jinja2-3.0.1-py3-none-any.whl (133 kB)
Collecting jsonpickle==2.0.0
  Downloading jsonpickle-2.0.0-py2.py3-none-any.whl (37 kB)
Collecting keyring==23.0.1
  Downloading keyring-23.0.1-py3-none-any.whl (33 kB)
Collecting MarkupSafe==2.0.1
  Downloading MarkupSafe-2.0.1-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.manylinux_2_12_x86_64.manylinux2010_x86_64.whl (31 kB)
Collecting mccabe==0.6.1
  Downloading mccabe-0.6.1-py2.py3-none-any.whl (8.6 kB)
Collecting networkx==2.5.1
  Downloading networkx-2.5.1-py3-none-any.whl (1.6 MB)
Collecting nodeenv==1.6.0
  Downloading nodeenv-1.6.0-py2.py3-none-any.whl (21 kB)
Requirement already satisfied: nose==1.3.7 in /usr/local/lib/python3.7/site-packages (from -r requirements.txt (line 33)) (1.3.7)
Collecting numpy==1.21.0
  Downloading numpy-1.21.0-cp37-cp37m-manylinux_2_12_x86_64.manylinux2010_x86_64.whl (15.7 MB)
Collecting packaging==21.0
  Downloading packaging-21.0-py3-none-any.whl (40 kB)
Collecting Pillow==8.3.0
  Downloading Pillow-8.3.0-cp37-cp37m-manylinux_2_5_x86_64.manylinux1_x86_64.whl (3.0 MB)
Collecting pip==21.1.1
  Downloading pip-21.1.1-py3-none-any.whl (1.5 MB)
Collecting pkginfo==1.7.0
  Downloading pkginfo-1.7.0-py2.py3-none-any.whl (25 kB)
Collecting pluggy==0.13.1
  Downloading pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting pre-commit==2.13.0
  Downloading pre_commit-2.13.0-py2.py3-none-any.whl (190 kB)
Collecting py==1.10.0
  Downloading py-1.10.0-py2.py3-none-any.whl (97 kB)
Collecting pycodestyle==2.7.0
  Downloading pycodestyle-2.7.0-py2.py3-none-any.whl (41 kB)
Collecting pyflakes==2.3.1
  Downloading pyflakes-2.3.1-py2.py3-none-any.whl (68 kB)
Collecting Pygments==2.9.0
  Downloading Pygments-2.9.0-py3-none-any.whl (1.0 MB)
Collecting pygraphviz==1.7
  Downloading pygraphviz-1.7.zip (118 kB)
Collecting pyparsing==2.4.7
  Downloading pyparsing-2.4.7-py2.py3-none-any.whl (67 kB)
Collecting pytest==6.2.4
  Downloading pytest-6.2.4-py3-none-any.whl (280 kB)
Collecting pytz==2021.1
  Downloading pytz-2021.1-py2.py3-none-any.whl (510 kB)
Collecting PyYAML==5.4.1
  Downloading PyYAML-5.4.1-cp37-cp37m-manylinux1_x86_64.whl (636 kB)
Collecting readme-renderer==29.0
  Downloading readme_renderer-29.0-py2.py3-none-any.whl (15 kB)
Collecting requests==2.25.1
  Downloading requests-2.25.1-py2.py3-none-any.whl (61 kB)
Collecting requests-toolbelt==0.9.1
  Downloading requests_toolbelt-0.9.1-py2.py3-none-any.whl (54 kB)
Collecting restructuredtext-lint==1.3.2
  Downloading restructuredtext_lint-1.3.2.tar.gz (13 kB)
Collecting rfc3986==1.5.0
  Downloading rfc3986-1.5.0-py2.py3-none-any.whl (31 kB)
Collecting scipy==1.6.1
  Downloading scipy-1.6.1-cp37-cp37m-manylinux1_x86_64.whl (27.4 MB)
Collecting setuptools==56.2.0
  Downloading setuptools-56.2.0-py3-none-any.whl (785 kB)
Collecting six==1.16.0
  Downloading six-1.16.0-py2.py3-none-any.whl (11 kB)
Collecting snowballstemmer==2.1.0
  Downloading snowballstemmer-2.1.0-py2.py3-none-any.whl (93 kB)
Collecting Sphinx==4.0.2
  Downloading Sphinx-4.0.2-py3-none-any.whl (2.9 MB)
Collecting sphinx-rtd-theme==0.5.2
  Downloading sphinx_rtd_theme-0.5.2-py2.py3-none-any.whl (9.1 MB)
Collecting sphinxcontrib-applehelp==1.0.2
  Downloading sphinxcontrib_applehelp-1.0.2-py2.py3-none-any.whl (121 kB)
Collecting sphinxcontrib-devhelp==1.0.2
  Downloading sphinxcontrib_devhelp-1.0.2-py2.py3-none-any.whl (84 kB)
Collecting sphinxcontrib-htmlhelp==2.0.0
  Downloading sphinxcontrib_htmlhelp-2.0.0-py2.py3-none-any.whl (100 kB)
Collecting sphinxcontrib-jsmath==1.0.1
  Downloading sphinxcontrib_jsmath-1.0.1-py2.py3-none-any.whl (5.1 kB)
Collecting sphinxcontrib-qthelp==1.0.3
  Downloading sphinxcontrib_qthelp-1.0.3-py2.py3-none-any.whl (90 kB)
Collecting sphinxcontrib-serializinghtml==1.1.5
  Downloading sphinxcontrib_serializinghtml-1.1.5-py2.py3-none-any.whl (94 kB)
Collecting toml==0.10.2
  Downloading toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting tqdm==4.61.1
  Downloading tqdm-4.61.1-py2.py3-none-any.whl (75 kB)
Collecting twine==3.4.1
  Downloading twine-3.4.1-py3-none-any.whl (34 kB)
Collecting urllib3==1.26.6
  Downloading urllib3-1.26.6-py2.py3-none-any.whl (138 kB)
Collecting virtualenv==20.4.7
  Downloading virtualenv-20.4.7-py2.py3-none-any.whl (7.2 MB)
Collecting webencodings==0.5.1
  Downloading webencodings-0.5.1-py2.py3-none-any.whl (11 kB)
Requirement already satisfied: wheel==0.36.2 in /usr/local/lib/python3.7/site-packages (from -r requirements.txt (line 73)) (0.36.2)
Collecting yapf==0.23.0
  Downloading yapf-0.23.0-py2.py3-none-any.whl (167 kB)
Collecting zipp==3.5.0
  Downloading zipp-3.5.0-py3-none-any.whl (5.7 kB)
Collecting typing-extensions>=3.6.4
  Downloading typing_extensions-3.10.0.0-py3-none-any.whl (26 kB)
Collecting jeepney>=0.4.2
  Downloading jeepney-0.7.1-py3-none-any.whl (54 kB)
Collecting SecretStorage>=3.2
  Downloading SecretStorage-3.3.1-py3-none-any.whl (15 kB)
Collecting cryptography>=2.0
  Downloading cryptography-3.4.7-cp36-abi3-manylinux2014_x86_64.whl (3.2 MB)
Collecting cffi>=1.12
  Downloading cffi-1.14.6-cp37-cp37m-manylinux1_x86_64.whl (402 kB)
Collecting pycparser
  Downloading pycparser-2.20-py2.py3-none-any.whl (112 kB)
Building wheels for collected packages: docopt, pygraphviz, restructuredtext-lint
  Building wheel for docopt (setup.py): started
  Building wheel for docopt (setup.py): finished with status 'done'
  Created wheel for docopt: filename=docopt-0.6.2-py2.py3-none-any.whl size=13705 sha256=f6d45a75a5a9e6942d1063059fd1e10a9f0b83887dd0c096dcb3fecac9d1ec3f
  Stored in directory: /root/.cache/pip/wheels/72/b0/3f/1d95f96ff986c7dfffe46ce2be4062f38ebd04b506c77c81b9
  Building wheel for pygraphviz (setup.py): started
  Building wheel for pygraphviz (setup.py): finished with status 'error'
  ERROR: Command errored out with exit status 1:
   command: /usr/local/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"'; __file__='"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' bdist_wheel -d /tmp/pip-wheel-lx7xx3y1
       cwd: /tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/
  Complete output (55 lines):
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.linux-x86_64-3.7
  creating build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/scraper.py -> build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/testing.py -> build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/graphviz.py -> build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/agraph.py -> build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/__init__.py -> build/lib.linux-x86_64-3.7/pygraphviz
  creating build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_attribute_defaults.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_subgraph.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_readwrite.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_unicode.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_drawing.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_string.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_close.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_scraper.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_edge_attributes.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_graph.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_html.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_clear.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/__init__.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_node_attributes.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  copying pygraphviz/tests/test_layout.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
  running egg_info
  writing pygraphviz.egg-info/PKG-INFO
  writing dependency_links to pygraphviz.egg-info/dependency_links.txt
  writing top-level names to pygraphviz.egg-info/top_level.txt
  reading manifest file 'pygraphviz.egg-info/SOURCES.txt'
  reading manifest template 'MANIFEST.in'
  warning: no files found matching '*.png' under directory 'doc'
  warning: no files found matching '*.txt' under directory 'doc'
  warning: no files found matching '*.css' under directory 'doc'
  warning: no previously-included files matching '*~' found anywhere in distribution
  warning: no previously-included files matching '*.pyc' found anywhere in distribution
  warning: no previously-included files matching '.svn' found anywhere in distribution
  no previously-included directories found matching 'doc/build'
  writing manifest file 'pygraphviz.egg-info/SOURCES.txt'
  copying pygraphviz/graphviz.i -> build/lib.linux-x86_64-3.7/pygraphviz
  copying pygraphviz/graphviz_wrap.c -> build/lib.linux-x86_64-3.7/pygraphviz
  running build_ext
  building 'pygraphviz._graphviz' extension
  creating build/temp.linux-x86_64-3.7
  creating build/temp.linux-x86_64-3.7/pygraphviz
  gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/include/python3.7m -c pygraphviz/graphviz_wrap.c -o build/temp.linux-x86_64-3.7/pygraphviz/graphviz_wrap.o
  In file included from /usr/include/graphviz/gvc.h:17,
                   from pygraphviz/graphviz_wrap.c:2712:
  /usr/include/graphviz/types.h:49:10: fatal error: cgraph.h: No such file or directory
     49 | #include <cgraph.h>
        |          ^~~~~~~~~~
  compilation terminated.
  error: command 'gcc' failed with exit status 1
  ----------------------------------------
  ERROR: Failed building wheel for pygraphviz
  Running setup.py clean for pygraphviz
  Building wheel for restructuredtext-lint (setup.py): started
  Building wheel for restructuredtext-lint (setup.py): finished with status 'done'
  Created wheel for restructuredtext-lint: filename=restructuredtext_lint-1.3.2-py3-none-any.whl size=13666 sha256=ef6b48382ddff413444e41744d482dc13160c496ca364e17a65b2370a9de8df0
  Stored in directory: /root/.cache/pip/wheels/32/f9/1f/1bf1f220360fc5d61cba1e8da660d93c5e6335b0c77fc1008c
Successfully built docopt restructuredtext-lint
Failed to build pygraphviz
Installing collected packages: pycparser, pyparsing, cffi, zipp, webencodings, urllib3, typing-extensions, six, pytz, packaging, MarkupSafe, jeepney, idna, cryptography, chardet, certifi, sphinxcontrib-serializinghtml, sphinxcontrib-qthelp, sphinxcontrib-jsmath, sphinxcontrib-htmlhelp, sphinxcontrib-devhelp, sphinxcontrib-applehelp, snowballstemmer, setuptools, SecretStorage, requests, Pygments, Pillow, numpy, Jinja2, importlib-metadata, imagesize, filelock, distlib, bleach, Babel, appdirs, alabaster, virtualenv, tqdm, toml, Sphinx, scipy, rfc3986, requests-toolbelt, readme-renderer, PyYAML, pyflakes, pycodestyle, py, pluggy, pkginfo, nodeenv, mccabe, keyring, iniconfig, imageio, identify, docopt, decorator, coverage, colorama, cfgv, attrs, yapf, twine, sphinx-rtd-theme, restructuredtext-lint, pytest, pygraphviz, pre-commit, pip, networkx, jsonpickle, invoke, flake8, coveralls, colour-science
  Attempting uninstall: setuptools
    Found existing installation: setuptools 47.1.0
    Uninstalling setuptools-47.1.0:
      Successfully uninstalled setuptools-47.1.0
  Attempting uninstall: numpy
    Found existing installation: numpy 1.19.0
    Uninstalling numpy-1.19.0:
      Successfully uninstalled numpy-1.19.0
  Attempting uninstall: coverage
    Found existing installation: coverage 5.4
    Uninstalling coverage-5.4:
      Successfully uninstalled coverage-5.4
    Running setup.py install for pygraphviz: started
    Running setup.py install for pygraphviz: finished with status 'error'
    ERROR: Command errored out with exit status 1:
     command: /usr/local/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"'; __file__='"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-hmimt8mz/install-record.txt --single-version-externally-managed --compile --install-headers /usr/local/include/python3.7m/pygraphviz
         cwd: /tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/
    Complete output (56 lines):
    running install
    running build
    running build_py
    creating build
    creating build/lib.linux-x86_64-3.7
    creating build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/scraper.py -> build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/testing.py -> build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/graphviz.py -> build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/agraph.py -> build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/__init__.py -> build/lib.linux-x86_64-3.7/pygraphviz
    creating build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_attribute_defaults.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_subgraph.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_readwrite.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_unicode.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_drawing.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_string.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_close.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_scraper.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_edge_attributes.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_graph.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_html.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_clear.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/__init__.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_node_attributes.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    copying pygraphviz/tests/test_layout.py -> build/lib.linux-x86_64-3.7/pygraphviz/tests
    running egg_info
    writing pygraphviz.egg-info/PKG-INFO
    writing dependency_links to pygraphviz.egg-info/dependency_links.txt
    writing top-level names to pygraphviz.egg-info/top_level.txt
    adding license file 'LICENSE' (matched pattern 'LICEN[CS]E*')
    reading manifest file 'pygraphviz.egg-info/SOURCES.txt'
    reading manifest template 'MANIFEST.in'
    warning: no files found matching '*.png' under directory 'doc'
    warning: no files found matching '*.txt' under directory 'doc'
    warning: no files found matching '*.css' under directory 'doc'
    warning: no previously-included files matching '*~' found anywhere in distribution
    warning: no previously-included files matching '*.pyc' found anywhere in distribution
    warning: no previously-included files matching '.svn' found anywhere in distribution
    no previously-included directories found matching 'doc/build'
    writing manifest file 'pygraphviz.egg-info/SOURCES.txt'
    copying pygraphviz/graphviz.i -> build/lib.linux-x86_64-3.7/pygraphviz
    copying pygraphviz/graphviz_wrap.c -> build/lib.linux-x86_64-3.7/pygraphviz
    running build_ext
    building 'pygraphviz._graphviz' extension
    creating build/temp.linux-x86_64-3.7
    creating build/temp.linux-x86_64-3.7/pygraphviz
    gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -fPIC -I/usr/local/include/python3.7m -c pygraphviz/graphviz_wrap.c -o build/temp.linux-x86_64-3.7/pygraphviz/graphviz_wrap.o
    In file included from /usr/include/graphviz/gvc.h:17,
                     from pygraphviz/graphviz_wrap.c:2712:
    /usr/include/graphviz/types.h:49:10: fatal error: cgraph.h: No such file or directory
       49 | #include <cgraph.h>
          |          ^~~~~~~~~~
    compilation terminated.
    error: command 'gcc' failed with exit status 1
    ----------------------------------------
ERROR: Command errored out with exit status 1: /usr/local/bin/python -u -c 'import sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"'; __file__='"'"'/tmp/pip-install-d6t1fra0/pygraphviz_23a4829b28d44863b551f19bd02abcf4/setup.py'"'"';f=getattr(tokenize, '"'"'open'"'"', open)(__file__);code=f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' install --record /tmp/pip-record-hmimt8mz/install-record.txt --single-version-externally-managed --compile --install-headers /usr/local/include/python3.7m/pygraphviz Check the logs for full command output.
WARNING: You are using pip version 21.0.1; however, version 21.2.4 is available.
You should consider upgrading via the '/usr/local/bin/python -m pip install --upgrade pip' command.
The command '/bin/sh -c pip install -r requirements.txt     && rm /tmp/requirements.txt' returned a non-zero code: 1

Running on a CentOS 7 box:

  Operating System: CentOS Linux 7 (Core)
       CPE OS Name: cpe:/o:centos:centos:7
            Kernel: Linux 3.10.0-1160.11.1.el7.x86_64
      Architecture: x86-64

I would also agree with having one version and like @chetannanda wonder whether the / could confuse some things.

On a related "separators" topic, was this amendment ever made to allow studios to choose their preferred separator for aliases:
https://lists.aswf.io/g/ocio-user/message/565

Currently the config is full of aliases using _ as the word separator which makes them much harder to use predictably in filenames

Originally posted by @frenchie1980 in #74 (comment)

Hi,

I noticed that last year but forgot to address it:

    name = "AP0_to_Gamma2.2_AP1-Texture"
    clf_transform_id = format_clf_transform_id(FAMILY, GENUS, name, VERSION)
    filename = output_directory / clf_basename(clf_transform_id)
    clf_transforms[filename] = generate_clf_transform(
        filename,
        [
            matrix_RGB_to_RGB_transform("ACES2065-1", "ACEScg"),
            gamma_transform(2.2),
        ],
        clf_transform_id,
        "AP0 to Gamma 2.2 AP1 - Texture",
        "ACES2065-1",
        "2.2 gamma-corrected AP1 primaries, D60 white point", <<<---
    )

The ACES whitepoint is not D60, it is close but not quite like it: https://docs.acescentral.com/tb/white-point

Quite minor, but I was wondering why it was the only config that included the 'reference' role, but as per Carol Payne on Slack:

"If the reference role is in the reference config, that’s probably a bug, which we can fix :)"

README says to invoke with invoke build-reference-config but the actual command is invoke build-config-reference

Proposing adding a pure gamma 2.2 display to the ACES configs (CG and Studio) alongside the existing sRGB (Piece-Wise) display. FWIW, this would parallel the "Gamma 2.2/Rec 709" display in the default Maya config.

As many folks have noted, it seems like a safer bet generally for CG/VFX artists to use a pure gamma 2.2 display to avoid crushed shadows.

In some of the color spaces (e.g. camera logs) the current configs contain individual transform operators even when a Built-in Transform is available.

The benefit of that is that it is more apparent what math is being applied. The drawback is that it is not apparent at a glance whether the matrix coefficients and etc. are really the correct ones for that color space (e.g. a specific camera log) or whether they have been tampered with.

At the working group discussion today, it was felt that it is somewhat preferable to use the Built-in Transforms whenever they exist. This proposal is to update the Python script to insert a Built-in Transform if it exists for the given OCIO version that the config is being built for.

That was a discussion about this on Slack, but I want to open an issue for this.

Default ACES config must include Standard color spaces even if they are legacy or not used in VFX industry.

ACES that want to be a standard for new media also have a duty to join separate camps, VFX, Graphic Design, Photographers, etc.

Obeying some standard color spaces, that can be used in other industries, like Adobe RGB (that included in ALL DSLR and Mirrorless cameras prior to 2023 release date). ProPhoto RGB (RIMM/ROMM) that is internal wide gamut color space for most Adobe Apps (good or not, is the same industry standard as proprietary Nuke) that have almost the same as ACEScg or BT.2020 gamut size.
Some can be used in research papers or in resources about color science. For example https://www.colour-science.org/apps/ Have a lot classical, legacy or other color spaces from Different industries, that make this package usable for everyone, not only several holliwood companies.

Looking how many camera specific color profiles already included in ACES configs, 3-5-10 standard color spaces not make ACES config heavier or easier to manage. But can help to find a piece for all who need to work with colors.

In v1 of these config releases, the working group decided to maintain parity with previous OCIOv1 ACES config releases with respect to the matte_paint and texture_paint roles. We made this decision to minimize disruption to applications wishing to make use of the new configs in the short term.

With the upcoming release of v2 of the configs, the group has decided the time is ripe to make the needed switch from:

  matte_paint: sRGB - Texture
  texture_paint: ACEScct

to the new:

  matte_paint: ACEScct
  texture_paint: sRGB - Texture

This issue is just to serve as documentation for the forthcoming PRs.

In the ASWF Color Interop Forum recommendations, there is a color space "Unknown". This is intended to be used by application developers when they need to set the color space metadata in some file format if they don't actually know what the real color space is. This is intended to help avoid the common problem where developers simply "guess" and set something that turns out to be wrong.

The question then is what should happen when reading a file that is tagged with the color space "Unknown"?

If config authors include "Unknown" in their config pointing to whatever color space they want to use as a default for handling that scenario, then it requires no special action on the part of the application. This could be done by defining a new color space or role, or by adding an alias to an existing color space.

However, the config author may want the application to ask the user to identify the color space rather than relying on a default. This is historically indicated by setting the "strictparsing" attribute of the config to "true".

So a possible recommendation for app developers would be to proceed as follows:

1. Simply pass the color space to OCIO. If the config author has defined "Unknown", it will be handled at that time.
2. If it doesn't match a color space in the config, the app could check if the string is "Unknown" and if so, then check the config's strictparsing attribute. If it's true, the app should ask the user to select a color space. (Though config authors should be aware that it won't always be possible for an app to ask a user or otherwise suspend processing.)
3. If strictparsing is false, the app could use the file's path in the File Rules to obtain a color space. Or if the file either doesn't have a path, or it seems inappropriate to use it, the app could simply use the color space for the default File Rule.

Any thoughts?

How should this be handled in the built-in ACES configs?

Hello,

Title says it all, we use that all the time with Unreal Engine to benefit from the builtin decoding functions. There are plenty of other cases in realtime workflows where this is relevant

Cheers,

Thomas

As we know, the primaries for sRGB were chosen to match those of Rec.709, and so it is common for these two terms to be used somewhat interchangeably in certain situations. This may be confusing for people that are color management novices and so some thought should be given to how to use the terms in color space names.

The ACES 1.2 config has duplicate color spaces to handle this: Utility - Linear - sRGB and Utility - Linear - Rec.709 are separate spaces that have the same definition under the hood. Should we do something similar in the new configs?

This issue is to collect feedback about which approach should be used.

For novices, who don't understand that these two spaces are actually the same, having two separate menu options could lead to confusion. For example, they may be vaguely familiar that these are the same but worry that the config may be implementing them slightly differently (otherwise, they might think, why have two separate options?).

One minor issue with the ACES 1.2 config is that these spaces are in different equality groups and thus are declared as being separate color spaces and thus do not automatically short circuit. That said, the optimizer would optimize out the matrices, so a Processor from Utility - Linear - sRGB to Utility - Linear - Rec.709 should still become a no-op (even if a bit farther down in the library).

The bigger issue is for situations where color spaces are manipulated in a way that does not involve calling OCIO to get a Processor. For example, in situations where color space names are used by external libraries (MaterialX, USD, etc.) and applications, having two names for the same space may occasionally cause unintended behavior since they may do optimizations outside of OCIO and not realize a pair of different color space names are actually the same.

One last point concerns the list of spaces that are intended to be shown for rendering space options (spaces that have encoding=scene-linear and category=working-space). It seems especially redundant to have two separate, duplicate, spaces show up in this list.

One alternative that has been used elsewhere is to avoid duplicating the color spaces and simply combine the terms into a single name, for example: Utility - Linear - sRGB / Rec.709.

Advantages of having separate names Utility - Linear - sRGB and Utility - Linear - Rec.709

• Consistency with what was done in the ACES 1.2 config
• Avoid any confusion caused by combining them into one name

Advantages of unifying the names Utility - Linear - sRGB / Rec.709

• Educate novices that these are actually the same space
• Avoid confusion over which menu item to pick
• Avoid making menus longer than they need to be
• Avoid issues with tools unable to optimize out an unnecessary conversion

p.s.
Some may observe that the ACES 1.2 config sometimes only uses Rec.709 and does not have an sRGB duplicate. For example, Utility - Gamma 2.2 - Rec.709 - Texture has no equivalent Utility - Gamma 2.2 - sRGB - Texture. I think this was a good design decision and consider it inappropriate to use "sRGB" with any gamma designation other than the piecewise curve since it would add to an already confusing situation. The intent here is to explicitly exclude that topic from conversation in this issue.

We are planning our next release of the OCIO configs for ACES. The plan is to include these as built-in configs in the upcoming OCIO 2.3 release. The VFX Reference Platform leadership has asked us to have the library released by the end of August in order to be included in the VFX Reference Platform for CY 2024, so we need to have the configs available by early August so that we have time to integrate them into the library.

I've created a spreadsheet to help with the release planning.

Per the discussion at today's Configs WG, I've bumped the config part of the version string to 2.0.0 for the upcoming release. The ACES version will remain at 1.3.

I'm proposing bumping the OCIO version to 2.3 to take advantage of the latest built-ins. But what older OCIO releases do we want to support? Please add the proposed name, and what features you want included, to the spreadsheet. (Note that any configs for older versions will not be built into the 2.3 library, so these could be added to the Python generator later, if necessary.)

Likely a copy-and-paste error, leaving three subsection headers for §2.3.1 being "Reference Config", "CG Config", and "Reference Config"

The categories attribute of color spaces is intended to allow applications to filter the list of color spaces presented in menus to be appropriate for either a type of task or a type of user. The category values currently used in the CG and Studio config are 'working-space' and 'file-io'. Based on feedback from Apple at a recent Configs WG meeting, it sounds like it would be helpful to introduce a 'texture' category.

Here is the list of color spaces I propose adding this to (all of these are in both the CG and Studio configs):

ACEScg
Linear P3-D65
Linear Rec.2020
Linear Rec.709 (sRGB)
Gamma 1.8 Rec.709 - Texture
Gamma 2.2 AP1 - Texture
Gamma 2.2 Rec.709 - Texture
Gamma 2.4 Rec.709 - Texture
sRGB Encoded AP1 - Texture
sRGB Encoded P3-D65 - Texture
sRGB - Texture
Raw

this is related to .rc2

some of the config file give error "invalid configuration file" when making ocio asset in UE 4.27.2.

for example:
studio-config-v1.0.0-rc2_aces-v1.3_ocio-v2.0.ocio
is working in ue 4.27.2

studio-config-v1.0.0-rc2_aces-v1.3_ocio-v2.1.ocio
is not working in ue 4.27.2

also, what to use for Unreal engine input transform?
shouldn't there be a: input: linear-sRGB?

Including a single ViewTransform, e.g. ACES-OUTPUT - ACES2065-1_to_CIE-XYZ-D65 - SDR-VIDEO-D60sim-D65_1.0 adds it to all the displays, we might want granularity and be able to add it only for a particular display.

I get instant crash when i try to use exr half float textures blender 3.1 or 3.2
with the beta profile OpenColorIO-Config-ACES 0.2.0

There are several different versions that are involved in a given config instance:

• The version of the OpenColorIO config file format (currently 2.1, soon to be 2.2)
• The version of the ACES system (currently 1.3, soon to be 2.0)
• The version of a given instance of the config (e.g., changing as color spaces are added or removed from the spreadsheet)

The OCIO config file format is documented as the "ocio_profile_version" on the first line of the config. The other two should also be documented in the config, ideally in a way that is both machine readable and human readable.

In addition, we may want some of these versions to show up in the name of the config file itself.

The working group has discussed these topics several times but I don't think we ever came to a conclusion on how this will work. Creating an issue here since the Python code probably needs to be updated to reflect whatever the decision is.

Of course, there is a fourth version which is the version of the Python generating code, but my guess is that this will not affect the usability of the config enough that it will be a significant concern. The config description string already seems to contain a creation date and corresponding release version and git commit hash for the Python generating code itself and my view is that that is sufficient. But I think we do need some more formal way of recording the other three versions listed above.

I propose that the "name" attribute of the config object be used to hold a human & machine readable string that includes these three versions. (In Python this would use the Config class setName method.)

For example the name string could be something like: "Studio Config for ACES 1.3 [OCIO v2.1] [color spaces v0.2.0]"

Should the file name of the config itself include these too? For example change "config-aces-cg.ocio" to something like:
"cg-config_aces-1.3_ocio-2.1_colorspaces-0.2.0.ocio"

Of course, the config is a text file and may be edited, so there is no guarantee that a given config name string or file name will be as reliable as a hash of the file. Nevertheless, a versioned name string of some sort is more human readable and could be quite helpful as a first piece of information to ask for when investigating user problems.

We would like to add typing annotations to the repo and use pyright for static type checking.

I'm using this config as an environment variable, with Blender. I just replaced the OCIO studio config file from last year with the latest studio one, and to my surprise I found a greatly reduced list of camera colour spaces, and no ACEScc. What happened? Is that intentional or the result of an issue on my end?

In OCIO v2, a colorspace may have an aliases attribute that provides alternate names for the color space. This allows configs to be more compact than the earlier ACES configs (which duplicated each color space to define the alternate name).

The spreadsheet of color spaces has a column for the alias strings (although they may need to be refined). In the Python, these strings may be provided as a list in the ColorSpace constructor or later individually using the addAlias method.

It seems there is code to add these at line 194 in:
opencolorio_config_aces/config/generation/factories.py

But the aliases don't seem to be showing up in the config. Is it an issue in the code or the spreadsheet or something else?

Hi,

Instead of polluting #1, I'm creating a new thread to discuss the discovery repo I have been poking at lately: https://github.com/colour-science/discover-aces-dev

It is an experiment at this stage, but the code walks through https://github.com/ampas/aces-dev/tree/master/transforms/ctl, discovers and classifies all the relevant CTL transforms and transform pairs.

My naive hope is that we might eventually be able to use that process to automatically build the core ACES config that matches aces-dev without too much code.

A direct benefit is that it enforces things to be clean on the CTL side, and while implementing the discovery code, a few things surfaced that I hope we will be able to resolve in a timely fashion.

Note that I cheated for the LMTs, they should not be visible because their source and target are AP0. I also culled most of the Alexa transforms, the ridiculous number of them was blowing up the graph.

Cheers,

Thomas

Problem Statement
Many devices used in the ACES, OCIO and USD ecosystems for content authoring and display have screens that use the P3 primaries and D65 white point. In the Apple ecosystem, this gamut is generally referred to as "Display P3". Thus far, the ACES OCIO config has colorspaces designed to support textures authored with either the sRGB gamut or the ACES AP1 (aka ACEScg) gamut, with a couple of different transfer functions. It also has a colorspace for handling linear content with the P3-D65 gamut. It has not had colorspaces that support textures authored with the P3 primaries, D65 white point and sRGB transfer function.

As such, it would be5 valuable to the community of users of the ACES OCIO config to add colorspaces that directly support textures authored with the P3-D65 (aka DisplayP3) gamut.

Proposed solution
Add colorspaces the support the following combination of primaries, white points and transfer functions

• P3 primaries, D65 white point, sRGB transfer function

The colorspaces would be named

• sRGB encoded - P3-D65 - Texture

In order to provide the most flexibility to different pipelines and authoring ecosystems, these colorspaces would have the following aliases

• srgb_p3d65
• srgb_encoded_p3d65_tx
• srgb_displayp3

As a related, but somewhat separate issue, the proposal would put these colorspaces in the following family:
Input/Texture
Given that that may end up being a separate Issue, the colorspaces would live in the Utility family.

These colorspaces would be in the following category
texture

As discussed with @doug-walker and @carolalynn22, we currently use a human readable inner config name:

ocio_profile_version: 2.1

environment:
  {}
search_path: ""
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]
name: Academy Color Encoding System - CG Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.1.1]
description: |
  The "Academy Color Encoding System" (ACES v1.3) "CG Config"
  -----------------------------------------------------------
  
  This minimalistic "OpenColorIO" config is geared toward computer graphics artists requiring a lean config that does not include camera colorspaces and the less common displays and looks.
  
  Generated with "OpenColorIO-Config-ACES" v0.1.1-14-gec7d1cf on the 2022/05/10 at 20:12.

i.e. Academy Color Encoding System - CG Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.1.1]

It would be desirable to line it up with the actual config basename for pipeline purposes, i.e. cg-config-v0.1.0_aces-v1.3_ocio-v2.1.1.ocio.

We could then change the description title to use the current inner config name:

ocio_profile_version: 2.1

environment:
  {}
search_path: ""
strictparsing: true
luma: [0.2126, 0.7152, 0.0722]
name: cg-config-v0.1.0_aces-v1.3_ocio-v2.1.1
description: |
  Academy Color Encoding System - CG Config [COLORSPACES v0.1.0] [ACES v1.3] [OCIO v2.1.1]
  ----------------------------------------------------------------------------------------
  
  This minimalistic "OpenColorIO" config is geared toward computer graphics artists requiring a lean config that does not include camera colorspaces and the less common displays and looks.
  
  Generated with "OpenColorIO-Config-ACES" v0.1.1-14-gec7d1cf on the 2022/05/10 at 20:12.

The basic question I am posing for the group is: Do we want to continue including a prefix (e.g., "Input") in the color space names in the new configs? And if so, should we update what the prefixes are or how they are used?

Color space names

In the OCIO v1 ACES configs, the color space names are prefixed in order to group them into families. Here are some color space names from the ACES 1.2 config:

    name: ACES - ACES2065-1
    name: ACES - ACEScct
    name: Input - ARRI - V3 LogC (EI800) - Wide Gamut
    name: Input - Sony - S-Log3 - Venice S-Gamut3.Cine
    name: Output - P3D65
    name: Output - sRGB
    name: Output - sRGB (D60 sim.)
    name: Utility - Dolby PQ 10000
    name: Utility - Curve - sRGB
    name: Utility - Gamma 2.2 - Rec.709 - Texture
    name: Utility - Linear - Adobe Wide Gamut RGB
    name: Utility - sRGB - Texture
    name: Utility - Raw
    name: Utility - Look - Blue Light Artifact Fix
    name: Role - compositing_log

The prefixes that are used in that config are "ACES", "Input", "Output", "Utility", and "Role". In some cases there are secondary prefixes, such as including the camera vendor under "Input" (e.g., "Input - ARRI") and "Linear" and "Curve" under "Utility" (e.g., "Utility - Curve").

The new ACES Reference config adds the "Display" prefix for use with the new display color spaces added in OCIO v2. For example:

    name: Display - sRGB

In all cases, the prefix is also used in the family attribute of the color space (although there is some minor variation in how that is done, for example, the family for the "Role" prefix falls under the Utility family). The family attribute is used to generate hierarchical menus for color space names. Some apps have done this in both OCIO v1 and v2 (although v2 makes it easier by providing some convenience functions for it in apphelpers).

In the earlier configs, prefixes were added to the color space names for several reasons. First, the official ACES naming, taken from the tag in the CTL files, often (although not always) includes a prefix.

Second, adding a prefix may help organize the long menus encountered in applications that do not use hierarchical menus for color space names. However, it should be noted that the ordering of color spaces presented by OCIO to an application follows the order established by the config author. So the config author should at least control the ordering (unless the application alphabetizes them, which is discouraged).

Display & View names

A related question is: Should a prefix or suffix should be used in the Display and View names?

In the ACES 1.2 config, there is only one display ("ACES") and the views do not have a prefix or suffix. Here are some views:

  sRGB
  sRGB D60 sim.
  Rec.2020 ST2084 1000 nits
  Raw
  Log

In the new ACES Reference config, all of the displays have a "Display - " prefix. (In OCIO v2, the display naming should match the display color space naming, so it is a related question.) And the views sometimes have an "Output - " prefix and sometimes an " - ACES 1.x" suffix. For example, here are some displays:

  Display - sRGB:
  Display - Rec.1886 / Rec.709 Video:

and some views:

  Output - SDR Video - ACES 1.0
  Output - SDR Video (D60 sim on D65) - ACES 1.0
  Output - HDR Video (1000 nits & Rec.2020 lim) - ACES 1.1
  Un-tone-mapped
  Raw

Considerations

It's clear that there are pros and cons to prefixing the names. On the one hand, some might argue that the names are too long and unwieldy. On the other hand, I've seen a lot of people saying that they really like the naming conventions pioneered in the ACES configs.

Here are some aspects of the problem to consider:

Versioning
The name for the views, at least, probably needs to indicate the ACES version. Once ACES 2.0 is released, there will likely be a transition period where both ACES 1.x and ACES 2.0 Output Transforms are in some configs. Should this be a prefix or suffix?

Color spaces vs. Displays/Views
The new configs are taking advantage of the OCIO v2 feature of splitting Output Transforms into a Display + View. Therefore, the config currently does not have any color spaces that have an ACES Output Transform baked in. Hence, there are no color spaces that need the "Output" prefix. The Reference config is still using them in the View names, but this may not be necessary. Similarly, per the previous point, the ACES 1.x vs. 2.0 distinction may only be necessary in Views and not in color space names.

Handling of video color spaces
One question often heard from users is around how to deal with sRGB images (or similar). There are two ways of managing these color spaces in the current ACES configs: treat them as display color spaces and simply linearize them; or apply an inverse ACES Output Transform. (Note that in OCIO v2, inverting the Output Transform is better handled using DisplayViewTransform rather than ColorSpaceTransform.) Future ACES configs may provide more options which fall somewhere in between (e.g. inverting some of the view transform but with slope limiting to prevent generating extreme values). But in any case, we may want to see if improvements to the naming could be made to reduce user confusion.

Changes to the Utility color spaces
In the OCIO v1 configs, there was a large (and arguably unwieldy) set of "Utility" color spaces. Taking advantage of OCIO v2 features will change this collection, as would raising the expectations around application UX support. For example, the "curve" color spaces will become Named Transforms. Many of the other color spaces are not needed any more. And the "Utility - Look" spaces will become simply Looks. Should the "Utility" collection be named/organized differently? Should "Texture" (which is now a suffix) become a family name or prefix?.

Duplicate names
The previous and current ACES config had a number of color spaces that show up multiple times under different names. For example, having separate color spaces for linear Rec.709 and linear sRGB rather than one linear Rec.709/sRGB space. Or having the same space both as a display and as a texture input. Should we try to minimize that, or continue with that practice?

Availability of categories
In OCIO v2, color spaces have a categories attribute which is intended to be used by applications to filter the list of color spaces presented in menus. This reduces the need for prefixes to organize color spaces.

Diversity of implementations
If all applications implemented features OCIO supports such as hierarchical menus and categories, it would eliminate the need to have the prefixes in color space names. Unfortunately, not all applications have done this and so a judgment call needs to be made about how long to bias the UX for everyone in order to work around the limitations of the least capable implementations. An effort is underway to survey how many applications still have not implemented hierarchical menus.

Backwards compatibility
The new color space aliases attribute in OCIO v2 may be used to provide backwards compatibility for the earlier names. This will allow old project data (scene files, etc.) that have embedded references to the earlier names to continue to work with the new config.

Clarity when used in isolation
In some cases, the color space name will be seen on its own, for example without the context provided by the hierarchical menu organization. For example, many applications (e.g., Nuke, Maya) will store the color space name as a parameter value for a color space conversion. Similarly, the color space name could be a command-line argument for something like oiiotool. The name needs to be sufficiently clear and unambiguous, even in this type of usage (i.e., where the family attribute is not present).

Proposal

An informal discussion during a recent working group meeting indicated that people are leaning towards removing the prefix from the name but keeping it in the family. Just to start the discussion, here is a strawman proposal (I'm still on the fence about a number of these, TBH):

1. The first-level prefixes "Input", "Utility", and "ACES" will be dropped from the color space names but will remain in the family (and thus in hierarchical menus).
2. The current second-level vendor prefixes (e.g., "ARRI", "RED") will be dropped from the color space name (but kept in the family) if they are clearly implied by the rest of the name.
3. Linear versions of the camera-primary color spaces will retain a "Linear" prefix.
4. ACES Views will get a prefix (rather than the current suffix), including the ACES version (e.g. "ACES 1.1").
5. In order to disambiguate display-referred video spaces from scene-referred texture spaces, the display-referred color spaces will have a "Display" suffix. A "Texture" suffix will be added to texture spaces. So for example, there could be a "sRGB - Display" and a "sRGB - Texture" color space (each connecting via its corresponding reference space). The "Display" and "Texture" would also be in the family.
6. Named Transforms will have a "Curve" suffix, where appropriate.
7. Both the full and short-hand names from the ACES 1.2 config will become aliases in the new Studio and CG configs (for color spaces with an equivalent in the new config).
8. Color space ordering in the config will be by family so that in applications which don't yet support hierarchical menus, the list will at least be organized.

@flord

• There is no Arri input space in the studio config? That is almost the only one we need!
• There is no linear sRGB colorspace? I understand it's the same as linear Rec.709, but I would expect sRGB to be mentioned somewhere to avoid any confusion. linear Rec.709/sRGB perhaps...
• In Nuke, when loading a .mov file, it seems to be hard-coded to use the Gamma2.2 space. With either config, Nuke throws an error because that space does not exist. How are we going to deal with that? Tell Foundry to stop hard coding spaces?
• In Nuke, there is only one menu for displays and display spaces. This makes the raw space being repeated multiple times, making the list of spaces even longer. I guess we also need to ask Foundry to fix that.

@MrLixm

• #57 (comment)

Hello, great to see this discussion. A thing I'm wondering is why the unique identifier of the colourspace is also the pretty name used for interfaces? Shouldn't decoupling the UI and the logic a better idea to allow for more flexible configs that can be updated at any moment ?

SImple naive example :

  - !<ColorSpace>
    identifier: displaysrgb
    name: True-PRO sRGB Display
    family: Display
    equalitygroup: ""
    bitdepth: 32f
    description: Convert CIE XYZ (D65 white) to sRGB (piecewise EOTF)

Where anyone could just change the name and it wouldn't break anything in any software.

This could then open a lot of other discussions (identifiers formats, identifiers conventions, ...) but just wanna know your thought about this ? Cheers. Liam.

@anderslanglands

I understand that it may be too late but it would be really nice if compact, unique identifiers could be split from the “display name”, especially if the display name is forced to have extra context to be used in isolation.

For instance, some applications will bake the colour space name into file names (substance does this when exporting) and with the current ACES configs this results in some absolutely horrific file names. Plus all those spaces are just bugs waiting to happen.

As someone who likes to think he knows a little about colour, but doesn’t know OCIO very well, I find the current naming in the ACES configs extremely confusing - eg which sRGB is actually sRGB? Or are they both the same thing? (I still don’t know the answer to this).

@KelSolaar

• Rec. 709/Rec. 1886 for display names vs Rec.709/Rec.1886 for colorspaces.
• Ensure that colorspaces version is updated when we update the generator.

@scoopxyz

• Just a small comment to include a link to the spreadsheets that are used as the "ground truth" for naming, etc. in the README.md if you can :)

@nick-shaw

Is there a reason that the ACES Reference Gamut compression is available as a look in the Reference config, but not the Studio config? I feel we should be encouraging people to start using it, and making it easy for them to do so.

On that subject, because the "Blue Highlight Fix" is alphabetically before the RGC, that comes up as the default look when the Reference config is used. That should really be deprecated in favour of the RGC.

And finally (not that I'm obsessed with the RGC at all!) but it brings up the point that support for aliases in looks could be useful, so you could simply use e.g. "RGC" instead of typing "ACES 1.3 Reference Gamut Compression" in full.

Bartłomiej Styczeń

@Thomas Mansencal
so I finally got to this, and all seems to go well until I specify a BuiltinTransform Style in the CSV, I tried with these:
ACEScc_to_ACES2065-1
ACEScct_to_ACES2065-1
ACEScg_to_ACES2065-1
ACESproxy10i_to_ACES2065-1
And they all crash the generator with
INFO:opencolorio_config_aces.config.cg.generate.config:Creating a "Colorspace" transform for "ACEScc_to_ACES2065-1" style...
Traceback (most recent call last):
File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/studio/generate/config.py", line 274, in
config, data = generate_config_studio(
File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/studio/generate/config.py", line 228, in generate_config_studio
_config, data = generate_config_cg(
File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/cg/generate/config.py", line 997, in generate_config_cg
colorspace = style_to_colorspace(**kwargs)
File "/home/aswf/OpenColorIO-Config-ACES/opencolorio_config_aces/config/cg/generate/config.py", line 415, in style_to_colorspace
[beautify_alias(signature["name"])] + signature["aliases"]
KeyError: 'name'
Before I delve into the source code, just wanted to ask if it’s something you recognise and maybe the problem is as trivial as error in the BuiltinTransform Style name

After some debugging and slight modification to the code and csv, I got a config, but not really sure about the correctness of it.
The problem I mentioned above is due to a signature["name'] never being set. I have no clue where that name should come from so I just fed it style name.
Later on there was a problem with the config version:
PyOpenColorIO.Exception: Error building YAML: Only config version 2.1 (or higher) can have BuiltinTransform style 'ACES-LMT - ACES 1.3 Reference Gamut Compression'.
It seems like the generation starts with the proper 2.1 version, but then it is changed midway to 2.0 in
config/cd/generate/config.py:
1085: data.profile_version = VersionData(2, 0)
If that was intended, can I just remove that line or will it mess up the further logic? (edited)

Sidenote: Dockerfile seems to be a bit out of date, it’s based on old ci-ocio that uses python 3.7 and one of the requirements requires python >= 3.8 (numpy 1.22 if I remember correctly).
I’ve used FROM aswf/ci-ocio:2022 and it built fine, but maybe that can cause some issues with the generator?

@mdecaria

Hi, congratulations on the beta config release, just have some general questions/feedback on the Studio Config

• I'm curious about the reason behind no Linear P3-D60? Why have P3-D60 Display and D60 sims if the linear equivalent isn't available to help with those workflows?
• How are the aliases' names chosen? Some seem a little inconsistent/missing.
  srgb_texture would be nice to have on sRGB - Texture
  Should ST-2084 - Curve have the st2084_crv alias for consistency with the display name?
  Why does Linear Rec.2020 get a combined alias with no underscore but other spaces don't?
• For categories labels - ACEScg is a working-space, Linear Rec.709 is also one; although not typical, Linear P3-D65 could be labelled as one?
• As the DCDM ODTs are now omitted ( sadly ), what's the best re-implementation for backwards compatibility sake besides relying on the previous LUTs?

@remia

I looked quickly at the studio config, nothing really important to report or probably already known:

• The config generates the following warning: "[OpenColorIO Warning]: file_rules: defines a default rule using color-space 'ACES2065-1' that does not match the default role 'sRGB - Texture'.",
• The '/' family separator is used in some colorspaces which cause additional menu hierarchies in Nuke but seems to be handled correctly with the newer app helpers so just need to update the UI,
• NamedTransform for ST2084 curve encoding attribute is "log", might be "hdr-video" but I guess the former also makes sense strictly speaking,
• I was a bit mislead by the OCIO version in the config name, it seems to be the one used by the generator but not the one to be used by the end-user. As in if it was the case I would expect the OCIO 2.1.2 studio config to include the RGC and have a 2.0.4 version without it,
• Testing on ociodisplay exposed a crash on Linux when there is no Looks in the OCIO config and you hover the Looks override menu (more of a note for OCIO dev to look at).

Great work everyone!

@zachlewis

My quickie beef -- can we get rid of the " - Display" part of the Display names? Gets to be quite a bit to type.

I understand that we want to keep " - Display" in the Display Color Spaces names, and that's fine. But maybe instead of using Shared Views for all the ACES-based views, we can use plain-ol regular views.

Derek Flood

I see that the Canon CLFs have been updated for C-Log3 and its corresponding linear.
#71

Is it planned to also support the C-Log2? Or is C-Log2 depreciated/unsupported?

Just seeking education/understanding, thanks!

The inactive_colorspaces list in the 1.0.0 cg config is this:

inactive_colorspaces: [CIE-XYZ-D65, 
sRGB - Display, 
Rec.1886 Rec.709 - Display, 
Rec.1886 Rec.2020 - Display, 
sRGB - Display, 
Rec.1886 Rec.709 - Display, 
Rec.1886 Rec.2020 - Display, 
Rec.1886 Rec.2020 - Display, 
Rec.2100-HLG - Display, 
Rec.2100-PQ - Display, 
Rec.2100-PQ - Display, 
Rec.2100-PQ - Display, 
ST2084-P3-D65 - Display, 
ST2084-P3-D65 - Display, 
ST2084-P3-D65 - Display, 
P3-D60 - Display, 
P3-D65 - Display, 
P3-D65 - Display, 
P3-D65 - Display, 
P3-DCI - Display, 
P3-DCI - Display, 
ST2084-P3-D65 - Display]

So there are two problems, first it has a bunch of duplicate entries. Second, it lists color spaces that are only in the studio config.

The studio config has the first problem, but not the second.

This generates a warning but is not an error.

We noted that a few weeks ago but this is a good reminder:

https://community.acescentral.com/t/aces-1-3-now-available/3739/17

Hi,

Thank you for the amazing work done with the configurations, I was wondering, is the Output - sRGB gone? What happen with similar color spaces, they were really useful to fix issues that the Utility sRGB Texture had with high and low ranges.

Best,
Jose

The ASWF Color Interop Forum has developed a recommendation for color spaces that should be supported for texture assets and CG rendering. The draft of the document is here.

The proposed names should be added to the OCIO ACES configs, either as the color space name or as an alias. The suffix "Texture" should be replaced with "Scene-referred".

We may want to revisit the naming of "sRGB Encoded P3-D65 - Texture" and make that an alias.

The color spaces to add are AdobeRGB, Linear AdobeRGB, and CIE-XYZ-D65 Scene-referred.

At the same time, support should be added for any MaterialX 1.39 names which are not already part of the configs. This means adding "adobergb" and "lin_adobergb". We should discuss whether to make "none" an alias of Raw. The "g18_ap1" is deprecated and does not need to be added. The rest of them are already in the configs as aliases.

This applies to both the CG and Studio configs for ACES.

The role assignments from the aces_1.2 config have sometimes been controversial and should be re-evaluated for the new configs. The aces_1.2 roles were as follows:

roles:
  color_picking: Output - sRGB
  color_timing: ACES - ACEScc
  compositing_linear: ACES - ACEScg
  compositing_log: Input - ADX - ADX10
  data: Utility - Raw
  default: ACES - ACES2065-1
  matte_paint: Utility - sRGB - Texture
  reference: Utility - Raw
  rendering: ACES - ACEScg
  scene_linear: ACES - ACEScg
  texture_paint: ACES - ACEScc

Here's a proposed strawman with updated roles for people to react to:

roles:
  aces_interchange: ACES2065-1
  cie_xyz_d65_interchange: CIE-XYZ-D65
  color_picking: sRGB - Display
  color_timing: ACEScct
  compositing_linear: ACEScg
  compositing_log: ACEScct
  data: Raw
  default: sRGB - Texture
  matte_paint: ACEScct
  scene_linear: ACEScg
  texture_paint: sRGB - Texture

Proposed changes:

• Add the interchange roles.
• Remove the rendering role since the configs are intended to be general purpose and allow the choice of a few options rather than locking into one (ACEScg and linear Rec.709 being the most common).
• Removed the reference role, since it has caused a lot of confusion and is not interpreted consistently.
• Updated ACEScc to the more recent ACEScct, which was not around when the original ACES config was developed.
• The matte/texture paint roles always seemed backwards in the original. (A matte painting needs more than sRGB range.)
• The default role is primarily for files. While ACES2065-4 specifies OpenEXR as the preferred format for ACES image files with a color space of ACES2065-1, I'm not sure that's the case in practice. Thoughts?
• The color_picking one is more challenging. We don't have a way to refer to a display+view unless we add a color space for it. However the display color space on it's own will only get the untonemapped view transform, so we may need to add a color space for sRGB with an ACES view transform, or else omit the role.

The current draft of the CG config has the following roles:

roles:
  aces_interchange: ACES2065-1
  cie_xyz_d65_interchange: CIE-XYZ-D65
  color_timing: ACEScct
  compositing_log: ACEScct
  data: Raw
  default: ACES2065-1
  scene_linear: ACEScg

So some of the proposed changes have already been implemented. Some roles were dropped and perhaps that is even preferable for some of the less used ones. But I wanted to ensure it's an intentional choice and create an issue to capture opinions.

Form working group to discuss creation and management of OCIO-curated configs, and in particular direction for a new ACES config.

As reported on Slack, srgb_texture is missing the encoding attribute (should be "sdr-video").

Update -- in addition, the 'CIE-XYZ-D65' color space should have the encoding 'display-linear', and 'Raw' should have the encoding 'data'. All other color spaces and named transforms in the Studio config have the encoding set.

Will Canon Log2 be supported in the configs at some point? Reading the linked Canon Whitepaper it says:

Q1: Is Canon Log 3 the successor to and an improved version of the existing Canon Log 2?
A: Canon Log 3 is not the successor to Canon Log 2 but the successor to Canon Log. It extends the dynamic
range by the equivalent of one stop compared with Canon Log.

Q2: Which log gamma curve: Canon Log, Canon Log 2 or Canon Log 3, would you recommend that
users should use?
A: For users who have a camera with all the log curves installed, we would recommend that Canon Log 2 or
Canon Log 3 be used. Users can choose to use either the Canon Log 2 or Canon Log 3 gamma curve
depending on their workflows. Canon Log 2 is suited to those workflows where image quality can be enhanced
by grading at the postproduction stage whereas Canon Log 3 is suited to cases where users want to create the
final “look” of their images by means of simple grading without investing too much time at the post-production
stage.

thanks!

Currently the display color spaces are inactive. But this makes it difficult for people to invert view transforms. For example, bringing in an sRGB image as a back plate or image plane that will be shown under a view transform, but that view transform was effectively already applied to the source.

We had a long discussion about this before originally making them inactive, as there are a number of issues, but we should revisit to see if all of them are still valid.

If we do this, we should make Un-tone-mapped the first view transform in the list to work around a bug that is still present in older releases (prior to OCIO 2.3.1).

Apple kCGColorSpaceExtendedDisplayP3 supports float values above 1.0 for HDR/EDR display on capable Mac systems. Currently the views for the newly added Display P3 display in the Studio and CG configs only include the SDR D65 and D60 sim Output Transforms. The addition of HDR Output transforms to that list would greatly simplify working in HDR for users with suitable Apple devices.

I have previously made my own config which does exactly this, and in my (admittedly limited) testing there appear to be no issues with mixing SDR and HDR views for the same display.

The name of the configs contains a string with three versions. For example: cg-config-v1.0.0_aces-v1.3_ocio-v2.1. It is self-evident what the ACES and OCIO versions should contain but the guidelines for when to increment the config part have not been documented. The following guidelines are proposed as a strawman for further discussion:

Major version increment:

• Adding color spaces
• Adding displays

Minor version increment:

• Adding looks
• Adding new views to existing displays
• Adding named transforms
• Role changes
• Significant changes to existing transforms
• Changes to aliases

Patch version increment:

• Removing color spaces, displays, views, if they are kept in the inactive list
• Minor changes to existing transforms
• Changes to description text
• Changes to family, categories, encoding
• Changes to file_rules or viewing_rules
• Changes to active_displays, active_views, inactive_colorspaces
• Changes to default_view_transform

I'm on the fence about some of these. In many cases it could be a matter of degree (was it a big change or a small change) and so it's difficult to come up with absolutely fixed rules. Therefore, it seems prudent to refer to these as "guidelines" rather than "rules" to indicate that in some cases there will be a judgment call made by the configs working group on how to assign a new version string.

I'm noting that the configs do not appear to have any DisplayViewTransforms. Have you considered adding these? If not for all display/view combinations, then perhaps just a couple to cover the most common scenarios: ACES 1.0 SDR - Rec709 for VFX to send proxy media to offline editorial, and ACES 1.0 SDR - sRGB for CG dailies. These could then also provide an example for config authors to add more as needed.

When loading the new studio-config-v1.0.0-rc1_aces-v1.3_ocio-v2.1.ocio, I get the following warning:

[OpenColorIO Warning]: file_rules: defines a default rule using color-space 'ACES2065-1' that does not match the default role 'sRGB - Texture'.

Putting a note that we need to bump the package version in various files accordingly to the tag.

Request:
Addition of Apple Log to the OpenColorIO ACES config. I suspect this also means the addition of a new "Input/Apple" family.

Reference implementation:
A CTL-based Apple Log IDT was recently added to aces-dev at:
https://github.com/ampas/aces-dev/tree/dev/transforms/ctl/idt/vendorSupplied/apple

Documentation:
The official white paper, and example 1D LUT (.cube) are located here:
https://developer.apple.com/download/all/?q=Apple%20log%20profile

During the initial creation of the CG configurator, I made jsonpickle, used for serialization mandatory. However, it should have been an optional dependency.

There have been user requests for Sony S-Log 2 support on Slack:

References

• #87

i am a newbire in learning ACES,
i have changed the colorspace to 709 by lut file.
now i am trying to change colorspace from RED log3G10 to sRGB by ACES.
but i dont't konw to do it .
can you support a demo about log3G10 to sRGB?
thank you !

The configs need to be updated to support the release of ACES 2.0. There are many questions to resolve on the way to that goal, this issue is a placeholder for the discussion.

Open questions:

• What displays will be supported? Waiting on a list from AMPAS.
• How will backwards compatibility for ACES 1 output transforms be handled? Will ACES 1 View Transforms and Views be included in the new configs, perhaps as inactive? Will the ACES 1 configs get further updates (e.g. AppleLog and bug fixes)?
• Which configs do we want built into the OCIO library itself?
• How will D60 sim be handled? All displays will have D65 and D60 versions. Is there a way for a user to make that decision at a project level and then only see the chosen white point? Do we need to add library support to allow hierarchical view menus (i.e. a family attribute for views)?
• And, I hesitate to even mention this, what should the new views be named?