RE: [Openexr-devel] groups of channels

[Luc-Eric Rousseau]

> -----Original Message-----
> From: Florian Kainz [mailto:address@hidden
> 
> Luc-Eric Rousseau wrote:
> >Have you considered adding the concept of groups of 
> >channels in the OpenEXR format?  If there were the concept of 
> >grouping channels together hierarchically, and being able to 
> >add meta-data (attributes..) on those groups, the format 
> >could be used as a sort of floating-point equivalent of 
> >photoshop files.
>
> We have not considered adding a "channel group" concept.
> Do you have a specific application in mind?
> What sort of API do you envision for channel groups, and
> could your API be implemented in a backwards-compatible
> manner?
> 

As far as I can tell, in OpenEXR, there are no tags or meaning enforced for 
channels, so I can see potential for much incompatible ad hoc solutions for 
storing multiple images in a single file.

I've used the word photoshop documents, but what I mean is storing for example 
multiple render passes in the same file.  Or storing multiple layers for a 
texture (bump, diffuse, etc), images that really go together.  There could 
potentially be a need for attributes to be applied to several channels but not 
others - for example, information that applies only to the RGB channels.

I'm fine with a channel called "R" that means it's the red channel.  If there 
are multiple images in the file, I wished all Red channels were called "R". In 
other words, I would like that name to be the type, not a user name.

With regards to back comp,  Photoshop files can be 'flat'.  If an EXR image 
contained multiple layers, and the application producing it would want that 
image to be understood by an application that doesn't understand layer, it 
would need to save a flatened version of the image, or it could flag a group as 
being the main layer.  An application that doesn't understand layers is not 
necessarily expected to be able to re-write the file without loosing the layers.

It's also possible of course for a host application to do all of this without 
any change to OpenEXR, by keeping EXR as being only one image, and then another 
file, for example an AAF, is used to specify the meta data of how these 
different files work together.  It's just a pain for the user to track all of 
these files. (It does work well at optimizing the meta data for image 
sequences, however)