Re: [Openexr-devel] Storing multiple layers in OpenEXR files

[Florian Kainz]

At ILM we have not developed a way to store layer order information.
It would probably be a good idea to agree on a standard way to
represent layers in an EXR file.

I like your "layername.channelname" naming convention, but your way
of describing the layer order seems to be more complicated than it
needs to be.

The pixel data types for all channels are already stored in the file's
channel list.  Repeating the pixel data type in the Layer attribute
doesn't add any new information, and it prevents you from having layers
where the channels have different types (e.g. R,G,B of type HALF and
Z of type FLOAT).  Also, given your naming convention for the channels,
listing a layer's channels in the string is unnecessary; the set of
channels in a layer can be derived from the file's channel list.

Why don't you just use a single string attribute that lists the
layers in front-to-back (or back-to-front) order?

Yves Poissant wrote:
> This is a sort of follow-up on this thread:
> http://lists.gnu.org/archive/html/openexr-devel/2004-08/msg00007.html
>
> At Hash Inc, to store multiple layers for the same render, we have 
> adopted the convention:
>   "layername.channelname"
> Where channelnames are the conventional names like "R", "G", "B", "A", 
> etc. This is simple and works well.
>
> However, we also had a need for storing the particular load order for 
> the layers/groups for compositing purposes. So we have added some 
> metadata in the header. It goes like this:
> For each layer, there is a metadata attribute named :
>   "LayerO"
> where "O" is a non 0-padded load order number starting with 1. This is a 
> string attribute with value :
>   "layername T R,G,B,..."
> where "T" is the enum value of Imf::PixelType
> and "R,G,B" is a comma separated list of channel names.
>
> We also considered simply adding the load order number in front of the 
> channel name such as "O.layername.channelname"  But the metadata way 
> greatly simplifies the channel name searching since we don't have to 
> scan through all of then first to parse and regroup them. We simply loop 
> through the meatadata and load/regroup the channels as listed in the 
> metadata. Furtheremore, it keeps the compatibility of the ad-hoc naming 
> convention "layername.channelname" for other applications to load them.
>
> We also use the single buffer names "R", "G", etc to store the fully 
> composited final render result. This way, when our EXR files are loaded 
> in another application, at least the final render result is displayable.
>
> I'm interested to know if anyone else have developped a way to store 
> layer order information in EXR files and if there is an actual need for 
> that kind of information.
>
> Yves Poissant
> Hash Inc.