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
