Re: Multi-part history

Larry,

This leads to performance problems when processing EXR files with high number (dozens of hundreds) of layers. For us, it was the main reason to enable multi-part when OpenEXR 2.0 came out.

Juri


From: [email protected] [mailto:[email protected]] On Behalf Of Larry Gritz
Sent: 07 April, 2015 18:37
To: Gunter Sprenger
Cc: [email protected]
Subject: Re: [Openexr-devel] Multi-part history

I think the usual convention is to use multi-part when you have multiple camera views, each of which needs the same set of channels (e.g. right and left eye, each of which have R, G, B, A, Z, etc.). But when you simply have a lot of distinct channels from the same camera (such as various lighting AOV's, as you mention), then usually it's done as a single part, with lots of channels named appropriately.



On Apr 7, 2015, at 1:30 AM, Gunter Sprenger <[email protected]<mailto:[email protected]>> wrote:


It would be great to have the possibility of sharing a z channel between parts. For each framebuffer (diffuse, indirect etc) we write out
a part and we have to include the z channel which is identical for all parts.

On 04/06/2015 07:32 PM, Piotr Stanczyk wrote:
Indeed, there was quite a long thread about that in the offline discussions when we were looking at 2.0  .. I might still have that saved off somewhere, but it might take a while.
In short, we wanted to have some commonality between parts to ensure that there was some semantic that bound these parts together which would prevent a free for all mash-up.  I seem to recall that the stereo pipe was good test case for things like display window, time code, aspect ratio etc ...
There was a desire to have a small enough set that could be potentially relaxes as time went on; going the other way is much more tricky.



Piotr


On 6 April 2015 at 08:33, Karl Rasche <[email protected]<mailto:[email protected]>> wrote:
Does anyone recall the motivation behind having common attributes shared between parts in a multi-part file?

It seems like the sort of thing that was debated and added for some good reason..

Thanks
Karl


_______________________________________________
Openexr-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/openexr-devel





_______________________________________________

Openexr-devel mailing list

[email protected]<mailto:[email protected]>

https://lists.nongnu.org/mailman/listinfo/openexr-devel
_______________________________________________
Openexr-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
Larry Gritz
[email protected]<mailto:[email protected]>

_______________________________________________
Openexr-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/openexr-devel