The critical thing was making sure that the channel names were never more than 32 characters. If you kept them under that, you at least know that they will be named consistently throughout the sequence. The only essential part of the name was the prefix - so Diffuse chanels started with DIFF_ regardless of what the passname or camera name was.
My script then opened the sequence in Nuke, determined all the layers that existed, loaded them into the scene (using tcl add layer), then created and deleted channels using shuffles and removes and rendered out a new image. I'll see if I can clean-up and document the function that does all the heavy lifting this weekend. JP On Fri, May 18, 2012 at 1:54 PM, Howard Jones <[email protected]>wrote: > yes that sounds like the issue. > How did you auto detect the wrong channels - or was this by hand. > > > Howard > > ------------------------------ > *From:* Jean-Paul LeDoux <[email protected]> > *To:* Howard Jones <[email protected]>; Nuke Python discussion < > [email protected]> > *Sent:* Friday, 18 May 2012, 19:09 > > *Subject:* Re: [Nuke-python] EXR with badly named layers > > Hi, > > Not sure if you're getting your renders from Maya, but the unpredictable > naming of your channels looks a lot like an issue we were dealing with when > we started using Maya's pass system. > > (I hope I'm getting this right...) The OpenEXR verison used by maya prior > to 2012 only supports channel name lengths of 32 characters, and out of the > box Maya builds it with it's pass-prefix, pass name and in some > circumstances would tack on the camera name as well. If all that goes over > 32 chars , it makes an unpredictable mess - and for us, sometimes the > channel names even changed between images in a rendered sequence. This did > not play well with the generic template system I was building for comp. :) > > For us, we got the cap on channel names coming out of maya(which included > modifiying Maya's default 'RENDERPASSTYPE' values) , and then created a > nuke post-process that runs the renders through nuke (detect channels, > shuffle to new name, remove old channel, etc) and spits out every frame > with lovely generic pass names (ie motionvec). This also had the byproduct > of producing much more nuke-friendly scanline exrs too. > > Anywho, good luck! > > JP > > > > > > On Fri, May 18, 2012 at 1:51 AM, Howard Jones <[email protected]>wrote: > > Cool thanks - looks like there is something related in there. > Something for the 'to do' list :) > > Howard > > ------------------------------ > *From:* Deke Kincaid <[email protected]> > *To:* Nuke Python discussion <[email protected]> > *Sent:* Friday, 18 May 2012, 6:25 > *Subject:* Re: [Nuke-python] EXR with badly named layers > > Perhaps you can do it with the exr python bindings: > > Look here > http://excamera.com/sphinx/articles-openexr.html > > > On Thu, May 17, 2012 at 2:29 AM, Howard Jones <[email protected]>wrote: > > Hi > > Is there a way to rename the layers from an exr file, Basically the file > should have say 'motionvec' but has come in as something like > 'HGD_010_motionvec_2346745634756'. > So out of interest is it possible to rename these directly in the exr > file. My tests using a quick replace, so far create other errors in the > file even though layers have been changed - in this case 'Reader did not > set bounding box'. > > I know its quicker just to reset our shuffles but I'm curious as to if > this is possible and if so how? > > Cheers > > Howard > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > > > > >
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
