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

[Cowa]

Господа, опять вы за свое. Возможно, конечно, в споре родится истина ...
Кстати, Parasite, сколько денег за алгоритм? Может стоит повозиться.
Да и еще, насколько принципиально если склеенный файл будет в BMP или в Jpeg. Ну кроме занимаемого места на диске. Ведь при открытии они в памяти будут занимать приблизительно одинаковый объем.

[svp]

Можете даже несколько упростить себе задачу: продемонстрировать мне создание любого сжатого архива (чем и является ЖПЕГ по факту) с конца его файла к началу или с середины и в обе стороны - с сохранением всей структуры и возможности дальнейшей работы с ним в обычном порядке.

Это не одно и тоже, а всё выми выше сказанное флейм, в создании коего Вы нас тут постоянно обвиняете.

Мой алгоритм позволяет такие вольности по отношению к БМП и ТИФФ без каких либо ограничений - хоть в шахматном порядке в оба параллельно...

Запись в произвольное место JPEG-a не требуется для его склейки из тайлов. И Zed уже пытался Вам дважды это сказать. Я тоже пытался. А Вы уцепились за свою произвольную запись пикселя или тайла в произвольное место. С тем, что это сложно или невозможно сделать не спорил никто.

Вот вам лог того же FileMon-а - построение jpg из тайлов в кэше GE. Он (лог) как раз и отображает последовательность: чтение из кэша GE в память n файлов - запись в финальный jpg, затем ОПЯТЬ ЧТЕНИЕ кэша и ОПЯТЬ ЗАПИСЬ в jpg и так по кругу.

Вложения
FM.ZIP
(2.92 KiB) Скачиваний: 1

Здесь Zed привёл доказательство своих слов, Вы же аккуратно обошли их:

По поводу MB - гуглить "libJPEG" (hint: оно же сигнатура "© Thomas G.Lane 6a 7-Feb-96" в екзешнике МБ). Входит в неизменном виде в состав Дельфи под эгидой "PasJPEG", если я не ошибаюсь - на коих дельфях и писан МБ. Если Вы мне покажете функции того, что приписываете МБ - в libJPEGе, то я публично сьем распечатки со всеми своими постами (и заодно дам Вам денег за работающий алгоритм). Если Вы не можете этого сделать - то просьба не тратить мое время на доказательство общеизвестного лично Вам.

Он показал Вам лог, как выше показали ему лог Вы. Теперь вы ссылаетесь на гугл не допуская даже вероятности, что в с jpeg можно работать и с помощью каких-то ещё дополнительных библиотек.

Такое очщущение, что Parasite просто пытается словесно обгадить всех, кто смеет с ним спорить. Причём делает это используя аргументы и словесный,я извиняюсь, понос, совершенно к делу не относящиеся. Очевидно в риторике с ним тягаться здесь некому, но не в логике.
Чтобы не захламлять впредь полезные ветки форума создал тему. Прошу с ответами сюда: viewtopic.php?f=2&t=70#p1768

[Parasite]

Такое очщущение, что Parasite просто пытается словесно обгадить всех, кто смеет с ним спорить. Причём делает это используя аргументы и словесный,я извиняюсь, понос, совершенно к делу не относящиеся.

Второй пошёл....©
Как закончите - скАжете. Продолжим обсуждение BMP + SAS.

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

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

[zed]

Если желаете оспорить сказанное мной - то плиз только детальные сведения технического порядка (коих я пока еще не вижу ни разу)

Имеющий глаза, да увидит... чем мои логи вас не устраивают?

[Parasite]

Parasite, сколько денег за алгоритм? Может стоит повозиться.

Договорно. Извольте в личку с готовыми примерами (можно триальными)...

Да и еще, насколько принципиально если склеенный файл будет в BMP или в Jpeg. Ну кроме занимаемого места на диске. Ведь при открытии они в памяти будут занимать приблизительно одинаковый объем.

ЖПЕГ - формат с потерями, БМП - нет. А контент и так не блещет качеством, чтобы его еще на раз усугублять очередным жпегом... и ЖПЕГ по данному алгоритму НЕ собрать.

[Parasite]

Если желаете оспорить сказанное мной - то плиз только детальные сведения технического порядка (коих я пока еще не вижу ни разу)

Имеющий глаза, да увидит... чем мои логи вас не устраивают?

Тем, что они по смыслу идентичны моим - чем теряется сама нить Вашей позиции в споре. Имеющему глаза видно, что строки:

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

82712   20:43:02   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 0 Length: 4096   
82713   20:43:02   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 4096 Length: 4096   
82714   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 8192 Length: 4096   
82715   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 12288 Length: 4096   
82716   20:43:02   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 16384 Length: 4096   
82717   20:43:02   MapBuilder.exe:4024   READ    E:   SUCCESS   Offset: 1179648 Length: 4096   
82718   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 20480 Length: 4096   
82719   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 24576 Length: 4096   
82720   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 28672 Length: 4096   
82721   20:43:02   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 32768 Length: 4096   
82722   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 36864 Length: 4096   
82723   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 40960 Length: 4096   
82724   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 45056 Length: 4096   
82725   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 49152 Length: 4096   
82726   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 53248 Length: 4096   
82727   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 57344 Length: 4096   
82728   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 61440 Length: 4096   
82729   20:43:02   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 65536 Length: 4096   
82730   20:43:02   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 69632 Length: 4096   
82731   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 73728 Length: 4096   
82732   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 77824 Length: 4096   
82733   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 81920 Length: 4096   
82734   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 86016 Length: 4096   
82735   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 90112 Length: 4096   
82736   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 94208 Length: 4096   
82737   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 98304 Length: 4096   
82738   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 102400 Length: 4096   
82739   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 106496 Length: 4096   
82740   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 110592 Length: 4096   
82741   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 114688 Length: 4096   
82742   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 118784 Length: 4096   
82743   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 122880 Length: 4096   
82744   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 126976 Length: 4096   
82745   20:43:03   MapBuilder.exe:4024   WRITE    E:\Кино\rrr.jpg   SUCCESS   Offset: 131072 Length: 4096   
82746   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 135168 Length: 4096   
82747   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 139264 Length: 4096   
82748   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 143360 Length: 4096   
82749   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 147456 Length: 4096   
82750   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 151552 Length: 4096   
82751   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 155648 Length: 4096   
82752   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 159744 Length: 4096   
82753   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 163840 Length: 4096   
82754   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 167936 Length: 4096   
82755   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 172032 Length: 4096   
82756   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 176128 Length: 4096   
82757   20:43:03   MapBuilder.exe:4024   WRITE   E:\Кино\rrr.jpg   SUCCESS   Offset: 180224 Length: 4096   
...итд


показывают линейную, а не рандомную запись файла rrr.jpg из пре-буфера ОС на запись (с размером FIFO буфера на дисковые операции в 4096 байт). Неужели Вам не видно, что адрес записи последовательно увеличивается на 4096, и что запись разова и ЛИНЕЙНА - на фоне того, что мой алгоритм использует только рандомную, а не линейную запись?
Это именно то, что показано также и в моих логах - и это именно то, что я и утверждал мессагами ранее (о стандартности работы со жпегом в МБ). О чем спорим-то, о имеющий язык?
Зафоркать же процесс выгребания из кэша с процессом дампа результата - дело трех минут чистого времени, и это давно есть даже в элементарных скриптовых языках (это в тему о наличии факта проверки кэша одновременно с процессом дампа результата).

[zed]

показывают линейную, а не рандомную...

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

MapBuilder при создании jpg единоразово отъедает по ~ 30 Мб в оперативке и в файле подкачки, а затем, последовательно пишет в файл на венике

А изначально то разговор шёл о обработке JPG на венике, а не в памяти. Вы упорно утверждали, что вначале нужно сразу ВСЕ данные загрузить в память, а уже затем их записать в JPG. В своём логе я показал, что загружать ВСЕ данные сразу нет необходимости, а можно их подгружать (а уже записанное выгружать) по ходу записи в JPG. Считаю разговор законченным.

[Parasite]

Про рандомную запись тут только вы и прожужжали все уши, я про это не говорил и никогда не имел в виду (между прочим)

Между прочим, просьба обьяснить мне - каким образом Вы собираетесь линейно клеить мелкий квадрат (тайл) в большой квадрат (составляемую карту), если вклеивание линейно приведет ко клейке линии, а не квадрата?
Квадрат следует клеить так:
1. сперва записывается первая пачка-линия пикселей из тайла (256 пикс);
2. потом пропускаем число "пустых" пикселей, равное (длина клеемой карты минус 256) - чтобы попасть на начало второй линии из тайла в большой карте;
3. записываем вторую линию пикселей из тайла (256 пикс);
4. пропускаем очередное число "пустых" пикселей, равное (длина клеемой карты минус 256) - чтобы попасть на начало третьей линии из тайла в большой карте;
5. повторяем, пока не кончится тайл (256 раз, ака 256 линий вклейки в отдельно взятом тайле, ака 256 рандомных доступов к файлу-приемнику на каждый клеемый тайл).

Ваш (и мой) логи показывают совершенно другую картину (а именно - линейную запись без пропусков по типу п2, п4 итд) - что доказывает наличие ВСЕГО предварительно собранного битмапа в памяти, и факт непрерывной записи на базе оного с попутным утаптыванием в жпег. Это именно то, что я Вам твержу уже на протяжении последней пары дней. Мне таки продолжать разжевывать всю глубину Вашего заблуждения? Извольте...

..разумеется, для клейки с пропусками - файл-приемник УЖЕ должен существовать, причем существовать в своем полном размере (чтобы ненароком не вылететь в OUT_OF_BOUNDS при клейке очередной линии). Но из Вашего лога опять же следует, что файл-приемник создается таки с нулевой длиной, и далее пропорционально растет согласно сдампливаемым в него данным, и делает он это разово и по порядку - в полнейшем соответствии с логикой работы libJPEG (сорцы свободно доступны всем заинтересованным желающим).

А изначально то разговор шёл о обработке JPG на венике, а не в памяти. Вы упорно утверждали, что вначале нужно сразу ВСЕ данные загрузить в память, а уже затем их записать в JPG.

Скажем так - это Вы голословно начали утверждать обратное, а я - обоснованно и на примерах оспорил.
Изначально я вообще не предлагал клеить в форматы, подразумевающие динамическое сжатие (см.пост с описанием алгоритма). Более того - я продолжаю утверждать, что описанный алгоритм безусловно не сработает при составлении ЖПЕГа.

В своём логе я показал, что загружать ВСЕ данные сразу нет необходимости

Ваш (и мой) лог показывает разовый и линейный дамп уже сформированной в памяти ЖПЕГ-структуры на диск. Ничего более этого.

можно их подгружать (а уже записанное выгружать) по ходу записи в JPG.

Google: "forking threads" (примерно 2 680 000 результатов найдено...)

Считаю разговор законченным.

Аргументы закончились?

[zed]

Между прочим, просьба обьяснить мне - каким образом Вы собираетесь линейно клеить мелкий квадрат (тайл) в большой квадрат (составляемую карту), если вклеивание линейно приведет ко клейке линии, а не квадрата?

Последняя просьба так сказать?
Ну что ж, неужели самому нельзя догадаться до:
- в память загружается n-тайлов 256*256, количество n определяется: Разрешение выходного JPG делённое на 256. (в предельном случае, при построении JPG шириной 65k, n=256 - в памяти они займут ~ 50МБ);
- поскольку в память мы загрузили не "абы-какие" файлы, а именно те, что следует писать в JPG, то из каждого n-файла берётся первая строчка 256 пикселей и формируется первая строка для записи длиной n*256;
- в JPG пишется первая строка ПОЛНОСТЬЮ, без пропусков;
- формируется следующая строка n*256 и так 256 раз (вполне возможно, что обработчику JPG передаётся не одна строка, а 8 или сразу все 256, из-за особенностей JPG-компрессии, но суть дела это ни сколько не меняет);
- на место старых n тайлов, в память загружаются следующие, и "процесс" повторяется.
"Это же элементарно, Ватсон!" И хватит пустых разговоров, все что хотел сказать, я сказал и думаю довольно внятно. Тот кто возмётся плотнее за вопрос построения JPG не в памяти, сам разберётся что к чему.

Мне таки продолжать разжевывать всю глубину Вашего заблуждения? Извольте...

Смешно, на основе предложенного ВАМИ ошибочного алгоритма, ВЫ пришли к выводу о моём заблуждении. Может хватит?

Кстати, про MapBuilder: в нём так же реализован и алгоритм построения BMP на венике, как вы и предлагали, с первоначальным созданием заполненного однородным цветом файла и т.д. по шагам... может автор MapBuilder-а не очень обидится, если вы выложите часть исходников, касаемо хотя бы BMP - не такой уж это и секрет.

[Parasite]

в память загружается n-тайлов 256*256,

Ах все-таки в память, все-таки загружаются и все-таки N тайлов......как раз N тайлов грузит и стандартный обработчик, и SAS при склейке. В чем сакральный смысл Вашего метода? Только в количестве этих оных N, грузимых разово? Ну так клейте SASом маленькие картинки с числом тайлов равному нужному Вам N - никакой переделки САСа и не понадобится........

- в JPG пишется первая строка ПОЛНОСТЬЮ, без пропусков

(устало): Поржал, спасибо.
В последний раз уведомляю Вас, что в ЖПЕГ невозможно записать "первую строку©", остановиться подумать, покурить, попить кофе, сходить выгулять ящерицу, подождать, укачать следующую пачку тайлов, скомпоновать ему вторую строку битмапом и дать добавить к предыдущей - стандартно в ЖПЕГ разово пакуется и записывается ВЕСЬ контент, на базе ВСЕЙ подготовленной к упаковке картинки. Говоря в свете "в JPG пишется первая строка" - Вы говорите о том, что в ЖПЕГ будут утоптаны Ваша первая строка + нули до конца Вашего контента согласно размеров Вашего изображения забитого в заголовок - даже если Вы их не задавали, и все это дело будет закруглено в ЖПЕГе маркером EOI (в противном случае при упаковке Вы получите "BROKEN_PIPE" и упаковка в жпег будет прервана по критическому еррору). И эта операция будет разовой и необратимой в смысле потерь в ЖПЕГе. Передавая жпегу на вход указание "утопчи мне изображение размером 1000х1000, но пока что вот тебе лишь 1000х8 и немного подожди" - Вы получите еррор "EOI NOT FOUND": передав ему EOI после передачи контента 1000х8 - Вы получите жпег-картинку 1000х8 и не более, а передав EOI в свете нужной картинки 1000х1000 - Вы получите одну картинку 1000х1000 в жпеге, где всё забито нулями после Вашего контента и до конца картинки (и оные нули будут отлично утоптаны в жпег тоже).
Фичи же дозаписи алгоритм ЖПЕГ не подразумевает в принципе (добавить часть к этой картинке будет означать - распаковать предыдущую, докинуть в нее добавляемый битмап и заново утоптать весь контент в жпег).

Напоминаю в последний раз, что самой крупной единицей в рамках работы со ЖПЕГом во всех его режимах является изображение (image) - т.е. само изображение, которое надо сжать и которое и подается кодеру на вход - и с которым и работает кодер по своим внутренним алгоритмам, начиная от проверки размеров всего изображения на кратность 8ке и конвертации всего изображения в YCbCr. Отход от этого принципа приведет к необходимости писать свой кодер "жпег" в кавычках, и результат более чем вероятно будет несовместим со стандартами жпега (оно же стандарт ISO/IEC IS 10918-1) и соответственно со стандартными распаковщиками/вьюверами оного, чем вопрос про именно жпег теряет силу.

Засим разговор про ЖПЕГ закончен - мне, извините, надоело чесать языком (пальцами) в пустоту. Оратору просьба таки покурить данные ранее ссылки про компрессию в ЖПЕГ и работу с нею. Дальнейшее обсуждение - только по доказательству точки зрения оратора (в виде готовых рабочих и проверяемых алгоритмов и работающих скомпиленных семплов, а не пустых теоретических рассуждений). Исходники же алгоритмов "классического" жпега есть, например, в том же libJPEG или например на исходники.ру (http://sources.ru/cpp/graphics/graph_converter.shtml)