oiiotool: Improve guessing about output format based on inputs #2717
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
|
Is this what passes for spam these days? |
What data format does oiiotool write for its outputs? The ones specified by -d, if supplied, but otherwise it will make a guess based on the types of inputs it has seen. This patches makes several improvements: * Multi-subimage files were getting very confused because different subimages may want different data formats, and it was at best remembering data formats overall and by channel name, but not taking subimages into consideration. Make this much more specific by remembering both raw channel names (for all subimages), as well as specific channels of named subimages. * The way the input data formats were remembered had repeaded (and non-matching) code depending on whether the input was read immediately or lazily. That is now cleared up, with the logic refactored and expressed only once. * The -d directive can specify a type (for all channels), a type for a particular channel name (`channel=type`), and -- this part is new -- a type for all channels of a named subimage (specified as `subimage.*=type`) or just one channel of a specific subimage (`subimage.channel=type`). Signed-off-by: Larry Gritz <lg@larrygritz.com>
lgritz
added a commit
to lgritz/OpenImageIO
that referenced
this pull request
Oct 21, 2020
…mySoftwareFoundation#2717) What data format does oiiotool write for its outputs? The ones specified by -d, if supplied, but otherwise it will make a guess based on the types of inputs it has seen. This patch makes several improvements: * Multi-subimage files were getting very confused because different subimages may want different data formats, and it was at best remembering data formats overall and by channel name, but not taking subimages into consideration. Make this much more specific by remembering both raw channel names (for all subimages), as well as specific channels of named subimages. * The way the input data formats were remembered had repeated (and non-matching) code depending on whether the input was read immediately or lazily. That is now cleared up, with the logic refactored and expressed only once. * The -d directive can specify a type (for all channels), a type for a particular channel name (`channel=type`), and -- this part is new -- a type for all channels of a named subimage (specified as `subimage.*=type`) or just one channel of a specific subimage (`subimage.channel=type`). Signed-off-by: Larry Gritz <lg@larrygritz.com>
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.
What data format does oiiotool write for its outputs? The ones
specified by -d, if supplied, but otherwise it will make a guess based
on the types of inputs it has seen.
This patches makes several improvements:
Multi-subimage files were getting very confused because different
subimages may want different data formats, and it was at best
remembering data formats overall and by channel name, but not taking
subimages into consideration. Make this much more specific by
remembering both raw channel names (for all subimages), as well as
specific channels of named subimages.
The way the input data formats were remembered had repeaded (and
non-matching) code depending on whether the input was read
immediately or lazily. That is now cleared up, with the logic
refactored and expressed only once.
The -d directive can specify a type (for all channels), a type for a
particular channel name (
channel=type), and -- this part is new --a type for all channels of a named subimage (specified as
subimage.*=type) or just one channel of a specific subimage(
subimage.channel=type).Fixes #2710
Signed-off-by: Larry Gritz lg@larrygritz.com