Re: [Openexr-user] EXR layer naming conventions

[Jim Hourihan]

On Jul 3, 2007, at 12:59 AM, Michael Wolf wrote:

> The only problem I see is that it would not allow older importers  
> that don't support layers to load any data.
>
> How about an attribute "Stereoscopic", which defines the name for  
> the other layer.
>
> So you'd either end up with:
>
>         Stereoscopic = "right"                
>         [RGBAZ]
>         right.[RGBAZ]
>
> or
>         Stereoscopic = "left"         
>         left.[RGBAZ]
>         [RGBAZ]
>
> and older loaders could at least display something?

I see your point.

The technique of having an attribute that provides meaning to the  
channels/layers could work; but one could argue that it shuffles the  
problem to a new location instead of solving it.

I started this thread because I need to have some way to recognize in  
general the meaning of channel names. R G B A Z have de-facto meant  
red, green, blue, alpha, and depth -- except when "red", "green",  
"blue", or "alpha" are used (so far always in a layer) in which case  
those replace R G B A. The problem is exacerbated by stereo which is  
similarly plagued by ambiguities in channel naming.

So, we have three choices:

1) Ignore the issue: a de-facto standard will emerge or there will be  
annoyances with one or more facilities or tools writing EXRs that are  
readable but not necessarily interpretable by others.

2) Agree on a semantic tagging mechanism. Either add additional per- 
channel information in the file format itself or agree on an  
attribute which maps channel names to semantic keywords/tags. In this  
case, channel names are completely decoupled from their  
interpretation. The EXR spec or a third party document explicitly  
indicates a handful of tags (RED709, GREEN709, BLUE709,  
PREMULT_ALPHA, DEPTH_METERS, LEFT, RIGHT) which could be combined  
(e.g. RED709 RIGHT).

3) Agree on a channel naming convention or include a convention which  
is part of the EXR spec. Certain names are defined to mean something:  
R == red, etc. EXR implicitly does this with the layerless R G B A  
channels already.

I would argue that option #1 is a no-go: IMHO DPX and TIFF suffer  
from similar problems which cause endless nauseating arguments. As  
EXR becomes adopted by bigger players they may just decide this  
without input and the results may be designed by a committee.

I think a combination of option #2 and #3 is in order:

Declare the R G B A are reserved to mean linear light Rec709 red,  
green, blue + premultipled alpha *unless* chromaticities are present  
in the header in which case they are tristimulous values which need  
to be interpreted in conjunction with the derived chromaticity  
matrix. Z is a depth channel indicating distance from the fragment at  
the pixel to camera. This would require some changes for people using  
"red", "green", "blue" to mean R G and B in their layers.

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.).

And the ones we just discused: "PerChannelCamera" which maps  
"channelname" = "left" or "right" or "center". Along with  
"PerChannelCameraMatrix" or some such.

Thoughts?

        -Jim