Revise OpenEXR sorting of channel names into canonical order

[lgritz]

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", "y", AND "z", and if all three
are present, 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. If all of x,y,z
aren't found in a layer, we continue to use the old heuristic.

Signed-off-by: Larry Gritz lg@larrygritz.com

[lgritz]

We realized that saving 2D data ("X" and "Y" only) will reverse the order.

I just pushed an update that revises the heuristic: If "X" is found, and either "Y" or "Z", then it assumes it's some kind of spatial data and that x,y,z should be in that order, not confused with Y as luminance and Z as depth.

[fpsunflower]

I'm sure the logic is sound, but feels like something that deserves unit tests spelling out all these corner cases (and the common ones).

[lgritz]

You're right, I'll add some tests.

[lgritz]

Turns out the openexr-images collection had something with exactly the case we are addressing here. Added a test of that to our testsuite.