Question

For the last few weeks I ve been tearing my hair out trying to get a tiling mechanism working on an iPhone. I need to scale and crop images of about 150mb so that they can be saved as tiles that will be requested by a scroll view, allowing the user to see the image in high resolution.

The problem is that these images are really pushing the bounds of what an iPhone can handle. It seems quite easy to scale these huge images down to 1000 or so across and do that tiling, but for large zoom levels I need to scale it mid-way, say 4000 across and that s too big. So I hit upon the idea of making medium sized blocks from the full sized image and tiling each of those and the medium zoom.

By creating an autoreleasepool around the inner loops, and draining it after each cycle I can mostly keep the memory under control but sometimes, and to me it seems random, memory is getting leaked, or at least not drained. I m doing all this on a secondary thread and when it gets back to the first function in that thread I release the thread s own autoreleasepool and only then do the last memory artifacts get cleared. It doesn t seem to bother the simulator but the iPhone is much less forgiving and it crashes before it can complete the whole tiling process. The cropping code I am using is from Hive05

http://www.hive05.com/2008/11/crop-an-image-using-the-iphone-sdk/

Has anyone else had to deal with such massive images before? Is pre-generating tiles the best way to go? Any suggestions on why some loops would increase the memory and some not, or how to force every auto-released thing to clear on the inner pool instead of waiting for the outer pool?

Thanks for reading this far.

for got to add, these images are TIFs, so perhaps a direct reading of the bitmap info would be better than scaling and cropping the entire thing

Answer 1

I ve managed to write the loops that cycle through tiles of 1024x1024 and my iPhone 3G is able to finish the processing. It takes over 30 minutes though so it isn t great but that s what you get for working with 150mb TIF on a cellphone.

To keep the memory usage low I had to drain the AutoReleasepools after each iteration. Apple Tech Support pointed out that since the iPhone is a reference-counted environment rather than a garbage collected environment it is better to create a new AutoReleasePool at the start of each inner loop and drain it at the end of each loop than to create it before any loops start, drain it many times and then release it after the loops are done. Until I made that change my app would crash an iPhone but run fine on the simulator.

Answer 2

First of all, I have serious doubts that an 150 MB image would fit in the device s memory, even if we re talking about a 3GS. That one has about 128 MB available memory for 3rd party apps maximum. See the device console messages and look for memory warnings, I guess you ll see that before crashing, the app emits them when trying to load your image. Reading the bitmap info in chunks would seem more sensible, as you ll be managing smaller sections at a time. I don t think Cocoa has a random-access file API, so you ll have to resort to a C function.

友情链接