[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: |
Fri, 29 Jun 2007 15:29:03 -0700 (PDT) |
On 6/28/07 12:19 PM, "Jim Hourihan" <address@hidden> wrote:
> 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.
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