SASGIS

Веб-картография и навигация


View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000295SAS.Планета[All Projects] Хотелкаpublic04-12-2010 20:0216-05-2015 08:26
ReporterParasite 
Assigned Tovdemidov 
PrioritynormalSeveritytweakReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformWindowsOSXPOS VersionSP3
Product Version101201 
Target Version150915Fixed in Version150915 
Summary0000295: Сохранение (либо экспорт) графики в RAW-формат
DescriptionПодробности тут:
http://sasgis.org/forum/viewtopic.php?p=11240#p11240

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

- Relationships
related to 0001213closedvdemidov Склеивание BMP больше 32767x32767 

-  Notes
(0007038)
vdemidov (manager)
17-05-2012 05:14

Может кто-то сделает такую склейку? Сейчас это уже очень просто сделать. Нужно только фреймик с настройками нарисовать и сам формат придумать.
(0007041)
zed (manager)
17-05-2012 06:41

>Сейчас это уже очень просто сделать.
Это смотря как делать. Если вроде BMP, то просто, но там идёт расход памяти на удержание всей строки тайлов (в распакованном виде) и больших размеров RAW всё равно не склеишь. А вот если делать железо-бетонный RAW, с возможностью сводить всю землю на 20-м зуме, то нужно действовать более аккуратно - таскать из кэша тайлики, применять к ним настройки, накладывать оверлеи и потом по-тайлово клеить в RAW.

>Нужно только фреймик с настройками
На вкладке Склеить или Экспорт? На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали".
(0007045)
zed (manager)
17-05-2012 06:56
edited on: 17-05-2012 06:57

Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени.

(0007046)
vdemidov (manager)
17-05-2012 07:08

Ну при возможности выделить 1 гиг оперативки этого хватит на склейку картинки шириной в 1 000 000 пикселов. Сравни с 32767 при склейке в bmp. Так что хватит и текущей реализации.
(0007047)
vdemidov (manager)
17-05-2012 07:09

>На вкладке Склеить сейчас фрейма нету, хотя не помешал бы для каждого формата свой фрейм, чтоб лишние настройки не "отсвечивали".
Ага. Нужно сделать.
(0007048)
vdemidov (manager)
17-05-2012 07:12

>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла? Если так, то придётся тогда ещё и с итератером тайлов заморачиваться, чтобы можно было последовательно писать в RAW. Потому как простое предварительное создание битмапа, как в случае с BMP, может отнять неоправданно много времени.
Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл по запросу строки попадающей в диапазон покрываемый талом. Главное что бы эти строки запрашивались последовательно, а в каком порядке не важно.
(0007049)
zed (manager)
17-05-2012 07:30

>на склейку картинки шириной в 1 000 000 пикселов
Делать, так уж нормально и чтоб не возвращаться потом к этому вопросу. А так, размер сводимого RAW будет ограничен размером ОЗУ у пользователя. А кто-то и при 256Мб оперативки захочет создать большой снимок. Имхо, формат RAW тут вопрошается именно как абсолютно безлимитный, с единственным ограничением - свободное место на HDD.

>Это ты о чем? Текущая реализация готовит битмапку шириной в один тайл
Это я про вариант по-тайловой склейки, а не строками.
(0007050)
vdemidov (manager)
17-05-2012 07:44

Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет? На ближайшие годы хватит и текущей реализации.
>А кто-то и при 256Мб оперативки захочет создать большой снимок.
Будет просто своп работать. Долго и беспощадно.
(0007051)
Parasite (administrator)
17-05-2012 08:32

>Задумайся. Квадратная картинка 1 000 000 на 1 000 000 пикселей будет занимать 4 000 000 000 000 байт то есть 4 терабайта. Ты представляешь сколько оно работать будет?
Не шибко дольше, чем линейная запись одного 4Тб файла. При скорости среднестатистического винта в 66Мб\сек - это 16 часов. При учете того, что параллельно надо будет подчитывать мелкие тайлы и таки дергать диск - хрен с ним, сутки работы. Весьма малая кровь для терапиксельного лосслесса...:)

>>А кто-то и при 256Мб оперативки захочет создать большой снимок.
>Будет просто своп работать. Долго и беспощадно.
При нормальной реализации вопроса и обработке потайлово - свопа вообше не будет, так как в памяти одновременно будет висеть не более 1 битмапа 256х256.
(0007052)
Parasite (administrator)
17-05-2012 08:38

>Кстати, а по-умолчанию там чередование строк идёт как у BMP - верхняя строка пикселей физически записана в самом конце файла?
Где это "там"? RAW как раз и подразумевает отсутствие фиксированного формата, это просто голые данные - и свизуализировать их "в картинку" задача просмотрщика, а не писателя. Как сделаешь - так и будет, другими словами. Хоть в шахматном порядке пиксели клей, главное - задокументировать схему записи и размеры по X\Y\bits (для этого и нужен отдельный мелкий файлик рядом).

Обычно предпочитают (чтобы можно было начать отрисовывать сразу по началу чтения) последовательную запись, где начало файла - левый верхний угол картинки, и далее - вправо\вниз. Но это не стандарт, а просто так обычно делают.
(0007053)
zed (manager)
17-05-2012 08:50

>Будет просто своп работать. Долго и беспощадно.
А по-моему, свалится в Out of memory.
(0007054)
vdemidov (manager)
17-05-2012 08:52
edited on: 17-05-2012 08:57

>>Будет просто своп работать. Долго и беспощадно.
> А по-моему, свалится в Out of memory.
Ну если запретить своп или поставить его очень маленьким, то будет. А при достаточном свопе 32-битному приложению доступно до 2 гигов рамки, танцами с бубном можно увеличить до 3-х.

(0007055)
vdemidov (manager)
17-05-2012 08:57

Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :)
>Не шибко дольше, чем линейная запись одного 4Тб файла.
Это если писать построчно с буфером как я предлагаю. А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест по килобайту в разных местах диска. Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.
(0007056)
Parasite (administrator)
17-05-2012 09:31

>Кому будет мало картинок шириной в 1 000 000 пикселей, тот склеит с разрезанием на части по горизонтали, а потом напишет тулзу для сшивания нескольких терабайтных файлов в один :)
Те, кому мало картинок шириной в 1 000 000 пикселей - уже давно написали свои тулзы, благо что это буквально страница кода, а дальше нужно только откинуться на спинку кресла на сутки.
А вот планирование совершенно ненужных костылей по разрезанию битмапов в теме, которая была создана как раз для ухода от разрезания битмапов - это какой-то неверный путь. Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня.

>А если писать по тайлово, то запись каждого файла будет выливаться в запись 256 мест
Совершенно верно.

>Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.
Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это.
Разумеется, некий вменяемый буфер для скорости - нужен, но не такой чтобы сваливать его в своп. Имхо, ниже 256Мб щас ни у кого нет - вот оное и использовать.

PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд.
Выигрыш в том, что сжатые лежащие практически в одном месте жпеги читать много быстрее, чем метаться по всему многогигабайтному РАВу с рандомной записью.
(0007057)
vdemidov (manager)
17-05-2012 09:52

>>Посмотри в тестах современных винтов скорость рандомной записи по одному килобайту.
> Да, это не самый скоростной метод. Зато свопа совершенно не будет - а мы обсуждали именно это.
Ради интереса посмотрел скорость рендомного чтения блоками по 512 байт и 4К на своем винте. Вышло 0.035 Mb/s и 0.287 Mb/s. Тоесть для килобайта будет где-то 0.1 Mb/s
Пересчитай время наполнения 4-х терабайт. :)

>PS: а что мешает держать в буфере не "тайловую" строку 1Мх256, а "пиксельную" строку 1Мх1? То есть, прочитал все нужные тайлы, составил из них однопиксельную полоскут в буфере, кою и слил в RAW. Потом опять прочитал те же тайлы, за второй полоской...итд.
Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку, и винт для чтения этой тучи файлов каждый раз. Так что будет приблизительно эквивалентно свопу по скорости.

>Имхо, если делать - то нормально, ас костылями оно и так сводится прямо сегодня.
Хорошо. Я предложил как получить быстро и просто чуток ограниченное решение. Если его делать никто не хочет, мне то что. Продвинутое и универсальное решение в таком случае делать точно никто не будет.
(0007058)
vdemidov (manager)
17-05-2012 10:02

В общем самый производительный метод склейки в RAW это клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM, а потом склеивать из полученных файлов один гигантский. Быстрее ничего не получится. Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится.
(0007059)
Parasite (administrator)
17-05-2012 10:39

>Пересчитай время наполнения 4-х терабайт. :)
Еще раз: я обсуждал крайний пункт пункт отхода от свопа, а не скорость общей работы. Истина, как водится - посередине.

>Тогда узким местом будет проц, которому для получения каждой строки придется распаковывать тучу файлов и брать из каждого только одну строчку и винт для чтения этой тучи файлов каждый раз.
Ну процессор-то имхо ни при делах - 1Mx1 битмап есть аналог распаковки 1000х1000 цветного жпег-битмапа в памяти (да у меня валлпейпер в 4 раза больше) - особенно если распараллелить эту распаковку 3900 одинаковых тайлов, а вот винту придется попотеть в любом случае. Но это и ожидалось, собссно. Лично я на это полностью согласныйя - цель оправдывает средства.

>клеить кучу файлов с максимальной шириной которую позволяет твой объем RAM
Вернее, которую позволит 32хбитный САС. Я правильно понимаю?
РАМы-то у меня мноооого, только вот ни сас ни 32бит винда не видят больше 3гиг с копейками, а на винде64 подозреваю что ее не увидит один сас......

>а потом склеивать из полученных файлов один гигантский.
Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно?
(0007060)
vdemidov (manager)
17-05-2012 10:53

>Ну процессор-то имхо ни при делах - 1Mx1 битмап
Нет. Он будет распаковывать каждый тайл полностью. Так что для того что бы получить 4 мегабайта строчки результата, ему придется распаковать джепегов на 1 гиг битмапок. И так для каждой строчки. Будет ну очень медленно.
 
>Усилиями САСа (то есть будет что-то вроде пакетной обработки в пределах задачи "Сведение в РАВ"), или сугубо самостоятельно?
А это как захочет тот кто будет эту хотелку реализовывать. Я лишь подсказываю способ как это можно реализовать с минимальной сложностью.
(0007061)
Tolik (manager)
17-05-2012 11:01

> Ну кроме варианта придумать формат с хранением не по строкам, а прямо по тайлам, но это к данной теме вряд ли относится.

> Хоть в шахматном порядке пиксели клей

Так может и правда, можно клеить в тайловом порядке?
(0007062)
Dima2000 (developer)
17-05-2012 11:09

Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов.

Насчёт памяти, 32-х битное приложение не может вроде как получить более 3Г памяти. Но это относится лишь к линейной памяти, в винде есть механизм по типу старого досовского EMS (http://ru.wikipedia.org/wiki/Address_Windowing_Extensions), и вот там получай сколько хочешь (до ограничения самой винды на размер поддерживаемой памяти). И это работает в 32-битной винде. Зато требует явной поддержки со стороны приложения.
PS. Если что, я не проверял как оно работает, но по идее должно.
(0007063)
vdemidov (manager)
17-05-2012 11:12

>Распаковывать исходные файлы по нескольку раз - имхо глупость. Уж лучше памяти больше хапнуть и просчитывать всегда строку тайлов.
Ну оно именно так сейчас и работает, а некоторым кажется, что это слишком просто :)
(0007064)
Dima2000 (developer)
17-05-2012 11:24

>Так может и правда, можно клеить в тайловом порядке?
Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?
(0007067)
Tolik (manager)
17-05-2012 12:00

А, значит, "отсутствие фиксированного формата" - нам не подходит, надо делать под определённые открывалки-гляделки. Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки?
(0007070)
Parasite (administrator)
17-05-2012 12:16

>Нет. Он будет распаковывать каждый тайл полностью.
Я про буфер 1Мх1, который придется держать в памяти как RW (куда и будем клеить полоски 256х1)
А распаковывать (в памяти) тайлы можно и поочередно. Вовсе не обязательно их открывать все сразу.
И более того, все нужные тайлы можно закэшировать в память заранее, это для полоски в 1Мх256 - всего лишь 3900 тайлов, т.е.39мб. Загнав в память 39Мб - на выходе поимеем 1Мх256 на вполне себе линейную запись, и никаких промежуточных дерганий диска на чтение.

>Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?
Кто угодно. Надо просто знать что делаешь и зачем - а это уже за рамками и этого тикета, и этого форума.

>надо делать под определённые открывалки-гляделки.
Вот только попробуй....!!

>Кстати, давно хотел спросить, чем потом открывать такие терапиксельные картинки?
ГеоЭкспресс жрет их на ура и выдает вполне кошерный .sid.
Гисы тоже работают с равами, обеспечивая селективную выборку из файла.
Разумеется, попробовать открыть ЭТО фотошопом - смерти подобно, но это уже не к программе а к юзеру оной, повторяю. Надо понимать, ЗАЧЕМ такие файлы и как с ними делать любоff. То есть - задача довольно специфична сама по себе, но таки нужна.
(0007072)
Dima2000 (developer)
17-05-2012 12:27
edited on: 17-05-2012 12:30

>А распаковывать (в памяти) тайлы можно и поочередно.
Это увеличивает нагрузку на CPU ровно в 256 раз. Хотя, при отсутствии другого выхода, можно и так. А закэшировать 4к тайлов должна и сама винда, уже со второго (и даже первого) их чтения. Да, согласен, в самой SAS проще и быстрее.

>>Клеить можно как угодно. Вопрос кто потом ЭТО сможет открыть?
>Кто угодно.
Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-)
Вопрос как раз в том, чтобы клеить под что-то известное, что может быть открыто (тем же ГеоЭкспрессом). И с текущими ограничениями на память в SAS/винде. Вот я почти уверен, что с интерливом по тайлам открыть никто не сможет, какой бы текстовый файлик не приложили ...

(0007073)
zed (manager)
17-05-2012 12:29

Мне эта задача видится так: спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте. Загружаем подстроку тайлов, гарантированно влезающую в этот кусок озу, производим необходимую обработку и пишем эту подстроку в RAW. Тогда получится, что мы не упадём с out of memory и будем писать на винт не кусочками по 256 пикселей, а достаточно длинными подстроками. Т.е. в частном случае, когда все тайлы строки влазят в память, мы получим тот же вариант, что и сейчас работает для склейки в остальные форматы.

Другими словами, по-хорошему, тут нужен СВОЙ алгоритм манипуляции с тайлами. Тогда будет надёжно и универсально - с любым размером памяти можно будет склеить любой сколь-угодно большой RAW.
(0007074)
Dima2000 (developer)
17-05-2012 12:33
edited on: 17-05-2012 12:35

>спрашиваем у юзера, сколько ОЗУ можно смело отъедать при экспорте
Имхо совершенно лишний и непонятный вопрос. Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80% (остальное - запас винде на всякий случай) свободной _физической_ памяти на текущий момент. Или половину не свободной, а вообще всей.

(0007075)
zed (manager)
17-05-2012 12:39

>Имхо совершенно лишний и непонятный вопрос.
Человеку, решившему связаться с RAW этот вопрос должен быть абсолютно ясен. К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб).
(0007076)
Dima2000 (developer)
17-05-2012 12:48
edited on: 17-05-2012 12:54

Что-то вообще не пойму о чём копья ломаются. Уж если хочется работать с RAW, то память (RAM) нужна по любому. А в 1.5Г памяти влезает полоса 2М*256 ... Т.е. сейчас, без всяких ухищрений, SAS должна клеить картинки до 2М пикселей шириной!

Остальное убил, извините, попутал в расчётах.

(0007077)
zed (manager)
17-05-2012 13:07

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

Вы же, и vdemidov выше, походу предлагаете вообще никак не контролировать этот вопрос и пускай юзер ограбает сам по первое число, если у него мало оперативки.
(0007078)
Parasite (administrator)
17-05-2012 13:22
edited on: 17-05-2012 13:22

>то увеличивает нагрузку на CPU ровно в 256 раз.
Это если попытаться их одновременно распаковать (а зачем?), и до кучи отожрать в памяти х256 места.

>Ну так клейте (экспортом!) в TAR и открывайте! Никаких ограничений вообще. ;-)
Ну так и попробуйте потом из этого тара со жпегами взять RGB конкретного пикселя с конкретными координатами.

>интерливом по тайлам открыть никто не сможет
Даже собственный скрипт не сможет?

>Чтобы не сваливаться в своп можно просто и тупо запросить винду об 80%
А то, что в этой винде может быть УЖЕ запущен какой-нибудь Оракл на 146% ее памяти (УЖЕ со свопом, в смысле) - ты не подумал?

>свободной _физической_ памяти на текущий момент.
А через минуту там запустится Оракл - который так не спрашивает, а тупо ХОЧЕТ свои 80%. А ее нет. И будет тут тикет "А почему Оракла с Сасом конфликтует???"

>К тому же, вопрос этот будет выражен комбобоксом, с предустановленными значениями (64, 256, 512, 1024Мб).
Настоятельно прошу не делать этот совершенно ненужный комбобокс. Надо памяти - либо брать ее от системы МОЛЧА (хай просвопится. Не смертельно), либо см.ниже.

>О том, что нужно либо заранее, перед началом склейки, как-то сообщить юзеру, что он не сможет склеить снимок с Width более чем xxxx, при текущем размере памяти
А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО? Склейка-то та же, вопрос лишь в объеме наполнения входного буфера: 1 тайл или их полоска на всю ширину изображения.
Либо вообще сделать оптимальный автодетект этого буфера (например, делить физ.память на 4 - и упихивать в это макс.кол-во тайлов).

(0007079)
zed (manager)
17-05-2012 13:37
edited on: 17-05-2012 13:38

>А перейти на минимальную стратегию "клеим потайлово и без свопа" - слабО?
Нет не слабо. Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb.

В общем, сделать можно по-разному, поэтому кто первый возмётся (если вообще возмётся) за реализацию, так оно и будет :)

(0007080)
Dima2000 (developer)
17-05-2012 13:42

>>то увеличивает нагрузку на CPU ровно в 256 раз.
>Это если попытаться их одновременно распаковать (а зачем?),
Нет, это если каждый тайл распаковывать по нескольку раз (для получения каждый раз одной строки пикселей, а не всех 256-ти), а не строго один, как сейчас.

Закругляюсь, я похоже не в теме. Вообще не понимаю как можно использовать Планету для работы неделю и более. Картинка 2М*2М пикселей занимает 8К*8К тайлов, 64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток! А читать намного быстрее мелкие тайлы не получится, даже из контейнера трукрипт.

Как получить много памяти под выходной буфер в почти любой винде я вариант предложил, его надо брать проверять, MSDN утверждает что он работает. И даже в своп не попадает! Уж выделить окно в 200К памяти (под один тайл) в _виртуальном_ пространстве всегда можно, это физической памяти не занимает, а дальше лишь успевай дёргать винду для переключения страничек. Для ускорения (чтобы пореже в винду улетать) можно выделить не под 1 тайл, а под 1000, ну или сколько свободно в пространстве SAS-а (а там почти всегда 1.5Г-1.9Г есть).
(0007081)
Parasite (administrator)
17-05-2012 13:43

>Это просто будет ещё один вырожденный случай, если задать максимальное использование памяти < 1Mb.
Угу. Но лично мне и со свопом сойдет - для такой задачи я готов освободить систему. Первый раз что ли "винтом думать"... Это vdemidov тут раскачал лодку. :)
(0007082)
Parasite (administrator)
17-05-2012 13:50

>Нет, это если каждый тайл распаковывать по нескольку раз
Ну и пусть распаковывается. Что такое для современного камня задача "распаковать _из памяти в память_ стандарт прошлого века на битмапе, который без тормозов распаковывается даже на телефоне"?

>Вообще не понимаю как можно использовать Планету для работы неделю и более.
(по секрету) - у меня в job'ах прямо сейчас висит САС с октября прошлого года... Скоро закончит, 98% уже почти по всем из 20и проходов. :)

>64М тайлов будут лишь читаться с диска 64М * 16К/тайл / 1М/с = 12 суток!
...а линейное копирование того же тома (с ровно тем же объемом инфы!) занимает какие то часы. Вывод? Не юзайте медленный и ущербный НТФС, особенно в плане ее давно известных проблем при хранении куч мелких файлов.
(0007083)
vdemidov (manager)
17-05-2012 14:15

>Это vdemidov тут раскачал лодку. :)
А я то чем провинился. Я агитирую делать самым простым возможным способом. Пусть, в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз. И сделать ее просто. Это вы тут развели демагогию, что чем делать ограниченное лучше не делать вообще.
(0007084)
Parasite (administrator)
17-05-2012 14:36

>А я то чем провинился.
Ну первым про своп-то именно ты заикнулся, а зря. Можно подумать, САС сам по себе не свопится, огаога.....А так бы сделал сразу со свопом, и никто бы особо и не заметил.

>в результате, эта склейка будет ограничена, но даже с такими ограничениями она будет превосходить существующие в десятки раз.
Так хочется ж без ограничений. И без свопа. И чтобы быстро! :)

Резюмирую: делать со свопом, но без нарезки на части. Если у юзверя мало памяти - то можно лио попапить ему мессиджбокс, либо тупо забить и пихать в своп (а не хватит - значит, не хватит. Тут уже подсчитали, что 2М по длинной - вполне влезет в своп, а для большего - разумеется и затраты должны быть больше, и там уже будет другой тикет если что).
(0007085)
zed (manager)
17-05-2012 14:52

>она будет превосходить существующие в десятки раз
Забыл добавить: если у пользователя есть +100500 Гб оперативки.
Так же, не путай: ограниченный вариант - это когда мы заранее просчитываем, сколько нам и чего можно выделять для текущей операции и ставим себя в эти рамки. Текущая же склейка, ничем не ограничена, и будет вываливаться с ошибками (и не вываливается до сих пор только из-за того, что максимальное разрешение существующих форматов относительно невелико). Оно тебе надо? Ну закроешь ты этот тикет - появится рядышком новый - сделать экспорт в RAW без ограничений на использование оперативки. И будет стоять ровно та же задача - написать новый алгоритм. Я ещё понимаю, если бы формат был "горячий" вроде jpeg, без которого в общем-то никуда (потому и терпели вылеты), но тут же никто в плечи не гонит, главное чтобы работало стабильно.
(0007086)
Dima2000 (developer)
17-05-2012 14:52
edited on: 17-05-2012 15:14

>2М по длинной
Не по длинной, а именно по ширине. Высота может быть любой, раз говорят что SAS теперь клеит потайлово по вертикали.

Натыкался на какой-то баг при общем количестве тайлов более 2млрд, но не помню где именно. Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали). А вполне вероятно в склейке бага и нет.

(0007087)
zed (manager)
17-05-2012 14:53

>и там уже будет другой тикет если что).
Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :)
(0007089)
Parasite (administrator)
17-05-2012 15:15

>но тут же никто в плечи не гонит, главное чтобы работало стабильно.
+100500, и вот например у меня 32Гб оперативки - и вот убедите меня (как юзера), что мне ее не хватит? Когда скриптам - хватает и 128Мб на всё (клею потайлово - медленно, зато гарантированно и ДЕЙСТВИТЕЛЬНО безразмерно). А так как клею через весьма большие многогигабайтные системные буферы - то и ничуть не медленно даже. :)

>Не по длинной, а именно по ширине.
Тем более.

>Ну значит нефик клеить сразу весь мир на z20 и выше.
А если ВНЕЗАПНО захочется? :)

>Ну вот, о чём я и говорил - новый тикет не заставит себя ждать :)
C другой стороны, таких упоротых гиков надо будет тут на сасгисе еще поискать. Для начала - таких винтов пока еще нету, чтобы прочувствовать лимиты и тикет делать... :)

Да, кстати - до кучи надо продумать момент дырок в РАВе. Либо клеить заранее определенное значение RGB при натыкании на дырку (и тогда нужно бы возможность определения этого дефолтового цвета для дырок), либо сперва заполнять весь рав этим цветом - а потом клеить тайлы какие найдутся (а в дырках цвет останется автоматически). Первый вариант имхо более разумен.
(0007090)
Parasite (administrator)
17-05-2012 15:19

>Да и 2Г тайлов, это полоса 8К*256К тайлов, а это минимум z19 (и весь мир по вертикали).
Минус дырки, заметь.
(0007092)
Dima2000 (developer)
17-05-2012 15:44

>Минус дырки, заметь.
В полосе выделения дырок быть не может. Насколько я знаю, SAS не поддерживает многосвязные выделения.

>>Ну значит нефик клеить сразу весь мир на z20 и выше.
>А если ВНЕЗАПНО захочется? :)
Уменьшать ширину, не 8К тайлов в полосе, а меньше.
Или использовать не SAS. ;-)
(0007093)
Parasite (administrator)
17-05-2012 15:50

>В полосе выделения дырок быть не может.
Неужели?

>Уменьшать ширину, не 8К тайлов в полосе, а меньше.
>Или использовать не SAS. ;-)
...или сделать нормальный, безлимитный алгоритм. Время-то есть, как правильно указал товарищ zed.
(0007096)
Parasite (administrator)
17-05-2012 16:45
edited on: 17-05-2012 16:53

>Неужели? Объясните плиз в личку или на форуме как создать область выделения, с внутренней не соединённой с границами дыркой? Или хоть ссылку где про это написано?
Понятия не имею. Выше я про дырки в кэше (= отсуствующие на сервере тайлы) в границах пользовательского выделения, а не про саму "изящно-дырявую" рамку выделения как таковую.

Очевидно же, что выделив ВЕСЬ мир и сводя его например в 19м уровне - получим пустые места в кэше весьма много где, ибо те же окияны кончаются на 12м уровне если не ошибаюсь (а они токи попадают в выделение "весь_мир"). То есть, на 19м зуме на 2\3 выделения будет 404 еррор, и этот момент нам надо будет как-то отдельно отрабатывать. Заливать дефолтовым цветом или еще как иначе, бо "истинно-дырявых" форматов растров пока еще не придумали.

(0007523)
Parasite (administrator)
19-06-2012 09:48

Кстати, вот тулза делающая как раз "сведение безразмерных битмапов через винт" (но платная): http://www.mcrenox.com.ar/vlijoiner/

Интересно, как они обошли лимиты BMP на размер? Скорее всего - никак.... :)
(0015933)
zed (manager)
16-05-2015 08:26

Да ну, каких безразмерных? Ты почитай: "output format is PNG or BMP", так что у них максимум 64k для PNG и 32k для BMP. Эти лимиты не обойдёшь. Безразмерные это всякие ECW/J2K/RAW, но никак не BMP :)

- Users who viewed this issue
User List Anonymous (4635x), VMatveev (6x), netsky (1x)
Total Views 4642
Last View 29-03-2024 15:04

- Issue History
Date Modified Username Field Change
04-12-2010 20:02 Parasite New Issue
06-12-2010 09:28 vdemidov Status new => acknowledged
06-12-2010 09:28 vdemidov Product Version => 101201
06-12-2010 09:28 vdemidov Target Version => 110311.Alfa
06-12-2010 10:21 vdemidov Target Version 110311.Alfa => 24xxxx
07-04-2011 01:38 gpsMax Tag Attached: склейка
07-04-2011 01:38 gpsMax Tag Attached: экспорт
09-04-2011 14:04 gpsMax Tag Attached: raw
11-04-2011 07:09 vdemidov Status acknowledged => confirmed
17-05-2012 05:14 vdemidov Note Added: 0007038
17-05-2012 05:15 vdemidov Relationship added related to 0001213
17-05-2012 06:41 zed Note Added: 0007041
17-05-2012 06:56 zed Note Added: 0007045
17-05-2012 06:57 zed Note Edited: 0007045 View Revisions
17-05-2012 07:08 vdemidov Note Added: 0007046
17-05-2012 07:09 vdemidov Note Added: 0007047
17-05-2012 07:12 vdemidov Note Added: 0007048
17-05-2012 07:30 zed Note Added: 0007049
17-05-2012 07:44 vdemidov Note Added: 0007050
17-05-2012 08:32 Parasite Note Added: 0007051
17-05-2012 08:38 Parasite Note Added: 0007052
17-05-2012 08:50 zed Note Added: 0007053
17-05-2012 08:52 vdemidov Note Added: 0007054
17-05-2012 08:57 vdemidov Note Added: 0007055
17-05-2012 08:57 vdemidov Note Edited: 0007054 View Revisions
17-05-2012 09:31 Parasite Note Added: 0007056
17-05-2012 09:52 vdemidov Note Added: 0007057
17-05-2012 10:02 vdemidov Note Added: 0007058
17-05-2012 10:39 Parasite Note Added: 0007059
17-05-2012 10:53 vdemidov Note Added: 0007060
17-05-2012 11:01 Tolik Note Added: 0007061
17-05-2012 11:09 Dima2000 Note Added: 0007062
17-05-2012 11:12 vdemidov Note Added: 0007063
17-05-2012 11:24 Dima2000 Note Added: 0007064
17-05-2012 12:00 Tolik Note Added: 0007067
17-05-2012 12:16 Parasite Note Added: 0007070
17-05-2012 12:27 Dima2000 Note Added: 0007072
17-05-2012 12:29 zed Note Added: 0007073
17-05-2012 12:30 Dima2000 Note Edited: 0007072 View Revisions
17-05-2012 12:33 Dima2000 Note Added: 0007074
17-05-2012 12:35 Dima2000 Note Edited: 0007074 View Revisions
17-05-2012 12:39 zed Note Added: 0007075
17-05-2012 12:48 Dima2000 Note Added: 0007076
17-05-2012 12:54 Dima2000 Note Edited: 0007076 View Revisions
17-05-2012 13:07 zed Note Added: 0007077
17-05-2012 13:22 Parasite Note Added: 0007078
17-05-2012 13:22 Parasite Note Edited: 0007078 View Revisions
17-05-2012 13:37 zed Note Added: 0007079
17-05-2012 13:38 zed Note Edited: 0007079 View Revisions
17-05-2012 13:42 Dima2000 Note Added: 0007080
17-05-2012 13:43 Parasite Note Added: 0007081
17-05-2012 13:50 Parasite Note Added: 0007082
17-05-2012 14:15 vdemidov Note Added: 0007083
17-05-2012 14:36 Parasite Note Added: 0007084
17-05-2012 14:52 zed Note Added: 0007085
17-05-2012 14:52 Dima2000 Note Added: 0007086
17-05-2012 14:53 zed Note Added: 0007087
17-05-2012 15:14 Dima2000 Note Edited: 0007086 View Revisions
17-05-2012 15:15 Parasite Note Added: 0007089
17-05-2012 15:19 Parasite Note Added: 0007090
17-05-2012 15:44 Dima2000 Note Added: 0007092
17-05-2012 15:50 Parasite Note Added: 0007093
17-05-2012 16:03 Dima2000 Note Added: 0007094
17-05-2012 16:31 Dima2000 Note Deleted: 0007094
17-05-2012 16:45 Parasite Note Added: 0007096
17-05-2012 16:53 Parasite Note Edited: 0007096 View Revisions
19-06-2012 09:48 Parasite Note Added: 0007523
30-04-2015 14:09 vdemidov Assigned To => vdemidov
30-04-2015 14:09 vdemidov Status confirmed => assigned
15-05-2015 19:55 vdemidov Tag Attached: VIP
15-05-2015 19:56 vdemidov Status assigned => resolved
15-05-2015 19:56 vdemidov Fixed in Version => 150915
15-05-2015 19:56 vdemidov Resolution open => fixed
15-05-2015 19:56 vdemidov Target Version 24xxxx => 150915
16-05-2015 08:26 zed Note Added: 0015933



Copyright © 2007 - 2024 SAS.Planet Team