Hmm... Just tried upping the header size with the EXRs I have and got your code
to start working again when I raised the header search size to 4096.
Rich
On May 22, 2012, at 9:15 AM, Rich Bobo wrote:
> Adrian,
>
> I just did a few more tests after getting to work and had less success than
> my initial testing last night. I'm guessing that the location of the
> compression flag will change, based on other header data and the space it
> takes up? You had very specific index locations in your sample code. How did
> you determine how far to look? Would a larger header size be more likely to
> work with files that are larger and that have more channels? Sorry for the
> dumb questions - I have a an intuitive grasp of how this is working, but no
> experience with it...
>
> Thanks,
> Rich
>
> 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 <richb...@mac.com> 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
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>>
>>
>> _______________________________________________
>> Nuke-users mailing list
>> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
>
> _______________________________________________
> Nuke-users mailing list
> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
