RE memory

[austie333]

Hi Folks,

I tried to open an A3 sized TIFF image, about 16 mb with Paint and it spat the dummy saying that it had insufficient memory. Is there anyway, and how do you if you can, increase memory size for Paint?

Kind regards,

Philip

[david.atwell]

Take a look at this thread: viewtopic.php?f=10&t=23125

You can, but it requires upgrading your entire computer. :-)

[Crimson]

If you can't open an image 16MB in size (which is not small, but still should be manageable), you may want to consider upgrading your RAM anyway, seeing as programs are more and more resource-demanding now.

That said, make sure you close any background applications that you may not be using, but are still sucking RAM.

[alexo]

I got an "insufficient memory" error when I tried opening a large number of images.

I understand that Paint.NET keeps the images in memory but there is actually a mechanism in Windows to allow an application to allocate huge amounts of virtual memory without the need of a 64-bit address space or the /3GB switch.

Raymond Chen explained how to to do it in 2004 in his blog (Myth: Without /3GB a single program can't allocate more than 2GB of virtual memory).

I will add that you are not even constrained by the size of your page file since CreateFileMapping can use a disk file for backing storage.

Now, I am not familiar enough with .NET to speculate on how easy it will be to implement such a technique, but if it is feasible (and I really hope that it is), the number of concurrently open images will only be constrained by free disk space (assuming any single image can fit in available memory). Obviously, the trade-off will be slower switching between images but it could be made a configuration option.

What do you think?

[Sozo]

I would say upgrading the ram is the easiest way out, and it will benefit the whole computer, not just Paint.NET. Ram upgrades have long been the most cost effective upgrades in terms of price vs. performance. Just make sure you get ram that is compatible with your motherboard (Google should help). Might I suggest Newegg.com as a reliable, good priced online retailer?

[Lance McKnight]

I remember going to a website where it would scan the hardware of the computer and make recommendation to improve the performance of the computer. I cannot, for the life of me, remember the site name. :?

[Rick Brewster]

Paint.NET only has rudimentary support for TIFF images, and I strongly recommend using PNG instead. You are probably opening an image that is 1-bit per pixel and with an enormous number of pixels. It is the final image dimensions in pixels, not the file size, that determines memory requirements.

[alexo]

Hi Rick,

Can you comment on my suggestion above?

Is is doable? Is is worth doing?

Thanks,

Alex.

[Rick Brewster]

If you must open an image that requires that much virtual memory allocation, then you must use a 64-bit version of Windows. Paint.NET does not use a paging system like that. It is not a bad idea, but would require a rewrite of substantial portions of the code. Hopefully someday, but definitely not anytime soon.

[alexo]

If you must open an image that requires that much virtual memory allocation, then you must use a 64-bit version of Windows. Paint.NET does not use a paging system like that. It is not a bad idea, but would require a rewrite of substantial portions of the code. Hopefully someday, but definitely not anytime soon.

Sorry for being unclear Rick,

I was talking about opening multiple images simultaneously, where each one fits in available memory individually but the lot of them does not.

Thanks,

Alex.

[Rick Brewster]

I've considered that, but it would actually introduce a worse reliability problem.

The layout of the heap* changes over time based on whatever allocations and deallocations happen. Imagine a scenario where you load two images, one requiring 1GB of memory and the other requiring 1.5GB. When you first start up Paint.NET, the heap is pretty empty and so it is easy to carve out big sequential sections of it. The 1.5gb image loads fine, is then unmapped, and then the 1gb image loads fine. You then do a bunch of work on that 1gb image. Then, you switch back to the first image. The 1gb image is unmapped, but because of the work you were doing you no longer have a 1.5gb "hole" in your virtual address space (as a simple example: imagine that you have a 1.5gb sequential area except for 1 tiny allocation parked at the 1.2gb mark that is a result of loading a font or a brush or whatever).

At that point Paint.NET would have to say, "Sorry but I can't switch to that image. Out of memory." That is a major data loss issue, not to mention confusing to the user ("but I already loaded it! it's right there!"). It is much safer to keep everything in memory so that you can guarantee that switching between the images will not fail. I would much rather tell the user up front that they cannot load an image then have it explode on them 30 minutes later in a non-deterministic way.

This would not just be an issue with large images. Even with smaller images, the entropy of the heap increases over time, and so you will still run into this issue.

My pie-in-the-sky design for Paint.NET involves switching to a system analagous to what GIMP and Photoshop use. Instead of doing 1 big allocation for a bitmap, say 10k pixels wide x 10k pixels tall = 100 million pixels = 400mb, it is split up into tiles of maybe 64kb or 256kb (preferably a size that lets you fit 2-3 into the L2 cache of a Core i7 or Atom). There is then an additional level of indirection for working with pixel data in the code, but it opens up a world of possibilities. For example, paging in/out tiles based on a least-recently-used algorithm (paging and caching), or having procedural tiles ("this tile is a solid color ... I won't even allocate storage for the pixels. I'll just remember that solid color value"). It is also much easier to find ~6000 "holes" of 64kb in size than 1 hole that is 400mb in size.

In summary, for the foreseeable future the solution is to run 64-bit Windows and buy a ton of RAM (which thankfully is cheap).

* Well, the heap (which is an abstraction on top of the virtual memory manager system) and the virtual address space -- for this post I'll just use the term "heap" to mean both/either. There is also the managed heap (.NET), but it just allocates chunks from virtual address space and parks its objects in there.