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

[Parasite]

Поиск по этой странице на слово "RAW" - поможет отцу русской демократии.

И к чему здесь RAW? Меня вполне устраивает ECW, без этих jpg/bmp-лимитов

Прочитайте еще раз тот мой пост, где было дано многословное описание алгоритма (который сейчас и обсуждается, нек.образом). Там написано черным по белому и про RAW в том числе.
А если все устраивает и так - то вообще непонятен сам факт Вашего обсуждения того, что Вам не нужно.
Меня - НЕ устраивает ни как экзотика ECW, ни как очередной формат с потерями JP2000, ни "Недостаточно памяти для отработки команды" - поэтому и предлагаются более разумные пути обхода этого всего великолепия.

Своп есть расширение основной памяти (RAM) при наличии ее отсутствия в нужных приложению рамках.

И как это относится к MapBuilder-у, если его затраты на память минимальны?

Своп относится к МапБилдеру обратно пропорционально качеству оптимизации кода и прожорливости к памяти оного МапБилдера.

теряя в качестве. Вопрос в том, что это не так просто как с BMP, и WinHex тут не в помощь. Но на программном уровне это решаемо. Таким же образом и MapBuilder, не нагружая память, работает с JPG

Казалось бы - что мешает поставить FileMon и посмотреть самому - куда как и зачем обращается MB при своей работе, чем сидеть и многословно заблуждаться в паблике?
А алгоритм произвольного изменения графического контента упакованного в ЖПЕГ, без необходимости последующей перепаковки\прохода софтом по файлу и затрагивания соседних с изменяемыми данных - я лично готов у Вас купить за деньги (повороты\вращения сюда не относятся - они не приводят к изменению собственно контента, неприменимы к SAS в теме сабжа вследствие ненужности и тут не обсуждались изначально).

[Parasite]

Нет НИКАКОГО способа собрать составной жпег без общей разовой упаковки всего готового файла, На этом - всё. Учите, плиз, матчасть.

Есть! Наверно имеет смысл отослать к изучению матчасти именно Вас, Parasite.
Цветовые каналы изображения в jpeg разбиты на квадраты (блоки). Поменять один пиксель не затронув всего блока, естественно, нельзя, но можно не трогать и не распаковывать остальные блоки. Именно на этом принципе работают преобразования Jpeg без потери качества в XNView. Там можно поворачивать картинку на n*90 градусов. При этом первоначальная ширина и высота картинки обрезаются по модулю 8, то есть неполные блоки отрезаются. Если их оставить, то разбивка на блоки всего изображения поменяется и его надо будет перепаковывать с новыми потерями.
При клейке большого Jpeg'а из маленьких с размерами кратными размеру блока, совершенно очевидно, не потребуют перепаковки всего изображения.
В этом Zed прав.

Дремучее заблуждение по большинству пунктов (хотя некоторые основы матчасти оратор таки слышал).
1. Lossless-операции над ЖПЕГ-контентом реализуются не поблочно и не по-канально, а над всем файлом единоразово благодаря "lossless"-rotation (в кавычки взято не зря). Вывод: нет НИКАКОЙ возможности "безпотерьно" повернуть\кропнуть\изменить один блок в ЖПЕГе не затрагивая всего остального содержимого файла.
2. Более того - нет никакой возможности изменить произвольное число пикселей в блоке, не затрагивая соседей по блоку - без последующего пересчета и квантизации всего данного блока, пересчета оного и последующего изменения индексной таблицы блоков в заголовке (как минимум - чтоб не вдаваться в детали).
3. И более того - нет никакой возможности одномоментно вычислить точное смещение начала данных по конкретному нужному пикселю относительно начала файла без необходимости разборки как минимум заголовка файла и чтения (к тому же поканально, то есть не за один раз) данных о нужном блоке, а из него - уже о нужном пикселе. Далее - см.п.1
4. Операции над блоками при ЖПЕГ-компрессии относятся к начальным этапам кодирования. Почту за честь уведомить Вас, что после разбития блоков и квантизации каждого - в рамках упаковки в ЖПЕГ проводится еще довольно большое количество шагов до получения окончательного файла. Например тут (http://doug.kerr.home.att.net/pumpkin/J ... on_DAK.pdf) хорошо и пошагово расписано. Прошу обратить внимание, что поблочная разбивка и локальная обработка каждого - это п.3.7 вышеупомянутого документа, а получение финального ЖПЕГа - это п.3.15 там же, то есть Вами из обсуждения умышленно проскипана ПОЛОВИНА крайне необходимых операций над файлом (в том числе и глобальных - например Хаффманн-компрессия значений всех блоков, индексация в заголовок файла - без коих операций это не файл жпег-стандарта, а набор случайных полупереваренных алгоритмом байт).
5. И еще более того - порядок байтового прохода в standart JPEG и progressive JPEG разный, и соответственно будут отличаться процедуры работы с ними.

И так далее (могу продолжить, но не вижу смысла и обоснования временных затрат на).
Оратору просьба таки ознакомиться с матчастью перед вступлением в тематическую дискуссию, чтобы не выюзывать время собеседника на обьяснение прописных общеизвестных истин. Благодарю.

PS: впрочем, у Вас всегда есть возможность показать мне возможность смены случайного пикселя в ЖПЕГ-контенте путем разовой байтовой замены в теле файла сторонним процессом без необходимости обращения ни к заголовку, ни к соседним с изменяемыми данным. Показать на деле - в виде рабочего алгоритма на любом доступном языке программирования, а не голословных теоретических рассуждений.
PPS: работа с большими, глобальными изображениями - это моя работа на протяжении уже ряда лет, большинство из которой осуществляется в ImagePro Plus http://www.mediacy.com/index.aspx?page=IPPFeatures (который является топовой научной программой для работы с глобальными многогигабайтными изображениями вообще, и с высококачественными RAW-данными сканирования результатов канальной микроскопии в частности - и он тоже не может менять ЖПЕГ без перепаковки, но может БМП и ТИФФ без сжатия согласно предложенного мною ранее алгоритма, а также умеет индексный ГИФ с "lossless"-перепаковкой).
На чем и позвольте откланяться.

[svp]

Это говорил я:

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

Я также не утверждал, что не придётся обходить весь JPEG файл. Это не проблема. Проблема держать в оперативной памяти ОГРОМНЫЙ битмап.

А это вот уже второй раз говорит Parasite:

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

Не шла речь так же и о "прогрессивном" сжатии. Оно здесь не нужно. Речь идёт о ЧАСТНОМ случае, а не о полной поддержке формата. Именно о частном случае сборки большого jpeg-файла с минимальными затратами вычислительных ресурсов и оперативной памяти. А вы тут собрали все свои дюжие познания. Сражён наповал вашим резюме=).
Ни о какой коррекции произвольного пикселя изначально речи не шло и не может идти! Зачем гнать столько ненужной воды? Я не специалист по алгоритмам jpeg-сжатия и не вдавался никогда в их тонкости. Просто размышляю логично исходя из наблюдаемых фактов. Наверняка не требуется иметь огромный битмап в памяти чтобы сжать его в JPEG. Очевидно есть потоковые алгоритмы, которые могут писать прямо на винчестер.

[Cowa]

Parasite , спасибо за ссылки.
Господа, ну что вы все воюете . Подкрепление своего мнения ссылками на источник довольно быстро успокаивает народ. А рассуждения типа: MapBuilder работает с jpeg так-то и так-то, на мой взгляд не обоснованы. Это мнение отдельного оратора. Факты где. Чем проверялось? Короче, ссылки в студию. С другой стороны, хотелось бы видеть алгоритм преобразования BMP в Jpeg непосредственно на винте. Ну сделаю я склеенный BMP в пару гигов - и что с ним делать-то. Или RAW.

[Parasite]

Проблема держать в оперативной памяти ОГРОМНЫЙ битмап.

Да, это главная проблема.
Решение же я описывал (прямое конструирование контейнера с линейным доступом на диске).

А это вот уже второй раз говорит Parasite:

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

Не шла речь так же о ... сжатии. Оно здесь не нужно.

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

Речь идёт о ЧАСТНОМ случае, а не о полной поддержке формата.

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

Ни о какой коррекции произвольного пикселя изначально речи не шло и не может идти! Зачем гнать столько ненужной воды?

А как еще Вы планировали заполнять свежесозданный контейнер информацией, как не попиксельно\построчно\поблочно (читай - побайтно прямой записью в файл-контейнер)?

Наверняка не требуется иметь огромный битмап в памяти чтобы сжать его в JPEG.

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

Очевидно есть потоковые алгоритмы, которые могут писать прямо на винчестер.

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

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

[Parasite]

Parasite , спасибо за ссылки.

Не вопрос. Пешы ысчо.

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

Да, мне тоже. Путем прямой записи в файл-приемник сторонним процессом (НЕ упаковщиком данного формата), повторюсь.

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

Если картинка 800\600 в формате БМП или ТИФФ будет занимать, к примеру, РОВНО 1Мб (для примера, повторюсь) - то она это будет делать ВСЕГДА, независимо от контента, какой бы там ни был, и ничто не мешает сперва вычислить размер, создать оный 1Мб на винте, а потом в него клеить какой угодно контент - и получившаяся картинка будет валидна всегда.

В жпеге же чисто черная картинка может занимать 10Кб (к примеру), а попиксельная шахматка по инверсным цветам того же размера 800\600 - все 500Кб (к примеру), причем выяснится это ТОЛЬКО после сжатия всего исходного 800\600 и полной отработки всего алгоритма жпег-компрессии (и соответствующего отьедания памяти в процессе). То же самое и про ГИФ, и про compressed-ТИФФ, и про все остальные с той или иной мерой компрессии.

А теперь подождем ответа предыдущих ораторов...

[zed]

хотелось бы видеть алгоритм преобразования BMP в Jpeg непосредственно на винте.
Да, мне тоже. Путем прямой записи в файл-приемник сторонним процессом (НЕ упаковщиком данного формата), повторюсь.

MapBuilder как раз-таки УПАКОВЩИК jpg, а конкретный алгоритм можете попросить у автора MapBuilder-а, авось не зажмёт...

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

[Parasite]

хотелось бы видеть алгоритм преобразования BMP в Jpeg непосредственно на винте.
Да, мне тоже. Путем прямой записи в файл-приемник сторонним процессом (НЕ упаковщиком данного формата), повторюсь.

MapBuilder как раз-таки УПАКОВЩИК jpg, а конкретный алгоритм можете попросить у автора MapBuilder-а, авось не зажмёт...

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

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

Также, если Вы посмотрите внутрь екзешника MB - Вы возможно узнаете, что обработчик жпега в данной программе - ничто иное как libJPEG 6.0a от 7 февраля 1996 года (то есть 12 лет назад - когда, заметьте, в ходу были картинки 320\200 и 640\480, а глобальными считались 1600\1200 и про линейную склейку оных никто разговора не вел). Данный пакет довольно хорош и быстр как стандартный обработчик\парсер ЖПЕГов, изучен вдоль и поперек и используется в огромной куче фряшных продуктов. ВСЕ функции данного пакета элементарно гуглятся, и в них нет ничего изумительного и невероятного.

За алгоритм же прямого конструирования ЖПЕГа без участия стандартных жпег-упаковщиков я уже предложил денег - ловите момент. Мой способ позволяет делать это только для БМП и ТИФФ.

PS: Вопрос не в том, почему MB собирает большой жпег быстро - вопрос в том, почему SAS собирает этот же жпег медленно (да еще и еррорит по ходу дела). Алгоритмы жпег-сжатия за годы использования в миллионах продуктов уже вылизаны как у кота, и довольно быстры сами по себе (например полноцветная картинка 10Кх10К "в уме" утаптывается за время меньше одной секунды, разово занимая память около 300Мб в пике - что для современной машины абсолютно некритично).

Parasite, вы доказываете неизвестно что

Отстаньте с флеймом, ради Христа. Просьба быть обьективным и не сваливаться в личности, а оффтоп - просьба направлять направо©. Спасибо.
Что именно я доказываю - я описал в предыдущих постах довольно подробно и, надеюсь, максимально понятно. Теперь того же самого жду от Вас, если Вам есть чего сказать по теме - обоснованного и подтвержденного проверяемыми фактами. Если нет - то обсуждение создания жпега на винте со своей стороны считаю законченным по его техзнической несостоятельности (но вопрос по БМП и ТИФФ - по-прежнему открыт).

Благодарю за внимание, я кончил.

[zed]

У меня есть полные сорцы (как и ES тоже), спасибо

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

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

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

[Parasite]

И этот человек, у которого есть сорцы, но он их жмотит

Дальнейшее обсуждение данной темы с этим отдельно взятым оратором считаю законченным. Если ему неочевидна ситуация "НЕ МОИ сорцы и без права дальнейшего распространения" в плане "он их жмотит©" - то говорить тут больше не о чем, а доказывать очевидное и общеизвестное в ответ на абсолютные домыслы и ничем не подкрепленные заявления, разгребая всю эту детскую непосредственность - у меня нет ни времени, ни желания, ни моральной либо материальной заинтересованности.

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

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

Всё.