Snoqualmie Falls at Flood II
I made it out to take more pictures and video (see below) of the flooding along the Snoqualmie River near Spring Glen this morning.
Check out this video of Snoqualmie Falls at a normal summer time flow for comparison.
I made it out to take more pictures and video (see below) of the flooding along the Snoqualmie River near Spring Glen this morning.
Check out this video of Snoqualmie Falls at a normal summer time flow for comparison.
Posted by
wac
at
1:39 PM
1 comments
After an extended period of snowfall, the freezing level has climbed drastically while we receive over half a foot of new rainfall. The result is extensive flooding.
We have a few videos from Snoqualmie Falls along with a gallery of other images from around Spring Glen.
Update: More photos and video from January 8th.
Posted by
wac
at
7:48 PM
4
comments
Update (January 2009): Just over two years later another flood event, and some more video of the falls and Spring Glen below.
Flood waters pour over Snoqualmie Falls.
Posted by
wac
at
9:55 AM
0
comments
Our webcam now has a time-lapse movie for today and yesterday. Or rather it will have one for yesterday after it’s been running for more than one day. This was achieved by saving off a copy of every webcam image into a directory for the day and then processing them with some free tools. In this post I walk through the process we use to make this happen.
First, my Gawker image fetch project grew a new -d directory option to save JPEG files into a directory. We have to save the images if we expect to make a movie out of them at some point. It should be noted this requires a bit of disk space. With a new image every 30 seconds, a day of images occupies nearly 150 megabytes of disk.
Now that we have the images, we want to turn them into a movie. For this we start with netpbm.
Using jpegtopnm we convert the series of JPEG images into a series of raster images that the next software can deal with.
Next in line is mjpegtools. It has a tool ppmtoy4m that takes the series of raster images and renders it into a “Y4M” video file. The Y4M format adds useful information to traditional YUV video data, such as the size of the image and the framerate. It’s worth noting that this Y4M data is mainly raw video frames, which results in a fairly large file if we write it to disk.
Lastly, we want to use x264 to convert the Y4M data into a highly-compressed movie that your can view with your web browser. The only problem is that x264 treats it’s input as raw YUV data by default and has no switch to make use of Y4M data, it only uses Y4M data if the input file is named something.y4m.
But we don’t want to save a very large Y4M file to our disk every 10 minutes when we’re generating the movie, only to throw the file away when we’re done. We want to just send it the input directly. All the other tools allow us to pipeline the commands together so as one command processes some data it passes it’s output straight on to the next command. So now it was time to fix x264 to let us pipeline the way we want:
I sent this message to the x264-devel list this morning.
This patch adds the long option “
--y4m-input” which setsb_y4m. It
also avoids any evaluation that might result in setting bothb_avis
andb_y4m.
In order to politely handle pipelines from mjpegtools and other y4m
sources,b_y4mmust be set even if the filename is ”-”. Sadly, that filename
does not end in ”.y4m”.
The patch is available here.
In the longer term it would be useful to offer options for all
accepted input and output types on stdin and stdout to avoid having to
create (rather sizable) temp file everywhere.
So with that fix in place now we can send a series of JPEG files through the pipe of jpegtopnm, ppmtoy4m, x264 and wind up with a time-lapse movie you can watch.
Update: The files are now also mangled by the qt-faststart program (part of ffmpeg) which will let QuickTime (and possibly other players) start playback immediately before the whole file is loaded. I’ll try to get this change committed to svn soon.
Posted by
wac
at
11:08 AM
0
comments
I’ve made some improvements to Gawker Image Fetch and moved it over to Google Code Hosting.
If you checkout the copy from Subversion over there you’ll gain the ability to specify the Gawker instance with Bonjour/Zeroconf, as well as having a new --foreground mode that fills your terminal with exciting debugging messages like:
Saw service ‘Unprivileged Clown._lapse._tcp.local.’
Source moved to 1.2.3.4:7548
Replacing connection
Connecting to 1.2.3.4:7548
The new Zeroconf features appear to work in both OS X and FreeBSD. Theoretically it should be able to follow the camera to a new IP if the camera machine reboots.
I’m still seeing an occasional bug that requires restarting the script in the install for the webcam. Hopefully the additional debugging information will help me get to the bottom of that.
Let me know if it works for you…
Thanks to the developers of pyzeroconf for that library. It has a few bugs which I’ve fixed for this script and haven’t submitted back yet.
Update: I sent a patch along by email to pyzeroconf interested parties.
Posted by
wac
at
3:21 PM
0
comments
There’s not a lot more to it than the title suggests. I’ve made a script you can use to fetch webcam images from any host on the Internet that’s running Gawker.
The script takes arguments of the host and port to connect to as well as the file to overwrite with the latest exciting image. Together with some javascript you can do neat things like have a live updating webcam image.
Silly things like half-written images are dealt with, but that means the directory that has the image file in it needs to be writable. If the camera sends images faster than your local machine can write out to disk, that’s bad. So don’t do that.
In the future, I’ll make changes that fulfill desires I have, like producing a timelapse movie of the last 24 hours. And more complicated, a timelapse movie that skips the dark frames in the night that are less interesting.
After a few minutes of thought: Future changes like reconnecting in the event of a failure spring to mind as well. For now though, this is scratches-an-itch-ware.
Update: My script now resides at Google Code with the code available in Subversion at http://gawker-image-fetch.googlecode.com/svn/trunk/. It now supports finding cameras with Zeroconf and reconnecting automatically.
Later Update: New features are appearing, like support scripts for doing time-lapse movies. Check the code site for the latest information.
Posted by
wac
at
10:45 PM
4
comments
We have a new test webcam pointed at Mount Si. I’ve always been
bothered by the bizarre behavior of the QuickCam when it catches the morning
sun. Using an iSight may help this since it theoretically is smart enough to do
some aperture adjustment on its own. On the other hand, it’s ability to pick out
details in the dark has proven to be somewhat more sketchy.
It is worth noting that the new webcam setup I’m testing is using only open
source software (aside from the operating system). Or at least it will be once
I’m happy with the performance and release the script I’m using to fetch images
that are served with Gawker.
The resolution of this camera is about the same as the QuickCam, but the image is a lot sharper. I have a feeling that the image tag on that page isn’t shaped quite right for the size of the image that is output from that camera. But that’s why it says “testing” all over the page. A chance to work the kinks out.
def ParseDescription(self, desc_buffer):
pass
We’ll see if that’s premature optimization some time soon…
Posted by
wac
at
10:22 PM
0
comments
Important Disclaimer: This is our personal website. The views, thoughts, text and images expressed on these pages are our own and not those of our employers, the universities we attend, the United States Government, ABC, or Major League Baseball.
© 1997-2008 Carrel.ORG