Re: [Openexr-user] EXR layer naming conventions

[jonathan . litt]

> 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