Adrian, I was trying to make sense of the .REPLACE argument in nuke.filename section. After searching through the docs and googling a bit, I finally found some info on the .REPLACE variable...
According to Bill Spitzak, Senior Software Engineer: "nuke.REPLACE is an optional argument to the nuke.filename(node) function that says that #### sequences should be replaced." So, this replaces the hash index numbering shorthand with what -- %0d4 -- or something else? I don't understand. Why would you need to do that? Thanks, Rich On May 21, 2012, at 10:30 PM, Richard Bobo wrote: > Adrian, > > Brilliant - I'll be making it into a nice little pulldown menu utility > function! And, looking a bit deeper at your code, of course, so I can learn > some more Python… 8^) > > Thanks! > > Rich > > Rich Bobo > Senior VFX Compositor > > Mobile: (248) 840-2665 > Web: http://richbobo.com/ > > "Man has been endowed with reason, with the power to create, so that he can > add to what he's been given." > - Anton Chekhov > > > > On May 21, 2012, at 6:40 PM, Adrian Baltowski wrote: > >> Hi >> With just few lines of code and totally simplified >> >> ********************************** >> compList = ['None', 'RLE', 'ZIP', 'ZIP 16 lines', 'PIZ', 'PXR24', 'B44', >> 'B44A'] >> >> n = nuke.selectedNode() >> file = nuke.filename(n, nuke.REPLACE) >> fd = open(file, 'rb') >> header = fd.read(1024) >> index = header.find('compression') >> comp =ord(header[(index+28):(index+29)]) >> print compList[comp] >> >> *********************************** >> >> Each exr file MUST have compression info in the header and this info is >> placed just after channels info. It's simple to get actual size of channels >> list but I quickly set 1024 bytes of a headroom. >> >> Best >> Adrian >> >> >> >> >> >> W dniu 2012-05-21 21:04:38 użytkownik Rich Bobo <[email protected]> napisał: >> >> On May 21, 2012, at 3:00 PM, Nathan Rusch wrote: >> >> The OpenEXR utilities are pretty nice to have around, especially exrheader. >> Sounds like it might be worth a look for you. >> >> exrheader /path/to/input/image.exr | grep compression >> >> Yep. I'll have a look, when I get a bit of extra time to experiment... >> >> Thanks! >> >> Rich >> >> >> >> >> -Nathan >> >> >> From: Rich Bobo >> Sent: Monday, May 21, 2012 11:53 AM >> To: Nuke user discussion >> Subject: Re: [Nuke-users] How to check zip compression type for EXR >> images...? >> >> Thanks, Nathan. Looks like more trouble than it's worth. I tried a down and >> dirty 'strings <path> | grep compress | more' and came up with two instances >> of the word "compression", but no other info. So, I guess I'll just use the >> "Does it take lots longer to cache?" testing method! ;^) >> >> Rich >> >> >> On May 21, 2012, at 2:37 PM, Nathan Rusch wrote: >> >> No, it isn’t. >> >> Depending on the context from which you need to check the compression >> scheme, if Python proves too unwieldy, you could also resort to >> parsing/pattern-matching the output of the exrheader executable. >> >> -Nathan >> >> >> From: Rich Bobo >> Sent: Monday, May 21, 2012 11:32 AM >> To: Nuke user discussion >> Subject: Re: [Nuke-users] How to check zip compression type for EXR >> images...? >> >> I found this reference and it looks like the OpenEXR module would have what >> I need, but I'm not sure if it's part of Nuke's Python installation or not... >> >> http://excamera.com/articles/26/doc/openexr.html >> >> >> Rich >> >> On May 21, 2012, at 2:24 PM, Rich Bobo wrote: >> >> Hi, >> >> Anyone know a quick way to check EXR images to see if they were saved as >> 16-scanline zips or single-scanline zips? ViewMetaData reveals nothing >> about the compression type. I'm sure there's a command line invocation that >> will show more - I just can't find it... >> >> Thanks for any help, >> >> Rich >> >> >> Rich Bobo >> Senior VFX Compositor >> Mobile: (248) 840-2665 >> Web: http://richbobo.com/ >> >> _______________________________________________ >> 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 >> >> >> _______________________________________________ >> 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
