Despite many requests for a grayscale demonstration, I have held off coding anything until I could really present something unique.  I don’t like adding projects to this site that offer nothing novel or interesting, and there are already hundreds of downloads – in every programming language – that demonstrate standard color-to-grayscale conversions.   So rather than add one more “here’s a grayscale algorithm” article, I have spent the past week collecting every known grayscale conversion routine.  To my knowledge, this is the only project on the Internet that presents 7+ unique grayscale conversion algorithms, and at least two of the algorithms – custom # of grayscale shades with and without dithering – were written from scratch for this very article.

So without further ado, here are seven unique ways to convert a full-color image to grayscale.  (Note: I highly recommend reading the full article so you understand how the various algorithms work and what their purposes might be, but if all you want is the source code, you’ll find it past all the pictures and just above the donation link.)

Grayscale – An Introduction

Black and white (or monochrome) photography dates back to the mid-19th century.  Despite the eventual introduction of color photography, monochromatic photography remains popular.  If anything, the digital revolution has actually increased the popularity of monochromatic photography because any digital camera is capable of taking black-and-white photographs (whereas analog cameras required the use of special monochromatic film).  Monochromatic photography is sometimes considered the “sculpture” variety of photographic art.  It tends to abstract the subject, allowing the photographer to focus on form and interpretation instead of simply reproducing reality.

Because the terminology black-and-white is imprecise – black-and-white photography actually consists of many shades of gray – I will refer to such images as grayscale.

Several other terms will be used frequently throughout my explanations.  The first is color space.  A color space is a way to visualize a shape or object that represents all available colors.  Different ways of representing color generate different color spaces.  The RGB color space is represented as a cube, HSL can be a cylinder, cone, or bicone, YIQ and YPbPr have more abstract shapes.  This article will primarily reference the RGB and HSL color spaces.

I will also refer frequently to color channels.  Most digital images are comprised of three separate color channels: typically a red channel, a green channel, and a blue channel.  Layering these channels on top of each other creates a full-color image.  Different color models have different channels (sometimes the channels are colors, sometimes they are other values like lightness or saturation), but this article will primarily focus on RGB channels.

On to the algorithms!

Sample Image:

This bright, colorful promo art for The Secret of Monkey Island: Special Edition will be used to demonstrate each of our seven unique grayscale algorithms.

Method 1 – Averaging (aka “quick and dirty”)

Grayscale image generated from the formula: Average(Red, Green, Blue)

This method is the most boring, so let’s address it first.  “Averaging” is probably the most common grayscale conversion routine, and it works something like this:

Gray = (Red + Green + Blue) / 3

Fast, simple – no wonder this is the go-to grayscale algorithm for rookie programmers.  This formula generates a reasonably nice grayscale equivalent, and its simplicity makes it easy to implement and optimize (look-up tables work quite well).  However, this formula is not without shortcomings – while fast and simple, it does a poor job of representing shades of gray relative to the way humans perceive luminosity (or brightness).  For that, we need something a bit more complex.

Method 2 – Correcting for the human eye (sometimes called “luma” or “luminance,” though such terminology isn’t really accurate)

Grayscale generated using a formula similar to (Red * 0.3 + Green * 0.59 + Blue * 0.11)

It’s hard to tell a difference between this image and the one above, so let me provide one more example.  In the image below, method #1 or the “average method” covers the top half of the picture, while method #2 covers the bottom half:

If you look closely, you can see a horizontal line running across the center of the image. The top half (the average method) is more washed-out than the bottom half. This is especially visible in the middle-left segment of the image, beneath the cheekbone of the background skull.

The difference between the two methods is even more pronounced when flipping between them at full-size, as you can do in the provided source code.  Now might be a good time to download my sample project (available at the bottom of this article) so you can compare the various algorithms side-by-side.

This second algorithm plays off the fact that cone density in the human eye is not uniform across colors.  Humans perceive green more strongly than red, and red more strongly than blue.  This makes sense from an evolutionary biology standpoint – much of the natural world appears in shades of green, so humans have evolved greater sensitivity to green light.  (Note: this is oversimplified, but accurate.)

Because humans do not perceive all colors equally, the “average method” of grayscale conversion is inaccurate.  Instead of treating red, green, and blue light equally, a good grayscale conversion will weight each color based on how the human eye perceives it.  A common formula in image processors (Photoshop, GIMP) is:

Gray = (Red * 0.3 + Green * 0.59 + Blue * 0.11)

It’s surprising to see such a huge difference between red, green, and blue, isn’t it?  This formula requires a bit of extra computation, but it results in a more dynamic grayscale image.  Again, downloading the sample program is the best way to appreciate this, so I recommend grabbing the code, experimenting with it, then returning to this article.

It’s worth noting that there is disagreement on the best formula for this type of grayscale conversion.  In my project, I have chosen to go with the original ITU-R recommendation (BT.709, specifically) which is the historical precedent.  This formula, sometimes called Luma, looks like this:

Gray = (Red * 0.2126 + Green * 0.7152 + Blue * 0.0722)

Some modern digital image and video formats use a different recommendation (BT.601), which calls for slightly different coefficients:

Gray = (Red * 0.299 + Green * 0.587 + Blue * 0.114)

A full discussion of which formula is “better” is beyond the scope of this article.  For further reading, I strongly suggest the work of Charles Poynton.  For 99.99% of programmers, the difference between these two formulas is irrelevant.  Both are perceptually preferable to the “average method” discussed at the top of this article.

Method 3 – Desaturation

A desaturated image. Desaturating an image takes advantage of the ability to treat the (R, G, B) colorspace as a 3-dimensional cube. Desaturation approximates a luminance value for each pixel by choosing a corresponding point on the neutral axis of the cube.

Next on our list of methods is desaturation.

There are various ways to describe the color of a pixel.  Most programmers use the RGB color model, where each color is described by its red, green, and blue components.  While this is a nice way for a machine to describe color, the RGB color space can be difficult for humans to visualize.  If I tell you, “oh, I just bought a car.  Its color is RGB(122, 0, 255),” I doubt you can imagine the color I’m describing.  If, however, I say, “I just bought a car.  It is a bright, vivid shade of violet,” you can probably picture the color in question.  (Note: this is a hypothetical example.  I do not drive a purple car.  :)

For this reason (among others), the HSL color space is sometimes used to describe colors.  HSL stands for hue, saturation, lightness.  Hue could be considered the name of the color – red, green, orange, yellow, etc.  Mathematically, hue is described as an angular dimension on the color wheel (range [0,360]), where pure red occurs at 0°, pure green at 120°, pure blue at 240°, then back to pure red at 360°.  Saturation describes how vivid a color is; a very vivid color has full saturation, while gray has no saturation.  Lightness describes the brightness of a color; black has zero lightness, while white has full lightness.

Desaturating an image works by converting an RGB triplet to an HSL triplet, then forcing the saturation to zero. Basically, this takes a pixel and converts it to its least-saturated variant.  The mathematics of this conversion are more complex than this article warrants, so I’ll simply provide the shortcut calculation.  A pixel can be desaturated by finding the midpoint between the maximum of (R, G, B) and the minimum of (R, G, B), like so:

(Max(R, G, B) + Min(R, G, B)) / 2

In terms of the RGB color space, desaturation forces each pixel to a point along the neutral axis running from (0, 0, 0) to (255, 255, 255).  If that makes no sense, take a moment to read this wikipedia article about the RGB color space.

Desaturation results in a flatter, softer grayscale image.  If you compare this desaturated sample to the human-eye-corrected sample (Method #2), you should notice a difference in the contrast of the image.  Method #2 seems more like an Ansel Adams photograph, while desaturation looks like the kind of grayscale photo you might take with a cheap point-and-shoot camera.  Of the three methods discussed thus far, desaturation results in the flattest (least contrast) and darkest overall image.

Method 4 – Decomposition (think of it as de-composition – not the biological process!)

Decomposition using maximum values

Decomposition using minimum values

Decomposing an image (sounds gross, doesn’t it?) could be considered a simpler form of desaturation.  To decompose an image, we force each pixel to the highest (maximum) or lowest (minimum) of its red, green, and blue values.  Note that this is done on a per-pixel basis – so if we are performing a maximum decompose and pixel #1 is RGB(255, 0, 0) while pixel #2 is RGB(0, 0, 64), we will set pixel #1 to 255 and pixel #2 to 64.  Decomposition only cares about which color value is highest or lowest – not which channel it comes from.

As you can imagine, a maximum decomposition provides a brighter grayscale image, while a minimum decomposition provides a darker one.

This method of grayscale reduction is typically used for artistic effect.

Method 5 – Single color channel

Grayscale generated by using only red channel values.

Grayscale generated by using only green channel values.

Grayscale generated by using only blue channel values.

Finally, we reach the fastest computational method for grayscale reduction – using data from a single color channel.  Unlike all the methods mentioned so far, this method requires no calcuations.  All it does is pick a single channel and make that the grayscale representation of the images.

Believe it or not, this algorithm is the one most digital cameras use for taking “grayscale” photos.  CCDs in digital cameras are comprised of a blend of red, green, and blue sensors, and rather than perform the necessary math to convert RGB values to gray ones, they simply grab a single channel (green, for the reasons mentioned in Method #2 – human eye correction) and call that the grayscale one.  For this reason, most photographers recommend against using your camera’s built-in grayscale option.  Instead, shoot everything in color and then perform the grayscale conversion later, using whatever method leads to the best result!

It is difficult to predict the results of this method of grayscale conversion.  As such, it is usually reserved for artistic effect.

Method 6 – Custom # of gray shades

Grayscale using only 4 shades - black, dark gray, light gray, and white

Now it’s time for the fun algorithms.  Method #6, which I wrote from scratch for this project, allows the user to specify how many shades of gray the resulting image will use.  Any value between 2 and 256 is accepted; 2 results in a black-and-white image, while 256 gives you an image identical to Method #1 above.  This project only uses 8-bit color channels, but for 16 or 24-bit grayscale images (and their resulting 65,536 and 16,777,216 maximums) this code would work just fine.

The algorithm works by selecting X # of gray values, equally spread (inclusively) between zero luminance – black – and full luminance – white.  The above image uses four shades of gray.  Here is another example, using sixteen shades of gray:

In this image, we use 16 shades of gray spanning from black to white

I enjoy the artistic possibilities of this algorithm.  The attached source code renders all grayscale images in real-time, so for a better understanding of this algorithm, load up the sample code and rapidly scroll between different numbers of gray shades.

Method 7 – Custom # of gray shades with dithering (in this example, horizontal error-diffusion dithering)

This image also uses only four shades of gray (black, dark gray, light gray, white), but it adds full error-diffusion dithering support

Our final algorithm is perhaps the strangest one of all.  Like the previous method, it allows the user to specify any value in the [2,256] range, and the algorithm will automatically calculate the best spread of grayscale values for that range.  However, this algorithm also adds full dithering support.

What is dithering, you ask?  In image processing, dithering uses optical illusions to make an image look more colorful than than it actually is.  Dithering algorithms work by interspersing whatever colors are available into new patterns – ordered or random – that fool the human eye into perceiving more colors than are actually present.  If that makes no sense, take a look at this gallery of dithered images.

There are many different dithering algorithms.  The one I provide is one of the simpler error-diffusion mechanisms: a one-dimensional diffusion that bleeds color conversion errors from left to right.

If you look at the image above, you’ll notice that only four colors are present – black, dark gray, light gray, and white – but because these colors are mixed together, from a distance this image looks much sharper than the four-color non-dithered image under Method #6.  Here is a side-by-side comparison:

The left side of the image is a 4-shade non-dithered image; the right side is a 4-shade image WITH dithering

When few colors are available, dithering preserves more nuances than a non-dithered image, but the trade-off is a “dirty,” speckled look.  Some dithering algorithms are better than others; the one I’ve used falls somewhere in the middle, which is why I selected it.

As a final example, here is a 16-color grayscale image with full dithering, followed by a side-by-side comparison with the non-dithered version:

Hard to believe only 16 shades of gray are used in this image, isn't it?

As the number of colors in an image increases, dithering artifacts become less and less noticeable. Can you tell which side of the image is dithered and which is not?

Conclusion

If you’re reading this from a slow Internet connection, I apologize for the image-heavy nature of this article.  Unfortunately, the only way to really demonstrate all these grayscale techniques is by showing many examples!

The source code for this project, like all image processing code on this site, runs in real-time.  The GUI is simple and streamlined, automatically hiding and displaying relevant user-adjustable options as you click through the various algorithms:

GUI of the provided source code. The program also allows you to load your own images.

Each algorithm is provided as a stand-alone method, accepting a source and destination picturebox as parameters.  I designed it this way so you can grab whatever algorithms interest you and drop them straight into an existing project, without need for modification.

Comments and suggestions are welcome.  If you know of any interesting grayscale conversion algorithms I might have missed, please let me know.

(Fun fact: want to convert a grayscale image back to color?  If so, check out my real-time image colorization project.)

A set of camera diffusion lenses.

In traditional photography and film, a diffusion filter is used to soften light from a flash or stationary lamp.  Specialized lenses are available for this purpose, but the effect can be cheaply replicated by smearing petroleum jelly over the light (seriously) or by shooting through a sheet of nylon.

In image processing, a diffusion filter often means something else entirely.  Photoshop’s “Diffuse” filter randomly rearranges pixels within a set radius.  (GIMP can do the same thing, but the effect is more accurately titled “Spread.”)  This effect can be animated for a cheap explosion effect – something a number of SNES, Genesis, and DOS games used to great effect.

This project demonstrates a simple, real-time method for replicating such an effect.  All code is commented and reasonably optimized, and an animated “special effect” version is provided for those interested.  Unlike Photoshop, this routine allows you to specify separate horizontal and vertical max random distances, as well as the ability to wrap pixels around image edges.

Here's the original image (a poster for LittleBigPlanet)

Here is the same image with a diffuse filter applied (max distance=5)

...and here is the image again, but with max distance = 50

...and one more example. This time, edge wrapping has been enabled. Note the bleed of planet pixels at the top and black pixels at the bottom.

Another form of “colorization” is taking any image – including full-color ones – and colorizing the image for dramatic or artistic effect. This is the type of colorization filter provided by software like Photoshop and GIMP, and it’s also the effect my source code provides.

Here's the original image (a poster for Enslaved: Odyssey to the West)

...and here's the same poster, colorized

Colorization works by retaining certain data about each pixel’s color (luminance and possibly saturation) while ignoring other data about color (hue). In the demonstration above, each pixel in the second picture has the exact same saturation and luminance as the top picture, but all hue values have been replaced with blue.

Different programs implement colorization differently. Most require you to specify hue and saturation values, with luminance being optional. I really like the effect created when you keep the saturation values from the original image. If you force saturation values to an arbitrary number – like Photoshop or GIMP – the colorized image looks either drab or blown-out.

Here's another colorization - this time to orange. Saturation values are unchanged.

Here's the same image, but with saturation forced to 50 percent (Photoshop style). See how the characters and background blur together? The nice contrast between the background buildings and the character on the right is no longer present.

...and here's the image again, but with saturation forced to 100 percent. This looks terrible, IMO.

I think the top image in this set offers the most interesting colorization… but since I wrote this code, I could be biased… :)

Full sample code is provided, and – like all code on this site – it’s fast enough to run in real-time.

Here's a screenshot of the GUI attached to the sample code

Comments and ideas for improvement are always welcome.

Why such a complex title?

It all started with a strange idea I had today.  I was thinking of common ways to randomize image data (don’t ask why), and it struck me that the most common randomization method – varying RGB data of single pixels – is not the most interesting way to go about it.  Why not use lines, triangles, or other polygons to randomize an image?  How would that look?

To test my theory, I wrote a quick program that selects two random pixels in an image, averages their colors, then draws a line of that averaged color between the two points. When repeated over and over again, such an algorithm leads to some interesting effects…

I started with this God of War 3 image...

...and got this (100,000 iterations of lines with max length 42).

Here's the same image, but with lines of max length 85.

Kinda cool.  I’m not sure what to call this effect… although it looks “furry” to me.  Should we invent a new word – furrification?

Once I had lines working, my next curiosity involved polygons.  Here’s the same picture, but with triangle randomization:

Same parameters as the first line-based randomization above (100,000 iterations, 42 max length).

Same parameters as the second line-based image above (100,000 iterations, max length 85)

This is also a cool effect, especially when you watch it in action.  (The program refreshes the screen every 100 iterations.)

While I didn’t go to the trouble of implementing additional polygons, the code is primed and ready for it.  In fact, it would be trivial to draw polygons of any segment count.

Once I had my newly randomized images, I decided to pop into GIMP and do a bit of post-processing.  It was then that I realized this could be used to create pretty sweet stained glass images:

Sweet!

It’s trivial to create an image like this – simply open up your base image, then add a triangle randomized copy over the top as a new layer.  Set the layer mode to “difference” and bam: stained glass!

Same effect, but with a larger triangle size.

Other blending modes provide interesting effects – for example, multiply:

Same two images as the first stained glass example - just the blending mode has changed.

Anyway, I thought this was an interesting exploration in using a randomized copy of an image as an overlay.

Bayonetta is quite possibly the best action game I've ever played - yes, even better than God of War III

I’ve had this code ready for months, but I couldn’t bring myself to post it until I added something more exciting than just “emboss” and “engrave.”

Today is that day!

First, let me mention what emboss/engrave actually do. These are two of the simplest image processing filters, and they can be efficiently implemented in pretty much any programming language. They both operate on the same principle – for each pixel, subtract the RGB values of one or more neighboring pixels in a particular direction. This leads to an image where low-contrast areas are all black, while high-contrast areas (edges) are varying colors of brighter intensity. Most emboss/engrave filters add 127 to the RGB values so that uniformly contrasted areas are gray. As a bonus feature, I’ve added a “color” option to this code, so you can emboss/engrave an image to any hue. In the Bayonetta example above, the left side of the picture is embossed to something around #81a3fe.

Relief is a variation on emboss/engrave, where the base color is not artificially generated but is based off the current pixel. This acts almost like a sharpen filter, but because the filter doesn’t operate in all directions, it lends the image a more artificial look. (Hence the “relief” moniker – on certain images, it looks like an image has been chipped out of stone and then painted.) Try it on a photo – they tend to work best!

One possible view of the Mandelbrot set (generated with this project)

Today’s very cool project demonstrates a proof of concept implementation for rendering the famed Mandelbrot set (or “Mandelbrot fractal”) using VB6.  It’s a bit of a feat, since VB6 isn’t exactly optimized for recursion-heavy calculations…but you know me.  :)  I love making VB do things it was never meant to do!

I’m very happy with how the project turned out.  It may not be the fastest or prettiest or most accurate implementation (for example, at very high zoom-in you’ll start to see noticeable quality degradation), but I’ve deliberately kept the project as short and sweet as possible to maximize adaptability and learning potential.

To enhance the experience, I’ve added several user-controlled options to help you get a feel for how the rendering works.  First is the scroll-bar at the top of the screen, which allows you to preferentially set speed or accuracy as the program’s objective.  (For those familiar with how the Mandelbrot set works, the scroll bar controls the “escape time” of the recursive function.)

Another neat option is a click-and-drag feature that allows you to draw new rendering boundaries.  This makes it simple to zoom as deep as you want into the fractal.

Finally, rather than a drab grayscale rendering, I’ve chosen a more purplish gradient.  The code can be easily modified to favor another color if you so choose.

The code is reasonably optimized, so a complete view should render within several seconds on most modern hardware.  If speed is a concern, note that the white areas of the image take the longest to process – so minimizing the amount of white you select will maximize render speed.  Also, due to the inherent limits of the “Double” type in VB6, if you zoom in really, really far the program may lock up.  (Simply click the close button to force-terminate the project if this happens.)

The download link can be found below these sample images.

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

Anaphase, courtesy of Lothar Schermelleh

Today’s project is something new to this site – bioinformatics code!  It’s unfortunate that it’s taken me several years to post code related to my field, but hey – better late than never.  (That seems to be a recurring theme on this site…)

First, a primer.  If you don’t know what the title of this article references, 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) to help explain the purpose and design of my code.

The algorithm implementations are quite fast, and the visual feedback is a big improvement over traditional command-line tools. I’ve also included a FASTA file with data from chromosome #1 in the human genome (bases 6000-12000, I believe), which you can use to test the project.

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

(FYI #2, this project has been cited in the following paper: Spontaneo L, Cercone N. Correlating CpG islands, motifs, and sequence variants in human chromosome 21. 2011. BMC Genomics 12(Suppl 2):S10.  I recommend it to anyone seeking a more in-depth explanation of this code.)

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)

This project uses a 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

This project is coded in the Microsoft Visual Basic 6.0 programming language. VB6 provides a relevant blend of native-code processing speed (allowing fast implementation of the HMM and associated visualizations) and a simple, flexible GUI. Visual feedback is a key element of this process, as finding CpG islands using HMMs may require some some experimentation with input values to maximize efficiency and accuracy of the algorithm. To my knowledge, previous implementations of HMM-based CpG detection code have been command-line only, making this visual implementation first of its kind. (Additional note: 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 screenshot 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. (Additional note: to any VB experts reading this – please note that I am aware of mechanisms for overcoming this limitation, but such solutions are cumbersome compared to simply rebuilding the FASTA file as a byte array.)

Step 2: HMM Parameters
The GUI allows the user to change 14 HMM-related parameters. Additionally, I have added an option to let the program estimate the eight state probabilities. This is a trivial computation to perform, but it helps 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 relatively accurate.

Once these probabilities have been estimated, the I state probabilities are estimated by doubling 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 fast HMM calculations.

Next, all HMM probabilities are calculated and stored.

This is followed by a second loop run backward through the data that calculates all data necessary for the Viterbi algorithm. (Additional 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 can be run very quickly. (Additional 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 satisfying curiosity. If speed is your goal, it is trivial to disable this part of the code.)

Step 4: The Sliding Window
This step is where visual feedback becomes an essential component. In this project, I have chosen to display two graphs built from the HMM data; 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 predict 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.

(Additional note: 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). Multiple runs with varying parameters generate similar estimates. Adjusting the sliding window size doesn’t have a large effect on the estimates, although larger windows will unsurprisingly result in larger CpG island predictions. 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.

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