Re: Deep object ID and lack of Z

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