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

[Cowa]

zed

небыло возможности проверить работу программы

А проверить стоит. Думаю понравится. Мне лично эта склейка не нужна. Я ею не пользуюсь. Мне был интересен сам подход к решению этого вопроса (склейка очень большого кол-ва тайлов). Это чтобы мозги не засыхали

если алгоритм действительно от Parasite-та, то есть возможность увеличить быстродействие раза в 2, отказавшись от "рандомности" и перейдя к линейной записи без предварительного заполнения BMP однородным цветом.

Можно достичь абсолютной линейности записи выходного файла, но тогда пострадает скорость (ну так раза в полтора как минимум). Так что у меня файл пишется не совсем линейно. А заполнения BMP однородным цветом никто и не делает.
Все делается почти последовательно и записью по 768 байт. Т.е файл увеличивается постепенно.
А чтобы увеличить быстродействие в 2 раза - то пишем сами реализацию алгоритма и показываем.

А насчет создание JPG непосредственно на диске (это ваша нескончаемая с Parasite тема), мне кажется, что вполне реально. Создается сначала BMP на диске, затем включается математика (причем бешенная, я вам скажу) и постепенно рассчитывая коэффициенты сжатия пишется на диск в заготовку JPG методом seek в то место в какое нужно. Потом файл обрезается и корректируется заголовок на предмет размера. BMP - удаляется.
Правда, думаю, этот процесс займет уйму времени, т.к. каждое действие пишется очень малыми блоками на диск. Корректируется и затем снова пишется. Я смотрел ссылки Parasite, все реально. Если найду нормальное описание последовательности кодирования (те,что видел, иногда противоречат друг другу) - то докажу. Но уже за денежку.

Parasite

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

(Это из описания алгоритма) Так вот, это ошибочное заявление (к сожалению). А так скорость бы выросла раз в 5-7.

[zed]

А заполнения BMP однородным цветом никто и не делает.
Все делается почти последовательно и записью по 768 байт. Т.е файл увеличивается постепенно.

Про быстродействие относилось ТОЛЬКО если вы работали по предложенному алгоритму, с предварительным созданием "пустого" BMP. А раз вы уже скорректировали алгоритм в сторону быстродействия, то вопрос снят.

Создается сначала BMP на диске, затем включается математика...

Очень "не правильно", возьмите сами FileMon, посмотрите на работу MapBuildera, и проверьте есть ли там где-нибуть готовый битмап из которого идёт построение JPG. Раз логика простая: JPG создаётся только из готового битмапа, то битмап должен где-нибудь быть - либо на венике, либо в оперативке/подкачке - то попробуйте найти, где же этот битмап у MapBuilder-a? Для надёжности, попробуйте создать JPG (MapBuilder-ом) 65*65k, при этом битмап должен занимать ~12 ГБ - такое трудно спрятать
Ищите в направлении ПОТОКОВОГО создания JPG - в этом вся изюминка.

Просьба к Parasite не вдаваться в рассуждения по данному посту касательно JPG, тему по этому вопросу, с вами, по прежнему считаем закрытой. Ок?

[Cowa]

zed
Тему JPG обсуждать пока не хочу, я еще не готов . Я лишь предложил один из вариантов.

битмап должен где-нибудь быть - либо на венике, либо в оперативке/подкачке

Подкачка - тот же винт. Т.е. битмап либо на винте либо в памяти. В памяти нет - ее бы не хватило. На винт тоже не пишется -

возьмите сами FileMon

Вот чудеса. Ну ладно, все, все, все, все, все - по поводу JPG делаем паузу.

[Parasite]

перейдя к линейной записи без предварительного заполнения BMP однородным цветом.

А гапы в финальном БМП как показывать будем (ситуация "хотели вклеить сюда тайл, но данного тайла в кэше не оказалось")?
Свалимся по OUT OF BOUNDS из-за байтового мусора в этом (необработанном) месте файла? Или покажем квадратик с пиксельной/цветовой кашей?
Ню-ню.

[zed]

перейдя к линейной записи без предварительного заполнения BMP однородным цветом.

А гапы в финальном БМП как показывать будем (ситуация "хотели вклеить сюда тайл, но данного тайла в кэше не оказалось")?
Свалимся по OUT OF BOUNDS из-за байтового мусора в этом (необработанном) месте файла? Или покажем квадратик с пиксельной/цветовой кашей?
Ню-ню.

Почему же, если тайл отсутствует, то вместо него пишется любой цвет, определённый заранее. Впрочем, это уже сделано, и ваш коммент не к месту.
Читайте:

Cowa
А заполнения BMP однородным цветом никто и не делает.

[Parasite]

Parasite

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

(Это из описания алгоритма) Так вот, это ошибочное заявление (к сожалению). А так скорость бы выросла раз в 5-7.

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

Я вполне допускаю, что побайтовая запись будет медленней той же построчной к примеру - ну так и нехай ее, это несабжевый параметр (и лично для меня не являющийся ключевым изначально - качает оно всё равно много дольше чем клеит, а при моем алгоритме клеить можно начинать уже после первого скачанного тайла и продолжать на форке с каждым следующим скачанным).

[zed]

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

Ого, создание BMP в реальном времени? Это для чего же?

[Parasite]

Почему же, если тайл отсутствует, то вместо него пишется любой цвет, определённый заранее.

Плавно приходим к выводу, что пустое место заполнять таки надо, и это надо будет будет тем больше, чем меньше будет скачанных тайлов и чем больit гапов к обработке.
Теперь сравните, что проще для конкретной реализации - разовое создание зануленного файла (ОДНА строчка сорца с элементарным while ($in, EOF, i++), либо постоянное дергание работающего алгоритма на тему проверки - надо ли занулять, и если надо - то таки пойти и занулить (причем не непрерывной линией а "квадратиком") отвлекшись от процесса клейки, и не пора ли прекращать зануление этого отдельно взятого гапа - в сухом остатке далеко НЕ одна строчка сорцев.

Впрочем, алгоритм был описан в общем и целом, а его конкретные реализации каждый волен выдумывать сам. В никсах например такой проблемы вообще не стоит - команда "dd /dev/null > ххх" даст любому желающему какой угодно большой нуленый файл сугубо средствами системы - абсолютно без необходимости программить это дело самому и отдельно. Либо же банальный запрос grow-файла, как вариант (нефиксированной длины и растущего по мере заполнения вплоть до лимита текущей ФС). В винде этого просто нет.

Впрочем, это уже сделано, и ваш коммент не к месту.
Читайте:

CowaА заполнения BMP однородным цветом никто и не делает.

Не к месту Ваш коммент "Уже сделано" в свете сказанного предыдущим оратором "Никто и не делает". Что именно сделано-то?
PS: ша, закрыли флейм - пока опять не началось©
PPS: Вы бы реальные примеры работающих алгоритмов бы так же споро писали бы лучше, как оффтопите...

[Parasite]

Ого, создание BMP в реальном времени? Это для чего же?

Ммда................
Ознакомьтесь, пожалуйста, ЕЩЕ РАЗ с алгоритмом - на сей раз внимательно, плиз! - и не отнимайте у меня время очередным оффтопом.

[Parasite]

Создается сначала BMP на диске, затем включается математика (причем бешенная, я вам скажу) и постепенно рассчитывая коэффициенты сжатия пишется на диск в заготовку JPG

Это называется "конвертнуть готовый БМП-файл в готовый к использованию ЖПЕГ-файл" (ключевое слово - файл). Это будет работать. На диске он находится, в РАМе или у черта на куличках в удаленном хранилище - дело десятое, ибо все равно он будет сперва прочитан в безусловном порядке. Имено так работает стандартный алгоритм - берет данные из одного готового файла, и через математику сливает во второй. И это вовсе не то, за что шел спор (ныне прекращенный с пользователем zed).
Все дело в том, что блоки при жпег-кодинге обходятся и коэффициенты сжатия у блоков рассчитываются не по порядку, а зигзагом через все изображение - причем зигзаг проходит по всему готовому изображению (визуально это похоже на лист из тетради в косую линейку), и обрабатывая строку N - Вы будете ОБЯЗАНЫ уже иметь и строку N+1, и N-1, и все остальные до конца данного Вами на вход кодеру изображения ("окантованного" маркером EOI), иначе кодинг вылетит с еррором. Другими словами, в жпег может быть утоптана ТОЛЬКО вся картинка разово, а не ее отдельные части постепенно.
Можете погуглить на тему визуализатора жпег-алгоритма, там доходчиво показано. Где-то встречал на рефератных сайтах...

PS: а я вот до сих пор так и не понял - а кому вообще понадобился именно жпег в свете сабжа? Кому-то нужен дважды пережатый картографический контент, или я что-то упустил изначально? Или у жпега какие-то специальные фичи в свете сабжа (кроме размера файла)?