Improved ordering of channels for EXR files.

[lgritz]

Now we very robustly cluster "layers" together (with the unnamed layer
first, if it exists), and within each layer have a canonical RGBAZ
order.

[lgritz]

Any feedback on this, @sebastianelsner ?

[sebastianelsner]

Both images submitted on the mailing list still make iv crash on windows.
Will test CentOS tomorrow at work.

[lgritz]

These changes just address the "channels in the wrong order" problem. I don't yet have any theory about why those files would crash.

If you do a 'oiiotool broken.exr -o out.exr', does that work? That is, can you coax OIIO core into reading and writing the file if iv (OpenGL, Qt, etc.) is not in the mix?

[sebastianelsner]

using oiiotool the way you suggested works without crashing on win + linux. Also with your changes applied iv displays without crashing on CentOS, while it still does on Windows. I will try to investigate on Windows a bit more ans open a new ticket if necessary.

[sebastianelsner]

After a bit more investigating I found that the crashes are still happening on both platforms under certain circumstances:
Open iv, open test.exr (files from mailing list post) > crash
Open iv, open test_small.exr > no crash > open test.exr > no crash

It seems if I load the small file first, the large file also loads. After that I can do the usual stuff like toggling images etc.

[sebastianelsner]

Can anyone reproduce this with the steps I gave? The images are: https://dl.dropboxusercontent.com/u/82588645/oiio_exr/test.exr and https://dl.dropboxusercontent.com/u/82588645/oiio_exr/test_small.exr

[lgritz]

I still have been unable to reproduce on any platform.

Can you compile a debug version, run iv with -F (keeps in the foreground), run in the debugger such as gdb, and get a stack trace showing exactly where it's crashing?

[lgritz]

Oh, and if it's still a reproducible problem, let's open a new ticket on it.

[sebastianelsner]

I will test and report in a different ticket.