Re: Deep object ID and lack of Z

I think it is not unreasonable to append the documentation with an explicit
mention of using a specific channel for object identifiers. We already
mention the use case when presenting the UINT data type.

Piotr



On 12 November 2014 16:36, Peter Hillman <[email protected]> wrote:

>  There are no hard requirements for a "Z" channel: the library
> implementation deliberately does not enforce any naming conventions. If you
> have control over all the tools which will read and write that data you are
> free to do what you like.  Don't expect it to work with any third party
> tools, though.
>
> If you just store objectIDs without depth or alpha, you will still be
> writing a "valid OpenEXR file" but not one with a valid standard
> interpretation. If you tried to open that in some third party viewer, I'd
> expect third party tools either to display a blank image, or else to report
> a (hopefully meaningful) error.
>
> Perhaps there's a misnomer in the documentation.  The "Technical
> Introduction" specifically states the channel names are arbitrary and that
> RGBAZ etc have special interpretation, but it does not say they are
> required. The "Interpreting Deep Pixels" *does* state that Z is required,
> but only in the context of a 'normal deep image' representing point or
> volume samples in depth. The purpose of that document is to specify how to
> generate such images so they'll work with standard image viewers, and in
> particular deep compositing packages, and how those packages should handle
> that data and merging images.
>
> In this case, the objects won't be merged and there's no expectation that
> an image will display "correctly" by any  tool, and there's no depth
> channel, so I'd say you can do what you like, though the object ID channel
> should be called "id"
>
> By analogy, there is a convention of how to store RGBA in a regular EXR
> and what those values mean. You are permitted to store anything you like
> instead, but there are no conventions. You can store only a UV map into a
> regular tiled EXR, with channels called "u" and "v", or "s" and "t". That's
> valid, but non-standard, and there's nothing to specify how UV coordinates
> should be interpreted. Many tools would open that image as blank, since
> they'd expect to find RGB data. An objectID-only deep image would be the
> same.
>
> peter
>
>
> On 13/11/14 10:36, Richard Hadsell wrote:
>
> On 11/12/2014 04:14 PM, Larry Gritz wrote:
>
> The OpenEXR tech documents make it fairly clear that deep OpenEXR files
> must contain a "Z" channel in the base layer.
>
> Some people have talked about OpenEXR deep files as a container for object
> IDs (stored as int32) that allows for a differing number of object ID
> values per pixel. Ideally, there would be only one channel, "id", of type
> int32. There is no need for (or meaning of) depth for this use case, but
> technically this would not be a valid OpenEXR file.
>
> Thoughts? Is anybody else in favor of relaxing the hard requirement for Z
> channels, at least for the special case of other channels containing only
> integer values?
>
>
> --
> Larry Gritz
> [email protected]
>
>
> I agree.  Supporting channels with varying numbers of samples per pixel
> should not be limited to data that depend on depth, even if the feature is
> named "deep data".  I am sure that users will find other uses for the
> feature, and I am surprised that Z seems to be a requirement.
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>

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