Parameter is not valid error on bitmap constructor - c#

I know, I know... there are many others posts like this. I didn't find what I was look for, let's move on.
I break a PDF into images using this GhostScript implementation for C# and then try to load each image into a Bitmap, sometimes it gives me a Parameter is not valid error on this line:
[...]new Bitmap((Image)Image.FromFile(imagePath))[...]
Image.FromFile(imagePath) successfully returns an Image (though I think it's returning a Bitmap) but then Bitmap's constructor gives me the error. What am I doing wrong?
P.S.
I'm casting the result to Image because when I quick watch the result of Image.FromFile(...) it shows it as a System.Drawing.Bitmap (either way, cast, no cast, yields the same result).

You shouldn't create a new bitmap from the bitmap, just cast the reference to the bitmap that you have already:
Bitmap b = (Bitmap)Image.FromFile(imagePath);
If you create a new bitmap from the bitmap that you load from the file, you don't get any reference to the bitmap that you loaded. As you can't dispose that bitmap you will leave them for the garbage collector to finalise, and if that doesn't happen fast enough you may run out of memory.

Try using the Bitmap constructor that receives a path to the image like so:
var b = new Bitmap(imagePath);

Related

Bitmap LockBits, UnlockBits calling performance

I'm working on an application where the performance is very important. This application requires lots of image processing so, as most of us know that Bitmap's pixels accessing using GDI+ methods GetPixel and SetPixel is quite slow. To solve this issue we use Bitmap.LockBits and Bitmap.UnlockBits methods and i'm totally aware of how to access pixels using this method but my question is:
What is the performance of both Bitmap.LockBits and Bitmap.UnlockBits ? Do they perform any pixels copying or something that may have non-linear order?
I'm asking this question because I found a lots of calling for Bitmap.LockBits and Bitmap.UnlockBits methods in my code. I made a search but I didn't find anything
LockBits method returns BitmapData object, which is used to describe the memory sector.
BitmapData _bmd = _bmp.LockBits(new Rectangle(0, 0, _bmp.Width,_bmp.Height) , ImageLockMode ReadWrite, _bmp.PixelFormat);
Take a look here http://www.mfranc.com/programming/operacje-na-bitmapkach-net-1/
Update:
Lockbits will copy the bitmap data from a bitmap to a location in memory that is ready to be read/written to. The lockbits function will give you Scan0 that is a pointer to the start of this bitmap data.So it involves copying but even that would be much faster when compared to the Normal GDI+ Operation as per the comparison chart above.Also look out for out of bound memory .

Properly dispose of non referenced Image without garbage collection C#

I have a C# program which creates a List of Bitmaps from the images in a directory. It'll use the whole list of Bitmaps to generate one new image, which it will then save. When the user loads a new directory to repeat the process, the List of Bitmaps is cleared and refilled. The bitmaps are loaded upon creation of the object, "new Bitmap(path)".
I had a problem which occurred when the user performed the following steps:
Load images from directory 1
Chose not to save and instead load images from directory 2
Tries to save by overwriting an image from directory 1
Program is unable to save due to "A generic error in GDI+", because it is still "using" the image that is being overwritten.
The original List of Bitmaps loaded from directory 1 is indeed cleared and then refilled with images from directory 2. However, Bitmap.Save() refuses to overwrite an image it had previously loaded unless I call System.GC.Collect() after I perform Clear().
I'm pretty sure the problem has something to do with keeping the Bitmaps around even though there are no references, otherwise why would garbage collecting solve the problem? Is this the right way to go about solving this problem, or is there a "proper" way to dispose of Bitmaps in C#? Thanks.
You need to call Dispose on the Bitmap instances.. so they free their file handle.
var bitmap = new Bitmap(path_to_file);
// use it
bitmap.Dispose();
Or, since Bitmap inherits from Image which implements IDisposable, you can do this:
using (var bitmap = new Bitmap(path_to_file)) {
// use it..
}

ImageList: Disposing the original image removes it from the list

ImageList should create a copy of all images that are inserted into it. Therefore it should be safe to dispose the originals after adding them to the list.
Why does the following testcase fail?
Bitmap test = new Bitmap(128, 128);
ImageList il = new ImageList();
il.Images.Add(test);
Assert.AreEqual(1, il.Images.Count); // OK, image has been inserted
test.Dispose(); // now let's dispose the original
try
{
var retrievalTest = il.Images[0];
}
catch (ArgumentException) // ... but this Exception happens!
{
}
Assert.AreEqual(1, il.Images.Count); // and this will fail
What seems to happen here is this: When trying to retrieve the image, the ImageList discovers that the original has been disposed, and removes it from the ImageList.
Why is that happen, I thought the ImageList is supposed to create a copy of the image?
Yes, ImageList creates a copy of the bitmap. But your test code runs afoul of the famous lazy initialization pattern that's so common in the .NET framework. What matters is when it creates the copy. Which is does only when it has to. Make a small change in your code to hurry that up:
il.Images.Add(test);
var dummy = il.Handle; // <== NOTE: added
test.Dispose(); // no problem
And you'll see that disposing is no longer a problem.
Not sure how to give proper advice here, the code is too synthetic. This in general works well enough, ImageList makes the copy when its consumers start using its bitmaps, Treeview or ListView. In general, avoid using ImageList as a collection object, it wasn't made to do that job. Separate the view from the model and you'll stay out of trouble.
ImageList should create a copy of all images that are inserted into
it.
I don't see any indication in the documentation, that it does. So the simple answer is: your assumption is wrong.

How to get the bitmap from a Graphics object in C#?

How do you get a bitmap from a graphics object (or at least a pointer to it's Scan0)?
If a graphics object really always refers to a bitmap, then it IS possible to get to the bitmap data from the graphics object. (Think: the graphics object HAS TO have a pointer to the bmp data. I'd code it in C but I'm on a project that requires everyone be hobbled by .NET.)
Applications of this would include things like:
- using unsafe code to obtain faster screenshots
- modifying what's on a control using CreateGraphics
- (and the task I'm actually trying to accomplish which would take too long to explain)
Yes, this has been asked before but never answered. I'm not looking for how to get a graphics object from a bitmap (obviously trivial).
FAIL1, FAIL2, FAIL3, FAIL4, FAIL5, FAIL6, FAIL7
I don't think what you're trying to do is possible since your assumption that "a graphics object really always refers to a bitmap" is false.
There's a good article here that shows how to render a control to bitmap if you really want a bitmap and another one here that shows how to quickly update the screen at the WndProc level. If you're more familiar with C++ that might get you going the right direction.

Efficient image manipulation in C#

I'm using the System.Drawing classes to generate thumbnails and watermarked images from user-uploaded photos. The users are also able to crop the images using jCrop after uploading the original. I've taken over this code from someone else, and am looking to simplify and optimize it (it's being used on a high-traffic website).
The previous guy had static methods that received a bitmap as a parameter and returned one as well, internally allocating and disposing a Graphics object. My understanding is that a Bitmap instance contains the entire image in memory, while Graphics is basically a queue of draw operations, and that it is idempotent.
The process currently works as follows:
Receive the image and store it in a temporary file.
Receive crop coordinates.
Load the original bitmap into memory.
Create a new bitmap from the original, applying the cropping.
Do some crazy-ass brightness adjusting on the new bitmap, maybe (?) returning a new bitmap (I'd rather not touch this; pointer arithmetics abound!), lets call this A.
Create another bitmap from the resulting one, applying the watermark (lets call this B1)
Create a 175x175 thumbnail bitmap from A.
Create a 45x45 thumbnail bitmap from A.
This seems like a lot of memory allocations; my question is this: is it a good idea to rewrite portions of the code and reuse the Graphics instances, in effect creating a pipeline? In effect, I only need 1 image in memory (the original upload), while the rest can be written directly to disk. All the generated images will need the crop and brightness transformations, and a single transformation that is unique to that version, effectively creating a tree of operations.
Any thought or ideas?
Oh, and I should probably mention that this is the first time I'm really working with .NET, so if something I say seems confused, please bear with me and give me some hints.
Reusing Graphics objects will probably not result in significant performance gain.
The underlying GDI code simple creates a device context for the bitmap you have loaded in RAM (a Memory DC).
The bottleneck of your operation appears to be in loading the image from disk.
Why reload the image from disk? If it is already in a byte array in RAM, which it should be when it is uploaded - you can just create a memory stream on the byte array and then create a bitmap from that memory stream.
In other words, save it to the disk, but don't reload it, just operate on it from RAM.
Also, you shouldn't need to create a new bitmap to apply the watermark (depending on how it'd done.)
You should profile the operation to see where it needs improvement (or even if it needs to be improved.)
The process seems reasonable. Each image has to exist in memory before it is saved to disk - so each version of your thumbnails will be in memory first. The key to making sure this works efficiently is to Dispose your Graphics and Bitmap objects. The easiest way to do that is with the using statement.
using( Bitmap b = new Bitmap( 175, 175 ) )
using( Graphics g = Graphics.FromBitmap( b ) )
{
...
}
I completed a similar project a while ago and did some practical testing to see if there was a difference in performance if I reused the Graphics object rather than spin up a new one for every image. In my case, I was working on a steady stream of large numbers of images (>10,000 in a "batch"). I found that I did get a slight performance increase by reusing the Graphics object.
I also found I got a slight increase by using GraphicsContainers in the Graphics object to easily swap different states into/out of the object as it was used to perform various actions. (Specifically, I had to apply a crop and draw some text and a box (rectangle) on each image.) I don't know if this makes sense for what you need to do. You might want to look at the BeginContainer and EndContainer methods in the Graphics object.
In my case, the difference was slight. I don't know if you would get more or less improvement in your implementation. But since you will incur a cost in rewriting your code, you might want to consider finishing the current design and doing some perf tests before rewriting. Just a thought.
Some links you might find useful:
Using Nested Graphics Containers
GraphicsContainer Class
I am only going to throw this out there casually, but if you wanted a quick 'guide' to best practices for working with images, look at the Paint.NET project. For free high-proformance tools for doing image manipulation, look at AForge.NET.
The benefit of AForge is to allow you to do alot of these steps without creating a new bitmap every time. If this is for a website, I can almost guarentee that the code you are working with will be the performance bottleneck for the application.

Categories