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

[Charles Henrich]

I thought I had replied to this, but perhaps something ate my email.  Im not
sure the value of a channelsWithprefix() method adds for us, as we need to
know all the channels an exr can produce from the get go, so we scan the
channel list first thing.  Im also not sure the need of having a
layering-order attribute either.  Layer order seems largely irrelevant,
inter-layer order on the other hand is critical.  (B/G/R versus R/G/B for
example).  

If there were additional methods to retreive the channel list in a sorted
order, or if we could preserve the order in the file upon retrieval we could
solve this more simply.  Something like:

ChannelList &imfchannels = C_inputfile->header().channelsbyfileorder();
ChannelList &imfchannels = C_inputfile->header().channelsbyname();

etc.. 

If that was in place the spec could essentially say "layering is achieved by
channels named as such: layername.channel, (or any prefix really).  If the
application needs specific inter-layer, or even layer ordering, then it can do
so by writing those layers in the required order at write time, and using the
channelsbyfileorder() method to retrieve the saved order.

It also allows the OpenEXR technology to really only know or care about
channels as its fundamental unit (only unit).  Which is a good thing, as I
know at some point here we're going to add grouping to nuke, so we'll end up
with arbitrary numbers of nested groups.  (group.group.group.channel).  Which
really isnt something exr should have to deal with, but as long as we can
read/write in a specific order and people expect that when encountering a non
alphanumeric string that order is important, it'll work without any additional
changes.  

My two cents anyway.

-Crh

       Charles Henrich           Digital Domain          address@hidden

                         http://www.sigbus.com/~henrich