No, not a big problem, I just wanted to make sure it was required. I'm not yet very deep (excuse the pun) in the "comp" part of deep comp -- I've written the renderer part, and know it's outputting sorted, non-overlapping samples, and as I write various reading software, I'm just trying to make sure that the added complexity of handling messy files (which I'm not generating) has a justification.
On Oct 29, 2013, at 4:43 PM, Christopher Horvath <blackenc...@gmail.com> wrote: > Hey Larry, > > It's common to pre-comp work you're doing while compositing, or to work in > stages. By not requiring a Deep Pixel (in Nuke, or in EXR2) to be "tidy", it > makes merging deep pixels trivial, as well as keeping the amount of data > significantly lower. By way of example, look at how the deep pixels in the > paper have more points of data after being tidied. Peter Hillman had some > specific examples showing how tidied volume renders became significantly > larger than their untidied versions. Since the major downside, or > limitation, of deep workflows is their increased data usage - every step > which can prevent additional data bloat is one we should take! > > Given that the paper provides a performant code sample which will tidy and > merge samples, one that can be used by client applications, is this a major > concern? > > Chris > > > > On Tue, Oct 29, 2013 at 4:38 PM, Larry Gritz <l...@larrygritz.com> wrote: > Can you elaborate on why the new document puts it on the head of the reader > to deal with overlapping or unsorted samples? What are the circumstances in > practice that lead to "MESSY" deep files? > > -- lg > > > On Oct 28, 2013, at 9:39 AM, Florian Kainz <ka...@ilm.com> wrote: > > > > > - Samples in a single pixel are explicitly allowed to be unsorted > > and overlapping. The previous version assumed that samples always > > had to be sorted and non-overlapping, but that is not how deep > > images are used in practice. > > > > -- > Larry Gritz > l...@larrygritz.com > > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > > > > -- > I think this situation absolutely requires that a really futile and stupid > gesture be done on somebody's part. And we're just the guys to do it. -- Larry Gritz l...@larrygritz.com
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel
