 |
||||||||||
| ||||||||||
| ||||||||||
Multimedia »
GDI+ »
General
Intermediate
Image Processing for Dummies with C# and GDI+ Part 1 - Per Pixel FiltersBy Christian GrausThe first in a series of articles which will build an image processing library in C# and GDI+ |
C#.NET 1.0, Win2K, WinXP, Windows, .NET, GDI+, Visual Studio, VS.NET2002, Dev Posted: 20 Mar 2002 Updated: 20 Mar 2002 Views: 470,699 Bookmarked: 293 times |
||
|
|
|||
|
Advanced Search Sitemap |
|
|
|
||||||||||||||||
Welcome to this, my first article in C#, and the first in a series on image processing. I figure between Nish and Chris Losinger waiting to bust my chops, I should learn as much as anyone from this article.
Overview
The purpose of the series will be to build a class that allows any C# programmer
access to common, and not so common, image processing functionality. The
reason we are doing it in C# is simply that I want to learn it, but the
functionality we use is available through GDI+ in C++, and indeed the code to
do the same thing using a DIBSECTION is not terribly
different. This first article will focus on per pixel filters, in other
words, filters that apply the same algorithm to each pixel 'in place' with no
regard for the values in any other pixels. You will see as we progress
that the code becomes somewhat more complex when we start moving pixels or
changing values based on calculations that take into account surrounding pixel
values.
The App
The app we will use is a basic Windows Forms application ( it is in fact my
first ). I've included code to load and save images using GDI+, and a
menu to which I will add filters. The filters are all static functions in
a class called BitmapFilter, so that an image can be passed in ( C# passes
complex types in by reference ) and a bool returned to indicate success or
failure. As the series progresses I am sure the app will get some other
nice functionality, such as scaling and warping, but that will probably happen
as the focus of an article after the core functionality is in place.
Scrolling is achieved in the standard manner, the Paint method uses the AutoScrollPosition
property to find out our scroll position, which is set by using the AutoScrollMinSize
property. Zooming is achieved through a double, which we set
whenever we change the scale, and which is used to set the AutoScrollMinSize
anew, as well as to scale the Rectangle we pass into DrawImage
in the Paint method.
Pixel Access, a.k.a. Unsafe code, and other nastiness
My first real disappointment in building this code was to find that the BitmapData
class in GDI+ does not allow us to access the data it stores, except through a
pointer. This means we need to use the unsafe keyword to
scope the block of code which accesses the data. The net effect of this
is that a highly security level is required for our code to execute, i.e. any
code using the BitmapData class is not likely to be run from a
remote client. This is not an issue for us right now, though, and it is
our only viable option, as GetPixel/SetPixel is
simply too slow for us to use iterating through bitmaps of any real size.
The other down side is that this class is meant to be portable, but anyone using it will need to change their project settings to support compiling of unsafe code.
A quirk I noticed from the first beta of GDI+ continues to this day, namely requesting a 24bitRGB image will return a 24bitBGR image. BGR ( that is, pixels are stored as blue, green, red values ) is the way Windows stored things internally, but I'm sure more than a few people will get a surprise when they first use this function and realise they are not getting what they asked for.
Invert Filter
Here, then is our first, and most simple filter - it simply inverts a bitmap, meaning that we subtract each pixel value from 255.
public static bool Invert(Bitmap b)
{
// GDI+ still lies to us - the return format is BGR, NOT RGB.
BitmapData bmData = b.LockBits(new Rectangle(0, 0, b.Width, b.Height),
ImageLockMode.ReadWrite, PixelFormat.Format24bppRgb);
int stride = bmData.Stride;
System.IntPtr Scan0 = bmData.Scan0;
unsafe
{
byte * p = (byte *)(void *)Scan0;
int nOffset = stride - b.Width*3;
int nWidth = b.Width * 3;
for(int y=0;y < b.Height;++y)
{
for(int x=0; x < nWidth; ++x )
{
p[0] = (byte)(255-p[0]);
++p;
}
p += nOffset;
}
}
b.UnlockBits(bmData);
return true;
}
This example is so simple that it doesn't even matter that the pixels are out of
order. The stride member tells us how wide a single line is, and the
Scan0 member is the pointer to the data. Within our unsafe block we grab
the pointer, and calculate our offset. All bitmaps are word aligned, and
so there can be a difference between the size of a row and the number of pixels
in it. This padding must be skipped, if we try and access it we will not
simply fail, we will crash. We therefore calculate the offset we need to
jump at the end of each row and store it as nOffset.
The key thing when image processing is to do as much outside the loop as
possible. An image of 1024x768 will contain 786432 individual pixels, a
lot of extra overhead if we add a function call, or create a variable inside
the loops. In this case, our x loop steps through Width*3 iterations,
when we care about each individual color, we will step the width only, and
increment our pointer by 3 for each pixel.
That should leave the rest of the code pretty straightforward. We are stepping through each pixel, and reversing it, as you can see here:
Grayscale filter
Subsequent examples will show less and less of the code, as you become more familiar with what the boilerplate part of it does. The next, obvious filter is a grayscale filter. You might think that this would involve simply summing the three color values and dividing by three, but this does not take into effect the degree to which our eyes are sensitive to different colors. The correct balance is used in the following code:
unsafe
{
byte * p = (byte *)(void *)Scan0;
int nOffset = stride - b.Width*3;
byte red, green, blue;
for(int y=0;y < b.Height;++y)
{
for(int x=0; x < b.Width; ++x )
{
blue = p[0];
green = p[1];
red = p[2];
p[0] = p[1] = p[2] = (byte)(.299 * red
+ .587 * green
+ .114 * blue);
p += 3;
}
p += nOffset;
}
}
As you can see, we are now iterating through the row b.Width times, and stepping
through the pointer in increments of 3, extracting the red, green and blue
values individually. Recall that we are pulling out bgr values, not
rgb. Then we apply our formula to turn them into the grey value, which
obvious is the same for red, green and blue. The end result looks like
this:
A note on the effects of filters
It's worthwhile observing before we continue that the Invert filter is the only non-destructive filter we will look at. That is to say, the grayscale filter obviously discards information, so that the original bitmap cannot be reconstructed from the data that remains. The same is also true as we move into filters which take parameters. Doing a Brightness filter of 100, and then of -100 will not result in the original image - we will lose contrast. The reason for that is that the values are clamped - the Brightness filter adds a value to each pixel, and if we go over 255 or below 0 the value is adjusted accordingly and so the difference between pixels that have been moved to a boundary is discarded.
Brightness filter
Having said that, the actual filter is pretty simple, based on what we already know:
for(int y=0;y<b.Height;++y)
{
for (int x = 0; x < nWidth; ++x)
{
nVal = (int) (p[0] + nBrightness);
if (nVal < 0) nVal = 0;
if (nVal > 255) nVal = 255;
p[0] = (byte)nVal;
++p;
}
p += nOffset;
}
The two examples below use the values of 50 and -50 respectively, both on the original image
Contrast
The operation of contrast is certainly the most complex we have attempted.
Instead of just moving all the pixels in the same direction, we must either
increase or decrease the difference between groups of pixels. We accept
values between -100 and 100, but we turn these into a double between
the values of 0 and 4.
if (nContrast < -100) return false;
if (nContrast > 100) return false;
double pixel = 0, contrast = (100.0+nContrast)/100.0;
contrast *= contrast;
My policy has been to return false when invalid values are passed in, rather than clamp them, because they may be the result of a typo, and therefore clamping may not represent what is wanted, and also so users can find out what values are valid, and thus have a realistic expectation of what result a given value might give.
Our loop treats each color in the one iteration, although it's not necessary in this case to do it that way.
red = p[2];
pixel = red/255.0;
pixel -= 0.5;
pixel *= contrast;
pixel += 0.5;
pixel *= 255;
if (pixel < 0) pixel = 0;
if (pixel > 255) pixel = 255;
p[2] = (byte) pixel;
We turn the pixel into a value between 0 and 1, and subtract .5. The net result is a negative value for pixels that should be darkened, and positive for values we want to lighten. We multiply this value by our contrast value, then reverse the process. Finally we clamp the result to make sure it is a valid color value. The following images use contrast values of 30 and -30 respectively.
Gamma
First of all, an explanation of this filter. The following explanation of gamma was found on the web: In the early days of television it was discovered that CRT's do not produce a light intensity that is proportional to the input voltage. Instead, the intensity produced by a CRT is proportional to the input voltage raised to the power gamma. The value of gamma varies depending on the CRT, but is usually close to 2.5. The gamma response of a CRT is caused by electrostatic effects in the electron gun. In other words, the blue on my screen might well not be the same as the blue on your screen. A gamma filter attempts to correct for this. It does this by building a gamma ramp, an array of 256 values for red, green and blue based on the gamma value passed in (between .2 and 5). The array is built like this:
byte [] redGamma = new byte [256];
byte [] greenGamma = new byte [256];
byte [] blueGamma = new byte [256];
for (int i = 0; i < 256; ++i)
{
redGamma[i] = (byte)Math.Min(255, (int)(( 255.0
* Math.Pow(i/255.0, 1.0/red)) + 0.5));
greenGamma[i] = (byte)Math.Min(255, (int)(( 255.0
* Math.Pow(i/255.0, 1.0/green)) + 0.5));
blueGamma[i] = (byte)Math.Min(255, (int)(( 255.0
* Math.Pow(i/255.0, 1.0/blue)) + 0.5));
}
You'll note at this point in development I found the Math class.
Having built this ramp, we step through our image, and set our values to the
values stored at the indices in the array. For example, if a red value is
5, it will be set to redGamma[5]. The code to perform this operation is
self evident, I'll jump right to the examples. I've used Gamma values of
.6 and 3 for the two examples, with the original as always first for
comparison. I used the same values for red, green and blue, but the
filter allows them to differ.
Color Filter
Our last filter is a color filter. It is very simple - it just adds or subracts a value to each color. The most useful thing to do with this filter is to set two colors to -255 in order to strip them and see one color component of an image. I imagine by now you'd know exactly what that code will look like, so I'll give you the red, green and blue components of my son to finish with. I hope you found this article informative, the next will cover convolution filters, such as edge detection, smoothing, sharpening, simple embossing, etc. See you then !!!
