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.

For those who are impatient, the function to perform recursive directory search is here:

#include <sys/types.h>
#include <sys/stat.h>
#include <dirent.h>
#include <errno.h>
#include <vector>
#include <string>
#include <iostream>
#include <boost/regex.hpp>

void GetFileListing(vector<string> &files, string dir, string filter, bool ignoreCase) {
    DIR *d;
    if ((d = opendir(dir.c_str())) == NULL) return;
    if (dir.at(dir.length() - 1) != '/') dir += "/";

    struct dirent *dent;
    struct stat st;
    boost::regex exp;

    if (ignoreCase)
        exp.set_expression(filter, boost::regex_constants::icase);
    else
        exp.set_expression(filter);

    while ((dent = readdir(d)) != NULL) {
        string path = dir;

        if (string(dent->d_name) != "." && string(dent->d_name) != "..") {
            path += string(dent->d_name);
            const char *p = path.c_str();
            lstat(p, &st);

            if (S_ISDIR(st.st_mode)) {
                GetFiles(files, (path + string("/")).c_str(), filter, ignoreCase);
            } else {
                if (filter == ".*") {
                    files.push_back(path);
                } else {
                    if (boost::regex_match(string(dent->d_name), exp)) files.push_back(path);
                }
            }
        }
    }

    closedir(d);
}

I used boost library to perform regular expression matches for file names. If you just want to obtain a listing of all the files, you can do without using the boost library.

The following code snippet demonstrates how to use the function. The results are stored in a vector container passed in. Note that the “filter” parameter needs standard regular expressions (so if you are looking for any files, the expression should be .* instead of just *) to work properly.

The code should be pretty self-explanatory. If ignoreCase is set to true, then the match will be case-insensitive.

vector<string> files;

FileUtils::GetFiles(files,"/tmp", ".*", true);
for (int i = 0 ; i < files.size(); i++) {
    cout << files[i] << endl;
}

Besides installing wp-hooks and jsMath I also installed jsMath fonts so that I don’t have to rely on end users having the correct font installed in order to view the LaTex equations.

Here’s an example (Schwarz inequality):

\[
\left[\int_a^b x(t)y(t)dt\right]^2\leq\int_a^bx^2(t)dt\int_a^by^2(t)dt
\]

The Homepage

Depending on who you ask, you either love Google’s minimalist search home page or prefer a more colorful one like Bing. But we need to remember that the primary goal of a search engine is to perform search. Bing’s home page clearly followed Live’s footstep and as a result the main page is bloated. The home page for Bing comes at 31 Kb while Google’s is just above 4 Kb. (I used wget on both sites and compared the downloaded html, excluding images).

So Bing is at a disadvantage from the start. For the same data pipe size, Google can serve four times as many requests as Bing could. Put it another way: to achieve the same performance, Microsoft would need more resources to compete with Google.

Search Experience

On normal searches, Bing lives largely to the hype generated before its launch. It does a decent job in finding relevant results. Comparing the search results between Google and Bing on the same search terms, they are largely similar in terms of how they rank the pages.

Performance-wise, Bing holds up pretty well in general. But occasionally, you can experience a noticeable delay when returning results. Google on the other hand returns results uniformly fast.

Like its home page, the average size of Bing’s result pages is much larger than Google’s. Bing’s search result page (on search term “test”) is almost 40 Kb in size while Google’s result page remains under 5 Kb.

I often use searches on servers with a slow remote session and Bing would perform poorly compared with Google in such an environment (e.g. large page sizes).

Bing Is No Google

While for the most part Bing gets pretty good search results, I did find some rather poor results from certain search terms.

Try search the word download on Bing, here is the result you get:

I don’t know why the first couple of entries would be for Adobe Acrobat Readers. Google’s first entry points to CNet’s download site, which makes a lot more sense.

Now, try search “C–” on Bing. C minus minus is no where to be found in the results.

If you wanted to find a little more about the TASM assembler, don’t count on it returning top on the list using Bing, even though the related searches contains related information.

The same thing goes for searching chemical compounds. Searching NH3 doesn’t return you any information about ammonia from the main search results.

Last but not least, Bing lacks the versatility interpreting mathematical equations. To calculate 2 to the 100 power for instance, one could use either 2^100 or 2**100. But using Bing, you are limited to only the first form.

So, to me it is doubtful that Bing would be help Microsoft increase its share in search in any significant way at least not in the near future.

Here I will examine a few commonly used method in measuring time intervals under Linux. All of the following timing routines are timed against the same OpenMP parallel for loop (on a quad-core CPU, the parallel for will spawn four concurrent threads).

time()

The time() function returns time with the accuracy to a second. So this function is generally useful for measuring long-running processes.

clock()

In single-core systems, clock() is often used for time measurements. The resolution of this timer is determined by CLOCKS_PER_SEC and is usually a microsecond. Since it determines the number of CPU clock cycles elapsed, it is not particularly useful in measuring time on a multi-core processor system when there are concurrent executing threads as the result of clock() function is the accumulation of CPU clocks across all active CPUs. On a quad-core system, if all cores are at full utilization then the result time is roughly four times the wall time.

gettimeofday()

Similar to the clock() function, gettimeofday() has a resolution up to one microsecond. As the function name suggests, gettimeofday() measures the wall time and thus is suitable for time measurement in multi-core, multi-cpu systems.

rdtsc

The time stamp counter is available on most modern CPUs (since Pentium). There are many implementations based on rdtsc (e.g. on Windows systems, the Win32 API call QueryPerformanceCounter). Implementation based on rdtsc is generally very accurate (with resolution up to one nanosecond) but depending on implementation, its accuracy might be susceptible to CPU clock throttling (common in mobile CPUs). In my implementation below, the rdtsc results are divided by the CPU frequency.

grep “cpu MHz” /proc/cpuinfo | cut -d’:’ -f2

This implementation assumes that CPU frequency remains constant during operations, which could lead to poor accuracy should the CPU frequency change during the measurement. For desktop CPU though, this is less of a concern however.

clock_gettime

Like rdtsc, this function has a nanosecond accuracy and is available on all POSIX compliant systems.

Intel Threading Building Block also provides a timer function tick_count::now() and the time can easily measured using the code snippet below:

    t_start = tick_count::now();
    //statements
    t_end = tick_count::now();
    cout << (t_end - t_start).seconds() * 1000 << " ms" << endl;

The following lists the code for time measuring using the methods mentioned above.

#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <time.h>
#include <ctime>

using namespace std;

void Foo() {
#pragma omp parallel
    {
        for (long i = 0; i < 50000; i++)
            for (long j = 0; j < 50000; j++);
    }

}

unsigned long long rdtsc() {
    unsigned a, d;

    __asm__ volatile("rdtsc" : "=a" (a), "=d" (d));

    return ((unsigned long long) a) | (((unsigned long long) d) << 32);
}

void Time() {
    time_t t1, t2;

    time(&t1);
    Foo();
    time(&t2);

    cout << "time() : " << t2 - t1 << " s" << endl;
}

void Clock() {
    clock_t c1 = clock();
    Foo();
    clock_t c2 = clock();
    cout << "clock() : " << (float) (c2 - c1) / (float) CLOCKS_PER_SEC << " s" << endl;
}

void GetTimeOfDay() {
    timeval t1, t2, t;
    gettimeofday(&t1, NULL);
    Foo();
    gettimeofday(&t2, NULL);
    timersub(&t2, &t1, &t);

    cout << "gettimeofday() : " << t.tv_sec + t.tv_usec / 1000000.0 << " s" << endl;
}

void RDTSC() {
    unsigned long long t1, t2;

    t1 = rdtsc();
    Foo();
    t2 = rdtsc();

    cout << "rdtsc() : " << 1.0 * (t2 - t1) / 3199987.0 / 1000.0 << " s" << endl;
}

void ClockGettime() {
    timespec res, t1, t2;
    clock_getres(CLOCK_REALTIME, &res);

    clock_gettime(CLOCK_REALTIME, &t1);
    Foo();
    clock_gettime(CLOCK_REALTIME, &t2);

    cout << "clock_gettime() : "
         << (t2.tv_sec - t1.tv_sec)  + (float) (t2.tv_nsec - t1.tv_nsec) / 1000000000.0
         << " s" << endl;
}

int main() {
    cout.setf(ios::fixed);
    cout.setf(ios::showpoint);
    cout.precision(5);

    Time();
    Clock();
    GetTimeOfDay();

    RDTSC();
    ClockGettime();

    return (EXIT_SUCCESS);
}

And here is the output from my quad-core computer in debug mode.

time() : 6 s
clock() : 21.85000 s
gettimeofday() : 5.67368 s
rdtsc() : 5.65957 s
clock_gettime() : 5.65894 s

After a quick search on ImageMagick’s site I realized that I was missing the following libraries:

libpng12
libjpeg62

Note, that you might want to use the following commands to find out the exact package names:

sudo apt-cache search libpng
sudo apt-cache search libjpeg

sudo apt-cache search libjpeg
And then use the following commands to install the packages:

sudo apt-get install libpng12-0 libpng12-dev
sudo apt-get install libjpeg62 libjpeg62-dev

Note that after that, you will need to re-configure and re-build the Magick++ library (e.g. ./configure, ./make ./make install) so that Magick++ library can be linked correctly with the above libraries.

I have a lot of important programs on my main PC and I wanted to be extra cautious, so instead of backing up the working harddrive and install Ubuntu 9.04 on top of it, I decided to install it on a new harddrive. This way, I could always fall back to my currently working Ubuntu 8.04 installation should something not working out the way I wanted.

The drive I chose to install Ubuntu 9.04 on was a Western Digital Caviar Black WD1001FALS (1TB). The installation went smoothly and ten minutes later I was able to use the brand new Ubuntu 9.04 desktop.

It took me a while to customize the desktop, install the applications I needed and migrate the data over. But everything pretty much worked out-of-box. And it certainly feels a lot faster than Ubuntu 8.04.

The only minor “glitch” I ran into was my dual sound card setup. As I mentioned in an earlier post, I needed to use a second sound card because my on board Intel sound board does not have a MIDI/Game port. I needed that port to hook up my old MIDI keyboard. After the installation though, the sound playback would only go through the Sound Blaster sound card, not the on board Intel HDA sound card. There are various posts (1,2,3,4,5) suggesting how to fix this issue but unfortunately none of them worked in my case. No matter which sound card I initialized first, I always ended up with the Sound Blaster Live card working but not the on-board Intel sound card. Here is how I fixed it: I removed the Sound Blaster Live card first and booted up with just the on board sound. After making sure that the on board sound worked properly, I plugged in the Sound Blaster PCI card and then everything worked as desired (the sound now comes from the on-board Intel HDA instead of the Sound Blaster card).

As a side note, it seems that WD1001FALS does have some performance advantage over WD6400AAKS (which is the harddrive I run Ubuntu 8.04 on) even though their platter densities are quite comparable (333MB/platter versus 320MB/platter).

Apparently, I do not have enough memory on the server and the large volume of requests caused the main memory and the swap space to fill up quickly. And eventually I got the “out of memory error”. So for the majority of the day (from noon on), the server was pretty much inaccessible. I even rebooted the server a couple of times but the situation did not improve much due to the number of requests I was handling. I had to fine tune some Apache settings and wait till the requests die down… Anyway, I was finally able to login to my own site twelve hours later after the post initially appeared on Slashdot.

Some readers had kindly pointed out that the information I presented was not entirely accurate. I guess that I did not even realize that it is more of a 64bit versus 32bit Windows issue. One would have assumed that the only real difference between the two is the size of the addressable memory. Nevertheless, I was thrilled to hear the kind of nostalgia you have all expressed.

The RC build of Windows 7 (build 7100) has many tweaks over the previous beta build I have (build 7000) and I have not yet played with it long enough to come up with any meaningful conclusions. However, this is not the point of this article. As you might have noticed from the title of this article, I was not about to talk about my experience with Windows 7 (maybe I will write about it later). What I noticed the first thing in Windows 7 is that the DEBUG command is nowhere to be found.

I was just old enough to remember the very early days of DEBUG under MS-DOS. In fact, I was fascinated with such a small and yet powerful tool that came with every version of MS-DOS distribution. the DEBUG command was so powerful that you could do almost anything with your machine with sometimes just a few key strokes.

For a long time, I used DEBUG to learn x86 assembly language and to learn about disk (both floppy disks and harddrives) structures and file systems. And occasionally, I would use DEBUG to edit binary files.

I remembered that I could use commands like

-l 100 0 0 1
-d

to load the boot sector from floppy A and inspect whether the boot sector was infected with any virus and if so, I would find a clean floppy disk and using DEBUG to write its boot sector to the disk that was infected.

And routinely, I would use the following commands to inspect the partition table of my harddrive to make sure that it was free from any infections:

mov ax, 0201
mov bx, 1000
mov cx, 0001
mov dx, 0080
int 13
int 3
-g 100
-d 1000

Remember this one?

jmp ffff:0000

I remembered that someone at my high school used to play the pranks by changing the very first few bytes on floppy disks to EA:00:00:FF and placed the disks in computers in the lab so that whenever someone turned on the computer, it would enter an infinite reboot cycle.

And when CIH stroke in the late nineties, my friends and I would use DEBUG to inspect the virus’s code to see how the instructions could actually be used to cause real physical damage to the hardware.

After Windows came along, I still used DEBUG often. After all, deep inside Windows (up till Windows ME), there was MS-DOS and for years, user were allowed to operate in real mode if they so inclined to. With the advent of Windows 2000 and then later Windows XP people started to forget about DEBUG since the operating system became true 32bit and the DOS prompt became just an emulator. You could still view files and write assembly code within DEBUG, but it was in a protected environment and everything you do was pretty safe and you couldn’t really do anything harmful to the hardware (of course, you could still overwrite sectors in floppy disks if you wanted to).

Ah, those were the good old days. Just like QBasic disappeared from later versions MS-DOS, DEBUG has gradually become obsolete. It remained in Windows Vista, but it is no where to be found in Windows 7. At last, Windows has shed one of its last vintage applications from the MS-DOS era.

The simplest way is to use the mean value of the gray scale image pixel values. As a rule of thumb, we set the low threshold to 0.66*[mean value] and set the high threshold to 1.33*[mean value]. Another way is to use the median color in the gray scale image and uses 0.66*[median value] and 1.33*[median value] accordingly. For typical images, these two methods achieve comparable results.

For example, the following shows the picture of a building along with its histogram (original image from Microsoft Research Digital Image. Please see Microsoft Research Digital Image License Agreement for more information):

Building

Building Histogram

The following shows the edge detection results using Canny algorithm (left image uses mean value auto-thresholding, right image uses median value auto-thresholding) and the results exhibit very little visible differences.

Building (Canny Mean)

Building (Canny Median)

However, for images has non-equalized histogram (see the picture of cloud and its histogram below):

Cloud

Cloud Histogram

Canny Edge detection result based on mean value auto-thresholding is pretty poor (see image on the left below), while edge detection based on median value auto-thresholding achieved much better result (see image on the right below)

Cloud (Canny Mean)

Cloud (Canny Median)

Alternatively, we could have performed histogram equalization on the image first before applying Canny edge detection with mean auto-thresholding:

Cloud Equalized

Cloud Equalized Histogram

And after image equalization, both mean and median value auto-thresholding achieved similar results.

Cloud Equalized (Canny Mean)

Cloud Equalized (Canny Median)

So the Canny edge detection using median value auto-thresholding seems to adapt to different types of images very well (note selecting the median value selection can be thought as equalizing the histogram, except that the pixel values are not changed during such operation).

The following is the code listing for the histogram calculation using IPP (based on the image class I created earlier)

/** @brief Get the min max mean value statistics for the current image
 *   @param min, max, mean: these are output parameters that are passed
 *         back by reference.
 */
void IPPGrayImage::MinMaxMean(float& min, float& max, double& mean)
{
    IppStatus sts;
    IppiSize origImgSize = {_width, _height};

    sts = ippiMinMax_32f_C1R(_imgBuffer, _width * PIXEL_SIZE, origImgSize, &min, &max);
    assert(sts == ippStsNoErr);
    sts = ippiMean_32f_C1R(_imgBuffer, _width * PIXEL_SIZE, origImgSize, &mean, ippAlgHintFast);
    assert(sts == ippStsNoErr);
}

/** @brief Calculate the histogram of the image
 *   @param nLevel: the number of bins in the histogram
 *        levels: this is the optional levels user can pass in (histogram will be then
 *                calculated with these levels instead of the uniform levels by default.
 *   @return an integer array which contains the histogram.
 *   @note the histogram is by default calculated using uniform bins across the color range.
 */
unsigned int * IPPGrayImage::GetHistogram(unsigned int nLevel, float levels[])
{
    IppStatus sts;
    Ipp32f* l = new Ipp32f[nLevel];
    IppiSize origImgSize = {_width, _height};

    unsigned int* bins = new unsigned int[nLevel - 1];

    float minVal = 0, maxVal = 0, stepVal = 0;
    double meanVal = 0;
    if (levels != NULL)
    {
        for (unsigned int i = 0; i < nLevel; i++)
        {
            l[i] = levels[i];
        }
    }
    else
    {
        MinMaxMean(minVal, maxVal, meanVal);
        stepVal = (maxVal - minVal) / (float) nLevel;

        for (unsigned int i = 0; i < nLevel; i++)
        {
            l[i] = minVal + stepVal * i;
        }
    }

    sts = ippiHistogramRange_32f_C1R(_imgBuffer, _width * PIXEL_SIZE, origImgSize, (Ipp32s*) bins, (Ipp32f*) l, nLevel);
    return bins;
}

As I mentioned a few days ago, I installed Ubuntu 9.04 on one of my home machines the day it became available and while no radical new features introduced I liked the improvements over 8.10 and 8.04. Since haven’t tried KDE for a while, I decide to download and install the latest Kubuntu 9.04 on VMWare and give it a try.

Kubuntu’s installation process is as easy as it could be just like installing Ubuntu. It took only a minute or two longer than installing Ubuntu but within 10 minutes I was ready to log in.

What I liked
The new Dolphin file manager is extremely fast and easy to use. I like the the places side bar where you could create shortcuts to your favorite folders. The performance of Dolphin is also much faster than Nautilus in Gnome. For smaller folder sizes (e.g. folders with less than 100 files) there is usually very little noticeable performance issue in either file managers. But with large folders (e.g. folders with a few thousands files), Nautilus becomes unbearably slow. Dolphin seems to have little trouble handling large folders.

I also like the “filter” capability in Dolphin. It makes finding files in folders much easier.

The new KDE application launcher is also very pleasant to use and I think it is certainly a big improvement over KDE 3’s start menu. The main menu usability has almost been my main issue when using GNOME. Even though alternative menus such as Gnome Main Menu and Ubuntu System Panel provide similar functionalities, they lack the polish and stability of KDE’s application launcher.

The overall performance of KDE 4 seems to be on par if not better than that of KDE 3.

What I didn’t like
One of the main reasons the KDE community developed the Plasma desktop was to provide users a richer visual experience. Unfortunately I have never been a big fan of any UI visual sugars. Of course, this is totally a personal preference and opinion seems to be evenly divided within the Linux community–people either loves the new look and feel or think it is too cumbersome. And the borders of default windows are excessively thick which I think it is a waste of screen real estate.

The new task bar is a bit buggy and seems to be too easy to mess up, it would help to have a menu item called “restore to default layout”.

One of the problem I ran into was that Kubuntu somehow couldn’t remember the screen resolution setting under VMWare (by the way, I was using the 64bit version of Kubuntu). And every time after a reboot the screen size got automatically reset to 640×480. I am not sure whether this particular issue is related to just VMWare (6.5.2), but it was very annoying as I had to manually adjust the screen resolution every time. And once the screen resolution is adjusted, font sizes on certain applications got messed up. It seems that the font in Konqueror got scaled up multiple times somehow and looks ridiculously large.

So I guess I will have to stick to my GNOME desktop for a long while…

This kind of enthusiasm is certainly encouraging as Linux matures. And certainly, this kind of enthusiasm is much needed for the open source community in general. Whether it is proprietary software or free software, the community acceptance is definitely key to the success of its future.

I have three systems running on Ubuntu at home right now. My Wordpress server is running Ubuntu 8.04 server (32 bit). One of my working machine is running Ubuntu 8.04 64 bit and the other is running Ubuntu 8.10. For my server, I will stick to the 8.04 as it is an LTS release. But I am thinking of installing the latest Ubuntu desktops onto my workstations in the next couple of weeks…

Update 1 8:00 PM
I have just installed Ubuntu 9.04 using the ISO image I downloaded earlier onto a VM. The installation was made even easier (the time zone is now selected by default). The default installation took just about five minutes. The boot time is also very impressive. It took just about 20 seconds before showing the login screen, which is a big improvement over my 8.04 installation.

Update 2 9:00 PM
Even though a fresh installation might be ideal, I decided to run the update on my Ubuntu 8.10 machine anyway. This is mainly because it was used as a file and VM server and I had done very little customizations on it besides that. So I think the chances of getting a successful upgrade is pretty high. The distribution upgrade is pretty slow though, and it is downloading at about 30k/s right now…

Upgrading from Ubuntu 8.10 to 9.04

Update 3 4/24/2009 7:00 AM
The 8.10 to 9.04 upgrade went surprisingly well. The only problem I had has nothing to do with Ubuntu.

Since the machine I was doing the update on is a file and VMs server, I did not bother attach display or keyboard to it. So when I was doing the update yesterday used an SSH connection and forgot that the updates would need to shutdown SSH and other services in order to install the newer version of the daemons. Anyway, half way through the upgrade, the connection to my server was lost. At first I thought that I could just attach a monitor and keyboard to my server and continue the whole upgrade process. Of course it wouldn’t work since the upgrade process was tied to that particular terminal.

So I had to reboot the machine. For whatever reason, maybe because the machine was only half upgraded, the normal boot does not work and I could not log in via the graphical login screen. I restarted in “safe” mode dropping into a root shell and did a

sudo dpkg –configure -a

And the upgrade process picked up from where it was left at before. This is truly impressive! After the upgrade process finished, I rebooted into the new 9.04 installation:

sudo lsb_release -a

Distributor ID: Ubuntu
Description: Ubuntu 9.04
Release: 9.04
Codename: jaunty

The only thing that did not work after the upgrade was the VMWare Server (which is totally expected as it needs to link to the correct version of libraries). But after a simple re-config, the VMWare Server came back into life.

In my opinion, the above three IDEs all have their strengths and weaknesses depending on what kind of project you are working on. Here are some of my observations.

KDevelop is probably the most comprehensive IDE of the three. This should not come as a surprise as it has been around for more than 10 years and it bas been the de facto development environment for most of the KDE development work. It is very feature rich and you can use it to develop many different types of applications natively out of box (e.g. KDE, GTK+, Qt, wxWidgets, etc). If you are developing GNU style applications, you will benefit from the Automake project type if provides. Besides the vast functionalities KDevelop provides, it is also very fast, efficient and stable.

Nonetheless, KDevelop is not the most intuitive IDE and does not suit small projects (e.g. prof of concept code) well as the initial project setup can be time consuming.

Code::Blocks is a very capable IDE for C++ development as well. It offers many project templates even though it does not offer native KDE project types. This should not be a problem to most people however. Among the features I like the most is that it does not require explicit make file configuration and the build dependencies are inferred by default. This makes it very attractive for rapid prototyping. Debugging under Code::Blocks is also a pleasant experience. It also integrates (at least in the later SVN versions) Valgrind’s MemCheck and Cachegrind, which are very useful for detecting memory leaks and tweaking algorithms for the maximum performance.

The latest stable version of Code::Blocks is 8.02, it is a little dated as a lot of functionalities have been added in the later SVN builds. If you do not require the most stability (I have run into some issues recently), using SVN build should not be a problem. The editor (e.g. syntax highlighting, collapsible regions) is a little bit buggy though and the contextual help does not always work to the level of detail I desired.

NetBeans C++ IDE is probably the most beautiful one among the three. It offers the most detailed syntax highlighting, and can be configured to display class hierarchy and library function information. The refactor tool works pretty well and is certainly a boon to large scale development. Its contextual help is also of top-notch.

All of these come at a cost of course. NetBeans C++ IDE is the most resource intensive among the three. It can easily use 500 MB memory when doing development and can be sluggish at times. It also comes with a very limited project template (e.g. no out-of-box project templates for Qt, wxWidgets). Certain settings are hard to get at as well. Nevertheless, if I am primarily writing back-end code, NetBeans C++ IDE could easily earn my top choice.

Some people like Anjuta and compare it favorably to Code::Blocks. But I haven’t got a chance to use it yet.

So naturally, I wanted to revert back to my previous working version (SVN 5489). There are some instructions on lgp203.free.fr that in theory should work to install any revisions of Code::Blocks from SVN. But the script provided there did not work for me as it was complaining about not able to find certain packages. So I decided to do it manually, and here are the steps I took to get SVN 5489 installed.

First, you will need to remove the installed version of Code::Blocks.

sudo apt-get remove codeblocks
sudo apt-get remove codeblocks-common

Then you will need to install the Debian packages one by one from lgp203.free.fr. using

wget http://lgp203.free.fr/pool/codeblocks/wxsmith-headers_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/libwxsmithlib0_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-headers_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/libcodeblocks0_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-common_8.02svn5489_all.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-contrib_8.02svn5489_amd64.deb
wget http://lgp203.free.fr/pool/codeblocks/codeblocks-contrib-common_8.02svn5489_all.deb

sudo dpkg -i wxsmith-headers_8.02svn5489_all.deb
sudo dpkg -i libwxsmithlib0_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-headers_8.02svn5489_all.deb
sudo dpkg -i libcodeblocks0_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-common_8.02svn5489_all.deb
sudo dpkg -i codeblocks-contrib_8.02svn5489_amd64.deb
sudo dpkg -i codeblocks-contrib-common_8.02svn5489_all.deb

You can find a full list of all the available Code::Blocks’ SVN versions here. Now, I am running version 5489 and everything is working again.

What I have found out over time is that the default IO priorities tend to cause the UI very sluggish when doing heavy IO operations (e.g. copying files between disks, etc.). While this problem is not inherent to Linux (Linux is only the kernel), The default sluggish behavior under heavy IO conditions makes popular Linux distributions (e.g. Ubuntu) less user friendly than it should.

While using ionice can solve this issue, it isn’t very continent as it needs to be manually set every time the user performs heavy IO tasks.

It is true that the performance of the main-stream hard drives/and controllers (e.g. SATA) is partially responsible for the sluggishness of the UI response and higher end disk sub-systems like serial attached SCSI alleviate this problem to a certain degree, for Linux to really go main stream nevertheless, this problem should not be overlooked as SATA is the common disk sub-system almost all main-stream users have.

Since copying large files is such a common task nowadays, why couldn’t we just lower the default IO priority settings instead of relying on user to use ionice? In general, most end users care more about the UI responsiveness than the background disk throughput.

In this article, I will show a simple example of creating a wrapper class using IPP and Magick++. The example I am going to show can be used to calculate the 2-dimensional FFT spectrum of a gray-scale image. This framework can be easily extended to include other algorithms that can be applied to an image using IPP.

Before I show the implementation details, let me first show how easy it is to use the class. The code snippet below shows how to read in an image file, apply 2D FFT with and without a Hamming window and save the results into image files.

    IPPGrayImage *img, *img1;

    img = new IPPGrayImage();
    img->LoadFromFile(IMAGE_FILE);

    img1 = img->Clone();
    img1 = img1->FFT(true);
    img1->SaveToFile(IMAGE_HOME + "/test_fftmag.jpg");
    img1 = img->Clone();
    img1 = img->ApplyHammingWindow();
    img1->SaveToFile(IMAGE_HOME + "/test_hamming.jpg");
    img1 = img1->FFT(true);
    img1->SaveToFile(IMAGE_HOME + "/test_fftmag_hamming.jpg");

And for the following IMAGE_FILE,

Test image used for 2D FFT

Here are the results for FFT spectrum with and without hamming window:

Hamming window applied

FFT spectrum (without Hamming window)

FFT spectrum with Hamming window

The header file for the class is as follows:

#ifndef IPPGRAYIMAGE_H
#define IPPGRAYIMAGE_H

#include <Magick++/Image.h>
#include <Magick++.h>
#include <ipp.h>

using namespace std;
using namespace Magick;

namespace KDW
{
    class IPPGrayImage
    {
    public:
        unsigned int PIXEL_SIZE;

        IPPGrayImage();
        IPPGrayImage(const unsigned int width, const unsigned int height);
        IPPGrayImage(Ipp32f *imgBuffer, const unsigned int width, const unsigned int height);
        IPPGrayImage(const IPPGrayImage& other);
        virtual ~IPPGrayImage();
        IPPGrayImage& operator=(const IPPGrayImage& other);

        void LoadFromFile(string fileName);
        void SaveToFile();
        void SaveToFile(string fileName);

        inline float GetPixel(unsigned int col, unsigned int row) {return _imgBuffer[row * _width + col];}
        inline void SetPixel(unsigned int col, unsigned int row, float clr) {_imgBuffer[row * _width + col] = clr;}

        unsigned int GetWidth() { return _width;}
        unsigned int GetHeight() { return _height;}

        Ipp32f* GetImageBuffer() { return _imgBuffer;}
        Image* GetImage() { return _img;}

        IPPGrayImage* Clone();
        IPPGrayImage* ApplyHammingWindow();
        IPPGrayImage* FFT(bool fftShift = false);
    protected:
    private:
        unsigned int _width;
        unsigned int _height;

        Image* _img;
        Pixels* _view;
        PixelPacket* _pixels;
        Ipp32f* _imgBuffer;
        string _fileName;

        void Init();
    };
}
#endif // IPPGRAYIMAGE_H

And here’s the implementation for the class:

#include <assert.h>
#include <math.h>

#include "IPPGrayImage.h"

namespace KDW
{
    /** @brief Constructor()
     *  Initialize image buffer.
     */
    IPPGrayImage::IPPGrayImage()
    {
        Init();
    }

    /** @brief Constructor(width, height)
     *  Initialize an image size of width x height.
     */
    IPPGrayImage::IPPGrayImage(const unsigned int width, const unsigned int height)
    {
        Init();

        _width = width;
        _height = height;

        int stepByte = 0;
        _imgBuffer = ippiMalloc_32f_C1(_width, _height, &stepByte);
    }

    /** @brief Constructor(imgBuffer, width, height)
     *  Initilize from an Ipp32f buffer (width x height)
     */
    IPPGrayImage::IPPGrayImage(Ipp32f *imgBuffer, const unsigned int width, const unsigned int height)
    {
        Init();

        _width = width;
        _height = height;
        _imgBuffer = imgBuffer;
    }

    /** @brief Copy Constructor
     */
    IPPGrayImage::IPPGrayImage(const IPPGrayImage& other)
    {
        _width = other._width;
        _height = other._height;

        int stepByte = 0;

        _imgBuffer = ippiMalloc_32f_C1(_width, _height, &stepByte);

        for (unsigned int row = 0; row < _height ; row++)
        {
            for (unsigned int column = 0; column < _width ; column++)
            {
                _imgBuffer[column + row * _width] =other._imgBuffer[column + row * _width];
            }
        }

        if (other._pixels == NULL) _pixels = NULL;
    }

    /** @brief Overload =
     */
    IPPGrayImage& IPPGrayImage::operator=(const IPPGrayImage& rhs)
    {
        if (this == &rhs) return *this; // handle self assignment

        return *this;
    }

    /**
     * @brief Destructor
     */
    IPPGrayImage::~IPPGrayImage()
    {
        ippFree(_imgBuffer);
        delete _img;
        delete _view;
    }

    /**
     * @brief Common initialization code
     */
    void IPPGrayImage::Init()
    {
        PIXEL_SIZE = sizeof(Ipp32f);
        _pixels = NULL;
        _imgBuffer = NULL;
        _img = NULL;
    }

    /** @brief Load an image from file
      */
    void IPPGrayImage::LoadFromFile(string fileName)
    {
        _img = new Image(fileName);
        Geometry g = _img->size();

        _width = g.width();
        _height= g.height();

        _view = new Pixels(*_img);
        _pixels = _view->get(0,0, _width, _height);

        int stepByte = 0;
        _imgBuffer = ippiMalloc_32f_C1(_width, _height, &stepByte);

        for (unsigned int row = 0; row < _height ; row++)
        {
            for (unsigned int column = 0; column < _width ; column++)
            {
                PixelPacket *p = &_pixels[column + row * _width];
                Color c = Color(p->red, p->green, p->blue);
                _imgBuffer[column + row * _width] = c.intensity();
            }
        }
    }

    /** @brief Save the current image buffer to file
      */
    void IPPGrayImage::SaveToFile()
    {
        SaveToFile("");
    }

    /** @brief SaveToFile(fileName)
     *  Saves the current image buffer to a file (by file name).
     */
    void IPPGrayImage::SaveToFile(string fileName)
    {
        if (_img != NULL && _pixels != NULL)
        {
            for (unsigned int y = 0; y< _height ; y++)
            {
                for (unsigned int x = 0; x < _width; x++)
                {
                    float clr = (float) _imgBuffer[x + y * _width];
                    _pixels[x+ y * _width] = Color(clr, clr, clr);
                }
            }
            _view->sync();
            _img->syncPixels();

            if (fileName == "")
            {
                _img->write(_fileName);
            }
            else
            {
                _img->write(fileName);
            }
        }
        else
        {
            Image img(Geometry(_width, _height),"white");

            for (unsigned int y = 0; y< _height ; y++)
            {
                for (unsigned int x = 0; x < _width; x++)
                {
                    Color c;
                    float clr = (float) _imgBuffer[x + y * _width];
                    img.pixelColor(x,y, Color(clr, clr, clr));
                }
            }

            img.write(fileName);
        }
    }

    /** @brief Clone
    *   Duplicate the current image to another IPPGrayImage object.
    *   @return an IPPGrayImage pointer to the cloned image
    */
    IPPGrayImage* IPPGrayImage::Clone()
    {
        IPPGrayImage *newImg;

        newImg = new IPPGrayImage(_width, _height);

        int stepByte = 0;
        newImg->_imgBuffer = ippiMalloc_32f_C1(_width,_height, &stepByte);

        for (unsigned int y = 0 ; y < _height ; y++)
        {
            for (unsigned int x = 0 ; x < _width ; x++)
            {
                newImg->_imgBuffer[x + y * _width] = _imgBuffer[x + y * _width];
            }
        }

        return newImg;
    }

    /** @brief Apply Hamming window to the image
     *  @return an IPPGrayImage pointer to the processed image
     */
    IPPGrayImage* IPPGrayImage::ApplyHammingWindow()
    {
        IPPGrayImage *newImg;
        newImg = new IPPGrayImage(_width , _height);
        IppiSize srcImgSize = {_width, _height};

        IppStatus sts;
        int stepByte;
        Ipp32f *imgCache = ippiMalloc_32f_C1(_width , _height , &stepByte);

        sts = ippiWinHamming_32f_C1R(_imgBuffer, _width * PIXEL_SIZE, imgCache, _width * PIXEL_SIZE, srcImgSize);
        assert(sts ==ippStsNoErr);

        for (unsigned int y = 0; y< _height; y++)
        {
            for (unsigned int x = 0; x < _width; x++)
            {
                newImg->_imgBuffer[x+ y * _width] = imgCache[x + y * _width];
            }
        }

        return newImg;
    }

    /** @brief Perform FFT on the image and returns the magnitude component
     *  @param fftShift: if it is true, the the result is with
     *         zero-frequency component shifted to center of spectrum
     *  @return the magnitude FFT component
     */
    IPPGrayImage* IPPGrayImage::FFT(bool fftShift)
    {
        IPPGrayImage *newImg;
        IppiFFTSpec_R_32f *spec;
        IppStatus sts;

        unsigned int n = (int) (logf((float) _width) / logf(2.0f));
        unsigned int m = (int) (logf((float) _height) / logf(2.0f));

        unsigned int N = pow(2, n);
        unsigned int M = pow(2, m);

        if (N < _width)
        {
            n = n + 1;
            N = pow(2, n);
        }

        if (M < _height)
        {
            m = m + 1;
            M = pow(2, m);
        }

        int stepByte;
        Ipp32f *src = ippiMalloc_32f_C1(M , N , &stepByte);
        Ipp32f *dst = ippiMalloc_32f_C1(M , N , &stepByte);
        Ipp32f *mag = ippiMalloc_32f_C1(M , N , &stepByte);

        IppiSize srcImgSize = {_width, _height};
        IppiSize dstImgSize = {N, M};

        sts = ippiCopyConstBorder_32f_C1R(
                  _imgBuffer, _width * PIXEL_SIZE, srcImgSize,
                  src,  N * PIXEL_SIZE, dstImgSize,
                  0,0,0);
        assert(sts ==ippStsNoErr);

        sts = ippiFFTInitAlloc_R_32f(&spec, n , m, IPP_FFT_DIV_BY_SQRTN, ippAlgHintAccurate);
        assert(sts ==ippStsNoErr);

        sts = ippiFFTFwd_RToPack_32f_C1R(src, N*PIXEL_SIZE, dst, N*PIXEL_SIZE, spec, 0);
        assert(sts ==ippStsNoErr);

        sts = ippiMagnitudePack_32f_C1R(dst, N*PIXEL_SIZE, mag, N*PIXEL_SIZE, dstImgSize);
        assert (sts ==ippStsNoErr);

        newImg = new IPPGrayImage(N , M);

        if (fftShift)
        {
#pragma omp sections
            {
#pragma omp section
                {
                    for (unsigned int y = 0 ; y < M/2; y++)
                    {
                        for (unsigned int x = 0 ; x < N/2; x++)
                        {
                            newImg->_imgBuffer[x+ y *N] = mag[x + N/2 + (y + M/2) * N];
                        }
                    }
                }
#pragma omp section
                {
                    for (unsigned int y = 0 ; y < M/2; y++)
                    {
                        for (unsigned int x = N/2 ; x < N; x++)
                        {
                            newImg->_imgBuffer[x+ y *N] = mag[x - N/2 + (y + M/2) * N];
                        }
                    }
                }
#pragma omp section
                {
                    for (unsigned int y = M/2 ; y < M; y++)
                    {
                        for (unsigned int x = 0 ; x < N/2; x++)
                        {
                            newImg->_imgBuffer[x+ y *N] = mag[x + N/2 + (y - M/2) * N];
                        }
                    }
                }
#pragma omp section
                {
                    for (unsigned int y = M/2 ; y < M; y++)
                    {
                        for (unsigned int x = N/2 ; x < N; x++)
                        {
                            newImg->_imgBuffer[x+ y *N] = mag[x - N/2 + (y - M/2) * N];
                        }
                    }
                }
            }
        }
        else
        {
            for (unsigned int y = 0; y< M; y++)
            {
                for (unsigned int x = 0; x <N; x++)
                {
                    newImg->_imgBuffer[x+ y * N] = mag[x + y * N];
                }
            }

        }

        return newImg;
    }
}

The above example showed only the FFT function, but virtually all IPP image routines can be accommodated using the wrapper image class above. Intel IPP utilizes many different data types (e.g. Ipp8u, Ipp16s, Ipp32f etc.), but to provide most of the flexibility and compatibility I chose to use only the 32 bit floating data type. For specific implementations, other data types can be used as well.

So I went to the source code and located the style sheet where the font parameters are set.

To change the default font-size, you will need to modify the following CSS file: [your WordPress install root path]/wp-content/plugins/syntaxhighlighter/syntaxhighlighter/styles/shCore.css. Locate the following class:

.syntaxhighlighter span

{

	margin: 0 !important;

	padding: 0 !important;

	border: 0 !important;

	outline: 0 !important;

	background: none !important;

	text-align: left !important;

	float: none !important;

	vertical-align: baseline !important;

	position: static !important;

	left: auto !important;

	top: auto !important;

	right: auto !important;

	bottom: auto !important;

	height: auto !important;

	width: auto !important;

	line-height: 1.1em !important;

	font-family: "Consolas", "Monaco", "Bitstream Vera Sans Mono", "Courier New", Courier, monospace !important;

	font-weight: normal !important;

	font-style: normal !important;

	font-size: 1em !important;

}

And change the font-size to 1.05em or the size you prefer. Note that this setting is extremely sensitive and typically a 5 percent of increase is enough. Since prefer the Courier font better, I also swapped it with the default “Consolas”.