I just checked in with the cg supe, and I also had a look in exrheader - they're definitely regular zip1 scanlines, not within tiles either. Apparently that's an option in Mantra but it's not what they're doing here.
I understand the current limitations with rendering multichannel exr's and avidly wait for multipart files as well as multithreaded reads. But as I said we are getting much smaller files (and corresponding speedups in Nuke) just by re-rendering them. On 3 May 2013 17:03, Nathan Rusch <[email protected]> wrote: > Yeah, Zip1 is just a compression scheme for a block of data. With a > tiled file, the compression gets applied on a per-tile basis, so each > scanline in each tile would be compressed separately; for a bucket size of > 32, that would be zipping 32 pixels together. > > Since there is no multithreaded decompression of (non-deep) EXR files in > Nuke, you would definitely see a performance hit when trying to read the > sequence in, especially with 36 channels, and it stands to reason that the > compression ratio would be comparably horrible as well. > > -Nathan > > > *From:* Michael Garrett <[email protected]> > *Sent:* Friday, May 03, 2013 1:58 PM > *To:* Nuke user discussion <[email protected]> > *Subject:* Re: [Nuke-users] EXR file size Mantra vs Nuke re-render > > Hey - that was the one thing I thought of but didn't mention - I have so > little experience with them that I assumed Zip1 always rendered scanline. > I'll check that out! > > On 3 May 2013 16:55, Nathan Rusch <[email protected]> wrote: > >> Sounds like Mantra is generating tiled files. >> >> -Nathan >> >> >> *From:* Michael Garrett <[email protected]> >> *Sent:* Friday, May 03, 2013 1:37 PM >> *To:* Nuke user discussion <[email protected]> >> *Subject:* [Nuke-users] EXR file size Mantra vs Nuke re-render >> >> I just got some multichannel Zip1 compressed 16 bit half EXR files >> rendered with Mantra which were incredibly slow to read off the network. >> >> I re-rendered them like for like in Nuke 7.0v6 to see if there was a >> performance gain. What I found is that the size of each frame went from >> ~170MB/frame to ~43MB/frame. That's definitely rendering all channels >> (about 36 individual channels), 16-bit half, Zip1 compressed in both source >> and destination images. >> >> I know that Nuke has not yet rolled in the multi part image optimisation >> that's in EXR 2.0, I'm certainly looking forward to that. But I'd be >> interested to kow howit could be possible that the file size has shrunk so >> much in the instance I described above. >> >> Cheers, >> Michael >> ------------------------------ >> _______________________________________________ >> 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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
