How to Convert Temperature (K) to RGB: Algorithm and Sample Code

Converting temperature (Kelvin) to RGB: an overview

If you don’t know what “color temperature” is, start here.

While working on a “Color Temperature” tool for PhotoDemon, I spent an evening trying to track down a simple, straightforward algorithm for converting between temperature (in Kelvin) and RGB values. This seemed like an easy algorithm to find, since many photo editors provide tools for correcting an image’s color temperature in post-production, and every modern camera – including smartphones – provides a way to adjust white balance based on the lighting conditions of a shot.

Example of a camera white balance screen. Image courtesy of

Little did I know, but it’s pretty much impossible to find a reliable temperature to RGB conversion formula. Granted, there are some algorithms out there, but most work by converting temperature to the XYZ color space, to which you could add your own RGB transformation after the fact. Such algorithms seem to be based off AR Robertson’s method, one implementation of which is here, while another is here.

Unfortunately, that approach isn’t really a mathematical formula – it’s just glorified look-up table interpolation. That might be a reasonable solution under certain circumstances, but when you factor in the additional XYZ -> RGB transformation required, it’s just too slow and overwrought for simple real-time color temperature adjustment.

So I wrote my own algorithm, and it works pretty damn well. Here’s how I did it.

Caveats for using this algorithm

Caveat 1: my algorithm provides a high-quality approximation, but it’s not accurate enough for serious scientific use. It’s designed primarily for photo manipulation – so don’t try and use it for astronomy or medical imaging.

Caveat 2: due to its relative simplicity, this algorithm is fast enough to work in real-time on reasonably sized images (I tested it on 12 megapixel shots), but for best results you should apply mathematical optimizations specific to your programming language. I’m presenting it here without math optimizations so as to not over-complicate it.

Caveat 3: this algorithm is only designed to be used between 1000 K and 40000 K, which is a nice spectrum for photography. (Actually, it’s way larger than most photographic situations will ever call for.) While it will work for temperatures outside these ranges, the estimation quality will decline.

Special thanks to Mitchell Charity

First off, I owe a big debt of gratitude to the source data I used to generate these algorithms – Mitchell Charity’s raw blackbody datafile at Charity provides two datasets, and my algorithm uses the CIE 1964 10-degree color matching function. A discussion of the CIE 1931 2-degree CMF with Judd Vos corrections versus the 1964 10-degree set is way beyond the scope of this article, but you can start here for a more comprehensive analysis if you’re so inclined.

The Algorithm: sample output

Here’s the output of the algorithm from 1000 K to 40000 K:

Output of my algorithm from 1000 K to 40000 K. The white point occurs at 6500-6600 K, which is perfect for photo manipulation purposes on a modern LCD monitor.

Here’s a more detailed shot of the algorithm in the interesting photographic range, which is 1500 K to 15000 K:

Same algorithm, but from 1500 K to 15000 K

As you can see, banding is minimal – which is a big improvement over the aforementioned look-up table methods. The algorithm also does a great job of preserving the slightly yellow cast leading up to the white point, which is important for imitating daylight in post-production photo manipulation.

How I arrived at this algorithm

My first step in reverse-engineering a reliable formula was to plot Charity’s original blackbody values. You can download my whole worksheet here in LibreOffice / OpenOffice .ods format (430kb).

Here’s how the data looks when plotted:

Mitchell Charity’s original Temperature (K) to RGB (sRGB) data, plotted in LibreOffice Calc. Again, these are based off the CIE 1964 10-degree CMFs. The white point, as desired, occurs between 6500 K and 6600 K (the peak on the left-hand side of the chart). (Source:

From this, it’s easy to note that there are a few floors and ceilings that make our algorithm easier. Specifically:

  • Red values below 6600 K are always 255
  • Blue values below 2000 K are always 0
  • Blue values above 6500 K are always 255

It’s also important to note that for purposes of fitting a curve to the data, green is best treated as two separate curves – one for temperatures below 6600 K, and a separate one for temperatures above that point.

From here, I separated the data (without the “always 0” and “always 255” segments) into individual color components. In a perfect world, a curve could then be fitted to each set of points, but unfortunately it wasn’t that simple. Because there’s a large disparity between the X and Y values in the plot – the x-values are all over 1000, and they are plotted in 100 point segments, while the y values all fall between 255 and 0 – it was necessary to transpose the x data in order to get a better fit. For optimization purposes, I stuck to first dividing the x value (the temperature) by 100 across each color, followed by an additional subtraction if it led to a significantly better fit. Here are the resultant charts for each curve, along with the best-fit curve and corresponding R-squared value:

Apologies for the horrifically poor font kerning and hinting in those charts. I love LibreOffice for many things, but its inability to do font aliasing on charts is downright shameful. I also don’t like having to extract charts from screenshots because they don’t have an export option, but that’s a rant best saved for some other day.

As you can see, the curves all fit reasonably well, with R-square values above .987. I could have spent more time really tweaking the curves, but for purposes of photo manipulation these are plenty close enough. No layperson is going to be able to tell that the curves don’t exactly fit raw idealized blackbody observations, right?

The algorithm

Using that data, here’s the algorithm, in all its glory.

First, pseudocode:

    Start with a temperature, in Kelvin, somewhere between 1000 and 40000.  (Other values may work,
     but I can't make any promises about the quality of the algorithm's estimates above 40000 K.)
    Note also that the temperature and color variables need to be declared as floating-point.

    Set Temperature = Temperature \ 100
    Calculate Red:

    If Temperature <= 66 Then
        Red = 255
        Red = Temperature - 60
        Red = 329.698727446 * (Red ^ -0.1332047592)
        If Red < 0 Then Red = 0
        If Red > 255 Then Red = 255
    End If
    Calculate Green:

    If Temperature <= 66 Then
        Green = Temperature
        Green = 99.4708025861 * Ln(Green) - 161.1195681661
        If Green < 0 Then Green = 0
        If Green > 255 Then Green = 255
        Green = Temperature - 60
        Green = 288.1221695283 * (Green ^ -0.0755148492)
        If Green < 0 Then Green = 0
        If Green > 255 Then Green = 255
    End If
    Calculate Blue:

    If Temperature >= 66 Then
        Blue = 255

        If Temperature <= 19 Then
            Blue = 0
            Blue = Temperature - 10
            Blue = 138.5177312231 * Ln(Blue) - 305.0447927307
            If Blue < 0 Then Blue = 0
            If Blue > 255 Then Blue = 255
        End If

    End If

In the pseudocode above, note that Ln() means natural logarithm. Note also that you can omit the “If color < 0” checks if you will only ever supply temperatures in the recommended range. (You still need to leave the “If color > 255” checks, though.)

As for actual code, here’s the exact Visual Basic function I’m using in PhotoDemon. It’s not yet optimized (for example, the logarithms would be much faster via look-up table) but at least the code is short and readable:

'Given a temperature (in Kelvin), estimate an RGB equivalent
Private Sub getRGBfromTemperature(ByRef r As Long, ByRef g As Long, ByRef b As Long, ByVal tmpKelvin As Long)

    Static tmpCalc As Double

    'Temperature must fall between 1000 and 40000 degrees
    If tmpKelvin < 1000 Then tmpKelvin = 1000
    If tmpKelvin > 40000 Then tmpKelvin = 40000
    'All calculations require tmpKelvin \ 100, so only do the conversion once
    tmpKelvin = tmpKelvin \ 100
    'Calculate each color in turn
    'First: red
    If tmpKelvin <= 66 Then
        r = 255
        'Note: the R-squared value for this approximation is .988
        tmpCalc = tmpKelvin - 60
        tmpCalc = 329.698727446 * (tmpCalc ^ -0.1332047592)
        r = tmpCalc
        If r < 0 Then r = 0
        If r > 255 Then r = 255
    End If
    'Second: green
    If tmpKelvin <= 66 Then
        'Note: the R-squared value for this approximation is .996
        tmpCalc = tmpKelvin
        tmpCalc = 99.4708025861 * Log(tmpCalc) - 161.1195681661
        g = tmpCalc
        If g < 0 Then g = 0
        If g > 255 Then g = 255
        'Note: the R-squared value for this approximation is .987
        tmpCalc = tmpKelvin - 60
        tmpCalc = 288.1221695283 * (tmpCalc ^ -0.0755148492)
        g = tmpCalc
        If g < 0 Then g = 0
        If g > 255 Then g = 255
    End If
    'Third: blue
    If tmpKelvin >= 66 Then
        b = 255
    ElseIf tmpKelvin <= 19 Then
        b = 0
        'Note: the R-squared value for this approximation is .998
        tmpCalc = tmpKelvin - 10
        tmpCalc = 138.5177312231 * Log(tmpCalc) - 305.0447927307
        b = tmpCalc
        If b < 0 Then b = 0
        If b > 255 Then b = 255
    End If
End Sub

This function was used to generate the sample output near the start of this article, so I can guarantee that it works.

Sample images

Here’s a great example of what color temperature adjustments can do. The image below – a promotional poster for the HBO series True Blood – nicely demonstrates the potential of color temperature adjustments. On the left is the original shot; on the right, a color temperature adjustment using the code above. In one click, a nighttime scene can been recast in daylight.

Color temperature adjustments in action. (Click for full size)

The actual color temperature tool in my PhotoDemon project looks like this:

PhotoDemon’s Color Temperature tool.

Download it here to see it in action.

addendum October 2014

Renaud Bédard has put together a great online demonstration of this algorithm. Check it out here, and thanks to Renaud for sharing!

addendum April 2015

Thank you to everyone who has suggested improvements to the original algorithm. I know there are a lot of comments on this article, but they’re worth reading if you’re planning on implementing your own version.

I’d like to call out two specific improvements. First, Neil B has helpfully provided a better version of the original curve-fitting functions, which results in slightly modified temperature coefficients. His excellent article describes the changes in detail.

Next, Francis Loch has added some comments and sample images below, which are very helpful if you want to apply these corrections to a photograph. His modifications produce a much more detailed image, as his sample images demonstrate.

Announcing PhotoDemon 5.0 Beta 1 – Testers Needed!

  1. Summary
  2. Download
  3. PhotoDemon 5.0: A Bit of Background
  4. List of what’s new and improved
PhotoDemon’s biggest update in years is nearing completion, which means it’s time for you to try and break it. Give it a spin and let me know what you think of the improvements (which are many!)


PhotoDemon 5.0 is nearing completion, and I need help testing it. Version 5.0 includes an all-new image subsystem that required rewriting every filter and effect in the program (and some 17,000 lines of code!). All those changes have made the software significantly faster and smoother, but it might also have broken a few things. Download the beta and help me make sure everything is working the way it’s supposed to.


The PhotoDemon 5.0 beta 1 comes in two flavors:

Remember – if you are an advanced user, you can always download the most recent development build of PhotoDemon’s source code from its GitHub page.

PhotoDemon is funded by donations from users like you.
Please consider a small donation to fund development and to help me support my family.
Even $1.00 helps. Thank you!

PhotoDemon 5.0: A Bit of Background

As you might know, PhotoDemon has a long and complicated history spanning some 12 years. That longevity has some perks – for example, tons of features – but it also has some downsides.

One of the biggest downsides to being 12 years old is that the software carries with it some bad design choices, made many years ago when I was a young and immature programmer, that have perpetually bogged down the implementation of new and exciting features. In particular, features like large images, selections, and alpha-channel (transparency) support have all been impossible because of the way PhotoDemon stores and renders images. Originally, the software was only meant to work on 8-bit images, and 24-bit support was later tacked on as an afterthought. I took that framework as far as I could go, but upon releasing PhotoDemon to the public earlier this year, I realized that it was time to fix that problem.

Enter version 5.0.

PhotoDemon 5.0 has just about been rewritten from the ground up, and I don’t say that lightly. The software is comprised of some 30,000 lines of code, and version 5.0 involved the writing of more than half (17,000) of those lines. Why? Because it was finally time for a completely new image subsystem, one capable of potentially supporting selections, alpha-channels, high bit-depths, layers, and whatever else I might want to someday throw at it.

(Note: features like selections are not yet part of PhotoDemon. They will take a good chunk of time to write – but at least now it will be physically possible to add them!)

This new image subsystem is something I’m very proud of. At a high level, it’s basically a specialized image class that stores and tracks all image data, and passes that data between the screen, image files, and various filters and effects. The subsystem does not rely on anything specific to Visual Basic (the programming language PhotoDemon is written in), meaning it is capable of supporting any features it wants – regardless of whether or not VB actually supports them. Past versions of PhotoDemon relied on VB’s inherent “picture boxes”, as they are called, for image storage and processing, and because VB6 is now 14 years old it simply couldn’t handle things like large images or transparency.

But no more.

This rewrite has been a massive project, and every single filter and tool (every damn one!) had to be rewritten to accommodate the new technology. This proved to be a good thing, because I hadn’t revisited some of those filters for over a decade, and in the past ten years I’ve learned a great deal about writing cleaner, better, faster imaging code. That made this a prime chance to re-engineer every filter and tool in the program to make it as fast and accurate as possible, and I think you’ll like the result.

But enough about this – you probably want to know what’s actually new in PhotoDemon 5.0. I won’t discuss everything here (some features are still under construction), but here are the highlights.

List of what’s new and improved in v5.0 beta 1

  • Everything is faster – all filters, tools, effects, loading images, saving images, macros, batch conversion, undo/redo. Seriously – EVERYTHING.
  • Completely rewritten image load/save code. As an example of how much better the new version is: I ran two identical batch conversions of 138 wedding photos (10 megapixels each, 3872×2592 pixels). The batch conversion was simple – load each image, then save it in another folder at a different JPEG quality. PhotoDemon 4.4 did the conversion in 2 minutes 21 seconds. The PhotoDemon 5.0 beta did it in 1 minute 11 seconds. (Thanks to Herman Liu for much testing and help with the implementation!)
  • Redesigned menus. Every item has a descriptive icon, and menus have been reorganized according to improved design rules
  • Menus now have useful icons and improved organization
  • Drag-and-Drop compatibility. Drag images from your desktop or file manager onto PhotoDemon, and it will open them all automatically. (Thanks to Kroc of for the suggestion!)
  • MUCH better Wine compatibility for OSX and Linux users. Undo/Redo and all tools and effects should now work under Wine. Let me know if you find any that do not.
  • New “Tile” tool tiles the current image to a target size (in pixels) or number of tiles. (Thanks to Ye Peng for the suggestion!)
  • PhotoDemon’s new “Tile” tool
  • New “Duplicate Image” tool. Perfect for making a working copy of an image without fear of overwriting the original. (Thanks to Achmad Junus for the suggestion!)
  • Auto-Enhance overhaul. All four auto-enhance tools (contrast, highlights, midtones, shadows) have been rewritten from scratch using completely new algorithms. I think you’ll find them way more useful than the old tools.
  • Improved mosaic tool. Faster, higher quality, and mosaics can now be as large as the image or as tiny as one pixel in either dimension.
  • Added previewing to a bunch of forms that lacked it before – Reduce Colors (Quantize), Black and White Conversion, Find Edges
  • Increased size of all preview windows. They are now much larger, which makes it easier to see how a filter or tool will affect an image.
  • Improved handling of edge pixels for all convolution filters (blur, soften, sharpen, etc)
  • Improved color reduction algorithms (faster and higher quality)
  • Floating-point implementation of histogram equalization means it is now significantly more accurate
  • DPI-aware images mean no more distortion at 120dpi – a big improvement for people using “larger font” settings in Windows
  • No limit on image sizes. The bigger, the better. (Thanks to Robert Rayment for his help with this bug!)
  • Full GDI+ support for saving and loading. If the FreeImage plugin can’t be found, GIF/JPEG/PNG/TIFF import and export will still be available. (Thanks to Alfred Hellmueller for the suggestion to add GDI+ compatibility!)
  • Turbo JPEG loading while batch conversions are running
  • Improved bug reporting system and online form to match
  • Tons of miscellaneous bug fixes, tweaks, and optimizations

Announcing PhotoDemon 4.4 – Now With Update Notifications, Improved Histogram, and More


PhotoDemon v4.4 is now available. It has a lot of cool new features. Download it here.

New Feature: Update Notifications

The most important update in version 4.4 is the addition of an automatic update notifier.

PhotoDemon's new update notifier
PhotoDemon’s new update notifier.

By default, PhotoDemon will check for updates whenever the software is run. Automatic update checks can be disabled from the Edit -> Preferences menu. You can also manually check for updates by going to Help -> Check for Updates.

I’m not sold on the layout of the update notification form – particularly the center alignment of the version numbers, which looks off due to the white space on the right-hand side – so its appearance may change in future versions, but at least this first draft conveys all the essential information.

Finally, note that this is merely an update notifier, not an automatic updater – clicking the “Yes” button will only open the PhotoDemon download page in your browser. It will not download the update for you, and it will not overwrite your current copy of the software. This is my preferred behavior for portable applications, but I am open to suggestions for better methods.

New Feature: Helpful Undo/Redo Text

The left-hand bar in v4.4 has been redesigned from version 4.3:

Comparison of v4.3 and v4.4 left-hand bar
v4.3 is on the left, v4.4 is on the right

The new, more compact version is in preparation for adding additional tools to the bottom section of the left-hand bar. It was also done as part of the new “friendly text” version of the Undo/Redo buttons:

new Undo/Redo interface
PhotoDemon’s helpful new Undo/Redo text.

I tried displaying the full text of the Undo/Redo action in the Undo/Redo buttons themselves, but as some of the descriptions are rather long, the button text would get pushed onto multiple lines (or off the button entirely!) making them look terrible. So the current implementation is: hover over the Undo/Redo button to see what action will be performed. As you can see, the Edit menu also contains a full-text description of Undo/Redo behavior.

Redesigned Histogram

With version 4.4, I don’t think it’s biased to say that PhotoDemon provides the best image histogram tool in the business:

PhotoDemon 4.4's redesigned histogram
PhotoDemon 4.4’s redesigned histogram

Individual channels can now be hidden or displayed in any combination. (The histogram will automatically adjust its maximum and minimum values accordingly.) This is useful for comparing just two color channels, for example, or comparing a single color channel against luminance.

The histogram now provides a “use smooth lines” option. This enables two features: antialiased lines (which VB does not do natively, so it’s a custom implementation), and cubic spline interpolation. Here’s an example of the aesthetic difference this makes:

Comparison of histogram render methods
Makes a difference, doesn’t it?

The new histogram interface provides a logarithmic rendering option. Images that are very dark or very bright will blow out the histogram at one end or the other, making it very difficult to see what’s happening in those ranges. Take the histogram of this beautiful FF7 fan art from user マップ, for example:

Image in need of a logarithmic histogram

Logarithmic histogram in action

Classic features like displaying the values of the histogram level under the cursor are still present, and you can still export the histogram image to an 8-bit PNG, GIF, or BMP file.

Finally, as of version 4.4 PhotoDemon’s histogram window is now non-modal. This means that you can leave the histogram window open while loading/saving/manipulating images, and the window will automatically refresh itself when necessary. Perform a filter or color operation and the histogram will update to reflect those changes; Undo a previous action and it will also update, making it very useful for comparing the effects of various filters.

As part of these updates, the histogram code has been newly refactored and optimized, so it’s fast and extremely low-resource, even when left open during image operations. All histogram data is pre-calculated, so when you change rendering options (such as enabling/disabling channels or switching between logarithmic and regular representation) the new histogram is instantly redrawn without requiring a recalculation of the raw data.

I’m not done with histogram updates, but v4.4 provides a great improvement over v4.3.

Redesigned Grayscale Interface and New Grayscale Algorithms

The grayscale conversion form has been completely redesigned in v4.4:

Redesigned grayscale interface
Special thanks to pixiv user ぴよな*ティア for the image in the preview.

Grayscale conversion was one of the last features to lack an instant-preview option, but no longer – you can now see real-time previews of the various grayscale algorithms.

I have also ported over all seven of the grayscale conversion algorithms from my standalone grayscale project, some of which were not present in PhotoDemon. The full list of available grayscale conversion methods now includes:

  • Averaging
  • ITU standard (adjusting for cone density in the human eyes)
  • Desaturation (HSL color space)
  • Decomposition to maximum or minimum values
  • Single color channel reduction
  • Reduction to specific # of gray shades
  • Reduction to specific # of gray shades with dithering

PhotoDemon defaults to the ITU standard method, which is the best choice for people who have no idea what these various options mean. :) For a full discussion of how these methods work and why some are preferable to others, see my aforementioned in-depth grayscale article.

Finally, the reduce-to-specific-number-of-shades option can now be used to reduce an image to black and white (two shades). Previously it required three shades or more. That said, I still advise using PhotoDemon’s specific “convert to black and white” menu option, which provides more control over 2-color reduction.

Other miscellaneous updates and bugfixes

Other updates in v4.4 include:

  • The system hand cursor is now automatically applied to all clickable objects. This was previously done manually, and because VB isn’t smart about sharing resources, a hand cursor was stored in multiple places throughout the .exe. The new automated feature meant I could remove those references, so the new v4.4 .exe is actually smaller than v4.3, despite including a bunch of additional features. Windows Vista/7 users will also get a much prettier hand icon.
  • Batch conversion now has a more robust error handler. This is in preparation for the addition of an all-new batch conversion wizard, which didn’t make the cut for 4.4 but should be included in 4.5
  • Miscellaneous bug fixes related to save prompting, MDI maximizing, and more. See a full list of updates at PhotoDemon’s commit page on github.

In Conclusion…

I hope you enjoy the changes in version 4.4. As always, feel free to contact me with any feedback you might have.

Announcing PhotoDemon: A Fast, Free, Open-Source Photo Editor and Image Processor

PhotoDemon screenshot
PhotoDemon v4.2 in the midst of a massive batch conversion (1643 files)

tl;dr – I’ve spent 12 years working on an advanced image processing program. (Think PhotoShop, but without any on-canvas painting tools.) The software is now available under the title “PhotoDemon.” It is fast, free, completely open-source (BSD licensed), and it provides a number of useful features, including macro recording and automated batch conversion. You can download it here.

I can’t often say that a blog post has been 12 years in the making… but believe it or not, this post has taken me that long to write.

Many years ago, when I was but a lowly high school student, I legitimately believed that I alone could produce the world’s greatest video game. It was going to be epic in every possible way – immersive 3D graphics, fully orchestrated musical score, hundreds of pages of witty dialogue. I was going to program the whole thing myself in Visual Basic 6.0, and it was going to be AWESOME.


This might shock you, but that game never came to fruition.

Fortunately, my delusional teenage aspirations weren’t entirely a waste – I did end up writing many hours of original music for the game, and I also produced a suite of useful development tools. One of those tools was called the GenesisX Image Studio, after my one-man GenesisX Production Company. (Yes, that name sounded cool to my teenage mind.) The purpose of GenesisX Image Studio was to convert 24-bit image files to the game’s custom 8-bit Genesis X Format.

Perhaps you recall, but back in the year 2000 bandwidth was hard to come by, and distributing a game chock full of large 24-bit images over the Internet simply wasn’t feasible. GIF images were still under patent protection so there were concerns about using them, and PNG wasn’t widely known or supported. So I decided to write my own image format, and this was the program capable of converting JPEGs and BMPs to that:

GXF Compressor screenshot
Here’s a screenshot of the GenesisX Image Studio. I know – it burns the eyes a little. Don’t you love the red/black gradient? It seemed so edgy at the time. (facepalm)

While the GXF Compressor was hideous to look at, it included some interesting code, including a rather clever interactive palette editor. That palette editor was at the heart of the Genesis X Format. It worked by taking 256-color images and blending low-frequency colors at a ratio of their occurrences within the image. This way, it was possible to get a 256-color image down to 128 colors or less with very little degradation; the image would then be RLE compressed and optionally zLib compressed, and it was capable of producing downright tiny files.

GXF Palette Editor
The GenesisX Palette Editor. I’m not sure why I felt the need to plaster a bright red copyright message on the form… I’m fairly certain no one was interested in stealing my painfully amateurish code.

When the ultimate game project associated with this software died, I continued to peck away at the image studio, mostly because I enjoyed learning about image processing and the software already provided a framework for things like loading and saving images, zooming and scrolling them, and a rudimentary set of filters. Over time, I eliminated the 256-color feature set and focused only on 16 million color support. Eventually the ridiculous “GenesisX” moniker was dropped, and the project was renamed “DemonSpectre Image Workshop.” (DemonSpectre was my online alias at the time.)

DemonSpectre Image Workshop
By 2002, the project had become slightly less hideous. The red/black gradient was replaced by the blue/black gradient made famous by InstallShield, and a thoroughly useless logo was added to the left-hand side. The code base also grew to include a variety of new filters and processing techniques.

In 2002, Microsoft introduced the first version of Visual Studio .NET, effectively obsoleting the COM-based VB6 overnight. I was in university by then, and had become very aware that VB was not the right language for a programmer who wanted to be taken seriously in the U.S. job market. So I learned C++, java, and Perl, though I retained a love for classic VB, in large part because it was the language that got me into programming in the first place.

The next 8-9 years saw slow, incremental upgrades to the software, usually the result of a random night or weekend when I was fed up with work and needed to focus on something not-work-related. Eventually I renamed the software “VB Photoshop” (no copyright problems there!), then later PhotoDemon, a mash-up of my old DemonSpectre moniker and the fact that the software had grown to focus primarily on photo editing.

In fact, my interest in digital photography led to many of the program’s best features, since I used PhotoDemon to implement tools that other image editing programs lacked or implemented poorly. (I’m looking at you, PhotoShop batch conversion!) Since its inception, PhotoDemon also served as a testbed for my image processing work in other programming languages, because for all its flaws, classic VB is unbeatable as a rapid prototyping language. I still use it for first-implementation tests of obscure features or filters, simply because I can go from pseudocode to real-time implementation in minutes (versus hours in java, and days/months in C). And because VB6 compiles down to native code (unlike the interpreted P-code of earlier versions), it’s perfect for prototyping image processing code, which often needs to execute in real-time.

PhotoDemon v4.2 menu screenshot
PhotoDemon has come a long way from its original GenesisX Image Studio roots. The current version looks quite nice, and it includes features I find lacking in other software – such as extensive accelerator (“hotkey”) support. For those who don’t utilize accelerators, the menus are designed to maximize discoverability. IMO they’re a significant improvement over most image editing software menus.

Because I continued to receive a surprising amount of traffic to my VB-oriented programming site, I would periodically strip interesting features out of PhotoDemon and publish them independently. In fact, most of my open-source programming projects are merely subsets of PhotoDemon’s codebase. (And it’s a surprisingly large codebase – over 30,000 lines – and that’s not including the 3rd-party DLLs it relies on for extra functionality.)

Every now and then, I’ll receive an email from a poor programmer who’s stuck supporting a legacy VB6 application and has consequently stumbled across my site. These emails always brighten my day, and they’re the reason I still provide VB6 projects despite the language being “dead” for more than 10 years. (Although “dead” is a relative term – Microsoft’s extended support lasted until 2008, and they have promised “it just works” compatibility for VB6 applications FOR THE LIFETIME of Windows 8. I know people have their criticisms of Microsoft, but no major tech company is half as good as they are when it comes to supporting legacy software. Hats off to Microsoft for that.)

Occasionally, these emails will ask me if I have a single project that condenses my many image processing techniques into a single piece of software. For ten years, my response to this question has been a vague, teasing, “maybe I do – you’ll have to wait and see!” I’m not sure why I’ve never just tell people about PhotoDemon… probably because they would pester me for copies of the code, and I hate sending out .zip files of large source directories, especially when I haven’t made up my mind about how I want to license said code.

But this summer, as I was sending out yet another one of these vague email responses, it struck me that I’d spent the past ten years hinting at PhotoDemon but never really thinking seriously about when it might live somewhere besides my hard drive. Wasn’t it time to seriously commit to getting the project in a workable state? (Anyone who knows me shouldn’t find this surprising – my motto has always been “better late than never,” and boy does this project meet that definition!)

So I committed, then and there, to getting PhotoDemon into a workable state. My last three months have been spent cleaning up its code base, stripping out useless functions and features, writing documentation, and coaxing it to work with modern Windows visual styles – no small feat, considering VB6 never worked with Windows XP visual styles, let alone Windows 7.

PhotoDemon current version screen shot
PhotoDemon, as it looks in August 2012. Note the use of Windows 7 visual styles, along with full MDI support. Also – no hideous background gradient! :)

Because I’m a glutton for punishment, I also got PhotoDemon working with modern version control software. (Here it is on GitHub.) I wonder if I’m the first person to try and get a massive VB6 codebase working properly with Git… Surprisingly, it does work, though it takes some tweaking thanks to VB’s strange intermixing of text and binary files. Maybe someday I’ll document what I did. Then again, maybe not – I’m not sure I want people trying to set up legacy VB projects with GitHub, lol.

After getting the code to a pleasantly robust state, I put up a preliminary project page for PhotoDemon on this site. That was six weeks ago. Thus far it seems to have been well-received among the VB programmers who frequent my site, and with the help of those programmers, many miscellaneous bugs have been squashed. After a rigorous few weeks of testing, I think PhotoDemon is finally stable enough to warrant broader use.

And that’s why this blog post exists.

Over the next few weeks, possibly months, I plan on releasing a series of “developer diaries” that discuss PhotoDemon’s features and design in detail. I don’t know many projects with a 12-year development time that spans from the developer first learning to program to becoming a professional coder, and I think my experiences could be useful for other young programmers looking to embark on their own open source project. Also, some of PhotoDemon’s more advanced capabilities – such as macro recording and playback – represent unique design challenges, and I think it could be worthwhile to discuss the implementation hurdles I faced in hopes of helping other programmers build such features right on their first try.

PhotoDemon v4.2 print dialog
PhotoDemon’s current interface aims to find that sweet spot between minimalism and power. For example, here’s the print dialog. I find most print dialogs to be woefully over-engineered, so this one provides only the options I use on a regular basis. Also, I just noticed that the “Orientation” label is misaligned vertically. D’oh! Better go fix that…

But for now, here’s what’s worth mentioning: PhotoDemon is stable, and I’d love your feedback on it. It’s designed as a portable app, meaning no installer is required. Just download the .zip, extract it, and run PhotoDemon.exe. (Not a Windows user? PhotoDemon should work with the latest stable release of Wine.)

Input is welcome from programmers and non-programmers alike. To download just the executable, use this link:

Download PhotoDemon (software only, no source code)

If you want the program AND its complete source code, download it from PhotoDemon’s GitHub page:

Download PhotoDemon (with complete source code)

A GitHub account is not required. Simply click the “ZIP” button with the cloud-and-arrow icon to download the source in standard VB6 format. (The ZIP button is just below the project description, in the top-left quadrant of the page.)

Issues can be submitted from the “Help” menu within PhotoDemon, or by visiting the Issues page, or by simply sending me an email.

Stay tuned for posts describing PhotoDemon’s (quite large) feature set in detail, as well as in-depth guides for its advanced features, including macro recording and batch conversion.

Finally, note that PhotoDemon is updated regularly. I tend to make commits on at least a weekly basis, and often more frequently than that. For the most up-to-date version of the software, download it from GitHub.

Thanks for your interest, and I hope you enjoy the software.

How to use a scanner (or TWAIN-compatible digital camera) in VB6

Today’s project demonstrates how to implement full scanner support from within a VB6 project. As a bonus, it also provides support for TWAIN-compatible digital cameras.

Before we begin

Because VB6 does not include a native scanner library, some sort of third-party DLL is required for scanner access.  My preferred choice is the free, public-domain EZTW32 library, which I have happily used for many years.  (The first version of EZTW32 was released in 1994!)  This project uses the most recent version of EZTW32 at the time of this writing: v1.19, updated 2009.02.22.  You can check for a newer version of the library here.

There are two versions of the EZTW32 library: a free, public-domain library – called “classic” – and a more sophisticated, paid version – called “pro.”  This project utilizes only the classic version.  The paid version includes many advanced features, and if you are interested in anything beyond simply capturing images from a scanner, it may be worth a look.  A full description of the “pro” version’s feature set is available here.

While the EZTW32 library provides many ways of interacting with the scanner, this project will focus on the following:

Private Declare Function TWAIN_IsAvailable Lib "EZTW32.dll" () As Long
Private Declare Function TWAIN_SelectImageSource Lib "EZTW32.dll" (ByVal hwndApp As Long) As Long
Private Declare Function TWAIN_AcquireToFilename Lib "EZTW32.dll" (ByVal hwndApp As Long, _
 ByVal sFile As String) As Long

The sample project includes a copy of v1.19 of the EZTW32 library.  If you would like to download a newer version of the library, simply copy the new version of EZTW32.dll into the same directory as the executable file (or .VBP file).  It should work without a problem.

Bonus tip: how to load DLLs from any location

Because a 3rd-party library is required to access a scanner in VB6, it is useful to know how to load a DLL from any location.  By default, VB6 will attempt to load a DLL from the computer’s system folder.  This is not ideal when developing portable applications (e.g. applications that can be run without requiring an installer), because it requires the user to manually copy files into their system folder… and that’s bad for a variety of reasons (security, potential for mistakes, etc).  It is possible to load a DLL from other locations using the regsvr32 command, but I don’t like regsvr32 because it adds additional entries to the user’s system registry, and it must be re-run every time the project is moved to a new folder.

So the best solution, in my opinion, is to tell VB to expect the DLL to appear in the same folder as the project itself.  (Alternatively, a /plugins/ sub-directory could be used.)  We do this by adding the following code to the General Declarations section of the project:

Private Declare Function LoadLibrary Lib "kernel32" Alias "LoadLibraryA" (ByVal lpLibFileName _
 As String) As Long
Private Declare Function FreeLibrary Lib "kernel32" (ByVal hLibModule As Long) As Long
Dim hLib as Long

Then, in the Form_Load sub, add this code to determine the project directory and tell VB to load any EZTW32 functions from the DLL in that directory:

Dim ProgramPath as String
ProgramPath = App.Path
If Right(ProgramPath, 1) <> "\" Then ProgramPath = ProgramPath & "\"

hLib = LoadLibrary(ProgramPath & "EZTW32.dll")

Finally, add this to the Form_Unload sub to release the DLL when the program terminates:

FreeLibrary hLib

The sample project (available below) demonstrates this technique, so feel free to download that instead of copying-and-pasting the code from this page.

What this project demonstrates

Because this project is focused on the basics of using a scanner, it demonstrates only the following:

  • How to check if the system offers scanner support (e.g. is a scanner driver loaded?)
  • On systems with multiple scanners, allow the user to select which scanner they want to use
  • Load the scanner’s built-in software and allow the user to preview and scan an image
  • Send the scanned image to a temporary file, then load that temporary file into a VB picture box

All of the above also applies to TWAIN-compatible digital cameras, which the software treats just like a scanner.

Finally, as mentioned earlier, EZTW32 has a paid “pro” version that offers additional features. You can learn more about the “pro” version here.


As you may have inferred from its title, EZTW32 relies on the TWAIN protocol for accessing a scanner. TWAIN is one of several ways to interact with a scanner; other common options include WIA (Windows Image Acquisition) on Windows, and SANE (Scanner Access Now Easy) on Linux.

TWAIN has some advantages and disadvantages compared to WIA and SANE. One of TWAIN’s unique characteristics is that it requires the scanner to provide its own user interface. The advantage of this approach is that on a given system, TWAIN-compatible programs all launch the same scanner user interface – the interface provided by the scanner itself. This is good for casual users, because regardless of whether they use this program or Photoshop or GIMP, the scanner interface will always be the exact same. The downside is that if you want to implement custom scanner features or options, TWAIN makes it difficult.

Canon scanner user interface
Because TWAIN relies upon the scanner to provide its own user interface, the user will see a different scan window depending on their scanner brand. My Canon scanner software looks like this.

Another advantage of TWAIN is its longevity. The TWAIN standard has been around since 1992, so pretty much every scanner made in the last 20 years will offer TWAIN drivers. By comparison, WIA didn’t exist until the year 2000, and it wasn’t until Windows Vista that most scanners offered WIA support.

One disadvantage of TWAIN is that Windows Vista and Windows 7 give WIA preferential treatment. If you set up a new scanner using the default Windows Hardware Wizard, it may only load WIA drivers – meaning you’ll need to hunt down the install CD that came with your scanner, or download the latest driver bundle from the scanner manufacturer’s website. I discovered this the hard way when testing this program with my Canon all-in-one printer/scanner/fax. If my program can’t find your scanner, download the free GIMP image software from this link and use the File -> Create… -> Scanner/Camera… option. If my program can’t find your scanner, and GIMP can’t find your scanner, you probably don’t have TWAIN drivers installed. If GIMP works but my program does not, send me a message and I’ll investigate further.

Download the sample project

My sample project is pretty minimalist:

Scanner project user interface
The sample project keeps things simple.

I tried to keep the code as small and simple as possible. Again, the latest version of the EZTW32 dll (v1.19) is included in the download. Future versions of the file should be backwards-compatible; simply replace the existing dll with a newer version.


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!

Seven grayscale conversion algorithms (with pseudocode and VB6 source code)

I have uploaded a great many image processing demonstrations over the years, but today’s project – grayscale conversion techniques – is actually the image processing technique that generates the most email queries for me.  I’m glad to finally have a place to send those queries!

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 seven 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 – this article will refer to such images as grayscale.

Several other technical terms will be used 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 lead to 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: 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.

How all grayscale algorithms fundamentally work

All grayscale algorithms utilize the same basic three-step process:

  1. Get the red, green, and blue values of a pixel
  2. Use fancy math to turn those numbers into a single gray value
  3. Replace the original red, green, and blue values with the new gray value

When describing grayscale algorithms, I’m going to focus on step 2 – using math to turn color values into a grayscale value. So, when you see a formula like this:

Gray = (Red + Green + Blue) / 3

Recognize that the actual code to implement such an algorithm looks like:

For Each Pixel in Image {

   Red = Pixel.Red
   Green = Pixel.Green
   Blue = Pixel.Blue

   Gray = (Red + Green + Blue) / 3

   Pixel.Red = Gray
   Pixel.Green = Gray
   Pixel.Blue = Gray


On to the algorithms!

Sample Image:

Promo art for The Secret of Monkey Island: Special Edition, ©2009 LucasArts
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 - average method
Grayscale image generated from the formula: Average(Red, Green, Blue)

This method is the most boring, so let’s address it first.  “Averaging” is the most common grayscale conversion routine, and it works 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 (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 values related to cone density in the human eye
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:

Grayscale methods 1 and 2 compared
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)

Surprising to see such a large difference between the red, green, and blue coefficients, 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% 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

Grayscale generated from a Desaturate algorithm
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),” you probably can’t picture 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, lightnessHue 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; white has full lightness, while black has zero lightness.

Desaturating an image works by converting an RGB triplet to an HSL triplet, then forcing the saturation to zero. Basically, this takes a color 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:

Gray = ( Max(Red, Green, Blue) + Min(Red, Green, Blue) ) / 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, e.g. not the biological process!)

Decomposition - Max Values
Decomposition using maximum values
Decomposition - Minimum 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.

Maximum decomposition:

Gray = Max(Red, Green, Blue)

Minimum decomposition:

Gray = Min(Red, Green, Blue)

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 - red channel only
Grayscale generated by using only red channel values.
Grayscale - green channel only
Grayscale generated by using only green channel values.
Grayscale - blue channel only
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 value, as in:

Gray = Red


Gray = Green


Gray = Blue

Believe it or not, this shitty algorithm is the one most digital cameras use for taking “grayscale” photos.  CCDs in digital cameras are comprised of a grid 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
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:

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

This grayscale algorithm is a bit more complex. It looks something like:

ConversionFactor = 255 / (NumberOfShades - 1)
AverageValue = (Red + Green + Blue) / 3
Gray = Integer((AverageValue / ConversionFactor) + 0.5) * ConversionFactor

-NumberOfShades is a value between 2 and 256
-technically, any grayscale algorithm could be used to calculate AverageValue; it simply provides
 an initial gray value estimate
-the "+ 0.5" addition is an optional parameter that imitates rounding the value of an integer
 conversion; YMMV depending on which programming language you use, as some round automatically

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)

Grayscale - four shades, dithered
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:

Side-by-side of dithered and non-dithered 4-color grayscale images
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:

Grayscale image, 16 shades, dithered
Hard to believe only 16 shades of gray are used in this image, isn't it?
Grayscale, 16 shades, dithered vs non-dithered
As the number of shades of gray 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?

Because the code for this algorithm is fairly complex, I'm going to refer you to the download for details. Simply open the Grayscale.frm file in your text editor of choice, then find the drawGrayscaleCustomShadesDithered sub. It has all the gory details, with comments.


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


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!

Real-time Diffuse (Spread) Image Filter in VB6

One brand of camera diffusion lenses
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.

LittleBigPlanet mini poster
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.


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!

How to Colorize an Image (in VB6)

“Colorization” in image processing can refer to one of several things. Most commonly, to colorize an image is to take an image without color (like a black and white photograph) and artificially apply color to it. One example of this is the old Three Stooges movies which were originally shot in black-and-white, but re-released several years ago in color. Colorization of an entire movie is expensive and time-consuming, and a lot of human intervention is required to make things look right.

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.

Enslaved poster - original
Here's the original image (a poster for Enslaved: Odyssey to the West)
Enslaved poster - blue colorization
...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.

Enslaved poster - orange, original saturation
Here's another colorization - this time to orange. Saturation values are unchanged.
Enslaved poster - orange, 50 percent saturation
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.
Enslaved poster - orange, 100 percent saturation
...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.

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

Comments and ideas for improvement are always welcome.


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!

Stained Glass Effect (using VB6 and GIMP)

I wanted to title this article “a novel method for matrix randomization using polygons and custom differential post-processing blending“… but that was a bit long, even for me.

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:


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.


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!

Generating Emboss / Engrave / Relief Filters (in VB6)

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!


DISCLAIMER: These download files are regularly scanned to ensure they remain free from malicious content. Unfortunately, some virus scanners will flag these .zip files as suspicious simply because they contain source code and/or executable files. I have submitted my projects to a number of companies in an attempt to rectify these false-positives. Some have been cooperative. Others have not. If your virus scanner alerts you regarding these files, please allow the file to be submitted for further analysis (if your program allows for that). This should help ensure that any false-positive warnings gradually disappear for all users.

This site - and its many free downloads - are 100% funded by donations. Please consider a small contribution to fund server costs and to help me support my family. Even $1.00 helps. Thank you!