openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] Interpreting Deep Images, Revised Document


From: Peter Hillman
Subject: Re: [Openexr-devel] Interpreting Deep Images, Revised Document
Date: Wed, 30 Oct 2013 13:45:57 +1300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

I can't think of a realistic reason why data can't be written 'SORTED' rather than 'MESSY', since a sort on the samples isn't particularly expensive compared to writing them, and it causes no extra data. It's possible you want to sort the samples according to some scheme other than depth order, but I can't think why!

Note that merging two tidy deep images does not give back a tidy result, so tidying separate elements before writing to EXRs could be wasted effort

Florian's document gives examples where overlapping is necessary: tidying images containing overlapping samples with different motion vectors or object identifiers causes loss of data.

On 30/10/13 12:43, Christopher Horvath 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 <address@hidden> 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 <address@hidden> 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
address@hidden




_______________________________________________
Openexr-devel mailing list
address@hidden
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.


_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel


reply via email to

[Prev in Thread] Current Thread [Next in Thread]