Make OGG not MP3

In reference to recent news, MP3 is still gaining momentum, as Wal-Mart is replacing their Windows Media Audio (WMA) files with MP3. In my humble opinion, MP3 is still better than WMA because it is so well understood (coders, decoders, support, household name, etc.) and WMA is really just a way for Microsoft to get a piece of the Fraunhofer pie. However, as long as MP3 is really "gaining momentum", then we need to collectively do something about it...

Personally, I've made the following pledges and hope they inspire someone:

1. I will not distribute MP3
   I deal with a lot of original content, and after mix-down there's a choice--how to encode it to let someone hear it over the Internet? I will always choose FLAC or Ogg Vorbis, and refuse to send an MP3.
   
2. I will maintain my personal collection in Ogg Vorbis
   When I buy a new CD, the first thing I do (usually) is run it through GNOME Sound Juicer (which supports OGG and FLAC by default) and create Ogg Vorbis files so I can load it onto music player (software) or portable media player (hardware), and to protect the data from being damaged by wear on the CD. This is the cheif method that OGG could become ubiquitous. Transcoding MP3 to OGG is lossy (it's much better to start from the original sampling), and any audiophile would tell you it's not worth it. Therefor, the most important source of OGG files is at the source (audio CD, FLAC, etc.), and we can become less dependent on MP3 by replacing MP3 files with newly-encoded OGG files.
   
3. I will not buy a portable media player that does not support free codecs like Ogg Vorbis
   Okay, I still want to be able to listen to MP3, but in order to support pledge #2, I need my portable media device to support OGG out of the box. I personally have a COWON (iAudio) T2, but there are many other options from abroad.
4. I prefer Ogg Vorbis Internet radio over other formats
   Hey, if OGG has the same fidelity at a lower bandwidth (you'll note the rates on Internet streams have a lower average), then we're saving the host bandwidth by preferring an Ogg Vorbis stream. Also, since Internet radio is struggling with royalties, why don't they save themselves money by dropping their MP3 streams and providing only Ogg Vorbis streams? I feel that most Internet radio listeners would not mind having to download an additional codec (if they even need to) to make the switch.
   

These are reasonable commitments to make, and the second big corporations catch on, we'll start to see MP3 dwindle away. Ogg Vorbis will have to make a statistical win (what is the probability of an audio file being an OGG?), and a compatibility win (what is the probability I can play this OGG?) in order to acheive this.

Note that DRM is not even in my vocabulary--it seems like the only "solution" to DRM is to avoid it at all costs. This business of limiting where, when and who can listen to a file (that someone has paid for, mind you) is nonsense. This is exactly the reason we dropped vinyl albums and magnetic tapes for compact discs--so we could hear the same thing again whenever and wherever we want.

Finally, Gmail offers IMAP

Previously Google claimed that IMAP would be too difficult to implement given their unconventional e-mail organization scheme (all e-mails basically in one folder). Now, they've finally opened up IMAP servers which allows much greater control than POP 3 previously did. For instance, one should be able to now import old e-mails into Gmail so that now all your mail is searcheable from one place!

GNU Screen -- The best thing since VNC?

I have recently found myself in a bit of a blunder. I found myself opening a VNC server (with vncserver) and then connecting to it just to open a bunch of xterm's, and this seemed wasteful to download pictures of a text-mode terminal. I also SSH in and run long-term tasks and want to disconnect--but don't want to use nohup because I might want to re-gain control of the program or just see in real-time what the output is.

Then I remembered I read the description of a software some time ago in pirut, and thought it was a great idea. This software, as I remember it, was much like what I've just found here, but it seems like this project is defunct. I know there was something which was its own daemon and allowed persistent sessions, but...

After a lot of Googling, I finally came accross GNU Screen. I find this software awesome! Basically, it's like a window manager for your Secure Shell, allowing multiple new shells to be opened and switched between, "screen splitting" so you can see two screens at once, persistence of your tasks--which was exactly what I was looking for, and other features like sharing the session between users. Now I can have my multiple terminals running on the remote machine and use them effectively and more efficiently than via VNC.

The Wikipedia article links to many good tutorials in its references section. I recommend you try a few of them, especially this one, but if you're like me--you need to know right away:

• install: yum install screen


• run: screen


• disconnect: CTRL+a d


• reconnect: screen -r -d

Disclaimer: Yes, VNC is newer than Screen. No, Screen is not convenient when you need to use GUI's since even if you get it to work, it's forwarding who X windows, which can be much too slow if you're connecting over WAN. VNC is definitely the way to go if you have GUI programs you want to use in conjunction with text-mode.

Happy screening!

Jamendo

Jamendo is an excellent program which allows artists to release musical works into the public domain under various formats. With plugins for programs like Rhythmbox, you can use the service as an Internet Radio, and if you like something you can visit the artist's site on Jamendo or get the whole album on BitTorrent. Recordings are uploaded in WAV for FLAC, and are distributed in OGG and MP3.

If you are an artist with content that you feel would should be in the public domain, sharing your original recordings is easy. More importantly, you can get feedback on your recordings from the Jamendo community, which can be exciting because all the opinions (although sometimes misguided) are impartial--which is more than you can expect of your friends :) .

SourceForge.net User Network

Anyone can join SourceForge.net, even if you don't have a project to share. Many projects need testers, developers, documentation writers, and translators (and more). There's a long list of projects which have advertised they need assistance (http://sourceforge.net/people/). It's a great way to help out the SF.net community and gain coding experience both by examining code and by extending/adding new code.

Configure OpenSSH to automatically authenticate

Sometimes entering your pass-phrase to gain SSH access can get redundant, or you may want an automated script to be able to authenticate as you (as described at http://sial.org/howto/rsync/).

I've been trying to do this for some time now--apparently if you read the man pages carefully enough you can figure this out. I thought I'd need a more advanced SSH client, but OpenSSH already has everything you need--the ssh-keygen program is key. Following is a brief walk-through of how to configure connection from client to server for SSH. Replace the words client and server as appropriate.

client$ ssh-keygen -t rsa

It will ask where to save, you want the default since this is where ssh will look. It will ask for a pass-phrase, and since we're trying to get around having to enter a pass-phrase, we don't want to protect our authentication, so just hit enter twice. Then it will give you a fingerprint and put files in your ~/.ssh directory.

Copy the ~/.ssh/id_rsa.pub to the server machine taking care not to overwrite the same file there:

client$ scp ~/.ssh/id_rsa.pub user@server.address:.ssh/client.pub

Now SSH to the server and add the public key to the authorized keys file like so:

server$ cd ~/.ssh
server$ cat client.pub >> authorized_keys
server$ rm client.pub

The SSH server won't let you use the key unless the file is secured. That is, the keys should only be readable by you.

server$ ls -l authorized_keys
-rw-rw-r-- 1 user users authorized_keys
server$ chmod og-rw authorized_keys

Now we should be able to open an SSH session simply by:

client$ ssh user@server.address

where you can omit the 'user@' part if the user names are the same on the local and remote machines.

Finally, note that doing all this means if you leave your machine open, an intruder has more doors they can open! This is why you should always lock and/or time-out your screen. If the key has no passphrase, then if someone copies it, they can gain access to the machine you opened with this procedure. Therefore, you should restrict access to your machine by configuring /etc/hosts.allow and /etc/hosts.deny. If you're concerned, don't let the passphrase for the key be null (use a passphrase). Taking these steps can help protect your key.

Cost Review for Luxeon LED Headlight

To justify building on myself, I had to do a cost analysis.

Purchased:

4x D-cell Batteries ($5)
1x LED Dynamics BoostPuck ($35)
4x Lumileds Luxeon I Star/O ($25)

Subtotal: $65

Spare parts:
1x 270uF capacitor
1x 24-gauge (AWG) lead wire
1x Pentium3 Heat Sink
1x Mounting bracket
1x Rocker switch
2x 2 D-cell Battery Holder
1x 18-gauge (AWG) lead wire

Note that comparable systems are water-resistant and include a rechargeable battery system, but can cost from $120 up to $300.

Rebuild of Luxeon I Bicycle Headlight

This is a practical comparison between two light sources: an old 2-C cell halogen headlight and a single Luxeon I Star (with optics), both driven at the proper power. This is an image with no special adjustments and the sources about 5 feet away. It is easy to see that the Luxeon I has both more flux (total amount of light) and better throw (maximum intensity of beam). Note that halogen bulbs are known to be more efficient than traditional vacuum bulbs, see Lighting efficacy for more. According to my calculations, the power delivered to the halogen bulb is about 1.5 Watts, and the power to the Luxeon I (obviously) is 1 Watt. Note the spectrum of light output, and how this would make riding safer. This comparison allows the efficiency of the LED to really "shine".

Note that my power supply (limited to 1 amp) may not have been able to provide enough current to drive the Halogen bulb to the same power as the 2 C-cells, so the halogen light may get brighter with actual batteries. However, the power measurements quoted are absolutely correct and (together with the comparison picture) still illustrate the point of efficiency. Also note that only one Luxeon I (1-watt) is switched on in the comparison picture, whereas four are used in my headlight assembly.

The LED Dynamics BoostPuck 350mA current regulator came today. The model with lead wires attached was not available, so I had to solder on wires. It really is small as they say; even smaller than my rocker switch. I left the extra pins (reference voltage, and dim) not connected.


Using my power supply, I verified all the parts and connections were OK. The meter pictured is showing volts across the input power pins of the BoostPuck (out of frame). The system is was actually pulling down the voltage on my 1-amp-maximum power supply set at 6.0V by 200mV. You can see that the LED's are fully illuminated, which requires at least 12 Volts in their wiring configuration...


I soldered everything together as I mentioned I would in my last post (in series). I included a 270uF capacitor. The only problem with the BoostPuck is that it's a sealed unit and has no way to mount it to anything, unless you use the pins to anchor it (which I don't). It's not heavy, so I didn't think it's all that important. Using industrial hot glue, I fixed it to the rocker switch, and the capacitor to it as well. I expect the hot glue not to hold for long, especially if things heat up. I'll use some epoxy if all goes well--the hot glue comes off easily, epoxy won't.

The light output looks about right. It might be a little dimmer than the unregulated circuit, but it's worth the gains in battery efficiency/power delivery. The BoostPuck is producing over 12VDC across the four LED's in series, which is about what I expected. I haven't actually checked, but I'm assuming that the diode current is 350mA. I didn't make measurements of the current drawn from the batteries because of the AC components.


The light beam itself is continuous (as opposed to strobed); waving hands in front of the beam doesn't reveal individual light pulses as with other charge-pumping lights I've encountered. Also, the intensity differences between the new and old LED's is gone as I expected. The newer LED's needed a higher voltage than the older LED's to produce the same amount of light, and fixing the current at 350mA equalized the light intensity.

For clarity, below is a crude circuit diagram including all the parts.

Luxeon LED headlight assembly

Have an old processor heat sink laying around? This Pentium 3 heatsink is the perfect size for four Luxeon I Star/O assemblies (LumiLEDs Product# LXHL-NWE8). Luxeon light sources need very good heat dissipation, and this might be over-doing it, but why not prolong the life of the light sources?

I wanted to get around paying up to $300 for a battery-powered bicycle headlamp, so I decided to meet or exceed the expectations with available parts.

I initially bought only two of these Luxeon Stars (with optics) over a year ago. I didn't have a good way to drive them other than my Elenco Precision (TM) power supply and alkaline batteries, both of which are voltage sources. I tried using two D cell alkaline batteries, this provided 3.0V which is less than the typical 3.4V, and not didn't force enough current to for the LED's to be all the way on. I also didn't have a good mounting bracket, or a good way to mount the batteries to the bicycle frame.


Recently, using the mounting bracket from and old mechanical speedometer and zip ties, I was able to make an excellent mount. This stops the lights from changing pitch (very important for this application) or breaking free. I connected them all in parallel to try to give them all 3.0V from the two D cells.

Lesson learned: Don't solder when the device is a metal core PCB and it's sitting on a heat sink with silicon paste in between! Leave these PCB's on an insulator while soldering.


I noted that they were only drawing around 800mA, nowhere near 1.4A (4x350mA). I decided to increase my power supply voltage potential, but this meant there needs to be another component in series with the light sources to allow the excess voltage to be dissipated. In the application notes from LumiLEDs, they recommend using a 6V power supply and a 10 Ohm resistor for a Luxeon I. I added another battery pack to the frame to get 6.3V, but I decided to use 0.9V rectifying diodes (3A max) rather than four resistors (one in series with each supply) which would require desoldering. This achieved 1.6A with one diode in series and 1.1A with two diodes in series. I stuck with the two diodes in series to stay on the safe side. The diodes get rather hot very quickly since they're dissipating so much power. This is a major problem, by my measurements -- 45% of the power was being dissipated in the diodes themselves, delivering only 55% of the power from the batteries to the light sources. Another reason that a passive approach (linear mode voltage regulation) is bad for alkaline battery applications is that the higher the power delivery, the more the batteries self heat and increase internal resistance. In other words, Alkaline's are less efficient when discharged quickly. It is a common trend that batteries are more efficient with intermittent loading for reasons related to battery theory. For much more, see the IEEE paper Battery­Driven System Design: A New Frontier in Low Power Design, by Kanishka Lahiri, Anand Raghunathan, Sujit Dey, and Debashis Panigrahi.

Lesson learned: The voltage drop across an LED is related to the energy released in each photon--relating to the wavelength of the light emitted. (Note that this is the P-N junction voltage drop, and differs from the external voltage drop and light spectrum is also highly dependent upon construction materials). The current through the LED corresponds to the number of photons emitted--relating to the intensity of light emitted. These brief rules of thumb really help in understanding how to apply high-power LED's.

Lesson learned: Luxeon LED's are constant-current devices, so to get them to the proper luminous intensity and power consumption, they need to be driven at the proper current amperage. For Luxeon I's this is 350mA, for Luxeon III's this is 700mA, etc. This point remained subtle to me because I figured I could always just find a voltage potential which would result in the proper current being drawn. The problem is that LumiLEDs has a tighter manufacturer tolerance of 350mA operating conditions than the forward voltage (Vf) which is loosely maintained. This means each light source will require a slightly different Vf to draw 350mA and use run at the full 1 Watt. The most robust solution is a constant current source which can be used to drive multiple light source in series. This also allows the supply voltage to fluctuate (eg: a draining battery) and not affect the luminous intensity as it would without a regulator.

Lesson learned: A common optimization for alkaline battery-powered applications is to use a charge-pumping power regulator. These are capable of producing voltages higher than their input voltage (12VDC from 6VDC for instance) by intermittently presenting a larger load and driving an oscillating circuit. The typical result is luminous intensity remaining mostly flat until the battery is mostly depleted. Just connecting a 12VDC battery supply would result in an exponentially decaying luminous intensity.

These conclusions lead me to replace my diode-dissipating circuit with a switch-mode power supply including a boost circuit. Because of the scarce availability of through-hole mounting switch-mode power supplies and the necessity for a PCB, I was very happy to find products from LED Dynamics including the BoostPuck. Their Application Figure 3 in their datasheet is my exact application. The regulators are unfortunately around $34, but it's worth the efficiency of a switch-mode power supply, the optimized battery utilization, and proper driving (constant current of 350mA) of the light sources to get the most light without risking burning out the LED.

When the unit arrives, I'll removed the hot glue (to keep the parts clean) and connect the light sources in series and connect the BoostPuck to the ligth sources after the rocker switch. As per the application notes, I'll need to include a capacitor since my batteries are a few feet away. More as soon as the part comes in.

1979 Free Spirit Ten Speed

Once I started riding this old Free Spirit ten-speed, I was hooked. Most of my riding is on a paved recreational trail, so the thin tires aren't a hazard and the bike is a lot more efficient than a Mountain Bike on those conditions.


The bicycle came from Sears & Roebuck circa 1979. I decided that even if I buy a new road bike, that I wanted to keep the Free Spirit around since it was in such good condition compared to a few much younger bikes I have seen. The parts are old (Shimano) parts, but most of the following procedures still apply to most bicycles.

The first problem was that the wheels needed to be "trued" very badly, the crank was loose, it had lots of grime around the chain hardware, the brakes needed to be tensioned, and it had some out of order accessories. The accessories it had were a luggage wrack in the back which had a broken support (which is laying on the ground behind the bike in the picture), and a mechanical speedometer which had a loose cable and just made chirping noises. It also had "soft" plastic handle grips on the end of the dropped handle bars which were petrified and provided no cushioning.


I started by disassembling the whole thing! I cleaned all the parts with CLOROX(tm) disinfecting wipes because they have a cleaning agent which does no harm and are great for absorbing grime. I put the luggage wrack aside because it just got in the way of mounting/dismounting (and was broken). As for the speedometer, modern bicycle computers (speedometer, odometer, tripometer, etc.) are now inexpensive, under $12 at your local "superstore", and allow you to program your wheel size (unlike the mechanical one), so I replaced the huge speedometer with the little computer.


I took the wheels to the local bike shop and had them trued for $5/wheel. They still have a little jitter, but it's nothing compared to the thumping and wobbling that they had before. They had both lateral (off rotation axis) wobble and radial (tending to not form a circle) wobble. I can ride over 20 mph now and not leave the ground.


While the wheels were being worked on, I was able to remove the plastic grips a lot easier than I expected (these things have tendency to become attached). Rubber grips can be a real pain, but I figured the plastic grips would have been fused to the handlebars. I just inserted a flat-head screw driver (on the bottom side to avoid any visible scratching) in between the grip and the handle bar. I didn't pry with the screwdriver, rather just inserted and removed it several times, spraying WD-40 down the length of the screwdriver each time. After about three times, I was able to break each grip free by trying to twist the grip around the handlebar. Once it came free, I took out the screwdriver and worked it off. I cleaned the lubricant off the bars. I bought some handlebar gel tape from Bartrager, and installed them according to these directions since there were none in the box. I guess I have long handlebars because I didn't have to cut the length of the tape, I just made a cut to taper the distal end of the tape so it was flush with the handlebar cap.





The bicycle has a disk brake in the back which needed to be manually tightened because it didn't lock the wheel. The brakes in the front were also too loose. Tip: If brake pads don't lock the wheel, they need more tension. Take the wheel off of the frame, and ask an assistant to hold the pads together. If your caliper makes it easy to disengage the recoiling springs, you won't need an assistant. Taking the wheel off will provide enough slack to make the adjustment--I found it was impossible otherwise. Adjust where the steel cable is fastened on the caliper side about a centimeter and tighten everything back up.


The bike was back in order but the crank still felt bad because it moved inside the frame. It's a one-piece crank and is a lot simpler than I thought before. Take the chain off first. It has a big locking nut which you'll need a big wrench for. Note that the threads are in the opposite direction from most threads, so you take the nut off by turning it in a clockwise direction. Under that, there were some washers which act as dust covers. There is a big nut that the ball bearings ride on which needs to be finger-tightened, it was loose and this is where the crank wobble came from. I de-greased the ball bearings and the journals inside the frame. It was essentially dry inside just a lot of black deposits on everything. There was some fatigue on the right-hand (gear) side where the ball bearings either crashed down or the bearing retainer was hitting. With one-piece cranks, look inside where the crank fits and look for the obstructions from the other tubes. Find a place to fit the corner of the crank and angle the crank through as to take the gear away from the frame. This will give you more space and will let the crank rest. After everything was clean (I had to use an abrasive brush in some places), I greased everything up as much as I could and put everything back together. I used a screwdriver to make the final torque on the hand-tightened nut, I stopped as soon as I felt no wobbling of the crank. When you put everything back together, you should be able to spin the crank and it should keep spinning for a while. If it doesn't make it more than a few turns after you let go, it's too tight.


After a few other adjustments, like the kickstand position, everything was ready to go. The bike feels a lot tighter like a new bike would. All the rattling, chirping, and wobbling is gone.

The bike will need new tires soon (the thin tires don't last very long), I have about 300 miles on mine and the tread in the back is disappearing. When I replace these, I'll try to disassemble the bearings on the wheels and try to revive them like I did the crank bearings. I'll also replace the chain at that time.

Mount USB drives on boot

On Fedora Core 7, leaving a USB drive (a simple flash disk) connected doesn't seem to be mounting after reboot even though it's properly listed in the /etc/fstab. I went through a few solutions to this, like this one, but the only one that worked for me was modifying the /etc/rc.sysinit script as I explain below.

I seem to remember creating an entry in the fstab, and allowing the auto option (which is part of the default specification), would make your USB partition mount on boot. The issue with FC7 seems to be that the usb-storage kernel module isn't being loaded when the fstab is first loaded, and that the USB devices aren't initialized yet by /etc/rc.sysinit. This seems to be common with all newer distros, in accordance with the move to udev, hal and other components, which facilitate plug & play user mounting and they don't need them to be available before entering a GUI. This is great for workstations, but I have a "headless" server configuration, therefor I'm not using GNOME to mount anything on-demand, but rather they should be available statically.

After a few days of trial & error, and inspiration from this post, I added the following lines to the end of my /etc/rc.sysinit. Note that changes to this particular file may be removed by system updates (Using yum) as I explain below.

# Try to mount all USB partitions
# This should be moved to `rc.local' and be prepended with a wait
modprobe usb-storage
mount -a

I believe this is the most most robust method, since simply adding the entry to the fstab will allow it to be mounted after the USB devices are initialized. It is preferred to use the /etc/rc.local script to issue this nature of commands (local/custom configuration), but this script seems to be run before the /etc/rc.sysinit script exits, meaning the USB partitions may not yet be available. Commanding the /etc/rc.local script to wait for the /etc/rc.sysinit script to exit may be a solution.

Finally, note that you can guarantee consistency of the partition before mounting it by carefully editing the corresponding fstab line in the normal way, see man 5 fstab for more.

Label your EXT3 partitions!

If you have removable drives used for backup or portable media, and you're using EXT3 rather than FAT16 (the default format of most USB flash drives), mounting these drives by their Linux device name is ambiguous. For example, I have a hard drive in a Venus DS-3 with a single EXT3 partition on it. The problem is, making the entry in the /etc/fstab file. The /dev/sd[a-z][1-9] designation is not good enough because it changes with the order of the connections during boot-time or plug-in time.

Making labels for each partition to be mounted fixes the problem entirely. To create a label for an ext2/ext3 partition, use the e2label command:

e2label [device] [label]

My exact command was:

e2label /dev/sde1 "Venus1"

Note that I had to find the right drive using 'fdisk' before I knew it was 'sde1'.

The change takes place right away, and then you can put a line in your /etc/fstab like:

LABEL="Venus1"          /media/venus1           ext3    noauto          0 0

And it will run through the drives to find the right label. We've associated the mount location with the partition on the physical device. This is especially important if you're mounting the drives on a server and are not using any automatic mounting facility.

Some recommend to also label the static partitions if you're using only EXT3. If you're using LVM, the groups and volumes are already labeled.

Alternatively, you may use a UUID, obtained from

udevinfo -q env -n /dev/sdd1

Where sdd1 is your USB device, which you can find from

fdisk -l

There is a lot more info you can get with udevinfo but for now, just grab the ID_FS_UUID and you can use it in your /etc/fstab as follows:

UUID=492bc203-de77-40b6-be4b-49e84fee430e /data ext3 auto,defaults 0 0

See http://www.patrickmin.com/linux/tip.php?name=usbkey_mount and
http://floatingsun.net/articles/howtos/howto-usb-automount.html for more.

Narrow-angle Panormas with Hugin

I have a telephoto lens and I wanted to stitch together several pictures of the Baltimore-Washington International airfield. Taking the pictures was just fine, although I hadn't learned how to set the exposure settings yet (see my post on this), and need to do it again on a clear day. What I didn't realize was that there's essentially no 'barrel distortion' with narrow-angle shots.

I found that it's hard for Hugin to figure out the angle of your shots when there's no barrel distortion. It misbehaves if you try to use the same procedure as you would for wide angle panoramas, and gives you completely insane average errors and if you try a preview--it won't be pretty. There are two things you need to do: tell it your horizontal field of view angle, and don't allow barrel distortion optimization. Only use "Positions and View (y,p,r,v)", and check that the barrel distortion stays close to 0.000 for now. This means that your panorama is essentially flat.

I was taking my panorama shots in portrait mode, which meant that my horizontal angle was 75% (the inverse of the aspect ratio 4/3) of the angle in landscape mode. That angle was about 8.10 degrees, and so the angle for each shot was 6.08 degrees. I got my focal length from the EXIF data, 224 mm, but the angle is most important.

Before final optimiztion and stitching, you may want to change the barrel distortion to something between 0.0034 and 0.006. This will add perspective to the panorama. Make sure you still don't run the optimizer for barrel distortion.

Panoramas with the Nikon D-50

This is a panorama I made while learning the following procedure for the Nikon D-50. These same instructions should apply to most Nikon Digital SLR cameras, and can be translated to most other digital cameras. In fact, I find that the huge resolution of my camera doesn't really impact the final product because you want most of the image to fit on your computer monitor, and you're literally multiplying megapixel area each time you take a shot (your canvas gets big quick)--so for close range panoramas, cheap digital cameras are fine as long as you can apply the following instructions to them.

The Nikon CoolPix series, unlike the Nikon D-50, has a Panorama Assist mode. This mode allowed you to take the first shot, which would set up the shutter, aperture and white balance for the rest of the shots. Then the right third of the last image would appear on the left-hand side and be semi-transparent. This allowed you to align landmarks and get good anchors for your stiching. The fixing of the shooting settings was also nice because it meant that the seems wouldn't be visible if you use a good panorama tool (see my post on Hugin).

However, the Nikon D-50 is more professional and didn't include such a mode. No matter! After reading over the manual, which is available on the internet (it was hard to find at Nikon's site, www.nikonusa.com), it was easy to piece together the same process as the 'Panorama Assist' mode.

How to do it:

Get a tripod and make sure it has a level. Set up the tripod and check the level before and after mounting the camera. Loosen the yaw all the way, and tighten the pitch and roll. Without a Tripod, you'll find that your panorama will actually be askew, and picking a level rectangle for cropping will leave you with a lot of wasted image area.

If you're shooting a large up and down angle and have the standard 300mm lens, roll the camera and shoot portrait shots. This means if you don't rotate each shot, you might be stichting tops and bottoms of images in Hugin, which is counterinuitive, but you can rotate the anchor in Hugin later and everything will be fine.

Since we're post-processing the images, you should use 'Fine' mode. You don't have to use 'Raw', and in fact I noticed no real difference between 'Raw' and 'Fine' modes for this application.

The the 'M' mode on the mode dial means 'Manual Mode'. So, you just put the camera into this mode, and the shooting settings (shutter speed and aperture) are fixed.

Note that being in Manual Mode means the camera is not doing anything for you! You'll have to find some angle in your panorama to set the exposure settings until the exposure meter says zero. I favor the angle closest to the sun, but don't let the sun enter the frame. This will leave the dark portions of the panorama underexposed. The exposure meter is inside the viewfinder along the bottom. Rotate the winder on the right-hand side as you normally would to change the shutter speed and find the fastest speed that gets the reticle inside the meter. Then hold down the button on top, next to the power switch, shaped like an iris and rotate the same winder to adjust the aperture. Repeat the process until the reticle in the exposure meter is at zero.

On other thing you'll want to do is find a target at nominal distance to focus (or perform an auto focus) on. Then switch the camera into manual focus mode, since we don't want it to change. Don't accidentally change the focus.

Now you can start snapping away. Pick the most left angle and shoot, then change the yaw of the camera keeping a landmark that was on the right-hand side in the frame. Don't share too much of the yaw angle with the previous frame or you'll take too many pictures. Don't share too little or you won't have enough landmarks (common features) to teach the panorama tool how to stitch them together. You'll get the hang of it.

Finally, load the pictures onto your GNU+Linux workstation (or Windows, bleh) and import the series of shots into Hugin. http://hugin.sourceforge.net/

Hugin Deserves a Hug!

Yes, I know other bloggers have already written in depth about Hugin, but I'd like to share my experience.

First of all, Hugin is just a graphical front-end for already established panorama libraries (which I didn't know existed) called panotools. Before, I would piece together a panorama by hand with The GIMP, but that never made the edges seamless, and never accounted for the lens barrel distortion.

The official page:
http://hugin.sourceforge.net/

They have plenty of tutorials to get you started. The program is not overcomplicated and you can get the hang of it rather quickly (make sure you are following the tutorials). It's just a matter of teaching the panorama tool how the images fit together and how the camera distorts the landscape.

The panorma shown was taken with a Nikon Coolpix 5400 in Panorama Assist mode some time ago. I hadn't been able to see the pictures stitched together because of the intensity of the barrel distortion, but with Hugin, it was a snap!

More process-specific posts on Hugin to come.

Announcing New Bliggity Blog

Assuming that anyone might read this, I just want to make this post to announce that my blog will no longer be strictly GNU+Linux and computer tips. It will still be related to these topics, but posts on 'how to do this' either with a GUI or from the command line are getting too scarce. Note that I will start to use 'labels' (aka 'tags') so that you can still filter out all but a certain topic.

Pesky Windows "Thumbs.db" Files

Windows creates a Thumbs.db file whenever it finds an image in a directory. If you are trying to reduce the number of files on your file system, or trying (really hard) to save space, you can issue the following commands as administrator.

locate -r ".*/Thumbs.db" > ~/delme-thumbs.txt

Which queries the mlocate database for the thumbnail files. If you're not running mlocate, you would use the find command here.

cat ~/delme-thumbs.txt | tr \\n \\0 | xargs -0 du -hsc

This will show you how much each file is taking up and include a sum of the total size. Finally, you might want to free these files with the following command:

cat delme-thumbs.txt | tr \\n \\0 | xargs -0 rm

To Beep or not to Beep

Seems like Linux has done everything to prevent anyone from controlling the I/O devices under /dev, which includes you. I had a simple task, I wanted my "mail-notification" program to beep when I had mail. Under "When new mail arrives:", there was the command "play /path/to/some/sound.aiff" or something... I don't want any process interrupting my sound card because I'm running Fedora Linux, and I don't have JACK or another sound mixer which will mix sounds from multiple processes (maybe one day ALSA will work like this).

So anyway, I tried a million different commands...

echo -ne "\a"

which prints just a bell character, but it's interpretted by mail-notification (or nothing) and is lost--not sounded on the system beeper.

I tried a C program by Johnathan Nightingale, beep, which I had lying around, but it fails because the kernel doesn't like it touching the devices.

Finally, I thought "hmm, beep.c is just writing to /dev/console, why can't I?" and I tried

echo -ne "\a" > /dev/console

And it worked! It's not the same beep as Thunderbird/xterm/emacs, but it's fine with me!

Executing a command on multiple files with FIND

Okay, so apparently, the FIND command is so powerful that you can even tell it what to do with the files when it finds them. I always used to find multiple files, translate newline characters to null characters, then pass each argument to XARGS as in:
find ./ -regex ".*\.mp3" | tr \\n \\0 | xargs -0 -n 1 md5sum > mp3checksums.md5

But, you can also say:
find ./ -regex ".*\.mp3" -exec md5sum {} \; > mp3checksums.md5

Where, the {} implies to insert an individual argument into that part of the exec string, and the semicolon (escaped so it's not picked up by BASH) ends the -exec agrument.

Computer Internal Dust Solutions

It seems like opening up my computer (or multiple in my case) and blowing it out every month is releasing too much dust back into the air, and all those particles that were stuck in there can wreak havoc upon your moving parts (fans). Assuming you operate electronic devices which have ventilation fans indoors, try the following.

Get a HEPA filter and run it, at least on its lowest setting, all the time.
The electricity it takes to run such filters is completely eclipsed by how much dust they remove from the indoor air and prevent those particles from being stirred up again. It's better for human breathing, and better for devices with moving parts. Also, if the filter circulates the air, your components might run cooler.

Install low-impedance dust filters in front of your computer's ventilation intakes.
Many computer cases are already shipping with single-layer plastic mesh filters which will stop most huge dust particles (the ones you can see anyway). I decided to give it a shot and installed some extra dust filters on the intakes of two computers. One computer had side ports which were completely open (no, fan, just big holes). NOTE: If you have filters installed, air will follow the path of least impedance, so either block or put filters over all air passageways that flow into the case. Don't put filters on exhaust ports (ports which blow out).
I decided to use WEB Vent Filters, but these have a few drawbacks: they have fibers which come loose, and are higher impedance than the coarse foam. Coarse foam like that in SHOP*VAC Foam Sleeves is preferred for low impedance of air flow, but doesn't offer good filtering of smaller particles. Both are readily available at the local hardware store.



I put WEB Vent Filters on the outside of the case (so they wouldn't get sucked into the fan) for one, and in between the case and the air duct for the other. On the other computer, I took the front panel off, and installed the filters over the intake fans, but under the outer cover. The only concern I have now is cleaning these. I'm hoping that after the one-to-two month interval, I can vacuum the filters externally to clear large debris back out through the intake, and then the next interval I can remove them and wash them under water.


WARNING: Remember, the foam should be low impedance! Any dust filter you install over a ventilation port or fan will impede the flow of air through your device. Fans will spin a little faster, but air flow will be slower. Make sure this doesn't cause any heat issues, and either remove the filter or install more fans if necessary. Inevitably, over time the filters will become clogged and become further impeding, and will require replacement or washing.

Vacuum and dust often.
I know, this is common sense, but I've seen people who just have a million Duster cans and they blow out their computer whenever it starts to make noise. Grinding noises are a very bad sign--this means that something is on or around the fan's journal (which usually has ball bearings), and the fan will most likely fail if not cleaned. Oiling the fan's journals using three-in-one motor oil can help, but the best bet is to keep the fans free from particles beforehand, and replace them when things start to go awry. Rule of thumb: if you have to clean it out more than once every one to two months, you have a dust problem. Also, blowing the dust around can cause a fan assembly to become dirty.

Finally, keeping these computer systems away from sources of dust is a good idea. Major sources of dust include laundry, bedding, and animals and humans.

Shell Script to Parse Command Line Arguments

Problem: I needed a script that took just file names and translated large JPEG's into smaller or thumbnail images. The problem was the convert command, part of ImageMagick, needs the specific output file name.

Solution: The following script.

#!/bin/bash

if [ ! -d Thumbs ] ; then
mkdir Thumbs;
fi

while [ $# -ge 1 ]; do
TARGET=`echo -n "$1" | sed "s/.jpg/t.png/" | sed "s/.JPG/T.PNG/" | sed "s/.jpeg/t.png/" | sed "s/.JPEG/T.PNG/"`;
if [ -e $TARGET ] ; then
echo "Refusing to overwrite $TARGET. ";
else
echo -n "Converting $1 to Thumbs/$TARGET: ";
convert $1 -resize 128x128 Thumbs/$TARGET;

if [ $? -eq 0 ]
then
echo "OK."
else
echo "ERROR: $?"
fi

fi

shift

done
exit 0