Out of Memory Exception on DrawImage

Discussion:

(too old to reply)

unknown

2004-11-10 13:50:25 UTC

Hi All,

I am getting an out of memory exception error calling Graphics.DrawImage on
a 12 Mb file in an ASP.NET app.

I am croping and resizing using the function (below)

My machine is a new and fast hyperthreaded pent 4, 1Gb ram, this should
work?
I can open the file in paint and view it in the windows previewer without a
problem.

The Jpeg file is created by converting a PDF to Jpeg using ghostscript at
600 DPI.
If I RIP the file at 300 DPI, obviously a smaller JPeg is created, which
works fine.

Any ideas would be greatly appreciated.
Thanks,

Mark

public static Image Crop(Image sourceImage, int x, int y, int width, int
height, int targetWidth, int targetHeight)

{

Bitmap bmpSource = new Bitmap(targetWidth, targetHeight,
PixelFormat.Format32bppArgb);

bmpSource.SetResolution(72, 72);

Graphics gdiSource = Graphics.FromImage(bmpSource);

try

{

gdiSource.InterpolationMode = InterpolationMode.HighQualityBicubic;

gdiSource.DrawImage(sourceImage,

new Rectangle(0, 0, targetWidth, targetHeight), // Resulting cropped image
size

new Rectangle(x, y, width, height), // Selected part of source image

GraphicsUnit.Pixel);

}

finally

{

gdiSource.Dispose();

}

return bmpSource;

}

Bob Powell [MVP]

2004-11-10 15:39:26 UTC

Permalink

The size of a jpeg file has very little relationship to the final size of
the raster generated when the file is decompressed.

The file is just filling the memory.

Remember that the memory load will be calculated as ImgX * ImgY *
(pixelDepth/8) so a 1024 * 768 * 32bpp image will require 3145728 bytes
regardless of the JPEG file size.

I suspect a 12 meg jpeg is going to be a very large raster indeed.
--
Bob Powell [MVP]
Visual C#, System.Drawing

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm

The GDI+ FAQ RSS feed: http://www.bobpowell.net/faqfeed.xml
Windows Forms Tips and Tricks RSS: http://www.bobpowell.net/tipstricks.xml
Bob's Blog: http://bobpowelldotnet.blogspot.com/atom.xml

Post by unknown
Hi All,
I am getting an out of memory exception error calling Graphics.DrawImage on
a 12 Mb file in an ASP.NET app.
I am croping and resizing using the function (below)
My machine is a new and fast hyperthreaded pent 4, 1Gb ram, this should
work?
I can open the file in paint and view it in the windows previewer without a
problem.
The Jpeg file is created by converting a PDF to Jpeg using ghostscript at
600 DPI.
If I RIP the file at 300 DPI, obviously a smaller JPeg is created, which
works fine.
Any ideas would be greatly appreciated.
Thanks,
Mark
public static Image Crop(Image sourceImage, int x, int y, int width, int
height, int targetWidth, int targetHeight)
{
Bitmap bmpSource = new Bitmap(targetWidth, targetHeight,
PixelFormat.Format32bppArgb);
bmpSource.SetResolution(72, 72);
Graphics gdiSource = Graphics.FromImage(bmpSource);
try
{
gdiSource.InterpolationMode = InterpolationMode.HighQualityBicubic;
gdiSource.DrawImage(sourceImage,
new Rectangle(0, 0, targetWidth, targetHeight), // Resulting cropped image
size
new Rectangle(x, y, width, height), // Selected part of source image
GraphicsUnit.Pixel);
}
finally
{
gdiSource.Dispose();
}
return bmpSource;
}

unknown

2004-11-10 16:58:39 UTC

Permalink

Hi Bob,

Thanks for the reply,

I do initially read in the file to create a thumbnail, and get the height
and width of the jpeg, this is done in another process(windows service which
RIPS the file using ghostscript) before the function to crop/size the image
is called (asp.net web application) This does not cause any errors.

The size of the jpeg is (7017 x 9925) so yes, if the pixel depth is 32bpp
(is this the default), it will use:
278,574,900 bytes. The size of the image that DrawImage is going to draw to
will generally be less than 1024 x 768 as its actually a viewable area on
the screen. so 265 odd Mb + 3 Mb should be ok on a machine with 1Gb. Are
these calcs correct?

I have seen a couple of posts (various google / tamaracka.com searches)
indicating the memory problem in a asp.net app an not in a winforms app, can
you comment on this, or could this be a red herring.

I only get the error when gdiSource.DrawImage(sourceImage,..... is called,
at this point would the images already be in memory, or am I missing the
point here, not knowing the concepts behind how these functions work
internally?

Thanks

Mark

Post by Bob Powell [MVP]
The size of a jpeg file has very little relationship to the final size of
the raster generated when the file is decompressed.
The file is just filling the memory.
Remember that the memory load will be calculated as ImgX * ImgY *
(pixelDepth/8) so a 1024 * 768 * 32bpp image will require 3145728 bytes
regardless of the JPEG file size.
I suspect a 12 meg jpeg is going to be a very large raster indeed.
--
Bob Powell [MVP]
Visual C#, System.Drawing
Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm
The GDI+ FAQ RSS feed: http://www.bobpowell.net/faqfeed.xml
Windows Forms Tips and Tricks RSS: http://www.bobpowell.net/tipstricks.xml
Bob's Blog: http://bobpowelldotnet.blogspot.com/atom.xml

Post by unknown
Hi All,
I am getting an out of memory exception error calling Graphics.DrawImage

Post by unknown
a 12 Mb file in an ASP.NET app.
I am croping and resizing using the function (below)
My machine is a new and fast hyperthreaded pent 4, 1Gb ram, this should
work?
I can open the file in paint and view it in the windows previewer

without

Post by Bob Powell [MVP]
a

Post by unknown
problem.
The Jpeg file is created by converting a PDF to Jpeg using ghostscript at
600 DPI.
If I RIP the file at 300 DPI, obviously a smaller JPeg is created, which
works fine.
Any ideas would be greatly appreciated.
Thanks,
Mark
public static Image Crop(Image sourceImage, int x, int y, int width, int
height, int targetWidth, int targetHeight)
{
Bitmap bmpSource = new Bitmap(targetWidth, targetHeight,
PixelFormat.Format32bppArgb);
bmpSource.SetResolution(72, 72);
Graphics gdiSource = Graphics.FromImage(bmpSource);
try
{
gdiSource.InterpolationMode = InterpolationMode.HighQualityBicubic;
gdiSource.DrawImage(sourceImage,
new Rectangle(0, 0, targetWidth, targetHeight), // Resulting cropped image
size
new Rectangle(x, y, width, height), // Selected part of source image
GraphicsUnit.Pixel);
}
finally
{
gdiSource.Dispose();
}
return bmpSource;
}

Bob Powell [MVP]

2004-11-10 22:21:42 UTC

Permalink

GDI+ opens the file, reads the headers and then does nothing until the image
is needed for drawing or other manipulation. The behaviour you are seeing is
consistent with having simply overloaded the system.
--
Bob Powell [MVP]
Visual C#, System.Drawing

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm

The GDI+ FAQ RSS feed: http://www.bobpowell.net/faqfeed.xml
Windows Forms Tips and Tricks RSS: http://www.bobpowell.net/tipstricks.xml
Bob's Blog: http://bobpowelldotnet.blogspot.com/atom.xml

Post by unknown
Hi Bob,
Thanks for the reply,
I do initially read in the file to create a thumbnail, and get the height
and width of the jpeg, this is done in another process(windows service which
RIPS the file using ghostscript) before the function to crop/size the image
is called (asp.net web application) This does not cause any errors.
The size of the jpeg is (7017 x 9925) so yes, if the pixel depth is 32bpp
278,574,900 bytes. The size of the image that DrawImage is going to draw to
will generally be less than 1024 x 768 as its actually a viewable area on
the screen. so 265 odd Mb + 3 Mb should be ok on a machine with 1Gb. Are
these calcs correct?
I have seen a couple of posts (various google / tamaracka.com searches)
indicating the memory problem in a asp.net app an not in a winforms app, can
you comment on this, or could this be a red herring.
I only get the error when gdiSource.DrawImage(sourceImage,..... is called,
at this point would the images already be in memory, or am I missing the
point here, not knowing the concepts behind how these functions work
internally?
Thanks
Mark

http://www.bobpowell.net/tipstricks.xml

Post by unknown

Post by Bob Powell [MVP]
Bob's Blog: http://bobpowelldotnet.blogspot.com/atom.xml

Post by unknown
Hi All,
I am getting an out of memory exception error calling

Graphics.DrawImage

Post by unknown

Post by Bob Powell [MVP]
on

without

Post by Bob Powell [MVP]
a

Post by unknown
problem.
The Jpeg file is created by converting a PDF to Jpeg using ghostscript

Post by Bob Powell [MVP]

Post by unknown
600 DPI.
If I RIP the file at 300 DPI, obviously a smaller JPeg is created, which
works fine.
Any ideas would be greatly appreciated.
Thanks,
Mark
public static Image Crop(Image sourceImage, int x, int y, int width, int
height, int targetWidth, int targetHeight)
{
Bitmap bmpSource = new Bitmap(targetWidth, targetHeight,
PixelFormat.Format32bppArgb);
bmpSource.SetResolution(72, 72);
Graphics gdiSource = Graphics.FromImage(bmpSource);
try
{
gdiSource.InterpolationMode = InterpolationMode.HighQualityBicubic;
gdiSource.DrawImage(sourceImage,
new Rectangle(0, 0, targetWidth, targetHeight), // Resulting cropped

image

Post by Bob Powell [MVP]

Post by unknown
size
new Rectangle(x, y, width, height), // Selected part of source image
GraphicsUnit.Pixel);
}
finally
{
gdiSource.Dispose();
}
return bmpSource;
}

unknown

2004-11-11 09:17:42 UTC

Permalink

Ok, thanks Bob,

Hmmm, not sure how to get around this one, is it possible to read parts of
the image? possibly to tile the image into smaller parts?
Are there any conventions to working with images in this way?

Thanks,

Mark

Bill Woodruff

2004-11-12 07:33:21 UTC

Permalink

Mark,

I've been working on a project involving panning around in and zooming a fairly
large .png image (5500 x 9900) on a 1 gigabyte PIV.

I've had to put aside DrawImage and use lower level GDI calls through inter-op
to get satisfactory loading and performance, but internal memory use is still
very high, as you might expect. Justin Rogers has some good code for speeding up
bitmap loading :

http://weblogs.asp.net/justin_rogers/articles/131704.aspx

As I understand it when the raster is created internally it's converted to 32
bit pre-multiplied argb format : thus my 15 megabyte png file consumes up to 400
megs or so at run time depending on what I am doing. I have had no problems, in
spite of Bob Powell's dire warnings, creating the Graphics object off this
loaded image and re-using it. A friend of mine has examined what's going on
under the hood with the Graphics object passed in to the Paint event : he
concludes, unlike Bob's analysis, that this is the same Graphics object as one
created off the Image : it is in just a slightly different wrapper. Subjectively
I perceive performance increases by re-using the Graphics object : but I am
unable to quantify this yet : and take what I say with a grain of salt since I
personally am unable to verify and understand my friend's conclusions based on
using Reflector to examine the CLR.

At this point I have decided there is no way to construct a reasonably
performing large image viewer in .NET without going to some very lower level
code. If you are doing a project for the real world, it makes more sense to me
that you would prepare "slices" of the very large image and bring them into the
view area predictively or on-demand. Of course nothing would stop you from
loading in a big image, creating sub-sections of it and writing them out as
files, and then using those sub-sections after having disposed of the "big
image" if you've got the memory resources to do that.

best, Bill Woodruff
dotScience

unknown

2004-11-12 09:03:18 UTC

Permalink

Hi Bill,

Thank you very much for the response, I will definately look at using
unmanaged code.

I am also working on a project involving zooming, panning etc using asp.net
/ flash / webservices.
Currently, when an image is zoomed in, I open the whole jpeg and get the
part of the image according to the coordinates of the zoom and scale it to
the viewable area in the preview window that is open. I have seen some
techniques in action, where its obvious that the image has been tiled. I am
thinking of implementing something like this and have a few ideas on how to
do it, but do you know of any explanations of these types of techniques that
I can compare against.

Question on using unmanaged code in .NET.
I can use the GDI+ libraries and do all my coding in C#, which would mean
its all done in one project and will definately go this route first and
makes the most sense. Do you know if there would be any benefit of using a
native windows development environment for this part of the process, for
instance, I could do this using Delphi. (another Delphi to VS convert!)

Thanks

Mark

Post by Bill Woodruff
Mark,
I've been working on a project involving panning around in and zooming a fairly
large .png image (5500 x 9900) on a 1 gigabyte PIV.
I've had to put aside DrawImage and use lower level GDI calls through inter-op
to get satisfactory loading and performance, but internal memory use is still
very high, as you might expect. Justin Rogers has some good code for speeding up
http://weblogs.asp.net/justin_rogers/articles/131704.aspx
As I understand it when the raster is created internally it's converted to 32
bit pre-multiplied argb format : thus my 15 megabyte png file consumes up to 400
megs or so at run time depending on what I am doing. I have had no problems, in
spite of Bob Powell's dire warnings, creating the Graphics object off this
loaded image and re-using it. A friend of mine has examined what's going on
under the hood with the Graphics object passed in to the Paint event : he
concludes, unlike Bob's analysis, that this is the same Graphics object as one
created off the Image : it is in just a slightly different wrapper. Subjectively
I perceive performance increases by re-using the Graphics object : but I am
unable to quantify this yet : and take what I say with a grain of salt since I
personally am unable to verify and understand my friend's conclusions based on
using Reflector to examine the CLR.
At this point I have decided there is no way to construct a reasonably
performing large image viewer in .NET without going to some very lower level
code. If you are doing a project for the real world, it makes more sense to me
that you would prepare "slices" of the very large image and bring them into the
view area predictively or on-demand. Of course nothing would stop you from
loading in a big image, creating sub-sections of it and writing them out as
files, and then using those sub-sections after having disposed of the "big
image" if you've got the memory resources to do that.
best, Bill Woodruff
dotScience

Doug Forster

2004-11-15 02:41:42 UTC

Permalink

Hi Mark,

You might like to look at this: http://www.voicenet.com/~richgel/
for a free progressive jpeg decoder (written in C++). The core GDI+ is
actually an unmanaged library quite easily accessed from C++ where you would
have much closer control of memory usage plus easy access to ordinary GDI if
you wish (for image scaling for example - much faster via GDI if you target
Windows 2000+)

Cheers

Doug Forster

Post by unknown
Hi Bill,
Thank you very much for the response, I will definately look at using
unmanaged code.
I am also working on a project involving zooming, panning etc using asp.net
/ flash / webservices.
Currently, when an image is zoomed in, I open the whole jpeg and get the
part of the image according to the coordinates of the zoom and scale it to
the viewable area in the preview window that is open. I have seen some
techniques in action, where its obvious that the image has been tiled. I am
thinking of implementing something like this and have a few ideas on how to
do it, but do you know of any explanations of these types of techniques that
I can compare against.
Question on using unmanaged code in .NET.
I can use the GDI+ libraries and do all my coding in C#, which would mean
its all done in one project and will definately go this route first and
makes the most sense. Do you know if there would be any benefit of using a
native windows development environment for this part of the process, for
instance, I could do this using Delphi. (another Delphi to VS convert!)
Thanks
Mark

Post by Bill Woodruff
Mark,
I've been working on a project involving panning around in and zooming a

fairly

Post by Bill Woodruff
large .png image (5500 x 9900) on a 1 gigabyte PIV.
I've had to put aside DrawImage and use lower level GDI calls through

inter-op

Post by Bill Woodruff
to get satisfactory loading and performance, but internal memory use is

still

Post by Bill Woodruff
very high, as you might expect. Justin Rogers has some good code for

speeding up

Post by Bill Woodruff
http://weblogs.asp.net/justin_rogers/articles/131704.aspx
As I understand it when the raster is created internally it's converted
to

Post by Bill Woodruff
bit pre-multiplied argb format : thus my 15 megabyte png file consumes up

to 400

Post by Bill Woodruff
megs or so at run time depending on what I am doing. I have had no

problems, in

Post by Bill Woodruff
spite of Bob Powell's dire warnings, creating the Graphics object off this
loaded image and re-using it. A friend of mine has examined what's going

Post by Bill Woodruff
under the hood with the Graphics object passed in to the Paint event : he
concludes, unlike Bob's analysis, that this is the same Graphics object
as

one

Post by Bill Woodruff
created off the Image : it is in just a slightly different wrapper.

Subjectively

Post by Bill Woodruff
I perceive performance increases by re-using the Graphics object : but I

Post by Bill Woodruff
unable to quantify this yet : and take what I say with a grain of salt

since I

Post by Bill Woodruff
personally am unable to verify and understand my friend's conclusions

based on

Post by Bill Woodruff
using Reflector to examine the CLR.
At this point I have decided there is no way to construct a reasonably
performing large image viewer in .NET without going to some very lower

level

Post by Bill Woodruff
code. If you are doing a project for the real world, it makes more sense

to me

Post by Bill Woodruff
that you would prepare "slices" of the very large image and bring them

into the

Post by Bill Woodruff
view area predictively or on-demand. Of course nothing would stop you from
loading in a big image, creating sub-sections of it and writing them out

Post by Bill Woodruff
files, and then using those sub-sections after having disposed of the "big
image" if you've got the memory resources to do that.
best, Bill Woodruff
dotScience

Bob Powell [MVP]

2004-11-12 10:42:00 UTC

Permalink

Hello Bill,

Post by Bill Woodruff

Post by Bill Woodruff
Bob Powell's dire warnings

Which ones?? I make so many :-))

Post by Bill Woodruff

Post by Bill Woodruff
A friend of mine has examined what's going on

under the hood with the Graphics object passed in to the Paint event : he
concludes, unlike Bob's analysis, that this is the same Graphics object as
one
created off the Image : it is in just a slightly different wrapper.

I'd like to see that too.

The only problems I see with large images is that they eat memory resources
very quickly. Unless the machine is equipped with multi-gigabyte RAM it's
unlikely that the magical performance people expect is going to be
forthcoming. Running Windows XP pro with very few appplications in memory I
am seeing 550megs available out of 1 gig. A good sized image would eat that
up very quickly leaving the system in a mnemonically impoverished state.

This subject is one that comes up so often that I'd like to put up a big
article in the FAQ or on Tips and Tricks that explained all the parameters.
Any insights you might have from your experiences working with large memory
files would be greatly appreciated.
--
Bob Powell [MVP]
Visual C#, System.Drawing

Answer those GDI+ questions with the GDI+ FAQ
http://www.bobpowell.net/gdiplus_faq.htm

The GDI+ FAQ RSS feed: http://www.bobpowell.net/faqfeed.xml
Windows Forms Tips and Tricks RSS: http://www.bobpowell.net/tipstricks.xml
Bob's Blog: http://bobpowelldotnet.blogspot.com/atom.xml

Bill Woodruff

2004-11-13 03:25:37 UTC

Permalink

Post by Bob Powell [MVP]
This subject is one that comes up so often that I'd like to put up a
big article in the FAQ or on Tips and Tricks that explained all the
parameters. Any insights you might have from your experiences
working with large memory files would be greatly appreciated.

Yes, it would be good to have a real "monograph" on the subject. I am trying to
get my friend (a world class expert on the clr and ace pilot of Roeder's
Reflector) to figure out for me the relative "costs/benefits" of creating the
Graphics object off the bitmap once and re-using it inside the Paint event vs.
(as is more "standard" practice) referencing it off the EventArgs passed into
the Paint event. It would be very nice to be able to more objectively talk about
these things, and I can't think of a better place for it than your excellent
technical resource, the GDI+ faq.

In the meantime it is clear that Justin Rogers' code previously cited does speed
up bitmap loading and that using BitBlt enables reasonable panning of a very
large image (in a panel functioning as a "viewport" using standard mouse
click-and-drag technique). If you look with Reflector at what's happneing
under-the-hood with the Paint event, my friend tells me, it's easy to see what
Justin Rogers did in his code : but that's easy for him to say :)

I hope to put up a CodeProject article sharing my "large image viewer" as soon
as it's "riper."

best, Bill Woodruff
dotScience
Chiang Mai, Thailand

unknown

2004-11-16 11:07:03 UTC

Permalink

Hi Bill,

I have looked at the ImageFast Library, are you suggesting, loading the file
using it (FromFile), then calling my existing function to crop/scale(using
DrawImage) or re-write the crop/scale function using a unmanaged DrawImage
equivalent function call?

I have tried 'just' replacing the load function and the my crop / scale
function seems to take longer on the same file ?
(the difference is in the order of around 200ms)

Do you have an example of using a DrawImage equivalent function using
unmanaged GDI+ calls?

Thanks

Mark Redman

Bill Woodruff

2004-11-19 17:49:44 UTC

Permalink

Mark Redman wrote : >> I have looked at the ImageFast Library, are you
suggesting, loading the file using it (FromFile) ?

Yep, although I am now going to follow Etian Buket's suggestion in a recent
message to this group and experiment with loading using the technique he
describes (my friend, the world class clr expert, says he has looked at Buket's
code with Reflector (I assume at the IM level) and that technique should be as
fast as the one outlined by J. Rogers). By discarding the code in Rogers'
example that deals with metafiles, you can cut out one casting and return a
bitmap, rather than an image ... if you don't need the metafile stuff.

Post by unknown
I have tried 'just' replacing the load function and the my crop / scale

function seems to take longer on the same file ?

Post by unknown
(the difference is in the order of around 200ms)

Don't know what to say about that, but I personally find the LOADING ONLY
accelerated using J. Rogers' technique .. I'm not doing any cropping.

Post by unknown
Do you have an example of using a DrawImage equivalent function using

unmanaged GDI+ calls?

I am using straight bitblitting using PInvokes, and I am using StretchBlit, but
am unsastisfied with the results of stretchBlt. Just the regular old stuff of
getting the hdc, creating a compatible dc, etc.

We're a long way from a "science" of being to analyze an image (size,
colordepth, etc.) and construct ... in code ... a useful set of heuristics that
might let us apply techniques differentially taking into account the runtime
platform's cpu horsepower and memory resources, but I think folks like Bob
Powell, and Frank Hileman, with some input from the likes of me and you, can
help us get there.

It makes more sense to me at this point to break up a very large image into
chunks and bring in those chunks as needed ... and it makes more sense to me to
use the graphics programs I've spent years mastering, like PhotoShop, to prepare
the highest quality scaled versions of an image in advance. Of course in the
real world you could be dealing with dynamic image input, or even building
images from data streams, so that doesn't fit that model.

I've got Whidbey up and running now and I will be curious to see if there are
any differences in running this type of code.

best, Bill Woodruff
dotScience
Chiang Mai, Thailand