We Keep Coding

Confused about LockBits, BitmapData and PixelFormat.Format48bppRgb

Consider the following code:
public static Bitmap Create3x3Bitmap(PixelFormat pixelFormat)
{
var bmp = new Bitmap(3, 3, pixelFormat);
// I know SetPixel does not perform well, this is strictly for learning purposes
bmp.SetPixel(0, 0, Color.Red);
bmp.SetPixel(1, 0, Color.Lime);
bmp.SetPixel(2, 0, Color.Blue);
bmp.SetPixel(0, 1, Color.White);
bmp.SetPixel(1, 1, Color.Gray);
bmp.SetPixel(2, 1, Color.Black);
bmp.SetPixel(0, 2, Color.Cyan);
bmp.SetPixel(1, 2, Color.Fuchsia);
bmp.SetPixel(2, 2, Color.Yellow);
return bmp;
}
The code above should produce a 3 x 3 Bitmap instance which, if magnified, should look like this:
I figured out that I could "scan" the bitmap's pixels information using the Bitmap.LockBits method. I succeeded doing just that using the 24 and 32 bits based PixelFormat values as the pixelFormat argument.
However, I have yet to understand how to work out pixel informations when PixelFormat.Format48bppRgb is used instead:
public void Test()
{
using (var bmp = Create3x3Bitmap(PixelFormat.Format48bppRgb))
{
var lockRect = new Rectangle(0, 0, bmp.Width, bmp.Height);
var data = bmp.LockBits(lockRect, ImageLockMode.ReadWrite, bmp.PixelFormat);
var absStride = Math.Abs(data.Stride); // will be equal to 20
var size = absStride * data.Height; // will be equal to 60
byte[] scanData = new byte[size];
Marshal.Copy(data.Scan0, scanData, 0, size);
// ...
// more stuff here, irrelevant for the actual question
// ...
bmp.UnlockBits(bitmapData);
}
}
If I run the code above using the debugger and break right after the call to Marshal.Copy, I can see that the scanData byte array contains 60 bytes. My understanding is that for each of the three RGB channels, two bytes are required. This means 6 bytes per pixel. There's also two additional unused bytes for each "row" on the y-axis, which in this case is 3 rows.
So if I'm getting this right, here is how I should interpret the array's content for the first row:
Now what confuses me is how I'm supposed to interpret each channel's pair of bytes and translate that back into the original color. It makes sense that for the first pixel (which is red), a pair of 0s would be found for both the blue and green channel. I wasn't so sure what to make of 0 and 32 as a pair that's supposed to mean "full-on red", but looking around the net I came to understand that the range is 0 to 8192 rather than 0 to 65535, due to a limitation of GDI+.
And sure enough, using BitConverter.ToUInt16 got me a value of 8192 for that pair of bytes. So the result for the red pixel makes sense.
However, it also gives 1768 for the "232, 6" pairs found on each channel of the gray pixel (indexes 26 to 31 on the image above). And that's where I am confused. Since gray color's 8 bits channels are midway in the range of 0 to 255, I would have expected something like 4095 or 4096, which is midway between 0 to 8192. 🤷‍♂️
Is my understanding on byte pairs representing channels even correct? If so then how come I got these channel values for gray color?

Minor nit: you wrote this:
There's also two additional empty pixels for each "row" on the y-axis, which in this case is 3 rows.
There are two additional bytes for each row, making the stride 20 bytes instead of the 18 bytes that would be needed for three 6-byte pixel values. This fulfills the GDI+ requirement that the bitmap stride be a multiple of 4.
As far as the question itself goes…
As noted in a comment, the Q&A Why are RGB values of a PixelFormat.Format48bppRgb image only from 0 to 255? should be helpful to you. Indeed, this statement has at least half of the answer to your puzzle:
GDI+ allows only values from 0 to 8192 in the color channel.
This means that when you set a pixel to, for example, red, which has a 24-bit RGB value of (255,0,0), this is extended to 48-bits by creating a value of (8192,0,0). This is different from the (65535,0,0) one might expect with 16 bits per pixel.
The other part is that the pixel channels are stored as two-byte, little-endian, 16-bit values. When you see a byte 0 (0x00), followed by a byte 32 (0x20), the way to interpret that is to store the first byte in a ushort variable, then shift the second byte left by 8 bits and combine that with the first byte in the same variable. E.g.:
byte[] redChannelBytes = { 0x00, 0x20 };
ushort redChannel = redChannelBytes[0] | (redChannelBytes[1] << 8);
Or you can just call BitConverter.ToUInt16(byte[], int)
byte[] redChannelBytes = { 0x00, 0x20 };
ushort redChannel = BitConverter.ToUInt16(redChannelBytes, 0);

Maybe I'm a bit late but I think I can add some useful info to the accepted answer.
Since gray color's 8 bits channels are midway in the range of 0 to 255, I would have expected something like 4095 or 4096, which is midway between 0 to 8192.
It's because the transformation between 'ordinary' and 'wide' pixel formats is not linear. The regular pixel formats (and the Color struct as well) represent colors with gamma correction γ = 2.2, whereas the wide pixel formats have no gamma correction (γ = 1.0).
To get the correct 13bpp level, you can use the following formula:
outputLevel = 8192 * Math.Pow(inputLevel / 255d, 1d / gamma)
which gives you 1770 for inputLevel = 128 and gamma = 0.45 (= 1 / 2.2), which is very close to 1768.
Actually Windows is cheating a bit as you can notice for low inputLevel values: the formula above gives you 0 for input levels < 5, though try SetPixel with 48/64 bpp format and low RGB color values and you can see that the raw RGB components are never zero and they are always different. So using a proper gamma correction may ridiculously cause loss of information when widening the pixel format... That's why (besides performance) I use lookup tables instead when translating colors. The linked source points to the 48-bit color transformations.
To make things even more complicated all these apply only when using GDI+ on Windows. The ReactOS implementation uses a simple linear transformation for wide formats, and also uses the full 16 bit range as opposed to the Windows' 13 bpp range. And in Mono the libgdiplus implementation simply does not support the wide formats at all.
That's why the linked source firstly checks whether to use the lookup tables. It always respects the actual underlying behavior and can also use the full 16bpp range depending on the actual GDI+ implementation. Feel free to use the library if you wish. One of the main motivations was to simplify the complexity and also to provide fast solutions for manipulating bitmaps of any PixelFormat. It also allows to access the actual underlying raw data in a managed way (see the ReadRaw/WriteRaw examples under the last link).

How to create a bitmap with 16 bits per pixel on MacOS?

I want to create a bitmap that has 16 bits per pixel, but when I specify any of the pixel formats:
PixelFormat.Format16bppArgb1555, PixelFormat.Format16bppGrayScale, PixelFormat.Format16bppRgb555, PixelFormat.Format16bppRgb565
They all throw a System.NotImplementedException with the error message "Not Implemented". I can't allocate 16 bits per pixel manually because Bitmap.SetPixel() only allows you to set a byte to alpha, red, green, or blue (so I need to use marshalling which requires a particular pixel format). Rather than setting a byte for each color value, I'm trying to distribute 16 bits between red, green, and blue. For example 5 bits for red, 5 bits for green, and 5 bits for blue.
Below is an example of one of the 16 bits per pixel pixel formats that throws a System.NotImplementedException:
Bitmap bitmap = new Bitmap(width, height, PixelFormat.Format16bppArgb1555);
My system is MacOS.

System.Drawing does not support every pixel format on all platforms. Once I collected the differences (see the Restrictions of Possible Pixel Formats on Different Platforms part). I think MacOS uses the same package as the Linux version.
As Bitmap encoders cannot save images preserving the Format16bppArgb1555 pixel format anyway I suggest you to create a Bitmap instance using the closest compatible format (for example, Format32bppArgb instead of Format16bppArgb1555), and if you really want to transform the colors into the ARGB1555 color space, you can use the Quantize method with PredefinedColorsQuantizer.Argb1555 using the same library I linked for the comparison. You can download it from NuGet.
Disclaimer: I dit not test it on MacOS but it works in Linux (Ubuntu).
Rather than setting a byte for each color value, I'm trying to distribute 16 bits between red, green, and blue. For example 5 bits for red, 5 bits for green, and 5 bits for blue.
Edit: I'm already working on the next version, which will allow using a managed bitmap data with any PixelFormat on any platform. See the public BitmapDataFactory.CreateBitmapData method (not available in a public release yet but you can already play with it if you check out the Development branch).
Update:
I have image bytes (i.e. bytes representing only an image, no header), and I'm testing to see if the format of the image the image bytes decode to is 16 bits per pixel.
Now I see why you need to set pixels in a 16-bit raw format. As in Linux/MacOS the System.Drawing.Bitmap has a limited support the easiest solution if you create managed bitmap data as I mentioned above.
Note: I published a pre-release, which makes the BitmapDataFactory.CreateBitmapData method available without checking out my development branch. And now you can turn your raw bytes of any PixelFormat to a Bitmap like this:
(of course, if pfGuess is not the actual format the result can be messy)
public Bitmap ToBitmap(byte[] rawData, PixelFormat pfGuess, Size size)
{
// the result bitmap will be ARGB32, which works on every platform
Bitmap result = new Bitmap(size.Width, size.Height);
// we create an accessor for the result so we can quickly copy the translated pixels
using var bitmapDataDst = result.GetWritableBitmapData();
// For the managed source any pixel format will work.
// Please note though that unlike System.Drawing.Bitmap images,
// managed bitmap data never has padding bytes at the end of each line.
// So if your rawData has padding (eg. when size has odd width and pf is 16bpp),
// then maybe the best if you include the padding in width.
// See https://learn.microsoft.com/en-us/windows/win32/medfound/image-stride for details
using var bitmapDataSrc = BitmapDataFactory.CreateBitmapData(size, pfGuess);
// Checking if rawData is long enough. RowSize is the width in bytes.
if (rawData.Length < bitmapDataSrc.RowSize * size.Height)
throw new ArgumentException("rawData is too short");
int currentByte = 0;
// iterating through rows
for (int y = 0; y < size.Height; y++)
{
var rowSrc = bitmapDataSrc[y]; // has the specified pixel format
var rowDst = bitmapDataDst[y]; // has ARGB32 pixel format
// writing raw pixels
for (int x = 0; x < bitmapDataSrc.RowSize; x++)
rowSrc.WriteRaw<byte>(x, rawData[currentByte++]);
// copying the pixels interpreted as pfGuess to result
for (int x = 0; x < size.Width; x++)
rowDst[x] = rowSrc[x];
}
// The result bitmap is now populated from the arbitrarily interpreted raw data.
// As it has ARGB32 format you can save it on any platform without any issues.
return result;
}

Find intersection of two images in C#

I have two images (A and B) and would like to know the rectangle intersection of the images. The images represent scrolled screen content, and I would only like the exclusive value of the images with no intersections. So A represents a capture, then B represents the same screen area but scrolled some % of the content, with additional content at the bottom. but because the scroll will not always represent an entire scroll of content (at the end, for instance)
So basically if B was only a partially scrolled view of the content, I want to reduce B so it does not contain any image data that's present in A; so when I merge A and B (and any other scrolls prior to A) they do not contain duplicate data.
This is my example image representing A and B stitched together; as you can see the content is duplicated.

There is some ambiguity here since there could be multiple intersections. By that I mean there could a 1 pixel high intersection as well as a 100 pixel high intersection. One way to resolve that ambiguity is to take the greatest intersection possible between the two images. Here's a brute force method. I'll assume the two screenshots have the same dimensions w x h.
Compare each of `h` rows of A to B.
Perform the same comparison on `h-1` rows with A's y coordinates offset by +1 (down 1).
Perform the same comparison on `h-2` rows with A's y coordinates offset by +2 (down 2).
...
Whenever the comparison succeeds, return that offset. That is the Y coordinate of A that should be stitched to the top of B.
The main issue here is performance. The worst case time is pretty bad (width * height * height) but that's if every pixel compares identical until the last one, for every row. By returning early as soon as one pixel doesn't match the performance might be practically good enough.
Comparing with memcp
Here's an easy and fast way to compare your images starting at a given Y offset.
[DllImport("msvcrt.dll", CallingConvention=CallingConvention.Cdecl)]
static extern int memcmp(IntPtr b1, IntPtr b2, long count);
static bool compareIntersection(int width, int height, int yOffset, IntPtr a, IntPtr b)
{
int bytesPerPixel = 4; // this needs to be set to reflect your image format
int bytesToRead = (height - yOffset) * width * bytesPerPixel;
IntPtr aStart = a + yOffset * width * bytesPerPixel;
return 0 == memcmp(aStart, b, bytesToRead);
}
The arguments to the function are the width of the image, height of the image, the y offset in A, and pointers into the beginning of each bitmap's memory. You can get those pointers by using Bitmap.LockBits and then BitmapData.Scan0.
The code is untested so it could have problems.

Loading raw data into a Bitmap - what have I done wrong?

I'm using c sharp, .net 4 (client profile, if that's important) and I have a byte array that contains the raw data of an image. Specifically, this image:
It is the output from the SANE test backend and the format is fully described on the SANE web site here. Incidentally, I have passed in the parameters:
depth: 8
mode: Color
and it has returned:
format: RGB
depth: 8
lines: 196
pixels per line: 157
bytes per line: 471
a byte stream that is 92316 bytes long
So, the numbers seem reasonable (196 * (157 * 471) = 92316) - three bytes (24bits) per pixel.
And from reading the SANE documentation the data is sequenced three bytes per pixel from the top left corner going left to right, top to bottom - like this (they have a better picture sorry for this ASCIItastic approach):
red,green,blue red,green,blue
-------------- --------------
byte 1 byte 2 ...
Since I know so much about the image I figured that it would be super simps to load it up into a Bitmap and I knocked up this:
var bmp = new Bitmap(157, 196, PixelFormat.Format24bppRgb);
BitmapData bmpData = bmp
.LockBits(new Rectangle(0, 0, bmp.Width, bmp.Height),
ImageLockMode.ReadWrite,
bmp.PixelFormat);
Marshal.Copy(data, 0, bmpData.Scan0, data.Length);
bmp.UnlockBits(bmpData);
but it produced this:
close, but no cigar, so to speak.
So, what have I done wrong?

The problem is that in a bitmap there is a gap between the bytes of a line and the bytes of the next line (more here).If speed is not your primary concern, you can do this much more easily with SetPixel and a loop.
EDIT:
This would give a significant speed up compared to SetPixel, but I'm afraid but you'd still have to use a loop ;)
for(int i = 0; i < bmp.Height; i++) {
Marshal.Copy(data,
i * bmp.Height,
bmpData.Scan0 + i * bmpData.Stride,
bmp.Width * 3);
}
Note that I haven't tested the code, but it should be enough to give you the idea.

Bitmap requires lines to be padded to some particular size (4 bytes, searc hor format details i.e. here ).
As result 157 pixels per line don't map exactly to binary format for bits of the bitmap and you see each next line shifted a bit. I think you need to allocate 158*3 bytes per line and copy each line from source (not exactly bitmap due to lack of padding) format to destination, filling last 3 bytes of each line with 0.

Image format conversion is going abnormally slow

I am receiving an image from an external system in the form of a sequence of BGR values followed by an empty byte. The sequence looks sort of like...
[B,G,R,0,B,G,R,0,...,B,G,R,0] where each BGR0 is a single pixel in an image.
I need this in a .NET Bitmap so I can perform some manipulations on it and have come up with the following function to do so:
private Bitmap fillBitmap(byte[] data, int width, int height)
{
Bitmap map = new Bitmap(width, height);
for (int i = 0; i < data.Length; i += 4)
{
int y = ((i / 4) / width);
int x = ((i / 4) - (y * width));
int b = data[i];
int g = data[i + 1];
int r = data[i + 2];
Color pixel = Color.FromArgb(r, g, b);
map.SetPixel(x, y, pixel);
}
return map;
}
This would normally be ok except that most of my images are 1920x1200... so I have a loop that's iterating over 2 million times. Even then that wouldn't be so bad as 2 million iterations shouldn't be very taxing on any modern processor.
But for some reason, this loop can take upwards of 5-15 seconds to run on a pretty beefy Xeon on my server. It would be trivial to parallelize the loop but I suspect there is an even better way of going about this. Any help would be greatly appreciated!

The description of the Bitmap.LockBits Method says,
You can change the color of an image with the SetPixel method, although the LockBits method offers better performance for large-scale changes.
An alternative, I'd guess, might be to use the Bitmap(Stream) Constructor, after you create a Stream which matches the file format of a bitmap.

Check some FastBitmap implementation that will help you set the array from which you will be able to generate the image.

A call to GetPixel and SetPixel makes an interop call to native functions. Each time you call one of the functions the Bitmap image is locked the corresponding pixel/bytes is modified and then the image is finally unlocked. You can imagine performing this repeatedly is highly inefficient.
As others have suggested use the LockBits method, although you will have to use unsafe code I imagine. Now if this is allowed, use it. It allows direct access to the Bitmap's pixels in an unmanaged memory buffer.