Недостаточно памяти для отработки команды.

[Necros]

у меня 4 гига оперативы.. но ХР видит лишь 3 гига.. а склеивание происходит лишь когда выбрано максимум 36х36 .. нельзя ли как-нибудь оптимизировать склеивалку?

Ставь 64 битную систему она видит до 32Гб ОЗУ

[Parasite]

Да склейка в отличии от загрузки требует много ОЗУ, для 1Gb максимальное разрешение при склейке примерно 16000*16000 пикселей.

Не стоит недооценивать фичи виртуальной памяти (в просторечии - своп).

PS: присоединяюсь к вопросу про "недостаточно памяти". На компе 8Гб памяти (х64) + авторазмер свопа. Отказывается клеить карту 56х50 тайлов (хотя в фотошопе прекрасно обрабатываются и гораздо более глобальные изображения, на той же машине)

[angoo]

Практически аналогичная проблема.
v 0.9.9.943
карта размером 13040*10000
на машине с 512Мб опертивки шурша свопом собирает за 30 минут. Но есть проблема. Случайным образом на собранном фрагменте появляются один или несколько белых квадратов. Соответсвующие фрагменты 100% загружены.

на машине с 2,5Гб ОЗУ та же карта, тот же кэш и та же копия программы сначала прячет окошко выбора места сохранения и имени файла за основным, а затем после указания имени файла сообщает приблизительно следующее "Недостаточно памяти для обработки программы. Обработано файлов 0".

В чем могут быть грабли?

[Parasite]

На компе 8Гб памяти (х64) + авторазмер свопа. Отказывается клеить карту 56х50 тайлов

Маразм крепчал. ТА ЖЕ карта была укачана GoogleMV и ПРЕКРАСНЕЙШЕ буквально за пару минут сведена в единый файл без каких-либо ошибок и даже не особо свопясь в процессе. На той же машине, тем же юзером, тот же участок и того же размера.

Автору СЛЕЗНАЯ просьба таки обратить внимание на глюк. Могу предложить алгоритм, позволяющий склеивать практически безразмерные изображения с практически нулевыми затратами машинных ресурсов (используется в некоторых режимах ::TK и ::ImageMagic в Перле, например).

[svp]

Могу предложить алгоритм, позволяющий склеивать практически безразмерные изображения с практически нулевыми затратами машинных ресурсов (используется в некоторых режимах ::TK и ::ImageMagic в Перле, например).

Ну так предлагайте и выкладывайте! =). Если у автора руки не дойдут, то кто-нибудь (я например) сделает отдельную клеилку. На входе файл выделения -- на выходе склеенная картинка. Вообще пичкать всё в одну прогу -- не есть хорошо. Надо постепенно думать о плагинах. Скрипты вот уже работают. Может сочитним интерфейсы и azya сделает поддержку внешних клеилок, закачивалок, механизмов доступа к кешу в виде отдельных dll-ек,
А если пока он сочтет нужным это не делать, то будем клеить внешними утилитами.
В любом случае алгоритмы, статьи, исходники и проч по скеливанию больших картинок выкладывайте. Энтузиасты найдутся.
Также поощраются исходники и описания механизмов антибана для гугла.

[Parasite]

Могу предложить алгоритм, позволяющий склеивать практически безразмерные изображения с практически нулевыми затратами машинных ресурсов (используется в некоторых режимах ::TK и ::ImageMagic в Перле, например).

Ну так предлагайте и выкладывайте! =). Если у автора руки не дойдут, то кто-нибудь (я например) сделает отдельную клеилку. На входе файл выделения -- на выходе склеенная картинка.

Предлагаю (готовых сорцев под винду нет - я отошел от програмимирования под нее лет 10 назад и юзаю только по необходимости - посему опишу, так скать, человеческим языком):
1. Берем параметры выделения юзером (X-Y-zoom), вычисляем в уме - сколько на сколько будет финальная картинка (в пикселях).
2. Высчитываем в уме - сколько нам потребуется байт под данную картинку в формате BMP либо (если вылазим за лимитейшны формата BMP по размерам) - то в TIFF без сжатия. Выделенное болдом - крайне важно.
3. Приплюсовываем к полученному числу стандартную длину стандартного БМП либо ТИФФ заголовка при данном разрешении (предварительно заполнив в заголовках все нужные поля по типу Х, Y итд).
Полученное число - точный размер картинки финального файла в байтах.
Все вышесказанные пункты делаются "в уме" и практически моментально, повторюсь.
4. Создаем на винте темповый grow-файл (либо, если винда не позволяет создавать grow-файлы - то создаем фиксированный файл данного размера, заполняя его нулями либо #FF) с рандом-доступом. В первом случае создание будет моментальным, во втором - возможно, займет минуту-две.
5. В оный файл со смещения #0000 пишем побайтно собранный стандартный заголовок из п.3. Записать несколько десятков байт заголовка - это практически мгновенно.
Получаем двумерный массив байт #00 с размерностью финальной картинки и уже готовым заголовком.

Уже на этой стадии файл должен открываться стандартными просмотрщиками в виде глобального черного (при заливке #00) либо белого (при заливке #FF) прямоугольника с размером финальной картинки.

6. Берем из кэша тайл 256х256. Растягиваем его в уме до битмапа (получаем двумерный массив 256х256пикс=65Кпикс размером). Вычисляем в уме, какое квадратное место в финальном массиве он должен занять. Пишем оные мелкие 65Кпикс побайтно в большой файл (записать несколько десятков Кб в произвольное место файла по смещению, не забывая про "квадратность" а не линейность исходного набора 65кпикс - это будет практически мгновенно).
7. Повторяем п.6 для всех необходимых тайлов, не забывая сбрасывать из памяти данные обработки предыдущего тайла перед началом обработки нового.
8. По окончании процесса - закрываем большой файл и переименовываем его в .bmp либо .tif

В сухом остатке: заполненный данными глобальный файл с заголовком, все тайлы - вклеены в оный, пустые места в оном (в случае пропуска тайлов) будут видны как черные либо белые квадраты 256х256, пиковый максимальный запрос к памяти - 65Kb.data + XXXX.program (для собственно работающего процесса). В случае работы с интерпретатором Перла макс.запрос к памяти ни разу не превышал 8мб (при этом создавались многогигабайтные выходные файлы), никаких тормозов\переполнений памяти\выгрузок соседних процессов замечено не было. Скорость заполнения основного файла при данной задаче на современных машинах примерно равна скорости линейной записи такого же но пустого файла (1-2 минуты на 4Гб), ибо временем работы собственно алгоритма и обработки блочков данных 256х256 можно пренебречь (особенно если рассадить оные на мульти-(процессорность\ядерность)). Потери качества файла НЕТ (бмп\тифф без сжатия - форматы без потерь).
Необходимости постоянно ворочать весь глобальный файл в виде графики В УМЕ, жутко свопясь\тормозя\выгружая соседние процессы (как это делают большинство прикладного виндявого софта включая и Фотошоп) - нет.

Далее юзер волен конвертнуть полученный файл во что угодно сторонними средствами.

PS: если файл настолько глобален что не лезет даже в лимиты ТИФФа - то вместо тиффа принимаем файл с последовательной записью данных без заголовков (т.е. RAW), далее - все так же. Последние версии фотошопа умеют открывать глобальные RAWы - главное, правильно создать оные и выставить те же самые чередования данных в фотошопе при открытии.

Подобным способом лично я обрабатывал изображения по 15-20ГИГАбайт на файл (правда не в Фотошопе ввиду его отказа работать с такими большими картинками, а в Image-Pro PLUS - но смысл тот же). Кстати, вышеописанный алгоритм является нативным для Image-Pro PLUS, для профессиональных графических RIPов-интерполяторов итд - так как по-другому ворочать многогигабайтные массивы просто не получится - никакого RAMа не хватит.

Вообще пичкать всё в одну прогу -- не есть хорошо. Надо постепенно думать о плагинах.

Я это говорил где-то в одной из предыдущих мессаг - но оное было как-то проигнорировано...
Я - ЗА плагины. ГЕ можно плагином прикрутить, нужный мне Zoomify - тоже....
PS: было бы отлично если бы плагины были скриптовыми, а не прекомпиленными.

[svp]

Предлагаю (готовых сорцев под винду нет - я отошел от програмимирования под нее лет 10 назад и юзаю только по необходимости - посему опишу, так скать, человеческим языком):

То, что вы рассказали человеческим языком, понятно и ежу. Я, вообще-то, рассчитывал, что есть хоть какие-то исходники, дабы не разбираться по новой в шапках разных форматов. Да и почему так важно под какую ОС исходники? Портировать всегда проще и быстрее, чем разбираться и наступать на (даже простейшие) грабли с нуля.
Есть исходники на перле? Милости просим. Алгоритм тут не хитрый, время уходит на детали, а не на такие очевидные и простые вещи.

[Parasite]

Предлагаю (готовых сорцев под винду нет - я отошел от програмимирования под нее лет 10 назад и юзаю только по необходимости - посему опишу, так скать, человеческим языком):

То, что вы рассказали человеческим языком, понятно и ежу.

Разумеется. Ничего кардинально нового и чудодейственного я и не обещал (кроме алгоритма, который РАБОТАЕТ и позволяет эффективно решать возложенную задачу), а то что рассказал - постарался максимально расписать в деталях.
В любом случае, если это понятно и ежу - то почему сей алгоритм введен в число прог, которые можно пересчитать по пальцам одной руки?

Я, вообще-то, рассчитывал, что есть хоть какие-то исходники, дабы не разбираться по новой в шапках разных форматов.

То есть, вопрос о структуре заголовка?
http://c-site.h1.ru/infa/bmp_struct.htm (БМП)
http://el-izdanie.narod.ru/gl4/4-4.htm (TIFF)
ну или google.com (откуда и взяты верхние ссылки за минуту поиска)
PS: свои исходники - запощу как попадутся под руку, надо искать на архивных болванках, уж шибко давно это было.

Портировать всегда проще и быстрее, чем разбираться и наступать на (даже простейшие) грабли с нуля.

О каких КОНКРЕТНО граблях речь? Форматам этим уже сто лет в обед, и даже стандартные процедуры работы с ними вылизаны еще лучше, чем у кота, не говоря уж про документирование заголовков и структуры файла. В любом случае, готовых исходников (и не перловых, а нормальных) полно на любом сайте фряшного софта, в разделе ГРАФИКА (фряшный софт как правило идет с сорцами, и поддержка BMP/TIFF в практически всех графпрогах - это стандарт де-факто).

[svp]

То есть, вопрос о структуре заголовка?

О каких КОНКРЕТНО граблях речь?

Речь шла о времени на написание и отладку кода. И о возможности сэкономить это время, если уже есть готовые исходники или библиотеки.

[Parasite]

о времени на написание и отладку кода. И о возможности сэкономить это время, если уже есть готовые исходники

Не совсем понятно, чем Вам смогут помочь готовые исходники на перле - на фоне того, что SAS был писан явно не на нем. Сам же алгоритм действий - описан, а портировать с языка на язык один мелкий отдельно взятый алгоритм - геморроя будет больше, чем написать его с нуля сразу в нужном языке (особенно если учесть, что переводить придется с модульного скриптового языка - в прекомпилируемый код). Вот типичнейший кусок простенького сорца на перле, разбираться в коем - сомнительное удовольствие:

Код: Выделить всё

    my $get=LWP::UserAgent->new();$req=HTTP::Request->new(GET=>$link);
    $response=$get->request($req); if ($response->is_error())
      { $error=$response->status_line; return 0  }
    ($name=$link)=~s(^.*/)();open(DUMP,">$store");binmode DUMP;$an=$response->as_string;
    chomp($an); $an=~m/\n\n(.*)/s;


PS: Впрочем, про готовые исходники я тоже писал выше. Попадутся под руку - запощу, не вопрос.