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.

Event Barrier

In the above example, a number of threads start at different times with the arrival of each clock event and wait till all threads finish running before the next clock event arrives.

Such barrier can be implemented using various techniques with different level of difficulties. One possible implementation can be found in Joseph Albahari’s Threading in C# where a monitor construct is used to wait on a synchronization object in the main thread after the worker threads are queued.

    lock (workerLocker)
    {
      while (runningWorkers > 0)
        Monitor.Wait (workerLocker);
    }

In each of the worker thread, the number of running workers is decremented when the thread finishes:

    lock (workerLocker)
    {
      runningWorkers--;
      Monitor.Pulse (workerLocker);
    }

And when the running number of workers reaches zero, the monitor exist the wait condition and the main thread continues.

The wait on the locker object forms a barrier in the example above. The method illustrated here is simple and elegant. It can be used to create the barriers needed to synchronize the clock event mentioned earlier.

Threadpooling might not always be the optimal solution though. While the number of threads in a thread pool is typically bounded to a few dozens, it may incur excessive context switching penalties if the majority of the threads are CPU bound. In a computation intensive situation, a fixed number of threads approximating the number of computational cores would be more appropriate (for instance, four threads on a four core CPU).

Here I will show another relatively simple way to construct a barrier where only a predetermined maximum number of threads can reach at a given time. To achieve such a ceiling, a global semaphore is used (in this example three concurrent threads can enter the semaphore):

public class Global
{
    public static Semaphore sp = new Semaphore(3, 3);
}

To simplify coding and shield the programmer from the synchronization mechanism details, I created an IEvent interface and an abstract EventBase as follows:

interface IEvent
{
    void OnEvent(int arg);
}

public abstract class EventBase : IEvent
{
    #region IEvent Members
    public void OnEvent(int arg)
    {
        Global.sp.WaitOne();
        Run(arg);
        Global.sp.Release();
    }
    #endregion

    public virtual void Run(int arg)
    {
    }
}

Users can simply implement their code that needs to block at the barrier by inheriting from EventBase and overridding the Run() method:

public class Event1 : EventBase
{
    public override void Run(int arg)
    {
        Console.WriteLine("Thread {0}, arg {1}", Thread.CurrentThread.ManagedThreadId, arg);
        Thread.Sleep(1000);
    }
}

To illustrate how this barrier implementation can be used considering the following code:

class Program
{
    delegate void MyEvent(int arg);

    static void Main(string[] args)
    {
        IEvent e = new Event1();
        MyEvent m = new MyEvent(e.OnEvent);

        List<IAsyncResult> l = new List<IAsyncResult>();

        for (int i = 0 ; i < 6 ; i++)
        {
          IAsyncResult r = m.BeginInvoke(i, null, null);
          l.Add(r);
        }

        foreach (IAsyncResult r in l)
        {
            m.EndInvoke(r);
        }
    }
}

In the code above, we simulate six concurrent threads that need to be synchronized. The multi-threading is achieved via asynchronous invocation. Because the capacity of the semaphore is set to be 3 in this example and if this code is run on a quad-core machine, you will see that the six asynchronous threads are run in two batches, three at a time. And all the threads are synchronized at the end. Here is the sample output:

Thread 10, arg 1
Thread 11, arg 2
Thread 6, arg 0
Thread 13, arg 4
Thread 10, arg 5
Thread 12, arg 3

Using this approach, the number of concurrently running threads can be precisely controlled by the maximum threads allowed in the semaphore.

#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.

Since I had quite a few unofficial packages installed on my primary PC, I was not quite sure how the upgrade would turn out and I was prepared to see a few gotchas at some point. But the upgrade process was surprisingly smooth (albeit slow since all new versions of the installed packages had to be fetched first), and when the upgrade process is done I was able to boot into the new desktop. The only thing I needed to do was to re-install the CUDA driver (190.18), but this was to be expected since every major kernel updates would require the CUDA driver to be re-installed. I certainly hope that NVidia would make their proprietary binary drivers more robust by detecting kernel changes and reinstall automatically if necessary as opposed to require the end user’s manual intervention.

For my other machine running Ubuntu 9.04, the upgrade was equally smooth. One of the problems I ran into there was due to my VMWare Server installation. As it turned out, there are some issues with the default installation package that came with VMWare Server 2. The problem however can be resolved with Radu’s installation script.

To enable administrative share access from Linux hosts, we need to change the Windows machine’s security policy. My assumption is that you are using Windows XP. You may need to make further changes depending on the version of Windows you are using.

The security policy snap-in is located at

c:\windows\system32\secpol.msc

Select local policies and then Security Options:

Then select sharing and security model for local accounts:

Under the enhanced security scheme, “Guest only: local users authenticate as guests” is chosen. This policy means that administrative network access is treated as if it was done with a guest account and therefore you would get permission denied error when trying to access an administrative share — even though your account has administrative rights locally.

To allow administrative share on Samba network, you can simply select the other option “Classic: local users authenticate as themselves”.

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).

For the type of applications that perform the same task over a large dataset for example,

for (int i = 0 ; i < num ; i++)
{
    //lengthy tasks
}

we could easily break down the for loop evenly into chunks that fit into the number of processors given. And for each of the subsets we could create a new process to perform the desired tasks. For instance, if we were to execute the above for loop in parallel on a duo-core processor, we could re-write each of the loops like the following:

//core 1
for (int i = 0 ; i < num ; i+=2)
{
    //lengthy tasks
}

//core 2
for (int i = 1 ; i < num ; i+=2)
{
    //lengthy tasks
}

By executing the application in separate processes, we eliminated certain race conditions that must be properly handled in a multi-threaded process and thus it is far easier to execute multiple processes concurrently when there is no inter-process communications involved than to handle multi-processing within a process via multi-threading. In a multi-process scenario, the operating system handles the concurrency issue behind the scene whereas in the multi-threading case the application developer must ensure the code regions are thread safe.

The following C# code shows how to dispatch tasks among different processes using asynchronous method invocations. Each process being invoked can identify its order by the extra integer parameter (line 36) passed to it. Thus we only needed to modify the target application to take this extra parameter into account (for instance, in a quad-core system, the first process would process items 1,5,9… and the second process would run items 2,6,10, and so on)

using System;
using System.Diagnostics;
using System.Threading;

namespace MPDispatcher
{
    class Program
    {
        public delegate bool CmdDlg(string fn, string args);

        private bool RunCommand(string fn, string args)
        {
            bool r = true;
            Process p = new Process();

            p.StartInfo.FileName = fn;
            p.StartInfo.Arguments = args;

			Console.WriteLine(String.Format("Starting {0} with arguments {1}. Thread ID: {2}", fn, args, Thread.CurrentThread.ManagedThreadId));
            r = p.Start();
            p.WaitForExit();

            return r;
        }

		public bool DispatchCommand(int numOfThreads, string args)
        {
            bool r = true;

            IAsyncResult[] ars = new IAsyncResult[numOfThreads];
            CmdDlg[] dlgs = new CmdDlg[numOfThreads];

            for (int i = 0; i < numOfThreads; i++)
            {
                dlgs[i] = new CmdDlg(RunCommand);
                ars[i] = dlgs[i].BeginInvoke(args, i.ToString(), null, null);
				Thread.Sleep(100);
            }

            bool finished = false;

			//wait till all processes are finished.
            while (!finished)
            {
                bool t = true;

                for (int i = 0; i < numOfThreads; i++)
                    t = t && ars[i].IsCompleted;   

                if (t) finished = true;

                Thread.Sleep(100);
            }

            for (int i = 0; i < numOfThreads; i++)
            {
                r = r && dlgs[i].EndInvoke(ars[i]);
            }

            return r;
        }

        static void Main(string[] args)
        {
            Program p = new Program();

			if (args.Length < 1 || args[0].ToUpper() == "-H") {
				Console.WriteLine("Usage: MPDispatcher {app name} {app args}");
			} else {
				int numThreads = 4; //use 4 threads
				string argStr = string.Empty;

				for (int i = 1 ; i < args.Length; i++) {
					argStr = String.Format("{0} {1}", argStr, args[i]);
				}

            	p.DispatchCommand(numThreads, argStr);
			}
        }
    }
}

The above code works under Windows and Linux (Mono).

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

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.

Background

Image blur is typically caused by

• Motion (e.g. the relative movement between the camera and the object during exposure)
• Out-of-focus
• Low lighting condition

Other types of image blur may also occur in photography (such as Bokeh). And it is desirable to be able to automatically distinguish desired image blur (e.g. Bokeh caused by camera lens with a shallow depth of field) from un-intended blur (e.g. out of focus).

When reference images (e.g. a series of images with different focus settings) are present, detecting image blur is a relatively simple task. For instance, in passive auto-focus cameras, a series of scene images are captured with progressive focus settings. And the intensity differences are calculated within the same region across these different images. Thus, the image with the highest intensity difference corresponds to the correct focus setting. In Active-focus cameras, image blur detection problem is circumvented by measuring the distance between the lens and the object.

The problem becomes more difficult if we are only given a single image. Since many parameters that we used above in camera auto-focusing are not present in a single image setting, we could not reliably infer image sharpness by the method used in passive auto-focusing as we do not have sufficient knowledge to re-construct the series of images necessary for comparison.

We can however, tell whether an image is in-focus by calculating the intensity differences along the edges in an image. If the calculated intensity is higher than a predefined threshold, we deduce that the image is sharp. And if the calculated intensity is lower than a predefined threshold, we conclude that the image is blurred. So now we shifted the problem to identifying such optimal regions where the intensities are calculated.

Algorithm Overview

In this algorithm, we first use Canny edge detection to obtain the edges in the image. The edges are then parameterized using Hough transform. We then calculate the pixel gradients along the parameterized lines detected and finally we use the gradients to decide whether the image is blurred.

I will discuss some technical and implementation details in the up-coming posts. Stay tuned.