> > 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. >
That's interesting. My experience has usually been quite the opposite. I find the same operations done in Merges after shuffling to rgb are faster, and definitely use less resources, than picking the relevant layers inside the Merge nodes. Back in v5, I sent a script to support as an example of this behavior, more specifically how using layers within the Merge nodes caused memory usage to go through the roof (and not respect the memory limit in the preferences). At the time, this was logged as a memory leak bug. I don't think this was ever resolved, but to be fair this is probably less of an issue nowadays with higher-specced workstations. Hearing that you find it faster to pick layers in a merge node than shuffling & merging makes me very curious, though. I wonder if, given enough memory (so it's not depleted by the mentioned leak/overhead), some scripts may indeed run faster that way. Do you have any examples? And going back to the original topic, my experience with multi-channel exr files is: - Separate exr sequences for each aov/layer is faster than a single multi-channel exr, yes. As you mentioned, exr stores additional channels/layers in an interleaved fashion, so the reader has to step through all of them before going to the next scanline, even if you're not using them all. Even if you read each layer separately and copy them all into layers in your script (so you get the equivalent of a multi-channel exr), this is still faster than using a multi-channel exr file. - When merging different layers coming from the same stream, I find performance to be better when shuffling layers to rgba and keeping merges to operate on rgba. (although this is the opposite of what Deke said, so your mileage may vary) Cheers, Ivan 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
