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
