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

[Yves Poissant]

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

Indeed, OpenEXR already have this capability of storing multiple channels of 
different types. And we don't need to duplicate this capability. Instead, we 
are looking for a way to store information about some types of higher order 
type of object which are objects composed of a set of homogenously typed 
channels. RGB or RGBA are good examples.

We would not try to store RGBZ as one object. Instead, we would store RGB as 
an object and Z as a separate object. They are conceptually not of the same 
order anyway.

This said, I see your point and agree that there might be some need for some 
non-homogenous objects although I can't see any for now except for XYZ 
encoded colors where Y would have higher resolution than X and Z. But they 
would still be of the same datatype though. I could imagine RGBA where RGB 
would be half and A would be byte too.

Anyway, I don't pretend that I covered all possible cases. But rather that 
we had a need for those homogenous collections of channels. I mainly hopped 
that my post would generate some discussion as to a possible conventions for 
that need and possibly develop a model with expanded capabilities in this 
direction.

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

We don't have regular expressions nor wildcards to retrieve all channel 
names starting with "diffuse." and which would retrieve the set {diffuse.R, 
diffuse.G, diffuse.B}. Or alternatively, a query with "diffuse.*" that would 
retrieve the first channel in alpahbetical order like "Diffuse.B". And then 
from that we couls continue scanning through the channel names until the 
layername differs. Without that, we must first retrieve all the channels and 
parse their names and build a regrouping structure. Then we can start 
retrieving the actual data and regrouping them into layers.

Since the regrouping data and channel names were readily available at store 
time, I just decided that it was simpler to save that information rather 
than deriving and rebuilding it at load time.

What would help, in this regard, would be to set a flag, before scanning 
through the channels, where channels would be retrieved in stored order 
rather than in alphabetical order. This capability may already exist though 
but I did not find a way to do that.

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

In one single string attribute. I llike that idea. And this would certainly 
save file space.

What about something like this :
"diffuse{R,G,B},ambiance{R,G,B},Z,tangent{X,Y},normal{X,Y}"

Yves Poissant
Hash Inc.