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 <[email protected]> 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 <[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
