Improve OCIO (especially 2.2) support and better testing #3755
Conversation
This file contains hidden or 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
Tweak the heuristics for trying to determine which arbitrary-named color spaces are equivalent to certain known common names. For OCIO 2.2+, some of this is easier and more reliable by using the new built-in color spaces -- for example, we can transform a set of sentinel colors from an arbitrary cs into the known built-in acescg, or lin_srgb, etc., and if the values don't change, we know that cs *is* the canonical one, even if named something weird. But one problem is that for older OCIO, the built-in config is not present, so if you have a color space named, I dunno, "linear", it's hard to know what that is. Is it what we now call lin_srgb? Is it ACEScg? Something else? So the hack is: first, we try to identify a space that we think is sRGB (almost all configs have something called "srgb", because everybody needs it, and we take it at face value that if they call a cs "srgb", it's the real "srgb", fools who use the name for something else get what they deserve). We transform the sentinel colors from the srgb into the cs we are interrogating, and if they match what we expect to see from an srgb->lin_srgb transformation, then guess what -- the unknown color space must be lin_srgb! We may, in the future, expand this to deduce other spaces. But this is a start. There are other changes I made here to make this whole process much less expensive than it had been getting, there was some redundant work, and some work that only was useful for 2.2 or only useful for <= 2.1, so I only do those in the right circumstances now. Also along for the ride: improve test coverage for maketx features of colorconvert, unpremult, attrib, attrib.
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.
Tweak the heuristics for trying to determine which arbitrary-named color spaces are equivalent to certain known common names.
For OCIO 2.2+, some of this is easier and more reliable by using the new built-in color spaces -- for example, we can transform a set of sentinel colors from an arbitrary cs into the known built-in acescg, or lin_srgb, etc., and if the values don't change, we know that cs is the canonical one, even if named something weird.
But one problem is that for older OCIO, the built-in config is not present, so if you have a color space named, I dunno, "linear", it's hard to know what that is. Is it what we now call lin_srgb? Is it ACEScg? Something else? So the hack is: first, we try to identify a space that we think is sRGB (almost all configs have something called "srgb", because everybody needs it, and we take it at face value that if they call a cs "srgb", it's the real "srgb", fools who use the name for something else get what they deserve). We transform the sentinel colors from the srgb into the cs we are interrogating, and if they match what we expect to see from an srgb->lin_srgb transformation, then guess what -- the unknown color space must be lin_srgb!
We may, in the future, expand this to deduce other spaces. But this is a start.
There are other changes I made here to make this whole process much less expensive than it had been getting, there was some redundant work, and some work that only was useful for 2.2 or only useful for <= 2.1, so I only do those in the right circumstances now.
Also along for the ride: improve test coverage for maketx features of colorconvert, unpremult, attrib, attrib.