Fairfield 5: Three Edgy ZoomWalks

Using a series of still photographs to create a video, my technique in these ZoomWalks, is a double-edged sword. It takes effort to align the photographs, for instance, but any batch processing that I can identify can be employed to alter or enhance the photos. Recently I experimented with edge detection, using the imagemagick tool, to turn the photographs into what looks like a cross between a negative and pencil sketches. It turned out pretty well, so here I offer the recent three ZoomWalks processed into that style. I hope you enjoy them.



The Unsecret Path @ MUM (Edge/Outline Version) from Ben Branch on Vimeo.



Rotating the Dome @ MUM (Edge/Outline Version) from Ben Branch on Vimeo.



Orbiting the Maharishi Vedic Observatory (Edge/Outline Version) from Ben Branch on Vimeo.

Here is the obligatory still photo for the 'Recent Posts' and 'Popular Posts' sidebars.

Fairfield 5: Three ZoomWalks

During my March 2012 visit to Fairfield and MUM (Maharishi University of Management), I took photographs for three new ZoomWalk videos. (Earlier ZoomWalks are shown here.) This post will present the new videos and, at the end, discuss some changes in technique from the earlier ZoomWalks.

The Unsecret Path

In Sthapatya Veda, southern entrances are strongly discouraged, so the south face of the MUM campus not only has no entrances, it's fenced off. This can be inconvenient for traveling between half the campus and downtown or Everybody's, so an unofficial but well-tended path has evolved.

The first video is another ZoomWalk where the camera faces forward as the walker goes along this "unsecret" path. Because there are many objects (leaves, etc.) close to the walker and few objects far away, it worked best to have a short distance between the still photographs from which the video is constructed. Too many steps, and the continuity between frames would be lost. For this video, I took only one step between pictures.


The Unsecret Path @ MUM from Ben Branch on Vimeo.

Rotating the Golden Dome

 

The next ZoomWalk is quite different: the camera keeps facing a particular object, in this case the Maharishi Patanjali Golden Dome, as I walk.


Rotating the Dome @ MUM from Ben Branch on Vimeo.

For this video, I took two steps between each photograph. I had originally intended to take only one, but it was a very hot and sunny day. To stay out long enough for one step per photo I would have needed to bring along a snack, some water, and a wide-brimmed hat.

Orbiting the Maharishi Vedic Observatory

 

The third video was accumulated a couple of miles from the MUM campus, in Maharishi Vedic City, where the Vedic Observatory is located. Because of the concentric nature of the observatory, I walked around the structure about halfway out, once facing outwards, to capture the ring of instruments, and once facing inwards, to photograph the structures representing various planets and other astrological constructs. I also looped around one of the instruments.


Orbiting the Maharishi Vedic Observatory from Ben Branch on Vimeo.

I needed to take more photos, less far apart, for the outward facing portion of this video. Those instruments just fly by.

Techniques and Experiences

 

Whereas the "looking forward" ZoomWalks can use automatic methods to improve the alignment of the still images, that would be counterproductive when the camera is facing inward (Rotating the Golden Dome) or outward (Orbiting the Maharishi Vedic Observatory). Objects are supposed to slide from one side to the other through the frames. However, using the raw photos without any alignment whatsoever produces very jerky, almost unwatchable, videos. Thus I had to manually align each frame using some object or segment of the image. For the Golden Dome, it was the ornament on top, the kalash, that was my registration mark. Similarly, in the second half of the Observatory video, it was the cylinder in the center of the observatory. Aligning while looking outwards was difficult because of the lack of a central object; I would use the horizon and hope for the best. Needless to say, this manual aligning took a significant amount of time, and might discourage long-duration rotational ZoomWalks unless I find an automating technique. (The Rotating Dome video is based on about 240 photographs, plus title and credits frames.)

During the generation of the videos I experimented with "doubles." This is an animation technique where two identical pictures are taken of each step of the animation; thus, an animation with 24 frames per second requires only 12 animation steps. Previous ZoomWalks had one original image, then one or two "morphed" images, then the next original image. In shorthand, for images A and B, the frames generated would be, for two morphed images:

1. 100% A
2. 67%A/33%B
3. 33%A/67%B
4. 100%B

In all three of these videos, I doubled the originals by making a copy of each under a new name. (This I was able to automate.) Then, a two-morph video (Golden Dome) would be:

1. 100% A
2. 100% A
3. 67%A/33%B
4. 33%A/67%B
5. 100%B

A one-morph video (Unsecret Path and Vedic Observatory) would be:

1. 100%A
2. 100%A
3. 50%A/50%B
4. 100%B

I believe the higher proportion of original, unblended images produced by doubling yields a better product.

The algorithm for automatic alignment (used only in Unsecret Path) was also tweaked. Before, pairs of images would be compared, and because of the way the list of images was walked through, no more than half could ever be inspected. The new procedure is to align around "anchor points." For instance, consider the sequence of photographs 1, 2, 3, 4, 5, 6. If comparing three at a time, 2 would be the anchor point, and 1 and 3 would be compared to 2. Then 5 would be an anchor point for comparison with 4 and 6. Because of the way the align_image_stack tool works, the anchor point is unmodified; nonetheless, up to two-thirds of the images are alignable. There is no attempt to compare anchors, so occasionally a badly photographed anchor will require manual intervention. It also appears that comparing 3 images at a time (one anchor and two changeable) works better than comparing 5 at a time (one anchor and four changeable). Comparing 5 at a time puts images that are too different in the same pool, so attempting to reconcile them makes no sense.

Here is a still photograph to satisfy the 'Recent Posts' and 'Popular Posts' sidebars.

Those Darn Pushpins

I earlier documented the construction of my current computer, Juno. Last month it suddenly, overnight, began turning itself off just a few seconds after being turned on. At first I wasn't sure if it was the power supply, or something else, and I was even considering swapping power supplies. However, after being turned off overnight (and cooling off completely), juno would run just long enough for me to log in, and fortunately one of the programs that starts automatically when I log in is a system monitoring application called gkrellm. Thus it was revealed to me that the MCP (media and communications processor) on my motherboard, a combination of an interface to the memory and an integrated graphics processor (IGP), an nForce 730i, was rapidly getting so hot (over 90°C) that it was automatically shutting the system down to prevent damage to itself.

I was now confident of what I would find when I opened up the computer case. The heatsink on top of the MCP had probably come loose, robbing the MCP of any means to be cooled. The heatsink used by this particular motherboard, a Zotac 9300 mini ITX, is fastened atop the chipset by spring-loaded pushpins. Just two of them, on opposite corners. When building Juno, I had accidentally popped one of the pushpins out. Though I had successfully reinserted it, my thought was that this was the likely weak spot. It was.

Just pushing that pin back through the hole didn't work; it would immediately pop out again. It was going to be necessary for me to access the underside of the motherboard, which meant largely disassembling the computer.

Here is the underside of the motherboard. The locations of the two heatsink pushpin holes are circled in red. One is holding a pushpin, and one isn't. The bolted arms at the bottom of the photo are part of the mechanism that holds the heatsink for the CPU -- much more reliable than pushpins.

I inspected the failed pushpin. There was some beveling of the lip; perhaps I could spread the tip, or perhaps I should try something else; if I employed this pushpin again, the next failure might be in two months rather than two years.

The smallest machine screw at the hardware store (#4) would fit through the pushpin hole without forcing, so that was my choice of repair.

Here is the underside. Two thin, flexible washers protect the motherboard.

I carefully reassembled Juno, and pressed the power button. It booted normally, but then I looked at gkrellm and saw that the MCP was running about 15°C hotter than before.

Although technically acceptable, this was distressing. Two possible causes occurred to me. First, that the separation of the heatsink and MCP had scrambled or churned the thermal grease, which might have become thicker or dried out over the last two years. Second, that an imbalance of force exerted by the one remaining pushpin versus the nut-and-bolt might have lifted one corner, a small amount to be sure, but enough to interfere with heat transfer. Especially since only two of the four corners of this heatsink were secured or securable. If it had to have pushpins, why not four?

Both of these possibilities would mean disassembling the computer yet again. Worse, because the CPU heatsink hovers over a third of the MCP heatsink, I might need to remove the CPU heatsink to get sufficient access to the MCP to replace the other pushpin. To clean surfaces and replace the old thermal grease, I would almost certainly have to take off the CPU heatsink. Here's a top-down view.

I didn't feel that the reward would be worth the effort of a complete teardown. The temperature was still within specs, after all. But I enjoy tinkering when there's time, and so decided to try a couple of easier remedies.

First, I replaced the downward-blowing CPU fan, 120mm in diameter, with a 140mm fan. Thus more air would be blown onto the MCP, theoretically reducing its temperature.

The 140mm fan didn't quite fit into the case; I attached it to the CPU heatsink with only one screw so that it would rotate a few mm, allowing the case cover to close. Sad to say, this didn't lower the MCP temperature at all, and might have even raised it a degree or two. The airflow pattern of the larger fan was less suitable than that of the smaller one! I put the 120mm fan back on.

Then I tried attaching an 80mm fan to blow horizontally at the MCP heatsink. It turned out to fasten only in such as way that it could blow air towards the vicinity of the MCP, but not directly at it.

It didn't change the temperature a bit. I reversed the fan, so that it would push hot air out of the case, but that didn't change the temperature either. I then slapped it onto the back of the case, in a location which had some ventilation but still blocked perhaps a quarter of the fan, again to blow hot air out, and that may have improved the MCP temperature by 1°-2°C.

At this point I'd invested enough time. After all, the nVidia settings program considers the MCP to be only one measly bar into the yellow.

Juno is chugging along well, and I'm slowly growing accustomed to the higher MCP temperatures. They haven't interfered with writing this blog post!