Re: [Openexr-devel] Deep object ID and lack of Z

[Piotr Stanczyk]

I was suggesting it would be worthwhile to augment the document so as to avoid confusion for the cases when the 'id' channel is deep. 

On 12 November 2014 18:30, Peter Hillman <address@hidden> wrote:

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 <address@hidden> 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
address@hidden

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
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel