Develop Reference

Loading and displaying a 16 (12) bit grayscale png into a PictureBox

I'm using a framework for some camera hardware called IDS Peak and we are receiving 16 bit grayscale images back from the framework, the framework itself can write the files to disk as PNGs and that's all good and well, but how do I display them in a PictureBox in Winforms?
Windows Bitmap does not support 16 bit grayscale so the following code throws a 'Parameter is not valid.' System.ArgumentException
var image = new Bitmap(width, height, stride, System.Drawing.Imaging.PixelFormat.Format16bppGrayScale, iplImg.Data());
iplImg.Data() here is an IntPtr to the bespoke Image format of the framework.
Considering Windows Bitmap does not support the format, and I can write the files using the framework to PNGs, how can I do one of the following:
Convert to a different object type other than Bitmap to display directly in Winforms without reading from the files.
Load the 16-bit grayscale PNG files into the PictureBox control (or any other control type, it doesn't have to be a PictureBox).
(1) is preferable as it doesn't require file IO but if (2) is the only possibility that's completely fine as I need to both save and display them anyway but (1) only requires a write operation and not a secondary read.
The files before writing to disc are actually monochrome with 12 bits per pixel, packed.

While it is possible to display 16-bit images, for example by hosting a wpf control in winforms, you probably want to apply a windowing function to reduce the image to 8 bit before display.
So lets use unsafe code and pointers for speed:
var bitmapData = myBitmap.LockBits(
new Rectangle(0, 0, myBitmap.Width, myBitmap.Height),
ImageLockMode.ReadWrite,
myBitmap.PixelFormat);
try
{
var ptr= (byte*)bitmapData.Scan0;
var stride = bitmapData.Stride;
var width = bitmapData.Width;
var height= bitmapData.Height;
// Conversion Code
}
finally
{
myBitmap.UnlockBits(bitmapData);
}
or using wpf image classes, that generally have better 16-bit support:
var myBitmap= new WriteableBitmap(new BitmapImage(new Uri("myBitmap.jpg", UriKind.Relative)));
writeableBitmap.Lock();
try{
var ptr = (byte*)myBitmap.BackBuffer;
...
}
finally
{
myBitmap.Unlock();
}
To loop over all the pixels you would use a double loop:
for (int y = 0; y < height; y++)
{
var row = (ushort*)(ptr+ y * stride);
for (int x = 0; x < width; x++)
{
var pixelValue = row[x];
// Scaling code
}
}
And to scale the value you could use a linear scaling between the min and max values to the 0-255 range of a byte
var slope = (byte.MaxValue + 1f) / (maxUshortValyue - minUshortValue);
var scaled = (int)(((pixelValue + 0.5f - minUshortValue) * slope)) ;
scaled = scaled > byte.MaxValue ? byte.MaxValue: scaled;
scaled = scaled < 0 ? 0: scaled;
var byteValue = (byte)scaled;
The maxUshortValyue / minUshortValue would either be computed from the max/min value of the image, or configured by the user. You would also need to create a target image in order to write down the result into a target 8-bit grayscale bitmap to be displayed, or write down the same value for each color channel in a color image.

ImageSource from 3 IntPtr

I get three IntPtr's to the arrays of the RGB channels from an external library.
At the moment I merge the three arrays to one and create an ImageSource from the new array.
But the images can be really huge (at the moment up to 8000 x 4000 px), so the conversion of the data, which are already laying in the memory takes too long.
Is there a way to use these pointers to show the image in a canvas without copying? I.e. a derived class of ImageSource with costum OnRender method or something else?
I didn't found anything belongs to my problem.
Update:
My current code looks like this:
int unmapByes = Math.Abs(stride) - (width * 3);
byte* _ptrR = (byte*)ptrR;
byte* _ptrG = (byte*)ptrG;
byte* _ptrB = (byte*)ptrB;
BitmapSource bmpsrc = null;
App.Current.Dispatcher.Invoke(() =>
{
bmpsrc = BitmapSource.Create(width,
height,
96,
96,
PixelFormats.Bgr24,
null,
new byte[bytes],
stride);
});
BitmapBuffer bitmapBuffer = new BitmapBuffer(bmpsrc);
byte* buffer = (byte*)bitmapBuffer.BufferPointer;
Parallel.For(0, bytes / 3 - height, (offset) =>
{
int i = offset * 3 + (((offset + 1) / width)) * unmapByes;
*(buffer + i) = *(_ptrB + offset);
*(buffer + i + 1) = *(_ptrG + offset);
*(buffer + i + 2) = *(_ptrR + offset);
});
return bmpsrc;

WPF image sources are actually textures residing on the GPU, so they have to have very specific formats. You won't get by with your three arrays in this world.
However, 8000x4000 is only 32MB (times color bytes), that's nothing to copy around in RAM. If you really profiled your slowdown to be about this, I'd wager you're doing something wrong (using List<> or similar growable arrays instead of preallocating the whole buffer, redoing the computation more than once etc.)
As one optimizing tip off the top of my head, I suggest not using the naive implementation with 3 pointers advancing at the same time, do one array at a time to preserve it in your L1 cache.

The right answer is:
Get rid of computations in the loop, which have high costs. In this case it is the division. Computations with high costs are every computation which is not in the instruction set of the CPU.
The second one is, that a Parallel.For loop can increase the speed, but only if every Thread of the loop has a bigger amount of work. Otherwise the costs for the handling are too high.
So now I changed my code and use a Parallel.For loop for each line and an inner for loop for each pixel in this line.
Now I can convert an image with the size of 8000x4000 24rgb in 32ms (on my system I can say 1 Megapixel = 1ms).
For the future: Everyone who has a question wants to know, why his question was voted down. If you don't know the answer or only write bull***t, stop it.

Arrays juggling - data preparation

I could use some advice or help regarding a problem i'm facing and can't figure out a decent algorithm or solution.
Here's the status:
I have a 2D array of shorts: short[][] signal one dimension is the so-called channels. So depending on the problem i may have from 1 to 128. My test cases have 60 channels. And the other dimension represents "time" - 2048 samples per second and the samples are about 30 seconds long.
So around this: short[60][61440] array is my source.
My destination is to put this data into a byte array, representing image data. I'm using 16bpp so direct conversion to bytes will be done. This is still not the problematic part.
The problem is i wish to get over with is that i wish to present the data like this: The 60 channels are converted into 12x5 matrixes and 256 samples (1/8 of a second) will be displayed next to each other. Then a next "row" of those and the next... Lemme put up a sketch:
So if i have a sample of exactly 30 seconds, i get an image of dimensions 3072 x 1200 px. (So 256 samples per 12px on width and 240(30x8) samples per 5 px on heighth)
Can someone provide a clue on how to get this over with?
I've been thinking about a few versions, but none that would really work.
I hope my problem can be understood.
Ok so adding info:
bitmap = new Bitmap(60, length, PixelFormat.Format16bppRgb565);
BitmapData bmpdata = bitmap.LockBits(new Rectangle(0, 0, 60, length), ImageLockMode.ReadWrite, PixelFormat.Format16bppRgb565);
for (int i = 0; i < length; i++)
{
for (int j = 0; j < channel_number; j++)
{
bufferList.AddRange(BitConverter.GetBytes(signalArray[j][i]));
}
}
where the bufferList is defined as List<byte> bufferList = new List<byte>();
This is an example where i make an image 60 x 61440 px (channels x time)
What i will do with this image is not the main point. The point is i wish to prepare data to get the desired image as described...

Why does a bitmap compare not equal to itself?

This is a bit puzzling here. The following code is part of a little testing application to verify that code changes didn't introduce a regression. To make it fast we used memcmp which appears to be the fastest way of comparing two images of equal size (unsurprisingly).
However, we have a few test images that exhibit a rather surprising problem: memcmp on the bitmap data tells us that they are not equal, however, a pixel-by-pixel comparison doesn't find any difference at all. I was under the impression that when using LockBits on a Bitmap you get the actual raw bytes of the image. For a 24 bpp bitmap it's a bit hard to imagine a condition where the pixels are the same but the underlying pixel data isn't.
A few surprising things:
The differences are always single bytes that are 00 in one image and FF in the other.
If one changes the PixelFormat for LockBits to Format32bppRgb or Format32bppArgb, the comparison succeeds.
If one passes the BitmapData returned by the first LockBits call as 4th argument to the second one, the comparison succeeds.
As noted above, the pixel-by-pixel comparison succeeds as well.
I'm a bit stumped here because frankly I cannot imagine why this happens.
(Reduced) Code below. Just compile with csc /unsafe and pass a 24bpp PNG image as first argument.
using System;
using System.Drawing;
using System.Drawing.Imaging;
using System.Runtime.InteropServices;
class Program
{
public static void Main(string[] args)
{
Bitmap title = new Bitmap(args[0]);
Console.WriteLine(CompareImageResult(title, new Bitmap(title)));
}
private static string CompareImageResult(Bitmap bmp, Bitmap expected)
{
string retval = "";
unsafe
{
var rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
var resultData = bmp.LockBits(rect, ImageLockMode.ReadOnly, bmp.PixelFormat);
var expectedData = expected.LockBits(rect, ImageLockMode.ReadOnly, expected.PixelFormat);
try
{
if (memcmp(resultData.Scan0, expectedData.Scan0, resultData.Stride * resultData.Height) != 0)
retval += "Bitmap data did not match\n";
}
finally
{
bmp.UnlockBits(resultData);
expected.UnlockBits(expectedData);
}
}
for (var x = 0; x < bmp.Width; x++)
for (var y = 0; y < bmp.Height; y++)
if (bmp.GetPixel(x, y) != expected.GetPixel(x, y))
{
Console.WriteLine("Pixel diff at {0}, {1}: {2} - {3}", x, y, bmp.GetPixel(x, y), expected.GetPixel(x, y));
retval += "pixel fail";
}
return retval != "" ? retval : "success";
}
[DllImport("msvcrt.dll", CallingConvention = CallingConvention.Cdecl)]
static extern int memcmp(IntPtr b1, IntPtr b2, long count);
}

Take a look at this, which pictorially illustrates a LockBits buffer - it shows the Rows of Strides and where Padding can appear at the end of the Stride (if it's needed).
https://web.archive.org/web/20141229164101/http://bobpowell.net/lockingbits.aspx
http://supercomputingblog.com/graphics/using-lockbits-in-gdi/
A stride is probably aligned to the 32bit (i.e. word) boundary (for efficiency purposes)...and the extra unused space at the end of the stride is to make the next Stride be aligned.
So that's what's giving you the random behaviour during the comparison...spurious data in the Padding region.
When you are using Format32bppRgb and Format32bppArgb that's naturally word aligned, so I guess you don't have any extra unused bits on the end, which is why it works.

Just an educated guess:
24 bits (3 bytes) is a little bit awkward on 32/64 bit hardware.
With this format there are bound to be buffers that are flushed out to a multiple of 4 bytes, leaving 1 or more bytes as 'don't care' . They can contain random data and the software doesn't feel obliged to zero them out. This will make memcmp fail.

How can I do a color or numeric replacement with bitwise/boolean logic

How can I do a color replace like the code below without using the if statement and instead use boolean algebra (or some other magic that will not introduce conditional logic)
The Problem (excuse the code):
private Image ReplaceRectangleColors(Bitmap b,
Rectangle rect,
Color oldColor,
Color newColor)
{
BitmapData bmData = b.LockBits(rect,
ImageLockMode.ReadWrite,
PixelFormat.Format24bppRgb);
int stride = bmData.Stride;
IntPtr Scan0 = bmData.Scan0;
byte red = 0;
byte blue = 0;
byte green = 0;
unsafe
{
byte * p = (byte *)(void *)Scan0;
int nOffset = stride - rect.Width *3;
for(int y=0; y < rect.Height; ++y)
{
for(int x=0; x < rect.Width; ++x )
{
red = p[0];
blue = p[1];
green = p[2];
if (red == oldColor.R
&& blue == oldColor.B
&& green == oldColor.G)
{
p[0] = newColor.R;
p[1] = newColor.B;
p[2] = newColor.G;
}
p += 3;
}
p += nOffset;
}
}
b.UnlockBits(bmData);
return (Image)b;
}
The problem I have is that if the image is huge this code gets executed many times and has poor formance. I know there has to be a way to substitute the color replacement with something much cleaner/faster. Any ideas?
Just to summarize and simplify, I want to turn
if (red == oldColor.R
&& blue == oldColor.B
&& green == oldColor.G)
{
red = newColor.R;
blue = newColor.B;
green = newColor.G;
}
into a bit operation that doesn't include an if statement.

There aren't any bitwise operations that will replace pixels of one colour with another for you. In fact, reading a pixel, applying a bitwise operation and writing back the results for every pixel will probably work out slower than reading a pixel and only doing any work on it and writing it back if it matches your target colour.
However, there are some things that can be done to speed up the code, with increasing levels of complexity:
1) The first thing you could do is not to read the 3 bytes before you do the compare. If you read each byte only as it is needed for the comparison, then in the case that the red byte doesn't match, there isn't any need to read or compare the Green/Blue bytes. (The optimiser may well work this out on your behalf though)
2) Use cache coherence by accessing the data in the address-order that it is stored in. (You're doing this by working on the scanlines by putting x in your inner loop).
3) Use multithreading. Break the image into (e.g.) 4 strips, and process them in parallel, and you should be able to get a "several times" speedup if you have a 4+ core processor.
4) You may be able to work several times faster by using a 32-bit or 64-bit value instead of four or eight 8-bit values. This is because fetching one byte from memory might take a similar time (give or take some cache coherence etc) to fetching an entire CPU register (4 or 8 bytes). Once you have the value in a register, you can do a single comparison (RGBA) rather than four (R, G, B, A bytes separately), and then a single write back - potentially as much as 4x faster. This is the easy case (for 32-bpp images), as they conveniently fit one-pixel-per-int, so you can use a 32-bit integer to read/compare/write an entire RGBA pixel in a single operation.
But for other image depths you will have a much harder case, as the number of bytes in each pixel will not exactly match the size of your 32-bit int. For example, for 24bpp images, you will need to read three 32-bit dwords (12 bytes) so that you can then process four pixels (3 bytes x 4 = 12) on each iteration of your loop. You will need to use bitwise operations to peel apart these 3 ints and compare them to your 'oldcolour' (see below). An added complication is that you must be careful not to run off the end of each scanline if you are processing it in 4-pixel jumps. A similar process applies to using 64-bit longs, or processing lower bpp images - but you will have to start doing more intricate bit-wise operations to pull the data out cleanly, and it can get pretty complicated.
So how do you compare the pixels?
The first pixel is easy.
int oldColour = 0x00112233; // e.g. R=33, G=22, B=11
int newColour = 0x00445566;
int chunk1 = scanline[i]; // Treating scanline as an array of int, read 3 ints (12 bytes)
int chunk2 = scanline[i+1]; // We cache them in ints as we will read/write several times
int chunk3 = scanline[i+2];
if (chunk1 & 0x00ffffff == oldColour) // read and check 3 bytes of pixel
chunk2 = (chunk2 & 0xff000000) | newColour; // Write back 3 bytes of pixel
The next pixel has one byte in the first int, and 2 bytes in the next int:
if ((chunk1 >> 24) == (oldColour & 0xff)) // Does B byte match?
{
if ((chunk2 & 0x0000ffff) == (oldColour >> 8))
{
chunk1 = (chunk1 & 0x00ffffff) | (newColour & 0xff); // Replace B byte in chunk1
chunk2 = (chunk2 & 0xffff0000) | (newColour >> 8); // Replace G, B bytes in chunk2
}
}
Then the third pixel has 2 bytes (RG) in chunk2 and 1 byte (B) in chunk3:
if ((chunk2 >> 16) == (oldColour & 0xffff))
{
if ((chunk3 & 0xff) == (oldColour >> 16))
{
chunk2 = (chunk2 & 0x0000ffff) | (newColour << 16); // Replace RG bytes in chunk2
chunk3 = (chunk3 & 0xffffff00) | (newColour >> 16); // Replace B byte in chunk3
}
}
And finally, the last 3 bytes in chunk3 are the last pixel
if ((chunk3 >> 8) == oldCOlour)
chunk3 = (chunk3 & 0x000000ff) | (newColour << 8);
... and then write back the chunks to the scanline buffer.
That's the gist of it (and my masking/combining above may have some bugs, as I wrote the example code quickly and may have mixed up some of the pixels!).
Of course, once it works, you can then optimise it a load more - for example, whenever I compare stuff to parts of the oldColour (e.g. oldColour >> 16), I can precaclulate that constant outside the entire processing loop, and just use an "oldColourShiftedRight16" variable to avoid recalculating it on every pass through the loop. THe same goes for all the bits of newColour that are used. Potentially you may be able to make some gains by avoiding writing back the values that haven't been touched, too, as many of your pixels probably won't match the one you want to change.
So that should give you some idea of what you were asking for. It's not particularly simple, but it's a great deal of fun :-)
When you've got it all written and super-optimised, then the final step is to throw it away and just use your graphics card to do the whole thing a bazillion times faster in hardware - but let's face it, where's the fun in that? :-)

I wrote a project recently where I did color manipulation on a pixel per pixel basis. It had to run fast as it would update while you moved a mouse cursor around.
I started with unsafe code but I don't like unsafe code and so changed to safe territory and when I did, I had the speed issues you had but the resolution wasn't changing conditional logic. It was designing better algorithms for the pixel manipulation.
I'll give you an overview of what I did and I'm hoping it can get you where you want to be because it's really close.
First: I had multiple possible input pixel formats. Due to that I couldn't assume the RGB bytes were at specific offsets or even a static width. As such, I read the info from the passed in image and return a "color" that represents the sizes of each field:
private System.Drawing.Color GetOffsets(System.Drawing.Imaging.PixelFormat PixelFormat)
{
//Alpha contains bytes per color,
// R contains R offset in bytes
// G contains G offset in bytes
// B contains B offset in bytes
switch(PixelFormat)
{
case System.Drawing.Imaging.PixelFormat.Format24bppRgb:
return System.Drawing.Color.FromArgb(3, 0, 1, 2);
case System.Drawing.Imaging.PixelFormat.Format32bppArgb:
case System.Drawing.Imaging.PixelFormat.Format32bppPArgb:
return System.Drawing.Color.FromArgb(4, 1, 2, 3);
case System.Drawing.Imaging.PixelFormat.Format32bppRgb:
return System.Drawing.Color.FromArgb(4, 0, 1, 2);
case System.Drawing.Imaging.PixelFormat.Format8bppIndexed:
return System.Drawing.Color.White;
default:
return System.Drawing.Color.White;
}
}
For example purposes, let's say that a 24-bit RGB image is the source. I didn't want to change alpha values as I'm going to blend a color in to it.
Thus, R is at offset 0, B is at offset 1 and G at offset 2 and each pixel is three bits wide. This I create a temporary Color with this data.
Next, since this is in a custom control, I didn't want flickering so I overrode the OnPaintBackground and turned it off:
protected override void OnPaintBackground(System.Windows.Forms.PaintEventArgs pevent)
{
//base.OnPaintBackground(pevent);
}
Finally, and here's the part that gets to the crux of what you're doing, I draw a new image on each OnPaint (which is triggered as a mouse moves because I "Invalidate" it in the mouse move event handler)
Full code - before I call certain sections out ...
protected override void OnPaint(System.Windows.Forms.PaintEventArgs pe)
{
base.OnPaint(pe);
pe.Graphics.FillRectangle(new System.Drawing.SolidBrush(this.BackColor), pe.ClipRectangle);
System.Drawing.Rectangle DestinationRect = GetDestinationRectangle(pe.ClipRectangle);
if(DestinationRect != System.Drawing.Rectangle.Empty)
{
System.Drawing.Image BlendedImage = (System.Drawing.Image) this.Image.Clone();
if(HighlightRegion != System.Drawing.Rectangle.Empty && this.Image != null)
{
System.Drawing.Rectangle OffsetHighlightRegion =
new System.Drawing.Rectangle(
new System.Drawing.Point(
Math.Min(Math.Max(HighlightRegion.X + OffsetX, 0), BlendedImage.Width - HighlightRegion.Width -1),
Math.Min(Math.Max(HighlightRegion.Y + OffsetY, 0), BlendedImage.Height - HighlightRegion.Height -1)
)
, HighlightRegion.Size
);
System.Drawing.Bitmap BlendedBitmap = (System.Drawing.Bitmap) BlendedImage;
System.Drawing.Color OffsetRGB = GetOffsets(BlendedImage.PixelFormat);
byte BlendR = SelectionColor.R;
byte BlendG = SelectionColor.G;
byte BlendB = SelectionColor.B;
byte BlendBorderR = SelectionBorderColor.R;
byte BlendBorderG = SelectionBorderColor.G;
byte BlendBorderB = SelectionBorderColor.B;
if(OffsetRGB != System.Drawing.Color.White) //White means not supported
{
int BitWidth = OffsetRGB.G - OffsetRGB.R;
System.Drawing.Imaging.BitmapData BlendedData = BlendedBitmap.LockBits(new System.Drawing.Rectangle(0, 0, BlendedBitmap.Width, BlendedBitmap.Height), System.Drawing.Imaging.ImageLockMode.ReadWrite, BlendedBitmap.PixelFormat);
int StrideWidth = BlendedData.Stride;
int BytesPerColor = OffsetRGB.A;
int ROffset = BytesPerColor - (OffsetRGB.R + 1);
int GOffset = BytesPerColor - (OffsetRGB.G + 1);
int BOffset = BytesPerColor - (OffsetRGB.B + 1);
byte[] BlendedBytes = new byte[Math.Abs(StrideWidth) * BlendedData.Height];
System.Runtime.InteropServices.Marshal.Copy(BlendedData.Scan0, BlendedBytes, 0, BlendedBytes.Length);
//Create Highlighted Region
for(int Row = OffsetHighlightRegion.Top ; Row <= OffsetHighlightRegion.Bottom ; Row++)
{
for(int Column = OffsetHighlightRegion.Left ; Column <= OffsetHighlightRegion.Right ; Column++)
{
int Offset = Row * StrideWidth + Column * BytesPerColor;
if(Row == OffsetHighlightRegion.Top || Row == OffsetHighlightRegion.Bottom || Column == OffsetHighlightRegion.Left || Column == OffsetHighlightRegion.Right)
{
BlendedBytes[Offset + ROffset] = BlendBorderR;
BlendedBytes[Offset + GOffset] = BlendBorderG;
BlendedBytes[Offset + BOffset] = BlendBorderB;
}
else
{
BlendedBytes[Offset + ROffset] = (byte) ((BlendedBytes[Offset + ROffset] + BlendR) >> 1);
BlendedBytes[Offset + GOffset] = (byte) ((BlendedBytes[Offset + GOffset] + BlendG) >> 1);
BlendedBytes[Offset + BOffset] = (byte) ((BlendedBytes[Offset + BOffset] + BlendB) >> 1);
}
}
}
System.Runtime.InteropServices.Marshal.Copy(BlendedBytes, 0, BlendedData.Scan0, BlendedBytes.Length);
BlendedBitmap.UnlockBits(BlendedData);
//base.Image = (System.Drawing.Image) BlendedBitmap;
}
}
pe.Graphics.DrawImage(BlendedImage, 0, 0, DestinationRect, System.Drawing.GraphicsUnit.Pixel);
}
}
Going through the code here are some explanations...
System.Drawing.Image BlendedImage = (System.Drawing.Image) this.Image.Clone();
It is important to draw to an offscreen image - this creates one such image. Otherwise, the drawing will be much slower.
if(HighlightRegion != System.Drawing.Rectangle.Empty && this.Image != null)
HighlightRegion is a RECT that holds the area to "mark off" on the source image. I have used this to mark off image regions of 4 Million pixels and it still runs fast enough to be "real time"
Some code below is used because a user might be scrolled over or down on the image so I modify my destination by their scrolling amount.
Below that, I cast the IMAGE to a BITMAP and get the before-mentioned Color info which I'll need to start using now. Depending on what you're doing you might want to cache that instead of getting it each time.
System.Drawing.Bitmap BlendedBitmap = (System.Drawing.Bitmap) BlendedImage;
On my control, I exposed two Color properties - SelectionColor and SelectionBorderColor - so that my regions still have a nice border with them. Part of my speed optimization was to pre-cast these to bytes as I'll be doing bitwise operations in a moment.
You'll see a comment in the code "White not supported" - in this case, the "White" is the "Fake Color" we use to store our bit widths. I used "White" to mean "I can't operate on this data"
The next line establishes that indeed each color is one bit because they might not be depending on our target color format by subtracting the R and G offset. Note that if you cannot garauntee that your G follows your R then you'll need to use something else. In my case, it was garaunteed.
Now where the part you're really looking for starts. I use a LockBits to get the bit data. After that, I use the data to finish setting up some pre-loop variables.
And then, I copy the data to a byte array. I'm going to loop through this byte array, change the values and then copy it's data back to the BITMAP. I was working on the BITMAP directly before thinking that since it's offscreen it would be just as fast as working with a native array.
I was wrong. Performance profiling proved it to me. It's faster to copy everything to a byte array and work within that.
Now the loop starts. It goes row by row, column by column. Offset is a number telling us where in the byte array we are in terms of "current pixel".
Then, I blend 50% or I draw a border. Note that for each pixel I have not only an IF statement, but also OR checks.
And it's still fast as blazes.
Finally, I copy back and unlock the bits. And then copy the image to the onscreen surface.