Large Image Memory Management (UI)

Question

I am working on an iPad-only iOS application that essentially downloads large, high-quality images (JPEG) from Dropbox and displays the selected image in UIScrollView and UIImageView, allowing the user to zoom and pan the image.

The application is mainly used to display images to potential customers who are interested in buying them in the form of frame prints. The way it works is that the image is first displayed, scaled and displayed to show the potential customer if he likes the image. If they like it, they can decide whether they want to crop a certain area (while maintaining certain proportions / sizes), and the final image (cropped or not) is then sent as an email application for production.

The problem that I am facing now is that even though the application will only work on new iPads (i.e. more memory, etc.), I cannot find a way to process the image so that the application does not received memory warnings and then crash .

Most images are 4256x2832 in size, which brings at least 40 MB of memory per image. As long as I show only one image, cropping the image (currently the main problem with memory / crash) creates a new cropped image, which in turn instantly crashes the total RAM usage by applications by about 120 MB, causing a crash.

In short . I'm looking for a way to manage very large images, be able to crop them, and after cropping, there is still enough memory to send them as email attachments.

I was thinking of introducing a single-user image manager that all views will use, and it will only contain one large image at a time, but I'm not sure if this is the right way, or even if that could help anyway.

Answer 1

In the end, I solved the problem. Since I couldn't resize the source files in Dropbox (the client has its own reasons), I went ahead and used BOSImageResizeOperation , which is essentially just a fast, thread-safe library for quickly resizing images.

Using this library, I noticed that images that previously occupied 40-60 MB of memory per image now seemed to be about half as large. In addition, resizing is so fast that the original image is quickly freed from memory that iOS does not issue a memory warning.

With this, I received a further application, and I appreciate the whole idea, suggestions and comments. I hope this makes the application do, and I can get as far away from big image processing, heh.

Answer 2

One way to handle this is to stitch the image. You can save a large decompressed image to a “disk” as a series of fragments, and when the user rolls, pull out only those tiles that you really need to display. You will need only 1 tile in memory at a time, because you draw it on the screen, then eject and load the next tile. (You might want to cache visible tiles in memory, but this is implementation detail. Even having the whole tile image can reduce the memory pressure because you don't need one large, continuous block.) This is how applications like Photoshop deal with this situation.