Blog

I’m still struggling to make my 5th camera functional. After resoldering didn’t make any difference, I returned the second of my two multiplexers to Amazon and ordered a new one. When it arrived, I took extra care to solder on the passthrough pins. I used a much newer soldering iron, and it took considerably less time this go around. I connected the board and 5th camera and powered up the Pi. Unlike last time I tried, all the cameras’ lights turned on, which was a promising sign. Unfortunately, that wasn’t the end of the issue. With the second multiplexer attached, cameras 1 and 2 returned black (empty) photos. Camera 5 continues to give a data error: mmal: no data received… When I removed the second multiplexer, the original 4 cameras resumed working as normal. I tried switching the multiplexers (putting the new one on the bottom and the old one on top) without any effect. I’m frustrated by the instability the second multiplexer introduces into the system, so I returned it to Amazon. Soon I will reorder it again and hope that combination of both new splitters works. Until then, the system will remain as a 4 camera module.

My friend Avi built a lite logging platform for me to use, called Peashooter.

I modified my scripts to utilize this new tool, and now I have web based logs of the system’s progress. As long as it is connected to wifi, I’ll be easily able to see what it is up to.

Tearing and Timing

Due to the camera’s limited performance in low light, there isn’t much incentive to shoot outdoors any longer than 15 hours. As mentioned in Journal 8, battery life won’t ever be a limiting factor for outdoor shoots, so I won’t be including it in my evaluations here.

While I was I initially happy with the results of my first time-lapse, there were a few issues that I wanted to clean up.

In a few spots, the cameras’ don’t align perfectly, resulting in ‘tearing’.

If you rewatch the video carefully, you’ll also notice some interesting stitching artifacts in the corner of Physical Sciences (the building with red and white glass).

I suspect this phenomena arose from inconsistent layering of the two cameras that overlap in that region.

I spent some time this week refining the photo stitching template to reduce these tearing issues. Most of this consisted of reworking the panorama in Hugin on my Mac and manually adding more control points.

Hugin uses control points to denote which pixels overlap between photos. Many of them are auto generated. Each control point I added helped to make the final result a tiny bit more cohesive. When I was satisfied with the new template, I ported it to the Pi and then ran into a problem.

The original template could stitch a round in a average 90 seconds, allowing me to easily take photos every 2 minutes. This new template averages ~170 seconds/round, nearly twice as long. I’ve tested several similar refined templates, and they all take about this much time. It seems that the increased fidelity of the template has a dramatic impact on it’s stitching time. Now I can’t take photos any faster than once every 3 minutes. Why is that a problem? If I shoot for 15 hours (a full day), I’ll get 300 rounds. At 15 fps, this makes a brisk 20 second video – time will pass for the viewer at almost 1 hour/second. The shorter the interval I can shoot at, the smoother the resulting video becomes. I’m therefore motivated to shoot faster than once every 3 minutes, if possible. Thinking about this, I did some tests with Hugin’s batch processor on my Mac. These tests involved feeding Hugin a number of rounds and timing it as it ran. From this I discovered that my Mac can stitch rounds using the new template at about 30 seconds/round or using original template at about 16 seconds/round.

What are the interval/round limitations?

Due to the limitations of the cameras, I can’t shoot any faster than every 15 seconds, regardless of any processing.

Each round (photos 1-4) takes up ~10MB. Each finalized panorama is about 22MB. Fully configured, the Pi has roughly 18.6GB free (on a 32GB microSD card). If the Pi handles the stitching, I can take 590 rounds before I run out of space. Over a full day (15 hours), this actually is not a limiting factor. As shown in the table below, if I shoot at 2 min/round, I only have 450 rounds at the end of the day, comfortably less than my 590 limit. My first time-lapse was comprised of 409 rounds.

If my Mac handles the stitching, the Pi no longer needs to make panoramas, keeping each round only 10MB. I can shoot 1860 rounds within my space constraints. 1800 rounds in 15 hours is a round every 30 seconds, which would make a far smoother video than once every 3 minutes. The caveat though, is the processing time. 1800 rounds will take my computer 15 hours to churn through. See the table below for a comparison of different intervals and processing times.

If I’m shooting at 2 minutes/round or slower, it doesn’t make sense to use my Mac over the Pi.

After all this thought, I made further modifications to the template. This most recent version (v4) can be stitched by the Pi in ~90 seconds and my computer in ~16, effectively the same time as the original. Stitching 1800 rounds on my computer with this new template will take 8.5 hours. I think that running my setup for the entire day, bringing it inside, and having my computer stitch while I sleep is a viable option. With this in mind, I’ve forked the run-timelapse script. One version will utilize template 4 and take a round every two minutes, similar to last time. The other version will take photos every 30 seconds, but not stitch anything. The table below shows compares photo interval with processing time for this most recent template.

I’m planning on shooting my next time-lapse on Maryland Day (4/29/17) in a public location. To fully capture the activity of the day, I intend to shoot at 30 second intervals with external stitching.