OCIOZ archive feature (#1627)

[cedrik-fuoco-adsk]

This PR is the implementation of the OCIOZ archive config feature (https://github.com/AcademySoftwareFoundation/OpenColorIO/issues/1627).

• The OCIO environment variable can now be set to an OCIOZ archive and an archive will work in CreateFromFile. e.g. export OCIO=/home/user/myconfig/myarchived_config.ocioz

• A new abstract class called ConfigIOProxy has been added to the Public API.

  This abstract class allows a client application to implement a derived class that can provide a different way of getting the config, the LUTs, and the existence of the LUTs.

  The three methods are :

  getConfigData:
  Return the config
  
  getLutData:
  Return the LUT
  
  getFastLutFileHash:
  Check for the existence of a LUT and return the hash. It must return the hash because
  OCIO cannot use the default hash computation here since the LUT might not be from the filesystem.
  

• CreateFromConfgIOProxy has been added to the Public API which allows creation of a config from a derived instance of ConfigIOProxy.

• isArchivable has been added to the Public API which tell you if the current config is archivable or not.

  • A config is archivable based on the following requirements:
    • The working directory is set and it is an absolute path.
    • Search paths and FileTransform source have no absolute paths.
    • All LUTs must be inside the working directory on the filesystem.
    • A search path or a FileTransfrom source must not start with a context variable.

• A new app called "ocioarchive" provides the following:

  • Archive a config using the $OCIO environment variable
  • Archive a config by specifying the config file (e.g. myconfig.ocio)
  • Extract an OCIOZ archive
  • List the contents of an OCIOZ archive

• ociocheck:

  • Prints the config CacheID in the miscellaneous section
  • Prints whether the config is archivable.

• Minizip-ng (handles the ZIP format) and ZLIB (handles compression) have been added as dependencies to OCIO.

Signed-off-by: Cedrik Fuoco [email protected]

[amyspark]

Hi @cedrik-fuoco-adsk ! I take this should fix #1580 too?

[cedrik-fuoco-adsk]

Hi @cedrik-fuoco-adsk ! I take this should fix #1580 too?

Hi @amyspark,

I would say that it should potentially fix issue #1580 based on the information on the issue.

Unfortunately, I don't have the setup or environment to test that.

[doug-walker]

Thank you for the thorough review Remi! We will push another commit to address your points.

[cedrik-fuoco-adsk]

Thanks @remia for all the comments!

The last commit should address all of your comments except the side note on splitting Config_tests.cpp.

Note that the Linux CI Build are still failing because of the issue with the CMake version.

[doug-walker]

One more commit is in progress to update a few comments.

[remia]

Here is a proposed fix for the VFX 2019 Linux builds, minizip-ng should compile successfully, there might be a follow up issue due to zlib build location using lib instead of lib64 (update the CMake module to fix that) from what I saw in my local Docker container.

--- a/.github/workflows/ci_workflow.yml
+++ b/.github/workflows/ci_workflow.yml
@@ -252,6 +252,10 @@ jobs:
     steps:
       - name: Checkout
         uses: actions/checkout@v2
+      # minizip-ng requires CMake 3.13+ but VFX2019 image ships with 3.12
+      - name: Upgrade VFX2019 CMake
+        run: pip install cmake==3.13.3
+        if: matrix.vfx-cy == '2019'
       - name: Install docs env
         run: share/ci/scripts/linux/yum/install_docs_env.sh
         if: matrix.build-docs == 'ON'

[remia]

I assume the remaining error can be addressed doing something similar to what we do for expat here?

[cedrik-fuoco-adsk]

I assume the remaining error can be addressed doing something similar to what we do for expat here?

The lib prefix is ok. It seems like it doesn't use CMAKE_INSTALL_LIBDIR even though it is set to "lib64". It still installs it into "ext/dist/lib" instead of "ext/dist/lib64"

EDIT: Should be all fixed now!