Discussion:
[Openexr-user] EXR layer naming conventions
Jim Hourihan
2007-06-28 19:19:41 UTC
Permalink
Hi All, I was wondering how people are using EXR layers. Especially
how the layers are being named and if there are any defacto standards
out there.

For example:

channels: R G B A Z diff.red diff.green diff.blue ...

Where the diff layer has slightly different channel naming convention
than the "default" layer. I assume that some of these things are a
result of matching channel/layer names to shader parameters. A brief
email conversation with Florian produced the idea that some sort of
recommended best practices might established for layer naming, but
I'm wondering if that's even feasible.

I'm also interested in whether people are using EXR to hold stereo
pairs and if so how.

Thanks.

-Jim
Michael Wolf
2007-06-28 20:27:22 UTC
Permalink
Post by Jim Hourihan
Hi All, I was wondering how people are using EXR layers. Especially
how the layers are being named and if there are any defacto standards
out there.
I'm not sure about standards, but exrTrader for LightWave uses the buffer names as defined by Lightwave itself.

They are either RGB or just a single named channel, the exception being the motion buffer.

Here is a list:

R G B A Z
Raw Colour: Raw.R .G .B
Reflection Colour: Refl.R .G .B
Diffuse Colour: Diff.R .G .B
Specular Colour: Spec.R .G .B
Backdrop Colour: Backdrop.R .G .B
PreEffect Colour: PreEffect.R .G .B

Single channels:
Special, Luminosity, Diffuse, Specularity, Reflectivity, Transparency, Shading, Shadow, Geometry, DiffShade, SpecShade

Motion.X .Y

I'd be eager to have some standardization out there (as far as that is possible with the different kinds of render outputs). exrTrader supports channel naming presets, so I could add a new one any time.

Cheers,
Mike
--
db&w Bornemann & Wolf GbR
Dagmar Bornemann, Michael Wolf
Seyffer Str. 34
70197 Stuttgart
Germany

http://www.db-w.com
http://www.infinimap.com
tel: +49 (711) 664 525-0
fax: +49 (711) 664 525-1
icq: 252887990
skype: lupus_lux
Brendan Bolles
2007-06-28 21:07:17 UTC
Permalink
Post by Michael Wolf
Special, Luminosity, Diffuse, Specularity, Reflectivity,
Transparency, Shading, Shadow, Geometry, DiffShade, SpecShade
Motion.X .Y
I'd be eager to have some standardization out there (as far as that
is possible with the different kinds of render outputs). exrTrader
supports channel naming presets, so I could add a new one any time.
I'd really like the pseudo-standard to be that if you're doing
layers, the channel names should all be single-letters like Michael
has there. Are there cases where you reed to put more letters? That
would make it easier for people to make layers like "guy.head.spec.R"
and you know that everything before is part of the layer name and the
"R" is the channel.

And also, I think that is you have multiple channels that are tied
together, they should always use the layer format, like Motion.X and
Motion.Y. I see some files that just say "X" or "Y" or "VX" or
"velX" and there's no good algorithmic way to know they're tied
together.



Brendan
Jonathan Litt
2007-06-29 22:29:03 UTC
Permalink
Post by Jim Hourihan
Hi All, I was wondering how people are using EXR layers. Especially
how the layers are being named and if there are any defacto standards
out there.
channels: R G B A Z diff.red diff.green diff.blue ...
Where the diff layer has slightly different channel naming convention
than the "default" layer. I assume that some of these things are a
result of matching channel/layer names to shader parameters. A brief
email conversation with Florian produced the idea that some sort of
recommended best practices might established for layer naming, but
I'm wondering if that's even feasible.
Agreed, it would be great if the spec had some recommendations in this area as apps are starting to diverge more and more here. The "Technical Introduction" document currently has the following section:

-------------
Channel Names

An OpenEXR image can have any number of channels with arbitrary names. The specialized RGBA image interface assumes that channels with the names "R", "G", "B" and "A" mean red, green, blue and alpha. No predefined meaning has been assigned to any other channels. However, for a few channel names we recommend the interpretations given in the table below. We expect this table to grow over time as users employ OpenEXR for data such as shadow maps, motion-vector fields or images with more than three color channels.

name interpretation
---- --------------
Y luminance, used either alone, for gray-scale images, or
in combination with RY and BY for color images.
RY, BY chroma for luminance/chroma images, see above.
AR, AG, AB red, green and blue alpha/opacity, for colored mattes
(required to composite images of objects like colored
glass correctly).
-------------


A few thoughts on extending this:

- I think "Z" for camera depth should be added to the recommendation list. This is a de facto standard in many (if not most?) apps already.

- I agree with the other comments that "<layer>.<channel>" is the best way to go for all other channels, so that associated channels can be easily matched by layer.

- Layer names should be mostly unrestricted, but there should probably be a recommendation for nesting within layer names, for example using dots or underscores (e.g. layer.sublayer.channel). This could support things like stereo images each with multiple layers. (For what it's worth, Nuke uses "<layer>.<channel>" for all channel names, but it doesn't allow dots in the "<layer>" part.)

- For consistency, "<channel>" should, if possible, be chosen from the list of main channels: R/G/B/A/Z/Y/RY/BY. This works for layers that represent colors. Writers should be strict about using the recommended channel suffixes,
but readers should recognize other reasonable versions, like r/g/b/a,
red/green/blue/alpha, etc..

- What about scalar (single value) layers or layers that represent 3D data like points/normals/vectors? Some apps currently use x/y/z as channel suffixes, e.g. N.x, N.y, and N.z for normals. At least one uses nx, ny, and nz with no suffix. For scalars, most apps I've looked at just output the layer name without a channel suffix, e.g. "myscalar". It would be nice to have a unified, deterministic rule to handle all of these cases without requiring complex logic or lists of legal suffixes. What about using simple numerical indices for all data (non-color) channels? The layer name should be enough for apps to interpret the individual channels. Scalars could be the same, but with just a single index. For example: N.0, N.1, N.2, myscalar.0. This idea could also handle layers holding a 4-point vector or 16-element matrix at each pixel.

Thoughts? There might be a better approach than numerical indices for data channels, but I can't think of anything else simple and flexible, at least not without having a system to declare file-specific channel suffixes in a "channel suffix declarations" attribute, or something like that. That would be an interesting idea to explore, but I think we need to be practical. Anything more than a simple naming convention is unlikely to be incorporated by application developers any time soon.

-Jonathan
Jim Hourihan
2007-06-29 22:37:58 UTC
Permalink
Post by Jonathan Litt
- For consistency, "<channel>" should, if possible, be chosen from
the list of main channels: R/G/B/A/Z/Y/RY/BY. This works for layers
that represent colors. Writers should be strict about using the
recommended channel suffixes,
but readers should recognize other reasonable versions, like r/g/b/a,
red/green/blue/alpha, etc..
This is what I was hoping to avoid in my code but cannot. Obviously
if you throw non-english languages possibly represented as UTF-8 or
possibly transliterated to ASCII in the mix you've got a lot of
permutations to deal with.

I think nuke's behavior is ideal with regard to layer/channel naming.

Another possibility is to define a header attribute that provides
semantic information.

-Jim
j***@yahoo.com
2007-06-30 03:15:46 UTC
Permalink
Post by Jim Hourihan
Post by Jonathan Litt
- For consistency, "<channel>" should, if possible, be chosen from
the list of main channels: R/G/B/A/Z/Y/RY/BY. This works for layers
that represent colors. Writers should be strict about using the
recommended channel suffixes, but readers should recognize other reasonable
versions, like r/g/b/a, red/green/blue/alpha, etc..
This is what I was hoping to avoid in my code but cannot. Obviously
if you throw non-english languages possibly represented as UTF-8 or
possibly transliterated to ASCII in the mix you've got a lot of
permutations to deal with.
I'm not sure I follow ... just to recap my previous message, what I was suggesting is that full channel names beyond the standard ones be formatted "<layer>.<channel>" where "<layer>" could be freeform, including UTF-8 if desired (would be up to the application), but "<channel>" be rather strict, consisting of only R/G/B/A/Z/Y/RY/BY/AR/AG/AB (all previously defined in the spec except for Z) or plain integers. Readers could be flexible and also recognize lowercase or full words for "<channel>" (e.g. "red") or possibly other cases, but wouldn't be required to in order to be compliant. Do you think anything about a system like that would be unfriendly in regards to usage of UTF-8?

For example this is what the full channel names could look like for a file comprising main output, a diffuse layer, a spec layer saved as luminance/chrominance (a contrived example), a scalar noise layer, a uv layer, a normal layer, and then everything duplicated for a left-side stereo image:

R G B A Z
diff.R diff.G diff.B
spec.Y spec.RY spec.BY
noise.0
uv.0 uv.1
N.0 N.1 N.2
left.R left.G left.B left.A left.Z
left.diff.R left.diff.G left.diff.B
left.spec.Y left.spec.RY left.spec.BY
left.noise.0
left.uv.0 left.uv.1
left.N.0 left.N.1 left.N.2

The key idea here is the consistency of a) using <layer>.<channel> for all non-standard channels, even scalar channels and b) having the <channel> part in <layer>.<channel> conform to a standard.

-Jonathan
Jim Hourihan
2007-06-30 05:35:10 UTC
Permalink
Post by j***@yahoo.com
Post by Jonathan Litt
but readers should recognize other reasonable
versions, like r/g/b/a, red/green/blue/alpha, etc..
This is the part I was referring to. The abundance of reasonable
alternate R G B channel names. There are a lot of them. I completely
agree with everything else you said.

-Jim
Post by j***@yahoo.com
I'm not sure I follow ... just to recap my previous message, what I
was suggesting is that full channel names beyond the standard ones
be formatted "<layer>.<channel>" where "<layer>" could be freeform,
including UTF-8 if desired (would be up to the application), but
"<channel>" be rather strict, consisting of only R/G/B/A/Z/Y/RY/BY/
AR/AG/AB (all previously defined in the spec except for Z) or plain
integers. Readers could be flexible and also recognize lowercase or
full words for "<channel>" (e.g. "red") or possibly other cases,
but wouldn't be required to in order to be compliant. Do you think
anything about a system like that would be unfriendly in regards to
usage of UTF-8?
For example this is what the full channel names could look like for
a file comprising main output, a diffuse layer, a spec layer saved
as luminance/chrominance (a contrived example), a scalar noise
layer, a uv layer, a normal layer, and then everything duplicated
R G B A Z
diff.R diff.G diff.B
spec.Y spec.RY spec.BY
noise.0
uv.0 uv.1
N.0 N.1 N.2
left.R left.G left.B left.A left.Z
left.diff.R left.diff.G left.diff.B
left.spec.Y left.spec.RY left.spec.BY
left.noise.0
left.uv.0 left.uv.1
left.N.0 left.N.1 left.N.2
The key idea here is the consistency of a) using <layer>.<channel>
for all non-standard channels, even scalar channels and b) having
the <channel> part in <layer>.<channel> conform to a standard.
-Jonathan
Drew Hess
2007-06-30 06:13:19 UTC
Permalink
Post by j***@yahoo.com
Post by Jim Hourihan
This is what I was hoping to avoid in my code but cannot. Obviously
if you throw non-english languages possibly represented as UTF-8 or
possibly transliterated to ASCII in the mix you've got a lot of
permutations to deal with.
Readers could be flexible and also recognize lowercase or full words
for "<channel>" (e.g. "red") or possibly other cases,
What about "rouge", or "rojo", or "hong", or Ô ?
Post by j***@yahoo.com
but wouldn't be required to in order to be compliant. Do you think
anything about a system like that would be unfriendly in regards to
usage of UTF-8?
As long as you're just comparing strings for equality, any
ISO-compliant C++ std::string implementation can handle UTF-8
encodings. However, once you introduce case-insensitive comparisons
on UTF-8 strings, you need a proper UTF-8 string facility, which ISO
C++ (and OpenEXR) lacks. Then there's the whole issue of regexps,
which would be really useful in the presence of layers (e.g., "*.r"),
but get a lot tougher (and slower) when required to support UTF-8
encodings.

I think both UTF-8 and flexible channel names are important issues.
Unfortunately, support for one complicates support for the other.

d
Jim Hourihan
2007-07-03 02:03:25 UTC
Permalink
Just to add some more fuel to the fire: has anybody been using EXR to
store stereo data?
If so how? "left" and "right" layers? etc, etc.

My inclination is to write them as:

left.[RGBAZ]
right.[RGBAZ]

and if there are additional layers (e.g.):

left.diffuse.[RGB]
right.diffuse.[RGB]

But it seems like nailing down "left" and "right" (and/or "center")
would be a good idea
along with any accompanying attributes (matrices).

-Jim
Post by Jim Hourihan
Hi All, I was wondering how people are using EXR layers. Especially
how the layers are being named and if there are any defacto
standards out there.
channels: R G B A Z diff.red diff.green diff.blue ...
Where the diff layer has slightly different channel naming
convention than the "default" layer. I assume that some of these
things are a result of matching channel/layer names to shader
parameters. A brief email conversation with Florian produced the
idea that some sort of recommended best practices might established
for layer naming, but I'm wondering if that's even feasible.
I'm also interested in whether people are using EXR to hold stereo
pairs and if so how.
Thanks.
-Jim
_______________________________________________
Openexr-user mailing list
http://lists.nongnu.org/mailman/listinfo/openexr-user
Michael Wolf
2007-07-03 07:59:12 UTC
Permalink
On Tue, 03 Jul 2007 04:03:25 +0200, Jim Hourihan <***@tweakfilms.com> w=
rote:

Hi Jim,
Post by Jim Hourihan
If so how? "left" and "right" layers? etc, etc.
left.[RGBAZ]
right.[RGBAZ]
left.diffuse.[RGB]
right.diffuse.[RGB]
But it seems like nailing down "left" and "right" (and/or "center")
would be a good idea
along with any accompanying attributes (matrices).
The only problem I see is that it would not allow older importers that d=
on't support layers to load any data.

How about an attribute "Stereoscopic", which defines the name for the ot=
her layer.

So you'd either end up with:

Stereoscopic =3D "right" =

[RGBAZ]
right.[RGBAZ]

or
Stereoscopic =3D "left" =

left.[RGBAZ]
[RGBAZ]

and older loaders could at least display something?

Cheers,
Mike

-- =

db&w Bornemann & Wolf GbR
Dagmar Bornemann, Michael Wolf
Seyffer Str. 34
70197 Stuttgart
Germany

http://www.db-w.com
http://www.infinimap.com
tel: +49 (711) 664 525-0
fax: +49 (711) 664 525-1
icq: 252887990
skype: lupus_lux
Jim Hourihan
2007-07-03 17:58:22 UTC
Permalink
Post by Michael Wolf
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.
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
Jim Hourihan
2007-07-03 18:12:59 UTC
Permalink
Post by Jim Hourihan
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.

-Jim
j***@yahoo.com
2007-07-05 23:26:09 UTC
Permalink
Post by Jim Hourihan
Post by Jim Hourihan
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
Jim Hourihan
2007-07-06 18:20:26 UTC
Permalink
Post by j***@yahoo.com
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
Your idea seems like it would do the trick. Since we're already
assuming channel names with dots are in a layer hierarchy, applying
that same convention to attribute names gives us channel and layer
attributes right now. (Assuming its ok to use dots in an attribute
name). Any API like the layer API would be gravy.
Post by j***@yahoo.com
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.
Agreed. But maybe we just want a "best practices" document for film.
I know EXR is being used in other settings (like NASA) and my guess
is that they have a completely different set of issues to deal with
(e.g., 7 "color" channel images).

-Jim

Loading...