All exrs are zip1 scanline. We created the multichannels in nuke from zip1 vray renders. On Sep 1, 2011 8:41 PM, "Deke Kincaid" <[email protected]> wrote: > Sorry, no benchmarks yet. I started making a doc about exr to put up on > nukepedia that one day I will finish. > > Ryan: are the exr files scanline or tile exr's? > > -deke > > > On Thu, Sep 1, 2011 at 14:18, Dan Walker <[email protected]> wrote: > >> Hey Deke, >> >> Could you elaborate on the last paragraph. Given a multi chan EXR. Are >> there bench mark tests that have been done to track optimal setups in comps? >> Basically, better to do this than that. I know there are a multitude of >> scenarios you have to consider but there are some tips users can supply >> based on their experiences. >> >> I'd say submitting them in an email thread is probably the best approach or >> the Foundry can compile and validate the submitted tips. They're not busy >> working on anything at the moment, right?! ;-) >> >> >> >> >> On Thu, Sep 1, 2011 at 1:55 PM, Deke Kincaid <[email protected] >wrote: >> >>> Exr files are interleaved. So when you look at some scanlines, you need >>> to read in every single channel in the EXR from those scanlines even if you >>> only need one of them. So if you have a multichannel file with 40 channels >>> but you only use rgba and one or two matte channels, then your going to >>> incur a large hit. >>> >>> Another thing is it sounds like you are shuffling out the channels to the >>> rgb before you merge them. This also does quite a hit in speed. It is far >>> faster to merge and pick the channels you need rather then shuffling them >>> out first. >>> >>> -deke >>> >>> On Thu, Sep 1, 2011 at 12:37, Ryan O'Phelan <[email protected] >wrote: >>> >>>> Recently I've been trying to evaluate the load of nuke renders on our >>>> file server, and ran a few tests comparing multichannel vs. non-multichannel >>>> reads, and my initial test results were opposite of what I was expecting. >>>> My tests showed that multichannel comps rendered about 20-25% slower, and >>>> made about 25% more load on the server in terms of disk reads. I was >>>> expecting the opposite, since there are fewer files being called with >>>> multichannel reads. >>>> >>>> For what it's worth, all reads were zip1 compressed EXRs and I tested >>>> real comps, as well as extremely simplified comps where the multichannel >>>> files were branched and then fed into a contact sheet. I was monitoring >>>> performance using the performance monitor on the file server using only 20 >>>> nodes and with almost nobody using the server. >>>> >>>> Can anyone explain this? Or am I wrong and need to redo these tests? >>>> >>>> Thanks, >>>> Ryan >>>> >>>> >>>> >>>> _______________________________________________ >>>> Nuke-users mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
