Paint.NET very slow in opening 23MB JPEG file

[rradi]

Hi Rick,

I attempted to see how Paint.NET will behave when i opening images larger than 2-3MBs on a Dual-Core Intel® Xeon® Processor 5150 based platform and saw some interesting things.

The images I used can be downloaded from the following link:

http://hubblesite.org/newscenter/newsdesk/archive/releases/2006/01/image/a+warn

I know that Paint.NET is not prepared yet to be able to open massive images such as the 385MB TIFF file in this link (which caused Paint.NET to crash btw), but when trying to open the 23MB JPEG file on that site, Paint.NET consumed 3GB of RAM!!, causing Windows to complain that its Virtual memory was too low, and took maybe 4 minutes to load the file.

I tried to see how Photoshop 7 would react to such files, and found that the 23MB JPEG opened in approximately 10 seconds and the 385MB TIFF opened in approximately 45 seconds.

So my question is: Are even 23MBs that big for Paint.NET at the moment? Are there any future plans to fix or enhance this?

Thanks,

Rami Radi

[trickman]

23 MB JPEG? OMG! :oops:

[Rick Brewster]

A 23MB JPEG still has to be decompressed and stored in memory, and then takes up much more than 23 MB. We store the entire image in memory along with a few extra buffers for compositing and other purposes. We do not use a foreful tiling scheme like Photoshop or The GIMP, and instead have relied on the slow transition to 64-bit to provide more virtual address space for the users who need to work with enormous images. This is a core part of Paint.NET's architecture, and it was purposefuly designed this way.

[rradi]

Hi Rick,

Thank you for the explanation, but doesn't what you say imply that Paint.NET should take say a maximum of 50-60MBs of memory to open the 23MB file?

Instead, it takes 3GBs! This is what i am worried about. Do you think there might be some kind of memory leak?

Thanks,

Rami

[Bob]

http://paintdotnet.12.forumer.com/viewtopic.php?p=6009

So, to compute the memory requirements for an image, the following formula can be used:

(W x H x 4) x (L + 2)

[Illnab1024]

equals 3,888,000,000 bytes of memory used.

[Rick Brewster]

Why would it take 50-60 MB of memory?

A 23MB JPEG decompresses to an enormous image. Memory usage is proportional to the number of pixels in an image, not its compressed file size. For example, for a 1000 x 1000 image, memory usage is proportional to 1000 x 1000 x number_of_layers. (Each layer has 1000x1000 pixels). For single layer images we also have a relatively large memory usage penalty, as we also have a composition and scratch buffers. So really memory usage is proportional to (width x height x (layers + 2)). Also, multiply by 4 because each pixel takes 4 bytes of memory (red, green, blue, alpha).

A 1000x1000 image takes the same amount of memory after decompression whether it was saved to disk as a low-quality 50KB JPEG or a high-quality 500KB JPEG.

A 23MB JPEG is an enormous image. That's like what, 20000x15000 or something? Enormous images take enormous amounts of memory to load, even if the JPEG codec was able to squash it to a much smaller file on disk.

[rradi]

Arrrrgh! I forgot the compression methodology of JPEG files completely!

Thank you guys, and sorry about that!

Rami Radi

[Rick Brewster]

Apps like Photoshop and The GIMP can work with large images because they implement sophisticated and custom tiling schemes. It's essentially the same as virtual memory paging, except that they get the split the image into arbitrary rectangular tiles. In Paint.NET, we rely on the OS's built-in virtual memory / paging, but that does 4 KB at a time and can only split the image into vertical stripes of tiles (that's simplifying though). Rectangular tiles can result in better locality, as if I draw something on the left side of a very lage image I don't end up paging in stuff all the way over on the right of the image.

The tradeoff is development simplicity: I can write less code that does more stuff with fewer bugs and publish it sooner, but in return it requires more of your system's memory at any given moment. Or, on 32-bit systems, it just may not work because of the limitations of the available virtual addressing.

On that Xeon 5150 I really hope you are running 64-bit Windows Paint.NET runs about 40% faster on that chip in 64-bit mode (on the Athlons and Opterons we get a 60% bonus).