EXR layer naming conventions

<pre><span style="font-size: 130%;">http://www.mail-archive.com/openexr-user@nongnu.org/msg00178.html<br /><br />R G B A Z<br />Raw Colour: Raw.R .G .B<br />Reflection Colour: Refl.R .G .B<br />Diffuse Colour: Diff.R .G .B<br />Specular Colour: Spec.R .G .B<br />Backdrop Colour: Backdrop.R .G .B<br />PreEffect Colour: PreEffect.R .G .B<br /><br />Single channels:<br />Special, Luminosity, Diffuse, Specularity, Reflectivity, Transparency, Shading,<br />Shadow, Geometry, DiffShade, SpecShade<br /><br />Motion.X .Y<br /><br /><tt>the channel names should all be single-letters, </tt><tt>Are there cases where you reed to put more letters? That<br /></tt><tt>would make it easier for people to make layers like "guy.head.spec.R"<br /></tt><tt>and you know that everything before is part of the layer name and the<br /></tt><tt>"R" is the channel.<br /><br /></tt><tt>And also, I think that is you have multiple channels that are tied<br /></tt><tt>together, they should always use the layer format, like Motion.X and<br /></tt><tt>Motion.Y. I see some files that just say "X" or "Y" or "VX" or<br /></tt><tt>"velX" and there's no good algorithmic way to know they're tied<br /></tt><tt>together.<br /><br />-----------------------------------------------------------------------------<br /><br /></tt>Channel Names<br /><br />An OpenEXR image can have any number of channels with arbitrary names. The<br />specialized RGBA image interface assumes that channels with the names "R", "G",<br />"B" and "A" mean red, green, blue and alpha. No predefined meaning has been<br />assigned to any other channels. However, for a few channel names we recommend<br />the interpretations given in the table below. We expect this table to grow over<br />time as users employ OpenEXR for data such as shadow maps, motion-vector fields<br />or images with more than three color channels.<br /><br />name interpretation<br />---- --------------<br />Y luminance, used either alone, for gray-scale images, or<br />in combination with RY and BY for color images.<br />RY, BY chroma for luminance/chroma images, see above.<br />AR, AG, AB red, green and blue alpha/opacity, for colored mattes<br />(required to composite images of objects like colored<br />glass correctly).<br />-------------<br /><br /><br />A few thoughts on extending this:<br /><br />- I think "Z" for camera depth should be added to the recommendation list. This<br />is a de facto standard in many (if not most?) apps already.<br /><br />- I agree with the other comments that "</span><layer><span style="font-size: 130%;">.</span><channel><span style="font-size: 130%;">" is the best way to<br />go for all other channels, so that associated channels can be easily matched by<br />layer.<br /><br />- Layer names should be mostly unrestricted, but there should probably be a<br />recommendation for nesting within layer names, for example using dots or<br />underscores (e.g. layer.sublayer.channel). This could support things like<br />stereo images each with multiple layers. (For what it's worth, Nuke uses<br />"</span><layer><span style="font-size: 130%;">.</span><channel><span style="font-size: 130%;">" for all channel names, but it doesn't allow dots in the<br />"</span><layer><span style="font-size: 130%;">" part.)<br /><br />- For consistency, "</span><channel><span style="font-size: 130%;">" should, if possible, be chosen from the list of<br />main channels: R/G/B/A/Z/Y/RY/BY. This works for layers that represent colors.<br />Writers should be strict about using the recommended channel suffixes,<br />but readers should recognize other reasonable versions, like r/g/b/a,<br />red/green/blue/alpha, etc..<br /><br />- What about scalar (single value) layers or layers that represent 3D data like<br />points/normals/vectors? Some apps currently use x/y/z as channel suffixes, e.g.<br />N.x, N.y, and N.z for normals. At least one uses nx, ny, and nz with no suffix.<br />For scalars, most apps I've looked at just output the layer name without a<br />channel suffix, e.g. "myscalar". It would be nice to have a unified,<br />deterministic rule to handle all of these cases without requiring complex logic<br />or lists of legal suffixes. What about using simple numerical indices for all<br />data (non-color) channels? The layer name should be enough for apps to<br />interpret the individual channels. Scalars could be the same, but with just a<br />single index. For example: N.0, N.1, N.2, myscalar.0. This idea could also<br />handle layers holding a 4-point vector or 16-element matrix at each pixel.<br /><br />Thoughts? There might be a better approach than numerical indices for data<br />channels, but I can't think of anything else simple and flexible, at least not<br />without having a system to declare file-specific channel suffixes in a "channel<br />suffix declarations" attribute, or something like that. That would be an<br />interesting idea to explore, but I think we need to be practical. Anything more<br />than a simple naming convention is unlikely to be incorporated by application<br />developers any time soon.<br /></span><tt><br /></tt></channel></layer></channel></layer></channel></layer></pre>

EXR layer naming conventions

http://www.mail-archive.com/openexr-user@nongnu.org/msg00178.html R G B A Z Raw Colour: Raw.R .G .B Reflection Colour: Refl.R .G .B Diffuse ...

Read more »