Масштабирование и обрезка огромного изображения на iPhone

Question

В течение последних нескольких недель я разрывал свои волосы, пытаясь создать механизм для работы с плиточкой, работающий на iPhone. Мне нужно масштабировать и обрезать изображения размером около 150 мб, чтобы их можно было сохранить в виде плиток, которые будут запрашиваться в виде прокрутки, что позволит пользователю видеть изображение с высоким разрешением.

Проблема в том, что эти изображения действительно подталкивают границы того, что может обрабатывать iPhone. Кажется довольно легко масштабировать эти огромные изображения до 1000 или около того и делать эту черепицу, но для больших уровней масштабирования мне нужно масштабировать ее в середине, скажем, 4000, и это слишком велико. Поэтому я натолкнулся на идею создания блоков среднего размера из полноразмерного изображения и разбивки каждого из них и среднего масштаба.

Создавая autoreleasepool вокруг внутренних циклов и осушая его после каждого цикла, я могу в основном держать память под контролем, но иногда, и для меня это кажется случайным, память течет или, по крайней мере, не сливается. Я делаю все это на вторичном потоке, и когда он возвращается к первой функции в этом потоке, я освобождаю собственный autoreleasepool потока, и только тогда очищаются последние артефакты памяти. Это, похоже, не беспокоит симулятор, но iPhone гораздо менее прощает, и он падает, прежде чем он сможет завершить весь процесс черепицы. Кадрирование код, я использую от Hive05

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

Кто-нибудь еще приходилось иметь дело с такими массивными изображениями раньше? Является ли предварительная генерация плитки лучшим способом? Любые предложения о том, почему некоторые циклы увеличивают память, а некоторые нет, или как заставить каждую автоматически выпущенную вещь очищаться от внутреннего пула, а не ждать внешнего пула?

Спасибо, что прочитали это.

для GOT, чтобы добавить эти изображения TIFs, поэтому, возможно прямое считывание информации растровый будет лучше, чем масштабирование и кадрирование всю вещь

Answer 1

Мне удалось написать циклы, которые проходят через плитки 1024x1024, и мой iPhone 3G способен завершить обработку. Это занимает более 30 минут, хотя это не очень удобно, но это то, что вы получаете для работы с 150 Мбит TIF на мобильном телефоне.

Чтобы поддерживать низкое использование памяти, мне пришлось слить AutoReleasepool после каждой итерации. Apple Tech Support указала, что поскольку iPhone является средой с подсчетом ссылок, а не средой сбора мусора, лучше создать новый AutoReleasePool в начале каждого внутреннего цикла и слить его в конце каждого цикла, чем создать его раньше любые циклы начинают, истощают много раз, а затем отпускают их после завершения циклов. До тех пор, пока я не сделаю это изменение, мое приложение не сломит iPhone, но будет отлично работать на симуляторе.

Answer 2

Прежде всего, у меня есть серьезные сомнения в том, что 150 Изображение MB будет вписываться в память устройства, даже если мы говорим о 3GS. У этого есть около 128 МБ доступной памяти для сторонних приложений максимум. См. Сообщения консоли устройства и поиск предупреждений о памяти, я думаю, вы увидите, что перед сбоем приложение выбрасывает их при попытке загрузить изображение. Чтение информации растрового изображения в кусках показалось бы более разумным, так как вы будете управлять небольшими разделами за раз. Я не думаю, что у Cocoa есть API-интерфейс с произвольным доступом, поэтому вам придется прибегнуть к функции C.