We are using a .net dll (http://imageresizing.net/download) for imageresizing on runtime. It works perfectly. However, it happen after some time (between 1-7 days) that system started to raise exception in the even viewer:
Exception information:
Exception type: OutOfMemoryException
Exception message: Insufficient memory to continue the execution of the program.
And after that exception the website usually stop working with the error throwing "System.OutOfMemoryException".
And if we "recycle" the application pool in which the website is running, it clears the problem and website get back to normal immediately without any code change.
Before imagereiszing dll, we were using our custom code and same problem happen with that too. Following is the code.
private Bitmap ConvertImage(Bitmap input, int width, int height, bool arc)
{
if (input.PixelFormat == PixelFormat.Format1bppIndexed ||
input.PixelFormat == PixelFormat.Format4bppIndexed ||
input.PixelFormat == PixelFormat.Format8bppIndexed)
{
Bitmap unpackedBitmap = new Bitmap(input.Width, input.Height);
Graphics g = Graphics.FromImage(unpackedBitmap);
g.Clear(Color.White);
g.DrawImage(input, new Rectangle(0,0,input.Width, input.Height));
g.Dispose();
input = unpackedBitmap;
}
double aspectRatio = (double)input.Height / (double)input.Width;
int actualHeight = CommonMethods.GetIntValue(Math.Round(aspectRatio * width, 0));
Bitmap _imgOut;
if (actualHeight > height)
{
ResizeImage resizeImage = new ResizeImage(width, actualHeight, InterpolationMethod.Bicubic);
Bitmap _tempBitmap = resizeImage.Apply(input);
Bitmap _croppedBitmap = new Bitmap(width, height);
Graphics _crop = Graphics.FromImage(_croppedBitmap);
_crop.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias;
_crop.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic;
_crop.CompositingQuality = System.Drawing.Drawing2D.CompositingQuality.HighQuality;
_crop.DrawImageUnscaledAndClipped(_tempBitmap, new Rectangle(0, 0, width, height));
_crop.Dispose();
_imgOut = _croppedBitmap;
}
else
{
ResizeImage resizeImage = new ResizeImage(width, height, InterpolationMethod.Bicubic);
_imgOut = resizeImage.Apply(input);
}
// Draw the arc if it has been requested
if (arc)
{
Graphics _arc = Graphics.FromImage(_imgOut);
_arc.SmoothingMode = System.Drawing.Drawing2D.SmoothingMode.AntiAlias;
_arc.InterpolationMode = System.Drawing.Drawing2D.InterpolationMode.HighQualityBicubic;
_arc.CompositingQuality = System.Drawing.Drawing2D.CompositingQuality.HighQuality;
_arc.DrawArc(new Pen(Color.White, 24), new Rectangle(-13, -13, 50, 50), 180, 90);
_arc.Dispose();
}
// job done
return _imgOut;
}
We are resizing image like: www.mysite.com/images/myimage.jpg?width=196&height=131
Looking forward.
Farrukh
When you encounter an OutOfMemoryException (regardless of where it occurs), it can be caused by a memory leak anywhere in the application. Having debugged dozens of these instances with WinDbg, I've never found any that ended up being due to a bug in http://imageresizing.net.
That said, there's an easy way to determine whether it is a problem with http://imageresizing.net or not; create a separate application pool and subfolder application in IIS for your images and image resizing. Install nothing there except the image resizer. Next time you encounter the error, log on to the server and find out which w3wp.exe instance is responsible for the massive memory usage.
If it's in the ImageResizer app pool, go collect your $20-$50 bug bounty from http://imageresizing.net/support. If not, you need to figure out where you're leaking stuff in your main application.
If you're working with System.Drawing anywhere else in the app, that's the first place to look. Check your code against this list of pitfalls.
If you're positive you're disposing of every System.Drawing.* instance in a using or finally clause, then read this excellent article a few times to make sure you're not failing on any of the basics, then dig in with DebugDiag and/or WinDBG (see bottom of article).
Related
I want to save a view's snapshot to a file, but comes the error.
My code is as following:
View decor = ***; //
int width = decor.getWidth();
int height = decor.getHeight();
Bitmap bitmap = Bitmap.createBitmap(width, height, Config.ARGB_8888);
Canvas canvas = new Canvas(bitmap);
decor.draw(canvas);
int bytes = bitmap.getByteCount() + 8;
ByteBuffer buffer = ByteBuffer.allocate(bytes);
buffer.putInt(width);
buffer.putInt(height);
bitmap.copyPixelsToBuffer(buffer);
byte[] array = buffer.array();
but bitmap.copyPixelsToBuffer(buffer); will crash.
the error is like this:
12-09 08:36:43.107: E/libEGL(14642): call to OpenGL ES API with no current context (logged once per thread)
This error only happens on Android 5.0, are there any changes in the new platform? I know android 5.0 use a ThreadedRender to render a surface, how can I handle this problem? Thanks very much!!!
Even i am facing the same problem! It seems like in pre-lollipop version the context was leaking and is being used by default (I assume). But with lollipop it is strictly needed to create or pass the context explicitly!
hope these helps!
https://stackoverflow.com/a/27092070
I am developping an app that has a main activity showing the app title (two animated imageviews overlayed), two animated pictures, also overlayed, and three buttons. This activity also has a background image, which is the same that is used by the other activities.
The app flows from one activity to another and, eventually, this main activity is launched again (with the FLAG_ACTIVITY_CLEAR_TOP). Everything works fine but, after reloading it several times, an Out Of Memory error happens on my Android 2.1 device.
At first, I had all the images in the drawable folder and the problem appeared after reaching the main activity 5 times. Then, I adjusted the bitmap sizes and put them in the approppriate folders depending on the density and the problem appeared after reaching the main activity 14 times. Now, I just removed the background image for test purposes and the Out Of Memory appears after more than 20 re-launches.
Also, if I press the Home button and then switch back to my app, the problem seems not to appear until much later.
Moreover, I tested the app in a Nexus 5 and the Out Of Memory never happens.
So... is that a problem with my phone? with Android 2.1?
Thanks!
[EDIT]
I think that I have located the problem but, still, strange behavior.
For example, at one point, I need to recreate the activity. As the "recreate" method is not available for my min API level (7), I do it as follows:
Intent refresh = new Intent(getActivity(), getActivity().getClass());
refresh.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP);
startActivity(refresh);
Which, I think, is correct. I release the onClickListeners and clear the animations in onStop(). However, if I put a breakpoint in onStop(), it is not called when I expect it to happen. Sometimes it is called as soon as the activity is recreated but sometimes it is called several seconds later.
However, if I press the Home button, onStop is properly called and when I switch back to the application everything works fine.
The easiest solution is to add in manifest under application tag
android:largeHeap="true"
But this is won't solve your problem, just delay it to a few more rounds
This link will help you to analyze your application and see what cause this:
http://blogs.innovationm.com/android-out-of-memory-error-causes-solution-and-best-practices/
My Guess this is related to images because i had this issue also..
The android official link to this problem is:
http://developer.android.com/training/displaying-bitmaps/index.html
This the link that helped me.. Try it out
http://developer.android.com/training/displaying-bitmaps/load-bitmap.html
Hope that helps
check this outLoading Large Bitmaps Efficiently
Read Bitmap Dimensions and Type
BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(getResources(), R.id.myimage, options);
int imageHeight = options.outHeight;
int imageWidth = options.outWidth;
String imageType = options.outMimeType;
Load a Scaled Down Version into Memory
public static int calculateInSampleSize(
BitmapFactory.Options options, int reqWidth, int reqHeight) {
// Raw height and width of image
final int height = options.outHeight;
final int width = options.outWidth;
int inSampleSize = 1;
if (height > reqHeight || width > reqWidth) {
final int halfHeight = height / 2;
final int halfWidth = width / 2;
// Calculate the largest inSampleSize value that is a power of 2 and keeps both
// height and width larger than the requested height and width.
while ((halfHeight / inSampleSize) >= reqHeight
&& (halfWidth / inSampleSize) >= reqWidth) {
inSampleSize *= 2;
}
}
return inSampleSize;
}
public static Bitmap decodeSampledBitmapFromResource(Resources res, int resId,
int reqWidth, int reqHeight) {
// First decode with inJustDecodeBounds=true to check dimensions
final BitmapFactory.Options options = new BitmapFactory.Options();
options.inJustDecodeBounds = true;
BitmapFactory.decodeResource(res, resId, options);
// Calculate inSampleSize
options.inSampleSize = calculateInSampleSize(options, reqWidth, reqHeight);
// Decode bitmap with inSampleSize set
options.inJustDecodeBounds = false;
return BitmapFactory.decodeResource(res, resId, options);
}
imageView.setImageBitmap(
decodeSampledBitmapFromResource(getResources(), R.id.myimage, 100, 100));
I'm trying to use the creative gesture camera in Processing. I started with the Intel Perceptual Computing SDK, and ran into an issue.
I want to get the hand openness, and I am running into some issues - no matter what, the hand.openness returns 0. It otherwise runs quite well...
Some Sample code I'm trying to get to work: If you open your hand it starts printing to the console, close it and it stops.
import intel.pcsdk.*;
PXCUPipeline session;
PXCMGesture.GeoNode hand = new PXCMGesture.GeoNode();
void setup()
{
session = new PXCUPipeline(this);
if(!session.Init(PXCUPipeline.GESTURE))
exit();
}
void draw()
{
background(0);
if(session.AcquireFrame(false))
{
if(session.QueryGeoNode(PXCMGesture.GeoNode.LABEL_BODY_HAND_PRIMARY|PXCMGesture.GeoNode.LABEL_OPEN, hand)) //Only when primary hand is open
{
rect(0, 0, 10, 10);
println(hand.openness + " : " + frameCount); //Openness should be from 0 to 100
}
session.ReleaseFrame();
}
}
Using the current version of Processing (2.0.3), Perceptual Computing SDK Version 7383.
Try updating the version of the SDK you're using if your project will allow it, there were quite a few bugs with getting attributes such as openess, openessState, radius, to name a few with the processing library (some attributes would even throw a null pointer exception when trying to retrieve them). I believe these have all been fixed in the recent versions, along with the inclusion of 64 bit processing support.
I am in the process of moving a webforms app to MVC3. Ironically enough, everything is cool beans except one thing - images are served from a handler, specifically the Microsoft Generated Image Handler. It works really well - on average a 450kb photo gets output at roughly 20kb.
The actual photo on disk weighs in at 417kb, so i am getting a great reduction.
Moving over to MVC3 i would like to drop the handler and use a controller action. However i seem to be unable to achieve the same kind of file size reduction when rendering the image. I walked through the source and took an exact copy of their image transform code yet i am only achieving 230~kb, which is still a lot bigger than what the ms handler is outputting - 16kb.
You can see an example of both the controller and the handler here
I have walked through the handler source code and cannot see anything that is compressing the image further. If you examine both images you can see a difference - the handler rendered image is less clear, more grainy looking, but still what i would consider satisfactory for my needs.
Can anyone give me any pointers here? is output compression somehow being used? or am i overlooking something very obvious?
The code below is used in my home controller to render the image, and is an exact copy of the FitImage method in the Image Transform class that the handler uses ...
public ActionResult MvcImage()
{
var file = Server.MapPath("~/Content/test.jpg");
var img = System.Drawing.Image.FromFile(file);
var sizedImg = MsScale(img);
var newFile = Server.MapPath("~/App_Data/test.jpg");
if (System.IO.File.Exists(newFile))
{
System.IO.File.Delete(newFile);
}
sizedImg.Save(newFile);
return File(newFile, "image/jpeg");
}
private Image MsScale(Image img)
{
var scaled_height = 267;
var scaled_width = 400;
int resizeWidth = 400;
int resizeHeight = 267;
if (img.Height == 0)
{
resizeWidth = img.Width;
resizeHeight = scaled_height;
}
else if (img.Width == 0)
{
resizeWidth = scaled_width;
resizeHeight = img.Height;
}
else
{
if (((float)img.Width / (float)img.Width < img.Height / (float)img.Height))
{
resizeWidth = img.Width;
resizeHeight = scaled_height;
}
else
{
resizeWidth = scaled_width;
resizeHeight = img.Height;
}
}
Bitmap newimage = new Bitmap(resizeWidth, resizeHeight);
Graphics gra = Graphics.FromImage(newimage);
SetupGraphics(gra);
gra.DrawImage(img, 0, 0, resizeWidth, resizeHeight);
return newimage;
}
private void SetupGraphics(Graphics graphics)
{
graphics.CompositingMode = CompositingMode.SourceCopy;
graphics.CompositingQuality = CompositingQuality.HighSpeed;
graphics.InterpolationMode = InterpolationMode.HighQualityBicubic;
graphics.SmoothingMode = SmoothingMode.HighSpeed;
}
If you don't set the quality on the encoder, it uses 100 by default. You'll never get a good size reduction by using 100 due to the way image formats like JPEG work. I've got a VB.net code example of how to set the quality parameter that you should be able to adapt.
80L here is the quality setting. 80 still gives you a fairly high quality image, but at DRASTIC size reduction over 100.
Dim graphic As System.Drawing.Graphics = System.Drawing.Graphics.FromImage(newImage)
graphic.InterpolationMode = Drawing.Drawing2D.InterpolationMode.HighQualityBicubic
graphic.SmoothingMode = Drawing.Drawing2D.SmoothingMode.HighQuality
graphic.PixelOffsetMode = Drawing.Drawing2D.PixelOffsetMode.HighQuality
graphic.CompositingQuality = Drawing.Drawing2D.CompositingQuality.HighQuality
graphic.DrawImage(sourceImage, 0, 0, width, height)
' now encode and send the new image
' This is the important part
Dim info() As Drawing.Imaging.ImageCodecInfo = Drawing.Imaging.ImageCodecInfo.GetImageEncoders()
Dim encoderParameters As New Drawing.Imaging.EncoderParameters(1)
encoderParameters.Param(0) = New Drawing.Imaging.EncoderParameter(Drawing.Imaging.Encoder.Quality, 80L)
ms = New System.IO.MemoryStream
newImage.Save(ms, info(1), encoderParameters)
When you save or otherwise write the image after setting the encoder parameters, it'll output it using the JPEG encoder (in this case) set to quality 80. That will get you the size savings you're looking for.
I believe it's defaulting to PNG format also, although Tridus' solution solves that also.
However, I highly suggest using this MVC-friendly library instead, as it avoids all the image resizing pitfalls and doesn't leak memory. It's very lightweight, free, and fully supported.
I have a .NET 2.0 app that runs just fine on XP and Vista, but on Windows 7 RC (x64) it crashes with the following error:
Exception Information
Exception Type: System.OutOfMemoryException
Message: Out of memory.
Data: System.Collections.ListDictionaryInternal
TargetSite: Void .ctor(System.Drawing.Image, System.Drawing.Drawing2D.WrapMode)
HelpLink: NULL
Source: System.Drawing
StackTrace Information
at System.Drawing.TextureBrush..ctor(Image image, WrapMode wrapMode)
at System.Windows.Forms.ControlPaint.DrawBackgroundImage(Graphics g, Image backgroundImage, Color backColor, ImageLayout backgroundImageLayout, Rectangle bounds, Rectangle clipRect, Point scrollOffset, RightToLeft rightToLeft)
at System.Windows.Forms.Control.PaintBackground(PaintEventArgs e, Rectangle rectangle, Color backColor, Point scrollOffset)
at System.Windows.Forms.Control.PaintBackground(PaintEventArgs e, Rectangle rectangle)
at System.Windows.Forms.Control.OnPaintBackground(PaintEventArgs pevent)
at System.Windows.Forms.ScrollableControl.OnPaintBackground(PaintEventArgs e)
at System.Windows.Forms.Control.PaintWithErrorHandling(PaintEventArgs e, Int16 layer, Boolean disposeEventArgs)
at System.Windows.Forms.Control.WmPaint(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ScrollableControl.WndProc(Message& m)
Any ideas about why this is happening, or how I might program around it? It's just painting a standard winform with no special background.
UPDATE:
I've found that this is only an issue when the BackgroundImageLayout = ImageLayout.Tile, which is also the default. Set it to Zoom or Center, and the issue dissapears. That's pretty unsatisfactory though, because I need it to tile.
I had a similar problem. In my case I had disposed of my MemoryStream I loaded the image from.
//The following throws and OutOfMemoryException at the TextureBrush.ctor():
/*someBytes and g declared somewhere up here*/
Bitmap myBmp = null;
using(MemoryStream ms = new MemoryStream(someBytes))
myBmp = new Bitmap(ms);
if(myBmp != null) //that's right it's not null.
using(TextureBrush tb = new TextureBrush(myBmp)) //OutOfMemoryException thrown
g.FillRectangle(tb,0,0,50,50);
//This code does not throw the same error:
/*someBytes and g declared somewhere up here*/
MemoryStream ms = new MemoryStream(someBytes);
Bitmap myBmp = new Bitmap(ms);
if(myBmp != null)
using(TextureBrush tb = new TextureBrush(myBmp))
g.FillRectangle(tb,0,0,50,50);
Turns out the solution to this had to do with the PNG file itself used for the background.
I just opened it with Paint.NET and resaved it, then put it back in the project and it worked.
Not sure what changed, but it resolved the problem.
Please do not dispose the Image or close the filestream object from where you have got the Image before calling the TextureBrush class for tiling. Otherwise the TextureBrush class will throw an Out of Memory exception.
So the better way is to show the tiled Image by calling the TextureBrush Image and then close the filestream object in the Paint event of the windows form.