Whilst working on a small new project to write a console application that examines images for certain kinds of colour data I started, as I always do, with looking at how best to achieve this in a performant manner for the client. There is nothing worse than an application that appears to hang whilst an invisible piece of processing occurs. True, in this instance it was a console app that would be automagically scheduled for use and so this was not such a design issue but I still think it’s good practice. The main remit of the application was to iterate over every single pixel within an image file and to perform various calculations against the colour data that we obtained, the calculations were fairly simple and thus set in stone and so no real performance gains could be made out of a refactor, however this business of iterating over every pixel….
What of course springs to mind in the first instance is the easiest and quickest option and is demonstrated by the following code:-
for (int y = 0; y < img.Height; y++){
for (int x = 0; x < img.Width; x++){
Color clr2 = img.GetPixel(x, y);
if (clr2 == Color.Blue){
Console.WriteLine("The colour was blue!");
}
}
}
Job done, send it to the client…. But is that really the best way? If the client is processing huge amounts of very large files then very quickly your seemingly amazing turnaround of a solution for their issues seems ill thought out. A little more digging and I came across the Lockbits/UnlockBits methods of the bitmap object which I must admit that until this point I had not heard of. Please see this excellent blog if you need to know the precise mechanics of how this works.
http://www.bobpowell.net/lockingbits.htm
Effectively LockBits gives you direct access within memory to the underlying data that the image is composed of, access to the data is not via managed code instead using pointers and so needs to be marked as unsafe within the code, in addition the application itself needs to also allow unsafe code blocks to be run which can be done via the build tab within the project properties. After a little refactoring and we are presented with the following revisted code which performs the same job as the earlier snippet:-
BitmapData picData = img.LockBits(new Rectangle(0, 0, img.Width, img.Height), ImageLockMode.ReadOnly, img.PixelFormat);
try {
/* Now ascertain the pixel size......*/
int pixelSize = -1;
switch (picData.PixelFormat) {
case PixelFormat.Format32bppArgb: { pixelSize = 4; break; }
case PixelFormat.Format24bppRgb: { pixelSize = 3; break; }
case PixelFormat.Format8bppIndexed: { pixelSize = 1; break; }
}
if (pixelSize <= 0) {
throw new FormatException("Pixel format is unsupported or could not be ascertained");
}
/* OK. Iterate over the Pixels */
for (int y = 0; y < picData.Height; y++) {
/* OK. As we are using unmanaged memory we need to mark the code segment as unsafe...*/
unsafe { //AllowUnsafeCode
/* Now obtain a pointer to the current row of data for the three bitmpas that we are processing
The source image we access read only whilst we are writing the other two and thus need read-write
access. */
byte* row = (byte*)picData.Scan0 + (y * picData.Stride);
/* Iterate over the width of the image */
for (int x = 0; x < picData.Width; x++) {
int[] array = { row[(x * pixelSize) + BLUE], row[(x * pixelSize) + GREEN], row[(x * pixelSize) + RED] };
Color clr2 = Color.FromArgb(array[RED], array[GREEN], array[BLUE]);
if(clr2==Color.Blue){
Console.WriteLine("The colour was blue!");
}
}
}
}
/* Whatever happens ensure that we unlock the images once processing has completed. */
finally {
try {
img.UnlockBits(picData);
} catch { }
}
The proof of the pudding is of course in the eating, and this one tastes good. Against my 854 x 640 image using the original method the timings come in at 1.35 seconds per image, not exactly racing red especially when compared to the LockBits processing time which, even with all that extra set up code came in at under a 0.08 seconds which is in the region of 16 times faster.
