Develop Reference

GDI+ generic error saving bitmap created from memory using LockBits

The GDI+ generic error when saving a bitmap is obviously a common problem according to my research here on SO and the web. Given following simplified snippet:
byte[] bytes = new byte[2048 * 2048 * 2];
for (int i = 0; i < bytes.Length; i++)
{
// set random or constant pixel data, whatever you want
}
Bitmap bmp = new Bitmap(2048, 2048, PixelFormat.Format16bppGrayScale);
BitmapData bmpData = bmp.LockBits(new Rectangle(0, 0, 2048, 2048), ImageLockMode.ReadWrite, bmp.PixelFormat);
System.Runtime.InteropServices.Marshal.Copy(bytes, 0, bmpData.Scan0, 8388608);
bmp.UnlockBits(bmpData);
bmp.Save(#"name.bmp");
This results in the 0x80004005 generic error. The usual reason for this are said to be locks on components, but I do not see anything here I. Am I just blind? The path I am saving to exists, of course, only a empty bmp file is created (0B).
Background: I am getting pixel data from a camera driver that I transfer to .NET using a C++/CLI wrapper, so the Bitmap object above is returned by a function call. But since this small example already fails, I guess that there is nothing wrong with the adapter.
Any suggestions are highly appreciated!

Bitmap bmp = new Bitmap(2048, 2048, PixelFormat.Format16bppGrayScale);
GDI+ exceptions are rather poor, you'll have little hope to diagnose the two mistakes. The lesser one is your Save() call, it doesn't specify the ImageFormat you want to save. The default is PNG, not BMP as you hoped.
But the core one is PixelFormat.Format16bppGrayScale. When GDI+ was designed, long before .NET came around, everybody was still using CRTs instead of LCD monitors. CRTs were quite good at displaying a gamut of colors. Although good, there were no mainstream CRTs yet that were capable of display 65536 distinct gray colors. Most of all restricted by the DAC in the video adapter, the chip that converts the digital pixel value to an analog signal for the CRT. A DAC that can convert with 16-bit accuracy at 100 MHz or more wasn't technologically feasible yet. Microsoft gambled on display technology improving to make that possible someday so specified Format16bppGrayScale as a pixel format that might someday be available.
That did not happen. Rather the opposite, LCDs are significantly worse at color resolution. Typical LCD panels can only resolve 6 bits of a color rather than the 8 bits available from the pixel format. Getting to 16-bit color resolution is going to require a significant technological break-through.
So they guessed wrong and, since the pixel format isn't useful, GDI+ doesn't actually have an image encoder that can write a 16bpp grayscale image format. Kaboom when you try to save it to disk, regardless of the ImageFormat you pick.
16bpp grayscale is actually used, radiological imaging uses that pixel format. With very expensive displays to make it actually useful. Such equipment however invariable uses a custom image format to go with that, DICOM is the usual choice. GDI+ doesn't have a codec for it.
You'll need to go shopping for a library that supports the image format that your customer wants. Lead Tools is the thousand pound gorilla in that product segment.

PixelFormat.Format32bppArgb seems to work for me on Ubuntu 20 using GDI.
var bitmapdata = bitmap.LockBits(new Rectangle(0, 0, width, height), ImageLockMode.ReadOnly,
PixelFormat.Format32bppArgb);
The error I was getting was
System.ArgumentException: 'Parameter is not valid.'
at System.Drawing.SafeNativeMethods.Gdip.CheckStatus(Int32 status)
at System.Drawing.Bitmap.LockBits(Rectangle rect, ImageLockMode flags, PixelFormat format, BitmapData bitmapData)
at System.Drawing.Bitmap.LockBits(Rectangle rect, ImageLockMode flags, PixelFormat format)

Creating a custom Image display in WPF as an optimization mechanism

I am doing some image processing on a custom class representing 16 bit gray-scale images.
The intensity of the pixels is stored in a single dimension ushort array: ushort[] data
I also have the width, the height, the dpi, the stride, if necessary.
My motivation is the following: I show the results of certain operations quite fast, but the conversion from the array to the bitmapsource to the image object is too lengthy, so I was thinking of an Image object which drew its "source" directly from the array. I could thus write a method "update()" instead of doing multiple conversions.
1/ Is this possible?
2/ Would it be faster?
3/ How would I go about doing it?
The way I currently draw the image is with the following code (there's a bit more to that, but essetially that the heart of it)
BitmapSource bmps = BitmapSource.Create(Width, Height, Dpi, Dpi, PixelFormats.Gray16, null,
data, stride);
image.Source=bmps;
Thank you!

Instead of using a separate array to store pixels and then creating a BitmapSource to show the results, I think it would be better using a WriteableBitmap, this way you can store pixel data (16-bit greyscale values) directly in its BackBuffer. Thus you can code something like this:
// You create "bmp" just once and then update its content when needed
var bmp = new WriteableBitmap(640, 480, 96, 96, PixelFormats.Gray16, null);
var imgRect = new Int32Rect(0, 0, bmp.PixelWidth, bmp.PixelHeight);
Then you update the image:
bmp.Lock();
ApplySomeFilter(bmp.BackBuffer, ImageFilter.Blur); // this is just an example ;)
bmp.AddDirtyRect(imgRect);
bmp.Unlock();
The ApplySomeFilter method can use unsafe code to modify pixel data of the WriteableBitmap.
For example, if ApplySomeFilter is defined like this:
unsafe public void ApplySomeFilter(void* imgBuffer, ImageFilter filter)
{
// code that modifies pixels goes here
}
then you can call it this way:
ApplySomeFilter(bmp.BackBuffer.ToPointer(), ImageFilter.Blur);

Sprite/Texture Atlas: GDI+ Bitmap.MakeTransparent for color-key with OpenTK

I am writing a support class for sprite/texture atlas functionality, using C# with OpenTK.
Most functionality is working fine thus far (simple 2D tiles on an orthographic view).
My problem relates to unexpected display results when calling the GDI+ Bitmap.MakeTransparent() method to set a color (Magenta / 0xFFFF00FF) for use as a color-key.
It would seem that I am using incorrect pixel format parameters for the bitmap.LockBits() and GL.TexImage2D() calls. My code was based on examples which indeed worked, but which had in common that the rectangle passed to LockBits() was for the entire image.
The calls which pertain to this process are:
<!-- language: C# -->
Bitmap bitmap = new Bitmap(filename);
bitmap.MakeTransparent(Color.Magenta);
GL.GenTextures(1, out texture_id);
GL.BindTexture(TextureTarget.Texture2D, texture_id);
// "rect" is initialized for one of:
// - the dimensions of the entire image
// (0, 0, bitmap.width, bitmap.height)
// - the dimensions for a sub-rectangle within the image (for one tile)
// (tile_x * tile_width, tile_y * tile_height, tile_width, tile_height)
// I observe different behaviors for a sub-rectangle,
// as compared to the entire image, when in combination with
// the .MakeTransparent() call.
//
// This code is in a load_tile() method, and the plan was to make
// multiple calls per image file, one per tile to extract as a GL texture.
// Without transparency, that worked fine.
Rectangle rect = new Rectangle(xx, yy, width, height);
BitmapData data = bitmap.LockBits(rect,
ImageLockMode.ReadOnly,
System.Drawing.Imaging.PixelFormat.Format32bppRgb);
// In the absence of calling bitmap.MakeTransparent(),
// images loaded and displayed as expected with Format24bppRgb.
// With MakeTransparent() and Format32bppRgb, the results seem to be OS-dependent.
// (At first I thought the "correct" combination to be found,
// but then found that the results were "right" only under Windows 7.)
GL.TexImage2D(
OpenTK.Graphics.OpenGL.TextureTarget.Texture2D, // texture_target,
0, // level,
OpenTK.Graphics.OpenGL.PixelInternalFormat.Rgba, // internal_format
data.Width, data.Height, // width, height,
0, // border,
OpenTK.Graphics.OpenGL.PixelFormat.Bgra, // pixel_format
OpenTK.Graphics.OpenGL.PixelType.UnsignedByte, // pixel_type
data.Scan0 // pixels
);
// Certainly the internal_format and pixel_format arguments are pertinent,
// but other combinations I have tried produced various undesired display results.
// After reading various (OpenGL, OpenTK, and GDI+) docs, still I am not enlightened..
bitmap.UnlockBits(data);
I have tested a small demo using the code above on different boxen, and observe these results:
Windows 7 box: magenta pixels act as transparent (the desired result)
Windows XP box: magenta pixels rendered as black
Ubuntu Linux box: magenta pixels rendered as magenta
This surprises me, as I anticipated that (GDI+ and OpenGL and the OpenTK bindings) would act the same on different boxes.
To the extent that I have absorbed the GDI+ and OpenGL / OpenTK API documentation, I think my puzzlement relates to these two points:
What is a correct way of calling MakeTransparent() + LockBits() + GL.TexImage2D(), so as to result in the specified color being rendered as transparent?
Why do I see strange display results (as if the "stride" was mis-calculated) for certain pixel format parameter combinations, when LockBits() is called for a sub-rectangle rather than the entire image?
Update:
I have whittled down my code into a small project on Github:
https://github.com/sglasby/OpenGL_Transparent_Sprite
Also, I stumbled upon a parameter combination that works
(arg 3 of LockBits() is Format32bppPArgb),
though it is not clear why it works, given that the documentation implies another pixelformat is wanted:
http://msdn.microsoft.com/en-us/library/8517ckds.aspx
(which states that the bitmap will be in Format32bppArgb after calling MakeTransparent).

While this is a separate issue to your question, in most cases you should actually use premultiplied-alpha (Format32bppPArgb). If this format is working correctly, then understanding why Format32bppArgb does not work is mostly an academic exercise.
I ran your example project on Win7 with an Intel 2000HD and got the following results:
Format32bppPArgb works correctly
Format32bppRgb works correctly
Format32bppArgb is scrambled
On further investigation, this does not appear to be linked to OpenGL, but rather to the way Bitmap.LockBits works.
Check the values of data.Stride on the debugger for each approach:
Format32bppPArgb has a stride of 128 (4x the bitmap width, correct)
Format32bppRgb has a stride of 128 (4x the bitmap width, correct)
Format32bppArgb has a stride of 512 (16x the bitmap width, ?)
MSDN does not turn up something useful here. At this point, I cannot tell why this is happening. I'll update this answer if I manage to uncover anything.
Edit: lo and behold, if you force the correct stride when unpacking the data, the output looks correct:
GL.PixelStore(PixelStoreParameter.UnpackRowLength, data.Width * 4); // 4x for 32bpp

Bitmap.LockBits usage causing AccessViolation?

I have some code that copies a Bitmap into a Direct3D Texture for rendering video. When the system is under heavy load, I get occasional AccessViolationException's on the call to Bitmap.LockBits.
Here is a very simple example of what happens:
// Get a PixelFormat.Format24bppRgb image
Bitmap bitmap24 = getVideoFrame();
// Copy into a 32bpp ARGB texture
BitmapData bitmapData = null;
try
{
// Why am I allowed to do this?
bitmapData = this.bitmap24.LockBits(new Rectangle(0, 0, bitmap.Width, bitmap.Height),
ImageLockMode.ReadOnly,
PixelFormat.Format32bppArgb);
// Blit from bitmapData to texture32
Texture texture32 = convertBitmapToTexture(bitmapData);
}
finally
{
if (bitmapData != null)
this.bitmap.UnlockBits(bitmapData);
}
Why am I allowed to call Bitmap.LockBits and pass in PixelFormat.Format32bppArgb when I know that the bitmap format is PixelFormat.Format24bppRgb? I assume that LockBits must automagically expand from 3 bytes per pixel to 4.
Could the LockBits expansion be causing these exceptions? Why would it only happen occasionaly?

LockBits will store the bitmap in memory in whatever format you specify.
AccessViolationException occurs when you're accessing memory you aren't supposed to be accessing. I can think of two scenarios where this will happen:
1) You're using ImageLockMode.ReadOnly.. is there anywhere you're actually trying to change a value of a pixel? Perhaps try changing this to ImageLockMode.ReadWrite and see if that helps.
2) You've confused yourself about how big your buffer must be and you have a Marshal.Copy in your convertBitmapToTexture function that is attempting to copy past the end of your buffer.
It might be easier for you to think in terms of int's instead of bytes when you're using 32bppArgb. That way you'll be less likely to run into any confusion.

Copy one Bitmap onto a larger Bitmap using without using Graphics.DrawImage

This is a follow up from Rendering to a single Bitmap object from multiple threads
What im trying to achieve is to take a bitmap of say 50x50 pixels and draw it onto a larger bitmap(100x100 pixels) at any point on the larger image, using the bitmaps LockBits function or any other but NOT graphics.DrawImage. My reasons for not wanting to use DrawImage is stated in the other thread.
I have managed to get something by using Marshal.Copy from the source BitmapData to the dest BitmapData but its creating a tiled, stretched image horizontally.

You could manipulate the image in memory without relying on any system calls. If you dig into the underlying format of a .BMP file you could build your own Device Independant Bitmap class that truly "understands" the low level format of a .BMP.
For example a 8 bit per pixel image is essentially a 2 dimensional array of bytes (each byte is 1 pixel) plus a simple color table. Roughly speaking (and this is very very rough):
byte[,] bColors = new byte[3,256]; // 256 RGB colors
byte[,] bImage = new byte[25,50]; // 25 x 50 pixels
The trick is (as always) getting a hold of the raw pixel data, doing the processing, and then updating the raw pixel data with your changes.
In the past I've approached this by converting a GDI HBITMAP into a 24bpp DIB, doing my funky image processing on the raw pixels (3 bytes per pixels makes this easier), then converting the DIB back into a HBITMAP. This was all using just classic GDI (pre GDI+ even, let alone C#).
Using that approach you could design a control structure to allow multiple writers to different sections of your much bigger image.
However... the lowlevel BitBlt GDI calls are likely to be way more efficient that anything you can do. If I were you I'd make certain that just doing 50 or 100 bitblt's in a row would be too slow (you'd likely need to do this in c++).
The most annoying challenges with dealing with DIB's are:
Converting a DIB to an actual "image" ready for display and
Converting an actual "image" into a DIB
Saving a DIB as something other than a .BMP
Core references when I started learning the "horror" that images actually are:
http://msdn.microsoft.com/en-us/library/dd183562(VS.85).aspx
http://msdn.microsoft.com/en-us/library/dd144879(VS.85).aspx
http://msdn.microsoft.com/en-us/library/dd162973(VS.85).aspx
How you go about getting to/from .NET Image's... well... that's a good question :)

This should work just fine using LockBits/BitmapData, if you are using a 32bpp [P]ARGB pixel format. The trick is that you will have to copy the data one row at a time so that it aligns in the correct places. You should be able to do this using something like:
Rectangle srcArea = new Rectangle(0, 0, srcBitmap.Width, srcBitmap.Height);
BitmapData srcData = srcBitmap.LockBits(srcArea, ImageLockMode.ReadOnly, destBitmap.PixelFormat);
Rectangle destArea = new Rectangle(25, 25, srcBitmap.Width, srcBitmap.Height);
BitmapData destData = destBitmap.LockBits(destArea, ImageLockMode.WriteOnly, destBitmap.PixelFormat);
IntPtr srcPtr = srcData.Scan0;
IntPtr destPtr = destData.Scan0;
byte[] buffer = new byte[srcData.Stride];
for (int i = 0; i < srcData.Height; ++i)
{
Marshal.Copy(srcPtr, buffer, 0, buffer.Length);
Marshal.Copy(buffer, 0, destPtr, buffer.Length);
srcPtr += srcData.Stride;
destPtr += destData.Stride;
}
srcBitmap.UnlockBits(srcData);
destBitmap.UnlockBits(destData);
As a warning, this code won't work as is because I am not sure what the right incantations are for incrementing IntPtr's. I've done this same type of thing before, but in C++. Also, I don't know if there is a way to directly copy the data instead of using an intermediate buffer.
An additional caveat: the LockBits call srcBitmap and the sizing of the buffer assume that srcBitmap will be completely enclosed in destBitmap. If this is not the case (some part of the bitmap will be cropped off) the area locked and the size of the buffer will need to be adjusted.
If you are not using a 32bpp pixel format (ie 24bpp), it will be more difficult. The stride of your source BitmapData may include some amount of padding that should not be copied. You could work around this by calculating the amount of actual pixel data in a source row, and copy this amount. Indexed pixel formats would be even more work.

I would recommend taking a look at the internal bitmap memory structure.
The best approach, I think, would be to not try to set the BitmapData directly. Instead, I would make a single, shared byte array of the appropriate size, and set the byte array directly from your smaller images.
When you compose your larger image, you can take the final byte array and directly make a Bitmap from the byte data.
This has the advantage of allowing you to control the memory management, thread the operations, etc, as you seemed to want to do in your original post. It should be very fast for the data access, as well.