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

[Drew Hess]

Hi Charles,

Charles Henrich <address@hidden> writes:

> Layer order seems largely irrelevant,
> inter-layer order on the other hand is critical.  (B/G/R versus R/G/B for
> example).  


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?

thanks
d



>
> 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
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

pgpDI8J27FytL.pgp
Description: PGP signature