| Follow @monsterjavaguns
Atlanta, GA
Jason van Gumster mostly makes stuff up. He writes, animates, and occasionally teaches, all using open source tools. He's run a small, independent animation studio, wrote Blender For Dummies and GIMP Bible, and continues to blurt out his experiences during a [sometimes] weekly podcast, the Open Source Creative Podcast. Adventures (and lies) at @monsterjavaguns.
Authored Comments
If we were *just* talking about images transferred from a device like a camera, then checksums would probably work as a solution. However, in the case of animation frames that are being rendered, it would be difficult to use checksums to do this sort of thing because of exactly the problem you've brought up. We're dealing with original data; there's no "known good" version of the file to compare against. In that case, our question of data integrity changes from "is this the same file as another one we already know about?" to "can this file be read as an image at all?" That's what verify() is for.
That's a good question, and to be honest I'm not sure that the images are loaded into memory. That said, like I wrote in the article, I regularly use a variation of this script on directories with over 44,000 images in them and I've not encountered any abnormal memory usage. Granted, the machine I run this one has a pretty beefy RAM spec, so I'll definitely need to pay closer attention the next time I run it.
All in all, it probably wouldn't hurt (and would likely be more proper) to add a img.close() at the end of that for loop. That should resolve most of the issue there, I'd think.