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

[Florian Kainz]

It should be possible to derive the kind of data in a layer
from the channel names; for example, "layer.R, layer.G, layer.B"
represents color data, but "layer.Z" is a depth buffer.

I agree that the composite image is not well-defined without
information about how the layers in a file should be combined.
However, what compositing operations are available and the
parameters the user can set to control their behavior, or
whether compositing information should be stored in the image
file at all, depends on the software you use.  Defining a
language to describe image compositing is clearly beyond the
the scope of an image file format.

In my opinion, defining a standard "layer order" attribute is
about as much as we can do without becoming application-specific.
If even the layer order isn't generally useful, then maybe we
shouldn't define any standard attributes to describe layers.
Individual software packages can still store what they need
in their own attributes: layer order, channel order, etc.

Having the channelsWithPrefix() function seems to be useful in
any case (at least, its existence doesn't harm anyone), so I'll
it to class ChannelList.

Florian


Charles Henrich wrote:
> > Hmm, I look at this completely the opposite way.  
> >
> > Inter-layer/channel order (BGR, RGB, etc.) is an application-specific
> > choice: chosen for performance, compatibility with existing types, etc.  If
> > the application chooses to read channel order differently than what's
> > specified in the file, there's no correctness issue.
> >
> > Layer order is (possibly, but not always) chosen by the author of the image
> > to indicate relative depth of each layer, i.e. the correct order for
> > compositing.
> >
> > I'm curious, why do you say the opposite?
>
>
> For layer ordering to make sense, you need to know if the layer contains image
> data or ancillary control data, and if its to be included in the assembly.
> Now you would also need to know just how to assemble those layers as well if
> to be assembled.  Without that, order doesnt have any benefit?
>
> As for Channel Ordering, on first look it seemed to me to be beneficial to
> allow an application to order channels within a layer for its internal use if
> nothing else.  
>
> Following this, I suppose it comes doewn to as you say, cross application
> support.  Does layer order or channel order make any sense across
> applications?  I'd argue not really for both the reasons you've stated and
> I've stated.  However, we can allow application-dependant ordering if there
> were a method in which we could preserve an explicit channel ordering when
> generating and reading an exr file.
>
> -Crh
>
>        Charles Henrich           Digital Domain          address@hidden
>
>                          http://www.sigbus.com/~henrich