|
My good friend and roommate Matt Arsenault has just pushed the initial (0.1) release of his Clutter bindings for Haskell. This was his RCOS project for this semester.
Anyway, if you speak Haskell and enjoy Clutter, download them and see what you can do! He's looking for lots of input for the next steps, so please have at it...
Now that you've heard my long diatribe on why I need to take tens of thousands of frames of growing plants (totaling hundreds — or possibly thousands — of gigabytes), I'll explain my process for managing and processing the images (the technical side of things), in case anyone ever wants to do something similar...
I've got two cameras for this project; a D80, and a Coolpix 8700. They're both way beyond the point where quality is a problem when compressing down to my destination format (HD@720p, or @1080p if Nate gets his way). The D80 has an antique 55mm Micro-Nikkor attached (along with a PK-13 extension tube to get to 1:1 if I need it); the 8700 has a reasonable macro feature on the built-in lens.
Both cameras are set on full-manual — shutter speed, aperture, white balance, focus, everything. The D80 is outputting RAWs; the 8700 is only outputting JPEGs (for reasons I'll explain in a minute) — this means that a shot from the D80 is about 8MB, and a shot from the 8700 is about 1MB.
Each camera takes a picture once a minute. To achieve this, the D80 (which doesn't ship with an intervalometer feature, and I have yet to finish my intervalometer project) is tethered (via a nice, standard USB-A-to-USB-mini-B cable) to my EeePC running Ubuntu. The Eee is connected to an external (USB) 160GB "buffer" hard drive.
The general flow of photos from the D80 to Final Cut follows something like the following:
The above process would be more or less the same for the 8700, except that I have no idea where the nonstandard tethering cable that Nikon was using back-in-the-day is, so I have to the 2GB CF card on the camera. This means that RAW is out of the question (sadface), so all of the steps up until e above are unnecessary for this camera (with a significant loss of maneuverability with the images in post, as well as the fact that I then have to take the card out of the camera every few hours — which of course disturbs the timelapse and adds a slight hassle).
I realized recently that I never actually introduced this project; a lot of people around me have already heard about it (or been directly affected by it, by being asked to put up with shutter noise every minute for the last few days or to fill up bowls with water), so I forgot! The basic idea is that I don't like filming people, because schedules are hard to coordinate, it's hard to find people who are convincing actors, etc.; I also don't like the quality of video that comes from the PDX-10s (or, to be honest, the higher-end-but-older-PD-170s) that the school provides for us to use. I don't have access to a video camera at all that would satisfy me, quality-wise, as I come from the super-crisp world of still photography!
Anyway; I decided I wanted to do something completely avoiding both human actors and video cameras for my final video project (after having dealt with both of these things for the first two projects, to reasonable success — but without a lot of comfort). So I proposed a short (~5 minute) video on "the birth and death of things". This elicited a "what!? you have 80 years?!" from one of my classmates; I noted that "things" in this case would be plants, and perhaps insects (molds/fungi have since been added to the list), since they are a) easy to give life to, and b) legal to kill within the timeframe of the project ;-)
So now I have to take video, with my DSLR (and my old Nikon point-'n-shoot; I need lots of video!), of a bunch of plants being born (and, later, dying). I ordered a ton of growing supplies: lights, greenhouse domes, seeds, pots, soilless mix, etc., as well as some fabric and various other supplies.
The initial plan was to fabric-off a chunk of our "porch" (it has walls on all sides, but the glass is missing from two of the windows), in order to make a situation in which I controlled all of the light in the room, so that lighting on the plants would be consistent between day and night. So, once the fabric got here, I set to work. I succeeded in making a blacked out area; unfortunately, plants didn't seem to want to grow in the mid-thirty-degree-F weather that seems to be hanging around Troy. Bummer!
Luckily, I had a set of herbs (basil, dill, and something else which I can never remember even though I look it up every day — it's cilantro!) growing in the warmth of our kitchen windowsill. When I got back to Troy this Sunday, the basil was just starting to pop out, so I decided to put it under the camera. I ended up taking apart my dresser to fabricate a warm completely-enclosed growing space; this is currently the most successful of my growing areas (the third is under my desk; I believe that success is just a few days off there — unfortunately, I'm leaving for Thanksgiving later today!).
So, yeah! That's the plan, anyway!
I'm beginning to see tiny bits of success trying to make plants grow for my final Intermediate Video project... in fact, I already have ~20GB of frames (from two cameras). Some cool video, some crap. It's going to be a long journey!
Basil

Dill

Excuses
This post has been stewing for a very long time, as is evidenced by it covering a span of three years. With such a long timeframe comes a terribly scattered and disconnected process of storytelling (for me, at least), so keep that in mind while you notice how long your scrollbar currently is... there is no structure here, only late-night babble.
Also, I apologize in advance for making anyone feel bad over the course of the next few paragraphs...
The Problem
A freshman's eye would peg Rensselaer as a paragon of proprietary software, and they certainly wouldn't be wrong. A majority of the academic portion of campus is heavily entrenched in software like Office, MATLAB, Mathematica, and various CAD packages (or Creative Suite, Max/MSP, and Final Cut Studio, on the other side of campus). I wouldn't blame this on the 'tute, though — many of these packages have no free/open source counterpart even remotely in the same tier. The problem centers more around how much the attitude that comes along with such software is also pervasive here.
Going to RPI — for most people (mainly the engineers and artists, who together comprise way more than half of the student body) — is about spending four years learning how to make lots and lots of money using the tools that you have to use in your particularly overspecialized field; nothing more, nothing less. There's been a recent push for multidisciplinary studies, but I feel like this isn't as serious as it could be, yet — destroying entire departments (foreign language, for example) doesn't lead to much faith in this program...
While this heavily money-and-proprietary-software-driven philosophy might be a little off-putting to someone coming from a background filled with free and open source software (or even a science-for-science's sake background), there is hope!; this is what I want to write about, since it's much more interesting than what's broken...
The Real Problem
I should first clarify that I don't have a problem with proprietary software; I use OS X as my primary operating system, I often resort to Mathematica or Final Cut to do things that can't be easily solved otherwise... I'm very much a right-tool-for-the-job person. My problem is with the attitude; the attitude that says that "everything I create should be mine because there's a chance I can make fame or fortune off of it, and why in the world would I want to share that with other people?"... that is the attitude driven by total immersion in a corporate-academic/closed-source world, and that is what I have a problem with, and it's deeply embedded within both the faculty and a significant portion of the student population.
During freshman year, I spent the whole year doing physics and hiding my disapproval for the overarching RPI philosophy by spending lots of time with my few dozen extremely social floormates. Robb and I often chatted about how we felt about the school, and supported each other as much as we could in terms of not following in everyone else's footsteps.
By the beginning of sophomore year, Robb and I had heard rumors from one of our CS professors (Robert Ingalls, who taught our operating systems course) that there was actually a forming contingent of like-minded folk — people who enjoyed writing software in order to share it with the world, people who believed in the world we believed in.
Finding RCOS
This group turned out to be the Rensselaer Center for Open Software (RCOS, as we semi-lovingly call it). Headed by Moorthy (who was also my data structures professor at the time, though I didn't make the connection until mere minutes before we met him to propose our project), RCOS is an interesting beast. It provides funding, support, and — more importantly, at least in my opinion — a home for people interested in working on or learning about free/open software.
In order to participate, you have to bring a project to the table. It could be something small, as you're just getting started with programming, or something grand, far beyond the scope of a single person project, something you just want to peck away at — as long as there's something to be done, and you're willing to share your code and ideas, you're welcome to stay as long as you'd like.
Three times a semester, the group (or individual) hacking away at each project has to get up in front of the rest of the group — which now numbers somewhere around 30 — and show off what they've done, where they've come from, and where they hope to go; these presentations take place at weekly meetings which form the primary social interaction of the group and provide a place for people to bounce ideas off everyone, show off what they've learned, and get support from the rest of the group when they're having an issue.
Seed
First semester sophomore year — shortly after we discovered RCOS — Robb, Matt, and I proposed the "Orange Window Manager", a next-generation window manager that we were planning to write, utilizing Robb's knowledge from his time working on Compiz, as well as various technologies not then being used in window managers (primarily, Clutter). We wrote Seed, the JavaScriptCore<->GObject-Introspection bridge which we were planning to use for extensibility within our window manager, instead, mostly after realizing that we didn't have the time nor patience to write a window manager. Hearing about Shell and Mutter and friends at GNOME Summit affected that decision a slight bit as well; we had already accidentally duplicated some of the effort in creating Seed alongside GJS, we weren't interested in continuing down that path.
RCOS ended up funding two semesters of Seed development and also provided a place for us to show off what we were working on to a bunch of people from outside of the GNOME developer community — which is really a great thing, and lets you put a little bit of perspective on what you're working on... both semesters we had other overarching projects in mind, but both semesters Seed was the primary target of our development time, because it was something feasible and something potentially useful to others.
Big Picture
Without something like RCOS, Seed almost certainly would not have been written; I would still be sitting here having never gotten my hands dirty in the GNOME world (some would say we'd be better off that way :-D); and, more importantly for the big picture, dozens of undergrads would never have gotten a taste of community in software, nor of writing code out in the open, nor of thinking of themselves second for once when coming up with ideas.
I believe that this is incredibly important, and — shockingly — something relatively unique to our campus (I realize it happens in other places, but not nearly as many as one would initially hope), and that more campuses should take heed and — if at all possible — try to pull off something similar!
The Man with The Plan
It turns out that this is all made possible by one person: Sean O'Sullivan, who graduated from RPI in '85 and went on to help found MapInfo — far from being a model citizen of the free/open-source world, but the timeframe excuses them, without question.
Mr. O'Sullivan apparently believes in our world too — so much that he donated a significant chunk of money in order to initiate and fund RCOS for a few years, as well as to create a annual semester-long course on developing open source software (which Robb is currently enrolled in, and is having a blast with, from what I hear...).
Reasonable social protocol would dictate that Seed contain some sort of "thank you" to both Mr. O'Sullivan and to Moorthy; unfortunately I never quite feel comfortable inserting any sort of message to that effect anywhere, nor bringing it up this late in the game, so this is my thank you: thank you for the last three semesters, and hopefully three more; thank you for believing in our cause and our world; and thank you for showing even just a few new people something they hadn't seen before, and possibly wouldn't have had their paths not crossed yours.
TL;DR
RPI has an awesome-but-underappreciated program for getting people involved in open software, run by Mukkai Krishnamoorthy and created by Sean O'Sullivan, and it gives me the little bit of hope I have for our community...
After I got home from Boston and finished Tuesday's homework, it was time to finish up my recreation of the last three minutes of The Usual Suspects. I had edited a good deal of the video while on the train; during that part, I had an epiphany of ridiculousness, as I realised I was editing video, composing music, and mixing audio on a 1800s era transportation device, using an inch-thick slab of aluminum and silicon... quite ridiculous!
I had a lot of trouble composing the background music for this on the train; once I got home, I borrowed Robb's mini-keyboard, and things got a lot better.
The raw music, for your listening "pleasure":
Background Music!
The Final Chord!
What you've all been waiting for, the video!, or Quicktime+H.264 format
The short-and-silly blooper reel!, or Quicktime+H.264 format
Nate's face (in not-quite-police-sketch-mode), which comes printing out of the printer as the reveal takes place:
The final cast list is also up. Unfortunately, I didn't manage to convince as many people as I would have liked to help me, so there were some shots which were infeasible, and I ended up playing quite a few people (Kobayashi and Keaton, most importantly, but also all of the rest of the usual suspects, except Verbal, of course).
I now have to figure out what I'm going to do next! We have one more project; the only requirement is that it be between three and 12 minutes long... that's awfully open-ended for me! We'll see! I'd really love if I could avoid having people in my next project (not that I don't love you guys, but it's a hassle working around a bunch of people's class schedules); I'd be even more happy if I could avoid the ER (that's equipment, not emergency), by doing something involving only what I can do with my still camera. We'll see, again!
I just got back from GNOME Summit Boston; I'll write about that experience at a later date... I edited together the first 2/3 or so of the video on the train on the way down to Boston (I had to work on proglang homework on the way back, which I somehow finished within the bounds of a single day), and tonight I started throwing the audio montage on. I'm really not sure what I'm going to do about the music, though, because there's simply no way I can duplicate the whole thing in time. At least, not if I want it to sound good...
Also, Nate sprained his ankle, so recording the last bits of video tomorrow is going to be really awkward. In addition to the fact that I don't have any extra actors to be the few remaining people. Really bad.
Remind me not to do anything for my final project (the next project) that requires cooperation; I'm really bad at shepherding people/asking people for help/etc... and it's not good!
We'll see. It'll get done, somehow.
This was hard.
I can't believe how hard it is to break a mug. We had to break it into two pieces with a hammer, then hold it together while dropping it (with liquid in it!). It worked out not-too-bad; we then slowed it down to 25%, which is a little sketchy because of the already-really-low framerate, but Motion seems to have done a reasonably good job making it not look horrible.
|
|