Loading multiview images with a single view from other software failed.

I understand that you can't share the file, but how were the channels in this case? Can you share the output of exrheader FILE.exr for this image?

Here's a public file that has the same issue:
https://github.com/openexr/openexr-images/blob/master/v2/Stereo/Leaves.exr

Your file breaks my 2.79 release entirely :)
I will test your patch first thing tomorrow morning just to double-check. Particularly for non-multiview cases, to make sure things are still 100%.

Thanks for reviewing!

In D2887#67955, @Dalai Felinto (dfelinto) wrote:

When rendering (-b FILE.blend -f 1) the file above with 2.79 and using exrheader we get:

multiView (type stringvector): "right"

Ok, I'll change that, this comment threw me off.

/* if rendered only one view, we treat as a a non-view render */

As for the Leaves.exr it's a file that has both views (and your patch fix it indeed). But you originally reported a file that had only one view and was Multi-View.

I think the issue specifically happens when there is one view per part. Leaves.exr has two parts with each one view, and the problematic file I have here has one part with one "main" view.

I'm insisting on this because maybe we should using the "multiView" header info also for the mono-view (left or right only) single layer exr, which we are not at the moment.

Yes, there is an inconsistency where (without this patch) we save multiView header information for mono-view renders, but then discard it when loading back the .exr. I think we should probably preserve that information for both save and load.

"/* if rendered only one view, we treat as a a non-view render */"

Right. But in this case I was referring to when we were not rendering a "mono" view, which is exactly this scenario. Misleading logic/comments are my bad though ;)

Now that I think of it, I think I left the single-layer exr without the view tag to keep it in compliance with old exr readers entirely. I may be wrong here but I think we were even using a different library to write these images back then. Anyways, +1 for including single view name header info for single-layer exrs as well.

Single-layer is perfect now. For multi-layer you introduced a few changes. They may be by design, but I would like to hear from you on these, so they would at least be mentioned in the commit log:

(1) Combined channel is no longer exported (we still export Combined.Combined, but not RenderLayer.Combined).
This is valid for files without "Views" as well as with "Views".

(2) The main "view" can be suppressed from the channel names. In 2.79 I was doing it only for single-view multi-view files. This was a more serious concern back when Multi-View was introduced, so that Blender Multi-View files would open in prior Blenders without any regressions. For now I think it's fine to have explicit Layer.Pass.view.channel for any multi-layer file, since Blender multi-layer exr is its own thing anyways.

In D2887#68007, @Dalai Felinto (dfelinto) wrote:

(1) Combined channel is no longer exported (we still export Combined.Combined, but not RenderLayer.Combined).
This is valid for files without "Views" as well as with "Views".

It's the other way around I think, this patch exports RenderLayer.Combined but no longer Combined.Combined? Combined.Combined was introduced in 2.75 along with the multiview changes, but seems to just duplicate RenderLayer.Combined for one of the render layers. What was the purpose of that?

(2) The main "view" can be suppressed from the channel names. In 2.79 I was doing it only for single-view multi-view files. This was a more serious concern back when Multi-View was introduced, so that Blender Multi-View files would open in prior Blenders without any regressions. For now I think it's fine to have explicit Layer.Pass.view.channel for any multi-layer file, since Blender multi-layer exr is its own thing anyways.

I guess you are referring to saving as "Individual"? I've updated the patch to leave out the view name from the channel name in that case again, might as well leave it unchanged.