Δαφνη Ευτυχια Αρθουρος

From wouldyoueva, 2008-03-07:

"What can we conclude from the Presidential candidates?

"Well, Obama is black. Clinton is a woman. And McCain is old.

"An old black woman politician would win in a landslide, right? Ah, Shirley Chisholm, a nation turns its lonely eyes to you."

From wouldyoueva, 2008-03-07:

"What can we conclude from the Presidential candidates?

"Well, Obama is black. Clinton is a woman. And McCain is old.

"An old black woman politician would win in a landslide, right? Ah, Shirley Chisholm, a nation turns its lonely eyes to you."

I don't have the right icon for this entry ("sky-eye") on LJ any more, but I do on some of the other sites it's mirrored to.

My efforts Friday wiped me out for the weekend. What a surprise. (Achy today, but still hope to drag myself to 3LF rehearsal for the second week in a row ... maybe.)

Anyhow, on Saturday I was treated to a phenomenon that I always find a bit mesmerizing however many times I've seen it. Multiple layers of clouds, each moving in a different direction. I made two attempts to capture the effect using the digital camera, bracing it as securely as I could, and pressing the shutter button as often as the camera would respond. (My hand got tired after fifty or sixty frames, so each attempt made for a really short video clip.) I then scaled the frames to a manageable size using ImageMagick and combined them into an MPEG into using ffmpeg (and an animated GIF using ImageMagick again).

The camera wasn't as stable as I'd hoped, so there's some jitter from camera motion between frames. In the clip I'm posting here, I attempted to fix that by opening each frame in GIMP and measuring the location of one particular detail, then converting the x,y coordinates of that feature in each frame into a set of translations. Because I only used one point in each rotations were not corrected, only translations. (Sorry about that, but it was tedious enough just correcting the translations.)

[Hmm. Embedded video doesn't seem to be working here. It worked on the CJ copy of this entry, or you can go straight to the YouTube page or grab the MPEG or animated GIF using the links in the next paragraph.]

The effect is much more pronounced if you save the MPEG locally and watch it with looping enabled, and a bit more so than that if you grab the animated GIF, which has a slower frame rate than the MPEG and doesn't have those distracting, blocky MPEG compression artifacts. (I was tempted to just stick the GIF here, but it's 8.3 MB -- compared to 180 KB for the MPEG -- and I thought that might be a bit much (though I did consider doing it anyhow and just putting it behind an <lj-cut> tag).)

I figure there's got to be a way to trade file size for image quality when assembling a video with ffmpeg, but I've barely begun to make sense of the eighteen-volume list of command-line options in the usage message it spits out. Considering that I don't know jack about video, a lot of the one-line explanations are gibberish to me. (They'll make sense eventually.)

This was after the main part of the 28-hour rain had stopped and the roof-rending wind had started. After watching the clouds for a while, I retreated to a less-drafty spot (even with the window closed, I was feeling gusts on my face, driven between the sashes -- and that window isn't covered with plastic because I have to be able to open it to dump the buckets collecting water from the leak) and was entertained by noticing that wunderground.com was reporting not one, but three answers in the cloud-cover box:

Clouds:

Scattered Clouds 5000 ft / 1524 m Mostly Cloudy 7000 ft / 2133 m Mostly Cloudy 10000 ft / 3048 m

This leads into revisiting an idea I had a while back but put on a back burner: automated de-jittering of video. I know that mechanical solutions exist (Steadicam, and even shake-reduction technology in recent still cameras), and I'm pretty sure software solutions already exist (though I don't know whether it's usually implemented in the camera or in the editing software -- ITSR at least one solution that was half and half -- the camera recorded motion using an internal inertial and/or gyroscopic system and included that data along with the video for an editing program to apply the compensations later). One day while I was attempting to shoot cell-phone video from the passenger seat of a moving car, I started thinking about how I might solve the problem working from scratch: ( sorta-mathy bits (but no actual math) )

Which turns this into a Google-fu problem.

The last time I looked, I wasn't able to figure out the right search terms to find the needle I wanted and exclude enough of the haystack for me to see it. At some point I'll try again. But I've got too many projects-in-progress at a time already, so I'll be hitting this one a little bit at a time.

But if one of y'all already knows where to find what I'm looking for, or are inspired to find it yourself for your own projects, feel free to save me some effort and drop me a clue. :-)

I don't have the right icon for this entry ("sky-eye") on LJ any more, but I do on some of the other sites it's mirrored to.

My efforts Friday wiped me out for the weekend. What a surprise. (Achy today, but still hope to drag myself to 3LF rehearsal for the second week in a row ... maybe.)

Anyhow, on Saturday I was treated to a phenomenon that I always find a bit mesmerizing however many times I've seen it. Multiple layers of clouds, each moving in a different direction. I made two attempts to capture the effect using the digital camera, bracing it as securely as I could, and pressing the shutter button as often as the camera would respond. (My hand got tired after fifty or sixty frames, so each attempt made for a really short video clip.) I then scaled the frames to a manageable size using ImageMagick and combined them into an MPEG into using ffmpeg (and an animated GIF using ImageMagick again).

The camera wasn't as stable as I'd hoped, so there's some jitter from camera motion between frames. In the clip I'm posting here, I attempted to fix that by opening each frame in GIMP and measuring the location of one particular detail, then converting the x,y coordinates of that feature in each frame into a set of translations. Because I only used one point in each rotations were not corrected, only translations. (Sorry about that, but it was tedious enough just correcting the translations.)

The effect is much more pronounced if you save the MPEG locally and watch it with looping enabled, and a bit more so than that if you grab the animated GIF, which has a slower frame rate than the MPEG and doesn't have those distracting, blocky MPEG compression artifacts. (I was tempted to just stick the GIF here, but it's 8.3 MB -- compared to 180 KB for the MPEG -- and I thought that might be a bit much (though I did consider doing it anyhow and just putting it behind an <lj-cut> tag).)

I figure there's got to be a way to trade file size for image quality when assembling a video with ffmpeg, but I've barely begun to make sense of the eighteen-volume list of command-line options in the usage message it spits out. Considering that I don't know jack about video, a lot of the one-line explanations are gibberish to me. (They'll make sense eventually.)

This was after the main part of the 28-hour rain had stopped and the roof-rending wind had started. After watching the clouds for a while, I retreated to a less-drafty spot (even with the window closed, I was feeling gusts on my face, driven between the sashes -- and that window isn't covered with plastic because I have to be able to open it to dump the buckets collecting water from the leak) and was entertained by noticing that wunderground.com was reporting not one, but three answers in the cloud-cover box:

Clouds:

Scattered Clouds 5000 ft / 1524 m Mostly Cloudy 7000 ft / 2133 m Mostly Cloudy 10000 ft / 3048 m

This leads into revisiting an idea I had a while back but put on a back burner: automated de-jittering of video. I know that mechanical solutions exist (Steadicam, and even shake-reduction technology in recent still cameras), and I'm pretty sure software solutions already exist (though I don't know whether it's usually implemented in the camera or in the editing software -- ITSR at least one solution that was half and half -- the camera recorded motion using an internal inertial and/or gyroscopic system and included that data along with the video for an editing program to apply the compensations later). One day while I was attempting to shoot cell-phone video from the passenger seat of a moving car, I started thinking about how I might solve the problem working from scratch: ( sorta-mathy bits (but no actual math) )

Which turns this into a Google-fu problem.

The last time I looked, I wasn't able to figure out the right search terms to find the needle I wanted and exclude enough of the haystack for me to see it. At some point I'll try again. But I've got too many projects-in-progress at a time already, so I'll be hitting this one a little bit at a time.

But if one of y'all already knows where to find what I'm looking for, or are inspired to find it yourself for your own projects, feel free to save me some effort and drop me a clue. :-)