OpenColorIO 2.2 support -- preliminaries #3662
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Make it so that when we build against OCIO 2.2, it is possible to specify the built-in configs. The logic had previously precluded this, because at one point it checks to see if the passed config or contents of env $OCIO was an existing file. Now you can set OCIO to "ocio://default", for example, and it will be used by OIIO. * Expose getAliases (I think that has been there for a while but we didn't expose in in our ColorConfig wrapper). * Expose isColorSpaceLinear (new to OCIO 2.2) * New OIIO global getattribute query: "opencolorio_version" returns the human-readable version string (such as "2.2.0"). * Some miscellaneous other cleanup in color_ocio.cpp * Change in color methodology for test suite: Previously, for every call to oiiotool in the testsuite, we passed a `--colorconfig` argument to oiiotool pointing it to the sample colorconfig that we ship in the testsuite. Here, I'm changing it so that the cmake setup for tests sets the OCIO env variable for all tests, so no explicit --colorconfig is necessary, and thus you won't see a path to the config in any of the test output files if they need to echo the command line arguments (and you'll see several test outputs altered in this way). This is a prelude to later changes that will use the built-in configs themselves for tests, when available. More interesting changes coming in subsequent PRs.
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Nov 16, 2022
) * Make it so that when we build against OCIO 2.2, it is possible to specify the built-in configs. The logic had previously precluded this, because at one point it checks to see if the passed config or contents of env $OCIO was an existing file. Now you can set OCIO to "ocio://default", for example, and it will be used by OIIO. * Expose getAliases (I think that has been there for a while but we didn't expose in in our ColorConfig wrapper). * Expose isColorSpaceLinear (new to OCIO 2.2) * New OIIO global getattribute query: "opencolorio_version" returns the human-readable version string (such as "2.2.0"). * Some miscellaneous other cleanup in color_ocio.cpp * Change in color methodology for test suite: Previously, for every call to oiiotool in the testsuite, we passed a `--colorconfig` argument to oiiotool pointing it to the sample colorconfig that we ship in the testsuite. Here, I'm changing it so that the cmake setup for tests sets the OCIO env variable for all tests, so no explicit --colorconfig is necessary, and thus you won't see a path to the config in any of the test output files if they need to echo the command line arguments (and you'll see several test outputs altered in this way). This is a prelude to later changes that will use the built-in configs themselves for tests, when available. More interesting changes coming in subsequent PRs.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Make it so that when we build against OCIO 2.2, it is possible to specify the built-in configs. The logic had previously precluded this, because at one point it checks to see if the passed config or contents of env $OCIO was an existing file. Now you can set OCIO to "ocio://default", for example, and it will be used by OIIO.
Expose getAliases (I think that has been there for a while but we didn't expose in in our ColorConfig wrapper).
Expose isColorSpaceLinear (new to OCIO 2.2)
New OIIO global getattribute query: "opencolorio_version" returns the human-readable version string (such as "2.2.0").
Some miscellaneous other cleanup in color_ocio.cpp
Change in color methodology for test suite: Previously, for every call to oiiotool in the testsuite, we passed a
--colorconfigargument to oiiotool pointing it to the sample colorconfig that we ship in the testsuite. Here, I'm changing it so that the cmake setup for tests sets the OCIO env variable for all tests, so no explicit --colorconfig is necessary, and thus you won't see a path to the config in any of the test output files if they need to echo the command line arguments (and you'll see several test outputs altered in this way). This is a prelude to later changes that will use the built-in configs themselves for tests, when available.More interesting changes coming in subsequent PRs.