Re: Deep object ID and lack of Z

The "technical introduction" document does define that the channel
name "id" is reserved for per-sample objectIDs, and states that all
samples with the same ID belong to the same object (page 20). Do we
need to be more specific?

It doesn't specify that the channel has to be an integer, but then I
suppose if you had less than 2048 integer IDs you could use a half
to save space in the decoded image. There's also no convention for
assigning a human-readable name to an ID number, though Florian did
propose a scheme:

http://lists.nongnu.org/archive/html/openexr-devel/2011-04/msg00007.html

On 13/11/14 14:13, Piotr Stanczyk
wrote:

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