At first I noticed that the database was down, but when I finally got to the console after work, it appeared that the server had crashed for some reason. So naturally, I powered down the server and rebooted. But nothing happened, there was no POST message. At first I thought this was just a temporary glitch of some kind, but after repeated reboot attempts it became apparent that something was seriously wrong. I swapped RAM and CPU and tried a few other tricks but the machine refused to show any sign of life… I guess that somehow the old hand-me-down server had just bit the dust.

I could have just powered back on my old server but since I had intended to upgrade to Ubuntu 10.04 (my old server was running Ubuntu 8.04) I decided to run my server under VMWare for the time being till I get a chance to upgrade my old server to 10.04 first.

I guess I will have to live with my old Pentium III server for a bit longer. But hey, old as it is, it only consumes 40W of power!

Update 8/3/2010
I have switched back to my old server. As I mentioned yesterday, I upgraded the server to Ubuntu 10.04. So everything is back to normal, at least for now…

Luckily, I got a fully equipped hand-me-down Compaq (HP) ProLiant DL360 G2 server and I decided to migrate my website over during the weekend.

Even though this server is a few generations behind, it has dual Pentium III S 1.4 GHz processors, 15,000 RMP SCSI harddrive and 4GB of RAM which is more than plenty to meet my near future needs.

Since my web server was running on Ubuntu Server 8.04, this hardware upgrade also gives me an opportunity to upgrade the OS to the latest version of Ubuntu Server (10.04) which is also an LTS version.

With the new hardware and software, the site should be running rather smoothly for the next couple of years…

… … …
avrdude: Device signature = 0×000000
… … …

Typically when I ran into this problem it was due to loose cable connection and I was able to get past it by reconnecting the ICSP header and try again. But this time, the it seems that no matter how many times I tried the problem remained.

I am pretty sure that chip itself was not damaged as it was sitting in the ICSP board I built all the time and I was able to program it successfully many times minutes before this happened.

Here’s what I have tried and so far had no success:

• rebooted system
• re-seated the IC
• changed -B option to allow more delays
• changed -b option to different baud rates
• tried to use external clock signal from a working ATmega328p

And just to be sure nothing was wrong with either the cable or the board itself, I popped in another ATmega328P and everything worked. So it seems that even though I did not change any fuse settings, and the only command I used was

avrdude -V -F -C avrdude.conf -c duemilanove -p m328p -U flash:w:{hex file})

I guess that somehow the fuse settings had changed and thus the chip stopped responding to the clock signal.

So, it’s time for me to try the high voltage parallel programming method (like this one) to see if my theory was correct.

Following the instructions, I built the shield quickly (not very pretty but serves the purpose nevertheless). The none-standard header spacing was not a big issue as it was easy enough to bend the header pins to achieve the desired spacing (see picture below):

Top view

Bottom View

For the high voltage programming enable 12V supply, I chose to use a simply transistor switch instead of the boost converter:

12V Supply

The drawback of this approach is that the output voltage is not as precise and I had to experiment a little bit to obtain the required HV programming voltage The enable signal comes from the Arduino is around 4.5 V which may not be sufficient to put the transistor in the saturated mode and in my case with a 14 Volt supply, I was able to obtain the required 12 V output. Since the control signal is inverted compared to the original schematic in the article, I had to invert all the digitalWrites to the 12V enable pin to make the program work with my version of the shield.

I used the AVR Fuse calculator to obtain the default fuse settings for ATmega328p:

LFuse = 0×62
HFuse = 0xD9
EFuse = 0xFF

And it brought the “bricked” ATmega328p back to life with the first try! So I guess a parallel mode programmer can come in handy in situations like this.

Google PAC-MAN

I really admire Google’s creativity and it is actually quite impressive to cramp such a game into just 58K of javascript (http://www.google.com/logos/js/pacman10-hp.2.js) and a small PNG file:

Google PAC-MAN (behind the scene)

The standard way of connecting a unipolar stepper motor to the parallel port is to use a Darlington driver such as ULN2003 and there are already many examples out there on how to do this. In this post, I will show you how to build a simple stepper motor driver using discrete MOSFETs.

In the circuit diagram below, you will find that the four power MOSFETs are used as switches for each coil in the stepper motor (the stepper motor I used in this example is a MITSUMI M35SP-9. In theory, any uni-polar stepper motors should work with this circuit). A pull-down resistor is attached to the gate of each MOSFET. This is important as otherwise the interference from the port would prevent the MOSFET from switching reliably.

Controller Circuit

The benefit of using discrete MOSFET is that they can handle extremely high current loads. Using IRFZ22, the coil current can be as high as 10 Amp.

Stepper Motor Controller

The following C code sets the data port (pin 2, 3, 4, 5) to high in order so that the stepper motor would rotate clockwise. If you want the motor to rotate counter-clockwise, simply change the output order to 8,4,2,1.

#include <sys/io.h>

#define PAR_PORT 0x378 

void main()
{
	while (1)
	{
		outb(1, PAR_PORT);
		outb(2, PAR_PORT);
		outb(4, PAR_PORT);
		outb(8, PAR_PORT);
	}
}                                            

Here is the circuit diagram:

An Isolated MOSFET Serial Port Relay Controller

The benefit of using an opto-isolator is that the rest of the controller circuit is totally isolated from the serial port and thus prevents the port from accidentally being damaged by wrong wiring or current surge due to a failed component. And by replacing the drive circuitry from using a BJT to a MOSFET, the switching capability is improved dramatically, making switching higher current load more reliable and more efficient.

Here is a picture of the finished board:

Circuit Board

And here is a simple program that toggles the relay on and off at an interval of 0.5 second.

#include <sys/ioctl.h>
#include <fcntl.h>
#include <stdlib.h>

#define _SERIAL_PORT "/dev/ttyS0"

int main(int argc, char **argv)
{
        int fd, status = 0, cmd = 0;

        if ((fd = open(_SERIAL_PORT, O_RDWR | O_NDELAY)) < 0)  exit(1);

        while(1) {
                if (cmd) cmd = 0;  else cmd = TIOCM_DTR;

                ioctl(fd, TIOCMSET, &cmd);
                ioctl(fd, TIOCMGET, &status);

                if (status & TIOCM_DTR) puts("ON"); else puts("OFF");
                usleep(500000l);
        }

        close(fd);
}

The basic operation principal of a degaussing coil is using a strong and gradual fading magnetic field which has an initial magnetic field many times stronger than the magnetization within the tube (typically in the shadow mask or the supporting frame). To produce such a strong magnetic field, we would need a very strong electromagnet. The simplest way is to find a pre-wound spool of magnetic wire and connect it to an AC source.

I bought a spool of 28 AWG magnetic wire which is roughly 1000ft. The spool has an inner diameter of roughly 1 inch. To increase the inductance of the coil and make it suitable for use with 110V main power, I added a steel rod as the core (the steel rod came from a used printer which was just a tad thinner than 1 inch). Here’s a picture of the degaussing coil I built:

Degaussing Coil

To test the coil, you will have to be careful about the maximum current the magnetic wire coil can carry. Excessive current can cause the coil to melt and possibly burn! If you are unsure about the inductance of the coil, you probably want to use an autotransformer (Variac) and a AC current meter to determine what is the optimal operation voltage for your coil. Or, if you don’t have such tools, you will at least want to add a 100W light bulb between the coil and the power to limit the maximum current. If the light is dim when you power on the coil, then it indicates that your coil has sufficient inductance to operate using 110V AC power. If the light is very bright, you will have to adjust your design (i.e., adding a core with higher permissibility or add more turns to the winding).

If your construct is the same as mine, then the coil can operate at 110V AC with no overheating issue (current is at roughly 0.35 A when connected).

Degaussing Circuit

When degaussing, connect the power and move the coil slowly away from the TV screen to a few feet away in a gradual and circular motion.

Simplest Switch using MOSFET

In this example, the switching capability is achieved by the dielectric nature of MOSFET’s gate. Since the gate is insulated from other device regions, the leakage current is relatively small and thus the capacitor can hold its charge for a relatively long period of time.

When the gate and the positive lead are touched, the relatively small gate capacitor is rapidly charged (dry skin has a resistance of several mega-ohm) and the switch turns on. And when the gate and the ground are touched the gate capacitor quickly discharges and the switch turns off.

But it would have been too early to tell how the future lies for Google’s budding browser platform without first seeing it running on other platforms, particularly on Linux. Although the market share for Linux has been a distant third comparing to Windows and Mac OS (depending on how the market share is calculated the figure goes anywhere between less than 1% to a few percentages), it is a sign of serious commitment when we see the support for Linux finally comes. To be honest, the developer build Chrome for Linux had been around for a while now, but the release of Beta last week was the first official release from Google.

Before I started using it, I wasn’t keeping my hopes very high. I was prepared to experience some glitches as after all it is still in its early Beta stage and comparing to Firefox, Chrome is only in its infant stage. But the result is much beyond my expectations.

The installation process was pretty much flawless. Google provides both Debian and RPM packages (Chrome 4.0.249.30) and installing on 64bit Ubuntu (9.10) was as simple as any other Ubuntu packages. And upon starting for the first time, it offered to import my favorites from my current Firefox installations. Unfortunately, I had my Firefox sessions open at the time, and it was unable to import the settings. But it was easy enough to manually import all my favorites ones I started using it.

My first impression is that the user interface is very pleasant. It is clean, minimal and almost barren. Like the simple design of its homepage, Google wanted to emphasize on the content and rather the shell. This clean design is also a necessity given Google’s intension of a Chrome based web-centric OS. Serving as the desktop surface, every square inch of client usable screen real estate counts. This philosophy virtually dictated every aspect of the Chrome browser. When maximized, borders are gone. The top border was shrunk down further–an other nice touch–as users do not need to move the window when the browser is maximized. Even the status area is not permanently utilized. It only appears when there is message to display.
All of these efforts add up to give users the maximum screen space.

Another well thought behavior was the slight delay when closing tabs. When you have dozens of open tabs, the tab sizes were adjusted dynamically to accommodate the limited screen width. If you try to close these tabs one by one, it would be annoying if you had to constantly adjust your mouse to find the “close” icon of the tab. Google realized this, and designed Chrome such that as long as mouse remains in the tabbing area, the tab sizes do not change. So that closing multiple consecutive windows is a simple matter of multiple mouse clicks, without the need to move or adjust. The tab sizes are only adjusted after a brief delay when the mouse moves out of the “tabbing” area (see screen shot below).

Tab closing behavior

Chrome is also a full-fledged web development environment. It has many handy tools (developer->developer tools menu) you would need to inspect/debug your web pages. It even provides a task manager, listing the resources each web page utilizes. Presumably, being an OS rather than a simple browser means that it has to have a task manager of some sort.

Needless to say, page loading in Chrome is generally noticeably faster than that in Firefox. Fast page loading is extremely important for concurrently loading multiple pages (for example, opening a folder of favorites). If a browser is slow, many pages will time out due to the limited rendering capability of the browser. When I loaded a set of a couple dozen or so sites in both Firefox and Chrome, only a couple of sites failed to load properly in Chrome, where as in Firefox as many as ten sites were timed out.

Sites with Flash also worked flawlessly. While this has less to do with Google than Adobe, supporting Flash out-of-box is certainly a nice thought as users generally assume that a web site should just work, regardless of what plug-in is required.

And of course, Chrome is standard compliant. It passes even the most stringent ACID3 browser test. The only gripe I had was the lack of a bookmark menu icon when bookmark bar is not used. In this case, you will have to open the bookmark manager in order to retrieve bookmarked items.

Remember though, this is only a beta browser and it’s not near its completion by any means. I am sure there would be more pleasant surprises down the pipeline.

Whether or not the Chrome OS lives up to its hype, Chrome as a browser is certainly a serious and credible challenge to Microsoft Internet Explorer and it is here to stay.

After removing the fan rotor you can see the stator and the control circuits. This particular fan is driven by a single chip ATS 277(the data sheet can be found here), which is a complementary output Hall effect latch. It turns on and off the alternate side of the poles depending on the rotor’s position.

The stator of a cooling fan

So, using this Hall effect latch IC, we can build a simply electronic circuit that can be used to detect the polarity of a magnet (the magnetic field has to be strong enough to trigger the sensor due to its limited sensitivity).

Here is the schematics I used to build such a detector:

Magnetic Polarity Detector Schematic

and here is a picture of the detector after it was built.

The assembled detector

When the circuit is powered on, one of the two output will be latched at low and thus the LED connected to that pin will light up:

Activated with one side of the magnet

If the Hall sensor detects a strong enough magnetic field, the original pin with the low output will turn high and the other pin will turn low. Thus the blue LED will be off and the red LED will be turned on (see the picture below, note that the red LED is illuminated albeit it is a little dark compared to the blue one).

Activated with the other side of the magnet

By alternating the polarity of the magnetic field (e.g. use the opposite side of the magnet), the LEDs will alternate between blue and red, depending on the polarity used.

#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <math.h>
#include <iostream>

using namespace std;

bool IsPrime(unsigned long long n) {
	bool r = true;

	for (unsigned long long i = 3; i < sqrt((double) n) + 1; i+= 2)
	{
		if (n % i ==0) {
			r = false;
			break;
		}
	}

	return r;
}

bool IsPalindrome(unsigned long long n) {
	bool r = true;
	char s[30];
	int l = sprintf(s, "%llu", n);

	if (l == 1 && n != 1) {
		r = true;
	} else	{
		for (int i = 0; i < l/2; i++) {
			if (s[i] != s[l-i-1]) {
				r = false;
				break;
			}
		}
	}

	return r;
}

/*
 * usage: palprime [lbound] [ubound]
 */
int main(int argc, char** argv) {
	unsigned long long beginNum = 3;
	unsigned long long endNum = 3;

	if (argc == 2) { // lbound default to 3
#ifdef _WIN32
		endNum = _strtoui64(argv[1], NULL, 10);
#else
		endNum = strtoull(argv[1], NULL, 10);
#endif

	} else if (argc == 3) {
#ifdef _WIN32
		beginNum = _strtoui64(argv[1], NULL, 10);
		endNum = _strtoui64(argv[2], NULL, 10);
#else
		beginNum = strtoull(argv[1], NULL, 10);
		endNum = strtoull(argv[2], NULL, 10);
#endif
	}

        unsigned long long i = beginNum;

        while (i < endNum) {
                char s[30];
                int l = sprintf(s, "%llu", i);

		//length cannot be even as even length palindrome numbers
		//can be divided by 11.
                if (l % 2 == 0) {
                    i = ((unsigned long long) (i / 10)) * 100 + 1;
                    continue;
                }

		if (IsPalindrome(i)) {
			if (IsPrime(i)) {
				cout << i << endl;
			}
		}

                i+=2;

                if (s[0] % 2 == 0) {
                    i+=pow(10, l-1);

		    //leading/ending number cannot be 5
                    if (((int) (s[0] - '0')) + 1 == 5) {
                        i += 2 * pow(10, l-1);
                    }
                }
	}
	return (EXIT_SUCCESS);
}

At first, I was trying to find all the palprimes that can be represented by 64 bit integers. But soon I realized that it would take months to do so using the code above with a quad-core PC (using 4 processes with different ranges). Anyway, here’s the last few palindromic primes less than 10,000,000,000,000:

9999899989999
9999901099999
9999907099999
9999913199999
9999919199999
9999938399999
9999961699999
9999970799999
9999980899999
9999987899999

And here are a few interesting ones:

11357975311
1112345432111
1300000000031
1700000000071
1900000000091
7900000000097
9200000000029
1357900097531

This time, the issue is with cheap capacitors used in some compact fluorescent light (CFL) bulbs. The following photo is taken from the electronic ballast of a CFL that failed during the first year of its use:

Bad Capacitor in CFL electronic ballast

As you can see that the bulging top clearly shows signs of leakage. The capacitor used in this particular CFL is rated 22uf/200V with a maximum operating temperature of 105 degree (Celsius). Under normal conditions, this capacitor should be fine. But with a lot of interior light fixtures that are recessed into the ceiling, the heat generated during normal operation can easily approach this limit and causes the CFL to fail prematurely. Many failed CFLs I had over the past few years exhibited similar capacitor problems. And apparently, the general quality issue of CFLs has been concerning.

It seems to me though that the easiest way to fix this issue is for manufacturers to use electrolytic capacitors with higher operating temperature rating and lower ESR. Since the majority of CFL electronic ballasts utilize only one electrolytic capacitor, the increase in cost should be minimum.

Alternatively, if we “bin” the prime numbers according to the differences (gaps) between two consecutive prime numbers, we would yield another logarithmic distribution: the histogram of such differences will be logarithmic as well.

So, take the following sequence of prime numbers for example:

2, 3, 5, 7, 11, 13, 17, 19, 23, 29…

The distances between the consecutive numbers in the above sequence are:

3-2 = 1
5-3 = 2
7-5 = 2
11-7 = 4
19-17 = 2
23-19 = 4
29-23 = 6

We then calculate the histogram based on the gaps.

Denote the histogram bin index as
\[i = \lfloor\frac{d}{2}\rfloor\]

For the example above, we get the following distributions for H[i]:
\[H[0] = 1, H[1] = 3 H[2]=2, H[3]=1\]

Now we calculate the distribution (H[i]) described above using prime numbers within the following interval (for all prime numbers up to 4,294,967,291):
\[[2^0, 2^{32}]\]

We can obtain the following plot for the histogram (H[i]):

Prime number distribution

To illustrate that the distribution is indeed around a logarithm curve, we take the logrithms of the values for each H[i] and get the following figure:

Prime number distribution

As you can see, the distribution is around a straight line.

Now, two years later after crude oil price peeked and then stabilized amidst the economic turmoil, the main reason for companies from Toyota and GM alike to push for new electric and hybrid vehicles seems to me is to show case their technological capabilities and ride along the buzz generated many years ago when the first generation Prius first hit the road. Using the technologies available to us today and in the immediate future, the advantage in terms of environmental impacts of these alternative vehicles such as the hybrid and electric cars remains unclear. And at their current state, it is doubtful that these alternative drivetrains make any economical sense.

Take electric cars for example. From an environmental point of view, while electrical vehicles by themselves do not generate any greenhouse emissions like their gasoline and diesel counterparts, the manufacturing process of the batteries that go into these EVs are likely to have a high environmental impact. The extraction of precious metals and the creation of some of the chemical compounds that used in these high energy density battery packs are likely to consume more energy than the well established process for engine manufacturing. And much of that energy is coming from electrical power plants that use fossil fuel for electricity generation. The “cleaner” nature of EVs is merely because of the redistribution of pollution over different stages of their life cycles and over different geographic areas.

From an economical stand point, today’s manufacturing processes to produce batteries used in the electrical vehicles remain very expensive and the cost of which constitutes a significant portion of the overall cost of the vehicle. And because batteries must be plugged into the grid for charging, it relies on the cost of electricity in order to make economical sense. It seems funny to me that at a time when people prefer natural gas based heating system and shy away from electrical baseboards due to cost considerations, it would somehow be cheaper to charge the EVs off the grid on a daily basis. We know that the power requirement for the electrical vehicles dwarfs some of the most power hungry household electrical systems. Until we are further removed from fossil fuels in our electricity generation process, the cost saving of using EVs is hardly justified. We are having the illusion of savings due to government subsidy and the lower day-to-day operating expenses. The initial investment buying an EV, however, is likely to be much bigger than that of a traditional gasoline counterpart.

Reliability remains a big concern for EVs and hybrids, particularly for EVs. As I discussed before, given the complexity of the hybrid powertrains and the inherent reliability issues of the battery banks, it remains unknown how the long-term reliability (e.g. over a time span of 20 years) of these EVs compare against that of the more traditional vehicles. So even though electric motors are generally much more reliable than gasoline engines, the current state of battery technology significantly limits the overall reliability of these battery powered vehicles.

Another not-so-obvious problem of EVs is related to the power-hungry auxiliary systems (e.g. Heater, air conditioner, audio amplifier, etc). Using these systems will significantly shorten the advertised range and EVs may have to rely on an alternative power-generating unit (e.g. a regular gas powered motor) to generate the additional power needed while using these auxiliary systems.

To improve EV performance, companies have invested heavily and concentrated on reducing the overall weight of the vehicles by using lighter materials such as carbon fibers for the body frames. If we were to adopt a similar approach in today’s gasoline car manufacturing process and reduce the weight of the vehicles, we would significantly reduce the power requirement and thus be able to reduce the engine sizes and ultimately reduce emissions as well.

So, the long term viability of the current electrical vehicles remains to be seen.

References:

• Chevy volt to get 230 mpg rating
• Slashdot comments on Chevy Volt Rated At 230 mpg In the City
• Electric Vehicles and the Environment
• http://www.typesofenergy.co.uk/electric-vehicles-environment.html
• A Different Take on the GM Volt Announcement
• Chevy Volt (part II): 230 MPG, but at what cost?

Since the database access is using a SQL Server account rather than integrated authentication, in theory the database access code should not be affected by whether I use Forms authentication or Windows authentication in the web application.

However, the problem I ran into was that if I use Forms authentication mode, everything works fine. But if I switch the authentication mode to Windows, I would get the following error message emitted from the data access layer after the application was deployed to the server:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 – Could not open a connection to SQL Server)

What is weirder is that if I tried to use the application locally on the web server after deployment, everything would work fine. And after “touching” the deployed website on the server, the web pages can then be remotely accessed via client browser for a while (10 minutes maybe) but after that the same error would occur again.

So I searched many forums but could not find any conclusive explanations or remedies.

The Not So Satisfying Solution

One of my coworkers took a look at my code and confirmed that there were no coding errors but noticed that I did not have port information in the connection string (Note, even though we use non-standard ports, this has never been necessary). So as he suggested, I plugged in the port number and it worked!

Clearly, I am still as confused as before. The authentication modes differences must have somehow affected the way the connection string is interpreted…

So I followed the instructions given in these two blogs: Install Mono 2.4 on Ubuntu,
Building Mono and MonoDevelop from source on Ubuntu 9.04 64bit to re-install Monodevelop 2.0 and its dependencies from the source.

One thing you will need to pay special attention to is that for the monodevelop-debugger-mdb-2.0 to compile successfully, you will need mono-debugger version 2.4, instead of the latest version 2.4.1. Otherwise you will receive an error on Thread.AbortInvocation as there is a breaking change in mono-debugger 2.4.1 which added a parameter to the method (see mono debugger 2.4.1 change log).

Google Finance Error

This is just the latest one of a string of high-profile outages from large corporations like Google (here’s an other outage less than two months ago) and Microsoft (this outage was on July 3, due to fire at a data center in Seattle).

It certainly does not bode well for those who tout cloud computing. While in theory, larger cloud service providers like Google and Microsoft have the resources and capabilities to make their cloud services much more reliable. In practice, it doesn’t help when the services are down at the most unfortunate time when you need them the most.

I could see some benefits of using cloud computing in some non-essential business scenarios, but I doubt that any business would shift its core applications into the cloud. The reason is quite simple: For the bread-and-butter business applications, we need to know with confidence when the system will be down. When you host your own application, even if you don’t have control over everything (e.g. hardware failure) you at least can control when you implement changes. So while your applications might not be up 99% of the time, you could carefully plan the outage windows for the necessary maintenances to minimize any side effects to the normal business operations.

Of course, there are many other reasons why companies should not en-thrust their core businesses to the cloud. Some of the reasons are physical (e.g. a web service call will always be magnitudes slower than a in-process function call. And Internet speed will always be slower than intranet and significantly slower than memory speed), and some are philosophical. Like Richard Stallman once put it:

“One reason you should not use web applications to do your computing is that you lose control. It’s just as bad as using a proprietary program. Do your own computing on your own computer with your copy of a freedom-respecting program. If you use a proprietary program or somebody else’s web server, you’re defenseless. You’re putty in the hands of whoever developed that software.”

Results

When presented with images that are clear, the algorithm correctly identified most of them (see images below):

Building (Microsoft Research Digital Image)

Street (Microsoft Research Digital Image)

Sky

Flower

The following images illustrate how the original image (top right) is divided into sub regions. Canny detection is performed on each of the sub images.

When performing Hough Transform, I chose to detect up to ten lines in each image, with the following stepping parameter (the detection results are very sensitive to these parameters, the following parameters were chosen based on experiment results):
\[\rho=1, \theta=0.01\]

Out of all the detected lines, a few sections are selected based on line continuity and the calculated average gradients around the detected lines. The following images shows the chosen Hough line segments based on the algorithm.

The table below shows the gradient index calculated within each area (the average of the gradients along all the chosen line segments within a sub-image. The result is scaled by 1000, the scale factor is chosen such that for clear images the resulted index is greater than 1 and for blur images the resulted index is less than 1).

And the sub images are indexed as follows:

The algorithm can also detect images with deliberate blur regions (e.g. Bokeh). The results are illustrated below:

Plant (Microsoft Research Digital Image)

Note that the 0′s in the detection results indicate that within those regions, no lines could be reliably detected and thus those regions are considered blurred.
Generally speaking, when an image contains both blurred and clear regions, some of the indexes will be zero and others will be greater than one.

The following images are detected as blurred, with the detected indexes far less than one.

Boat (Microsoft Research Digital Image)

Candle

Limitations

when image contrast is low, or when objects borders are not clearly defined, the algorithm may have difficulty in distinguishing whether an image is blurred. Take the following two cloud images for instance, the image on the left was correctly classified as a clear image due to the relatively high contrast around the center. But the image to the right was classified as blurred due to its lack of contrast.

Cloud

Cloud

Update (7/12/2010)

A few readers requested the code for calculating gradients. The method I used was quite simple, please see the LineUtils code below:

/*
 * File:   lineutils.cpp
 * Author: kwong
 *
 * Created on June 5, 2009, 8:47 PM
 */

#include "LineUtils.h"

#include <math.h>
#include <stdlib.h>
#include <iostream>
#include <ios>

using namespace std;

namespace KDW {
    const float PI = 3.14159265358979;
    const float Epsilon = 1e-5;
    const float MaxGradient = 1e6;

    LineUtils::LineUtils() {
    }

    LineUtils::LineUtils(const LineUtils& orig) {
    }

    LineUtils::~LineUtils() {
    }

    /**
     * Get the equation parameters for the line that passes through (x,y) and is perpendicular
     * to the line specified by parameters (p0, theta0) in normal form.
     *
     * @param p0 : distance to line from origin.
     * @param theta0 : the slope of p0.
     * @param x : x coordinate of the point where the perpendicular line passes through
     * @param y : y coordinate of the point where the perpendicular line passes through
     * @param &p : the perpendicular line's distance from origin.
     * @param &theta : the slope of p.
     **/
    void LineUtils::GetPerpendicularLineParameters(float p0, float theta0, float x, float y, float &p, float &theta) {
        float x0 = p0 * cos(theta0);
        float y0 = p0 * sin(theta0);

        p = sqrt((x0 - x)*(x0 - x) + (y0 - y)*(y0 - y));

        float a1 = theta0 - PI / 2.0;
        float a2 = theta0 + PI / 2.0;

        //d=|x0 * cos a + y0 * sin a - p|
        float d1 = abs(x * cos(a1) + y * sin(a1) - p);
        float d2 = abs(x * cos(a2) + y * sin(a2) - p);

        if (d1 < d2)
            theta = a1;
        else
            theta = a2;
    }

    /**
     * Get a line segement's coordinates. The segement is centered at x0, y0.
     *
     * @param p : distance to line from origin.
     * @param theta : the slope of p.
     * @param x0 : x coordinate of the segement center.
     * @param y0 : y coordinate of the segement center.
     * @param numOfPoints : the number of coordinate points to collect at either side
     *                      of (x0, y0)
     * @param points[] : returns the x,y coordinates of the points on the line segement in IppiPoint.
     **/
    void LineUtils::GetLineIntervalPoints(float p, float theta, float x0, float y0, int numOfPoints, IppiPoint points[]) {
        if (abs(sin(theta)) < Epsilon) {
            for (int xp = x0 - numOfPoints; xp <= x0 + numOfPoints; xp++) {
                points[(int) (xp + numOfPoints - x0)].x = xp;
                points[(int) (xp + numOfPoints - x0)].y = y0;
            }
        } else if (abs(cos(theta)) < Epsilon) {
            for (int yp = y0 - numOfPoints; yp <= y0 + numOfPoints; yp++) {
                points[(int) (yp + numOfPoints - y0)].y = yp;
                points[(int) (yp + numOfPoints - y0)].x = x0;
            }
        } else if ((abs(theta) > 0 && abs(theta) <= 0.25 * PI) ||
                (abs(theta) > 0.75 * PI && abs(theta) <= PI) ||
                (theta > PI && theta <= 1.25 * PI) ||
                (theta > 1.75 * PI and theta <= 2.0 * PI)) {
            for (int xp = x0 - numOfPoints; xp <= x0 + numOfPoints; xp++) {
                points[(int) (xp + numOfPoints - x0)].x = xp;
                points[(int) (xp + numOfPoints - x0)].y = (int) ((p - points[(int) (xp + numOfPoints - x0)].x * cos(theta)) / sin(theta));
            }
        } else {
            for (int yp = y0 - numOfPoints; yp <= y0 + numOfPoints; yp++) {
                points[(int) (yp + numOfPoints - y0)].y = yp;
                points[(int) (yp + numOfPoints - y0)].x = (p - points[(int) (yp + numOfPoints - y0)].y * sin(theta)) / cos(theta);
            }
        }
    }

    /**
     * Get a line segement's coordinates. The segement is centered at x0, y0.
     *
     * @param points[] : the x,y coordinate of the input points (ordered).
     * @param threashold : the threashold of disconnected points before a line is considered no
     *              longer connected.
     * @param lpoints[] : the x,y coordinates of the points in the detected longest connected line.
     * @param &maxLen : the maximum length of the output array, addtional line points
     *                  will be discarded if exceed this limit.
     **/
    void LineUtils::GetLongestConnectedLinePoints(IppiPoint points[], int len, int threshold, IppiPoint lpoints[], int &maxLen) {
        int maxIndexEnd = 0, curRunLength = 0, maxRunLength = 0;

        lpoints[curRunLength] = points[0];

        for (int i = 1; i < len; i++) {
            //if ((abs(points[i].x - points[i - 1].x) > threshold) || (abs(points[i].y - points[i - 1].y) > threshold)) {
            if ((abs(points[i].x - lpoints[curRunLength].x) > threshold) || (abs(points[i].y - lpoints[curRunLength].y) > threshold)) {
                //if (curRunLength > maxRunLength) {
                if (curRunLength > maxRunLength) {
                    maxRunLength = curRunLength;
                    maxIndexEnd = i;
                }
                curRunLength = 0;
                lpoints[curRunLength] = points[i];

                //}
            } else {
                if (curRunLength >= maxLen) {
                    maxRunLength = maxLen;
                    break;
                }

                curRunLength++;
                lpoints[curRunLength] = points[i];
            }
        }

        for (int i = maxIndexEnd - maxRunLength - 1; i < maxIndexEnd; i++) {
            if (i - (maxIndexEnd - maxRunLength) - 1 < maxRunLength) {
                lpoints[i - (maxIndexEnd - maxRunLength - 1)] = points[i];
            }
        }

        maxLen = maxRunLength;
    }

    bool LineUtils::GetMinMaxIndicies(float pixels[], int len, int &minIndex, int &maxIndex) {
        bool isEdge = false;
        bool isPositive = true;

        int numCrossings = 0;

        minIndex = 0;
        maxIndex = 0;

        float avg = 0;

        for (int i = 0; i < len; i++) {
            avg += pixels[i];
        }

        avg = avg / (float) len;        

        if (pixels[0] > avg)
            isPositive = true;
        else
            isPositive = false;

        for (int i = 0; i < len; i++) {
            if (pixels[i] < pixels[minIndex]) {
                minIndex = i;
            } else if (pixels[i] > pixels[maxIndex]) {
                maxIndex = i;
            }

            if (isPositive && pixels[i] < avg) {
                isPositive = false;
                numCrossings++;
            } else if (!isPositive && pixels[i] > avg) {
                isPositive = true;
                numCrossings++;
            }
        }

        if (numCrossings < 3)
            return true;
        else
            return false;
    }

    float LineUtils::CalculateGradient(IppiPoint points[], float pixels[], int len, int minIndex, int maxIndex) {
        float lAvg = 0;
        float hAvg = 0;

        if (minIndex > 0 && minIndex < len - 1) {
            lAvg = (pixels[minIndex] + pixels[minIndex - 1] + pixels[minIndex + 1]) / 3.0;
        } else if (minIndex > 1) {
            lAvg = (pixels[minIndex] + pixels[minIndex - 1] + pixels[minIndex - 2]) / 3.0;
        } else if (minIndex < len - 2) {
            lAvg = (pixels[minIndex] + pixels[minIndex + 1] + pixels[minIndex + 2]) / 3.0;
        } else {
            lAvg = pixels[minIndex];
        }

        if (maxIndex > 0 && maxIndex < len - 1) {
            hAvg = (pixels[maxIndex] + pixels[maxIndex - 1] + pixels[maxIndex + 1]) / 3.0;
        } else if (maxIndex > 1) {
            hAvg = (pixels[maxIndex] + pixels[maxIndex - 1] + pixels[maxIndex - 2]) / 3.0;
        } else if (maxIndex < len - 2) {
            hAvg = (pixels[maxIndex] + pixels[maxIndex + 1] + pixels[maxIndex + 2]) / 3.0;
        } else {
            hAvg = pixels[maxIndex];
        }

        float h = hAvg - lAvg;
        float t = abs(h / (float) (points[maxIndex].x - points[minIndex].x));

        if (t > 0)
            return t > MaxGradient ? MaxGradient : t;
        else
            return MaxGradient;
    }

    float LineUtils::GetAverage(float gradients[], int count) {
        int zerosCount = 0;
        int minValIndex = 0, maxValIndex = 0;

        for (int i = 0; i < count; i++) {
            if (gradients[i] == 0)
                zerosCount++;

            if (gradients[i] > gradients[maxValIndex])
                maxValIndex = i;
            else if (gradients[i] < gradients[minValIndex])
                minValIndex = i;
        }

        gradients[minValIndex] = 0;
        gradients[maxValIndex] = 0;

        zerosCount += 2;

        if (zerosCount < 6) {
            for (int i = 0; i < count; i++) {
                if (gradients[i] > gradients[maxValIndex])
                    maxValIndex = i;
                else if (gradients[i] < gradients[minValIndex])
                    minValIndex = i;
            }
        }

        gradients[minValIndex] = 0;
        gradients[maxValIndex] = 0;

        zerosCount += 2;

        if (zerosCount < 6) {
            for (int i = 0; i < count; i++) {
                if (gradients[i] > gradients[maxValIndex])
                    maxValIndex = i;
                else if (gradients[i] < gradients[minValIndex])
                    minValIndex = i;
            }
        }

        gradients[minValIndex] = 0;
        gradients[maxValIndex] = 0;

        float r = 0;
        zerosCount = 0;
        for (int i = 0; i < count; i++) {
            if (gradients[i] > 0) {
                r += gradients[i];
                zerosCount++;
            }
        }

        if (zerosCount == 0)
            return 0;
        else
            return r / (float) zerosCount;
    }
}

Gradient Calculation

If you remember how the Hough parameters were determined (in polar form, see figure below), it is not difficult to obtain the pixel coordinates centered around the points on the detected line.

Region selection for gradient calculation

In fact, we can formulate a line that is perpendicular to the line section detected during Hough transform, and use the line section that is within a predefined region (e.g. the between the dotted lines) to calculate the gradients of luminance. The following code snippet shows how the perpendicular line’s parameters are obtained.

    /**
     * Get the equation parameters for the line that passes through (x,y) and is perpendicular
     * to the line specified by parameters (p0, theta0) in normal form.
     *
     * @param p0 : distance to line from origin.
     * @param theta0 : the slope of p0.
     * @param x : x coordinate of the point where the perpendicular line passes through
     * @param y : y coordinate of the point where the perpendicular line passes through
     * @param &p : the perpendicular line's distance from origin.
     * @param &theta : the slope of p.
     **/
    void LineUtils::GetPerpendicularLineParameters(float p0, float theta0, float x, float y, float &p, float &theta) {
        float x0 = p0 * cos(theta0);
        float y0 = p0 * sin(theta0);

        p = sqrt((x0 - x)*(x0 - x) + (y0 - y)*(y0 - y));

        float a1 = theta0 - PI / 2.0;
        float a2 = theta0 + PI / 2.0;

        //d=|x0 * cos a + y0 * sin a - p|
        float d1 = abs(x * cos(a1) + y * sin(a1) - p);
        float d2 = abs(x * cos(a2) + y * sin(a2) - p);

        if (d1 < d2)
            theta = a1;
        else
            theta = a2;
    }

In an ideal situation, the gradient of the line points obtained via the method above looks like the figures below, where the edges are clearly identified.

Edge (dark to bright)

Edge (dark to bright to dark)

Sometimes, when the lighting condition is poor, the image would appear to be “grainy”, which sometimes led to poor line detection. For instance, the following figure shows the the gradient when the region around the detected edge is grainy:

None-Edge

We use the number of times the luminance increases above or decreases below its mean along the perpendicular line interval as a measure of whether we accept the detection results as gradients or not. Typically when such number of crossings is less than 3 (see the first two images above) the curve is either monotonic or has a single peak, we assume that gradients can be correctly calculated and if the crossings are more than 3 we discard the results. The gradient is calculated as the slope of the curve. In the examples above, we used ten pixels on each side of the Hough line to calculate gradients.

Image Regions

For images with complex contents, it becomes difficult for the Hough transform to reliably identify line structures within the image. Future more, certain photography techniques (i.e. Bokeh) leave portions of images deliberately blurred. Without dividing image into different sub-regions, the classification results would be compromised.

Thus, images are divided into 9 (3×3) sub-images after Canny edge detection, and Hough transform is performed against each sub-images. The figure below illustrates how an image is divided:

Image divided into 3x3 sub-images (Microsoft Research Digital Image)

This technique is especially useful when portions of images are deliberately blurred, like the image shown above. It also helps the line detection accuracy when the image contains complex scenes. By dividing up the image, each sub area’s complexity is greatly reduced. Other methods in scene separation might achieve even better results, but it is out of the scope for our discussion here.

In my next post, I will show some results obtained from using the method mentioned in this and the previous articles and will also discuss its limitations.

Experience tells us that blur images tend to contain less details then their sharper counterparts. And the areas where intensity transitions occur (e.g. the border of an object) are more well defined in clear images. Mathematically speaking, the slope of the intensity transition is statistically deeper in clear images than blur ones. Since whether an image is blurred or not is not affected by color space, it is sufficient to perform detection in the luminance space (i.e. gray scale images):

\[I=0.299R\times0.587G\times0.114B\]

Canny Edge Detection

Thus the very first step in deciding whether an image or an area within an image is blurred is to use some sort of edge detection algorithms to obtain a collection of the edges in the image.

Canny edge detection is a good candidate since it is optimal in terms of good detection and localization. And hysteresis is used to reduce streaking and thus Canny edge detection achieves relatively continuous edge boundaries comparing to other edge detection methods.

In one of my previous posts, I discussed Canny edge detection using auto thresholding utilizing Intel’s Integrated Performance Primitives (IPP). I used the same algorithm here for the image pre-processing process.

Hough Transform

In order to analyze the gradients along detected edges, it is necessary to first parameterize them. Hough transform comes in handy for this task.

While Hough transform is capable of identifying arbitrary shapes, for the purpose of detecting image blurs simple line detection is more robust. Besides, IPP has an implementation for line detection using Hough transform out of the box.

Since our goal is to determine the quality of the image within a region of interest, we do not need to analyze all the edges identified within that region. But rather, we could select a few based on some pre-determined criteria that would maximize our ability to correctly determine the luminance gradients.

The following code snippet shows my implementation of the edge parameterization method using IPP:

    bool CompareIppiPoint(IppiPoint &p1, IppiPoint &p2) {
        if (p1.x == p2.x) {
            return p1.y < p2.y;
        } else {
            return p1.x < p2.x;
        }
    }

    void IPPGrayImage::HoughLine(IppPointPolar delta, int threshold, int maxLineCount, int* pLineCount, IppPointPolar pLines[], list<IppiPoint> pList[]) {
        IppStatus sts;
        IppiSize roiSize = {_width, _height};

        int bufSize;
        sts = ippiHoughLineGetSize_8u_C1R(roiSize, delta, maxLineCount, &bufSize);
        assert(sts == ippStsNoErr);
        Ipp8u * pBuf = ippsMalloc_8u(bufSize);

        Ipp8u *imgBuf;
        int stepSize;
        imgBuf = ippiMalloc_8u_C1(_width, _height, &stepSize);

        sts = ippiConvert_32f8u_C1R(_imgBuffer, _width * PIXEL_SIZE, imgBuf, _width, roiSize, ippRndNear);
        assert(sts == ippStsNoErr);
        assert(imgBuf != NULL);

        sts = ippiHoughLine_8u32f_C1R(imgBuf, _width, roiSize, delta, threshold, pLines, maxLineCount, pLineCount, pBuf);
        assert(sts == ippStsNoErr);

        //d=|x0 * cos a + y0 * sin a - p|
        int val = 0;
        float d;
        for (int x = 0; x < _width; x++) {
            for (int y = 0; y < _height; y++) {
                if (imgBuf[x + y * _width] > 0) {
                    val = imgBuf[x + y * _width];

                    for (int i = 0; i < *pLineCount; i++) {
                        d = abs((float) cos(pLines[i].theta) * (float) x + (float) sin(pLines[i].theta) * (float) y - abs(pLines[i].rho));
                        if (d < threshold) {
                            IppiPoint p;
                            p.x = x;
                            p.y = y;

                            pList[i].push_back(p);
                        }
                    }
                }
            }
        }

        for (int i = 0; i < *pLineCount; i++) {
            pList[i].sort(CompareIppiPoint);
        }

        ippsFree(pBuf);
        ippiFree(imgBuf);
    }

Note that the selection for delta is crucial for the line detection quality. In the code above, up to maxLineCount number of lines are detected and each line’s parameters are stored in pLines[]. The edge image pixel coordinates within a given range that is less than threshold are collected into the list. Because the Hough detection does not indicate the begin and the end point of a line, we need to iterate through the pixels in pList[] and find the sections that the detected lines pass through. The image below illustrates how the edge regions are chosen based on detected line parameters. Image features within a region between the dotted line are recorded based on the distances to the line defined by:
\[d=\vert x_0cos\alpha+y_0sin\alpha-p\vert\]

Region selection for gradient calculation

In practice, for each parameterized line I chose to select the longest section where the line approximates a section of the edge. Other line sections can be used as well, but the longest portion tends to offer better classification results. The code is shown below, and the thickened section in the figure above illustrates the selected section.

    void LineUtils::GetLongestConnectedLinePoints(IppiPoint points[], int len, int threshold, IppiPoint lpoints[], int &maxLen) {
        int maxIndexEnd = 0, curRunLength = 0, maxRunLength = 0;

        lpoints[curRunLength] = points[0];

        for (int i = 1; i < len; i++) {
            if ((abs(points[i].x - lpoints[curRunLength].x) > threshold) || (abs(points[i].y - lpoints[curRunLength].y) > threshold)) {
                if (curRunLength > maxRunLength) {
                    maxRunLength = curRunLength;
                    maxIndexEnd = i;
                }
                curRunLength = 0;
                lpoints[curRunLength] = points[i];
            } else {
                if (curRunLength >= maxLen) {
                    maxRunLength = maxLen;
                    break;
                }

                curRunLength++;
                lpoints[curRunLength] = points[i];
            }
        }

        for (int i = maxIndexEnd - maxRunLength - 1; i < maxIndexEnd; i++) {
            if (i - (maxIndexEnd - maxRunLength) - 1 < maxRunLength) {
                lpoints[i - (maxIndexEnd - maxRunLength - 1)] = points[i];
            }
        }

        maxLen = maxRunLength;
    }

In my next post, I will continue with the gradient calculation and some methods to enhance the detection accuracies.