Converting image to byte array

[Luis Arvayo]

Hello,

I am trying to convert a jpeg image stored in a PictureBox to a byte array
in order to later save it to a database, but I get this error : "Generic
Error in GDI+".

The source code is the following (when clicking in a button):

MemoryStream ms = new MemoryStream();
pictureBox1.Image.Save(ms, System.Drawing.Imaging.ImageFormat.Jpeg); //
<-- Error is here
byte[] data = new byte[ms.Length];
ms.Position = 0;
ms.Read(data, 0, (int)ms.Length);
...save the array to a database

The image inside the PictureBox was obtained from a jpeg file the following
way (when clicking other button and by using a OpenFileDialog in order to
define the source file):

pictureBox1.Image = Image.FromFile(openFileDialog1.FileName);

Is there something I am doing wrong ?. In fact, sometimes the error does not
raise, but when I try to draw an image in some control, the image is not
displayed. It seems that GDI+ was kept in a corrupted state.

Does anyone have any hint ?

Thanks in advance
Luis A.

 

[Guest]

Hi Luis,
I just ran the extact code you had and it compiled and executed perfectly,
I read an image into the byte array. Verify that the images you are trying
to load can be opended in other applications. Was there any more information
along with the exception that was thrown?

Mark.

 

[Robbe Morris [C# MVP]]

http://www.eggheadcafe.com/PrintSearchContent.asp?LINKID=799

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net

Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

 

[Jon Skeet [C# MVP]]

http://www.eggheadcafe.com/PrintSearchContent.asp?LINKID=799

I'm not keen on that code, I'm afraid. Calling Close manually rather
than with a using statement means that the stream isn't closed if an
exception is thrown - not a problem for a MemoryStream, but not a good
idea in general.

Then there's the:

try
{
// Stuff
}
catch (Exception e)
{
throw e;
}

What's the point of catching it if you're just going to throw it? All
that does is get rid of potentially useful bits of the stack trace.


Then there's using Image.FromStream - the docs say that you must keep
the stream open while the image is in use, but you close the stream
immediately. You're also giving it a stream which is positioned at the
*end* of the data rather than at the beginning - I believe there should
be:

oStream.Position = 0;

after the call to Write and before the call to Image.FromStream.

(MS naming conventions also suggest using camel casing for parameter
names, but that's just a minor nit-pick.)

Finally - I'm not sure how this helps the OP, who had equivalent code
for the relevant section, namely the call to Image.Save...

 

[Robbe Morris [C# MVP]]

Good point on the try/catch block. I didn't pay much
attention to that when I posted the code block awhile ago.

As for the other items, that code (with correct try/catch)
and using works quite well in my production apps. I use
it largely for comitting chart images to and from cache.

I posted it just assuming the original poster might
need to perform both actions.

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net

Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

 

[Jon Skeet [C# MVP]]

Good point on the try/catch block. I didn't pay much
attention to that when I posted the code block awhile ago.

As for the other items, that code (with correct try/catch)
and using works quite well in my production apps. I use
it largely for comitting chart images to and from cache.

That doesn't mean it's correct though. I suspect it entirely depends on
what you do with the image. Here's a test method (I've made your
methods static):

static void Main()
{
Image original = Image.FromFile ("test.jpg");
byte[] bytes = ConvertImageToByteArray(original);
Image converted = ConvertByteArrayToImage(bytes);
Image thumb = converted.GetThumbnailImage
(100, 100, null, new IntPtr(0));
}

All is fine until you ask for the thumbnail - at which point things go
wrong, with your code as it currently is. If you don't close the
stream, however, everything's fine. Even if it works for your cases,
doing something which goes against what the documentation specifically
requires seems a bad idea to me.

I'm still surprised that it works without repositioning the stream, but
maybe that's just something it does internally automatically. Bit of a
shame, in a way, as it presumably means you can't have a seekable
stream which contains some other data and *then* the image data..

I posted it just assuming the original poster might
need to perform both actions.

Unfortunately the problem was performing just the one action to start
with

 

[Robbe Morris [C# MVP]]

I only use ConvertByteArrayToImage in one place and it doesn't really try
to do anything with the image afterwards. Thus, I never saw issues with
this.

That said, I hate to have tips out there that aren't accurate. It is
correct now.

--
2004 and 2005 Microsoft MVP C#
Robbe Morris
http://www.masterado.net


Earn $$$ money answering .NET Framework
messageboard posts at EggHeadCafe.com.
http://www.eggheadcafe.com/forums/merit.asp

Good point on the try/catch block. I didn't pay much
attention to that when I posted the code block awhile ago.

As for the other items, that code (with correct try/catch)
and using works quite well in my production apps. I use
it largely for comitting chart images to and from cache.

That doesn't mean it's correct though. I suspect it entirely depends on
what you do with the image. Here's a test method (I've made your
methods static):

static void Main()
{
Image original = Image.FromFile ("test.jpg");
byte[] bytes = ConvertImageToByteArray(original);
Image converted = ConvertByteArrayToImage(bytes);
Image thumb = converted.GetThumbnailImage
(100, 100, null, new IntPtr(0));
}

All is fine until you ask for the thumbnail - at which point things go
wrong, with your code as it currently is. If you don't close the
stream, however, everything's fine. Even if it works for your cases,
doing something which goes against what the documentation specifically
requires seems a bad idea to me.

I'm still surprised that it works without repositioning the stream, but
maybe that's just something it does internally automatically. Bit of a
shame, in a way, as it presumably means you can't have a seekable
stream which contains some other data and *then* the image data..

I posted it just assuming the original poster might
need to perform both actions.

Unfortunately the problem was performing just the one action to start
with