[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Openexr-user] EXR layer naming conventions
From: |
jonathan . litt |
Subject: |
Re: [Openexr-user] EXR layer naming conventions |
Date: |
Thu, 5 Jul 2007 16:26:09 -0700 (PDT) |
> On Jul 3, 2007, at 10:58 AM, Jim Hourihan wrote:
>
>> In addition, one or more attributes ala Michael's suggestion can be
>> present which provides interpretation information per-channel.
>> These would map channel names to values. Not all channels need be
>> present in any map. The EXR spec or a similar document would
>> clearly indicate some of the per-channel map names and their values
>> (e.g., "PerChannelUnits" has "centimeters", "meters", "kilometers",
>> "feet", "yards", etc.).
>
> Rereading my email again I realized what I'm hoping for is per-
> channel attributes and some conventions on what their values mean.
> Maybe an interface like that for layers could be added to the
> ChannelList class to make this easy to use.
Some of the examples you mention seem like they would make more sense as
per-layer attributes rather than per-channel attributes. For example a camera
matrix, or units for things like normal and vector layers. (If something like a
camera matrix weren't specified per-layer then readers would need to be able to
handle cases like some channels not having the attribute or some having
inconsistent values.)
Implementation-wise, do you think that it would be preferable to have new
attribute types which themselves could store lists of attributes (similar to
"chlist"), or to use the top-level list of attributes and recognize "."
notation in attribute names? e.g.:
attribute: value:
layer1.cameraMatrix some matrix ...
layer2.cameraMatrix some matrix ...
vs.
PerLayerCameraMatrix (layer1: matrix..., layer2: matrix...)
The former could be used with the current file format and attribute interface.
Helper functions like you mention could ease lookup, but wouldn't be required
to get started. The latter might not require a new file format but would at
least require new compound attribute types in the interface.
And of course all of this would require a set of recommended mappings to be
useful. This is still somewhat divorced from the previous discussion about how
much guidance the spec should provide regarding channel and layer naming
*unless* if the set of recommended mappings were so complete as to render
channel/layer names inconsequential.
-Jonathan