Grasshopper3 Mobile Setup

I've now got a complete mobile setup working for the Grasshopper3 camera that I started playing with last week, and I took it for a spin during the Freefly company barbecue. (It's Seattle, so barbecues are indoor events. And it's Freefly, so there are RC drift cars everywhere.)

Since the camera communicates to a Windows or Linux machine over USB 3.0, I went looking for small USB 3.0-capable devices to go with it. There are a few interesting options. My laptop, which I carry around 90% of the time anyway, is the default choice. It is technically portable, but it's not really something you could use like a handheld camcorder. 

The smallest and least expensive device I found, thanks to a tip in last post's comments, is the ODROID-XU. At first I was skeptical that this small embedded Linux board could work with the camera, but there is actually a Point Grey app note describing how to set it up. The fixed 2GB of RAM would be limiting for buffering at full frame rate. And there is no SATA, since the single USB3.0 interface is intended for fast hard drives. So it would be limited to recording short bursts or at low frame rates, I think. But for the price it may still be interesting to explore. I will have to become a Linux hacker some day.

The Intel NUC, with a 4"x4" footprint, is another interesting choice if I want to turn it into a boxed camera, with up to 16GB of RAM and a spot for an SSD. The camera's drivers are known to work well on Intel chipsets, so this would be a good place to start. It would need a battery to go with it, but even so the resulting final package would be pretty compact and powerful. The only thing that's missing is an external monitor via HDMI out.

My first idea, and the one I ended up going with, is the Microsoft Surface Pro 2:

The Grasshopper3 take better pictures at 150fps than my phone does stills.

Other than a brief mention in a Point Grey app note, there wasn't any documentation that convinced me the Surface Pro 2 would work, but it has an Intel i5-4300 series, 8GB of RAM, and USB 3.0, so it seemed likely. And it did work, although at first not quite as well as my laptop (which is an i7-3740QM with 16GB of RAM). Using the FlyCapture2 Viewer, I could reliably record 120fps on the laptop, and sometimes if I kill all the background processes and the wind is blowing in the right direction, 150fps. On the Surface, those two numbers were more like 90fps and 120fps. Understandable, if the limitation really is processing power.

I also could not install the Point Grey USB 3.0 driver on the Surface. I tried every trick I know for getting third-party drivers to install in Windows: disabled driver signing (even though they are signed drivers), modified the .INF to trick Windows into accepting that it was in fact a USB 3.0 driver, turning off Secure Boot and UEFI mode, forcing the issue by uninstalling the old driver. No matter what, Windows 8.1 would not let me change drivers. I read on that internet thing that Windows 8 has its own integrated USB 3.0 driver, even though it still says Intel in driver name. Anyway, after a day of cursing at Windows 8 refusing to let me do a simple thing, I gave up on that approach and started looking at software.

The FlyCapture2 Viewer is a convenient GUI for streaming and saving images, but it definitely has some weird quirks. It tries to display images on screen at full frame rate, which is silly at 150fps. Most monitors can't keep up with that, and it's using processing power to convert the image to a GDI bitmap and draw graphics. The program also doesn't allow pure RAM buffering. It always tries to convert and save images to disk, filling the RAM buffer only if it is unable to do so fast enough. At 150fps, this leads to an interesting memory and processor usage waveform:

Discontinuous-mode RAM converter.

During the up slope of the memory usage plot, the program is creating a FIFO buffer in RAM and simultaneously pulling images out, converting them to their final still or video format, and writing them to disk. During the down slope, recording has stopped and the program finishes converting and saving the buffer. You can also see from the processor usage that even just streaming and displaying images without recording (when the RAM slope is zero) takes up a lot of processor time.

The difference between the up and down slopes is the reason why there needs to be a buffer. Hard disk speed can't keep up with the raw image data. An SSD like the one on the Surface Pro 2 has more of a chance, but it still can't record 1:1 at 150fps. It can, however, operate continuously at 30fps and possibly faster with some tweaking.

But to achieve actual maximum frame rate (USB 3.0 bus or sensor limited), I wanted to be able to 1) drop display rate down to 30fps and 2) only buffer into RAM, without trying to convert and save images at the same time. This is how high-speed cameras I've used in the past have worked. It means you get a limited record time based on available memory, but it's much easier on the processor. Converting and saving is deferred until after recording has finished. You could also record into a circular RAM buffer and use a post trigger after something exciting happens. Unfortunately, as far as I could tell, the stock FlyCapture2 Viewer program doesn't have these options.

The FlyCapture2 SDK, though, is extensive and has tons of example code. I dug around for a while and found the SimpleGUI example project was the easiest to work with. It's a Visual C# .NET project, a language I haven't used before but since I know C and VB.NET, it was easy enough to pick up. The project has only an image viewer and access to the standard camera control dialog, no capacity to buffer or save. So that part I have been adding myself. It's a work-in-progress still, so I won't post any source yet, but you can see the interface on this contraption:

Part of the motivation for choosing the Surface was so I could make the most absurd Mōvi monitor ever.

To the SimpleGUI I have just added a field for frame buffer size, a Record button, and a Save Buffer button. In the background, I have created an array of images that is dynamically allocated space in RAM as it gets filled up with raw images from the camera. I also modified the display code to only run at a fraction of the camera frame rate. (The code is well-written and places display and image capture on different threads, but I still think lowering the display rate helps.)

Once the buffered record is finished, Save Buffer starts the processor-intensive work of converting the image to its final format (including doing color processing and compression). It writes the images to a folder and clears out the RAM buffer as it goes. With the Surface's SSD, the write process is relatively quick. Not quite 150fps quick, but not far off either. So you record for 10-20 seconds, then save for a bit longer than that. Of course, you can still record continuously at lower frame rates using the normal FlyCapture2 Viewer. But this allows even the Surface to hit maximum frame rate.

All hail USB 3.0.

I just have to worry about cracking the screen now.

There are still a number of things I want to add to the program. I tested the circular buffer with post-trigger idea but couldn't get it working quite the way I wanted yet. I think that is achievable, though, and would make capturing unpredictable events much easier. I also want to attempt to write my own simultaneous buffering and converting/saving code to see if it can be any faster than the stock Viewer. I doubt it will but it's worth a try. Maybe saving raw images without trying to convert formats or do color processing is possible at faster rates. And there are some user interface functions to improve on. But in general I'm happy with the performance of the modified SimpleGUI program.

And I'm happy with the Grasshopper3 + Surface Pro 2 combo in general. They work quite nicely together, since the Surface combines the functions of monitor and recorder into one relatively compact device. The real enabler here is USB 3.0, though. It's hard to even imagine the transfer speeds at work. At 350MB/s, at any given point in time there are 10 bits, more than an entire pixel, contained in the two feet of USB 3.0 cable going from the camera to the Surface.

The sheer amount of data being generated is mind-boggling. For maximum frame rate, the RAM buffer must save raw images, which are 8 bits per pixel at 1920x1200 resolution. Each pixel has a color defined by the Bayer mask. (Higher bit depths and more advanced image processing modes are available at lower frame rates.) On the Surface, this means about 18 seconds of 150fps buffering, at most.

There are a variety of options available for color processing the raw image, and after color processing it can be saved as a standard 24-bit bitmap, meaning 8 bits of red, green, and blue for each pixel. In this format, each frame is a 6.6MB file. This fills up the 256GB SSD after just four minutes of video... So a better option might be to save the frames as high-quality JPEGs, which seems to offer about a 10:1 compression. Still, getting frame data off the Surface and onto my laptop for editing seemed like it would be a challenge.

Enter the RAGE.

USB 3.0 comes to the rescue here as well, though. There exist many extremely fast USB 3.0 thumb drives now. This 64GB one has a write speed of 50MB/s and a read speed nearing 200MB/s (almost as fast as the camera streams data). And it's not even nearly the fastest one available. The read speed is so fast that it's actually way better for me to just edit off of this drive than transfer anything to my laptop's hard drive.

Solid- I mean, Lightworks.

Lightworks seems to handle .bmp or .jpg frame folders nicely, importing continuously-numbered image sequences without a hassle. If they're on a fast enough disk, previewing them is no problem either. So I can just leave the source folders on the thumb drive - a really nice workflow, actually. When the editing is all done, I can archive the entire drive and/or just wipe it and start again.

While I was grabbing the USB 3.0 thumb drive, I also found this awesome thing:

It's a ReTrak USB 3.0 cable, which is absolutely awesome for Mōvi use - even better than the relatively flexible $5 eBay cable I bought to replace the suspension bridge cable that Point Grey sells. It's extremely thin and flexible, so as to impart minimum force onto the gimbal's stabilized payload. I'm not sure the shielding is sufficient for some of the things I plan to do with it, though, so I'll keep the other cables around just in case...

That's it for now. Here's some water and watermelon:

New Camera...thing.

After being completely surrounded by new cameras for a weekend at NAB 2014, I decided to do a little shopping around to possibly update my video camera. My Panasonic HDC-SD60 has served me well, especially with its 20x optical zoom and image stabilization. Pretty much every video on my site for the last few years has been from that camera. (This one is maybe my favorite, and shows its pretty decent low-light performance as well.) But there is so much new video camera technology now that I couldn't resist the urge to do some research into video cameras in the $1-2k price range.

Last year the Blackmagic Pocket Cinema Camera (BMPCC) was annouced at NAB and at the time I thought I might be interested in getting one. It's a really awesome camera because of its size and ability to shoot raw, wide dynamic range HD video, at a reasonable price. My only worry was that is was small enough that I might try to fly it on a smaller-than-adequate multirotor and crash. There's also the Panasonic GH3 (and new 4K GH4 coming soon), which is well-known for its extremely good video quality. It has the same interchangeable lens format (MFT) as the BMPCC.

But I also really like the camcorder format - specifically, a built-in zoom lens and optical stabilization. The BMPCC and GH3/GH4 (and other dSLRs that are out of my price range) have the advantage of large-format sensors that can collect lots of light, something that most camcorders with integrated zoom lenses suck at. But I did find an exception: the Sony HDR-CX900/B (2K) and FDR-AX100/B (4K), both with awesome 1" sensors. Sample footage from the FDR-AX100/B is especially impressive.

So with those as my top choices I considered the pros and cons decided on...

...none of the above.

And here's why: Everything I ever take video of is moving, and moving quickly. Not only that, but the camera usually is moving quickly to keep up. And every single one of those cameras has a rolling shutter, which is something that in my mind I can't understand how the world has come to accept (kind of like Hulu ads that are longer than TV commercial breaks). Looking at the end of this FDR-AX100 test video, it goes from "wow that is the sharpest-looking cat video I have ever seen on the internet" to "okay this is actually broken," in my view. So my solution to the problem was to run away from the consumer market entirely and get a machine vision camera with a global shutter. Specifically, a Point Grey Grasshopper 3 (GS3-U3-23S6C-C):

It's actually a tiny thing!

The body is smaller than a GoPro, but that's a pretty meaningless metric as I will explain shortly. As a machine vision camera, there are no shortage of inexpensive CCTV and scientific lenses for it. And this particular one has a color Sony IMX174 1/1.2" CMOS sensor, which is supposed to be quite good. Most machine vision cameras with global shutter use a CCD, but this new Sony global-shutter CMOS is interesting and hopefully will appear in a Sony camcorder soon, at which point maybe I rejoin the normal world. (Probably not; I am a terrible consumer because I usually think I could build things better from scratch...) But for now, the only way to get this sensor is in an industrial block camera like this.

No that's not a DB9 port...it's a USB3.0 mini-B.

Bill Kerman makes an excellent imaging test subject...

Anyway, the downside of a machine vision camera is that it's missing some (most?) parts a camera normally comprises. You've got a sensor, an FPGA for image processing, and a USB3.0 port. The rest is left as an exercise to the user. In effect, you are tied to a computer for recording the video. It's worth mentioning that the idea of an external recorder is not uncommon in high-end video cameras, so this isn't that unusual. But I did sort-of go in the opposite direction as the highly-integrated camcorder that I wanted. For now, anyway.

The benefits make up for it, I think. For starters, it can shoot up to 162 frames per second at 1920 x 1200 resolution. This is in 8-bit raw mode, so the data rate is 1920 x 1200 x 162 Bytes/s = 373MB/s. (For speed calculation, I'm treating 1MB as 1,000,000 Bytes, not 1,048,576 Bytes.) Color processing of the raw Bayer filter sensor data can be done on either side of the USB3.0 transfer, but for maximum frame rate it is left to the host computer. As for what happens to the data: if it can be written to hard drive space fast enough, it is. If not, as is the case on my laptop, it can be buffered in RAM.

Hrm, time to get an SSD I guess...

The RAM buffer is pretty common in high-speed cameras, but it means your record time is limited. The rate at which raw video chews through RAM is impressive. A fast SSD might just be able to keep up with the USB3.0 data rate, if there are no other bottlenecks in the system. For now, though, I just stuck to short bursts at the not-quite-maximum frame rate of 120fps:

I was playing with different video modes: mostly raw grayscale images and color-processed H.264 compression. (The H.264 encoding seems to be faster than the HDD write speed at the moment.) But yeah, it's certainly capable of high-quality HD video at 4-5x slow motion. At lower resolutions, it can go to even higher frame rates, mostly limited by the USB3.0 data rate.

Did you notice the global shutter? Freeze any of the frames with a propeller in it and the prop is visible in its normal shape...not something ranging from a banana to a boomerang depending on the shutter speed. The shutter can also be set as low as 5μs, meaning you can stop just about anything short of a bullet with enough light. (Ping-pong balls are relatively easy to stop even at ~2ms shutter speed and normal warehouse lighting, as was demonstrated.) 

The shutter can be synchronized with an external digital signal. So I can do this, but without a strobe gun. (Side note: You can see the rolling shutter wreaking havoc on the strobe in that video, and this one too, creating bands of light and dark as part of the image is shuttered with the strobe on and part of it with the strobe off.) The shutter sync works both ways too; it can also output a digital signal that is synchronized to the shutter. I have plans for this feature as well...

One other interesting characteristic of this sensor is that it has quite good low-light performance. This is useful for high-speed video since it can make the most out of the photons it gets with a very fast shutter. But it's also interesting to play with on its own. For example, I can image Bill Kerman in almost pitch black:

It's not nearly as impressive as the Sony A7s low-light demo, but it does produce quite nice video even at night, using the on-board color processor to do some gamma correction. Here's some video taken with just the slightest hint of light left in the sky:

I have no ideas what kind of ISO it can achieve, and it's not a published specification for this camera. (If I had to take a ballpark guess I would say ISO 2000+ with acceptable noise levels? I have almost no feel for that metric, though, so I'll have to try metering it against something.) But it's good compared to any video camera I've owned. Probably not quite as good as a full-frame dSLR. But combined with the global shutter, I think it can do some very interesting night shooting.

So far so good...I have many planned uses for this thing. The next step, though, will be un-tethering it...

HSV: Arrows and Fruit

In case you've never seen what an arrow going through fruit looks like in 333x slow motion.

These videos were shot with a Phantom high speed video camera in the Edgerton Center Strobe Lab during a freshman seminar. The lighting came out very well, even at 10,000 frames per second. Everyone's favorite seems to be the one where the arrow misses, taking out the cups but leaving the fruits hanging in mid-air. Newton's first and second law in action.

An interesting side note: the Phantom capture software saved the video in raw 8-bit format at a resolution of 512x256 (exactly 512x256 bytes per frame, no compression). But it added a .mov header. Although Quicktime could play it, my custom video converter tried to extract the frames as raw data. It put the header in as dummy pixels on the first frame, then all subsequent frames were shifted by that amount (so that they looked off-center). The fix was some very simple math:

1. Divide the file size in bytes by (512x256). Take the remainder.
2. Subtract that number of bytes from the file using a hex editor. This is the header.
3. Confirmation that the header ends after this number of bytes:

A wonderful little tag "mdat" (movie data?) at the exact address of the remainder. I love raw video! Compression is for losers.