In my experience, yes, absolutely. But there's been a lot of dispute on this particular subject here in the past.
Have a look at older posts (search for "single EXR, multiple layers", for example), and pick your choice :) On Wed, Dec 14, 2011 at 6:29 PM, Nhatphong Tran < nhatphong.t...@pixomondo.com> wrote: > Thanks guys! It's interesting that supposedly this was filed as bug ID > 7585. > > So would you say that the fastest workflow would still be to strip out > each layer into separated EXR sequences and merge them back together in > Nuke? > > > Phong > > > > > On 12/14/2011 5:12 PM, Jonathan Egstad wrote: > >> Nathan's correct. >> The channels are stored in the file interleaved and Nuke's exrReader >> correctly pulls data from only the channels requested, but the >> decompression must happens for all channels. >> >> My understanding is that exr 2.0 will support non-interleaved channels >> which should become reality within the next 6 months. However that means >> that image generators (renderers, etc) will need to upgrade to 2.0 too…so >> it will likely take quite a while for it to actually happen in reality. >> >> -jonathan >> >> On Dec 14, 2011, at 4:15 PM, Nathan Rusch wrote: >> >> I don't think this is a "bug" in Nuke's EXR reader code... I think it's >>> a limitation of OpenEXR's design. Since files are scanline-interleaved, all >>> of the channels in any scanline must be decompressed and read in order to >>> extract the RGBA data (or any other arbitrary channel). >>> >>> -Nathan >>> >>> -----Original Message----- From: Nhatphong Tran >>> Sent: Wednesday, December 14, 2011 3:46 PM >>> To: nuke-dev@support.thefoundry.**co.uk<nuke-dev@support.thefoundry.co.uk> >>> Subject: [Nuke-dev] Optimized EXR Reader >>> >>> Hi! >>> >>> We noticed EXR read performance drops if there are a lot of layers >>> included in the EXR, even if only standard RGBA channels are requested. >>> According to TheFoundry this is a bug in the EXR reader plugin which >>> causes all channels to be loaded. Does anyone have a starting point >>> where this problem lies in the source code given? >>> >>> Thanks a lot, >>> >>> >>> Phong >>> ______________________________**_________________ >>> Nuke-dev mailing list >>> Nuke-dev@support.thefoundry.**co.uk <Nuke-dev@support.thefoundry.co.uk>, >>> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >>> ______________________________**_________________ >>> Nuke-dev mailing list >>> Nuke-dev@support.thefoundry.**co.uk <Nuke-dev@support.thefoundry.co.uk>, >>> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >>> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >>> >> ______________________________**_________________ >> Nuke-dev mailing list >> Nuke-dev@support.thefoundry.**co.uk <Nuke-dev@support.thefoundry.co.uk>, >> http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> >> http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >> >> > ______________________________**_________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.**co.uk <Nuke-dev@support.thefoundry.co.uk>, > http://forums.thefoundry.co.**uk/ <http://forums.thefoundry.co.uk/> > http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-dev<http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev> >
_______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
