Variable, file and database cache dependencies extend this capability to allow the user to link the cache to the data source. When the data is modified, and therefore no longer valid, the cache can be automatically cleared. Aside from the fact that it has an affinity for SQL Server 2005, it’s a decent system. However, in my opinion, the key issue is not *when* to cache, but *what* to cache. The theory of data caching is actually based on two concepts, temporal locality AND spacial locality (when one thing is requested, data near it will also soon be requested). ASP.NET puts the burden of spacial locality solely on the shoulders of the developer.

A data access scenario

Here is a typical scenario: a user arrives at a web site, say it’s an e-commerce system. The user searches for “widget”, and gets 500 results for widgets. The user then searches for “widget x” and gets 100 results, finding the item they want in the first page.

Next, the user clicks on widget-x and then views the product’s details, including thumbnails, specifications, and related products. Deciding to look at related products, they click on widget-y, widget-z and widget-v; all of witch show widget-x in their “related items”. The user then returns to the details page for widget-x and adds the item to their shopping cart, and then proceeds to check-out. Checkout is three stages, finally showing a receipt of the user’s order.

Without a data cache, this system could load the product record for widget-x a total of eleven times, depending on how the checkout pages are implemented. Also, product details and related products are loaded twice for the product details page for widget-x and possibly again for the other widgets.

Performance & cache

Even a cursory thought about performance should bring to mind the need for a data cache to avoid unnecessary trips to the database server. However, cache has a lot of knobs and it’s not immediate how and when the data should be cached. The following is a list of variations on how a cache system could be used to minimize the impact of this common user behavior:

And the list goes on. Furthermore, within each one of these methods, there are more detailed options of how to invalidate the cache, and exactly how to key the various bits of cached data. It’s a lot to manage for the developer, and it gets much worse if there is no system-wide plan for a team of developers.

Relational locality

Unfortunately, I’m not proposing a solution, however, I do have some thoughts on a possible approach. I think the cache concept of spacial locality could be extended to relational locality. That is, when a record is accessed, its related records will likely be accessed also. Due to the highly relational nature of relational databases, this type of system should be relatively easy to implement in an automated fashion. The types of cache controls needed would be something like relation-levels to traverse when requesting data.

A radical approach would be to create a pass-through layer where all data requests get sent to a data cache. This cache decides what to pull from the database based on the data requested. In this type of model, the data cache would essentially replace the data access layer. When selecting related data to fetch, two approaches could be taken:

I realize that this type of system requires a major development investment, and may not be practical at this time. However, it seems a smarter and simpler cache system is needed if ASP.NET aims to enable the average developer to create massive web systems out of the box.

Binary Basics

All data in a computer is represented as bits. In VB.NET the Integer type is a 32-bit integer and is represented internally as 32 bits. For example:


Dim i As Integer = 4


Internally, the variable i is represented as the following 32 bits:


Bits: 0000 0000 0000 0000 0000 0000 0000 0100
Index: 31 0


Each bit has an index, starting from 0 at the right and ending with 31 at the left. The value of each bit is 2^x, where x is the bit’s index in the bit string, so the right-most bit (more commonly known as the Least Significant bit) has a decimal value of 2^0 or 1. The left-most bit (or Most Significant bit) has a decimal value of 2^31 or 2,147,483,648.

The value of the number is the sum of all “1″ bits in the string. For example:


[ 0111 ] = 2^2 + 2^1 + 2^0
= 4 + 2 + 1
= 7


VB’s Bit Operators

Visual Basic provides the tools needed to start editing individual bits, namely the “bitwise” logical operators. The following is a list of bitwise operators along with a basic idea of their intended purpose. The first three operators below (And, Or, XOr) enable you to use two bit strings to produce a new third string. The last operator (Not), operates on just one bit string alone.


And - Lets you check for a specific pattern
Or - Turns on a specified pattern, leaving other bits alone
XOr - Chooses one flag or the other, but not both
Not - Inverts all bits (1 becomes 0, and vice versa)


Here are a few examples of two given input strings along with the output created. These examples show what happens conceptually, actual VB code would not have literal binary strings.


1111 And 1010 = 1010
1010 And 0101 = 0000

Not 1001 = 0110
Not 1111 = 0000
Not 0000 = 1111


As mentioned earlier, in real VB code the bit string is hidden in the Integer data type. The bitwise operators can be used to see the actual contents of these bit strings. The first thing we need is a function that displays the bit string of a given Integer.


Sub PrintBinary(ByVal number As Integer)
Dim bpi As Integer = CInt(Math.Log(Integer.MaxValue, 2))

Console.WriteLine()
End Sub


The first line of this code establishes the number of bits in an integer by taking the log base 2 of the maximum integer value, which returns ~30.99 and is rounded up to 31 by CInt.

(Side note: the reason 30.99 is returned instead of 31 is because the max value of a signed integer is actually 1 less than the value of the most significant bit when negatives are implemented using 2’s complement. Understanding this is not critical to the rest of this post.)

Next a loop is created to print out each bit from most significant (left) to least significant (right). Each iteration of the loop, the number is And’ed with the current value of the bit in position i, which is represented by 2 to the i’th power. This integer value of 2^i creates a bit string with only 1 bit turned on (all other bits are set to zero) and is used to test the same bit in the given number by applying the And operator.

If this And operation returns zero, the bit in the i’th position of the given number is off, if it returns non-zero, the bit is on. Below is an trace of the loop showing what is actually happening at the bit level when i=1 and i=2. A call to PrintBinary(4) is assumed.


The number passed in by the user:
number = 4
= 0000 0000 0000 0000 0000 0000 0000 0100

If (number And CLng(2 ^ 2)) > 0 Then
4 And 4 > 0 (?)
= 0000 0000 0000 0000 0000 0000 0000 0100
= 4 '<- Result, True


As shown in the two iterations above, the And operator compares the bits in a string 1-by-1 matched up by index. If the bits are both on, the resulting bit in the i'th position in the new bit string is also on. The final result is returned as an Integer.

This becomes more interesting when using the Or operator to create a number with multiple bits turned on. The key is to use numbers that are an integer power of 2, any other numbers will mangle the bit string. Here is an example of setting 3 bits and passing it to our PrintBinary() function:


' Note that
' 128 = 2 ^ 7
' 4 = 2 ^ 2
' 2 = 2 ^ 1

PrintBinary(128 Or 4 Or 2)
= 0000 0000 0000 0000 0000 0000 1000 0110


Notice how the bit positions match exactly the powers of 2 that were passed to PrintBinary, that is bits 7, 2 and 1 are flipped on.

Real World Bit Strings

In a real application, it is desirable to simplify this process as much as possible; enter enumerations. An enumeration can be used to give names to individual bits and can then be used in a function as a set of flags or options.


Public Enum FileFlags As Integer
Read = 1
Write = 2
Execute = 4
End Enum


Notice that the enumeration values are integer powers of 2, same as above. This enumeration defines 3 flags, Read, Write and Execute. A function can use these flags to indicate how it should operate. This is only appropriate when the flags are not mutually exclusive (meaning more than one flag can be applied at the same time).

To use this enumeration, I have created a dummy function called "SetPermissions". The function is not complete; it is only intended to demonstrate how to read bit flags by using a bit mask.


Sub SetPermissions(ByVal flags As FileFlags)
If (flags And FileFlags.Execute) = FileFlags.Execute Then
Console.Write("X")
Else
Console.Write("-")
End If

SetPermissions(FileFlags.Read Or FileFlags.Write)
=> -RW


What is actually happening is that when SetPermissions is called, the "Or" operator is turning on the Read bit and the Write bit in our bit string. The function then applies a bit mask using the "And" operator to test if each individual flag is set.

A Few Words on Style

Enumerations are preferred when multiple options are available for one specific value. They should not be used when the values are logically disconnected.

Constants can be used instead of enumerations, however, enumerations are preferred when the values logically group together (constants also disable intelisense). The Win32 API is a good example of values that should be grouped when ported to .NET. In the C/C++ headers, all values are represented as individual constants, converting them to an enumeration when porting makes working with the API much nicer.

As always, never under any circumstance should literal numbers be used to create a flag. So-called magic numbers without names will confuse the hell out of anyone working on the code after you have written it - yes, including you . All literal numbers should be given names, either as enumerations, constants, or at the very least in a local variable.

Download the bit string example code for this article.

Although the background and mathematical basis for the algorithm are interesting, I’m only going to discuss them briefly and focus on the implementation and performance issues in .NET. If you are curious about the details behind the algorithm, you should check out the original articles I found.

The Algorithm

To find relative changes in intensity level, the algorithm processes the image one pixel at a time. It looks at the change in intensity to the left and right of the current pixel, stores it and then checks the change in intensity in the pixels above and below the current pixel and stores it as well. The actual process happens one dimension at a time for each pixel (horizontal and then vertical), and then combines the result into two dimensional pixel data, the output image.

As each pixel is encountered, its neighboring pixel’s intensity levels get calculated and then subtracted from the neighbor pixel on the opposite side. The resulting sum of all the pixels is the relative change in intensity at that location. If opposite neighbor pixels are the same color, when subtracted from each other the result will be zero (black). If the two neighboring pixels were radically different intensity levels the output would be greater than zero. The mechanism that averages the pixels is a weighted matrix, one for vertical (the xMask) and one for horizontal (the yMask):

Dim xMask(,) As Single _
= New Single(,) {{-1, 0, 1}, _
{-2, 0, 2}, _
{-1, 0, 1}}

Dim yMask(,) As Single _
= New Single(,) {{1, 2, 1}, _
{0, 0, 0}, _
{-1, -2, -1}}

Each element in the matrices represents a bordering pixel, with the center element being the current pixel. The numbers in each matrix is the weighting of the importance of the pixel at that location, so pixels directly above or beside the current pixel are weighted heavier (denoted above with a 2 instead of a 1) than diagonal pixels. Notice that in both matrices, the current pixel is ignored (set to zero).

For the vertical yMask, the strictly horizontal elements are zero, and the opposite is true for the xMask. The elements of each matrix are multiplied by the border pixels intensity levels, and then the results are summed. Since the opposite sides are also opposite signs, the sum is the change in intensity we were looking for. The final step is to add the absolute value of the horizontal and vertical differences in intensity. This process is actually a rough approximation of the mathematical gradient of the image.

First Implementation: GDI+

To get things started, I wanted to keep the details of working with the image data to a minimum, so I created the algorithm to work with the infinitely slow GDI+ Bitmap object using the GetPixel and SetPixel methods. The implementation is straight forward:

1. Create X and Y loops to scan across
each pixel in the source image
2. Create I and J loops to process the
eight border pixels for the current pixel (X,Y)
3. Get the current border pixel
Intensity(X + I, Y + J) : 1/3 * (R + G + B)
using Bitmap.GetPixel on the source image
4. Multiply the intensity by the appropriate mask
5. Clamp the output value to [0, 255]
6. Write the output pixel value to the output
image (Bitmap.SetPixel)

Below is sample output of the initial implementation:

This process typically runs in about 3K pixels /second, which sounds fast… but actually takes about 160 seconds to process an 800 x 600 pixel image (480K pixels). So for real-time processing, this method is absolutely out. Although it’s very slow, this method works as expected and was useful to me as a reference renderer as I tested new approaches.

Take Two: Direct Pixel Access

The GDI Bitmap object offers a handy function, Lock/UnlockBits(), that returns the raw bytes of memory composing the Bitmap object. By using this function, it is possible to read all pixels in one call, process them, and then write them back in a single call. This is much, much faster than using Get/SetPixel() methods which operate on a single pixel for each read and write. The intense down side of LockBits is that you no longer have friendly access to the pixel by X and Y coordinates, and documentation is pretty bad.
When calling LockBits(), you specify what format you want the data to be returned in. The pixels get returned as a contiguous array of bit data, and you are charged with picking it apart. For my purposes, I’ve forced the format to always be 24 bit RGB. The function returns a one dimensional array of bytes. Each pixel is encoded according to the format specified, so in my case, there are 3 bytes for each pixel (R, G and B). To emulate two dimensions, a “stride” value is given, which lets you know how many bytes there are per line, along with a “height” which is the total number of scan lines. So each pixel can still be accessed with X and Y coordinates by using the following formula:

Pixel.Red = Array[stride * Y + X * 3]
Pixel.Blue = Array[stride * Y + X * 3 + 1]
Pixel.Green = Array[stride * Y + X * 3 + 2]

Notice that the Y value is multiplied by the width of the scan line and X is multiplied by the amount of byte data per pixel, the 3 here is for RGB. The first byte at this location is red, the next byte is green and the last byte is blue, which is why 0, 1 and 2 are added to X.
To make this logic less painful, I created a wrapper class for the bitmap object which has its own GetPixel and SetPixel methods. This class locks the bits on the image when it loads and then operates on the array. It implements IDisposable, and when Dispose is called, it calls UnlockBits on the original bitmap image, committing all changes to the image at once.
This implementation runs at around 50Kp/s, a huge improvement of over the original. Processing the pixels in blocks greatly improved performance, but this is still a little too slow for any real-time application. The 800×600 image still takes about 10 seconds to process with this new method.

Take Three: Divide and Conquer

The next approach I took was to reduce the input data by splitting the image in two. The actual split is done by creating Rectangle objects and then passing these rectangles to LockBits when retrieving the image data.
Since I wanted to test different numbers of splits, it became very important to *neatly* keep track of work units, that is, what part of the image was actually being processed. Also, I had another idea in mind for the next implementation, so I wanted this idea of work units to be reusable. To facilitate this, I created a class called ImageWorkUnit with the following properties:

Image: The input Bitmap which is being processed
WorkArea: The Rectangle of the area to process
Result: The output Bitmap shared by all workers

Using this new work unit class, I then created a method to split the image into multiple work units (the number of units is variable) and then a loop to process each loop sequentially. Right now, stop and make a quick estimate of how fast this new method will run using two units (splitting the image in half). Before I ran this new implementation, I made an approximation of no more than few percent speed increase. I was wrong. This method runs at a blazing 450Kp/s, a vast improvement over the direct pixel access method.
As happy as I was with the result, it was a little disturbing and I decide to do some tests. I varied the number of divisions, and much to my surprise, using only one division it ran at the same speed, 450Kp/s. This implied that the speed increase was not caused by dividing the image, but by something else. Here is the original processing loop:

For y As Integer = 0 To inImg.Height - 1
For x As Integer = 0 To inImg.Width – 1
...
Next
Next

Now here is the new processing loop for the work unit based implementation:

For y As Integer = 0 To area.Height - 1
For x As Integer = 0 To area.Width - 1
...
Next
Next

The speed increase was due to the fact that I was no longer accessing the Height and Width properties of the image (it was also accessed in the body of the loop). It turns out, the Height and Width properties of the Bitmap object are not exactly optimized. By simply not accessing these properties inside the loop, I got a speed up of about 900%.

Take Four: Use the Cores Luke

In the final implementation, I created a new class to spawn separate threads to process the image in parallel. This function gets the processor count, and then splits the image that many times and spawns threads to process the chunks.
Oddly, this method runs at either 500Kp/s *or* around 700Kp/s. The discrepancy is because of the thread scheduler. In the new class I created, I simply spawn threads, fire them off and leave it up to the thread scheduler to pick a core to execute on. If both threads execute on the same core, the result is 500Kp/s, when they happen to run on different cores, the speed up to 700Kp/s occurs. I’m not exactly sure how to get around this in managed code – if you have any ideas, please post a comment and let me know.
So with the fastest algorithm, and my fingers crossed, it can process that 800×600 image in about 0.6 seconds (down from 2.5 minutes), which is actually a reasonable rate for real time applications.
Download the Sobel edge detector code and sample images.

The Goal

The goal of this algorithm is to be able to identify the blobs in the following black and white image.

The first image above is the source image, and the second is the source with each pixel outlined in black and the blobs outlined in red. I will define a blob as a collection of pixels that share any of the 8 possible common borders. Notice that a blob could be defined using only 4 borders (that is, don’t count diagonal boarders), which would change the top two blobs in the example.

The Algorithm

The algorithm is simply going to count the number of pixels in the blob. This could easily be extended to actually collect the pixel locations to create a region. Keep in mind that in this example black pixels are “on” and white pixels are “off”. The basic idea is as follows:

1. To initialize, create a copy of the image, which will
be altered to mark the progress of the algorithm
2. Base Cases
a. If a pixel is off, return zero
b. If a pixel is out of bounds, return zero
3.Recursive Case
a. If a pixel is on
i. Turn off the current pixel
ii. Return 1 plus the sum of all 8 surrounding
pixels

And that’s the entire algorithm.

An Example: BlobSize(6, 1)

An example might help to clear up any confusion. Let’s get the size of the blob located at pixel (6, 1). The following image is a visual representation of what the algorithm is going to do in the first two recursive calls.

Assume our function is BlobSize(x as Integer, y as Integer) and returns an Integer (the number of pixels in the blob), and we are calling BlobSize(6, 1). We go back to the algorithm: step 1, this pixel is on and it is within the boundaries of the image, so we are not at a base case – skip to step 2. Step 2, the pixel is on, so turn it off and then return 1 + the sum of all surrounding pixels, that is:

Return _
BlobSize(5, 0) + BlobSize(6, 0) + BlobSize(7, 0) + _
BlobSize(5, 1) + 1 + BlobSize(7, 1) + _
BlobSize(5, 2) + BlobSize(6, 2) + BlobSize(7, 2)

Notice how each term in the return statement corresponds to a pixel from the 3×3 box in the image above (the 1 being the current pixel). The results from pixels 1, 2, 3, 4, 5, 6, and 7 will all be base cases and return 0 since they are off. But notice that pixel 8 is another recursive case, where it’s surrounding 8 pixels will be tested and the blob will expand. This function will ultimately return 5.
Here is the code for BlobSize():

Private Function BlobSize(ByVal image As Bitmap, _
ByVal x As Integer, ByVal y As Integer) _
As Integer
If x < 0 Or x >= image.Width Or _
y < 0 Or y >= image.Height Then
Return 0
End If
Dim c As Color = image.GetPixel(x, y)
If c.R = 255 And c.G = 255 And c.B = 255 Then
Return 0
End If
image.SetPixel(x, y, Color.White)
Dim size As Integer = 1
For i As Integer = -1 To 1
For j As Integer = -1 To 1
If i = 0 And j = 0 Then Continue For
size += BlobSize(image, x + i, y + j)
Next
Next
Return size
End Function


The Problem

Here is a comparison of the blob size (n) to the number of recursive calls (r):

n | r
---------------
5 | 41
6 | 49
13 | 105
1125 | 9001
1350 | 10801
2925 | 23401

The performance of this algorithm is 8n + 1 or O(n) in Big O notation. This causes a problem because the algorithm is recursive. The problem occurs for larger values of n. On my machine, the upper limit was 26705 recursions on a 196 x 156 pixel, solid black image. At this point the system ran out of stack space and I got a StackOverflowException.

Conclusion

This algorithm will work for images no larger than 3338 pixels on my machine; however the stack space can possibly vary from machine to machine. There are several sneaky tricks that could be done to make it work on larger images, but the bottom line is that this algorithm is not well suited for the task.
Ultimately, you must resort to using calculus to solve this problem with larger image sizes. I will show an implementation using the Gaussian or Laplaceian method some time in the future.

You can download the code and test images for BlobSize() here.

A simple sine wave is composed of 4 basic components: amplitude, frequency, wave length and phase angle. The wave analyzer allows you to add waves to the graph, and then tweak these components to see how it effects the output.

It gets interesting when you add multiple waves and then combine their output. This shows a similar output to what you would see if you had several wave generators hooked up to a string (in real life) and looked at their combined effect.

To get started, first go download the app (or source code). Run the application and then follow these steps to get something like this:



1. Click "Add Waveform"
2. Click "Add Waveform" again to get a second wave
3. Now in the Function Generators window, increase the wave
length parameter of the second wave.
4. You should now see the plot of two waves on the green
screen, to see the sum, click the "Sum All Channels"
button, on the main window
5. To see *just* the sum, go back toe the Function
Generators window and click the "visible" button on
both the waves to hide them


Euler’s method (pronounced Oiler) is one way of doing this, and I will show a very simple example using the following differential equation:

dy/dx = 2x

When solved by integration, the actual solution is:

y = x ^ 2

So that is the value that we want to obtain from the program after it completes. The Euler method requires initial known values for a starting point and then determines the slope of the tangent line at that point in order to find the next *approximate* point on the curve. The initial x, y values can be arbitrary (x=1 and y=1 are used in the example), but it must be a solution to the system – using x=1, y=8 would be bad since x^2=8 is false.

Since this is an approximation, the the final result will always be off by some margin of error (for example, for xMax=2, y should equal 4, since 2 ^ 2 = 4, but when you run this code, you will see that it is off by a small amount). This error is a function of the step size, dx. Smaller step sizes are generally more accurate. In the example below, a step size of 0.01 is used, which results in an error of 0.25% and a step size of 0.005 results in an error of 0.103%.

In the code below, xMax is the ending x-value that will be approximated, dx is the step size, and x & y are the initial known values. The code was written to be run as a console application in VB.NET 2005.


Sub Main()
Dim x As Double = 1
Dim y As Double = 1
Dim xMax As Double = 2
Dim dx As Double = 0.01

Sub Euler(ByRef x As Double, _
ByRef y As Double, _
ByVal dx As Double)
Dim slope As Double = 2 * x
Dim change As Double = slope * dx
y += change
x += dx
End Sub


Here is a sample run:

X , Y -- % Error
...
1.91 , 3.64 -- Error: 0.249%
1.92 , 3.68 -- Error: 0.250%
1.93 , 3.72 -- Error: 0.250%
1.94 , 3.75 -- Error: 0.250%
1.95 , 3.79 -- Error: 0.250%
1.96 , 3.83 -- Error: 0.250%
1.97 , 3.87 -- Error: 0.250%
1.98 , 3.91 -- Error: 0.250%
1.99 , 3.95 -- Error: 0.250%
2.00 , 3.99 -- Error: 0.250%

As you can see from the sample run, the output claims that:

x ^ 2 = y
2 ^ 2 = 3.99

illustrating the approximation error. However, models are not supposed to be exact, they are supposed to be a representation that exhibits behavior similar to the thing your are trying to analyze. Also, there are much better approximation methods (such as Runge-Kutta). You wouldn't want to really use this method to solve the equation in this example, this was just to establish how the concept works. As the complexity of the model grows, this method becomes much more attractive.

This basic framework can be used to model all sorts of neat stuff. Coming up, I will post an example model for a cooling liquid using this method in conjunction with Newton's law of cooling, and then gravity and falling objects.

You can read more about Euler's method here.

After some thought, I reasoned: in order to find the nearest known color, you must get the difference for each known color based on your sampled color. You could do this by looping through each known color in the enumeration Drawing.KnownColor.

Next, you could compare the R, G, and B values (or H, S, V values if that is more appropriate) for the known to the sample. To get the distance, you could either do a simple sum of the absolute differences, or if you are a Man or Woman of science, you would use the RMS (Root Mean Square) value. Finally, you keep the value with the smallest difference and return it.

In my sample code below, I also created a structure for returning the Name, Color and the Distance – this is just a little sugar to help the medicine go down, not really necessary.

Private R As New Random

Return best
End Function