Well, I was going to work on writing something that would preprocess a video file and calculate exactly where all the cuts were and what the intensity and “bend” were at any given time, and I ran into a roadblock.
Groovy is an awesome programming language. I want to program in Groovy as much as I possibly can. And so I found Xuggler (a SWIG-based Java interface to ffmpeg), and I wrote a convenient Groovy wrapper class for accessing frames in an ffmpeg video stream.
It was great. I could load a file, get all the frames I wanted one at a time as Java BufferedImages, draw on them using Java2D, and write them back out in an image sequence. (I figure I can probably export another movie file, too, but I haven’t tried that part of Xuggler yet, let alone wrapped it.)
Now I actually needed to process those images to find motion in them, and so I set up a simple image difference filter in Groovy, and I tried it out. It was slooooooow. It processed about one frame per second. I realized Groovy would be slow, but I hoped it wouldn’t be that slow.
A couple of months ago, I took a stab at making an AMV (anime music video). I’ve done it before… once… but this time, like lots of times, I had absolutely no time to work on it because I’d jam-packed myself with more homework than I knew what to do with.
So, I found myself pacing along, in a sleep-deprived state, talking at a friend about how I tried to do such-and-such and had to do wossname instead and never found time for, um, doing that AMV thing and that since it was me of all people doing it I might as well save time in an insanely difficult way by, say, programming my computer do it all for me.
An automatic AMV generator. Sometimes I amaze myself. Oftentimes I come up with some idea that blows my socks off and then realize it’s just a telephone or a wheel. This time, whether or not it had been done before, I knew I was particularly persnicketily picky about my AMVs… so picky that I was sure no other automatic AMV generator could be exactly what I wanted.
To make myself clear, this is something that doesn’t exist yet, but it’s something I’ve been actively working on for a few weeks. And I’m calling it MVTron.
In short: Is Groovy Science dead? Yes and no. Yes, its author (me) is somewhat distracted with other things and has left the project to atrophy. On the other hand, no, its author (me) still has strong opinions about what it is and where it can go, and will probably pick it up again eventually if no one else does.
Well, I went back to school, and I left Groovy Science in a pretty unuseful state. I only got about halfway through the tutorials I was planning, I never set up a way to build a .jar file, and I didn’t even end up choosing a license. To trump that, I think I was going about it the wrong way from the start.
The premise was to make a common, easy-to-transform format for symbolic expressions, which could be used to help glue and wrap (groovify?) existing Java libraries. What I failed to notice was that Groovy already has a standard format for symbolic expressions: Objects.
Groovy Science isn’t what has my attention nowadays, but I’ve still been doing some thinking about it in my spare time, and I’d like to see it redefine itself in a few directions: