Hi Ton,
There was some discussion about the positioning of the 'views' name part
when developing the multiview EXR standard. As you say, there's little
difference from a developer point of view.
It seemed to us nicer that an alphabetical list of channels shows layers
and passes first. It's easier to navigate that channel list to select
individual passes. Arguably, the fact there are multiple views of a pass
in an EXR is only as interesting to the artists as that it contains
R,G,B,A channels. Conceptually, the image contains "stereo layers and
passes" rather than two separate sets of layers and passes, one for each
view. Now that the standard is more widely adopted this isn't so much of
a consideration, but was handy in the days that there were packages that
could handle multiple layers in an EXR but didn't understand the
multiview extensions.
From an efficiency point of view, EXR stores channel data in
alphabetical order by channel name. Since stereo views of the same pass
are often almost identical, storing them adjacently may well help
compression and give a smaller file. However, we didn't really extensive
testing of this with typical imagery.
It would be worth looking at the EXR-2.0 code base (currently the
develop branch on github) for stereo images too: that doesn't store the
view in the channel name, instead storing it in the part's 'view'
attribute. ImfPartHelper.h generates correct multiview channel names and
recommended part assignments for both (EXR-2.0) and single part
(EXR-1.7.X compatible) multiview EXRs, so you should be able to handle
both versions with very little extra code.
Peter
On 04/09/2013 12:29 AM, Ton Roosendaal wrote:
Hi all,
There's a project in Blender to get (at last ;) good stereo support integrated
for the render/composite/display pipeline.
Obviously we'll try to align well to the proposed OpenEXR spec of it.
http://www.openexr.com/MultiViewOpenEXR.pdf
My question is why the authors proposed to insert the view 'layers' on the
lowest level in the structure. Was this for compatibility, or other reasons?
In Blender internally, we use a list of "render layers" with a list of "passes"
which each have the channel buffers. The paper proposes to then add views as follows:
render_result -> layers -> passes -> views -> channels
An other way would be to move views to the top level:
render_result -> views -> layers -> passes -> channels
It probably doesn't matter much (exr file read can map to how we store it
internally), but I'd be very interested to hear if there's people here who did
a stereo migration for their pipelines and can share some experience.
Thanks,
-Ton-
------------------------------------------------------------------------
Ton Roosendaal Blender Foundation t...@blender.org www.blender.org
Blender Institute Entrepotdok 57A 1018AD Amsterdam The Netherlands
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
