Tuesday, February 10, 2009
Wednesday, October 29, 2008
Sunday, March 2, 2008
Sunday, February 3, 2008
Tuesday, January 15, 2008
First weeks stats
Google video seems to have some problems currently with download stats. No current download numbers shown to viewers. And there reports feature seems to be up or down almost daily...
Here is a copy of the "all time" downloads as of 2008-01-14.
Here is a copy of the "all time" downloads as of 2008-01-14.
Sunday, January 6, 2008
Saturday, January 5, 2008
Video Tech
The videos on this site are done with a Sony EVI-D30 PZT (pan/zoom/tilt) camera driven by some custom software.
The proposal I made to BVC was to use the EVI-D30 which is available at low cost on eBay (typically about $175 plus shipping) to see if it could be used to "automate" some aspects of videoing track races. I even offered to spend my Nov race winnings on buying a camera.
Using this type of camera has several nice features. First it can be mounted in places you would be hard pressed to put a person and camera. And at our velodrome this allows use of a higher (by almost 2 meters) spot. Which in turn means that the back straight shots would be looking down at the riders and would actually be able to see them. The best you can do with a hand held from our stands is to see the top half of the rider, with the bottom half being obscured by the upper track and rails.
Second, this type of system should be able to provide a steadier and more reproducible shot as compared to a hand held.
Finally, if suitable easy to operate tracking software can be implemented, it may be easier to find volunteers to operate the system.
The initial software is a simple C++ program that can be used under Windows/Cygwin or Linux. It controls the camera via a serial port using the cameras VISCA protocol. Conceptually the program models the race simply, keeping a virtual distance around the track (0-200m) which is continuously updated with respect to the current virtual speed in kph.
Given a position (in meters) on the track, the track dimensions, and camera location, the program can calculate the current angles for pan and tilt, and the current distance between the camera and that part of the track. The math for this was provided by my son Ryan Lynne (apparently engineering students are good for something..)
The camera operator uses a simple set of keyboard commands to keep the head of the race in the video frame. Typically this only requires four commands: speed up, slow down, jump and pause. The speed commands simply increase or decrease the virtual speed.
Jump moves the virtual position slightly ahead (about 5-10 m depending on speed) allowing the frame to catch up with the riders.
Pause causes the position updater to stop for a short (.5 - 1 second) time to allow the race to move back into the frame.
The initial set of videos used shutter priority exposure with the shutter set to 1/250.
The operator viewed the video in real time using virtualdub attached to an ATI capture card.
The actual video was saved using a Hauppauge WinTV 250 card and a Hauppage wintv application to save directly to MPEG2.
Post race the videos where processed by Ryan Cousineau to re-compress down to mp4.
With the 6-day over we'll be updating the software a bit. First the initial deployed software didn't get the full math work over for tilt as the math functions didn't arrive until the day of the race. No time to test... So I'll be testing that shortly.
Second, Ryan (whose vast knowledge of video dwarfs mine) has made some suggestions to optimize the video quality. Probably by switching to full manual exposure, with the largest aperture we have. Then find the fastest shutter that still works. This will hopefully brighten up the videos considerably and cut down on noise.
Longer term, I may look at an EVI-D70 camera. It is effectively the same (for control) by has a faster lens which may help in our low lite environment.
The proposal I made to BVC was to use the EVI-D30 which is available at low cost on eBay (typically about $175 plus shipping) to see if it could be used to "automate" some aspects of videoing track races. I even offered to spend my Nov race winnings on buying a camera.
Using this type of camera has several nice features. First it can be mounted in places you would be hard pressed to put a person and camera. And at our velodrome this allows use of a higher (by almost 2 meters) spot. Which in turn means that the back straight shots would be looking down at the riders and would actually be able to see them. The best you can do with a hand held from our stands is to see the top half of the rider, with the bottom half being obscured by the upper track and rails.
Second, this type of system should be able to provide a steadier and more reproducible shot as compared to a hand held.
Finally, if suitable easy to operate tracking software can be implemented, it may be easier to find volunteers to operate the system.
The initial software is a simple C++ program that can be used under Windows/Cygwin or Linux. It controls the camera via a serial port using the cameras VISCA protocol. Conceptually the program models the race simply, keeping a virtual distance around the track (0-200m) which is continuously updated with respect to the current virtual speed in kph.
Given a position (in meters) on the track, the track dimensions, and camera location, the program can calculate the current angles for pan and tilt, and the current distance between the camera and that part of the track. The math for this was provided by my son Ryan Lynne (apparently engineering students are good for something..)
The camera operator uses a simple set of keyboard commands to keep the head of the race in the video frame. Typically this only requires four commands: speed up, slow down, jump and pause. The speed commands simply increase or decrease the virtual speed.
Jump moves the virtual position slightly ahead (about 5-10 m depending on speed) allowing the frame to catch up with the riders.
Pause causes the position updater to stop for a short (.5 - 1 second) time to allow the race to move back into the frame.
The initial set of videos used shutter priority exposure with the shutter set to 1/250.
The operator viewed the video in real time using virtualdub attached to an ATI capture card.
The actual video was saved using a Hauppauge WinTV 250 card and a Hauppage wintv application to save directly to MPEG2.
Post race the videos where processed by Ryan Cousineau to re-compress down to mp4.
With the 6-day over we'll be updating the software a bit. First the initial deployed software didn't get the full math work over for tilt as the math functions didn't arrive until the day of the race. No time to test... So I'll be testing that shortly.
Second, Ryan (whose vast knowledge of video dwarfs mine) has made some suggestions to optimize the video quality. Probably by switching to full manual exposure, with the largest aperture we have. Then find the fastest shutter that still works. This will hopefully brighten up the videos considerably and cut down on noise.
Longer term, I may look at an EVI-D70 camera. It is effectively the same (for control) by has a faster lens which may help in our low lite environment.
Subscribe to:
Posts (Atom)