zed писал(а):Parasite писал(а):Впрочем, я еще не встречал пользователя которому бы не хватало 65*65k...
Ну? Вот мы и встретились
Мне лично не хватает... прикиньте, к примеру, снимок Москвы в 19 зуме одним файлом
Поиск по
этой странице на слово "RAW" - поможет отцу русской демократии.
zed писал(а):MapBuilder клеит в памяти и через своп.
Хм, что есть своп?
Своп есть расширение основной памяти (RAM) при наличии ее отсутствия в нужных приложению рамках.
zed писал(а):MapBuilder при создании jpg единоразово отъедает по ~ 30 Мб в оперативке и в файле подкачки, а затем, последовательно пишет в файл на венике (размер которого увеличивается не скачком с 0 и до нормального, а определёнными порциями). При этом расходуемая память не растёт, как у SAS (у которого обработка идёт в памяти), в зависимости от размера выходного файла.
MapBuilder создаёт один большой JPG из тысяч маленьких jpg, и вы хотите сказать, что вначале тысячи маленьких распаковываются, а затем они пакуются в один JPG?
Совершенно верно.
Другой вопрос, что алгоритм данного процесса в MB намного более оптимизирован, чем у SAS (на что я указывал автору SAS не раз, но......).
zed писал(а):Нет, всё происходит пошагово - распаковка n-го числа мелких файлов - запись/упаковка в новый JPG - и так по кругу.
Заблуждение.
Нет
НИКАКОГО способа собрать
составной жпег без общей разовой упаковки всего готового файла, На этом - всё. Учите, плиз, матчасть.
Для примера - можете попытаться поменять один (стого определенный) пиксель в одном (строго определенном) месте изображения, сохраненного (сохраняемого) в ЖПЕГ. Для конкретного примера - картинка 1600\1200, жпег, размер 238Кб - поменять пиксели 20\20, 40\20 и 40\40 на цвет #00 - БЕЗ распаковки и последующей повторной упаковки в ЖПЕГ (просьба указать конкретные смещения от начала исходного файла и их новые значения - для решения данной задачи).
PS: В БМП это
элементарно, путем банального ВинХекс по разово вычисляемым и фиксированным смещениям.
) Надо будет поковыряться на досуге.
