I should add, I just checked the speed with each channel split off and read in separately then copied back to the same multichannel stream inside a Group node, it's about 10-15 times faster so we will definitely be going down that route. It's something I've taken for granted working at various places where you get the auto compiled group node but I didn't realise the difference was so huge compared to a true multichannel image.
On 8 May 2013 14:52, Michael Garrett <[email protected]> wrote: > Piotr, thanks for confirmation straight from the source. > > Elias, these files have 16 bit rgba but all other channels are actually 32 > bit. But keeping in mind that this is with Mantra. > > > > On 8 May 2013 14:41, Elias Ericsson Rydberg < > [email protected]> wrote: > >> If I'm not misinformed you should be able to mix 16 and 32 bit in one >> single exr. However I think your rgb layer have to be 32 for this to work. >> At least this is my experience with Arnold for XSI. >> >> 8 maj 2013 kl. 20:37 skrev Piotr Stanczyk <[email protected]>: >> >> Hi, >> >> >> OpenEXR 1.6.1 and 1.7.0 do not differ in that respect. v1.6.1 could store >> channels of different types in the file. How applications treat them is >> quite another matter though ... >> >> Piotr >> >> >> ------------------------------ >> *From:* [email protected] [ >> [email protected]] on behalf of Michael >> Garrett [[email protected]] >> *Sent:* 08 May 2013 11:28 >> *To:* [email protected] >> *Subject:* Re: [Nuke-users] Re: EXR file size Mantra vs Nuke re-render >> >> I just had another look in exrheader and indeed, a bunch of these >> channels are 32-bit, although the beauty is 16 bit and Nuke sees the file >> as 16 bit in the metadata. >> >> Would this be because Houdini is using OpenEXR 1.7, which is backward >> compatible? As far as I knew, 1.6.1 was only able to store a single data >> type across all channels. I'm interested to know, but at least I'm aware of >> the issue now. >> >> Thanks for bringing this to my attention by the way! >> >> >> >> On 8 May 2013 11:22, Michael Garrett <[email protected]> wrote: >> >>> Interesting...I had thought that the ability to have a 32 bit channel or >>> layer in an otherwise 16 bit half float file was something you could only >>> do with OpenEXR 1.7. >>> >>> I know it's not best practice to have multichannel exr's right now, >>> I'll look into the possibility of getting them broken out as well. >>> >>> I will double check with the lighter as to what her output settings >>> are, but both the metadata tag and exrheader are telling me it's zip1 >>> scanline ((aka exr compression = 2). >>> >>> >>> >>> On 8 May 2013 00:00, marty b <[email protected]> wrote: >>> >>>> ** >>>> Good call John. >>>> >>>> Mantra render with 16bit 'C' & 32bit extra planes = 2.5Mb >>>> Mantra render with 16bit 'C' & 16bit extra planes = 1Mb >>>> >>>> Re-render in Nuke at 16bit = 760KB >>>> >>>> In Mantra just set the Quantize of the Extra Image Planes to 16bit >>>> float from 32bit float. >>>> >>>> _______________________________________________ >>>> 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
