Re: Deep object ID and lack of Z

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