The Short Description:

Here you have it: the largest, most complex programming project now available on tannerhelland.com. Originally a final project for a university bioinformatics course, my artificial life simulator has now been completely retooled as a full-blown lesson in evolution and population genetics.

As with most artificial life simulators, a set of simple artificial creatures compete for limited resources.  Each creature has a strand of pseudo-DNA that determines three basic attributes: size, speed, and range (how far it can see).  When the little critters reproduce (asexually… unfortunately), mutations may occur.  Over time, this can lead to remarkable changes in gene frequency throughout the population.  Typically the creatures with a balance of speed and range tend to win out over bigger, slower creatures and smaller, faster ones.

The code is well-optimized, so it should run decently on any hardware.   As a bonus, the simulator can be surprisingly addicting – my longest simulation to date ran for over 500,000 cycles before all the creatures died.  For further analysis of a particular simulation run, all data can be saved to a tab-delimited text file compatible with any major spreadsheet software.

The Long Description:

As you can imagine, a project of this magnitude warrants a fair amount of documentation.  I am currently working on a “how to use this software to teach evolution and population genetics” tutorial that educators – or anyone interested in biology – can read to see how things like genetic drift, population equilibrium, the “bottleneck” effect, and other aspects of a small, closed population work.

Unfortunately, a document like that takes some time to create… so rather than holding off until I’ve finished it, I’ve decided to upload the project for people to start playing with.  If you have any comments or questions, let me know and I’ll see if I can’t work answers into the final version of the tutorial.

(If you’d like to be notified when the documentation is finished, please let me know via the contact form.  I plan on sending out an email once all updates have been posted.)

Download Artificial Life Simulator Code and Executable (38 kb)

Anaphase, courtesy of Lothar Schermelleh

Today’s project is something new to this site – some bioinformatics code!  I feel a tad ridiculous that it’s taken me so many years to post code related to my field, but hey – better late than never.  (That seems to be a recurring theme around here…)

First, a primer.  If you don’t know what the title of this article refers to, here are some Wikipedia links to get you started:

Hidden Markov models (including some examples in Python)

Viterbi algorithm / Viterbi paths (including even more Python examples)

CpG islands

As a bonus, I’m including sections from my original write-up on this program (it began as a university project) in hopes that they’ll shed some light on how the code works and what its potential usefulness is.

The algorithm implementations are quite fast, and the visual feedback is an excellent addition (IMO). Full source code and a sample executable are provided, as well as a FASTA file with data from chromosome #1 in the human genome (bases 6000-12000, I believe).

Download HMM / Viterbi / Sliding Window / CpG Analysis Code (33 kb)

(FYI, my original lab assignment link is here: http://dna.cs.byu.edu/bio465/Labs/hmm.shtml.  It contains quite a bit of helpful information and links if you’re looking to write your own HMM implementation.)

INTRODUCTION

CpG islands are regions of DNA characterized by a large number of adjacent cytosine and guanine nucletoides linked by phosphodiester bonds. Additionally, CpG islands appear in some 70% of promoters of human genes (40% of mammalian genes). Unlike CpG sites in the coding region of a gene, in most instances the CpG sites in CpG islands are unmethylated if genes are expressed. This observation led to the speculation that methylation of CpG sites in the promoter of a gene may inhibit the expression of a gene. (Wikipedia, retrieved Feb 2007)

In this project, I was particularly concerned with generating an accurate Hidden Markov model to define the relationship between normal states (B) and island states (I) within a region of the human chromosome. Such an implementation is useful for gene finding, as CpG islands tend to appear near the promoters of important mammalian genes. The automation of this process is critical because such islands are impossible to locate by simply looking at a strand of DNA (they may cover several hundred bases and their C/G content may be only slightly higher than expected values).

PROCEDURE

I opted to code this project in the Microsoft Visual Basic 6.0 programming language. I believe this implementation is highly appropriate, as I can quickly generate both graphs for visualization and a simple, easy-to-modify GUI (since finding CpG islands can require a lot of trial-and-error using different parameters, and this is not conducive to a command-line program). VB6 is excellent for quickly assembling GUIs, and for algorithms of this nature its speed is comparable to that of a raw C++ implementation.  (BTW, if you are a Linux user please note that this project works flawlessly under Wine 1.1.27, and likely earlier versions as well.)

I will refer to the following image as I walk through my implementation of a HMM.

Step 1: Loading a FASTA file
This routine isn’t of much interest, except to mention a programming quirk particular to VB6. A, C, G, and T entries from the FASTA file are reassigned into a byte array as the numbers 0, 1, 2, and 3. In VB6, number comparison and processing is generally faster than string comparison and processing. (To any VB experts reading this – please note that I am aware of mechanisms for overcoming this, but the fact of the matter is that I prefer working with byte arrays. :)

Step 2: HMM Parameters
As per the lab specifications, the user can change 14 HMM-related parameters. Additionally, I have chosen to add an option to let the program estimate the eight state probabilities. This is a trivial operation, but it seems to markedly increase the accuracy of the algorithm. The estimation of A, C, G and T’s being emitted in a B state is computed by the percentage of occurrences of each of these entries in the original FASTA data. I predict that given the low percentage of I states in a length of DNA, this method of estimating emission probabilities is likely quite accurate. Once those categories have been determined, the I state probabilities are computed by doubling the C and G probabilities and halving the A and T probabilities.

Step 3: The HMM and Viterbi algorithms
This step begins by moving all HMM parameters into look-up tables. The logs of these values are pre-calculated, allowing us to add them (instead of multiplying) for future HMM calculations.

Next, all HMM probabilities are calculated and stored.

This is followed by a 2nd loop backward through the data while calculating all data necessary for the Viterbi algorithm. (Note: this is not necessarily the most efficient way to do this, but the speed difference is negligible for sequences less than 100,000 bases long.)

After all Viterbi data has been pre-calculated, the traceback part of the Viterbi algorithm becomes extremely fast. (Another note: execution speed of this chunk of code is slightly reduced because I translate the states into a string and display that string in the textbox in the upper-right of the program window. This is mainly for convenience and/or to satisfy my curiosity.)

Step 4: The Sliding Window
This step is one where I felt a proper GUI was essential. I have chosen to display two graphs; the top graph displays raw counts of C and G occurrences as compared to the expected value (where 0.5 is used as the expected ratio). The bottom graph displays the ratio of I and B states, and it is this data that is used to recommend the location of any CpG islands.

A noteworthy shortcoming of this implementation is that it is designed to only find the most probable CpG island (instead of multiple islands). In a more formal implementation, returning any/all potential CpG island locations would be more useful.

(And for the record, this step is my favorite part of the program. I find it to be well-implemented and surprisingly graphically pleasing for a bioinformatics tool. :)

RESULTS
By my estimation, the program’s most accurate CpG prediction for this FASTA file is bases 2018-2045 (which corresponds to bases 6018-6045 in the original data, I believe). If you run the program yourself, you will find that most of its estimates fall around this range. Adjusting the sliding window doesn’t have tremendous effect on the estimates, although larger windows will result in larger CpG island predictions (not surprising). The percentage of I states varies dramatically; certain parameters result in levels as high as 30-40% while others are less than 5%. For my best estimate (above), the percentage of I states was 22%.

Finally, code execution is swift – typically a matter of seconds – and if the text display in the top-right is disabled the program runs more-or-less instantaneously on modern hardware.

"Antiquified" version of a BBT promo photo

I’m guessing you’ve seen this style of image before – a sort of pseudo-antique filter than can make any photo look like it was taken with a very old camera (or even a daguerreotype – how’s that for a cool word?).  There are many ways to programmatically generate images like this, and in this article I’ve put together one that does more than just make the image look “brown.”  This filter involves several steps (fading, multiplicative brightness, and gamma correction, among others) and results in a conversion that not only adds a sepia coloring, but also gives an image a histogram more in keeping with older photos.

As with all graphics code on this site, the algorithm is fast enough to be applied in real-time.  Full source code and a sample executable are provided.

Download Sepia/Antique Image Filter Code (186 kb)

As always, full source code and a sample .exe is provided in the download link below.

Download Nature-Inspired Image Filter Code (318 kb)

Below, you can see how each filter looks on a promotional image from Final Fantasy Versus XIII.

Original:

Final Fantasy Versus XIII

Atmosphere:

Final Fantasy Versus XIII - Atmosphere Effect

Burn:

Final Fantasy Versus XIII - Burn Effect

Fog:

Final Fantasy Versus XIII - Fog Effect

Freeze:

Final Fantasy Versus XIII - Freeze Effect

Lava:

Final Fantasy Versus XIII - Lava Effect

Ocean:

Final Fantasy Versus XIII - Ocean Effect

Rainbow:

Final Fantasy Versus XIII - Rainbow Effect

Metal:

Final Fantasy Versus XIII - Metal Effect

Underwater:

Final Fantasy Versus XIII - Underwater Effect

In this project, I’ve provided a 5×5 custom filter engine with support for scaling/weighting and biasing/offsetting.  This is identical to the custom filter engine provided by Photoshop, and mine is even slightly faster (at least for the screen-sized images I’ve been testing).

Besides being fast, the engine is also smart.  It is clever enough to estimate edge pixels correctly – even for scaled/weighted filters – and it will automatically validate all input values to make sure they’re appropriate.

Finally, I’ve included 7 sample filters for you to play with, including blur, sharpen, emboss, engrave, grease, unfocus, and vibrate.

Download Custom Filter Engine Code (91 kb)

Below, you can see how each filter looks on a promotional image from Castle, an excellent new NYPD dramedy on ABC.

Original:

Blur:

Sharpen:

Emboss:

Engrave:

Grease:

Unfocus:

Vibrate:

Download Edge Detection Code (86 kb)

For those who have never used edge detection algorithms before, here’s an idea of the output:

Original image:

Prewitt method (horizontal):

Prewitt method (vertical):

Sobel method (horizontal):

Sobel method (vertical):

Laplacian method:

Hilite method:

Tanner’s method 1:

Tanner’s method 2:

As promised, here is the second half of my histogram code project.  In this project, I’ll show you how to stretch a histogram, equalize individual channels, and – most useful of all – equalize an image’s overall luminance.  Cool, eh?

Stretching a Histogram

The most straightforward of these functions is stretching a histogram.  The idea is this: many images stretch from pretty-dark colors to pretty-light colors, but they don’t take advantage of the full luminance spectrum by stretching all the way from pure black to pure light.  (For example, a “washed-out” image typically fails to utilize the entire luminance spectrum.)  To help fix an image like this, it is necessary to adjust the image’s colors to better span all possible brightness values.

Stretching does this by finding the darkest and lightest values in an image, then performing an automatic conversion between that color range (max – min) and the ideal color range (pure white – pure black).

As an example, here is an image that doesn’t span the full brightness spectrum:

Notice how the top half of the histogram is empty?  The brightest pixels in this image are only a mid-level gray.

Here is the same image after running a stretch histogram algorithm:

Notice how the histogram now stretches all the way to pure white?  Admittedly, this picture is not the best example of how stretching can be useful – but it’s a good demonstration of what stretching does.

Stretching is a fast and simple function, but its useful is limited.  Take the following image, for example:

The colors in this tiger picture stretch all the way from pure black to pure white, but they seem to be more heavily concentrated toward the dark end of the luminance spectrum.  To really fix this picture, we need to redistribute its colors across the spectrum in a more equal way.

Enter equalization.

Equalizing a Histogram

Equalizing is a more complex and time-consuming function than stretching, but it is able to fix problems outside the reach of stretching alone.

Here is the tiger image post-equalization:

See how much more balanced the histogram has become?  As another example, here is the cloud picture from above after both stretching and equalizing:

Equalizing has brought out a bunch of details that weren’t apparent in the original image.

Rather than going through the gory details of how histogram equalizing works, I’m going to refer you to the excellent Wikipedia article on the subject:

http://en.wikipedia.org/wiki/Histogram_equalization

Also, I’d like to quote one very applicable comment from the above article (emphasis added by me):

The above describes histogram equalization on a greyscale image. However, it can also be used on color images by applying the same method separately to the Red, Green and Blue components of the RGB color values of the image. Still, it should be noted that applying the same method on the Red, Green, and Blue components of an RGB image may yield dramatic changes in the image’s color balance since the relative distributions of the color channels change as a result of applying the algorithm. However, if the image is first converted to another color space, Lab color space, or HSL/HSV color space in particular, then the algorithm can be applied to the luminance or value channel without resulting in changes to the hue and saturation of the image.

Because of this, I have supplied two equalizing algorithms in this project – one that equalizes any combination of color channels, and another that equalizes only luminance.  The luminance method provides the code for converting between RGB and HSL color spaces…and that code is very complex.  It’s probably worth your while to take that code on faith for now, and maybe at a future date I’ll discuss color space transformations in more detail.

Get the Code!

But enough chat!  Here’s the link for the code:

Download Advanced Histogram Code (91 kb)

I realized today that while I use image histograms in several of the projects on this site (particularly my Real-Time Image Levels demo), I don’t actually provide a stand-alone image histogram viewer.

…Until now, that is.  :)

Image histograms are HUGELY useful in image processing.  In fact, the most basic image processing algorithm – adjusting brightness – is entirely an image histogram process, theoretically speaking.  Many other functions (including contrast, invert, levels, curves, and more) can be described in terms of an image histogram as well.

So what is an image histogram, and why is it useful?

What is a histogram?

Answers.com defines histograms as:

A bar graph of a frequency distribution in which the widths of the bars are proportional to the classes into which the variable has been divided and the heights of the bars are proportional to the class frequencies.

I realize this definition is not entirely useful, but it is important to note that histograms are not used only in image processing.  Histograms are simply a type of graph – nothing more, nothing less.

A simpler way to define histograms is this: a histogram is a bar graph that shows population by category.  Categories are listed, in order, along the x-axis (or horizontally).  The population (or, alternatively, number of occurrences) of each category is listed along the y-axis (or vertically).  In this graph from the 2000 U.S. census, travel time of working Americans is shown as a histogram:

Simple, eh?

So what is an Image Histogram?

As you can imagine, an image histogram is a type of histogram that tells us something about an image.  In most cases, the categories in an image histogram are brightness levels (from black to white), while the “population” of each category is the number of pixels with that brightness.

To demonstrate, let’s look at two different image histograms.

First, here is a histogram of a dark, cloudy image:

Notice how the image histogram is heavily weighted to the left?  Because this image is quite dark, the histogram shows much more pixels on the left side of the graph (the dark side) than it does on the right side of the graph (the light side).

Conversely, here is the histogram of a bright image:

While there are some dark regions in the center of the image (indicated by the spike on the far left of our histogram), the bulk of the image is lighter, and as a result the bulk of our histogram is shifted toward the right.

Now that you know what image histograms represent, try out the attached histogram code and see if you can predict rough histogram outlines before loading an image.  (Note that as with all VB6 picture-box-based code, the program will not load images larger than ~2mb.)

The forthcoming “Image Histograms Part 2″ project will showcase stretching a histogram and equalizing a histogram, so stay tuned!

Download Histogram Code (85 kb)

1) Simple “painting” code – basically, connecting a series of lines together as the user drags their mouse around.

2) An implementation of the hard-to-find (and poorly documented) API call for filling a contiguous region of an image. (Photoshop users should know this as the “paint bucket” tool.)

The API call used to perform the fill operation is ExtFloodFill, with a VB6 declaration and parameters like so:

Private Declare Function ExtFloodFill Lib "GDI32" (ByVal hdc As Long, ByVal X As Long, ByVal Y As Long, ByVal crColor As Long, ByVal wFillType As Long) As Long

To use the program, draw several lines using the left mouse button, then fill contiguous regions (with random colors) via the right button. Simple, eh?

Download Code (7 kb)

Because the first draft of this project has become so popular, I’ve written a new and MUCH faster version of the source code.  As before, no pre-built images or palettes are used, meaning that both coloring and flame generation are done using only math (and ingenuity!).

Updates to this version include the following:

• DIB sections are now used in place of Get/SetPixel.  This alone nearly tripled the frame rate on my old 1.6ghz laptop.
• Flame coloring is now done via look-up tables.  Previously this was calculated on the fly, which required way too many duplicate calculations.
• Random horizontal movement of individual flames is now calculated for every 4th pixel (instead of every single one).  Random number generation is costly, and visually this method looks almost identical (but is markedly faster).
• Scrollbars are now available so that you can color the flames however you’d like.  Red flames, blue flames, green flames, or any combination in-between – so knock yourself out.

On my aforementioned 1.6ghz laptop, the original version of this code ran (compiled) at 6-7 fps for a 512×256 image.  The new code runs between 27 and 28 fps – or a 400+% increase.

As usual, the sample code was written for VB6, but an .exe is included for those just wanting screenshots (or if you just want to see the effect in action).  Enjoy, and if you have any recommendations for Fire v.3, leave a comment!

Download Code (18 kb)