-
Notifications
You must be signed in to change notification settings - Fork 597
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revise OpenEXR sorting of channel names into canonical order (#2595)
Brief background: OpenEXR sorts channel names alphabetically. Most formats dont allow channel naming at all, let alone forcing a particular order contrary to the order the user tries to write it to the file. OIIO promises that if there is RGB, they will be first and in that order, next will be alpha if present, then depth, then everything else. So our exr reader will reshuffle channels into this canonical order before presenting to the calling app. In addition to literal R, G, and B being first, also obvious synonyms are accepted and understood to be first ("Red", "Green", "Blue", and also "Y" in case it's just a 1-channel intensity and then maybe alpha). A user noticed an interesting edge case: what if it's a normal map or positional info, so the channel names are x, y, z? You want it in that order (coincidentally alphabetical), duh. But the current heuristic will reorder it as Y (mistaking for intensity), Z (mistaking for depth), then X (a non-special name, so goes last). Ick! The solution is that we need a more sophisticaed heuristic. This patch changes the logic to first just sort by layer, then within each layer, look to see if there are channels "x", and either "y" or "z", and if so, then we can conclude that it means something spatial and that Y isn't really intensity and Z isn't really depth for that particular layer, so an alternate ordering is used. In all other cases, we continue to use the old heuristic. Signed-off-by: Larry Gritz <[email protected]>
- Loading branch information
Showing
3 changed files
with
123 additions
and
15 deletions.
There are no files selected for viewing
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
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
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