[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Openexr-devel] groups of channels
From: |
Luc-Eric Rousseau |
Subject: |
RE: [Openexr-devel] groups of channels |
Date: |
Mon, 2 Aug 2004 16:14:56 -0400 |
> -----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)